From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 4 07:51:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07562 for ; Tue, 4 Jan 2005 07:51:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CloLn-0004KW-Hr for forces-archive@IETF.ORG; Tue, 04 Jan 2005 08:03:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F32186@cherry.ease.lsoft.com>; Tue, 4 Jan 2005 7:51:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 51898769 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 4 Jan 2005 07:51:01 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 4 Jan 2005 07:34:17 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Tue, 4 Jan 2005 20:57:37 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Tue, 4 Jan 2005 20:34:03 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> Date: Tue, 4 Jan 2005 20:30:32 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi, Happy New Year! Incidentally this may be the first post for 2005 :) While I agree the path-data issue may become an important issue for further protocol issue resolution, I just find that we may not in a very efficient way to deal with it. Recalling the argument we'v had, I have a feeling that to resolve this issue quickly we may need the model team to proceed one step ahead, that is, to define at least one LFB(e.g., a LPF IPv4 LFB) with all its attributes presented, based on the model defined schema for LFBs. Let's think that if we have such an LFB, I suppose it will be much easier for the protocol team to proceed with its encoding as well as the path-data PDU for protocol. Best regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: Re: [issue6] Summary of Path Jamal, Joel, Weiming, Firstly, v. sorry about my late response on this issue. I went thru this thread, but it wasn't clear to me what the final summary was or which email I should respond to. I think this is a very important issue so if one of you could summarize this and point out the outstanding aspects, etc., it would make it easy for myself and others to comment on this. Even if you could point me to one of your previous emails that has this, it would be good. Sorry for the trouble, but I would hate to respond with an inaccurate idea about where this issue currently stands. Thanks Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 5 11:12:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17184 for ; Wed, 5 Jan 2005 11:12:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmDyE-0000EM-7R for forces-archive@IETF.ORG; Wed, 05 Jan 2005 11:25:15 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F353C9@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 11:12:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52091618 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 11:12:10 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 11:00:51 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005010508002015:9548 ; Wed, 5 Jan 2005 08:00:20 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792B5@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/05/2005 08:00:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/05/2005 08:00:23 AM, Serialize complete at 01/05/2005 08:00:23 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1104940846.1117.206.camel@jzny.localdomain> Date: Wed, 5 Jan 2005 11:00:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025792B5@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Happy New Year Hormuzd and everybody else, On Mon, 2004-12-27 at 02:54, Khosravi, Hormuzd M wrote: > So the summary of what i am saying is the FE OBject LFB is a source as > well as sink of the Association msg/response. If there are any > attributes already known to the FE then it makes sense to notify the CE > of their state (the name being one of them). > [HK] Yes I agree with that...similar to what I am saying. I think we > will need both the FE Object and FE Protocol object to be advertised in > the Association message. Agreed. > > Let me know how you would like to resolve this? Any suggestions would > be > > welcome. > > Isnt this discussion the point? If we dont get anywhere i will capture > it in the tracking database. [I think if we agree with the comments > above, we have resolved this one...atleast partly] > Indeed. > > One more thing, you had asked for a special TLV -> FORCES_REASON for > > the Teardown msg. Since we would both like to avoid this, any suggestions > on > > how this can be accommodated via FE LFBs? May be we remove the Reason > > completely from the Teardown msg?...let me know your thoughts? > > This is a hard one. We could send it easily (either direction) if it is > an attribute. I think for logging debugging purposes we would need to > know the departure reasons. But whose attribute is this? > Maybe other people have opinions. > [HK] We could use similar mechanism as we do to report all our results, > to report the Reason. Let me know your thoughts, The challenge is that each data sent needs to have a path associated with it. We need to tie it to some path. What do other people think? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 5 11:17:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17567 for ; Wed, 5 Jan 2005 11:17:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmE3p-0000NO-4b for forces-archive@IETF.ORG; Wed, 05 Jan 2005 11:31:01 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F353D0@cherry.ease.lsoft.com>; Wed, 5 Jan 2005 11:17:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52092082 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 5 Jan 2005 11:17:58 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 5 Jan 2005 11:16:37 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005010508160197:9579 ; Wed, 5 Jan 2005 08:16:01 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/05/2005 08:16:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/05/2005 08:16:08 AM, Serialize complete at 01/05/2005 08:16:08 AM Content-Type: multipart/mixed; boundary="=-p48gvoi3sQ7z/Sq7WUZc" Message-ID: <1104941788.1118.223.camel@jzny.localdomain> Date: Wed, 5 Jan 2005 11:16:28 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff --=-p48gvoi3sQ7z/Sq7WUZc Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-01-04 at 07:30, Wang,Weiming wrote: > Hi, > > Happy New Year! > > Incidentally this may be the first post for 2005 :) > And this is the third ;-> > While I agree the path-data issue may become an important issue for further > protocol issue resolution, I just find that we may not in a very efficient way > to deal with it. We need to make progress. If progress requires that we go with some basic stuff initially, then thats the path we should take. It seems very apparent that using basic indexing is very simple and no complaints whatsoever about it. Block paths was the next simple thing. Keying and interleaving with above is so far the outstanding issue. I believe were approaching closure before you got busy. So if you have time now, please lets go back to where we left off. Otherwise we need to put a time limit on this so we can move on. Chairs please chip in here. > Recalling the argument we'v had, I have a feeling that to > resolve this issue quickly we may need the model team to proceed one step ahead, > that is, to define at least one LFB(e.g., a LPF IPv4 LFB) with all its > attributes presented, based on the model defined schema for LFBs. Something like IPV4 LFB would be too complicated (because it needs dependencies on other LFBs and in itself doesnt serve the purpose of describing things we are stuck on). But you propose a good idea: Lets define an LFB that has all the needed roadblocks to move forward. We already have the NOOP LFB for the basics. I added basic events to it (attached - you need the LFB.xsd i mod'ed to validate it). Joel, take a look at the events bits and tell me if we are still synced. NOOP is sufficient for a simple LFB definition. We should define a second LFB, ComplexNOOP. This will have all the twists you can think of (content reference, attribute sharing, multilevel tables). Interop should mandate that these two LFBs are involved. > Let's think > that if we have such an LFB, I suppose it will be much easier for the protocol > team to proceed with its encoding as well as the path-data PDU for protocol. Refer to comments above. cheers, jamal --=-p48gvoi3sQ7z/Sq7WUZc Content-Disposition: attachment; filename=noop.xml Content-Type: text/xml; name=noop.xml; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit pathlink A series of 32 bits representing a path pathlen 1 the count of paths int32 verbose 2 whether data should be sent when event happens boolean path 3 path entities uint32 dummyStruct table entry type for dummy LFB foo1 3 foo1 attribute int32 foo2 4 foo2 attribute int32 NOOP 5 a dummy class for explanation 1.0 baseclass fooInput Packet input fooOutput Packet output EvPTable 1 table of paths to attributes of interest pathlink dataTable 2 the table of NooP information dummyStruct --=-p48gvoi3sQ7z/Sq7WUZc-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 6 14:32:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07074 for ; Thu, 6 Jan 2005 14:32:21 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdZg-0004tb-My for forces-archive@IETF.ORG; Thu, 06 Jan 2005 14:45:39 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F38B25@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 14:32:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52267094 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 14:32:09 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 14:31:43 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j06JVgBU020096; Thu, 6 Jan 2005 19:31:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j06JVXuk012263; Thu, 6 Jan 2005 19:31:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005010611313706385 ; Thu, 06 Jan 2005 11:31:38 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jan 2005 11:31:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcTzQVR+sA6PtgyVSNeMBSs1j4p3yAA5LXqg X-OriginalArrivalTime: 06 Jan 2005 19:31:20.0584 (UTC) FILETIME=[4CB15080:01C4F426] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03D07E23@orsmsx408> Date: Thu, 6 Jan 2005 11:31:19 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Happy New Year to All! Jamal, seems like we have resolved this issue (1) with the exception of the details of Reason in Teardown msg. I think we can probably work on that in a conference call with the rest of the team since no one seems to be responding on the list. Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, January 05, 2005 8:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Happy New Year Hormuzd and everybody else, On Mon, 2004-12-27 at 02:54, Khosravi, Hormuzd M wrote: > So the summary of what i am saying is the FE OBject LFB is a source as > well as sink of the Association msg/response. If there are any > attributes already known to the FE then it makes sense to notify the CE > of their state (the name being one of them).=20 > [HK] Yes I agree with that...similar to what I am saying. I think we > will need both the FE Object and FE Protocol object to be advertised in > the Association message.=20 Agreed.=20 > > Let me know how you would like to resolve this? Any suggestions would > be > > welcome. >=20 > Isnt this discussion the point? If we dont get anywhere i will capture > it in the tracking database. [I think if we agree with the comments > above, we have resolved this one...atleast partly] >=20 Indeed. > > One more thing, you had asked for a special TLV -> FORCES_REASON for > > the Teardown msg. Since we would both like to avoid this, any suggestions > on > > how this can be accommodated via FE LFBs? May be we remove the Reason > > completely from the Teardown msg?...let me know your thoughts? >=20 > This is a hard one. We could send it easily (either direction) if it is > an attribute. I think for logging debugging purposes we would need to > know the departure reasons. But whose attribute is this? > Maybe other people have opinions. > [HK] We could use similar mechanism as we do to report all our results, > to report the Reason. Let me know your thoughts, The challenge is that each data sent needs to have a path associated with it. We need to tie it to some path. What do other people think?=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 6 15:40:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14319 for ; Thu, 6 Jan 2005 15:40:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmedI-00083o-HN for forces-archive@IETF.ORG; Thu, 06 Jan 2005 15:53:25 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F38EAB@cherry.ease.lsoft.com>; Thu, 6 Jan 2005 15:40:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52275702 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 6 Jan 2005 15:40:02 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 6 Jan 2005 15:39:35 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j06KdXXD029757; Thu, 6 Jan 2005 20:39:34 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j06KdXue029531; Thu, 6 Jan 2005 20:39:33 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005010612393315261 ; Thu, 06 Jan 2005 12:39:33 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jan 2005 12:39:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue2] feedback on section 6.3 Thread-Index: AcTkdn1cPWR7g1pFTkWiBGpsVLCabgPsANHw X-OriginalArrivalTime: 06 Jan 2005 20:39:32.0510 (UTC) FILETIME=[D3ABABE0:01C4F42F] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03D07FE8@orsmsx408> Date: Thu, 6 Jan 2005 12:39:30 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue2] feedback on section 6.3 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Jamal, Other than the editorial changes below, can we close this issue ? I'll be sending email to Avri with all the editorial changes. Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, December 17, 2004 12:20 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue2] feedback on section 6.3 On Wed, 2004-12-15 at 19:19, Khosravi, Hormuzd M wrote: > Issue 2 is also editorial changes...pls see my comments below, >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >=20 > - 6.3.1 Config Message >=20 > + "Config data" should be "Config data and path" [will do] >=20 > + Type is bad to describe operations. That should be operations > [Type=3DOperations, since it's a nested TLV] I think more readable to say operation =3D XXXX >=20 > + UPDATE/REPLACE, DEL ALL are really flag extensions which will become > clear once we have path-data noise cleared. Suggest you remove.=20 > [these are basic operations that we agreed on, not sure how path-data > affects them...but we can remove at later point if they are not needed] >=20 > + What is PACKET SUBSCRIBE/UNSUBSCRIBE? [this will be removed] >=20 > - 6.3.2 Config Response Message >=20 > Why do we have " Operation Result " > As far as i can see it is sufficient to look at the Main header type, > a operation, path and its associated data. > Unless this is meant to be a less verbose result? [yes] >=20 > + BTW, what is the point of mentioning "single or Array LFB > specific result entries" or result might be TLV. Just say the=20 > presentation of the data is stuill under discussion.=20 > [ok, will make this change] ok. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 7 23:49:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25496 for ; Fri, 7 Jan 2005 23:49:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn8ku-0005AL-Ji for forces-archive@IETF.ORG; Sat, 08 Jan 2005 00:03:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F3B3E4@cherry.ease.lsoft.com>; Fri, 7 Jan 2005 23:49:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52465031 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 7 Jan 2005 23:49:30 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 7 Jan 2005 23:49:04 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 8 Jan 2005 13:13:07 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 8 Jan 2005 12:48:45 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> Date: Sat, 8 Jan 2005 12:45:08 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [issue6] Summary of Path > On Tue, 2005-01-04 at 07:30, Wang,Weiming wrote: > > While I agree the path-data issue may become an important issue for further > > protocol issue resolution, I just find that we may not in a very efficient way > > to deal with it. > > We need to make progress. If progress requires that we go with some > basic stuff initially, then thats the path we should take. It seems very > apparent that using basic indexing is very simple and no complaints > whatsoever about it. Block paths was the next simple thing. Keying and > interleaving with above is so far the outstanding issue. > I believe were approaching closure before you got busy. > So if you have time now, please lets go back to where we left off. > Otherwise we need to put a time limit on this so we can move on. Chairs > please chip in here. [Weiming]I'm sorry I didn't reply too often laterly, but I think I'v clearly expressed my views regarding things like the Key that Joel proposed. To repeat my views, 1. the Key is actually a kind of things to substitute a subpath with another ID, like keyValue=f1.g1.h2, keyID=1 Therefore it's a kind of duplicating for IDs, if the subpath is something like a purely a f1, then the key becomes keyValue=f1, keyID=1 Therefore, my thinking is it's really a duplicating work. 2. If we want to really limit the search field for an attribute, I think we can just use things like a property of 'Search-allowed' or 'Search-denied', instead of defining another key. 3. I even thought to use attribute property to limit the search is unnecessary, it just leads to too much implementation oriented, which limits the progress. Actually, the protocol can deal with it just by responses, i.e., doing unsupported searching will lead to an error response by the protocol. Another problem with the Key propose is, it's just a kind of initial thinking. I think Joel or the model team should give more details on what it really looks like. I don't think it's very efficient for the protocol team to discuss the ideas that the model team itself is still not very clear. That's why I strongly suppose a quite complete LFB definition be presented, with which ideas of things like index, key, path can be clearly described. To speak of this, I have to say, along with the more discussions, I just find that we (including Jamal, Joel, and me) seem to have even differences on the basis of the definitions like paths, index, and key also. For example, I think a path is a PDU that is defined by protocol, while I see Jamal's NOOP LFB, it seems defined there, i.e., the individual LFBs define individual Paths, and the Path itself is an LFB attribute? This is far from I thought. I also have doubt on the index. My very original thought was that we can use an attribute of 'index' for indexing, therefore we don't have index in the protocol. Then, Joel proposed that the index should be by protocol instead of the LFB attribute, so I tried to go in this way. Along with the discussions we have, I find it maybe not really so. It seems sometimes you think it is a pure index used by protocol, sometime it is defined by LFB. All this makes me believe that a relatively perfect LFB attribute definition from model team is very helpful for our further discussion. Of coarse, in the process to form such a LFB, we'l be very pleased to join to discuss. Jamal presented a good start with the NOOP LFB, I suppose. Thank you. Weiming > > > Recalling the argument we'v had, I have a feeling that to > > resolve this issue quickly we may need the model team to proceed one step ahead, > > that is, to define at least one LFB(e.g., a LPF IPv4 LFB) with all its > > attributes presented, based on the model defined schema for LFBs. > > Something like IPV4 LFB would be too complicated (because it needs > dependencies on other LFBs and in itself doesnt serve the purpose of > describing things we are stuck on). > But you propose a good idea: Lets define an LFB that has all the needed > roadblocks to move forward. We already have the NOOP LFB for the basics. > I added basic events to it (attached - you need the LFB.xsd i mod'ed to > validate it). Joel, take a look at the events bits and tell me if we are > still synced. > NOOP is sufficient for a simple LFB definition. We should define a > second LFB, ComplexNOOP. This will have all the twists you can think of > (content reference, attribute sharing, multilevel tables). Interop > should mandate that these two LFBs are involved. > > > Let's think > > that if we have such an LFB, I suppose it will be much easier for the protocol > > team to proceed with its encoding as well as the path-data PDU for protocol. > > Refer to comments above. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 8 00:26:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27560 for ; Sat, 8 Jan 2005 00:26:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn9K8-0006yk-Ei for forces-archive@IETF.ORG; Sat, 08 Jan 2005 00:39:50 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F3B475@cherry.ease.lsoft.com>; Sat, 8 Jan 2005 0:26:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52468631 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 8 Jan 2005 00:25:58 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 8 Jan 2005 00:25:18 -0500 Received: from [68.232.106.249] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8569937 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 08 Jan 2005 00:25:17 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050108001135.03b85490@localhost> Date: Sat, 8 Jan 2005 00:24:57 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c There are a couple of specific aspects that I think it may help to spell out. 1) Remember that the fileds may be defined in a data type that is imported. That is, an array may be defined as having as content a structure of type "IP-information" which in turn has a field of type "IP address prefix". It seems clear to me that the structure definition can not include the indiciation as to whether IP address prefix is a key in some array, since the structure is used in many places. 2) I believe that the FE implementation needs the information as to what keys are likely to be used by the CE> The model is the only thing that can give this guidance. 3) While the FE can return errors, the CE is helped by knowing what kinds of indexing are likely to work. While this can be done with capabilities, I have several concerns with that 3a) representing the legal keys as capabilities just gets messy 3b) I think that CE implementors will be helped by knowing what keying the FE will support. Interoperability requires some common core set. If FE implementors get to chose, multi-vendor CEs will just use that core set. Hence, if we want this keying to be used and usable, we need to define what will be supported. The model is the right place to do that. Given that we are going to define keying in the model, there are several possible approaches. Zsolt and I have batted a couple back and forth, but I doubt if we have found them all. I actually don't like any of these ideas. a) the key-id approach I suggested b) have a key TLV consist of a sequence of path-fragment / value pairs, (similar to what I think Weiming is proposing) with a restriction that only those combinations which have been declared to be keys may be used. c) restrict keying to path identifiable fields, and restrict it to being used only with full array element references at the end of the path. Then use a flag associated with the path to indicate that content keying is being used, and the last part of the path references the key. I think that the exact mechanism is less important than the questions of whether the keying must be pre-declared in the model, and whether key elements must be unique. If we can agree on those two questions, we can sketch enough protocol to keep moving. Yours, Joel M. Halpern At 11:45 PM 1/7/2005, Wang,Weiming wrote: >[Weiming]I'm sorry I didn't reply too often laterly, but I think I'v clearly >expressed my views regarding things like the Key that Joel proposed. To >repeat >my views, >1. the Key is actually a kind of things to substitute a subpath with >another ID, >like > keyValue=f1.g1.h2, keyID=1 >Therefore it's a kind of duplicating for IDs, if the subpath is something >like a >purely a f1, then the key becomes > keyValue=f1, keyID=1 >Therefore, my thinking is it's really a duplicating work. >2. If we want to really limit the search field for an attribute, I think >we can >just use things like a property of 'Search-allowed' or 'Search-denied', >instead >of defining another key. >3. I even thought to use attribute property to limit the search is >unnecessary, >it just leads to too much implementation oriented, which limits the progress. >Actually, the protocol can deal with it just by responses, i.e., doing >unsupported searching will lead to an error response by the protocol. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 9 23:25:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01896 for ; Sun, 9 Jan 2005 23:25:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnrLA-0006a5-4l for forces-archive@IETF.ORG; Sun, 09 Jan 2005 23:39:43 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F3EAD7@cherry.ease.lsoft.com>; 9 Jan 2005 23:25:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52698725 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 23:25:38 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 23:21:38 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005010920210369:20054 ; Sun, 9 Jan 2005 20:21:03 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:21:04 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:21:06 PM, Serialize complete at 01/09/2005 08:21:06 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105330894.1040.50.camel@jzny.localdomain> Date: Sun, 9 Jan 2005 23:21:34 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050108001135.03b85490@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit On Sat, 2005-01-08 at 00:24, Joel M. Halpern wrote: > There are a couple of specific aspects that I think it may help to spell out. [..] > I think that the exact mechanism is less important than the questions of > whether the keying must be pre-declared in the model, and whether key > elements must be unique. > If we can agree on those two questions, we can sketch enough protocol to > keep moving. The predeclared keys are a good hint to the CE, but without capabilities (which i also have strong distate for in this case) the backup is to for the FE to reject a requested content operation. In other words, I do think that it is practical to say have a ASIC vendor implementing the some LFB not supporting any content searches. So given that, the only value to predeclaring is giving a good hint to the CE. I think its still a good thing to have and we should add it. Heres where i think the two biggest discrepancies so far are and that need to be resolved: 1) interleaving of path-data-path-data .. So far Joel and myself have been saying you have path [pathfilter] [data] This is for simplicty reasons (and that a path leads to data) Weiming is asking for: path pathfilter data pathfilter data ... subpath is what is refered as a pathfilter above (content or block refinement of the path). When you look at what you end up dumping in say a table that has colums pointing to another table; then you can see that we would end up doing what Weiming is asking for. The examples i presented around November infact showed this. The problem with Weiming's approach is the overhead in the case of large quantities of data (either dumping from FE or setting to the FE). You end up with a lot of nested TLVs. And thats not efficient packing of data (consider 100K L3 table with each entry chewing an extra 8 bytes of overhead and requiring two extra TLV levels) Compromise: I think we should allow the path-data-path-data interleaving but also allow a "cooked" mode bulk/batched operation for efficiency purposes 2) for the keys: i) Weiming asking for equality notation. Example foo1=10 all the way to "foo1<10", "foo1 is in the range of 1,10" etc Joel unhappy with this... My opinion for compromise: I think it will be easier to just enforce to "=" sign only. The block notations should allow for lists and ranges (I am not sure i see it for field IDs). ii) Weiming asking for multiple keys with logical operators example: "foo1=10" OR "foo2=200" AND "foo3=14" My opinion for compromise: I think we should allow for multiple keys but restrict logical operation to AND only. Infact the AND is implicit in the fact you have a series of key operations. It should be noted that what Weiming is asking for is more flexible and future proof; however, as Joel has pointed out numerous times we should try a much as we can to leave the intelligence to the CE and not turn the FE into a database engine. [As an example the CE should be able to resolve all entries that have "foo1=10 OR foo2=100" and then make an exact request to the FE what paths are being targeted]. To chip in my opinion: As we learn more from experience we could add more features - but for now, lets cut down to just the basics. If people are in agreement i can redo my earlier text with the above suggested changes and bounce it on the list. Weiming/Joel - lets hear from you. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 9 23:25:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01918 for ; Sun, 9 Jan 2005 23:25:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnrLH-0006aG-1T for forces-archive@IETF.ORG; Sun, 09 Jan 2005 23:39:48 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F3EBBF@cherry.ease.lsoft.com>; 9 Jan 2005 23:25:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52698744 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 23:25:46 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 23:23:19 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005010920224566:20058 ; Sun, 9 Jan 2005 20:22:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E03D07FE8@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:22:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:22:47 PM, Serialize complete at 01/09/2005 08:22:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105330996.1041.52.camel@jzny.localdomain> Date: Sun, 9 Jan 2005 23:23:16 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue2] feedback on section 6.3 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03D07FE8@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hormuzd, On Thu, 2005-01-06 at 15:39, Khosravi, Hormuzd M wrote: > Jamal, > > Other than the editorial changes below, can we close this issue ? > I'll be sending email to Avri with all the editorial changes. > That would be good nuf to close it. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 9 23:25:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01944 for ; Sun, 9 Jan 2005 23:25:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnrLN-0006aa-Eb for forces-archive@IETF.ORG; Sun, 09 Jan 2005 23:39:54 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F3EA3C@cherry.ease.lsoft.com>; 9 Jan 2005 23:25:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52698764 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 9 Jan 2005 23:25:52 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 9 Jan 2005 23:25:10 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005010920243774:20061 ; Sun, 9 Jan 2005 20:24:37 -0800 References: <468F3FDA28AA87429AD807992E22D07E03D07E23@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:24:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/09/2005 08:24:38 PM, Serialize complete at 01/09/2005 08:24:38 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105331108.1040.55.camel@jzny.localdomain> Date: Sun, 9 Jan 2005 23:25:08 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03D07E23@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit On Thu, 2005-01-06 at 14:31, Khosravi, Hormuzd M wrote: > Happy New Year to All! > > Jamal, seems like we have resolved this issue (1) with the exception of > the details of Reason in Teardown msg. I think we can probably work on > that in a conference call with the rest of the team since no one seems > to be responding on the list. Sounds reasonable. In any case, if we ever have a conference call i think it should be to shoot for resolving the path-data issue which in my opinion is the show stopper. All these other issues outstanding at the moment are pretty much resolvable each in less than 10 minutes. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 02:02:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11945 for ; Mon, 10 Jan 2005 02:02:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cntmo-0003L5-AA for forces-archive@IETF.ORG; Mon, 10 Jan 2005 02:16:28 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F3EE7F@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 2:02:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52708599 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 02:02:08 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 02:01:26 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0A71UfX014605; Mon, 10 Jan 2005 07:01:30 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0A71M4M031356; Mon, 10 Jan 2005 07:01:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005010923013030279 ; Sun, 09 Jan 2005 23:01:30 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 9 Jan 2005 23:01:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcT2zHqOjjdqIYl5QZWhwIcr8CijbgAFZ73w X-OriginalArrivalTime: 10 Jan 2005 07:01:30.0271 (UTC) FILETIME=[36075AF0:01C4F6E2] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792C3@orsmsx408> Date: Sun, 9 Jan 2005 23:01:19 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Agree completely. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation=20 In any case, if we ever have a conference call i think it should be to shoot for resolving the path-data issue which in my opinion is the show stopper. All these other issues outstanding at the moment are pretty much resolvable each in less than 10 minutes. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 09:49:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23071 for ; Mon, 10 Jan 2005 09:49:43 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co157-0003aU-Na for forces-archive@IETF.ORG; Mon, 10 Jan 2005 10:03:50 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F3F3E4@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 9:49:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52786331 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 09:49:34 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 09:47:24 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Mon, 10 Jan 2005 23:12:06 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 10 Jan 2005 22:47:10 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> Date: Mon, 10 Jan 2005 22:43:32 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi Jamal, Joel as well, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [issue6] Summary of Path > > Heres where i think the two biggest discrepancies so far are and that > need to be resolved: > > 1) interleaving of path-data-path-data .. > So far Joel and myself have been saying you have > path [pathfilter] [data] > This is for simplicty reasons (and that a path leads to data) This is an important item, you shouldn't have simplified it :). And I'm not sure if Joel also thinks so. > > Weiming is asking for: > path pathfilter data pathfilter data ... > > subpath is what is refered as a pathfilter above (content or block > refinement of the path). If we can reach agreement on the path-data-path-data ...mode, I think it's also a good progress,and also complies with my thougt partially. I just thought that Joel might be insisting on the format as Op-path-data,Op-path-data,.... My further thought is, in the path-data-path-data mode, actually the paths have lots field in duplicating. For instance, the same Attribute ID will always be there in all paths. As a result, one of the reason for my suggest for a Mainpath and Subpath is for the efficiency. > > When you look at what you end up dumping in say a table that has colums > pointing to another table; then you can see that we would end up doing > what Weiming is asking for. I'm not very sure what you mean here. I just thought the two are the same in basic functions, with the latter giving more bits saved. > The examples i presented around November infact showed this. > > The problem with Weiming's approach is the overhead in the case of large > quantities of data (either dumping from FE or setting to the FE). You > end up with a lot of nested TLVs. And thats not efficient packing of > data (consider 100K L3 table with each entry chewing an extra 8 bytes of > overhead and requiring two extra TLV levels) I'm afraid the things are reversed a little :), or you are talking about other thing than the subpath. I guess you are talking about how data are encoded, i.e, to use a packed data (D1-D2-D3-...), or to use a format with ID1-D1-ID2-D2-ID3-D3-.... Yes, I suggested this before, but I think it is another issue from the subpath we are discussing. One remark for the latter data format is, the ID there does not need to use TLV to present, a pure ID is enough, I think. Cheers, Weiming > > Compromise: I think we should allow the path-data-path-data interleaving > but also allow a "cooked" mode bulk/batched operation for efficiency > purposes > > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 09:57:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23436 for ; Mon, 10 Jan 2005 09:57:03 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1Bx-0003sT-CO for forces-archive@IETF.ORG; Mon, 10 Jan 2005 10:11:09 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F3F53C@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 9:56:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52786719 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 09:56:36 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 09:49:39 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8601099; Mon, 10 Jan 2005 09:49:42 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050110094710.06565008@localhost> Date: Mon, 10 Jan 2005 09:49:33 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105330894.1040.50.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 I look at it the opposite way. Thinking about the CE software design, the only time I would build a CE that used content addressing is when I know that the FE will support it. There will always be a mandatory to support indexing method for every array. (Otherwise, interoperability is gone.) As such, optional, may work if you try it, methods are simply a waste of effort. Personally, the longer this discussion goes on, the more I am inclined to conclude that the whole idea of content addressing is a bad idea. It complicates the FE, complicates the CE, and complicates the protocol. Yours, Joel M. Halpern At 11:21 PM 1/9/2005, Jamal Hadi Salim wrote: >The predeclared keys are a good hint to the CE, but without capabilities >(which i also have strong distate for in this case) the backup is to for >the FE to reject a requested content operation. In other words, I do >think that it is practical to say have a ASIC vendor implementing the >some LFB not supporting any content searches. >So given that, the only value to predeclaring is giving a good hint to >the CE. I think its still a good thing to have and we should add it. From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 10:29:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26097 for ; Mon, 10 Jan 2005 10:29:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1i8-00058I-Lq for forces-archive@IETF.ORG; Mon, 10 Jan 2005 10:44:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F3F4DF@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:29:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52788668 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:29:57 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:24:38 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011007240530:21036 ; Mon, 10 Jan 2005 07:24:05 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 07:24:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 07:24:06 AM, Serialize complete at 01/10/2005 07:24:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105370675.1084.16.camel@jzny.localdomain> Date: Mon, 10 Jan 2005 10:24:36 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit On Mon, 2005-01-10 at 09:43, Wang,Weiming wrote: > Hi Jamal, Joel as well, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: [issue6] Summary of Path > > > > Heres where i think the two biggest discrepancies so far are and that > > need to be resolved: > > > > 1) interleaving of path-data-path-data .. > > So far Joel and myself have been saying you have > > path [pathfilter] [data] > > This is for simplicty reasons (and that a path leads to data) > This is an important item, you shouldn't have simplified it :). And I'm not sure > if Joel also thinks so. Sorry, I was assuming path-data-path-data is preceeded by op. To be precise op-mainpath-subpath-data-subpath-data-subpath... > > > > Weiming is asking for: > > path pathfilter data pathfilter data ... > > > > subpath is what is refered as a pathfilter above (content or block > > refinement of the path). > If we can reach agreement on the path-data-path-data ...mode, I think it's also > a good progress,and also complies with my thougt partially. I just thought that > Joel might be insisting on the format as Op-path-data,Op-path-data,.... Joels view(matching mine) is op-mainpath-subpath-data. > My further thought is, in the path-data-path-data mode, actually the paths have > lots field in duplicating. For instance, the same Attribute ID will always be > there in all paths. As a result, one of the reason for my suggest for a Mainpath > and Subpath is for the efficiency. > its op-mainpath-subpath-data-subpath-data-subpath. I think i should put together the text so we can be sure we are talking about the same thing. > > > > When you look at what you end up dumping in say a table that has colums > > pointing to another table; then you can see that we would end up doing > > what Weiming is asking for. > I'm not very sure what you mean here. I just thought the two are the same in > basic functions, with the latter giving more bits saved. > It could be a misunderstanding of your scheme. Let me put together some text and see if we are saying the same thing. > > The examples i presented around November infact showed this. > > > > The problem with Weiming's approach is the overhead in the case of large > > quantities of data (either dumping from FE or setting to the FE). You > > end up with a lot of nested TLVs. And thats not efficient packing of > > data (consider 100K L3 table with each entry chewing an extra 8 bytes of > > overhead and requiring two extra TLV levels) > I'm afraid the things are reversed a little :), or you are talking about other > thing than the subpath. If you dump table1 in the example i posted you could end up having data that looks like: table1subscriptx,t1value, t2value, j1value,j2value This is needed for efficiency reasons. Note t2value is infact index/subscript for table2 but residing in table1. > I guess you are talking about how data are encoded, i.e, > to use a packed data (D1-D2-D3-...), or to use a format with > ID1-D1-ID2-D2-ID3-D3-.... Yes, I suggested this before, but I think it is > another issue from the subpath we are discussing. One remark for the latter data > format is, the ID there does not need to use TLV to present, a pure ID is > enough, I think. I think that the dumped data should not look any different from data that is sent to the FE to set for example - this is the puritism approach. In such a case you would need to have separation of Data and path into different TLVs - which is where conflict comes in i.e cleanliness and efficiency conflict. Heres a basic first attempt at BNF that would satisfy what you are asking for: OPER_TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO:= [SUBPATH] [DATARAW] SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> DATARAW := somedata [DATAINFO] cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 10:38:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26817 for ; Mon, 10 Jan 2005 10:38:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1q7-0005Sg-2c for forces-archive@IETF.ORG; Mon, 10 Jan 2005 10:52:20 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F3F59D@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:38:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52789217 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:38:12 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:33:03 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011007323031:21048 ; Mon, 10 Jan 2005 07:32:30 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <6.1.2.0.0.20050110094710.06565008@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 07:32:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 07:32:31 AM, Serialize complete at 01/10/2005 07:32:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105371180.1091.26.camel@jzny.localdomain> Date: Mon, 10 Jan 2005 10:33:01 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050110094710.06565008@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Mon, 2005-01-10 at 09:49, Joel M. Halpern wrote: > I look at it the opposite way. > Thinking about the CE software design, the only time I would build a CE > that used content addressing is when I know that the FE will support it. > There will always be a mandatory to support indexing method for every > array. (Otherwise, interoperability is gone.) Indexing doesnt require any forwarding path support - content searches on an FE only make sense (IMO) when the forwarding path supports it. > As such, optional, may work if you try it, methods are simply a waste of > effort. So lets pick the L3 LFB. It is possible CAM implementations of such an LFB will allow search by prefix while others wont. When creating an L3 LFB however it makes sense to define the prefix as a search key. > Personally, the longer this discussion goes on, the more I am inclined to > conclude that the whole idea of content addressing is a bad idea. It > complicates the FE, complicates the CE, and complicates the protocol. I agree - however, consensus seems to be leaning towards allowing content keys at least. Minimal requirements met towards that goal is fine. cheers, jamla From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 10:47:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27332 for ; Mon, 10 Jan 2005 10:47:37 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co1z1-0005s8-Ab for forces-archive@IETF.ORG; Mon, 10 Jan 2005 11:01:45 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F3F5D3@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:47:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52789853 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:47:21 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:39:39 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8601568; Mon, 10 Jan 2005 10:39:39 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050110103740.06529c00@localhost> Date: Mon, 10 Jan 2005 10:39:30 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105370675.1084.16.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Yes, if we are going to have content addressing, something like what Jamal provided is what I was envisioning as well. There are obviously many details to be filled in, but they depend in large part on some of the other issues we are discussing. Yours, Joel M. Halpern At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: >Heres a basic first attempt at BNF that would satisfy what you are >asking for: > >OPER_TLV : = >PATH-DATA := [DATAINFO] >PATH := flags IDcount >DATAINFO:= [SUBPATH] [DATARAW] >SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> >DATARAW := somedata [DATAINFO] From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 10:53:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27640 for ; Mon, 10 Jan 2005 10:53:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co25H-00067g-EG for forces-archive@IETF.ORG; Mon, 10 Jan 2005 11:08:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F3F6D7@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:53:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52790276 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:53:38 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:49:38 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8601732 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:49:26 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <6.1.2.0.0.20050110094710.06565008@localhost> <1105371180.1091.26.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050110104730.06514b28@localhost> Date: Mon, 10 Jan 2005 10:49:17 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105371180.1091.26.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Using the L3 Next-Hop-Selection LFB as a case to consider, I see two reasonable choices. Either we simply use indexing all the time, and do not make use of the ability for some implementations to easily address information by the IP address & prefix-length, or else we mandate that all implementations support such addressing, even those that do not have hardware support. Yours, Joel At 10:33 AM 1/10/2005, Jamal Hadi Salim wrote: >On Mon, 2005-01-10 at 09:49, Joel M. Halpern wrote: > > I look at it the opposite way. > > Thinking about the CE software design, the only time I would build a CE > > that used content addressing is when I know that the FE will support it. > > There will always be a mandatory to support indexing method for every > > array. (Otherwise, interoperability is gone.) > >Indexing doesnt require any forwarding path support - content searches >on an FE only make sense (IMO) when the forwarding path supports it. > > > As such, optional, may work if you try it, methods are simply a waste of > > effort. > >So lets pick the L3 LFB. It is possible CAM implementations of such an >LFB will allow search by prefix while others wont. When creating an L3 >LFB however it makes sense to define the prefix as a search key. > > > Personally, the longer this discussion goes on, the more I am inclined to > > conclude that the whole idea of content addressing is a bad idea. It > > complicates the FE, complicates the CE, and complicates the protocol. > >I agree - however, consensus seems to be leaning towards allowing >content keys at least. Minimal requirements met towards that goal is >fine. > >cheers, >jamla From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 10:59:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28122 for ; Mon, 10 Jan 2005 10:59:54 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2B6-0006Oe-C2 for forces-archive@IETF.ORG; Mon, 10 Jan 2005 11:14:02 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F3F5BF@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 10:59:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52790682 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 10:59:50 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 10:58:43 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0AFwgbP216394 for ; Mon, 10 Jan 2005 15:58:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0AFxZFq166698 for ; Mon, 10 Jan 2005 16:59:35 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0AFwfwZ008789 for ; Mon, 10 Jan 2005 16:58:41 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0AFwfIx008771 for ; Mon, 10 Jan 2005 16:58:41 +0100 Received: from [9.4.69.100] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA57248 for ; Mon, 10 Jan 2005 16:58:40 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E03D07E23@orsmsx408> <1105331108.1040.55.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E2A62E.6000907@zurich.ibm.com> Date: Mon, 10 Jan 2005 16:58:38 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105331108.1040.55.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Issue 1 included a discussion of the meaning of the ADVERTISE (or SHOW) operation used for instance in the Association Setup messages. Here are a few short clarifications: The idea for this ADVERTISE (or SHOW) operation is for the FE to pass the value of an attribute to the CE in the path-data form. This is different from an event fired by the FE (for which I think the REPORT operation should be kept, btw), and different from a GET RESPONSE (as the value is transmitted without the CE asking explicitely for it; Jamal had proposed this at some point). In this context, the issue (raised on the list by Hormuzd) of advertising not only one atribute, but the whole LFB at once (for instance a core LFB) would require the definition of an "LFB attributes serialization" method, which is missing at this point. And best wishes to all ! -Robert Jamal Hadi Salim wrote: >On Thu, 2005-01-06 at 14:31, Khosravi, Hormuzd M wrote: > > >>Happy New Year to All! >> >>Jamal, seems like we have resolved this issue (1) with the exception of >>the details of Reason in Teardown msg. I think we can probably work on >>that in a conference call with the rest of the team since no one seems >>to be responding on the list. >> >> > >Sounds reasonable. >In any case, if we ever have a conference call i think it should >be to shoot for resolving the path-data issue which in my opinion >is the show stopper. All these other issues outstanding at the moment >are pretty much resolvable each in less than 10 minutes. > >cheers, >jamal > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 11:07:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28732 for ; Mon, 10 Jan 2005 11:07:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2Iv-0006fs-8H for forces-archive@IETF.ORG; Mon, 10 Jan 2005 11:22:07 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F3F5E5@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 11:07:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52791315 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 11:07:54 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 11:07:01 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011008062844:21089 ; Mon, 10 Jan 2005 08:06:28 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <6.1.2.0.0.20050110094710.06565008@localhost> <1105371180.1091.26.camel@jzny.localdomain> <6.1.2.0.0.20050110104730.06514b28@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 08:06:28 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/10/2005 08:06:29 AM, Serialize complete at 01/10/2005 08:06:29 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105373219.1084.39.camel@jzny.localdomain> Date: Mon, 10 Jan 2005 11:06:59 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050110104730.06514b28@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit At the expense of getting shot: I think Indexing should be mandatory and content keying optional. It is clear that the CE can convert from content to indexing if armed with all the info on how tables are populated in the FE. My only concern is some of the FEs that may only understand content keying and run on some dumb FE (Steve had some convincing arguement in this direction a while back). cheers, jamal On Mon, 2005-01-10 at 10:49, Joel M. Halpern wrote: > Using the L3 Next-Hop-Selection LFB as a case to consider, I see two > reasonable choices. Either we simply use indexing all the time, and do not > make use of the ability for some implementations to easily address > information by the IP address & prefix-length, or else we mandate that all > implementations support such addressing, even those that do not have > hardware support. > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 11:51:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04571 for ; Mon, 10 Jan 2005 11:51:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2z1-0000I2-SP for forces-archive@IETF.ORG; Mon, 10 Jan 2005 12:05:36 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F3F56F@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 11:51:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52794569 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 11:51:26 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 11:46:34 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0AGkWvN008600 for ; Mon, 10 Jan 2005 16:46:32 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0AGk84S004465 for ; Mon, 10 Jan 2005 16:46:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011008462704048 for ; Mon, 10 Jan 2005 08:46:27 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 08:46:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: ForCES Protocol Issue #1 closure Thread-Index: AcTzRkcoLRHHX7KcRZGR/RekLn5LRgACy5XAAACIeAAAALKfIADNH89Q X-OriginalArrivalTime: 10 Jan 2005 16:46:05.0867 (UTC) FILETIME=[E0B68FB0:01C4F733] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Mon, 10 Jan 2005 08:46:05 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Protocol Issue #1 closure To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable All, =20 Given the latest exchange of emails, I would like to see if we can mark issue #1 as closed. Is the following=20 text acceptable as the summary on the issue? If there is any objection, please post before Tuesday evening, otherwise this issue will be marked as closed: [ In Section 6.2, the Association Setup, Association Setup=20 Response messages, will use the same grammar as the other=20 messages. They will contain both the FE Object and FE=20 Protocol Object with Operation as Advertise/Show. The FE=20 Object LFBs would be used to advertise any existing FE=20 attributes to the CE and vice versa in these messages. Open - Details of how Reason will be carried in the Teardown message. ] Regards, David From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 14:19:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14495 for ; Mon, 10 Jan 2005 14:19:36 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co5IL-0004yK-VS for forces-archive@IETF.ORG; Mon, 10 Jan 2005 14:33:45 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F3F8ED@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 14:19:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52806524 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 14:19:29 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 14:18:48 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0AJIlfX016660 for ; Mon, 10 Jan 2005 19:18:47 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0AJGtjd023094 for ; Mon, 10 Jan 2005 19:18:47 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011011184604093 for ; Mon, 10 Jan 2005 11:18:46 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 11:18:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [issue2] ForCES Protocol Issue #2 proposed closure Thread-Index: AcT3STSnvt6EMd1GTMy/WztSZxq9lA== X-OriginalArrivalTime: 10 Jan 2005 19:18:46.0903 (UTC) FILETIME=[351DB870:01C4F749] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Mon, 10 Jan 2005 11:18:46 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: [issue2] ForCES Protocol Issue #2 proposed closure To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable All, Based on discussions on the list it appears that issue #2 is reaching closure. I asked Hormuzd to provide me=20 proposed summary text on this issue which I have included=20 below: [ Issue 2 - Editorial Changes - In section 6.3.1, "Config data" should be "Config data and path" PACKET SUBSCRIBE/UNSUBSCRIBE operations to be removed Instead of Type in figure, say Operations =3D xxx In section 6.3.2, "single or Array LFB specific result entries"=20 should be "data - presentation TBD" ] Please examine this summary and let me know if it is acceptable or not by Wednesday evening. -David From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 10 23:39:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03328 for ; Mon, 10 Jan 2005 23:39:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoE1v-0003Jr-5G for forces-archive@IETF.ORG; Mon, 10 Jan 2005 23:53:24 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F4056E@cherry.ease.lsoft.com>; Mon, 10 Jan 2005 23:39:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52851288 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 23:38:57 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 23:34:43 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Tue, 11 Jan 2005 12:59:28 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Tue, 11 Jan 2005 12:34:26 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> Date: Tue, 11 Jan 2005 12:30:46 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This has mostly complied with what I thought. I'm glad we reach this point. To use key or not is another issue. The only different point I thought is the feasibility to put all field IDs in the mainpath for all possible cases, with subpath only deals with indexes. Content searching is one case that needs to have fieldIDs in the subpath. Joel tries to use key to avoid such case, but I think a key is still a kind of fieldID. I can think of other cases where fieldIDs in subpaths are needed. The following is one: Thinking we have an LFB with following attribute: Foo3, type structure, ID=5 { s1, type u32, ID=1 s2, type structure, ID=2 { g1, type u32, ID=1 g2, type u32, ID=2 g3, tyep u32, ID=3 } } also thinking we have already set the values for this attribute. Now, we need to modify some value in it, say to modify the s1, g1, and g2. Note that I don't want to modify the s2 and the g3(if I want to modify all the values, that becomes another case, where I only need to use a simple path-data to represent it). With mainpath and subpath, I think the format should be like: Mainpath(Foo3) subpath( s1) value subpath(s2.g1) value subpath(s2.g2) value I actually talked about this before with Joel. I think Joel asked that in this case, he would rather use three separate path-data to do so, that is, path(Foo3.s1) value path(Foo3.s2.g1) value path(Foo3.s2.g2) value If the above path-values are in one OpTLV, I can more or less live with it, but still think the mainpath and subpath mode is better than this. I supposed Joel asked the path-values be in different OpTLVs, which I'm hard to accept. I think such operation is originally atomic, to separate them into different OpTLVs is not reasonable enough. Want to hear what others think about it. cheers, weiming ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Monday, January 10, 2005 11:39 PM Subject: Re: [issue6] Summary of Path > Yes, if we are going to have content addressing, something like what Jamal > provided is what I was envisioning as well. > There are obviously many details to be filled in, but they depend in large > part on some of the other issues we are discussing. > > Yours, > Joel M. Halpern > > At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: > >Heres a basic first attempt at BNF that would satisfy what you are > >asking for: > > > >OPER_TLV : = > >PATH-DATA := [DATAINFO] > >PATH := flags IDcount > >DATAINFO:= [SUBPATH] [DATARAW] > >SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> > >DATARAW := somedata [DATAINFO] > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 00:07:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04620 for ; Tue, 11 Jan 2005 00:07:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoETO-0003uf-De for forces-archive@IETF.ORG; Tue, 11 Jan 2005 00:21:53 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F4060E@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 0:07:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52853785 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 00:07:27 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 10 Jan 2005 23:58:37 -0500 Received: from [68.232.103.214] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8612209 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 10 Jan 2005 23:58:36 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050110235753.06350ec0@localhost> Date: Mon, 10 Jan 2005 23:58:21 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 There is some argument based on protocol efficiency for combining them. I can live with that. However, for clarity I wish to note that atomicity is not a reason for combining them. The atomicity issue should be dealt with explicitly (as the protocol team as already indicated they will do). It should not be a side-effect of grouping things into TLVs. Yours, Joel M. Halpern At 11:30 PM 1/10/2005, Wang,Weiming wrote: >I actually talked about this before with Joel. I think Joel asked that in this >case, he would rather use three separate path-data to do so, that is, > >path(Foo3.s1) value >path(Foo3.s2.g1) value >path(Foo3.s2.g2) value > >If the above path-values are in one OpTLV, I can more or less live with >it, but >still think the mainpath and subpath mode is better than this. I supposed Joel >asked the path-values be in different OpTLVs, which I'm hard to accept. I >think >such operation is originally atomic, to separate them into different OpTLVs is >not reasonable enough. > >Want to hear what others think about it. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 05:51:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11351 for ; Tue, 11 Jan 2005 05:51:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoJqc-0001s2-N8 for forces-archive@IETF.ORG; Tue, 11 Jan 2005 06:06:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F40A3A@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 5:51:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52875624 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 05:51:42 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 05:48:08 -0500 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0BAm7vU210768 for ; Tue, 11 Jan 2005 10:48:07 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0BAmxSr099098 for ; Tue, 11 Jan 2005 11:48:59 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0BAm7Zv006048 for ; Tue, 11 Jan 2005 11:48:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0BAm6Vl006042 for ; Tue, 11 Jan 2005 11:48:07 +0100 Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA57096 for ; Tue, 11 Jan 2005 11:48:06 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> Content-Type: multipart/alternative; boundary="------------000607080506080800040603" Message-ID: <41E3AEE1.5030100@zurich.ibm.com> Date: Tue, 11 Jan 2005 11:48:01 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. --------------000607080506080800040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On the Heartbeat exception: First we all agree that, at least from a logical point of view, the HB originates from the FE Protocol LFB to confirm ForCES-protocol-processing availability. The question is in what format should this message be sent from the FE to the CE. I try to list them all here: 1) give HB its own PL-message header type, the PL-message body is empty. 2) give HB the format of an event: LFB-Selector selects the FE Protocol LFB, command is EVENT-REPORT and path-data identifies the heartbeat event attribute in the FE Protocol LFB. Data is empty. 3) give HB its own command type, and hence no path-data needs to be transmitted, just an LFB-selector selecting the FE Protocol LFB and a special HB Command. Most importantly, one may want to extend the use of HB to other LFBs, i.e., beyond only verifying ForCES-protocol-processing availability. For instance, a HB coming from the FE LFB to indicate liveliness of the overall FE. For that purpose only formats 2) and 3) are suitable. _If we think it is worth extending the use of HB beyond verifying __ForCES-protocol-processing availability_, then we can reconsider its format, for the sake of remaining consistent. Regards, -Robert Khosravi, Hormuzd M wrote: >-----Original Message----- >From: Jamal Hadi Salim > > >>You definitely have a different opinion on this from what we have in >> >> >the > > >>draft >> >> > >Why would we be discussing it otherwise??? >my recollection is _you_ put it in the draft with intent we will revisit >and disscuss. >I sent the attached document back in October to accelerate the changes >to the original draft. Look at section 6.7 - I gave you a clear >opportunity to discuss this and didnt impose. Now its in the draft, is >the implication that it no longer holds?? Sounds almost like a lawyer >sneaking in fine print. > >[HK] Jamal, lets not get personal here. This issue has been discussed by >the protocol team in context with the attached document that you sent >out in October. The emails that I forwarded previously (also exchanged >in October) were pertaining to that discussion. Based on that email >discussion, I was under the impression that this issue is resolved >> go >with the old approach for HB msg that we had in the draft. Anyways, you >are free to revisit issues...hopefully we will eventually reach some >resolution :) > >There hasn't been much response yet, expect from Joel. > >Regards >Hormuzd > > > > --------------000607080506080800040603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On the Heartbeat exception:

First we all agree that, at least from a logical point of view, the HB originates from the FE Protocol LFB to confirm ForCES-protocol-processing availability. The question is in what format should this message be sent from the FE to the CE. I try to list them all here:

1) give HB its own PL-message header type, the PL-message body is empty.

2) give HB the format of an event: LFB-Selector selects the FE Protocol LFB, command is EVENT-REPORT and path-data identifies the heartbeat event attribute in the FE Protocol LFB. Data is empty.

3) give HB its own command type, and hence no path-data needs to be transmitted, just an LFB-selector selecting the FE Protocol LFB and a special HB Command.

Most importantly, one may want to extend the use of HB to other LFBs, i.e., beyond only verifying ForCES-protocol-processing availability. For instance, a HB coming from the FE LFB to indicate liveliness of the overall FE. For that purpose only formats 2) and 3) are suitable.

If we think it is worth extending the use of HB beyond verifying ForCES-protocol-processing availability, then we can reconsider its format, for the sake of remaining consistent.


Regards,
-Robert






Khosravi, Hormuzd M wrote: 
-----Original Message-----
From: Jamal Hadi Salim
  
You definitely have a different opinion on this from what we have in
    
the
  
draft
    

Why would we be discussing it otherwise???
my recollection is _you_ put it in the draft with intent we will revisit
and disscuss.
I sent the attached document back in October to accelerate the changes
to the original draft. Look at section 6.7 - I gave you a clear
opportunity to discuss this and didnt impose. Now its in the draft, is
the implication that it no longer holds?? Sounds almost like a lawyer
sneaking in fine print.

[HK] Jamal, lets not get personal here. This issue has been discussed by
the protocol team in context with the attached document that you sent
out in October. The emails that I forwarded previously (also exchanged
in October) were pertaining to that discussion. Based on that email
discussion, I was under the impression that this issue is resolved >> go
with the old approach for HB msg that we had in the draft. Anyways, you
are free to revisit issues...hopefully we will eventually reach some
resolution :)

There hasn't been much response yet, expect from Joel.

Regards
Hormuzd
--------------000607080506080800040603-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 09:05:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24903 for ; Tue, 11 Jan 2005 09:05:45 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMsL-00064X-4k for forces-archive@IETF.ORG; Tue, 11 Jan 2005 09:20:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F40FBC@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 9:05:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52925733 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 09:05:41 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 08:12:19 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011105113917:22963 ; Tue, 11 Jan 2005 05:11:39 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050110235753.06350ec0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 05:11:40 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 05:11:46 AM, Serialize complete at 01/11/2005 05:11:46 AM Content-Type: multipart/mixed; boundary="=-c4mt0GpcbeKSBrf4uMLT" Message-ID: <1105449130.1089.58.camel@jzny.localdomain> Date: Tue, 11 Jan 2005 08:12:10 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050110235753.06350ec0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 --=-c4mt0GpcbeKSBrf4uMLT Content-Type: text/plain Content-Transfer-Encoding: 7bit It should be noted that the grammar of attached document will have to be modified to: OPER_TLV : = + instead of: OPER_TLV : = to meet what Weiming is looking for. Weiming if you can think of a way to change that grammar to met that desire, please do so. Try to avoid large impact on the BNF if you can (otherwise i have to change all the use cases ;->) The atomicity indicators at the moment reside on the main header flags. Ok, folks - dont wanna sound like a lawyer, but here it is in scribe, sign on, modify etc. cheers, jamal On Mon, 2005-01-10 at 23:58, Joel M. Halpern wrote: > There is some argument based on protocol efficiency for combining them. I > can live with that. > > However, for clarity I wish to note that atomicity is not a reason for > combining them. The atomicity issue should be dealt with explicitly (as > the protocol team as already indicated they will do). It should not be a > side-effect of grouping things into TLVs. > > Yours, > Joel M. Halpern > > At 11:30 PM 1/10/2005, Wang,Weiming wrote: > >I actually talked about this before with Joel. I think Joel asked that in this > >case, he would rather use three separate path-data to do so, that is, > > > >path(Foo3.s1) value > >path(Foo3.s2.g1) value > >path(Foo3.s2.g2) value > > > >If the above path-values are in one OpTLV, I can more or less live with > >it, but > >still think the mainpath and subpath mode is better than this. I supposed Joel > >asked the path-values be in different OpTLVs, which I'm hard to accept. I > >think > >such operation is originally atomic, to separate them into different OpTLVs is > >not reasonable enough. > > > >Want to hear what others think about it. --=-c4mt0GpcbeKSBrf4uMLT Content-Disposition: attachment; filename=data_path2.txt Content-Type: text/plain; name=data_path2.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Standard Disclaimer: -------------------- This doc by no means imposes a decision. It serves as a discussion place holder with the a desire to speed up the path-data discussion up. NOTE: ----- 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA which is the subject of this discussion. Opcodes discussed so far: * SET (create, modify, append etc depending on PATH-DATA flags} * DEL (remove existing config objects specified by PATH-DATA } * GET (Access existing config objects specified in PATH-DATA } [Add any events here] A possible path-data layout. ---------------------------- OPER_TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO:= [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> DATARAW := somedata [DATAINFO] INDINFO := index | fieldID KEYINFO := KEYID KEY_DATA BLKINFO := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined at LFB definition) or dynamically created (table indices). -> flags are used to further refine the operation to be applied on the ID_TLV. -> SELECTOR := optional different BLK, KEY or Index/fieldID to extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH and applied operations. -> DATARAW contains the data whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data subpath data subpath data ..." flags ----- Derived from Netlink and BSD route sockets: --> F_EXCL Donot replace the config attribute(s) if already exists - Report back error instead. --> F_REPLACE Replace existing matching config attribute(s) with passed data. If config object doesnt exist, return an error. --> F_CREATE Create config object if it does not already exist. If config object already exists, return an error. --> F_APPEND: Add to the end of the object list/table. This could create xplicates (dup/triplicates etc) Essentially: - To ADD a new config object: F_CREATE | F_EXCL - To change an existing object: F_REPLACE - To test if object exists: F_EXCL Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. We may need to rediscuss that if need be. BLK path selection ------------------ For block operations three modes exist [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. 1) BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start // "a" end // "b" 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" count //"N" 3) BLK_LIST_INDEX TLV T= BLK_LIST_INDEX, length = 4+(4*(count of indices)) index0 // "a" index1 //"c" index2 //"e" ...... ...... indexN-1 //"?" Content path selection --------------------- We introduce a KEY_INFO TLV which will describe the KEY as well as associated KEY data (example Keyid = 3 for "foo1" and Key_data = 5"). KEYINFO TLV := KEYID KEY_DATA Where KEYID is a 32 bit entity that contains the index or field ID and data contains the data being referenced. The L of the TLV adjusts given the size of the KEY_DATA. The only equality allowed is the "=" sign which means any search will be for "KEYID=KEY_DATA" example "foo1=10" (where foo1's ID is actually placed in the KEYID field instead of the name "foo1". NOTE! NOTE! There is still some open discussion here: A) Joels view: i) Allow only for one or two keys per table instance for simplicty reasons. Example, allow only j1 to be the key for table2. Enforce this via LFB definition. ii) A key value is unique per table instance. In other words, if one was to scan table 2 they would only see one occurance of a table row which has value "j1=10" B) Weiming: i) there are no unique keys. ii) there can be multiple row instances of "j1=10" It should be noted that it is possible to achieve what Weiming wants using the F_APPEND flag when creating a table row entry. Infact there are some LFBs which may allow for this (I know some ASICs with classifiers that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. RAWDATA: ------- The RAWDATA TLV will contain the raw data and may optionaly contain a DATAINFO TLV. USE CASES --------- Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 5 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 1) To get foo1 Path: IDCount = 1, IDs = 1 Result: Path = IDCount = 1, IDs = 1, RAWDATA TLV with value of foo1 2) to set foo2 to 10 Path: IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 3) To dump table2 (get) Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = numentries2-1 RAWDATA TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations To set entry 0-2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = 2 RAWDATA TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To set entry 0,2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_LIST_RANGE TLV 0,2 RAWDATA TLV, Length = XXX, V = two j1value,j2value entries 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 the above shows that mainpath can constitute indices. Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 RAWDATA TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 TBD: What to do when say entry 1 doesnt exist? Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 RAWDATA TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 8) Using BLK_CNT_INDEX for #7 Path = IDCount = 1, IDs=4 followed by BLK_CNT_INDEX TLV to extend path T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 RAWDATA TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value j1value,j2value 9) Using BLK_LIST_INDEX TLV for #7 Path = IDCount = 1, IDs=4 followed by BLK_LIST_INDEX TLV T = BLK_CNT_INDEX, L = XXX Values: 0,1,2 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 RAWDATA TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 10) Dump contents of table1, Path = IDCount = 1, IDs=3 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=3 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... RAWDATA TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . . (note t2 is subscript for table2 and infact we are resolving table2 contents above) TBD: Do we just resolve the contents pointed to by t2value as shown above or do we have a flag to select between two modes? Clearly a good way to do this is not to resolve any paths(i.e dumping of table1 should obly have t1value and t2value); rather the CE should OPerate on both tables in one atomic invocation. 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 Subpath := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1KEY_DATA=100} In other the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" Result: Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 RAWDATA TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path = IDCount = 1, IDs=4 Subpath := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} Result: This assumes we have asked for the full results back (instead of just simple pass/fail. We need a flag - refer to other discussion) Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 RAWDATA TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TODO: ---- - more refinement of flags for atomicity etc - column and cell access in a table use cases - Provide a more complex use case example (where a table cell points to a whole table) $Log: data_path2.txt,v $ Revision 1.1 2004/11/14 18:47:07 hadi Initial revision --=-c4mt0GpcbeKSBrf4uMLT-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 09:07:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24965 for ; Tue, 11 Jan 2005 09:07:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMtn-00066B-Pw for forces-archive@IETF.ORG; Tue, 11 Jan 2005 09:21:35 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F40EE5@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 9:07:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52925802 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 09:07:05 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 09:04:48 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j0BE4lbP122536 for ; Tue, 11 Jan 2005 14:04:47 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0BE5fmZ151890 for ; Tue, 11 Jan 2005 15:05:41 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0BE4lwj019125 for ; Tue, 11 Jan 2005 15:04:47 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j0BE4kse019102 for ; Tue, 11 Jan 2005 15:04:46 +0100 Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA56972 for ; Tue, 11 Jan 2005 15:04:46 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41E3DCFC.3060502@zurich.ibm.com> Date: Tue, 11 Jan 2005 15:04:44 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Weiming, all, Wang,Weiming wrote (excerpt): >Thinking we have an LFB with following attribute: > >Foo3, type structure, ID=5 >{ > s1, type u32, ID=1 > s2, type structure, ID=2 > { > g1, type u32, ID=1 > g2, type u32, ID=2 > g3, tyep u32, ID=3 > } > } > >With mainpath and subpath, I think the format should be like: >Mainpath(Foo3) subpath( s1) value subpath(s2.g1) value subpath(s2.g2) value > >I actually talked about this before with Joel. I think Joel asked that in this >case, he would rather use three separate path-data to do so, that is, > >path(Foo3.s1) value >path(Foo3.s2.g1) value >path(Foo3.s2.g2) value > >If the above path-values are in one OpTLV, I can more or less live with it, but >still think the mainpath and subpath mode is better than this. I supposed Joel >asked the path-values be in different OpTLVs, which I'm hard to accept. I think >such operation is originally atomic, to separate them into different OpTLVs is >not reasonable enough. > >Want to hear what others think about it. > > > I find the three separate path-data simpler and clearer. Such path-data can be aggregated under the same OpTLV, or they can be in separate OpTLVs. The protocol should support both cases. >>At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: >> >> >>>Heres a basic first attempt at BNF that would satisfy what you are >>>asking for: >>> >>>OPER_TLV : = >>>PATH-DATA := [DATAINFO] >>>PATH := flags IDcount >>>DATAINFO:= [SUBPATH] [DATARAW] >>>SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> >>>DATARAW := somedata [DATAINFO] >>> >>> > > > I'd like some description of KEYINFO. Or better, an example of how this actually looks like for a content-based search key in a simple array. I am worried the devil is again in the details. Regarding the need to support content-based search at all: Joel rightly expressed concern about too much sophistication. I also think most of the management operations should be handled at the CE, except in the case of obvious protocol-efficiency gains. For instance, the CE is able to convert a content-based access into one (or more) index-based access(es), as the CE is supposed to keep track of what the FE stores. But block operations should not be split into a sequence of operations by the CE, even though the CE is very well able to do it too. Index-based accesses are the lowest-common denominator, and content-based accesses are an option that each LFB may or may not support, with arbitrary or pre-specified keys (or even key combinations). Requiring SQL-engine-like capability in an FE would kill the spec, I think. Note that even though the FE must have a (hopefully efficient) implementation to retrieve/set an entry from/into its data structs based on (ForCES) index, it does not mean at all that the FE uses an indexed array for the data struct used for datapath lookup. Probably this was obvious to everyone here. Regards, -Robert From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 11:59:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09070 for ; Tue, 11 Jan 2005 11:59:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPb0-0001Vl-J4 for forces-archive@IETF.ORG; Tue, 11 Jan 2005 12:14:20 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F412FA@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 11:59:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52942104 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 11:59:57 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 11:59:36 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011108582361:23571 ; Tue, 11 Jan 2005 08:58:23 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050110235753.06350ec0@localhost> <1105449130.1089.58.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 08:58:24 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 08:59:03 AM, Serialize complete at 01/11/2005 08:59:03 AM Content-Type: multipart/mixed; boundary="=-JN9kyg2I+KPdvCMdC9WX" Message-ID: <1105462735.1079.210.camel@jzny.localdomain> Date: Tue, 11 Jan 2005 11:58:55 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: REPOST Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105449130.1089.58.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c52a6b2685a9a1f963a24bd74e30b072 --=-JN9kyg2I+KPdvCMdC9WX Content-Type: text/plain Content-Transfer-Encoding: 7bit After proof reading, heres an updated version. If you have invested time reading the original version then take a look at the diff also attached. cheers, jamal --=-JN9kyg2I+KPdvCMdC9WX Content-Disposition: attachment; filename=diff.dp2-0 Content-Type: text/plain; name=diff.dp2-0; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- data_path2.txt 2005/01/11 16:30:37 1.2 +++ data_path2.txt 2005/01/11 16:55:00 @@ -24,15 +24,15 @@ A possible path-data layout. ---------------------------- -OPER_TLV : = +OPER TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount -DATAINFO:= [SELECTOR] [DATARAW] +DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> DATARAW := somedata [DATAINFO] -INDINFO := index | fieldID -KEYINFO := KEYID KEY_DATA -BLKINFO := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] +INDINFO TLV := index | fieldID +KEYINFO TLV := KEYID KEY_DATA +BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined @@ -45,11 +45,24 @@ The path information in the SELECTOR indicates what information is being used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH -and applied operations. +and applied operations. As an example a GET or DEL may not have data. -> DATARAW contains the data whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data subpath data subpath data ..." +NOTE! NOTE! +----------- +The DATARAW "somedata" is LFB dependent. +It is assumed that the recepient by virtue of knowing the LFB +can decode the data. +In the simple LFB used in this doc, the fields in the two tables +are all of fixed size. It would need some TLV to explain variable +sized entries such as strings. +TBD: Should we leave this upto the LFB specific to worry about +the encoding/decoding. If yes, how does the LFB definition describe +this? If no, should we add this to the grammar? If yes, how? + + flags ----- @@ -88,7 +101,7 @@ here for the moment. 1) BLK_RANGE_INDEX TLV -T = BLK_INDEX_RANGE, length of 4+8 +T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" @@ -144,15 +157,20 @@ that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). +[Additional note: In the case the forwarding path actually does everything +with index based tables, then doing a check of "j1=1 AND j2=10" +is valid; however, j2 and j1 are not really "keys" if we use +proper terminology ;->] Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. -RAWDATA: -------- +DATAINFO: +--------- -The RAWDATA TLV will contain the raw data and may -optionaly contain a DATAINFO TLV. +The DATAINFO TLV will contain the RAWDATA which may +optionaly contain a DATAINFO TLV (to allow for recursive interleaving +of path-data). USE CASES --------- @@ -163,17 +181,16 @@ foo2, type u32, ID = 2 -table2: type array, ID = 4 - elements are: - j1, type u32, ID = 1 - j2, type u32, ID = 2 - j3, type u32, ID = 5 - table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 +table2: type array, ID = 4 + elements are: + j1, type u32, ID = 1 + j2, type u32, ID = 2 + 1) To get foo1 Path: IDCount = 1, IDs = 1 @@ -185,16 +202,22 @@ Path: IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 +Result: +Depends on whether we asked for a simple +success/ACK back or full details + 3) To dump table2 (get) +Assuming numentries defines the number of entries. + Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 - end = numentries2-1 -RAWDATA TLV: L = XXX, V= + end = numentries-1 +DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations @@ -202,21 +225,22 @@ now) Path = IDCount = 1, IDs=4 -BLK_INDEX_RANGE TLV +BLK_RANGE_INDEX TLV start = 0 end = 2 -RAWDATA TLV: L = XXX, V= +DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To set entry 0,2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 -BLK_LIST_RANGE TLV +BLK_LIST_INDEX TLV 0,2 -RAWDATA TLV, Length = XXX, V = +DATAINFO TLV, Length = XXX, V = two j1value,j2value entries + 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 @@ -226,7 +250,11 @@ Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 -RAWDATA TLV, V= j1value,j2value +DATAINFO TLV, V= j1value,j2value + +Another valid response is: +Path = IDCount = 2, IDs=4.0 +DATAINFO TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations @@ -243,7 +271,7 @@ T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 -RAWDATA TLV, Length = XXXX +DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value @@ -262,7 +290,7 @@ T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 -RAWDATA TLV, Length = 4+2*(4+8) +DATAINFO TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value @@ -280,7 +308,7 @@ Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 -RAWDATA TLV, Length = XXXX +DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value @@ -296,7 +324,7 @@ T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... -RAWDATA TLV, Length = XXXX +DATAINFO TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . @@ -321,7 +349,7 @@ Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 -RAWDATA TLV, Length = XXXX +DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value @@ -342,19 +370,24 @@ Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 -RAWDATA TLV, Length = XXXX +DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value +TBD: What to do when we request the next 10 entries but theres +only 5? What about when the highest index available is 5? +Need to enumerate all possible error paths + TODO: ----- - more refinement of flags for atomicity etc - column and cell access in a table use cases - Provide a more complex use case example (where a table cell points -to a whole table) +to a whole table). Essentially this is no different from the +variable sized string problem pointed to in the BNF (while describing +"somedata"). $Log: data_path2.txt,v $ Revision 1.2 2005/01/11 16:30:37 hadi --=-JN9kyg2I+KPdvCMdC9WX Content-Disposition: attachment; filename=data_path2.txt Content-Type: text/plain; name=data_path2.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Standard Disclaimer: -------------------- This doc by no means imposes a decision. It serves as a discussion place holder with the a desire to speed up the path-data discussion up. NOTE: ----- 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA which is the subject of this discussion. Opcodes discussed so far: * SET (create, modify, append etc depending on PATH-DATA flags} * DEL (remove existing config objects specified by PATH-DATA } * GET (Access existing config objects specified in PATH-DATA } [Add any events here] A possible path-data layout. ---------------------------- OPER TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> DATARAW := somedata [DATAINFO] INDINFO TLV := index | fieldID KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined at LFB definition) or dynamically created (table indices). -> flags are used to further refine the operation to be applied on the ID_TLV. -> SELECTOR := optional different BLK, KEY or Index/fieldID to extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH and applied operations. As an example a GET or DEL may not have data. -> DATARAW contains the data whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data subpath data subpath data ..." NOTE! NOTE! ----------- The DATARAW "somedata" is LFB dependent. It is assumed that the recepient by virtue of knowing the LFB can decode the data. In the simple LFB used in this doc, the fields in the two tables are all of fixed size. It would need some TLV to explain variable sized entries such as strings. TBD: Should we leave this upto the LFB specific to worry about the encoding/decoding. If yes, how does the LFB definition describe this? If no, should we add this to the grammar? If yes, how? flags ----- Derived from Netlink and BSD route sockets: --> F_EXCL Donot replace the config attribute(s) if already exists - Report back error instead. --> F_REPLACE Replace existing matching config attribute(s) with passed data. If config object doesnt exist, return an error. --> F_CREATE Create config object if it does not already exist. If config object already exists, return an error. --> F_APPEND: Add to the end of the object list/table. This could create xplicates (dup/triplicates etc) Essentially: - To ADD a new config object: F_CREATE | F_EXCL - To change an existing object: F_REPLACE - To test if object exists: F_EXCL Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. We may need to rediscuss that if need be. BLK path selection ------------------ For block operations three modes exist [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. 1) BLK_RANGE_INDEX TLV T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" count //"N" 3) BLK_LIST_INDEX TLV T= BLK_LIST_INDEX, length = 4+(4*(count of indices)) index0 // "a" index1 //"c" index2 //"e" ...... ...... indexN-1 //"?" Content path selection --------------------- We introduce a KEY_INFO TLV which will describe the KEY as well as associated KEY data (example Keyid = 3 for "foo1" and Key_data = 5"). KEYINFO TLV := KEYID KEY_DATA Where KEYID is a 32 bit entity that contains the index or field ID and data contains the data being referenced. The L of the TLV adjusts given the size of the KEY_DATA. The only equality allowed is the "=" sign which means any search will be for "KEYID=KEY_DATA" example "foo1=10" (where foo1's ID is actually placed in the KEYID field instead of the name "foo1". NOTE! NOTE! There is still some open discussion here: A) Joels view: i) Allow only for one or two keys per table instance for simplicty reasons. Example, allow only j1 to be the key for table2. Enforce this via LFB definition. ii) A key value is unique per table instance. In other words, if one was to scan table 2 they would only see one occurance of a table row which has value "j1=10" B) Weiming: i) there are no unique keys. ii) there can be multiple row instances of "j1=10" It should be noted that it is possible to achieve what Weiming wants using the F_APPEND flag when creating a table row entry. Infact there are some LFBs which may allow for this (I know some ASICs with classifiers that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). [Additional note: In the case the forwarding path actually does everything with index based tables, then doing a check of "j1=1 AND j2=10" is valid; however, j2 and j1 are not really "keys" if we use proper terminology ;->] Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. DATAINFO: --------- The DATAINFO TLV will contain the RAWDATA which may optionaly contain a DATAINFO TLV (to allow for recursive interleaving of path-data). USE CASES --------- Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 1) To get foo1 Path: IDCount = 1, IDs = 1 Result: Path = IDCount = 1, IDs = 1, RAWDATA TLV with value of foo1 2) to set foo2 to 10 Path: IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 Result: Depends on whether we asked for a simple success/ACK back or full details 3) To dump table2 (get) Assuming numentries defines the number of entries. Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = numentries-1 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations To set entry 0-2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 2 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To set entry 0,2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_LIST_INDEX TLV 0,2 DATAINFO TLV, Length = XXX, V = two j1value,j2value entries 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 the above shows that mainpath can constitute indices. Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value Another valid response is: Path = IDCount = 2, IDs=4.0 DATAINFO TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 TBD: What to do when say entry 1 doesnt exist? Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 8) Using BLK_CNT_INDEX for #7 Path = IDCount = 1, IDs=4 followed by BLK_CNT_INDEX TLV to extend path T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 DATAINFO TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value j1value,j2value 9) Using BLK_LIST_INDEX TLV for #7 Path = IDCount = 1, IDs=4 followed by BLK_LIST_INDEX TLV T = BLK_CNT_INDEX, L = XXX Values: 0,1,2 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 10) Dump contents of table1, Path = IDCount = 1, IDs=3 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=3 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . . (note t2 is subscript for table2 and infact we are resolving table2 contents above) TBD: Do we just resolve the contents pointed to by t2value as shown above or do we have a flag to select between two modes? Clearly a good way to do this is not to resolve any paths(i.e dumping of table1 should obly have t1value and t2value); rather the CE should OPerate on both tables in one atomic invocation. 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 Subpath := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} In other words the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" Result: Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path = IDCount = 1, IDs=4 Subpath := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} Result: This assumes we have asked for the full results back (instead of just simple pass/fail. We need a flag - refer to other discussion) Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TBD: What to do when we request the next 10 entries but theres only 5? What about when the highest index available is 5? Need to enumerate all possible error paths TODO: - more refinement of flags for atomicity etc - column and cell access in a table use cases - Provide a more complex use case example (where a table cell points to a whole table). Essentially this is no different from the variable sized string problem pointed to in the BNF (while describing "somedata"). $Log: data_path2.txt,v $ Revision 1.2 2005/01/11 16:30:37 hadi posted to the list proof reading and making small changes next Revision 1.1 2004/11/14 18:47:07 hadi Initial revision --=-JN9kyg2I+KPdvCMdC9WX-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 12:20:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10173 for ; Tue, 11 Jan 2005 12:20:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPuL-0001tA-3E for forces-archive@IETF.ORG; Tue, 11 Jan 2005 12:34:30 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F412D6@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 12:19:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52943634 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 12:19:51 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 12:12:21 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011109114728:23617 ; Tue, 11 Jan 2005 09:11:47 -0800 References: <468F3FDA28AA87429AD807992E22D07E03D07E23@orsmsx408> <1105331108.1040.55.camel@jzny.localdomain> <41E2A62E.6000907@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 09:11:47 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 09:11:48 AM, Serialize complete at 01/11/2005 09:11:48 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105463538.1079.240.camel@jzny.localdomain> Date: Tue, 11 Jan 2005 12:12:19 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <41E2A62E.6000907@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Robert, The booting up of an FE (issuing of an association) can be looked at as an _event_ in my opinion. It asynchronously notifies the CE of the event of an FE arriving at (and attempting to join) the NE. The source LFB is clearly the FE Object LFB. Thoughts? Having said that: It does seem to be overkill to have this one operation that does get used for the association; I think Joel presented a similar view as well? I am however indifferent if we end up keeping that operation. On the announcement of the two core LFBs in the association message, I didnt quiet catch the obstacle you are pointing to. We should be able to announce any parameters we have for the two core LFBs at association time and have the CE override some of them. I posted an example of where a cold restart where a FE needs to reassociate - where advertising the attributes it has for the two LFBs make a lot of sense. cheers, jamal On Mon, 2005-01-10 at 10:58, Robert Haas wrote: > Issue 1 included a discussion of the meaning of the ADVERTISE (or SHOW) > operation used for instance in the Association Setup messages. Here are > a few short clarifications: > > The idea for this ADVERTISE (or SHOW) operation is for the FE to pass > the value of an attribute to the CE in the path-data form. This is > different from an event fired by the FE (for which I think the REPORT > operation should be kept, btw), and different from a GET RESPONSE (as > the value is transmitted without the CE asking explicitely for it; Jamal > had proposed this at some point). > > In this context, the issue (raised on the list by Hormuzd) of > advertising not only one atribute, but the whole LFB at once (for > instance a core LFB) would require the definition of an "LFB attributes > serialization" method, which is missing at this point. > > And best wishes to all ! > -Robert > > Jamal Hadi Salim wrote: > > >On Thu, 2005-01-06 at 14:31, Khosravi, Hormuzd M wrote: > > > > > >>Happy New Year to All! > >> > >>Jamal, seems like we have resolved this issue (1) with the exception of > >>the details of Reason in Teardown msg. I think we can probably work on > >>that in a conference call with the rest of the team since no one seems > >>to be responding on the list. > >> > >> > > > >Sounds reasonable. > >In any case, if we ever have a conference call i think it should > >be to shoot for resolving the path-data issue which in my opinion > >is the show stopper. All these other issues outstanding at the moment > >are pretty much resolvable each in less than 10 minutes. > > > >cheers, > >jamal > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 12:28:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10664 for ; Tue, 11 Jan 2005 12:28:23 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoQ2U-00023E-KS for forces-archive@IETF.ORG; Tue, 11 Jan 2005 12:42:45 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F41164@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 12:28:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52944167 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 12:27:47 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 12:27:23 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011109264933:23649 ; Tue, 11 Jan 2005 09:26:49 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 09:26:49 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 09:26:50 AM, Serialize complete at 01/11/2005 09:26:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105464441.1076.258.camel@jzny.localdomain> Date: Tue, 11 Jan 2005 12:27:21 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <41E3AEE1.5030100@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Tue, 2005-01-11 at 05:48, Robert Haas wrote: > On the Heartbeat exception: > > First we all agree that, at least from a logical point of view, theHB > originates from the FE Protocol LFB to confirm > ForCES-protocol-processing availability. Nod. > The question is in what format should this message be sent from the > FE to the CE. I try to list them all here: > > 1) give HB its own PL-message header type, the PL-message body is > empty. > > 2) give HB the format of an event: LFB-Selector selects the FE > Protocol LFB, command is EVENT-REPORT and path-data identifies the > heartbeat event attribute in the FE Protocol LFB. Data is empty. > I think this is what i am leaning towards ... A heartbeat is a synchronous _event_. A CE needs to kick the FE::LFBofinterest to start emiting the events (I suppose after setting the proper parameters such as clock interval and dead interval). One could say a basic heartbeat will have a zero sized message. OTOH, an synchronous event such as the one emited by the topology LFB will have > zero sized data (if configured to periodically send updates to the CE). The source of this message is the LFB object if going from CE to FE. Thats what has been configured to emit these synchronous events. What i am having problems with so far is the restriction of this message to only the FE protocol LFB and then taking further shortcuts to say we dont even need to mention the FE protocol LFB in the addressing. >3) give HB its own command type, and hence no path-data needs to be > >transmitted, just an LFB-selector selecting the FE Protocol LFB and a >special HB Command. > > Most importantly, one may want to extend the use of HB to other LFBs, > i.e., beyond only verifying ForCES-protocol-processing availability. > For instance, a HB coming from the FE LFB to indicate liveliness of > the overall FE. For that purpose only formats 2) and 3) are suitable. > > If we think it is worth extending the use of HB beyond verifying > ForCES-protocol-processing availability, then we can reconsider its > format, for the sake of remaining consistent. > Thanks for pointing this Robert. I think its worth it to attach it to the LFB reference. I really see no harm whatsoever in adding the extra bits to reference the FE protocol LFB in the case of the FE heartbeat. The example of the synchronous topology LFB updates is one example. I cant lay my hands on whether an MPLS ping will fit in such a scenario as well. Regardless, I think restricting the addressing to _not_ include LFB reference is an issue that needs to be addressed. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 13:36:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15308 for ; Tue, 11 Jan 2005 13:36:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoR5m-0003YN-0D for forces-archive@IETF.ORG; Tue, 11 Jan 2005 13:50:31 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F41392@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 13:35:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52951293 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 13:35:44 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 13:20:00 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8620799 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 13:19:59 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050111131714.065fddf8@localhost> Date: Tue, 11 Jan 2005 13:19:44 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105464441.1076.258.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d If the heartbeat goes only from the FE to the CE, treating it as an Event makes sense to me. That seems to be consistent re-use of mechanisms that have general utility. The problem I see with that is the CE->FE direction. Except for this case, the FE logic has no reason to be able to receive event messages. One alternative is to redefine heartbeat slightly. Define it as simply that the CE and FE must hear from each other at the configured interval. The FE generates his side by generate heartbeat notifications if he has nothing else to say. The CE can deal with his side by sending null protocol messages (messages with no operations). Does that work for people? Thank you, Joel At 12:27 PM 1/11/2005, Jamal Hadi Salim wrote: > > 2) give HB the format of an event: LFB-Selector selects the FE > > Protocol LFB, command is EVENT-REPORT and path-data identifies the > > heartbeat event attribute in the FE Protocol LFB. Data is empty. > > > >I think this is what i am leaning towards ... >A heartbeat is a synchronous _event_. A CE needs to kick the >FE::LFBofinterest to start emiting the events (I suppose after >setting the proper parameters such as clock interval and dead interval). >One could say a basic heartbeat will have a zero sized message. >OTOH, an synchronous event such as the one emited by the topology LFB >will have > zero sized data (if configured to periodically send updates >to the CE). > >The source of this message is the LFB object if going from CE to FE. >Thats what has been configured to emit these synchronous events. >What i am having problems with so far is the restriction of this message >to only the FE protocol LFB and then taking further shortcuts to say >we dont even need to mention the FE protocol LFB in the addressing. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 11 15:02:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21017 for ; Tue, 11 Jan 2005 15:02:32 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSRh-0005NM-59 for forces-archive@IETF.ORG; Tue, 11 Jan 2005 15:16:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F41746@cherry.ease.lsoft.com>; Tue, 11 Jan 2005 15:02:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 52966286 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 11 Jan 2005 15:02:24 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 11 Jan 2005 15:01:53 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011112011867:23932 ; Tue, 11 Jan 2005 12:01:18 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> <6.1.2.0.0.20050111131714.065fddf8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 12:01:18 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/11/2005 12:01:20 PM, Serialize complete at 01/11/2005 12:01:20 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105473710.1077.273.camel@jzny.localdomain> Date: Tue, 11 Jan 2005 15:01:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050111131714.065fddf8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Tue, 2005-01-11 at 13:19, Joel M. Halpern wrote: > If the heartbeat goes only from the FE to the CE, treating it as an Event > makes sense to me. That seems to be consistent re-use of mechanisms that > have general utility. > > The problem I see with that is the CE->FE direction. Sorry, a typo on my part when i typed that in. Meant FE->CE. > Except for this case, > the FE logic has no reason to be able to receive event messages. Scratch the CE->FE direction; its FE->CE > One alternative is to redefine heartbeat slightly. > Define it as simply that the CE and FE must hear from each other at the > configured interval. > The FE generates his side by generate heartbeat notifications if he has > nothing else to say. > The CE can deal with his side by sending null protocol messages (messages > with no operations). > > Does that work for people? Sounds neat and will reduce the amount of noise. Other adaptive heartbeats scheme i have seen (can be used in conjunction with what you propose) have the CE adjust the FE timers depending on the number of FEs present. Example, its 1 sec for upto 100 FEs and 2 seconds for [101,200] 4 seconds interval for > 200 nodes etc ... Some adaptation of this is used by mmusic mbus protocol. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 10:06:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19080 for ; Wed, 12 Jan 2005 10:06:32 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokIy-0007uO-53 for forces-archive@IETF.ORG; Wed, 12 Jan 2005 10:21:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F42B58@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 10:06:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53082499 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 10:06:28 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 10:05:55 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011207051568:26076 ; Wed, 12 Jan 2005 07:05:15 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> <6.1.2.0.0.20050111131714.065fddf8@localhost> <1105473710.1077.273.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 07:05:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 07:05:21 AM, Serialize complete at 01/12/2005 07:05:21 AM Content-Type: multipart/mixed; boundary="=-IbhkFZC7YrO0n/KHYkBM" Message-ID: <1105542347.1021.9.camel@jzny.localdomain> Date: Wed, 12 Jan 2005 10:05:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105473710.1077.273.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.8 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --=-IbhkFZC7YrO0n/KHYkBM Content-Type: text/plain Content-Transfer-Encoding: 7bit > On Tue, 2005-01-11 at 13:19, Joel M. Halpern wrote: > If the heartbeat goes only from the FE to the CE, treating it as an Event > makes sense to me. That seems to be consistent re-use of mechanisms that > have general utility. Attached sample FE Protocol Object definition. We havent settled on the events definition/subscription (so this could be way off). A subscription to an event in this case is equivalent to just kicking the LFB to start generating events/HBs. cheers, jamal --=-IbhkFZC7YrO0n/KHYkBM Content-Disposition: attachment; filename=FEProtoObj.xml Content-Type: text/xml; name=FEProtoObj.xml; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FEPO 5000 The FE Protocol Object 1.0 baseclass HBstate 2 Heartbeat event status(yes/no) boolean SupportableVersions 1 the table of ForCES versions that FE supports u8 HBI 3 Heartbeat Interval in millisecs u32 HBDI 4 Heartbeat Dead Interval in millisecs u32 CurrentRunningVersion 5 Currently running ForCES version u8 --=-IbhkFZC7YrO0n/KHYkBM-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 11:34:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26972 for ; Wed, 12 Jan 2005 11:34:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Colfo-0001d8-2D for forces-archive@IETF.ORG; Wed, 12 Jan 2005 11:48:49 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F42E1B@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 11:34:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53091618 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 11:34:08 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 11:25:41 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0CGPeSZ346334 for ; Wed, 12 Jan 2005 16:25:40 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0CGQ4P9071044 for ; Wed, 12 Jan 2005 16:26:04 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0CGPdwW004749 for ; Wed, 12 Jan 2005 16:25:39 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0CGPdne004742 for ; Wed, 12 Jan 2005 16:25:39 GMT Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA25750 for ; Wed, 12 Jan 2005 17:25:39 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j0CGPeSZ346334 Message-ID: <41E54F81.1040607@zurich.ibm.com> Date: Wed, 12 Jan 2005 17:25:37 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Multiple CEs talking to the same FE To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Here are some considerations around many CEs talking to the same FE,=20 based on early implementation experience: Associations: Multiple CEs may access the same FE, for instance to=20 accomplish different tasks, such as routing, security, QoS. These CEs=20 may each run in a separate machine, or they may share the same machine.=20 So there is an association for each (CE-FE) pair. Or do we consider=20 associations to include more than two members ? Note that multiple=20 associations may share the same TCP/SCTP/... connection. Demultiplexing: Note that in the case where multiple CEs run on the same=20 machine, the CE ID can be viewed as a demultiplexor. The ForCES protocol=20 does not otherwise include correlators that would enable callbacks to=20 the appropriate CE on the response to a ForCES command (or reception of=20 an event). Access conflicts: The framework draft specifies that CE synchronization=20 is beyond the scope of ForCES. This means that, for instance, two CEs=20 changing the same LFB attribute value, is not viewed at the ForCES level=20 as a conflict. But if two CEs try to perform interleaved 2-phase commit=20 operations on the same attribute, then ForCES should of course prevent=20 it and report it. Event reporting: If multiple CEs subscribe to different events in an=20 LFB, then the LFB must somehow know to which CE(s) events must be fired.=20 I propose that a list of interested CE IDs is associated with each event=20 attribute in the LFB. Regards, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 11:54:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28331 for ; Wed, 12 Jan 2005 11:54:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ColzD-000264-2H for forces-archive@IETF.ORG; Wed, 12 Jan 2005 12:08:50 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F42E20@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 11:54:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53093903 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 11:54:13 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 11:38:29 -0500 Received: from [69.170.9.20] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8637315 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 11:02:19 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> <6.1.2.0.0.20050111131714.065fddf8@localhost> <1105473710.1077.273.camel@jzny.localdomain> <1105542347.1021.9.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050112105905.03977a30@localhost> Date: Wed, 12 Jan 2005 11:01:52 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1105542347.1021.9.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Thanks. That is quite readable. (I hope it is as readable when we have the final format and all the other information.) I presume HBI (Heartbeat Interval) is the rate at which the FE will generate Heartbeat events. HBDI (Heartbeat Dead Interval) is presumably a period at which the FE would declare the CE dead? After all, the FE does not care when the CE will give up if it does not get heartbeats. But if it is an FE timer, what resets it? Any messages from the CE? Including the null message I hypothesised in an earlier reply? Or something else? Thank you, Joel At 10:05 AM 1/12/2005, Jamal Hadi Salim wrote: > > On Tue, 2005-01-11 at 13:19, Joel M. Halpern wrote: > > If the heartbeat goes only from the FE to the CE, treating it as an Event > > makes sense to me. That seems to be consistent re-use of mechanisms that > > have general utility. > >Attached sample FE Protocol Object definition. We havent settled on the >events definition/subscription (so this could be way off). A >subscription to an event in this case is equivalent to just kicking the >LFB to start generating events/HBs. > >cheers, >jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 12:42:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01225 for ; Wed, 12 Jan 2005 12:42:10 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ComjS-00033I-5O for forces-archive@IETF.ORG; Wed, 12 Jan 2005 12:56:45 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F42D21@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 12:41:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53098354 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 12:41:51 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 12:14:06 -0500 Received: from [69.170.9.20] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8637741 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 12:14:05 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <41E54F81.1040607@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: <6.1.2.0.0.20050112121110.0395a900@localhost> Date: Wed, 12 Jan 2005 12:13:37 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Multiple CEs talking to the same FE To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <41E54F81.1040607@zurich.ibm.com> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable I thought we had agreed that for now we would focus on a single active CE=20 per FE> An FE that wants to be managed by several CEs is (I thought) to=20 pretend it is several FEs, probably with distinct resources. The multi-manager problem is very very messy. The demultiplexing is a valid issue anyway. I think that the answer is=20 probably that one should use different ports if one is going to run several= =20 CEs (or FEs) on the same machine / interface. I am not sure we can /=20 should introduce an extra demux layer for the "native ethernet transport"= case. Yours, Joel At 11:25 AM 1/12/2005, Robert Haas wrote: >Here are some considerations around many CEs talking to the same FE, based= =20 >on early implementation experience: > >Associations: Multiple CEs may access the same FE, for instance to=20 >accomplish different tasks, such as routing, security, QoS. These CEs may= =20 >each run in a separate machine, or they may share the same machine. So=20 >there is an association for each (CE-FE) pair. Or do we consider=20 >associations to include more than two members ? Note that multiple=20 >associations may share the same TCP/SCTP/... connection. > >Demultiplexing: Note that in the case where multiple CEs run on the same=20 >machine, the CE ID can be viewed as a demultiplexor. The ForCES protocol=20 >does not otherwise include correlators that would enable callbacks to the= =20 >appropriate CE on the response to a ForCES command (or reception of an= event). > >Access conflicts: The framework draft specifies that CE synchronization is= =20 >beyond the scope of ForCES. This means that, for instance, two CEs=20 >changing the same LFB attribute value, is not viewed at the ForCES level=20 >as a conflict. But if two CEs try to perform interleaved 2-phase commit=20 >operations on the same attribute, then ForCES should of course prevent it= =20 >and report it. > >Event reporting: If multiple CEs subscribe to different events in an LFB,= =20 >then the LFB must somehow know to which CE(s) events must be fired. I=20 >propose that a list of interested CE IDs is associated with each event=20 >attribute in the LFB. > >Regards, > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 17:13:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22373 for ; Wed, 12 Jan 2005 17:13:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coqxq-0001g8-AR for forces-archive@IETF.ORG; Wed, 12 Jan 2005 17:27:49 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F43476@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 17:13:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53128222 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 17:12:41 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 17:12:03 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011214112747:28460 ; Wed, 12 Jan 2005 14:11:27 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> <6.1.2.0.0.20050111131714.065fddf8@localhost> <1105473710.1077.273.camel@jzny.localdomain> <1105542347.1021.9.camel@jzny.localdomain> <6.1.2.0.0.20050112105905.03977a30@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 02:11:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 02:11:30 PM, Serialize complete at 01/12/2005 02:11:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105567919.1021.44.camel@jzny.localdomain> Date: Wed, 12 Jan 2005 17:11:59 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050112105905.03977a30@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Wed, 2005-01-12 at 11:01, Joel M. Halpern wrote: > Thanks. That is quite readable. (I hope it is as readable when we have > the final format and all the other information.) BTW, I used u32 instead of uint32 as the type - not sure why the doc validated. > I presume HBI (Heartbeat Interval) is the rate at which the FE will > generate Heartbeat events. > HBDI (Heartbeat Dead Interval) is presumably a period at which the FE would > declare the CE dead? After all, the FE does not care when the CE will give > up if it does not get heartbeats. But if it is an FE timer, what resets > it? Good question. The original goal was for HA purposes. This hasnt been discussed in details yet; however, the general view at the time was for the FE to associate (failover) to another CE after that deadinterval period of not hearing from the router - as defined by policy which resides in that same LFB definition. Two such failover methodologies are mentiooned briefly infact in the protocol draft. I left that blank for now since i wasnt sure what to put in. > Any messages from the CE? We need to discuss it. Suggestion: The lack of any messages from the CE after a period of HBI will result in a FE firing a HB message. The lack of any message within DeadInterval will force the FE to ask for an ACK for its HB message (by setting the ACK flag in the header). > Including the null message I hypothesised in an earlier reply? > Or something else? Hasnt been discussed in details. This is an opportunity to do so. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 19:01:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01055 for ; Wed, 12 Jan 2005 19:01:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cosee-0003rl-I3 for forces-archive@IETF.ORG; Wed, 12 Jan 2005 19:16:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F4364A@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 19:01:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53132259 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 19:01:11 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 18:59:18 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0CNxFHm029252; Wed, 12 Jan 2005 23:59:15 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0CNwUM2024431; Wed, 12 Jan 2005 23:59:15 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011215591400277 ; Wed, 12 Jan 2005 15:59:14 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 15:59:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcT3LXMFX78+3ppGRIyRCQ4BkrnLigB1NQaQ X-OriginalArrivalTime: 12 Jan 2005 23:59:14.0881 (UTC) FILETIME=[B832E310:01C4F902] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03E11498@orsmsx408> Date: Wed, 12 Jan 2005 15:59:13 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Robert, All=20 The issue of LFB attributes serialization" method is actually a separate issue and applicable to all messages (not just association). I will post this as a separate issue (data encoding). Other than that #1 should be closed. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas In this context, the issue (raised on the list by Hormuzd) of=20 advertising not only one atribute, but the whole LFB at once (for=20 instance a core LFB) would require the definition of an "LFB attributes=20 serialization" method, which is missing at this point. And best wishes to all ! -Robert From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 19:04:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01261 for ; Wed, 12 Jan 2005 19:04:36 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coshj-0003vE-H1 for forces-archive@IETF.ORG; Wed, 12 Jan 2005 19:19:14 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F43763@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 19:04:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53132936 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 19:04:34 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 19:04:05 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0D044Hm031396 for ; Thu, 13 Jan 2005 00:04:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0D03ALw027908 for ; Thu, 13 Jan 2005 00:04:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011216040401285 for ; Wed, 12 Jan 2005 16:04:04 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 16:04:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F903.64B196D1" Thread-Topic: [issue 8] data encoding Thread-Index: AcT5A2RbpmDJSO4cTMOWjumrXgfibA== X-OriginalArrivalTime: 13 Jan 2005 00:04:04.0637 (UTC) FILETIME=[64E824D0:01C4F903] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03E114C8@orsmsx408> Date: Wed, 12 Jan 2005 16:04:03 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: [issue 8] data encoding To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F903.64B196D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I am sending out this email to capture the data encoding issue, that needs to be discussed and finalized. Data encoding and Path are the two main items that need to be resolved for the protocol draft. =20 I remember Steve/Zsolt had posted something on this sometime back. We could probably start the discussion using that text? =20 regards Hormuzd =20 ------_=_NextPart_001_01C4F903.64B196D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
I am = sending out=20 this email to capture the data encoding issue, that needs to be = discussed and=20 finalized.
Data = encoding and=20 Path are the two main items that need to be resolved for the = protocol=20 draft.
 
I = remember=20 Steve/Zsolt had posted something on this sometime back. We could = probably start=20 the discussion using that text?
 
regards
Hormuzd
 
------_=_NextPart_001_01C4F903.64B196D1-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 12 19:30:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03505 for ; Wed, 12 Jan 2005 19:30:18 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cot6e-0004Zq-96 for forces-archive@IETF.ORG; Wed, 12 Jan 2005 19:44:57 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F43806@cherry.ease.lsoft.com>; Wed, 12 Jan 2005 19:30:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53134261 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 12 Jan 2005 19:30:15 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 12 Jan 2005 19:29:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011216284294:29469 ; Wed, 12 Jan 2005 16:28:42 -0800 References: <468F3FDA28AA87429AD807992E22D07E03E114C8@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 04:28:43 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/12/2005 04:28:44 PM, Serialize complete at 01/12/2005 04:28:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1105576154.1091.4.camel@jzny.localdomain> Date: Wed, 12 Jan 2005 19:29:15 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 8] data encoding To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03E114C8@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Hormuzd, I belive that topic is being discussed under "Subject: [issue6] Summary of Path" The path-data describes how dats is encoded. Refer to the doc i posted on that thread. cheers, jamal On Wed, 2005-01-12 at 19:04, Khosravi, Hormuzd M wrote: > Hi All, > > I am sending out this email to capture the data encoding issue, that > needs to be discussed and finalized. > Data encoding and Path are the two main items that need to be resolved > for the protocol draft. > > I remember Steve/Zsolt had posted something on this sometime back. We > could probably start the discussion using that text? > > regards > Hormuzd > From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 13 09:10:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11865 for ; Thu, 13 Jan 2005 09:10:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp5uo-0004wi-E7 for forces-archive@IETF.ORG; Thu, 13 Jan 2005 09:25:37 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F4469B@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 9:10:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53225227 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 09:10:45 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 09:10:01 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011306090127:30040 ; Thu, 13 Jan 2005 06:09:01 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/13/2005 06:09:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/13/2005 06:09:28 AM, Serialize complete at 01/13/2005 06:09:28 AM Content-Type: multipart/mixed; boundary="=-0W3x2NXfcbntDFWWOFRu" Message-ID: <1105625373.1706.13.camel@jzny.localdomain> Date: Thu, 13 Jan 2005 09:09:33 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: data path encoding update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 64592953d6410e1f725ee21266e2f396 --=-0W3x2NXfcbntDFWWOFRu Content-Type: text/plain Content-Transfer-Encoding: 7bit I have updated the document to show variable size data encoding. Please review. Both new and diff from previous included. Weiming! havent heard from you; have heard from Joel on previous posting of this doc. My interpretation is it seems agreeble to him. So please Get, Del , Add|Modify so we can wrap this up. cheers, jamal --=-0W3x2NXfcbntDFWWOFRu Content-Disposition: attachment; filename=diff.dp2-1.txt Content-Type: text/plain; name=diff.dp2-1.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- data_path2.txt 2005/01/11 17:03:15 1.3 +++ data_path2.txt 2005/01/13 14:06:08 @@ -29,7 +29,8 @@ PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> -DATARAW := somedata [DATAINFO] +DATARAW := [DATAINFO] +THEDATA := [somedata]* [VARENCDATA TLV]* INDINFO TLV := index | fieldID KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] @@ -46,9 +47,13 @@ used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH and applied operations. As an example a GET or DEL may not have data. --> DATARAW contains the data whose path is selected. This may +-> DATARAW contains "the data" whose path is selected. This may recursively contain DATAINFO such that we can have a series -of "path data subpath data subpath data ..." +of "path data selector data selector data ..." +The data depending on the LFB may containing variable sized entities. +To ensure that entities > 2^16 bytes can also be encoded, the +Type of the VARENCDATA will indicate whether the the length is in +bytes, words, doublewords etc. (expand more later on this) NOTE! NOTE! ----------- @@ -191,6 +196,11 @@ j1, type u32, ID = 1 j2, type u32, ID = 2 +table3: type array, ID = 5 + elements are: + someid, type u32, ID = 1 + name, type string variable sized, ID = 2 + 1) To get foo1 Path: IDCount = 1, IDs = 1 @@ -340,7 +350,7 @@ 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 -Subpath := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} +SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} In other words the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" @@ -359,7 +369,7 @@ starting at index 10. Path = IDCount = 1, IDs=4 -Subpath := +SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} @@ -380,16 +390,44 @@ only 5? What about when the highest index available is 5? Need to enumerate all possible error paths +13) Dump contents of table3, + +should be noted that this table has a column with element name +that is variable sized. The purpose of this use case is to show +how such an element is to be encoded. + +Path = IDCount = 1, IDs=5 + +Result: +Assuming subscript/index holes in the table +Path = IDCount = 1, IDs=5 +T = BLK_LIST_INDEX, L = XXX +Values: 3, 5, 15, ... + +DATAINFO TLV, Length = XXXX +Values: + someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval + someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval + someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval + someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval + . + . + . TODO: - more refinement of flags for atomicity etc - column and cell access in a table use cases -- Provide a more complex use case example (where a table cell points -to a whole table). Essentially this is no different from the -variable sized string problem pointed to in the BNF (while describing -"somedata"). +- shos an example like the one Weiming was talking about where you +have someone configuring in one message table1 but also the entry +in table2 that is pointed at. This will show a sample of +path subpath data subpath data i believe. $Log: data_path2.txt,v $ +Revision 1.4 2005/01/13 14:01:11 hadi +added table 3 which contains variable sized strings. +added example of how such a table is to be manipulated +extended the grammar slightly to accomodate above + Revision 1.3 2005/01/11 17:03:15 hadi proof read and sent to list; major change was s/RAWDATA/DATAINFO/g A little more explanatory text --=-0W3x2NXfcbntDFWWOFRu Content-Disposition: attachment; filename=data_path2.txt Content-Type: text/plain; name=data_path2.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Standard Disclaimer: -------------------- This doc by no means imposes a decision. It serves as a discussion place holder with the a desire to speed up the path-data discussion up. NOTE: ----- 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA which is the subject of this discussion. Opcodes discussed so far: * SET (create, modify, append etc depending on PATH-DATA flags} * DEL (remove existing config objects specified by PATH-DATA } * GET (Access existing config objects specified in PATH-DATA } [Add any events here] A possible path-data layout. ---------------------------- OPER TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> DATARAW := [DATAINFO] THEDATA := [somedata]* [VARENCDATA TLV]* INDINFO TLV := index | fieldID KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined at LFB definition) or dynamically created (table indices). -> flags are used to further refine the operation to be applied on the ID_TLV. -> SELECTOR := optional different BLK, KEY or Index/fieldID to extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH and applied operations. As an example a GET or DEL may not have data. -> DATARAW contains "the data" whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data selector data selector data ..." The data depending on the LFB may containing variable sized entities. To ensure that entities > 2^16 bytes can also be encoded, the Type of the VARENCDATA will indicate whether the the length is in bytes, words, doublewords etc. (expand more later on this) NOTE! NOTE! ----------- The DATARAW "somedata" is LFB dependent. It is assumed that the recepient by virtue of knowing the LFB can decode the data. In the simple LFB used in this doc, the fields in the two tables are all of fixed size. It would need some TLV to explain variable sized entries such as strings. TBD: Should we leave this upto the LFB specific to worry about the encoding/decoding. If yes, how does the LFB definition describe this? If no, should we add this to the grammar? If yes, how? flags ----- Derived from Netlink and BSD route sockets: --> F_EXCL Donot replace the config attribute(s) if already exists - Report back error instead. --> F_REPLACE Replace existing matching config attribute(s) with passed data. If config object doesnt exist, return an error. --> F_CREATE Create config object if it does not already exist. If config object already exists, return an error. --> F_APPEND: Add to the end of the object list/table. This could create xplicates (dup/triplicates etc) Essentially: - To ADD a new config object: F_CREATE | F_EXCL - To change an existing object: F_REPLACE - To test if object exists: F_EXCL Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. We may need to rediscuss that if need be. BLK path selection ------------------ For block operations three modes exist [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. 1) BLK_RANGE_INDEX TLV T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" count //"N" 3) BLK_LIST_INDEX TLV T= BLK_LIST_INDEX, length = 4+(4*(count of indices)) index0 // "a" index1 //"c" index2 //"e" ...... ...... indexN-1 //"?" Content path selection --------------------- We introduce a KEY_INFO TLV which will describe the KEY as well as associated KEY data (example Keyid = 3 for "foo1" and Key_data = 5"). KEYINFO TLV := KEYID KEY_DATA Where KEYID is a 32 bit entity that contains the index or field ID and data contains the data being referenced. The L of the TLV adjusts given the size of the KEY_DATA. The only equality allowed is the "=" sign which means any search will be for "KEYID=KEY_DATA" example "foo1=10" (where foo1's ID is actually placed in the KEYID field instead of the name "foo1". NOTE! NOTE! There is still some open discussion here: A) Joels view: i) Allow only for one or two keys per table instance for simplicty reasons. Example, allow only j1 to be the key for table2. Enforce this via LFB definition. ii) A key value is unique per table instance. In other words, if one was to scan table 2 they would only see one occurance of a table row which has value "j1=10" B) Weiming: i) there are no unique keys. ii) there can be multiple row instances of "j1=10" It should be noted that it is possible to achieve what Weiming wants using the F_APPEND flag when creating a table row entry. Infact there are some LFBs which may allow for this (I know some ASICs with classifiers that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). [Additional note: In the case the forwarding path actually does everything with index based tables, then doing a check of "j1=1 AND j2=10" is valid; however, j2 and j1 are not really "keys" if we use proper terminology ;->] Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. DATAINFO: --------- The DATAINFO TLV will contain the RAWDATA which may optionaly contain a DATAINFO TLV (to allow for recursive interleaving of path-data). USE CASES --------- Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 table3: type array, ID = 5 elements are: someid, type u32, ID = 1 name, type string variable sized, ID = 2 1) To get foo1 Path: IDCount = 1, IDs = 1 Result: Path = IDCount = 1, IDs = 1, RAWDATA TLV with value of foo1 2) to set foo2 to 10 Path: IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 Result: Depends on whether we asked for a simple success/ACK back or full details 3) To dump table2 (get) Assuming numentries defines the number of entries. Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = numentries-1 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations To set entry 0-2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 2 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To set entry 0,2 of table2 (I am going to ignore error conditions for now) Path = IDCount = 1, IDs=4 BLK_LIST_INDEX TLV 0,2 DATAINFO TLV, Length = XXX, V = two j1value,j2value entries 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 the above shows that mainpath can constitute indices. Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value Another valid response is: Path = IDCount = 2, IDs=4.0 DATAINFO TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 TBD: What to do when say entry 1 doesnt exist? Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 8) Using BLK_CNT_INDEX for #7 Path = IDCount = 1, IDs=4 followed by BLK_CNT_INDEX TLV to extend path T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 DATAINFO TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value j1value,j2value 9) Using BLK_LIST_INDEX TLV for #7 Path = IDCount = 1, IDs=4 followed by BLK_LIST_INDEX TLV T = BLK_CNT_INDEX, L = XXX Values: 0,1,2 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 10) Dump contents of table1, Path = IDCount = 1, IDs=3 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=3 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . . (note t2 is subscript for table2 and infact we are resolving table2 contents above) TBD: Do we just resolve the contents pointed to by t2value as shown above or do we have a flag to select between two modes? Clearly a good way to do this is not to resolve any paths(i.e dumping of table1 should obly have t1value and t2value); rather the CE should OPerate on both tables in one atomic invocation. 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} In other words the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" Result: Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path = IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} Result: This assumes we have asked for the full results back (instead of just simple pass/fail. We need a flag - refer to other discussion) Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TBD: What to do when we request the next 10 entries but theres only 5? What about when the highest index available is 5? Need to enumerate all possible error paths 13) Dump contents of table3, should be noted that this table has a column with element name that is variable sized. The purpose of this use case is to show how such an element is to be encoded. Path = IDCount = 1, IDs=5 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=5 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval . . . TODO: - more refinement of flags for atomicity etc - column and cell access in a table use cases - shos an example like the one Weiming was talking about where you have someone configuring in one message table1 but also the entry in table2 that is pointed at. This will show a sample of path subpath data subpath data i believe. $Log: data_path2.txt,v $ Revision 1.4 2005/01/13 14:01:11 hadi added table 3 which contains variable sized strings. added example of how such a table is to be manipulated extended the grammar slightly to accomodate above Revision 1.3 2005/01/11 17:03:15 hadi proof read and sent to list; major change was s/RAWDATA/DATAINFO/g A little more explanatory text Revision 1.2 2005/01/11 16:30:37 hadi posted to the list proof reading and making small changes next Revision 1.1 2004/11/14 18:47:07 hadi Initial revision --=-0W3x2NXfcbntDFWWOFRu-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 13 16:22:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19794 for ; Thu, 13 Jan 2005 16:22:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpCeo-0007ax-3N for forces-archive@IETF.ORG; Thu, 13 Jan 2005 16:37:36 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F44F76@cherry.ease.lsoft.com>; Thu, 13 Jan 2005 16:22:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53268453 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 16:22:33 -0500 Approved-By: avri@PSG.COM Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 13 Jan 2005 15:36:45 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpBi1-000Hps-9B for FORCES@PEACH.EASE.LSOFT.COM; Thu, 13 Jan 2005 20:36:45 +0000 Mime-Version: 1.0 (Apple Message framework v619) References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <6.1.2.0.0.20050110094710.06565008@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: Date: Thu, 13 Jan 2005 15:36:44 -0500 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050110094710.06565008@localhost> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit On 10 jan 2005, at 09.49, Joel M. Halpern wrote: > Personally, the longer this discussion goes on, the more I am inclined > to conclude that the whole idea of content addressing is a bad idea. > It complicates the FE, complicates the CE, and complicates the > protocol. > I tend to agree with this. a. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 16 12:26:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29098 for ; Sun, 16 Jan 2005 12:26:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqEPF-0006Lp-NM for forces-archive@IETF.ORG; Sun, 16 Jan 2005 12:41:44 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F4A136@cherry.ease.lsoft.com>; 16 Jan 2005 5:18:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53600231 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Jan 2005 05:17:58 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 16 Jan 2005 05:15:44 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sun, 16 Jan 2005 18:41:35 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 16 Jan 2005 18:15:23 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <6.1.2.0.0.20050110094710.06565008@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <018801c4fbb4$50d4e0b0$845c21d2@Necom.hzic.edu.cn> Date: Sun, 16 Jan 2005 18:15:34 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi Joel, Along with the discussions, I have an impression that we may have some basic difference on the designe criteria for the protocol. I suppose you may more tend to make it more like a SNMP, that is, a simple, one by one operation based, and looks beautiful in the PDU. While I may have quite different thought in mind for it. I think, alghouth SNMP is a good prioneer worthy ForCES learning, there are basic difference between them. SNMP is for management while ForCES is for controlling. ForCES is somewhat a real-time system, which generically requires more complexity to ensure its feasibility and efficiency, therefore, I don't think it's very practical for ForCES to cut the complexity to acquire the simplicity. I agree with Jamal's thought that for ForCES beauty is the second we only need to consider, the first we should consider is its feasibility. As a result, the criteria in my mind for the protocol is, to meet the requirements is the first, to have an efficient PDU to save bits is the second, because I have always worried about the link resources that link CE and FE, the third is the simplicity. Talking about this, I have to say again that the idea of 'index' is really another thing that still bother me some. As you may also worry a little, the management of 'index' (as well as the index holes), that will in the end be a big extra burden for CE and FE. I'v been trying to find some router design instances (including ASIC based design), but still haven't found one that uses index to manage routing tables. I see the Cisco IOS, the linux Netfilter also do not use any index for such management. I'm not sure if you could show some more experiences on it. I also strongly ask other guys on the list to show some experiences with the use of index for routing table management. That will be much helpful for our confidence. Thank you. Weiming > On 10 jan 2005, at 09.49, Joel M. Halpern wrote: > > > Personally, the longer this discussion goes on, the more I am inclined > > to conclude that the whole idea of content addressing is a bad idea. > > It complicates the FE, complicates the CE, and complicates the > > protocol. > > From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 16 12:26:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29115 for ; Sun, 16 Jan 2005 12:26:19 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqEPJ-0006Lp-0v for forces-archive@IETF.ORG; Sun, 16 Jan 2005 12:41:46 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F4A104@cherry.ease.lsoft.com>; 16 Jan 2005 5:52:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53601686 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 16 Jan 2005 05:52:35 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 16 Jan 2005 05:52:09 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sun, 16 Jan 2005 19:18:00 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 16 Jan 2005 18:51:47 +0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> <41E3AEE1.5030100@zurich.ibm.com> <1105464441.1076.258.camel@jzny.localdomain> <6.1.2.0.0.20050111131714.065fddf8@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <022201c4fbb9$673f9c00$845c21d2@Necom.hzic.edu.cn> Date: Sun, 16 Jan 2005 18:51:59 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Joel, We actually have had quite a long discussion on the need for a specific HB msg or just use events for HBs.I think my thought complies with yours well. More detailedly, my thought is: 1. There are two entities related to HB, one is the HB attribute, the other is HB event. 2. For FE, HB event and HB attribute belongs to FE object attributes. For CE, there is only HB event that belongs to CE events. 3. HB attribute at FE can be set by CE to decide its parameters like the interval. ForCES has no access to HB parameters generated by CE. 4. To start HBs in FE is at the time to subscirbe it. There is no access for ForCES to decide when to start HB from CE. 5. PDU of HB events can fully be the same as general Event notification message. I think we have not met the issue of how the Event Notification message generated by CE is formatted. I'm sure when this is resolved, the message format for HB from CE to FE can also be resolved. Now, I think, we come to the discussion again on if we need a specific HB message for ForCES. Thank you. Weiming ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [issue 7] HB msg > If the heartbeat goes only from the FE to the CE, treating it as an Event > makes sense to me. That seems to be consistent re-use of mechanisms that > have general utility. > > The problem I see with that is the CE->FE direction. Except for this case, > the FE logic has no reason to be able to receive event messages. > One alternative is to redefine heartbeat slightly. > Define it as simply that the CE and FE must hear from each other at the > configured interval. > The FE generates his side by generate heartbeat notifications if he has > nothing else to say. > The CE can deal with his side by sending null protocol messages (messages > with no operations). > > Does that work for people? > > Thank you, > Joel > > At 12:27 PM 1/11/2005, Jamal Hadi Salim wrote: > > > 2) give HB the format of an event: LFB-Selector selects the FE > > > Protocol LFB, command is EVENT-REPORT and path-data identifies the > > > heartbeat event attribute in the FE Protocol LFB. Data is empty. > > > > > > >I think this is what i am leaning towards ... > >A heartbeat is a synchronous _event_. A CE needs to kick the > >FE::LFBofinterest to start emiting the events (I suppose after > >setting the proper parameters such as clock interval and dead interval). > >One could say a basic heartbeat will have a zero sized message. > >OTOH, an synchronous event such as the one emited by the topology LFB > >will have > zero sized data (if configured to periodically send updates > >to the CE). > > > >The source of this message is the LFB object if going from CE to FE. > >Thats what has been configured to emit these synchronous events. > >What i am having problems with so far is the restriction of this message > >to only the FE protocol LFB and then taking further shortcuts to say > >we dont even need to mention the FE protocol LFB in the addressing. > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 17 16:10:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15029 for ; Mon, 17 Jan 2005 16:10:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqeOQ-0007IE-Po for forces-archive@IETF.ORG; Mon, 17 Jan 2005 16:26:36 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F4BE57@cherry.ease.lsoft.com>; Mon, 17 Jan 2005 16:10:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53810563 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 17 Jan 2005 16:10:53 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 17 Jan 2005 16:09:54 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011713091127:34201 ; Mon, 17 Jan 2005 13:09:11 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/17/2005 01:09:11 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/17/2005 01:09:17 PM, Serialize complete at 01/17/2005 01:09:17 PM Content-Type: multipart/mixed; boundary="=-TvcMjT9fEaZnbNDY15mF" Message-ID: <1105996187.1079.288.camel@jzny.localdomain> Date: Mon, 17 Jan 2005 16:09:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 --=-TvcMjT9fEaZnbNDY15mF Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached updated version. The outstanding issues are listed in the text. Please read the text. Weiming! I am still waiting to hear from you on this. I have heard from Joel and he is pretty much set to move forward. Please make your comments, suggested modifications etc. cheers, jamal --=-TvcMjT9fEaZnbNDY15mF Content-Disposition: attachment; filename=data_path2.txt Content-Type: text/plain; name=data_path2.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Standard Disclaimer: -------------------- This doc by no means imposes a decision. It serves as a discussion place holder with the a desire to speed up the path-data discussion up. NOTE: ----- 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA which is the subject of this discussion. Opcodes discussed so far: * SET (create, modify, append etc depending on PATH-DATA flags} * DEL (remove existing config objects specified by PATH-DATA } * GET (Access existing config objects specified in PATH-DATA } [Add any events here] A possible path-data layout. ---------------------------- OPER TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> DATARAW := [DATAINFO] THEDATA := [somedata]* [VARENCDATA TLV]* INDINFO TLV := index | fieldID KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined at LFB definition) or dynamically created (table indices). -> flags are used to further refine the operation to be applied on the ID_TLV. -> SELECTOR := optional different BLK, KEY or Index/fieldID to extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being used for selection. -> DATAINFO: = Optional variable sized data dependent on PATH and applied operations. As an example a GET or DEL may not have data. -> DATARAW contains "the data" whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data selector data selector data ..." The data depending on the LFB may containing variable sized entities. To ensure that entities > 2^16 bytes can also be encoded, the Type of the VARENCDATA will indicate whether the the length is in bytes, words, doublewords etc. (expand more later on this) Example layout -------------- T = SET //operation + +---+ | | // pathata to target X | +--- // with data to be added/replaced | // This is the discussion point | | T = DEL //operation | + +---+ | // pathdata to target A +--- // with data to be Deleted // This is the discussion point A reminder: 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) There is only one path-data per operation. 4) Atomicity for operations is defined in the main header flags. 5) verbosity needed in response is defined in main headers flags. NOTE! NOTE! ----------- The DATARAW "somedata" in the BNF is LFB dependent. It is assumed that the recepient by virtue of knowing the LFB format can decode the data. In the simple LFB used in this doc, the fields in the two tables are all of fixed size. It would need some TLV to explain variable sized entries such as strings. TBD: Should we leave this upto the LFB specific to worry about the encoding/decoding. If yes, how does the LFB definition describe this? If no, should we add this to the grammar? If yes, how? NOTE: OPEN ISSUE on BNF ------------------------ At the moment, the BNF says: OPER TLV : = To satisfy Weiming fully we would need to make this: OPER TLV : = + Which means the rule that "There is only one path-data per operation" no longer holds. Joels belief is this is gonna add to complexity. I am indifferent. flags ----- Derived from Netlink and BSD route sockets: --> F_EXCL Donot replace the config attribute(s) if already exists - Report back error instead. --> F_REPLACE Replace existing matching config attribute(s) with passed data. If config object doesnt exist, return an error. --> F_CREATE Create config object if it does not already exist. If config object already exists, return an error. --> F_APPEND: Add to the end of the object list/table. This could create xplicates (dup/triplicates etc) Essentially: - To ADD a new config object: F_CREATE | F_EXCL - To change an existing object: F_REPLACE - To test if object exists: F_EXCL Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. We may need to rediscuss that if need be. BLK path selection ------------------ For block operations three modes exist [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. 1) BLK_RANGE_INDEX TLV T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" count //"N" 3) BLK_LIST_INDEX TLV T= BLK_LIST_INDEX, length = 4+(4*(count of indices)) index0 // "a" index1 //"c" index2 //"e" ...... ...... indexN-1 //"?" Content path selection --------------------- We introduce a KEY_INFO TLV which will describe the KEY as well as associated KEY data (example Keyid = 3 for "foo1" and Key_data = 5"). KEYINFO TLV := KEYID KEY_DATA Where KEYID is a 32 bit entity that contains the index or field ID and data contains the data being referenced. The L of the TLV adjusts given the size of the KEY_DATA. The only equality allowed is the "=" sign which means any search will be for "KEYID=KEY_DATA" example "foo1=10" (where foo1's ID is actually placed in the KEYID field instead of the name "foo1". NOTE! NOTE! There is still some open discussion here: A) Joels view: i) Allow only for one or two keys per table instance for simplicty reasons. Example, allow only j1 to be the key for table2. Enforce this via LFB definition. ii) A key value is unique per table instance. In other words, if one was to scan table 2 they would only see one occurance of a table row which has value "j1=10" B) Weiming: i) there are no unique keys. ii) there can be multiple row instances of "j1=10" It should be noted that it is possible to achieve what Weiming wants using the F_APPEND flag when creating a table row entry. Infact there are some LFBs which may allow for this (I know some ASICs with classifiers that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). [Additional note: In the case the forwarding path actually does everything with index based tables, then doing a check of "j1=1 AND j2=10" is valid; however, j2 and j1 are not really "keys" if we use proper terminology ;->] Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. DATAINFO: --------- The DATAINFO TLV will contain the RAWDATA which may optionaly contain a DATAINFO TLV (to allow for recursive interleaving of path-data). USE CASES --------- Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 table3: type array, ID = 5 elements are: someid, type u32, ID = 1 name, type string variable sized, ID = 2 1) To get foo1 Path: IDCount = 1, IDs = 1 Result: Path = IDCount = 1, IDs = 1, RAWDATA TLV with value of foo1 2) to set foo2 to 10 Path: flags = F_REPLACE, IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 Result: Depends on whether we asked for a simple success/ACK back or full details 3) To dump table2 (get) Assuming numentries defines the number of entries. Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = numentries-1 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations To create entry 0-2 of table2 (I am going to ignore error conditions for now) Path: flags = F_CREATE | F_REPLACE, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 2 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To replace entry 0,2 of table2 (I am going to ignore error conditions for now) Path: flags = F_REPLACE, = IDCount = 1, IDs=4 BLK_LIST_INDEX TLV 0,2 DATAINFO TLV, Length = XXX, V = two j1value,j2value entries 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 the above shows that mainpath can constitute indices. Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value Another valid response is: Path = IDCount = 2, IDs=4.0 DATAINFO TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 TBD: What to do when say entry 1 doesnt exist? Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 8) Using BLK_CNT_INDEX for #7 Path = IDCount = 1, IDs=4 followed by BLK_CNT_INDEX TLV to extend path T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 DATAINFO TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value j1value,j2value 9) Using BLK_LIST_INDEX TLV for #7 Path = IDCount = 1, IDs=4 followed by BLK_LIST_INDEX TLV T = BLK_CNT_INDEX, L = XXX Values: 0,1,2 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 10) Dump contents of table1, Path = IDCount = 1, IDs=3 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=3 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . . (note t2 is subscript for table2 and infact we are resolving table2 contents above) TBD: Do we just resolve the contents pointed to by t2value as shown above or do we have a flag to select between two modes? Clearly a good way to do this is not to resolve any paths(i.e dumping of table1 should obly have t1value and t2value); rather the CE should OPerate on both tables in one atomic invocation. 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} In other words the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" Result: Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} Result: This assumes we have asked for the full results back (instead of just simple pass/fail. We need a flag - refer to other discussion) Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TBD: What to do when we request the next 10 entries but theres only 5? What about when the highest index available is 5? Need to enumerate all possible error paths 13) Dump contents of table3, should be noted that this table has a column with element name that is variable sized. The purpose of this use case is to show how such an element is to be encoded. Path = IDCount = 1, IDs=5 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=5 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval . . . 14) Multiple atomic operations. [This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is both tables are in the same LFB] Main header has atomic flag set and we are request for verbose/full results back; Two operations on the LFB instance, both are SET operations. //Operation 1: Add a new entry to table2 index #20. Path: flags = F_CREATE | F_EXCL, IDCount = 2, IDs=4.20 DATAINFO TLV, V= j1value,j2value // second Operation: Update table1 entries which // were pointing to NH index 10 to now point to index 20 Path: flags = F_REPLACE, IDCount = 1, IDs=3 SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID = 2 KEY_DATA=10} DATAINFO TLV, V= 20 Result: //first operation, SET Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value //second opertion SET - assuming 3 entries were updated Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TODO: - column and cell access in a table use cases - resolve issues outstanding between Joel and Weiming So we can move on! $Log: data_path2.txt,v $ Revision 1.6 2005/01/17 21:05:58 hadi added an example layout diagram updated issues list posted to list Revision 1.5 2005/01/17 19:25:49 hadi posted to the list Revision 1.4 2005/01/13 14:01:11 hadi added table 3 which contains variable sized strings. added example of how such a table is to be manipulated extended the grammar slightly to accomodate above Revision 1.3 2005/01/11 17:03:15 hadi proof read and sent to list; major change was s/RAWDATA/DATAINFO/g A little more explanatory text Revision 1.2 2005/01/11 16:30:37 hadi posted to the list proof reading and making small changes next Revision 1.1 2004/11/14 18:47:07 hadi Initial revision --=-TvcMjT9fEaZnbNDY15mF-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 18 10:22:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01605 for ; Tue, 18 Jan 2005 10:22:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvQZ-0002MV-Eo for forces-archive@IETF.ORG; Tue, 18 Jan 2005 10:37:59 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F4D249@cherry.ease.lsoft.com>; Tue, 18 Jan 2005 10:22:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53920147 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Jan 2005 10:21:53 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 18 Jan 2005 10:20:15 -0500 Received: from [219.82.171.196] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Tue, 18 Jan 2005 23:46:30 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <41E3DCFC.3060502@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <006401c4fd71$ad41d100$020aa8c0@wwm1> Date: Tue, 18 Jan 2005 23:23:26 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Joel, Robert, and Jamal, Firstly, Jamal, I appreciate your efforts, but just could you give me a little bit more time for more discussions on the fundamentals, before we can perfectly settle the PDU? From Joel's original proposal on Index and Robert's comments as below, I think the key goes to the state as "if an CE can maintain a copy of any tables in FE?". I confess that CE can do this well for routing tables in FE, but I just worry about some other tables that FE may actually change the contents of the tables. I can think of these tables as some tables for capabilities, for statistics, and even for some events. Obviously, CE will not be able to have a copy in advance before querying them. This also leads to the difficulties for the use the idea index for them. Therefore, my compromise is, even if we choose INDEX, it should not be a MUST for all kinds of tables. For content-based searching, I have to say again that, when we observe it from the mechanical point of view, index is also a kind of content searching, that is, the content is the index(note we will never expect a sequential index). Therefore, I don't think it makes sense much to discuss if an FE need a content searching mechanism or not, instead, we may just need to discuss in which dgree FE should support such search. When we have the thought that not all tables are always applicable with Index, I'm afraid to include content-based searching expression in the protocol is unavoidable, unless we assume and make a provisioning that it is only allowed to access a whole table, instead of entries in the table. Yours, Weiming ----- Original Message ----- From: "Robert Haas" To: Sent: Tuesday, January 11, 2005 10:04 PM Subject: Re: [issue6] Summary of Path > Weiming, all, > > Wang,Weiming wrote (excerpt): > > >Thinking we have an LFB with following attribute: > > > >Foo3, type structure, ID=5 > >{ > > s1, type u32, ID=1 > > s2, type structure, ID=2 > > { > > g1, type u32, ID=1 > > g2, type u32, ID=2 > > g3, tyep u32, ID=3 > > } > > } > > > >With mainpath and subpath, I think the format should be like: > >Mainpath(Foo3) subpath( s1) value subpath(s2.g1) value subpath(s2.g2) value > > > >I actually talked about this before with Joel. I think Joel asked that in this > >case, he would rather use three separate path-data to do so, that is, > > > >path(Foo3.s1) value > >path(Foo3.s2.g1) value > >path(Foo3.s2.g2) value > > > >If the above path-values are in one OpTLV, I can more or less live with it, but > >still think the mainpath and subpath mode is better than this. I supposed Joel > >asked the path-values be in different OpTLVs, which I'm hard to accept. I think > >such operation is originally atomic, to separate them into different OpTLVs is > >not reasonable enough. > > > >Want to hear what others think about it. > > > > > > > I find the three separate path-data simpler and clearer. Such path-data > can be aggregated under the same OpTLV, or they can be in separate > OpTLVs. The protocol should support both cases. > > >>At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: > >> > >> > >>>Heres a basic first attempt at BNF that would satisfy what you are > >>>asking for: > >>> > >>>OPER_TLV : = > >>>PATH-DATA := [DATAINFO] > >>>PATH := flags IDcount > >>>DATAINFO:= [SUBPATH] [DATARAW] > >>>SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> > >>>DATARAW := somedata [DATAINFO] > >>> > >>> > > > > > > > I'd like some description of KEYINFO. Or better, an example of how this > actually looks like for a content-based search key in a simple array. I > am worried the devil is again in the details. > > Regarding the need to support content-based search at all: Joel rightly > expressed concern about too much sophistication. I also think most of > the management operations should be handled at the CE, except in the > case of obvious protocol-efficiency gains. > > For instance, the CE is able to convert a content-based access into one > (or more) index-based access(es), as the CE is supposed to keep track of > what the FE stores. But block operations should not be split into a > sequence of operations by the CE, even though the CE is very well able > to do it too. > > Index-based accesses are the lowest-common denominator, and > content-based accesses are an option that each LFB may or may not > support, with arbitrary or pre-specified keys (or even key > combinations). Requiring SQL-engine-like capability in an FE would kill > the spec, I think. > > Note that even though the FE must have a (hopefully efficient) > implementation to retrieve/set an entry from/into its data structs based > on (ForCES) index, it does not mean at all that the FE uses an indexed > array for the data struct used for datapath lookup. Probably this was > obvious to everyone here. > > Regards, > -Robert > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 18 10:54:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04930 for ; Tue, 18 Jan 2005 10:54:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqvvn-0003Jj-IP for forces-archive@IETF.ORG; Tue, 18 Jan 2005 11:10:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F4D109@cherry.ease.lsoft.com>; Tue, 18 Jan 2005 10:54:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53922300 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Jan 2005 10:54:16 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 18 Jan 2005 10:53:13 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8731540 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Jan 2005 10:53:12 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <41E3DCFC.3060502@zurich.ibm.com> <006401c4fd71$ad41d100$020aa8c0@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050118104416.03af9350@localhost> Date: Tue, 18 Jan 2005 10:53:03 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006401c4fd71$ad41d100$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 >I certainly agree that being forced to fetch (or worse update) entire >tables would be a very bad choice. However, I have not yet seen a convincing case for either 1) a situation where indices are not supportable 2) a situation where arbitrary keying is needed. Here arbitrary refers to either of non-unique keys or keys that are not declared by the LFB class definition. I have seen some interesting arguments for limitted content keying to reflect cases where it is known a priori that it will be helpful to many FE implementations if the CE uses the content keys. Note here that we are discussing the structure of information, not the content. The fact that the FE will modify statistical information does not appear to be relevant. And capability information MUST have a known access structure, so that the CE can traverse and utilize the information. I prefer to make that structure a simple index. Yes, you can declare the indexing is a form of content addressing. It is a form of content addressing with unique, pre-declared keys. Given that for interoperability, the CE must have a table access method that it supports that it knows all FEs will support, simple indexxing is a very good way to meet that constrain. We could require that every table have a declared mandatory to support addressing mechanism. Which means that as LFB definitions are created we introduce the potential to further complicate both FEs and CEs. WIthout adding much advantage. Note that even CAMs actually have an internal index, and that the index is actual usable, knowable, and sometimes necessary. So I am unpersuaded that there is any case where the CE can not easily have enough information to use indices, or where it is a major difficulty for the FE to use indices. As long as the content addressing was simple, I am willing to recognize the groups desire to have the mechanism even if I am not persuaded of the value. However, arbitrary keying, selected by the CE at run time simply does not seem to me to meet this. There is no reason to turn the FE into a search engine. Much less one that can return multiple matches on arbitrary fields. Yours, Joel M. Halpern >Joel, Robert, and Jamal, > >Firstly, Jamal, I appreciate your efforts, but just could you give me a little >bit more time for more discussions on the fundamentals, before we can >perfectly >settle the PDU? > > >From Joel's original proposal on Index and Robert's comments as below, I > think >the key goes to the state as "if an CE can maintain a copy of any tables in >FE?". I confess that CE can do this well for routing tables in FE, but I just >worry about some other tables that FE may actually change the contents of the >tables. I can think of these tables as some tables for capabilities, for >statistics, and even for some events. Obviously, CE will not be able to have a >copy in advance before querying them. This also leads to the difficulties for >the use the idea index for them. Therefore, my compromise is, even if we >choose INDEX, it should not be a MUST for all kinds of tables. > >For content-based searching, I have to say again that, when we observe it from >the mechanical point of view, index is also a kind of content searching, that >is, the content is the index(note we will never expect a sequential index). >Therefore, I don't think it makes sense much to discuss if an FE need a >content >searching mechanism or not, instead, we may just need to discuss in which >dgree >FE should support such search. > >When we have the thought that not all tables are always applicable with Index, >I'm afraid to include content-based searching expression in the protocol is >unavoidable, unless we assume and make a provisioning that it is only >allowed to >access a whole table, instead of entries in the table. > >Yours, >Weiming > >----- Original Message ----- >From: "Robert Haas" >To: >Sent: Tuesday, January 11, 2005 10:04 PM >Subject: Re: [issue6] Summary of Path > > > > Weiming, all, > > > > Wang,Weiming wrote (excerpt): > > > > >Thinking we have an LFB with following attribute: > > > > > >Foo3, type structure, ID=5 > > >{ > > > s1, type u32, ID=1 > > > s2, type structure, ID=2 > > > { > > > g1, type u32, ID=1 > > > g2, type u32, ID=2 > > > g3, tyep u32, ID=3 > > > } > > > } > > > > > >With mainpath and subpath, I think the format should be like: > > >Mainpath(Foo3) subpath( s1) value subpath(s2.g1) value subpath(s2.g2) > value > > > > > >I actually talked about this before with Joel. I think Joel asked that in >this > > >case, he would rather use three separate path-data to do so, that is, > > > > > >path(Foo3.s1) value > > >path(Foo3.s2.g1) value > > >path(Foo3.s2.g2) value > > > > > >If the above path-values are in one OpTLV, I can more or less live > with it, >but > > >still think the mainpath and subpath mode is better than this. I supposed >Joel > > >asked the path-values be in different OpTLVs, which I'm hard to accept. I >think > > >such operation is originally atomic, to separate them into different > OpTLVs >is > > >not reasonable enough. > > > > > >Want to hear what others think about it. > > > > > > > > > > > I find the three separate path-data simpler and clearer. Such path-data > > can be aggregated under the same OpTLV, or they can be in separate > > OpTLVs. The protocol should support both cases. > > > > >>At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: > > >> > > >> > > >>>Heres a basic first attempt at BNF that would satisfy what you are > > >>>asking for: > > >>> > > >>>OPER_TLV : = > > >>>PATH-DATA := [DATAINFO] > > >>>PATH := flags IDcount > > >>>DATAINFO:= [SUBPATH] [DATARAW] > > >>>SUBPATH := <[KEYINFO]+ | [BLKINFO]| [INDINFO]> > > >>>DATARAW := somedata [DATAINFO] > > >>> > > >>> > > > > > > > > > > > I'd like some description of KEYINFO. Or better, an example of how this > > actually looks like for a content-based search key in a simple array. I > > am worried the devil is again in the details. > > > > Regarding the need to support content-based search at all: Joel rightly > > expressed concern about too much sophistication. I also think most of > > the management operations should be handled at the CE, except in the > > case of obvious protocol-efficiency gains. > > > > For instance, the CE is able to convert a content-based access into one > > (or more) index-based access(es), as the CE is supposed to keep track of > > what the FE stores. But block operations should not be split into a > > sequence of operations by the CE, even though the CE is very well able > > to do it too. > > > > Index-based accesses are the lowest-common denominator, and > > content-based accesses are an option that each LFB may or may not > > support, with arbitrary or pre-specified keys (or even key > > combinations). Requiring SQL-engine-like capability in an FE would kill > > the spec, I think. > > > > Note that even though the FE must have a (hopefully efficient) > > implementation to retrieve/set an entry from/into its data structs based > > on (ForCES) index, it does not mean at all that the FE uses an indexed > > array for the data struct used for datapath lookup. Probably this was > > obvious to everyone here. > > > > Regards, > > -Robert > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 18 16:41:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10341 for ; Tue, 18 Jan 2005 16:41:47 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr1Ld-0006IV-5f for forces-archive@IETF.ORG; Tue, 18 Jan 2005 16:57:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F4DA79@cherry.ease.lsoft.com>; Tue, 18 Jan 2005 16:41:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 53988304 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 18 Jan 2005 16:40:28 -0500 Approved-By: ellen.m.deleganes@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 18 Jan 2005 16:39:26 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0ILdPBx018796 for ; Tue, 18 Jan 2005 21:39:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0ILdO4a006863 for ; Tue, 18 Jan 2005 21:39:25 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011813392502873 for ; Tue, 18 Jan 2005 13:39:25 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 13:39:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4FDA6.2DACDE48" X-MS-Has-Attach: yes Thread-Topic: latest update of the model draft Thread-Index: AcT9hSDYJHBbzBofQKeOEaLwALwOiAAIPuBQ X-OriginalArrivalTime: 18 Jan 2005 21:39:25.0203 (UTC) FILETIME=[2E0A1E30:01C4FDA6] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03F0F09B@orsmsx408> Date: Tue, 18 Jan 2005 13:41:02 -0800 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: FW: latest update of the model draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.0 (+) X-Scan-Signature: 30c45940341dfca873ffed8b7c76dde9 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FDA6.2DACDE48 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4FDA6.2DACDE48" ------_=_NextPart_002_01C4FDA6.2DACDE48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops - I sent this to the wrong list. I meant to send it to the overall ForCES list. Sorry for the duplication for those of you on the protocol list. I will try to generate a diff file with the previous version to send out. =20 Regards, Ellen =20 ________________________________ From: Deleganes, Ellen M=20 Sent: Tuesday, January 18, 2005 9:43 AM To: 'forces-protocol@ietf.org' Subject: latest update of the model draft =20 This is the latest version of the model draft. The most significant change was to pull out the class definitions section from this draft and update the references through the rest of the document. Other minor editorial changes have also been made. =20 The major open issue is the need to update the FE and LFB attribute XML based on the discussions that have been going on in the reflector as these have to reflect the class definitions. There are a number of editorial comments throughout these sections that need to be resolved as the major rework is being done. These were captured in an earlier email. =20 Regards, Ellen ------_=_NextPart_002_01C4FDA6.2DACDE48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oops = – I sent this to the wrong list. I meant to send it to the overall ForCES list. = Sorry for the duplication for those of you on the protocol list. I will try to generate a diff file with the previous version to send = out.

 

Regards,

Ellen

 

From: = Deleganes, Ellen M
Sent: Tuesday, January = 18, 2005 9:43 AM
To: = 'forces-protocol@ietf.org'
Subject: latest update of = the model draft

 

This is the latest version of the = model draft. The most significant change was to pull out the class definitions section from this draft and update the references through the rest of = the document. Other minor editorial changes have also been = made.

 

The major open issue is the need to = update the FE and LFB attribute XML based on the discussions that have been = going on in the reflector as these have to reflect the class definitions. There = are a number of editorial comments throughout these sections that need to be = resolved as the major rework is being done. These were captured in an earlier = email.

 

Regards,

Ellen

------_=_NextPart_002_01C4FDA6.2DACDE48-- ------_=_NextPart_001_01C4FDA6.2DACDE48 Content-Type: text/plain; name="draft-ietf-forces-model-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-forces-model-04.txt Content-Disposition: attachment; filename="draft-ietf-forces-model-04.txt" Content-Transfer-Encoding: base64 DQogICAgICAgDQogICAgICAgDQogICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBMLiBZYW5nIA0KICAgICAgRXhwaXJhdGlvbjogQXVndXN0IDIwMDVJbnRl bCBDb3JwLiANCiAgICAgIEZpbGU6IGRyYWZ0LWlldGYtZm9yY2VzLW1vZGVsLTA0LnR4dCAgICAg ICAgIEouIEhhbHBlcm4gDQogICAgICBXb3JraW5nIEdyb3VwOiBGb3JDRVMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1lZ2lzdG8gU3lzdGVtcw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gR29wYWwgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5va2lhIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gRGVLb2sgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElEVCBJbmMu IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWi4g SGFyYXN6dGkgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTLiBCbGFrZSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRXJpY3Nzb24gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBFLiBEZWxlZ2FuZXMgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnAuIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIEZvckNFUyBGb3J3YXJkaW5nIEVsZW1lbnQg TW9kZWwgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLWZvcmNlcy1tb2RlbC0wNC50eHQgDQogICAgICAgDQogICAgICAgDQogICAg ICAgDQogICAgICAgDQogICAgICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgICAgIA0KICAgICAg VGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIA0KICAgICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2 LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSANCiAgICAgIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgDQogICAgICBpdHMgYXJlYXMs IGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSANCiAg ICAgIGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu IA0KICAgICAgIA0KICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDQogICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KICAgICAgZG9jdW1lbnRzIGF0IGFu eSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIA0KICAg ICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzIGBg d29yayBpbiANCiAgICAgIHByb2dyZXNzLicnIA0KICAgICAgIA0KICAgICAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCiAgICAgICANCiAgICAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQgIA0KICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAgICAg DQogICBBYnN0cmFjdCANCiAgICAgICANCiAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUg Zm9yd2FyZGluZyBlbGVtZW50IChGRSkgbW9kZWwgdXNlZCBpbiANCiAgICAgIHRoZSBGb3J3YXJk aW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAoRm9yQ0VTKSBwcm90b2NvbC4gIA0K ICAgICAgVGhlIG1vZGVsIHJlcHJlc2VudHMgdGhlIGNhcGFiaWxpdGllcywgc3RhdGUgYW5kIGNv bmZpZ3VyYXRpb24gb2YgDQogICAgDQogICAgDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAg ICAgZm9yd2FyZGluZyBlbGVtZW50cyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIEZvckNFUyBw cm90b2NvbCwgc28gDQogICAgICB0aGF0IGNvbnRyb2wgZWxlbWVudHMgKENFcykgY2FuIGNvbnRy b2wgdGhlIEZFcyBhY2NvcmRpbmdseS4gIE1vcmUgDQogICAgICBzcGVjaWZpY2FsbHksIHRoZSBt b2RlbCBkZXNjcmliZXMgdGhlIGxvZ2ljYWwgZnVuY3Rpb25zIHRoYXQgYXJlIA0KICAgICAgcHJl c2VudCBpbiBhbiBGRSwgd2hhdCBjYXBhYmlsaXRpZXMgdGhlc2UgZnVuY3Rpb25zIHN1cHBvcnQs IGFuZCANCiAgICAgIGhvdyB0aGVzZSBmdW5jdGlvbnMgYXJlIG9yIGNhbiBiZSBpbnRlcmNvbm5l Y3RlZC4gIFRoaXMgRkUgbW9kZWwgDQogICAgICBpcyBpbnRlbmRlZCB0byBzYXRpc2Z5IHRoZSBt b2RlbCByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGluIHRoZSANCiAgICAgIEZvckNFUyByZXF1aXJl bWVudHMgZHJhZnQsIFJGQyAzNTY0IFsxXS4gIEEgbGlzdCBvZiB0aGUgYmFzaWMgDQogICAgICBs b2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tzIChMRkJzKSBpcyBhbHNvIGRlZmluZWQgaW4gdGhlIExG QiBjbGFzcyANCiAgICAgIGxpYnJhcnkgdG8gYWlkIHRoZSBlZmZvcnQgaW4gZGVmaW5pbmcgaW5k aXZpZHVhbCBMRkJzLiAgDQogICAgICAgDQogICBUYWJsZSBvZiBDb250ZW50cyAgDQogICAgDQog ICAgICBBYnN0cmFjdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMSANCiAgICAgIDEuIERlZmluaXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgICAgMi4gSW50cm9kdWN0 aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUg DQogICAgICAgICAyLjEuIFJlcXVpcmVtZW50cyBvbiB0aGUgRkUgbW9kZWwuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgICAgICAgIDIuMi4gVGhlIEZFIE1vZGVsIGluIFJlbGF0 aW9uIHRvIEZFIEltcGxlbWVudGF0aW9ucy4uLi4uLi4uLi4uLi42IA0KICAgICAgICAgMi4zLiBU aGUgRkUgTW9kZWwgaW4gUmVsYXRpb24gdG8gdGhlIEZvckNFUyBQcm90b2NvbC4uLi4uLi4uLi4u LjcgDQogICAgICAgICAyLjQuIE1vZGVsaW5nIExhbmd1YWdlIGZvciB0aGUgRkUgTW9kZWwuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgICAgICAgIDIuNS4gRG9jdW1lbnQgU3RydWN0dXJl Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgICAgMy4gRkUg TW9kZWwgQ29uY2VwdHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjggDQogICAgICAgICAzLjEuIEZFIENhcGFiaWxpdHkgTW9kZWwgYW5kIFN0YXRlIE1vZGVs Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgICAgICAgIDMuMi4gTEZCIChMb2dpY2FsIEZ1 bmN0aW9uYWwgQmxvY2spIE1vZGVsaW5nLi4uLi4uLi4uLi4uLi4uLi4uLjExIA0KICAgICAgICAg ICAgMy4yLjEuIExGQiBPdXRwdXRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTMgDQogICAgICAgICAgICAzLjIuMi4gTEZCIElucHV0cy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNiANCiAgICAgICAgICAgIDMuMi4zLiBQYWNrZXQg VHlwZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5IA0KICAgICAg ICAgICAgMy4yLjQuIE1ldGFkYXRhLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMjAgDQogICAgICAgICAgICAzLjIuNS4gTEZCIFZlcnNpb25pbmcuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNyANCiAgICAgICAgICAgIDMuMi42LiBMRkIg SW5oZXJpdGFuY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI3IA0KICAg ICAgICAgMy4zLiBGRSBEYXRhcGF0aCBNb2RlbGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjggDQogICAgICAgICAgICAzLjMuMS4gQWx0ZXJuYXRpdmUgQXBwcm9hY2hl cyBmb3IgTW9kZWxpbmcgRkUgRGF0YXBhdGhzLi4uLi4yOCANCiAgICAgICAgICAgIDMuMy4yLiBD b25maWd1cmluZyB0aGUgTEZCIFRvcG9sb2d5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMzIA0K ICAgICAgNC4gTW9kZWwgYW5kIFNjaGVtYSBmb3IgTEZCIENsYXNzZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMzcgDQogICAgICAgICA0LjEuIE5hbWVzcGFjZS4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zNyANCiAgICAgICAgIDQuMi4gPExG QkxpYnJhcnk+IEVsZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjM3 IA0KICAgICAgICAgNC4zLiA8bG9hZD4gRWxlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMzkgDQogICAgICAgICA0LjQuIDxmcmFtZURlZnM+IEVsZW1lbnQg Zm9yIEZyYW1lIFR5cGUgRGVjbGFyYXRpb25zLi4uLi4uLi4uLi4zOSANCiAgICAgICAgIDQuNS4g PGRhdGFUeXBlRGVmcz4gRWxlbWVudCBmb3IgRGF0YSBUeXBlIERlZmluaXRpb25zLi4uLi4uLi4u LjQwIA0KICAgICAgICAgICAgNC41LjEuIDx0eXBlUmVmPiBFbGVtZW50IGZvciBBbGlhc2luZyBF eGlzdGluZyBEYXRhIFR5cGVzLi4uNDIgDQogICAgICAgICAgICA0LjUuMi4gPGF0b21pYz4gRWxl bWVudCBmb3IgRGVyaXZpbmcgTmV3IEF0b21pYyBUeXBlcy4uLi4uLi40MyANCiAgICAgICAgICAg IDQuNS4zLiA8YXJyYXk+IEVsZW1lbnQgdG8gRGVmaW5lIEFycmF5cy4uLi4uLi4uLi4uLi4uLi4u Li4uLjQzIA0KICAgICAgICAgICAgNC41LjQuIDxzdHJ1Y3Q+IEVsZW1lbnQgdG8gRGVmaW5lIFN0 cnVjdHVyZXMuLi4uLi4uLi4uLi4uLi4uNDUgDQogICAgICAgICAgICA0LjUuNS4gPHVuaW9uPiBF bGVtZW50IHRvIERlZmluZSBVbmlvbiBUeXBlcy4uLi4uLi4uLi4uLi4uLi40NiANCiAgICAgICAg ICAgIDQuNS42LiBBdWdtZW50YXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQ2IA0KICAgICAgICAgNC42LiA8bWV0YWRhdGFEZWZzPiBFbGVtZW50IGZvciBNZXRh ZGF0YSBEZWZpbml0aW9ucy4uLi4uLi4uLi4uNDcgDQogICAgICAgICA0LjcuIDxMRkJDbGFzc0Rl ZnM+IEVsZW1lbnQgZm9yIExGQiBDbGFzcyBEZWZpbml0aW9ucy4uLi4uLi4uLi40OCANCiAgICAg ICAgICAgIDQuNy4xLiA8ZGVyaXZlZEZyb20+IEVsZW1lbnQgdG8gRXhwcmVzcyBMRkIgSW5oZXJp dGFuY2UuLi4uLjQ5IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICAgICAgICA0LjcuMi4gPGlucHV0UG9ydHM+IEVsZW1lbnQgdG8gRGVmaW5l IExGQiBJbnB1dHMuLi4uLi4uLi4uLi40OSANCiAgICAgICAgICAgIDQuNy4zLiA8b3V0cHV0UG9y dHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBPdXRwdXRzLi4uLi4uLi4uLjUyIA0KICAgICAgICAg ICAgNC43LjQuIDxhdHRyaWJ1dGVzPiBFbGVtZW50IHRvIERlZmluZSBMRkIgT3BlcmF0aW9uYWwg DQogICAgICAgICAgICBBdHRyaWJ1dGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi41NCANCiAgICAgICAgICAgIDQuNy41LiA8Y2FwYWJpbGl0aWVzPiBF bGVtZW50IHRvIERlZmluZSBMRkIgQ2FwYWJpbGl0eSANCiAgICAgICAgICAgIEF0dHJpYnV0ZXMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjU3IA0KICAg ICAgICAgICAgNC43LjYuIDxkZXNjcmlwdGlvbj4gRWxlbWVudCBmb3IgTEZCIE9wZXJhdGlvbmFs IA0KICAgICAgICAgICAgU3BlY2lmaWNhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNTggDQogICAgICAgICA0LjguIFhNTCBTY2hlbWEgZm9yIExGQiBD bGFzcyBMaWJyYXJ5IERvY3VtZW50cy4uLi4uLi4uLi4uLi4uLi41OCANCiAgICAgIDUuIEZFIEF0 dHJpYnV0ZXMgYW5kIENhcGFiaWxpdGllcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjY3IA0KICAgICAgICAgNS4xLiBYTUwgU2NoZW1hIGZvciBGRSBBdHRyaWJ1dGUgRG9jdW1lbnRz Li4uLi4uLi4uLi4uLi4uLi4uLi4uNjggDQogICAgICAgICA1LjIuIEZFRG9jdW1lbnQuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43MiANCiAgICAgICAgICAg IDUuMi4xLiBGRUNhcGFiaWxpdGllcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjcyIA0KICAgICAgICAgICAgNS4yLjIuIEZFQXR0cmlidXRlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNzUgDQogICAgICAgICA1LjMuIFNhbXBsZSBGRSBBdHRy aWJ1dGUgRG9jdW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43OCANCiAgICAgIDYu IFNhdGlzZnlpbmcgdGhlIFJlcXVpcmVtZW50cyBvbiBGRSBNb2RlbC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjgwIA0KICAgICAgICAgNi4xLiBQb3J0IEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uODEgDQogICAgICAgICA2LjIuIEZvcndhcmRpbmcg RnVuY3Rpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44MSANCiAgICAg ICAgIDYuMy4gUW9TIEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjgxIA0KICAgICAgICAgNi40LiBHZW5lcmljIEZpbHRlcmluZyBGdW5jdGlvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uODIgDQogICAgICAgICA2LjUuIFZlbmRvciBT cGVjaWZpYyBGdW5jdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44MiANCiAg ICAgICAgIDYuNi4gSGlnaC1Ub3VjaCBGdW5jdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjgyIA0KICAgICAgICAgNi43LiBTZWN1cml0eSBGdW5jdGlvbnMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uODIgDQogICAgICAgICA2LjguIE9mZi1s b2FkZWQgRnVuY3Rpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44MiAN CiAgICAgICAgIDYuOS4gSVBGTE9XL1BTQU1QIEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjgzIA0KICAgICAgNy4gVXNpbmcgdGhlIEZFIG1vZGVsIGluIHRoZSBG b3JDRVMgUHJvdG9jb2wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uODMgDQogICAgICAgICA3LjEuIEZF IFRvcG9sb2d5IFF1ZXJ5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44 NSANCiAgICAgICAgIDcuMi4gRkUgQ2FwYWJpbGl0eSBEZWNsYXJhdGlvbnMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjg2IA0KICAgICAgICAgNy4zLiBMRkIgVG9wb2xvZ3kgYW5kIFRv cG9sb2d5IENvbmZpZ3VyYWJpbGl0eSBRdWVyeS4uLi4uLi4uLi4uODYgDQogICAgICAgICA3LjQu IExGQiBDYXBhYmlsaXR5IERlY2xhcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li44NyANCiAgICAgICAgIDcuNS4gU3RhdGUgUXVlcnkgb2YgTEZCIEF0dHJpYnV0ZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjg4IA0KICAgICAgICAgNy42LiBMRkIgQXR0cmlidXRlIE1h bmlwdWxhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uODggDQogICAgICAgICA3 LjcuIExGQiBUb3BvbG9neSBSZS1jb25maWd1cmF0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi44OSANCiAgICAgIDguIEFja25vd2xlZGdtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg5IA0KICAgICAgOS4gU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uODkgDQogICAgICAx MC4gTm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi44OSANCiAgICAgIDExLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkwIA0KICAgICAgMTIuIEF1dGhvcnMnIEFkZHJl c3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOTEgDQogICAg ICAxMy4gSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi45MiANCiAgICAgIDE0LiBJQU5BIGNvbnNpZGVyYXRpb24uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkyIA0KICAgICAgIA0KICAgQ29udmVudGlv bnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50ICANCiAgICAgICAgICAgDQogICAgICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIA0KICAg ICAgTk9UIiwgDQogICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gDQogICAgICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQy0yMTE5XS4gDQogICAgDQogICBZYW5nLCBl dCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDNdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAg ICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgICANCiAgIDEu IA0gICAgIERlZmluaXRpb25zIA0KICAgICAgIA0KICAgICAgVGVybWlub2xvZ3kgYXNzb2NpYXRl ZCB3aXRoIHRoZSBGb3JDRVMgcmVxdWlyZW1lbnRzIGlzIGRlZmluZWQgaW4gDQogICAgICBSRkMg MzU2NCBbMV0gYW5kIGlzIG5vdCBjb3BpZWQgaGVyZS4gIFRoZSBmb2xsb3dpbmcgbGlzdCBvZiAN CiAgICAgIHRlcm1pbm9sb2d5IHJlbGV2YW50IHRvIHRoZSBGRSBtb2RlbCBpcyBkZWZpbmVkIGlu IHRoaXMgc2VjdGlvbi4gDQogICAgDQogICAgICBGRSBNb2RlbCAtLSBUaGUgRkUgbW9kZWwgaXMg ZGVzaWduZWQgdG8gbW9kZWwgdGhlIGxvZ2ljYWwgDQogICAgICBwcm9jZXNzaW5nIGZ1bmN0aW9u cyBvZiBhbiBGRS4gIFRoZSBGRSBtb2RlbCBwcm9wb3NlZCBpbiB0aGlzIA0KICAgICAgZG9jdW1l bnQgaW5jbHVkZXMgdGhyZWUgY29tcG9uZW50czogdGhlIG1vZGVsaW5nIG9mIGluZGl2aWR1YWwg DQogICAgICBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tzIChMRkIgbW9kZWwpLCB0aGUgbG9naWNh bCBpbnRlcmNvbm5lY3Rpb24gDQogICAgICBiZXR3ZWVuIExGQnMgKExGQiB0b3BvbG9neSkgYW5k IHRoZSBGRSBsZXZlbCBhdHRyaWJ1dGVzLCBpbmNsdWRpbmcgDQogICAgICBGRSBjYXBhYmlsaXRp ZXMuICBUaGUgRkUgbW9kZWwgcHJvdmlkZXMgdGhlIGJhc2lzIHRvIGRlZmluZSB0aGUgDQogICAg ICBpbmZvcm1hdGlvbiBlbGVtZW50cyBleGNoYW5nZWQgYmV0d2VlbiB0aGUgQ0UgYW5kIHRoZSBG RSBpbiB0aGUgDQogICAgICBGb3JDRVMgcHJvdG9jb2wuICANCiAgICAgICANCiAgICAgIERhdGFw YXRoIC0tIEEgY29uY2VwdHVhbCBwYXRoIHRha2VuIGJ5IHBhY2tldHMgd2l0aGluIHRoZSANCiAg ICAgIGZvcndhcmRpbmcgcGxhbmUgaW5zaWRlIGFuIEZFLiAgTm90ZSB0aGF0IG1vcmUgdGhhbiBv bmUgZGF0YXBhdGggDQogICAgICBjYW4gZXhpc3Qgd2l0aGluIGFuIEZFLiANCiAgICAgICANCiAg ICAgIExGQiAoTG9naWNhbCBGdW5jdGlvbmFsIEJsb2NrKSBDbGFzcyAob3IgdHlwZSkgLS0gQSB0 ZW1wbGF0ZSANCiAgICAgIHJlcHJlc2VudGluZyBhIGZpbmUtZ3JhaW5lZCwgbG9naWNhbGx5IHNl cGFyYWJsZSBhbmQgd2VsbC1kZWZpbmVkIA0KICAgICAgcGFja2V0IHByb2Nlc3Npbmcgb3BlcmF0 aW9uIGluIHRoZSBkYXRhcGF0aC4gIExGQiBjbGFzc2VzIGFyZSB0aGUgDQogICAgICBiYXNpYyBi dWlsZGluZyBibG9ja3Mgb2YgdGhlIEZFIG1vZGVsLiANCiAgICAgICANCiAgICAgIExGQiBJbnN0 YW5jZSAtLSBBcyBhIHBhY2tldCBmbG93cyB0aHJvdWdoIGFuIEZFIGFsb25nIGEgZGF0YXBhdGgs IA0KICAgICAgaXQgZmxvd3MgdGhyb3VnaCBvbmUgb3IgbXVsdGlwbGUgTEZCIGluc3RhbmNlcywg d2hlcmUgZWFjaCBMRkIgaXMgDQogICAgICBhbiBpbnN0YW5jZSBvZiBhIHNwZWNpZmljIExGQiBj bGFzcy4gIE11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgDQogICAgICBzYW1lIExGQiBjbGFzcyBj YW4gYmUgcHJlc2VudCBpbiBhbiBGRSdzIGRhdGFwYXRoLiAgTm90ZSB0aGF0IHdlIA0KICAgICAg b2Z0ZW4gcmVmZXIgdG8gTEZCcyB3aXRob3V0IGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gYW4gTEZC IGNsYXNzIA0KICAgICAgYW5kIExGQiBpbnN0YW5jZSB3aGVuIHdlIGJlbGlldmUgdGhlIGltcGxp ZWQgcmVmZXJlbmNlIGlzIG9idmlvdXMgDQogICAgICBmb3IgdGhlIGdpdmVuIGNvbnRleHQuIA0K ICAgICAgIA0KICAgICAgTEZCIE1vZGVsIC0tIFRoZSBMRkIgbW9kZWwgZGVzY3JpYmVzIHRoZSBj b250ZW50IGFuZCBzdHJ1Y3R1cmVzIGluIA0KICAgICAgYW4gTEZCLCBwbHVzIHRoZSBhc3NvY2lh dGVkIGRhdGEgZGVmaW5pdGlvbi4gIEZvdXIgdHlwZXMgb2YgDQogICAgICBpbmZvcm1hdGlvbiBh cmUgZGVmaW5lZCBpbiB0aGUgTEZCIG1vZGVsLiAgVGhlIGNvcmUgcGFydCBvZiB0aGUgDQogICAg ICBMRkIgbW9kZWwgaXMgdGhlIExGQiBjbGFzcyBkZWZpbml0aW9uczsgdGhlIG90aGVyIHRocmVl IHR5cGVzIA0KICAgICAgZGVmaW5lIHRoZSBhc3NvY2lhdGVkIGRhdGEgaW5jbHVkaW5nIGNvbW1v biBkYXRhIHR5cGVzLCBzdXBwb3J0ZWQgDQogICAgICBmcmFtZSBmb3JtYXRzIGFuZCBtZXRhZGF0 YS4gDQogICAgICAgDQogICAgICBMRkIgTWV0YWRhdGEgLS0gTWV0YWRhdGEgaXMgdXNlZCB0byBj b21tdW5pY2F0ZSBwZXItcGFja2V0IHN0YXRlIA0KICAgICAgZnJvbSBvbmUgTEZCIHRvIGFub3Ro ZXIsIGJ1dCBpcyBub3Qgc2VudCBhY3Jvc3MgdGhlIG5ldHdvcmsuICBUaGUgDQogICAgICBGRSBt b2RlbCBkZWZpbmVzIGhvdyBzdWNoIG1ldGFkYXRhIGlzIGlkZW50aWZpZWQsIHByb2R1Y2VkIGFu ZCANCiAgICAgIGNvbnN1bWVkIGJ5IHRoZSBMRkJzLCBidXQgbm90IGhvdyB0aGUgcGVyLXBhY2tl dCBzdGF0ZSBpcyANCiAgICAgIGltcGxlbWVudGVkIHdpdGhpbiBhY3R1YWwgaGFyZHdhcmUuIA0K ICAgICAgIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA0XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAg DQogICAgICBMRkIgQXR0cmlidXRlIC0tIE9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgb2YgdGhlIExG QnMgdGhhdCBtdXN0IGJlIA0KICAgICAgdmlzaWJsZSB0byB0aGUgQ0VzIGFyZSBjb25jZXB0dWFs aXplZCBpbiB0aGUgRkUgbW9kZWwgYXMgdGhlIExGQiANCiAgICAgIGF0dHJpYnV0ZXMuICBUaGUg TEZCIGF0dHJpYnV0ZXMgaW5jbHVkZTogZmxhZ3MsIHNpbmdsZSBwYXJhbWV0ZXIgDQogICAgICBh cmd1bWVudHMsIGNvbXBsZXggYXJndW1lbnRzLCBhbmQgdGFibGVzIHRoYXQgdGhlIENFIGNhbiBy ZWFkIA0KICAgICAgb3IvYW5kIHdyaXRlIHZpYSB0aGUgRm9yQ0VTIHByb3RvY29sLiANCiAgICAg ICANCiAgICAgIExGQiBUb3BvbG9neSAtLSBBIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBsb2dpY2Fs IGludGVyY29ubmVjdGlvbiANCiAgICAgIGFuZCB0aGUgcGxhY2VtZW50IG9mIExGQiBpbnN0YW5j ZXMgYWxvbmcgdGhlIGRhdGFwYXRoIHdpdGhpbiBvbmUgDQogICAgICBGRS4gIFNvbWV0aW1lcyB0 aGlzIHJlcHJlc2VudGF0aW9uIGlzIGNhbGxlZCBpbnRyYS1GRSB0b3BvbG9neSwgdG8gDQogICAg ICBiZSBkaXN0aW5ndWlzaGVkIGZyb20gaW50ZXItRkUgdG9wb2xvZ3kuICBMRkIgdG9wb2xvZ3kg aXMgb3V0c2lkZSANCiAgICAgIG9mIHRoZSBMRkIgbW9kZWwsIGJ1dCBpcyBwYXJ0IG9mIHRoZSBG RSBtb2RlbC4gDQogICAgICAgDQogICAgICBGRSBUb3BvbG9neSAtLSBBIHJlcHJlc2VudGF0aW9u IG9mIGhvdyBtdWx0aXBsZSBGRXMgd2l0aGluIGEgDQogICAgICBzaW5nbGUgTkUgYXJlIGludGVy Y29ubmVjdGVkLiAgU29tZXRpbWVzIHRoaXMgaXMgY2FsbGVkIGludGVyLUZFIA0KICAgICAgdG9w b2xvZ3ksIHRvIGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSBpbnRyYS1GRSB0b3BvbG9neSAoaS5lLiwg TEZCIA0KICAgICAgdG9wb2xvZ3kpLiAgQW4gaW5kaXZpZHVhbCBGRSBtaWdodCBub3QgaGF2ZSB0 aGUgZ2xvYmFsIGtub3dsZWRnZSANCiAgICAgIG9mIHRoZSBmdWxsIEZFIHRvcG9sb2d5LCBidXQg dGhlIGxvY2FsIHZpZXcgb2YgaXRzIGNvbm5lY3Rpdml0eSANCiAgICAgIHdpdGggb3RoZXIgRkVz IGlzIGNvbnNpZGVyZWQgdG8gYmUgcGFydCBvZiB0aGUgRkUgbW9kZWwuICBUaGUgRkUgDQogICAg ICB0b3BvbG9neSBpcyBkaXNjb3ZlcmVkIGJ5IHRoZSBGb3JDRVMgYmFzZSBwcm90b2NvbCBvciBi eSBzb21lIA0KICAgICAgb3RoZXIgbWVhbnMuIA0KICAgICAgIA0KICAgICAgSW50ZXItRkUgVG9w b2xvZ3kgLS0gU2VlIEZFIFRvcG9sb2d5LiANCiAgICAgICANCiAgICAgIEludHJhLUZFIFRvcG9s b2d5IC0tIFNlZSBMRkIgVG9wb2xvZ3kuICANCiAgICAgICANCiAgICAgIExGQiBjbGFzcyBsaWJy YXJ5IC0tIEEgc2V0IG9mIExGQiBjbGFzc2VzIHRoYXQgaGFzIGJlZW4gaWRlbnRpZmllZCANCiAg ICAgIGFzIHRoZSBtb3N0IGNvbW1vbiBmdW5jdGlvbnMgZm91bmQgaW4gbW9zdCBGRXMgYW5kIGhl bmNlIHNob3VsZCBiZSANCiAgICAgIGRlZmluZWQgZmlyc3QgYnkgdGhlIEZvckNFUyBXb3JraW5n IEdyb3VwLiAgDQogICAgICAgDQogICAyLiANICAgICBJbnRyb2R1Y3Rpb24gDQogICAgDQogICAg ICBSRkMgMzc0NiBbMl0gc3BlY2lmaWVzIGEgZnJhbWV3b3JrIGJ5IHdoaWNoIGNvbnRyb2wgZWxl bWVudHMgKENFcykgDQogICAgICBjYW4gY29uZmlndXJlIGFuZCBtYW5hZ2Ugb25lIG9yIG1vcmUg c2VwYXJhdGUgZm9yd2FyZGluZyBlbGVtZW50cyANCiAgICAgIChGRXMpIHdpdGhpbiBhIG5ldHdv cmtpbmcgZWxlbWVudCAoTkUpIHVzaW5nIHRoZSBGb3JDRVMgcHJvdG9jb2wuICANCiAgICAgIFRo ZSBGb3JDRVMgYXJjaGl0ZWN0dXJlIGFsbG93cyBGb3J3YXJkaW5nIEVsZW1lbnRzIG9mIHZhcnlp bmcgDQogICAgICBmdW5jdGlvbmFsaXR5IHRvIHBhcnRpY2lwYXRlIGluIGEgRm9yQ0VTIG5ldHdv cmsgZWxlbWVudC4gIFRoZSANCiAgICAgIGltcGxpY2F0aW9uIG9mIHRoaXMgdmFyeWluZyBmdW5j dGlvbmFsaXR5IGlzIHRoYXQgQ0VzIGNhbiBtYWtlIA0KICAgICAgb25seSBtaW5pbWFsIGFzc3Vt cHRpb25zIGFib3V0IHRoZSBmdW5jdGlvbmFsaXR5IHByb3ZpZGVkIGJ5IEZFcyANCiAgICAgIGlu IGFuIE5FLiAgQmVmb3JlIENFcyBjYW4gY29uZmlndXJlIGFuZCBjb250cm9sIHRoZSBmb3J3YXJk aW5nIA0KICAgICAgYmVoYXZpb3Igb2YgRkVzLCBDRXMgbmVlZCB0byBxdWVyeSBhbmQgZGlzY292 ZXIgdGhlIGNhcGFiaWxpdGllcyANCiAgICAgIGFuZCBzdGF0ZXMgb2YgdGhlaXIgRkVzLiAgUkZD IDM2NTQgWzFdIG1hbmRhdGVzIHRoYXQgdGhlIA0KICAgICAgY2FwYWJpbGl0aWVzLCBzdGF0ZXMg YW5kIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYmUgZXhwcmVzc2VkIGluIA0KICAgICAgdGhl IGZvcm0gb2YgYW4gRkUgbW9kZWwuIA0KICAgICAgIA0KICAgICAgUkZDIDM0NDQgWzExXSBvYnNl cnZlZCB0aGF0IGluZm9ybWF0aW9uIG1vZGVscyAoSU1zKSBhbmQgZGF0YSANCiAgICAgIG1vZGVs cyAoRE1zKSBhcmUgZGlmZmVyZW50IGJlY2F1c2UgdGhleSBzZXJ2ZSBkaWZmZXJlbnQgcHVycG9z ZXMuICANCiAgICAgICJUaGUgbWFpbiBwdXJwb3NlIG9mIGFuIElNIGlzIHRvIG1vZGVsIG1hbmFn ZWQgb2JqZWN0cyBhdCBhIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICBjb25jZXB0dWFsIGxldmVsLCBpbmRlcGVuZGVudCBvZiBhbnkgc3Bl Y2lmaWMgaW1wbGVtZW50YXRpb25zIG9yIA0KICAgICAgcHJvdG9jb2xzIHVzZWQiLiAgIkRNcywg Y29udmVyc2VseSwgYXJlIGRlZmluZWQgYXQgYSBsb3dlciBsZXZlbCANCiAgICAgIG9mIGFic3Ry YWN0aW9uIGFuZCBpbmNsdWRlIG1hbnkgZGV0YWlscy4gIFRoZXkgYXJlIGludGVuZGVkIGZvciAN CiAgICAgIGltcGxlbWVudG9ycyBhbmQgaW5jbHVkZSBwcm90b2NvbC1zcGVjaWZpYyBjb25zdHJ1 Y3RzLiIgIFNvbWV0aW1lcyANCiAgICAgIGl0IGlzIGRpZmZpY3VsdCB0byBkcmF3IGEgY2xlYXIg bGluZSBiZXR3ZWVuIHRoZSB0d28uICBUaGUgRkUgDQogICAgICBtb2RlbCBkZXNjcmliZWQgaW4g dGhpcyBkb2N1bWVudCBpcyBwcmltYXJpbHkgYW4gaW5mb3JtYXRpb24gDQogICAgICBtb2RlbCwg YnV0IGFsc28gaW5jbHVkZXMgc29tZSBhc3BlY3RzIG9mIGEgZGF0YSBtb2RlbCwgc3VjaCBhcyAN CiAgICAgIGV4cGxpY2l0IGRlZmluaXRpb25zIG9mIHRoZSBMRkIgY2xhc3Mgc2NoZW1hIGFuZCBG RSBzY2hlbWEuICBJdCBpcyANCiAgICAgIGV4cGVjdGVkIHRoYXQgdGhpcyBGRSBtb2RlbCB3aWxs IGJlIHVzZWQgYXMgdGhlIGJhc2lzIHRvIGRlZmluZSANCiAgICAgIHRoZSBwYXlsb2FkIGZvciBp bmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHRoZSBDRSBhbmQgRkUgaW4gdGhlIA0KICAgICAg Rm9yQ0VTIHByb3RvY29sLiAgIA0KICAgICAgICAgICANCiAgIDIuMS4gUmVxdWlyZW1lbnRzIG9u IHRoZSBGRSBtb2RlbCANCiAgICAgICANCiAgICAgIFJGQyAzNjU0IFsxXSBkZWZpbmVzIHJlcXVp cmVtZW50cyB0aGF0IG11c3QgYmUgc2F0aXNmaWVkIGJ5IGEgDQogICAgICBGb3JDRVMgRkUgbW9k ZWwuICBUbyBzdW1tYXJpemUsIGFuIEZFIG1vZGVsIG11c3QgZGVmaW5lOiANCiAgICAgICAgLiBM b2dpY2FsbHkgc2VwYXJhYmxlIGFuZCBkaXN0aW5jdCBwYWNrZXQgZm9yd2FyZGluZyBvcGVyYXRp b25zIA0KICAgICAgICAgICBpbiBhbiBGRSBkYXRhcGF0aCAobG9naWNhbCBmdW5jdGlvbmFsIGJs b2NrcyBvciBMRkJzKTsgDQogICAgICAgIC4gVGhlIHBvc3NpYmxlIHRvcG9sb2dpY2FsIHJlbGF0 aW9uc2hpcHMgKGFuZCBoZW5jZSB0aGUgDQogICAgICAgICAgIHNlcXVlbmNlIG9mIHBhY2tldCBm b3J3YXJkaW5nIG9wZXJhdGlvbnMpIGJldHdlZW4gdGhlIHZhcmlvdXMgDQogICAgICAgICAgIExG QnM7IA0KICAgICAgICAuIFRoZSBwb3NzaWJsZSBvcGVyYXRpb25hbCBjYXBhYmlsaXRpZXMgKGUu Zy4sIGNhcGFjaXR5IGxpbWl0cywgDQogICAgICAgICAgIGNvbnN0cmFpbnRzLCBvcHRpb25hbCBm ZWF0dXJlcywgZ3JhbnVsYXJpdHkgb2YgY29uZmlndXJhdGlvbikgDQogICAgICAgICAgIG9mIGVh Y2ggdHlwZSBvZiBMRkI7IA0KICAgICAgICAuIFRoZSBwb3NzaWJsZSBjb25maWd1cmFibGUgcGFy YW1ldGVycyAoaS5lLiwgYXR0cmlidXRlcykgb2YgDQogICAgICAgICAgIGVhY2ggdHlwZSBvZiBM RkI7IA0KICAgICAgICAuIE1ldGFkYXRhIHRoYXQgbWF5IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIExG QnMuIA0KICAgICAgICANCiAgIDIuMi4gVGhlIEZFIE1vZGVsIGluIFJlbGF0aW9uIHRvIEZFIElt cGxlbWVudGF0aW9ucyANCiAgICAgICANCiAgICAgIFRoZSBGRSBtb2RlbCBwcm9wb3NlZCBoZXJl IGlzIGJhc2VkIG9uIGFuIGFic3RyYWN0aW9uIG9mIGRpc3RpbmN0IA0KICAgICAgbG9naWNhbCBm dW5jdGlvbmFsIGJsb2NrcyAoTEZCcyksIHdoaWNoIGFyZSBpbnRlcmNvbm5lY3RlZCBpbiBhIA0K ICAgICAgZGlyZWN0ZWQgZ3JhcGgsIGFuZCByZWNlaXZlLCBwcm9jZXNzLCBtb2RpZnksIGFuZCB0 cmFuc21pdCBwYWNrZXRzIA0KICAgICAgYWxvbmcgd2l0aCBtZXRhZGF0YS4gIFRoZSBGRSBtb2Rl bCBzaG91bGQgYmUgZGVzaWduZWQgc3VjaCB0aGF0IA0KICAgICAgZGlmZmVyZW50IGltcGxlbWVu dGF0aW9ucyBvZiB0aGUgZm9yd2FyZGluZyBkYXRhcGF0aCBjYW4gYmUgDQogICAgICBsb2dpY2Fs bHkgbWFwcGVkIG9udG8gdGhlIG1vZGVsIHdpdGggdGhlIGZ1bmN0aW9uYWxpdHkgYW5kIA0KICAg ICAgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyBjb3JyZWN0bHkgY2FwdHVyZWQuICBIb3dldmVyLCB0 aGUgbW9kZWwgaXMgDQogICAgICBub3QgaW50ZW5kZWQgdG8gZGlyZWN0bHkgYWRkcmVzcyBob3cg YSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIA0KICAgICAgbWFwcyB0byBhbiBMRkIgdG9wb2xv Z3kuICBJdCBpcyBsZWZ0IHRvIHRoZSBmb3J3YXJkaW5nIHBsYW5lIA0KICAgICAgdmVuZG9ycyB0 byBkZWZpbmUgaG93IHRoZSBGRSBmdW5jdGlvbmFsaXR5IGlzIHJlcHJlc2VudGVkIHVzaW5nIA0K ICAgICAgdGhlIEZFIG1vZGVsLiAgIE91ciBnb2FsIGlzIHRvIGRlc2lnbiB0aGUgRkUgbW9kZWwg c3VjaCB0aGF0IGl0IGlzIA0KICAgICAgZmxleGlibGUgZW5vdWdoIHRvIGFjY29tbW9kYXRlIG1v c3QgY29tbW9uIGltcGxlbWVudGF0aW9ucy4gIA0KICAgICAgIA0KICAgICAgVGhlIExGQiB0b3Bv bG9neSBtb2RlbCBmb3IgYSBwYXJ0aWN1bGFyIGRhdGFwYXRoIGltcGxlbWVudGF0aW9uIA0KICAg ICAgTVVTVCBjb3JyZWN0bHkgY2FwdHVyZSB0aGUgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyBvbiB0 aGUgcGFja2V0LiAgDQogICAgICBNZXRhZGF0YSBnZW5lcmF0aW9uIGJ5IGNlcnRhaW4gTEZCcyBt dXN0IGFsd2F5cyBwcmVjZWRlIGFueSB1c2Ugb2YgDQogICAgICB0aGF0IG1ldGFkYXRhIGJ5IHN1 YnNlcXVlbnQgTEZCcyBpbiB0aGUgdG9wb2xvZ3kgZ3JhcGg7IHRoaXMgaXMgDQogICAgDQogICBZ YW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDZdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVs ICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHJlcXVpcmVkIGZv ciBsb2dpY2FsbHkgY29uc2lzdGVudCBvcGVyYXRpb24uICBGdXJ0aGVyLCANCiAgICAgIG1vZGlm aWNhdGlvbiBvZiBwYWNrZXQgZmllbGRzIHRoYXQgYXJlIHN1YnNlcXVlbnRseSB1c2VkIGFzIGlu cHV0cyANCiAgICAgIGZvciBmdXJ0aGVyIHByb2Nlc3NpbmcgbXVzdCBvY2N1ciBpbiB0aGUgb3Jk ZXIgc3BlY2lmaWVkIGluIHRoZSANCiAgICAgIG1vZGVsIGZvciB0aGF0IHBhcnRpY3VsYXIgaW1w bGVtZW50YXRpb24gdG8gZW5zdXJlIGNvcnJlY3RuZXNzLiANCiAgICANCiAgIDIuMy4gVGhlIEZF IE1vZGVsIGluIFJlbGF0aW9uIHRvIHRoZSBGb3JDRVMgUHJvdG9jb2wgDQogICAgICAgDQogICAg ICBUaGUgRm9yQ0VTIGJhc2UgcHJvdG9jb2wgaXMgdXNlZCBieSB0aGUgQ0VzIGFuZCBGRXMgdG8g bWFpbnRhaW4gDQogICAgICB0aGUgY29tbXVuaWNhdGlvbiBjaGFubmVsIGJldHdlZW4gdGhlIENF cyBhbmQgRkVzLiAgVGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIG1heSBiZSB1c2VkIHRvIHF1 ZXJ5IGFuZCBkaXNjb3ZlciB0aGUgaW50ZXItRkUgdG9wb2xvZ3kuICANCiAgICAgIFRoZSBkZXRh aWxzIG9mIGEgcGFydGljdWxhciBkYXRhcGF0aCBpbXBsZW1lbnRhdGlvbiBpbnNpZGUgYW4gRkUs IA0KICAgICAgaW5jbHVkaW5nIHRoZSBMRkIgdG9wb2xvZ3ksIGFsb25nIHdpdGggdGhlIG9wZXJh dGlvbmFsIA0KICAgICAgY2FwYWJpbGl0aWVzIGFuZCBhdHRyaWJ1dGVzIG9mIGVhY2ggaW5kaXZp ZHVhbCBMRkIsIGFyZSBjb252ZXllZCANCiAgICAgIHRvIHRoZSBDRSB3aXRoaW4gaW5mb3JtYXRp b24gZWxlbWVudHMgaW4gdGhlIEZvckNFUyBwcm90b2NvbC4gIFRoZSANCiAgICAgIG1vZGVsIG9m IGFuIExGQiBjbGFzcyBzaG91bGQgZGVmaW5lIGFsbCBvZiB0aGUgaW5mb3JtYXRpb24gdGhhdCAN CiAgICAgIG5lZWRzIHRvIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGFuIEZFIGFuZCBhIENFIGZvciB0 aGUgcHJvcGVyIA0KICAgICAgY29uZmlndXJhdGlvbiBhbmQgbWFuYWdlbWVudCBvZiB0aGF0IExG Qi4gICANCiAgICAgICANCiAgICAgIFNwZWNpZnlpbmcgdGhlIHZhcmlvdXMgcGF5bG9hZHMgb2Yg dGhlIEZvckNFUyBtZXNzYWdlcyBpbiBhIA0KICAgICAgc3lzdGVtYXRpYyBmYXNoaW9uIGlzIGRp ZmZpY3VsdCB3aXRob3V0IGEgZm9ybWFsIGRlZmluaXRpb24gb2YgdGhlIA0KICAgICAgb2JqZWN0 cyBiZWluZyBjb25maWd1cmVkIGFuZCBtYW5hZ2VkICh0aGUgRkUgYW5kIHRoZSBMRkJzIHdpdGhp bikuICANCiAgICAgIFRoZSBGRSBNb2RlbCBkb2N1bWVudCBkZWZpbmVzIGEgc2V0IG9mIGNsYXNz ZXMgYW5kIGF0dHJpYnV0ZXMgZm9yIA0KICAgICAgZGVzY3JpYmluZyBhbmQgbWFuaXB1bGF0aW5n IHRoZSBzdGF0ZSBvZiB0aGUgTEZCcyB3aXRoaW4gYW4gRkUuICANCiAgICAgIFRoZXNlIGNsYXNz IGRlZmluaXRpb25zIHRoZW1zZWx2ZXMgd2lsbCBnZW5lcmFsbHkgbm90IGFwcGVhciBpbiANCiAg ICAgIHRoZSBGb3JDRVMgcHJvdG9jb2wuICBSYXRoZXIsIEZvckNFUyBwcm90b2NvbCBvcGVyYXRp b25zIHdpbGwgDQogICAgICByZWZlcmVuY2UgY2xhc3NlcyBkZWZpbmVkIGluIHRoaXMgbW9kZWws IGluY2x1ZGluZyByZWxldmFudCANCiAgICAgIGF0dHJpYnV0ZXMgYW5kIHRoZSBkZWZpbmVkIG9w ZXJhdGlvbnMuICANCiAgICAgICAgDQogICAgICBTZWN0aW9uIDcgcHJvdmlkZXMgbW9yZSBkZXRh aWxlZCBkaXNjdXNzaW9uIG9uIGhvdyB0aGUgRkUgbW9kZWwgDQogICAgICBzaG91bGQgYmUgdXNl ZCBieSB0aGUgRm9yQ0VTIHByb3RvY29sLiANCiAgICANCiAgIDIuNC4gTW9kZWxpbmcgTGFuZ3Vh Z2UgZm9yIHRoZSBGRSBNb2RlbCANCiAgICAgICANCiAgICAgIEV2ZW4gdGhvdWdoIG5vdCBhYnNv bHV0ZWx5IHJlcXVpcmVkLCBpdCBpcyBiZW5lZmljaWFsIHRvIHVzZSBhIA0KICAgICAgZm9ybWFs IGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UgdG8gcmVwcmVzZW50IHRoZSBjb25jZXB0dWFsIEZFIG1v ZGVsIA0KICAgICAgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuICBVc2Ugb2YgYSBmb3JtYWwg bGFuZ3VhZ2UgY2FuIGhlbHAgdG8gDQogICAgICBlbmZvcmNlIGNvbnNpc3RlbmN5IGFuZCBsb2dp Y2FsIGNvbXBhdGliaWxpdHkgYW1vbmcgTEZCcy4gIEEgZnVsbCANCiAgICAgIHNwZWNpZmljYXRp b24gd2lsbCBiZSB3cml0dGVuIHVzaW5nIHN1Y2ggYSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlLiAN CiAgICAgIFRoZSBmb3JtYWwgZGVmaW5pdGlvbiBvZiB0aGUgTEZCIGNsYXNzZXMgbWF5IGZhY2ls aXRhdGUgdGhlIA0KICAgICAgZXZlbnR1YWwgYXV0b21hdGlvbiBvZiBzb21lIG9mIHRoZSBjb2Rl IGdlbmVyYXRpb24gcHJvY2VzcyBhbmQgdGhlIA0KICAgICAgZnVuY3Rpb25hbCB2YWxpZGF0aW9u IG9mIGFyYml0cmFyeSBMRkIgdG9wb2xvZ2llcy4gDQogICAgICAgDQogICAgICBIdW1hbiByZWFk YWJpbGl0eSB3YXMgdGhlIG1vc3QgaW1wb3J0YW50IGZhY3RvciBjb25zaWRlcmVkIHdoZW4gDQog ICAgICBzZWxlY3RpbmcgdGhlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UsIHdoZXJlYXMgZW5jb2Rp bmcsIGRlY29kaW5nIA0KICAgICAgYW5kIHRyYW5zbWlzc2lvbiBwZXJmb3JtYW5jZSB3YXMgbm90 IGEgc2VsZWN0aW9uIGZhY3Rvci4gVGhlIA0KICAgICAgZW5jb2RpbmcgbWV0aG9kIGZvciBvdmVy IHRoZSB3aXJlIHRyYW5zcG9ydCBpcyBub3QgZGVwZW5kZW50IG9uIA0KDQogICAgDQogICBZYW5n LCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDddIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAg ICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHRoZSBzcGVjaWZpY2F0 aW9uIGxhbmd1YWdlIGNob3NlbiBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyANCiAg ICAgIGRvY3VtZW50IGFuZCB1cCB0byB0aGUgRm9yQ0VTIHByb3RvY29sIHRvIGRlZmluZS4gICAN CiAgICAgICANCiAgICAgIFhNTCB3YXMgY2hvc2VuIGFzIHRoZSBzcGVjaWZpY2F0aW9uIGxhbmd1 YWdlIGluIHRoaXMgZG9jdW1lbnQsIA0KICAgICAgYmVjYXVzZSBYTUwgaGFzIHRoZSBhZHZhbnRh Z2Ugb2YgYmVpbmcgYm90aCBodW1hbiBhbmQgbWFjaGluZSANCiAgICAgIHJlYWRhYmxlIHdpdGgg d2lkZWx5IGF2YWlsYWJsZSB0b29scyBzdXBwb3J0LiAgDQogICAgICAgDQogICAyLjUuIERvY3Vt ZW50IFN0cnVjdHVyZSANCiAgICAgICANCiAgICAgIFNlY3Rpb24gMyBwcm92aWRlcyBhIGNvbmNl cHR1YWwgb3ZlcnZpZXcgb2YgdGhlIEZFIG1vZGVsLCBsYXlpbmcgDQogICAgICB0aGUgZm91bmRh dGlvbiBmb3IgdGhlIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBhbmQgc3BlY2lmaWNhdGlvbnMg DQogICAgICBpbiB0aGUgc2VjdGlvbnMgdGhhdCBmb2xsb3cuICBTZWN0aW9uIDQgYW5kIDUgY29u c3RpdHV0ZSB0aGUgY29yZSANCiAgICAgIG9mIHRoZSBGRSBtb2RlbCwgZGV0YWlsaW5nIHRoZSB0 d28gbWFqb3IgY29tcG9uZW50cyBpbiB0aGUgRkUgDQogICAgICBtb2RlbDogTEZCIG1vZGVsIGFu ZCBGRSBsZXZlbCBhdHRyaWJ1dGVzIGluY2x1ZGluZyBjYXBhYmlsaXR5IGFuZCANCiAgICAgIExG QiB0b3BvbG9neS4gIFNlY3Rpb24gNiBkaXJlY3RseSBhZGRyZXNzZXMgdGhlIG1vZGVsIHJlcXVp cmVtZW50cyANCiAgICAgIGltcG9zZWQgYnkgdGhlIEZvckNFUyByZXF1aXJlbWVudCBkcmFmdCBb MV0gd2hpbGUgU2VjdGlvbiA3IA0KICAgICAgZXhwbGFpbnMgaG93IHRoZSBGRSBtb2RlbCBzaG91 bGQgYmUgdXNlZCBpbiB0aGUgRm9yQ0VTIHByb3RvY29sLiAgDQogICAgDQogICAzLiANICAgICBG RSBNb2RlbCBDb25jZXB0cyAgDQogICAgICAgDQogICAgICBTb21lIG9mIHRoZSBpbXBvcnRhbnQg Y29uY2VwdHMgdXNlZCB0aHJvdWdob3V0IHRoaXMgZG9jdW1lbnQgYXJlIA0KICAgICAgaW50cm9k dWNlZCBpbiB0aGlzIHNlY3Rpb24uICBTZWN0aW9uIDMuMSBleHBsYWlucyB0aGUgZGlmZmVyZW5j ZSANCiAgICAgIGJldHdlZW4gYSBzdGF0ZSBtb2RlbCBhbmQgYSBjYXBhYmlsaXR5IG1vZGVsLCBh bmQgZGVzY3JpYmVzIGhvdyANCiAgICAgIHRoZSB0d28gY2FuIGJlIGNvbWJpbmVkIGluIHRoZSBG RSBtb2RlbC4gIFNlY3Rpb24gMy4yIGludHJvZHVjZXMgDQogICAgICB0aGUgY29uY2VwdCBvZiBM RkJzIChMb2dpY2FsIEZ1bmN0aW9uYWwgQmxvY2tzKSBhcyB0aGUgYmFzaWMgDQogICAgICBmdW5j dGlvbmFsIGJ1aWxkaW5nIGJsb2NrcyBpbiB0aGUgRkUgbW9kZWwuICBTZWN0aW9uIDMuMyBkaXNj dXNzZXMgDQogICAgICB0aGUgbG9naWNhbCBpbnRlci1jb25uZWN0aW9uIGFuZCBvcmRlcmluZyBi ZXR3ZWVuIExGQiBpbnN0YW5jZXMgDQogICAgICB3aXRoaW4gYW4gRkUsIHRoYXQgaXMsIHRoZSBM RkIgdG9wb2xvZ3kuICANCiAgICAgICANCiAgICAgIFRoZSBGRSBtb2RlbCBwcm9wb3NlZCBpbiB0 aGlzIGRvY3VtZW50IGlzIGNvbXByaXNlZCBvZiB0d28gbWFqb3IgDQogICAgICBjb21wb25lbnRz OiB0aGUgTEZCIG1vZGVsIGFuZCBGRSBsZXZlbCBhdHRyaWJ1dGVzLCBpbmNsdWRpbmcgRkUgDQog ICAgICBjYXBhYmlsaXRpZXMgYW5kIExGQiB0b3BvbG9neS4gIFRoZSBMRkIgbW9kZWwgcHJvdmlk ZXMgdGhlIGNvbnRlbnQgDQogICAgICBhbmQgZGF0YSBzdHJ1Y3R1cmVzIHRvIGRlZmluZSBlYWNo IGluZGl2aWR1YWwgTEZCIGNsYXNzLiAgRkUgDQogICAgICBhdHRyaWJ1dGVzIHByb3ZpZGUgaW5m b3JtYXRpb24gYXQgdGhlIEZFIGxldmVsLCBwYXJ0aWN1bGFybHkgdGhlIA0KICAgICAgY2FwYWJp bGl0aWVzIG9mIHRoZSBGRSBhdCBhIGNvYXJzZSBsZXZlbC4gIFBhcnQgb2YgdGhlIEZFIGxldmVs IA0KICAgICAgaW5mb3JtYXRpb24gaXMgdGhlIExGQiB0b3BvbG9neSwgd2hpY2ggZXhwcmVzc2Vz IHRoZSBsb2dpY2FsIA0KICAgICAgaW50ZXItY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBMRkIgaW5z dGFuY2VzIGFsb25nIHRoZSBkYXRhcGF0aChzKSANCiAgICAgIHdpdGhpbiB0aGUgRkUuICBEZXRh aWxzIG9mIHRoZXNlIGNvbXBvbmVudHMgYXJlIGRlc2NyaWJlZCBpbiANCiAgICAgIFNlY3Rpb24g NCBhbmQgNS4gIFRoZSBpbnRlbnQgb2YgdGhpcyBzZWN0aW9uIGlzIHRvIGRpc2N1c3MgdGhlc2Ug DQogICAgICBjb25jZXB0cyBhdCB0aGUgaGlnaCBsZXZlbCBhbmQgbGF5IHRoZSBmb3VuZGF0aW9u IGZvciB0aGUgZGV0YWlsZWQgDQogICAgICBkZXNjcmlwdGlvbiBpbiB0aGUgZm9sbG93aW5nIHNl Y3Rpb25zLiANCiAgICAgICANCiAgIDMuMS4gRkUgQ2FwYWJpbGl0eSBNb2RlbCBhbmQgU3RhdGUg TW9kZWwgDQogICAgICAgDQogICAgICBUaGUgRm9yQ0VTIEZFIG1vZGVsIG11c3QgZGVzY3JpYmUg Ym90aCBhIGNhcGFiaWxpdHkgYW5kIGEgc3RhdGUgDQogICAgICBtb2RlbC4gIFRoZSBGRSBjYXBh YmlsaXR5IG1vZGVsIGRlc2NyaWJlcyB0aGUgY2FwYWJpbGl0aWVzIGFuZCANCiAgICAgIGNhcGFj aXRpZXMgb2YgYW4gRkUgYnkgc3BlY2lmeWluZyB0aGUgdmFyaWF0aW9uIGluIGZ1bmN0aW9ucyAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgOF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg c3VwcG9ydGVkIGFuZCBhbnkgbGltaXRhdGlvbnMuICBUaGUgRkUgc3RhdGUgbW9kZWwgZGVzY3Jp YmVzIHRoZSANCiAgICAgIGN1cnJlbnQgc3RhdGUgb2YgdGhlIEZFLCB0aGF0IGlzLCB0aGUgaW5z dGFudGFuZW91cyB2YWx1ZXMgb3IgDQogICAgICBvcGVyYXRpb25hbCBiZWhhdmlvciBvZiB0aGUg RkUuICANCiAgICAgICANCiAgICAgIENvbmNlcHR1YWxseSwgdGhlIEZFIGNhcGFiaWxpdHkgbW9k ZWwgdGVsbHMgdGhlIENFIHdoaWNoIHN0YXRlcyANCiAgICAgIGFyZSBhbGxvd2VkIG9uIGFuIEZF LCB3aXRoIGNhcGFjaXR5IGluZm9ybWF0aW9uIGluZGljYXRpbmcgY2VydGFpbiANCiAgICAgIHF1 YW50aXRhdGl2ZSBsaW1pdHMgb3IgY29uc3RyYWludHMuICBUaHVzLCB0aGUgQ0UgaGFzIGdlbmVy YWwgDQogICAgICBrbm93bGVkZ2UgYWJvdXQgY29uZmlndXJhdGlvbnMgdGhhdCBhcmUgYXBwbGlj YWJsZSB0byBhIHBhcnRpY3VsYXIgDQogICAgICBGRS4gIEZvciBleGFtcGxlLCBhbiBGRSBjYXBh YmlsaXR5IG1vZGVsIG1heSBkZXNjcmliZSB0aGUgRkUgYXQgYSANCiAgICAgIGNvYXJzZSBsZXZl bCBzdWNoIGFzOiANCiAgICAgICANCiAgICAgICAgLiB0aGlzIEZFIGNhbiBoYW5kbGUgSVB2NCBh bmQgSVB2NiBmb3J3YXJkaW5nOyANCiAgICAgICAgLiB0aGlzIEZFIGNhbiBwZXJmb3JtIGNsYXNz aWZpY2F0aW9uIG9uIHRoZSBmb2xsb3dpbmcgZmllbGRzOiANCiAgICAgICAgICAgc291cmNlIElQ IGFkZHJlc3MsIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MsIHNvdXJjZSBwb3J0IA0KICAgICAgICAg ICBudW1iZXIsIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyLCBldGM7IA0KICAgICAgICAuIHRoaXMg RkUgY2FuIHBlcmZvcm0gbWV0ZXJpbmc7IA0KICAgICAgICAuIHRoaXMgRkUgY2FuIGhhbmRsZSB1 cCB0byBOIHF1ZXVlcyAoY2FwYWNpdHkpOyANCiAgICAgICAgLiB0aGlzIEZFIGNhbiBhZGQgYW5k IHJlbW92ZSBlbmNhcHN1bGF0aW5nIGhlYWRlcnMgb2YgdHlwZXMgDQogICAgICAgICAgIGluY2x1 ZGluZyBJUFNlYywgR1JFLCBMMlRQLiANCiAgICANCiAgICAgIFdoaWxlIG9uZSBjb3VsZCB0cnkg YW5kIGJ1aWxkIGFuIG9iamVjdCBtb2RlbCB0byBmdWxseSByZXByZXNlbnQgDQogICAgICB0aGUg RkUgY2FwYWJpbGl0aWVzLCBvdGhlciBlZmZvcnRzIGZvdW5kIHRoaXMgdG8gYmUgYSBzaWduaWZp Y2FudCANCiAgICAgIHVuZGVydGFraW5nLiAgVGhlIG1haW4gZGlmZmljdWx0eSBhcmlzZXMgaW4g ZGVzY3JpYmluZyBkZXRhaWxlZCANCiAgICAgIGxpbWl0cywgc3VjaCBhcyB0aGUgbWF4aW11bSBu dW1iZXIgb2YgY2xhc3NpZmllcnMsIHF1ZXVlcywgYnVmZmVyIA0KICAgICAgcG9vbHMsIGFuZCBt ZXRlcnMgdGhlIEZFIGNhbiBwcm92aWRlLiAgV2UgYmVsaWV2ZSB0aGF0IGEgZ29vZCANCiAgICAg IGJhbGFuY2UgYmV0d2VlbiBzaW1wbGljaXR5IGFuZCBmbGV4aWJpbGl0eSBjYW4gYmUgYWNoaWV2 ZWQgZm9yIHRoZSANCiAgICAgIEZFIG1vZGVsIGJ5IGNvbWJpbmluZyBjb2Fyc2UgbGV2ZWwgY2Fw YWJpbGl0eSByZXBvcnRpbmcgd2l0aCBhbiANCiAgICAgIGVycm9yIHJlcG9ydGluZyBtZWNoYW5p c20uICBUaGF0IGlzLCBpZiB0aGUgQ0UgYXR0ZW1wdHMgdG8gDQogICAgICBpbnN0cnVjdCB0aGUg RkUgdG8gc2V0IHVwIHNvbWUgc3BlY2lmaWMgYmVoYXZpb3IgaXQgY2Fubm90IA0KICAgICAgc3Vw cG9ydCwgdGhlIEZFIHdpbGwgcmV0dXJuIGFuIGVycm9yIGluZGljYXRpbmcgdGhlIHByb2JsZW0u ICANCiAgICAgIEV4YW1wbGVzIG9mIHNpbWlsYXIgYXBwcm9hY2hlcyBpbmNsdWRlIERpZmZTZXJ2 IFBJQiBbNF0gYW5kIA0KICAgICAgRnJhbWV3b3JrIFBJQiBbNV0uIA0KICAgIA0KICAgICAgVGhl IEZFIHN0YXRlIG1vZGVsIHByZXNlbnRzIHRoZSBzbmFwc2hvdCB2aWV3IG9mIHRoZSBGRSB0byB0 aGUgQ0UuICANCiAgICAgIEZvciBleGFtcGxlLCB1c2luZyBhbiBGRSBzdGF0ZSBtb2RlbCwgYW4g RkUgbWF5IGJlIGRlc2NyaWJlZCB0byANCiAgICAgIGl0cyBjb3JyZXNwb25kaW5nIENFIGFzIHRo ZSBmb2xsb3dpbmc6ICANCiAgICAgICAgLiBvbiBhIGdpdmVuIHBvcnQsIHRoZSBwYWNrZXRzIGFy ZSBjbGFzc2lmaWVkIHVzaW5nIGEgZ2l2ZW4gDQogICAgICAgICAgIGNsYXNzaWZpY2F0aW9uIGZp bHRlcjsgDQogICAgICAgIC4gdGhlIGdpdmVuIGNsYXNzaWZpZXIgcmVzdWx0cyBpbiBwYWNrZXRz IGJlaW5nIG1ldGVyZWQgaW4gYSANCiAgICAgICAgICAgY2VydGFpbiB3YXksIGFuZCB0aGVuIG1h cmtlZCBpbiBhIGNlcnRhaW4gd2F5OyANCiAgICAgICAgLiB0aGUgcGFja2V0cyBjb21pbmcgZnJv bSBzcGVjaWZpYyBtYXJrZXJzIGFyZSBkZWxpdmVyZWQgaW50byBhIA0KICAgICAgICAgICBzaGFy ZWQgcXVldWUgZm9yIGhhbmRsaW5nLCB3aGlsZSBvdGhlciBwYWNrZXRzIGFyZSBkZWxpdmVyZWQg DQogICAgICAgICAgIHRvIGEgZGlmZmVyZW50IHF1ZXVlOyANCiAgICAgICAgLiBhIHNwZWNpZmlj IHNjaGVkdWxlciB3aXRoIHNwZWNpZmljIGJlaGF2aW9yIGFuZCBwYXJhbWV0ZXJzIA0KICAgICAg ICAgICB3aWxsIHNlcnZpY2UgdGhlc2UgY29sbGVjdGVkIHF1ZXVlcy4gDQogICAgICAgDQoNCiAg ICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgOV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMg RkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgRmln dXJlIDEgc2hvd3MgdGhlIGNvbmNlcHRzIG9mIEZFIHN0YXRlLCBjYXBhYmlsaXRpZXMgYW5kIA0K ICAgICAgY29uZmlndXJhdGlvbiBpbiB0aGUgY29udGV4dCBvZiBDRS1GRSBjb21tdW5pY2F0aW9u IHZpYSB0aGUgRm9yQ0VTIA0KICAgICAgcHJvdG9jb2wuIA0KICAgIA0KICAgICAgICAgICArLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsg DQogICAgICAgICAgIHwgICAgICAgfCBGRSBjYXBhYmlsaXRpZXM6IHdoYXQgaXQgY2FuL2Nhbm5v dCBkby4gIHwgICAgICAgfCANCiAgICAgICAgICAgfCAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICB8IA0KICAgICAgICAgICB8ICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgDQogICAg ICAgICAgIHwgICBDRSAgfCBGRSBzdGF0ZTogd2hhdCBpdCBpcyBub3cuICAgICAgICAgICAgICAg IHwgIEZFICAgfCANCiAgICAgICAgICAgfCAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICB8IA0KICAgICAgICAgICB8ICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgDQogICAgICAgICAg IHwgICAgICAgfCBGRSBjb25maWd1cmF0aW9uOiB3aGF0IGl0IHNob3VsZCBiZS4gICAgIHwgICAg ICAgfCANCiAgICAgICAgICAgfCAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+fCAgICAgICB8IA0KICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsgDQogICAgICAgDQogICAgICBG aWd1cmUgMS4gSWxsdXN0cmF0aW9uIG9mIEZFIHN0YXRlLCBjYXBhYmlsaXRpZXMgYW5kIGNvbmZp Z3VyYXRpb24gDQogICAgICAgICAgZXhjaGFuZ2UgaW4gdGhlIGNvbnRleHQgb2YgQ0UtRkUgY29t bXVuaWNhdGlvbiB2aWEgRm9yQ0VTLiANCiAgICANCiAgICAgIFRoZSBjb25jZXB0cyByZWxhdGlu ZyB0byBMRkJzLCBwYXJ0aWN1bGFybHkgY2FwYWJpbGl0eSBhdCB0aGUgTEZCIA0KICAgICAgbGV2 ZWwgYW5kIExGQiB0b3BvbG9neSB3aWxsIGJlIGRpc2N1c3NlZCBpbiB0aGUgcmVzdCBvZiB0aGlz IA0KICAgICAgc2VjdGlvbi4gDQogICAgICAgDQogICAgICBDYXBhYmlsaXR5IGluZm9ybWF0aW9u IGF0IHRoZSBMRkIgbGV2ZWwgaXMgYW4gaW50ZWdyYWwgcGFydCBvZiB0aGUgDQogICAgICBMRkIg bW9kZWwsIGFuZCBpcyBtb2RlbGVkIHRoZSBzYW1lIHdheSBhcyB0aGUgb3RoZXIgb3BlcmF0aW9u YWwgDQogICAgICBwYXJhbWV0ZXJzIGluc2lkZSBhbiBMRkIuICBGb3IgZXhhbXBsZSwgd2hlbiBj ZXJ0YWluIGZlYXR1cmVzIG9mIA0KICAgICAgYW4gTEZCIGNsYXNzIGFyZSBvcHRpb25hbCwgaXQg bXVzdCBiZSBwb3NzaWJsZSBmb3IgdGhlIENFIHRvIA0KICAgICAgZGV0ZXJtaW5lIHdoZXRoZXIg dGhvc2Ugb3B0aW9uYWwgZmVhdHVyZXMgYXJlIHN1cHBvcnRlZCBieSBhIGdpdmVuIA0KICAgICAg TEZCIGluc3RhbmNlLiAgU3VjaCBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGNhbiBiZSBtb2RlbGVk IGFzIGEgDQogICAgICByZWFkLW9ubHkgYXR0cmlidXRlIGluIHRoZSBMRkIgaW5zdGFuY2UsIHNl ZSBTZWN0aW9uIDQuNy41IGZvciANCiAgICAgIGRldGFpbHMuIA0KICAgICAgIA0KICAgICAgQ2Fw YWJpbGl0eSBpbmZvcm1hdGlvbiBhdCB0aGUgRkUgbGV2ZWwgbWF5IGRlc2NyaWJlIHRoZSBMRkIg DQogICAgICBjbGFzc2VzIHRoYXQgdGhlIEZFIGNhbiBpbnN0YW50aWF0ZTsgdGhlIG51bWJlciBv ZiBpbnN0YW5jZXMgb2YgDQogICAgICBlYWNoIHRoYXQgY2FuIGJlIGNyZWF0ZWQ7IHRoZSB0b3Bv bG9naWNhbCAobGlua2FnZSkgbGltaXRhdGlvbnMgDQogICAgICBiZXR3ZWVuIHRoZXNlIExGQiBp bnN0YW5jZXMsIGV0Yy4gIFNlY3Rpb24gNSBkZWZpbmVzIHRoZSBGRSBsZXZlbCANCiAgICAgIGF0 dHJpYnV0ZXMgaW5jbHVkaW5nIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24uICANCiAgICAgICANCiAg ICAgIE9uY2UgdGhlIEZFIGNhcGFiaWxpdHkgaXMgZGVzY3JpYmVkIHRvIHRoZSBDRSwgdGhlIEZF IHN0YXRlIA0KICAgICAgaW5mb3JtYXRpb24gY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHR3byBsZXZl bHMuICBUaGUgZmlyc3QgbGV2ZWwgaXMgDQogICAgICB0aGUgbG9naWNhbGx5IHNlcGFyYWJsZSBh bmQgZGlzdGluY3QgcGFja2V0IHByb2Nlc3NpbmcgZnVuY3Rpb25zLCANCiAgICAgIGNhbGxlZCBM b2dpY2FsIEZ1bmN0aW9uYWwgQmxvY2tzIChMRkJzKS4gIFRoZSBzZWNvbmQgbGV2ZWwgb2YgDQog ICAgICBpbmZvcm1hdGlvbiBkZXNjcmliZXMgaG93IHRoZXNlIGluZGl2aWR1YWwgTEZCcyBhcmUg b3JkZXJlZCBhbmQgDQogICAgICBwbGFjZWQgYWxvbmcgdGhlIGRhdGFwYXRoIHRvIGRlbGl2ZXIg YSBjb21wbGV0ZSBmb3J3YXJkaW5nIHBsYW5lIA0KICAgICAgc2VydmljZS4gIFRoZSBpbnRlcmNv bm5lY3Rpb24gYW5kIG9yZGVyaW5nIG9mIHRoZSBMRkJzIGlzIGNhbGxlZCANCiAgICAgIExGQiBU b3BvbG9neS4gIFNlY3Rpb24gMy4yIGRpc2N1c3NlcyBoaWdoIGxldmVsIGNvbmNlcHRzIGFyb3Vu ZCANCiAgICAgIExGQnMsIHdoZXJlYXMgU2VjdGlvbiAzLjMgZGlzY3Vzc2VzIExGQiB0b3BvbG9n eSBpc3N1ZXMuIA0KICAgICAgIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAzLjIuIExGQiAoTG9naWNhbCBGdW5jdGlvbmFsIEJsb2NrKSBNb2Rl bGluZyANCiAgICAgICANCiAgICAgIEVhY2ggTEZCIHBlcmZvcm1zIGEgd2VsbC1kZWZpbmVkIGFj dGlvbiBvciBjb21wdXRhdGlvbiBvbiB0aGUgDQogICAgICBwYWNrZXRzIHBhc3NpbmcgdGhyb3Vn aCBpdC4gIFVwb24gY29tcGxldGlvbiBvZiBpdHMgcHJlc2NyaWJlZCANCiAgICAgIGZ1bmN0aW9u LCBlaXRoZXIgdGhlIHBhY2tldHMgYXJlIG1vZGlmaWVkIGluIGNlcnRhaW4gd2F5cyAoZS5nLiwg DQogICAgICBkZWNhcHN1bGF0b3IsIG1hcmtlciksIG9yIHNvbWUgcmVzdWx0cyBhcmUgZ2VuZXJh dGVkIGFuZCBzdG9yZWQsIA0KICAgICAgb2Z0ZW4gaW4gdGhlIGZvcm0gb2YgbWV0YWRhdGEgKGUu Zy4sIGNsYXNzaWZpZXIpLiAgRWFjaCBMRkIgDQogICAgICB0eXBpY2FsbHkgcGVyZm9ybXMgYSBz aW5nbGUgYWN0aW9uLiAgQ2xhc3NpZmllcnMsIHNoYXBlcnMgYW5kIA0KICAgICAgbWV0ZXJzIGFy ZSBhbGwgZXhhbXBsZXMgb2Ygc3VjaCBMRkJzLiAgTW9kZWxpbmcgTEZCcyBhdCBzdWNoIGEgDQog ICAgICBmaW5lIGdyYW51bGFyaXR5IGFsbG93cyB1cyB0byB1c2UgYSBzbWFsbCBudW1iZXIgb2Yg TEZCcyB0byANCiAgICAgIGV4cHJlc3MgdGhlIGhpZ2hlci1vcmRlciBGRSBmdW5jdGlvbnMgKHN1 Y2ggYXMgYW4gSVB2NCBmb3J3YXJkZXIpIA0KICAgICAgcHJlY2lzZWx5LCB3aGljaCBpbiB0dXJu IGNhbiBkZXNjcmliZSBtb3JlIGNvbXBsZXggbmV0d29ya2luZyANCiAgICAgIGZ1bmN0aW9ucyBh bmQgdmVuZG9yIGltcGxlbWVudGF0aW9ucyBvZiBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUuICANCiAg ICAgIFRoZXNlIExGQnMgd2lsbCBiZSBkZWZpbmVkIGluIGRldGFpbCBpbiBvbmUgb3IgbW9yZSBk b2N1bWVudHMuIA0KICAgICAgIA0KICAgICAgQW4gTEZCIGhhcyBvbmUgb3IgbW9yZSBpbnB1dHMs IGVhY2ggb2Ygd2hpY2ggdGFrZXMgYSBwYWNrZXQgUCwgYW5kIA0KICAgICAgb3B0aW9uYWxseSBt ZXRhZGF0YSBNOyBhbmQgcHJvZHVjZXMgb25lIG9yIG1vcmUgb3V0cHV0cywgZWFjaCBvZiANCiAg ICAgIHdoaWNoIGNhcnJpZXMgYSBwYWNrZXQgUCcsIGFuZCBvcHRpb25hbGx5IG1ldGFkYXRhIE0n LiAgTWV0YWRhdGEgDQogICAgICBpcyBkYXRhIGFzc29jaWF0ZWQgd2l0aCB0aGUgcGFja2V0IGlu IHRoZSBuZXR3b3JrIHByb2Nlc3NpbmcgDQogICAgICBkZXZpY2UgKHJvdXRlciwgc3dpdGNoLCBl dGMuKSBhbmQgaXMgcGFzc2VkIGZyb20gb25lIExGQiB0byB0aGUgDQogICAgICBuZXh0LCBidXQg aXMgbm90IHNlbnQgYWNyb3NzIHRoZSBuZXR3b3JrLiAgSW4gZ2VuZXJhbCwgbXVsdGlwbGUgDQog ICAgICBMRkJzIGFyZSBjb250YWluZWQgaW4gb25lIEZFLCBhcyBzaG93biBpbiBGaWd1cmUgMiwg YW5kIGFsbCB0aGUgDQogICAgICBMRkJzIHNoYXJlIHRoZSBzYW1lIEZvckNFUyBwcm90b2NvbCB0 ZXJtaW5hdGlvbiBwb2ludCB0aGF0IA0KICAgICAgaW1wbGVtZW50cyB0aGUgRm9yQ0VTIHByb3Rv Y29sIGxvZ2ljIGFuZCBtYWludGFpbnMgdGhlIA0KICAgICAgY29tbXVuaWNhdGlvbiBjaGFubmVs IHRvIGFuZCBmcm9tIHRoZSBDRS4gICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICAN CiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxMV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUg TW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgQ0UgICAgIHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEZwIHJlZmVyZW5jZSBwb2ludCANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAg ICAgfCBGRSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgdiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfCANCiAgICAgICAg fCB8ICAgICAgICAgICAgICAgIEZvckNFUyBwcm90b2NvbCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgfCANCiAgICAgICAgfCB8ICAgICAgICAgICAgICAgICAgIHRlcm1pbmF0aW9uIHBvaW50 ICAgICAgICAgICAgICAgICAgICAgIHwgfCANCiAgICAgICAgfCArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfCANCiAgICAgICAgfCAg ICAgICAgICAgXiAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgICAg ICAgfCANCiAgICAgICAgfCAgICAgICAgICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 IEludGVybmFsIGNvbnRyb2wgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgOiAgICAgICAgICAg ICAgICAgICAgICAgICAgICA6ICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAg ICArLS0tOi0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS06LS0tLS0tLS0tLXwgICAgICAgICAg fCANCiAgICAgICAgfCAgICAgICB8ICAgOkxGQjEgICAgICB8ICAgICAgICAgICAgIHwgICA6ICAg ICBMRkIyIHwgICAgICAgICAgfCANCiAgICAgICAgfCA9PT09PT58ICAgdiAgICAgICAgICB8PT09 PT09PT09PT09PnwgICB2ICAgICAgICAgIHw9PT09PT0+Li4ufCANCiAgICAgICAgfCBJbnB1dHN8 ICstLS0tLS0tLS0tKyB8T3V0cHV0cyAgICAgIHwgKy0tLS0tLS0tLS0rIHwgICAgICAgICAgfCAN CiAgICAgICAgfCAoUCxNKSB8IHxBdHRyaWJ1dGVzfCB8KFAnLE0nKSAgICAgIHwgfEF0dHJpYnV0 ZXN8IHwoUCIsTSIpICAgfCANCiAgICAgICAgfCAgICAgICB8ICstLS0tLS0tLS0tKyB8ICAgICAg ICAgICAgIHwgKy0tLS0tLS0tLS0rIHwgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICArLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgICAgfCANCiAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyLiBHZW5l cmljIExGQiBEaWFncmFtIA0KICAgIA0KICAgICAgQW4gTEZCLCBhcyBzaG93biBpbiBGaWd1cmUg MiwgaGFzIGlucHV0cywgb3V0cHV0cyBhbmQgYXR0cmlidXRlcyANCiAgICAgIHRoYXQgY2FuIGJl IHF1ZXJpZWQgYW5kIG1hbmlwdWxhdGVkIGJ5IHRoZSBDRSBpbmRpcmVjdGx5IHZpYSBhbiBGcCAN CiAgICAgIHJlZmVyZW5jZSBwb2ludCAoZGVmaW5lZCBpbiBSRkMgMzc0NiBbMl0pIGFuZCB0aGUg Rm9yQ0VTIHByb3RvY29sIA0KICAgICAgdGVybWluYXRpb24gcG9pbnQuICBUaGUgaG9yaXpvbnRh bCBheGlzIGlzIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIA0KICAgICAgZm9yIGNvbm5lY3Rpbmcg dGhlIGlucHV0cyBhbmQgb3V0cHV0cyBvZiBMRkJzIHdpdGhpbiB0aGUgc2FtZSBGRS4gDQogICAg ICBUaGUgdmVydGljYWwgYXhpcyBiZXR3ZWVuIHRoZSBDRSBhbmQgdGhlIEZFIGRlbm90ZXMgdGhl IEZwIA0KICAgICAgcmVmZXJlbmNlIHBvaW50IHdoZXJlIGJpZGlyZWN0aW9uYWwgY29tbXVuaWNh dGlvbiBiZXR3ZWVuIHRoZSBDRSANCiAgICAgIGFuZCBGRSBvY2N1cnM6IHRoZSBDRSB0byBGRSBj b21tdW5pY2F0aW9uIGlzIGZvciBjb25maWd1cmF0aW9uLCANCiAgICAgIGNvbnRyb2wgYW5kIHBh Y2tldCBpbmplY3Rpb24gd2hpbGUgRkUgdG8gQ0UgY29tbXVuaWNhdGlvbiBpcyB1c2VkIA0KICAg ICAgZm9yIHBhY2tldCByZS1kaXJlY3Rpb24gdG8gdGhlIGNvbnRyb2wgcGxhbmUsIG1vbml0b3Jp bmcgYW5kIA0KICAgICAgYWNjb3VudGluZyBpbmZvcm1hdGlvbiwgZXJyb3JzLCBldGMuICBOb3Rl IHRoYXQgdGhlIGludGVyYWN0aW9uIA0KICAgICAgYmV0d2VlbiB0aGUgQ0UgYW5kIHRoZSBMRkIg aXMgb25seSBhYnN0cmFjdCBhbmQgaW5kaXJlY3QuICBUaGUgDQogICAgICByZXN1bHQgb2Ygc3Vj aCBhbiBpbnRlcmFjdGlvbiBpcyBmb3IgdGhlIENFIHRvIGluZGlyZWN0bHkgDQogICAgICBtYW5p cHVsYXRlIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBMRkIgaW5zdGFuY2VzLiAgIA0KICAgIA0KICAg ICAgQSBuYW1lc3BhY2UgaXMgdXNlZCB0byBhc3NvY2lhdGUgYSB1bmlxdWUgbmFtZSBvciBJRCB3 aXRoIGVhY2ggTEZCIA0KICAgICAgY2xhc3MuICBUaGUgbmFtZXNwYWNlIG11c3QgYmUgZXh0ZW5z aWJsZSBzbyB0aGF0IGEgbmV3IExGQiBjbGFzcyANCiAgICAgIGNhbiBiZSBhZGRlZCBsYXRlciB0 byBhY2NvbW1vZGF0ZSBmdXR1cmUgaW5ub3ZhdGlvbiBpbiB0aGUgDQogICAgICBmb3J3YXJkaW5n IHBsYW5lLiAgICAgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAy MDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdIA0KDCAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICAN CiAgICANCiAgICAgICANCiAgICAgIExGQiBvcGVyYXRpb24gbXVzdCBiZSBzcGVjaWZpZWQgaW4g dGhlIG1vZGVsIHRvIGFsbG93IHRoZSBDRSB0byANCiAgICAgIHVuZGVyc3RhbmQgdGhlIGJlaGF2 aW9yIG9mIHRoZSBmb3J3YXJkaW5nIGRhdGFwYXRoLiAgRm9yIGluc3RhbmNlLCANCiAgICAgIHRo ZSBDRSBtdXN0IHVuZGVyc3RhbmQgYXQgd2hhdCBwb2ludCBpbiB0aGUgZGF0YXBhdGggdGhlIElQ djQgDQogICAgICBoZWFkZXIgVFRMIGlzIGRlY3JlbWVudGVkLiAgVGhhdCBpcywgdGhlIENFIG5l ZWRzIHRvIGtub3cgaWYgYSANCiAgICAgIGNvbnRyb2wgcGFja2V0IGNvdWxkIGJlIGRlbGl2ZXJl ZCB0byBpdCBlaXRoZXIgYmVmb3JlIG9yIGFmdGVyIA0KICAgICAgdGhpcyBwb2ludCBpbiB0aGUg ZGF0YXBhdGguICBJbiBhZGRpdGlvbiwgdGhlIENFIG11c3QgdW5kZXJzdGFuZCANCiAgICAgIHdo ZXJlIGFuZCB3aGF0IHR5cGUgb2YgaGVhZGVyIG1vZGlmaWNhdGlvbnMgKGUuZy4sIHR1bm5lbCBo ZWFkZXIgDQogICAgICBhcHBlbmQgb3Igc3RyaXApIGFyZSBwZXJmb3JtZWQgK2J5IHRoZSBGRXMu ICBGdXJ0aGVyLCB0aGUgQ0UgbXVzdCANCiAgICAgIHZlcmlmeSB0aGF0IHRoZSB2YXJpb3VzIExG QnMgYWxvbmcgYSBkYXRhcGF0aCB3aXRoaW4gYW4gRkUgYXJlIA0KICAgICAgY29tcGF0aWJsZSB0 byBsaW5rIHRvZ2V0aGVyLiANCiAgICAgICANCiAgICAgIFRoZXJlIGlzIHZhbHVlIHRvIHZlbmRv cnMgaWYgdGhlIG9wZXJhdGlvbiBvZiBMRkIgY2xhc3NlcyBjYW4gYmUgDQogICAgICBleHByZXNz ZWQgaW4gc3VmZmljaWVudCBkZXRhaWwgc28gdGhhdCBwaHlzaWNhbCBkZXZpY2VzIA0KICAgICAg aW1wbGVtZW50aW5nIGRpZmZlcmVudCBMRkIgZnVuY3Rpb25zIGNhbiBiZSBpbnRlZ3JhdGVkIGVh c2lseSBpbnRvIA0KICAgICAgYW4gRkUgZGVzaWduLiAgVGhlcmVmb3JlLCBhIHNlbWktZm9ybWFs IHNwZWNpZmljYXRpb24gaXMgbmVlZGVkOyANCiAgICAgIHRoYXQgaXMsIGEgdGV4dCBkZXNjcmlw dGlvbiBvZiB0aGUgTEZCIG9wZXJhdGlvbiAoaHVtYW4gcmVhZGFibGUpLCANCiAgICAgIGJ1dCBz dWZmaWNpZW50bHkgc3BlY2lmaWMgYW5kIHVuYW1iaWd1b3VzIHRvIGFsbG93IGNvbmZvcm1hbmNl IA0KICAgICAgdGVzdGluZyBhbmQgZWZmaWNpZW50IGRlc2lnbiwgc28gdGhhdCBpbnRlcm9wZXJh YmlsaXR5IGJldHdlZW4gDQogICAgICBkaWZmZXJlbnQgQ0VzIGFuZCBGRXMgY2FuIGJlIGFjaGll dmVkLiAgDQogICAgICAgDQogICAgICBUaGUgTEZCIGNsYXNzIG1vZGVsIHNwZWNpZmllcyBpbmZv cm1hdGlvbiBzdWNoIGFzOiANCiAgICAgICAgLiBudW1iZXIgb2YgaW5wdXRzIGFuZCBvdXRwdXRz IChhbmQgd2hldGhlciB0aGV5IGFyZSANCiAgICAgICAgICAgY29uZmlndXJhYmxlKSANCiAgICAg ICAgLiBtZXRhZGF0YSByZWFkL2NvbnN1bWVkIGZyb20gaW5wdXRzOyANCiAgICAgICAgLiBtZXRh ZGF0YSBwcm9kdWNlZCBhdCB0aGUgb3V0cHV0czsgDQogICAgICAgIC4gcGFja2V0IHR5cGUocykg YWNjZXB0ZWQgYXQgdGhlIGlucHV0cyBhbmQgZW1pdHRlZCBhdCB0aGUgDQogICAgICAgICAgIG91 dHB1dHM7IA0KICAgICAgICAuIHBhY2tldCBjb250ZW50IG1vZGlmaWNhdGlvbnMgKGluY2x1ZGlu ZyBlbmNhcHN1bGF0aW9uIG9yIA0KICAgICAgICAgICBkZWNhcHN1bGF0aW9uKTsgDQogICAgICAg IC4gcGFja2V0IHJvdXRpbmcgY3JpdGVyaWEgKHdoZW4gbXVsdGlwbGUgb3V0cHV0cyBvbiBhbiBM RkIgYXJlIA0KICAgICAgICAgICBwcmVzZW50KTsgDQogICAgICAgIC4gcGFja2V0IHRpbWluZyBt b2RpZmljYXRpb25zOyANCiAgICAgICAgLiBwYWNrZXQgZmxvdyBvcmRlcmluZyBtb2RpZmljYXRp b25zOyANCiAgICAgICAgLiBMRkIgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbjsgDQogICAgICAgIC4g TEZCIG9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMsIGV0Yy4gDQogICAgICAgDQogICAgICBTZWN0aW9u IDQgb2YgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGRldGFpbGVkIGRpc2N1c3Npb24gb2YgdGhl IA0KICAgICAgTEZCIG1vZGVsIHdpdGggYSBmb3JtYWwgc3BlY2lmaWNhdGlvbiBvZiBMRkIgY2xh c3Mgc2NoZW1hLiAgVGhlIA0KICAgICAgcmVzdCBvZiBTZWN0aW9uIDMuMiBvbmx5IGludGVuZHMg dG8gcHJvdmlkZSBhIGNvbmNlcHR1YWwgb3ZlcnZpZXcgDQogICAgICBvZiBzb21lIGltcG9ydGFu dCBpc3N1ZXMgaW4gTEZCIG1vZGVsaW5nLCB3aXRob3V0IGNvdmVyaW5nIGFsbCB0aGUgDQogICAg ICBzcGVjaWZpYyBkZXRhaWxzLiANCiAgICAgICAgIA0KICAgMy4yLjEuIExGQiBPdXRwdXRzIA0K ICAgICAgIA0KICAgICAgQW4gTEZCIG91dHB1dCBpcyBhIGNvbmNlcHR1YWwgcG9ydCBvbiBhbiBM RkIgdGhhdCBjYW4gc2VuZCANCiAgICAgIGluZm9ybWF0aW9uIHRvIGFub3RoZXIgTEZCLiAgVGhl IGluZm9ybWF0aW9uIGlzIHR5cGljYWxseSBhIHBhY2tldCANCiAgICANCiAgIFlhbmcsIGV0IGFs LiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAx M10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgYW5kIGl0cyBhc3NvY2lhdGVkIG1l dGFkYXRhLCBhbHRob3VnaCBpbiBzb21lIGNhc2VzIGl0IG1pZ2h0IA0KICAgICAgY29uc2lzdCBv ZiBvbmx5IG1ldGFkYXRhLCBpLmUuLCB3aXRoIG5vIHBhY2tldCBkYXRhLiANCiAgICAgICANCiAg ICAgIEEgc2luZ2xlIExGQiBvdXRwdXQgY2FuIGJlIGNvbm5lY3RlZCB0byBvbmx5IG9uZSBMRkIg aW5wdXQuICBUaGlzIA0KICAgICAgaXMgcmVxdWlyZWQgdG8gbWFrZSB0aGUgcGFja2V0IGZsb3cg dGhyb3VnaCB0aGUgTEZCIHRvcG9sb2d5IA0KICAgICAgdW5hbWJpZ3VvdXNseS4gDQogICAgICAg DQogICAgICBTb21lIExGQnMgd2lsbCBoYXZlIGEgc2luZ2xlIG91dHB1dCwgYXMgZGVwaWN0ZWQg aW4gRmlndXJlIDMuYS4gDQogICAgICAgDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICB8ICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICB8ICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgT1VUICstLT4gDQogICAgICAgIC4u LiAgICAgICAgICBPVVQgKy0tPiAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgIHwgDQogICAg ICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgRVhDRVBUSU9OT1VUICst LT4gDQogICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAgIGEuIE9uZSBvdXRwdXQgICAgICAg ICAgICAgICBiLiBUd28gZGlzdGluY3Qgb3V0cHV0cyANCiAgICAgICANCiAgICAgICAgICstLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAg IHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICBFWENFUFRJT05PVVQgKy0tPiAN CiAgICAgICAgIHwgICAgICAgICBPVVQ6MSArLS0+ICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgfCANCiAgICAgICAgLi4uICAgICAgICBPVVQ6MiArLS0+ICAgICAgICAgICAuLi4gICAgICAg ICAgT1VUOjEgKy0tPiANCiAgICAgICAgIHwgICAgICAgICAuLi4gICArLi4uICAgICAgICAgICAg fCAgICAgICAgICAgT1VUOjIgKy0tPiANCiAgICAgICAgIHwgICAgICAgICBPVVQ6biArLS0+ICAg ICAgICAgICAgfCAgICAgICAgICAgLi4uICAgKy4uLiANCiAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rICAgICAgICAgICAgICAgfCAgICAgICAgICAgT1VUOm4gKy0tPiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAN CiAgICAgICAgYy4gT25lIG91dHB1dCBncm91cCAgICAgICBkLiBPbmUgb3V0cHV0IGFuZCBvbmUg b3V0cHV0IGdyb3VwIA0KICAgICAgIA0KICAgICAgRmlndXJlIDMuIEV4YW1wbGVzIG9mIExGQnMg d2l0aCB2YXJpb3VzIG91dHB1dCBjb21iaW5hdGlvbnMuIA0KICAgICAgIA0KICAgICAgVG8gYWNj b21tb2RhdGUgYSBub24tdHJpdmlhbCBMRkIgdG9wb2xvZ3ksIG11bHRpcGxlIExGQiBvdXRwdXRz IA0KICAgICAgYXJlIG5lZWRlZCBzbyB0aGF0IGFuIExGQiBjbGFzcyBjYW4gZm9yayB0aGUgZGF0 YXBhdGguICBUd28gDQogICAgICBtZWNoYW5pc21zIGFyZSBwcm92aWRlZCBmb3IgZm9ya2luZzog bXVsdGlwbGUgc2luZ2xldG9uIG91dHB1dHMgDQogICAgICBhbmQgb3V0cHV0IGdyb3Vwcywgd2hp Y2ggY2FuIGJlIGNvbWJpbmVkIGluIHRoZSBzYW1lIExGQiBjbGFzcy4gDQogICAgICAgDQogICAg ICBNdWx0aXBsZSBzZXBhcmF0ZSBzaW5nbGV0b24gb3V0cHV0cyBhcmUgZGVmaW5lZCBpbiBhbiBM RkIgY2xhc3MgdG8gDQogICAgICBtb2RlbCBhIHByZS1kZXRlcm1pbmVkIG51bWJlciBvZiBzZW1h bnRpY2FsbHkgZGlmZmVyZW50IG91dHB1dHMuIA0KICAgICAgVGhhdCBpcywgdGhlIG51bWJlciBv ZiBvdXRwdXRzIG11c3QgYmUga25vd24gd2hlbiB0aGUgTEZCIGNsYXNzIGlzIA0KICAgICAgZGVm aW5lZC4gIEFkZGl0aW9uYWwgc2luZ2xldG9uIG91dHB1dHMgY2Fubm90IGJlIGNyZWF0ZWQgYXQg TEZCIA0KICAgICAgaW5zdGFudGlhdGlvbiB0aW1lLCBub3IgY2FuIHRoZXkgYmUgY3JlYXRlZCBv biB0aGUgZmx5IGFmdGVyIHRoZSANCiAgICAgIExGQiBpcyBpbnN0YW50aWF0ZWQuIA0KICAgICAg IA0KICAgICAgRm9yIGV4YW1wbGUsIGFuIElQdjQgTFBNIChMb25nZXN0LVByZWZpeC1NYXRjaGlu ZykgTEZCIG1heSBoYXZlIA0KICAgICAgb25lIG91dHB1dChPVVQpIHRvIHNlbmQgdGhvc2UgcGFj a2V0cyBmb3Igd2hpY2ggdGhlIExQTSBsb29rLXVwIA0KICAgICAgd2FzIHN1Y2Nlc3NmdWwsIHBh c3NpbmcgYSBNRVRBX1JPVVRFSUQgYXMgbWV0YWRhdGE7IGFuZCBoYXZlIA0KICAgIA0KICAgWWFu ZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE0XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAg ICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBhbm90aGVyIG91dHB1 dCAoRVhDRVBUSU9OT1VUKSBmb3Igc2VuZGluZyBleGNlcHRpb24gcGFja2V0cyB3aGVuIA0KICAg ICAgdGhlIExQTSBsb29rLXVwIGZhaWxlZC4gIFRoaXMgZXhhbXBsZSBpcyBkZXBpY3RlZCBpbiBG aWd1cmUgMy5iLiAgDQogICAgICBQYWNrZXRzIGVtaXR0ZWQgYnkgdGhlc2UgdHdvIG91dHB1dHMg bm90IG9ubHkgcmVxdWlyZSBkaWZmZXJlbnQgDQogICAgICBkb3duc3RyZWFtIHRyZWF0bWVudCwg YnV0IHRoZXkgYXJlIGEgcmVzdWx0IG9mIHR3byBkaWZmZXJlbnQgDQogICAgICBjb25kaXRpb25z IGluIHRoZSBMRkIgYW5kIGVhY2ggb3V0cHV0IGNhcnJpZXMgZGlmZmVyZW50IG1ldGFkYXRhLiAg DQogICAgICBUaGlzIGNvbmNlcHQgYXNzdW1lcyB0aGUgbnVtYmVyIG9mIGRpc3RpbmN0IG91dHB1 dHMgaXMga25vd24gd2hlbiANCiAgICAgIHRoZSBMRkIgY2xhc3MgaXMgZGVmaW5lZC4gRm9yIGVh Y2ggc2luZ2xldG9uIG91dHB1dCwgdGhlIExGQiBjbGFzcyANCiAgICAgIGRlZmluaXRpb24gZGVm aW5lcyB0aGUgdHlwZXMgb2YgZnJhbWVzIGFuZCBtZXRhZGF0YSB0aGUgb3V0cHV0IA0KICAgICAg ZW1pdHMuIA0KICAgICAgIA0KICAgICAgQW4gb3V0cHV0IGdyb3VwLCBvbiB0aGUgb3RoZXIgaGFu ZCwgaXMgdXNlZCB0byBtb2RlbCB0aGUgY2FzZSANCiAgICAgIHdoZXJlIGEgZmxvdyBvZiBzaW1p bGFyIHBhY2tldHMgd2l0aCBhbiBpZGVudGljYWwgc2V0IG9mIG1ldGFkYXRhIA0KICAgICAgbmVl ZHMgdG8gYmUgc3BsaXQgaW50byBtdWx0aXBsZSBwYXRocy4gSW4gdGhpcyBjYXNlLCB0aGUgbnVt YmVyIG9mIA0KICAgICAgc3VjaCBwYXRocyBpcyBub3Qga25vd24gd2hlbiB0aGUgTEZCIGNsYXNz IGlzIGRlZmluZWQgYmVjYXVzZSBpdCANCiAgICAgIGlzIG5vdCBhbiBpbmhlcmVudCBwcm9wZXJ0 eSBvZiB0aGUgTEZCIGNsYXNzLiAgQW4gb3V0cHV0IGdyb3VwIA0KICAgICAgY29uc2lzdHMgb2Yg YSBudW1iZXIgb2Ygb3V0cHV0cywgY2FsbGVkIHRoZSBvdXRwdXQgaW5zdGFuY2VzIG9mIA0KICAg ICAgdGhlIGdyb3VwLCB3aGVyZSBhbGwgb3V0cHV0IGluc3RhbmNlcyBzaGFyZSB0aGUgc2FtZSBm cmFtZSBhbmQgDQogICAgICBtZXRhZGF0YSBlbWlzc2lvbiBkZWZpbml0aW9ucyAoc2VlIEZpZ3Vy ZSAzLmMpLiAgRWFjaCBvdXRwdXQgDQogICAgICBpbnN0YW5jZSBjYW4gY29ubmVjdCB0byBhIGRp ZmZlcmVudCBkb3duc3RyZWFtIExGQiwganVzdCBhcyBpZiANCiAgICAgIHRoZXkgd2VyZSBzZXBh cmF0ZSBzaW5nbGV0b24gb3V0cHV0cywgYnV0IHRoZSBudW1iZXIgb2Ygb3V0cHV0IA0KICAgICAg aW5zdGFuY2VzIGNhbiBkaWZmZXIgYmV0d2VlbiBMRkIgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIExG QiBjbGFzcy4gIA0KICAgICAgVGhlIGNsYXNzIGRlZmluaXRpb24gbWF5IGluY2x1ZGUgYSBsb3dl ciBhbmQvb3IgYW4gdXBwZXIgbGltaXQgb24gDQogICAgICB0aGUgbnVtYmVyIG9mIG91dHB1dHMu ICBJbiBhZGRpdGlvbiwgZm9yIGNvbmZpZ3VyYWJsZSBGRXMsIHRoZSBGRSANCiAgICAgIGNhcGFi aWxpdHkgaW5mb3JtYXRpb24gbWF5IGRlZmluZSBmdXJ0aGVyIGxpbWl0cyBvbiB0aGUgbnVtYmVy IG9mIA0KICAgICAgaW5zdGFuY2VzIGluIHNwZWNpZmljIG91dHB1dCBncm91cHMgZm9yIGNlcnRh aW4gTEZCcy4gIFRoZSBhY3R1YWwgDQogICAgICBudW1iZXIgb2Ygb3V0cHV0IGluc3RhbmNlcyBp biBhIGdyb3VwIGlzIGFuIGF0dHJpYnV0ZSBvZiB0aGUgTEZCIA0KICAgICAgaW5zdGFuY2UsIHdo aWNoIGlzIHJlYWQtb25seSBmb3Igc3RhdGljIHRvcG9sb2dpZXMsIGFuZCByZWFkLXdyaXRlIA0K ICAgICAgZm9yIGR5bmFtaWMgdG9wb2xvZ2llcy4gIFRoZSBvdXRwdXQgaW5zdGFuY2VzIGluIGEg Z3JvdXAgYXJlIA0KICAgICAgbnVtYmVyZWQgc2VxdWVudGlhbGx5LCBmcm9tIDAgdG8gTi0xLCBh bmQgYXJlIGFkZHJlc3NhYmxlIGZyb20gDQogICAgICB3aXRoaW4gdGhlIExGQi4gIFRoZSBMRkIg aGFzIGEgYnVpbHQtaW4gbWVjaGFuaXNtIHRvIHNlbGVjdCBvbmUgDQogICAgICBzcGVjaWZpYyBv dXRwdXQgaW5zdGFuY2UgZm9yIGVhY2ggcGFja2V0LiAgVGhpcyBtZWNoYW5pc20gaXMgDQogICAg ICBkZXNjcmliZWQgaW4gdGhlIHRleHR1YWwgZGVmaW5pdGlvbiBvZiB0aGUgY2xhc3MgYW5kIGlz IHR5cGljYWxseSANCiAgICAgIGNvbmZpZ3VyYWJsZSB2aWEgc29tZSBhdHRyaWJ1dGVzIG9mIHRo ZSBMRkIuIA0KICAgICAgIA0KICAgICAgRm9yIGV4YW1wbGUsIGNvbnNpZGVyIGEgcmUtZGlyZWN0 b3IgTEZCLCB3aG9zZSBzb2xlIHB1cnBvc2UgaXMgdG8gDQogICAgICBkaXJlY3QgcGFja2V0cyB0 byBvbmUgb2YgTiBkb3duc3RyZWFtIHBhdGhzIGJhc2VkIG9uIG9uZSBvZiB0aGUgDQogICAgICBt ZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggZWFjaCBhcnJpdmluZyBwYWNrZXQuICBTdWNoIGFuIExG QiBpcyANCiAgICAgIGZhaXJseSB2ZXJzYXRpbGUgYW5kIGNhbiBiZSB1c2VkIGluIG1hbnkgZGlm ZmVyZW50IHBsYWNlcyBpbiBhIA0KICAgICAgdG9wb2xvZ3kuICBGb3IgZXhhbXBsZSwgYSByZWRp cmVjdG9yIGNhbiBiZSB1c2VkIHRvIGRpdmlkZSB0aGUgDQogICAgICBkYXRhIHBhdGggaW50byBh biBJUHY0IGFuZCBhbiBJUHY2IHBhdGggYmFzZWQgb24gYSBGUkFNRVRZUEUgDQogICAgICBtZXRh ZGF0YSAoTj0yKSwgb3IgdG8gZm9yayBpbnRvIGNvbG9yIHNwZWNpZmljIHBhdGhzIGFmdGVyIA0K ICAgICAgbWV0ZXJpbmcgdXNpbmcgdGhlIENPTE9SIG1ldGFkYXRhIChyZWQsIHllbGxvdywgZ3Jl ZW47IE49MyksIGV0Yy4gDQogICAgICAgDQogICAgICBVc2luZyBhbiBvdXRwdXQgZ3JvdXAgaW4g dGhlIGFib3ZlIExGQiBjbGFzcyBwcm92aWRlcyB0aGUgZGVzaXJlZCANCiAgICAgIGZsZXhpYmls aXR5IHRvIGFkYXB0IGVhY2ggaW5zdGFuY2Ugb2YgdGhpcyBjbGFzcyB0byB0aGUgcmVxdWlyZWQg DQogICAgICBvcGVyYXRpb24uICBUaGUgbWV0YWRhdGEgdG8gYmUgdXNlZCBhcyBhIHNlbGVjdG9y IGZvciB0aGUgb3V0cHV0IA0KICAgICAgaW5zdGFuY2UgaXMgYSBwcm9wZXJ0eSBvZiB0aGUgTEZC LiAgRm9yIGVhY2ggcGFja2V0LCB0aGUgdmFsdWUgb2YgDQogICAgDQogICBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTVd IA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHRoZSBzcGVjaWZpZWQgbWV0YWRhdGEg bWF5IGJlIHVzZWQgYXMgYSBkaXJlY3QgaW5kZXggdG8gdGhlIG91dHB1dCANCiAgICAgIGluc3Rh bmNlLiAgQWx0ZXJuYXRpdmVseSwgdGhlIExGQiBtYXkgaGF2ZSBhIGNvbmZpZ3VyYWJsZSBzZWxl Y3RvciANCiAgICAgIHRhYmxlIHRoYXQgbWFwcyBhIG1ldGFkYXRhIHZhbHVlIHRvIG91dHB1dCBp bnN0YW5jZS4gDQogICAgICAgDQogICAgICBOb3RlIHRoYXQgb3RoZXIgTEZCcyBtYXkgYWxzbyB1 c2UgdGhlIG91dHB1dCBncm91cCBjb25jZXB0IHRvIA0KICAgICAgYnVpbGQgaW4gc2ltaWxhciBh ZGFwdGl2ZSBmb3JraW5nIGNhcGFiaWxpdHkuICBGb3IgZXhhbXBsZSwgYSANCiAgICAgIGNsYXNz aWZpZXIgTEZCIHdpdGggb25lIGlucHV0IGFuZCBOIG91dHB1dHMgY2FuIGJlIGRlZmluZWQgZWFz aWx5IA0KICAgICAgYnkgdXNpbmcgdGhlIG91dHB1dCBncm91cCBjb25jZXB0LiAgQWx0ZXJuYXRp dmVseSwgYSBjbGFzc2lmaWVyIA0KICAgICAgTEZCIHdpdGggb25lIHNpbmdsZXRvbiBvdXRwdXQg aW4gY29tYmluYXRpb24gd2l0aCBhbiBleHBsaWNpdCBOLQ0KICAgICAgb3V0cHV0IHJlLWRpcmVj dG9yIExGQiBtb2RlbHMgdGhlIHNhbWUgcHJvY2Vzc2luZyBiZWhhdmlvci4gIFRoZSANCiAgICAg IGRlY2lzaW9uIG9mIHdoZXRoZXIgdG8gdXNlIHRoZSBvdXRwdXQgZ3JvdXAgbW9kZWwgZm9yIGEg Y2VydGFpbiANCiAgICAgIExGQiBjbGFzcyBpcyBsZWZ0IHRvIHRoZSBMRkIgY2xhc3MgZGVzaWdu ZXJzLiANCiAgICAgICANCiAgICAgIFRoZSBtb2RlbCBhbGxvd3MgdGhlIG91dHB1dCBncm91cCBi ZSBjb21iaW5lZCB3aXRoIG90aGVyIHNpbmdsZXRvbiANCiAgICAgIG91dHB1dChzKSBpbiB0aGUg c2FtZSBjbGFzcywgYXMgZGVtb25zdHJhdGVkIGluIEZpZ3VyZSAzLmQuICBUaGUgDQogICAgICBM RkIgaGVyZSBoYXMgdHdvIHR5cGVzIG9mIG91dHB1dHMsIE9VVCwgZm9yIG5vcm1hbCBwYWNrZXQg b3V0cHV0LCANCiAgICAgIGFuZCBFWENFUFRJT05PVVQgZm9yIHBhY2tldHMgdGhhdCB0cmlnZ2Vy ZWQgc29tZSBleGNlcHRpb24uICBUaGUgDQogICAgICBub3JtYWwgT1VUIGhhcyBtdWx0aXBsZSBp bnN0YW5jZXMsIHRodXMsIGl0IGlzIGFuIG91dHB1dCBncm91cC4gDQogICAgICAgDQogICAgICBJ biBzdW1tYXJ5LCB0aGUgTEZCIGNsYXNzIG1heSBkZWZpbmUgb25lIG91dHB1dCwgbXVsdGlwbGUg DQogICAgICBzaW5nbGV0b24gb3V0cHV0cywgb25lIG9yIG1vcmUgb3V0cHV0IGdyb3Vwcywgb3Ig YSBjb21iaW5hdGlvbiANCiAgICAgIHRoZXJlb2YuIE11bHRpcGxlIHNpbmdsZXRvbiBvdXRwdXRz IHNob3VsZCBiZSB1c2VkIHdoZW4gdGhlIExGQiANCiAgICAgIG11c3QgcHJvdmlkZSBmb3IgZm9y a2luZyB0aGUgZGF0YXBhdGgsIGFuZCBhdCBsZWFzdCBvbmUgb2YgdGhlIA0KICAgICAgZm9sbG93 aW5nIGNvbmRpdGlvbnMgaG9sZDogDQogICAgICAgIC4gdGhlIG51bWJlciBvZiBkb3duc3RyZWFt IGRpcmVjdGlvbnMgYXJlIGluaGVyZW50IGZyb20gdGhlIA0KICAgICAgICAgICBkZWZpbml0aW9u IG9mIHRoZSBjbGFzcyBhbmQgaGVuY2UgZml4ZWQ7IA0KICAgICAgICAuIHRoZSBmcmFtZSB0eXBl IGFuZCBzZXQgb2YgbWV0YWRhdGEgZW1pdHRlZCBvbiBhbnkgb2YgdGhlIA0KICAgICAgICAgICBv dXRwdXRzIGFyZSBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBmcm9tIHdoYXQgaXMgZW1pdHRlZCBv biAgDQogICAgICAgICAgIHRoZSBvdGhlciAgb3V0cHV0cyAoaS5lLiwgdGhleSBjYW5ub3Qgc2hh cmUgZnJhbWUtdHlwZSBhbmQgDQogICAgICAgICAgIG1ldGFkYXRhIGRlZmluaXRpb25zKTsgDQog ICAgICAgDQogICAgICBBbiBvdXRwdXQgZ3JvdXAgaXMgYXBwcm9wcmlhdGUgd2hlbiB0aGUgTEZC IG11c3QgcHJvdmlkZSBmb3IgDQogICAgICBmb3JraW5nIHRoZSBkYXRhcGF0aCwgYW5kIGF0IGxl YXN0IG9uZSBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgDQogICAgICBob2xkOiANCiAgICAg ICAgLiB0aGUgbnVtYmVyIG9mIGRvd25zdHJlYW0gZGlyZWN0aW9ucyBpcyBub3Qga25vd24gd2hl biB0aGUgTEZCIA0KICAgICAgICAgICBjbGFzcyBpcyBkZWZpbmVkOyANCiAgICAgICAgLiB0aGUg ZnJhbWUgdHlwZSBhbmQgc2V0IG9mIG1ldGFkYXRhIGVtaXR0ZWQgb24gdGhlc2Ugb3V0cHV0cyAN CiAgICAgICAgICAgYXJlIHN1ZmZpY2llbnRseSBzaW1pbGFyIG9yIGlkZWFsbHkgaWRlbnRpY2Fs LCBzdWNoIHRoZXkgY2FuIA0KICAgICAgICAgICBzaGFyZSB0aGUgc2FtZSBvdXRwdXQgZGVmaW5p dGlvbi4gDQogICAgICAgDQogICAzLjIuMi4gTEZCIElucHV0cyANCiAgICAgICANCiAgICAgIEFu IExGQiBpbnB1dCBpcyBhIGNvbmNlcHR1YWwgcG9ydCBvbiBhbiBMRkIgd2hlcmUgdGhlIExGQiBj YW4gDQogICAgICByZWNlaXZlIGluZm9ybWF0aW9uIGZyb20gb3RoZXIgTEZCcy4gIFRoZSBpbmZv cm1hdGlvbiBpcyB0eXBpY2FsbHkgDQogICAgICBhIHBhY2tldCBhbmQgYXNzb2NpYXRlZCBtZXRh ZGF0YSwgYWx0aG91Z2ggaW4gc29tZSBjYXNlcyBpdCBtaWdodCANCiAgICAgIGNvbnNpc3Qgb2Yg b25seSBtZXRhZGF0YSwgd2l0aG91dCBhbnkgcGFja2V0IGRhdGEuIA0KICAgICAgIA0KICAgIA0K ICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDE2XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBN b2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBGb3IgTEZC IGluc3RhbmNlcyB0aGF0IHJlY2VpdmUgcGFja2V0cyBmcm9tIG1vcmUgdGhhbiBvbmUgb3RoZXIg DQogICAgICBMRkIgaW5zdGFuY2UgKGZhbi1pbikuIFRoZXJlIGFyZSB0aHJlZSB3YXlzIHRvIG1v ZGVsIGZhbi1pbiwgYWxsIA0KICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBMRkIgbW9kZWwgYW5kIGNh biBiZSBjb21iaW5lZCBpbiB0aGUgc2FtZSBMRkI6IA0KICAgICAgICAuIEltcGxpY2l0IG11bHRp cGxleGluZyB2aWEgYSBzaW5nbGUgaW5wdXQgDQogICAgICAgIC4gRXhwbGljaXQgbXVsdGlwbGV4 aW5nIHZpYSBtdWx0aXBsZSBzaW5nbGV0b24gaW5wdXRzIA0KICAgICAgICAuIEV4cGxpY2l0IG11 bHRpcGxleGluZyB2aWEgYSBncm91cCBvZiBpbnB1dHMgKGlucHV0IGdyb3VwKSANCiAgICAgICAN CiAgICAgIFRoZSBzaW1wbGVzdCBmb3JtIG9mIG11bHRpcGxleGluZyB1c2VzIGEgc2luZ2xldG9u IGlucHV0IChGaWd1cmUgDQogICAgICA0LmEpLiAgTW9zdCBMRkJzIHdpbGwgaGF2ZSBvbmx5IG9u ZSBzaW5nbGV0b24gaW5wdXQuICBNdWx0aXBsZXhpbmcgDQogICAgICBpbnRvIGEgc2luZ2xlIGlu cHV0IGlzIHBvc3NpYmxlIGJlY2F1c2UgdGhlIG1vZGVsIGFsbG93cyBtb3JlIHRoYW4gDQogICAg ICBvbmUgTEZCIG91dHB1dCB0byBjb25uZWN0IHRvIHRoZSBzYW1lIExGQiBpbnB1dC4gIFRoaXMg cHJvcGVydHkgDQogICAgICBhcHBsaWVzIHRvIGFueSBMRkIgaW5wdXQgd2l0aG91dCBhbnkgc3Bl Y2lhbCBwcm92aXNpb25zIGluIHRoZSBMRkIgDQogICAgICBjbGFzcy4gIE11bHRpcGxleGluZyBp bnRvIGEgc2luZ2xlIGlucHV0IGlzIGFwcGxpY2FibGUgd2hlbiB0aGUgDQogICAgICBwYWNrZXRz IGZyb20gdGhlIHVwc3RyZWFtIExGQnMgYXJlIHNpbWlsYXIgaW4gZnJhbWUtdHlwZSBhbmQgDQog ICAgICBhY2NvbXBhbnlpbmcgbWV0YWRhdGEsIGFuZCByZXF1aXJlIHNpbWlsYXIgcHJvY2Vzc2lu Zy4gIE5vdGUgdGhhdCANCiAgICAgIHRoaXMgbW9kZWwgZG9lcyBub3QgYWRkcmVzcyBob3cgcG90 ZW50aWFsIGNvbnRlbnRpb24gaXMgaGFuZGxlZCANCiAgICAgIHdoZW4gbXVsdGlwbGUgcGFja2V0 cyBhcnJpdmUgc2ltdWx0YW5lb3VzbHkuICBJZiBjb250ZW50aW9uIA0KICAgICAgaGFuZGxpbmcg bmVlZHMgdG8gYmUgZXhwbGljaXRseSBtb2RlbGVkLCBvbmUgb2YgdGhlIG90aGVyIHR3byANCiAg ICAgIG1vZGVsaW5nIHNvbHV0aW9ucyBtdXN0IGJlIHVzZWQuIA0KICAgICAgIA0KICAgICAgVGhl IHNlY29uZCBtZXRob2QgdG8gbW9kZWwgZmFuLWluIHVzZXMgaW5kaXZpZHVhbGx5IGRlZmluZWQg DQogICAgICBzaW5nbGV0b24gaW5wdXRzIChGaWd1cmUgNC5iKS4gIFRoaXMgbW9kZWwgaXMgbWVh bnQgZm9yIHNpdHVhdGlvbnMgDQogICAgICB3aGVyZSB0aGUgTEZCIG5lZWRzIHRvIGhhbmRsZSBk aXN0aW5jdCB0eXBlcyBvZiBwYWNrZXQgc3RyZWFtcywgDQogICAgICByZXF1aXJpbmcgaW5wdXQt c3BlY2lmaWMgaGFuZGxpbmcgaW5zaWRlIHRoZSBMRkIsIGFuZCB3aGVyZSB0aGUgDQogICAgICBu dW1iZXIgb2Ygc3VjaCBkaXN0aW5jdCBjYXNlcyBpcyBrbm93biB3aGVuIHRoZSBMRkIgY2xhc3Mg aXMgDQogICAgICBkZWZpbmVkLiAgRm9yIGV4YW1wbGUsIGEgTGF5ZXIgMiBEZWNhcHN1bGF0aW9u L0VuY2Fwc3VsYXRpb24gTEZCIA0KICAgICAgbWF5IGhhdmUgdHdvIGlucHV0cywgb25lIGZvciBy ZWNlaXZpbmcgTGF5ZXIgMiBmcmFtZXMgZm9yIA0KICAgICAgZGVjYXBzdWxhdGlvbiwgYW5kIG9u ZSBmb3IgcmVjZWl2aW5nIExheWVyIDMgZnJhbWVzIGZvciANCiAgICAgIGVuY2Fwc3VsYXRpb24u ICBUaGlzIExGQiB0eXBlIGV4cGVjdHMgZGlmZmVyZW50IGZyYW1lcyAoTDIgdnMuIEwzKSANCiAg ICAgIGF0IGl0cyBpbnB1dHMsIGVhY2ggd2l0aCBkaWZmZXJlbnQgc2V0cyBvZiBtZXRhZGF0YSwg YW5kIHdvdWxkIA0KICAgICAgdGh1cyBhcHBseSBkaWZmZXJlbnQgcHJvY2Vzc2luZyBvbiBmcmFt ZXMgYXJyaXZpbmcgYXQgdGhlc2UgDQogICAgICBpbnB1dHMuICBUaGlzIG1vZGVsIGlzIGNhcGFi bGUgb2YgZXhwbGljaXRseSBhZGRyZXNzaW5nIHBhY2tldCANCiAgICAgIGNvbnRlbnRpb24gYnkg ZGVmaW5pbmcgaG93IHRoZSBMRkIgY2xhc3MgaGFuZGxlcyB0aGUgY29udGVuZGluZyANCiAgICAg IHBhY2tldHMuIA0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgIA0KICAgWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDE3XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICAg ICAgICAgICAgICB8IExGQiBYICAgICAgICArLS0tKyAgIHwgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICB8ICAgfCAgICAgICAg ICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0rICAgdiAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAg ICAgICAgICAgIHwgTEZCIFkgICAgICAgICstLS0rLS0+fGlucHV0ICAgICBNZXRlciBMRkIgICAg IHwgDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgIF4gICB8ICAgICAgICAg ICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLSsgICB8ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAg ICAgICAgICAgfCBMRkIgWiAgICAgICAgfC0tLSsgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rIA0KICAgIA0KICAgICAgKGEpIEFuIExGQiBjb25uZWN0cyB3aXRoIG11 bHRpcGxlIHVwc3RyZWFtIExGQnMgdmlhIGEgc2luZ2xlIA0KICAgICAgaW5wdXQuIA0KICAgICAg IA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAgfCBMRkIgWCAgICAgICAgKy0tLSsg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0rICAgKy0tPnxsYXllcjIgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICAgICAgICAgICAgfCBMRkIgWSAgICAgICAgKy0tLS0tLT58bGF5ZXIzICAgICBM RkIgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgIA0KICAgICAgKGIpIEFuIExGQiBj b25uZWN0cyB3aXRoIG11bHRpcGxlIHVwc3RyZWFtIExGQnMgdmlhIHR3byBzZXBhcmF0ZSANCiAg ICAgICAgICBzaW5nbGV0b24gaW5wdXRzLiANCiAgICAgICANCiAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAg ICAgICAgICAgICAgIHwgUXVldWUgTEZCICMxICstLS0rICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIHwgDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgIHwgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLSsgICArLS0+fGluOjAgICBcICAgICAgICAgICAgICAgIHwgDQogICAgICAg ICAgICAgICAgICAgfCBRdWV1ZSBMRkIgIzIgKy0tLS0tLT58aW46MSAgIHwgaW5wdXQgZ3JvdXAg ICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgIHwuLi4gICAg fCAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0+fGluOk4tMSAvICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgLi4u ICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICAgICAgICAgIHwgUXVldWUgTEZCICNOIHwtLS0rICAgfCAgICAgU2No ZWR1bGVyIExGQiAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAgICANCiAgICAgIChjKSBBIFNj aGVkdWxlciBMRkIgdXNlcyBhbiBpbnB1dCBncm91cCB0byBkaWZmZXJlbnRpYXRlIHdoaWNoIA0K ICAgICAgcXVldWUgTEZCIHBhY2tldHMgYXJlIGNvbWluZyBmcm9tLiANCiAgICAgICANCiAgICAg ICAgICAgICAgICBGaWd1cmUgMy4gSW5wdXQgbW9kZWxpbmcgY29uY2VwdHMgKGV4YW1wbGVzKS4g DQogICAgICAgDQogICAgICBUaGUgdGhpcmQgbWV0aG9kIHRvIG1vZGVsIGZhbi1pbiB1c2VzIHRo ZSBjb25jZXB0IG9mIGFuIGlucHV0IA0KICAgICAgZ3JvdXAuICBUaGUgY29uY2VwdCBpcyBzaW1p bGFyIHRvIHRoZSBvdXRwdXQgZ3JvdXAgaW50cm9kdWNlZCBpbiANCiAgICAgIHRoZSBwcmV2aW91 cyBzZWN0aW9uLCBhbmQgaXMgZGVwaWN0ZWQgaW4gRmlndXJlIDQuYy4gIEFuIGlucHV0IA0KICAg ICAgZ3JvdXAgY29uc2lzdHMgb2YgYSBudW1iZXIgb2YgaW5wdXQgaW5zdGFuY2VzLCBhbGwgc2hh cmluZyB0aGUgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdIA0KDCAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAg ICANCiAgICAgIHByb3BlcnRpZXMgKHNhbWUgZnJhbWUgYW5kIG1ldGFkYXRhIGV4cGVjdGF0aW9u cykuICBUaGUgaW5wdXQgDQogICAgICBpbnN0YW5jZXMgYXJlIG51bWJlcmVkIGZyb20gMCB0byBO LTEuICBGcm9tIHRoZSBvdXRzaWRlLCB0aGVzZSANCiAgICAgIGlucHV0cyBhcHBlYXIgYXMgbm9y bWFsIGlucHV0cywgaS5lLiwgYW55IGNvbXBhdGlibGUgdXBzdHJlYW0gTEZCIA0KICAgICAgY2Fu IGNvbm5lY3QgaXRzIG91dHB1dCB0byBvbmUgb2YgdGhlc2UgaW5wdXRzLiAgV2hlbiBhIHBhY2tl dCBpcyANCiAgICAgIHByZXNlbnRlZCB0byB0aGUgTEZCIGF0IGEgcGFydGljdWxhciBpbnB1dCBp bnN0YW5jZSwgdGhlIGluZGV4IG9mIA0KICAgICAgdGhlIGlucHV0IHdoZXJlIHRoZSBwYWNrZXQg YXJyaXZlZCBpcyBrbm93biB0byB0aGUgTEZCIGFuZCB0aGlzIA0KICAgICAgaW5mb3JtYXRpb24g bWF5IGJlIHVzZWQgaW4gdGhlIGludGVybmFsIHByb2Nlc3NpbmcuICBGb3IgZXhhbXBsZSwgDQog ICAgICB0aGUgaW5wdXQgaW5kZXggY2FuIGJlIHVzZWQgYXMgYSB0YWJsZSBzZWxlY3Rvciwgb3Ig YXMgYW4gZXhwbGljaXQgDQogICAgICBwcmVjZWRlbmNlIHNlbGVjdG9yIHRvIHJlc29sdmUgY29u dGVudGlvbi4gIEFzIHdpdGggb3V0cHV0IGdyb3VwcywgDQogICAgICB0aGUgbnVtYmVyIG9mIGlu cHV0IGluc3RhbmNlcyBpbiBhbiBpbnB1dCBncm91cCBpcyBub3QgZGVmaW5lZCBpbiANCiAgICAg IHRoZSBMRkIgY2xhc3MuICBIb3dldmVyLCB0aGUgY2xhc3MgZGVmaW5pdGlvbiBtYXkgaW5jbHVk ZSANCiAgICAgIHJlc3RyaWN0aW9ucyBvbiB0aGUgcmFuZ2Ugb2YgcG9zc2libGUgdmFsdWVzLiAg SW4gYWRkaXRpb24sIGlmIGFuIA0KICAgICAgRkUgc3VwcG9ydHMgY29uZmlndXJhYmxlIHRvcG9s b2dpZXMsIGl0IG1heSBpbXBvc2UgZnVydGhlciANCiAgICAgIGxpbWl0YXRpb25zIG9uIHRoZSBu dW1iZXIgb2YgaW5zdGFuY2VzIGZvciBhIHBhcnRpY3VsYXIgcG9ydCANCiAgICAgIGdyb3VwKHMp IG9mIGEgcGFydGljdWxhciBMRkIgY2xhc3MuICBXaXRoaW4gdGhlc2UgbGltaXRhdGlvbnMsIA0K ICAgICAgZGlmZmVyZW50IGluc3RhbmNlcyBvZiB0aGUgc2FtZSBjbGFzcyBtYXkgaGF2ZSBhIGRp ZmZlcmVudCBudW1iZXIgDQogICAgICBvZiBpbnB1dCBpbnN0YW5jZXMuICBUaGUgbnVtYmVyIG9m IGFjdHVhbCBpbnB1dCBpbnN0YW5jZXMgaW4gdGhlIA0KICAgICAgZ3JvdXAgaXMgYW4gYXR0cmli dXRlIG9mIHRoZSBMRkIgY2xhc3MsIHdoaWNoIGlzIHJlYWQtb25seSBmb3IgDQogICAgICBzdGF0 aWMgdG9wb2xvZ2llcywgYW5kIGlzIHJlYWQtd3JpdGUgZm9yIGNvbmZpZ3VyYWJsZSB0b3BvbG9n aWVzLiANCiAgICAgICANCiAgICAgIEFzIGFuIGV4YW1wbGUgZm9yIHRoZSBpbnB1dCBncm91cCwg Y29uc2lkZXIgdGhlIFNjaGVkdWxlciBMRkIgDQogICAgICBkZXBpY3RlZCBpbiBGaWd1cmUgMy5j LiAgU3VjaCBhbiBMRkIgcmVjZWl2ZXMgcGFja2V0cyBmcm9tIGEgDQogICAgICBudW1iZXIgb2Yg UXVldWUgTEZCcyB2aWEgYSBudW1iZXIgb2YgaW5wdXQgaW5zdGFuY2VzLCBhbmQgdXNlcyB0aGUg DQogICAgICBpbnB1dCBpbmRleCBpbmZvcm1hdGlvbiB0byBjb250cm9sIGNvbnRlbnRpb24gcmVz b2x1dGlvbiBhbmQgDQogICAgICBzY2hlZHVsaW5nLiANCiAgICAgICANCiAgICAgIEluIHN1bW1h cnksIHRoZSBMRkIgY2xhc3MgbWF5IGRlZmluZSBvbmUgaW5wdXQsIG11bHRpcGxlIHNpbmdsZXRv biANCiAgICAgIGlucHV0cywgb25lIG9yIG1vcmUgaW5wdXQgZ3JvdXBzLCBvciBhIGNvbWJpbmF0 aW9uIHRoZXJlb2YuICBBbnkgDQogICAgICBpbnB1dCBhbGxvd3MgZm9yIGltcGxpY2l0IG11bHRp cGxleGluZyBvZiBzaW1pbGFyIHBhY2tldCBzdHJlYW1zIA0KICAgICAgdmlhIGNvbm5lY3Rpbmcg bXVsdGlwbGUgb3V0cHV0cyB0byB0aGUgc2FtZSBpbnB1dC4gIEV4cGxpY2l0IA0KICAgICAgbXVs dGlwbGUgc2luZ2xldG9uIGlucHV0cyBhcmUgdXNlZnVsIHdoZW4gZWl0aGVyIHRoZSBjb250ZW50 aW9uIA0KICAgICAgaGFuZGxpbmcgbXVzdCBiZSBoYW5kbGVkIGV4cGxpY2l0bHksIG9yIHdoZW4g dGhlIExGQiBjbGFzcyBtdXN0IA0KICAgICAgcmVjZWl2ZSBhbmQgcHJvY2VzcyBhIGtub3duIG51 bWJlciBvZiBkaXN0aW5jdCB0eXBlcyBvZiBwYWNrZXQgDQogICAgICBzdHJlYW1zLiAgQW4gaW5w dXQgZ3JvdXAgaXMgc3VpdGFibGUgd2hlbiBjb250ZW50aW9uIGhhbmRsaW5nIG11c3QgDQogICAg ICBiZSBtb2RlbGVkIGV4cGxpY2l0bHksIGJ1dCB0aGUgbnVtYmVyIG9mIGlucHV0cyBhcmUgbm90 IGluaGVyZW50IA0KICAgICAgZnJvbSB0aGUgY2xhc3MgKGFuZCBoZW5jZSBpcyBub3Qga25vd24g d2hlbiB0aGUgY2xhc3MgaXMgZGVmaW5lZCksIA0KICAgICAgb3Igd2hlbiBpdCBpcyBjcml0aWNh bCBmb3IgTEZCIG9wZXJhdGlvbiB0byBrbm93IGV4YWN0bHkgb24gd2hpY2ggDQogICAgICBpbnB1 dCB0aGUgcGFja2V0IHdhcyByZWNlaXZlZC4gDQogICAgDQogICAzLjIuMy4gUGFja2V0IFR5cGUg DQogICAgICAgDQogICAgICBXaGVuIExGQiBjbGFzc2VzIGFyZSBkZWZpbmVkLCB0aGUgaW5wdXQg YW5kIG91dHB1dCBwYWNrZXQgZm9ybWF0cyANCiAgICAgIChlLmcuLCBJUHY0LCBJUHY2LCBFdGhl cm5ldCwgZXRjLikgbXVzdCBiZSBzcGVjaWZpZWQuICBUaGVzZSBhcmUgDQogICAgICB0aGUgdHlw ZXMgb2YgcGFja2V0cyBhIGdpdmVuIExGQiBpbnB1dCBpcyBjYXBhYmxlIG9mIHJlY2VpdmluZyBh bmQgDQogICAgICBwcm9jZXNzaW5nLCBvciBhIGdpdmVuIExGQiBvdXRwdXQgaXMgY2FwYWJsZSBv ZiBwcm9kdWNpbmcuICBUaGlzIA0KICAgICAgcmVxdWlyZXMgZGlzdGluY3QgcGFja2V0IHR5cGVz IGJlIHVuaXF1ZWx5IGxhYmVsZWQgd2l0aCBhIHN5bWJvbGljIA0KICAgICAgbmFtZSBhbmQvb3Ig SUQuIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg IEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQog ICAgICAgDQogICAgICBOb3RlIHRoYXQgZWFjaCBMRkIgaGFzIGEgc2V0IG9mIHBhY2tldCB0eXBl cyB0aGF0IGl0IG9wZXJhdGVzIG9uLCANCiAgICAgIGJ1dCBkb2VzIG5vdCBjYXJlIHdoZXRoZXIg dGhlIHVuZGVybHlpbmcgaW1wbGVtZW50YXRpb24gaXMgcGFzc2luZyANCiAgICAgIGEgZ3JlYXRl ciBwb3J0aW9uIG9mIHRoZSBwYWNrZXRzLiAgRm9yIGV4YW1wbGUsIGFuIElQdjQgTEZCIG1pZ2h0 IA0KICAgICAgb25seSBvcGVyYXRlIG9uIElQdjQgcGFja2V0cywgYnV0IHRoZSB1bmRlcmx5aW5n IGltcGxlbWVudGF0aW9uIA0KICAgICAgbWF5IG9yIG1heSBub3QgYmUgc3RyaXBwaW5nIHRoZSBM MiBoZWFkZXIgYmVmb3JlIGhhbmRpbmcgaXQgb3ZlciAtDQogICAgICAtIHdoZXRoZXIgdGhhdCBp cyBoYXBwZW5pbmcgb3Igbm90IGlzIG9wYXF1ZSB0byB0aGUgQ0UuIA0KICAgIA0KICAgMy4yLjQu IE1ldGFkYXRhIA0KICAgICAgIA0KICAgICAgTWV0YWRhdGEgaXMgdGhlIHBlci1wYWNrZXQgc3Rh dGUgdGhhdCBpcyBwYXNzZWQgZnJvbSBvbmUgTEZCIHRvIA0KICAgICAgYW5vdGhlci4gVGhlIG1l dGFkYXRhIGlzIHBhc3NlZCB3aXRoIHRoZSBwYWNrZXQgdG8gYXNzaXN0IA0KICAgICAgc3Vic2Vx dWVudCBMRkJzIHRvIHByb2Nlc3MgdGhhdCBwYWNrZXQuICBUaGUgRm9yQ0VTIG1vZGVsIGNhcHR1 cmVzIA0KICAgICAgaG93IHRoZSBwZXItcGFja2V0IHN0YXRlIGluZm9ybWF0aW9uIGlzIHByb3Bh Z2F0ZWQgZnJvbSBvbmUgTEZCIHRvIA0KICAgICAgb3RoZXIgTEZCcy4gIFByYWN0aWNhbGx5LCBz dWNoIG1ldGFkYXRhIHByb3BhZ2F0aW9uIGNhbiBoYXBwZW4gDQogICAgICB3aXRoaW4gb25lIEZF LCBvciBjcm9zcyB0aGUgRkUgYm91bmRhcnkgYmV0d2VlbiB0d28gaW50ZXJjb25uZWN0ZWQgDQog ICAgICBGRXMuICBXZSBiZWxpZXZlIHRoYXQgdGhlIHNhbWUgbWV0YWRhdGEgbW9kZWwgY2FuIGJl IHVzZWQgZm9yIA0KICAgICAgZWl0aGVyIHNpdHVhdGlvbjsgaG93ZXZlciwgb3VyIGZvY3VzIGhl cmUgaXMgZm9yIGludHJhLUZFIA0KICAgICAgbWV0YWRhdGEuIA0KICAgICAgIA0KICAgMy4yLjQu MS4gTWV0YWRhdGEgVm9jYWJ1bGFyeSANCiAgICAgICANCiAgICAgIE1ldGFkYXRhIGhhcyBoaXN0 b3JpY2FsbHkgYmVlbiB1bmRlcnN0b29kIHRvIG1lYW4gImRhdGEgYWJvdXQgDQogICAgICBkYXRh Ii4gIFdoaWxlIHRoaXMgZGVmaW5pdGlvbiBpcyBhIHN0YXJ0LCBpdCBpcyBpbmFkZXF1YXRlIHRv IA0KICAgICAgZGVzY3JpYmUgdGhlIG11bHRpcGxlIGZvcm1zIG9mIG1ldGFkYXRhLCB3aGljaCBt YXkgYXBwZWFyIHdpdGhpbiBhIA0KICAgICAgY29tcGxleCBuZXR3b3JrIGVsZW1lbnQuICBUaGUg ZGlzY3Vzc2lvbiBoZXJlIGNhdGVnb3JpemVzIGZvcm1zIG9mIA0KICAgICAgbWV0YWRhdGEgYnkg dHdvIG9ydGhvZ29uYWwgYXhlcy4gDQogICAgICAgDQogICAgICBUaGUgZmlyc3QgYXhpcyBpcyAi aW50ZXJuYWwiIHZlcnN1cyAiZXh0ZXJuYWwiLCB3aGljaCBkZXNjcmliZXMgDQogICAgICB3aGVy ZSB0aGUgbWV0YWRhdGEgZXhpc3RzIGluIHRoZSBuZXR3b3JrIG1vZGVsIG9yIGltcGxlbWVudGF0 aW9uLiAgDQogICAgICBGb3IgZXhhbXBsZSwgYSBwYXJ0aWN1bGFyIHZlbmRvciBpbXBsZW1lbnRh dGlvbiBvZiBhbiBJUHY0IA0KICAgICAgZm9yd2FyZGVyIG1heSBtYWtlIGRlY2lzaW9ucyBpbnNp ZGUgb2YgYSBjaGlwIHRoYXQgYXJlIG5vdCB2aXNpYmxlIA0KICAgICAgZXh0ZXJuYWxseS4gIFRo b3NlIGRlY2lzaW9ucyBhcmUgbWV0YWRhdGEgZm9yIHRoZSBwYWNrZXQgdGhhdCBpcyANCiAgICAg ICJpbnRlcm5hbCIgdG8gdGhlIGNoaXAuICBXaGVuIGEgcGFja2V0IGlzIGZvcndhcmRlZCBvdXQg b2YgdGhlIA0KICAgICAgY2hpcCwgaXQgbWF5IGJlIG1hcmtlZCB3aXRoIGEgdHJhZmZpYyBtYW5h Z2VtZW50IGhlYWRlci4gIFRoYXQgDQogICAgICBoZWFkZXIsIHdoaWNoIGlzIG1ldGFkYXRhIGZv ciB0aGUgcGFja2V0LCBpcyB2aXNpYmxlIG91dHNpZGUgb2YgDQogICAgICB0aGUgY2hpcCwgYW5k IGlzIHRoZXJlZm9yZSBjYWxsZWQgImV4dGVybmFsIiBtZXRhZGF0YS4gDQogICAgICAgDQogICAg ICBUaGUgc2Vjb25kIGF4aXMgaXMgImltcGxpY2l0IiB2ZXJzdXMgImV4cHJlc3NlZCIsIHdoaWNo IHNwZWNpZmllcyANCiAgICAgIHdoZXRoZXIgb3Igbm90IHRoZSBtZXRhZGF0YSBoYXMgYSB2aXNp YmxlIHBoeXNpY2FsIHJlcHJlc2VudGF0aW9uLiANCiAgICAgIEZvciBleGFtcGxlLCB0aGUgdHJh ZmZpYyBtYW5hZ2VtZW50IGhlYWRlciBkZXNjcmliZWQgaW4gdGhlIA0KICAgICAgcHJldmlvdXMg cGFyYWdyYXBoIG1heSBiZSByZXByZXNlbnRlZCBhcyBhIHNlcmllcyBvZiBiaXRzIGluIHNvbWUg DQogICAgICBmb3JtYXQsIGFuZCB0aGF0IGhlYWRlciBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIHBh Y2tldC4gIFRob3NlIGJpdHMgDQogICAgICBoYXZlIHBoeXNpY2FsIHJlcHJlc2VudGF0aW9uLCBh bmQgYXJlIHRoZXJlZm9yZSAiZXhwcmVzc2VkIiANCiAgICAgIG1ldGFkYXRhLiAgSWYgdGhlIG1l dGFkYXRhIGRvZXMgbm90IGhhdmUgYSBwaHlzaWNhbCANCiAgICAgIHJlcHJlc2VudGF0aW9uLCBp dCBpcyBjYWxsZWQgImltcGxpY2l0IiBtZXRhZGF0YS4gIFRoaXMgc2l0dWF0aW9uIA0KICAgICAg b2NjdXJzLCBmb3IgZXhhbXBsZSwgd2hlbiBhIHBhcnRpY3VsYXIgcGF0aCB0aHJvdWdoIGEgbmV0 d29yayANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAg ICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0K ICAgICAgZGV2aWNlIGlzIGludGVuZGVkIHRvIGJlIHRyYXZlcnNlZCBvbmx5IGJ5IHBhcnRpY3Vs YXIga2luZHMgb2YgDQogICAgICBwYWNrZXRzLCBzdWNoIGFzIGFuIElQdjQgcm91dGVyLiAgQW4g aW1wbGVtZW50YXRpb24gbWF5IG5vdCBtYXJrIA0KICAgICAgZXZlcnkgcGFja2V0IGFsb25nIHRo aXMgcGF0aCBhcyBiZWluZyBvZiB0eXBlICJJUHY0IiwgYnV0IHRoZSANCiAgICAgIGludGVudGlv biBvZiB0aGUgZGVzaWduZXJzIGlzIHRoYXQgZXZlcnkgcGFja2V0IGlzIG9mIHRoYXQgdHlwZS4g IA0KICAgICAgVGhpcyB1bmRlcnN0YW5kaW5nIGNhbiBiZSB0aG91Z2h0IG9mIGFzIG1ldGFkYXRh IGFib3V0IHRoZSBwYWNrZXQsIA0KICAgICAgd2hpY2ggaXMgaW1wbGljaXRseSBhdHRhY2hlZCB0 byB0aGUgcGFja2V0IHRocm91Z2ggdGhlIGludGVudCBvZiANCiAgICAgIHRoZSBkZXNpZ25lcnMu IA0KICAgICAgIA0KICAgICAgSW4gdGhlIEZvckNFUyBtb2RlbCwgd2UgZG8gTk9UIGRpc2N1c3Mg b3IgcmVwcmVzZW50IG1ldGFkYXRhIA0KICAgICAgImludGVybmFsIiB0byB2ZW5kb3IgaW1wbGVt ZW50YXRpb25zIG9mIExGQnMuICBPdXIgZm9jdXMgaXMgc29sZWx5IA0KICAgICAgb24gbWV0YWRh dGEgImV4dGVybmFsIiB0byB0aGUgTEZCcywgYW5kIHRoZXJlZm9yZSB2aXNpYmxlIGluIHRoZSAN CiAgICAgIEZvckNFUyBtb2RlbC4gIFRoZSBtZXRhZGF0YSBkaXNjdXNzZWQgd2l0aGluIHRoaXMg bW9kZWwgbWF5LCBvciANCiAgICAgIG1heSBub3QsIGJlIHZpc2libGUgb3V0c2lkZSBvZiB0aGUg cGFydGljdWxhciBGRSBpbXBsZW1lbnRpbmcgdGhlIA0KICAgICAgTEZCIG1vZGVsLiAgSW4gdGhp cyByZWdhcmQsIHRoZSBzY29wZSBvZiB0aGUgbWV0YWRhdGEgd2l0aGluIA0KICAgICAgRm9yQ0VT IGlzIHZlcnkgbmFycm93bHkgZGVmaW5lZC4gDQogICAgICAgDQogICAgICBOb3RlIGFsc28gdGhh dCB3aGlsZSB3ZSBkZWZpbmUgbWV0YWRhdGEgd2l0aGluIHRoaXMgbW9kZWwsIGl0IGlzIA0KICAg ICAgb25seSBhIG1vZGVsLiAgVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCB2ZW5kb3IgaW1w bGVtZW50YXRpb25zIA0KICAgICAgb2YgRm9yQ0VTIHVzZSB0aGUgZXhhY3QgbWV0YWRhdGEgcmVw cmVzZW50YXRpb25zIGRlc2NyaWJlZCBpbiB0aGlzIA0KICAgICAgZG9jdW1lbnQuICBUaGUgb25s eSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudCBpcyB0aGF0IHZlbmRvcnMgDQogICAgICBpbXBs ZW1lbnQgdGhlIEZvckNFUyBwcm90b2NvbCwgbm90IHRoZSBtb2RlbC4gDQogICAgICAgDQogICAz LjIuNC4yLiBNZXRhZGF0YSBsaWZlY3ljbGUgd2l0aGluIHRoZSBGb3JDRVMgbW9kZWwgDQogICAg DQogICAgICBFYWNoIG1ldGFkYXRhIGNhbiBiZSBjb252ZW5pZW50bHkgbW9kZWxlZCBhcyBhIDxs YWJlbCwgdmFsdWU+IA0KICAgICAgcGFpciwgd2hlcmUgdGhlIGxhYmVsIGlkZW50aWZpZXMgdGhl IHR5cGUgb2YgaW5mb3JtYXRpb24sIChlLmcuLCANCiAgICAgICJjb2xvciIpLCBhbmQgaXRzIHZh bHVlIGhvbGRzIHRoZSBhY3R1YWwgaW5mb3JtYXRpb24gKGUuZy4sIA0KICAgICAgInJlZCIpLiAg VGhlIHRhZyBoZXJlIGlzIHNob3duIGFzIGEgdGV4dHVhbCBsYWJlbCwgYnV0IGl0IGNhbiBiZSAN CiAgICAgIHJlcGxhY2VkIG9yIGFzc29jaWF0ZWQgd2l0aCBhIHVuaXF1ZSBudW1lcmljIHZhbHVl IChpZGVudGlmaWVyKS4gICANCiAgICAgICANCiAgICAgIFRoZSBtZXRhZGF0YSBsaWZlLWN5Y2xl IGlzIGRlZmluZWQgaW4gdGhpcyBtb2RlbCB1c2luZyB0aHJlZSB0eXBlcyANCiAgICAgIG9mIGV2 ZW50czogIndyaXRlIiwgInJlYWQiIGFuZCAiY29uc3VtZSIuICBUaGUgZmlyc3QgIndyaXRlIiAN CiAgICAgIGltcGxpY2l0bHkgY3JlYXRlcyBhbmQgaW5pdGlhbGl6ZXMgdGhlIHZhbHVlIG9mIHRo ZSBtZXRhZGF0YSwgYW5kIA0KICAgICAgaGVuY2Ugc3RhcnRzIHRoZSBsaWZlLWN5Y2xlLiAgVGhl IGV4cGxpY2l0ICJjb25zdW1lIiBldmVudCANCiAgICAgIHRlcm1pbmF0ZXMgdGhlIGxpZmUtY3lj bGUuICBXaXRoaW4gdGhlIGxpZmUtY3ljbGUsIHRoYXQgaXMsIGFmdGVyIA0KICAgICAgYSAid3Jp dGUiIGV2ZW50LCBidXQgYmVmb3JlIHRoZSBuZXh0ICJjb25zdW1lIiBldmVudCwgdGhlcmUgY2Fu IGJlIA0KICAgICAgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiAid3JpdGUiIGFuZCAicmVhZCIgZXZl bnRzLiAgVGhlc2UgInJlYWQiIA0KICAgICAgYW5kICJ3cml0ZSIgZXZlbnRzIGNhbiBiZSBtaXhl ZCBpbiBhbiBhcmJpdHJhcnkgb3JkZXIgd2l0aGluIHRoZSANCiAgICAgIGxpZmUtY3ljbGUuICBP dXRzaWRlIG9mIHRoZSBsaWZlLWN5Y2xlIG9mIHRoZSBtZXRhZGF0YSwgdGhhdCBpcywgDQogICAg ICBiZWZvcmUgdGhlIGZpcnN0ICJ3cml0ZSIgZXZlbnQsIG9yIGJldHdlZW4gYSAiY29uc3VtZSIg ZXZlbnQgYW5kIA0KICAgICAgdGhlIG5leHQgIndyaXRlIiBldmVudCwgdGhlIG1ldGFkYXRhIHNo b3VsZCBiZSByZWdhcmRlZCBub24tDQogICAgICBleGlzdGVudCBvciBub24taW5pdGlhbGl6ZWQu ICBUaHVzLCByZWFkaW5nIGEgbWV0YWRhdGEgb3V0c2lkZSBvZiANCiAgICAgIGl0cyBsaWZlLWN5 Y2xlIGlzIGNvbnNpZGVyZWQgYW4gZXJyb3IuICANCiAgICAgICANCiAgICAgIFRvIGVuc3VyZSBp bnRlci1vcGVyYWJpbGl0eSBiZXR3ZWVuIExGQnMsIHRoZSBMRkIgY2xhc3MgDQogICAgICBzcGVj aWZpY2F0aW9uIG11c3QgZGVmaW5lIHdoYXQgbWV0YWRhdGEgdGhlIExGQiBjbGFzcyAicmVhZHMi IG9yIA0KICAgICAgImNvbnN1bWVzIiBvbiBpdHMgaW5wdXQocykgYW5kIHdoYXQgbWV0YWRhdGEg aXQgInByb2R1Y2VzIiBvbiBpdHMgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVz IEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjFdIA0KDCAgIEludGVy bmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAw NSANCiAgICANCiAgICANCiAgICAgIG91dHB1dChzKS4gIEZvciBtYXhpbXVtIGV4dGVuc2liaWxp dHksIHRoaXMgZGVmaW5pdGlvbiBzaG91bGQgDQogICAgICBuZWl0aGVyIHNwZWNpZnkgd2hpY2gg TEZCcyB0aGUgbWV0YWRhdGEgaXMgZXhwZWN0ZWQgdG8gY29tZSBmcm9tIA0KICAgICAgZm9yIGEg Y29uc3VtZXIgTEZCLCBub3Igd2hpY2ggTEZCcyBhcmUgZXhwZWN0ZWQgdG8gY29uc3VtZSANCiAg ICAgIG1ldGFkYXRhIGZvciBhIGdpdmVuIHByb2R1Y2VyIExGQi4gDQogICAgDQogICAgICBXaGls ZSBpdCBpcyBpbXBvcnRhbnQgdG8gZGVmaW5lIHRoZSBtZXRhZGF0YSB0eXBlcyBwYXNzaW5nIGJl dHdlZW4gDQogICAgICBMRkJzLCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgdG8gZGVmaW5lIHRoZSBl eGFjdCBlbmNvZGluZyBtZWNoYW5pc20gDQogICAgICB1c2VkIGJ5IExGQnMgZm9yIHRoYXQgbWV0 YWRhdGEuICBEaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIGFyZSANCiAgICAgIGFsbG93ZWQgdG8g dXNlIGRpZmZlcmVudCBlbmNvZGluZyBtZWNoYW5pc21zIGZvciBtZXRhZGF0YS4gIEZvciANCiAg ICAgIGV4YW1wbGUsIG9uZSBpbXBsZW1lbnRhdGlvbiBtYXkgc3RvcmUgbWV0YWRhdGEgaW4gcmVn aXN0ZXJzIG9yIA0KICAgICAgc2hhcmVkIG1lbW9yeSwgd2hpbGUgYW5vdGhlciBpbXBsZW1lbnRh dGlvbiBtYXkgZW5jb2RlIG1ldGFkYXRhIA0KICAgICAgaW4tYmFuZCBhcyBhIHByZWFtYmxlIGlu IHRoZSBwYWNrZXRzLiANCiAgICAgICANCiAgICAgIEF0IGFueSBsaW5rIGJldHdlZW4gdHdvIExG QnMsIHRoZSBwYWNrZXQgaXMgbWFya2VkIHdpdGggYSBmaW5pdGUgDQogICAgICBzZXQgb2YgYWN0 aXZlIG1ldGFkYXRhLCB3aGVyZSBhY3RpdmUgbWVhbnMgdGhlIG1ldGFkYXRhIGlzIHdpdGhpbiAN CiAgICAgIGl0cyBsaWZlLWN5Y2xlLiAgVGhlcmUgYXJlIHR3byBjb3JvbGxhcmllcyBvZiB0aGlz IG1vZGVsOiANCiAgICAgICANCiAgICAgIDEuIE5vIHVuLWluaXRpYWxpemVkIG1ldGFkYXRhIGV4 aXN0cyBpbiB0aGUgbW9kZWwuIA0KICAgICAgIA0KICAgICAgMi4gTm8gbW9yZSB0aGFuIG9uZSBv Y2N1cnJlbmNlIG9mIGVhY2ggbWV0YWRhdGEgdGFnIGNhbiBiZSANCiAgICAgICAgIGFzc29jaWF0 ZWQgd2l0aCBhIHBhY2tldCBhdCBhbnkgZ2l2ZW4gdGltZS4gDQogICAgICAgIA0KICAgMy4yLjQu My4gTEZCIE9wZXJhdGlvbnMgb24gTWV0YWRhdGEgDQogICAgICAgDQogICAgICBXaGVuIHRoZSBw YWNrZXQgaXMgcHJvY2Vzc2VkIGJ5IGFuIExGQiAoaS5lLiwgYmV0d2VlbiB0aGUgdGltZSBpdCAN CiAgICAgIGlzIHJlY2VpdmVkIGFuZCBmb3J3YXJkZWQgYnkgdGhlIExGQiksIHRoZSBMRkIgbWF5 IHBlcmZvcm0gcmVhZCwgDQogICAgICB3cml0ZSBhbmQvb3IgY29uc3VtZSBvcGVyYXRpb25zIG9u IGFueSBhY3RpdmUgbWV0YWRhdGEgYXNzb2NpYXRlZCANCiAgICAgIHdpdGggdGhlIHBhY2tldC4g IElmIHRoZSBMRkIgaXMgY29uc2lkZXJlZCB0byBiZSBhIGJsYWNrIGJveCwgb25lIA0KICAgICAg b2YgdGhlIGZvbGxvd2luZyBvcGVyYXRpb25zIGlzIHBlcmZvcm1lZCBvbiBlYWNoIGFjdGl2ZSBt ZXRhZGF0YS4gDQogICAgICAgDQogICAgICAgIC4gSUdOT1JFOiAgICAgICAgICAgaWdub3JlcyBh bmQgZm9yd2FyZHMgdGhlIG1ldGFkYXRhIA0KICAgICAgICAuIFJFQUQ6ICAgICAgICAgICAgIHJl YWRzIGFuZCBmb3J3YXJkcyB0aGUgbWV0YWRhdGEgDQogICAgICAgIC4gUkVBRC9SRS1XUklURTog ICAgcmVhZHMsIG92ZXItd3JpdGVzIGFuZCBmb3J3YXJkcyB0aGUgDQogICAgICAgICAgIG1ldGFk YXRhIA0KICAgICAgICAuIFdSSVRFOiAgICAgICAgICAgIHdyaXRlcyBhbmQgZm9yd2FyZHMgdGhl IG1ldGFkYXRhIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2FuIGFsc28gYmUgdXNl ZCB0byBjcmVhdGUgbmV3IG1ldGFkYXRhKSANCiAgICAgICAgLiBSRUFELUFORC1DT05TVU1FOiBy ZWFkcyBhbmQgY29uc3VtZXMgdGhlIG1ldGFkYXRhIA0KICAgICAgICAuIENPTlNVTUUgICAgICAg ICAgIGNvbnN1bWVzIG1ldGFkYXRhIHdpdGhvdXQgcmVhZGluZyANCiAgICAgICANCiAgICAgIFRo ZSBsYXN0IHR3byBvcGVyYXRpb25zIHRlcm1pbmF0ZSB0aGUgbGlmZS1jeWNsZSBvZiB0aGUgbWV0 YWRhdGEsIA0KICAgICAgbWVhbmluZyB0aGF0IHRoZSBtZXRhZGF0YSBpcyBub3QgZm9yd2FyZGVk IHdpdGggdGhlIHBhY2tldCB3aGVuIA0KICAgICAgdGhlIHBhY2tldCBpcyBzZW50IHRvIHRoZSBu ZXh0IExGQi4gDQogICAgICAgDQogICAgICBJbiBvdXIgbW9kZWwsIGEgbmV3IG1ldGFkYXRhIGlz IGdlbmVyYXRlZCBieSBhbiBMRkIgd2hlbiB0aGUgTEZCIA0KICAgICAgYXBwbGllcyBhIFdSSVRF IG9wZXJhdGlvbiB0byBhIG1ldGFkYXRhIHR5cGUgdGhhdCB3YXMgbm90IHByZXNlbnQgDQogICAg ICB3aGVuIHRoZSBwYWNrZXQgd2FzIHJlY2VpdmVkIGJ5IHRoZSBMRkIuICBTdWNoIGltcGxpY2l0 IGNyZWF0aW9uIA0KDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAy MDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjJdIA0KDCAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICAN CiAgICANCiAgICAgIG1heSBiZSB1bmludGVudGlvbmFsIGJ5IHRoZSBMRkIsIHRoYXQgaXMsIHRo ZSBMRkIgbWF5IGFwcGx5IHRoZSANCiAgICAgIFdSSVRFIG9wZXJhdGlvbiB3aXRob3V0IGtub3dp bmcgb3IgY2FyaW5nIGlmIHRoZSBnaXZlbiBtZXRhZGF0YSANCiAgICAgIGV4aXN0ZWQgb3Igbm90 LiAgSWYgaXQgZXhpc3RlZCwgdGhlIG1ldGFkYXRhIGdldHMgb3Zlci13cml0dGVuOyBpZiANCiAg ICAgIGl0IGRpZCBub3QgZXhpc3QsIHRoZSBtZXRhZGF0YSBpcyBjcmVhdGVkLiANCiAgICAgICAN CiAgICAgIEZvciBMRkJzIHRoYXQgaW5zZXJ0IHBhY2tldHMgaW50byB0aGUgbW9kZWwsIFdSSVRF IGlzIHRoZSBvbmx5IA0KICAgICAgbWVhbmluZ2Z1bCBtZXRhZGF0YSBvcGVyYXRpb24uIA0KICAg ICAgIA0KICAgICAgRm9yIExGQnMgdGhhdCByZW1vdmUgdGhlIHBhY2tldCBmcm9tIHRoZSBtb2Rl bCwgdGhleSBtYXkgZWl0aGVyIA0KICAgICAgUkVBRC1BTkQtQ09OU1VNRSAocmVhZCkgb3IgQ09O U1VNRSAoaWdub3JlKSBlYWNoIGFjdGl2ZSBtZXRhZGF0YSANCiAgICAgIGFzc29jaWF0ZWQgd2l0 aCB0aGUgcGFja2V0LiANCiAgICAgICANCiAgIDMuMi40LjQuIE1ldGFkYXRhIFByb2R1Y3Rpb24g YW5kIENvbnN1bXB0aW9uIA0KICAgICAgIA0KICAgICAgRm9yIGEgZ2l2ZW4gbWV0YWRhdGEgb24g YSBnaXZlbiBwYWNrZXQgcGF0aCwgdGhlcmUgbXVzdCBiZSBhdCANCiAgICAgIGxlYXN0IG9uZSBw cm9kdWNlciBMRkIgdGhhdCBjcmVhdGVzIHRoYXQgbWV0YWRhdGEgYW5kIHNob3VsZCBiZSBhdCAN CiAgICAgIGxlYXN0IG9uZSBjb25zdW1lciBMRkIgdGhhdCBuZWVkcyB0aGF0IG1ldGFkYXRhLiAg SW4gdGhpcyBtb2RlbCwgDQogICAgICB0aGUgcHJvZHVjZXIgYW5kIGNvbnN1bWVyIExGQnMgb2Yg YSBtZXRhZGF0YSBhcmUgbm90IHJlcXVpcmVkIHRvIA0KICAgICAgYmUgYWRqYWNlbnQuICBJbiBh ZGRpdGlvbiwgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHByb2R1Y2VycyBhbmQgDQogICAgICBjb25z dW1lcnMgZm9yIHRoZSBzYW1lIG1ldGFkYXRhLiAgV2hlbiBhIHBhY2tldCBwYXRoIGludm9sdmVz IA0KICAgICAgbXVsdGlwbGUgcHJvZHVjZXJzIG9mIHRoZSBzYW1lIG1ldGFkYXRhLCB0aGVuIHN1 YnNlcXVlbnQgcHJvZHVjZXJzIA0KICAgICAgb3ZlcndyaXRlIHRoYXQgbWV0YWRhdGEgdmFsdWUu IA0KICAgIA0KICAgICAgVGhlIG1ldGFkYXRhIHRoYXQgaXMgcHJvZHVjZWQgYnkgYW4gTEZCIGlz IHNwZWNpZmllZCBieSB0aGUgTEZCIA0KICAgICAgY2xhc3MgZGVmaW5pdGlvbiBvbiBhIHBlciBv dXRwdXQgcG9ydCBncm91cCBiYXNpcy4gIEEgcHJvZHVjZXIgbWF5IA0KICAgICAgYWx3YXlzIGdl bmVyYXRlIHRoZSBtZXRhZGF0YSBvbiB0aGUgcG9ydCBncm91cCwgb3IgbWF5IGdlbmVyYXRlIGl0 IA0KICAgICAgb25seSB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuICBXZSBjYWxsIHRoZSBmb3Jt ZXIgYW4gDQogICAgICAidW5jb25kaXRpb25hbCIgbWV0YWRhdGEsIHdoZXJlYXMgdGhlIGxhdHRl ciBpcyBhICJjb25kaXRpb25hbCIgDQogICAgICBtZXRhZGF0YS4gIEluIHRoZSBjYXNlIG9mIGNv bmRpdGlvbmFsIG1ldGFkYXRhLCBpdCBzaG91bGQgYmUgDQogICAgICBwb3NzaWJsZSB0byBkZXRl cm1pbmUgZnJvbSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgTEZCIHdoZW4gYSANCiAgICAgICJjb25k aXRpb25hbCIgbWV0YWRhdGEgaXMgcHJvZHVjZWQuIA0KICAgICAgIA0KICAgICAgVGhlIGNvbnN1 bWVyIGJlaGF2aW9yIG9mIGFuIExGQiwgdGhhdCBpcywgdGhlIG1ldGFkYXRhIHRoYXQgdGhlIA0K ICAgICAgTEZCIG5lZWRzIGZvciBpdHMgb3BlcmF0aW9uLCBpcyBkZWZpbmVkIGluIHRoZSBMRkIg Y2xhc3MgDQogICAgICBkZWZpbml0aW9uIG9uIGEgcGVyIGlucHV0IHBvcnQgZ3JvdXAgYmFzaXMu ICBBbiBpbnB1dCBwb3J0IGdyb3VwIA0KICAgICAgbWF5ICJyZXF1aXJlIiBhIGdpdmVuIG1ldGFk YXRhLCBvciBtYXkgdHJlYXQgaXQgYXMgIm9wdGlvbmFsIiANCiAgICAgIGluZm9ybWF0aW9uLiAg SW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgTEZCIGNsYXNzIGRlZmluaXRpb24gbXVzdCANCiAgICAg IGV4cGxpY2l0bHkgZGVmaW5lIHdoYXQgaGFwcGVucyBpZiBhbiBvcHRpb25hbCBtZXRhZGF0YSBp cyBub3QgDQogICAgICBwcm92aWRlZC4gIE9uZSBhcHByb2FjaCBpcyB0byBzcGVjaWZ5IGEgZGVm YXVsdCB2YWx1ZSBmb3IgZWFjaCANCiAgICAgIG9wdGlvbmFsIG1ldGFkYXRhLCBhbmQgYXNzdW1l IHRoYXQgdGhlIGRlZmF1bHQgdmFsdWUgaXMgdXNlZCBpZiANCiAgICAgIHRoZSBtZXRhZGF0YSBp cyBub3QgcHJvdmlkZWQgd2l0aCB0aGUgcGFja2V0LiANCiAgICAgICANCiAgICAgIFdoZW4gYSBj b25zdW1lciBMRkIgcmVxdWlyZXMgYSBnaXZlbiBtZXRhZGF0YSwgaXQgaGFzIGRlcGVuZGVuY2ll cyANCiAgICAgIG9uIGl0cyB1cC1zdHJlYW0gTEZCcy4gIFRoYXQgaXMsIHRoZSBjb25zdW1lciBM RkIgY2FuIG9ubHkgDQogICAgICBmdW5jdGlvbiBpZiB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgcHJv ZHVjZXIgb2YgdGhhdCBtZXRhZGF0YSBhbmQgbm8gDQogICAgICBpbnRlcm1lZGlhdGUgTEZCIGNv bnN1bWVzIHRoZSBtZXRhZGF0YS4gDQogICAgICAgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAg ICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjNdIA0K DCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBB dWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoZSBtb2RlbCBzaG91bGQgZXhwb3NlIHRo ZXNlIGludGVyLWRlcGVuZGVuY2llcy4gIEZ1cnRoZXJtb3JlLCBpdCANCiAgICAgIHNob3VsZCBi ZSBwb3NzaWJsZSB0byB0YWtlIGludGVyLWRlcGVuZGVuY2llcyBpbnRvIGNvbnNpZGVyYXRpb24g DQogICAgICB3aGVuIGNvbnN0cnVjdGluZyBMRkIgdG9wb2xvZ2llcywgYW5kIGFsc28gdGhhdCB0 aGUgZGVwZW5kZW5jaWVzIA0KICAgICAgY2FuIGJlIHZlcmlmaWVkIHdoZW4gdmFsaWRhdGluZyB0 b3BvbG9naWVzLiANCiAgICAgICANCiAgICAgIEZvciBleHRlbnNpYmlsaXR5IHJlYXNvbnMsIHRo ZSBMRkIgc3BlY2lmaWNhdGlvbiBzaG91bGQgZGVmaW5lIA0KICAgICAgd2hhdCBtZXRhZGF0YSB0 aGUgTEZCIHJlcXVpcmVzIHdpdGhvdXQgc3BlY2lmeWluZyB3aGljaCBMRkIocykgaXQgDQogICAg ICBleHBlY3RzIGEgY2VydGFpbiBtZXRhZGF0YSB0byBjb21lIGZyb20uICBTaW1pbGFybHksIExG QnMgc2hvdWxkIA0KICAgICAgc3BlY2lmeSB3aGF0IG1ldGFkYXRhIHRoZXkgcHJvZHVjZSB3aXRo b3V0IHNwZWNpZnlpbmcgd2hpY2ggTEZCcyANCiAgICAgIHRoZSBtZXRhZGF0YSBpcyBtZWFudCBm b3IuIA0KICAgICAgIA0KICAgICAgV2hlbiBzcGVjaWZ5aW5nIHRoZSBtZXRhZGF0YSB0YWdzLCBz b21lIGhhcm1vbml6YXRpb24gZWZmb3J0IG11c3QgDQogICAgICBiZSBtYWRlIHNvIHRoYXQgdGhl IHByb2R1Y2VyIExGQiBjbGFzcyB1c2VzIHRoZSBzYW1lIHRhZyBhcyBpdHMgDQogICAgICBpbnRl bmRlZCBjb25zdW1lcihzKSwgb3IgdmljZSB2ZXJzYS4gDQogICAgICAgDQogICAzLjIuNC41LiBG aXhlZCwgVmFyaWFibGUgYW5kIENvbmZpZ3VyYWJsZSBUYWcgIA0KICAgICAgIA0KICAgICAgV2hl biB0aGUgcHJvZHVjZWQgbWV0YWRhdGEgaXMgZGVmaW5lZCBmb3IgYSBnaXZlbiBMRkIgY2xhc3Ms IG1vc3QgDQogICAgICBtZXRhZGF0YSB3aWxsIGJlIHNwZWNpZmllZCB3aXRoIGEgZml4ZWQgdGFn LiAgRm9yIGV4YW1wbGUsIGEgUmF0ZSANCiAgICAgIE1ldGVyIExGQiB3aWxsIGFsd2F5cyBwcm9k dWNlIHRoZSAiQ29sb3IiIG1ldGFkYXRhLiANCiAgICAgICANCiAgICAgIEEgc21hbGwgc3Vic2V0 IG9mIExGQnMgbmVlZCB0aGUgY2FwYWJpbGl0eSB0byBwcm9kdWNlIG9uZSBvciBtb3JlIA0KICAg ICAgb2YgdGhlaXIgbWV0YWRhdGEgd2l0aCB0YWdzIHRoYXQgYXJlIG5vdCBmaXhlZCBpbiB0aGUg TEZCIGNsYXNzIA0KICAgICAgZGVmaW5pdGlvbiwgYnV0IGluc3RlYWQgY2FuIGJlIHNlbGVjdGVk IHBlciBMRkIgaW5zdGFuY2UuICBBbiANCiAgICAgIGV4YW1wbGUgb2Ygc3VjaCBhbiBMRkIgY2xh c3MgaXMgYSBHZW5lcmljIENsYXNzaWZpZXIgTEZCLiAgV2UgY2FsbCANCiAgICAgIHRoaXMgY2Fw YWJpbGl0eSAidmFyaWFibGUgdGFnIG1ldGFkYXRhIHByb2R1Y3Rpb24iLiAgSWYgYW4gTEZCIA0K ICAgICAgcHJvZHVjZXMgbWV0YWRhdGEgd2l0aCBhIHZhcmlhYmxlIHRhZywgdGhlIGNvcnJlc3Bv bmRpbmcgTEZCIA0KICAgICAgYXR0cmlidXRlLCBjYWxsZWQgdGhlIHRhZyBzZWxlY3Rvciwgc3Bl Y2lmaWVzIHRoZSB0YWcgZm9yIGVhY2ggDQogICAgICBzdWNoIG1ldGFkYXRhLiAgVGhpcyBtZWNo YW5pc20gaW1wcm92ZXMgdGhlIHZlcnNhdGlsaXR5IG9mIGNlcnRhaW4gDQogICAgICBtdWx0aS1w dXJwb3NlIExGQiBjbGFzc2VzLCBzaW5jZSBpdCBhbGxvd3MgdGhlIHNhbWUgTEZCIGNsYXNzIHRv IA0KICAgICAgYmUgdXNlZCBpbiBkaWZmZXJlbnQgdG9wb2xvZ2llcywgcHJvZHVjaW5nIHRoZSBy aWdodCBtZXRhZGF0YSB0YWdzIA0KICAgICAgYWNjb3JkaW5nIHRvIHRoZSBuZWVkcyBvZiB0aGUg dG9wb2xvZ3kuIA0KICAgICAgICANCiAgICAgIERlcGVuZGluZyBvbiB0aGUgY2FwYWJpbGl0eSBv ZiB0aGUgRkUsIHRoZSB0YWcgc2VsZWN0b3IgY2FuIGJlIA0KICAgICAgZWl0aGVyIGEgcmVhZC1v bmx5IG9yIGEgcmVhZC13cml0ZSBhdHRyaWJ1dGUuICBJZiB0aGUgc2VsZWN0b3IgaXMgDQogICAg ICByZWFkLW9ubHksIHRoZSB0YWcgY2Fubm90IGJlIG1vZGlmaWVkIGJ5IHRoZSBDRS4gIElmIHRo ZSBzZWxlY3RvciANCiAgICAgIGlzIHJlYWQtd3JpdGUsIHRoZSB0YWcgY2FuIGJlIGNvbmZpZ3Vy ZWQgYnkgdGhlIENFLCBoZW5jZSB3ZSBjYWxsIA0KICAgICAgdGhpcyAiY29uZmlndXJhYmxlIHRh ZyBtZXRhZGF0YSBwcm9kdWN0aW9uLiIgIE5vdGUgdGhhdCB1c2luZyB0aGlzIA0KICAgICAgZGVm aW5pdGlvbiwgY29uZmlndXJhYmxlIHRhZyBtZXRhZGF0YSBwcm9kdWN0aW9uIGlzIGEgc3Vic2V0 IG9mIA0KICAgICAgdmFyaWFibGUgdGFnIG1ldGFkYXRhIHByb2R1Y3Rpb24uIA0KICAgICAgIA0K ICAgICAgU2ltaWxhciBjb25jZXB0cyBjYW4gYmUgaW50cm9kdWNlZCBmb3IgdGhlIGNvbnN1bWVy IExGQnMgdG8gDQogICAgICBzYXRpc2Z5IGRpZmZlcmVudCBtZXRhZGF0YSBuZWVkcy4gIE1vc3Qg TEZCIGNsYXNzZXMgd2lsbCBzcGVjaWZ5IA0KICAgICAgdGhlaXIgbWV0YWRhdGEgbmVlZHMgdXNp bmcgZml4ZWQgbWV0YWRhdGEgdGFncy4gIEZvciBleGFtcGxlLCBhIA0KICAgICAgTmV4dCBIb3Ag TEZCIG1heSBhbHdheXMgcmVxdWlyZSBhICJOZXh0SG9wSWQiIG1ldGFkYXRhOyBidXQgdGhlIA0K ICAgICAgUmVkaXJlY3RvciBMRkIgbWF5IG5lZWQgYSAiQ2xhc3NJRCIgbWV0YWRhdGEgaW4gb25l IGluc3RhbmNlLCBhbmQgDQogICAgICBhICJQcm90b2NvbFR5cGUiIG1ldGFkYXRhIGluIGFub3Ro ZXIgaW5zdGFuY2UgYXMgYSBiYXNpcyBmb3IgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdIA0KDCAg IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1 c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHNlbGVjdGluZyB0aGUgcmlnaHQgb3V0cHV0IHBv cnQuICBJbiB0aGlzIGNhc2UsIGFuIExGQiBhdHRyaWJ1dGUgDQogICAgICBpcyB1c2VkIHRvIHBy b3ZpZGUgdGhlIHJlcXVpcmVkIG1ldGFkYXRhIHRhZyBhdCBydW4tdGltZS4gIFRoaXMgDQogICAg ICBtZXRhZGF0YSB0YWcgc2VsZWN0b3IgYXR0cmlidXRlIG1heSBiZSByZWFkLW9ubHkgb3IgcmVh ZC13cml0ZSwgDQogICAgICBkZXBlbmRpbmcgb24gdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgTEZC IGluc3RhbmNlIGFuZCB0aGUgRkUuIA0KICAgICAgIA0KICAgMy4yLjQuNi4gTWV0YWRhdGEgVXNh Z2UgQ2F0ZWdvcmllcyANCiAgICAgICANCiAgICAgIERlcGVuZGluZyBvbiB0aGUgcm9sZSBhbmQg dXNhZ2Ugb2YgYSBtZXRhZGF0YSwgdmFyaW91cyBhbW91bnRzIG9mIA0KICAgICAgZW5jb2Rpbmcg aW5mb3JtYXRpb24gbXVzdCBiZSBwcm92aWRlZCB3aGVuIHRoZSBtZXRhZGF0YSBpcyANCiAgICAg IGRlZmluZWQsIHdoZXJlIHNvbWUgY2FzZXMgb2ZmZXIgbGVzcyBmbGV4aWJpbGl0eSBpbiB0aGUg dmFsdWUgDQogICAgICBzZWxlY3Rpb24gdGhhbiBvdGhlcnMuIA0KICAgICAgIA0KICAgICAgVGhl cmUgYXJlIHRocmVlIHR5cGVzIG9mIG1ldGFkYXRhIHJlbGF0ZWQgdG8gbWV0YWRhdGEgdXNhZ2U6 IA0KICAgICAgICAuIFJlbGF0aW9uYWwgKG9yIGJpbmRpbmcpIG1ldGFkYXRhIA0KICAgICAgICAu IEVudW1lcmF0ZWQgbWV0YWRhdGEgDQogICAgICAgIC4gRXhwbGljaXQvZXh0ZXJuYWwgdmFsdWUg bWV0YWRhdGEgDQogICAgICAgDQogICAgICBUaGUgcHVycG9zZSBvZiB0aGUgcmVsYXRpb25hbCBt ZXRhZGF0YSBpcyB0byByZWZlciBpbiBvbmUgTEZCIA0KICAgICAgaW5zdGFuY2UgKHByb2R1Y2Vy IExGQikgdG8gYSAidGhpbmciIGluIGFub3RoZXIgZG93bnN0cmVhbSBMRkIgDQogICAgICBpbnN0 YW5jZSAoY29uc3VtZXIgTEZCKSwgd2hlcmUgdGhlICJ0aGluZyIgaXMgdHlwaWNhbGx5IGFuIGVu dHJ5IA0KICAgICAgaW4gYSB0YWJsZSBhdHRyaWJ1dGUgb2YgdGhlIGNvbnN1bWVyIExGQi4gDQog ICAgICAgDQogICAgICBGb3IgZXhhbXBsZSwgdGhlIFByZWZpeCBMb29rdXAgTEZCIGV4ZWN1dGVz IGFuIExQTSBzZWFyY2ggdXNpbmcgDQogICAgICBpdHMgcHJlZml4IHRhYmxlIGFuZCByZXNvbHZl cyB0byBhIG5leHQtaG9wIHJlZmVyZW5jZS4gIFRoaXMgDQogICAgICByZWZlcmVuY2UgbmVlZHMg dG8gYmUgcGFzc2VkIGFzIG1ldGFkYXRhIGJ5IHRoZSBQcmVmaXggTG9va3VwIExGQiANCiAgICAg IChwcm9kdWNlcikgdG8gdGhlIE5leHQgSG9wIExGQiAoY29uc3VtZXIpLCBhbmQgbXVzdCByZWZl ciB0byBhIA0KICAgICAgc3BlY2lmaWMgZW50cnkgaW4gdGhlIG5leHQtaG9wIHRhYmxlIHdpdGhp biB0aGUgY29uc3VtZXIuIA0KICAgICAgIA0KICAgICAgRXhwcmVzc2luZyBhbmQgcHJvcGFnYXRp bmcgc3VjaCBhIGJpbmRpbmcgcmVsYXRpb25zaGlwIGlzIHByb2JhYmx5IA0KICAgICAgdGhlIG1v c3QgY29tbW9uIHVzYWdlIG9mIG1ldGFkYXRhLiAgT25lIG9yIG1vcmUgb2JqZWN0cyBpbiB0aGUg DQogICAgICBwcm9kdWNlciBMRkIgYXJlIGJvdW5kIHRvIGEgc3BlY2lmaWMgb2JqZWN0IGluIHRo ZSBjb25zdW1lciBMRkIuICANCiAgICAgIFN1Y2ggYSByZWxhdGlvbnNoaXAgaXMgZXN0YWJsaXNo ZWQgYnkgdGhlIENFIGV4cGxpY2l0bHkgYnkgDQogICAgICBwcm9wZXJseSBjb25maWd1cmluZyB0 aGUgYXR0cmlidXRlcyBpbiBib3RoIExGQnMuICBBdmFpbGFibGUgDQogICAgICBtZXRob2RzIGlu Y2x1ZGUgdGhlIGZvbGxvd2luZzogDQogICAgICAgDQogICAgICBUaGUgYmluZGluZyBtYXkgYmUg ZXhwcmVzc2VkIGJ5IHRhZ2dpbmcgdGhlIGludm9sdmVkIG9iamVjdHMgaW4gDQogICAgICBib3Ro IExGQnMgd2l0aCB0aGUgc2FtZSB1bmlxdWUsIGJ1dCBvdGhlcndpc2UgYXJiaXRyYXJ5LCANCiAg ICAgIGlkZW50aWZpZXIuICBUaGUgdmFsdWUgb2YgdGhlIHRhZyBpcyBleHBsaWNpdGx5IGNvbmZp Z3VyZWQgYnkgdGhlIA0KICAgICAgQ0UgYnkgd3JpdGluZyB0aGUgdmFsdWUgaW50byBib3RoIExG QnMsIGFuZCB0aGlzIHZhbHVlIGlzIGFsc28gDQogICAgICBjYXJyaWVkIGJ5IHRoZSBtZXRhZGF0 YSBiZXR3ZWVuIHRoZSBMRkJzLiANCiAgICAgICANCiAgICAgIEFub3RoZXIgd2F5IG9mIHNldHRp bmcgdXAgYmluZGluZyByZWxhdGlvbnMgaXMgdG8gdXNlIGEgbmF0dXJhbGx5IA0KICAgICAgb2Nj dXJyaW5nIHVuaXF1ZSBpZGVudGlmaWVyIG9mIHRoZSBjb25zdW1lcidzIG9iamVjdCBhcyBhIA0K ICAgICAgcmVmZXJlbmNlIGFuZCBhcyBhIHZhbHVlIG9mIHRoZSBtZXRhZGF0YSAoZS5nLiwgdGhl IGFycmF5IGluZGV4IG9mIA0KICAgICAgYSB0YWJsZSBlbnRyeSkuICBJbiB0aGlzIGNhc2UsIHRo ZSBpbmRleCBpcyBlaXRoZXIgcmVhZCBvciANCiAgICAgIGluZmVycmVkIGJ5IHRoZSBDRSBieSBj b21tdW5pY2F0aW5nIHdpdGggdGhlIGNvbnN1bWVyIExGQi4gIE9uY2UgDQoNCiAgICANCiAgIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAyNV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgdGhlIENFIG9idGFp bnMgdGhlIGluZGV4LCBpdCBuZWVkcyB0byB3cml0ZSBpdCBpbnRvIHRoZSBwcm9kdWNlciANCiAg ICAgIExGQiB0byBlc3RhYmxpc2ggdGhlIGJpbmRpbmcuIA0KICAgICAgIA0KICAgICAgSW1wb3J0 YW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgYmluZGluZyB1c2FnZSBvZiBtZXRhZGF0YSBhcmU6 IA0KICAgICAgIA0KICAgICAgICAuIFRoZSB2YWx1ZSBvZiB0aGUgbWV0YWRhdGEgc2hvd3MgdXAg aW4gdGhlIENFLUZFIGNvbW11bmljYXRpb24gDQogICAgICAgICAgIGZvciBCT1RIIHRoZSBjb25z dW1lciBhbmQgdGhlIHByb2R1Y2VyLiAgVGhhdCBpcywgdGhlIA0KICAgICAgICAgICBtZXRhZGF0 YSB2YWx1ZSBtdXN0IGJlIGNhcnJpZWQgb3ZlciB0aGUgRm9yQ0VTIHByb3RvY29sLiAgDQogICAg ICAgICAgIFVzaW5nIHRoZSB0YWdnaW5nIHRlY2huaXF1ZSwgdGhlIHZhbHVlIGlzIFdSSVRURU4g dG8gYm90aCANCiAgICAgICAgICAgTEZCcy4gIFVzaW5nIHRoZSBvdGhlciB0ZWNobmlxdWUsIHRo ZSB2YWx1ZSBpcyBXUklUVEVOIHRvIA0KICAgICAgICAgICBvbmx5IHRoZSBwcm9kdWNlciBMRkIg YW5kIG1heSBiZSBSRUFEIGZyb20gdGhlIGNvbnN1bWVyIExGQi4gDQogICAgICAgDQogICAgICAg IC4gVGhlIG1ldGFkYXRhIHZhbHVlIGlzIGlycmVsZXZhbnQgdG8gdGhlIENFLCB0aGUgYmluZGlu ZyBpcyANCiAgICAgICAgICAgc2ltcGx5IGV4cHJlc3NlZCBieSB1c2luZyB0aGUgU0FNRSB2YWx1 ZSBhdCB0aGUgY29uc3VtZXIgYW5kIA0KICAgICAgICAgICBwcm9kdWNlciBMRkJzLiANCiAgICAg ICANCiAgICAgICAgLiBIZW5jZSB0aGUgbWV0YWRhdGEgZGVmaW5pdGlvbiBpcyBub3QgcmVxdWly ZWQgdG8gaW5jbHVkZSANCiAgICAgICAgICAgdmFsdWUgYXNzaWdubWVudHMuICBUaGUgb25seSBl eGNlcHRpb24gaXMgd2hlbiBzb21lIHNwZWNpYWwgDQogICAgICAgICAgIHZhbHVlKHMpIG9mIHRo ZSBtZXRhZGF0YSBtdXN0IGJlIHJlc2VydmVkIHRvIGNvbnZleSBzcGVjaWFsIA0KICAgICAgICAg ICBldmVudHMuICBFdmVuIHRob3VnaCB0aGVzZSBzcGVjaWFsIGNhc2VzIG11c3QgYmUgZGVmaW5l ZCB3aXRoIA0KICAgICAgICAgICB0aGUgbWV0YWRhdGEgc3BlY2lmaWNhdGlvbiwgdGhlaXIgZW5j b2RlZCB2YWx1ZXMgY2FuIGJlIA0KICAgICAgICAgICBzZWxlY3RlZCBhcmJpdHJhcmlseS4gIEZv ciBleGFtcGxlLCBmb3IgdGhlIFByZWZpeCBMb29rdXAgTEZCIA0KICAgICAgICAgICBleGFtcGxl LCBhIHNwZWNpYWwgdmFsdWUgbWF5IGJlIHJlc2VydmVkIHRvIHNpZ25hbCB0aGUgTk8tDQogICAg ICAgICAgIE1BVENIIGNhc2UsIGFuZCB0aGUgdmFsdWUgb2YgemVybyBtYXkgYmUgYXNzaWduZWQg Zm9yIHRoaXMgDQogICAgICAgICAgIHB1cnBvc2UuIA0KICAgICAgICANCiAgICAgIFRoZSBzZWNv bmQgY2xhc3Mgb2YgbWV0YWRhdGEgaXMgdGhlIGVudW1lcmF0ZWQgdHlwZS4gIEFuIGV4YW1wbGUg DQogICAgICBpcyB0aGUgIkNvbG9yIiBtZXRhZGF0YSB0aGF0IGlzIHByb2R1Y2VkIGJ5IGEgTWV0 ZXIgTEZCLiBBcyB0aGUgDQogICAgICBuYW1lIHN1Z2dlc3RzLCBlbnVtZXJhdGVkIG1ldGFkYXRh IGhhcyBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIA0KICAgICAgb2YgcG9zc2libGUgdmFsdWVz LCBlYWNoIHdpdGggYSBzcGVjaWZpYyBtZWFuaW5nLiAgQWxsIHBvc3NpYmxlIA0KICAgICAgY2Fz ZXMgbXVzdCBiZSBlbnVtZXJhdGVkIHdoZW4gZGVmaW5pbmcgdGhpcyBjbGFzcyBvZiBtZXRhZGF0 YS4gIA0KICAgICAgQWx0aG91Z2ggYSB2YWx1ZSBlbmNvZGluZyBtdXN0IGJlIGluY2x1ZGVkIGlu IHRoZSBzcGVjaWZpY2F0aW9uLCANCiAgICAgIHRoZSBhY3R1YWwgdmFsdWVzIGNhbiBiZSBzZWxl Y3RlZCBhcmJpdHJhcmlseSAoZS5nLiwgPFJlZD0wLCANCiAgICAgIFllbGxvdz0xLCBHcmVlbj0y PiBhbmQgPFJlZD0zLCBZZWxsb3c9MiwgR3JlZW4gMT4gd291bGQgYmUgYm90aCANCiAgICAgIHZh bGlkIGVuY29kaW5ncywgd2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCBhbiBlbmNvZGluZyBpcyAN CiAgICAgIHNwZWNpZmllZCkuIA0KICAgICAgIA0KICAgICAgVGhlIHZhbHVlIG9mIHRoZSBlbnVt ZXJhdGVkIG1ldGFkYXRhIG1heSBvciBtYXkgbm90IGJlIGNvbnZleWVkIA0KICAgICAgdmlhIHRo ZSBGb3JDRVMgcHJvdG9jb2wgYmV0d2VlbiB0aGUgQ0UgYW5kIEZFLiANCiAgICAgICANCiAgICAg IFRoZSB0aGlyZCBjbGFzcyBvZiBtZXRhZGF0YSBpcyB0aGUgZXhwbGljaXQgdHlwZS4gIFRoaXMg cmVmZXJzIHRvIA0KICAgICAgY2FzZXMgd2hlcmUgdGhlIG1ldGFkYXRhIHZhbHVlIGlzIGV4cGxp Y2l0bHkgdXNlZCBieSB0aGUgY29uc3VtZXIgDQogICAgICBMRkIgdG8gY2hhbmdlIHNvbWUgcGFj a2V0IGhlYWRlciBmaWVsZHMuICBJbiBvdGhlciB3b3JkcywgdGhlIA0KICAgICAgdmFsdWUgaGFz IGEgZGlyZWN0IGFuZCBleHBsaWNpdCBpbXBhY3Qgb24gc29tZSBmaWVsZCBhbmQgd2lsbCBiZSAN CiAgICAgIHZpc2libGUgZXh0ZXJuYWxseSB3aGVuIHRoZSBwYWNrZXQgbGVhdmVzIHRoZSBORS4g IEV4YW1wbGVzIGFyZTogDQogICAgICBUVEwgaW5jcmVtZW50IGdpdmVuIHRvIGEgSGVhZGVyIE1v ZGlmaWVyIExGQiwgYW5kIERTQ1AgdmFsdWUgZm9yIGEgDQogICAgICBSZW1hcmtlciBMRkIuICBG b3IgZXhwbGljaXQgbWV0YWRhdGEsIHRoZSB2YWx1ZSBlbmNvZGluZyBtdXN0IGJlIA0KICAgIA0K ICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDI2XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBN b2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBleHBsaWNp dGx5IHByb3ZpZGVkIGluIHRoZSBtZXRhZGF0YSBkZWZpbml0aW9uLiAgVGhlIHZhbHVlcyBjYW5u b3QgDQogICAgICBiZSBzZWxlY3RlZCBhcmJpdHJhcmlseSBhbmQgc2hvdWxkIGNvbmZvcm0gdG8g d2hhdCBpcyBjb21tb25seSANCiAgICAgIGV4cGVjdGVkLiAgRm9yIGV4YW1wbGUsIGEgVFRMIGlu Y3JlbWVudCBtZXRhZGF0YSBzaG91bGQgYmUgZW5jb2RlZCANCiAgICAgIGFzIHplcm8gZm9yIHRo ZSBubyBpbmNyZW1lbnQgY2FzZSwgb25lIGZvciB0aGUgc2luZ2xlIGluY3JlbWVudCANCiAgICAg IGNhc2UsIGV0Yy4gIEEgRFNDUCBtZXRhZGF0YSBzaG91bGQgdXNlIDAgdG8gZW5jb2RlIERTQ1A9 MCwgMSB0byANCiAgICAgIGVuY29kZSBEU0NQPTEsIGV0Yy4gDQogICAgICAgDQogICAzLjIuNS4g TEZCIFZlcnNpb25pbmcgDQogICAgICAgDQogICAgICBMRkIgY2xhc3MgdmVyc2lvbmluZyBpcyBh IG1ldGhvZCB0byBlbmFibGUgaW5jcmVtZW50YWwgZXZvbHV0aW9uIA0KICAgICAgb2YgTEZCIGNs YXNzZXMuIEluIGdlbmVyYWwsIGFuIEZFIGlzIG5vdCBhbGxvd2VkIHRvIGNvbnRhaW4gYW4gTEZC IA0KICAgICAgaW5zdGFuY2UgZm9yIG1vcmUgdGhhbiBvbmUgdmVyc2lvbiBvZiBhIHBhcnRpY3Vs YXIgY2xhc3MuICANCiAgICAgIEluaGVyaXRhbmNlIChkaXNjdXNzZWQgbmV4dCBpbiBTZWN0aW9u IDMuMi42KSBoYXMgc3BlY2lhbCBydWxlcy4gDQogICAgICBJZiBhbiBGRSBkYXRhcGF0aCBtb2Rl bCBjb250YWluaW5nIGFuIExGQiBpbnN0YW5jZSBvZiBhIHBhcnRpY3VsYXIgDQogICAgICBjbGFz cyBDIGFsc28gc2ltdWx0YW5lb3VzbHkgY29udGFpbnMgYW4gTEZCIGluc3RhbmNlIG9mIGEgY2xh c3MgQycgDQogICAgICBpbmhlcml0ZWQgZnJvbSBjbGFzcyBDOyBDIGNvdWxkIGhhdmUgYSBkaWZm ZXJlbnQgdmVyc2lvbiB0aGFuIEMnLiANCiAgICANCiAgICAgIExGQiBjbGFzcyB2ZXJzaW9uaW5n IGlzIHN1cHBvcnRlZCBieSByZXF1aXJpbmcgYSB2ZXJzaW9uIHN0cmluZyBpbiANCiAgICAgIHRo ZSBjbGFzcyBkZWZpbml0aW9uLiAgQ0VzIG1heSBzdXBwb3J0IG11bHRpcGxlIHZlcnNpb25zIG9m IGEgDQogICAgICBwYXJ0aWN1bGFyIExGQiBjbGFzcyB0byBwcm92aWRlIGJhY2t3YXJkIGNvbXBh dGliaWxpdHksIGJ1dCBGRXMgDQogICAgICBhcmUgbm90IGFsbG93ZWQgdG8gc3VwcG9ydCBtb3Jl IHRoYW4gb25lIHZlcnNpb24gb2YgYSBwYXJ0aWN1bGFyIA0KICAgICAgY2xhc3MuIA0KICAgICAg IA0KICAgMy4yLjYuIExGQiBJbmhlcml0YW5jZSANCiAgICAgICANCiAgICAgIExGQiBjbGFzcyBp bmhlcml0YW5jZSBpcyBzdXBwb3J0ZWQgaW4gdGhlIEZFIG1vZGVsIGFzIGEgbWV0aG9kIHRvIA0K ICAgICAgZGVmaW5lIG5ldyBMRkIgY2xhc3Nlcy4gIFRoaXMgYWxzbyBhbGxvd3MgRkUgdmVuZG9y cyB0byBhZGQgDQogICAgICB2ZW5kb3Itc3BlY2lmaWMgZXh0ZW5zaW9ucyB0byBzdGFuZGFyZGl6 ZWQgTEZCcy4gIEFuIExGQiBjbGFzcyANCiAgICAgIHNwZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5 IHRoZSBiYXNlIGNsYXNzIGFuZCB2ZXJzaW9uIG51bWJlciBpdCANCiAgICAgIGluaGVyaXRzIGZy b20gKHRoZSBkZWZhdWx0IGlzIHRoZSBiYXNlIExGQiBjbGFzcykuICBNdWx0aXBsZS0NCiAgICAg IGluaGVyaXRhbmNlIGlzIG5vdCBhbGxvd2VkLCBob3dldmVyLCB0byBhdm9pZCB1bm5lY2Vzc2Fy eSANCiAgICAgIGNvbXBsZXhpdHkuICANCiAgICAgICANCiAgICAgIEluaGVyaXRhbmNlIHNob3Vs ZCBiZSB1c2VkIG9ubHkgd2hlbiB0aGVyZSBpcyBzaWduaWZpY2FudCByZXVzZSBvZiANCiAgICAg IHRoZSBiYXNlIExGQiBjbGFzcyBkZWZpbml0aW9uLiAgQSBzZXBhcmF0ZSBMRkIgY2xhc3Mgc2hv dWxkIGJlIA0KICAgICAgZGVmaW5lZCBpZiBsaXR0bGUgb3Igbm8gcmV1c2UgaXMgcG9zc2libGUg YmV0d2VlbiB0aGUgZGVyaXZlZCBhbmQgDQogICAgICB0aGUgYmFzZSBMRkIgY2xhc3MuIA0KICAg ICAgIA0KICAgICAgQW4gaW50ZXJlc3RpbmcgaXNzdWUgcmVsYXRlZCB0byBjbGFzcyBpbmhlcml0 YW5jZSBpcyBiYWNrd2FyZCANCiAgICAgIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBhIGRlc2NlbmRh bnQgYW5kIGFuIGFuY2VzdG9yIGNsYXNzLiAgIA0KICAgICAgQ29uc2lkZXIgdGhlIGZvbGxvd2lu ZyBoeXBvdGhldGljYWwgc2NlbmFyaW8gd2hlcmUgYSBzdGFuZGFyZGl6ZWQgDQogICAgICBMRkIg Y2xhc3MgIkwxIiBleGlzdHMuICBWZW5kb3IgQSBidWlsZHMgYW4gRkUgdGhhdCBpbXBsZW1lbnRz IExGQiANCiAgICAgICJMMSIgYW5kIHZlbmRvciBCIGJ1aWxkcyBhIENFIHRoYXQgY2FuIHJlY29n bml6ZSBhbmQgb3BlcmF0ZSBvbiANCiAgICAgIExGQiAiTDEiLiAgU3VwcG9zZSB0aGF0IGEgbmV3 IExGQiBjbGFzcywgIkwyIiwgaXMgZGVmaW5lZCBiYXNlZCBvbiANCiAgICAgIHRoZSBleGlzdGlu ZyAiTDEiIGNsYXNzIGJ5IGV4dGVuZGluZyBpdHMgY2FwYWJpbGl0aWVzIA0KICAgICAgaW5jcmVt ZW50YWxseS4gTGV0IHVzIGV4YW1pbmUgdGhlIEZFIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNz dWUgDQogICAgICBieSBjb25zaWRlcmluZyB3aGF0IHdvdWxkIGhhcHBlbiBpZiB2ZW5kb3IgQiB1 cGdyYWRlcyBpdHMgRkUgZnJvbSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMg QXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyN10gDQoMICAgSW50ZXJu ZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 IA0KICAgIA0KICAgIA0KICAgICAgIkwxIiB0byAiTDIiIGFuZCB2ZW5kb3IgQydzIENFIGlzIG5v dCBjaGFuZ2VkLiAgVGhlIG9sZCBMMS1iYXNlZCANCiAgICAgIENFIGNhbiBpbnRlcm9wZXJhdGUg d2l0aCB0aGUgbmV3IEwyLWJhc2VkIEZFIGlmIHRoZSBkZXJpdmVkIExGQiANCiAgICAgIGNsYXNz ICJMMiIgaXMgaW5kZWVkIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCB0aGUgYmFzZSBjbGFzcyAi TDEiLiAgIA0KICAgICAgIA0KICAgICAgVGhlIHJldmVyc2Ugc2NlbmFyaW8gaXMgYSBtdWNoIGxl c3MgcHJvYmxlbWF0aWMgY2FzZSwgaS5lLiwgd2hlbiANCiAgICAgIENFIHZlbmRvciBCIHVwZ3Jh ZGVzIHRvIHRoZSBuZXcgTEZCIGNsYXNzICJMMiIsIGJ1dCB0aGUgRkUgaXMgbm90IA0KICAgICAg dXBncmFkZWQuICBOb3RlIHRoYXQgYXMgbG9uZyBhcyB0aGUgQ0UgaXMgY2FwYWJsZSBvZiB3b3Jr aW5nIHdpdGggDQogICAgICBvbGRlciBMRkIgY2xhc3NlcywgdGhpcyBwcm9ibGVtIGRvZXMgbm90 IGFmZmVjdCB0aGUgbW9kZWw7IGhlbmNlIA0KICAgICAgd2Ugd2lsbCB1c2UgdGhlIHRlcm0gImJh Y2t3YXJkIGNvbXBhdGliaWxpdHkiIHRvIHJlZmVyIHRvIHRoZSANCiAgICAgIGZpcnN0IHNjZW5h cmlvIGNvbmNlcm5pbmcgRkUgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gDQogICAgICAgDQogICAg ICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5IGNhbiBiZSBkZXNpZ25lZCBpbnRvIHRoZSBpbmhlcml0 YW5jZSBtb2RlbCANCiAgICAgIGJ5IGNvbnN0cmFpbmluZyBMRkIgaW5oZXJpdGFuY2UgdG8gcmVx dWlyZSB0aGUgZGVyaXZlZCBjbGFzcyBiZSBhIA0KICAgICAgZnVuY3Rpb25hbCBzdXBlcnNldCBv ZiB0aGUgYmFzZSBjbGFzcyAoaS5lLiB0aGUgZGVyaXZlZCBjbGFzcyBjYW4gDQogICAgICBvbmx5 IGFkZCBmdW5jdGlvbnMgdG8gdGhlIGJhc2UgY2xhc3MsIGJ1dCBub3QgcmVtb3ZlIGZ1bmN0aW9u cykuICANCiAgICAgIEFkZGl0aW9uYWxseSwgdGhlIGZvbGxvd2luZyBtZWNoYW5pc21zIGFyZSBy ZXF1aXJlZCB0byBzdXBwb3J0IEZFIA0KICAgICAgYmFja3dhcmQgY29tcGF0aWJpbGl0eTogDQog ICAgICAgIDEuIFdoZW4gZGV0ZWN0aW5nIGFuIExGQiBpbnN0YW5jZSBvZiBhbiBMRkIgdHlwZSB0 aGF0IGlzIA0KICAgICAgICAgICB1bmtub3duIHRvIHRoZSBDRSwgdGhlIENFIE1VU1QgYmUgYWJs ZSB0byBxdWVyeSB0aGUgYmFzZSANCiAgICAgICAgICAgY2xhc3Mgb2Ygc3VjaCBhbiBMRkIgZnJv bSB0aGUgRkUuIA0KICAgICAgICAyLiBUaGUgTEZCIGluc3RhbmNlIG9uIHRoZSBGRSBTSE9VTEQg c3VwcG9ydCBhIGJhY2t3YXJkIA0KICAgICAgICAgICBjb21wYXRpYmlsaXR5IG1vZGUgKG1lYW5p bmcgdGhlIExGQiBpbnN0YW5jZSByZXZlcnRzIGl0c2VsZiANCiAgICAgICAgICAgYmFjayB0byB0 aGUgYmFzZSBjbGFzcyBpbnN0YW5jZSksIGFuZCB0aGUgQ0UgU0hPVUxEIGJlIGFibGUgDQogICAg ICAgICAgIHRvIGNvbmZpZ3VyZSB0aGUgTEZCIHRvIHJ1biBpbiBzdWNoIGEgbW9kZS4gDQogICAg ICAgDQogICAzLjMuIEZFIERhdGFwYXRoIE1vZGVsaW5nICANCiAgICAgICANCiAgICAgIFBhY2tl dHMgY29taW5nIGludG8gdGhlIEZFIGZyb20gaW5ncmVzcyBwb3J0cyBnZW5lcmFsbHkgZmxvdyAN CiAgICAgIHRocm91Z2ggbXVsdGlwbGUgTEZCcyBiZWZvcmUgbGVhdmluZyBvdXQgb2YgdGhlIGVn cmVzcyBwb3J0cy4gIEhvdyANCiAgICAgIGFuIEZFIHRyZWF0cyBhIHBhY2tldCBkZXBlbmRzIG9u IG1hbnkgZmFjdG9ycywgc3VjaCBhcyB0eXBlIG9mIHRoZSANCiAgICAgIHBhY2tldCAoZS5nLiwg SVB2NCwgSVB2NiBvciBNUExTKSwgYWN0dWFsIGhlYWRlciB2YWx1ZXMsIHRpbWUgb2YgDQogICAg ICBhcnJpdmFsLCBldGMuICBUaGUgcmVzdWx0IG9mIExGQiBwcm9jZXNzaW5nIG1heSBoYXZlIGFu IGltcGFjdCBvbiANCiAgICAgIGhvdyB0aGUgcGFja2V0IGlzIHRvIGJlIHRyZWF0ZWQgaW4gZG93 bnN0cmVhbSBMRkJzLiAgVGhpcyANCiAgICAgIGRpZmZlcmVudGlhdGlvbiBvZiBwYWNrZXQgdHJl YXRtZW50IGRvd25zdHJlYW0gY2FuIGJlIA0KICAgICAgY29uY2VwdHVhbGl6ZWQgYXMgaGF2aW5n IGFsdGVybmF0aXZlIGRhdGFwYXRocyBpbiB0aGUgRkUuICBGb3IgDQogICAgICBleGFtcGxlLCB0 aGUgcmVzdWx0IG9mIGEgNi10dXBsZSBjbGFzc2lmaWNhdGlvbiBwZXJmb3JtZWQgYnkgYSANCiAg ICAgIGNsYXNzaWZpZXIgTEZCIGNvdWxkIGNvbnRyb2wgd2hpY2ggcmF0ZSBtZXRlciBpcyBhcHBs aWVkIHRvIHRoZSANCiAgICAgIHBhY2tldCBieSBhIHJhdGUgbWV0ZXIgTEZCIGluIGEgbGF0ZXIg c3RhZ2UgaW4gdGhlIGRhdGFwYXRoLiAgIA0KICAgICAgIA0KICAgICAgTEZCIHRvcG9sb2d5IGlz IGEgZGlyZWN0ZWQgZ3JhcGggcmVwcmVzZW50YXRpb24gb2YgdGhlIGxvZ2ljYWwgDQogICAgICBk YXRhcGF0aHMgd2l0aGluIGFuIEZFLCB3aXRoIHRoZSBub2RlcyByZXByZXNlbnRpbmcgdGhlIExG QiANCiAgICAgIGluc3RhbmNlcyBhbmQgdGhlIGRpcmVjdGVkIGxpbmsgZGVwaWN0aW5nIHRoZSBw YWNrZXQgZmxvdyANCiAgICAgIGRpcmVjdGlvbiBmcm9tIG9uZSBMRkIgdG8gdGhlIG5leHQuICBT ZWN0aW9uIDMuMy4xIGRpc2N1c3NlcyBob3cgDQogICAgICB0aGUgRkUgZGF0YXBhdGhzIGNhbiBi ZSBtb2RlbGVkIGFzIExGQiB0b3BvbG9neTsgd2hpbGUgU2VjdGlvbiANCiAgICAgIDMuMy4yIGZv Y3VzZXMgb24gaXNzdWVzIHJlbGF0ZWQgdG8gTEZCIHRvcG9sb2d5IHJlY29uZmlndXJhdGlvbi4g ICANCiAgICAgICANCiAgIDMuMy4xLiBBbHRlcm5hdGl2ZSBBcHByb2FjaGVzIGZvciBNb2RlbGlu ZyBGRSBEYXRhcGF0aHMgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3Vz dCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdIA0KDCAgIEludGVybmV0IERy YWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAg ICANCiAgICANCiAgICAgICANCiAgICAgIFRoZXJlIGFyZSB0d28gYmFzaWMgd2F5cyB0byBleHBy ZXNzIHRoZSBkaWZmZXJlbnRpYXRpb24gaW4gcGFja2V0IA0KICAgICAgdHJlYXRtZW50IHdpdGhp biBhbiBGRSwgb25lIHJlcHJlc2VudHMgdGhlIGRhdGFwYXRoIGRpcmVjdGx5IGFuZCANCiAgICAg IGdyYXBoaWNhbGx5ICh0b3BvbG9naWNhbCBhcHByb2FjaCkgYW5kIHRoZSBvdGhlciB1dGlsaXpl cyBtZXRhZGF0YSANCiAgICAgICh0aGUgZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCkuIA0KICAgICAg IA0KICAgICAgICAuIFRvcG9sb2dpY2FsIEFwcHJvYWNoIA0KICAgICAgIA0KICAgICAgICBVc2lu ZyB0aGlzIGFwcHJvYWNoLCBkaWZmZXJlbnRpYWwgcGFja2V0IHRyZWF0bWVudCBpcyBleHByZXNz ZWQgDQogICAgICAgIGJ5IHNwbGl0dGluZyB0aGUgTEZCIHRvcG9sb2d5IGludG8gYWx0ZXJuYXRp dmUgcGF0aHMuICBJbiBvdGhlciANCiAgICAgICAgd29yZHMsIGlmIHRoZSByZXN1bHQgb2YgYW4g TEZCIG11c3QgY29udHJvbCBob3cgdGhlIHBhY2tldCBpcyANCiAgICAgICAgZnVydGhlciBwcm9j ZXNzZWQsIHRoZW4gc3VjaCBhbiBMRkIgd2lsbCBoYXZlIHNlcGFyYXRlIG91dHB1dCANCiAgICAg ICAgcG9ydHMsIG9uZSBmb3IgZWFjaCBhbHRlcm5hdGl2ZSB0cmVhdG1lbnQsIGNvbm5lY3RlZCB0 byANCiAgICAgICAgc2VwYXJhdGUgc3ViLWdyYXBocywgZWFjaCBleHByZXNzaW5nIHRoZSByZXNw ZWN0aXZlIHRyZWF0bWVudCANCiAgICAgICAgZG93bnN0cmVhbS4gDQogICAgICAgDQogICAgICAg IC4gRW5jb2RlZCBTdGF0ZSBBcHByb2FjaCANCiAgICAgICANCiAgICAgICAgQW4gYWx0ZXJuYXRl IHdheSBvZiBleHByZXNzaW5nIGRpZmZlcmVudGlhbCB0cmVhdG1lbnQgaXMgYnkgDQogICAgICAg IHVzaW5nIG1ldGFkYXRhLiAgVGhlIHJlc3VsdCBvZiB0aGUgb3BlcmF0aW9uIG9mIGFuIExGQiBj YW4gYmUgDQogICAgICAgIGVuY29kZWQgaW4gYSBtZXRhZGF0YSwgd2hpY2ggaXMgcGFzc2VkIGFs b25nIHdpdGggdGhlIHBhY2tldCB0byANCiAgICAgICAgZG93bnN0cmVhbSBMRkJzLiAgQSBkb3du c3RyZWFtIExGQiwgaW4gdHVybiwgY2FuIHVzZSB0aGUgDQogICAgICAgIG1ldGFkYXRhIGFuZCBp dHMgdmFsdWUgKGUuZy4sIGFzIGFuIGluZGV4IGludG8gc29tZSB0YWJsZSkgdG8gDQogICAgICAg IGRldGVybWluZSBob3cgdG8gdHJlYXQgdGhlIHBhY2tldC4gDQogICAgICAgDQogICAgICBUaGVv cmV0aWNhbGx5LCBlaXRoZXIgYXBwcm9hY2ggY291bGQgc3Vic3RpdHV0ZSBmb3IgdGhlIG90aGVy LCBzbyANCiAgICAgIG9uZSBjb3VsZCBjb25zaWRlciB1c2luZyBhIHNpbmdsZSBwdXJlIGFwcHJv YWNoIHRvIGRlc2NyaWJlIGFsbCANCiAgICAgIGRhdGFwYXRocyBpbiBhbiBGRS4gIEhvd2V2ZXIs IG5laXRoZXIgbW9kZWwgYnkgaXRzZWxmIHJlc3VsdHMgaW4gDQogICAgICB0aGUgYmVzdCByZXBy ZXNlbnRhdGlvbiBmb3IgYWxsIHByYWN0aWNhbGx5IHJlbGV2YW50IGNhc2VzLiAgRm9yIGEgDQog ICAgICBnaXZlbiBGRSB3aXRoIGNlcnRhaW4gbG9naWNhbCBkYXRhcGF0aHMsIGFwcGx5aW5nIHRo ZSB0d28gDQogICAgICBkaWZmZXJlbnQgbW9kZWxpbmcgYXBwcm9hY2hlcyB3aWxsIHJlc3VsdCBp biB2ZXJ5IGRpZmZlcmVudCANCiAgICAgIGxvb2tpbmcgTEZCIHRvcG9sb2d5IGdyYXBocy4gIEEg bW9kZWwgdXNpbmcgb25seSB0aGUgdG9wb2xvZ2ljYWwgDQogICAgICBhcHByb2FjaCBtYXkgcmVx dWlyZSBhIHZlcnkgbGFyZ2UgZ3JhcGggd2l0aCBtYW55IGxpbmtzIG9yIHBhdGhzLCANCiAgICAg IGFuZCBub2RlcyAoaS5lLiwgTEZCIGluc3RhbmNlcykgdG8gZXhwcmVzcyBhbGwgYWx0ZXJuYXRp dmUgDQogICAgICBkYXRhcGF0aHMuICBPbiB0aGUgb3RoZXIgaGFuZCwgYSBtb2RlbCB1c2luZyBv bmx5IHRoZSBlbmNvZGVkIA0KICAgICAgc3RhdGUgbW9kZWwgd291bGQgYmUgcmVzdHJpY3RlZCB0 byBhIHN0cmluZyBvZiBMRkJzLCB3aGljaCBpcyBub3QgDQogICAgICBhbiBpbnR1aXRpdmUgd2F5 IHRvIGRlc2NyaWJlIGRpZmZlcmVudCBkYXRhcGF0aHMgKHN1Y2ggYXMgTVBMUyBhbmQgDQogICAg ICBJUHY0KS4gIFRoZXJlZm9yZSwgYSBtaXggb2YgdGhlc2UgdHdvIGFwcHJvYWNoZXMgd2lsbCBs aWtlbHkgYmUgDQogICAgICB1c2VkIGZvciBhIHByYWN0aWNhbCBtb2RlbC4gIEluIGZhY3QsIGFz IHdlIGlsbHVzdHJhdGUgYmVsb3csIHRoZSANCiAgICAgIHR3byBhcHByb2FjaGVzIGNhbiBiZSBt aXhlZCBldmVuIHdpdGhpbiB0aGUgc2FtZSBMRkIuICANCiAgICAgICANCiAgICAgIFVzaW5nIGEg c2ltcGxlIGV4YW1wbGUgb2YgYSBjbGFzc2lmaWVyIHdpdGggTiBjbGFzc2lmaWNhdGlvbiANCiAg ICAgIG91dHB1dHMgZm9sbG93ZWQgYnkgb3RoZXIgTEZCcywgRmlndXJlIDUoYSkgc2hvd3Mgd2hh dCB0aGUgTEZCIA0KICAgICAgdG9wb2xvZ3kgbG9va3MgbGlrZSB3aGVuIHVzaW5nIHRoZSBwdXJl IHRvcG9sb2dpY2FsIGFwcHJvYWNoLiAgDQogICAgICBFYWNoIG91dHB1dCBmcm9tIHRoZSBjbGFz c2lmaWVyIGdvZXMgdG8gb25lIG9mIHRoZSBOIExGQnMgd2hlcmUgbm8gDQogICAgICBtZXRhZGF0 YSBpcyBuZWVkZWQuICBUaGUgdG9wb2xvZ2ljYWwgYXBwcm9hY2ggaXMgc2ltcGxlLCANCiAgICAg IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgZ3JhcGhpY2FsbHkgaW50dWl0aXZlLiAgSG93ZXZlciwgaWYg TiBpcyBsYXJnZSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIw MDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyOV0gDQoMICAgSW50ZXJuZXQgRHJhZnQg ICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0K ICAgIA0KICAgICAgYW5kIHRoZSBOIG5vZGVzIGZvbGxvd2luZyB0aGUgY2xhc3NpZmllciAoTEZC IzEsIExGQiMyLCAuLi4sIA0KICAgICAgTEZCI04pIGFsbCBiZWxvbmcgdG8gdGhlIHNhbWUgTEZC IHR5cGUgKGUuZy4sIG1ldGVyKSwgYnV0IGVhY2ggaGFzIA0KICAgICAgaXRzIG93biBpbmRlcGVu ZGVudCBhdHRyaWJ1dGVzLCB0aGUgZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCBnaXZlcyBhIA0KICAg ICAgbXVjaCBzaW1wbGVyIHRvcG9sb2d5IHJlcHJlc2VudGF0aW9uLCBhcyBzaG93biBpbiBGaWd1 cmUgNShiKS4gIA0KICAgICAgVGhlIGVuY29kZWQgc3RhdGUgYXBwcm9hY2ggcmVxdWlyZXMgdGhh dCBhIHRhYmxlIG9mIE4gcm93cyBvZiANCiAgICAgIG1ldGVyIGF0dHJpYnV0ZXMgaXMgcHJvdmlk ZWQgaW4gdGhlIE1ldGVyIG5vZGUgaXRzZWxmLCB3aXRoIGVhY2ggDQogICAgICByb3cgcmVwcmVz ZW50aW5nIHRoZSBhdHRyaWJ1dGVzIGZvciBvbmUgbWV0ZXIgaW5zdGFuY2UuICBBIA0KICAgICAg bWV0YWRhdGEgTSBpcyBhbHNvIG5lZWRlZCB0byBwYXNzIGFsb25nIHdpdGggdGhlIHBhY2tldCBQ IGZyb20gdGhlIA0KICAgICAgY2xhc3NpZmllciB0byB0aGUgbWV0ZXIsIHNvIHRoYXQgdGhlIG1l dGVyIGNhbiB1c2UgTSBhcyBhIGxvb2stdXAgDQogICAgICBrZXkgKGluZGV4KSB0byBmaW5kIHRo ZSBjb3JyZXNwb25kaW5nIHJvdyBvZiB0aGUgYXR0cmlidXRlcyB0aGF0IA0KICAgICAgc2hvdWxk IGJlIHVzZWQgZm9yIGFueSBwYXJ0aWN1bGFyIHBhY2tldCBQLiANCiAgICAgICANCiAgICAgIFdo YXQgaWYgdGhvc2UgTiBub2RlcyAoTEZCIzEsIExGQiMyLCAuLi4sIExGQiNOKSBhcmUgbm90IG9m IHRoZSANCiAgICAgIHNhbWUgdHlwZT8gRm9yIGV4YW1wbGUsIGlmIExGQiMxIGlzIGEgcXVldWUg d2hpbGUgdGhlIHJlc3QgYXJlIGFsbCANCiAgICAgIG1ldGVycywgd2hhdCBpcyB0aGUgYmVzdCB3 YXkgdG8gcmVwcmVzZW50IHN1Y2ggZGF0YXBhdGhzPyAgV2hpbGUgDQogICAgICBpdCBpcyBzdGls bCBwb3NzaWJsZSB0byB1c2UgZWl0aGVyIHRoZSBwdXJlIHRvcG9sb2dpY2FsIGFwcHJvYWNoIA0K ICAgICAgb3IgdGhlIHB1cmUgZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCwgdGhlIG5hdHVyYWwgY29t YmluYXRpb24gb2YgdGhlIA0KICAgICAgdHdvIGFwcGVhcnMgdG8gYmUgdGhlIGJlc3Qgb3B0aW9u LiBGaWd1cmUgNShjKSBkZXBpY3RzIHR3byANCiAgICAgIGRpZmZlcmVudCBmdW5jdGlvbmFsIGRh dGFwYXRocyB1c2luZyB0aGUgdG9wb2xvZ2ljYWwgYXBwcm9hY2ggDQogICAgICB3aGlsZSBsZWF2 aW5nIHRoZSBOLTEgbWV0ZXIgaW5zdGFuY2VzIGRpc3Rpbmd1aXNoZWQgYnkgbWV0YWRhdGEgDQog ICAgICBvbmx5LCBhcyBzaG93biBpbiBGaWd1cmUgNShjKS4gIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFAgICAgICB8ICAgTEZCIzEgIHwgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0+fChBdHRyaWItMSl8IA0KICAgICAgICAgICArLS0t LS0tLS0tLS0tLSsgICAgICB8ICAgICAgICAgICstLS0tLS0tLS0tKyANCiAgICAgICAgICAgfCAg ICAgICAgICAgIDF8LS0tLS0tKyAgIFAgICAgICArLS0tLS0tLS0tLSsgDQogICAgICAgICAgIHwg ICAgICAgICAgICAyfC0tLS0tLS0tLS0tLS0tLS0+fCAgIExGQiMyICB8IA0KICAgICAgICAgICB8 IGNsYXNzaWZpZXIgM3wgICAgICAgICAgICAgICAgIHwoQXR0cmliLTIpfCANCiAgICAgICAgICAg fCAgICAgICAgICAuLi58Li4uICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgDQogICAgICAgICAg IHwgICAgICAgICAgICBOfC0tLS0tLSsgICAgICAgICAgLi4uIA0KICAgICAgICAgICArLS0tLS0t LS0tLS0tLSsgICAgICB8ICAgUCAgICAgICstLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLT58ICAgTEZCI04gIHwgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfChBdHRyaWItTil8IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgNShhKSBVc2luZyBwdXJlIHRv cG9sb2dpY2FsIGFwcHJvYWNoICANCiAgICAgICANCiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgIHwgICAgICAgICAg ICAxfCAgICAgICAgICAgICAgICAgfCAgIE1ldGVyICAgICB8IA0KICAgICAgICAgICB8ICAgICAg ICAgICAgMnwgICAoUCwgTSkgICAgICAgIHwgKEF0dHJpYi0xKSAgfCANCiAgICAgICAgICAgfCAg ICAgICAgICAgIDN8LS0tLS0tLS0tLS0tLS0tLT58IChBdHRyaWItMikgIHwgDQogICAgICAgICAg IHwgICAgICAgICAgLi4ufCAgICAgICAgICAgICAgICAgfCAgIC4uLiAgICAgICB8IA0KICAgICAg ICAgICB8ICAgICAgICAgICAgTnwgICAgICAgICAgICAgICAgIHwgKEF0dHJpYi1OKSAgfCANCiAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsg DQogICAgICAgDQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDMwXSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICAgICAgICA1KGIpIFVzaW5nIHB1cmUgZW5jb2RlZCBzdGF0ZSBhcHByb2Fj aCB0byByZXByZXNlbnQgdGhlIExGQiANCiAgICAgICAgICAgdG9wb2xvZ3kgaW4gNShhKSwgaWYg TEZCIzEsIExGQiMyLCAuLi4sIGFuZCBMRkIjTiBhcmUgb2YgdGhlIA0KICAgICAgICAgICAgICAg ICAgICAgICAgIHNhbWUgdHlwZSAoZS5nLiwgbWV0ZXIpLiAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rIA0KICAgICAg ICAgICArLS0tLS0tLS0tLS0tLSsgKFAsIE0pICAgICAgIHwgcXVldWUgICAgICAgfCANCiAgICAg ICAgICAgfCAgICAgICAgICAgIDF8LS0tLS0tLS0tLS0tLT58IChBdHRyaWItMSkgIHwgDQogICAg ICAgICAgIHwgICAgICAgICAgICAyfCAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rIA0KICAg ICAgICAgICB8ICAgICAgICAgICAgM3wgKFAsIE0pICAgICAgICstLS0tLS0tLS0tLS0tKyANCiAg ICAgICAgICAgfCAgICAgICAgICAuLi58LS0tLS0tLS0tLS0tLT58ICAgTWV0ZXIgICAgIHwgICAN CiAgICAgICAgICAgfCAgICAgICAgICAgIE58ICAgICAgICAgICAgICB8IChBdHRyaWItMikgIHwg DQogICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgfCAgIC4uLiAgICAgICB8 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKEF0dHJpYi1OKSAg fCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsgDQogICAgICAgDQogICAgICAgICAgICA1KGMpIFVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhl IHR3bywgaWYgTEZCIzEsIExGQiMyLCAuLi4sIA0KICAgICAgICAgICAgIGFuZCBMRkIjTiBhcmUg b2YgZGlmZmVyZW50IHR5cGVzIChlLmcuLCBxdWV1ZSBhbmQgbWV0ZXIpLiANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICBGaWd1cmUg NS4gQW4gZXhhbXBsZSBvZiBob3cgdG8gbW9kZWwgRkUgZGF0YXBhdGhzIA0KICAgIA0KICAgICAg RnJvbSB0aGlzIGV4YW1wbGUsIHdlIGRlbW9uc3RyYXRlIHRoYXQgZWFjaCBhcHByb2FjaCBoYXMg YSANCiAgICAgIGRpc3RpbmN0IGFkdmFudGFnZSBkZXBlbmRpbmcgb24gdGhlIHNpdHVhdGlvbi4g IFVzaW5nIHRoZSBlbmNvZGVkIA0KICAgICAgc3RhdGUgYXBwcm9hY2gsIGZld2VyIGNvbm5lY3Rp b25zIGFyZSB0eXBpY2FsbHkgbmVlZGVkIGJldHdlZW4gYSANCiAgICAgIGZhbi1vdXQgbm9kZSBh bmQgaXRzIG5leHQgTEZCIGluc3RhbmNlcyBvZiB0aGUgc2FtZSB0eXBlIGJlY2F1c2UgDQogICAg ICBlYWNoIHBhY2tldCBjYXJyaWVzIG1ldGFkYXRhIHRoZSBmb2xsb3dpbmcgbm9kZXMgY2FuIGlu dGVycHJldCBhbmQgDQogICAgICBoZW5jZSBpbnZva2UgYSBkaWZmZXJlbnQgcGFja2V0IHRyZWF0 bWVudC4gIEZvciB0aG9zZSBjYXNlcywgYSANCiAgICAgIHB1cmUgdG9wb2xvZ2ljYWwgYXBwcm9h Y2ggZm9yY2VzIG9uZSB0byBidWlsZCBlbGFib3JhdGUgZ3JhcGhzIA0KICAgICAgd2l0aCBtYW55 IG1vcmUgY29ubmVjdGlvbnMgYW5kIG9mdGVuIHJlc3VsdHMgaW4gYW4gdW53aWVsZHkgZ3JhcGgu ICANCiAgICAgIE9uIHRoZSBvdGhlciBoYW5kLCBhIHRvcG9sb2dpY2FsIGFwcHJvYWNoIGlzIHRo ZSBtb3N0IGludHVpdGl2ZSANCiAgICAgIGZvciByZXByZXNlbnRpbmcgZnVuY3Rpb25hbGx5IGRp ZmZlcmVudCBkYXRhcGF0aHMuIA0KICAgICAgIA0KICAgICAgRm9yIGNvbXBsZXggdG9wb2xvZ2ll cywgYSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvIGlzIHRoZSBtb3N0IA0KICAgICAgZmxleGlibGUu ICBBIGdlbmVyYWwgZGVzaWduIGd1aWRlbGluZSBpcyBwcm92aWRlZCB0byBpbmRpY2F0ZSANCiAg ICAgIHdoaWNoIGFwcHJvYWNoIGlzIGJlc3QgdXNlZCBmb3IgYSBwYXJ0aWN1bGFyIHNpdHVhdGlv bi4gIFRoZSANCiAgICAgIHRvcG9sb2dpY2FsIGFwcHJvYWNoIHNob3VsZCBwcmltYXJpbHkgYmUg dXNlZCB3aGVuIHRoZSBwYWNrZXQgDQogICAgICBkYXRhcGF0aCBmb3JrcyB0byBkaXN0aW5jdCBM RkIgY2xhc3NlcyAobm90IGp1c3QgZGlzdGluY3QgDQogICAgICBwYXJhbWV0ZXJpemF0aW9ucyBv ZiB0aGUgc2FtZSBMRkIgY2xhc3MpLCBhbmQgd2hlbiB0aGUgZmFuLW91dHMgZG8gDQogICAgICBu b3QgcmVxdWlyZSBjaGFuZ2VzLCBzdWNoIGFzIGFkZGluZy9yZW1vdmluZyBMRkIgb3V0cHV0cywg b3IgDQogICAgICByZXF1aXJlIG9ubHkgdmVyeSBpbmZyZXF1ZW50IGNoYW5nZXMuICBDb25maWd1 cmF0aW9uIGluZm9ybWF0aW9uIA0KICAgICAgdGhhdCBuZWVkcyB0byBjaGFuZ2UgZnJlcXVlbnRs eSBzaG91bGQgYmUgZXhwcmVzc2VkIGJ5IHVzaW5nIHRoZSANCiAgICAgIGludGVybmFsIGF0dHJp YnV0ZXMgb2Ygb25lIG9yIG1vcmUgTEZCcyAoYW5kIGhlbmNlIHVzaW5nIHRoZSANCiAgICAgIGVu Y29kZWQgc3RhdGUgYXBwcm9hY2gpLiANCiAgICAgICANCg0KDQoNCg0KICAgIA0KICAgWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDMxXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICAgICstLS0tLS0tLS0tKyAgViAgICAgICstLS0tLS0tLS0t KyAgICAgICAgICAgKy0tLS0tLSsgICAgICAgIHwgDQogICAgICAgICAgIHwgICAgICAgICAgfCAg fCAgICAgIHwgICAgICAgICAgfGlmIElQLWluLUlQfCAgICAgIHwgICAgICAgIHwgDQogICAgICAt LS0tPnwgaW5ncmVzcyAgfC0+Ky0tLS0tPnxjbGFzc2lmaWVyfC0tLS0tLS0tLS0+fERlY2FwLnwt LS0tPi0tLSsgDQogICAgICAgICAgIHwgcG9ydHMgICAgfCAgICAgICAgIHwgICAgICAgICAgfC0t LS0rICAgICAgfCAgICAgIHwgDQogICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICstLS0t LS0tLS0tKyAgICB8b3RoZXJzKy0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgViANCiAgICAgICAgICAgKGEpICBUaGUgTEZCIHRvcG9sb2d5IHdpdGgg YSBsb2dpY2FsIGxvb3AgDQogICAgDQogICAgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0tLS0t KyAgICAgICAgICAgICstLS0tLS0rICAgKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICB8ICAgICAg IHwgICB8ICAgICAgICAgICB8aWYgSVAtaW4tSVAgfCAgICAgIHwgICB8ICAgICAgICAgICB8IA0K ICAgICAgLS0tPnxpbmdyZXNzfC0tPnxjbGFzc2lmaWVyMXwtLS0tLS0tLS0tLT58RGVjYXAufC0t PitjbGFzc2lmaWVyMnwtDQogICA+IA0KICAgICAgICAgIHwgcG9ydHMgfCAgIHwgICAgICAgICAg IHwtLS0tKyAgICAgICB8ICAgICAgfCAgIHwgICAgICAgICAgIHwgDQogICAgICAgICAgKy0tLS0t LS0rICAgKy0tLS0tLS0tLS0tKyAgICB8b3RoZXJzICstLS0tLS0rICAgKy0tLS0tLS0tLS0tKyAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBWIA0KICAgICAgICAgICAoYikgIFRoZSBMRkIgdG9w b2xvZ3kgd2l0aG91dCB0aGUgbG9vcCB1dGlsaXppbmcgdHdvIA0KICAgICAgICAgICAgICAgIGlu ZGVwZW5kZW50IGNsYXNzaWZpZXIgaW5zdGFuY2VzLiANCiAgICAgICANCiAgICAgICAgICAgICAg ICAgICBGaWd1cmUgNi4gQW4gTEZCIHRvcG9sb2d5IGV4YW1wbGUuIA0KICAgIA0KICAgICAgSXQg aXMgaW1wb3J0YW50IHRvIHBvaW50IG91dCB0aGF0IHRoZSBMRkIgdG9wb2xvZ3kgZGVzY3JpYmVk IGhlcmUgDQogICAgICBpcyB0aGUgbG9naWNhbCB0b3BvbG9neSwgbm90IHRoZSBwaHlzaWNhbCB0 b3BvbG9neSBvZiBob3cgdGhlIEZFIA0KICAgICAgaGFyZHdhcmUgaXMgYWN0dWFsbHkgbGFpZCBv dXQuICBOZXZlcnRoZWxlc3MsIHRoZSBhY3R1YWwgDQogICAgICBpbXBsZW1lbnRhdGlvbiBtYXkg c3RpbGwgaW5mbHVlbmNlIGhvdyB0aGUgZnVuY3Rpb25hbGl0eSBpcyBtYXBwZWQgDQogICAgICB0 byB0aGUgTEZCIHRvcG9sb2d5LiAgRmlndXJlIDYgc2hvd3Mgb25lIHNpbXBsZSBGRSBleGFtcGxl LiAgSW4gDQogICAgICB0aGlzIGV4YW1wbGUsIGFuIElQLWluLUlQIHBhY2tldCBmcm9tIGFuIElQ U2VjIGFwcGxpY2F0aW9uIGxpa2UgDQogICAgICBWUE4gbWF5IGdvIHRvIHRoZSBjbGFzc2lmaWVy IGZpcnN0IGFuZCBoYXZlIHRoZSBjbGFzc2lmaWNhdGlvbiANCiAgICAgIGRvbmUgYmFzZWQgb24g dGhlIG91dGVyIElQIGhlYWRlcjsgdXBvbiBiZWluZyBjbGFzc2lmaWVkIGFzIGFuIElQLQ0KICAg ICAgaW4tSVAgcGFja2V0LCB0aGUgcGFja2V0IGlzIHRoZW4gc2VudCB0byBhIGRlY2Fwc3VsYXRv ciB0byBzdHJpcCANCiAgICAgIG9mZiB0aGUgb3V0ZXIgSVAgaGVhZGVyLCBmb2xsb3dlZCBieSBh IGNsYXNzaWZpZXIgYWdhaW4gdG8gcGVyZm9ybSANCiAgICAgIGNsYXNzaWZpY2F0aW9uIG9uIHRo ZSBpbm5lciBJUCBoZWFkZXIuIElmIHRoZSBzYW1lIGNsYXNzaWZpZXIgDQogICAgICBoYXJkd2Fy ZSBvciBzb2Z0d2FyZSBpcyB1c2VkIGZvciBib3RoIG91dGVyIGFuZCBpbm5lciBJUCBoZWFkZXIg DQogICAgICBjbGFzc2lmaWNhdGlvbiB3aXRoIHRoZSBzYW1lIHNldCBvZiBmaWx0ZXJpbmcgcnVs ZXMsIGEgbG9naWNhbCANCiAgICAgIGxvb3AgaXMgbmF0dXJhbGx5IHByZXNlbnQgaW4gdGhlIExG QiB0b3BvbG9neSwgYXMgc2hvd24gaW4gRmlndXJlIA0KICAgICAgNihhKS4gIEhvd2V2ZXIsIGlm IHRoZSBjbGFzc2lmaWNhdGlvbiBpcyBpbXBsZW1lbnRlZCBieSB0d28gDQogICAgICBkaWZmZXJl bnQgcGllY2VzIG9mIGhhcmR3YXJlIG9yIHNvZnR3YXJlIHdpdGggZGlmZmVyZW50IGZpbHRlcnMg DQogICAgICAoaS5lLiwgb25lIHNldCBvZiBmaWx0ZXJzIGZvciB0aGUgb3V0ZXIgSVAgaGVhZGVy IGFuZCBhbm90aGVyIHNldCANCiAgICAgIGZvciB0aGUgaW5uZXIgSVAgaGVhZGVyKSwgdGhlbiBp dCBpcyBtb3JlIG5hdHVyYWwgdG8gbW9kZWwgdGhlbSBhcyANCiAgICAgIHR3byBkaWZmZXJlbnQg aW5zdGFuY2VzIG9mIGNsYXNzaWZpZXIgTEZCLCBhcyBzaG93biBpbiBGaWd1cmUgDQogICAgICA2 KGIpLiANCiAgICANCiAgICAgIFRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIExGQiBjbGFzcywgDQogICAgICBlYWNoIExGQiBpbnN0YW5jZSBoYXMg aXRzIG93biBMRkIgaW5zdGFuY2UgSUQuICBPbmUgd2F5IHRvIGVuY29kZSANCiAgICANCiAgIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAzMl0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgdGhlIExGQiBpbnN0 YW5jZSBJRCBpcyB0byBlbmNvZGUgaXQgYXMgeC55IHdoZXJlIHggaXMgdGhlIExGQiANCiAgICAg IGNsYXNzIElEIGFuZCB5IGlzIHRoZSBpbnN0YW5jZSBJRCB3aXRoaW4gZWFjaCBMRkIgY2xhc3Mu IA0KICAgICAgIA0KICAgMy4zLjIuIENvbmZpZ3VyaW5nIHRoZSBMRkIgVG9wb2xvZ3kgIA0KICAg ICAgIA0KICAgICAgV2hpbGUgdGhlcmUgaXMgbGl0dGxlIGRvdWJ0IHRoYXQgYW4gaW5kaXZpZHVh bCBMRkIgbXVzdCBiZSANCiAgICAgIGNvbmZpZ3VyYWJsZSwgdGhlIGNvbmZpZ3VyYWJpbGl0eSBx dWVzdGlvbiBpcyBtb3JlIGNvbXBsaWNhdGVkIGZvciANCiAgICAgIExGQiB0b3BvbG9neS4gIFNp bmNlIHRoZSBMRkIgdG9wb2xvZ3kgaXMgcmVhbGx5IHRoZSBncmFwaGljIA0KICAgICAgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGRhdGFwYXRocyB3aXRoaW4gYW4gRkUsIGNvbmZpZ3VyaW5nIHRoZSBM RkIgDQogICAgICB0b3BvbG9neSBtZWFucyBkeW5hbWljYWxseSBjaGFuZ2luZyB0aGUgZGF0YXBh dGhzLCBpbmNsdWRpbmcgDQogICAgICBjaGFuZ2luZyB0aGUgTEZCcyBhbG9uZyB0aGUgZGF0YXBh dGhzIG9uIGFuIEZFIChlLmcuLCBjcmVhdGluZywgDQogICAgICBpbnN0YW50aWF0aW5nIG9yIGRl bGV0aW5nIExGQnMpIGFuZCBzZXR0aW5nIHVwIG9yIGRlbGV0aW5nIA0KICAgICAgaW50ZXJjb25u ZWN0aW9ucyBiZXR3ZWVuIG91dHB1dHMgb2YgdXBzdHJlYW0gTEZCcyB0byBpbnB1dHMgb2YgDQog ICAgICBkb3duc3RyZWFtIExGQnMuICAgDQogICAgICAgDQogICAgICBXaHkgd291bGQgdGhlIGRh dGFwYXRocyBvbiBhbiBGRSBldmVyIGNoYW5nZSBkeW5hbWljYWxseT8gIFRoZSANCiAgICAgIGRh dGFwYXRocyBvbiBhbiBGRSBhcmUgc2V0IHVwIGJ5IHRoZSBDRSB0byBwcm92aWRlIGNlcnRhaW4g ZGF0YSANCiAgICAgIHBsYW5lIHNlcnZpY2VzIChlLmcuLCBEaWZmU2VydiwgVlBOLCBldGMuKSB0 byB0aGUgTmV0d29yayANCiAgICAgIEVsZW1lbnQncyAoTkUpIGN1c3RvbWVycy4gIFRoZSBwdXJw b3NlIG9mIHJlY29uZmlndXJpbmcgdGhlIA0KICAgICAgZGF0YXBhdGhzIGlzIHRvIGVuYWJsZSB0 aGUgQ0UgdG8gY3VzdG9taXplIHRoZSBzZXJ2aWNlcyB0aGUgTkUgaXMgDQogICAgICBkZWxpdmVy aW5nIGF0IHJ1biB0aW1lLiAgVGhlIENFIG5lZWRzIHRvIGNoYW5nZSB0aGUgZGF0YXBhdGhzIHdo ZW4gDQogICAgICB0aGUgc2VydmljZSByZXF1aXJlbWVudHMgY2hhbmdlLCBzdWNoIGFzIGFkZGlu ZyBhIG5ldyBjdXN0b21lciBvciANCiAgICAgIHdoZW4gYW4gZXhpc3RpbmcgY3VzdG9tZXIgY2hh bmdlcyB0aGVpciBzZXJ2aWNlLiAgSG93ZXZlciwgbm90ZSANCiAgICAgIHRoYXQgbm90IGFsbCBk YXRhcGF0aCBjaGFuZ2VzIHJlc3VsdCBpbiBjaGFuZ2VzIGluIHRoZSBMRkIgDQogICAgICB0b3Bv bG9neSBncmFwaC4gQ2hhbmdlcyBpbiB0aGUgZ3JhcGggYXJlIGRlcGVuZGVudCBvbiB0aGUgYXBw cm9hY2ggDQogICAgICB1c2VkIHRvIG1hcCB0aGUgZGF0YXBhdGhzIGludG8gTEZCIHRvcG9sb2d5 LiAgQXMgZGlzY3Vzc2VkIGluIA0KICAgICAgMy4zLjEsIHRoZSB0b3BvbG9naWNhbCBhcHByb2Fj aCBhbmQgZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCBjYW4gDQogICAgICByZXN1bHQgaW4gdmVyeSBk aWZmZXJlbnQgbG9va2luZyBMRkIgdG9wb2xvZ2llcyBmb3IgdGhlIHNhbWUgDQogICAgICBkYXRh cGF0aHMuICBJbiBnZW5lcmFsLCBhbiBMRkIgdG9wb2xvZ3kgYmFzZWQgb24gYSBwdXJlIA0KICAg ICAgdG9wb2xvZ2ljYWwgYXBwcm9hY2ggaXMgbGlrZWx5IHRvIGV4cGVyaWVuY2UgbW9yZSBmcmVx dWVudCANCiAgICAgIHRvcG9sb2d5IHJlY29uZmlndXJhdGlvbiB0aGFuIG9uZSBiYXNlZCBvbiBh biBlbmNvZGVkIHN0YXRlIA0KICAgICAgYXBwcm9hY2guICBIb3dldmVyLCBldmVuIGFuIExGQiB0 b3BvbG9neSBiYXNlZCBlbnRpcmVseSBvbiBhbiANCiAgICAgIGVuY29kZWQgc3RhdGUgYXBwcm9h Y2ggbWF5IGhhdmUgdG8gY2hhbmdlIHRoZSB0b3BvbG9neSBhdCB0aW1lcywgDQogICAgICBmb3Ig ZXhhbXBsZSwgdG8gYnlwYXNzIHNvbWUgTEZCcyBvciBpbnNlcnQgbmV3IExGQnMuICBTaW5jZSBh IG1peCANCiAgICAgIG9mIHRoZXNlIHR3byBhcHByb2FjaGVzIGlzIHVzZWQgdG8gbW9kZWwgdGhl IGRhdGFwYXRocywgTEZCIA0KICAgICAgdG9wb2xvZ3kgcmVjb25maWd1cmF0aW9uIGlzIGNvbnNp ZGVyZWQgYW4gaW1wb3J0YW50IGFzcGVjdCBvZiB0aGUgDQogICAgICBGRSBtb2RlbC4gIA0KICAg ICAgIA0KICAgICAgV2Ugd2FudCB0byBwb2ludCBvdXQgdGhhdCBhbGxvd2luZyBhIGNvbmZpZ3Vy YWJsZSBMRkIgdG9wb2xvZ3kgaW4gDQogICAgICB0aGUgRkUgbW9kZWwgZG9lcyBub3QgbWFuZGF0 ZSB0aGF0IGFsbCBGRXMgbXVzdCBoYXZlIHRoaXMgDQogICAgICBjYXBhYmlsaXR5LiAgRXZlbiBp ZiBhbiBGRSBzdXBwb3J0cyBjb25maWd1cmFibGUgTEZCIHRvcG9sb2d5LCB0aGUgDQogICAgICBG RSBtYXkgaW1wb3NlIGxpbWl0YXRpb25zIG9uIHdoYXQgY2FuIGFjdHVhbGx5IGJlIGNvbmZpZ3Vy ZWQuICANCiAgICAgIFBlcmZvcm1hbmNlLW9wdGltaXplZCBoYXJkd2FyZSBpbXBsZW1lbnRhdGlv bnMgbWF5IGhhdmUgemVybyBvciANCiAgICAgIHZlcnkgbGltaXRlZCBjb25maWd1cmFiaWxpdHks IHdoaWxlIEZFIGltcGxlbWVudGF0aW9ucyBydW5uaW5nIG9uIA0KICAgICAgbmV0d29yayBwcm9j ZXNzb3JzIG1heSBwcm92aWRlIG1vcmUgZmxleGliaWxpdHkgYW5kIA0KICAgICAgY29uZmlndXJh YmlsaXR5LiAgSXQgaXMgZW50aXJlbHkgdXAgdG8gdGhlIEZFIGRlc2lnbmVycyB0byBkZWNpZGUg DQogICAgICB3aGV0aGVyIG9yIG5vdCB0aGUgRkUgYWN0dWFsbHkgaW1wbGVtZW50cyByZWNvbmZp Z3VyYXRpb24gYW5kIGlmIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDMzXSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICBzbywgaG93IG11Y2guICBXaGV0aGVyIGEgc2ltcGxlIHJ1bnRpbWUg c3dpdGNoIGlzIHVzZWQgdG8gZW5hYmxlIA0KICAgICAgb3IgZGlzYWJsZSAoaS5lLiwgYnlwYXNz KSBjZXJ0YWluIExGQnMsIG9yIG1vcmUgZmxleGlibGUgc29mdHdhcmUgDQogICAgICByZWNvbmZp Z3VyYXRpb24gaXMgdXNlZCwgaXMgaW1wbGVtZW50YXRpb24gZGV0YWlsIGludGVybmFsIHRvIHRo ZSANCiAgICAgIEZFIGFuZCBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBGRSBtb2RlbC4gIEluIGVp dGhlciBjYXNlLCB0aGUgDQogICAgICBDRShzKSBtdXN0IGJlIGFibGUgdG8gbGVhcm4gdGhlIEZF J3MgY29uZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMuICANCiAgICAgIFRoZXJlZm9yZSwgdGhlIEZF IG1vZGVsIG11c3QgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgZGVzY3JpYmluZyANCiAgICAgIHRo ZSBMRkIgdG9wb2xvZ3kgY29uZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMgb2YgYW4gRkUuICBUaGVz ZSANCiAgICAgIGNhcGFiaWxpdGllcyBtYXkgaW5jbHVkZSAoc2VlIFNlY3Rpb24gNSBmb3IgZnVs bCBkZXRhaWxzKTogDQogICAgICAgIC4gV2hpY2ggTEZCIGNsYXNzZXMgdGhlIEZFIGNhbiBpbnN0 YW50aWF0ZSANCiAgICAgICAgLiBNYXhpbXVtIG51bWJlciBvZiBpbnN0YW5jZXMgb2YgdGhlIHNh bWUgTEZCIGNsYXNzIHRoYXQgY2FuIGJlIA0KICAgICAgICAgICBjcmVhdGVkIA0KICAgICAgICAu IEFueSB0b3BvbG9naWNhbCBsaW1pdGF0aW9ucywgRm9yIGV4YW1wbGU6IA0KICAgICAgICAgICAg IG8gVGhlIG1heGltdW0gbnVtYmVyIG9mIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBjbGFzcyBvciBh bnkgDQogICAgICAgICAgICAgICAgY2xhc3MgdGhhdCBjYW4gYmUgY3JlYXRlZCBvbiBhbnkgZ2l2 ZW4gYnJhbmNoIG9mIHRoZSANCiAgICAgICAgICAgICAgICBncmFwaCANCiAgICAgICAgICAgICBv IE9yZGVyaW5nIHJlc3RyaWN0aW9ucyBvbiBMRkJzIChlLmcuLCBhbnkgaW5zdGFuY2Ugb2YgTEZC IA0KICAgICAgICAgICAgICAgIGNsYXNzIEEgbXVzdCBiZSBhbHdheXMgZG93bnN0cmVhbSBvZiBh bnkgaW5zdGFuY2Ugb2YgTEZCIA0KICAgICAgICAgICAgICAgIGNsYXNzIEIpLiANCiAgICAgICAN CiAgICAgIE5vdGUgdGhhdCBldmVuIHdoZW4gdGhlIENFIGlzIGFsbG93ZWQgdG8gY29uZmlndXJl IExGQiB0b3BvbG9neSANCiAgICAgIGZvciB0aGUgRkUsIHRoZSBDRSBpcyBub3QgZXhwZWN0ZWQg dG8gYmUgYWJsZSB0byBpbnRlcnByZXQgYW4gDQogICAgICBhcmJpdHJhcnkgTEZCIHRvcG9sb2d5 IGFuZCBkZXRlcm1pbmUgd2hpY2ggc3BlY2lmaWMgc2VydmljZSBvciANCiAgICAgIGFwcGxpY2F0 aW9uIChlLmcuIFZQTiwgRGlmZlNlcnYsIGV0Yy4pIGlzIHN1cHBvcnRlZCBieSB0aGUgRkUuICAN CiAgICAgIEhvd2V2ZXIsIG9uY2UgdGhlIENFIHVuZGVyc3RhbmRzIHRoZSBjb2Fyc2UgY2FwYWJp bGl0eSBvZiBhbiBGRSwgDQogICAgICBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIENF IHRvIGNvbmZpZ3VyZSB0aGUgTEZCIHRvcG9sb2d5IA0KICAgICAgdG8gaW1wbGVtZW50IHRoZSBu ZXR3b3JrIHNlcnZpY2UgdGhlIE5FIGlzIHN1cHBvc2VkIHRvIHByb3ZpZGUuICANCiAgICAgIFRo dXMsIHRoZSBtYXBwaW5nIHRoZSBDRSBoYXMgdG8gdW5kZXJzdGFuZCBpcyBmcm9tIHRoZSBoaWdo IGxldmVsIA0KICAgICAgTkUgc2VydmljZSB0byBhIHNwZWNpZmljIExGQiB0b3BvbG9neSwgbm90 IHRoZSBvdGhlciB3YXkgYXJvdW5kLiANCiAgICAgIFRoZSBDRSBpcyBub3QgZXhwZWN0ZWQgdG8g aGF2ZSB0aGUgdWx0aW1hdGUgaW50ZWxsaWdlbmNlIHRvIA0KICAgICAgdHJhbnNsYXRlIGFueSBo aWdoIGxldmVsIHNlcnZpY2UgcG9saWN5IGludG8gdGhlIGNvbmZpZ3VyYXRpb24gDQogICAgICBk YXRhIGZvciB0aGUgRkVzLiAgSG93ZXZlciwgaXQgaXMgY29uY2VpdmFibGUgdGhhdCB3aXRoaW4g YSBnaXZlbiANCiAgICAgIG5ldHdvcmsgc2VydmljZSBkb21haW4sIGEgY2VydGFpbiBhbW91bnQg b2YgaW50ZWxsaWdlbmNlIGNhbiBiZSANCiAgICAgIHByb2dyYW1tZWQgaW50byB0aGUgQ0UgdG8g Z2l2ZSB0aGUgQ0UgYSBnZW5lcmFsIHVuZGVyc3RhbmRpbmcgb2YgDQogICAgICB0aGUgTEZCcyBp bnZvbHZlZCB0byBhbGxvdyB0aGUgdHJhbnNsYXRpb24gZnJvbSBhIGhpZ2ggbGV2ZWwgDQogICAg ICBzZXJ2aWNlIHBvbGljeSB0byB0aGUgbG93IGxldmVsIEZFIGNvbmZpZ3VyYXRpb24gdG8gYmUg ZG9uZSANCiAgICAgIGF1dG9tYXRpY2FsbHkuICBOb3RlIHRoYXQgdGhpcyBpcyBjb25zaWRlcmVk IGFuIGltcGxlbWVudGF0aW9uIA0KICAgICAgaXNzdWUgaW50ZXJuYWwgdG8gdGhlIGNvbnRyb2wg cGxhbmUgYW5kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSANCiAgICAgIEZFIG1vZGVsLiBUaGVy ZWZvcmUsIGl0IGlzIG5vdCBkaXNjdXNzZWQgYW55IGZ1cnRoZXIgaW4gdGhpcyANCiAgICAgIGRy YWZ0LiAgDQogICAgDQoNCg0KDQoNCg0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4 cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzNF0gDQoMICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICstLS0tLS0t LS0tLSsgICAgICAgDQogICAgICAtLS0tPnwgSW5ncmVzcyAgfC0tLS0+fGNsYXNzaWZpZXIgfC0t LS0tLS0tLS0tLS0tKyAgDQogICAgICAgICAgIHwgICAgICAgICAgfCAgICAgfGNoaXAgICAgICAg fCAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgICArLS0tLS0tLS0t LS0rICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHYgDQogICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgKy0t LS0tLS0tKyAgICB8ICAgTmV0d29yayBQcm9jZXNzb3IgICAgICAgICAgICAgICAgICAgICAgIHwg DQogICAgICAgIDwtLS0tfCBFZ3Jlc3MgfCAgICB8ICAgKy0tLS0tLSsgICAgKy0tLS0tLSsgICAr LS0tLS0tLSsgICAgICAgIHwgDQogICAgICAgICAgICAgKy0tLS0tLS0tKyAgICB8ICAgfE1ldGVy IHwgICAgfE1hcmtlcnwgICB8RHJvcHBlcnwgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAg XiAgICAgICB8ICAgKy0tLS0tLSsgICAgKy0tLS0tLSsgICArLS0tLS0tLSsgICAgICAgIHwgDQog ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgDQogICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0rICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAg ICAgIHwgICAgKy0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLSsgICArLS0tLS0tKyAgICArLS0t LS0tLS0tKyAgIHwgDQogICAgICAgIHwgICAgfEZvcndhcmRlcnw8LS0tLS0tfFNjaGVkdWxlcnw8 LS18UXVldWUgfCAgICB8Q291bnRlciAgfCAgIHwgDQogICAgICAgIHwgICAgKy0tLS0tLS0tLSsg ICAgICAgKy0tLS0tLS0tLSsgICArLS0tLS0tKyAgICArLS0tLS0tLS0tKyAgIHwgDQogICAgICAg IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgKGEpICBUaGUgQ2FwYWJpbGl0eSBvZiB0aGUgRkUsIHJlcG9ydGVkIHRvIHRoZSBDRSANCiAg ICANCiAgICAgICAgICAgICArLS0tLS0rICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICArLS0tKyAgDQogICAgICAgICAgICAgfCAgICBBfC0tLT58UXVldWUxIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0+fCAgIHwgICANCiAgICAgIC0tLS0tLT58ICAgICB8ICAgICstLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICB8ICAgfCAgKy0tLSsgDQogICAgICAgICAgICAgfCAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgIHwgICB8IA0KICAgICAgICAgICAg IHwgICAgIHwgICAgKy0tLS0tLS0rICAgICAgKy0tLS0tLS0rICAgICAgIHwgICB8ICB8ICAgfCAN CiAgICAgICAgICAgICB8ICAgIEJ8LS0tPnxNZXRlcjEgfC0tLS0tPnxRdWV1ZTIgfC0tLS0tLT58 ICAgfC0+fCAgIHwgDQogICAgICAgICAgICAgfCAgICAgfCAgICB8ICAgICAgIHwgICAgICArLS0t LS0tLSsgICAgICAgfCAgIHwgIHwgICB8IA0KICAgICAgICAgICAgIHwgICAgIHwgICAgfCAgICAg ICB8LS0rICAgICAgICAgICAgICAgICAgIHwgICB8ICB8ICAgfCANCiAgICAgICAgICAgICArLS0t LS0rICAgICstLS0tLS0tKyAgfCAgICstLS0tLS0tKyAgICAgICB8ICAgfCAgKy0tLSsgDQogICAg ICAgICAgIGNsYXNzaWZpZXIgICAgICAgICAgICAgICstLT58RHJvcHBlcnwgICAgICAgfCAgIHwg IElQdjQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsg ICAgICAgKy0tLSsgIEZ3ZC4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU2NoZWR1bGVyIA0KICAgIA0KICAgICAgICAgICAgICAgICAgIChiKSAg T25lIExGQiB0b3BvbG9neSBhcyBjb25maWd1cmVkIGJ5IHRoZSBDRSBhbmQgDQogICAgICAgICAg ICAgICAgICAgICAgICBhY2NlcHRlZCBieSB0aGUgRkUgICAgICAgICAgICAgICANCiAgICAgDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDM1XSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUXVldWUxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgICAgICAg ICAgICAgICAgICArLS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAgIHwgIEF8LS0tLS0tLS0t LS0tLS0tLS0tLT58ICB8LS0rIA0KICAgICAgICAgICAgICAgICAgICAgICstPnwgICB8ICAgICAg ICAgICAgICAgICAgICB8ICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwgIHwgIEJ8LS0r ICArLS0rICAgKy0tKyAgICArLS0rICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwgICstLS0r ICB8ICB8ICB8ICAgfCAgfCAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwgTWV0 ZXIxICArLT58ICB8LS0+fCAgfCAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICB8ICB8ICAgfCAgfCAgICAgICAgICB8ICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgKy0tKyAgICstLSsgICAgICAgICAgfCAgICAgICAgICBJcHY0 IA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBDb3VudGVyMSBEcm9wcGVyMSBRdWV1 ZTJ8ICAgICstLSsgIEZ3ZC4gDQogICAgICAgICAgICAgICstLS0rICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLSsgICstLS0+fEEgfCAgKy0rIA0KICAgICAgICAgICAgICB8ICBBfC0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8LS0tLS0tPnxCIHwgIHwgfCANCiAgICAg ICAtLS0tLS0+fCAgQnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgfCAgKy0tLT58 QyB8LT58IHwtPiANCiAgICAgICAgICAgICAgfCAgQ3wtLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tKyAgfCArLT58RCB8ICB8IHwgDQogICAgICAgICAgICAgIHwgIER8LSsgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgKy0tKyAgKy0rIA0KICAgICAgICAgICAg ICArLS0tKyB8IHwgICAgKy0tLSsgICAgICAgICAgICAgICAgICBRdWV1ZTN8IHwgU2NoZWR1bGVy IA0KICAgICAgICAgIENsYXNzaWZpZXIxIHwgfCAgfCAgQXwtLS0tLS0tLS0tLS0+ICAgICAgICst LSsgIHwgfCANCiAgICAgICAgICAgICAgICAgICAgICB8ICstPnwgICB8ICAgICAgICAgICAgICAg ICAgICB8ICB8LS0rIHwgDQogICAgICAgICAgICAgICAgICAgICAgfCAgICB8ICBCfC0tKyAgKy0t KyArLS0tLS0tLS0+fCAgfCAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgKy0tLSsg IHwgIHwgIHwgfCAgICAgICAgICstLSsgICAgfCANCiAgICAgICAgICAgICAgICAgICAgICB8ICBN ZXRlcjIgICArLT58ICB8LSsgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICstLSsgICAgICAgICAgIFF1ZXVlNCAgfCANCiAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgTWFya2VyMSAgICAgICAgICArLS0rICAgIHwg DQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAg fC0tLS0rICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLSsgDQogICAgICAgICAgICAgICAgICAgKGMpICBBbm90aGVyIExGQiB0b3BvbG9n eSBhcyBjb25maWd1cmVkIGJ5IHRoZSBDRSBhbmQgDQogICAgICAgICAgICAgICAgICAgICAgICBh Y2NlcHRlZCBieSB0aGUgRkUgDQogICAgICAgDQogICAgICAgICAgIEZpZ3VyZSA3LiBBbiBleGFt cGxlIG9mIGNvbmZpZ3VyaW5nIExGQiB0b3BvbG9neS4gDQogICAgICAgDQogICAgICBGaWd1cmUg NyBzaG93cyBhbiBleGFtcGxlIHdoZXJlIGEgUW9TLWVuYWJsZWQgcm91dGVyIGhhcyBzZXZlcmFs IA0KICAgICAgbGluZSBjYXJkcyB0aGF0IGhhdmUgYSBmZXcgaW5ncmVzcyBwb3J0cyBhbmQgZWdy ZXNzIHBvcnRzLCBhIA0KICAgICAgc3BlY2lhbGl6ZWQgY2xhc3NpZmljYXRpb24gY2hpcCwgYSBu ZXR3b3JrIHByb2Nlc3NvciBjb250YWluaW5nIA0KICAgICAgY29kZXMgZm9yIEZFIGJsb2NrcyBs aWtlIG1ldGVyLCBtYXJrZXIsIGRyb3BwZXIsIGNvdW50ZXIsIHF1ZXVlLCANCiAgICAgIHNjaGVk dWxlciBhbmQgSXB2NCBmb3J3YXJkZXIuICBTb21lIG9mIHRoZSBMRkIgdG9wb2xvZ3kgaXMgYWxy ZWFkeSANCiAgICAgIGZpeGVkIGFuZCBoYXMgdG8gcmVtYWluIHN0YXRpYyBkdWUgdG8gdGhlIHBo eXNpY2FsIGxheW91dCBvZiB0aGUgDQogICAgICBsaW5lIGNhcmRzLiAgRm9yIGV4YW1wbGUsIGFs bCBvZiB0aGUgaW5ncmVzcyBwb3J0cyBtaWdodCBiZSBoYXJkLQ0KICAgICAgd2lyZWQgaW50byB0 aGUgY2xhc3NpZmljYXRpb24gY2hpcCBzbyBhbGwgcGFja2V0cyBtdXN0IGZsb3cgZnJvbSANCiAg ICAgIHRoZSBpbmdyZXNzIHBvcnQgaW50byB0aGUgY2xhc3NpZmljYXRpb24gZW5naW5lLiAgT24g dGhlIG90aGVyIA0KICAgICAgaGFuZCwgdGhlIExGQnMgb24gdGhlIG5ldHdvcmsgcHJvY2Vzc29y IGFuZCB0aGVpciBleGVjdXRpb24gb3JkZXIgDQogICAgICBhcmUgcHJvZ3JhbW1hYmxlLiBIb3dl dmVyLCBjZXJ0YWluIGNhcGFjaXR5IGxpbWl0cyBhbmQgbGlua2FnZSANCiAgICAgIGNvbnN0cmFp bnRzIGNvdWxkIGV4aXN0IGJldHdlZW4gdGhlc2UgTEZCcy4gRXhhbXBsZXMgb2YgdGhlIA0KICAg ICAgY2FwYWNpdHkgbGltaXRzIG1pZ2h0IGJlOiA4IG1ldGVyczsgMTYgcXVldWVzIGluIG9uZSBG RTsgdGhlIA0KICAgICAgc2NoZWR1bGVyIGNhbiBoYW5kbGUgYXQgbW9zdCB1cCB0byAxNiBxdWV1 ZXM7IGV0Yy4gIFRoZSBsaW5rYWdlIA0KICAgICAgY29uc3RyYWludHMgbWlnaHQgZGljdGF0ZSB0 aGF0IHRoZSBjbGFzc2lmaWNhdGlvbiBlbmdpbmUgbWF5IGJlIA0KICAgIA0KICAgWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDM2XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAg ICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBmb2xsb3dlZCBieSBhIG1ldGVy LCBtYXJrZXIsIGRyb3BwZXIsIGNvdW50ZXIsIHF1ZXVlIG9yIElQdjQgDQogICAgICBmb3J3YXJk ZXIsIGJ1dCBub3QgYSBzY2hlZHVsZXI7IHF1ZXVlcyBjYW4gb25seSBiZSBmb2xsb3dlZCBieSBh IA0KICAgICAgc2NoZWR1bGVyOyBhIHNjaGVkdWxlciBtdXN0IGJlIGZvbGxvd2VkIGJ5IHRoZSBJ UHY0IGZvcndhcmRlcjsgdGhlIA0KICAgICAgbGFzdCBMRkIgaW4gdGhlIGRhdGFwYXRoIGJlZm9y ZSBnb2luZyBpbnRvIHRoZSBlZ3Jlc3MgcG9ydHMgbXVzdCANCiAgICAgIGJlIHRoZSBJUHY0IGZv cndhcmRlciwgZXRjLiAgDQogICAgDQogICAgICBPbmNlIHRoZSBGRSByZXBvcnRzIHRoZXNlIGNh cGFiaWxpdGllcyBhbmQgY2FwYWNpdHkgbGltaXRzIHRvIHRoZSANCiAgICAgIENFLCBpdCBpcyBu b3cgdXAgdG8gdGhlIENFIHRvIHRyYW5zbGF0ZSB0aGUgUW9TIHBvbGljeSBpbnRvIGEgDQogICAg ICBkZXNpcmFibGUgY29uZmlndXJhdGlvbiBmb3IgdGhlIEZFLiAgRmlndXJlIDcoYSkgZGVwaWN0 cyB0aGUgRkUgDQogICAgICBjYXBhYmlsaXR5IHdoaWxlIDcoYikgYW5kIDcoYykgZGVwaWN0IHR3 byBkaWZmZXJlbnQgdG9wb2xvZ2llcyANCiAgICAgIHRoYXQgdGhlIENFIG1heSByZXF1ZXN0IHRo ZSBGRSB0byBjb25maWd1cmUuICBOb3RlIHRoYXQgYm90aCB0aGUgDQogICAgICBpbmdyZXNzIGFu ZCBlZ3Jlc3MgYXJlIG9taXR0ZWQgaW4gKGIpIGFuZCAoYykgdG8gc2ltcGxpZnkgdGhlIA0KICAg ICAgcmVwcmVzZW50YXRpb24uICBUaGUgdG9wb2xvZ3kgaW4gNyhjKSBpcyBjb25zaWRlcmFibHkg bW9yZSBjb21wbGV4IA0KICAgICAgdGhhbiA3KGIpIGJ1dCBib3RoIGFyZSBmZWFzaWJsZSB3aXRo aW4gdGhlIEZFIGNhcGFiaWxpdGllcywgYW5kIHNvIA0KICAgICAgdGhlIEZFIHNob3VsZCBhY2Nl cHQgZWl0aGVyIGNvbmZpZ3VyYXRpb24gcmVxdWVzdCBmcm9tIHRoZSBDRS4gICANCiAgICANCiAg IDQuIA0gICAgIE1vZGVsIGFuZCBTY2hlbWEgZm9yIExGQiBDbGFzc2VzIA0KICAgICAgIA0KICAg ICAgVGhlIG1haW4gZ29hbCBvZiB0aGUgRkUgbW9kZWwgaXMgdG8gcHJvdmlkZSBhbiBhYnN0cmFj dCwgZ2VuZXJpYywgDQogICAgICBtb2R1bGFyLCBpbXBsZW1lbnRhdGlvbi1pbmRlcGVuZGVudCBy ZXByZXNlbnRhdGlvbiBvZiB0aGUgRkVzLiAgDQogICAgICBUaGlzIGlzIGZhY2lsaXRhdGVkIHVz aW5nIHRoZSBjb25jZXB0IG9mIExGQnMsIHdoaWNoIGFyZSANCiAgICAgIGluc3RhbnRpYXRlZCBm cm9tIExGQiBjbGFzc2VzLiAgTEZCIGNsYXNzZXMgYW5kIGFzc29jaWF0ZWQgDQogICAgICBkZWZp bml0aW9ucyB3aWxsIGJlIHByb3ZpZGVkIGluIGEgY29sbGVjdGlvbiBvZiBYTUwgZG9jdW1lbnRz LiBUaGUgDQogICAgICBjb2xsZWN0aW9uIG9mIHRoZXNlIFhNTCBkb2N1bWVudHMgaXMgY2FsbGVk IGEgTEZCIGNsYXNzIGxpYnJhcnksIA0KICAgICAgYW5kIGVhY2ggZG9jdW1lbnQgaXMgY2FsbGVk IGFuIExGQiBjbGFzcyBsaWJyYXJ5IGRvY3VtZW50IChvciANCiAgICAgIGxpYnJhcnkgZG9jdW1l bnQsIGZvciBzaG9ydCkuICBFYWNoIG9mIHRoZSBsaWJyYXJ5IGRvY3VtZW50cyB3aWxsIA0KICAg ICAgY29uZm9ybSB0byB0aGUgc2NoZW1hIHByZXNlbnRlZCBpbiB0aGlzIHNlY3Rpb24uICBUaGUg cm9vdCBlbGVtZW50IA0KICAgICAgb2YgdGhlIGxpYnJhcnkgZG9jdW1lbnQgaXMgdGhlIDxMRkJM aWJyYXJ5PiBlbGVtZW50LiANCiAgICAgICANCiAgICAgIEl0IGlzIG5vdCBleHBlY3RlZCB0aGF0 IGxpYnJhcnkgZG9jdW1lbnRzIHdpbGwgYmUgZXhjaGFuZ2VkIA0KICAgICAgYmV0d2VlbiBGRXMg YW5kIENFcyAib3Zlci10aGUtd2lyZSIuICBCdXQgdGhlIG1vZGVsIHdpbGwgc2VydmUgYXMgDQog ICAgICBhbiBpbXBvcnRhbnQgcmVmZXJlbmNlIGZvciB0aGUgZGVzaWduIGFuZCBkZXZlbG9wbWVu dCBvZiB0aGUgQ0VzIA0KICAgICAgKHNvZnR3YXJlKSBhbmQgRkVzIChtb3N0bHkgdGhlIHNvZnR3 YXJlIHBhcnQpLiAgSXQgd2lsbCBhbHNvIHNlcnZlIA0KICAgICAgYXMgYSBkZXNpZ24gaW5wdXQg d2hlbiBzcGVjaWZ5aW5nIHRoZSBGb3JDRVMgcHJvdG9jb2wgZWxlbWVudHMgZm9yIA0KICAgICAg Q0UtRkUgY29tbXVuaWNhdGlvbi4gDQogICAgICAgDQogICA0LjEuIE5hbWVzcGFjZSANCiAgICAg ICANCiAgICAgIFRoZSBMRkJMaWJyYXJ5IGVsZW1lbnQgYW5kIGFsbCBvZiBpdHMgc3ViLWVsZW1l bnRzIGFyZSBkZWZpbmVkIGluIA0KICAgICAgdGhlIGZvbGxvd2luZyBuYW1lc3BhY2U6IA0KICAg ICAgIA0KICAgICAgICAgaHR0cDovL2lldGYub3JnL2ZvcmNlcy8xLjAvbGZibW9kZWwgDQogICAg ICAgDQogICA0LjIuIDxMRkJMaWJyYXJ5PiBFbGVtZW50IA0KICAgICAgIA0KICAgICAgVGhlIDxM RkJMaWJyYXJ5PiBlbGVtZW50IHNlcnZlcyBhcyBhIHJvb3QgZWxlbWVudCBvZiBhbGwgbGlicmFy eSANCiAgICAgIGRvY3VtZW50cy4gSXQgY29udGFpbnMgb25lIG9yIG1vcmUgb2YgdGhlIGZvbGxv d2luZyBtYWluIGJsb2NrczogDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1 Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMzddIA0KDCAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSAN CiAgICANCiAgICANCiAgICAgICANCiAgICAgICAgLiA8ZnJhbWVUeXBlRGVmcz4gZm9yIHRoZSBm cmFtZSBkZWNsYXJhdGlvbnM7IA0KICAgICAgICAuIDxkYXRhVHlwZURlZnM+IGZvciBkZWZpbmlu ZyBjb21tb24gZGF0YSB0eXBlczsgDQogICAgICAgIC4gPG1ldGFkYXRhRGVmcz4gZm9yIGRlZmlu aW5nIG1ldGFkYXRhLCBhbmQgDQogICAgICAgIC4gPExGQkNsYXNzRGVmcz4gZm9yIGRlZmluaW5n IExGQiBjbGFzc2VzLiANCiAgICAgICANCiAgICAgIEVhY2ggYmxvY2sgaXMgb3B0aW9uYWwsIHRo YXQgaXMsIG9uZSBsaWJyYXJ5IG1heSBjb250YWluIG9ubHkgDQogICAgICBtZXRhZGF0YSBkZWZp bml0aW9ucywgYW5vdGhlciBtYXkgY29udGFpbiBvbmx5IExGQiBjbGFzcyANCiAgICAgIGRlZmlu aXRpb25zLCB5ZXQgYW5vdGhlciBtYXkgY29udGFpbiBhbGwgb2YgdGhlIGFib3ZlLiANCiAgICAg ICANCiAgICAgIEluIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBtYWluIGJsb2NrcywgYSBsaWJyYXJ5 IGRvY3VtZW50IGNhbiANCiAgICAgIGltcG9ydCBvdGhlciBsaWJyYXJ5IGRvY3VtZW50cyBpZiBp dCBuZWVkcyB0byByZWZlciB0byBkZWZpbml0aW9ucyANCiAgICAgIGNvbnRhaW5lZCBpbiB0aGUg aW5jbHVkZWQgZG9jdW1lbnQuICBUaGlzIGNvbmNlcHQgaXMgc2ltaWxhciB0byANCiAgICAgIHRo ZSAiI2luY2x1ZGUiIGRpcmVjdGl2ZSBpbiBDLiAgSW1wb3J0aW5nIGlzIGV4cHJlc3NlZCBieSB0 aGUgDQogICAgICA8bG9hZD4gZWxlbWVudHMsIHdoaWNoIG11c3QgcHJlY2VkZSBhbGwgdGhlIGFi b3ZlIGVsZW1lbnRzIGluIHRoZSANCiAgICAgIGRvY3VtZW50LiAgRm9yIHVuaXF1ZSByZWZlcmVu Y2luZywgZWFjaCBMRkJMaWJyYXJ5IGluc3RhbmNlIA0KICAgICAgZG9jdW1lbnQgaGFzIGEgdW5p cXVlIGxhYmVsIGRlZmluZWQgaW4gdGhlICJwcm92aWRlIiBhdHRyaWJ1dGUgb2YgDQogICAgICB0 aGUgTEZCTGlicmFyeSBlbGVtZW50LiANCiAgICAgICANCiAgICAgIFRoZSA8TEZCTGlicmFyeT4g ZWxlbWVudCBhbHNvIGluY2x1ZGVzIGFuIG9wdGlvbmFsIDxkZXNjcmlwdGlvbj4gDQogICAgICBl bGVtZW50LCB3aGljaCBjYW4gYmUgdXNlZCB0byBwcm92aWRlIHRleHR1YWwgZGVzY3JpcHRpb24g YWJvdXQgDQogICAgICB0aGUgbGlicmFyeS4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93aW5n IGlzIGEgc2tlbGV0b24gb2YgYSBsaWJyYXJ5IGRvY3VtZW50OiANCiAgICAgICANCiAgICAgIDw/ eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+IA0KICAgICAgPExGQkxpYnJhcnkg eG1sbnM9Imh0dHA6Ly9pZXRmLm9yZy9mb3JjZXMvMS4wL2xmYm1vZGVsIiANCiAgICAgICAgcHJv dmlkZXM9InRoaXNfbGlicmFyeSI+IA0KICAgICAgICAgDQogICAgICAgIDxkZXNjcmlwdGlvbj4g DQogICAgICAgICAgLi4uIA0KICAgICAgICA8L2Rlc2NyaXB0aW9uPiANCiAgICAgICANCiAgICAg ICAgPCEtLSBMb2FkaW5nIGV4dGVybmFsIGxpYnJhcmllcyAob3B0aW9uYWwpIC0tPiANCiAgICAg ICAgPGxvYWQgbGlicmFyeT0iYW5vdGhlcl9saWJyYXJ5Ii8+IA0KICAgICAgICAuLi4gDQogICAg ICAgDQogICAgICAgIDwhLS0gRlJBTUUgVFlQRSBERUZJTklUSU9OUyAob3B0aW9uYWwpIC0tPiAN CiAgICAgICAgPGZyYW1lVHlwZURlZnM+IA0KICAgICAgICAgIC4uLiANCiAgICAgICAgPC9mcmFt ZVR5cGVEZWZzPiANCiAgICAgICANCiAgICAgICAgPCEtLSBEQVRBIFRZUEUgREVGSU5JVElPTlMg KG9wdGlvbmFsKSAtLT4gDQogICAgICAgIDxkYXRhVHlwZURlZnM+IA0KICAgIA0KICAgWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDM4XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgLi4uIA0KICAgICAg ICA8L2RhdGFUeXBlRGVmcz4gDQogICAgICAgDQogICAgICAgIDwhLS0gTUVUQURBVEEgREVGSU5J VElPTlMgKG9wdGlvbmFsKSAtLT4gDQogICAgICAgIDxtZXRhZGF0YURlZnM+IA0KICAgICAgICAg IC4uLiANCiAgICAgICAgPC9tZXRhZGF0YURlZnM+IA0KICAgICAgIA0KICAgICAgICA8IZdMRkIg Q0xBU1MgREVGSU5JVElPTlMgKG9wdGlvbmFsKSAtLT4gDQogICAgICAgIDxMRkJDTGFzc0RlZnM+ IA0KICAgICAgICAgIC4uLiANCiAgICAgICAgPC9MRkJDTGFzc0RlZnM+IA0KICAgICAgPC9MRkJM aWJyYXJ5PiANCiAgICAgICANCiAgICAgICANCiAgIDQuMy4gPGxvYWQ+IEVsZW1lbnQgDQogICAg ICAgDQogICAgICBUaGlzIGVsZW1lbnQgaXMgdXNlZCB0byByZWZlciB0byBhbm90aGVyIExGQiBs aWJyYXJ5IGRvY3VtZW50LiAgIA0KICAgICAgU2ltaWxhciB0byB0aGUgIiNpbmNsdWRlIiBkaXJl Y3RpdmUgaW4gQywgdGhpcyBtYWtlcyB0aGUgb2JqZWN0cyANCiAgICAgIChtZXRhZGF0YSB0eXBl cywgZGF0YSB0eXBlcywgZXRjLikgZGVmaW5lZCBpbiB0aGUgcmVmZXJyZWQgbGlicmFyeSANCiAg ICAgIGF2YWlsYWJsZSBmb3IgcmVmZXJlbmNpbmcgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQuIA0K ICAgICAgIA0KICAgICAgVGhlIGxvYWQgZWxlbWVudCBtdXN0IGNvbnRhaW4gdGhlIGxhYmVsIG9m IHRoZSBsaWJyYXJ5IHRvIGJlIA0KICAgICAgaW5jbHVkZWQgYW5kIG1heSBjb250YWluIGEgVVJM IHRvIHNwZWNpZnkgd2hlcmUgdGhlIGxpYnJhcnkgY2FuIGJlIA0KICAgICAgcmV0cmlldmVkLiAg VGhlIGxvYWQgZWxlbWVudCBjYW4gYmUgcmVwZWF0ZWQgdW5saW1pdGVkIHRpbWVzLiAgDQogICAg ICBUaHJlZSBleGFtcGxlcyBmb3IgdGhlIDxsb2FkPiBlbGVtZW50czogDQogICAgICAgDQogICAg ICA8bG9hZCBsaWJyYXJ5PSJhX2xpYnJhcnkiLz4gDQogICAgICA8bG9hZCBsaWJyYXJ5PSJhbm90 aGVyX2xpYnJhcnkiIGxvY2F0aW9uPSJhbm90aGVyX2xpYi54bWwiLz4gDQogICAgICA8bG9hZCBs aWJyYXJ5PSJ5ZXRhbm90aGVyX2xpYnJhcnkiIA0KICAgICAgICANCiAgICAgIGxvY2F0aW9uPSJo dHRwOi8vd3d3LnBldHJpbWVhdC5jb20vZm9yY2VzLzEuMC9sZmJtb2RlbC9scG0ueG1sIi8+IA0K ICAgICAgIA0KICAgICAgIA0KICAgNC40LiA8ZnJhbWVEZWZzPiBFbGVtZW50IGZvciBGcmFtZSBU eXBlIERlY2xhcmF0aW9ucyANCiAgICAgICANCiAgICAgIEZyYW1lIG5hbWVzIGFyZSB1c2VkIGlu IHRoZSBMRkIgZGVmaW5pdGlvbiB0byBkZWZpbmUgdGhlIHR5cGVzIG9mIA0KICAgICAgZnJhbWVz IHRoZSBMRkIgZXhwZWN0cyBhdCBpdHMgaW5wdXQgcG9ydChzKSBhbmQgZW1pdHMgYXQgaXRzIA0K ICAgICAgb3V0cHV0IHBvcnQocykuICBUaGUgPGZyYW1lRGVmcz4gb3B0aW9uYWwgZWxlbWVudCBp biB0aGUgbGlicmFyeSANCiAgICAgIGRvY3VtZW50IGNvbnRhaW5zIG9uZSBvciBtb3JlIDxmcmFt ZURlZj4gZWxlbWVudHMsIGVhY2ggZGVjbGFyaW5nIA0KICAgICAgb25lIGZyYW1lIHR5cGUuIA0K ICAgICAgIA0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIw MDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzOV0gDQoMICAgSW50ZXJuZXQgRHJhZnQg ICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0K ICAgIA0KICAgICAgRWFjaCBmcmFtZSBkZWZpbml0aW9uIGNvbnRhaW5zIGEgdW5pcXVlIG5hbWUg KE5NVE9LRU4pIGFuZCBhIGJyaWVmIA0KICAgICAgc3lub3BzaXMuICBJbiBhZGRpdGlvbiwgYW4g b3B0aW9uYWwgZGV0YWlsZWQgZGVzY3JpcHRpb24gbWF5IGJlIA0KICAgICAgcHJvdmlkZWQuIA0K ICAgICAgIA0KICAgICAgVW5pcXVlbmVzcyBvZiBmcmFtZSB0eXBlcyBtdXN0IGJlIGVuc3VyZWQg YW1vbmcgZnJhbWUgdHlwZXMgDQogICAgICBkZWZpbmVkIGluIHRoZSBzYW1lIGxpYnJhcnkgZG9j dW1lbnQgYW5kIGluIGFsbCBkaXJlY3RseSBvciANCiAgICAgIGluZGlyZWN0bHkgaW5jbHVkZWQg bGlicmFyeSBkb2N1bWVudHMuICANCiAgICAgICAgDQogICAgICBUaGUgZm9sbG93aW5nIGV4YW1w bGUgZGVmaW5lcyB0d28gZnJhbWUgdHlwZXM6IA0KICAgICAgIA0KICAgICAgPGZyYW1lRGVmcz4g DQogICAgICAgIDxmcmFtZURlZj4gDQogICAgICAgICAgPG5hbWU+aXB2NDwvbmFtZT4gDQogICAg ICAgICAgPHN5bm9wc2lzPklQdjQgcGFja2V0PC9zeW5vcHNpcz4gDQogICAgICAgICAgPGRlc2Ny aXB0aW9uPiANCiAgICAgICAgICAgIFRoaXMgZnJhbWUgdHlwZSByZWZlcnMgdG8gYW4gSVB2NCBw YWNrZXQuIA0KICAgICAgICAgIDwvZGVzY3JpcHRpb24+IA0KICAgICAgICA8L2ZyYW1lRGVmPiAN CiAgICAgICAgICA8ZnJhbWVEZWY+IA0KICAgICAgICAgIDxuYW1lPmlwdjY8L25hbWU+IA0KICAg ICAgICAgIDxzeW5vcHNpcz5JUHY2IHBhY2tldDwvc3lub3BzaXM+IA0KICAgICAgICAgIDxkZXNj cmlwdGlvbj4gDQogICAgICAgICAgICBUaGlzIGZyYW1lIHR5cGUgcmVmZXJzIHRvIGFuIElQdjYg cGFja2V0LiANCiAgICAgICAgICA8L2Rlc2NyaXB0aW9uPiANCiAgICAgICAgPC9mcmFtZURlZj4g DQogICAgICAgIC4uLiANCiAgICAgIDwvZnJhbWVEZWZzPiANCiAgICAgICAgDQogICA0LjUuIDxk YXRhVHlwZURlZnM+IEVsZW1lbnQgZm9yIERhdGEgVHlwZSBEZWZpbml0aW9ucyAgDQogICAgICAg DQogICAgICBUaGUgKG9wdGlvbmFsKSA8ZGF0YVR5cGVEZWZzPiBlbGVtZW50IGNhbiBiZSB1c2Vk IHRvIGRlZmluZSANCiAgICAgIGNvbW1vbmx5IHVzZWQgZGF0YSB0eXBlcy4gSXQgY29udGFpbnMg b25lIG9yIG1vcmUgPGRhdGFUeXBlRGVmPiANCiAgICAgIGVsZW1lbnRzLCBlYWNoIGRlZmluaW5n IGEgZGF0YSB0eXBlIHdpdGggYSB1bmlxdWUgbmFtZS4gU3VjaCBkYXRhIA0KICAgICAgdHlwZXMg Y2FuIGJlIHVzZWQgaW4gc2V2ZXJhbCBwbGFjZXMgaW4gdGhlIGxpYnJhcnkgZG9jdW1lbnRzLCAN CiAgICAgIGluY2x1ZGluZzogDQogICAgICAgDQogICAgICAgICAuICBEZWZpbmluZyBvdGhlciBk YXRhIHR5cGVzIA0KICAgICAgICAgLiAgRGVmaW5pbmcgbWV0YWRhdGEgDQogICAgICAgICAuICBE ZWZpbmluZyBhdHRyaWJ1dGVzIG9mIExGQiBjbGFzc2VzIA0KICAgICAgIA0KICAgICAgVGhpcyBp cyBzaW1pbGFyIHRvIHRoZSBjb25jZXB0IG9mIGhhdmluZyBhIGNvbW1vbiBoZWFkZXIgZmlsZSBm b3IgDQogICAgICBzaGFyZWQgZGF0YSB0eXBlcy4gDQogICAgICAgDQoNCiAgICANCiAgIFlhbmcs IGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSA0MF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgRWFjaCA8ZGF0YVR5cGVE ZWY+IGVsZW1lbnQgY29udGFpbnMgYSB1bmlxdWUgbmFtZSAoTk1UT0tFTiksIGEgDQogICAgICBi cmllZiBzeW5vcHNpcywgYW4gb3B0aW9uYWwgbG9uZ2VyIGRlc2NyaXB0aW9uLCBhbmQgYSB0eXBl IA0KICAgICAgZGVmaW5pdGlvbiBlbGVtZW50LiAgVGhlIG5hbWUgbXVzdCBiZSB1bmlxdWUgYW1v bmcgYWxsIGRhdGEgdHlwZXMgDQogICAgICBkZWZpbmVkIGluIHRoZSBzYW1lIGxpYnJhcnkgZG9j dW1lbnQgYW5kIGluIGFueSBkaXJlY3RseSBvciANCiAgICAgIGluZGlyZWN0bHkgaW5jbHVkZWQg bGlicmFyeSBkb2N1bWVudHMuIEZvciBleGFtcGxlOiANCiAgICAgICANCiAgICAgIDxkYXRhVHlw ZURlZnM+IA0KICAgICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICAgIDxuYW1lPmllZWVtYWNh ZGRyPC9uYW1lPiANCiAgICAgICAgICA8c3lub3BzaXM+NDgtYml0IElFRUUgTUFDIGFkZHJlc3M8 L3N5bm9wc2lzPiANCiAgICAgICAgICAuLi4gdHlwZSBkZWZpbml0aW9uIC4uLiANCiAgICAgICAg PC9kYXRhVHlwZURlZj4gDQogICAgICAgIDxkYXRhVHlwZURlZj4gDQogICAgICAgICAgPG5hbWU+ aXB2NGFkZHI8L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNpcz5JUHY0IGFkZHJlc3M8L3N5bm9w c2lzPiANCiAgICAgICAgICAuLi4gdHlwZSBkZWZpbml0aW9uIC4uLiANCiAgICAgICAgPC9kYXRh VHlwZURlZj4gDQogICAgICAgIC4uLiANCiAgICAgIDwvZGF0YVR5cGVEZWZzPiAgIA0KICAgICAg IA0KICAgICAgVGhlcmUgYXJlIHR3byBraW5kcyBvZiBkYXRhIHR5cGVzOiBhdG9taWMgYW5kIGNv bXBvdW5kLiAgQXRvbWljIA0KICAgICAgZGF0YSB0eXBlcyBhcmUgYXBwcm9wcmlhdGUgZm9yIHNp bmdsZS12YWx1ZSB2YXJpYWJsZXMgKGUuZy4gDQogICAgICBpbnRlZ2VyLCBBU0NJSSBzdHJpbmcs IGJ5dGUgYXJyYXkpLiANCiAgICAgICANCiAgICAgIFRoZSBmb2xsb3dpbmcgYnVpbHQtaW4gYXRv bWljIGRhdGEgdHlwZXMgYXJlIHByb3ZpZGVkLCBidXQgDQogICAgICBhZGRpdGlvbmFsIGF0b21p YyBkYXRhIHR5cGVzIGNhbiBiZSBkZWZpbmVkIHdpdGggdGhlIDx0eXBlUmVmPiBhbmQgDQogICAg ICA8YXRvbWljPiBlbGVtZW50czogDQogICAgICAgDQogICAgICAgICA8bmFtZT4gICAgICAgICAg ICAgICAgICAgTWVhbmluZyANCiAgICAgICAgIC0tLS0gICAgICAgICAgICAgICAgICAgICAtLS0t LS0tIA0KICAgICAgICAgY2hhciAgICAgICAgICAgICAgICAgICAgIDgtYml0IHNpZ25lZCBpbnRl Z2VyIA0KICAgICAgICAgdWNoYXIgICAgICAgICAgICAgICAgICAgIDgtYml0IHVuc2lnbmVkIGlu dGVnZXIgDQogICAgICAgICBpbnQxNiAgICAgICAgICAgICAgICAgICAgMTYtYml0IHNpZ25lZCBp bnRlZ2VyIA0KICAgICAgICAgdWludDE2ICAgICAgICAgICAgICAgICAgIDE2LWJpdCB1bnNpZ25l ZCBpbnRlZ2VyIA0KICAgICAgICAgaW50MzIgICAgICAgICAgICAgICAgICAgIDMyLWJpdCBzaWdu ZWQgaW50ZWdlciANCiAgICAgICAgIHVpbnQzMiAgICAgICAgICAgICAgICAgICAzMi1iaXQgdW5z aWduZWQgaW50ZWdlciANCiAgICAgICAgIGludDY0ICAgICAgICAgICAgICAgICAgICA2NC1iaXQg c2lnbmVkIGludGVnZXIgDQogICAgICAgICB1aW50NjQgICAgICAgICAgICAgICAgICAgNjQtYml0 IHVuaXNnbmVkIGludGVnZXIgDQogICAgICAgICBzdHJpbmdbTl0gICAgICAgICAgICAgICAgQVND SUkgbnVsbC10ZXJtaW5hdGVkIHN0cmluZyB3aXRoIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJ1ZmZlciBvZiBOIGNoYXJhY3RlcnMgKHN0cmluZyBtYXggDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbGVuZ3RoIGlzIE4tMSkgDQogICAgICAgICBieXRlW05d ICAgICAgICAgICAgICAgICAgQSBieXRlIGFycmF5IG9mIE4gYnl0ZXMgDQogICAgICAgICBmbG9h dDE2ICAgICAgICAgICAgICAgICAgMTYtYml0IGZsb2F0aW5nIHBvaW50IG51bWJlciANCiAgICAg ICAgIGZsb2F0MzIgICAgICAgICAgICAgICAgICAzMi1iaXQgSUVFRSBmbG9hdGluZyBwb2ludCBu dW1iZXIgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNDFdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAg ICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICAN CiAgICAgICAgIGZsb2F0NjQgICAgICAgICAgICAgICAgICA2NC1iaXQgSUVFRSBmbG9hdGluZyBw b2ludCBudW1iZXIgDQogICAgICAgDQogICAgICBUaGVzZSBidWlsdC1pbiBkYXRhIHR5cGVzIGNh biBiZSByZWFkaWx5IHVzZWQgdG8gZGVmaW5lIG1ldGFkYXRhIA0KICAgICAgb3IgTEZCIGF0dHJp YnV0ZXMsIGJ1dCBjYW4gYWxzbyBiZSB1c2VkIGFzIGJ1aWxkaW5nIGJsb2NrcyB3aGVuIA0KICAg ICAgZGVmaW5pbmcgbmV3IGRhdGEgdHlwZXMuIA0KICAgICAgIA0KICAgICAgQ29tcG91bmQgZGF0 YSB0eXBlcyBjYW4gYnVpbGQgb24gYXRvbWljIGRhdGEgdHlwZXMgYW5kIG90aGVyIA0KICAgICAg Y29tcG91bmQgZGF0YSB0eXBlcy4gIFRoZXJlIGFyZSBmb3VyIHdheXMgdGhhdCBjb21wb3VuZCBk YXRhIHR5cGVzIA0KICAgICAgY2FuIGJlIGRlZmluZWQuICBUaGV5IG1heSBiZSBkZWZpbmVkIGFz IGFuIGFycmF5IG9mIGVsZW1lbnRzIG9mIA0KICAgICAgc29tZSBjb21wb3VuZCBvciBhdG9taWMg ZGF0YSB0eXBlLiAgVGhleSBtYXkgYmUgYSBzdHJ1Y3R1cmUgb2YgDQogICAgICBuYW1lZCBlbGVt ZW50cyBvZiBjb21wb3VuZCBvciBhdG9taWMgZGF0YSB0eXBlcyAoYWxhIEMgDQogICAgICBzdHJ1 Y3R1cmVzKS4gIFRoZXkgbWF5IGJlIGEgdW5pb24gb2YgbmFtZWQgZWxlbWVudHMgb2YgY29tcG91 bmQgb3IgDQogICAgICBhdG9taWMgZGF0YSB0eXBlcyAoYWxhIEMgdW5pb25zKS4gIFRoZXkgbWF5 IGFsc28gYmUgZGVmaW5lZCBhcyANCiAgICAgIGF1Z21lbnRhdGlvbnMgKGV4cGxhaW5lZCBiZWxv dyBpbiA0LjUuNikgb2YgZXhpc3RpbmcgY29tcG91bmQgZGF0YSANCiAgICAgIHR5cGVzLiANCiAg ICAgICANCiAgICAgIEdpdmVuIHRoYXQgdGhlIEZPUkNFUyBwcm90b2NvbCB3aWxsIGJlIGdldHRp bmcgYW5kIHNldHRpbmcgDQogICAgICBhdHRyaWJ1dGUgdmFsdWVzLCBhbGwgYXRvbWljIGRhdGEg dHlwZXMgdXNlZCBoZXJlIG11c3QgYmUgYWJsZSB0byANCiAgICAgIGJlIGNvbnZleWVkIGluIHRo ZSBGT1JDRVMgcHJvdG9jb2wuICBGdXJ0aGVyLCB0aGUgRk9SQ0VTIHByb3RvY29sIA0KICAgICAg d2lsbCBuZWVkIGEgbWVjaGFuaXNtIHRvIGNvbnZleSBjb21wb3VuZCBkYXRhIHR5cGVzLiAgSG93 ZXZlciwgdGhlIA0KICAgICAgZGV0YWlscyBvZiBzdWNoIHJlcHJlc2VudGF0aW9ucyBhcmUgZm9y IHRoZSBwcm90b2NvbCBkb2N1bWVudCB0byANCiAgICAgIGRlZmluZSwgbm90IHRoZSBtb2RlbCBk b2N1bWVudC4gDQogICAgDQogICAgICBGb3IgdGhlIGRlZmluaXRpb24gb2YgdGhlIGFjdHVhbCB0 eXBlIGluIHRoZSA8ZGF0YVR5cGVEZWY+IA0KICAgICAgZWxlbWVudCwgdGhlIGZvbGxvd2luZyBl bGVtZW50cyBhcmUgYXZhaWxhYmxlOiA8dHlwZVJlZj4sIA0KICAgICAgPGF0b21pYz4sIDxhcnJh eT4sIDxzdHJ1Y3Q+LCBhbmQgPHVuaW9uPi4gDQogICAgICAgDQogICAgICBbRURJVE9SOiBIb3cg dG8gc3VwcG9ydCBhdWdtZW50YXRpb24gaXMgZm9yIGZ1cnRoZXIgc3R1ZHkuXSANCiAgICAgICAN CiAgIDQuNS4xLiA8dHlwZVJlZj4gRWxlbWVudCBmb3IgQWxpYXNpbmcgRXhpc3RpbmcgRGF0YSBU eXBlcyANCiAgICAgICANCiAgICAgIFRoZSA8dHlwZVJlZj4gZWxlbWVudCByZWZlcnMgdG8gYW4g ZXhpc3RpbmcgZGF0YSB0eXBlIGJ5IGl0cyBuYW1lLiAgDQogICAgICBUaGUgcmVmZXJyZWQgZGF0 YSB0eXBlIG11c3QgYmUgZGVmaW5lZCBlaXRoZXIgaW4gdGhlIHNhbWUgbGlicmFyeSANCiAgICAg IGRvY3VtZW50LCBvciBpbiBvbmUgb2YgdGhlIGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAg SWYgdGhlIA0KICAgICAgcmVmZXJyZWQgZGF0YSB0eXBlIGlzIGFuIGF0b21pYyBkYXRhIHR5cGUs IHRoZSBuZXdseSBkZWZpbmVkIHR5cGUgDQogICAgICB3aWxsIGFsc28gYmUgcmVnYXJkZWQgYXMg YXRvbWljLiAgSWYgdGhlIHJlZmVycmVkIGRhdGEgdHlwZSBpcyBhIA0KICAgICAgY29tcG91bmQg dHlwZSwgdGhlIG5ldyB0eXBlIHdpbGwgYWxzbyBiZSBhIGNvbXBvdW5kLiAgU29tZSB1c2FnZSAN CiAgICAgIGV4YW1wbGVzIGZvbGxvdzogDQogICAgICAgDQogICAgICA8ZGF0YVR5cGVEZWY+IA0K ICAgICAgICA8bmFtZT5zaG9ydDwvbmFtZT4gDQogICAgICAgIDxzeW5vcHNpcz5BbGlhcyB0byBp bnQxNjwvc3lub3BzaXM+IA0KICAgICAgICA8dHlwZVJlZj5pbnQxNjwvdHlwZVJlZj4gDQogICAg ICA8L2RhdGFUeXBlRGVmPiANCiAgICAgIDxkYXRhVHlwZURlZj4gDQogICAgICAgIDxuYW1lPmll ZWVtYWNhZGRyPC9uYW1lPiANCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQyXSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAgICAgIDxzeW5vcHNpcz40OC1iaXQgSUVFRSBNQUMgYWRkcmVzczwv c3lub3BzaXM+IA0KICAgICAgICA8dHlwZVJlZj5ieXRlWzZdPC90eXBlUmVmPiANCiAgICAgIDwv ZGF0YVR5cGVEZWY+IA0KICAgICAgIA0KICAgNC41LjIuIDxhdG9taWM+IEVsZW1lbnQgZm9yIERl cml2aW5nIE5ldyBBdG9taWMgVHlwZXMgDQogICAgICAgDQogICAgICBUaGUgPGF0b21pYz4gZWxl bWVudCBhbGxvd3MgdGhlIGRlZmluaXRpb24gb2YgYSBuZXcgYXRvbWljIHR5cGUgDQogICAgICBm cm9tIGFuIGV4aXN0aW5nIGF0b21pYyB0eXBlLCBhcHBseWluZyByYW5nZSByZXN0cmljdGlvbnMg YW5kL29yIA0KICAgICAgcHJvdmlkaW5nIHNwZWNpYWwgZW51bWVyYXRlZCB2YWx1ZXMuICBOb3Rl IHRoYXQgdGhlIDxhdG9taWM+IA0KICAgICAgZWxlbWVudCBjYW4gb25seSB1c2UgYXRvbWljIHR5 cGVzIGFzIGJhc2UgdHlwZXMsIGFuZCBpdHMgcmVzdWx0IGlzIA0KICAgICAgYWx3YXlzIGFub3Ro ZXIgYXRvbWljIHR5cGUuIA0KICAgICAgIA0KICAgICAgRm9yIGV4YW1wbGUsIHRoZSBmb2xsb3dp bmcgc25pcHBldCBkZWZpbmVzIGEgbmV3ICJkc2NwIiBkYXRhIHR5cGU6IA0KICAgICAgIA0KICAg ICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAgPG5hbWU+ZHNjcDwvbmFtZT4gDQogICAgICAgIDxz eW5vcHNpcz5EaWZmc2VydiBjb2RlIHBvaW50Ljwvc3lub3BzaXM+IA0KICAgICAgICA8YXRvbWlj PiANCiAgICAgICAgICA8YmFzZVR5cGU+dWNoYXI8L2Jhc2VUeXBlPiANCiAgICAgICAgICA8cmFu Z2VSZXN0cmljdGlvbj4gDQogICAgICAgICAgICA8YWxsb3dlZFJhbmdlIG1pbj0iMCIgbWF4PSI2 MyIvPiANCiAgICAgICAgICA8L3JhbmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAgIDxzcGVjaWFs VmFsdWVzPiANCiAgICAgICAgICAgIDxzcGVjaWFsVmFsdWUgdmFsdWU9IjAiPiANCiAgICAgICAg ICAgICAgPG5hbWU+RFNDUC1CRTwvbmFtZT4gDQogICAgICAgICAgICAgIDxzeW5vcHNpcz5CZXN0 IEVmZm9ydDwvc3lub3BzaXM+IA0KICAgICAgICAgICAgPC9zcGVjaWFsVmFsdWU+IA0KICAgICAg ICAgICAgLi4uIA0KICAgICAgICAgIDwvc3BlY2lhbFZhbHVlcz4gDQogICAgICAgIDwvYXRvbWlj PiANCiAgICAgIDwvZGF0YVR5cGVEZWY+IA0KICAgIA0KICAgNC41LjMuIDxhcnJheT4gRWxlbWVu dCB0byBEZWZpbmUgQXJyYXlzIA0KICAgICAgIA0KICAgICAgVGhlIDxhcnJheT4gZWxlbWVudCBj YW4gYmUgdXNlZCB0byBjcmVhdGUgYSBuZXcgY29tcG91bmQgZGF0YSB0eXBlIA0KICAgICAgYXMg YW4gYXJyYXkgb2YgYSBjb21wb3VuZCBvciBhbiBhdG9taWMgZGF0YSB0eXBlLiBUaGUgdHlwZSBv ZiB0aGUgDQogICAgICBhcnJheSBlbnRyeSBjYW4gYmUgc3BlY2lmaWVkIGVpdGhlciBieSByZWZl cnJpbmcgdG8gYW4gZXhpc3RpbmcgDQogICAgICB0eXBlICh1c2luZyB0aGUgPHR5cGVSZWY+IGVs ZW1lbnQpIG9yIGRlZmluaW5nIGFuIHVubmFtZWQgdHlwZSANCiAgICAgIGluc2lkZSB0aGUgPGFy cmF5PiBlbGVtZW50IHVzaW5nIGFueSBvZiB0aGUgPGF0b21pYz4sIDxhcnJheT4sIA0KICAgICAg PHN0cnVjdD4sIG9yIDx1bmlvbj4gZWxlbWVudHMuIA0KICAgICAgIA0KICAgICAgVGhlIGFycmF5 IGNhbiBiZSAiZml4ZWQtc2l6ZSIgb3IgInZhcmlhYmxlLXNpemUiLCB3aGljaCBpcyANCiAgICAg IHNwZWNpZmllZCBieSB0aGUgInR5cGUiIGF0dHJpYnV0ZSBvZiB0aGUgPGFycmF5PiBlbGVtZW50 LiBUaGUgDQogICAgICBkZWZhdWx0IGlzICJ2YXJpYWJsZS1zaXplIi4gIEZvciB2YXJpYWJsZSBz aXplIGFycmF5cywgYW4gb3B0aW9uYWwgDQogICAgICAibWF4LWxlbmd0aCIgYXR0cmlidXRlIGNh biBzcGVjaWZ5IHRoZSBtYXhpbXVtIGFsbG93ZWQgbGVuZ3RoLiANCiAgICAgIFRoaXMgYXR0cmli dXRlIHNob3VsZCBiZSB1c2VkIHRvIGVuY29kZSBzZW1hbnRpYyBsaW1pdGF0aW9ucywgYW5kIA0K ICAgICAgbm90IGltcGxlbWVudGF0aW9uIGxpbWl0YXRpb25zLiBUaGUgbGF0dGVyIHNob3VsZCBi ZSBoYW5kbGVkIGJ5IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQzXSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICBjYXBhYmlsaXR5IGF0dHJpYnV0ZXMgb2YgTEZCIGNsYXNzZXMsIGFuZCBz aG91bGQgbmV2ZXIgYmUgaW5jbHVkZWQgDQogICAgICBpbiBkYXRhIHR5cGUgZGVmaW5pdGlvbnMu IElmIHRoZSAibWF4LWxlbmd0aCIgYXR0cmlidXRlIGlzIG5vdCANCiAgICAgIHByb3ZpZGVkLCB0 aGUgYXJyYXkgaXMgcmVnYXJkZWQgYXMgb2YgdW5saW1pdGVkLXNpemUuIA0KICAgICAgIA0KICAg ICAgRm9yIGZpeGVkLXNpemUgYXJyYXlzLCBhICJsZW5ndGgiIGF0dHJpYnV0ZSBtdXN0IGJlIHBy b3ZpZGVkIHRoYXQgDQogICAgICBzcGVjaWZpZXMgdGhlIGNvbnN0YW50IHNpemUgb2YgdGhlIGFy cmF5LiANCiAgICAgICANCiAgICAgIFRoZSByZXN1bHQgb2YgdGhpcyBjb25zdHJ1Y3QgaXMgYWx3 YXlzIGEgY29tcG91bmQgdHlwZSwgZXZlbiBpZiANCiAgICAgIHRoZSBhcnJheSBoYXMgYSBmaXhl ZCBzaXplIG9mIDEuIA0KICAgIA0KICAgICAgQXJyYXlzIGNhbiBvbmx5IGJlIHN1YnNjcmlwdGVk IGJ5IGludGVnZXJzLCBhbmQgd2lsbCBiZSBwcmVzdW1lZCANCiAgICAgIHRvIHN0YXJ0IHdpdGgg aW5kZXggMC4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhl IGRlZmluaXRpb24gb2YgYSBmaXhlZCBzaXplIGFycmF5IA0KICAgICAgd2l0aCBhIHByZS1kZWZp bmVkIGRhdGEgdHlwZSBhcyB0aGUgYXJyYXkgZWxlbWVudHM6IA0KICAgICAgIA0KICAgICAgPGRh dGFUeXBlRGVmPiANCiAgICAgICAgPG5hbWU+ZHNjcC1tYXBwaW5nLXRhYmxlPC9uYW1lPiANCiAg ICAgICAgPHN5bm9wc3lzPiANCiAgICAgICAgICBBIHRhYmxlIG9mIDY0IERTQ1AgdmFsdWVzLCB1 c2VkIHRvIHJlLW1hcCBjb2RlIHNwYWNlLiANCiAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAg IDxhcnJheSB0eXBlPSJmaXhlZC1zaXplIiBsZW5ndGg9IjY0Ij4gDQogICAgICAgICAgICA8dHlw ZVJlZj5kc2NwPC90eXBlUmVmPiANCiAgICAgICAgPC9hcnJheT4gDQogICAgICA8L2RhdGFUeXBl RGVmPiANCiAgICAgICANCiAgICAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBkZWZpbmVzIGEgdmFy aWFibGUgc2l6ZSBhcnJheSB3aXRoIGFuIHVwcGVyIA0KICAgICAgbGltaXQgb24gaXRzIHNpemU6 IA0KICAgICAgIA0KICAgICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAgPG5hbWU+bWFjLWFsaWFz LXRhYmxlIDwvbmFtZT4gDQogICAgICAgIDxzeW5vcHN5cz5BIHRhYmxlIHdpdGggdXAgdG8gOCBJ RUVFIE1BQyBhZGRyZXNzZXM8L3N5bm9wc2lzPiANCiAgICAgICAgPGFycmF5IHR5cGU9InZhcmlh YmxlLXNpemUiIG1heC1sZW5ndGg9IjgiPiANCiAgICAgICAgICAgIDx0eXBlUmVmPmllZWVtYWNh ZGRyPC90eXBlUmVmPiANCiAgICAgICAgPC9hcnJheT4gDQogICAgICA8L2RhdGFUeXBlRGVmPiAN CiAgICANCiAgICAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyB0aGUgZGVmaW5pdGlvbiBv ZiBhbiBhcnJheSB3aXRoIGEgDQogICAgICBsb2NhbCAodW5uYW1lZCkgdHlwZSBkZWZpbml0aW9u OiANCiAgICAgICANCiAgICAgIDxkYXRhVHlwZURlZj4gDQogICAgICAgIDxuYW1lPmNsYXNzaWZp Y2F0aW9uLXRhYmxlPC9uYW1lPiANCiAgICAgICAgPHN5bm9wc3lzPiANCiAgICAgICAgICBBIHRh YmxlIG9mIGNsYXNzaWZpY2F0aW9uIHJ1bGVzIGFuZCByZXN1bHQgb3Bjb2Rlcy4gDQogICAgICAg IDwvc3lub3BzaXM+IA0KICAgICAgICA8YXJyYXkgdHlwZT0idmFyaWFibGUtc2l6ZSI+IA0KICAg ICAgICAgIDxzdHJ1Y3Q+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQ0XSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICAgICAgICA8ZWxlbWVudD4gDQogICAgICAgICAgICAgIDxuYW1lPnJ1 bGU8L25hbWU+IA0KICAgICAgICAgICAgICA8c3lub3BzaXM+VGhlIHJ1bGUgdG8gbWF0Y2g8L3N5 bm9wc2lzPiANCiAgICAgICAgICAgICAgPHR5cGVSZWY+Y2xhc3NydWxlPC90eXBlUmVmPiANCiAg ICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgICA8ZWxlbWVudD4gDQogICAgICAgICAg ICAgIDxuYW1lPm9wY29kZTwvbmFtZT4gDQogICAgICAgICAgICAgIDxzeW5vcHNpcz5UaGUgcmVz dWx0IGNvZGU8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgPHR5cGVSZWY+b3Bjb2RlPC90eXBl UmVmPiANCiAgICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgPC9zdHJ1Y3Q+IA0KICAg ICAgICA8L2FycmF5PiANCiAgICAgIDwvZGF0YVR5cGVEZWY+IA0KICAgICAgIA0KICAgICAgSW4g dGhlIGFib3ZlIGV4YW1wbGUgZWFjaCBlbnRyeSBvZiB0aGUgYXJyYXkgaXMgYSA8c3RydWN0PiBv ZiB0d28gDQogICAgICBmaWxlZHMgKCJydWxlIiBhbmQgIm9wY29kZSIpLiANCiAgICAgICANCiAg IDQuNS40LiA8c3RydWN0PiBFbGVtZW50IHRvIERlZmluZSBTdHJ1Y3R1cmVzIA0KICAgICAgIA0K ICAgICAgQSBzdHJ1Y3R1cmUgaXMgY29tcHJpc2VkIG9mIGEgY29sbGVjdGlvbiBvZiBkYXRhIGVs ZW1lbnRzLiAgRWFjaCANCiAgICAgIGRhdGEgZWxlbWVudCBoYXMgYSBkYXRhIHR5cGUgKGVpdGhl ciBhbiBhdG9taWMgdHlwZSBvciBhbiBleGlzdGluZyANCiAgICAgIGNvbXBvdW5kIHR5cGUpIGFu ZCBpcyBhc3NpZ25lZCBhIG5hbWUgdW5pcXVlIHdpdGhpbiB0aGUgc2NvcGUgb2YgDQogICAgICB0 aGUgY29tcG91bmQgZGF0YSB0eXBlIGJlaW5nIGRlZmluZWQuICBUaGVzZSBzZXJ2ZSB0aGUgc2Ft ZSANCiAgICAgIGZ1bmN0aW9uIGFzICJzdHJ1Y3QiIGluIEMsIGV0Yy4gDQogICAgICAgDQogICAg ICBUaGUgYWN0dWFsIHR5cGUgb2YgdGhlIGZpZWxkIGNhbiBiZSBkZWZpbmVkIGJ5IHJlZmVycmlu ZyB0byBhbiANCiAgICAgIGV4aXN0aW5nIHR5cGUgKHVzaW5nIHRoZSA8dHlwZURlZj4gZWxlbWVu dCksIG9yIGNhbiBiZSBhIGxvY2FsbHkgDQogICAgICBkZWZpbmVkICh1bm5hbWVkKSB0eXBlIGNy ZWF0ZWQgYnkgYW55IG9mIHRoZSA8YXRvbWljPiwgPGFycmF5PiwgDQogICAgICA8c3RydWN0Piwg b3IgPHVuaW9uPiBlbGVtZW50cy4gIA0KICAgICAgIA0KICAgICAgVGhlIHJlc3VsdCBvZiB0aGlz IGNvbnN0cnVjdCBpcyBhbHdheXMgcmVnYXJkZWQgYSBjb21wb3VuZCB0eXBlLCANCiAgICAgIGV2 ZW4gaWYgdGhlIDxzdHJ1Y3Q+IGNvbnRhaW5zIG9ubHkgb25lIGZpZWxkLiANCiAgICAgICANCiAg ICAgIEFuIGV4YW1wbGU6IA0KICAgICAgIA0KICAgICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAg PG5hbWU+aXB2NHByZWZpeDwvbmFtZT4gDQogICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAg SVB2NCBwcmVmaXggZGVmaW5lZCBieSBhbiBhZGRyZXNzIGFuZCBhIHByZWZpeCBsZW5ndGggDQog ICAgICAgIDwvc3lub3BzaXM+IA0KICAgICAgICA8c3RydWN0PiANCiAgICAgICAgICA8ZWxlbWVu dD4gDQogICAgICAgICAgICA8bmFtZT5hZGRyZXNzPC9uYW1lPiANCiAgICAgICAgICAgIDxzeW5v cHNpcz5BZGRyZXNzIHBhcnQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgIDx0eXBlUmVmPmlwdjRh ZGRyPC90eXBlUmVmPiANCiAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAgICAgICAgIDxlbGVtZW50 PiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA0NV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAg ICAgICAgICAgPG5hbWU+cHJlZml4bGVuPC9uYW1lPiANCiAgICAgICAgICAgIDxzeW5vcHNpcz5Q cmVmaXggbGVuZ3RoIHBhcnQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgIDxhdG9taWM+IA0KICAg ICAgICAgICAgICA8YmFzZVR5cGU+dWNoYXI8L2Jhc2VUeXBlPiANCiAgICAgICAgICAgICAgPHJh bmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAgICAgICAgIDxhbGxvd2VkUmFuZ2UgbWluPSIwIiBt YXg9IjMyIi8+IA0KICAgICAgICAgICAgICA8L3JhbmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAg ICAgPC9hdG9taWM+IA0KICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgIDwvc3RydWN0PiAN CiAgICAgIDwvZGF0YVR5cGVEZWY+IA0KICAgIA0KICAgNC41LjUuIDx1bmlvbj4gRWxlbWVudCB0 byBEZWZpbmUgVW5pb24gVHlwZXMgDQogICAgICAgDQogICAgICBTaW1pbGFyIHRvIHRoZSB1bmlv biBkZWNsYXJhdGlvbiBpbiBDLCB0aGlzIGNvbnN0cnVjdCBhbGxvd3MgdGhlIA0KICAgICAgZGVm aW5pdGlvbiBvZiBvdmVybGF5IHR5cGVzLiAgSXRzIGZvcm1hdCBpcyBpZGVudGljYWwgdG8gdGhl IA0KICAgICAgPHN0cnVjdD4gZWxlbWVudC4gDQogICAgICAgDQogICAgICBUaGUgcmVzdWx0IG9m IHRoaXMgY29uc3RydWN0IGlzIGFsd2F5cyByZWdhcmRlZCBhIGNvbXBvdW5kIHR5cGUsIA0KICAg ICAgZXZlbiBpZiB0aGUgdW5pb24gY29udGFpbnMgb25seSBvbmUgZWxlbWVudC4gDQogICAgICAg DQogICA0LjUuNi4gQXVnbWVudGF0aW9ucyANCiAgICAgICANCiAgICAgIENvbXBvdW5kIHR5cGVz IGNhbiBhbHNvIGJlIGRlZmluZWQgYXMgYXVnbWVudGF0aW9ucyBvZiBleGlzdGluZyANCiAgICAg IGNvbXBvdW5kIHR5cGVzLiAgSWYgdGhlIGV4aXN0aW5nIGNvbXBvdW5kIHR5cGUgaXMgYSBzdHJ1 Y3R1cmUsIA0KICAgICAgYXVnbWVudGF0aW9uIG1heSBhZGQgbmV3IGVsZW1lbnRzIHRvIHRoZSB0 eXBlLiAgVGhlIHR5cGUgb2YgYW4gDQogICAgICBleGlzdGluZyBlbGVtZW50IGNhbiBvbmx5IGJl IHJlcGxhY2VkIHdpdGggYW4gYXVnbWVudGF0aW9uIGRlcml2ZWQgDQogICAgICBmcm9tIHRoZSBj dXJyZW50IHR5cGUsIGFuIGV4aXN0aW5nIGVsZW1lbnQgY2Fubm90IGJlIGRlbGV0ZWQuICBJZiAN CiAgICAgIHRoZSBleGlzdGluZyBjb21wb3VuZCB0eXBlIGlzIGFuIGFycmF5LCBhdWdtZW50YXRp b24gbWVhbnMgDQogICAgICBhdWdtZW50YXRpb24gb2YgdGhlIGFycmF5IGVsZW1lbnQgdHlwZS4g DQogICAgICAgDQogICAgICBPbmUgY29uc2VxdWVuY2Ugb2YgdGhpcyBpcyB0aGF0IGF1Z21lbnRh dGlvbnMgYXJlIGNvbXBhdGlibGUgd2l0aCANCiAgICAgIHRoZSBjb21wb3VuZCB0eXBlIGZyb20g d2hpY2ggdGhleSBhcmUgZGVyaXZlZC4gIEFzIHN1Y2gsIA0KICAgICAgYXVnbWVudGF0aW9ucyBh cmUgdXNlZnVsIGluIGRlZmluaW5nIGF0dHJpYnV0ZXMgZm9yIExGQiBzdWJjbGFzc2VzIA0KICAg ICAgd2l0aCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiAgSW4gYWRkaXRpb24gdG8gYWRkaW5nIG5l dyBhdHRyaWJ1dGVzIA0KICAgICAgdG8gYSBjbGFzcywgdGhlIGRhdGEgdHlwZSBvZiBhbiBleGlz dGluZyBhdHRyaWJ1dGUgbWF5IGJlIHJlcGxhY2VkIA0KICAgICAgYnkgYW4gYXVnbWVudGF0aW9u IG9mIHRoYXQgYXR0cmlidXRlLCBhbmQgc3RpbGwgbWVldCB0aGUgDQogICAgICBjb21wYXRpYmls aXR5IHJ1bGVzIGZvciBzdWJjbGFzc2VzLiAgIA0KICAgICAgIA0KICAgICAgRm9yIGV4YW1wbGUs IGNvbnNpZGVyIGEgc2ltcGxlIGJhc2UgTEZCIGNsYXNzIEEgdGhhdCBoYXMgb25seSBvbmUgDQog ICAgICBhdHRyaWJ1dGUgKGF0dHIxKSBvZiB0eXBlIFguICBPbmUgd2F5IHRvIGRlcml2ZSBjbGFz cyBBMSBmcm9tIEEgDQogICAgICBjYW4gYmUgYnkgc2ltcGx5IGFkZGluZyBhIHNlY29uZCBhdHRy aWJ1dGUgKG9mIGFueSB0eXBlKS4gIEFub3RoZXIgDQogICAgICB3YXkgdG8gZGVyaXZlIGEgY2xh c3MgQTIgZnJvbSBBIGNhbiBiZSBieSByZXBsYWNpbmcgdGhlIG9yaWdpbmFsIA0KICAgICAgYXR0 cmlidXRlIChhdHRyMSkgaW4gQSBvZiB0eXBlIFggd2l0aCBvbmUgb2YgdHlwZSBZLCB3aGVyZSBZ IGlzIGFuIA0KICAgICAgYXVnbWVudGF0aW9uIG9mIFguICBCb3RoIGNsYXNzZXMgQTEgYW5kIEEy IGFyZSBiYWNrd2FyZCBjb21wYXRpYmxlIA0KICAgICAgd2l0aCBjbGFzcyBBLiANCiAgICAgICAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA0Nl0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg W0VESVRPUjogSG93IHRvIHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgYXVnbWVudGF0aW9uIGluIHRo ZSBYTUwgDQogICAgICBzY2hlbWEgaXMgZm9yIGZ1cnRoZXIgc3R1ZHkuXSANCiAgICANCiAgIDQu Ni4gPG1ldGFkYXRhRGVmcz4gRWxlbWVudCBmb3IgTWV0YWRhdGEgRGVmaW5pdGlvbnMgDQogICAg DQogICAgICBUaGUgKG9wdGlvbmFsKSA8bWV0YWRhdGFEZWZzPiBlbGVtZW50IGluIHRoZSBsaWJy YXJ5IGRvY3VtZW50IA0KICAgICAgY29udGFpbnMgb25lIG9yIG1vcmUgPG1ldGFkYXRhRGVmPiBl bGVtZW50cy4gIEVhY2ggPG1ldGFkYXRhRGVmPiANCiAgICAgIGVsZW1lbnQgZGVmaW5lcyBhIG1l dGFkYXRhLiANCiAgICAgICANCiAgICAgIEVhY2ggPG1ldGFkYXRhRGVmPiBlbGVtZW50IGNvbnRh aW5zIGEgdW5pcXVlIG5hbWUgKE5NVE9LRU4pLiANCiAgICAgIFVuaXF1ZW5lc3MgaXMgZGVmaW5l ZCB0byBiZSBvdmVyIGFsbCBtZXRhZGF0YSBkZWZpbmVkIGluIHRoaXMgDQogICAgICBsaWJyYXJ5 IGRvY3VtZW50IGFuZCBpbiBhbGwgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSBpbmNsdWRlZCANCiAg ICAgIGxpYnJhcnkgZG9jdW1lbnRzLiBUaGUgPG1ldGFkYXRhRGVmPiBlbGVtZW50IGFsc28gY29u dGFpbnMgYSBicmllZiANCiAgICAgIHN5bm9wc2lzLCBhbiBvcHRpb25hbCBkZXRhaWxlZCBkZXNj cmlwdGlvbiwgYW5kIGEgY29tcHVsc29yeSB0eXBlIA0KICAgICAgZGVmaW5pdGlvbiBpbmZvcm1h dGlvbi4gT25seSBhdG9taWMgZGF0YSB0eXBlcyBjYW4gYmUgdXNlZCBhcyANCiAgICAgIHZhbHVl IHR5cGVzIGZvciBtZXRhZGF0YS4gIA0KICAgICAgIA0KICAgICAgVHdvIGZvcm1zIG9mIHR5cGUg ZGVmaW5pdGlvbnMgYXJlIGFsbG93ZWQuIFRoZSBmaXJzdCBmb3JtIHVzZXMgdGhlIA0KICAgICAg PHR5cGVSZWY+IGVsZW1lbnQgdG8gcmVmZXIgdG8gYW4gZXhpc3RpbmcgYXRvbWljIGRhdGEgdHlw ZSBkZWZpbmVkIA0KICAgICAgaW4gdGhlIDxkYXRhVHlwZURlZnM+IGVsZW1lbnQgb2YgdGhlIHNh bWUgbGlicmFyeSBkb2N1bWVudCBvciBpbiANCiAgICAgIG9uZSBvZiB0aGUgaW5jbHVkZWQgbGli cmFyeSBkb2N1bWVudHMuIFRoZSB1c2FnZSBvZiB0aGUgPHR5cGVSZWY+IA0KICAgICAgZWxlbWVu dCBpcyBpZGVudGljYWwgdG8gaG93IGl0IGlzIHVzZWQgaW4gdGhlIDxkYXRhVHlwZURlZj4gDQog ICAgICBlbGVtZW50cywgZXhjZXB0IGhlcmUgaXQgY2FuIG9ubHkgcmVmZXIgdG8gYXRvbWljIHR5 cGVzLiANCiAgICAgICANCiAgICAgIFtFRElUT1I6IFRoZSBsYXR0ZXIgcmVzdHJpY3Rpb24gaXMg bm90IHlldCBlbmZvcmNlZCBieSB0aGUgWE1MIA0KICAgICAgc2NoZW1hLl0gDQogICAgICAgDQog ICAgICBUaGUgc2Vjb25kIGZvcm0gaXMgYW4gZXhwbGljaXQgdHlwZSBkZWZpbml0aW9uIHVzaW5n IHRoZSA8YXRvbWljPiANCiAgICAgIGVsZW1lbnQuIFRoaXMgZWxlbWVudCBpcyB1c2VkIGhlcmUg aW4gdGhlIHNhbWUgd2F5IGFzIGluIHRoZSANCiAgICAgIDxkYXRhVHlwZURlZj4gZWxlbWVudHMu IA0KICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIGJvdGggdXNhZ2VzOiAN CiAgICAgICAgDQogICAgICA8bWV0YWRhdGFEZWZzPiANCiAgICAgICAgPG1ldGFkYXRhRGVmPiAN CiAgICAgICAgICA8bmFtZT5ORVhUSE9QSUQ8L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNpcz5S ZWZlcnMgdG8gYSBOZXh0IEhvcCBlbnRyeSBpbiBOSCBMRkI8L3N5bm9wc2lzPiANCiAgICAgICAg ICA8dHlwZVJlZj5pbnQzMjwvdHlwZVJlZj4gDQogICAgICAgIDwvbWV0YWRhdGFEZWY+IA0KICAg ICAgICA8bWV0YWRhdGFEZWY+IA0KICAgICAgICAgIDxuYW1lPkNMQVNTSUQ8L25hbWU+IA0KICAg ICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICBSZXN1bHQgb2YgY2xhc3NpZmljYXRpb24g KDAgbWVhbnMgbm8gbWF0Y2gpLiANCiAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICA8 YXRvbWljPiANCiAgICAgICAgICAgIDxiYXNlVHlwZT5pbnQzMjwvYmFzZVR5cGU+IA0KICAgICAg ICAgICAgPHNwZWNpYWxWYWx1ZXM+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJl cyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQ3XSANCgwgICBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIw MDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgIDxzcGVjaWFsVmFsdWUgdmFsdWU9IjAiPiAN CiAgICAgICAgICAgICAgICA8bmFtZT5OT01BVENIPC9uYW1lPiANCiAgICAgICAgICAgICAgICA8 c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgQ2xhc3NpZmljYXRpb24gZGlkbpJ0IHJlc3Vs dCBpbiBtYXRjaC4gDQogICAgICAgICAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAg IDwvc3BlY2lhbFZhbHVlPiANCiAgICAgICAgICAgIDwvc3BlY2lhbFZhbHVlcz4gDQogICAgICAg ICAgPC9hdG9taWM+IA0KICAgICAgICA8L21ldGFkYXRhRGVmPiANCiAgICAgIDwvbWV0YWRhdGFE ZWZzPiANCiAgICAgICANCiAgIDQuNy4gPExGQkNsYXNzRGVmcz4gRWxlbWVudCBmb3IgTEZCIENs YXNzIERlZmluaXRpb25zIA0KICAgICAgIA0KICAgICAgVGhlIChvcHRpb25hbCkgPExGQkNsYXNz RGVmcz4gZWxlbWVudCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgb25lIG9yIA0KICAgICAgbW9yZSBM RkIgY2xhc3NlcyB1c2luZyA8TEZCQ2xhc3NEZWY+IGVsZW1lbnRzLiAgRWFjaCA8TEZCQ2xhc3NE ZWY+IA0KICAgICAgZWxlbWVudCBkZWZpbmVzIGFuIExGQiBjbGFzcyBhbmQgaW5jbHVkZXMgdGhl IGZvbGxvd2luZyBlbGVtZW50czogDQogICAgICAgIC4gPG5hbWU+IHByb3ZpZGVzIHRoZSBzeW1i b2xpYyBuYW1lIG9mIHRoZSBMRkIgY2xhc3MuICBFeGFtcGxlOiANCiAgICAgICAgICAiaXB2NGxw bSIgDQogICAgICAgIC4gPHN5bm9wc2lzPiBwcm92aWRlcyBhIHNob3J0IHN5bm9wc2lzIG9mIHRo ZSBMRkIgY2xhc3MuIA0KICAgICAgICAgIEV4YW1wbGU6ICJJUHY0IExvbmdlc3QgUHJlZml4IE1h dGNoIExvb2t1cCBMRkIiIA0KICAgICAgICAuIDx2ZXJzaW9uPiBpcyB0aGUgdmVyc2lvbiBpbmRp Y2F0b3IgDQogICAgICAgIC4gPGRlcml2ZWRGcm9tPiBpcyB0aGUgaW5oZXJpdGFuY2UgaW5kaWNh dG9yIA0KICAgICAgICAuIDxpbnB1dFBvcnRzPiBsaXN0cyB0aGUgaW5wdXQgcG9ydHMgYW5kIHRo ZWlyIHNwZWNpZmljYXRpb25zIA0KICAgICAgICAuIDxvdXRwdXRQb3J0cz4gbGlzdHMgdGhlIG91 dHB1dCBwb3J0cyBhbmQgdGhlaXIgc3BlY2lmaWNhdGlvbnMgDQogICAgICAgIC4gPGF0dHJpYnV0 ZXM+IGRlZmluZXMgdGhlIG9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMgb2YgdGhlIExGQiANCiAgICAg ICAgLiA8Y2FwYWJpbGl0aWVzPiBkZWZpbmVzIHRoZSBjYXBhYmlsaXR5IGF0dHJpYnV0ZXMgb2Yg dGhlIExGQiANCiAgICAgICAgLiA8ZGVzY3JpcHRpb24+IGNvbnRhaW5zIHRoZSBvcGVyYXRpb25h bCBzcGVjaWZpY2F0aW9uIG9mIHRoZSANCiAgICAgICAgICBMRkIgDQogICAgICAgDQogICAgICBb RURJVE9SOiBMRkIgY2xhc3MgbmFtZXMgc2hvdWxkIGJlIHVuaXF1ZSBub3Qgb25seSBhbW9uZyBj bGFzc2VzIA0KICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFuZCBpbiBhbGwgaW5jbHVk ZWQgZG9jdW1lbnRzLCBidXQgYWxzbyANCiAgICAgIHVuaXF1ZSBhY3Jvc3MgYSBsYXJnZSBjb2xs ZWN0aW9uIG9mIGxpYnJhcmllcy4gIE9idmlvdXNseSBzb21lIA0KICAgICAgZ2xvYmFsIGNvbnRy b2wgaXMgbmVlZGVkIHRvIGVuc3VyZSBzdWNoIHVuaXF1ZW5lc3MuICBUaGlzIHN1YmplY3QgDQog ICAgICByZXF1aXJlcyBmdXJ0aGVyIHN0dWR5Ll0gDQogICAgICAgDQogICAgICBIZXJlIGlzIGEg c2tlbGV0b24gb2YgYW4gZXhhbXBsZSBMRkIgY2xhc3MgZGVmaW5pdGlvbjogDQogICAgICAgDQog ICAgICA8TEZCQ2xhc3NEZWZzPiANCiAgICAgICAgPExGQkNsYXNzRGVmPiANCiAgICAgICAgICA8 bmFtZT5pcHY0bHBtPC9uYW1lPiANCiAgICAgICAgICA8c3lub3BzaXM+SVB2NCBMb25nZXN0IFBy ZWZpeCBNYXRjaCBMb29rdXAgTEZCPC9zeW5vcHNpcz4gDQogICAgICAgICAgPHZlcnNpb24+MS4w PC92ZXJzaW9uPiANCiAgICAgICAgICA8ZGVyaXZlZEZyb20+YmFzZWNsYXNzPC9kZXJpdmVkRnJv bT4gDQogICAgICAgDQogICAgICAgICAgPGlucHV0UG9ydHM+IA0KICAgICAgICAgICAgLi4uIA0K ICAgICAgICAgIDwvaW5wdXRQb3J0cz4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBp cmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNDhdIA0KDCAgIElu dGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3Qg MjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgICAgICA8b3V0cHV0UG9ydHM+IA0KICAg ICAgICAgICAgLi4uIA0KICAgICAgICAgIDwvb3V0cHV0UG9ydHM+IA0KICAgICAgIA0KICAgICAg ICAgIDxhdHRyaWJ1dGVzPiANCiAgICAgICAgICAgIC4uLiANCiAgICAgICAgICA8L2F0dHJpYnV0 ZXM+IA0KICAgICAgIA0KICAgICAgICAgIDxjYXBhYmlsaXRpZXM+IA0KICAgICAgICAgICAgLi4u IA0KICAgICAgICAgIDwvY2FwYWJpbGl0aWVzPiANCiAgICAgICANCiAgICAgICAgICA8ZGVzY3Jp cHRpb24+IA0KICAgICAgICAgICAgVGhpcyBMRkIgcmVwcmVzZW50cyB0aGUgSVB2NCBsb25nZXN0 IHByZWZpeCBtYXRjaCBsb29rdXAgDQogICAgICAgICAgICBvcGVyYXRpb24uIA0KICAgICAgICAg ICAgVGhlIG1vZGVsZWQgYmVoYXZpb3IgaXMgYXMgZm9sbG93czogDQogICAgICAgICAgICAgICBC bGFoLWJsYWgtYmxhaC4gDQogICAgICAgICAgPC9kZXNjcmlwdGlvbj4gDQogICAgICAgDQogICAg ICAgIDwvTEZCQ2xhc3NEZWY+IA0KICAgICAgICAuLi4gDQogICAgICA8L0xGQkNsYXNzRGVmcz4g DQogICAgICAgDQogICAgICBOb3RlIHRoYXQgdGhlIDxuYW1lPiwgPHN5bm9wc2lzPiwgYW5kIDx2 ZXJzaW9uPiBlbGVtZW50cyBhcmUgDQogICAgICByZXF1aXJlZCwgYWxsIG90aGVyIGVsZW1lbnRz IGFyZSBvcHRpb25hbCBpbiA8TEZCQ2xhc3NEZWY+LiANCiAgICAgIEhvd2V2ZXIsIHdoZW4gdGhl eSBhcmUgcHJlc2VudCwgdGhleSBtdXN0IG9jY3VyIGluIHRoZSBhYm92ZSANCiAgICAgIG9yZGVy LiAgDQogICAgICAgICANCiAgIDQuNy4xLiA8ZGVyaXZlZEZyb20+IEVsZW1lbnQgdG8gRXhwcmVz cyBMRkIgSW5oZXJpdGFuY2UgDQogICAgICAgDQogICAgICBUaGUgb3B0aW9uYWwgPGRlcml2ZWRG cm9tPiBlbGVtZW50IGNhbiBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgDQogICAgICB0aGlzIGNs YXNzIGlzIGEgZGVyaXZhdGl2ZSBvZiBzb21lIG90aGVyIGNsYXNzLiAgVGhlIGNvbnRlbnQgb2Yg DQogICAgICB0aGlzIGVsZW1lbnQgbXVzdCBiZSB0aGUgdW5pcXVlIG5hbWUgKDxuYW1lPikgb2Yg YW5vdGhlciBMRkIgDQogICAgICBjbGFzcy4gIFRoZSByZWZlcnJlZCBMRkIgY2xhc3MgbXVzdCBi ZSBkZWZpbmVkIGluIHRoZSBzYW1lIGxpYnJhcnkgDQogICAgICBkb2N1bWVudCBvciBpbiBvbmUg b2YgdGhlIGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiANCiAgICAgICANCiAgICAgIFtFRElU T1I6IFRoZSA8ZGVyaXZlZEZyb20+IGVsZW1lbnQgd2lsbCBsaWtlbHkgbmVlZCB0byBzcGVjaWZ5 IHRoZSANCiAgICAgIHZlcnNpb24gb2YgdGhlIGFuY2VzdG9yLCB3aGljaCBpcyBub3QgaW5jbHVk ZWQgaW4gdGhlIHNjaGVtYSB5ZXQuICANCiAgICAgIFRoZSBwcm9jZXNzIGFuZCBydWxlcyBvZiBj bGFzcyBkZXJpdmF0aW9uIGFyZSBzdGlsbCBiZWluZyANCiAgICAgIHN0dWRpZWQuXSANCiAgICAg ICANCiAgICAgIEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgZGVyaXZlZCBjbGFzcyBpcyBiYWNrd2Fy ZHMgY29tcGF0aWJsZSB3aXRoIA0KICAgICAgdGhlIGJhc2UgY2xhc3MuICAgDQogICAgICAgDQog ICA0LjcuMi4gPGlucHV0UG9ydHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBJbnB1dHMgDQogICAg ICAgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNDldIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAg Rm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAg ICAgIFRoZSBvcHRpb25hbCA8aW5wdXRQb3J0cz4gZWxlbWVudCBpcyB1c2VkIHRvIGRlZmluZSBp bnB1dCBwb3J0cy4gIA0KICAgICAgQW4gTEZCIGNsYXNzIG1heSBoYXZlIHplcm8sIG9uZSwgb3Ig bW9yZSBpbnB1dHMuICBJZiB0aGUgTEZCIGNsYXNzIA0KICAgICAgaGFzIG5vIGlucHV0IHBvcnRz LCB0aGUgPGlucHV0UG9ydHM+IGVsZW1lbnQgbXVzdCBiZSBvbWl0dGVkLiAgVGhlIA0KICAgICAg PGlucHV0UG9ydHM+IGVsZW1lbnQgY2FuIGNvbnRhaW4gb25lIG9yIG1vcmUgPGlucHV0UG9ydD4g ZWxlbWVudHMsIA0KICAgICAgb25lIGZvciBlYWNoIHBvcnQgb3IgcG9ydC1ncm91cC4gIFdlIGFz c3VtZSB0aGF0IG1vc3QgTEZCcyB3aWxsIA0KICAgICAgaGF2ZSBleGFjdGx5IG9uZSBpbnB1dC4g IE11bHRpcGxlIGlucHV0cyB3aXRoIHRoZSBzYW1lIGlucHV0IHR5cGUgDQogICAgICBhcmUgbW9k ZWxlZCBhcyBvbmUgaW5wdXQgZ3JvdXAuICBJbnB1dCBncm91cHMgYXJlIGRlZmluZWQgdGhlIHNh bWUgDQogICAgICB3YXkgYXMgaW5wdXQgcG9ydHMgYnkgdGhlIDxpbnB1dFBvcnQ+IGVsZW1lbnQs IGRpZmZlcmVudGlhdGVkIG9ubHkgDQogICAgICBieSBhbiBvcHRpb25hbCAiZ3JvdXAiIGF0dHJp YnV0ZS4gDQogICAgICAgDQogICAgICBNdWx0aXBsZSBpbnB1dHMgd2l0aCBkaWZmZXJlbnQgaW5w dXQgdHlwZXMgc2hvdWxkIGJlIGF2b2lkZWQgaWYgDQogICAgICBwb3NzaWJsZSAoc2VlIGRpc2N1 c3Npb24gaW4gU2VjdGlvbiAzLjIuMSkuICBTb21lIHNwZWNpYWwgTEZCcyANCiAgICAgIHdpbGwg aGF2ZSBubyBpbnB1dHMgYXQgYWxsLiAgRm9yIGV4YW1wbGUsIGEgcGFja2V0IGdlbmVyYXRvciBM RkIgDQogICAgICBkb2VzIG5vdCBuZWVkIGFuIGlucHV0LiANCiAgICAgICANCiAgICAgIFNpbmds ZSBpbnB1dCBwb3J0cyBhbmQgaW5wdXQgcG9ydCBncm91cHMgYXJlIGJvdGggZGVmaW5lZCBieSB0 aGUgDQogICAgICA8aW5wdXRQb3J0PiBlbGVtZW50LCB0aGV5IGFyZSBkaWZmZXJlbnRpYXRlZCBi eSBvbmx5IGFuIG9wdGlvbmFsIA0KICAgICAgImdyb3VwIiBhdHRyaWJ1dGUuIA0KICAgICAgIA0K ICAgICAgVGhlIDxpbnB1dFBvcnQ+IGVsZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBlbGVt ZW50czogDQogICAgICAuIDxuYW1lPiBwcm92aWRlcyB0aGUgc3ltYm9saWMgbmFtZSBvZiB0aGUg aW5wdXQuICBFeGFtcGxlOiAiaW4iLiAgDQogICAgICAgIE5vdGUgdGhhdCB0aGlzIHN5bWJvbGlj IG5hbWUgbXVzdCBiZSB1bmlxdWUgb25seSB3aXRoaW4gdGhlIA0KICAgICAgICBzY29wZSBvZiB0 aGUgTEZCIGNsYXNzLiANCiAgICAgIC4gPHN5bm9wc2lzPiBjb250YWlucyBhIGJyaWVmIGRlc2Ny aXB0aW9uIG9mIHRoZSBpbnB1dC4gIEV4YW1wbGU6IA0KICAgICAgICAiTm9ybWFsIHBhY2tldCBp bnB1dCIuIA0KICAgICAgLiA8ZXhwZWN0YXRpb24+IGxpc3RzIGFsbCBhbGxvd2VkIGZyYW1lIGZv cm1hdHMuICBFeGFtcGxlOiANCiAgICAgICAgeyJpcHY0IiBhbmQgImlwdjYifS4gIE5vdGUgdGhh dCB0aGlzIGxpc3Qgc2hvdWxkIHJlZmVyIHRvIG5hbWVzIA0KICAgICAgICBzcGVjaWZpZWQgaW4g dGhlIDxmcmFtZURlZnM+IGVsZW1lbnQgb2YgdGhlIHNhbWUgbGlicmFyeSANCiAgICAgICAgZG9j dW1lbnQgb3IgaW4gYW55IGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAgVGhlIA0KICAgICAg ICA8ZXhwZWN0YXRpb24+IGVsZW1lbnQgY2FuIGFsc28gcHJvdmlkZSBhIGxpc3Qgb2YgcmVxdWly ZWQgDQogICAgICAgIG1ldGFkYXRhLiAgRXhhbXBsZTogeyJjbGFzc2lkIiwgInZpZmlkIn0uICBU aGlzIGxpc3Qgc2hvdWxkIA0KICAgICAgICByZWZlciB0byBuYW1lcyBvZiBtZXRhZGF0YSBkZWZp bmVkIGluIHRoZSA8bWV0YWRhdGFEZWZzPiANCiAgICAgICAgZWxlbWVudCBpbiB0aGUgc2FtZSBs aWJyYXJ5IGRvY3VtZW50IG9yIGluIGFueSBpbmNsdWRlZCBsaWJyYXJ5IA0KICAgICAgICBkb2N1 bWVudHMuICBGb3IgZWFjaCBtZXRhZGF0YSwgaXQgbXVzdCBiZSBzcGVjaWZpZWQgd2hldGhlciB0 aGUgDQogICAgICAgIG1ldGFkYXRhIGlzIHJlcXVpcmVkIG9yIG9wdGlvbmFsLiAgRm9yIGVhY2gg b3B0aW9uYWwgbWV0YWRhdGEsIA0KICAgICAgICBhIGRlZmF1bHQgdmFsdWUgbXVzdCBiZSBzcGVj aWZpZWQsIHdoaWNoIGlzIHVzZWQgYnkgdGhlIExGQiBpZiANCiAgICAgICAgdGhlIG1ldGFkYXRh IGlzIG5vdCBwcm92aWRlZCB3aXRoIGEgcGFja2V0LiANCiAgICAgICANCiAgICAgIEluIGFkZGl0 aW9uLCB0aGUgb3B0aW9uYWwgImdyb3VwIiBhdHRyaWJ1dGUgb2YgdGhlIDxpbnB1dFBvcnQ+IA0K ICAgICAgZWxlbWVudCBjYW4gc3BlY2lmeSBpZiB0aGUgcG9ydCBjYW4gYmVoYXZlIGFzIGEgcG9y dCBncm91cCwgaS5lLiwgDQogICAgICBpdCBpcyBhbGxvd2VkIHRvIGJlIGluc3RhbnRpYXRlZC4g IFRoaXMgaXMgaW5kaWNhdGVkIGJ5IGEgInllcyIgDQogICAgICB2YWx1ZSAodGhlIGRlZmF1bHQg dmFsdWUgaXMgIm5vIikuIA0KICAgICAgIA0KICAgICAgQW4gZXhhbXBsZSA8aW5wdXRQb3J0cz4g ZWxlbWVudCwgZGVmaW5pbmcgdHdvIGlucHV0IHBvcnRzLCB0aGUgDQogICAgICBzZWNvbmQgb25l IGJlaW5nIGFuIGlucHV0IHBvcnQgZ3JvdXA6IA0KICAgICAgIA0KICAgICAgPGlucHV0UG9ydHM+ IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDUwXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZv ckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAg ICAgIDxpbnB1dFBvcnQ+IA0KICAgICAgICAgIDxuYW1lPmluPC9uYW1lPiANCiAgICAgICAgICA8 c3lub3BzaXM+Tm9ybWFsIGlucHV0PC9zeW5vcHNpcz4gDQogICAgICAgICAgPGV4cGVjdGF0aW9u PiANCiAgICAgICAgICAgIDxmcmFtZUV4cGVjdGVkPiANCiAgICAgICAgICAgICAgPHJlZj5pcHY0 PC9yZWY+IA0KICAgICAgICAgICAgICA8cmVmPmlwdjY8L3JlZj4gDQogICAgICAgICAgICA8L2Zy YW1lRXhwZWN0ZWQ+IA0KICAgICAgICAgICAgPG1ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAgICAg ICAgICA8cmVmPmNsYXNzaWQ8L3JlZj4gDQogICAgICAgICAgICAgIDxyZWY+dmlmaWQ8L3JlZj4g DQogICAgICAgICAgICAgIDxyZWYgZGVwZW5kZW5jeT0ib3B0aW9uYWwiIGRlZmF1bHRWYWx1ZT0i MCI+dnJmaWQ8L3JlZj4gDQogICAgICAgICAgICA8L21ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAg ICAgIDwvZXhwZWN0YXRpb24+IA0KICAgICAgICA8L2lucHV0UG9ydD4gDQogICAgICAgIDxpbnB1 dFBvcnQgZ3JvdXA9InllcyI+IA0KICAgICAgICAgIC4uLiBhbm90aGVyIGlucHV0IHBvcnQgLi4u IA0KICAgICAgICA8L2lucHV0UG9ydD4gDQogICAgICA8L2lucHV0UG9ydHM+IA0KICAgICAgIA0K ICAgICAgRm9yIGVhY2ggPGlucHV0UG9ydD4sIHRoZSBmcmFtZSB0eXBlIGV4cGVjdGF0aW9ucyBh cmUgZGVmaW5lZCBieSANCiAgICAgIHRoZSA8ZnJhbWVFeHBlY3RlZD4gZWxlbWVudCB1c2luZyBv bmUgb3IgbW9yZSA8cmVmPiBlbGVtZW50cyAoc2VlIA0KICAgICAgZXhhbXBsZSBhYm92ZSkuICBX aGVuIG11bHRpcGxlIGZyYW1lIHR5cGVzIGFyZSBsaXN0ZWQsIGl0IG1lYW5zIA0KICAgICAgdGhh dCAib25lIG9mIHRoZXNlIiBmcmFtZSB0eXBlcyBhcmUgZXhwZWN0ZWQuICBBIHBhY2tldCBvZiBh bnkgDQogICAgICBvdGhlciBmcmFtZSB0eXBlIGlzIHJlZ2FyZGVkIGFzIGluY29tcGF0aWJsZSB3 aXRoIHRoaXMgaW5wdXQgcG9ydCANCiAgICAgIG9mIHRoZSBMRkIgY2xhc3MuICBUaGUgYWJvdmUg ZXhhbXBsZSBsaXN0IHR3byBmcmFtZXMgYXMgZXhwZWN0ZWQgDQogICAgICBmcmFtZSB0eXBlczog ImlwdjQiIGFuZCAiaXB2NiIuIA0KICAgICAgIA0KICAgICAgTWV0YWRhdGEgZXhwZWN0YXRpb25z IGFyZSBzcGVjaWZpZWQgYnkgdGhlIDxtZXRhZGF0YUV4cGVjdGVkPiANCiAgICAgIGVsZW1lbnQu ICBJbiBpdHMgc2ltcGxlc3QgZm9ybSwgdGhpcyBlbGVtZW50IGNhbiBjb250YWluIGEgbGlzdCBv ZiANCiAgICAgIDxyZWY+IGVsZW1lbnRzLCBlYWNoIHJlZmVycmluZyB0byBhIG1ldGFkYXRhLiAg V2hlbiBtdWx0aXBsZSANCiAgICAgIGluc3RhbmNlcyBvZiBtZXRhZGF0YSBhcmUgbGlzdGVkIGJ5 IDxyZWY+IGVsZW1lbnRzLCBpdCBtZWFucyB0aGF0IA0KICAgICAgImFsbCBvZiB0aGVzZSIgbWV0 YWRhdGEgbXVzdCBiZSByZWNlaXZlZCB3aXRoIGVhY2ggcGFja2V0IChleGNlcHQgDQogICAgICBt ZXRhZGF0YSB0aGF0IGFyZSBtYXJrZWQgYXMgIm9wdGlvbmFsIiBieSB0aGUgImRlcGVuZGVuY3ki IA0KICAgICAgYXR0cmlidXRlIG9mIHRoZSBjb3JyZXNwb25kaW5nIDxyZWY+IGVsZW1lbnQpLiAg Rm9yIGEgbWV0YWRhdGEgDQogICAgICB0aGF0IGlzIHNwZWNpZmllZCAib3B0aW9uYWwiLCBhIGRl ZmF1bHQgdmFsdWUgbXVzdCBiZSBwcm92aWRlZCANCiAgICAgIHVzaW5nIHRoZSAiZGVmYXVsdFZh bHVlIiBhdHRyaWJ1dGUuICBUaGUgYWJvdmUgZXhhbXBsZSBsaXN0cyB0aHJlZSANCiAgICAgIG1l dGFkYXRhIGFzIGV4cGVjdGVkIG1ldGFkYXRhLCB0d28gb2Ygd2hpY2ggYXJlIG1hbmRhdG9yeSAN CiAgICAgICgiY2xhc3NpZCIgYW5kICJ2aWZpZCIpLCBhbmQgb25lIGJlaW5nIG9wdGlvbmFsICgi dnJmaWQiKS4gDQogICAgICAgDQogICAgICBbRURJVE9SOiBIb3cgdG8gZXhwcmVzcyBkZWZhdWx0 IHZhbHVlcyBmb3IgYnl0ZVtOXSBhdG9taWMgdHlwZXMgaXMgDQogICAgICB5ZXQgdG8gYmUgZGVm aW5lZC5dIA0KICAgICAgIA0KICAgICAgVGhlIHNjaGVtYSBhbHNvIGFsbG93cyBmb3IgbW9yZSBj b21wbGV4IGRlZmluaXRpb25zIG9mIG1ldGFkYXRhIA0KICAgICAgZXhwZWN0YXRpb25zLiAgRm9y IGV4YW1wbGUsIHVzaW5nIHRoZSA8b25lLW9mPiBlbGVtZW50LCBhIGxpc3Qgb2YgDQogICAgICBt ZXRhZGF0YSBjYW4gYmUgc3BlY2lmaWVkIHRvIGV4cHJlc3MgdGhhdCBhdCBsZWFzdCBvbmUgb2Yg dGhlIA0KICAgICAgc3BlY2lmaWVkIG1ldGFkYXRhIG11c3QgYmUgcHJlc2VudCB3aXRoIGFueSBw YWNrZXQuIEZvciBleGFtcGxlOiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMg QXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1MV0gDQoMICAgSW50ZXJu ZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 IA0KICAgIA0KICAgIA0KICAgICAgIA0KICAgICAgPG1ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAg ICA8b25lLW9mPiANCiAgICAgICAgICA8cmVmPnByZWZpeG1hc2s8L3JlZj4gDQogICAgICAgICAg PHJlZj5wcmVmaXhsZW48L3JlZj4gDQogICAgICAgIDwvb25lLW9mPiANCiAgICAgIDwvbWV0YWRh dGFFeHBlY3RlZD4gDQogICAgICAgDQogICAgICBUaGUgYWJvdmUgZXhhbXBsZSBzcGVjaWZpZXMg dGhhdCBlaXRoZXIgdGhlICJwcmVmaXhtYXNrIiBvciB0aGUgDQogICAgICAicHJlZml4bGVuIiBt ZXRhZGF0YSBtdXN0IGJlIHByb3ZpZGVkIHdpdGggYW55IHBhY2tldC4gDQogICAgICAgDQogICAg ICBUaGUgdHdvIGZvcm1zIGNhbiBhbHNvIGJlIGNvbWJpbmVkLCBhcyBpdCBpcyBzaG93biBpbiB0 aGUgDQogICAgICBmb2xsb3dpbmcgZXhhbXBsZTogDQogICAgICAgDQogICAgICA8bWV0YWRhdGFF eHBlY3RlZD4gDQogICAgICAgIDxyZWY+Y2xhc3NpZDwvcmVmPiANCiAgICAgICAgPHJlZj52aWZp ZDwvcmVmPiANCiAgICAgICAgPHJlZiBkZXBlbmRlbmN5PSJvcHRpb25hbCIgZGVmYXVsdFZhbHVl PSIwIj52cmZpZDwvcmVmPiANCiAgICAgICAgPG9uZS1vZj4gDQogICAgICAgICAgPHJlZj5wcmVm aXhtYXNrPC9yZWY+IA0KICAgICAgICAgIDxyZWY+cHJlZml4bGVuPC9yZWY+IA0KICAgICAgICA8 L29uZS1vZj4gDQogICAgICA8L21ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAgIA0KICAgICAgQWx0 aG91Z2ggdGhlIHNjaGVtYSBpcyBjb25zdHJ1Y3RlZCB0byBhbGxvdyBldmVuIG1vcmUgY29tcGxl eCANCiAgICAgIGRlZmluaXRpb25zIG9mIG1ldGFkYXRhIGV4cGVjdGF0aW9ucywgd2UgZG8gbm90 IGRpc2N1c3MgdGhvc2UgDQogICAgICBoZXJlLiANCiAgICANCiAgIDQuNy4zLiA8b3V0cHV0UG9y dHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBPdXRwdXRzIA0KICAgICAgIA0KICAgICAgVGhlIG9w dGlvbmFsIDxvdXRwdXRQb3J0cz4gZWxlbWVudCBpcyB1c2VkIHRvIGRlZmluZSBvdXRwdXQgDQog ICAgICBwb3J0cy4gIEFuIExGQiBjbGFzcyBtYXkgaGF2ZSB6ZXJvLCBvbmUsIG9yIG1vcmUgb3V0 cHV0cy4gIElmIHRoZSANCiAgICAgIExGQiBjbGFzcyBoYXMgbm8gb3V0cHV0IHBvcnRzLCB0aGUg PG91dHB1dFBvcnRzPiBlbGVtZW50IG11c3QgYmUgDQogICAgICBvbWl0dGVkLiAgVGhlIDxvdXRw dXRQb3J0cz4gZWxlbWVudCBjYW4gY29udGFpbiBvbmUgb3IgbW9yZSANCiAgICAgIDxvdXRwdXRQ b3J0PiBlbGVtZW50cywgb25lIGZvciBlYWNoIHBvcnQgb3IgcG9ydC1ncm91cC4gIElmIHRoZXJl IA0KICAgICAgYXJlIG11bHRpcGxlIG91dHB1dHMgd2l0aCB0aGUgc2FtZSBvdXRwdXQgdHlwZSwg d2UgbW9kZWwgdGhlbSBhcyANCiAgICAgIGFuIG91dHB1dCBwb3J0IGdyb3VwLiAgU29tZSBzcGVj aWFsIExGQnMgbWF5IGhhdmUgbm8gb3V0cHV0cyBhdCANCiAgICAgIGFsbCAoZS5nLiwgRHJvcHBl cikuIA0KICAgICAgIA0KICAgICAgU2luZ2xlIG91dHB1dCBwb3J0cyBhbmQgb3V0cHV0IHBvcnQg Z3JvdXBzIGFyZSBib3RoIGRlZmluZWQgYnkgdGhlIA0KICAgICAgPG91dHB1dFBvcnQ+IGVsZW1l bnQ7IHRoZXkgYXJlIGRpZmZlcmVudGlhdGVkIGJ5IG9ubHkgYW4gb3B0aW9uYWwgDQogICAgICAi Z3JvdXAiIGF0dHJpYnV0ZS4gDQogICAgICAgDQogICAgICBUaGUgPG91dHB1dFBvcnQ+IGVsZW1l bnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBlbGVtZW50czogDQogICAgICAuIDxuYW1lPiBwcm92 aWRlcyB0aGUgc3ltYm9saWMgbmFtZSBvZiB0aGUgb3V0cHV0LiAgRXhhbXBsZTogDQogICAgICAg ICJvdXQiLiBOb3RlIHRoYXQgdGhlIHN5bWJvbGljIG5hbWUgbXVzdCBiZSB1bmlxdWUgb25seSB3 aXRoaW4gDQogICAgICAgIHRoZSBzY29wZSBvZiB0aGUgTEZCIGNsYXNzLiANCiAgICANCiAgIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA1Ml0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgLiA8c3lub3BzaXM+ IGNvbnRhaW5zIGEgYnJpZWYgZGVzY3JpcHRpb24gb2YgdGhlIG91dHB1dCBwb3J0LiANCiAgICAg ICAgRXhhbXBsZTogIk5vcm1hbCBwYWNrZXQgb3V0cHV0Ii4gDQogICAgICAuIDxwcm9kdWN0PiBs aXN0cyB0aGUgYWxsb3dlZCBmcmFtZSBmb3JtYXRzLiAgRXhhbXBsZTogeyJpcHY0IiwgDQogICAg ICAgICJpcHY2In0uICBOb3RlIHRoYXQgdGhpcyBsaXN0IHNob3VsZCByZWZlciB0byBzeW1ib2xz IHNwZWNpZmllZCANCiAgICAgICAgaW4gdGhlIDxmcmFtZURlZnM+IGVsZW1lbnQgaW4gdGhlIHNh bWUgbGlicmFyeSBkb2N1bWVudCBvciBpbiANCiAgICAgICAgYW55IGluY2x1ZGVkIGxpYnJhcnkg ZG9jdW1lbnRzLiAgVGhlIDxwcm9kdWN0PiBlbGVtZW50IG1heSBhbHNvIA0KICAgICAgICBjb250 YWluIHRoZSBsaXN0IG9mIGVtaXR0ZWQgKGdlbmVyYXRlZCkgbWV0YWRhdGEuICBFeGFtcGxlOiAN CiAgICAgICAgeyJjbGFzc2lkIiwgImNvbG9yIn0uICBUaGlzIGxpc3Qgc2hvdWxkIHJlZmVyIHRv IG5hbWVzIG9mIA0KICAgICAgICBtZXRhZGF0YSBzcGVjaWZpZWQgaW4gdGhlIDxtZXRhZGF0YURl ZnM+IGVsZW1lbnQgaW4gdGhlIHNhbWUgDQogICAgICAgIGxpYnJhcnkgZG9jdW1lbnQgb3IgaW4g YW55IGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAgRm9yIA0KICAgICAgICBlYWNoIGdlbmVy YXRlZCBtZXRhZGF0YSwgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCB3aGV0aGVyIHRoZSANCiAgICAg ICAgbWV0YWRhdGEgaXMgYWx3YXlzIGdlbmVyYXRlZCBvciBnZW5lcmF0ZWQgb25seSBpbiBjZXJ0 YWluIA0KICAgICAgICBjb25kaXRpb25zLiBUaGlzIGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCB3 aGVuIGFzc2Vzc2luZyANCiAgICAgICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIExGQnMuIA0KICAg ICAgIA0KICAgICAgSW4gYWRkaXRpb24sIHRoZSBvcHRpb25hbCAiZ3JvdXAiIGF0dHJpYnV0ZSBv ZiB0aGUgPG91dHB1dFBvcnQ+IA0KICAgICAgZWxlbWVudCBjYW4gc3BlY2lmeSBpZiB0aGUgcG9y dCBjYW4gYmVoYXZlIGFzIGEgcG9ydCBncm91cCwgaS5lLiwgDQogICAgICBpdCBpcyBhbGxvd2Vk IHRvIGJlIGluc3RhbnRpYXRlZC4gVGhpcyBpcyBpbmRpY2F0ZWQgYnkgYSAieWVzIiANCiAgICAg IHZhbHVlICh0aGUgZGVmYXVsdCB2YWx1ZSBpcyAibm8iKS4gDQogICAgICAgDQogICAgICBUaGUg Zm9sbG93aW5nIGV4YW1wbGUgc3BlY2lmaWVzIHR3byBvdXRwdXQgcG9ydHMsIHRoZSBzZWNvbmQg YmVpbmcgDQogICAgICBhbiBvdXRwdXQgcG9ydCBncm91cDogDQogICAgICAgDQogICAgICA8b3V0 cHV0UG9ydHM+IA0KICAgICAgICA8b3V0cHV0UG9ydD4gDQogICAgICAgICAgPG5hbWU+b3V0PC9u YW1lPiANCiAgICAgICAgICA8c3lub3BzaXM+Tm9ybWFsIG91dHB1dDwvc3lub3BzaXM+IA0KICAg ICAgICAgIDxwcm9kdWN0PiANCiAgICAgICAgICAgIDxmcmFtZVByb2R1Y2VkPiANCiAgICAgICAg ICAgICAgPHJlZj5pcHY0PC9yZWY+IA0KICAgICAgICAgICAgICA8cmVmPmlwdjRiaXM8L3JlZj4g DQogICAgICAgICAgICA8L2ZyYW1lUHJvZHVjZWQ+IA0KICAgICAgICAgICAgPG1ldGFkYXRhUHJv ZHVjZWQ+IA0KICAgICAgICAgICAgICA8cmVmPm5oaWQ8L3JlZj4gDQogICAgICAgICAgICAgIDxy ZWY+bmh0YWJpZDwvcmVmPiANCiAgICAgICAgICAgIDwvbWV0YWRhdGFQcm9kdWNlZD4gDQogICAg ICAgICAgPC9wcm9kdWN0PiANCiAgICAgICAgPC9vdXRwdXRQb3J0PiAgIA0KICAgICAgICA8b3V0 cHV0UG9ydCBncm91cD0ieWVzIj4gDQogICAgICAgICAgPG5hbWU+ZXhjPC9uYW1lPiANCiAgICAg ICAgICA8c3lub3BzaXM+RXhjZXB0aW9uIG91dHB1dCBwb3J0IGdyb3VwPC9zeW5vcHNpcz4gDQog ICAgICAgICAgPHByb2R1Y3Q+IA0KICAgICAgICAgICAgPGZyYW1lUHJvZHVjZWQ+IA0KICAgICAg ICAgICAgICA8cmVmPmlwdjQ8L3JlZj4gDQogICAgICAgICAgICAgIDxyZWY+aXB2NGJpczwvcmVm PiANCiAgICAgICAgICAgIDwvZnJhbWVQcm9kdWNlZD4gDQogICAgICAgICAgICA8bWV0YWRhdGFQ cm9kdWNlZD4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNTNdIA0KDCAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAg ICANCiAgICAgICAgICAgICAgPHJlZiBhdmFpbGFiaWxpdHk9ImNvbmRpdGlvbmFsIj5lcnJvcmlk PC9yZWY+IA0KICAgICAgICAgICAgPC9tZXRhZGF0YVByb2R1Y2VkPiANCiAgICAgICAgICA8L3By b2R1Y3Q+IA0KICAgICAgICA8L291dHB1dFBvcnQ+IA0KICAgICAgPC9vdXRwdXRQb3J0cz4gDQog ICAgICAgDQogICAgICBUaGUgdHlwZXMgb2YgZnJhbWVzIGFuZCBtZXRhZGF0YSB0aGUgcG9ydCBw cm9kdWNlcyBhcmUgZGVmaW5lZCANCiAgICAgIGluc2lkZSB0aGUgPHByb2R1Y3Q+IGVsZW1lbnQg aW4gZWFjaCA8b3V0cHV0UG9ydD4uICBXaXRoaW4gdGhlIA0KICAgICAgPHByb2R1Y3Q+IGVsZW1l bnQsIHRoZSBsaXN0IG9mIGZyYW1lIHR5cGVzIHRoZSBwb3J0IHByb2R1Y2VzIGlzIA0KICAgICAg bGlzdGVkIGluIHRoZSA8ZnJhbWVQcm9kdWNlZD4gZWxlbWVudC4gIFdoZW4gbW9yZSB0aGFuIG9u ZSBmcmFtZSANCiAgICAgIGlzIGxpc3RlZCwgaXQgbWVhbnMgdGhhdCAib25lIG9mIiB0aGVzZSBm cmFtZXMgd2lsbCBiZSBwcm9kdWNlZC4gDQogICAgICAgDQogICAgICBUaGUgbGlzdCBvZiBtZXRh ZGF0YSB0aGF0IGlzIHByb2R1Y2VkIHdpdGggZWFjaCBwYWNrZXQgaXMgbGlzdGVkIA0KICAgICAg aW4gdGhlIG9wdGlvbmFsIDxtZXRhZGF0YVByb2R1Y2VkPiBlbGVtZW50IG9mIHRoZSA8cHJvZHVj dD4uICBJbiANCiAgICAgIGl0cyBzaW1wbGVzdCBmb3JtLCB0aGlzIGVsZW1lbnQgY2FuIGNvbnRh aW4gYSBsaXN0IG9mIDxyZWY+IA0KICAgICAgZWxlbWVudHMsIGVhY2ggcmVmZXJyaW5nIHRvIGEg bWV0YWRhdGEgdHlwZS4gIFRoZSBtZWFuaW5nIG9mIHN1Y2ggDQogICAgICBhIGxpc3QgaXMgdGhh dCAiYWxsIG9mIiB0aGVzZSBtZXRhZGF0YSBhcmUgcHJvdmlkZWQgd2l0aCBlYWNoIA0KICAgICAg cGFja2V0LCBleGNlcHQgdGhvc2UgdGhhdCBhcmUgbGlzdGVkIHdpdGggdGhlIG9wdGlvbmFsIA0K ICAgICAgImF2YWlsYWJpbGl0eSIgYXR0cmlidXRlIHNldCB0byAiY29uZGl0aW9uYWwiLiAgU2lt aWxhciB0byB0aGUgDQogICAgICA8bWV0YWRhdGFFeHBlY3RlZD4gZWxlbWVudCBvZiB0aGUgPGlu cHV0UG9ydD4sIHRoZSANCiAgICAgIDxtZXRhZGF0YVByb2R1Y2VkPiBlbGVtZW50IHN1cHBvcnRz IG1vcmUgY29tcGxleCBmb3Jtcywgd2hpY2ggd2UgDQogICAgICBkbyBub3QgZGlzY3VzcyBoZXJl IGZ1cnRoZXIuIA0KICAgIA0KICAgNC43LjQuIDxhdHRyaWJ1dGVzPiBFbGVtZW50IHRvIERlZmlu ZSBMRkIgT3BlcmF0aW9uYWwgQXR0cmlidXRlcyANCiAgICAgICAgIA0KICAgICAgT3BlcmF0aW9u YWwgcGFyYW1ldGVycyBvZiB0aGUgTEZCcyB0aGF0IG11c3QgYmUgdmlzaWJsZSB0byB0aGUgQ0Vz IA0KICAgICAgYXJlIGNvbmNlcHR1YWxpemVkIGluIHRoZSBtb2RlbCBhcyB0aGUgTEZCIGF0dHJp YnV0ZXMuICBUaGVzZSANCiAgICAgIGluY2x1ZGUsIGZvciBleGFtcGxlLCBmbGFncywgc2luZ2xl IHBhcmFtZXRlciBhcmd1bWVudHMsIGNvbXBsZXggDQogICAgICBhcmd1bWVudHMsIGFuZCB0YWJs ZXMuICBOb3RlIHRoYXQgdGhlIGF0dHJpYnV0ZXMgaGVyZSByZWZlciB0byANCiAgICAgIG9ubHkg dGhvc2Ugb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBvZiB0aGUgTEZCcyB0aGF0IG11c3QgYmUgdmlz aWJsZSANCiAgICAgIHRvIHRoZSBDRXMuICBPdGhlciB2YXJpYWJsZXMgdGhhdCBhcmUgaW50ZXJu YWwgdG8gTEZCIA0KICAgICAgaW1wbGVtZW50YXRpb24gYXJlIG5vdCByZWdhcmRlZCBhcyBMRkIg YXR0cmlidXRlcyBhbmQgaGVuY2UgYXJlIA0KICAgICAgbm90IGNvdmVyZWQuIA0KICAgICAgIA0K ICAgICAgU29tZSBleGFtcGxlcyBmb3IgTEZCIGF0dHJpYnV0ZXMgYXJlOiANCiAgICAgICAgLiBD b25maWd1cmFibGUgZmxhZ3MgYW5kIHN3aXRjaGVzIHNlbGVjdGluZyBiZXR3ZWVuIG9wZXJhdGlv bmFsIA0KICAgICAgICAgICBtb2RlcyBvZiB0aGUgTEZCIA0KICAgICAgICAuIE51bWJlciBvZiBp bnB1dHMgb3Igb3VwdXRzIGluIGEgcG9ydCBncm91cCANCiAgICAgICAgLiBNZXRhZGF0YSBDT05T VU1FIHZzLiBQUk9QQUdBVEUgbW9kZSBzZWxlY3RvcnMgDQogICAgICAgIC4gVmFyaW91cyBjb25m aWd1cmFibGUgbG9va3VwIHRhYmxlcywgaW5jbHVkaW5nIGludGVyZmFjZSANCiAgICAgICAgICAg dGFibGVzLCBwcmVmaXggdGFibGVzLCBjbGFzc2lmaWNhdGlvbiB0YWJsZXMsIERTQ1AgbWFwcGlu ZyANCiAgICAgICAgICAgdGFibGVzLCBNQUMgYWRkcmVzcyB0YWJsZXMsIGV0Yy4gDQogICAgICAg IC4gUGFja2V0IGFuZCBieXRlIGNvdW50ZXJzIA0KICAgICAgICAuIFZhcmlvdXMgZXZlbnQgY291 bnRlcnMgDQogICAgICAgIC4gTnVtYmVyIG9mIGN1cnJlbnQgaW5wdXRzIG9yIG91dHB1dHMgZm9y IGVhY2ggaW5wdXQgb3Igb3V0cHV0IA0KICAgICAgICAgICBncm91cCANCiAgICAgICAgLiBNZXRh ZGF0YSBDT05TVU1FL1BST1BBR0FURSBtb2RlIHNlbGVjdG9yIA0KICAgIA0KICAgWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDU0XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAg ICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgDQogICAgICBUaGVyZSBtYXkg YmUgdmFyaW91cyBhY2Nlc3MgcGVybWlzc2lvbiByZXN0cmljdGlvbnMgb24gd2hhdCB0aGUgQ0Ug DQogICAgICBjYW4gZG8gd2l0aCBhbiBMRkIgYXR0cmlidXRlLiAgVGhlIGZvbGxvd2luZyBjYXRl Z29yaWVzIG1heSBiZSANCiAgICAgIHN1cHBvcnRlZDogDQogICAgICAgIC4gTm8tYWNjZXNzIGF0 dHJpYnV0ZXMuICBUaGlzIGlzIHVzZWZ1bCB3aGVuIG11bHRpcGxlIGFjY2VzcyANCiAgICAgICAg ICAgbW9kZXMgbWF5YmUgZGVmaW5lZCBmb3IgYSBnaXZlbiBhdHRyaWJ1dGUgdG8gYWxsb3cgc29t ZSANCiAgICAgICAgICAgZmxleGliaWxpdHkgZm9yIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMu IA0KICAgICAgICAuIFJlYWQtb25seSBhdHRyaWJ1dGVzLiANCiAgICAgICAgLiBSZWFkLXdyaXRl IGF0dHJpYnV0ZXMuIA0KICAgICAgICAuIFdyaXRlLW9ubHkgYXR0cmlidXRlcy4gIFRoaXMgY291 bGQgYmUgYW55IGNvbmZpZ3VyYWJsZSBkYXRhIA0KICAgICAgICAgICBmb3Igd2hpY2ggcmVhZCBj YXBhYmlsaXR5IGlzIG5vdCBwcm92aWRlZCB0byB0aGUgQ0VzLiAgKGUuZy4sIA0KICAgICAgICAg ICB0aGUgc2VjdXJpdHkga2V5IGluZm9ybWF0aW9uKSANCiAgICAgICAgLiBSZWFkLXJlc2V0IGF0 dHJpYnV0ZXMuICBUaGUgQ0UgY2FuIHJlYWQgYW5kIHJlc2V0IHRoaXMgDQogICAgICAgICAgIHJl c291cmNlLCBidXQgY2Fubm90IHNldCBpdCB0byBhbiBhcmJpdHJhcnkgdmFsdWUuICBFeGFtcGxl OiANCiAgICAgICAgICAgQ291bnRlcnMuIA0KICAgICAgICAuIEZpcmluZy1vbmx5IGF0dHJpYnV0 ZXMuICBBIHdyaXRlIGF0dGVtcHQgdG8gdGhpcyByZXNvdXJjZSANCiAgICAgICAgICAgd2lsbCB0 cmlnZ2VyIHNvbWUgc3BlY2lmaWMgYWN0aW9ucyBpbiB0aGUgTEZCLCBidXQgdGhlIGFjdHVhbCAN CiAgICAgICAgICAgdmFsdWUgd3JpdHRlbiBpcyBpZ25vcmVkLiAgIA0KICAgICAgIA0KICAgICAg VGhlIExGQiBjbGFzcyBtYXkgZGVmaW5lIG1vcmUgdGhhbiBvbmUgcG9zc2libGUgYWNjZXNzIG1v ZGUgZm9yIGEgDQogICAgICBnaXZlbiBhdHRyaWJ1dGUgKGZvciBleGFtcGxlLCAid3JpdGUtb25s eSIgYW5kICJyZWFkLXdyaXRlIiksIGluIA0KICAgICAgd2hpY2ggY2FzZSBpdCBpcyBsZWZ0IHRv IHRoZSBhY3R1YWwgaW1wbGVtZW50YXRpb24gdG8gcGljayBvbmUgb2YgDQogICAgICB0aGUgbW9k ZXMuICBJbiBzdWNoIGNhc2VzIGEgY29ycmVzcG9uZGluZyBjYXBhYmlsaXR5IGF0dHJpYnV0ZSAN CiAgICAgIG11c3QgaW5mb3JtIHRoZSBDRSBhYm91dCB0aGUgYWNjZXNzIG1vZGUgdGhlIGFjdHVh bCBMRkIgaW5zdGFuY2UgDQogICAgICBzdXBwb3J0cyAoc2VlIG5leHQgc3Vic2VjdGlvbiBvbiBj YXBhYmlsaXR5IGF0dHJpYnV0ZXMpLiANCiAgICAgICANCiAgICAgIFRoZSBhdHRyaWJ1dGVzIG9m IHRoZSBMRkIgY2xhc3MgYXJlIGxpc3RlZCBpbiB0aGUgPGF0dHJpYnV0ZXM+IA0KICAgICAgZWxl bWVudC4gIEVhY2ggYXR0cmlidXRlIGlzIGRlZmluZWQgYnkgYW4gPGF0dHJpYnV0ZT4gZWxlbWVu dC4gIEFuIA0KICAgICAgPGF0dHJpYnV0ZT4gZWxlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5n IGVsZW1lbnRzOiANCiAgICAgICAgLiA8bmFtZT4gZGVmaW5lcyB0aGUgbmFtZSBvZiB0aGUgYXR0 cmlidXRlLiAgVGhpcyBuYW1lIG11c3QgYmUgDQogICAgICAgICAgIHVuaXF1ZSBhbW9uZyB0aGUg YXR0cmlidXRlcyBvZiB0aGUgTEZCIGNsYXNzLiAgRXhhbXBsZTogDQogICAgICAgICAgICJ2ZXJz aW9uIi4gIA0KICAgICAgICAuIDxzeW5vcHNpcz4gc2hvdWxkIHByb3ZpZGUgYSBicmllZiBkZXNj cmlwdGlvbiBvZiB0aGUgcHVycG9zZSANCiAgICAgICAgICAgb2YgdGhlIGF0dHJpYnV0ZS4gDQog ICAgICAgIC4gVGhlIGRhdGEgdHlwZSBvZiB0aGUgYXR0cmlidXRlIGNhbiBiZSBkZWZpbmVkIGVp dGhlciB2aWEgYSANCiAgICAgICAgICAgcmVmZXJlbmNlIHRvIGEgcHJlZGVmaW5lZCBkYXRhIHR5 cGUgb3IgcHJvdmlkaW5nIGEgbG9jYWwgDQogICAgICAgICAgIGRlZmluaXRpb24gb2YgdGhlIHR5 cGUuICBUaGUgZm9ybWVyIGlzIHByb3ZpZGVkIGJ5IHVzaW5nIHRoZSANCiAgICAgICAgICAgPHR5 cGVSZWY+IGVsZW1lbnQsIHdoaWNoIG11c3QgcmVmZXIgdG8gdGhlIHVuaXF1ZSBuYW1lIG9mIGFu IA0KICAgICAgICAgICBleGlzdGluZyBkYXRhIHR5cGUgZGVmaW5lZCBpbiB0aGUgPGRhdGFUeXBl RGVmcz4gZWxlbWVudCBpbiANCiAgICAgICAgICAgdGhlIHNhbWUgbGlicmFyeSBkb2N1bWVudCBv ciBpbiBhbnkgb2YgdGhlIGluY2x1ZGVkIGxpYnJhcnkgDQogICAgICAgICAgIGRvY3VtZW50cy4g IFdoZW4gdGhlIGRhdGEgdHlwZSBpcyBkZWZpbmVkIGxvY2FsbHkgKHVubmFtZWQgDQogICAgICAg ICAgIHR5cGUpLCBvbmUgb2YgdGhlIGZvbGxvd2luZyBlbGVtZW50cyBjYW4gYmUgdXNlZDogPGF0 b21pYz4sIA0KICAgICAgICAgICA8YXJyYXk+LCA8c3RydWN0PiwgYW5kIDx1bmlvbj4uIFRoZWly IHVzYWdlIGlzIGlkZW50aWNhbCB0byANCiAgICAgICAgICAgaG93IHRoZXkgYXJlIHVzZWQgaW5z aWRlIDxkYXRhVHlwZURlZj4gZWxlbWVudHMgKHNlZSBTZWN0aW9uIA0KICAgICAgICAgICA0LjUp LiANCiAgICAgICAgLiBUaGUgb3B0aW9uYWwgPGRlZmF1bHRWYWx1ZT4gZWxlbWVudCBjYW4gc3Bl Y2lmeSBhIGRlZmF1bHQgDQogICAgICAgICAgIHZhbHVlIGZvciB0aGUgYXR0cmlidXRlLCB3aGlj aCBpcyBhcHBsaWVkIHdoZW4gdGhlIExGQiBpcyANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAg IEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1NV0gDQoM ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICBpbml0aWFsaXplZCBvciByZXNldC4g IFtFRElUT1I6IEEgY29udmVudGlvbiB0byBkZWZpbmUgDQogICAgICAgICAgIGRlZmF1bHQgdmFs dWVzIGZvciBjb21wb3VuZCBkYXRhIHR5cGVzIGFuZCBieXRlW05dIGF0b21pYyANCiAgICAgICAg ICAgdHlwZXMgaXMgeWV0IHRvIGJlIGRlZmluZWQuXSANCiAgICAgICANCiAgICAgIEluIGFkZGl0 aW9uIHRvIHRoZSBhYm92ZSBlbGVtZW50cywgdGhlIDxhdHRyaWJ1dGU+IGVsZW1lbnQgDQogICAg ICBpbmNsdWRlcyBhbiBvcHRpb25hbCAiYWNjZXNzIiBhdHRyaWJ1dGUsIHdoaWNoIGNhbiB0YWtl IGFueSBvZiB0aGUgDQogICAgICBmb2xsb3dpbmcgdmFsdWVzIG9yIGV2ZW4gYSBsaXN0IG9mIHRo ZXNlIHZhbHVlczogInJlYWQtb25seSIsIA0KICAgICAgInJlYWQtd3JpdGUiLCAid3JpdGUtb25s eSIsICJyZWFkLXJlc2V0IiwgYW5kICJ0cmlnZ2VyLW9ubHkiLiBUaGUgDQogICAgICBkZWZhdWx0 IGFjY2VzcyBtb2RlIGlzICJyZWFkLXdyaXRlIi4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93 aW5nIGV4YW1wbGUgZGVmaW5lcyB0d28gYXR0cmlidXRlcyBmb3IgYW4gTEZCOiANCiAgICAgICAN CiAgICAgIDxhdHRyaWJ1dGVzPiANCiAgICAgICAgPGF0dHJpYnV0ZSBhY2Nlc3M9InJlYWQtb25s eSI+IA0KICAgICAgICAgIDxuYW1lPmZvbzwvbmFtZT4gDQogICAgICAgICAgPHN5bm9wc2lzPm51 bWJlciBvZiB0aGluZ3M8L3N5bm9wc2lzPiANCiAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5 cGVSZWY+IA0KICAgICAgICA8L2F0dHJpYnV0ZT4gDQogICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNz PSJyZWFkLXdyaXRlIHdyaXRlLW9ubHkiPiANCiAgICAgICAgICA8bmFtZT5iYXI8L25hbWU+IA0K ICAgICAgICAgIDxzeW5vcHNpcz5udW1iZXIgb2YgdGhpcyBvdGhlciB0aGluZzwvc3lub3BzaXM+ IA0KICAgICAgICAgIDxhdG9taWM+IA0KICAgICAgICAgICAgPGJhc2VUeXBlPnVpbnQzMjwvYmFz ZVR5cGU+IA0KICAgICAgICAgICAgPHJhbmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAgICAgICA8 YWxsb3dlZFJhbmdlIG1pbj0iMTAiIG1heD0iMjAwMCIvPiANCiAgICAgICAgICAgIDwvcmFuZ2VS ZXN0cmljdGlvbj4gDQogICAgICAgICAgPC9hdG9taWM+IA0KICAgICAgICAgIDxkZWZhdWx0VmFs dWU+MTA8L2RlZmF1bHRWYWx1ZT4gDQogICAgICAgIDwvYXR0cmlidXRlPiANCiAgICAgIDwvYXR0 cmlidXRlcz4gDQogICAgICAgDQogICAgICBUaGUgZmlyc3QgYXR0cmlidXRlICgiZm9vIikgaXMg YSByZWFkLW9ubHkgMzItYml0IHVuc2lnbmVkIA0KICAgICAgaW50ZWdlciwgZGVmaW5lZCBieSBy ZWZlcnJpbmcgdG8gdGhlIGJ1aWx0LWluICJ1aW50MzIiIGF0b21pYyANCiAgICAgIHR5cGUuICBU aGUgc2Vjb25kIGF0dHJpYnV0ZSAoImJhciIpIGlzIGFsc28gYW4gaW50ZWdlciwgYnV0IHVzZXMg DQogICAgICB0aGUgPGF0b21pYz4gZWxlbWVudCB0byBwcm92aWRlIGFkZGl0aW9uYWwgcmFuZ2Ug cmVzdHJpY3Rpb25zLiANCiAgICAgIFRoaXMgYXR0cmlidXRlIGhhcyB0d28gcG9zc2libGUgYWNj ZXNzIG1vZGVzLCAicmVhZC13cml0ZSIgb3IgDQogICAgICAid3JpdGUtb25seSIuICBBIGRlZmF1 bHQgdmFsdWUgb2YgMTAgaXMgcHJvdmlkZWQuIA0KICAgICAgIA0KICAgICAgTm90ZSB0aGF0IG5v dCBhbGwgYXR0cmlidXRlcyBhcmUgbGlrZWx5IHRvIGV4aXN0IGF0IGFsbCB0aW1lcyBpbiBhIA0K ICAgICAgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbi4gIFdoaWxlIHRoZSBjYXBhYmlsaXRpZXMg d2lsbCBmcmVxdWVudGx5IA0KICAgICAgaW5kaWNhdGUgdGhpcyBub24tZXhpc3RlbmNlLCBDRXMg bWF5IGF0dGVtcHQgdG8gcmVmZXJlbmNlIG5vbi0NCiAgICAgIGV4aXN0ZW50IG9yIG5vbi1wZXJt aXR0ZWQgYXR0cmlidXRlcyBhbnl3YXkuICBUaGUgRk9SQ0VTIHByb3RvY29sIA0KICAgICAgbWVj aGFuaXNtcyBzaG91bGQgaW5jbHVkZSBhcHByb3ByaWF0ZSBlcnJvciBpbmRpY2F0b3JzIGZvciB0 aGlzIA0KICAgICAgY2FzZS4gDQogICAgICAgDQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDU2XSAN CgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAg QXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBUaGUgbWVjaGFuaXNtIGRlZmluZWQgYWJv dmUgZm9yIG5vbi1zdXBwb3J0ZWQgYXR0cmlidXRlcyBjYW4gYWxzbyANCiAgICAgIGFwcGx5IHRv IGF0dGVtcHRzIHRvIHJlZmVyZW5jZSBub24tZXhpc3RlbnQgYXJyYXkgZWxlbWVudHMgb3IgdG8g DQogICAgICBzZXQgcmVhZC1vbmx5IGVsZW1lbnRzLiANCiAgICAgIA0KICAgNC43LjUuIDxjYXBh YmlsaXRpZXM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBDYXBhYmlsaXR5IEF0dHJpYnV0ZXMgDQog ICAgICAgICANCiAgICAgIFRoZSBMRkIgY2xhc3Mgc3BlY2lmaWNhdGlvbiB3aWxsIHByb3ZpZGUg c29tZSBmbGV4aWJpbGl0eSBmb3IgdGhlIA0KICAgICAgRkUgaW1wbGVtZW50YXRpb24gcmVnYXJk aW5nIGhvdyB0aGUgTEZCIGNsYXNzIGlzIGltcGxlbWVudGVkLiAgRm9yIA0KICAgICAgZXhhbXBs ZSwgdGhlIGNsYXNzIG1heSBkZWZpbmUgc29tZSBvcHRpb25hbCBmZWF0dXJlcywgaW4gd2hpY2gg DQogICAgICBjYXNlIHRoZSBhY3R1YWwgaW1wbGVtZW50YXRpb24gbWF5IG9yIG1heSBub3QgcHJv dmlkZSB0aGUgZ2l2ZW4gDQogICAgICBmZWF0dXJlLiAgSW4gdGhlc2UgY2FzZXMgdGhlIENFIG11 c3QgYmUgYWJsZSB0byBxdWVyeSB0aGUgTEZCIA0KICAgICAgaW5zdGFuY2UgYWJvdXQgdGhlIGF2 YWlsYWJpbGl0eSBvZiB0aGUgZmVhdHVyZS4gIEluIGFkZGl0aW9uLCB0aGUgDQogICAgICBpbnN0 YW5jZSBtYXkgaGF2ZSBzb21lIGxpbWl0YXRpb25zIHRoYXQgYXJlIG5vdCBpbmhlcmVudCBmcm9t IHRoZSANCiAgICAgIGNsYXNzIGRlZmluaXRpb24sIGJ1dCByYXRoZXIgdGhlIHJlc3VsdCBvZiBz b21lIGltcGxlbWVudGF0aW9uIA0KICAgICAgbGltaXRhdGlvbnMuICBGb3IgZXhhbXBsZSwgYW4g YXJyYXkgYXR0cmlidXRlIG1heSBiZSBkZWZpbmVkIGluIA0KICAgICAgdGhlIGNsYXNzIGRlZmlu aXRpb24gYXMgInVubGltaXRlZCIgc2l6ZSwgYnV0IHRoZSBwaHlzaWNhbCANCiAgICAgIGltcGxl bWVudGF0aW9uIG1heSBpbXBvc2UgYSBoYXJkIGxpbWl0IG9uIHRoZSBzaXplIG9mIHRoZSBhcnJh eS4gIA0KICAgICAgIA0KICAgICAgU3VjaCBjYXBhYmlsaXR5IHJlbGF0ZWQgaW5mb3JtYXRpb24g aXMgZXhwcmVzc2VkIGJ5IHRoZSBjYXBhYmlsaXR5IA0KICAgICAgYXR0cmlidXRlcyBvZiB0aGUg TEZCIGNsYXNzLiAgVGhlIGNhcGFiaWxpdHkgYXR0cmlidXRlcyBhcmUgYWx3YXlzIA0KICAgICAg cmVhZC1vbmx5IGF0dHJpYnV0ZXMsIGFuZCB0aGV5IGFyZSBsaXN0ZWQgaW4gYSBzZXBhcmF0ZSAN CiAgICAgIDxjYXBhYmlsaXRpZXM+IGVsZW1lbnQgaW4gdGhlIDxMRkJDbGFzc0RlZj4uICBUaGUg PGNhcGFiaWxpdGllcz4gDQogICAgICBlbGVtZW50IGNvbnRhaW5zIG9uZSBvciBtb3JlIDxjYXBh YmlsaXR5PiBlbGVtZW50cywgZWFjaCBkZWZpbmluZyANCiAgICAgIG9uZSBjYXBhYmlsaXR5IGF0 dHJpYnV0ZS4gIFRoZSBmb3JtYXQgb2YgdGhlIDxjYXBhYmlsaXR5PiBlbGVtZW50IA0KICAgICAg aXMgYWxtb3N0IHRoZSBzYW1lIGFzIHRoZSA8YXR0cmlidXRlPiBlbGVtZW50LCBpdCBkaWZmZXJz IGluIHR3byANCiAgICAgIGFzcGVjdHM6IGl0IGxhY2tzIHRoZSBhY2Nlc3MgbW9kZSBhdHRyaWJ1 dGUgKGJlY2F1c2UgaXQgaXMgYWx3YXlzIA0KICAgICAgcmVhZC1vbmx5KSwgYW5kIGl0IGxhY2tz IHRoZSA8ZGVmYXVsdFZhbHVlPiBlbGVtZW50IChiZWNhdXNlIA0KICAgICAgZGVmYXVsdCB2YWx1 ZSBpcyBub3QgYXBwbGljYWJsZSB0byByZWFkLW9ubHkgYXR0cmlidXRlcykuICANCiAgICAgICAN CiAgICAgIFNvbWUgZXhhbXBsZXMgb2YgY2FwYWJpbGl0eSBhdHRyaWJ1dGVzOiANCiAgICAgICAg LiBUaGUgdmVyc2lvbiBvZiB0aGUgTEZCIGNsYXNzIHRoYXQgdGhpcyBMRkIgaW5zdGFuY2UgY29t cGxpZXMgDQogICAgICAgICAgIHdpdGg7IA0KICAgICAgICAuIFN1cHBvcnRlZCBvcHRpb25hbCBm ZWF0dXJlcyBvZiB0aGUgTEZCIGNsYXNzOyANCiAgICAgICAgLiBNYXhpbXVtIG51bWJlciBvZiBj b25maWd1cmFibGUgb3V0cHV0cyBmb3IgYW4gb3V0cHV0IGdyb3VwOyANCiAgICAgICAgLiBNZXRh ZGF0YSBwYXNzLXRocm91Z2ggbGltaXRhdGlvbnMgb2YgdGhlIExGQjsgDQogICAgICAgIC4gTWF4 aW11bSBzaXplIG9mIGNvbmZpZ3VyYWJsZSBhdHRyaWJ1dGUgdGFibGVzOyANCiAgICAgICAgLiBB ZGRpdGlvbmFsIHJhbmdlIHJlc3RyaWN0aW9uIG9uIG9wZXJhdGlvbmFsIGF0dHJpYnV0ZXM7IA0K ICAgICAgICAuIFN1cHBvcnRlZCBhY2Nlc3MgbW9kZXMgb2YgY2VydGFpbiBhdHRyaWJ1dGVzIChp ZiB0aGUgYWNjZXNzIA0KICAgICAgICAgICBtb2RlIG9mIGFuIG9wZXJhdGlvbmFsIGF0dHJpYnV0 ZSBpcyBzcGVjaWZpZWQgYXMgYSBsaXN0IG9mIA0KICAgICAgICAgICB0d28gb3IgbW9kZSBtb2Rl cykuIA0KICAgICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGxpc3RzIHR3byBjYXBh YmlsaXR5IGF0dHJpYnV0ZXM6IA0KICAgICAgIA0KICAgICAgPGNhcGFiaWxpdGllcz4gDQogICAg ICAgIDxjYXBhYmlsaXR5PiANCiAgICAgICAgICA8bmFtZT52ZXJzaW9uPC9uYW1lPiANCiAgICAg ICAgICA8c3lub3BzaXM+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDU3XSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICAgICAgICBMRkIgY2xhc3MgdmVyc2lvbiB0aGlzIGluc3RhbmNlIGlz IGNvbXBsaWFudCB3aXRoLiANCiAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICA8dHlw ZVJlZj52ZXJzaW9uPC90eXBlUmVmPiANCiAgICAgICAgPC9jYXBhYmlsaXR5PiANCiAgICAgICAg PGNhcGFiaWxpdHk+IA0KICAgICAgICAgIDxuYW1lPmxpbWl0QmFyPC9uYW1lPiANCiAgICAgICAg ICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgTWF4aW11bSB2YWx1ZSBvZiB0aGUgImJhciIgYXR0 cmlidXRlLiANCiAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICA8dHlwZVJlZj51aW50 MTY8L3R5cGVSZWY+IA0KICAgICAgICA8L2NhcGFiaWxpdHk+ICANCiAgICAgIDwvY2FwYWJpbGl0 aWVzPiANCiAgICANCiAgIDQuNy42LiA8ZGVzY3JpcHRpb24+IEVsZW1lbnQgZm9yIExGQiBPcGVy YXRpb25hbCBTcGVjaWZpY2F0aW9uIA0KICAgICAgIA0KICAgICAgVGhlIDxkZXNjcmlwdGlvbj4g ZWxlbWVudCBvZiB0aGUgPExGQkNsYXNzPiBwcm92aWRlcyB1bnN0cnVjdHVyZWQgDQogICAgICB0 ZXh0IChpbiBYTUwgc2Vuc2UpIHRvIHZlcmJhbGx5IGRlc2NyaWJlIHdoYXQgdGhlIExGQiBkb2Vz LiAgIA0KICAgIA0KICAgNC44LiBYTUwgU2NoZW1hIGZvciBMRkIgQ2xhc3MgTGlicmFyeSBEb2N1 bWVudHMgDQogICAgICAgDQogICAgICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYt OCI/PiANCiAgICAgIDx4c2Q6c2NoZW1hIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAw MS9YTUxTY2hlbWEiIA0KICAgICAgIHhtbG5zPSJodHRwOi8vaWV0Zi5vcmcvZm9yY2VzLzEuMC9s ZmJtb2RlbCIgDQogICAgICAgeG1sbnM6bGZiPSJodHRwOi8vaWV0Zi5vcmcvZm9yY2VzLzEuMC9s ZmJtb2RlbCIgDQogICAgICAgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vaWV0Zi5vcmcvZm9yY2Vz LzEuMC9sZmJtb2RlbCIgDQogICAgICAgYXR0cmlidXRlRm9ybURlZmF1bHQ9InVucXVhbGlmaWVk IiANCiAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCI+IA0KICAgICAgPHhzZDph bm5vdGF0aW9uPiANCiAgICAgICAgPHhzZDpkb2N1bWVudGF0aW9uIHhtbDpsYW5nPSJlbiI+IA0K ICAgICAgICBTY2hlbWEgZm9yIERlZmluaW5nIExGQiBDbGFzc2VzIGFuZCBhc3NvY2lhdGVkIHR5 cGVzIChmcmFtZXMsIA0KICAgICAgICBkYXRhIHR5cGVzIGZvciBMRkIgYXR0cmlidXRlcywgYW5k IG1ldGFkYXRhKS4gDQogICAgICAgIDwveHNkOmRvY3VtZW50YXRpb24+IA0KICAgICAgPC94c2Q6 YW5ub3RhdGlvbj4gDQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZGVzY3JpcHRpb24iIHR5cGU9 InhzZDpzdHJpbmciLz4gDQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ic3lub3BzaXMiIHR5cGU9 InhzZDpzdHJpbmciLz4gDQogICAgICA8IS0tIERvY3VtZW50IHJvb3QgZWxlbWVudDogTEZCTGli cmFyeSAtLT4gDQogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTEZCTGlicmFyeSI+IA0KICAgICAg ICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAg ICAgIDx4c2Q6ZWxlbWVudCByZWY9ImRlc2NyaXB0aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAg ICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibG9hZCIgdHlwZT0ibG9hZFR5cGUiIG1pbk9jY3Vy cz0iMCIgDQogICAgICAgICAgICAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4g DQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZnJhbWVEZWZzIiB0eXBlPSJmcmFtZURl ZnNUeXBlIiANCiAgICAgICAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4gDQogICAg ICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZGF0YVR5cGVEZWZzIiB0eXBlPSJkYXRhVHlwZURl ZnNUeXBlIiANCiAgICAgICAgICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4gDQogICAg ICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibWV0YWRhdGFEZWZzIiB0eXBlPSJtZXRhZGF0YURl ZnNUeXBlIiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1OF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAg IA0KICAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJMRkJDbGFzc0RlZnMiIHR5cGU9IkxGQkNsYXNzRGVmc1R5cGUi IA0KICAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICA8 L3hzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0icHJvdmlkZXMi IHR5cGU9InhzZDpOYW1lIiANCiAgICAgIHVzZT0icmVxdWlyZWQiLz4gDQogICAgICAgIDwveHNk OmNvbXBsZXhUeXBlPiANCiAgICAgICAgPCEtLSBVbmlxdWVuZXNzIGNvbnN0cmFpbnRzIC0tPiAN CiAgICAgICAgPHhzZDprZXkgbmFtZT0iZnJhbWUiPiANCiAgICAgICAgICA8eHNkOnNlbGVjdG9y IHhwYXRoPSJsZmI6ZnJhbWVEZWZzL2xmYjpmcmFtZURlZiIvPiANCiAgICAgICAgICA8eHNkOmZp ZWxkIHhwYXRoPSJsZmI6bmFtZSIvPiANCiAgICAgICAgPC94c2Q6a2V5PiANCiAgICAgICAgPHhz ZDprZXkgbmFtZT0iZGF0YVR5cGUiPiANCiAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJs ZmI6ZGF0YVR5cGVEZWZzL2xmYjpkYXRhVHlwZURlZiIvPiANCiAgICAgICAgICA8eHNkOmZpZWxk IHhwYXRoPSJsZmI6bmFtZSIvPiANCiAgICAgICAgPC94c2Q6a2V5PiANCiAgICAgICAgPHhzZDpr ZXkgbmFtZT0ibWV0YWRhdGFEZWYiPiANCiAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJs ZmI6bWV0YWRhdGFEZWZzL2xmYjptZXRhZGF0YURlZiIvPiANCiAgICAgICAgICA8eHNkOmZpZWxk IHhwYXRoPSJsZmI6bmFtZSIvPiANCiAgICAgICAgPC94c2Q6a2V5PiANCiAgICAgICAgPHhzZDpr ZXkgbmFtZT0iTEZCQ2xhc3NEZWYiPiANCiAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJs ZmI6TEZCQ2xhc3NEZWZzL2xmYjpMRkJDbGFzc0RlZiIvPiANCiAgICAgICAgICA8eHNkOmZpZWxk IHhwYXRoPSJsZmI6bmFtZSIvPiANCiAgICAgICAgPC94c2Q6a2V5PiANCiAgICAgIDwveHNkOmVs ZW1lbnQ+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJsb2FkVHlwZSI+IA0KICAgICAg ICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJsaWJyYXJ5IiB0eXBlPSJ4c2Q6TmFtZSIgdXNlPSJyZXF1 aXJlZCIvPiANCiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibG9jYXRpb24iIHR5cGU9Inhz ZDphbnlVUkkiIA0KICAgICAgdXNlPSJvcHRpb25hbCIvPiANCiAgICAgIDwveHNkOmNvbXBsZXhU eXBlPiANCiAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0iZnJhbWVEZWZzVHlwZSI+IA0KICAg ICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZnJhbWVE ZWYiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBl PiANCiAgICAgICAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICAgICAgPHhzZDpl bGVtZW50IG5hbWU9Im5hbWUiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgICAgICAg IDx4c2Q6ZWxlbWVudCByZWY9InN5bm9wc2lzIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxl bWVudCByZWY9ImRlc2NyaXB0aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgIDwv eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAg ICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgPC94c2Q6 Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJkYXRhVHlwZURlZnNU eXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJkYXRhVHlwZURlZiIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICAgIDx4 c2Q6Y29tcGxleFR5cGU+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDU5XSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAg ICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8 eHNkOmVsZW1lbnQgcmVmPSJkZXNjcmlwdGlvbiIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAg ICAgICAgIDx4c2Q6Z3JvdXAgcmVmPSJ0eXBlRGVjbGFyYXRpb25Hcm91cCIvPiANCiAgICAgICAg ICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0K ICAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAg ICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8IS0tIA0KICAgICAgICAgUHJlZGVmaW5lZCAo YnVpbHQtaW4pIGF0b21pYyBkYXRhLXR5cGVzIGFyZTogDQogICAgICAgICAgICAgY2hhciwgdWNo YXIsIGludDE2LCB1aW50MTYsIGludDMyLCB1aW50MzIsIGludDY0LCB1aW50NjQsIA0KICAgICAg ICAgICAgIHN0cmluZ1tOXSwgYnl0ZVtOXSwgDQogICAgICAgICAgICAgZmxvYXQxNiwgZmxvYXQz MiwgZmxvYXQ2NCANCiAgICAgIC0tPiANCiAgICAgIDx4c2Q6Z3JvdXAgbmFtZT0idHlwZURlY2xh cmF0aW9uR3JvdXAiPiANCiAgICAgICAgPHhzZDpjaG9pY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJ0eXBlUmVmIiB0eXBlPSJ0eXBlUmVmTk1UT0tFTiIvPiANCiAgICAgICAgICA8 eHNkOmVsZW1lbnQgbmFtZT0iYXRvbWljIiB0eXBlPSJhdG9taWNUeXBlIi8+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJhcnJheSIgdHlwZT0iYXJyYXlUeXBlIi8+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJzdHJ1Y3QiIHR5cGU9InN0cnVjdFR5cGUiLz4gDQogICAgICAg ICAgPHhzZDplbGVtZW50IG5hbWU9InVuaW9uIiB0eXBlPSJzdHJ1Y3RUeXBlIi8+IA0KICAgICAg ICA8L3hzZDpjaG9pY2U+IA0KICAgICAgPC94c2Q6Z3JvdXA+IA0KICAgICAgPHhzZDpzaW1wbGVU eXBlIG5hbWU9InR5cGVSZWZOTVRPS0VOIj4gDQogICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFz ZT0ieHNkOnRva2VuIj4gDQogICAgICAgICAgPHhzZDpwYXR0ZXJuIHZhbHVlPSJcYysiLz4gDQog ICAgICAgICAgPHhzZDpwYXR0ZXJuIHZhbHVlPSJzdHJpbmdcW1xkK1xdIi8+IA0KICAgICAgICAg IDx4c2Q6cGF0dGVybiB2YWx1ZT0iYnl0ZVxbXGQrXF0iLz4gDQogICAgICAgIDwveHNkOnJlc3Ry aWN0aW9uPiANCiAgICAgIDwveHNkOnNpbXBsZVR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlw ZSBuYW1lPSJhdG9taWNUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJiYXNlVHlwZSIgdHlwZT0idHlwZVJlZk5NVE9LRU4iLz4gDQog ICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InJhbmdlUmVzdHJpY3Rpb24iIA0KICAgICAgICAg ICAgICAgICAgICAgICB0eXBlPSJyYW5nZVJlc3RyaWN0aW9uVHlwZSBtaW5PY2N1cnM9IjAiLz4g DQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InNwZWNpYWxWYWx1ZXMiIHR5cGU9InNwZWNp YWxWYWx1ZXNUeXBlIiANCiAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+IA0K ICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAg ICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9InJhbmdlUmVzdHJpY3Rpb25UeXBlIj4gDQogICAgICAg IDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJhbGxvd2VkUmFu Z2UiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBl PiANCiAgICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibWluIiB0eXBlPSJ4c2Q6aW50 ZWdlciIgDQogICAgICB1c2U9InJlcXVpcmVkIi8+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDYwXSAN CgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAg QXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgIDx4c2Q6YXR0cmlidXRlIG5h bWU9Im1heCIgdHlwZT0ieHNkOmludGVnZXIiIA0KICAgICAgdXNlPSJyZXF1aXJlZCIvPiANCiAg ICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiAN CiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAg ICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJzcGVjaWFsVmFsdWVzVHlwZSI+IA0KICAgICAgICA8 eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ic3BlY2lhbFZhbHVl IiBtYXhPY2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4g DQogICAgICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8 eHNkOmVsZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgPC94c2Q6c2VxdWVu Y2U+IA0KICAgICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ2YWx1ZSIgdHlwZT0ieHNk OnRva2VuIi8+IA0KICAgICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgIDwv eHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21w bGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImFycmF5VHlwZSI+IA0KICAg ICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8eHNkOmdyb3VwIHJlZj0idHlwZURlY2xh cmF0aW9uR3JvdXAiLz4gDQogICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgPHhzZDph dHRyaWJ1dGUgbmFtZT0idHlwZSIgdXNlPSJvcHRpb25hbCIgDQogICAgICAgICAgICAgICAgICAg ICAgIGRlZmF1bHQ9InZhcmlhYmxlLXNpemUiPiANCiAgICAgICAgICA8eHNkOnNpbXBsZVR5cGU+ IA0KICAgICAgICAgICAgPHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4c2Q6c3RyaW5nIj4gDQogICAg ICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9ImZpeGVkLXNpemUiLz4gDQogICAgICAg ICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9InZhcmlhYmxlLXNpemUiLz4gDQogICAgICAg ICAgICA8L3hzZDpyZXN0cmljdGlvbj4gDQogICAgICAgICAgPC94c2Q6c2ltcGxlVHlwZT4gDQog ICAgICAgIDwveHNkOmF0dHJpYnV0ZT4gDQogICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9Imxl bmd0aCIgdHlwZT0ieHNkOmludGVnZXIiIHVzZT0ib3B0aW9uYWwiLz4gDQogICAgICAgIDx4c2Q6 YXR0cmlidXRlIG5hbWU9Im1heExlbmd0aCIgdHlwZT0ieHNkOmludGVnZXIiIA0KICAgICAgICAg ICAgICAgICAgICAgICB1c2U9Im9wdGlvbmFsIi8+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+ IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJzdHJ1Y3RUeXBlIj4gDQogICAgICAgIDx4 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJlbGVtZW50IiBtYXhP Y2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAg ICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVs ZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmdyb3VwIHJlZj0i dHlwZURlY2xhcmF0aW9uR3JvdXAiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiAN CiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50 PiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA2MV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBG b3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAg ICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8 eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFkYXRhRGVmc1R5cGUiPiANCiAgICAgICAgPHhzZDpz ZXF1ZW5jZT4gDQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Im1ldGFkYXRhRGVmIiBtYXhP Y2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAg ICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVs ZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVm PSJkZXNjcmlwdGlvbiIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6Y2hv aWNlPiANCiAgICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJ0eXBlUmVmIiB0eXBl PSJ0eXBlUmVmTk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJhdG9taWMiIHR5cGU9ImF0b21pY1R5cGUiLz4gDQogICAgICAgICAgICAgICAgPC94c2Q6Y2hv aWNlPiANCiAgICAgICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgPC94c2Q6 Y29tcGxleFR5cGU+IA0KICAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpz ZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhU eXBlIG5hbWU9IkxGQkNsYXNzRGVmc1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQog ICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQkNsYXNzRGVmIiBtYXhPY2N1cnM9InVuYm91 bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgICAgIDx4 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0 eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJz eW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0idmVyc2lvbiIg dHlwZT0idmVyc2lvblR5cGUiLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9 ImRlcml2ZWRGcm9tIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFt ZT0iaW5wdXRQb3J0cyIgdHlwZT0iaW5wdXRQb3J0c1R5cGUiIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50 IG5hbWU9Im91dHB1dFBvcnRzIiB0eXBlPSJvdXRwdXRQb3J0c1R5cGUiIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgICAgPHhzZDpl bGVtZW50IG5hbWU9ImF0dHJpYnV0ZXMiIHR5cGU9IkxGQkF0dHJpYnV0ZXNUeXBlIiANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJjYXBhYmlsaXRpZXMiIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0eXBlPSJMRkJDYXBhYmlsaXRpZXNUeXBlIiBtaW5PY2N1cnM9IjAiLz4gDQogICAg ICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iZGVzY3JpcHRpb24iIG1pbk9jY3Vycz0iMCIv PiANCiAgICAgICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgPC94c2Q6Y29t cGxleFR5cGU+IA0KICAgICAgICAgICAgPCEtLSBLZXkgY29uc3RyYWludCB0byBlbnN1cmUgdW5p cXVlIGF0dHJpYnV0ZSBuYW1lcyB3aXRoaW4gDQogICAgICAgICAgICAgICAgIGEgY2xhc3M6IA0K ICAgICAgICAgICAgLS0+IA0KICAgICAgICAgICAgPHhzZDprZXkgbmFtZT0iYXR0cmlidXRlcyI+ IA0KICAgICAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJsZmI6YXR0cmlidXRlcy9sZmI6 YXR0cmlidXRlIi8+IA0KICAgICAgICAgICAgICA8eHNkOmZpZWxkIHhwYXRoPSJsZmI6bmFtZSIv PiANCiAgICAgICAgICAgIDwveHNkOmtleT4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNjJdIA0KDCAg IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1 c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAgICAgIDx4c2Q6a2V5IG5hbWU9ImNhcGFiaWxp dGllcyI+IA0KICAgICAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJsZmI6Y2FwYWJpbGl0 aWVzL2xmYjpjYXBhYmlsaXR5Ii8+IA0KICAgICAgICAgICAgICA8eHNkOmZpZWxkIHhwYXRoPSJs ZmI6bmFtZSIvPiANCiAgICAgICAgICAgIDwveHNkOmtleT4gDQogICAgICAgICAgPC94c2Q6ZWxl bWVudD4gDQogICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBl PiANCiAgICAgIDx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJ2ZXJzaW9uVHlwZSI+IA0KICAgICAgICA8 eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpOTVRPS0VOIj4gDQogICAgICAgICAgPHhzZDpwYXR0 ZXJuIHZhbHVlPSJbMS05XVswLTldKlwuKFsxLTldWzAtOV0qfDApIi8+IA0KICAgICAgICA8L3hz ZDpyZXN0cmljdGlvbj4gDQogICAgICA8L3hzZDpzaW1wbGVUeXBlPiANCiAgICAgIDx4c2Q6Y29t cGxleFR5cGUgbmFtZT0iaW5wdXRQb3J0c1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4g DQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImlucHV0UG9ydCIgdHlwZT0iaW5wdXRQb3J0 VHlwZSIgDQogICAgICAgICAgICAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+IA0K ICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAg ICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImlucHV0UG9ydFR5cGUiPiANCiAgICAgICAgPHhzZDpz ZXF1ZW5jZT4gDQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Im5hbWUiIHR5cGU9InhzZDpO TVRPS0VOIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9InN5bm9wc2lzIi8+IA0KICAg ICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJleHBlY3RhdGlvbiIgdHlwZT0icG9ydEV4cGVjdGF0 aW9uVHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJkZXNjcmlwdGlvbiIgbWlu T2NjdXJzPSIwIi8+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICAgIDx4c2Q6YXR0 cmlidXRlIG5hbWU9Imdyb3VwIiB0eXBlPSJib29sZWFuVHlwZSIgdXNlPSJvcHRpb25hbCIgDQog ICAgICAgICAgICAgICAgICAgICAgIGRlZmF1bHQ9Im5vIi8+IA0KICAgICAgPC94c2Q6Y29tcGxl eFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJwb3J0RXhwZWN0YXRpb25UeXBl Ij4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJmcmFtZUV4cGVjdGVkIiBtaW5PY2N1cnM9IjAiPiANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxl eFR5cGU+IA0KICAgICAgICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgICA8 IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgZnJhbWUgdHlwZSAtLQ0K ICAgICAgPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icmVmIiB0eXBlPSJ4 c2Q6c3RyaW5nIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwv eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgICA8 eHNkOmVsZW1lbnQgbmFtZT0ibWV0YWRhdGFFeHBlY3RlZCIgbWluT2NjdXJzPSIwIj4gDQogICAg ICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgICAgPHhzZDpjaG9pY2UgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVy IHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAgICAgICAgIDx4 c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9Im1ldGFkYXRhSW5wdXRSZWZUeXBlIi8+IA0KICAg ICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvbmUtb2YiIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0eXBlPSJtZXRhZGF0YUlucHV0Q2hvaWNlVHlwZSIvPiANCiAgICANCiAg IFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA2M10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9k ZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgICA8 L3hzZDpjaG9pY2U+IA0KICAgICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAg IDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpj b21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFkYXRhSW5wdXRD aG9pY2VUeXBlIj4gDQogICAgICAgIDx4c2Q6Y2hvaWNlIG1pbk9jY3Vycz0iMiIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBv ZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJy ZWYiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJv bmUtb2YiIHR5cGU9Im1ldGFkYXRhSW5wdXRDaG9pY2VUeXBlIi8+IA0KICAgICAgICAgIDx4c2Q6 ZWxlbWVudCBuYW1lPSJtZXRhZGF0YVNldCIgdHlwZT0ibWV0YWRhdGFJbnB1dFNldFR5cGUiLz4g DQogICAgICAgIDwveHNkOmNob2ljZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAg ICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFkYXRhSW5wdXRTZXRUeXBlIj4gDQogICAgICAg IDx4c2Q6Y2hvaWNlIG1pbk9jY3Vycz0iMiIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAg ICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEg LS0+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9Im1ldGFkYXRhSW5w dXRSZWZUeXBlIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvbmUtb2YiIHR5cGU9 Im1ldGFkYXRhSW5wdXRDaG9pY2VUeXBlIi8+IA0KICAgICAgICA8L3hzZDpjaG9pY2U+IA0KICAg ICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJtZXRh ZGF0YUlucHV0UmVmVHlwZSI+IA0KICAgICAgICA8eHNkOnNpbXBsZUNvbnRlbnQ+IA0KICAgICAg ICAgIDx4c2Q6ZXh0ZW5zaW9uIGJhc2U9InhzZDpOTVRPS0VOIj4gDQogICAgICAgICAgICA8eHNk OmF0dHJpYnV0ZSBuYW1lPSJkZXBlbmRlbmN5IiB1c2U9Im9wdGlvbmFsIiANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRlZmF1bHQ9InJlcXVpcmVkIj4gDQogICAgICAgICAgICAgIDx4c2Q6 c2ltcGxlVHlwZT4gDQogICAgICAgICAgICAgICAgPHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4c2Q6 c3RyaW5nIj4gDQogICAgICAgICAgICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJyZXF1 aXJlZCIvPiANCiAgICAgICAgICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Im9wdGlv bmFsIi8+IA0KICAgICAgICAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPiANCiAgICAgICAgICAg ICAgPC94c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICA8L3hzZDphdHRyaWJ1dGU+IA0KICAg ICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZGVmYXVsdFZhbHVlIiB0eXBlPSJ4c2Q6dG9r ZW4iIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlPSJvcHRpb25hbCIvPiANCiAgICAg ICAgICA8L3hzZDpleHRlbnNpb24+IA0KICAgICAgICA8L3hzZDpzaW1wbGVDb250ZW50PiANCiAg ICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0ib3V0 cHV0UG9ydHNUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6 ZWxlbWVudCBuYW1lPSJvdXRwdXRQb3J0IiB0eXBlPSJvdXRwdXRQb3J0VHlwZSIgDQogICAgICAg ICAgICAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+IA0KICAgICAgICA8L3hzZDpz ZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhU eXBlIG5hbWU9Im91dHB1dFBvcnRUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAg ICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAg ICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICANCiAgIFlhbmcsIGV0 IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA2NF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAg ICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJwcm9kdWN0IiB0eXBlPSJwb3J0UHJvZHVjdFR5cGUiLz4gDQogICAgICAgICAgPHhzZDpl bGVtZW50IHJlZj0iZGVzY3JpcHRpb24iIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgPC94c2Q6 c2VxdWVuY2U+IA0KICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJncm91cCIgdHlwZT0iYm9v bGVhblR5cGUiIHVzZT0ib3B0aW9uYWwiIA0KICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0 PSJubyIvPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6Y29tcGxleFR5 cGUgbmFtZT0icG9ydFByb2R1Y3RUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAg ICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJmcmFtZVByb2R1Y2VkIj4gDQogICAgICAgICAgICA8 eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAg ICAgICAgICAgPCEtLSByZWYgbXVzdCByZWZlciB0byBhIG5hbWUgb2YgYSBkZWZpbmVkIGZyYW1l IHR5cGUgLS0NCiAgICAgID4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InJl ZiIgdHlwZT0ieHNkOk5NVE9LRU4iIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPiANCiAgICAgICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAg ICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0K ICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJtZXRhZGF0YVByb2R1Y2VkIiBtaW5PY2N1cnM9 IjAiPiANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICAgICA8eHNk OmNob2ljZSBtYXhPY2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgICAgICAgIDwhLS0gcmVm IG11c3QgcmVmZXIgdG8gYSBuYW1lIG9mIGEgZGVmaW5lZCBtZXRhZGF0YSAtLT4gDQogICAgICAg ICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InJlZiIgdHlwZT0ibWV0YWRhdGFPdXRwdXRSZWZU eXBlIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvbmUtb2YiIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJtZXRhZGF0YU91dHB1dENob2ljZVR5cGUi Lz4gDQogICAgICAgICAgICAgIDwveHNkOmNob2ljZT4gDQogICAgICAgICAgICA8L3hzZDpjb21w bGV4VHlwZT4gDQogICAgICAgICAgPC94c2Q6ZWxlbWVudD4gDQogICAgICAgIDwveHNkOnNlcXVl bmNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6Y29tcGxleFR5cGUg bmFtZT0ibWV0YWRhdGFPdXRwdXRDaG9pY2VUeXBlIj4gDQogICAgICAgIDx4c2Q6Y2hvaWNlIG1p bk9jY3Vycz0iMiIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICA8IS0tIHJlZiBt dXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJvbmUtb2YiIHR5cGU9Im1ldGFkYXRhT3V0cHV0Q2hvaWNlVHlw ZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibWV0YWRhdGFTZXQiIHR5cGU9Im1l dGFkYXRhT3V0cHV0U2V0VHlwZSIvPiANCiAgICAgICAgPC94c2Q6Y2hvaWNlPiANCiAgICAgIDwv eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0ibWV0YWRhdGFP dXRwdXRTZXRUeXBlIj4gDQogICAgICAgIDx4c2Q6Y2hvaWNlIG1pbk9jY3Vycz0iMiIgbWF4T2Nj dXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFt ZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJyZWYiIHR5cGU9Im1ldGFkYXRhT3V0cHV0UmVmVHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVs ZW1lbnQgbmFtZT0ib25lLW9mIiB0eXBlPSJtZXRhZGF0YU91dHB1dENob2ljZVR5cGUiLz4gDQog ICAgICAgIDwveHNkOmNob2ljZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8 eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFkYXRhT3V0cHV0UmVmVHlwZSI+IA0KICAgICAgICA8 eHNkOnNpbXBsZUNvbnRlbnQ+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDY1XSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAgICAgICAgPHhzZDpleHRlbnNpb24gYmFzZT0ieHNkOk5NVE9LRU4i PiANCiAgICAgICAgICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImF2YWlsYWJpbGl0eSIgdXNlPSJv cHRpb25hbCIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0PSJ1bmNvbmRpdGlv bmFsIj4gDQogICAgICAgICAgICAgIDx4c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICAgICAg PHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4c2Q6c3RyaW5nIj4gDQogICAgICAgICAgICAgICAgICA8 eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJ1bmNvbmRpdGlvbmFsIi8+IA0KICAgICAgICAgICAgICAg ICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iY29uZGl0aW9uYWwiLz4gDQogICAgICAgICAgICAg ICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAgICAgICAgICAgICA8L3hzZDpzaW1wbGVUeXBlPiAN CiAgICAgICAgICAgIDwveHNkOmF0dHJpYnV0ZT4gDQogICAgICAgICAgPC94c2Q6ZXh0ZW5zaW9u PiANCiAgICAgICAgPC94c2Q6c2ltcGxlQ29udGVudD4gDQogICAgICA8L3hzZDpjb21wbGV4VHlw ZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IkxGQkF0dHJpYnV0ZXNUeXBlIj4gDQog ICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJhdHRy aWJ1dGUiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhU eXBlPiANCiAgICAgICAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICAgICAgPHhz ZDplbGVtZW50IG5hbWU9Im5hbWUiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgICAg ICAgIDx4c2Q6ZWxlbWVudCByZWY9InN5bm9wc2lzIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6 ZWxlbWVudCByZWY9ImRlc2NyaXB0aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAg ICAgPHhzZDpncm91cCByZWY9InR5cGVEZWNsYXJhdGlvbkdyb3VwIi8+IA0KICAgICAgICAgICAg ICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJkZWZhdWx0VmFsdWUiIHR5cGU9InhzZDp0b2tlbiIgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAg ICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJh Y2Nlc3MiIHVzZT0ib3B0aW9uYWwiIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZh dWx0PSJyZWFkLXdyaXRlIj4gDQogICAgICAgICAgICAgICAgPHhzZDpzaW1wbGVUeXBlPiANCiAg ICAgICAgICAgICAgICAgIDx4c2Q6bGlzdCBpdGVtVHlwZT0iYWNjZXNzTW9kZVR5cGUiLz4gDQog ICAgICAgICAgICAgICAgPC94c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICAgIDwveHNkOmF0 dHJpYnV0ZT4gDQogICAgICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgPC94 c2Q6ZWxlbWVudD4gDQogICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgIDwveHNkOmNvbXBs ZXhUeXBlPiANCiAgICAgIDx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJhY2Nlc3NNb2RlVHlwZSI+IA0K ICAgICAgICA8eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpOTVRPS0VOIj4gDQogICAgICAgICAg PHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0icmVhZC1vbmx5Ii8+IA0KICAgICAgICAgIDx4c2Q6ZW51 bWVyYXRpb24gdmFsdWU9InJlYWQtd3JpdGUiLz4gDQogICAgICAgICAgPHhzZDplbnVtZXJhdGlv biB2YWx1ZT0id3JpdGUtb25seSIvPiANCiAgICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVl PSJyZWFkLXJlc2V0Ii8+IA0KICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9InRyaWdn ZXItb25seSIvPiANCiAgICAgICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAgICAgPC94c2Q6c2lt cGxlVHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IkxGQkNhcGFiaWxpdGllc1R5 cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgPHhzZDplbGVtZW50IG5h bWU9ImNhcGFiaWxpdHkiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgDQogICBZYW5nLCBl dCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNjZdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAg ICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxl eFR5cGU+IA0KICAgICAgICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgICA8 eHNkOmVsZW1lbnQgbmFtZT0ibmFtZSIgdHlwZT0ieHNkOk5NVE9LRU4iLz4gDQogICAgICAgICAg ICAgICAgPHhzZDplbGVtZW50IHJlZj0ic3lub3BzaXMiLz4gDQogICAgICAgICAgICAgICAgPHhz ZDplbGVtZW50IHJlZj0iZGVzY3JpcHRpb24iIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAg ICAgICA8eHNkOmdyb3VwIHJlZj0idHlwZURlY2xhcmF0aW9uR3JvdXAiLz4gDQogICAgICAgICAg ICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAg ICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAg PC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpzaW1wbGVUeXBlIG5hbWU9ImJvb2xlYW5U eXBlIj4gDQogICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyI+IA0KICAg ICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9InllcyIvPiANCiAgICAgICAgICA8eHNkOmVu dW1lcmF0aW9uIHZhbHVlPSJubyIvPiANCiAgICAgICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAg ICAgPC94c2Q6c2ltcGxlVHlwZT4gDQogICAgICA8L3hzZDpzY2hlbWE+IA0KICAgIA0KICAgNS4g DSAgICAgRkUgQXR0cmlidXRlcyBhbmQgQ2FwYWJpbGl0aWVzIA0KICAgICAgIA0KICAgICAgQSBG b3JDRVMgZm9yd2FyZGluZyBlbGVtZW50IGhhbmRsZXMgdHJhZmZpYyBvbiBiZWhhbGYgb2YgYSBG b3JDRVMgDQogICAgICBjb250cm9sIGVsZW1lbnQuICBXaGlsZSB0aGUgc3RhbmRhcmRzIHdpbGwg ZGVzY3JpYmUgdGhlIHByb3RvY29sIA0KICAgICAgYW5kIG1lY2hhbmlzbXMgZm9yIHRoaXMgY29u dHJvbCwgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBhbmQgDQogICAgICBkaWZmZXJlbnQgaW5z dGFuY2VzIHdpbGwgaGF2ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzLiAgVGhlIENFIA0KICAgICAg bmVlZHMgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hhdCBlYWNoIGluc3RhbmNlIGl0IGlzIHJl c3BvbnNpYmxlIA0KICAgICAgZm9yIGlzIGFjdHVhbGx5IGNhcGFibGUgb2YgZG9pbmcuICBBcyBz dGF0ZWQgcHJldmlvdXNseSwgdGhpcyBpcyANCiAgICAgIGFuIGFwcHJveGltYXRpb24uICBUaGUg Q0UgaXMgZXhwZWN0ZWQgdG8gYmUgcHJlcGFyZWQgdG8gY29wZSB3aXRoIA0KICAgICAgZXJyb3Jz IGluIHJlcXVlc3RzIGFuZCB2YXJpYXRpb25zIGluIGRldGFpbCBub3QgY2FwdHVyZWQgYnkgdGhl IA0KICAgICAgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFib3V0IGFuIEZFLiANCiAgICAgICAN CiAgICAgIEluIGFkZGl0aW9uIHRvIGl0cyBjYXBhYmlsaXRpZXMsIGFuIEZFIHdpbGwgaGF2ZSBh dHRyaWJ1dGUgDQogICAgICBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGluIHVuZGVyc3Rh bmRpbmcgYW5kIGNvbnRyb2xsaW5nIHRoZSANCiAgICAgIGZvcndhcmRpbmcgb3BlcmF0aW9ucy4g IFNvbWUgb2YgdGhlIGF0dHJpYnV0ZXMgd2lsbCBiZSByZWFkIG9ubHksIA0KICAgICAgd2hpbGUg b3RoZXJzIHdpbGwgYWxzbyBiZSB3cml0ZWFibGUuIA0KICAgICAgIA0KICAgICAgVGhlIEZvckNF UyBwcm90b2NvbCB3aWxsIGRlZmluZSB0aGUgYWN0dWFsIG1lY2hhbmlzbSBmb3IgZ2V0dGluZyAN CiAgICAgIGFuZCBzZXR0aW5nIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbi4gIFRoaXMgbW9kZWwgZGVm aW5lcyB0aGUgDQogICAgICBzdGFydGluZyBzZXQgb2YgaW5mb3JtYXRpb24gdGhhdCB3aWxsIGJl IGF2YWlsYWJsZS4gIFRoaXMgDQogICAgICBkZWZpbml0aW9uIGluY2x1ZGVzIHRoZSBzZW1hbnRp Y3MgYW5kIHRoZSBzdHJ1Y3R1cmluZyBvZiB0aGUgDQogICAgICBhdHRyaWJ1dGUgaW5mb3JtYXRp b24gYW5kIGFsc28gcHJvdmlkZXMgZm9yIGV4dGVuc2lvbnMuIA0KICAgICAgIA0KICAgICAgSW4g b3JkZXIgdG8gY3Jpc3BseSBkZWZpbmUgdGhlIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBhbmQgDQog ICAgICBzdHJ1Y3R1cmUsIHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBhdHRyaWJ1dGVzIGFz IGluZm9ybWF0aW9uIA0KICAgICAgaW4gYW4gYWJzdHJhY3QgWE1MIGRvY3VtZW50LiAgQ29uY2Vw dHVhbGx5LCBlYWNoIEZFIGNvbnRhaW5zIHN1Y2ggDQogICAgICBhIGRvY3VtZW50LiAgVGhlIGRv Y3VtZW50IHN0cnVjdHVyZSBpcyBkZWZpbmVkIGJ5IHRoZSBYTUwgU2NoZW1hIA0KICAgICAgY29u dGFpbmVkIGluIHRoaXMgbW9kZWwuICBPcGVyYXRpb25hbGx5LCB0aGUgRm9yQ0VTIHByb3RvY29s IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDY3XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZv ckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAg ICByZWZlcnMgdG8gaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoYXQgZG9jdW1lbnQgaW4gb3Jk ZXIgdG8gcmVhZCANCiAgICAgIG9yIHdyaXRlIEZFIGF0dHJpYnV0ZXMgYW5kIGNhcGFiaWxpdGll cy4gIFRoaXMgZG9jdW1lbnQgaXMgYW4gDQogICAgICBhYnN0cmFjdCByZXByZXNlbnRhdGlvbiBv ZiB0aGUgaW5mb3JtYXRpb24uICBUaGVyZSBpcyBubyANCiAgICAgIHJlcXVpcmVtZW50IHRoYXQg c3VjaCBhIGRvY3VtZW50IGFjdHVhbGx5IGV4aXN0IGluIG1lbW9yeS4gIFVubGVzcyANCiAgICAg IHRoZSBGb3JDRVMgcHJvdG9jb2wgY2FsbHMgZm9yIHRyYW5zZmVyIG9mIHRoZSBpbmZvcm1hdGlv biBpbiBYTUwsIA0KICAgICAgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCByZXF1aXJlZCB0byBldmVy IGJlIHJlcHJlc2VudGVkIGluIHRoZSBGRSANCiAgICAgIGluIFhNTC4gIFRoZSBYTUwgc2NoZW1h IHNlcnZlcyBvbmx5IHRvIGlkZW50aWZ5IHRoZSBlbGVtZW50cyBhbmQgDQogICAgICBzdHJ1Y3R1 cmUgb2YgdGhlIGluZm9ybWF0aW9uLiANCiAgICAgICANCiAgICAgIFRoZSBzdWJzZWN0aW9ucyBp biB0aGlzIHBhcnQgb2YgdGhlIGRvY3VtZW50IHByb3ZpZGUgdGhlIGRldGFpbHMgDQogICAgICBv biB0aGlzIGFzcGVjdCBvZiB0aGUgRkUgbW9kZWwuICA1LjEgZ2l2ZXMgdGhlIFhNTCBzY2hlbWEg Zm9yIHRoZSANCiAgICAgIGFic3RyYWN0IEZFIGF0dHJpYnV0ZSBkb2N1bWVudC4gIDUuMiBlbGFi b3JhdGVzIG9uIGVhY2ggb2YgdGhlIA0KICAgICAgZGVmaW5lZCBhdHRyaWJ1dGVzIG9mIHRoZSBG RSwgZm9sbG93aW5nIHRoZSBoaWVyYXJjaHkgb2YgdGhlIA0KICAgICAgc2NoZW1hLiAgNS4zIHBy b3ZpZGVzIGFuIGV4YW1wbGUgWE1MIEZFIGF0dHJpYnV0ZSBkb2N1bWVudCB0byANCiAgICAgIGNs YXJpZnkgdGhlIG1lYW5pbmcgb2YgNS4xIGFuZCA1LjIuICANCiAgICAgICANCiAgIDUuMS4gWE1M IFNjaGVtYSBmb3IgRkUgQXR0cmlidXRlIERvY3VtZW50cyANCiAgICANCiAgICAgIDw/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+IA0KICAgICAgPHhzZDpzY2hlbWEgeG1sbnM6 eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSI+IA0KICAgICAgIA0KICAgICAg IDx4c2Q6YW5ub3RhdGlvbj4gDQogICAgICAgIDx4c2Q6ZG9jdW1lbnRhdGlvbiB4bWw6bGFuZz0i ZW4iPiANCiAgICAgICAgIFNjaGVtYSBmb3IgdGhlIEFic3RyYWN0IEZFIEF0dHJpYnV0ZXMgYW5k IENhcGFiaWxpdGllcyBEb2N1bWVudCANCiAgICAgICAgPC94c2Q6ZG9jdW1lbnRhdGlvbj4gDQog ICAgICAgPC94c2Q6YW5ub3RhdGlvbj4gDQogICAgICAgDQogICAgICAgPHhzZDplbGVtZW50IG5h bWU9IkZFRG9jdW1lbnQiPiANCiAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICA8 eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVDYXBhYmlsaXRp ZXMiIHR5cGU9IkZFQ2FwYWJpbGl0aWVzVHlwZSIgDQogICAgICAgICAgICAgICBtaW5PY2N1cnM9 IjAiIG1heE9jY3Vycz0iMSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVBdHRy aWJ1dGVzIiB0eXBlPSJGRUF0dHJpYnV0ZXNUeXBlIiANCiAgICAgICAgICAgICAgIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSIxIi8+IA0KICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAg ICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgPC94c2Q6ZWxlbWVudD4gDQogICAgICAgDQog ICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJGRUNhcGFiaWxpdGllc1R5cGUiPiANCiAgICAg ICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTW9kaWZpYWJs ZUxGQlRvcG9sb2d5IiB0eXBlPSJ4c2Q6Ym9vbGVhbiIgDQogICAgICAgICAgICAgIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSIxIi8+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlN1cHBv cnRlZExGQnMiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIj4gDQogICAgICAgICAgPHhzZDpj b21wbGV4VHlwZT4gDQogICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgPHhz ZDplbGVtZW50IG5hbWU9IlN1cHBvcnRlZExGQiIgdHlwZT0iU3VwcG9ydGVkTEZCVHlwZSIgDQog ICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4gDQog ICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgNjhdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAg ICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAg ICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlN1cHBvcnRl ZEF0dHJpYnV0ZXMiICANCiAgICAgICAgICAgICAgdHlwZT0iU3VwcG9ydGVkQXR0cmlidXRlc1R5 cGUiICANCiAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4gDQogICAg ICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAg DQogICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJTdXBwb3J0ZWRMRkJUeXBlIj4gDQogICAg ICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgPCEtLSB0aGUgbmFtZSBvZiBhIHN1cHBvcnRl ZCBMRkIgLS0+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQk5hbWUiIHR5cGU9Inhz ZDpOTVRPS0VOIi8+IA0KICAgICAgICAgPCEtLSBob3cgbWFueSBvZiB0aGlzIExGQiBjbGFzcyBj YW4gZXhpc3QgLS0+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQk9jY3VycmVuY2VM aW1pdCIgDQogICAgICAgICAgICAgIHR5cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiIG1pbk9j Y3Vycz0iMCIgDQogICAgICBtYXhPY2N1cnM9IjEiLz4gDQogICAgICAgICA8IS0tIEZvciBlYWNo IHBvcnQgZ3JvdXAsIGhvdyBtYW55IHBvcnRzIGNhbiBleGlzdCAtLT4gDQogICAgICAgICA8eHNk OmVsZW1lbnQgbmFtZT0iUG9ydEdyb3VwTGltaXRzIiBtaW5PY2N1cnM9IjAiIA0KICAgICAgbWF4 T2NjdXJzPSIxIj4gDQogICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgIDx4 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlBvcnRHcm91cExp bWl0IiBtaW5PY2N1cnM9IjAiICANCiAgICAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiPiANCiAgICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgICAgPHhz ZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iUG9ydEdyb3Vw TmFtZSIgdHlwZT0ieHNkOk5NVE9LRU4iLz4gDQogICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQg bmFtZT0iTWluUG9ydENvdW50IiAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgdHlwZT0ieHNkOm5vbk5lZ2F0aXZlSW50ZWdlciIgDQogICAgICAgICAgICAgICAgICAg IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSIxIi8+IA0KICAgICAgICAgICAgICAgPHhzZDplbGVt ZW50IG5hbWU9Ik1heFBvcnRDb3VudCIgIA0KICAgICAgICAgICAgICAgICAgICB0eXBlPSJ4c2Q6 bm9uTmVnYXRpdmVJbnRlZ2VyIiANCiAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9IjEiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAg ICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAg ICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiAN CiAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICAgPCEtLSBmb3IgdGhlIG5hbWVkIExG QiBDbGFzcywgdGhlIExGQiBDbGFzc2VzIGl0IG1heSBmb2xsb3cgLS0+IA0KICAgICAgICAgPHhz ZDplbGVtZW50IG5hbWU9IkNhbk9jY3VyQWZ0ZXJzIiBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0i MSI+IA0KICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICA8eHNkOnNlcXVl bmNlPiANCiAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJDYW5PY2N1ckFmdGVyIiANCiAg ICAgICAgICAgICAgICAgdHlwZT0iTEZCQWRqYWNlbmN5TGltaXRUeXBlIiANCiAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPiANCiAgICAgICAgICAg PC94c2Q6c2VxdWVuY2U+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1 c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDY5XSANCgwgICBJbnRlcm5ldCBE cmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQog ICAgDQogICAgDQogICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgPC94c2Q6 ZWxlbWVudD4gDQogICAgICAgIA0KICAgICAgICAgPCEtLSBmb3IgdGhlIG5hbWVkIExGQiBDbGFz cywgd2hpY2ggTEZCIENsYXNzZXMgbWF5IGZvbGxvdyAtLT4gDQogICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0iQ2FuT2NjdXJCZWZvcmVzIiBtaW5PY2N1cnM9IjAiIA0KICAgICAgbWF4T2NjdXJz PSIxIj4gDQogICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgIDx4c2Q6c2Vx dWVuY2U+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkNhbk9jY3VyQmVmb3JlIiAN CiAgICAgICAgICAgICAgICAgdHlwZT0iTEZCQWRqYWNlbmN5TGltaXRUeXBlIiANCiAgICAgICAg ICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPiANCiAgICAgICAg ICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAg ICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICAgPCEtLSBpbmZvcm1hdGlvbiBkZWZpbmVkIGJ5 IHRoZSBDbGFzcyBEZWZpbml0aW9uIC0tPiANCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJM RkJDbGFzc0NhcGFiaWxpdGllcyIgdHlwZT0ieHNkOmFueVR5cGUiIA0KICAgICAgICAgICAgICBt aW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIvPiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0K ICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICANCiAgICAgICA8eHNkOmNvbXBsZXhU eXBlIG5hbWU9IkxGQkFkamFjZW5jeUxpbWl0VHlwZSI+IA0KICAgICAgICA8eHNkOnNlcXVlbmNl PiANCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJOZWlnaGJvckxGQiIgdHlwZT0ieHNkOk5N VE9LRU4iLz4gDQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0idmlhUG9ydCIgdHlwZT0ieHNk Ok5NVE9LRU4iIA0KICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3Vu ZGVkIi8+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICAgPC94c2Q6Y29tcGxleFR5 cGU+IA0KICAgICAgIA0KICAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0iU3VwcG9ydGVkQXR0 cmlidXRlc1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICA8eHNkOmVs ZW1lbnQgbmFtZT0iU3VwcG9ydGVkQXR0cmlidXRlIiANCiAgICAgICAgICAgICAgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+ IA0KICAgICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJBdHRyaWJ1dGVOYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgIDx4 c2Q6ZWxlbWVudCBuYW1lPSJBY2Nlc3NNb2RlcyIgdHlwZT0ieHNkOk5NVE9LRU4iLz4gDQogICAg ICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQog ICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAg IDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICANCiAgICAgICA8eHNkOmNvbXBsZXhUeXBlIG5h bWU9IkZFQXR0cmlidXRlc1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAg ICA8eHNkOmVsZW1lbnQgbmFtZT0iVmVuZG9yIiB0eXBlPSJ4c2Q6c3RyaW5nIiBtaW5PY2N1cnM9 IjAiLz4gDQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTW9kZWwiIHR5cGU9InhzZDpzdHJp bmciIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJGRVN0YXR1 cyIgdHlwZT0iRkVTdGF0ZVR5cGUiIG1pbk9jY3Vycz0iMCIvPiANCiAgICANCiAgIFlhbmcsIGV0 IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSA3MF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAg ICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgPHhzZDplbGVtZW50IG5h bWU9IkxGQkluc3RhbmNlcyIgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiPiANCiAgICAgICAg ICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAg ICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iTEZCSW5zdGFuY2UiIG1pbk9jY3Vycz0iMCIgDQogICAg ICAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgICAgICAgICAgPHhzZDpj b21wbGV4VHlwZT4gDQogICAgICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAg ICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQkNsYXNzTmFtZSIgdHlwZT0ieHNkOk5NVE9LRU4iLz4i PiANCiAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJMRkJJbnN0YW5jZUlEIiB0eXBl PSJ4c2Q6Tk1UT0tFTiIvPiI+IA0KICAgICAgICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAg ICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICAgPC94c2Q6ZWxlbWVudD4g DQogICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8L3hzZDpjb21wbGV4VHlw ZT4gDQogICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJMRkJUb3BvbG9neSIgdHlwZT0iTEZCVG9wb2xvZ3lUeXBlIiANCiAgICAgICAgICAgICAgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9IjEiLz4gDQogICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0i RkVDb25maWd1cmVkTmVpZ2hib3JzIiBtaW5PY2N1cnM9IjAiIA0KICAgICAgICAgICAgICBtYXhP Y2N1cnM9IjEiPiANCiAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgPHhz ZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iRkVDb25maWd1cmVk TmVpZ2hib3IiIA0KICAgICAgICAgICAgICAgICB0eXBlPSJGRUNvbmZpZ3VyZWROZWlnaGJvclR5 cGUiICANCiAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRl ZCIvPiANCiAgICAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDwveHNkOmNvbXBs ZXhUeXBlPiANCiAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5j ZT4gDQogICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgIA0KICAgICAgIDx4c2Q6Y29t cGxleFR5cGUgbmFtZT0iTEZCVG9wb2xvZ3lUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+ IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxGQkxpbmsiIG1pbk9jY3Vycz0iMCIgDQog ICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+ IA0KICAgICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJGcm9tTEZCSUQiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgICAgPHhzZDpl bGVtZW50IG5hbWU9IkZyb21Qb3J0R3JvdXAiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAg ICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkZyb21Qb3J0SW5kZXgiICAgICAgICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgIHR5cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiLz4g DQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iVG9MRkJJRCIgdHlwZT0ieHNkOk5NVE9L RU4iLz4gDQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iVG9Qb3J0R3JvdXAiIHR5cGU9 InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IlRvUG9ydElu ZGV4IiAgDQogICAgICAgICAgICAgICAgIHR5cGU9InhzZDpub25OZWdhdGl2ZUludGVnZXIiLz4g DQogICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8L3hzZDpjb21wbGV4VHlw ZT4gDQogICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAg IEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3MV0gDQoM ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICAg PC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgIA0KICAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFt ZT0iRkVDb25maWd1cmVkTmVpZ2hib3JUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0K ICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Ik5laWdoYm9ySUQiIHR5cGU9InhzZDphbnlUeXBl Ii8+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Ik5laWdoYm9ySW50ZXJmYWNlIiB0eXBl PSJ4c2Q6YW55VHlwZSIvPiANCiAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJOZWlnaGJvck5l dHdvcmtBZGRyZXNzIiB0eXBlPSJ4c2Q6YW55VHlwZSIgDQogICAgICAgICAgICAgIG1pbk9jY3Vy cz0iMCIgbWF4T2NjdXJzPSIxIi8+IA0KICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Ik5laWdo Ym9yTUFDQWRkcmVzcyIgdHlwZT0ieHNkOmFueVR5cGUiIA0KICAgICAgICAgICAgICBtaW5PY2N1 cnM9IjAiIG1heE9jY3Vycz0iMSIvPiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAg IDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICANCiAgICAgICA8IS0tIFRoZSB2YWx1ZXMgZm9y IHRoZSBzaW1wbGUgc3RhdGUgYXR0cmlidXRlIC0tPiANCiAgICAgICA8IS0tIFRoZXNlIHNob3Vs ZCBwcm9iYWJseSBiZSBkaXJlY3RseSBlbmNvZGFibGUgaW4gdGhlIC0tPiANCiAgICAgICA8IS0t IHByb3RvY29sIHNvIHRoZXkgbWF5IGVuZCB1cCBudW1lcmljIGluc3RlYWQgb2Ygc3RyaW5ncyAt LT4gDQogICAgICAgPHhzZDpzaW1wbGVUeXBlIG5hbWU9IkZFU3RhdGVUeXBlIj4gDQogICAgICAg IDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOk5NVE9LRU4iPiANCiAgICAgICAgIDx4c2Q6ZW51 bWVyYXRpb24gdmFsdWU9IkFkbWluRGlzYWJsZSIvPiANCiAgICAgICAgIDx4c2Q6ZW51bWVyYXRp b24gdmFsdWU9Ik9wZXJEaXNhYmxlIi8+IA0KICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1 ZT0iT3BlckVuYWJsZSIvPiANCiAgICAgICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAgICAgIDwv eHNkOnNpbXBsZVR5cGU+IA0KICAgICAgIA0KICAgICAgPC94c2Q6c2NoZW1hPiANCiAgICAgICAN CiAgIDUuMi4gRkVEb2N1bWVudCANCiAgICANCiAgICAgIEFuIGluc3RhbmNlIG9mIHRoaXMgZG9j dW1lbnQgY2FwdHVyZXMgdGhlIGNhcGFiaWxpdGllcyBhbmQgRkUgDQogICAgICBsZXZlbCBhdHRy aWJ1dGUgLyBzdGF0ZSBpbmZvcm1hdGlvbiBhYm91dCBhIGdpdmVuIEZFLiAgQ3VycmVudGx5LCAN CiAgICAgIHR3byBlbGVtZW50cyBhcmUgYWxsb3dlZCBpbiB0aGUgRkVEb2N1bWVudCwgRkVDYXBh YmlsaXRpZXMgYW5kIA0KICAgICAgRkVBdHRyaWJ1dGVzLiAgDQogICAgICAgDQogICAgICBBdCB0 aGUgbW9tZW50LCBhbGwgY2FwYWJpbGl0eSBhbmQgYXR0cmlidXRlIGluZm9ybWF0aW9uIGluIHRo aXMgDQogICAgICBhYnN0cmFjdCBkb2N1bWVudCBpcyBkZWZpbmVkIGFzIG9wdGlvbmFsLiAgV2Ug bWF5IHdpc2ggdG8gbWFuZGF0ZSANCiAgICAgIHN1cHBvcnQgZm9yIHNvbWUgY2FwYWJpbGl0eSBh bmQvb3IgYXR0cmlidXRlIGluZm9ybWF0aW9uLiANCiAgICAgICANCiAgICAgIElmIGEgcHJvdG9j b2wgdXNpbmcgYmluYXJ5IGVuY29kaW5nIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgYWRvcHRlZCAN CiAgICAgIGJ5IHRoZSBGb3JDRVMgd29ya2luZyBncm91cCwgdGhlbiBlYWNoIHJlbGV2YW50IGVs ZW1lbnQgZGVmaW5lZCBpbiANCiAgICAgIHRoZSBzY2hlbWEgd2lsbCBoYXZlIGEgIlByb3RvY29s RW5jb2RpbmciIGF0dHJpYnV0ZSBhZGRlZCwgd2l0aCBhIA0KICAgICAgIkZpeGVkIiB2YWx1ZSBw cm92aWRpbmcgdGhlIHZhbHVlIHRoYXQgaXMgdXNlZCBpbiB0aGUgcHJvdG9jb2wgZm9yIA0KICAg ICAgdGhhdCBlbGVtZW50LCBzbyB0aGF0IHRoZSBYTUwgYW5kIHRoZSBvbiB0aGUgd2lyZSBwcm90 b2NvbCBjYW4gYmUgDQogICAgICBjb3JyZWxhdGVkLiAgIA0KICAgICAgIA0KICAgNS4yLjEuICBG RUNhcGFiaWxpdGllcyANCiAgICANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMg QXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3Ml0gDQoMICAgSW50ZXJu ZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1 IA0KICAgIA0KICAgIA0KICAgICAgVGhpcyBlbGVtZW50LCBpZiBpdCBvY2N1cnMsIG11c3Qgb2Nj dXIgb25seSBvbmNlIGFuZCBjb250YWlucyBhbGwgDQogICAgICB0aGUgY2FwYWJpbGl0eSByZWxh dGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBGRS4gIENhcGFiaWxpdHkgDQogICAgICBpbmZvcm1h dGlvbiBpcyBhbHdheXMgY29uc2lkZXJlZCB0byBiZSByZWFkLW9ubHkuIA0KICAgICAgIA0KICAg ICAgVGhlIGN1cnJlbnRseSBkZWZpbmVkIGVsZW1lbnRzIGFsbG93ZWQgd2l0aGluIHRoZSBGRUNh cGFiaWxpdGllcyANCiAgICAgIGVsZW1lbnQgYXJlIE1vZGlmaWFibGVMRkJUb3BvbG9neSwgTEZC c1N1cHBvcnRlZCwgDQogICAgICBXcml0ZWFibGVBdHRyaWJ1dGVzIGFuZCBSZWFkYWJsZUF0dHJp YnV0ZXMuIA0KICAgICAgIA0KICAgNS4yLjEuMS4gTW9kaWZpYWJsZUxGQlRvcG9sb2d5IA0KICAg ICAgIA0KICAgICAgVGhpcyBlbGVtZW50IGhhcyBhIGJvb2xlYW4gdmFsdWUuICBUaGlzIGVsZW1l bnQgaW5kaWNhdGVzIHdoZXRoZXIgDQogICAgICB0aGUgTEZCIHRvcG9sb2d5IG9mIHRoZSBGRSBt YXkgYmUgY2hhbmdlZCBieSB0aGUgQ0UuICBJZiB0aGUgDQogICAgICBlbGVtZW50IGlzIGFic2Vu dCwgdGhlIGRlZmF1bHQgdmFsdWUgaXMgYXNzdW1lZCB0byBiZSB0cnVlLCBhbmQgDQogICAgICB0 aGUgQ0UgcHJlc3VtZXMgdGhlIExGQiB0b3BvbG9neSBtYXkgYmUgY2hhbmdlZC4gIElmIHRoZSB2 YWx1ZSBpcyANCiAgICAgIHByZXNlbnQgYW5kIHNldCB0byBmYWxzZSwgdGhlIExGQiB0b3BvbG9n eSBvZiB0aGUgRkUgaXMgZml4ZWQuICBJbiANCiAgICAgIHRoYXQgY2FzZSwgdGhlIExGQnMgc3Vw cG9ydGVkIGNsYXVzZSBtYXkgYmUgb21pdHRlZCwgYW5kIHRoZSBsaXN0IA0KICAgICAgb2Ygc3Vw cG9ydGVkIExGQnMgaXMgaW5mZXJyZWQgYnkgdGhlIENFIGZyb20gdGhlIExGQiB0b3BvbG9neSAN CiAgICAgIGluZm9ybWF0aW9uLiAgSWYgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIExGQnMgaXMgcHJv dmlkZWQgd2hlbiANCiAgICAgIE1vZGlmaWFibGVMRkJUb3BvbG9neSBpcyBmYWxzZSwgdGhlIENh bk9jY3VyQmVmb3JlIGFuZCANCiAgICAgIENhbk9jY3VyQWZ0ZXIgaW5mb3JtYXRpb24gc2hvdWxk IGJlIG9taXR0ZWQuIA0KICAgICAgIA0KICAgNS4yLjEuMi4gU3VwcG9ydGVkTEZCcyBhbmQgU3Vw cG9ydGVkTEZCIA0KICAgICAgIA0KICAgICAgT25lIGNhcGFiaWxpdHkgdGhhdCB0aGUgRkUgc2hv dWxkIGluY2x1ZGUgaXMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIA0KICAgICAgTEZCIGNsYXNzZXMu ICBUaGUgU3VwcG9ydGVkTEZCcyBlbGVtZW50LCB3aGljaCBvY2N1cnMgYXQgbW9zdCANCiAgICAg IG9uY2UsIHNlcnZlcyBhcyBhIHdyYXBwZXIgZm9yIHRoZSBsaXN0IG9mIExGQiBjbGFzc2VzIHN1 cHBvcnRlZC4gIA0KICAgICAgRWFjaCBjbGFzcyBpcyBkZXNjcmliZWQgaW4gYSBTdXBwb3J0ZWRM RkIgZWxlbWVudC4gDQogICAgICAgDQogICAgICBFYWNoIG9jY3VycmVuY2Ugb2YgdGhlIFN1cHBv cnRlZExGQiBlbGVtZW50IGRlc2NyaWJlcyBhbiBMRkIgY2xhc3MgDQogICAgICB0aGF0IHRoZSBG RSBzdXBwb3J0cy4gIEluIGFkZGl0aW9uIHRvIGluZGljYXRpbmcgdGhhdCB0aGUgRkUgDQogICAg ICBzdXBwb3J0cyB0aGUgY2xhc3MsIEZFcyB3aXRoIG1vZGlmaWFibGUgTEZCIHRvcG9sb2d5IHNo b3VsZCANCiAgICAgIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgaG93IExGQnMgb2YgdGhlIHNw ZWNpZmllZCBjbGFzcyBtYXkgYmUgDQogICAgICBjb25uZWN0ZWQgdG8gb3RoZXIgTEZCcy4gIFRo aXMgaW5mb3JtYXRpb24gc2hvdWxkIGRlc2NyaWJlIHdoaWNoIA0KICAgICAgTEZCIGNsYXNzZXMg dGhlIHNwZWNpZmllZCBMRkIgY2xhc3MgbWF5IHN1Y2NlZWQgb3IgcHJlY2VkZSBpbiB0aGUgDQog ICAgICBMRkIgdG9wb2xvZ3kuICBUaGUgRkUgc2hvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gYXMg dG8gd2hpY2ggcG9ydCANCiAgICAgIGdyb3VwcyBtYXkgYmUgY29ubmVjdGVkIHRvIHRoZSBnaXZl biBhZGphY2VudCBMRkIgY2xhc3MuICBJZiBwb3J0IA0KICAgICAgZ3JvdXAgaW5mb3JtYXRpb24g aXMgb21pdHRlZCwgaXQgaXMgYXNzdW1lZCB0aGF0IGFsbCBwb3J0IGdyb3VwcyANCiAgICAgIG1h eSBiZSB1c2VkLiANCiAgICAgICANCiAgIDUuMi4xLjIuMS4gTEZCTmFtZSANCiAgICAgICANCiAg ICAgIFRoaXMgZWxlbWVudCBoYXMgYXMgaXRzIHZhbHVlIHRoZSBuYW1lIG9mIHRoZSBMRkIgYmVp bmcgZGVzY3JpYmVkLiANCiAgICAgICANCiAgIDUuMi4xLjIuMi4gTEZCT2NjdXJyZW5jZUxpbWl0 IA0KICAgICAgIA0KICAgICAgVGhpcyBlbGVtZW50LCBpZiBwcmVzZW50LCBpbmRpY2F0ZXMgdGhl IGxhcmdlc3QgbnVtYmVyIG9mIA0KICAgICAgaW5zdGFuY2VzIG9mIHRoaXMgTEZCIGNsYXNzIHRo ZSBGRSBjYW4gc3VwcG9ydC4gIEZvciBGRXMgdGhhdCBkbyANCiAgICANCiAgIFlhbmcsIGV0IGFs LiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3 M10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgbm90IGhhdmUgdGhlIGNhcGFiaWxp dHkgdG8gY3JlYXRlIG9yIGRlc3Ryb3kgTEZCIGluc3RhbmNlcywgdGhpcyANCiAgICAgIGNhbiBl aXRoZXIgYmUgb21pdHRlZCBvciBiZSB0aGUgc2FtZSBhcyB0aGUgbnVtYmVyIG9mIExGQiANCiAg ICAgIGluc3RhbmNlcyBvZiB0aGlzIGNsYXNzIGNvbnRhaW5lZCBpbiB0aGUgTEZCIGxpc3QgYXR0 cmlidXRlLiANCiAgICAgICANCiAgIDUuMi4xLjIuMy4gUG9ydEdyb3VwTGltaXRzIGFuZCBQb3J0 R3JvdXBMaW1pdCANCiAgICAgICANCiAgICAgIFRoZSBQb3J0R3JvdXBMaW1pdHMgZWxlbWVudCBp cyB0aGUgd3JhcHBlciB0byBob2xkIGluZm9ybWF0aW9uIA0KICAgICAgYWJvdXQgdGhlIHBvcnQg Z3JvdXBzIHN1cHBvcnRlZCBieSB0aGUgTEZCIGNsYXNzLiAgSXQgaG9sZHMgDQogICAgICBtdWx0 aXBsZSBvY2N1cnJlbmNlcyBvZiB0aGUgUG9ydEdyb3VwTGltaXQgZWxlbWVudC4gDQogICAgICAg DQogICAgICBFYWNoIG9jY3VycmVuY2Ugb2YgdGhlIFBvcnRHcm91cExpbWl0IGVsZW1lbnQgY29u dGFpbnMgdGhlIHBvcnQgDQogICAgICBvY2N1cnJlbmNlIGluZm9ybWF0aW9uIGZvciBhIHNpbmds ZSBwb3J0IGdyb3VwIG9mIHRoZSBMRkIgY2xhc3MuICANCiAgICAgIEVhY2ggb2NjdXJyZW5jZSBo YXMgdGhlIG5hbWUgb2YgdGhlIHBvcnQgZ3JvdXAgaW4gdGhlIA0KICAgICAgUG9ydEdyb3VwTmFt ZSBlbGVtZW50LCB0aGUgZmV3ZXN0IG51bWJlciBvZiBwb3J0cyB0aGF0IGNhbiBleGlzdCANCiAg ICAgIGluIHRoZSBncm91cCBpbiB0aGUgTWluUG9ydENvdW50IGVsZW1lbnQsIGFuZCB0aGUgbGFy Z2VzdCBudW1iZXIgDQogICAgICBvZiBwb3J0cyB0aGF0IGNhbiBleGlzdCBpbiB0aGUgZ3JvdXAg aW4gdGhlIE1heFBvcnRDb3VudCBlbGVtZW50LiANCiAgICAgICANCiAgIDUuMi4xLjIuNC5DYW5P Y2N1ckFmdGVycyBhbmQgQ2FuT2NjdXJBZnRlciANCiAgICAgICANCiAgICAgIFRoZSBDYW5PY2N1 ckFmdGVycyBlbGVtZW50IGlzIGEgd3JhcHBlciB0byBob2xkIHRoZSBtdWx0aXBsZSANCiAgICAg IG9jY3VycmVuY2VzIG9mIHRoZSBDYW5PY2N1ckFmdGVyIHBlcm1pc3NpYmxlIHBsYWNlbWVudCAN CiAgICAgIGluZm9ybWF0aW9uLiANCiAgICAgICANCiAgICAgIFRoZSBDYW5PY2N1ckFmdGVyIGVs ZW1lbnQgZGVzY3JpYmVzIGEgcGVybWlzc2libGUgcG9zaXRpb25pbmcgb2YgDQogICAgICB0aGUg U3VwcG9ydGVkTEZCLiAgU3BlY2lmaWNhbGx5LCBpdCBuYW1lcyBhbiBMRkIgdGhhdCBjYW4gDQog ICAgICB0b3BvbG9naWNhbGx5IHByZWNlZGUgdGhlIFN1cHBvcnRlZExGQi4gIFRoYXQgaXMsIHRo ZSBTdXBwb3J0ZWRMRkIgDQogICAgICBjYW4gaGF2ZSBhbiBpbnB1dCBwb3J0IGNvbm5lY3RlZCB0 byBhbiBvdXRwdXQgcG9ydCBvZiB0aGUgTEZCIHRoYXQgDQogICAgICBpdCBDYW5PY2N1ckFmdGVy LiAgVGhlIExGQiBjbGFzcyB0aGF0IHRoZSBTdXBwb3J0ZWRMRkIgY2FuIGZvbGxvdyANCiAgICAg IGlzIGlkZW50aWZpZWQgYnkgdGhlIE5laWdoYm9yTEZCIGVsZW1lbnQgb2YgdGhlIENhbk9jY3Vy QWZ0ZXIgDQogICAgICBlbGVtZW50LiAgSWYgdGhpcyBuZWlnaGJvciBjYW4gb25seSBiZSBjb25u ZWN0ZWQgdG8gYSBzcGVjaWZpYyBzZXQgDQogICAgICBvZiBpbnB1dCBwb3J0IGdyb3VwcywgdGhl biB0aGUgdmlhUG9ydCBlbGVtZW50IGlzIGluY2x1ZGVkLiAgVGhpcyANCiAgICAgIGVsZW1lbnQg b2NjdXJzIG9uY2UgZm9yIGVhY2ggaW5wdXQgcG9ydCBncm91cCBvZiB0aGUgU3VwcG9ydGVkTEZC IA0KICAgICAgdGhhdCBjYW4gYmUgY29ubmVjdGVkIHRvIGFuIG91dHB1dCBwb3J0IG9mIHRoZSBO ZWlnaGJvckxGQi4gDQogICAgICAgDQogICAgICBbZS5nLiwgV2l0aGluIGEgU3VwcG9ydGVkTEZC IGVsZW1lbnQsIGVhY2ggQ2FuT2NjdXJBZnRlciBlbGVtZW50IA0KICAgICAgbXVzdCBoYXZlIGEg dW5pcXVlIE5laWdoYm9yTEZCLCBhbmQgd2l0aGluIGVhY2ggQ2FuT2NjdXJBZnRlciANCiAgICAg IGVsZW1lbnQgZWFjaCB2aWFQb3J0IG11c3QgcmVwcmVzZW50IGEgdW5pcXVlIGFuZCB2YWxpZCBp bnB1dCBwb3J0IA0KICAgICAgZ3JvdXAgb2YgdGhlIFN1cHBvcnRlZExGQi4gIFRoZSAidW5pcXVl IiBjbGF1c2VzIGZvciB0aGlzIGhhdmUgbm90IA0KICAgICAgeWV0IGJlZW4gYWRkZWQgdG8gdGhl IHNjaGVtYS5dIA0KICAgICAgIA0KICAgNS4yLjEuMi41LiBDYW5PY2N1ckJlZm9yZXMgYW5kIENh bk9jY3VyQmVmb3JlIA0KICAgICAgIA0KICAgICAgVGhlIENhbk9jY3VyQmVmb3JlcyBlbGVtZW50 IGlzIGEgd3JhcHBlciB0byBob2xkIHRoZSBtdWx0aXBsZSANCiAgICAgIG9jY3VycmVuY2VzIG9m IHRoZSBDYW5PY2N1ckJlZm9yZSBwZXJtaXNzaWJsZSBwbGFjZW1lbnQgDQogICAgICBpbmZvcm1h dGlvbi4gDQogICAgICAgDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3NF0gDQoMICAgSW50ZXJuZXQg RHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0K ICAgIA0KICAgIA0KICAgICAgVGhlIENhbk9jY3VyQmVmb3JlIGVsZW1lbnQgc2ltaWxhcmx5IGxp c3RzIHRob3NlIExGQiBjbGFzc2VzIHRoYXQgDQogICAgICB0aGUgU3VwcG9ydGVkTEZCIG1heSBw cmVjZWRlIGluIHRoZSB0b3BvbG9neS4gIEluIHRoaXMgZWxlbWVudCwgDQogICAgICB0aGUgDQog ICAgICB2aWFQb3J0IGVsZW1lbnQgcmVwcmVzZW50cyB0aGUgb3V0cHV0IHBvcnQgZ3JvdXAgb2Yg dGhlIA0KICAgICAgU3VwcG9ydGVkTEZCIHRoYXQgbWF5IGJlIGNvbm5lY3RlZCB0byB0aGUgTmVp Z2hib3JMRkIuICBBcyB3aXRoIA0KICAgICAgQ2FuT2NjdXJBZnRlciwgdmlhUG9ydCBtYXkgb2Nj dXIgbXVsdGlwbGUgdGltZXMgaWYgbXVsdGlwbGUgb3V0cHV0IA0KICAgICAgcG9ydHMgbWF5IGxl Z2l0aW1hdGVseSBjb25uZWN0IHRvIHRoZSBnaXZlbiBOZWlnaGJvckxGQiBjbGFzcy4gDQogICAg ICAgDQogICAgICBbQW5kIGEgc2ltaWxhciBzZXQgb2YgdW5pcXVlbmVzcyBjb25zdHJhaW50cyBh cHBseSB0byB0aGUgDQogICAgICBDYW5PY2N1ckJlZm9yZSBjbGF1c2VzLCBldmVuIHRob3VnaCBh biBMRkIgbWF5IG9jY3VyIGJvdGggaW4gDQogICAgICBDYW5PY2N1ckFmdGVyIGFuZCBDYW5PY2N1 ckJlZm9yZS5dIA0KICAgICAgIA0KICAgNS4yLjEuMi42LiBMRkJDbGFzc0NhcGFiaWxpdGllcyAN CiAgICAgICANCiAgICAgIFRoaXMgZWxlbWVudCBjb250YWlucyBjYXBhYmlsaXR5IGluZm9ybWF0 aW9uIGFib3V0IHRoZSBzdWJqZWN0IExGQiANCiAgICAgIGNsYXNzIHdob3NlIHN0cnVjdHVyZSBh bmQgc2VtYW50aWNzIGFyZSBkZWZpbmVkIGJ5IHRoZSBMRkIgY2xhc3MgDQogICAgICBkZWZpbml0 aW9uLiAgDQogICAgICAgDQogICA1LjIuMS4zLiBTdXBwb3J0ZWRBdHRyaWJ1dGVzIA0KICAgICAg IA0KICAgICAgVGhpcyBlbGVtZW50IHNlcnZlcyBhcyBhIHdyYXBwZXIgdG8gaG9sZCB0aGUgaW5m b3JtYXRpb24gYWJvdXQgDQogICAgICBhdHRyaWJ1dGVkIHJlbGF0ZWQgY2FwYWJpbGl0aWVzLiAg U3BlY2lmaWNhbGx5LCBhdHRyaWJ1dGVzIHNob3VsZCANCiAgICAgIGJlIGRlc2NyaWJlZCBpbiB0 aGlzIGVsZW1lbnQgaWY6IA0KICAgICAgICBhKSB0aGV5IGFyZSBvcHRpb25hbCBlbGVtZW50cyBp biB0aGUgc3RhbmRhcmQgYW5kIGFyZSBzdXBwb3J0ZWQgDQogICAgICAgICAgIGJ5IHRoZSBGRSwg b3IgDQogICAgICAgIGIpIHRoZSBzdGFuZGFyZCBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2YgYWNjZXNz IHBlcm1pc3Npb25zIChmb3IgDQogICAgICAgICAgIGV4YW1wbGUsIHJlYWQtb25seSBvciByZWFk LXdyaXRlKS4gDQogICAgDQogICAgICBFYWNoIGF0dHJpYnV0ZSBzbyBkZXNjcmliZWQgaXMgY29u dGFpbmVkIGluIHRoZSANCiAgICAgIFN1cHBvcnRlZEF0dHJpYnV0ZXMgZWxlbWVudC4gIFRoYXQg ZWxlbWVudCBjb250YWlucyBhbiANCiAgICAgIEF0dHJpYnV0ZU5hbWUgZWxlbWVudCB3aG9zZSB2 YWx1ZSBpcyB0aGUgbmFtZSBvZiB0aGUgZWxlbWVudCBiZWluZyANCiAgICAgIGRlc2NyaWJlZCBh bmQgYW4gQWNjZXNzTW9kZXMgZWxlbWVudCwgd2hvc2UgdmFsdWUgaXMgdGhlIGxpc3Qgb2YgDQog ICAgICBwZXJtaXNzaW9ucy4gDQogICAgDQogICA1LjIuMi4gRkVBdHRyaWJ1dGVzIA0KICAgICAg IA0KICAgICAgVGhlIEZFQXR0cmlidXRlcyBlbGVtZW50IGNvbnRhaW5zIHRoZSBhdHRyaWJ1dGVz IG9mIHRoZSBGRSB0aGF0IA0KICAgICAgYXJlIG5vdCBjb25zaWRlcmVkICJjYXBhYmlsaXRpZXMi LiAgU29tZSBvZiB0aGVzZSBhdHRyaWJ1dGVzIGFyZSANCiAgICAgIHdyaXRlYWJsZSwgYW5kIHNv bWUgYXJlIHJlYWQtb25seSwgd2hpY2ggc2hvdWxkIGJlIGluZGljYXRlZCBieSANCiAgICAgIHRo ZSBjYXBhYmlsaXR5IGluZm9ybWF0aW9uLiAgQXQgdGhlIG1vbWVudCwgdGhlIHNldCBvZiBhdHRy aWJ1dGVzIA0KICAgICAgaXMgd29lZnVsbHkgaW5jb21wbGV0ZS4gIEVhY2ggYXR0cmlidXRlIGlz IGlkZW50aWZpZWQgYnkgYSB1bmlxdWUgDQogICAgICBlbGVtZW50IHRhZywgYW5kIHRoZSB2YWx1 ZSBvZiB0aGUgZWxlbWVudCBpcyB0aGUgdmFsdWUgb2YgdGhlIA0KICAgICAgYXR0cmlidXRlLiAN CiAgICAgICANCiAgIDUuMi4yLjEuIEZFU3RhdHVzIA0KICAgICAgIA0KDQogICAgDQogICBZYW5n LCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgNzVdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAg ICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoaXMgYXR0cmlidXRl IGNhcnJpZXMgdGhlIG92ZXJhbGwgc3RhdGUgb2YgdGhlIEZFLiAgRm9yIG5vdywgaXQgDQogICAg ICBpcyByZXN0cmljdGVkIHRvIHRoZSBzdHJpbmdzIEFkbWluRGlzYWJsZSwgT3BlckRpc2FibGUg YW5kIA0KICAgICAgT3BlckVuYWJsZS4gDQogICAgICAgDQogICA1LjIuMi4yLkxGQkluc3RhbmNl cyBhbmQgTEZCSW5zdGFuY2UgDQogICAgICAgDQogICAgICBUaGUgTEZCSW5zdGFuY2VzIGVsZW1l bnQgc2VydmVzIGFzIGEgd3JhcHBlciB0byBob2xkIHRoZSBtdWx0aXBsZSANCiAgICAgIG9jY3Vy cmVuY2VzIG9mIHRoZSBMRkJJbnN0YW5jZSBpbmZvcm1hdGlvbiBhYm91dCBpbmRpdmlkdWFsIExG QiANCiAgICAgIGluc3RhbmNlcyBvbiB0aGUgRkUuIA0KICAgICAgIA0KICAgICAgRWFjaCBvY2N1 cnJlbmNlIG9mIHRoZSBMRkJJbnN0YW5jZSBlbGVtZW50IGRlc2NyaWJlcyBhIHNpbmdsZSBMRkIg DQogICAgICBpbnN0YW5jZS4gIEVhY2ggZWxlbWVudCBjb250YWlucyBhbiBMRkJDbGFzc05hbWUg aW5kaWNhdGluZyB3aGF0IA0KICAgICAgY2xhc3MgdGhpcyBpbnN0YW5jZSBoYXMsIGFuZCBhbiBM RkJJbnN0YW5jZUlEIGluZGljYXRpbmcgdGhlIElEIA0KICAgICAgdXNlZCBmb3IgcmVmZXJyaW5n IHRvIHRoaXMgaW5zdGFuY2UuICBGb3Igbm93LCB0aGUgSUQgdXNlcyB0aGUgDQogICAgICBOTVRP S0VOIGNvbnN0cnVjdGlvbi4gIEZ1cnRoZXIgcHJvdG9jb2wgd29yayBpcyBsaWtlbHkgdG8gcmVw bGFjZSANCiAgICAgIHRoaXMgd2l0aCBhIHJhbmdlIHJlc3RyaWN0ZWQgaW50ZWdlci4gDQogICAg ICAgDQogICA1LjIuMi4zLiBMRkJUb3BvbG9neSBhbmQgTEZCTGluayANCiAgICAgICANCiAgICAg IFRoaXMgb3B0aW9uYWwgZWxlbWVudCBjb250YWlucyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgZWFj aCBpbnRlci0NCiAgICAgIExGQiBsaW5rIGluc2lkZSB0aGUgRkUuICBFYWNoIGxpbmsgaXMgZGVz Y3JpYmVkIGluIGFuIExGQkxpbmsgDQogICAgICBlbGVtZW50LiANCiAgICAgIFRoaXMgZWxlbWVu dCBjb250YWlucyBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGlkZW50aWZ5IHByZWNpc2VseSAN CiAgICAgIHRoZSBlbmQgcG9pbnRzIG9mIGEgbGluay4gIFRoZSBGcm9tTEZCSUQgYW5kIFRvTEZC SUQgZmllbGRzIA0KICAgICAgaW5kaWNhdGUgdGhlIExGQiBpbnN0YW5jZXMgYXQgZWFjaCBlbmQg b2YgdGhlIGxpbmssIGFuZCBtdXN0IA0KICAgICAgcmVmZXJlbmNlIExGQnMgaW4gdGhlIExGQiBp bnN0YW5jZSB0YWJsZS4gIFRoZSBGcm9tUG9ydEdyb3VwIGFuZCANCiAgICAgIFRvUG9ydEdyb3Vw IG11c3QgaWRlbnRpZnkgb3V0cHV0IGFuZCBpbnB1dCBwb3J0IGdyb3VwcyBkZWZpbmVkIGluIA0K ICAgICAgdGhlIExGQiBjbGFzc2VzIG9mIHRoZSBMRkIgaW5zdGFuY2VzIGlkZW50aWZpZWQgYnkg dGhlIEZyb21MRkJJRCANCiAgICAgIGFuZCBUb0xGQklELiAgVGhlIEZyb21Qb3J0SW5kZXggYW5k IFRvUG9ydEluZGV4IGZpZWxkcyBzZWxlY3QgdGhlIA0KICAgICAgZWxlbWVudHMgZnJvbSB0aGUg cG9ydCBncm91cHMgdGhhdCB0aGlzIGxpbmsgY29ubmVjdHMuICBBbGwgbGlua3MgDQogICAgICBh cmUgdW5pcXVlbHkgaWRlbnRpZmllZCBieSB0aGUgRnJvbUxGQklELCBGcm9tUG9ydEdyb3VwLCBh bmQgDQogICAgICBGcm9tUG9ydEluZGV4IGZpZWxkcy4gIE11bHRpcGxlIGxpbmtzIG1heSBoYXZl IHRoZSBzYW1lIFRvTEZCSUQsIA0KICAgICAgVG9Qb3J0R3JvdXAsIGFuZCBUb1BvcnRJbmRleCBh cyB0aGlzIG1vZGVsIHN1cHBvcnRzIGZhbiBpbiBvZiANCiAgICAgIGludGVyLUxGQiBsaW5rcyBi dXQgbm90IGZhbiBvdXQuIA0KICAgICAgIA0KICAgNS4yLjIuNC4gRkVDb25maWd1cmVkTmVpZ2hi b3JzIGFuIEZFQ29uZmlndXJlZE5laWdoYm9yIA0KICAgICAgIA0KICAgICAgVGhlIEZFQ29uZmln dXJlZE5laWdoYm9ycyBlbGVtZW50IGlzIGEgd3JhcHBlciB0byBob2xkIHRoZSANCiAgICAgIGNv bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhhdCBvbmUgb3IgbW9yZSBGRUNvbmZpZ3VyZWROZWln aGJvciANCiAgICAgIGVsZW1lbnRzIGNvbnZleSBhYm91dCB0aGUgY29uZmlndXJlZCBGRSB0b3Bv bG9neS4gDQogICAgICAgDQogICAgICBUaGUgRkVDb25maWd1cmVkTmVpZ2hib3IgZWxlbWVudCBv Y2N1cnMgb25jZSBmb3IgZWFjaCBjb25maWd1cmVkIA0KICAgICAgRkUgbmVpZ2hib3IgdGhlIEZF IGtub3dzIGFib3V0LiAgSXQgc2hvdWxkIG5vdCBiZSBmaWxsZWQgaW4gYmFzZWQgDQogICAgICBv biBGRSBsZXZlbCBwcm90b2NvbCBvcGVyYXRpb25zLiAgSW4gZ2VuZXJhbCwgbmVpZ2hib3IgZGlz Y292ZXJ5IA0KICAgICAgb3BlcmF0aW9uIG9uIHRoZSBGRSBzaG91bGQgYmUgcmVwcmVzZW50ZWQg YW5kIG1hbmlwdWxhdGVkIGFzIGFuIA0KICAgICAgTEZCLiAgSG93ZXZlciwgZm9yIEZFcyB0aGF0 IGluY2x1ZGUgbmVpZ2hib3IgZGlzY292ZXJ5IGFuZCBkbyBub3QgDQoNCiAgICANCiAgIFlhbmcs IGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSA3Nl0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgaGF2ZSBzdWNoIGFuIExG QiwgaXQgaXMgcGVybWl0dGVkIHRvIGZpbGwgaW4gdGhlIGluZm9ybWF0aW9uIGluIA0KICAgICAg dGhpcyB0YWJsZSBiYXNlZCBvbiBzdWNoIHByb3RvY29scy4gIA0KICAgICAgIA0KICAgICAgU2lt aWxhcmx5LCB0aGUgTUFDIGFkZHJlc3MgaW5mb3JtYXRpb24gaW4gdGhlIHRhYmxlIGlzIGludGVu ZGVkIHRvIA0KICAgICAgYmUgdXNlZCBpbiBzaXR1YXRpb25zIHdoZXJlIG5laWdoYm9ycyBhcmUg Y29uZmlndXJlZCBieSBNQUMgDQogICAgICBhZGRyZXNzLiAgUmVzb2x1dGlvbiBvZiBuZXR3b3Jr IGxheWVyIHRvIE1BQyBhZGRyZXNzIGluZm9ybWF0aW9uIA0KICAgICAgc2hvdWxkIGJlIGNhcHR1 cmVkIGluIEFSUCBMRkJzLCBub3QgZHVwbGljYXRlZCBpbiB0aGlzIHRhYmxlLiAgDQogICAgICBO b3RlIHRoYXQgdGhlIHNhbWUgbmVpZ2hib3IgbWF5IGJlIHJlYWNoZWQgdGhyb3VnaCBtdWx0aXBs ZSANCiAgICAgIGludGVyZmFjZXMgb3IgYXQgbXVsdGlwbGUgYWRkcmVzc2VzLiAgVGhlcmUgaXMg bm8gdW5pcXVlbmVzcyANCiAgICAgIHJlcXVpcmVtZW50IG9mIGFueSBzb3J0IG9uIG9jY3VycmVu Y2VzIG9mIHRoZSBGRUNvbmZpZ3VyZWROZWlnaGJvciANCiAgICAgIGVsZW1lbnQuIA0KICAgICAg IA0KICAgICAgSW5mb3JtYXRpb24gYWJvdXQgdGhlIGludGVuZGVkIGZvcm1zIG9mIGV4Y2hhbmdl IHdpdGggYSBnaXZlbiANCiAgICAgIG5laWdoYm9yIGlzIG5vdCBjYXB0dXJlZCBoZXJlLCBvbmx5 IHRoZSBhZGphY2VuY3kgaW5mb3JtYXRpb24gaXMgDQogICAgICBpbmNsdWRlZC4gDQogICAgICAg DQogICA1LjIuMi40LjEuTmVpZ2hib3JJRCANCiAgICAgICANCiAgICAgIFRoaXMgaXMgdGhlIElE IGluIHNvbWUgc3BhY2UgbWVhbmluZ2Z1bCB0byB0aGUgQ0UgZm9yIHRoZSANCiAgICAgIG5laWdo Ym9yLiAgSWYgdGhpcyB0YWJsZSByZW1haW5zLCB3ZSBwcm9iYWJseSBzaG91bGQgYWRkIGFuIEZF SUQgDQogICAgICBmcm9tIHRoZSBzYW1lIHNwYWNlIGFzIGFuIGF0dHJpYnV0ZSBvZiB0aGUgRkUu IA0KICAgICAgIA0KICAgNS4yLjIuNC4yLk5laWdoYm9ySW50ZXJmYWNlIA0KICAgICAgIA0KICAg ICAgVGhpcyBpZGVudGlmaWVzIHRoZSBpbnRlcmZhY2UgdGhyb3VnaCB3aGljaCB0aGUgbmVpZ2hi b3IgaXMgDQogICAgICByZWFjaGVkLiANCiAgICAgICANCiAgICAgIFtFZGl0b3JzIG5vdGU6IEFz IHRoZSBwb3J0IHN0cnVjdHVyZXMgYmVjb21lIGJldHRlciBkZWZpbmVkLCB0aGUgDQogICAgICB0 eXBlIGZvciB0aGlzIHNob3VsZCBiZSBmaWxsZWQgaW4gd2l0aCB0aGUgdHlwZXMgbmVjZXNzYXJ5 IHRvIA0KICAgICAgcmVmZXJlbmNlIHRoZSB2YXJpb3VzIHBvc3NpYmxlIG5laWdoYm9yIGludGVy ZmFjZXMsIGluY2x1ZGUgDQogICAgICBwaHlzaWNhbCBpbnRlcmZhY2VzLCBsb2dpY2FsIHR1bm5l bHMsIHZpcnR1YWwgY2lyY3VpdHMsIGV0Yy5dIA0KICAgICAgIA0KICAgNS4yLjIuNC4zLiBOZWln aGJvck5ldHdvcmtBZGRyZXNzIA0KICAgICAgIA0KICAgICAgTmVpZ2hib3IgY29uZmlndXJhdGlv biBpcyBmcmVxdWVudGx5IGRvbmUgb24gdGhlIGJhc2lzIG9mIGEgDQogICAgICBuZXR3b3JrIGxh eWVyIGFkZHJlc3MuICBGb3IgbmVpZ2hib3JzIGNvbmZpZ3VyZWQgaW4gdGhhdCBmYXNoaW9uLCAN CiAgICAgIHRoaXMgaXMgd2hlcmUgdGhhdCBhZGRyZXNzIGlzIHN0b3JlZC4gDQogICAgICAgDQog ICA1LjIuMi40LjQuTmVpZ2hib3JNYWNBZGRyZXNzIA0KICAgICAgIA0KICAgICAgTmVpZ2hib3Jz IGFyZSBzb21ldGltZXMgY29uZmlndXJlZCB1c2luZyBNQUMgbGV2ZWwgYWRkcmVzc2VzIA0KICAg ICAgKEV0aGVybmV0IE1BQyBhZGRyZXNzLCBjaXJjdWl0IGlkZW50aWZpZXJzLCBldGMuKSAgSWYg c3VjaCANCiAgICAgIGFkZHJlc3NlcyBhcmUgdXNlZCB0byBjb25maWd1cmUgdGhlIGFkamFjZW5j eSwgdGhlbiB0aGF0IA0KICAgICAgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGhlcmUuICBOb3RlIHRo YXQgb3ZlciBzb21lIHBvcnRzIHN1Y2ggYXMgDQogICAgICBwaHlzaWNhbCBwb2ludCB0byBwb2lu dCBsaW5rcyBvciB2aXJ0dWFsIGNpcmN1aXRzIGNvbnNpZGVyZWQgYXMgDQogICAgICBpbmRpdmlk dWFsIGludGVyZmFjZXMsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGVpdGhlciBmb3JtIG9mIA0KICAg ICAgYWRkcmVzcy4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAy MDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNzddIA0KDCAgIEludGVybmV0IERyYWZ0 ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICAN CiAgICANCiAgICAgICANCiAgIDUuMy4gU2FtcGxlIEZFIEF0dHJpYnV0ZSBEb2N1bWVudCANCiAg ICAgICANCiAgICAgIDw/eG1sIHZlcnNpb249IjEuMCI+IA0KICAgICAgPGZtOkZFRG9jdW1lbnQg eG1sbnM6Zm09Imh0dHA6Ly93d3cuaWV0Zi5vcmcvLi4udGhlc2NoZW1hLi4uIj4gDQogICAgICAg DQogICAgICAgPGZtOkZFQ2FwYWJpbGl0aWVzPiANCiAgICAgICANCiAgICAgICAgPGZtOk1vZGlm aWFibGVMRkJUb3BvbG9neT4gdHJ1ZSA8L2ZtOk1vZGlmaWFibGVMRkJUb3BvbG9neT4gDQogICAg ICAgDQogICAgICAgIDxmbTpTdXBwb3J0ZWRMRkJzPiANCiAgICAgICAgIDxmbTpTdXBwb3J0ZWRM RkI+IA0KICAgICAgICAgIDwhLS0gQSBzaW1wbGUgc2luZ2xlLWlucHV0IG11bHRpLW91dHB1dCBj bGFzc2lmaWVyIC0tPiANCiAgICAgICAgICA8Zm06TEZCTmFtZT4gQ2xhc3NpZmllciA8L2ZtOkxG Qk5hbWU+IA0KICAgICAgICAgIDxmbTpMRkJPY2N1cnJlbmNlTGltaXQ+IDMgPC9mbTpMRkJPY2N1 cnJlbmNlTGltaXQ+IA0KICAgIA0KICAgICAgICAgIDxmbTpQb3J0R3JvdXBMaW1pdHM+IA0KICAg ICAgICAgICA8Zm06UG9ydEdyb3VwTGltaXQ+IA0KICAgICAgICAgICAgPCEtLSBUaGUgaW5wdXQg cG9ydCAtLT4gDQogICAgICAgICAgICA8Zm06UG9ydEdyb3VwTmFtZT4gSW5wdXRQb3J0R3JvdXAg PC9mbTpQb3J0R3JvdXBOYW1lPiANCiAgICAgICAgICAgIDxmbTpNaW5Qb3J0Q291bnQ+IDEgPC9m bTpNaW5Qb3J0Q291bnQ+IA0KICAgICAgICAgICAgPGZtOk1heFBvcnRDb3VudD4gMSA8L2ZtOk1h eFBvcnRDb3VudD4gDQogICAgICAgICAgIDwvZm06UG9ydEdyb3VwTGltaXQ+IA0KICAgICAgICAg ICA8Zm06UG9ydEdyb3VwTGltaXQ+IA0KICAgICAgICAgICA8IS0tVGhlIG5vcm1hbCBvdXRwdXQg cG9ydHMgLS0+IA0KICAgICAgICAgICA8Zm06UG9ydEdyb3VwTmFtZT4gT3V0cHV0UG9ydEdyb3Vw IDwvZm06UG9ydEdyb3VwTmFtZT4gDQogICAgICAgICAgICA8Zm06TWluUG9ydENvdW50PiAwIDwv Zm06TWluUG9ydENvdW50PiANCiAgICAgICAgICAgIDxmbTpNYXhQb3J0Q291bnQ+IDMyIDwvZm06 TWF4UG9ydENvdW50PiANCiAgICAgICAgICAgPC9mbTpQb3J0R3JvdXBMaW1pdD4gDQogICAgICAg ICAgIDxmbTpQb3J0R3JvdXBMaW1pdD4gDQogICAgICAgICAgICA8IS0tIFRoZSBvcHRpb25hbCBl cnJvciBwb3J0IC0tPiANCiAgICAgICAgICAgIDxmbTpQb3J0R3JvdXBOYW1lPiBFcnJvclBvcnRH cm91cCA8L2ZtOlBvcnRHcm91cE5hbWU+IA0KICAgICAgICAgICAgPGZtOk1pblBvcnRDb3VudD4g MCA8L2ZtOk1pblBvcnRDb3VudD4gDQogICAgICAgICAgICA8Zm06TWF4UG9ydENvdW50PiAxIDwv Zm06TWF4UG9ydENvdW50PiANCiAgICAgICAgICAgPC9mbTpQb3J0R3JvdXBMaW1pdD4gDQogICAg ICAgICAgPC9mbTpQb3J0R3JvdXBMaW1pdHM+ICAgIA0KICAgICAgICAgIDxmbTpDYW5PY2N1ckFm dGVycz4gDQogICAgICAgICAgIDxmbTpDYW5PY2N1ckFmdGVyPiANCiAgICAgICAgICAgIDxmbTpO ZWlnaGJvckxGQj4gUG9ydCA8L2ZtOk5laWdoYm9yTEZCPiANCiAgICAgICAgICAgIDwhLS0gb21p dHRlZCB2aWFQb3J0IC0tPiANCiAgICAgICAgICAgPC9mbTpDYW5PY2N1ckFmdGVyPiANCiAgICAg ICAgICAgPGZtOkNhbk9jY3VyQWZ0ZXIgDQogICAgICAgICAgICA8Zm06TmVpZ2hib3JMRkI+IElu dGVybmFsU291cmNlIDwvZm06TmVpZ2hib3JMRkI+IA0KICAgICAgICAgICAgPCEtLSBvbWl0dGVk IHZpYVBvcnQgLS0+IA0KICAgICAgICAgICA8L2ZtOkNhbk9jY3VyQWZ0ZXI+IA0KICAgICAgICAg IDwvZm06Q2FuT2NjdXJBZnRlcnM+IA0KICAgICAgICAgIDxmbTpDYW5PY2N1ckJlZm9yZXM+IA0K ICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDc4XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNF UyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAg ICAgIDxmbTpDYW5PY2N1ckJlZm9yZT4gDQogICAgICAgICAgICA8Zm06TmVpZ2hib3JMRkI+IE1h cmtlciA8L2ZtOk5laWdoYm9yTEZCPiANCiAgICAgICAgICAgIDwhLS0gb21pdHRlZCB2aWFQb3J0 IC0tPiANCiAgICAgICAgICAgPC9mbTpDYW5PY2N1ckJlZm9yZT4gDQogICAgICAgICAgPC9mbTpD YW5PY2N1ckJlZm9yZXM+IA0KICAgICAgICAgPC9mbTpTdXBwb3J0ZWRMRkI+IA0KICAgICAgICAg PCEtLSB0aGVuIFN1cHBvcnRlZCBMRkIgZWxlbWVudHMgZm9yIFBvcnQsIEludGVybmFsU291cmNl IC0tPiANCiAgICAgICAgIDwhLS0gICAgICBNYXJrZXIsIC4uLiAtLT4gDQogICAgICAgIDwvZm06 U3VwcG9ydGVkTEZCcz4gDQogICAgICAgDQogICAgICAgIDxmbTpTdXBwb3J0ZWRBdHRyaWJ1dGVz PiANCiAgICAgICAgIDxmbTpTdXBwb3J0ZWRBdHRyaWJ1dGU+IA0KICAgICAgICAgIDxmbTpBdHRy aWJ1dGVOYW1lPiBGRVN0YXR1cyAgPC9mbTpBdHRyaWJ1dGVOYW1lPiANCiAgICAgICAgICA8Zm06 QWNjZXNzTW9kZXM+ICByZWFkIHdyaXRlIDwvZm06QWNjZXNzTW9kZXM+IA0KICAgICAgICAgPC9m bTpTdXBwb3J0ZWRBdHRyaWJ1dGU+IA0KICAgICAgICAgPGZtOlN1cHBvcnRlZEF0dHJpYnV0ZT4g DQogICAgICAgICAgPGZtOkF0dHJpYnV0ZU5hbWU+ICBWZW5kb3IgICA8L2ZtOkF0dHJpYnV0ZU5h bWU+IA0KICAgICAgICAgIDxmbTpBY2Nlc3NNb2Rlcz4gICAgcmVhZCAgICAgPC9mbTpBY2Nlc3NN b2Rlcz4gDQogICAgICAgICA8L2ZtOlN1cHBvcnRlZEF0dHJpYnV0ZSANCiAgICAgICAgIDxmbTpT dXBwb3J0ZWRBdHRyaWJ1dGU+IA0KICAgICAgICAgIDxmbTpBdHRyaWJ1dGVOYW1lPiAgTW9kZWwg ICAgPC9mbTpBdHRyaWJ1dGVOYW1lPiANCiAgICAgICAgICA8Zm06QWNjZXNzTW9kZXM+ICAgIHJl YWQgICAgIDwvZm06QWNjZXNzTW9kZXM+IA0KICAgICAgICAgPC9mbTpTdXBwb3J0ZWRBdHRyaWJ1 dGU+IA0KICAgICAgICA8L2ZtOlN1cHBvcnRlZEF0dHJpYnV0ZXM+IA0KICAgICAgIDwvZm06RkVD YXBhYmlsaXRpZXM+IA0KICAgICAgIA0KICAgICAgIDxmbTpGRUF0dHJpYnV0ZXM+IA0KICAgICAg ICA8Zm06VmVuZG9yPiBXb3JsZCBXaWRlIFdpZGdldHMgPC9mbTpWZW5kb3I+IA0KICAgICAgICA8 Zm06TW9kZWw+IEZvbyBGb3J3YXJkIE1vZGVsIDYgPC9mbTpNb2RlbD4gDQogICAgICAgIDxmbTpG RVN0YXR1cz4gICAgICAgT3BlckVuYWJsZSA8L2ZtOkZFU3RhdHVzPiANCiAgICAgICAgPGZtOkxG Qkluc3RhbmNlcz4gDQogICAgICAgICA8Zm06TEZCSW5zdGFuY2U+IA0KICAgICAgICAgIDxmbTpM RkJDbGFzc05hbWU+IENsYXNzaWZpZXIgPC9mbTpMRkJDbGFzc05hbWU+IA0KICAgICAgICAgIDxm bTpMRkJJbnN0YW5jZUlEPiBJbnN0NSAgICAgPC9mbTpMRkJJbnN0YW5jZUlEPiANCiAgICAgICAg IDwvZm06TEZCSW5zdGFuY2U+IA0KICAgICAgICAgPGZtOkxGQkluc3RhbmNlPiANCiAgICAgICAg ICA8Zm06TEZCQ2xhc3NOYW1lPiBJbnRlcmZhY2UgIDwvZm06TEZCQ2xhc3NOYW1lPiANCiAgICAg ICAgICA8Zm06TEZCSW5zdGFuY2VJRD4gSW5zdDExICAgIDwvZm06TEZCSW5zdGFuY2VJRD4gDQog ICAgICAgICA8L2ZtOkxGQkluc3RhbmNlPiANCiAgICAgICAgIDxmbTpMRkJJbnN0YW5jZT4gDQog ICAgICAgICAgPGZtOkxGQkNsYXNzTmFtZT4gTWV0ZXIgICAgICA8L2ZtOkxGQkNsYXNzTmFtZT4g DQogICAgICAgICAgPGZtOkxGQkluc3RhbmNlSUQ+IEluc3QxNyAgICA8L2ZtOkxGQkluc3RhbmNl SUQ+IA0KICAgICAgICAgPC9mbTpMRkJJbnN0YW5jZT4gDQogICAgICAgIDwvZm06TEZCSW50YW5j ZXM+IA0KICAgICAgICA8Zm06TEZCVG9wb2xvZ3k+IA0KICAgICAgICAgPGZtOkxGQkxpbms+IA0K ICAgICAgICAgIDxmbTpGcm9tTEZCSUQ+ICAgSW5zdDExICAgICAgPC9mbTpmcm9tTEZCSUQ+IA0K ICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDc5XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNF UyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAg ICAgPGZtOkZyb21Qb3J0R3JvdXA+IElGT253YXJkR3JvdXAgPC9mbTpGcm9tUG9ydEdyb3VwPiAN CiAgICAgICAgICA8Zm06RnJvbVBvcnRJbmRleD4gMSAgICAgICAgIDwvZm06RnJvbVBvcnRJbmRl eD4gDQogICAgICAgICAgPGZtOlRvTEZCSUQ+ICAgICBJbnN0NSAgICAgICA8L2ZtOlRvTEZCSUQ+ IA0KICAgICAgICAgIDxmbTpUb1BvcnRHcm91cD4gSW5wdXRQb3J0R3JvdXAgPC9mbTpUb1BvcnRH cm91cD4gDQogICAgICAgICAgPGZtOlRvUG9ydEluZGV4PiAxICAgICAgICAgICA8L2ZtOlRvUG9y dEluZGV4PiANCiAgICAgICAgIDwvZm06TEZCTGluaz4gDQogICAgICAgICA8Zm06TEZCTGluaz4g DQogICAgICAgICAgPGZtOkZyb21MRkJJRD4gICBJbnN0NSAgICAgICA8L2ZtOmZyb21MRkJJRD4g DQogICAgICAgICAgPGZtOkZyb21Qb3J0R3JvdXA+IE91dHB1dEdyb3VwIDwvZm06RnJvbVBvcnRH cm91cD4gDQogICAgICAgICAgPGZtOkZyb21Qb3J0SW5kZXg+IDEgICAgICAgICA8L2ZtOkZyb21Q b3J0SW5kZXg+IA0KICAgICAgICAgIDxmbTpUb0xGQklEPiAgICAgSW5zdDE3ICAgICAgIDwvZm06 VG9MRkJJRD4gDQogICAgICAgICAgPGZtOlRvUG9ydEdyb3VwPiBJbk1ldGVyR3JvdXAgPC9mbTpU b1BvcnRHcm91cD4gDQogICAgICAgICAgPGZtOlRvUG9ydEluZGV4PiAxICAgICAgICAgICA8L2Zt OlRvUG9ydEluZGV4PiANCiAgICAgICAgIDwvZm06TEZCTGluaz4gDQogICAgICAgIDwvZm06TEZC VG9wb2xvZ3k+IA0KICAgICAgIDwvZm06RkVBdHRyaWJ1dGVzPiANCiAgICAgIDwvZm06RkVEb2N1 bWVudD4gDQogICAgDQogICA2LiANICAgICBTYXRpc2Z5aW5nIHRoZSBSZXF1aXJlbWVudHMgb24g RkUgTW9kZWwgDQogICAgDQogICAgICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0aGUgcHJv cG9zZWQgRkUgbW9kZWwgbWVldHMgdGhlIA0KICAgICAgcmVxdWlyZW1lbnRzIG91dGxpbmVkIGlu IFNlY3Rpb24gNSBvZiBSRkMgMzY1NCBbMV0uICBUaGUgDQogICAgICByZXF1aXJlbWVudHMgY2Fu IGJlIHNlcGFyYXRlZCBpbnRvIGdlbmVyYWwgcmVxdWlyZW1lbnRzIChTZWN0aW9ucyANCiAgICAg IDUsIDUuMSAtIDUuNCkgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBtaW5pbWFsIHNldCBv ZiBsb2dpY2FsIA0KICAgICAgZnVuY3Rpb25zIHRoYXQgdGhlIEZFIG1vZGVsIG11c3Qgc3VwcG9y dCAoU2VjdGlvbiA1LjUpLiAgDQogICAgICAgDQogICAgICBUaGUgZ2VuZXJhbCByZXF1aXJlbWVu dCBvbiB0aGUgRkUgbW9kZWwgaXMgdGhhdCBpdCBiZSBhYmxlIHRvIA0KICAgICAgZXhwcmVzcyB0 aGUgbG9naWNhbCBwYWNrZXQgcHJvY2Vzc2luZyBjYXBhYmlsaXR5IG9mIHRoZSBGRSwgDQogICAg ICB0aHJvdWdoIGJvdGggYSBjYXBhYmlsaXR5IGFuZCBhIHN0YXRlIG1vZGVsLiAgSW4gYWRkaXRp b24sIHRoZSBGRSANCiAgICAgIG1vZGVsIGlzIGV4cGVjdGVkIHRvIGFsbG93IGZsZXhpYmxlIGlt cGxlbWVudGF0aW9ucyBhbmQgYmUgDQogICAgICBleHRlbnNpYmxlIHRvIGFsbG93IGRlZmluaW5n IG5ldyBsb2dpY2FsIGZ1bmN0aW9ucy4gDQogICAgDQogICAgICBBIG1ham9yIGNvbXBvbmVudCBv ZiB0aGUgcHJvcG9zZWQgRkUgbW9kZWwgaXMgdGhlIExvZ2ljYWwgDQogICAgICBGdW5jdGlvbiBC bG9jayAoTEZCKSBtb2RlbC4gIEVhY2ggZGlzdGluY3QgbG9naWNhbCBmdW5jdGlvbiBpbiBhbiAN CiAgICAgIEZFIGlzIG1vZGVsZWQgYXMgYW4gTEZCLiAgT3BlcmF0aW9uYWwgcGFyYW1ldGVycyBv ZiB0aGUgTEZCIHRoYXQgDQogICAgICBtdXN0IGJlIHZpc2libGUgdG8gdGhlIENFIGFyZSBjb25j ZXB0dWFsaXplZCBhcyBMRkIgYXR0cmlidXRlcy4gIA0KICAgICAgVGhlc2UgYXR0cmlidXRlcyBl eHByZXNzIHRoZSBjYXBhYmlsaXR5IG9mIHRoZSBGRSBhbmQgc3VwcG9ydCANCiAgICAgIGZsZXhp YmxlIGltcGxlbWVudGF0aW9ucyBieSBhbGxvd2luZyBhbiBGRSB0byBzcGVjaWZ5IHdoaWNoIA0K ICAgICAgb3B0aW9uYWwgZmVhdHVyZXMgYXJlIHN1cHBvcnRlZC4gVGhlIGF0dHJpYnV0ZXMgYWxz byBpbmRpY2F0ZSANCiAgICAgIHdoZXRoZXIgdGhleSBhcmUgY29uZmlndXJhYmxlIGJ5IHRoZSBD RSBmb3IgYW4gTEZCIGNsYXNzLiAgDQogICAgICBDb25maWd1cmFibGUgYXR0cmlidXRlcyBwcm92 aWRlIHRoZSBDRSBzb21lIGZsZXhpYmlsaXR5IGluIA0KICAgICAgc3BlY2lmeWluZyB0aGUgYmVo YXZpb3Igb2YgYW4gTEZCLiAgV2hlbiBtdWx0aXBsZSBMRkJzIGJlbG9uZ2luZyANCiAgICAgIHRv IHRoZSBzYW1lIExGQiBjbGFzcyBhcmUgaW5zdGFudGlhdGVkIG9uIGFuIEZFLCBlYWNoIG9mIHRo b3NlIA0KICAgICAgTEZCcyBjb3VsZCBiZSBjb25maWd1cmVkIHdpdGggZGlmZmVyZW50IGF0dHJp YnV0ZSBzZXR0aW5ncy4gIEJ5IA0KICAgICAgcXVlcnlpbmcgdGhlIHNldHRpbmdzIG9mIHRoZSBh dHRyaWJ1dGVzIGZvciBhbiBpbnN0YW50aWF0ZWQgTEZCLCANCiAgICAgIHRoZSBDRSBjYW4gZGV0 ZXJtaW5lIHRoZSBzdGF0ZSBvZiB0aGF0IExGQi4gIA0KICAgIA0KICAgIA0KICAgWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDgwXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAg ICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBJbnN0YW50aWF0ZWQgTEZCcyBh cmUgaW50ZXJjb25uZWN0ZWQgaW4gYSBkaXJlY3RlZCBncmFwaCB0aGF0IA0KICAgICAgZGVzY3Jp YmVzIHRoZSBvcmRlcmluZyBvZiB0aGUgZnVuY3Rpb25zIHdpdGhpbiBhbiBGRS4gIFRoaXMgDQog ICAgICBkaXJlY3RlZCBncmFwaCBpcyBkZXNjcmliZWQgYnkgdGhlIHRvcG9sb2d5IG1vZGVsLiAg VGhlIA0KICAgICAgY29tYmluYXRpb24gb2YgdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIGluc3RhbnRp YXRlZCBMRkJzIGFuZCB0aGUgDQogICAgICB0b3BvbG9neSBkZXNjcmliZSB0aGUgcGFja2V0IHBy b2Nlc3NpbmcgZnVuY3Rpb25zIGF2YWlsYWJsZSBvbiANCiAgICAgIHRoZSBGRSAoY3VycmVudCBz dGF0ZSkuIA0KICAgIA0KICAgICAgQW5vdGhlciBrZXkgY29tcG9uZW50IG9mIHRoZSBGRSBtb2Rl bCBpcyB0aGUgRkUgYXR0cmlidXRlcy4gVGhlIA0KICAgICAgRkUgYXR0cmlidXRlcyBhcmUgdXNl ZCBtYWlubHkgdG8gZGVzY3JpYmUgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgDQogICAgICBGRSwg YnV0IHRoZXkgYWxzbyBjb252ZXkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEZFIHN0YXRlLiANCiAg ICAgICANCiAgICAgIFRoZSBGRSBtb2RlbCBhbHNvIGluY2x1ZGVzIGEgZGVmaW5pdGlvbiBvZiB0 aGUgbWluaW1hbCBzZXQgb2YgTEZCcyANCiAgICAgIHRoYXQgaXMgcmVxdWlyZWQgYnkgU2VjdGlv biA1LjUgb2YgUkZDIDM1NjRbMV0uICBUaGUgc2VjdGlvbnMgdGhhdCANCiAgICAgIGZvbGxvdyBw cm92aWRlIG1vcmUgZGV0YWlsIG9uIHRoZSBzcGVjaWZpY3Mgb2YgZWFjaCBvZiB0aG9zZSBMRkJz LiANCiAgICAgIE5vdGUgdGhhdCB0aGUgZGV0YWlscyBvZiB0aGUgTEZCcyBhcmUgY29udGFpbmVk IGluIGEgc2VwYXJhdGUgTEZCIA0KICAgICAgQ2xhc3MgTGlicmFyeSBkb2N1bWVudC4gW0VESVRP UiAtIG5lZWQgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIHRoYXQgDQogICAgICBkb2N1bWVudF0uIA0K ICAgICAgIA0KICAgNi4xLiBQb3J0IEZ1bmN0aW9ucyANCiAgICANCiAgICAgIFRoZSBGRSBtb2Rl bCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgYSBQb3J0IExGQiBjbGFzcyBhbmQgaXRzIA0KICAgICAg dGVjaG5vbG9neS1zcGVjaWZpYyBzdWJjbGFzc2VzIHRvIG1hcCB0aGUgcGh5c2ljYWwgcG9ydCBv ZiB0aGUgDQogICAgICBkZXZpY2UgdG8gdGhlIExGQiBtb2RlbCB3aXRoIGJvdGggc3RhdGljIGFu ZCBjb25maWd1cmFibGUgDQogICAgICBhdHRyaWJ1dGVzLiAgVGhlIHN0YXRpYyBhdHRyaWJ1dGVz IG1vZGVsIHRoZSB0eXBlIG9mIHBvcnQsIGxpbmsgDQogICAgICBzcGVlZCwgZXRjLiAgVGhlIGNv bmZpZ3VyYWJsZSBhdHRyaWJ1dGVzIG1vZGVsIHRoZSBhZGRyZXNzaW5nLCANCiAgICAgIGFkbWlu aXN0cmF0aXZlIHN0YXR1cywgZXRjLiAgDQogICAgDQogICA2LjIuIEZvcndhcmRpbmcgRnVuY3Rp b25zIA0KICAgICAgIA0KICAgICAgQmVjYXVzZSBmb3J3YXJkaW5nIGZ1bmN0aW9uIGlzIG9uZSBv ZiB0aGUgbW9zdCBjb21tb24gYW5kIA0KICAgICAgaW1wb3J0YW50IGZ1bmN0aW9ucyBpbiB0aGUg Zm9yd2FyZGluZyBwbGFuZSwgaXQgcmVxdWlyZXMgc3BlY2lhbCANCiAgICAgIGF0dGVudGlvbiBp biBtb2RlbGluZyB0byBhbGxvdyBkZXNpZ24gZmxleGliaWxpdHksIGltcGxlbWVudGF0aW9uIA0K ICAgICAgZWZmaWNpZW5jeSwgbW9kZWxpbmcgYWNjdXJhY3kgYW5kIGNvbmZpZ3VyYXRpb24gc2lt cGxpY2l0eS4gIA0KICAgICAgVG93YXJkIHRoYXQgZW5kLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0 IHRoZSBjb3JlIGZvcndhcmRpbmcgDQogICAgICBmdW5jdGlvbiBiZWluZyBtb2RlbGVkIGJ5IHRo ZSBjb21iaW5hdGlvbiBvZiB0d28gTEZCcyAtLSBMb25nZXN0IA0KICAgICAgUHJlZml4IE1hdGNo IChMUE0pIGNsYXNzaWZpZXIgTEZCIGFuZCBOZXh0IEhvcCBMRkIuIFNwZWNpYWwgaGVhZGVyIA0K ICAgICAgd3JpdGVyIExGQiAgaXMgYWxzbyBuZWVkZWQgdG8gdGFrZSBjYXJlIG9mIFRUTCBkZWNy ZW1lbnQgYW5kIA0KICAgICAgY2hlY2tzdW0gZXRjLiANCiAgICANCiAgIDYuMy4gUW9TIEZ1bmN0 aW9ucyANCiAgICAgICANCiAgICAgIFRoZSBMRkIgY2xhc3MgbGlicmFyeSBpbmNsdWRlcyBkZXNj cmlwdGlvbnMgb2YgdGhlIE1ldGVyLCBRdWV1ZSAsIA0KICAgICAgU2NoZWR1bGVyLCBDb3VudGVy IGFuZCBEcm9wcGVyIExGQnMgdG8gc3VwcG9ydCB0aGUgUW9TIGZ1bmN0aW9ucyANCiAgICAgIGlu IHRoZSBmb3J3YXJkaW5nIHBhdGguICBUaGUgRkUgbW9kZWwgY2FuIGFsc28gYmUgdXNlZCB0byBk ZWZpbmUgDQogICAgICBvdGhlciB1c2VmdWwgUW9TIGZ1bmN0aW9ucyBhcyBuZWVkZWQuICBUaGVz ZSBMRkJzIGFsbG93IHRoZSBDRSB0byANCiAgICAgIG1hbmlwdWxhdGUgdGhlIGF0dHJpYnV0ZXMg dG8gbW9kZWwgSW50U2VydiBvciBEaWZmU2VydiBmdW5jdGlvbnMuICANCiAgICAgICANCiAgICAN CiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA4MV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUg TW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgNi40LiBHZW5l cmljIEZpbHRlcmluZyBGdW5jdGlvbnMgDQogICAgDQogICAgICBWYXJpb3VzIGNvbWJpbmF0aW9u cyBvZiBDbGFzc2lmaWVyLCBSZWRpcmVjdG9yLCBNZXRlciBhbmQgRHJvcHBlciANCiAgICAgIExG QnMgY2FuIGJlIHVzZWQgdG8gbW9kZWwgYSBjb21wbGV4IHNldCBvZiBmaWx0ZXJpbmcgZnVuY3Rp b25zLiAgDQogICAgDQogICA2LjUuIFZlbmRvciBTcGVjaWZpYyBGdW5jdGlvbnMgDQogICAgDQog ICAgICBOZXcgTEZCIGNsYXNzZXMgY2FuIGJlIGRlZmluZWQgYWNjb3JkaW5nIHRvIHRoZSBMRkIg bW9kZWwgYXMgDQogICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0IHRvIHN1cHBvcnQgdmVuZG9y IHNwZWNpZmljIGZ1bmN0aW9ucy4gIEEgDQogICAgICBuZXcgTEZCIGNsYXNzIGNhbiBhbHNvIGJl IGRlcml2ZWQgZnJvbSBhbiBleGlzdGluZyBMRkIgY2xhc3MgDQogICAgICB0aHJvdWdoIGluaGVy aXRhbmNlLiAgIA0KICAgICAgICAgICANCiAgIDYuNi5IaWdoLVRvdWNoIEZ1bmN0aW9ucyANCiAg ICAgICANCiAgICAgIEhpZ2gtdG91Y2ggZnVuY3Rpb25zIGFyZSB0aG9zZSB0aGF0IHRha2UgYWN0 aW9uIG9uIHRoZSBjb250ZW50cyBvciANCiAgICAgIGhlYWRlcnMgb2YgYSBwYWNrZXQgYmFzZWQg b24gY29udGVudCBvdGhlciB0aGFuIHdoYXQgaXMgZm91bmQgaW4gDQogICAgICB0aGUgSVAgaGVh ZGVyLiAgRXhhbXBsZXMgb2Ygc3VjaCBmdW5jdGlvbnMgaW5jbHVkZSBOQVQsIEFMRywgDQogICAg ICBmaXJld2FsbCwgdHVubmVsaW5nIGFuZCBMNyBjb250ZW50IHJlY29nbml0aW9uLiAgSXQgaXMg bm90IA0KICAgICAgcHJhY3RpY2FsIHRvIGluY2x1ZGUgYWxsIHBvc3NpYmxlIGhpZ2gtdG91Y2gg ZnVuY3Rpb25zIGluIHRoZSANCiAgICAgIGluaXRpYWwgTEZCIGxpYnJhcnkgZHVlIHRvIHRoZSBu dW1iZXIgYW5kIGNvbXBsZXhpdHkuIEhvd2V2ZXIsIHRoZSANCiAgICAgIGZsZXhpYmlsaXR5IG9m IHRoZSBMRkIgbW9kZWwgYW5kIHRoZSBwb3dlciBvZiBpbnRlcmNvbm5lY3Rpb24gaW4gDQogICAg ICBMRkIgdG9wb2xvZ3kgc2hvdWxkIG1ha2UgaXQgcG9zc2libGUgdG8gbW9kZWwgYW55IGhpZ2gt dG91Y2ggDQogICAgICBmdW5jdGlvbnMuIA0KICAgIA0KICAgNi43LiBTZWN1cml0eSBGdW5jdGlv bnMgDQogICAgICAgDQogICAgICBTZWN1cml0eSBmdW5jdGlvbnMgYXJlIG5vdCBpbmNsdWRlZCBp biB0aGUgaW5pdGlhbCBMRkIgY2xhc3MgDQogICAgICBsaWJyYXJ5LiAgSG93ZXZlciwgdGhlIEZF IG1vZGVsIGlzIGZsZXhpYmxlIGFuZCBwb3dlcmZ1bCBlbm91Z2ggdG8gDQogICAgICBtb2RlbCB0 aGUgdHlwZXMgb2YgZW5jcnlwdGlvbiBhbmQvb3IgZGVjcnlwdGlvbiBmdW5jdGlvbnMgdGhhdCBh biANCiAgICAgIEZFIHN1cHBvcnRzIGFuZCB0aGUgYXNzb2NpYXRlZCBhdHRyaWJ1dGVzIGZvciBz dWNoIGZ1bmN0aW9ucy4gIA0KICAgICAgIA0KICAgICAgVGhlIElQIFNlY3VyaXR5IFBvbGljeSAo SVBTUCkgV29ya2luZyBHcm91cCBpbiB0aGUgSUVURiBoYXMgDQogICAgICBzdGFydGVkIHdvcmsg aW4gZGVmaW5pbmcgdGhlIElQU2VjIFBvbGljeSBJbmZvcm1hdGlvbiBCYXNlIFs4XS4gIA0KICAg ICAgV2Ugd2lsbCB0cnkgdG8gcmV1c2UgYXMgbXVjaCBvZiB0aGUgd29yayBhcyBwb3NzaWJsZS4g DQogICAgICAgDQogICA2LjguIE9mZi1sb2FkZWQgRnVuY3Rpb25zIA0KICAgICAgIA0KICAgICAg SW4gYWRkaXRpb24gdG8gdGhlIHBhY2tldCBwcm9jZXNzaW5nIGZ1bmN0aW9ucyB0eXBpY2FsbHkg Zm91bmQgb24gDQogICAgICB0aGUgRkVzLCBzb21lIGxvZ2ljYWwgZnVuY3Rpb25zIG1heSBhbHNv IGJlIGV4ZWN1dGVkIA0KICAgICAgYXN5bmNocm9ub3VzbHkgYnkgc29tZSBGRXMsIGFzIGRpcmVj dGVkIGJ5IGEgZmluaXRlLXN0YXRlIG1hY2hpbmUgDQogICAgICBhbmQgdHJpZ2dlcmVkIG5vdCBv bmx5IGJ5IHBhY2tldCBldmVudHMsIGJ1dCBieSB0aW1lciBldmVudHMgYXMgDQogICAgICB3ZWxs LiAgRXhhbXBsZXMgb2Ygc3VjaCBmdW5jdGlvbnMgaW5jbHVkZTsgZmluaXRlLXN0YXRlIG1hY2hp bmUgDQogICAgICBleGVjdXRpb24gcmVxdWlyZWQgYnkgVENQIHRlcm1pbmF0aW9uIG9yIE9TUEYg SGVsbG8gcHJvY2Vzc2luZyANCiAgICAgIG9mZi1sb2FkZWQgZnJvbSB0aGUgQ0UuICBCeSBkZWZp bmluZyBMRkJzIGZvciBzdWNoIGZ1bmN0aW9ucywgdGhlIA0KICAgICAgRkUgbW9kZWwgaXMgY2Fw YWJsZSBvZiBleHByZXNzaW5nIHRoZXNlIGFzeW5jaHJvbm91cyBmdW5jdGlvbnMgdG8gDQogICAg ICBhbGxvdyB0aGUgQ0UgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Ygc3VjaCBvZmYtbG9hZGVkIGZ1bmN0 aW9ucyBvbiB0aGUgDQogICAgICBGRXMuIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhw aXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDgyXSANCgwgICBJ bnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0 IDIwMDUgDQogICAgDQogICAgDQogICAgICAgDQogICA2LjkuIElQRkxPVy9QU0FNUCBGdW5jdGlv bnMgDQogICAgICAgDQogICAgICBbOV0gZGVmaW5lcyBhbiBhcmNoaXRlY3R1cmUgZm9yIElQIHRy YWZmaWMgZmxvdyBtb25pdG9yaW5nLCANCiAgICAgIG1lYXN1cmluZyBhbmQgZXhwb3J0aW5nLiAg VGhlIExGQiBtb2RlbCBzdXBwb3J0cyBzdGF0aXN0aWNzIA0KICAgICAgY29sbGVjdGlvbiBvbiB0 aGUgTEZCIGJ5IGluY2x1ZGluZyBzdGF0aXN0aWNhbCBhdHRyaWJ1dGVzIChTZWN0aW9uIA0KICAg ICAgNC43LjQpIGluIHRoZSBMRkIgY2xhc3MgZGVmaW5pdGlvbnM7IGluIGFkZGl0aW9uLCBzcGVj aWFsIA0KICAgICAgc3RhdGlzdGljcyBjb2xsZWN0aW9uIExGQnMgc3VjaCBhcyBtZXRlciBMRkJz IGFuZCBjb3VudGVyIExGQnMgY2FuIA0KICAgICAgYWxzbyBiZSB1c2VkIHRvIHN1cHBvcnQgYWNj b3VudGluZyBmdW5jdGlvbnMgaW4gdGhlIEZFLiANCiAgICAgICANCiAgICAgIFsxMF0gZGVzY3Jp YmVzIGEgZnJhbWV3b3JrIHRvIGRlZmluZSBhIHN0YW5kYXJkIHNldCBvZiANCiAgICAgIGNhcGFi aWxpdGllcyBmb3IgbmV0d29yayBlbGVtZW50cyB0byBzYW1wbGUgc3Vic2V0cyBvZiBwYWNrZXRz IGJ5IA0KICAgICAgc3RhdGlzdGljYWwgYW5kIG90aGVyIG1ldGhvZHMuICBUaW1lIGV2ZW50IGdl bmVyYXRpb24sIGZpbHRlciBMRkIsIA0KICAgICAgYW5kIGNvdW50ZXIvbWV0ZXIgTEZCIGFyZSB0 aGUgZWxlbWVudHMgbmVlZGVkIHRvIHN1cHBvcnQgcGFja2V0IA0KICAgICAgZmlsdGVyaW5nIGFu ZCBzYW1wbGluZyBmdW5jdGlvbnMgLS0gdGhlc2UgZWxlbWVudHMgY2FuIGFsbCBiZSANCiAgICAg IHN1cHBvcnRlZCBpbiB0aGUgRkUgbW9kZWwuIA0KICAgICAgIA0KICAgNy4gDSAgICAgVXNpbmcg dGhlIEZFIG1vZGVsIGluIHRoZSBGb3JDRVMgUHJvdG9jb2wgDQogICAgICAgDQogICAgICBUaGUg YWN0dWFsIG1vZGVsIG9mIHRoZSBmb3J3YXJkaW5nIHBsYW5lIGluIGEgZ2l2ZW4gTkUgaXMgDQog ICAgICBzb21ldGhpbmcgdGhlIENFIG11c3QgbGVhcm4gYW5kIGNvbnRyb2wgYnkgY29tbXVuaWNh dGluZyB3aXRoIHRoZSANCiAgICAgIEZFcyAob3IgYnkgb3RoZXIgbWVhbnMpLiAgTW9zdCBvZiB0 aGlzIGNvbW11bmljYXRpb24gd2lsbCBoYXBwZW4gDQogICAgICBpbiB0aGUgcG9zdC1hc3NvY2lh dGlvbiBwaGFzZSB1c2luZyB0aGUgRm9yQ0VTIHByb3RvY29sLiAgVGhlIA0KICAgICAgZm9sbG93 aW5nIHR5cGVzIG9mIGluZm9ybWF0aW9uIG11c3QgYmUgZXhjaGFuZ2VkIGJldHdlZW4gQ0VzIGFu ZCANCiAgICAgIEZFcyB2aWEgdGhlIEZvckNFUyBwcm90b2NvbDogDQogICAgICAgICAxKSAgRkUg dG9wb2xvZ3kgcXVlcnk7IA0KICAgICAgICAgMikgIEZFIGNhcGFiaWxpdHkgZGVjbGFyYXRpb247 IA0KICAgICAgICAgMykgIExGQiB0b3BvbG9neSAocGVyIEZFKSBhbmQgY29uZmlndXJhdGlvbiBj YXBhYmlsaXRpZXMgDQogICAgICBxdWVyeTsgDQogICAgICAgICA0KSAgTEZCIGNhcGFiaWxpdHkg ZGVjbGFyYXRpb247IA0KICAgICAgICAgNSkgIFN0YXRlIHF1ZXJ5IG9mIExGQiBhdHRyaWJ1dGVz OyANCiAgICAgICAgIDYpICBNYW5pcHVsYXRpb24gb2YgTEZCIGF0dHJpYnV0ZXM7IA0KICAgICAg ICAgNykgIExGQiB0b3BvbG9neSByZWNvbmZpZ3VyYXRpb24uIA0KICAgICAgICAgIA0KICAgICAg SXRlbXMgMSkgdGhyb3VnaCA1KSBhcmUgcXVlcnkgZXhjaGFuZ2VzLCB3aGVyZSB0aGUgbWFpbiBm bG93IG9mIA0KICAgICAgaW5mb3JtYXRpb24gaXMgZnJvbSB0aGUgRkVzIHRvIHRoZSBDRXMuICBJ dGVtcyAxKSB0aHJvdWdoIDQpIGFyZSANCiAgICAgIHR5cGljYWxseSBxdWVyaWVkIGJ5IHRoZSBD RShzKSBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwb3N0LQ0KICAgICAgYXNzb2NpYXRpb24gKFBB KSBwaGFzZSwgdGhvdWdoIHRoZXkgbWF5IGJlIHJlcGVhdGVkbHkgcXVlcmllZCBhdCANCiAgICAg IGFueSB0aW1lIGluIHRoZSBQQSBwaGFzZS4gIEl0ZW0gNSkgKHN0YXRlIHF1ZXJ5KSB3aWxsIGJl IHVzZWQgYXQgDQogICAgICB0aGUgYmVnaW5uaW5nIG9mIHRoZSBQQSBwaGFzZSwgYW5kIG9mdGVu IGZyZXF1ZW50bHkgZHVyaW5nIHRoZSBQQSANCiAgICAgIHBoYXNlIChlc3BlY2lhbGx5IGZvciB0 aGUgcXVlcnkgb2Ygc3RhdGlzdGljYWwgY291bnRlcnMpLiANCiAgICAgICANCiAgICAgIEl0ZW1z IDYpIGFuZCA3KSBhcmUgImNvbW1hbmQiIHR5cGVzIG9mIGV4Y2hhbmdlcywgd2hlcmUgdGhlIG1h aW4gDQogICAgICBmbG93IG9mIGluZm9ybWF0aW9uIGlzIGZyb20gdGhlIENFcyB0byB0aGUgRkVz LiAgTWVzc2FnZXMgaW4gSXRlbSANCiAgICAgIDYpICh0aGUgTEZCIHJlLWNvbmZpZ3VyYXRpb24g Y29tbWFuZHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2VkIA0KICAgICAgZnJlcXVlbnRseS4gIEl0 ZW0gNykgKExGQiB0b3BvbG9neSByZS1jb25maWd1cmF0aW9uKSBpcyBuZWVkZWQgDQoNCiAgICAN CiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA4M10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUg TW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgb25seSBp ZiBkeW5hbWljIExGQiB0b3BvbG9naWVzIGFyZSBzdXBwb3J0ZWQgYnkgdGhlIEZFcyBhbmQgaXQg aXMgDQogICAgICBleHBlY3RlZCB0byBiZSB1c2VkIGluZnJlcXVlbnRseS4gICANCiAgICAgICAN CiAgICAgIEFtb25nIHRoZSBzZXZlbiB0eXBlcyBvZiBwYXlsb2FkIGluZm9ybWF0aW9uIHRoZSBG b3JDRVMgcHJvdG9jb2wgDQogICAgICBjYXJyaWVzIGJldHdlZW4gQ0VzIGFuZCBGRXMsIHRoZSBG RSBtb2RlbCBjb3ZlcnMgYWxsIG9mIHRoZW0gDQogICAgICBleGNlcHQgaXRlbSAxKSwgd2hpY2gg Y29uY2VybnMgdGhlIGludGVyLUZFIHRvcG9sb2d5LiAgVGhlIEZFIA0KICAgICAgbW9kZWwgZm9j dXNlcyBvbiB0aGUgTEZCIGFuZCBMRkIgdG9wb2xvZ3kgd2l0aGluIGEgc2luZ2xlIEZFLiAgDQog ICAgICBTaW5jZSB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBpdGVtIDEpIHJlcXVpcmVzIGds b2JhbCANCiAgICAgIGtub3dsZWRnZSBhYm91dCBhbGwgb2YgdGhlIEZFcyBhbmQgdGhlaXIgaW50 ZXItY29ubmVjdGlvbiB3aXRoIA0KICAgICAgZWFjaCBvdGhlciwgdGhpcyBleGNoYW5nZSBpcyBw YXJ0IG9mIHRoZSBGb3JDRVMgYmFzZSBwcm90b2NvbCANCiAgICAgIGluc3RlYWQgb2YgdGhlIEZF IG1vZGVsLiANCiAgICAgICANCiAgICAgIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgRkUg bW9kZWwgYW5kIHRoZSBzZXZlbiBwb3N0LQ0KICAgICAgYXNzb2NpYXRpb24gbWVzc2FnZXMgYXJl IHZpc3VhbGl6ZWQgaW4gRmlndXJlIDk6IA0KICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLS0+fCAgIENFICAgfCAN CiAgICAgICAgICAgICAgICAgICAgIC8tLS0tXCAgICAgICAgICAgICAgIC4gICAgICAgICAgICAr LS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAgICAgXF9fX18vIEZFIE1vZGVsICAgICAgLiAg ICAgICAgICAgICAgXiAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICB8Li4uLi4uLi4u Li4uLi4uLiAgICAgICAgKDEpLDIgfCAgICB8IDYsIDcgDQogICAgICAgICAgICAgICAgICAgICB8 ICAgIHwgIChvZmYtbGluZSkgICAuICAgICAgMywgNCwgNSB8ICAgIHwgDQogICAgICAgICAgICAg ICAgICAgICBcX19fXy8gICAgICAgICAgICAgICAuICAgICAgICAgICAgICB8ICAgIHYgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuICAgICAgICAgICAgKy0tLS0t LS0tKyANCiAgICAgICAgICAgICAgICAgICBlLmcuIFJGQ3MgICAgICAgICAgICAgIC4uLi4uLi4u Li4tLT58ICAgRkUgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAgRmlndXJlIDku IFJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBGRSBtb2RlbCBhbmQgdGhlIEZvckNFUyANCiAgICAg IHByb3RvY29sIG1lc3NhZ2VzLCB3aGVyZSAoMSkgaXMgcGFydCBvZiB0aGUgRm9yQ0VTIGJhc2Ug cHJvdG9jb2wsIA0KICAgICAgICAgICAgICAgICAgYW5kIHRoZSByZXN0IGFyZSBkZWZpbmVkIGJ5 IHRoZSBGRSBtb2RlbC4gDQogICAgICAgDQogICAgICBUaGUgYWN0dWFsIGVuY29kaW5nIG9mIHRo ZXNlIG1lc3NhZ2VzIGlzIGRlZmluZWQgYnkgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIGFu ZCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBGRSBtb2RlbC4gIFRoZWlyIGRpc2N1c3Npb24gDQog ICAgICBpcyBuZXZlcnRoZWxlc3MgaW1wb3J0YW50IGhlcmUgZm9yIHRoZSBmb2xsb3dpbmcgcmVh c29uczogDQogICAgICAgIC4gVGhlc2UgUEEgbW9kZWwgY29tcG9uZW50cyBoYXZlIGNvbnNpZGVy YWJsZSBpbXBhY3Qgb24gdGhlIEZFIA0KICAgICAgICAgICBtb2RlbC4gIEZvciBleGFtcGxlLCBz b21lIG9mIHRoZSBhYm92ZSBpbmZvcm1hdGlvbiBjYW4gYmUgDQogICAgICAgICAgIHJlcHJlc2Vu dGVkIGFzIGF0dHJpYnV0ZXMgb2YgdGhlIExGQnMsIGluIHdoaWNoIGNhc2Ugc3VjaCANCiAgICAg ICAgICAgYXR0cmlidXRlcyBtdXN0IGJlIGRlZmluZWQgaW4gdGhlIExGQiBjbGFzc2VzLiANCiAg ICAgICAgLiBUaGUgdW5kZXJzdGFuZGluZyBvZiB0aGUgdHlwZSBvZiBpbmZvcm1hdGlvbiB0aGF0 IG11c3QgYmUgDQogICAgICAgICAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBGRXMgYW5kIENFcyBj YW4gaGVscCB0byBzZWxlY3QgdGhlIA0KICAgICAgICAgICBhcHByb3ByaWF0ZSBwcm90b2NvbCBm b3JtYXQgYW5kIHRoZSBhY3R1YWwgZW5jb2RpbmcgbWV0aG9kIA0KICAgICAgICAgICAoc3VjaCBh cyBYTUwsIFRMVnMpLiANCiAgICAgICAgLiBVbmRlcnN0YW5kaW5nIHRoZSBmcmVxdWVuY3kgb2Yg dGhlc2UgdHlwZXMgb2YgbWVzc2FnZXMgDQogICAgICAgICAgIHNob3VsZCBpbmZsdWVuY2UgdGhl IHNlbGVjdGlvbiBvZiB0aGUgcHJvdG9jb2wgZm9ybWF0IA0KICAgICAgICAgICAoZWZmaWNpZW5j eSBjb25zaWRlcmF0aW9ucykuIA0KICAgICAgIA0KICAgICAgQW4gaW1wb3J0YW50IHBhcnQgb2Yg dGhlIEZFIG1vZGVsIGlzIHRoZSBwb3J0IHRoZSBGRSB1c2VzIGZvciBpdHMgDQogICAgICBtZXNz YWdlIGV4Y2hhbmdlcyB0byBhbmQgZnJvbSB0aGUgQ0UuICBJbiB0aGUgY2FzZSB0aGF0IGEgDQog ICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgODRdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIGRl ZGljYXRlZCBwb3J0IGlzIHVzZWQgZm9yIENFLUZFIGNvbW11bmljYXRpb24sIHdlIHByb3Bvc2Ug dG8gdXNlIA0KICAgICAgYSBzcGVjaWFsIHBvcnQgTEZCLCBjYWxsZWQgdGhlIENFLUZFIFBvcnQg TEZCIChhIHN1YmNsYXNzIG9mIHRoZSANCiAgICAgIGdlbmVyYWwgUG9ydCBMRkIgaW4gU2VjdGlv biA2LjEpLCB0byBtb2RlbCB0aGlzIGRlZGljYXRlZCBDRS1GRSANCiAgICAgIHBvcnQuICBUaGUg Q0UtRkUgUG9ydCBMRkIgYWN0cyBhcyBib3RoIGEgc291cmNlIGFuZCBzaW5rIGZvciB0aGUgDQog ICAgICB0cmFmZmljIGZyb20gYW5kIHRvIHRoZSBDRS4gIFNvbWV0aW1lcyB0aGUgQ0UtRkUgdHJh ZmZpYyBkb2VzIG5vdCANCiAgICAgIGhhdmUgaXRzIG93biBkZWRpY2F0ZWQgcG9ydCwgaW5zdGVh ZCB0aGUgZGF0YSBmYWJyaWMgaXMgc2hhcmVkIA0KICAgICAgZm9yIHRoZSBkYXRhIHBsYW5lIHRy YWZmaWMgYW5kIHRoZSBDRS1GRSB0cmFmZmljLiAgQSBzcGVjaWFsIA0KICAgICAgcHJvY2Vzc2lu ZyBMRkIgY2FuIGJlIHVzZWQgdG8gbW9kZWwgdGhlIEZvckNFUyBwYWNrZXQgDQogICAgICBlbmNh cHN1bGF0aW9uIGFuZCBkZWNhcHN1bGF0aW9uIGluIHN1Y2ggY2FzZXMuIA0KICAgICAgIA0KICAg ICAgVGhlIHJlbWFpbmluZyBzdWItc2VjdGlvbnMgb2YgdGhpcyBzZWN0aW9uIGFkZHJlc3MgZWFj aCBvZiB0aGUgDQogICAgICBzZXZlbiBtZXNzYWdlIHR5cGVzLiANCiAgICAgICANCiAgIDcuMS4g RkUgVG9wb2xvZ3kgUXVlcnkgDQogICAgDQogICAgICBBbiBGRSBtYXkgY29udGFpbiB6ZXJvLCBv bmUgb3IgbW9yZSBleHRlcm5hbCBpbmdyZXNzIHBvcnRzLiANCiAgICAgIFNpbWlsYXJseSwgYW4g RkUgbWF5IGNvbnRhaW4gemVybywgb25lIG9yIG1vcmUgZXh0ZXJuYWwgZWdyZXNzIA0KICAgICAg cG9ydHMuICBJbiBvdGhlciB3b3Jkcywgbm90IGV2ZXJ5IEZFIGhhcyB0byBjb250YWluIGFueSBl eHRlcm5hbCANCiAgICAgIGluZ3Jlc3Mgb3IgZWdyZXNzIGludGVyZmFjZXMuICBGb3IgZXhhbXBs ZSwgRmlndXJlIDEwIHNob3dzIHR3byANCiAgICAgIGNhc2NhZGluZyBGRXMuICBGRSAjMSBjb250 YWlucyBvbmUgZXh0ZXJuYWwgaW5ncmVzcyBpbnRlcmZhY2UgYnV0IA0KICAgICAgbm8gZXh0ZXJu YWwgZWdyZXNzIGludGVyZmFjZSwgd2hpbGUgRkUgIzIgY29udGFpbnMgb25lIGV4dGVybmFsIA0K ICAgICAgZWdyZXNzIGludGVyZmFjZSBidXQgbm8gaW5ncmVzcyBpbnRlcmZhY2UuICBJdCBpcyBw b3NzaWJsZSB0byANCiAgICAgIGNvbm5lY3QgdGhlc2UgdHdvIEZFcyB0b2dldGhlciB2aWEgdGhl aXIgaW50ZXJuYWwgaW50ZXJmYWNlcyB0byANCiAgICAgIGFjaGlldmUgdGhlIGNvbXBsZXRlIGlu Z3Jlc3MtdG8tZWdyZXNzIHBhY2tldCBwcm9jZXNzaW5nIGZ1bmN0aW9uLiANCiAgICAgIFRoaXMg cHJvdmlkZXMgdGhlIGZsZXhpYmlsaXR5IHRvIHNwcmVhZCB0aGUgZnVuY3Rpb25zIGFjcm9zcyAN CiAgICAgIG11bHRpcGxlIEZFcyBhbmQgaW50ZXJjb25uZWN0IHRoZW0gdG9nZXRoZXIgbGF0ZXIg Zm9yIGNlcnRhaW4gDQogICAgICBhcHBsaWNhdGlvbnMuICANCiAgICAgICANCiAgICAgIFdoaWxl IHRoZSBpbnRlci1GRSBjb21tdW5pY2F0aW9uIHByb3RvY29sIGlzIG91dCBvZiBzY29wZSBmb3Ig DQogICAgICBGb3JDRVMsIGl0IGlzIHVwIHRvIHRoZSBDRSB0byBxdWVyeSBhbmQgdW5kZXJzdGFu ZCBob3cgbXVsdGlwbGUgDQogICAgICBGRXMgYXJlIGludGVyLWNvbm5lY3RlZCB0byBwZXJmb3Jt IGEgY29tcGxldGUgaW5ncmVzcy1lZ3Jlc3MgDQogICAgICBwYWNrZXQgcHJvY2Vzc2luZyBmdW5j dGlvbiwgc3VjaCBhcyB0aGUgb25lIGRlc2NyaWJlZCBpbiBGaWd1cmUgDQogICAgICAxMC4gIFRo ZSBpbnRlci1GRSB0b3BvbG9neSBpbmZvcm1hdGlvbiBtYXkgYmUgcHJvdmlkZWQgYnkgRkVzLCBt YXkgDQogICAgICBiZSBoYXJkLWNvZGVkIGludG8gQ0UsIG9yIG1heSBiZSBwcm92aWRlZCBieSBz b21lIG90aGVyIGVudGl0eSANCiAgICAgIChlLmcuLCBhIGJ1cyBtYW5hZ2VyKSBpbmRlcGVuZGVu dCBvZiB0aGUgRkVzLiAgU28gd2hpbGUgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIHN1cHBv cnRzIEZFIHRvcG9sb2d5IHF1ZXJ5IGZyb20gRkVzLCBpdCBpcyBvcHRpb25hbCBmb3IgDQogICAg ICB0aGUgQ0UgdG8gdXNlIGl0LCBhc3N1bWluZyB0aGUgQ0UgaGFzIG90aGVyIG1lYW5zIHRvIGdh dGhlciBzdWNoIA0KICAgICAgdG9wb2xvZ3kgaW5mb3JtYXRpb24uIA0KICAgICAgIA0KDQoNCg0K DQoNCg0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4NV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAg IA0KICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICAgICAgIHwgICstLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLSsgICAr LS0tLS0tLS0tKyAgICAgICAgIHwgDQogICAgICAgaW5wdXR8ICAgICAgICAgfCAgIHwgICAgICAg ICAgICB8ICAgfCAgICAgICAgIHwgb3V0cHV0ICB8IA0KICAgICAgLS0tKy0+fCBJbmdyZXNzIHwt LT58SGVhZGVyICAgICAgfC0tPnxJUHY0ICAgICB8LS0tLS0tLS0tKy0tLT4rIA0KICAgICAgICAg fCAgfCBwb3J0ICAgIHwgICB8RGVjb21wcmVzc29yfCAgIHxGb3J3YXJkZXJ8IEZFICAgICAgfCAg ICB8IA0KICAgICAgICAgfCAgKy0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tKyAgICstLS0tLS0t LS0rICMxICAgICAgfCAgICB8IA0KICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICBWIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rIA0KICAgICAgICAgICAgICB8ICAgICANCiAgICAgICAgICAgICAgfCAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgIFYgICAg fCAgKy0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLSsgICAgICAgICB8IA0KICAgICAgICAgICAg ICB8IGlucHV0IHwgICAgICAgICAgICB8ICAgfCAgICAgICAgICB8IG91dHB1dCAgfCANCiAgICAg ICAgICAgICAgKy0+LS0rLT58SGVhZGVyICAgICAgfC0tPnwgRWdyZXNzICAgfC0tLS0tLS0tLSst LT4gDQogICAgICAgICAgICAgICAgICAgfCAgfENvbXByZXNzb3IgIHwgICB8IHBvcnQgICAgIHwg RkUgICAgICB8IA0KICAgICAgICAgICAgICAgICAgIHwgICstLS0tLS0tLS0tLS0rICAgKy0tLS0t LS0tLS0rICMyICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAgICAgRmlndXJlIDEw LiBBbiBleGFtcGxlIG9mIHR3byBGRXMgY29ubmVjdGVkIHRvZ2V0aGVyLiANCiAgICAgICANCiAg ICAgIE9uY2UgdGhlIGludGVyLUZFIHRvcG9sb2d5IGlzIGRpc2NvdmVyZWQgYnkgdGhlIENFIGFm dGVyIHRoaXMgDQogICAgICBxdWVyeSwgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBpbnRlci1GRSB0 b3BvbG9neSByZW1haW5zIHN0YXRpYy4gIA0KICAgICAgSG93ZXZlciwgaXQgaXMgcG9zc2libGUg dGhhdCBhbiBGRSBtYXkgZ28gZG93biBkdXJpbmcgdGhlIE5FIA0KICAgICAgb3BlcmF0aW9uLCBv ciBhIGJvYXJkIG1heSBiZSBpbnNlcnRlZCBhbmQgYSBuZXcgRkUgYWN0aXZhdGVkLCBzbyANCiAg ICAgIHRoZSBpbnRlci1GRSB0b3BvbG9neSB3aWxsIGJlIGFmZmVjdGVkLiAgSXQgaXMgdXAgdG8g dGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIHRvIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHRo ZSBDRSB0byBkZXRlY3Qgc3VjaCBldmVudHMgDQogICAgICBhbmQgZGVhbCB3aXRoIHRoZSBjaGFu Z2UgaW4gRkUgdG9wb2xvZ3kuICBGRSB0b3BvbG9neSBpcyBvdXRzaWRlIA0KICAgICAgdGhlIHNj b3BlIG9mIHRoZSBGRSBtb2RlbC4gDQogICAgICAgDQogICA3LjIuIEZFIENhcGFiaWxpdHkgRGVj bGFyYXRpb25zIA0KICAgICAgIA0KICAgICAgRkVzIHdpbGwgaGF2ZSBtYW55IHR5cGVzIG9mIGxp bWl0YXRpb25zLiAgU29tZSBvZiB0aGUgbGltaXRhdGlvbnMgDQogICAgICBtdXN0IGJlIGV4cHJl c3NlZCB0byB0aGUgQ0VzIGFzIHBhcnQgb2YgdGhlIGNhcGFiaWxpdHkgbW9kZWwuICBUaGUgDQog ICAgICBDRXMgbXVzdCBiZSBhYmxlIHRvIHF1ZXJ5IHRoZXNlIGNhcGFiaWxpdGllcyBvbiBhIHBl ci1GRSBiYXNpcy4gDQogICAgICBFeGFtcGxlczogDQogICAgICAgIC4gTWV0YWRhdGEgcGFzc2lu ZyBjYXBhYmlsaXRpZXMgb2YgdGhlIEZFLiAgVW5kZXJzdGFuZGluZyB0aGVzZSANCiAgICAgICAg ICAgY2FwYWJpbGl0aWVzIHdpbGwgaGVscCB0aGUgQ0UgdG8gZXZhbHVhdGUgdGhlIGZlYXNpYmls aXR5IG9mIA0KICAgICAgICAgICBMRkIgdG9wb2xvZ2llcywgYW5kIGhlbmNlIHRvIGRldGVybWlu ZSB0aGUgYXZhaWxhYmlsaXR5IG9mIA0KICAgICAgICAgICBjZXJ0YWluIHNlcnZpY2VzLiANCiAg ICAgICAgLiBHbG9iYWwgcmVzb3VyY2UgcXVlcnkgbGltaXRhdGlvbnMgKGFwcGxpY2FibGUgdG8g YWxsIExGQnMgb2YgDQogICAgICAgICAgIHRoZSBGRSkuIA0KICAgICAgICAuIExGQiBzdXBwb3J0 ZWQgYnkgdGhlIEZFLiANCiAgICAgICAgLiBMRkIgY2xhc3MgaW5zdGFudGlhdGlvbiBsaW1pdC4g DQogICAgICAgIC4gTEZCIHRvcG9sb2dpY2FsIGxpbWl0YXRpb25zIChsaW5rYWdlIGNvbnN0cmFp bnQsIG9yZGVyaW5nIA0KICAgICAgICAgICBldGMuKSANCiAgICAgICANCiAgIDcuMy4gTEZCIFRv cG9sb2d5IGFuZCBUb3BvbG9neSBDb25maWd1cmFiaWxpdHkgUXVlcnkgDQogICAgDQogICBZYW5n LCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgODZdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAg ICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgIFRoZSBG b3JDRVMgcHJvdG9jb2wgbXVzdCBwcm92aWRlIHRoZSBtZWFucyBmb3IgdGhlIENFcyB0byBkaXNj b3ZlciANCiAgICAgIHRoZSBjdXJyZW50IHNldCBvZiBMRkIgaW5zdGFuY2VzIGluIGFuIEZFIGFu ZCB0aGUgaW50ZXJjb25uZWN0aW9ucyANCiAgICAgIGJldHdlZW4gdGhlIExGQnMgd2l0aGluIHRo ZSBGRS4gIEluIGFkZGl0aW9uLCBzdWZmaWNpZW50IA0KICAgICAgaW5mb3JtYXRpb24gc2hvdWxk IGJlIGF2YWlsYWJsZSB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgRkUgDQogICAgICBzdXBwb3J0 cyBhbnkgQ0UtaW5pdGlhdGVkIChkeW5hbWljKSBjaGFuZ2VzIHRvIHRoZSBMRkIgdG9wb2xvZ3ks IA0KICAgICAgYW5kIGlmIHNvLCBkZXRlcm1pbmUgdGhlIGFsbG93ZWQgdG9wb2xvZ2llcy4gIFRv cG9sb2d5IA0KICAgICAgY29uZmlndXJhYmlsaXR5IGNhbiBhbHNvIGJlIGNvbnNpZGVyZWQgYXMg cGFydCBvZiB0aGUgRkUgDQogICAgICBjYXBhYmlsaXR5IHF1ZXJ5IGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDkuMy4gDQogICAgICAgDQogICA3LjQuIExGQiBDYXBhYmlsaXR5IERlY2xhcmF0aW9u cyANCiAgICAgICANCiAgICAgIExGQiBjbGFzcyBzcGVjaWZpY2F0aW9ucyBkZWZpbmUgYSBnZW5l cmljIHNldCBvZiBjYXBhYmlsaXRpZXMuIA0KICAgICAgV2hlbiBhbiBMRkIgaW5zdGFuY2UgaXMg aW1wbGVtZW50ZWQgKGluc3RhbnRpYXRlZCkgb24gYSB2ZW5kb3IncyANCiAgICAgIEZFLCBzb21l IGFkZGl0aW9uYWwgbGltaXRhdGlvbnMgbWF5IGJlIGludHJvZHVjZWQuICBOb3RlIHRoYXQgd2Ug DQogICAgICBkaXNjdXNzIG9ubHkgdGhvc2UgbGltaXRhdGlvbnMgdGhhdCBhcmUgd2l0aGluIHRo ZSBmbGV4aWJpbGl0eSBvZiANCiAgICAgIHRoZSBMRkIgY2xhc3Mgc3BlY2lmaWNhdGlvbi4gIFRo YXQgaXMsIHRoZSBMRkIgaW5zdGFuY2Ugd2lsbCANCiAgICAgIHJlbWFpbiBjb21wbGlhbnQgd2l0 aCB0aGUgTEZCIGNsYXNzIHNwZWNpZmljYXRpb24gZGVzcGl0ZSB0aGVzZSANCiAgICAgIGxpbWl0 YXRpb25zLiAgRm9yIGV4YW1wbGUsIGNlcnRhaW4gZmVhdHVyZXMgb2YgYW4gTEZCIGNsYXNzIG1h eSBiZSANCiAgICAgIG9wdGlvbmFsLCBpbiB3aGljaCBjYXNlIGl0IG11c3QgYmUgcG9zc2libGUg Zm9yIHRoZSBDRSB0byANCiAgICAgIGRldGVybWluZSBpZiBhbiBvcHRpb25hbCBmZWF0dXJlIGlz IHN1cHBvcnRlZCBieSBhIGdpdmVuIExGQiANCiAgICAgIGluc3RhbmNlIG9yIG5vdC4gQWxzbywg dGhlIExGQiBjbGFzcyBkZWZpbml0aW9ucyB3aWxsIHByb2JhYmx5IA0KICAgICAgY29udGFpbiB2 ZXJ5IGZldyBxdWFudGl0YXRpdmUgbGltaXRzIChlLmcuLCBzaXplIG9mIHRhYmxlcyksIHNpbmNl IA0KICAgICAgdGhlc2UgbGltaXRzIGFyZSB0eXBpY2FsbHkgaW1wb3NlZCBieSB0aGUgaW1wbGVt ZW50YXRpb24uICANCiAgICAgIFRoZXJlZm9yZSwgcXVhbnRpdGF0aXZlIGxpbWl0YXRpb25zIHNo b3VsZCBhbHdheXMgYmUgZXhwcmVzc2VkIGJ5IA0KICAgICAgY2FwYWJpbGl0eSBhcmd1bWVudHMu IA0KICAgICAgIA0KICAgICAgTEZCIGluc3RhbmNlcyBpbiB0aGUgbW9kZWwgb2YgYSBwYXJ0aWN1 bGFyIEZFIGltcGxlbWVudGF0aW9uIHdpbGwgDQogICAgICBwb3NzZXNzIGxpbWl0YXRpb25zIG9u IHRoZSBjYXBhYmlsaXRpZXMgZGVmaW5lZCBpbiB0aGUgDQogICAgICBjb3JyZXNwb25kaW5nIExG QiBjbGFzcy4gIFRoZSBMRkIgY2xhc3Mgc3BlY2lmaWNhdGlvbnMgbXVzdCBkZWZpbmUgDQogICAg ICBhIHNldCBvZiBjYXBhYmlsaXR5IGFyZ3VtZW50cywgYW5kIHRoZSBDRSBtdXN0IGJlIGFibGUg dG8gcXVlcnkgDQogICAgICB0aGUgYWN0dWFsIGNhcGFiaWxpdGllcyBvZiB0aGUgTEZCIGluc3Rh bmNlIHZpYSBxdWVyeWluZyB0aGUgdmFsdWUgDQogICAgICBvZiBzdWNoIGFyZ3VtZW50cy4gIFRo ZSBjYXBhYmlsaXR5IHF1ZXJ5IHdpbGwgdHlwaWNhbGx5IGhhcHBlbiANCiAgICAgIHdoZW4gdGhl IExGQiBpcyBmaXJzdCBkZXRlY3RlZCBieSB0aGUgQ0UuICBDYXBhYmlsaXRpZXMgbmVlZCBub3Qg DQogICAgICBiZSByZS1xdWVyaWVkIGluIGNhc2Ugb2Ygc3RhdGljIGxpbWl0YXRpb25zLiAgSW4g c29tZSBjYXNlcywgDQogICAgICBob3dldmVyLCBzb21lIGNhcGFiaWxpdGllcyBtYXkgY2hhbmdl IGluIHRpbWUgKGUuZy4sIGFzIGEgcmVzdWx0IA0KICAgICAgb2YgYWRkaW5nL3JlbW92aW5nIG90 aGVyIExGQnMsIG9yIGNvbmZpZ3VyaW5nIGNlcnRhaW4gYXR0cmlidXRlcyANCiAgICAgIG9mIHNv bWUgb3RoZXIgTEZCIHdoZW4gdGhlIExGQnMgc2hhcmUgcGh5c2ljYWwgcmVzb3VyY2VzKSwgaW4g DQogICAgICB3aGljaCBjYXNlIGFkZGl0aW9uYWwgbWVjaGFuaXNtcyBtdXN0IGJlIGltcGxlbWVu dGVkIHRvIGluZm9ybSB0aGUgDQogICAgICBDRSBhYm91dCB0aGUgY2hhbmdlcy4gDQogICAgICAg DQogICAgICBUaGUgZm9sbG93aW5nIHR3byBicm9hZCB0eXBlcyBvZiBsaW1pdGF0aW9ucyB3aWxs IGV4aXN0OiANCiAgICAgICAgLiBRdWFsaXRhdGl2ZSByZXN0cmljdGlvbnMuICBGb3IgZXhhbXBs ZSwgYSBzdGFuZGFyZGl6ZWQgbXVsdGktDQogICAgICAgICAgIGZpZWxkIGNsYXNzaWZpZXIgTEZC IGNsYXNzIG1heSBkZWZpbmUgYSBsYXJnZSBudW1iZXIgb2YgDQogICAgICAgICAgIGNsYXNzaWZp Y2F0aW9uIGZpZWxkcywgYnV0IGEgZ2l2ZW4gRkUgbWF5IHN1cHBvcnQgb25seSBhIA0KICAgICAg ICAgICBzdWJzZXQgb2YgdGhvc2UgZmllbGRzLiANCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAg ICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDg3XSAN CgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAg QXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgIC4gUXVhbnRpdGF0aXZlIHJlc3RyaWN0 aW9ucywgc3VjaCBhcyB0aGUgbWF4aW11bSBzaXplIG9mIA0KICAgICAgICAgICB0YWJsZXMsIGV0 Yy4gDQogICAgICAgDQogICAgICBUaGUgY2FwYWJpbGl0eSBwYXJhbWV0ZXJzIHRoYXQgY2FuIGJl IHF1ZXJpZWQgb24gYSBnaXZlbiBMRkIgY2xhc3MgDQogICAgICB3aWxsIGJlIHBhcnQgb2YgdGhl IExGQiBjbGFzcyBzcGVjaWZpY2F0aW9uLiAgVGhlIGNhcGFiaWxpdHkgDQogICAgICBwYXJhbWV0 ZXJzIHNob3VsZCBiZSByZWdhcmRlZCBhcyBzcGVjaWFsIGF0dHJpYnV0ZXMgb2YgdGhlIExGQi4g IA0KICAgICAgVGhlIGFjdHVhbCB2YWx1ZXMgb2YgdGhlc2UgYXJndW1lbnRzIG1heSBiZSwgdGhl cmVmb3JlLCBvYnRhaW5lZCANCiAgICAgIHVzaW5nIHRoZSBzYW1lIGF0dHJpYnV0ZSBxdWVyeSBt ZWNoYW5pc21zIGFzIHVzZWQgZm9yIG90aGVyIExGQiANCiAgICAgIGF0dHJpYnV0ZXMuIA0KICAg ICAgIA0KICAgICAgQ2FwYWJpbGl0eSBhdHRyaWJ1dGVzIHdpbGwgdHlwaWNhbGx5IGJlIHJlYWQt b25seSBhcmd1bWVudHMsIGJ1dCANCiAgICAgIGluIGNlcnRhaW4gY2FzZXMgdGhleSBtYXkgYmUg Y29uZmlndXJhYmxlLiAgRm9yIGV4YW1wbGUsIHRoZSBzaXplIA0KICAgICAgb2YgYSBsb29rdXAg dGFibGUgbWF5IGJlIGxpbWl0ZWQgYnkgdGhlIGhhcmR3YXJlIChyZWFkLW9ubHkpLCBpbiANCiAg ICAgIG90aGVyIGNhc2VzIGl0IG1heSBiZSBjb25maWd1cmFibGUgKHJlYWQtd3JpdGUsIHdpdGhp biBzb21lIGhhcmQgDQogICAgICBsaW1pdHMpLiANCiAgICAgICANCiAgICAgIEFzc3VtaW5nIHRo YXQgY2FwYWJpbGl0aWVzIHdpbGwgbm90IGNoYW5nZSBmcmVxdWVudGx5LCB0aGUgDQogICAgICBl ZmZpY2llbmN5IG9mIHRoZSBwcm90b2NvbC9zY2hlbWEvZW5jb2RpbmcgaXMgb2Ygc2Vjb25kYXJ5 IA0KICAgICAgY29uY2Vybi4gDQogICAgICAgDQogICA3LjUuIFN0YXRlIFF1ZXJ5IG9mIExGQiBB dHRyaWJ1dGVzIA0KICAgICAgIA0KICAgICAgVGhpcyBmZWF0dXJlIG11c3QgYmUgcHJvdmlkZWQg YnkgYWxsIEZFcy4gIFRoZSBGb3JDRVMgcHJvdG9jb2wgYW5kIA0KICAgICAgdGhlIGRhdGEgc2No ZW1hL2VuY29kaW5nIGNvbnZleWVkIGJ5IHRoZSBwcm90b2NvbCBtdXN0IHRvZ2V0aGVyIA0KICAg ICAgc2F0aXNmeSB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyB0byBmYWNpbGl0YXRlIHN0YXRl IHF1ZXJ5IG9mIA0KICAgICAgdGhlIExGQiBhdHRyaWJ1dGVzOiANCiAgICAgICAgLiBNdXN0IHBl cm1pdCBGRSBzZWxlY3Rpb24uICBUaGlzIGlzIHByaW1hcmlseSB0byByZWZlciB0byBhIA0KICAg ICAgICAgICBzaW5nbGUgRkUsIGJ1dCByZWZlcnJpbmcgdG8gYSBncm91cCBvZiAob3IgYWxsKSBG RXMgbWF5IA0KICAgICAgICAgICBvcHRpb25hbCBiZSBzdXBwb3J0ZWQuIA0KICAgICAgICAuIE11 c3QgcGVybWl0IExGQiBpbnN0YW5jZSBzZWxlY3Rpb24uICBUaGlzIGlzIHByaW1hcmlseSB0byAN CiAgICAgICAgICAgcmVmZXIgdG8gYSBzaW5nbGUgTEZCIGluc3RhbmNlIG9mIGFuIEZFLCBidXQg b3B0aW9uYWxseSANCiAgICAgICAgICAgYWRkcmVzc2luZyBvZiBhIGdyb3VwIG9mIExGQnMgKG9y IGFsbCkgbWF5IGJlIHN1cHBvcnRlZC4gDQogICAgICAgIC4gTXVzdCBzdXBwb3J0IGFkZHJlc3Np bmcgb2YgaW5kaXZpZHVhbCBhdHRyaWJ1dGUgb2YgYW4gTEZCLiANCiAgICAgICAgLiBNdXN0IHBy b3ZpZGUgZWZmaWNpZW50IGVuY29kaW5nIGFuZCBkZWNvZGluZyBvZiB0aGUgDQogICAgICAgICAg IGFkZHJlc3NpbmcgaW5mbyBhbmQgdGhlIGNvbmZpZ3VyZWQgZGF0YS4gDQogICAgICAgIC4gTXVz dCBwcm92aWRlIGVmZmljaWVudCBkYXRhIHRyYW5zbWlzc2lvbiBvZiB0aGUgYXR0cmlidXRlIA0K ICAgICAgICAgICBzdGF0ZSBvdmVyIHRoZSB3aXJlICh0byBtaW5pbWl6ZSBjb21tdW5pY2F0aW9u IGxvYWQgb24gdGhlIA0KICAgICAgICAgICBDRS1GRSBsaW5rKS4gDQogICAgICAgDQogICA3LjYu IExGQiBBdHRyaWJ1dGUgTWFuaXB1bGF0aW9uIA0KICAgICAgIA0KICAgICAgVGhpcyBpcyBhIHBs YWNlLWhvbGRlciBmb3IgYWxsIG9wZXJhdGlvbnMgdGhhdCB0aGUgQ0Ugd2lsbCB1c2UgdG8gDQog ICAgICBwb3B1bGF0ZSwgbWFuaXB1bGF0ZSwgYW5kIGRlbGV0ZSBhdHRyaWJ1dGVzIG9mIHRoZSBM RkIgaW5zdGFuY2VzIA0KICAgICAgb24gdGhlIEZFcy4gIFRoZXNlIG9wZXJhdGlvbnMgYWxsb3cg dGhlIENFIHRvIGNvbmZpZ3VyZSBhbiANCiAgICAgIGluZGl2aWR1YWwgTEZCIGluc3RhbmNlLiAN CiAgICAgICANCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAw NSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDg4XSANCgwgICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQog ICAgDQogICAgICBUaGUgc2FtZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDkuNSBmb3IgDQogICAgICBhdHRyaWJ1dGUgcXVlcnkgYXBwbGllcyBoZXJlIGZvciBh dHRyaWJ1dGUgbWFuaXB1bGF0aW9uIGFzIHdlbGwuICANCiAgICAgICANCiAgICAgIFN1cHBvcnQg Zm9yIHZhcmlvdXMgbGV2ZWxzIG9mIGZlZWRiYWNrIGZyb20gdGhlIEZFIHRvIHRoZSBDRSANCiAg ICAgIChlLmcuLCANCiAgICAgIHJlcXVlc3QgcmVjZWl2ZWQsIGNvbmZpZ3VyYXRpb24gY29tcGxl dGVkKSwgYXMgd2VsbCBhcyBtdWx0aS0NCiAgICAgIGF0dHJpYnV0ZSBjb25maWd1cmF0aW9uIHRy YW5zYWN0aW9ucyB3aXRoIGF0b21pYyBjb21taXQgYW5kIA0KICAgICAgcm9sbGJhY2ssIG1heSBi ZSBuZWNlc3NhcnkgaW4gc29tZSBjaXJjdW1zdGFuY2VzLiANCiAgICAgICANCiAgICAgIChFZGl0 b3IncyBub3RlOiBJdCByZW1haW5zIGFuIG9wZW4gaXNzdWUgYXMgdG8gd2hldGhlciBvciBub3Qg DQogICAgICBvdGhlciBtZXRob2RzIGFyZSBuZWVkZWQgaW4gYWRkaXRpb24gdG8gImdldCBhdHRy aWJ1dGUiIGFuZCAic2V0IA0KICAgICAgYXR0cmlidXRlIiAoc3VjaCBhcyBtdWx0aS1hdHRyaWJ1 dGUgdHJhbnNhY3Rpb25zKS4gIElmIHRoZSBhbnN3ZXIgDQogICAgICB0byB0aGF0IHF1ZXN0aW9u IGlzIHllcywgaXQgaXMgbm90IGNsZWFyIHdoZXRoZXIgc3VjaCBtZXRob2RzIA0KICAgICAgc2hv dWxkIGJlIHN1cHBvcnRlZCBieSB0aGUgRkUgbW9kZWwgaXRzZWxmIG9yIHRoZSBGb3JDRVMgDQog ICAgICBwcm90b2NvbC4pIA0KICAgICAgIA0KICAgNy43LiBMRkIgVG9wb2xvZ3kgUmUtY29uZmln dXJhdGlvbiANCiAgICAgICANCiAgICAgIE9wZXJhdGlvbnMgdGhhdCB3aWxsIGJlIG5lZWRlZCB0 byByZWNvbmZpZ3VyZSBMRkIgdG9wb2xvZ3k6IA0KICAgICAgICAuIENyZWF0ZSBhIG5ldyBpbnN0 YW5jZSBvZiBhIGdpdmVuIExGQiBjbGFzcyBvbiBhIGdpdmVuIEZFLiANCiAgICAgICAgLiBDb25u ZWN0IGEgZ2l2ZW4gb3V0cHV0IG9mIExGQiB4IHRvIHRoZSBnaXZlbiBpbnB1dCBvZiBMRkIgeS4g DQogICAgICAgIC4gRGlzY29ubmVjdDogcmVtb3ZlIGEgbGluayBiZXR3ZWVuIGEgZ2l2ZW4gb3V0 cHV0IG9mIGFuIExGQiANCiAgICAgICAgICAgYW5kIGEgZ2l2ZW4gaW5wdXQgb2YgYW5vdGhlciBM RkIuIA0KICAgICAgICAuIERlbGV0ZSBhIGdpdmVuIExGQiAoYXV0b21hdGljYWxseSByZW1vdmlu ZyBhbGwgaW50ZXJjb25uZWN0cyANCiAgICAgICAgICAgdG8vZnJvbSB0aGUgTEZCKS4gDQogICAg DQogICA4LiANICAgICBBY2tub3dsZWRnbWVudHMgDQogICAgICAgDQogICAgICBNYW55IG9mIHRo ZSBjb2xsZWFndWVzIGluIG91ciBjb21wYW5pZXMgYW5kIHBhcnRpY2lwYW50cyBpbiB0aGUgDQog ICAgICBGb3JDRVMgbWFpbGluZyBsaXN0IGhhdmUgcHJvdmlkZWQgaW52YWx1YWJsZSBpbnB1dCBp bnRvIHRoaXMgd29yay4gDQogICAgICAgICANCiAgIDkuIA0gICAgIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIA0KICAgICAgIA0KICAgICAgVGhlIEZFIG1vZGVsIGRlc2NyaWJlcyB0aGUgcmVwcmVz ZW50YXRpb24gYW5kIG9yZ2FuaXphdGlvbiBvZiBkYXRhIA0KICAgICAgc2V0cyBhbmQgYXR0cmli dXRlcyBpbiB0aGUgRkVzLiAgVGhlIEZvckNFUyBmcmFtZXdvcmsgZG9jdW1lbnQgWzJdIA0KICAg ICAgcHJvdmlkZXMgYSBjb21wcmVoZW5zaXZlIHNlY3VyaXR5IGFuYWx5c2lzIGZvciB0aGUgb3Zl cmFsbCBGb3JDRVMgDQogICAgICBhcmNoaXRlY3R1cmUuICBGb3IgZXhhbXBsZSwgdGhlIEZvckNF UyBwcm90b2NvbCBlbnRpdGllcyBtdXN0IGJlIA0KICAgICAgYXV0aGVudGljYXRlZCBwZXIgdGhl IEZvckNFUyByZXF1aXJlbWVudHMgYmVmb3JlIHRoZXkgY2FuIGFjY2VzcyANCiAgICAgIHRoZSBp bmZvcm1hdGlvbiBlbGVtZW50cyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCB2aWEgRm9yQ0VT LiAgDQogICAgICBBY2Nlc3MgdG8gdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUgRkUg bW9kZWwgaXMgDQogICAgICBhY2NvbXBsaXNoZWQgdmlhIHRoZSBGb3JDRVMgcHJvdG9jb2wsIHdo aWNoIHdpbGwgYmUgZGVmaW5lZCBpbiANCiAgICAgIHNlcGFyYXRlIGRvY3VtZW50cywgYW5kIHRo dXMgdGhlIHNlY3VyaXR5IGlzc3VlcyB3aWxsIGJlIGFkZHJlc3NlZCANCiAgICAgIHRoZXJlLiAg IA0KICAgICAgIA0KICAgMTAuIA0gICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCiAgICAgICAN Cg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDg5XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZv ckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAg IFsxXSBLaG9zcmF2aSwgSC4gZXQgYWwuLCAiUmVxdWlyZW1lbnRzIGZvciBTZXBhcmF0aW9uIG9m IElQIA0KICAgICBDb250cm9sIGFuZCBGb3J3YXJkaW5nIiwgUkZDIDM2NTQsIE5vdmVtYmVyIDIw MDMuIA0KICAgICAgDQogICAgIFsyXSBZYW5nLCBMLiBldCBhbC4sICJGb3J3YXJkaW5nIGFuZCBD b250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiANCiAgICAgKEZvckNFUykgRnJhbWV3b3JrIiwgUkZD IDM3NDYsIEFwcmlsIDIwMDQuIA0KICAgIA0KICAgMTEuIA0gICAgICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzIA0KICAgICANCiAgICAgIFszXSBCZXJuZXQsIFkuIGV0IGFsLiwgIkFuIEluZm9ybWFs IE1hbmFnZW1lbnQgTW9kZWwgZm9yIERpZmZzZXJ2IA0KICAgICAgUm91dGVycyIsIFJGQyAzMjkw LCBNYXkgMjAwMi4gDQogICAgICAgDQogICAgICBbNF0gQ2hhbiwgSy4gZXQgYWwuLCAiRGlmZmVy ZW50aWF0ZWQgU2VydmljZXMgUXVhbGl0eSBvZiBTZXJ2aWNlIA0KICAgICAgUG9saWN5IEluZm9y bWF0aW9uIEJhc2UiLCBSRkMgMzMxNywgTWFyY2ggMjAwMy4gDQogICAgICAgDQogICAgICBbNV0g U2FoaXRhLCBSLiBldCBhbC4sICJGcmFtZXdvcmsgUG9saWN5IEluZm9ybWF0aW9uIEJhc2UiLCBS RkMgDQogICAgICAzMzE4LCBNYXJjaCAyMDAzLiANCiAgICAgICANCiAgICAgIFs2XSBNb29yZSwg Qi4gZXQgYWwuLCAiSW5mb3JtYXRpb24gTW9kZWwgZm9yIERlc2NyaWJpbmcgTmV0d29yayANCiAg ICAgIERldmljZSBRb1MgRGF0YXBhdGggTWVjaGFuaXNtcyIsIFJGQyAzNjcwLCBKYW51YXJ5IDIw MDQuIA0KICAgICAgIA0KICAgICAgWzddIFNuaXIsIFkuIGV0IGFsLiwgIlBvbGljeSBGcmFtZXdv cmsgUW9TIEluZm9ybWF0aW9uIE1vZGVsIiwgUkZDIA0KICAgICAgMzY0NCwgTm92IDIwMDMuIA0K ICAgIA0KICAgICAgWzhdIExpLCBNLiBldCBhbC4sICJJUHNlYyBQb2xpY3kgSW5mb3JtYXRpb24g QmFzZSIsIHdvcmsgaW4gDQogICAgICBwcm9ncmVzcywgSmFudWFyeSAyMDAzLCA8ZHJhZnQtaWV0 Zi1pcHNwLWlwc2VjcGliLTA3LnR4dD4uIA0KICAgICAgIA0KICAgICAgWzldIFF1aXR0ZWssIEou IGV0IEFsLiwgIlJlcXVpcmVtZW50cyBmb3IgSVAgRmxvdyBJbmZvcm1hdGlvbiANCiAgICAgIEV4 cG9ydCIsIHdvcmsgaW4gcHJvZ3Jlc3MsIEphbnVhcnkgMjAwNCwgPGRyYWZ0LWlldGYtaXBmaXgt cmVxcy0NCiAgICAgIDE1LnR4dD4uIA0KICAgICAgIA0KICAgICAgWzEwXSBEdWZmaWVsZCwgTi4s ICJBIEZyYW1ld29yayBmb3IgUGFzc2l2ZSBQYWNrZXQgTWVhc3VyZW1lbnQgIiwgDQogICAgICB3 b3JrIGluIHByb2dyZXNzLCBEZWNlbWJlciAyMDAzLCA8ZHJhZnQtaWV0Zi1wc2FtcC1mcmFtZXdv cmstDQogICAgICAwNS50eHQ+LiANCiAgICAgICANCiAgICAgIFsxMV0gUHJhcywgQS4gYW5kIFNj aG9lbndhZWxkZXIsIEouLCBGUkMgMzQ0NCAiT24gdGhlIERpZmZlcmVuY2UgDQogICAgICBiZXR3 ZWVuIEluZm9ybWF0aW9uIE1vZGVscyBhbmQgRGF0YSBNb2RlbHMiLCBKYW51YXJ5IDIwMDMuIA0K ICAgICAgIA0KDQoNCg0KDQoNCg0KDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVz IEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOTBdIA0KDCAgIEludGVy bmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAw NSANCiAgICANCiAgICANCiAgIDEyLiANICAgICAgQXV0aG9ycycgQWRkcmVzc2VzIA0KICAgIA0K ICAgICAgTC4gTGlseSBZYW5nIA0KICAgICAgSW50ZWwgQ29ycC4gDQogICAgICBNYWlsIFN0b3A6 IEpGMy0yMDYgDQogICAgICAyMTExIE5FIDI1dGggQXZlbnVlIA0KICAgICAgSGlsbHNib3JvLCBP UiA5NzEyNCwgVVNBIA0KICAgICAgUGhvbmU6ICsxIDUwMyAyNjQgODgxMyANCiAgICAgIEVtYWls OiBsaWx5LmwueWFuZ0BpbnRlbC5jb20gDQogICAgICAgDQogICAgICBKb2VsIE0uIEhhbHBlcm4g DQogICAgICBNZWdpc3RvIFN5c3RlbXMsIEluYy4gDQogICAgICAyMDI1MSBDZW50dXJ5IEJsdmQu IA0KICAgICAgR2VybWFudG93biwgTUQgMjA4NzQtMTE2MiwgVVNBIA0KICAgICAgUGhvbmU6ICsx IDMwMSA0NDQtMTc4MyANCiAgICAgIEVtYWlsOiBqaGFscGVybkBtZWdpc3RvLmNvbSANCiAgICAg ICANCiAgICAgIFJhbSBHb3BhbCANCiAgICAgIE5va2lhIFJlc2VhcmNoIENlbnRlciANCiAgICAg IDUsIFdheXNpZGUgUm9hZCwgDQogICAgICBCdXJsaW5ndG9uLCBNQSAwMTgwMywgVVNBIA0KICAg ICAgUGhvbmU6ICsxIDc4MSA5OTMgMzY4NSANCiAgICAgIEVtYWlsOiByYW0uZ29wYWxAbm9raWEu Y29tIA0KICAgICAgIA0KICAgICAgQWxhbiBEZUtvayANCiAgICAgIElEVCBJbmMuIA0KICAgICAg MTU3NSBDYXJsaW5nIEF2ZS4gDQogICAgICBPdHRhd2EsIE9OIEsxRyAwVDMsIENhbmFkYSANCiAg ICAgIFBob25lOiArMSA2MTMgNzI0IDYwMDQgZXh0LiAyMzEgDQogICAgICBFbWFpbDogYWxhbi5k ZWtva0BpZHQuY29tIA0KICAgIA0KICAgICAgWnNvbHQgSGFyYXN6dGkgDQogICAgICBNb2R1bGFy IE5ldHdvcmtzIA0KICAgICAgRmlyc3QgRmxpZ2h0IFZlbnR1cmUgQ2VudGVyIA0KICAgICAgMiBE YXZpcyBEcml2ZSANCiAgICAgIFBPIEJveCAxMjA3NiANCiAgICAgIFJlc2VhcmNoIFRyaWFuZ2xl IFBhcmssIE5DIDI3NzA5LCBVU0EgDQogICAgICBQaG9uZTogKzEgOTE5IDc2NSAwMDI3IHgyMDE3 IA0KICAgICAgRW1haWw6IHpzb2x0QG1vZHVsYXJuZXQuY29tIA0KICAgIA0KDQoNCg0KDQoNCg0K DQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgOTFdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9y Q0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAg IFN0ZXZlbiBCbGFrZSANCiAgICAgIE1vZHVsYXIgTmV0d29ya3MgDQogICAgICBGaXJzdCBGbGln aHQgVmVudHVyZSBDZW50ZXIgDQogICAgICAyIERhdmlzIERyaXZlIA0KICAgICAgUE8gQm94IDEy MDc2IA0KICAgICAgUmVzZWFyY2ggVHJpYW5nbGUgUGFyaywgTkMgMjc3MDksIFVTQSANCiAgICAg IFBob25lOiArMSA5MTkgNzY1IDAwMjcgeDIwMTYgDQogICAgICBFbWFpbDogc2xibGFrZUBtb2R1 bGFybmV0LmNvbSANCiAgICAgICANCiAgICAgIEVsbGVuIERlbGVnYW5lcyANCiAgICAgIEludGVs IENvcnAuIA0KICAgICAgTWFpbCBTdG9wOiBKRjMtMjA2IA0KICAgICAgMjExMSBORSAyNXRoIEF2 ZW51ZSANCiAgICAgIEhpbGxzYm9ybywgT1IgOTcxMjQsIFVTQSANCiAgICAgIFBob25lOiArMSA1 MDMgNzEyIDQxNzMgDQogICAgICBFbWFpbDogZWxsZW4ubS5kZWxlZ2FuZXNAaW50ZWwuY29tIA0K ICAgICAgIA0KICAgICAgIA0KICAgMTMuIA0gICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHQgDQogICAgICAgDQogICAgICBUaGUgYXV0aG9ycyBhcmUgbm90IGF3YXJlIG9mIGFueSBpbnRl bGxlY3R1YWwgcHJvcGVydHkgcmlnaHQgDQogICAgICBpc3N1ZXMgcGVydGFpbmluZyB0byB0aGlz IGRvY3VtZW50LiANCiAgICAgICANCiAgIDE0LiANICAgICAgSUFOQSBjb25zaWRlcmF0aW9uIA0K ICAgIA0KICAgICAgQSBuYW1lc3BhY2UgaXMgbmVlZGVkIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRo ZSBMRkIgdHlwZSBpbiB0aGUgTEZCIA0KICAgICAgY2xhc3MgbGlicmFyeS4gIA0KICAgICAgIA0K ICAgICAgRnJhbWUgdHlwZSBzdXBwb3J0ZWQgb24gaW5wdXQgYW5kIG91dHB1dCBvZiBMRkIgbXVz dCBhbHNvIGJlIA0KICAgICAgdW5pcXVlbHkgaWRlbnRpZmllZC4gDQogICAgICAgIA0KICAgICAg QSBzZXQgb2YgbWV0YWRhdGEgc3VwcG9ydGVkIGJ5IHRoZSBMRkIgbW9kZWwgbXVzdCBhbHNvIGJl IHVuaXF1ZWx5IA0KICAgICAgaWRlbnRpZmllZCB3aXRoIG5hbWVzIG9yIElEcy4gDQogICAgICAg DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4 cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5Ml0gDQoM ------_=_NextPart_001_01C4FDA6.2DACDE48-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 19 11:31:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26423 for ; Wed, 19 Jan 2005 11:31:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrIzV-0006oJ-1g for forces-archive@IETF.ORG; Wed, 19 Jan 2005 11:47:33 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F4F016@cherry.ease.lsoft.com>; Wed, 19 Jan 2005 11:31:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54117471 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 19 Jan 2005 11:31:26 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 19 Jan 2005 11:27:06 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005011908262553:36421 ; Wed, 19 Jan 2005 08:26:25 -0800 References: <468F3FDA28AA87429AD807992E22D07E03F0F09B@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/19/2005 08:26:25 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/19/2005 08:26:28 AM, Serialize complete at 01/19/2005 08:26:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106152022.1073.8.camel@jzny.localdomain> Date: Wed, 19 Jan 2005 11:27:02 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: FW: latest update of the model draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03F0F09B@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Tue, 2005-01-18 at 16:41, Deleganes, Ellen M wrote: > This is the latest version of the model draft. The most significant > change was to pull out the class definitions section from this draft > and update the references through the rest of the document. Other > minor editorial changes have also been made. > Please send the diff. I am having a hard time seeing the difference between this and what you posted last time (a few weeks back). > > The major open issue is the need to update the FE and LFB attribute > XML based on the discussions that have been going on in the reflector Is this in any way related to the FE Object XML i posted? FEDocument and relatives in section 5 are now part of the FE OBject LFB - so that section needs to go; I can repost it if needed. Also i dont see any of my suggested changes in the LFB xsd. > as these have to reflect the class definitions. There are a number of > editorial comments throughout these sections that need to be resolved > as the major rework is being done. These were captured in an earlier > email. > Can you repost or create entries in the database for them? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 20 09:12:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29193 for ; Thu, 20 Jan 2005 09:12:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrdJ4-0007Zh-B7 for forces-archive@IETF.ORG; Thu, 20 Jan 2005 09:29:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F50669@cherry.ease.lsoft.com>; Thu, 20 Jan 2005 9:12:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54257013 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 20 Jan 2005 09:12:48 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 20 Jan 2005 09:10:49 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0KE9xxr034958 for ; Thu, 20 Jan 2005 14:10:07 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0KEANGm136500 for ; Thu, 20 Jan 2005 14:10:23 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0KE9wGn025787 for ; Thu, 20 Jan 2005 14:09:58 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0KE9wB9025778 for ; Thu, 20 Jan 2005 14:09:58 GMT Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA78160 for ; Thu, 20 Jan 2005 15:09:58 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <41E3DCFC.3060502@zurich.ibm.com> <006401c4fd71$ad41d100$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.uk.ibm.com id j0KE9xxr034958 Message-ID: <41EFBBB2.6030309@zurich.ibm.com> Date: Thu, 20 Jan 2005 15:09:54 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006401c4fd71$ad41d100$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: >Joel, Robert, and Jamal, > >Firstly, Jamal, I appreciate your efforts, but just could you give me a = little >bit more time for more discussions on the fundamentals, before we can pe= rfectly >settle the PDU? > >>From Joel's original proposal on Index and Robert's comments as below, = I think >the key goes to the state as "if an CE can maintain a copy of any tables= in >FE?". I confess that CE can do this well for routing tables in FE, but I= just >worry about some other tables that FE may actually change the contents o= f the >tables. I can think of these tables as some tables for capabilities, for >statistics, and even for some events. Obviously, CE will not be able to = have a >copy in advance before querying them. This also leads to the difficultie= s for >the use the idea index for them. Therefore, my compromise is, even if = we >choose INDEX, it should not be a MUST for all kinds of tables. > =20 > I think it should be a MUST for all tables to support index-based=20 access. Content-based search keys are optional: your example of=20 FE-dynamically-created content shows that a simple content-based search=20 key would suffice. Note that subsequent accesses may then use the index. >For content-based searching, I have to say again that, when we observe i= t from >the mechanical point of view, index is also a kind of content searching,= that >is, the content is the index(note we will never expect a sequential inde= x). >Therefore, I don't think it makes sense much to discuss if an FE need a = content >searching mechanism or not, instead, we may just need to discuss in whic= h dgree >FE should support such search. > =20 > The main difference is that the index is unique among all entries in a=20 table, as opposed to the content-search key. So the index can be used to=20 refer to a precise unique entry in a table, whereas a content-search key=20 cannot. Remember that the index is an _artificial_ addition introduced=20 by ForCES, whereas the _content_ is there in any case. >When we have the thought that not all tables are always applicable with = Index, >I'm afraid to include content-based searching expression in the protocol= is >unavoidable, unless we assume and make a provisioning that it is only al= lowed to >access a whole table, instead of entries in the table. > =20 > The current path-data text posted by Jamal captures the basic=20 content-search key, with the possiblity to AND multiple keys. If=20 experience shows that this is not sufficient, we can later on extend=20 this with a new TLV. For now I think it is acceptable to move forward=20 with this. Regards, -Robert >Yours, >Weiming > >----- Original Message ----- >From: "Robert Haas" >To: >Sent: Tuesday, January 11, 2005 10:04 PM >Subject: Re: [issue6] Summary of Path > > > =20 > >>Weiming, all, >> >>Wang,Weiming wrote (excerpt): >> >> =20 >> >>>Thinking we have an LFB with following attribute: >>> >>>Foo3, type structure, ID=3D5 >>>{ >>> s1, type u32, ID=3D1 >>> s2, type structure, ID=3D2 >>> { >>> g1, type u32, ID=3D1 >>> g2, type u32, ID=3D2 >>> g3, tyep u32, ID=3D3 >>> } >>>} >>> >>>With mainpath and subpath, I think the format should be like: >>>Mainpath(Foo3) subpath( s1) value subpath(s2.g1) value subpath(s2.g2) = value >>> >>>I actually talked about this before with Joel. I think Joel asked that= in >>> =20 >>> >this > =20 > >>>case, he would rather use three separate path-data to do so, that is, >>> >>>path(Foo3.s1) value >>>path(Foo3.s2.g1) value >>>path(Foo3.s2.g2) value >>> >>>If the above path-values are in one OpTLV, I can more or less live wit= h it, >>> =20 >>> >but > =20 > >>>still think the mainpath and subpath mode is better than this. I suppo= sed >>> =20 >>> >Joel > =20 > >>>asked the path-values be in different OpTLVs, which I'm hard to accept= . I >>> =20 >>> >think > =20 > >>>such operation is originally atomic, to separate them into different O= pTLVs >>> =20 >>> >is > =20 > >>>not reasonable enough. >>> >>>Want to hear what others think about it. >>> >>> >>> >>> =20 >>> >>I find the three separate path-data simpler and clearer. Such path-data >>can be aggregated under the same OpTLV, or they can be in separate >>OpTLVs. The protocol should support both cases. >> >> =20 >> >>>>At 10:24 AM 1/10/2005, Jamal Hadi Salim wrote: >>>> >>>> >>>> =20 >>>> >>>>>Heres a basic first attempt at BNF that would satisfy what you are >>>>>asking for: >>>>> >>>>>OPER_TLV : =3D >>>>>PATH-DATA :=3D [DATAINFO] >>>>>PATH :=3D flags IDcount >>>>>DATAINFO:=3D [SUBPATH] [DATARAW] >>>>>SUBPATH :=3D <[KEYINFO]+ | [BLKINFO]| [INDINFO]> >>>>>DATARAW :=3D somedata [DATAINFO] >>>>> >>>>> >>>>> =20 >>>>> >>> >>> =20 >>> >>I'd like some description of KEYINFO. Or better, an example of how thi= s >>actually looks like for a content-based search key in a simple array. I >>am worried the devil is again in the details. >> >>Regarding the need to support content-based search at all: Joel rightly >>expressed concern about too much sophistication. I also think most of >>the management operations should be handled at the CE, except in the >>case of obvious protocol-efficiency gains. >> >>For instance, the CE is able to convert a content-based access into one >>(or more) index-based access(es), as the CE is supposed to keep track o= f >>what the FE stores. But block operations should not be split into a >>sequence of operations by the CE, even though the CE is very well able >>to do it too. >> >>Index-based accesses are the lowest-common denominator, and >>content-based accesses are an option that each LFB may or may not >>support, with arbitrary or pre-specified keys (or even key >>combinations). Requiring SQL-engine-like capability in an FE would kill >>the spec, I think. >> >>Note that even though the FE must have a (hopefully efficient) >>implementation to retrieve/set an entry from/into its data structs base= d >>on (ForCES) index, it does not mean at all that the FE uses an indexed >>array for the data struct used for datapath lookup. Probably this was >>obvious to everyone here. >> >>Regards, >>-Robert >> >> =20 >> > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 21 09:43:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15380 for ; Fri, 21 Jan 2005 09:43:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0GL-0005LY-Ha for forces-archive@IETF.ORG; Fri, 21 Jan 2005 09:59:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F53593@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 9:43:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54436122 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 09:43:16 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 01:26:55 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Fri, 21 Jan 2005 14:53:45 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Fri, 21 Jan 2005 14:26:28 +0800 References: <1105996187.1079.288.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> Date: Fri, 21 Jan 2005 14:26:32 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Jamal, Thank you for the progressive efforts. Pls see comments inline for the format: OPER TLV : = [Weiming] I suppose you mean +. I see more is, we may even need a DATA more as + [DATA]. This last DATA may be needed by some Query Responses. PATH-DATA := [DATAINFO] PATH := flags IDcount [Weiming]Here, my thinking is the IDs should only be FieldIDs rather than any Indices included. Indices are represented only in the followed INDINFO TLV. I see to include index in this first Path may makes the path not unique for parsing. Moreover, if we use universal 32bit for IDs, we may not need the count. DATAINFO TLV := [SELECTOR] [DATARAW] [Weiming] The DATARAW here I see may better still as DATA, because we still have a case the data here are not purely raws for table. It's still possible it is a whole entry for a table. SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> [weiming]I see there may be only one KEYINFO, instead of KEYINFO+ here, but not very sure. Maybe Joel can comment more. I'v seen below that you'v included the sub fieldIDs in the INDINFO. I think the index and the sub fieldIDs are still possibly exsisting at the same time, therefore to separate it as [INDINFO] and [SUBPATH] is still that I suggest. DATARAW := [DATAINFO] THEDATA := [somedata]* [VARENCDATA TLV]* [Weimig]I'm not very sure of the meaning here. Maybe it has someting to do with data encoding. Hope others can comment more. INDINFO TLV := index | fieldID [Weiming]Let it just for Index, and add another optional TLV as SUBPATH TLV= KEYINFO TLV := KEYID KEY_DATA [Weiming]That's a small confusion to me, I supposed the DATA even for the key should be in the DATAINFO. we may need more explain from Joel also. BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] [Weiming]We may need to dig more into it. I'm not sure if the expression is unique for parsin or not. maybe we need some flags. Thank you. Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Tuesday, January 18, 2005 5:09 AM Subject: updated path data text > Attached updated version. > The outstanding issues are listed in the text. > Please read the text. > > Weiming! I am still waiting to hear from you on this. I have heard from > Joel and he is pretty much set to move forward. Please make your > comments, suggested modifications etc. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 21 10:47:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21054 for ; Fri, 21 Jan 2005 10:47:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1Gi-0007JQ-Lx for forces-archive@IETF.ORG; Fri, 21 Jan 2005 11:04:17 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F53836@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 10:47:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54443445 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 10:47:46 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 10:47:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012107463680:39044 ; Fri, 21 Jan 2005 07:46:36 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/21/2005 07:46:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/21/2005 07:46:38 AM, Serialize complete at 01/21/2005 07:46:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106322434.1088.44.camel@jzny.localdomain> Date: Fri, 21 Jan 2005 10:47:15 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit On Fri, 2005-01-21 at 01:26, Wang,Weiming wrote: > Hi Jamal, > > Thank you for the progressive efforts. Pls see comments inline for the format: > > OPER TLV : = > [Weiming] I suppose you mean +. As the note in the text i posted says: This is an issue for discussion. (In my opinion if we do this we have met about 99% of what you want; however, the discussion is about reaching a consensus). I am indifferent about this. Joel may have issues with it. > I see more is, we may even need a > DATA more as + [DATA]. This last DATA may be needed by some Query > Responses. Thats covered i believe. Look at some of the examples. > PATH-DATA := [DATAINFO] > PATH := flags IDcount > [Weiming]Here, my thinking is the IDs should only be FieldIDs rather than any > Indices included. Indices are represented only in the followed INDINFO TLV. You have said this a few times now. I apologize its not well taken care of in the current BNF and examples - This is because mostly i never understood the desire for this. > I see to include index in this first Path may makes the path not unique for > parsing. Note this is only in the first path. I dont see any ambiguity. Maybe you can provide me an example? > Moreover, if we use universal 32bit for IDs, we may not need the count. We need to know the boundaries. How do you know where the IDs end? We could put things in a TLV but that would have to include flags as well and waste an extra 32 bits. > DATAINFO TLV := [SELECTOR] [DATARAW] > [Weiming] The DATARAW here I see may better still as DATA, If i understood you, you dont like the name DATARAW and you just want the name changed to DATA? > because we still have > a case the data here are not purely raws for table. It's still possible it > is a > whole entry for a table. This is the controvesial piece which is now constrained to be only within KEYINFO. > SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> > [weiming]I see there may be only one KEYINFO, instead of KEYINFO+ here, Did you look at the examples where KEYINFO is used? I thought you had a very different opinion so far. This is also tagged as an issue in the text. Are you agreeing with Joel now? > but not very sure. Maybe Joel can comment more. Joel? > I'v seen below that you'v included the > sub fieldIDs in the INDINFO. I think the index and the sub fieldIDs are still > possibly exsisting at the same time, therefore to separate it as [INDINFO] and Good catch, how does this look: IDINFO := [FIELDINFO]* [INDINFO]* > [SUBPATH] is still that I suggest. > DATARAW := [DATAINFO] > THEDATA := [somedata]* [VARENCDATA TLV]* > [Weimig]I'm not very sure of the meaning here. Maybe it has someting to do with > data encoding. Hope others can comment more. Its also explained in the text with an example. Please read the text in full - it will help speed up these discussions. Essentially, this is to encode non-fixed sized data. > INDINFO TLV := index | fieldID > [Weiming]Let it just for Index, and add another optional TLV as > SUBPATH TLV= Refer to what i said above on IDINFO := [FIELDINFO]* [INDINFO]* > KEYINFO TLV := KEYID KEY_DATA > [Weiming]That's a small confusion to me, I supposed the DATA even for the key > should be in the DATAINFO. we may need more explain from Joel also. I will wait for Joels view - the idea behind keyinfo is to restrict the usage of keys. > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] > [Weiming]We may need to dig more into it. I'm not sure if the expression is > unique for parsin or not. maybe we need some flags. > Agreed; some of these BLKINFO maybe optimized later with flags. Weiming and Joel when you make chnages to the BNF, please walk onto the use cases i provided and say how they change if they are affected. And read the text closely as well so we are all in sync. cheers, jamal From entmib@ietf.org Fri Jan 21 19:54:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11282; Fri, 21 Jan 2005 19:54:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9nl-0007vm-0v; Fri, 21 Jan 2005 20:10:57 -0500 Received: from [208.158.8.50] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1Cs9hd-0001fh-3d; Fri, 21 Jan 2005 20:04:40 -0500 From: "Memorial Cubano" To: MemorialCubano@ns.cnri.reston.va.us Subject: Compaixao, reflexao e oraçoes pelas vitimas do comunismo X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 21 Jan 2005 20:04:40 -0500 X-Spam-Score: 24.7 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a c0501mempComLinks

EnEspanol / InEnglish / InItaliano

Memorial Cubano: pedido de compaixão, reflexão e orações pelas vítimas do comunismo

A ajuda que lhes solicitamos é de caráter espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros:

* Precisamos de sua valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do comunismo, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus.

* Entre os dias 18 e 20 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão pelo terceiro ano consecutivo o Memorial Cubano, com mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do comunismo em Cuba. Familiares desterrados que nunca puderam dar o adeus a esses seres queridos assassinados, por não lhes ser permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área será colocada uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram em nossa Pátria por causa do comunismo, porém, a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta homenagem espiritual? Simplesmente enviando uma mensagem de adesão e compaixão, uma reflexão, uma promessa de orações (que podem ser individuais, com sua família, comunidade ou colegas de trabalho), encomendar uma Missa ou serviço religioso, etc. Solicitamos-lhes que as Missas ou ofícios religiosos sejam encomendados, se for possível, entre os dias 18 e 20 de fevereiro. Porém, também podem ser antes ou depois. Assim, no mundo inteiro se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão solicitá-las em benefício das "vítimas do genocídio cubano sob o comunismo".

* Muitas dessas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando: "Viva Cristo Rei!"

* Confirmem-nos o quanto antes suas adesões, fazendo clic em:

Memorial:MinhaMensagemDeCompaixao / Memorial:MinhaMensagemDeAdesao (todas as mensagens de compaixão e de adesão passarão a formar parte do acervo histórico do Memorial Cubano)

Memorial:ConfirmamosMissa/ServicoReligioso/Oracoes (por favor, incluam local, data e, se o desejarem, outros detalhes).

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: antecipadamente, que a Providência os recompense com o cêntuplo já nesta terra.

Com a maior consideração e estima,

Renato Gomez

Coordenador Geral

Comitê Organizador do Memorial Cubano / tel. (1-786) 621-7505 Miami FL

PS: Em suas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida tentando alcançar a liberdade. Estima-se que o número deles seja de muitas dezenas de milhares de cubanos.

Finalmente, rezem pelos presos de consciência que agonizam nos cárceres, como o médico pró-vida Oscar Elías Biscet, o ativista de direitos humanos cego, Juan Carlos González Leyva e milhares de outros irmãos cubanos.

DeseoInformacaoPresosDeConsciencia.

LINKS PRIORITÁRIOS:

ConfirmoMissa/Oracoes (incluindo nome, local, data e, se o desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc. Pode incluir também sugestões)

Memorial:MinhaMensagemDeAdesao

Memorial:MinhaMensagemDeCompaixao

Memorial:MinhaOpiniao (para incluir sugestões, discordâncias, etc.)

OUTROS LINKS:

DesejoReceberMaisInfoMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com os nomes de todas as vítimas)

DesejoReceberMaisInfoPresosPoliticos

Memorial:Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Direitos Sem Fronteiras (DSF)

Tradução: Graça Salgueiro

From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 21 22:31:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18416 for ; Fri, 21 Jan 2005 22:31:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsCGH-0002YR-NX for forces-archive@IETF.ORG; Fri, 21 Jan 2005 22:48:34 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F5543F@cherry.ease.lsoft.com>; Fri, 21 Jan 2005 22:31:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54539360 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 21 Jan 2005 22:31:50 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 21 Jan 2005 22:23:19 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0M3NJ48022596 for ; Sat, 22 Jan 2005 03:23:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0M3NJ68001264 for ; Sat, 22 Jan 2005 03:23:19 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005012119231914262 for ; Fri, 21 Jan 2005 19:23:19 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jan 2005 19:23:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN Thread-Index: AcT/0g/oa2cZX7EATkCKCdOjA7YetgAU26aw X-OriginalArrivalTime: 22 Jan 2005 03:23:19.0543 (UTC) FILETIME=[B84DC870:01C50031] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Fri, 21 Jan 2005 19:23:18 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable FYI! Cheers, David =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Friday, January 21, 2005 7:43 AM To: IETF-Announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN=20 There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting=20 in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions=20 All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET.=20 As always, all initial submissions (-00) with a filename beginning with "draft-ietf"=20 must be approved by the appropriate WG Chair before they can be processed or announced.=20 WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st=20 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not=20 be made available in the Internet-Drafts directory or announced, and will have to be=20 resubmitted. Please do not wait until the last minute to submit. The Secretariat will=20 begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET,=20 but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns,=20 then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF=20 Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 22 02:10:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05103 for ; Sat, 22 Jan 2005 02:10:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsFfN-0006Xe-6Q for forces-archive@IETF.ORG; Sat, 22 Jan 2005 02:26:45 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F55AD9@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 2:10:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54558332 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 02:10:00 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 02:09:28 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 22 Jan 2005 15:36:22 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 22 Jan 2005 15:08:52 +0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> Date: Sat, 22 Jan 2005 15:08:56 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: updated path data text > On Fri, 2005-01-21 at 01:26, Wang,Weiming wrote: > > Hi Jamal, > > > > Thank you for the progressive efforts. Pls see comments inline for the format: > > > > OPER TLV : = > > [Weiming] I suppose you mean +. > > As the note in the text i posted says: This is an issue for discussion. > (In my opinion if we do this we have met about 99% of what you want; > however, the discussion is about reaching a consensus). > I am indifferent about this. Joel may have issues with it. I'm sorry I'v made a confusion by myself. Actually I'm indifferent of or +, IF ONLY we are going to have Subpaths with SubfieldIDs included in the followed DATA field. > > > I see more is, we may even need a > > DATA more as + [DATA]. This last DATA may be needed by some Query > > Responses. > > Thats covered i believe. Look at some of the examples. This also follows above thought. If we have, as you mentioned, the Path Selector Data Selector Data mode, this is not a problem. > > > PATH-DATA := [DATAINFO] According to your followed explanation, I suppose it should be: PATH-DATA := [DATAINFO]* Is it? > > PATH := flags IDcount > > [Weiming]Here, my thinking is the IDs should only be FieldIDs rather than any > > Indices included. Indices are represented only in the followed INDINFO TLV. > > You have said this a few times now. I apologize its not > well taken care of in the current BNF and examples - This is because > mostly i never understood the desire for this. > > > I see to include index in this first Path may makes the path not unique for > > parsing. > > Note this is only in the first path. I dont see any ambiguity. Maybe you > can provide me an example? Let me just try to use your example to show the possible ambiguity. table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 Then, according to your scheme, I understand, to access the #1 entry, we may use the Path=4.1, but I can understand this also as trying to access the j1 row of the table, which Path is also 4.1. > > > Moreover, if we use universal 32bit for IDs, we may not need the count. > > We need to know the boundaries. How do you know where the IDs end? > We could put things in a TLV but that would have to include flags as > well and waste an extra 32 bits. We have a different view here. I think the Path here should be represented as a TLV. That is, PATH TLV = flags I don't see any waste for bits here. > > > DATAINFO TLV := [SELECTOR] [DATARAW] > > [Weiming] The DATARAW here I see may better still as DATA, > > If i understood you, you dont like the name DATARAW and you just want > the name changed to DATA? > > > because we still have > > a case the data here are not purely raws for table. It's still possible it > > is a > > whole entry for a table. > > This is the controvesial piece which is now constrained to be only > within KEYINFO. My understanding of KEYINFO and the sub FIELDINFO I proposed are only optional, therefore Data are not purely raws. > > > SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> > > [weiming]I see there may be only one KEYINFO, instead of KEYINFO+ here, > > Did you look at the examples where KEYINFO is used? I thought you had a > very different opinion so far. This is also tagged as an issue in the > text. Are you agreeing with Joel now? After read your examples provided, I confess I'v understood more. But I have to say the examples you set on KEYINFO is actually what I mean the FIELDINFO. I don't think Joel's KEY is the same as you provided in the e.g. Even so, the example is still valuble to me, for I understand what you mean the '+' here. I suppose it should also apply to FIELDINFO below, i.e., [FIELDINFO] should be [FIELDINFO]+ . > > > but not very sure. Maybe Joel can comment more. > > Joel? > > > I'v seen below that you'v included the > > sub fieldIDs in the INDINFO. I think the index and the sub fieldIDs are still > > possibly exsisting at the same time, therefore to separate it as [INDINFO] and > > Good catch, how does this look: > IDINFO := [FIELDINFO]* [INDINFO]* Yes, that's it,though I think the SUBPATH is more relavent to the FIELDINFO meaning here. > > > > [SUBPATH] is still that I suggest. > > DATARAW := [DATAINFO] > > THEDATA := [somedata]* [VARENCDATA TLV]* > > [Weimig]I'm not very sure of the meaning here. Maybe it has someting to do with > > data encoding. Hope others can comment more. > > Its also explained in the text with an example. Please read the text in > full - it will help speed up these discussions. > Essentially, this is to encode non-fixed sized data. > > > INDINFO TLV := index | fieldID > > [Weiming]Let it just for Index, and add another optional TLV as > > SUBPATH TLV= > > Refer to what i said above on IDINFO := [FIELDINFO]* [INDINFO]* > > > KEYINFO TLV := KEYID KEY_DATA > > [Weiming]That's a small confusion to me, I supposed the DATA even for the key > > should be in the DATAINFO. we may need more explain from Joel also. after read your examples, I can accept to move some DataINFO here. Then, I try to suggest the SUBPATH TLV (or you call FIELDINFO TLV) as: SUBPATH TLV := counts The_Data Note that there are possibly moer than one level of fieldIDs here, just thinking in your example of table2, j1 is structure instead of an atom. Thank you. Weiming > > I will wait for Joels view - the idea behind keyinfo is to restrict the > usage of keys. > > > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] > > [Weiming]We may need to dig more into it. I'm not sure if the expression is > > unique for parsin or not. maybe we need some flags. > > > > Agreed; some of these BLKINFO maybe optimized later with flags. > > Weiming and Joel when you make chnages to the BNF, please walk onto the > use cases i provided and say how they change if they are affected. > And read the text closely as well so we are all in sync. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 22 03:23:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16811 for ; Sat, 22 Jan 2005 03:23:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsGol-0007yl-J9 for forces-archive@IETF.ORG; Sat, 22 Jan 2005 03:40:28 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F55BDF@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 3:23:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54562339 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 03:23:49 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 03:21:52 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 22 Jan 2005 16:48:58 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 22 Jan 2005 16:21:27 +0800 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <41E3DCFC.3060502@zurich.ibm.com> <006401c4fd71$ad41d100$020aa8c0@wwm1> <6.1.2.0.0.20050118104416.03af9350@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <1a6b01c5005b$61c8ca20$845c21d2@Necom.hzic.edu.cn> Date: Sat, 22 Jan 2005 16:21:33 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Joel, and Robert as well, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path > >I certainly agree that being forced to fetch (or worse update) entire > >tables would be a very bad choice. > > However, I have not yet seen a convincing case for either > 1) a situation where indices are not supportable That's one of the arguing point. Althought I cannot give a very clear look of the difficulty when indexapplied to tables that are originated from FE, I see the potentials for the difficulty. I can't see it very clear because the XML definitions for LFBs have still not yet been presented(That's one reason I suggeted for the fast work on it). The potential difficulty comes like in this way, a table, althought whose structure is defined by ForCES and can be accessed by CE, whose entries are not added by CE, instead, should by FE during run time. In this case, I presumed the index for the entires should be generated by CE, but obviously it leads to some difficulty. Now I want to focus our arguements based on this as: 1. Are you absolutely sure there will be no such tables for ForCES? 2. If isn't, then how can we deal with it if an index is MUST for all tables? > 2) a situation where arbitrary keying is needed. Here arbitrary refers to > either of non-unique keys or keys that are not declared by the LFB class > definition. Let's try to think of two kinds of LFBs: LPF LFB and Classifer LFB. The rule attribute for an LPF LFB may include the fields as: the Prefix with its Mask, the Nexthop. Then, which one do you think more preferable as Keys? I just see they are all needed as searching keys. I think it's well known that if all fields should be keys, there is no meaning to define keys anymore. Then the Classifier LFB, the rule attribute for which may include fields as: MatchField1, MatchField2, ... MatchFieldN, OutputPort. Usually any MatchField has no privileges over others. I just see that, if we allow for one MatchField as a searching key, we have no reason for others as keys. As a result, this also leads to non unique keys. Unless we have actual experiences with XML LFBs, I think it's too early to say a limited key is meaningful. Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 22 10:27:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10323 for ; Sat, 22 Jan 2005 10:26:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsNQI-0008Cg-GJ for forces-archive@IETF.ORG; Sat, 22 Jan 2005 10:43:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F56313@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 10:26:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54616487 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 10:26:52 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 10:10:07 -0500 Received: from [68.232.106.194] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8796782 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 10:10:06 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050122095802.06550ec0@localhost> Date: Sat, 22 Jan 2005 10:09:46 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d I'll comment on some of the other issues later, but I wanted to get these two highlighted. Firstly, I would strongly prefer to use +, i.e. multiple occurrences of the PATH-DATA TLV rather than the Subpaths with SubPath IDs. Secondly, with regard to the indexing and content addressing, as described there is some ambiguity which must be removed. There are several ways to remove it. 1) We can assign an identifier, declared with the array type, for each form of indexing. Thus, the path 4 would be the array, 4.1 would be the array, indexed by the subscript, and 4.2 would be the array with the element sleected by a specific declared key. Then the j1 element is 4.1.1 or 4.2.1. 2) We can declare that 4 means the whole array and 4.1 means the array with some form of indexing or content selection, where the key / index is identified in the keying / indexing TLV. Then 4.1.1 is the j1 element no matter what key is being used for the selection. In both those cases, the index value or content lookup value is in its own TLV. A third alternative becomes possible if we place restrictions on when content keying is used. Some of the advocates for content keying wanted it only used for leaf selection. In that case, we would use a flag to indicate that content keying is to be applied to the path after it is fully parsed. In that case, to reference the j1 element of the second index off array 4 one would use 4.2.1. However, to reference the structure in array 4 ata certain content key one would use the 4 as the path. This would not permit referencing just the j1 element when doing content keying. This has the advantage of allowing us to use the indexing in the path sequence, making the common case simpler. However, it has the disadvantage that it restricts the application of content keying. I mention this because at least two different discussants who have not been active recently had asked for this particular combination in earlier rounds of this debate. Yours, Joel M. Halpern At 02:08 AM 1/22/2005, Wang,Weiming wrote: >I'm sorry I'v made a confusion by myself. Actually I'm indifferent of > or +, IF ONLY we are going to have Subpaths with >SubfieldIDs included in the followed DATA field. > ... > > > PATH := flags IDcount > > > [Weiming]Here, my thinking is the IDs should only be FieldIDs rather than >any > > > Indices included. Indices are represented only in the followed > INDINFO TLV. > > > > You have said this a few times now. I apologize its not > > well taken care of in the current BNF and examples - This is because > > mostly i never understood the desire for this. > > > > > I see to include index in this first Path may makes the path not > unique for > > > parsing. > > > > Note this is only in the first path. I dont see any ambiguity. Maybe you > > can provide me an example? > >Let me just try to use your example to show the possible ambiguity. > >table2: type array, ID = 4 > elements are: > j1, type u32, ID = 1 > j2, type u32, ID = 2 > >Then, according to your scheme, I understand, to access the #1 entry, we >may use >the Path=4.1, but I can understand this also as trying to access the j1 row of >the table, which Path is also 4.1. From owner-forces@PEACH.EASE.LSOFT.COM Sat Jan 22 10:31:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10579 for ; Sat, 22 Jan 2005 10:31:22 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsNUZ-0008He-GZ for forces-archive@IETF.ORG; Sat, 22 Jan 2005 10:48:03 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F562F9@cherry.ease.lsoft.com>; Sat, 22 Jan 2005 10:31:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54616774 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 10:31:21 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 22 Jan 2005 10:23:41 -0500 Received: from [68.232.106.194] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8796926 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 22 Jan 2005 10:23:41 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> <006601c4f259$2eb48490$845c21d2@Necom.hzic.edu.cn> <1104941788.1118.223.camel@jzny.localdomain> <027701c4f53c$d45416a0$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050108001135.03b85490@localhost> <1105330894.1040.50.camel@jzny.localdomain> <02e701c4f722$c1b7bf50$845c21d2@Necom.hzic.edu.cn> <1105370675.1084.16.camel@jzny.localdomain> <6.1.2.0.0.20050110103740.06529c00@localhost> <003a01c4f796$51f8a020$845c21d2@Necom.hzic.edu.cn> <41E3DCFC.3060502@zurich.ibm.com> <006401c4fd71$ad41d100$020aa8c0@wwm1> <6.1.2.0.0.20050118104416.03af9350@localhost> <1a6b01c5005b$61c8ca20$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050122101224.066d3af0@localhost> Date: Sat, 22 Jan 2005 10:23:22 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue6] Summary of Path To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1a6b01c5005b$61c8ca20$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 There certainly may be tables which, for some FEs, are generated by the FE. In some FEs they may even be such that the CE can not modify them. I doubt that there will be any LFB classes where the class assumes that is always the case. Even in such cases, the FE can assign indices to the entries in a dense fashion. Remember that even CAMs are actually arrays (a sequence of memory entries) under the covers. Even if the FE implementation chooses to use complex tree structures to represent something, there are still well known algorithms for assigning and using indices in such structures. Possibly this is a failure of my imagination, but I really can not imagine a situation in which the FE can not support indexed access. Note that performing arbitrary searches is a lot more logic than maintaining indexing information. So any FE that can support arbitrary searches can easily support indexes. With regard to the question of where arbitrary keying is needed, the question turns on the view of the operation. From my perspective, content keying is potentially useful if it makes a CEs job easier. The first thing that affects my view is the previous paragraph. If basic indexing can not be counted on, then there is indeed a complex issue about what can be counted on. Given that we define the keys (if we allow them) it follows that we can reasonably require uniqueness for them. We structure the LFB definition so that fields which are keys are naturally unique. (For example, for a longest prefix match LFB which uses IP address & prefix length keying, multiple next-hops would be represented as a table within the selected entry, rather than representing them as multiple entries with the same key. Note this does not mean that the real hardware implements it as a two level table, but rather that the FE can manage the information exchange.) Remember that the LFB definition is an abstraction of the structure intended to allow many different actual implementations. In order for content keying to be useful to the CE, the CE programmer has to know, for any given LFB class, what things make sense to use. Thus, arbitrary keying only makes sense if we expect the CE to behave very differently (use completely different keying) for different FEs. While obviously there are variations in CE response based on FE capabilities, the idea is that most things will work the same way. Otherwise, we have not achieved multi-vendor interoperability. Yours, Joel M. Halpern At 03:21 AM 1/22/2005, Wang,Weiming wrote: >Joel, and Robert as well, > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: [issue6] Summary of Path > > > > >I certainly agree that being forced to fetch (or worse update) entire > > >tables would be a very bad choice. > > > > However, I have not yet seen a convincing case for either > > 1) a situation where indices are not supportable >That's one of the arguing point. Althought I cannot give a very clear look of >the difficulty when indexapplied to tables that are originated from FE, I see >the potentials for the difficulty. I can't see it very clear because the XML >definitions for LFBs have still not yet been presented(That's one reason I >suggeted for the fast work on it). >The potential difficulty comes like in this way, a table, althought whose >structure is defined by ForCES and can be accessed by CE, whose entries >are not >added by CE, instead, should by FE during run time. In this case, I >presumed the >index for the entires should be generated by CE, but obviously it leads to >some >difficulty. Now I want to focus our arguements based on this as: >1. Are you absolutely sure there will be no such tables for ForCES? >2. If isn't, then how can we deal with it if an index is MUST for all tables? > > > 2) a situation where arbitrary keying is needed. Here arbitrary refers to > > either of non-unique keys or keys that are not declared by the LFB class > > definition. >Let's try to think of two kinds of LFBs: LPF LFB and Classifer LFB. > >The rule attribute for an LPF LFB may include the fields as: the Prefix >with its >Mask, the Nexthop. Then, which one do you think more preferable as Keys? I >just >see they are all needed as searching keys. I think it's well known that if all >fields should be keys, there is no meaning to define keys anymore. > >Then the Classifier LFB, the rule attribute for which may include fields as: >MatchField1, MatchField2, ... MatchFieldN, OutputPort. Usually any MatchField >has no privileges over others. I just see that, if we allow for one MatchField >as a searching key, we have no reason for others as keys. As a result, >this also >leads to non unique keys. > >Unless we have actual experiences with XML LFBs, I think it's too early to >say a >limited key is meaningful. > >Cheers, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 24 09:20:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14260 for ; Mon, 24 Jan 2005 09:20:24 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct5LK-0005G6-D6 for forces-archive@IETF.ORG; Mon, 24 Jan 2005 09:37:30 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F58AE7@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 8:55:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54862847 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 08:55:21 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 08:54:07 -0500 Received: from [219.82.177.150] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Mon, 24 Jan 2005 22:21:38 +0800 (CST) References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <003901c5021c$a10a16e0$020aa8c0@wwm1> Date: Mon, 24 Jan 2005 21:57:15 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: updated path data text > I'll comment on some of the other issues later, but I wanted to get these > two highlighted. > > Firstly, I would strongly prefer to use +, i.e. multiple > occurrences of the PATH-DATA TLV rather than the Subpaths with SubPath IDs. I certainly can not get the reasons why Subpaths are so unacceptable to you. Let me try to use an example quite identical to Jamal's and with your index included to explain more on the advantage with the subpaths. Also I hope you can also show some of its disadvantages, and some advantages with the multiple separate path-data approach. A table attribute for an LFB as defined: table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 3 j4, type u32, ID = 4 Now, the configure task is: to set the j1 to 100, and j2 to 200, j3 to 300, and remain j4 as it is, for Index of the table (1, 3, 5, 7, 9). To use the separate Path-Data way, we have a sequence of Path-Data as: OpTLV= 'Set' ... Path(4.1) IndexTLV (1,3,5,7,9) Data(100) Path(4.2) IndexTLV (1,3,5,7,9) Data(200) Path(4.3) IndexTLV (1,3,5,7,9) Data(300) To use a subpath way, we have a path-data as: Path(4) IndexTLV(1,3,5,7,9) Subpath(1) Data(100) Subpath(2) Data(200) Subpath(3) Data(300) Obviously, I can see the advantage for the latter approaches. I have to say a path with subpaths expression, that is a tree structure in nature, is more relavant to LFB attribute nature, because they are also naturally tree structured with the AttributeID as the node and the FieldIDs their leaves. Yours, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 24 12:47:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05519 for ; Mon, 24 Jan 2005 12:47:31 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8Zo-0005Hu-3p for forces-archive@IETF.ORG; Mon, 24 Jan 2005 13:04:40 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F59100@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 12:47:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54893997 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 12:47:21 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 12:44:10 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012409432615:106 ; Mon, 24 Jan 2005 09:43:26 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 09:43:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 09:43:28 AM, Serialize complete at 01/24/2005 09:43:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106588646.1072.9.camel@jzny.localdomain> Date: Mon, 24 Jan 2005 12:44:06 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Weiming, On Sat, 2005-01-22 at 02:08, Wang,Weiming wrote: > Let me just try to use your example to show the possible ambiguity. > > table2: type array, ID = 4 > elements are: > j1, type u32, ID = 1 > j2, type u32, ID = 2 > > Then, according to your scheme, I understand, to access the #1 entry, we may use > the Path=4.1, but I can understand this also as trying to access the j1 row of > the table, which Path is also 4.1. Aha! I think this is the CORE source of all miscommunication we have had. So i am gonna delete everything we have said so far and try to settle this issue first. 4.1 is a path to "table2 row 1" _NOT_ to "any cell j1 in table2" as you have it. 4.1 can be used only when row 1 exists and not before. In the case of "table2 row 1" it may also be addressed as path=4 with index=1 - this is not an ambiguity, rather an alternative. I think we need to settle this first or we will talking about different things. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 24 13:21:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08525 for ; Mon, 24 Jan 2005 13:21:22 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct96Y-0006df-CS for forces-archive@IETF.ORG; Mon, 24 Jan 2005 13:38:32 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F591FA@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 13:20:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54898713 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 13:20:44 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 13:15:18 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0OIFIxr086710 for ; Mon, 24 Jan 2005 18:15:18 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0OIFI1g151348 for ; Mon, 24 Jan 2005 18:15:18 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0OIFHYo009966 for ; Mon, 24 Jan 2005 18:15:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0OIFHn9009958; Mon, 24 Jan 2005 18:15:17 GMT Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA86344; Mon, 24 Jan 2005 19:15:17 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <1106588646.1072.9.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.uk.ibm.com id j0OIFIxr086710 Message-ID: <41F53B35.9000104@zurich.ibm.com> Date: Mon, 24 Jan 2005 19:15:17 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: updated path data text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106588646.1072.9.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Jamal Hadi Salim wrote: >Weiming, > >On Sat, 2005-01-22 at 02:08, Wang,Weiming wrote: > =20 > >>Let me just try to use your example to show the possible ambiguity. >> >>table2: type array, ID =3D 4 >> elements are: >> j1, type u32, ID =3D 1 >> j2, type u32, ID =3D 2 >> >>Then, according to your scheme, I understand, to access the #1 entry, w= e may use >>the Path=3D4.1, but I can understand this also as trying to access the = j1 row of >>the table, which Path is also 4.1. >> =20 >> > >Aha! >I think this is the CORE source of all miscommunication we have had. >So i am gonna delete everything we have said so far and try to settle >this issue first. > >4.1 is a path to "table2 row 1" _NOT_ to "any cell j1 in table2" as you >have it. 4.1 can be used only when row 1 exists and not before. >In the case of "table2 row 1" it may also be addressed as path=3D4 with >index=3D1 - this is not an ambiguity, rather an alternative. > =20 > Indeed, but my assumption was that 4.1 is the element with index 1 in=20 table2, i.e., using the rule: - If the object x is an array, then x.y refers to element with index y=20 in the array. - else (object x is not an array), then x.y refers to element with ID y=20 in the object. So to address element j1 in the 1st entry of table2, one would write:=20 4.1.1 (or more explicitely: ID4.index1.ID1). In order to address the entire row of elements j1, one should make an=20 explicit difference between index and ID: ID4.index1 (1st entry in the array) is different from ID4.ID1 (first row=20 of the array). The less flexible alternative is to change the definition of table2 to=20 include instead two arrays j1 and j2, but then one cannot address the=20 first entry j1,j2, of course. Regards, -Robert >I think we need to settle this first or we will talking about different >things. > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 24 14:18:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14102 for ; Mon, 24 Jan 2005 14:18:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtA05-0000cq-Kn for forces-archive@IETF.ORG; Mon, 24 Jan 2005 14:35:50 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F59233@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 14:18:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54903105 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 14:18:39 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 14:17:52 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012411171010:258 ; Mon, 24 Jan 2005 11:17:10 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <1106588646.1072.9.camel@jzny.localdomain> <41F53B35.9000104@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 11:17:10 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 11:17:11 AM, Serialize complete at 01/24/2005 11:17:11 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106594270.1079.45.camel@jzny.localdomain> Date: Mon, 24 Jan 2005 14:17:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <41F53B35.9000104@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Mon, 2005-01-24 at 13:15, Robert Haas wrote: > Indeed, but my assumption was that 4.1 is the element with index 1 in > table2, i.e., using the rule: > - If the object x is an array, then x.y refers to element with index y > in the array. > - else (object x is not an array), then x.y refers to element with ID y > in the object. > > So to address element j1 in the 1st entry of table2, one would write: > 4.1.1 (or more explicitely: ID4.index1.ID1). > nod. > In order to address the entire row of elements j1, one should make an > explicit difference between index and ID: > ID4.index1 (1st entry in the array) is different from ID4.ID1 (first row > of the array). > I didnt follow: Did you mean "first column" in the case of ID4.ID1? Note, so far we have been defering talking about columns or cells within a row (subset of a column). Maybe a good time to start discusing this; i believe that a block operation complimented by a FIELDINFO TLV would suffice to describe the column coordinates of interest. In othewise this would be a cartesian x,y coordinate scheme with the block describing the indices(X) and the fieldinfo will describe the column(Y). > The less flexible alternative is to change the definition of table2 to > include instead two arrays j1 and j2, but then one cannot address the > first entry j1,j2, of course. I think this will complicate things further. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jan 24 14:31:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15144 for ; Mon, 24 Jan 2005 14:31:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtACr-000190-HC for forces-archive@IETF.ORG; Mon, 24 Jan 2005 14:49:01 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F5936A@cherry.ease.lsoft.com>; Mon, 24 Jan 2005 14:31:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 54904425 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 24 Jan 2005 14:31:51 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 24 Jan 2005 14:31:26 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012411304364:285 ; Mon, 24 Jan 2005 11:30:43 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> <003901c5021c$a10a16e0$020aa8c0@wwm1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 11:30:43 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/24/2005 11:30:44 AM, Serialize complete at 01/24/2005 11:30:44 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106595083.1079.61.camel@jzny.localdomain> Date: Mon, 24 Jan 2005 14:31:23 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003901c5021c$a10a16e0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit I was gonna have Joel take this but couldnt resist, sorry ;-> On Mon, 2005-01-24 at 08:57, Weiming Wang wrote: > A table attribute for an LFB as defined: > > table2: type array, ID = 4 > elements are: > j1, type u32, ID = 1 > j2, type u32, ID = 2 > j3, type u32, ID = 3 > j4, type u32, ID = 4 > > Now, the configure task is: to set the j1 to 100, and j2 to 200, j3 to 300, and > remain j4 as it is, for Index of the table (1, 3, 5, 7, 9). > > To use the separate Path-Data way, we have a sequence of Path-Data as: > OpTLV= 'Set' ... > Path(4.1) IndexTLV (1,3,5,7,9) Data(100) > Path(4.2) IndexTLV (1,3,5,7,9) Data(200) > Path(4.3) IndexTLV (1,3,5,7,9) Data(300) > > To use a subpath way, we have a path-data as: > Path(4) IndexTLV(1,3,5,7,9) > Subpath(1) Data(100) > Subpath(2) Data(200) > Subpath(3) Data(300) > > Obviously, I can see the advantage for the latter approaches. > If by subpaths you mean fieldinfos (or is it selctor in general), then i think after last exachange weve had they will show up in the BNF (recall the IDINFO construct). Let me for example show how the above will be incorporated in the BNF i posted (with addition of FIELDINFO): operation = SET Path: Flags = F_REPLACE, IDCount = 1, IDs=4 SELECTOR := // select the rows BLK_LIST_INDEX, L = XXX V = {1,3,5,7,9} // select the columns FIELDINFO = {1,2,3} // data to use DATAINFO TLV, Length = XXXX V = {100, 200, 300} cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 25 13:47:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27470 for ; Tue, 25 Jan 2005 13:47:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtVz9-0003eh-A6 for forces-archive@IETF.ORG; Tue, 25 Jan 2005 14:04:22 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F5BC80@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 13:46:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55052282 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 13:46:56 -0500 Approved-By: rha@ZURICH.IBM.COM Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 13:03:33 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0PI3V7E136028 for ; Tue, 25 Jan 2005 18:03:31 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0PI3VIf133736 for ; Tue, 25 Jan 2005 18:03:31 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0PI3ULn001491 for ; Tue, 25 Jan 2005 18:03:30 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0PI3UfI001488; Tue, 25 Jan 2005 18:03:30 GMT Received: from [127.0.0.1] (dhcp69-100.zurich.ibm.com [9.4.69.100]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA91272; Tue, 25 Jan 2005 19:03:30 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <1106588646.1072.9.camel@jzny.localdomain> <41F53B35.9000104@zurich.ibm.com> <1106594270.1079.45.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j0PI3V7E136028 Message-ID: <41F689E6.9010806@zurich.ibm.com> Date: Tue, 25 Jan 2005 19:03:18 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: updated path data text Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106594270.1079.45.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Jamal Hadi Salim wrote: >On Mon, 2005-01-24 at 13:15, Robert Haas wrote: > > =20 > >>Indeed, but my assumption was that 4.1 is the element with index 1 in=20 >>table2, i.e., using the rule: >>- If the object x is an array, then x.y refers to element with index y=20 >>in the array. >>- else (object x is not an array), then x.y refers to element with ID y= =20 >>in the object. >> >>So to address element j1 in the 1st entry of table2, one would write:=20 >>4.1.1 (or more explicitely: ID4.index1.ID1). >> >> =20 >> > >nod. > > =20 > >>In order to address the entire row of elements j1, one should make an=20 >>explicit difference between index and ID: >>ID4.index1 (1st entry in the array) is different from ID4.ID1 (first ro= w=20 >>of the array). >> >> =20 >> > >I didnt follow: Did you mean "first column" in the case of ID4.ID1? > =20 > no, I meant the entire first row, i.e., the array composed of the j1=20 elements only. First column (=3D1st entry of the array) is ID4.index1. Regards, -Robert >Note, so far we have been defering talking about columns or cells within >a row (subset of a column). Maybe a good time to start discusing this; i >believe that a block operation complimented by a FIELDINFO TLV would >suffice to describe the column coordinates of interest. In othewise this >would be a cartesian x,y coordinate scheme with the block describing the >indices(X) and the fieldinfo will describe the column(Y). > > =20 > >>The less flexible alternative is to change the definition of table2 to= =20 >>include instead two arrays j1 and j2, but then one cannot address the=20 >>first entry j1,j2, of course. >> =20 >> > > >I think this will complicate things further. > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 25 14:09:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28654 for ; Tue, 25 Jan 2005 14:09:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtWKX-0004Ka-8G for forces-archive@IETF.ORG; Tue, 25 Jan 2005 14:26:27 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F5BCB4@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 14:09:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55055101 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 14:09:03 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 14:04:54 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8849397 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 14:04:54 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <1106588646.1072.9.camel@jzny.localdomain> <41F53B35.9000104@zurich.ibm.com> <1106594270.1079.45.camel@jzny.localdomain> <41F689E6.9010806@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050125140328.03b5bec0@localhost> Date: Tue, 25 Jan 2005 14:04:21 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <41F689E6.9010806@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Once can imagine arbitrary joins, arbitrary selections, etc. But, given what ForCES is trying to do, does the CE really need this kind of flexibility? Yours, Joel At 01:03 PM 1/25/2005, Robert Haas wrote: >no, I meant the entire first row, i.e., the array composed of the j1 >elements only. >First column (=1st entry of the array) is ID4.index1. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jan 25 15:21:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04456 for ; Tue, 25 Jan 2005 15:21:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtXSz-0006aU-7M for forces-archive@IETF.ORG; Tue, 25 Jan 2005 15:39:14 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F5BEB9@cherry.ease.lsoft.com>; Tue, 25 Jan 2005 15:21:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55060694 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 25 Jan 2005 15:21:47 -0500 Approved-By: jon.maloy@ERICSSON.COM Received: from 198.24.6.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 25 Jan 2005 15:10:38 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id j0PKBQCR027337; Tue, 25 Jan 2005 14:11:29 -0600 (CST) Received: by eamrcnt751 with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Jan 2005 14:10:13 -0600 Received: from [142.133.72.71] (142.133.72.71 [142.133.72.71]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id DJ1NTX8B; Tue, 25 Jan 2005 15:10:09 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 References: A<022201c4fbb9$673f9c00$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41F6A79C.1080601@ericsson.com> Date: Tue, 25 Jan 2005 15:10:04 -0500 Reply-To: Jon Maloy Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: Re: [issue 7] HB msg Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <022201c4fbb9$673f9c00$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 2.8 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit I think it it time for me to reiterate what I said during the last meeting in DC. As I see it, it is not the task of the PL layer to prescribe how connection or peer failure should be performed, i.e, whether it should be by heartbeats or any other mechanism. The PL layer could state a _maximum failure detection time_ for the connection, register an event for this type of failure in the PL/TML API, and then leave the details to the TML. It is true that for TCP and for most other TMLs we will probably implement this as a heartbeat supervision, but in some cases (e.g. when a inteface board can detect and report carrier loss), failure can be detected much earlier. This is not an possibility we should preclude by making unnecessary assumptions in the PL layer. Also, there are many ways to implement a HB protocol, and I see no reason for the PL to impose a rigid and costly scheme of failure detection which the TML potentially (I know an example) can make more efficient than the PL layer ever can do. If there is no agreement on this, we should as a minimum make the heartbeat scheme PL-to-PL an optional feature. Regards /jon Wang,Weiming wrote: > Joel, > > We actually have had quite a long discussion on the need for a > specific HB msg > or just use events for HBs.I think my thought complies with yours > well. More > detailedly, my thought is: > > 1. There are two entities related to HB, one is the HB attribute, the > other is > HB event. > 2. For FE, HB event and HB attribute belongs to FE object attributes. > For CE, > there is only HB event that belongs to CE events. > 3. HB attribute at FE can be set by CE to decide its parameters like the > interval. ForCES has no access to HB parameters generated by CE. > 4. To start HBs in FE is at the time to subscirbe it. There is no > access for > ForCES to decide when to start HB from CE. > 5. PDU of HB events can fully be the same as general Event > notification message. > > I think we have not met the issue of how the Event Notification message > generated by CE is formatted. I'm sure when this is resolved, the > message format > for HB from CE to FE can also be resolved. > > Now, I think, we come to the discussion again on if we need a specific HB > message for ForCES. > > Thank you. > Weiming > > ----- Original Message ----- > From: "Joel M. Halpern" > Subject: Re: [issue 7] HB msg > > > > If the heartbeat goes only from the FE to the CE, treating it as an > Event > > makes sense to me. That seems to be consistent re-use of mechanisms > that > > have general utility. > > > > The problem I see with that is the CE->FE direction. Except for > this case, > > the FE logic has no reason to be able to receive event messages. > > One alternative is to redefine heartbeat slightly. > > Define it as simply that the CE and FE must hear from each other at the > > configured interval. > > The FE generates his side by generate heartbeat notifications if he has > > nothing else to say. > > The CE can deal with his side by sending null protocol messages > (messages > > with no operations). > > > > Does that work for people? > > > > Thank you, > > Joel > > > > At 12:27 PM 1/11/2005, Jamal Hadi Salim wrote: > > > > 2) give HB the format of an event: LFB-Selector selects the FE > > > > Protocol LFB, command is EVENT-REPORT and path-data identifies the > > > > heartbeat event attribute in the FE Protocol LFB. Data is empty. > > > > > > > > > >I think this is what i am leaning towards ... > > >A heartbeat is a synchronous _event_. A CE needs to kick the > > >FE::LFBofinterest to start emiting the events (I suppose after > > >setting the proper parameters such as clock interval and dead > interval). > > >One could say a basic heartbeat will have a zero sized message. > > >OTOH, an synchronous event such as the one emited by the topology LFB > > >will have > zero sized data (if configured to periodically send > updates > > >to the CE). > > > > > >The source of this message is the LFB object if going from CE to FE. > > >Thats what has been configured to emit these synchronous events. > > >What i am having problems with so far is the restriction of this > message > > >to only the FE protocol LFB and then taking further shortcuts to say > > >we dont even need to mention the FE protocol LFB in the addressing. > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 26 13:38:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27675 for ; Wed, 26 Jan 2005 13:38:43 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsKw-0007JK-0M for forces-archive@IETF.ORG; Wed, 26 Jan 2005 13:56:19 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F5D4B5@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 13:38:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55191345 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 13:38:42 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 13:32:30 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012610313831:6775 ; Wed, 26 Jan 2005 10:31:38 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/26/2005 10:31:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/26/2005 10:31:46 AM, Serialize complete at 01/26/2005 10:31:46 AM Content-Type: multipart/mixed; boundary="=-4bIKVhOc8BjxDJ4BO1Jx" Message-ID: <1106764338.1073.32.camel@jzny.localdomain> Date: Wed, 26 Jan 2005 13:32:18 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ff8f6fb66123e35ba88156f838266c1a --=-4bIKVhOc8BjxDJ4BO1Jx Content-Type: text/plain Content-Transfer-Encoding: 7bit Changelog: --------- $Log: data_path2.txt,v $ Revision 1.7 2005/01/26 06:27:10 hadi fixed INDINFO definition as caught by Weiming Added FIELDINFO Added example on selective setting based on posting from Weiming. Diff and text both attached. Please read it. cheers, jamal --=-4bIKVhOc8BjxDJ4BO1Jx Content-Disposition: attachment; filename=data_path2.txt Content-Type: text/plain; name=data_path2.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Standard Disclaimer: -------------------- This doc by no means imposes a decision. It serves as a discussion place holder with the a desire to speed up the path-data discussion up. NOTE: ----- 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA which is the subject of this discussion. Opcodes discussed so far: * SET (create, modify, append etc depending on PATH-DATA flags} * DEL (remove existing config objects specified by PATH-DATA } * GET (Access existing config objects specified in PATH-DATA } [Add any events here] A possible path-data layout. ---------------------------- OPER TLV : = PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]+ [IDINFO] DATARAW := [DATAINFO] THEDATA := somedata* [VARENCDATA TLV]* IDINFO := [INDINFO] [FIELDINFO] FIELDINFO TLV := one or more fieldIDs INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined at LFB definition) or dynamically created table indices. The IDs essentially define the _start_ point in a hierachy. They may also point to the final target path in the case of a terminal. Refer further to examples below. -> flags are used to further refine the operation to be applied on the ID_TLV. -> SELECTOR := optional construct that further defines the path. Different BLK, KEY or Index/fieldID extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being used for selection. Refer to examples for further info. The KEYINFO is the only selector that contains content search information. -> DATAINFO: = Optional variable sized data dependent on PATH and requested/applied operations. As an example a GET or DEL may not have data. -> DATARAW contains "the data" whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data selector data selector data ..." The data depending on the LFB may containing variable sized entities. To ensure that entities > 2^16 bytes can also be encoded, the Type of the VARENCDATA will indicate whether the the length is in bytes, words, doublewords etc. (expand more later on this) Example layout -------------- T = SET //operation + +---+ | | // pathata to target X | +--- // with data to be added/replaced | // This is the discussion point | | T = DEL //operation | + +---+ | // pathdata to target A +--- // with data to be Deleted // This is the discussion point A reminder: 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) There is only one path-data per operation. 4) Atomicity for operations is defined in the main header flags. 5) verbosity needed in response is defined in main headers flags. NOTE! NOTE! ----------- The DATARAW "somedata" in the BNF is LFB dependent. It is assumed that the recepient by virtue of knowing the LFB format can decode the data. In the simple LFB used in this doc, the fields in the two tables are all of fixed size. It would need some TLV to explain variable sized entries such as strings. TBD: Should we leave this upto the LFB specific to worry about the encoding/decoding. If yes, how does the LFB definition describe this? If no, should we add this to the grammar? If yes, how? NOTE: OPEN ISSUE on BNF ------------------------ At the moment, the BNF says: OPER TLV : = To satisfy Weiming fully we would need to make this: OPER TLV : = + Which means the rule that "There is only one path-data per operation" no longer holds. Joels belief is this is gonna add to complexity. I am indifferent. flags ----- Derived from Netlink and BSD route sockets: --> F_EXCL Donot replace the config attribute(s) if already exists - Report back error instead. --> F_REPLACE Replace existing matching config attribute(s) with passed data. If config object doesnt exist, return an error. --> F_CREATE Create config object if it does not already exist. If config object already exists, return an error. --> F_APPEND: Add to the end of the object list/table. This could create xplicates (dup/triplicates etc) Essentially: - To ADD a new config object: F_CREATE | F_EXCL - To change an existing object: F_REPLACE - To test if object exists: F_EXCL Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. We may need to rediscuss that if need be. BLK path selection ------------------ For block operations three modes exist [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. At the moment as well the Block operations apply to Indices and not field IDs. We could add BLK_XXX_FIELD later. 1) BLK_RANGE_INDEX TLV T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" The above Block operation will be removed since it is redundant with INDIFO TLV 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" count //"N" 3) BLK_LIST_INDEX TLV T= BLK_LIST_INDEX, length = 4+(4*(count of indices)) index0 // "a" index1 //"c" index2 //"e" ...... ...... indexN-1 //"?" Content path selection --------------------- We introduce a KEY_INFO TLV which will describe the KEY as well as associated KEY data (example Keyid = 3 for "foo1" and Key_data = 5"). KEYINFO TLV := KEYID KEY_DATA Where KEYID is a 32 bit entity that contains the index or field ID and data contains the data being referenced. The L of the TLV adjusts given the size of the KEY_DATA. The only equality allowed is the "=" sign which means any search will be for "KEYID=KEY_DATA" example "foo1=10" (where foo1's ID is actually placed in the KEYID field instead of the name "foo1". NOTE! NOTE! There is still some open discussion here: A) Joels view: i) Allow only for one or two keys per table instance for simplicty reasons. Example, allow only j1 to be the key for table2. Enforce this via LFB definition. ii) A key value is unique per table instance. In other words, if one was to scan table 2 they would only see one occurance of a table row which has value "j1=10" B) Weiming: i) there are no unique keys. ii) there can be multiple row instances of "j1=10" It should be noted that it is possible to achieve what Weiming wants using the F_APPEND flag when creating a table row entry. Infact there are some LFBs which may allow for this (I know some ASICs with classifiers that allow for this). It should also be noted that the majority of the popular LFBs such as the L3 LFB will have a single unique key (such as the IPV4 prefix). [Additional note: In the case the forwarding path actually does everything with index based tables, then doing a check of "j1=1 AND j2=10" is valid; however, j2 and j1 are not really "keys" if we use proper terminology ;->] Again, it should be emphasized that keying information is low level detail that can be "resolved" at the CE without enforcing it on the FE. DATAINFO: --------- The DATAINFO TLV will contain the RAWDATA which may optionaly contain a DATAINFO TLV (to allow for recursive interleaving of path-data). USE CASES --------- Assume LFB with following attributes for the following use cases. foo1, type u32, ID = 1 foo2, type u32, ID = 2 table1: type array, ID = 3 elements are: t1, type u32, ID = 1 t2, type u32, ID = 2 // index into table 2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 table3: type array, ID = 5 elements are: someid, type u32, ID = 1 name, type string variable sized, ID = 2 table4: type array, ID = 6 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 3 j4, type u32, ID = 4 1) To get foo1 Path: IDCount = 1, IDs = 1 Result: Path = IDCount = 1, IDs = 1, RAWDATA TLV with value of foo1 2) to set foo2 to 10 Path: flags = F_REPLACE, IDCount = 1, IDs = 2 RAWDATA TLV: L = 4+4, V=10 Result: Depends on whether we asked for a simple success/ACK back or full details 3) To dump table2 (get) Assuming numentries defines the number of entries. Path = IDCount = 1, IDs=4 Result: Path = IDCount = 1, IDs=4 BLK_INDEX_RANGE TLV start = 0 end = numentries-1 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (numentries2 in total) 4) Block operations To create entry 0-2 of table2 (I am going to ignore error conditions for now) Path: flags = F_CREATE | F_EXCL, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 2 DATAINFO TLV: L = XXX, V= a series of j1value,j2value entries (3 in total) 5) Block operations (with holes) To replace entry 0,2 of table2 (I am going to ignore error conditions for now) Path: flags = F_REPLACE, = IDCount = 1, IDs=4 BLK_LIST_INDEX TLV 0,2 DATAINFO TLV, Length = XXX, V = two j1value,j2value entries 6) Getting rows To get first entry of table2 Path = IDCount = 2, IDs=4.0 the above shows that mainpath can constitute indices. Result: Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value Another valid response is: Path = IDCount = 2, IDs=4.0 DATAINFO TLV, V= j1value,j2value 7) to get entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 TBD: What to do when say entry 1 doesnt exist? Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 8) Using BLK_CNT_INDEX for #7 Path = IDCount = 1, IDs=4 followed by BLK_CNT_INDEX TLV to extend path T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, length of 4+8 start = 0 count = 3 DATAINFO TLV, Length = 4+2*(4+8) Values: j1value,j2value j1value,j2value j1value,j2value 9) Using BLK_LIST_INDEX TLV for #7 Path = IDCount = 1, IDs=4 followed by BLK_LIST_INDEX TLV T = BLK_CNT_INDEX, L = XXX Values: 0,1,2 Result: Path = IDCount = 1, IDs=4 T = BLK_CNT_INDEX, L = XXX V: 0,1,2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 10) Dump contents of table1, Path = IDCount = 1, IDs=3 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=3 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: t1value, t2value, j1value,j2value . . (note t2 is subscript for table2 and infact we are resolving table2 contents above) TBD: Do we just resolve the contents pointed to by t2value as shown above or do we have a flag to select between two modes? Clearly a good way to do this is not to resolve any paths(i.e dumping of table1 should obly have t1value and t2value); rather the CE should OPerate on both tables in one atomic invocation. 11) get _all_ entries for table2 where j1=100 Path = IDCount = 1, IDs=4 SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID =1 KEY_DATA=100} In other words the BLK_RANGE_INDEX says "for all entries in table" and KEYINFO says "if they match j1= 100" Result: Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 9, 16, 22 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} Result: This assumes we have asked for the full results back (instead of just simple pass/fail. We need a flag - refer to other discussion) Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value TBD: What to do when we request the next 10 entries but theres only 5? What about when the highest index available is 5? Need to enumerate all possible error paths 13) Dump contents of table3, should be noted that this table has a column with element name that is variable sized. The purpose of this use case is to show how such an element is to be encoded. Path = IDCount = 1, IDs=5 Result: Assuming subscript/index holes in the table Path = IDCount = 1, IDs=5 T = BLK_LIST_INDEX, L = XXX Values: 3, 5, 15, ... DATAINFO TLV, Length = XXXX Values: someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval someidval, TLV: T=VARENCDATA, L = 8+strlen(name), V = nameval . . . 14) Multiple atomic operations. [This emulates adding a new nexthop entry and then atomically updating the L3 entries pointing to an old NH to point to a new one. The assumption is both tables are in the same LFB] Main header has atomic flag set and we are request for verbose/full results back; Two operations on the LFB instance, both are SET operations. //Operation 1: Add a new entry to table2 index #20. Path: flags = F_CREATE | F_EXCL, IDCount = 2, IDs=4.20 DATAINFO TLV, V= j1value,j2value // second Operation: Update table1 entries which // were pointing to NH index 10 to now point to index 20 Path: flags = F_REPLACE, IDCount = 1, IDs=3 SELECTOR := BLK_RANGE_INDEX TLV = {0,maxsize} KEYINFO = {KEYID = 2 KEY_DATA=10} DATAINFO TLV, V= 20 Result: //first operation, SET Path = IDCount = 1, IDs=4 INDINFO TLV, value = subscript/index of row 0 DATAINFO TLV, V= j1value,j2value //second opertion SET - assuming 3 entries were updated Path = IDCount = 1, IDs=4 T = BLK_LIST_INDEX, L = XXX Values: 16, 36,95 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 15) Selective setting (Example posted by Weiming) on table 4 -- for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. operation = SET Path: Flags = F_REPLACE, IDCount = 1, IDs=4 SELECTOR := // select the rows BLK_LIST_INDEX, L = XXX V = {1,3,5,7,9} // select the columns FIELDINFO, L = XXXX V = {1,2,3} // data to use DATAINFO TLV, Length = XXXX V = {100, 200, 300} TODO: - column and cell access in a table use cases - resolve issues outstanding between Joel and Weiming So we can move on! $Log: data_path2.txt,v $ Revision 1.7 2005/01/26 18:27:10 hadi fixed INDINFO definition as caught by Weiming Added FIELDINFO Added example on selective setting based on posting from Weiming. , Revision 1.6 2005/01/17 21:05:58 hadi added an example layout diagram updated issues list posted to list Revision 1.5 2005/01/17 19:25:49 hadi posted to the list Revision 1.4 2005/01/13 14:01:11 hadi added table 3 which contains variable sized strings. added example of how such a table is to be manipulated extended the grammar slightly to accomodate above Revision 1.3 2005/01/11 17:03:15 hadi proof read and sent to list; major change was s/RAWDATA/DATAINFO/g A little more explanatory text Revision 1.2 2005/01/11 16:30:37 hadi posted to the list proof reading and making small changes next Revision 1.1 2004/11/14 18:47:07 hadi Initial revision --=-4bIKVhOc8BjxDJ4BO1Jx Content-Disposition: attachment; filename=pd012605_diff Content-Type: text/plain; name=pd012605_diff; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- data_path2.txt 2005/01/17 21:05:58 1.6 +++ data_path2.txt 2005/01/26 18:25:41 @@ -28,25 +28,33 @@ PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] -SELECTOR := [BLKINFO] [KEYINFO]+ | [INDINFO]> +SELECTOR := [BLKINFO] [KEYINFO]+ [IDINFO] DATARAW := [DATAINFO] -THEDATA := [somedata]* [VARENCDATA TLV]* -INDINFO TLV := index | fieldID +THEDATA := somedata* [VARENCDATA TLV]* +IDINFO := [INDINFO] [FIELDINFO] +FIELDINFO TLV := one or more fieldIDs +INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] -> IDs := a series of 32bit IDs (whose count is given by IDcount) defining the main path. These IDs could be field IDs (staticaly defined -at LFB definition) or dynamically created (table indices). +at LFB definition) or dynamically created table indices. +The IDs essentially define the _start_ point in a hierachy. They +may also point to the final target path in the case of a terminal. +Refer further to examples below. + -> flags are used to further refine the operation to be applied on the ID_TLV. --> SELECTOR := optional different BLK, KEY or Index/fieldID -to extend/refine/filter the path. +-> SELECTOR := optional construct that further defines the path. +Different BLK, KEY or Index/fieldID extend/refine/filter the path. The SELECTOR has been reffered to as subpath in some email discussions. The path information in the SELECTOR indicates what information is being -used for selection. +used for selection. Refer to examples for further info. +The KEYINFO is the only selector that contains content search information. -> DATAINFO: = Optional variable sized data dependent on PATH -and applied operations. As an example a GET or DEL may not have data. +and requested/applied operations. As an example a GET or DEL may not +have data. -> DATARAW contains "the data" whose path is selected. This may recursively contain DATAINFO such that we can have a series of "path data selector data selector data ..." @@ -147,12 +155,17 @@ [a,b], [a,N] or a list [a,c,e,f] These modes could be optimized or more added; the idea is to capture here for the moment. +At the moment as well the Block operations apply to Indices and +not field IDs. We could add BLK_XXX_FIELD later. 1) BLK_RANGE_INDEX TLV T = BLK_RANGE_INDEX, length of 4+8 start // "a" end // "b" +The above Block operation will be removed since it is redundant +with INDIFO TLV + 2) BLK_CNT_INDEX TLV T=BLK_CNT_INDEX, length = 4+8 start // "a" @@ -244,6 +257,15 @@ someid, type u32, ID = 1 name, type string variable sized, ID = 2 +table4: type array, ID = 6 +elements are: +j1, type u32, ID = 1 +j2, type u32, ID = 2 +j3, type u32, ID = 3 +j4, type u32, ID = 4 + + + 1) To get foo1 Path: IDCount = 1, IDs = 1 @@ -277,7 +299,7 @@ To create entry 0-2 of table2 (I am going to ignore error conditions for now) -Path: flags = F_CREATE | F_REPLACE, IDCount = 1, IDs=4 +Path: flags = F_CREATE | F_EXCL, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 2 @@ -493,6 +515,24 @@ j1value,j2value j1value,j2value +15) Selective setting (Example posted by Weiming) +on table 4 -- for indices 1, 3, 5, 7, and 9. +Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. + +operation = SET +Path: Flags = F_REPLACE, IDCount = 1, IDs=4 +SELECTOR := + // select the rows + BLK_LIST_INDEX, L = XXX + V = {1,3,5,7,9} + // select the columns + FIELDINFO, L = XXXX + V = {1,2,3} +// data to use +DATAINFO TLV, Length = XXXX + V = {100, 200, 300} + + TODO: - column and cell access in a table use cases --=-4bIKVhOc8BjxDJ4BO1Jx-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 26 17:12:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27592 for ; Wed, 26 Jan 2005 17:12:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctvfm-00073N-4T for forces-archive@IETF.ORG; Wed, 26 Jan 2005 17:30:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F5DBA9@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 17:12:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55216363 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 17:12:23 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 17:10:56 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8871260 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 17:10:55 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050126164837.039c7b18@localhost> Date: Wed, 26 Jan 2005 17:10:32 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106764338.1073.32.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 A scattering of comments: 1) I am not sure the nesting of DATAINFO inside DATARAW is either necessary nor particularly useful. I am afraid it may lead to very confusing constructs. 2) Please, can we use one size length field for all TLVs? 16 bits? If we actually have a block of information larger than 64K to send, I think that we are solving some other problem than normal ForCES operation, and should probably use a different notion. (I can imaging a message sequence intended to convey a large block of information in an agreed format.) If a GET actually would produce more than 64K bytes, the FE should return a "too large" error, and let the CE get it in pieces. Among other things, the head of line blocking by large data may be a (admittedly minor) issue. 3) On the Delete operation, I do not normally expect it to include "data to be Deleted". It will include the index or the content selector, but that is not the same as the data to b deleted. 4) I can live with +. I thought I said so on the list. Sorry if I was not sufficiently clear. Compared with most of what we are discussing, this is small potatoes. 5) On the flags, I can not tell the difference between F_EXCL and F_CREATE? 5') I strongly object to F_APPEND as described. Keys or indices shall be unique. I would have no problem with F_APPEND if the meaning were: use only with indexed operation ignore the index specified in the operation use the smallest free index in the table return the index used in the result and all set operations would have the requirement that fields declared as key shall be unique in the table even if they are not the fields used for the entry selection. 6) When getting a whole table, I would prefer that the structure returned to represent the table included the indices, rather than using the BLK TLC alongside the data. The reason for this is that if we have tables inside tables (clearly necessary in some cases), we need to be able to return all the entries of the inner tables. When the get used the BLK, obviously the BLK is included in the results to indicate what is returned at the outermost layer. 7) In example 10, it says it is getting table1, and then says t1value, t2value, j1value, j2value. But there are no ji fields in table1? from the later text, this was envisioned as a transparent indirection. That fact that the t2 values can be used as indices in table2 should not affect the results of this get. (Note that if there was a t3value that was an alias for the table2 entry, that would be a different matter. But without the alias, table2 things should not be returned when one accesses table1.) note: examples 11 and 12 relate to the uniqueness debate. 8) rather than using special encoding, I believe we will need to agree on a general encoding for arrays, struct, bytestrings, strings, etc. All data types and constructs defined in the model must have an agreed encoding for use in the data portion (SET requests, GET responses, and content indexing all should use the same encoding rules.) 9) I find the implicit iteration binding in example 15 confusing. While I think we can write rules to permit this, I think it is going to be a major source of implementation errors. Yours, Joel PS: Jamal, thanks very much for all the work keeping this on track and organized. At 01:32 PM 1/26/2005, Jamal Hadi Salim wrote: >Changelog: >--------- >$Log: data_path2.txt,v $ >Revision 1.7 2005/01/26 06:27:10 hadi >fixed INDINFO definition as caught by Weiming >Added FIELDINFO >Added example on selective setting based on posting from Weiming. > > >Diff and text both attached. > >Please read it. > >cheers, >jamal > From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 26 20:11:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11149 for ; Wed, 26 Jan 2005 20:11:54 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyTU-00029X-Mk for forces-archive@IETF.ORG; Wed, 26 Jan 2005 20:29:34 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F5DE20@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 20:11:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55228028 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 20:11:54 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 18:58:26 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0QNwPpn015939 for ; Wed, 26 Jan 2005 23:58:25 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0QNw49Q031348 for ; Wed, 26 Jan 2005 23:58:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005012615582516330 for ; Wed, 26 Jan 2005 15:58:25 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jan 2005 15:58:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: TML Template/Requires Thread-Index: AcUEAmcnBmHG+2MzSYm0FW609S3lvg== X-OriginalArrivalTime: 26 Jan 2005 23:58:25.0226 (UTC) FILETIME=[EC62A2A0:01C50402] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Wed, 26 Jan 2005 15:54:41 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: TML Template/Requires To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable All, At the last meeting I said I would send out some suggestions for topics that each of the TML documents should make sure to address in order to go forward. Below is a set of such topics - please comment or propose changes as needed: * Description of problem being solved: Why a particular TML is being proposed/should be adopted. What problem does it solve that other TML proposals do not already solve. =20 E.g. better for highly scaled systems, better for intra- box scenarios, better for multiple hops, etc. * How specifically is it mapped to a transport protocol.=20 E.g. if TCP, what port #s, does FE or CE setup the connection, etc. Same for UDP or alternate protocols (e.g. TIPC, SCTP). The information here should be sufficiently detailed that an implementer could pickup the spec and create a compliant implementation * What TML messages are defined, in terms of description, ordering/message sequence, message types, etc. * How the TML satisfies the ForCES requirements RFC and=20 how the ForCES PL would use it. * All the mandatory parts of any IETF protocol spec, e.g. IANA considerations, security section, etc. Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Jan 26 23:56:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00936 for ; Wed, 26 Jan 2005 23:56:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu1ys-0007EG-ST for forces-archive@IETF.ORG; Thu, 27 Jan 2005 00:14:29 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F5E3BD@cherry.ease.lsoft.com>; Wed, 26 Jan 2005 23:56:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55245178 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 26 Jan 2005 23:56:26 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 26 Jan 2005 22:26:40 -0500 Received: from [220.192.115.9] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Thu, 27 Jan 2005 11:54:45 +0800 (CST) References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> <003901c5021c$a10a16e0$020aa8c0@wwm1> <1106595083.1079.61.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <006d01c50420$2c0e33c0$0973c0dc@WwmLapSamsung> Date: Thu, 27 Jan 2005 11:25:29 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFk aSBTYWxpbSIgPGhhZGlAWk5ZWC5DT00+DQogDQo+IC8vIHNlbGVjdCB0aGUgY29sdW1ucw0KPiAg ICAgICAgIEZJRUxESU5GTyA9IHsxLDIsM30NCj4gLy8gZGF0YSB0byB1c2UNCj4gREFUQUlORk8g VExWLCBMZW5ndGggPSBYWFhYDQo+IFYgPSB7MTAwLCAyMDAsIDMwMH0NCg0KDQpUbyBwdXQgdGhl IHN1YiBmaWVsZElEcyB0b2dldGhlciBhbmQgdGhlIGRhdGEgdG9nZXRoZXIgd2lsbCBicmluZyBh bWJpZ3VpdHkuIFRoaW5raW5nIG9mIGFuIGV4YW1wbGUgYXMgYmVsb3c6DQoNCnRhYmxlMjogdHlw ZSBhcnJheSwgSUQgPSA0DQogZWxlbWVudHMgYXJlOg0KIGoxLCB0eXBlIHN0cnVjdCBBZGQsIElE ID0gMQ0KIGoyLCB0eXBlIHUzMiwgSUQgPSAyDQogajMsIHR5cGUgdTMyLCBJRCA9IDMNCiBqNCwg dHlwZSB1MzIsIElEID0gNA0KDQpXaGVyZSBzdHJ1Y3QgQWRkIG1heSBiZSBnbG9iYWxseSBkZWZp bmVkIGFzOg0Kc3RydWN0IEFkZCB7DQpkMSwgdHlwZSB1MzIsIElEID0gMQ0KZDIsIHR5cGUgdTMy LCBJRCA9IDINCn0gDQoNCndoZXJlIHRoZSBJRHMgYXJlIG51bWJlcmVkIGluZGVwZW5kYW50bHkg b2YgdGFibGUyLg0KDQpUaGVuLCB3aGVuIHdlIHVzZSB0aGUgRklFTERJTkZPIGFzIHsxLDIsM30s aXQgd2lsbCBsZWFkIHRvIGRpZmZlcmVudCBwYXJzaW5nIHJlc3VsdDoNCg0Ke3sxLCAyfSwgM30g IC0tLSBtZWFuaW5nIHRvIGFkZHJlc3MgdGhlIHtqMS5kMiwgajN9DQp7MSwgMiwgM30gLS0tIG1l YW5pbmcgdG8gYWRkcmVzcyB0aGUge2oxLGoyLGozfQ0KDQpPYnZpb3VzbHksIHRoaXMgd2lsbCBh bHNvIGxlYWQgdG8gcGFyc2luZyBlcnJvciBvZiBEYXRhIFRMVi4NCg0KQnkgdXNpbmcgdGhlIHN1 YnBhdGgtZGF0YSBzZXBhcmF0ZSB3YXksIGFib3ZlIHR3byBjYXNlcyBhcmUgZGlmZmVyZW50bHkg YXM6DQoNClN1YnBhdGgoMS4yKSBEYXRhKDIwMDApIDsgc3VwcG9zZSB0byBzZXQgajEuZDI9MjAw MA0KU3VicGF0aCgzKSBEYXRhKDMwMCkNCg0KYW5kIA0KIHN1YnBhdGgoMSkgRGF0YSgxMDApDQpT dWJwYXRoKDIpIERhdGEoMjAwKQ0KU3VicGF0aCgzKSBEYXRhKDMwMCkNCg0KTm90ZSB0aGF0IHRo aXMgYXBwcm9hY2ggYXJlIGFsc28gYWN0dWFsbHkgbm90IGJpdHMgY29uc3VtaW5nIHZlcnkgbXVj aC4gQnkgZGVmaW5pbmcgYSBzdWJwYXRoLWRhdGEgd2l0aCBhIFRMViAoanVzdCBpZGVudGljYWwg dG8gd2hhdCB5b3Ugc3VwcG9zZSBLZXktZGF0YSBkb2VzKSBhczoNCg0KU1VCUEFUSCBUTFYgOj0g Y291bnRzIDxmaWVsZElEcz4gVGhlX0RhdGENCg0KYXMgSSBzdXBwb3NlZCBpbiBsYXN0IHBvc3Qu DQoNClRoYW5rcywNCldlaW1pbmcNCiANCg0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 13:03:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07371 for ; Thu, 27 Jan 2005 13:03:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEGk-0002Cj-FZ for forces-archive@IETF.ORG; Thu, 27 Jan 2005 13:21:26 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F5F06C@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 13:03:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55343052 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 13:03:34 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 13:03:00 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0RI2xux002254 for ; Thu, 27 Jan 2005 18:02:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0RI2xAw001211 for ; Thu, 27 Jan 2005 18:02:59 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005012710025932113 for ; Thu, 27 Jan 2005 10:02:59 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 10:02:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] path data textt update Thread-Index: AcUD1k//fX3oDhMHQDiK+Rsv/ijgwgAwxKRw X-OriginalArrivalTime: 27 Jan 2005 18:02:59.0035 (UTC) FILETIME=[6F65E2B0:01C5049A] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E040EB7CE@orsmsx408> Date: Thu, 27 Jan 2005 10:02:57 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Hi Jamal, Thanks a lot for putting this together, it is very useful for making progress! (Sorry, I have been unable to send in comments earlier) I had a few initial comments on the path-data layout.... Why do we need Flags in the PATH ? Isn't this something that should be part of the Operation itself ? I remember Joel also had some comments on this before. Opcodes for Operations which have been defined so far include.. ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL I don't see you having included all of these...what am I missing here ? Let me know your thoughts, I will send more details comments soon. Thanks again! Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, January 26, 2005 10:32 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] path data textt update Changelog: --------- $Log: data_path2.txt,v $ Revision 1.7 2005/01/26 06:27:10 hadi fixed INDINFO definition as caught by Weiming Added FIELDINFO Added example on selective setting based on posting from Weiming. Diff and text both attached. Please read it.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 14:51:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16465 for ; Thu, 27 Jan 2005 14:51:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuFwe-0004k7-92 for forces-archive@IETF.ORG; Thu, 27 Jan 2005 15:08:54 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F5F254@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 14:50:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55355829 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 14:50:52 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 14:47:04 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012711461617:15156 ; Thu, 27 Jan 2005 11:46:16 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 11:46:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 11:46:20 AM, Serialize complete at 01/27/2005 11:46:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106855217.1148.70.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 14:46:58 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: [1]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050126164837.039c7b18@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Joel, Thanks for the input; i will split response email into 2 so its more readable. On Wed, 2005-01-26 at 17:10, Joel M. Halpern wrote: > A scattering of comments: > > 1) I am not sure the nesting of DATAINFO inside DATARAW is either necessary > nor particularly useful. I am afraid it may lead to very confusing constructs. Based on #4 below we can kill this now. So how does this look: OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] DATARAW := somedata* [VARENCDATA TLV]* IDINFO := [INDINFO] [FIELDINFO] FIELDINFO TLV := one or more fieldIDs INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] I have killed BLK_LIST_INDEX as well. Should also be noted that the SELECTOR is both a content(using KEYINFO) as well as path selector. > 2) Please, can we use one size length field for all TLVs? 16 bits? If we > actually have a block of information larger than 64K to send, I think that > we are solving some other problem than normal ForCES operation, and should > probably use a different notion. (I can imaging a message sequence > intended to convey a large block of information in an agreed format.) If a > GET actually would produce more than 64K bytes, the FE should return a "too > large" error, and let the CE get it in pieces. Among other things, the > head of line blocking by large data may be a (admittedly minor) issue. The TLV is still 16 bit byte-lenght (16 bit T and 32 bit alignement for data); the suggestion to use the T to imply that the Length was other than byte-length was as you note in your email - to stash large amounts of data. It is not unusual to find table with 100K entries. Expound a little on the "too large" error usage with 100K entries and we can throw the non-byte-Length hack out. > 3) On the Delete operation, I do not normally expect it to include "data to > be Deleted". It will include the index or the content selector, but that > is not the same as the data to b deleted. > The data may be included in the SELECTOR to further refine what it is that is being deleted. Example 12 provides such usage. To save time: --- 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} -------- Is this fine with you? Did you mean something else? > 4) I can live with +. I thought I said so on the list.Sorry > if I was not sufficiently clear. Compared with most of what we are > discussing, this is small potatoes. Done. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 15:29:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21475 for ; Thu, 27 Jan 2005 15:29:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuGXW-0005rw-8V for forces-archive@IETF.ORG; Thu, 27 Jan 2005 15:46:56 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F5F475@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 15:29:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55359327 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 15:29:02 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:07:59 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012712071196:15388 ; Thu, 27 Jan 2005 12:07:11 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:07:12 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:07:15 PM, Serialize complete at 01/27/2005 12:07:15 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106856473.1148.96.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 15:07:53 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050126164837.039c7b18@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit On Wed, 2005-01-26 at 17:10, Joel M. Halpern wrote: > 5) On the flags, I can not tell the difference between F_EXCL and F_CREATE? The wording is unclear even to me now when i read it;-> Let me explain then maybe we can have better wording. Its a unixism derived from filesystem operations (look at man open). Adopted by BSD Route sockets in the next point in history. Extensively used in netlink (borrowed from Route sockets) and i believe in some databases.... As an example, if this was an operation to add to a table row: CREATE is essentially instantiating of the row object (and in this case populating the entries in that object) but not putting it in the table. A lookup in the targeted table (using a given key) may show that the table already contains an entry with a matching key. EXCL says if you do find the match in that case, do not stash the instantiated object in the table. In unix you return a -EEXIST i.e entry already exists. So if you want to add a brand new object you would have the CREATE|EXCL together. If all you wanted was to test for existence you could do a SET with just EXCL flag. A CREATE|REPLACE on the other hand will expect such an entry to exist already and perhaps replace the row or parts of it. > 5') I strongly object to F_APPEND as described. Keys or indices shall be > unique. I would have no problem with F_APPEND if the meaning were: > use only with indexed operation > ignore the index specified in the operation > use the smallest free index in the table > return the index used in the result > and all set operations would have the requirement that fields declared as > key shall be unique in the table even if they are not the fields used for > the entry selection. Theres actually ASICs out there that will accept entries that have the same key but may differ in one or more fields in a row. Theres also a few s/ware firewall types (such as Linux iptables) that do this. I cant remember the exact details but i know people play tricks with these kinds of setups that depend on such layouts. I would suspect such a setup would probably just go ahead and add entries anyways with or without this flag. If theres consensus to remove this then will be fine with me. > 6) When getting a whole table, I would prefer that the structure returned > to represent the table included the indices, rather than using the BLK TLC > alongside the data. The reason for this is that if we have tables inside > tables (clearly necessary in some cases), we need to be able to return all > the entries of the inner tables. When the get used the BLK, obviously the > BLK is included in the results to indicate what is returned at the > outermost layer. I dont think i understood you %100 on the benefit of tables inside tables. The motivation was to have the exact same format in the SET as it is the DELete or GET results. As an example, lets take example #7 7a) to GET entry 0-2 of table2 using BLK operations Path = IDCount = 1, IDs=4 followed by BLK_RANGE_INDEX TLV T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 Result: Path = IDCount = 1, IDs=4 T = BLK_INDEX_RANGE, length of 4+8 start = 0 end = 2 DATAINFO TLV, Length = XXXX Values: j1value,j2value j1value,j2value j1value,j2value 7b) To DELete the same entries you could send _exactly_ the same msg as 7a) just different operation 7c) To SET. you would send _exactly_ the same thing as the Result of GET in 7a). So that was the motivation - cleaner, less code involved. Clearly putting the indices in the DATAINFO TLV would save some space. What i didnt quiet get is how it helps in the case of table of table ... cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 15:31:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21708 for ; Thu, 27 Jan 2005 15:31:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuGaI-0005w6-3j for forces-archive@IETF.ORG; Thu, 27 Jan 2005 15:49:47 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F5F3C9@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 15:31:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55360385 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 15:31:56 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:28:57 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012712281051:15554 ; Thu, 27 Jan 2005 12:28:10 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:28:10 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:28:12 PM, Serialize complete at 01/27/2005 12:28:12 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106857733.1148.119.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 15:28:53 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050126164837.039c7b18@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Sorry I said two but this is 3 now .. On Wed, 2005-01-26 at 17:10, Joel M. Halpern wrote: > 6) When getting a whole table, I would prefer that the structure returned > to represent the table included the indices, rather than using the BLK TLC > alongside the data. The reason for this is that if we have tables inside > tables (clearly necessary in some cases), we need to be able to return all > the entries of the inner tables. When the get used the BLK, obviously the > BLK is included in the results to indicate what is returned at the > outermost layer. More thought since i typed last email: We could have DATARAW TLVs inside of DATARAW TLVs. This way we could kill the VARENC TLV and should be able to cover table of table setup i.e BNF extension on what i showed earlier .. DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] DATARAW := somedata* [VARENCDATA TLV]* Would be: DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] DATARAW := somedata* [DATARAW TLV]* > 7) In example 10, it says it is getting table1, and then says t1value, > t2value, j1value, j2value. But there are no ji fields in table1? t2value being table index of some row in table 2; just as would an L3LPM table probably have an index to NH table. Did i answer what you asked? > from the > later text, this was envisioned as a transparent indirection. That fact > that the t2 values can be used as indices in table2 should not affect the > results of this get. (Note that if there was a t3value that was an alias > for the table2 entry, that would be a different matter. But without the > alias, table2 things should not be returned when one accesses table1.) > I would have no issues with that approach as it would simplify things greatly. I would go as far as saying returning table1 should only return just table1 and not interpret anything. Desire to have both tables should be fulfiled by two GETs. Thoughts? > note: examples 11 and 12 relate to the uniqueness debate. Nod. Those examples show that KEYINFO is used to restrict search of content in the SELECTOR. Any further restriction(in the LFB definition) should result in rejection of the used KEYINFO. Does this sound reasonable? > 8) rather than using special encoding, I believe we will need to agree on a > general encoding for arrays, struct, bytestrings, strings, etc. All data > types and constructs defined in the model must have an agreed encoding for > use in the data portion (SET requests, GET responses, and content indexing > all should use the same encoding rules.) > The last time a proposal such as this(from Zsolt/Steve), it become problematic for two reasons a) Lead to innefficiencies/overhead in encoding. Workaround to try and dump things like tables resulted in tricks like those used in marshaling serialized java bytecode - which we dont suffer from at the moment. b) Not pretty at all dealing with variable sized data (such as the middle cell in a row being a variable sized entity). Resolve those and we could be back on track. Actually I am worried of spending even more time on that ;-> If theres some way we can do it without stalling progress, I wouldnt object. > 9) I find the implicit iteration binding in example 15 confusing. While I > think we can write rules to permit this, I think it is going to be a major > source of implementation errors. If you look at the SELECTOR as a "further" path/content selector/filter then should be fine, no? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 15:52:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23289 for ; Thu, 27 Jan 2005 15:52:20 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuGu1-0006UE-7s for forces-archive@IETF.ORG; Thu, 27 Jan 2005 16:10:09 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F5F363@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 15:52:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55362002 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 15:52:20 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:50:58 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012712501016:15706 ; Thu, 27 Jan 2005 12:50:10 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> <003901c5021c$a10a16e0$020aa8c0@wwm1> <1106595083.1079.61.camel@jzny.localdomain> <006d01c50420$2c0e33c0$0973c0dc@WwmLapSamsung> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:50:11 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:50:14 PM, Serialize complete at 01/27/2005 12:50:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106859053.1145.139.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 15:50:53 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <006d01c50420$2c0e33c0$0973c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.4 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Weiming, On Wed, 2005-01-26 at 22:25, Wang,Weiming wrote: > Jamal, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > // select the columns > > FIELDINFO = {1,2,3} > > // data to use > > DATAINFO TLV, Length = XXXX > > V = {100, 200, 300} > > > To put the sub fieldIDs together and the data together will bring ambiguity. Thinking of an example as below: > > table2: type array, ID = 4 > elements are: > j1, type struct Add, ID = 1 > j2, type u32, ID = 2 > j3, type u32, ID = 3 > j4, type u32, ID = 4 > > Where struct Add may be globally defined as: > struct Add { > d1, type u32, ID = 1 > d2, type u32, ID = 2 > } > > where the IDs are numbered independantly of table2. > > Then, when we use the FIELDINFO as {1,2,3},it will lead to different parsing result: > > {{1, 2}, 3} --- meaning to address the {j1.d2, j3} > {1, 2, 3} --- meaning to address the {j1,j2,j3} > > Obviously, this will also lead to parsing error of Data TLV. You keep bringing some very good points. I am hoping the end result is we will have some good encoding and reach a good consensus. We can allow FIELDINFO TLV to also contain FIELDINFO inside it; i.e from BNF i posted earlier for Joel as well as in my last email on the DATARAW, lets say we have: OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] DATARAW := somedata* [DATARAW TLV]* IDINFO := [INDINFO] [FIELDINFO] FIELDINFO TLV := INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] Then: {{1, 2}, 3} becomes: FIELDINFO TLV, L = XXXX V = {{FIELDINFO TLV, L = XXX, V = {1, 2}},3} And {1, 2, 3} is: FIELDINFO TLV, L = XXXX V = {1, 2, 3} Note again the FIELDINFO in this case is just a further filter to the target path > By using the subpath-data separate way, above two cases are differently as: > > Subpath(1.2) Data(2000) ; suppose to set j1.d2=2000 > > Subpath(3) Data(300) PATH TLV point to table BLKINFO or INDINFO to select row(s) in table FIELDINFO TLV, L = XXXX V = {{FIELDINFO TLV, L = XXX, V = {1, 2}},3} DATARAW TLV, L = XXXX V = {2000, 300 } It is expected that by reading the selector you know _exactly_ how to decode the data. Note also now that we allow for + You can repeat those multiple times > and > subpath(1) Data(100) > Subpath(2) Data(200) > Subpath(3) Data(300) > > Note that this approach are also actually not bits consuming very much. By defining a subpath-data with a > TLV (just identical to what you suppose Key-data does) as: > > SUBPATH TLV := counts The_Data > > as I supposed in last post. I fixed the BNF to show TLV as you said last time. Sorry took me a while to understand. Essentially this: --- PATH-DATA := [DATAINFO] PATH TLV := flags IDcount --- is like your SUBPATH TLV and you can do encode it as you describe also with + now being allowed multiple times. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 16:00:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23969 for ; Thu, 27 Jan 2005 16:00:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuH1d-0006eE-ME for forces-archive@IETF.ORG; Thu, 27 Jan 2005 16:18:01 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F5F424@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 16:00:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55362572 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 16:00:06 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:59:41 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012712585591:15773 ; Thu, 27 Jan 2005 12:58:55 -0800 References: <468F3FDA28AA87429AD807992E22D07E040EB7CE@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:58:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 12:58:57 PM, Serialize complete at 01/27/2005 12:58:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106859578.1146.148.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 15:59:38 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E040EB7CE@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 13:02, Khosravi, Hormuzd M wrote: > Hi Jamal, > > Thanks a lot for putting this together, it is very useful for making > progress! > (Sorry, I have been unable to send in comments earlier) > I had a few initial comments on the path-data layout.... > > Why do we need Flags in the PATH ? Isn't this something that should be > part of the Operation itself ? I remember Joel also had some comments on > this before. > The flags on the path are further refinements on the path or data itself (and not on the general msg type/command). Infact you can have multiple repetitions of the flags within the same operation. Look at the BNF. I cant recall what Joels comment was but its probably obsoleted now. > Opcodes for Operations which have been defined so far include.. > ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, > CANCEL > I don't see you having included all of these...what am I missing here ? > We are not really touching the operations details other than the obvious ones at the moment; i do expect some of the operations we defined already would disapear. DEL vs DEL all; ADD vs UPDATE replace. But thats such small potato that i dont think we should be spending any cycles discussing it right now. Lets resolve the the path data encoding all others will fall easily. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 16:09:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25690 for ; Thu, 27 Jan 2005 16:09:32 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHAZ-0007Bm-UE for forces-archive@IETF.ORG; Thu, 27 Jan 2005 16:27:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F5F32D@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 16:09:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55363894 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 16:09:12 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:18:37 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j0RKIbf7021468 for ; Thu, 27 Jan 2005 20:18:37 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0RKHuBa018953 for ; Thu, 27 Jan 2005 20:18:37 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005012712183300559 for ; Thu, 27 Jan 2005 12:18:34 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 12:18:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C504AD.5E93CEC6" Thread-Topic: [issue 9] Feedback: TML requirements (section 4) Thread-Index: AcUErV5YN/x1/2KATlCRenFKfj03rg== X-OriginalArrivalTime: 27 Jan 2005 20:18:31.0588 (UTC) FILETIME=[5EC6FE40:01C504AD] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E040EBB99@orsmsx408> Date: Thu, 27 Jan 2005 12:18:30 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: [issue 9] Feedback: TML requirements (section 4) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------_=_NextPart_001_01C504AD.5E93CEC6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is just an editorial change, I wanted to capture it since I didn't get much response on the Protocol list... Section 4 One requirement that I think we missed in the TML Requirements section (in protocol draft) is "Protection against DoS attacks as described in the Requirements RFC". Most of the TML proposals address this requirement, although we forgot to capture this. We need to send the appropriate text to Avri. =20 regards Hormuzd =20 ------_=_NextPart_001_01C504AD.5E93CEC6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is just an editorial change, I = wanted to=20 capture it since I didn't get much response on the Protocol=20 list...

Section 4

One=20 requirement that I think we missed in the TML Requirements section (in = protocol=20 draft) is “Protection against DoS attacks as=20 described in the Requirements RFC”. Most of the TML = proposals address=20 this requirement, although we forgot to capture this. We need to = send the=20 appropriate text to Avri.

 

regards

Hormuzd

 

------_=_NextPart_001_01C504AD.5E93CEC6-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 16:37:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02084 for ; Thu, 27 Jan 2005 16:37:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHbN-0000qV-DR for forces-archive@IETF.ORG; Thu, 27 Jan 2005 16:55:02 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F5F39A@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 16:37:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55366217 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 16:37:08 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 15:35:59 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8887245 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 15:35:58 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106855217.1148.70.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127152910.03e1a600@localhost> Date: Thu, 27 Jan 2005 15:33:23 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: [1]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106855217.1148.70.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 variable chunk length fields for TLVs is such a large invitiation to trouble that I would strongly prefer not to go there. I understand that some tables may be large. Routing / Forwarding tables are more than 64K. There rae two reasonable answers that I can see: Always use 32 bit lengths for TLVs. Or require the CE to fetch the large tables in piecs. I actually think the latter is more sensible. Note that if one is fetching a megabyte table over TCP, that is going to produce a noticeable blockage for any other transactions with that FE. With regard to deletion, I agree that deletion by key is supposed to be supported. I had read the pair "DEL data to be deleted" as referring to something else. Except for my desire that there shall only be one entry with j1=100 and j2=200 (if the j1, j2 pair is a table key), I agree with the formulation of being able to delete by that key as per example 12. Yours, Joel At 02:46 PM 1/27/2005, Jamal Hadi Salim wrote: > > 2) Please, can we use one size length field for all TLVs? 16 bits? If we > > actually have a block of information larger than 64K to send, I think that > > we are solving some other problem than normal ForCES operation, and should > > probably use a different notion. (I can imaging a message sequence > > intended to convey a large block of information in an agreed > format.) If a > > GET actually would produce more than 64K bytes, the FE should return a > "too > > large" error, and let the CE get it in pieces. Among other things, the > > head of line blocking by large data may be a (admittedly minor) issue. > >The TLV is still 16 bit byte-lenght (16 bit T and 32 bit alignement for >data); the suggestion to use the T to imply that the Length was other >than byte-length was as you note in your email - to stash large amounts >of data. It is not unusual to find table with 100K entries. Expound a >little on the "too large" error usage with 100K entries and we can throw >the non-byte-Length hack out. > > > 3) On the Delete operation, I do not normally expect it to include > "data to > > be Deleted". It will include the index or the content selector, but that > > is not the same as the data to b deleted. > > > >The data may be included in the SELECTOR to further refine what it is >that is being deleted. Example 12 provides such usage. To save time: > >--- >12) delete first 10 entries with j1=100, and j2=200 in table 2, >starting at index 10. > >Path: IDCount = 1, IDs=4 >SELECTOR := > BLK_CNT_INDEX TLV = {10,10} > KEYINFO = {KEYID =1 KEY_DATA=100} > KEYINFO = {KEYID =2 KEY_DATA=200} > >-------- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 17:19:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06067 for ; Thu, 27 Jan 2005 17:19:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuIFw-0001z9-Q4 for forces-archive@IETF.ORG; Thu, 27 Jan 2005 17:36:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F5F617@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 17:19:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55369999 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:19:03 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 17:04:43 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8888507 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:04:42 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106856473.1148.96.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127164448.03c75e48@localhost> Date: Thu, 27 Jan 2005 17:01:44 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106856473.1148.96.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Comments in line. At 03:07 PM 1/27/2005, Jamal Hadi Salim wrote: >On Wed, 2005-01-26 at 17:10, Joel M. Halpern wrote: > > > 5) On the flags, I can not tell the difference between F_EXCL and F_CREATE? > >The wording is unclear even to me now when i read it;-> >Let me explain then maybe we can have better wording. > >Its a unixism derived from filesystem operations (look at man open). >Adopted by BSD Route sockets in the next point in history. Extensively >used in netlink (borrowed from Route sockets) and i believe in some >databases.... >As an example, if this was an operation to add to a table row: CREATE is >essentially instantiating of the row object (and in this case populating >the entries in that object) but not putting it in the table. >A lookup in the targeted table (using a given key) may show that the >table already contains an entry with a matching key. >EXCL says if you do find the match in that case, do not stash the >instantiated object in the table. In unix you return a -EEXIST i.e entry >already exists. So if you want to add a brand new object you would have >the CREATE|EXCL together. If all you wanted was to test for existence >you could do a SET with just EXCL flag. >A CREATE|REPLACE on the other hand will expect such an entry to exist >already and perhaps replace the row or parts of it. This changes my confusion, but still leaves questions. Lets try listing cases for SET If CREATE is not set, then by definition we are doing a replace, and an error will be returned if the selected entry does not exist. If CREATE|EXCL then the create will work if there is no entry, and will fail if there is an existing entry. If CREATE without EXCL then it will create if thee is no entry, and update if there is an entry. Or else that is CREATE|REPLACE. In either case, whichever setting is used for "create or replace", the other flag combination seems to have no meaning. I suspect that the Unix flags have grown over time and we can define a cleaner set for ourselves without trying to emulate the sockets behavior. > > 5') I strongly object to F_APPEND as described. Keys or indices shall be > > unique. I would have no problem with F_APPEND if the meaning were: > > use only with indexed operation > > ignore the index specified in the operation > > use the smallest free index in the table > > return the index used in the result > > and all set operations would have the requirement that fields declared as > > key shall be unique in the table even if they are not the fields used for > > the entry selection. > >Theres actually ASICs out there that will accept entries that have the >same key but may differ in one or more fields in a row. >Theres also a few s/ware firewall types (such as Linux iptables) that >do this. >I cant remember the exact details but i know people play tricks with >these kinds of setups that depend on such layouts. In my opinion, values which can occur on multiple top level things should not be Keys. From a model perspective you can use nested tables, or not use those values as keys. Remember that the implementation will often be different from the model. Coping with that is the FE control logic's primary job. >I would suspect such a setup would probably just go ahead and add >entries anyways with or without this flag. If theres consensus to remove >this then will be fine with me. I believe we should remove this (F_APPEND). > > 6) When getting a whole table, I would prefer that the structure returned > > to represent the table included the indices, rather than using the BLK TLC > > alongside the data. The reason for this is that if we have tables inside > > tables (clearly necessary in some cases), we need to be able to return all > > the entries of the inner tables. When the get used the BLK, obviously the > > BLK is included in the results to indicate what is returned at the > > outermost layer. > >I dont think i understood you %100 on the benefit of tables inside >tables. >The motivation was to have the exact same format in the SET as it is >the DELete or GET results. As an example, lets take example #7 What I am looking for is that "GET whole table" uses a simpler structure than "GET range". Get RANGE does exactly what you describe. However, Get Whole table should, I think, look like Path = IDCount = 1, IDs = 4 result: Path = IDCount = 1, IDs = 4 Values: (structured defined in protocol document for array and structure values) # of entries subscript (0), j1value, j2value (where j1value, j2value is the representation for a structure of the table entry contents.) subscript(1), j1value, j2value [subscript(0) refers to the subscript of the first extant entry of the table.] The table construct is a packed sequence starting with a number of entries in the table, followed by pairs, where each pair is a subscript value followed by the packed representation of that entry in the table. In this case, it does not include the BLK construct. Note that this can be used in a SET operation. The FE will understand that the whole table is to be replaced. (This is important since a SET of Blk range 0..2 does not mean one should delete entries after 2.) Hence, this is a more reliable way to do a GET that can be used as a SET. (There is no need to worry about delete. Delete for the whole table, if defined, just uses the path to the table, with no value elements needed.) The other advantage of this is when there is a table2 inside table1. Suppose that table1's entries are a j1value and a table with x1 and x2 values. Then, GET Path = IDCount = 1, IDs = 4 result: Path = IDcount = 1, IDs - 4 Values: # of entries in table1 subscript(0), j1value # of entries of this table2 instance subscript(0), x1value, x2value subscript(1), x1value, x2value ... subscript(1), j1value # of entries of this table2 instance subscript(0), x1value, x2value ... ... This gives a consistent representation, that can be used with SETs, and which copes with nesting without trying to create weird matching between TLVs. From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 17:19:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06085 for ; Thu, 27 Jan 2005 17:19:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuIG7-0001zJ-Eu for forces-archive@IETF.ORG; Thu, 27 Jan 2005 17:37:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F5F597@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 17:19:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55370023 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:19:10 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 17:07:07 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8888613 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:07:07 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127170327.03e14310@localhost> Date: Thu, 27 Jan 2005 17:04:09 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106857733.1148.119.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 03:28 PM 1/27/2005, Jamal Hadi Salim wrote: > > from the > > later text, this was envisioned as a transparent indirection. That fact > > that the t2 values can be used as indices in table2 should not affect the > > results of this get. (Note that if there was a t3value that was an alias > > for the table2 entry, that would be a different matter. But without the > > alias, table2 things should not be returned when one accesses table1.) > > > >I would have no issues with that approach as it would simplify things >greatly. I would go as far as saying returning table1 should only return >just table1 and not interpret anything. Desire to have both tables >should be fulfiled by two GETs. Agreed. Extracted and repeated so anyone else who disagrees gets a clear chance to speak. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 17:20:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06209 for ; Thu, 27 Jan 2005 17:20:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuIHm-00021L-Mn for forces-archive@IETF.ORG; Thu, 27 Jan 2005 17:38:46 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F5F685@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 17:20:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55370305 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:20:56 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 17:18:45 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8888819 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 17:18:44 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127170837.03e66ff8@localhost> Date: Thu, 27 Jan 2005 17:15:43 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106857733.1148.119.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Actually, the more I look at this, and read your further response to Weiming, the less I like it. The identification of what is being set goes in the data path. Yes, there is a little bit of redundancy if one is trying to set fields x, y, and z of elements 1, 3, and 5 of the same structure. However, as soon as we go down this view, we now have to assemble identification from several places. This seems to be a case of making the protocol more complex in order to save a few bytes in a moderately rare corner case. + seems sufficient. I recommend removing the FIELDINFO. Note that there is actually an inconsistency between example 15 and earlier example. In the earlier examples, when there was a BLK_LIST_INDEX, there was a corresponding value for each value in the list. In example 15 we added a fieldinfo, and suddenly there is a value for each field, but the system is to implicitly duplicate them across the BLK_LIST_INDEX. That changes the semantics. Note that if we remove FIELDINFO, then we have the option of adding a semantic game. Given a BLK_LIST (Or count, or range), if there is only one occurrence of the value (whether it is a simple value or a structure does not matter) then the FE will understand to duplicate the value for all entries in the BLK. This is actually a useful way to optimize for the case that you and Weiming have asked for. As long as we do not also try to do FIELDLIST at the same time. Please. Yours, Joel At 03:28 PM 1/27/2005, Jamal Hadi Salim wrote: > > 9) I find the implicit iteration binding in example 15 confusing. While I > > think we can write rules to permit this, I think it is going to be a major > > source of implementation errors. > >If you look at the SELECTOR as a "further" path/content selector/filter >then should be fine, no? From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 18:44:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12193 for ; Thu, 27 Jan 2005 18:44:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuJaH-0003bS-PM for forces-archive@IETF.ORG; Thu, 27 Jan 2005 19:01:59 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F5F695@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 18:44:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55377683 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 18:44:06 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 18:41:43 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012715405730:16874 ; Thu, 27 Jan 2005 15:40:57 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106855217.1148.70.camel@jzny.localdomain> <6.1.2.0.0.20050127152910.03e1a600@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 03:40:57 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 03:40:59 PM, Serialize complete at 01/27/2005 03:40:59 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106869300.1097.7.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 18:41:40 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [1]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127152910.03e1a600@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 15:33, Joel M. Halpern wrote: > variable chunk length fields for TLVs is such a large invitiation to > trouble that I would strongly prefer not to go there. I understand that > some tables may be large. Routing / Forwarding tables are more than > 64K. There rae two reasonable answers that I can see: > Always use 32 bit lengths for TLVs. > Or require the CE to fetch the large tables in piecs. > I actually think the latter is more sensible. Note that if one is fetching > a megabyte table over TCP, that is going to produce a noticeable blockage > for any other transactions with that FE. Since we allow to have multi path-data within the same operation should be fine for an FE actually just breaking it into 64K chunks. Do you see any issues on that? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 19:17:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14640 for ; Thu, 27 Jan 2005 19:17:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuK6K-0004GH-He for forces-archive@IETF.ORG; Thu, 27 Jan 2005 19:35:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F5F85D@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 19:17:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55380173 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 19:17:14 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 19:15:33 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012716144728:17056 ; Thu, 27 Jan 2005 16:14:47 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106856473.1148.96.camel@jzny.localdomain> <6.1.2.0.0.20050127164448.03c75e48@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:14:48 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:14:49 PM, Serialize complete at 01/27/2005 04:14:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106871329.1090.42.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 19:15:29 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127164448.03c75e48@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 17:01, Joel M. Halpern wrote: > At 03:07 PM 1/27/2005, Jamal Hadi Salim wrote: > >On Wed, 2005-01-26 at 17:10, Joel M. Halpern wrote: > > > > > 5) On the flags, I can not tell the difference between F_EXCL and F_CREATE? > > > >The wording is unclear even to me now when i read it;-> > >Let me explain then maybe we can have better wording. > This changes my confusion, but still leaves questions. Lets try listing > cases for SET > If CREATE is not set, then by definition we are doing a replace, and an > error will be returned if the selected entry does not exist. > If CREATE|EXCL then the create will work if there is no entry, and will > fail if there is an existing entry. > If CREATE without EXCL then it will create if thee is no entry, and update > if there is an entry. Or else that is CREATE|REPLACE. > In either case, whichever setting is used for "create or replace", the > other flag combination seems to have no meaning. > > I suspect that the Unix flags have grown over time and we can define a > cleaner set for ourselves without trying to emulate the sockets behavior. Let me doodle on it and get back to you; I think you may be right but i just wanna make sure we dont forget some scenario. > In my opinion, values which can occur on multiple top level things should > not be Keys. From a model perspective you can use nested tables, or not > use those values as keys. Remember that the implementation will often be > different from the model. Coping with that is the FE control logic's > primary job. I just found that the Linux routing tables as well do support an APPEND (which appends to the end of the table) and PREPEND which inserts to the very top of the table. Note that this is a key based table. This worries me about totaly ignoring the existence of such a construct. Give me some short time to investigate its usage and how widespread that is and whether we can provide the same effect some other way. BSD as well seems to do this. Of course both constructs are dangerous. If you know the history behind this and could shed some light - that would save me some time. > >I would suspect such a setup would probably just go ahead and add > >entries anyways with or without this flag. If theres consensus to remove > >this then will be fine with me. > > I believe we should remove this (F_APPEND). The next person who says reasons and gives a reason will result in killing it. I'll just study the kernel code a little and see how useful this is. > What I am looking for is that "GET whole table" uses a simpler structure > than "GET range". > Get RANGE does exactly what you describe. Ok - gotcha. What you described is fine too but rather implicit. Could we have an explicit flag to say that this is happening or a new TLV type to indicate it - something like T=BULKDATA? > Note that this can be used in a SET operation. The FE will understand that > the whole table is to be replaced. Agreed. > (This is important since a SET of Blk > range 0..2 does not mean one should delete entries after 2.) > Hence, this is a more reliable way to do a GET that can be used as a SET. > (There is no need to worry about delete. Delete for the whole table, if > defined, just uses the path to the table, with no value elements needed.) nod. > The other advantage of this is when there is a table2 inside > table1. Suppose that table1's entries are a j1value and a table with x1 > and x2 values. Then, > > GET > Path = IDCount = 1, IDs = 4 > > result: > Path = IDcount = 1, IDs - 4 We would still need to encap whats below in a TLV, DATARAW or whatever other name that would recognize what this is. > Values: > # of entries in table1 > subscript(0), j1value > # of entries of this table2 instance > subscript(0), x1value, x2value > subscript(1), x1value, x2value > ... Using "# of entries in tableX" - why not just use a TLV there? Something like Path = IDcount = 1, IDs - 4 BULKDATA TLV, L = XXXX Values: subscript(0), j1value, BULKDATA TLV, L = XXXX Values subscript(0), x1value, x2value subscript(1), x1value, x2value ..... .... subscript(1), j1value, BULKDATA TLV, L = XXXX Values subscript(0), x1value, x2value subscript(1), x1value, x2value ..... .... ... .... ... cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 19:55:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17549 for ; Thu, 27 Jan 2005 19:55:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuKhR-00059q-42 for forces-archive@IETF.ORG; Thu, 27 Jan 2005 20:13:25 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F5F72C@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 19:55:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55382516 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 19:55:34 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 19:44:30 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012716434470:17219 ; Thu, 27 Jan 2005 16:43:44 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:43:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:43:46 PM, Serialize complete at 01/27/2005 04:43:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106873067.1097.72.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 19:44:27 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127170837.03e66ff8@localhost> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 17:15, Joel M. Halpern wrote: > Actually, the more I look at this, and read your further response to > Weiming, the less I like it. > The identification of what is being set goes in the data path. Yes, there > is a little bit of redundancy if one is trying to set fields x, y, and z of > elements 1, 3, and 5 of the same structure. However, as soon as we go down > this view, we now have to assemble identification from several places. > > This seems to be a case of making the protocol more complex in order to > save a few bytes in a moderately rare corner case. + seems > sufficient. > > I recommend removing the FIELDINFO. I agree on removing the nesting; I think that it would be hard to totaly remove it: is really flags followed by FIELDINFO except we make it _mandatory_. Recall Weimings example: table2: type array, ID = 4 elements are: j1, type struct Add, ID = 1 j2, type u32, ID = 2 j3, type u32, ID = 3 j4, type u32, ID = 4 Where struct Add may be globally defined as: struct Add { d1, type u32, ID = 1 d2, type u32, ID = 2 } And: {{1, 2}, 3} --- meaning to address the {j1.d2, j3} The addressing of the above is the tricky part without nesting. If we remove the restriction of IDcount being mandatory and substitute that with a single optional FIELDINFO, then this would satisfy both what you are saying as well as what Weiming wants IMO. i.e grammar goes from: ---- OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] DATARAW := somedata* [DATARAW TLV]* IDINFO := [INDINFO] [FIELDINFO] FIELDINFO TLV := INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] --- to: ---- OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags [FIELDINFO] DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO] [IDINFO] DATARAW := somedata* [DATARAW TLV]* IDINFO := [INDINFO] [FIELDINFO] FIELDINFO TLV := zero or more fieldIDs INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] --- What the above grammar is saying now is 1) select and/or filter the path to the target); essentially everything from PATH on but not including DATARAW then optinally 2) tell me what data to apply to that target. It could be rearranged to be more readable. Example Then path to that {{1, 2} becomes: PATH TLV: L = XXXX, V = flags, FIELDINFO TLV, L=XXX V = {1.2} // if specific row are being targeted then // INDINFO or one of the BLKs will follow here. DATAINFO TLV: L = XXXX, V= {2000} Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 19:55:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17580 for ; Thu, 27 Jan 2005 19:55:45 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuKhd-0005AJ-9R for forces-archive@IETF.ORG; Thu, 27 Jan 2005 20:13:37 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F5F81D@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 19:55:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55382543 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 19:55:46 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 19:55:31 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012716544578:17276 ; Thu, 27 Jan 2005 16:54:45 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:54:46 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 04:54:48 PM, Serialize complete at 01/27/2005 04:54:48 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106873728.1097.84.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 19:55:28 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [3-1]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127170837.03e66ff8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 17:15, Joel M. Halpern wrote: > Note that there is actually an inconsistency between example 15 and earlier > example. In the earlier examples, when there was a BLK_LIST_INDEX, there > was a corresponding value for each value in the list. In example 15 we > added a fieldinfo, and suddenly there is a value for each field, but the > system is to implicitly duplicate them across the BLK_LIST_INDEX. That > changes the semantics. The intent was to show a target filter; i agree that it may be confusing. The first part: fieldinfo, BLK**, KEY** just says "let me describe the data target for you"; they each have slightly different semantics. KEYINFO for example will appear before the data to say what the key match is. The end goal is to describe the data ... We could change how it is used. > Note that if we remove FIELDINFO, then we have the option of adding a > semantic game. Given a BLK_LIST (Or count, or range), if there is only one > occurrence of the value (whether it is a simple value or a structure does > not matter) then the FE will understand to duplicate the value for all > entries in the BLK. This is actually a useful way to optimize for the case > that you and Weiming have asked for. As long as we do not also try to do > FIELDLIST at the same time. Please. ;-> Look at the reconstruction; since we allow the repeatable path-data i think we should be able to simplify. If we can agree that a path-data is a target-slector followed by optional data then we are on our way. I see that the target filter will describe: a) the how to get to the start of the data (via the PATH - whose keyinfo we now make optional), b) what to look for when you get there (search key via KEYINFO) c) constraints (INDINFO, BLK** or further FIELDINFO); Not forgeting the flags of course From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 20:45:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21837 for ; Thu, 27 Jan 2005 20:45:22 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuLTa-0006JI-UZ for forces-archive@IETF.ORG; Thu, 27 Jan 2005 21:03:13 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F5F7C8@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 20:45:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55386734 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 20:44:48 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 20:01:37 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8890190 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 20:01:37 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106855217.1148.70.camel@jzny.localdomain> <6.1.2.0.0.20050127152910.03e1a600@localhost> <1106869300.1097.7.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127200112.03a44828@localhost> Date: Thu, 27 Jan 2005 20:01:32 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [1]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106869300.1097.7.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I agree that is one of many acceptable solutions available to the CE. Yours, Joel At 06:41 PM 1/27/2005, Jamal Hadi Salim wrote: >On Thu, 2005-01-27 at 15:33, Joel M. Halpern wrote: > > variable chunk length fields for TLVs is such a large invitiation to > > trouble that I would strongly prefer not to go there. I understand that > > some tables may be large. Routing / Forwarding tables are more than > > 64K. There rae two reasonable answers that I can see: > > Always use 32 bit lengths for TLVs. > > Or require the CE to fetch the large tables in piecs. > > I actually think the latter is more sensible. Note that if one is > fetching > > a megabyte table over TCP, that is going to produce a noticeable blockage > > for any other transactions with that FE. > >Since we allow to have multi path-data within the same operation should >be fine for an FE actually just breaking it into 64K chunks. >Do you see any issues on that? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 20:57:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22803 for ; Thu, 27 Jan 2005 20:57:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuLfM-0006ZZ-CL for forces-archive@IETF.ORG; Thu, 27 Jan 2005 21:15:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F5F96E@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 20:57:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55387552 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 20:57:16 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 20:48:13 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8890497 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 20:48:12 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> <1106873067.1097.72.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127204629.03a446e0@localhost> Date: Thu, 27 Jan 2005 20:48:07 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106873067.1097.72.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Given that PATH-DATA can occur multiple times, I don't see the value in allowing the FIELDINGO in the IDINFO. Just repeat the path and the subscript. The saving in reduced repetition is not, to me, worth the complexity. Admittedly, this is a personal judgement call. What has been proposed can be made to work. Yours, Joel At 07:44 PM 1/27/2005, Jamal Hadi Salim wrote: >On Thu, 2005-01-27 at 17:15, Joel M. Halpern wrote: > > Actually, the more I look at this, and read your further response to > > Weiming, the less I like it. > > The identification of what is being set goes in the data path. Yes, there > > is a little bit of redundancy if one is trying to set fields x, y, and > z of > > elements 1, 3, and 5 of the same structure. However, as soon as we go > down > > this view, we now have to assemble identification from several places. > > > > This seems to be a case of making the protocol more complex in order to > > save a few bytes in a moderately rare corner case. + seems > > sufficient. > > > > I recommend removing the FIELDINFO. > >I agree on removing the nesting; >I think that it would be hard to totaly remove it: is really >flags followed by FIELDINFO except we make it _mandatory_. >Recall Weimings example: > >table2: type array, ID = 4 >elements are: > j1, type struct Add, ID = 1 > j2, type u32, ID = 2 > j3, type u32, ID = 3 > j4, type u32, ID = 4 > > Where struct Add may be globally defined as: > struct Add { > d1, type u32, ID = 1 > d2, type u32, ID = 2 > } > >And: > {{1, 2}, 3} --- meaning to address the {j1.d2, j3} > >The addressing of the above is the tricky part without nesting. > >If we remove the restriction of IDcount being mandatory and >substitute that with a single optional FIELDINFO, then this would >satisfy both what you are saying as well as what Weiming wants IMO. i.e >grammar goes from: > >---- >OPER TLV : = + >PATH-DATA := [DATAINFO] >PATH TLV := flags IDcount >DATAINFO TLV := [SELECTOR] [DATARAW] >SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] >DATARAW := somedata* [DATARAW TLV]* >IDINFO := [INDINFO] [FIELDINFO] >FIELDINFO TLV := >INDINFO TLV := one or more indexes >KEYINFO TLV := KEYID KEY_DATA >BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] >--- > >to: > >---- >OPER TLV : = + >PATH-DATA := [DATAINFO] >PATH TLV := flags [FIELDINFO] >DATAINFO TLV := [SELECTOR] [DATARAW] >SELECTOR := [BLKINFO] [KEYINFO] [IDINFO] >DATARAW := somedata* [DATARAW TLV]* >IDINFO := [INDINFO] [FIELDINFO] >FIELDINFO TLV := zero or more fieldIDs >INDINFO TLV := one or more indexes >KEYINFO TLV := KEYID KEY_DATA >BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] >--- > >What the above grammar is saying now is >1) select and/or filter the path to the target); >essentially everything from PATH on but not including DATARAW >then optinally >2) tell me what data to apply to that target. > >It could be rearranged to be more readable. > >Example >Then path to that {{1, 2} becomes: >PATH TLV: L = XXXX, > V = flags, FIELDINFO TLV, L=XXX V = {1.2} >// if specific row are being targeted then >// INDINFO or one of the BLKs will follow here. >DATAINFO TLV: L = XXXX, > V= {2000} > >Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 21:05:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23413 for ; Thu, 27 Jan 2005 21:05:28 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuLn5-0006hi-Fv for forces-archive@IETF.ORG; Thu, 27 Jan 2005 21:23:19 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F5F937@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 21:05:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55388379 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 21:05:25 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 20:55:53 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8890526 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 20:55:52 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106856473.1148.96.camel@jzny.localdomain> <6.1.2.0.0.20050127164448.03c75e48@localhost> <1106871329.1090.42.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050127204833.03a68cb0@localhost> Date: Thu, 27 Jan 2005 20:55:46 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1106871329.1090.42.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db I think that there are two separate things mixed here. If I disentangle them, we may get clearer, and I suspect end up near agreement. We have to define an encoding for data. This has to be able to handle simple values (uint32, uint8), variable length character strings, byte strings, structures, and tables. After all, I can GET a structure which in turn contains a number and a table. So I have to be able to represent within the data, a table. Whether this is a packed binary structure, a nested TLV structure, or some other mechanism we can imagine makes relatively little difference to me. The generator and receiver will both know the relevant data types. So they can use that to help with parsing. Or we can encode redundant type and length information to make things more consistent and more robust. Or .... There does need to be a block of data sent on a SET request and returned in a successful GET response. This will need to be in a TLV inside the PATH-DATA TLV. If the data encoding uses a packed structure, then this TLV will be the DATA TLV> If the data encoding uses TLVs for array, structure, string, etc then this will presumably be the correct top level TLV needed for the type of the target of the operation. In either case, there presumably will be as many of these TLVs as there are entries in a BLK request. (Or, if we keep it, entries in a nested FIELDINFO request.) In either case, when fetching or setting an entire table we will not need the BLK construct as the data respresentation will need to be complete enough to handle it. Yours, Joel M. Halpern At 07:15 PM 1/27/2005, Jamal Hadi Salim wrote: > > What I am looking for is that "GET whole table" uses a simpler structure > > than "GET range". > > Get RANGE does exactly what you describe. > >Ok - gotcha. >What you described is fine too but rather implicit. Could we have an >explicit flag to say that this is happening or a new TLV type to >indicate it - something like T=BULKDATA? > > > Note that this can be used in a SET operation. The FE will understand > that > > the whole table is to be replaced. > >Agreed. > > > (This is important since a SET of Blk > > range 0..2 does not mean one should delete entries after 2.) > > Hence, this is a more reliable way to do a GET that can be used as a SET. > > (There is no need to worry about delete. Delete for the whole table, if > > defined, just uses the path to the table, with no value elements needed.) > >nod. > > > The other advantage of this is when there is a table2 inside > > table1. Suppose that table1's entries are a j1value and a table with x1 > > and x2 values. Then, > > > > GET > > Path = IDCount = 1, IDs = 4 > > > > result: > > Path = IDcount = 1, IDs - 4 > >We would still need to encap whats below in a TLV, DATARAW or whatever >other name that would recognize what this is. > > > Values: > > # of entries in table1 > > subscript(0), j1value > > # of entries of this table2 instance > > subscript(0), x1value, x2value > > subscript(1), x1value, x2value > > ... > >Using "# of entries in tableX" - why not just use a TLV there? > >Something like >Path = IDcount = 1, IDs - 4 >BULKDATA TLV, L = XXXX > Values: > subscript(0), j1value, BULKDATA TLV, L = XXXX > Values > subscript(0), x1value, x2value > subscript(1), x1value, x2value > ..... > .... > subscript(1), j1value, BULKDATA TLV, L = XXXX > Values > subscript(0), x1value, x2value > subscript(1), x1value, x2value > ..... > .... > ... > .... > ... From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 21:45:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26376 for ; Thu, 27 Jan 2005 21:45:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuMPM-0007ZT-8R for forces-archive@IETF.ORG; Thu, 27 Jan 2005 22:02:53 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F5FB9D@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 21:45:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55392631 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 21:44:59 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 21:43:21 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012718423575:17909 ; Thu, 27 Jan 2005 18:42:35 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> <1106873067.1097.72.camel@jzny.localdomain> <6.1.2.0.0.20050127204629.03a446e0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 06:42:36 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 06:42:37 PM, Serialize complete at 01/27/2005 06:42:37 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106880198.1091.91.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 21:43:19 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127204629.03a446e0@localhost> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 20:48, Joel M. Halpern wrote: > Given that PATH-DATA can occur multiple times, I don't see the value in > allowing the FIELDINGO in the IDINFO. Just repeat the path and the > subscript. The saving in reduced repetition is not, to me, worth the > complexity. > Admittedly, this is a personal judgement call. What has been proposed can > be made to work. It does sound reasonable to get rid of the internal FIELDINFO; I will have to run the use cases again to double check. This will lead the grammar to be: OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags [FIELDINFO] DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO] [INDINFO] DATARAW := somedata* [DATARAW TLV]* FIELDINFO TLV := zero or more fieldIDs INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] Weiming this should meet you desire to do: path(1.2) Data(2000) ; suppose to set j1.d2=2000 path(3) Data(300) and path(1) Data(100) path(2) Data(200) path(3) Data(300) Ive substituted the word subpath with path from above grammar. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jan 27 22:12:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27982 for ; Thu, 27 Jan 2005 22:12:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuMpi-00084r-O5 for forces-archive@IETF.ORG; Thu, 27 Jan 2005 22:30:07 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F5FA4B@cherry.ease.lsoft.com>; Thu, 27 Jan 2005 22:12:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55395105 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 27 Jan 2005 22:11:55 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 27 Jan 2005 22:11:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012719102265:18057 ; Thu, 27 Jan 2005 19:10:22 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106856473.1148.96.camel@jzny.localdomain> <6.1.2.0.0.20050127164448.03c75e48@localhost> <1106871329.1090.42.camel@jzny.localdomain> <6.1.2.0.0.20050127204833.03a68cb0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 07:10:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/27/2005 07:10:25 PM, Serialize complete at 01/27/2005 07:10:25 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106881865.1097.131.camel@jzny.localdomain> Date: Thu, 27 Jan 2005 22:11:05 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127204833.03a68cb0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Agreed on no need for BLK for entire tables and that those are optimizations really for ranges; The knowledge by the receiver/transmitter about what the data being carried is in my opinion the main optimization. In otherwise, if you can be told where on the LFB definition the data comes from, you can 100%, unambigously, intepret that data type. So defining DATARAW in addition to the path coordinates is sufficient for _all_ details. I though a little about the table dump you pointed to earlier and I dont think we need a new BULKDATA TLV; i.e by looking at the path Field ID, we know its table4 and we can therefore decode it. So a DATARAW is sufficient. The other way to do it (I think maybe thats what you are alluding to here) is to define containers for different DataTypes; The advantage of this case is that it is more structured data that can infact be decoded by any entity with not much knowledge of the LFB data definitions. The disadvantage i think is we will end up being relatively less efficient and we are more than likely going to run into the same issues as the Zsolt/Steve proposal. Like i said earlier: not religious if we dont get bogged down. cheers, jamal On Thu, 2005-01-27 at 20:55, Joel M. Halpern wrote: > I think that there are two separate things mixed here. If I disentangle > them, we may get clearer, and I suspect end up near agreement. > > We have to define an encoding for data. This has to be able to handle > simple values (uint32, uint8), variable length character strings, byte > strings, structures, and tables. After all, I can GET a structure which in > turn contains a number and a table. So I have to be able to represent > within the data, a table. > Whether this is a packed binary structure, a nested TLV structure, or some > other mechanism we can imagine makes relatively little difference to > me. The generator and receiver will both know the relevant data types. So > they can use that to help with parsing. Or we can encode redundant type > and length information to make things more consistent and more robust. Or .... > > There does need to be a block of data sent on a SET request and returned in > a successful GET response. This will need to be in a TLV inside the > PATH-DATA TLV. If the data encoding uses a packed structure, then this TLV > will be the DATA TLV> If the data encoding uses TLVs for array, structure, > string, etc then this will presumably be the correct top level TLV needed > for the type of the target of the operation. > In either case, there presumably will be as many of these TLVs as there are > entries in a BLK request. (Or, if we keep it, entries in a nested > FIELDINFO request.) > > In either case, when fetching or setting an entire table we will not need > the BLK construct as the data respresentation will need to be complete > enough to handle it. > > Yours, > Joel M. Halpern > > At 07:15 PM 1/27/2005, Jamal Hadi Salim wrote: > > > What I am looking for is that "GET whole table" uses a simpler structure > > > than "GET range". > > > Get RANGE does exactly what you describe. > > > >Ok - gotcha. > >What you described is fine too but rather implicit. Could we have an > >explicit flag to say that this is happening or a new TLV type to > >indicate it - something like T=BULKDATA? > > > > > Note that this can be used in a SET operation. The FE will understand > > that > > > the whole table is to be replaced. > > > >Agreed. > > > > > (This is important since a SET of Blk > > > range 0..2 does not mean one should delete entries after 2.) > > > Hence, this is a more reliable way to do a GET that can be used as a SET. > > > (There is no need to worry about delete. Delete for the whole table, if > > > defined, just uses the path to the table, with no value elements needed.) > > > >nod. > > > > > The other advantage of this is when there is a table2 inside > > > table1. Suppose that table1's entries are a j1value and a table with x1 > > > and x2 values. Then, > > > > > > GET > > > Path = IDCount = 1, IDs = 4 > > > > > > result: > > > Path = IDcount = 1, IDs - 4 > > > >We would still need to encap whats below in a TLV, DATARAW or whatever > >other name that would recognize what this is. > > > > > Values: > > > # of entries in table1 > > > subscript(0), j1value > > > # of entries of this table2 instance > > > subscript(0), x1value, x2value > > > subscript(1), x1value, x2value > > > ... > > > >Using "# of entries in tableX" - why not just use a TLV there? > > > >Something like > >Path = IDcount = 1, IDs - 4 > >BULKDATA TLV, L = XXXX > > Values: > > subscript(0), j1value, BULKDATA TLV, L = XXXX > > Values > > subscript(0), x1value, x2value > > subscript(1), x1value, x2value > > ..... > > .... > > subscript(1), j1value, BULKDATA TLV, L = XXXX > > Values > > subscript(0), x1value, x2value > > subscript(1), x1value, x2value > > ..... > > .... > > ... > > .... > > ... From owner-forces@PEACH.EASE.LSOFT.COM Fri Jan 28 13:49:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28908 for ; Fri, 28 Jan 2005 13:49:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubSr-0004iE-IP for forces-archive@IETF.ORG; Fri, 28 Jan 2005 14:07:30 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F60E2D@cherry.ease.lsoft.com>; Fri, 28 Jan 2005 13:49:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55503733 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 28 Jan 2005 13:49:28 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 28 Jan 2005 13:46:47 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005012810460208:21636 ; Fri, 28 Jan 2005 10:46:02 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106856473.1148.96.camel@jzny.localdomain> <6.1.2.0.0.20050127164448.03c75e48@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/28/2005 10:46:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/28/2005 10:46:03 AM, Serialize complete at 01/28/2005 10:46:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1106938005.1025.168.camel@jzny.localdomain> Date: Fri, 28 Jan 2005 13:46:46 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [2]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050127164448.03c75e48@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Some small gotcha in the BNF found while walking through the use cases.. To use Joels example below: On Thu, 2005-01-27 at 17:01, Joel M. Halpern wrote: > The other advantage of this is when there is a table2 inside > table1. Suppose that table1's entries are a j1value and a table2 with x1 > and x2 values. To give some values: Table1: ID 1 j1: ID 1, table2: ID2 x1: ID 1, x2: ID2 Lets say i wanted to set cell x1 of table2's index 4 which is contained in table1 index 10. The old way i would have specified a path with a mix of both field and index ids together. i.e 1.10.2.4.1 i.e a field.index.field.index.field And the data would contain whatever i want to set to x1. The only way to get this working now is to allow one of: a) PATHINFO := <[FIELDINFO][INDINFO]>* i.e you could have zero or more combos of FIELDINFO and INDINFO TLVs; A Field info preceeds a INDINFO --> 20 bytes overhead for example i gave b) Both FIELDINFO and INDINFO to be able to recursively contain each other i.e: FIELDINFO := fieldvalue(s) [INDINFO] INDINFO := index(es) [FIELDINFO] No difference in overhead; still 20 bytes c) restore or allow as a substitute the original format we had i.e the 1.10.2.4.1 example i gave MIXEDINFO:= a mix of fieldvalue(s) and indexes 4 bytes of overhead and rather intuitive to me. My prefered mode really. Disdvantage is now in the simple case we have a simple case such as 1.10 being describable by either FIELDINFO followed by INDINFO or by a single MIXEDINFO TLV. I am worried this is getting out of control; but should be noted that it is absolutely not an obscure case - we actually do use such a table layout. I believe if we can solve this, we are done on path data. cheers, jamal PS: As a reminder the standing BNF so far is: OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags [FIELDINFO] DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [BLKINFO] [KEYINFO] [INDINFO] DATARAW := somedata* [DATARAW TLV]* FIELDINFO TLV := zero or more fieldIDs INDINFO TLV := one or more indexes KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 06:08:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21243 for ; Sun, 30 Jan 2005 06:08:18 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvDDv-0006v9-Al for forces-archive@IETF.ORG; Sun, 30 Jan 2005 06:26:40 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F63689@cherry.ease.lsoft.com>; 30 Jan 2005 6:08:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55689654 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 06:08:05 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 03:43:05 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 29 Jan 2005 17:11:34 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 29 Jan 2005 16:42:29 +0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> <003901c5021c$a10a16e0$020aa8c0@wwm1> <1106595083.1079.61.camel@jzny.localdomain> <006d01c50420$2c0e33c0$0973c0dc@WwmLapSamsung> <1106859053.1145.139.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <01c701c505de$76898610$845c21d2@Necom.hzic.edu.cn> Date: Sat, 29 Jan 2005 16:42:27 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Jamal, Let me firstly explain the BNF for Subpaths that I proposed a litlle more. Pls allow me follow your BNF: > OPER TLV : = + > PATH-DATA := [DATAINFO] > PATH TLV := flags IDcount > DATAINFO TLV := [SELECTOR] [DATARAW] > SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] > DATARAW := somedata* [DATARAW TLV]* > IDINFO := [INDINFO] [FIELDINFO] > FIELDINFO TLV := > INDINFO TLV := one or more indexes > KEYINFO TLV := KEYID KEY_DATA > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] To simplify things, I just modify it with my thoughts inside as: OPER TLV : = + PATH-DATA := [DATAINFO] PATH TLV := flags IDcount DATAINFO TLV := [SELECTOR] [DATARAW] SELECTOR := [INDINFO] [SUBPATHINFO]* [KEYINFO]* !I think the BLKINFO can be included in INDINFO anyway, which all belongs to index ops. DATARAW := somedata* [DATARAW TLV]* INDINFO TLV:= [ENUM_INDEX] | [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] !ENUM_INDEX TLV is for enumerated indexs. SUBPATHINFO TLV:= IDcounts SUBPATH_DATA KEYINFO TLV := KEYID KEY_DATA !A comment here is, I do think a KEYID is a kind of FIELDID, therefore SUBPATHINFO format can include what KEYINFO does, note that the SUBPATHINFO TLV is identical to KEYINFO TLV only with a IDcounts added to allow more than one IDs. As a result, I even think we do not need the KEYINFO format in BNF here. The restriction imposed on KEYs can be defined by Model document (Just my thinking, I know it will be strongly objected.) Following above BNF, addressing to things like { {1,2},3} actually goes with two separate SUBPATHINFOs as: SUBPATHINFO TLV V = {IDcounts(2), IDs(1,2), Data(2000)} SUBPATHINFO TLV V = {IDcounts(1), IDs(3), Data(300)} Pls also see more a small comments inline below. Cheers, Weiming > Then: > {{1, 2}, 3} becomes: > > FIELDINFO TLV, L = XXXX > V = {{FIELDINFO TLV, L = XXX, V = {1, 2}},3} > And > {1, 2, 3} is: > > FIELDINFO TLV, L = XXXX > V = {1, 2, 3} I'm afraid this still does not solve the uniqueness issue, for the nested FIELDINFO TLV can still not be uniquely parsed, the V part still can be parsed as with or without the nested TLV. From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 06:08:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21265 for ; Sun, 30 Jan 2005 06:08:19 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvDE1-0006vK-Ga for forces-archive@IETF.ORG; Sun, 30 Jan 2005 06:26:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F636A9@cherry.ease.lsoft.com>; 30 Jan 2005 6:08:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55689736 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 06:08:16 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 04:17:04 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 29 Jan 2005 17:45:39 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 29 Jan 2005 17:16:33 +0800 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> <1106873067.1097.72.camel@jzny.localdomain> <6.1.2.0.0.20050127204629.03a446e0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <01e801c505e3$3930ed30$845c21d2@Necom.hzic.edu.cn> Date: Sat, 29 Jan 2005 17:16:32 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [3]Re: path data textt update > Given that PATH-DATA can occur multiple times, I don't see the value in > allowing the FIELDINGO in the IDINFO. Just repeat the path and the > subscript. The saving in reduced repetition is not, to me, worth the > complexity. I'v seen several times you mentioned the complexity the subpaths may add. I'v been thinking of the complexity you might thought, but the more I think, the more I find things are on the contrary, i.e., the repeated PATH-DATA will add much unnecessary complexity for system, not only the bits consuming. I'v made a post explaining the advantage for subpaths, and also hope you can reply with the contrary views, but a pity is I still didn' t get. I know you are quite experienced, but it may be difficult to fully understand what you mean before you show with more details. To more clearly express my views, pls allow me mention the example again as: To use the separate Path-Data way, we have a sequence of Path-Data as: OpTLV= 'Set' ... Path(4.1) IndexTLV (1,3,5,7,9) Data(100) Path(4.2) IndexTLV (1,3,5,7,9) Data(200) Path(4.3) IndexTLV (1,3,5,7,9) Data(300) To use a subpath way, we have a path-data as: Path(4) IndexTLV(1,3,5,7,9) Subpath(1) Data(100) Subpath(2) Data(200) Subpath(3) Data(300) To compare with: 1. the difference for bits consuming is very obvious. 2. The PATH-DATA + repeating mode also results in the complexity for resources consuming. Just consider we may need unnecessarily repeat the searching work for Index(1,3,5,7,9) for three times. Just as I mentioned an example before, why we need to drive three times to deliver three pieces of pisa to a family to the father, mother, and son? Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 06:11:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21432 for ; Sun, 30 Jan 2005 06:11:20 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvDGw-0006yB-0C for forces-archive@IETF.ORG; Sun, 30 Jan 2005 06:29:42 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F63570@cherry.ease.lsoft.com>; 30 Jan 2005 6:11:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55691029 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 06:11:14 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 29 Jan 2005 04:22:36 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 29 Jan 2005 17:51:10 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 29 Jan 2005 17:22:05 +0800 References: <1106764338.1073.32.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> Date: Sat, 29 Jan 2005 17:22:03 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Jamal, One more thing I have to mention is, the KEY you used in your example is actually also a fieldID anyway. To use KEYINFO this way is actually the same as Subpaths. Quoted from your example: table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 2) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} This is exactly what I mean the thought for subpaths, only with that subpaths allow more than one level fieldID addressing. I'm afraid what Joel means for KEY is a little different from what you mean :) Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Thursday, January 27, 2005 2:32 AM Subject: path data textt update > > Changelog: > --------- > $Log: data_path2.txt,v $ > Revision 1.7 2005/01/26 06:27:10 hadi > fixed INDINFO definition as caught by Weiming > Added FIELDINFO > Added example on selective setting based on posting from Weiming. > > > Diff and text both attached. > > Please read it. > > cheers, > jamal > From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 12:02:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16097 for ; Sun, 30 Jan 2005 12:02:32 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvIkr-0005Fa-25 for forces-archive@IETF.ORG; Sun, 30 Jan 2005 12:20:57 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F63BE0@cherry.ease.lsoft.com>; 30 Jan 2005 12:02:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55740283 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 12:02:15 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 30 Jan 2005 11:51:30 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8935675 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 11:51:29 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <6.1.2.0.0.20050126164837.039c7b18@localhost> <1106857733.1148.119.camel@jzny.localdomain> <6.1.2.0.0.20050127170837.03e66ff8@localhost> <1106873067.1097.72.camel@jzny.localdomain> <6.1.2.0.0.20050127204629.03a446e0@localhost> <01e801c505e3$3930ed30$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050130114248.0643eec0@localhost> Date: Sun, 30 Jan 2005 11:50:22 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <01e801c505e3$3930ed30$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 You are correct that if content searching is common, and particularly if arbitrary content searching is allowed, then the repetition of the content search clause would represent a significant increase in work. In contrast, if all of the element identifiers are in the path description, then the logic for parsing / interpreting paths and determining the class of object being manipulated is in one place, controlled by one field. This produces a significant increase in consistency and accuracy as compared with assembling paths from multiple components. And I normally expect that even the references to multiple indexes, and the setting of multiple discrete items in a single LFB are both moderately rare. If we have done our job right, items which are manipulated together will be defined in common structures. After looking over the discussion, I can probably live with the subpath. It would have to be structured along the lines of your example, rather than the earlier BNF proposal. That is, the two multiply occurring elements (indexing and subpathing) have to be neszted and arranged with the data in such a way that it is very clear what is being repeated, and how the data relates to the repetition. (Part of my concern with the previous example, was the odd grouping that had crept into the organization of information as we tried to understand each other.) I would ask at the same time whether you can live with a more restricted form of content addressing. Yours, Joel M. Halpern At 04:16 AM 1/29/2005, Wang,Weiming wrote: >Joel, > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: [3]Re: path data textt update > > > > Given that PATH-DATA can occur multiple times, I don't see the value in > > allowing the FIELDINGO in the IDINFO. Just repeat the path and the > > subscript. The saving in reduced repetition is not, to me, worth the > > complexity. >I'v seen several times you mentioned the complexity the subpaths may add. I'v >been thinking of the complexity you might thought, but the more I think, the >more I find things are on the contrary, i.e., the repeated PATH-DATA will add >much unnecessary complexity for system, not only the bits consuming. I'v >made a >post explaining the advantage for subpaths, and also hope you can reply >with the >contrary views, but a pity is I still didn' t get. I know you are quite >experienced, but it may be difficult to fully understand what you mean before >you show with more details. > >To more clearly express my views, pls allow me mention the example again as: > >To use the separate Path-Data way, we have a sequence of Path-Data as: >OpTLV= 'Set' ... >Path(4.1) IndexTLV (1,3,5,7,9) Data(100) >Path(4.2) IndexTLV (1,3,5,7,9) Data(200) >Path(4.3) IndexTLV (1,3,5,7,9) Data(300) > >To use a subpath way, we have a path-data as: >Path(4) IndexTLV(1,3,5,7,9) >Subpath(1) Data(100) >Subpath(2) Data(200) >Subpath(3) Data(300) > >To compare with: >1. the difference for bits consuming is very obvious. >2. The PATH-DATA + repeating mode also results in the complexity for resources >consuming. Just consider we may need unnecessarily repeat the searching >work for >Index(1,3,5,7,9) for three times. Just as I mentioned an example before, >why we >need to drive three times to deliver three pieces of pisa to a family to the >father, mother, and son? > >Cheers, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 15:04:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29190 for ; Sun, 30 Jan 2005 15:04:47 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvLb8-0000CN-A0 for forces-archive@IETF.ORG; Sun, 30 Jan 2005 15:23:13 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F63DDD@cherry.ease.lsoft.com>; 30 Jan 2005 15:04:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55752361 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 15:04:38 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 30 Jan 2005 14:55:44 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005013011545240:25970 ; Sun, 30 Jan 2005 11:54:52 -0800 References: <1105996187.1079.288.camel@jzny.localdomain> <1a1701c4ff82$2644c910$845c21d2@Necom.hzic.edu.cn> <1106322434.1088.44.camel@jzny.localdomain> <1a4d01c50051$3d3f5980$845c21d2@Necom.hzic.edu.cn> <6.1.2.0.0.20050122095802.06550ec0@localhost> <003901c5021c$a10a16e0$020aa8c0@wwm1> <1106595083.1079.61.camel@jzny.localdomain> <006d01c50420$2c0e33c0$0973c0dc@WwmLapSamsung> <1106859053.1145.139.camel@jzny.localdomain> <01c701c505de$76898610$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/30/2005 11:54:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/30/2005 11:54:59 AM, Serialize complete at 01/30/2005 11:54:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1107114937.7840.56.camel@jzny.localdomain> Date: Sun, 30 Jan 2005 14:55:37 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: updated path data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <01c701c505de$76898610$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Weiming, On Sat, 2005-01-29 at 03:42, Wang,Weiming wrote: > Jamal, > > Let me firstly explain the BNF for Subpaths that I proposed a litlle more. Pls > allow me follow your BNF: > > > OPER TLV : = + > > PATH-DATA := [DATAINFO] > > PATH TLV := flags IDcount > > DATAINFO TLV := [SELECTOR] [DATARAW] > > SELECTOR := [BLKINFO] [KEYINFO]* [IDINFO] > > DATARAW := somedata* [DATARAW TLV]* > > IDINFO := [INDINFO] [FIELDINFO] > > FIELDINFO TLV := > > INDINFO TLV := one or more indexes > > KEYINFO TLV := KEYID KEY_DATA > > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] > > To simplify things, I just modify it with my thoughts inside as: > > OPER TLV : = + > PATH-DATA := [DATAINFO] > PATH TLV := flags IDcount > DATAINFO TLV := [SELECTOR] [DATARAW] > SELECTOR := [INDINFO] [SUBPATHINFO]* [KEYINFO]* > !I think the BLKINFO can be included in INDINFO anyway, which all belongs to > index ops. sure. > DATARAW := somedata* [DATARAW TLV]* > INDINFO TLV:= [ENUM_INDEX] | [BLK_RANGE_INDEX] | [BLK_CNT_INDEX] > !ENUM_INDEX TLV is for enumerated indexs. Can you provide an example of ENUM_INDEX? > SUBPATHINFO TLV:= IDcounts SUBPATH_DATA So SUBPATH_DATA is actually data to be used for setting as opposed for searching/matching? Did i understand correctly? > KEYINFO TLV := KEYID KEY_DATA > !A comment here is, I do think a KEYID is a kind of FIELDID, therefore > SUBPATHINFO format can include what KEYINFO does, note that the SUBPATHINFO TLV > is identical to KEYINFO TLV only with a IDcounts added to allow more than one > IDs. As a result, I even think we do not need the KEYINFO format in BNF here. I am not sure i understood what SUBPATH_DATA is to be used for. KEY_DATA is the key value to compare against. In other words, you do not set anything with that data but you use it to refine entities of interest. > The restriction imposed on KEYs can be defined by Model document (Just my > thinking, I know it will be strongly objected.) Agreed. > Following above BNF, addressing to things like { {1,2},3} actually goes with two > separate SUBPATHINFOs as: > > SUBPATHINFO TLV > V = {IDcounts(2), IDs(1,2), Data(2000)} > > SUBPATHINFO TLV > V = {IDcounts(1), IDs(3), Data(300)} > So now i understand that SUBPATH_DATA is actually data that is to be set. in which case: How do you describe content that is to be searched? If you can meet that requirement I can live with it. Rewrite the grammar to include this as well. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jan 30 15:06:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29425 for ; Sun, 30 Jan 2005 15:06:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvLcx-0000E5-1m for forces-archive@IETF.ORG; Sun, 30 Jan 2005 15:25:07 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F63D92@cherry.ease.lsoft.com>; 30 Jan 2005 15:06:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 55752438 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 30 Jan 2005 15:06:29 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 30 Jan 2005 15:05:08 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005013012042000:26082 ; Sun, 30 Jan 2005 12:04:20 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/30/2005 12:04:20 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 01/30/2005 12:04:23 PM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Message-ID: <1107115504.7847.67.camel@jzny.localdomain> Date: Sun, 30 Jan 2005 15:05:04 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: path data textt update Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: base64 T24gU2F0LCAyMDA1LTAxLTI5IGF0IDA0OjIyLCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+IEphbWFs LA0KPiANCj4gT25lIG1vcmUgdGhpbmcgSSBoYXZlIHRvIG1lbnRpb24gaXMsIHRoZSBLRVkgeW91 IHVzZWQgaW4geW91ciBleGFtcGxlIGlzDQo+IGFjdHVhbGx5IGFsc28gYSBmaWVsZElEIGFueXdh eS4gVG8gdXNlIEtFWUlORk8gdGhpcyB3YXkgaXMgYWN0dWFsbHkgdGhlIHNhbWUgYXMNCj4gU3Vi cGF0aHMuICBRdW90ZWQgZnJvbSB5b3VyIGV4YW1wbGU6DQo+IA0KPiB0YWJsZTI6IHR5cGUgYXJy YXksIElEID0gNA0KPiBlbGVtZW50cyBhcmU6DQo+IGoxLCB0eXBlIHUzMiwgSUQgPSAxDQo+IGoy LCB0eXBlIHUzMiwgSUQgPSAyDQo+IA0KPiANCj4gMikgZGVsZXRlICBmaXJzdCAxMCBlbnRyaWVz IHdpdGggajE9MTAwLCBhbmQgajI9MjAwIGluIHRhYmxlIDIsDQo+IHN0YXJ0aW5nIGF0IGluZGV4 IDEwLg0KPiANCj4gUGF0aDogSURDb3VudCA9IDEsIElEcz00DQo+IFNFTEVDVE9SIDo9DQo+IEJM S19DTlRfSU5ERVggVExWID0gezEwLDEwfQ0KPiBLRVlJTkZPID0ge0tFWUlEID0xIEtFWV9EQVRB PTEwMH0NCj4gS0VZSU5GTyA9IHtLRVlJRCA9MiBLRVlfREFUQT0yMDB9DQo+IA0KPiBUaGlzIGlz IGV4YWN0bHkgd2hhdCBJIG1lYW4gdGhlIHRob3VnaHQgZm9yIHN1YnBhdGhzLCBvbmx5IHdpdGgg dGhhdCBzdWJwYXRocw0KPiBhbGxvdyBtb3JlIHRoYW4gb25lIGxldmVsIGZpZWxkSUQgYWRkcmVz c2luZy4NCg0KDQpLRVlJTkZPIGRvZXMgbm90IHNldCBhbnkgdmFsdWU7IGl0IGlzIG1lcmVseSBk ZXNjcmliaW5nIGhvdyB0byBzZWFyY2gNCmFuZCBmaW5kIHdoYXQgdG8gZGVsZXRlLg0KTG9va2lu ZyBhdCB5b3VyIHByZXZpb3VzIHBvc3RpbmcsIHN1YnBhdGggaXMgdXNlZCB0byBhbHNvIGNhcnJ5 IGRhdGEgdG8NCmJlIHVzZWQgZm9yIHNldHRpbmcgLSB1bmxlc3MgaSBtaXN1bmRlcnN0b29kLg0K SG93IGRvIHlvdSBzYXkgImZpcnN0IDEwIGVudHJpZXMgd2l0aCBqMT0xMDAsIGFuZCBqMj0yMDAg aW4gdGFibGUNCjIsc3RhcnRpbmcgYXQgaW5kZXggMTCoIHdpdGggc3VicGF0aD8NCg0KPiBJJ20g YWZyYWlkIHdoYXQgSm9lbCBtZWFucyBmb3IgS0VZIGlzIGEgbGl0dGxlIGRpZmZlcmVudCBmcm9t IHdoYXQgeW91IG1lYW4gOikNCj4gDQoNClRoZSBLRVkgbWVyZWx5IGRlc2NyaWJlcyBzZWFyY2gg Y29udGVudCBhbmQgTkVWRVIgZGF0YSB0byBiZSBzZXQuIEkNCnRoaW5rIHRoaXMgbWF5IGJlIHRo ZSBtaXN1bmRlcnN0YW5kaW5nLiBZb3Ugc2VlbSB0byBiZSBzYXlpbmcgc3VicGF0aA0KY2FuIGhh dmUgY29uc3RydWN0IHdoaWNoIGNhbiBiZSB1c2VkIHRvIGJlIGJvdGggZmlsdGVyIGFzIHdlbGwg YXMgDQpkYXRhIHRvIGJlIHNldC4gTWF5YmUgeW91IGNhbiBkZXNjcmliZSB0aGlzIGFuZ2xlIGEg bGl0dGxlIG1vcmUuDQoNCldoYXQgSm9lbCB3YW50cyBpcyBpbiBhZGRpdGlvbiB0byByZXN0cmlj dCB3aGF0IGZpZWxkSUQgY2FuIGJlIGEga2V5DQood2hpY2ggY291bGQgYmUgZG9uZSBpbiB0aGUg TEZCIGRvY3VtZW50KS4NCg0KY2hlZXJzLA0KamFtYWwNCg0K