From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 1 10:04: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 KAA12370 for ; Tue, 1 Feb 2005 10:04:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvzs1-0004PK-OY for forces-archive@IETF.ORG; Tue, 01 Feb 2005 10:23: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 <12.00F66F5C@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 10:04:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56029645 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 10:04:17 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Feb 2005 09:52:37 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8965746 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 01 Feb 2005 09:52:37 -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> <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 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050201093343.03aaae98@localhost> Date: Tue, 1 Feb 2005 09:52:09 -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: <01c701c505de$76898610$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Since things went momentarily quiet, let me take a crack at what I think we have discussed. Weiming has asked for some efficiency in referencing related components. I have asked that we use unique, pre-declared keys. Jamal (and others I think) have asked for block operations. We are still discussing where index (subscript) values go. For this description, I am going to put them with content keys. I would really like to be able to put the common case of simple subscripts into the data path. This can be done using a flag if we restrict content keying to the leaf reference. As we do not have agreement on that, I am NOT including that in this description. I think that would give: OPER TLV := + PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO := * * SELECTOR := BLKINFO | KEYINFO | IDXINFO DATA := DATARAW | + KEYINFO := KeyID DATARAW IDXINFO := uint32 DATARAW := encoded data representing ForCES LFB information. This can represent a simple value, a structure, a string, an array, or any other declared ForCES type. The questions of whether this is a packed representation, a TLV structure, or something else is a separable, and separate, discussion. IDs are identifiers of elements of LFBs or structures. The number of Selectors must either the same as the number of non-terminal array types selected by the IDs, plus an additional optional selector if the full ID list selects an array and a single element of the array is being referenced rather than the whole array. A Selector is either a blk / range selector TLV or it is an index TLV holding an unsigned integer, or it is a keying TLV holding a key identifier and a DATARAW. The question of the interaction between blk selectors and the following data element(s) is not fully resolved. It seems desirable to allow the following two cases: If a block selector is followed by a single DATA TLV, then the Data (inner selection and/or value) is applied to each of the elements of the block. If a block selector is followed by a number of DATA TLVs equal to the size of the block, then each DATA TLV corresponds to one element of the block. Do we need both of these? Presumably, if the number is not 1 and does not match it is an error. Note that using two BLKINFO selectors relative to nested arrays is legal, and should be defined to work, but is very prone to unexpected results. (The number of elements that actually match the selector may not be the same for different inner array occurrances.) Inner PATH-DATA will normally be used only when more than one item is being selected. It allows the factoring out of the common subexpressions. This may allow some efficiency in implementation and does allow some efficiency in bits on the wire. Yours, Joel M. Halpern At 03:42 AM 1/29/2005, Wang,Weiming wrote: > > 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] From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 1 14:30: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 OAA09564 for ; Tue, 1 Feb 2005 14:30:21 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw41R-0002r5-Bs for forces-archive@IETF.ORG; Tue, 01 Feb 2005 14:49: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.00F674A8@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 14:30:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56059900 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 14:30:21 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Feb 2005 14:28:17 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8969494 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 01 Feb 2005 14:28:16 -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> <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> <6.1.2.0.0.20050201093343.03aaae98@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050201141927.03be54f8@localhost> Date: Tue, 1 Feb 2005 14:27:38 -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: <6.1.2.0.0.20050201093343.03aaae98@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Following up on this, I have been batting an idea for the path / index / key encoding back and forth. The following changes the PATH and Selector encoding, with the goal of simplifying the common cases: There is one more variation that occurs to me. This is not what I sent to the list, and has some advantages and disadvantages. Tell me what you think. Suppose we declare that block and content indexing can only be applied at the end of a path. Given nesting, this does not restrict what can be described, just where one has to split the TLVs. Then, we declare that indexes are included in the path sequence. Suppose we take two flag bits, and declare the meanings as: 00 last not a table (normal case), includes the case where the last is an indexed selection of a table element. 01 last is the entire table 10 last is a block selection from the table. See BLK TLV 11 last is a content keyed selection from the table, see KEY TLV And the there is exactly one BLK or KEY TLV, and that is present only if the bits are set. (Arguably, the 01 combination is redundant, but the bits are available and it provides clarity.) So, to select x1 from table2 entry 4 inside table1 entry 10 we would have OPER TLV PATH flag = 00, count = 5, IDS = 1.10.2.4.1 as we would like. To select, from all table1s, the x1s of the 4the element of table2, we would have OPER TLV: (whatever operation is being performed PATH-DATA TLV flag = 01, count=1, IDS = 1 PATH-DATA TLV flag = 00, count=3, IDS = 2.4.1 To select an x2 based on the value of x1 (where x1 as a key has KeyID 1) from the 10th element of table1, we would have OPER TLV: (whatever operation is being performed) PATH-DATA TLV flag = 11, count = 3, IDS = 1.10.2 KEYTLV, KEYID = 1, DATARAW = x1value PATH-DATA TLV flag = 00, count = 1, IDS = 2 (to select x2) If we go with this, the syntax would become: OPER TLV := + PATH-DATA := [DATAINFO] PATH := flags IDcount DATAINFO := [SELECTOR] * SELECTOR := BLKINFO | KEYINFO DATA := DATARAW | + KEYINFO := KeyID DATARAW IDXINFO := uint32 DATARAW := encoded data representing ForCES LFB information. Where IDs would include subscripts, and SELECTOR would only occur if the flags indicated it should, and would only apply to the table that would be the end of the PATH at the TLV level. This would mean that nested PATH-DATA is used both for multiple selection with common part extraction and for intermediate content keyed/ block selection. Yours, Joel At 09:52 AM 2/1/2005, Joel M. Halpern wrote: >Since things went momentarily quiet, let me take a crack at what I think >we have discussed. > >Weiming has asked for some efficiency in referencing related components. >I have asked that we use unique, pre-declared keys. >Jamal (and others I think) have asked for block operations. >We are still discussing where index (subscript) values go. For this >description, I am going to put them with content keys. > I would really like to be able to put the common case of simple > subscripts > into the data path. This can be done using a flag if we restrict content > keying to the leaf reference. As we do not have agreement on that, I am > NOT including that in this description. > >I think that would give: > >OPER TLV := + >PATH-DATA := [DATAINFO] >PATH := flags IDcount >DATAINFO := * * >SELECTOR := BLKINFO | KEYINFO | IDXINFO >DATA := DATARAW | + >KEYINFO := KeyID DATARAW >IDXINFO := uint32 >DATARAW := encoded data representing ForCES LFB information. > This can represent a simple value, a structure, a string, an array, > or any other declared ForCES type. > The questions of whether this is a packed representation, a TLV > structure, or something else is a separable, and separate, discussion. > >IDs are identifiers of elements of LFBs or structures. >The number of Selectors must either the same as the number of non-terminal >array types selected by the IDs, plus an additional optional selector if >the full ID list selects an array and a single element of the array is >being referenced rather than the whole array. > >A Selector is either a blk / range selector TLV or it is an index TLV >holding an unsigned integer, or it is a keying TLV holding a key >identifier and a DATARAW. > >The question of the interaction between blk selectors and the following >data element(s) is not fully resolved. It seems desirable to allow the >following two cases: > If a block selector is followed by a single DATA TLV, then the Data > (inner selection and/or value) is applied to each of the elements of > the block. > If a block selector is followed by a number of DATA TLVs equal to the > size of the block, then each DATA TLV corresponds to one element of > the block. >Do we need both of these? >Presumably, if the number is not 1 and does not match it is an error. > >Note that using two BLKINFO selectors relative to nested arrays is legal, >and should be defined to work, but is very prone to unexpected >results. (The number of elements that actually match the selector may not >be the same for different inner array occurrances.) > >Inner PATH-DATA will normally be used only when more than one item is >being selected. It allows the factoring out of the common >subexpressions. This may allow some efficiency in implementation and does >allow some efficiency in bits on the wire. > >Yours, >Joel M. Halpern > >At 03:42 AM 1/29/2005, Wang,Weiming wrote: >> > 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] From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 1 15:48:50 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 PAA18086 for ; Tue, 1 Feb 2005 15:48:50 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5FM-0004qW-Pf for forces-archive@IETF.ORG; Tue, 01 Feb 2005 16:07: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 <16.00F6767A@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 15:48:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56067086 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 15:48:42 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Feb 2005 15:47:32 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020112464095:42720 ; Tue, 1 Feb 2005 12:46:40 -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> <6.1.2.0.0.20050201093343.03aaae98@localhost> <6.1.2.0.0.20050201141927.03be54f8@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 02/01/2005 12:46:41 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/01/2005 12:46:44 PM, Serialize complete at 02/01/2005 12:46:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1107290847.1072.85.camel@jzny.localdomain> Date: Tue, 1 Feb 2005 15:47:27 -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: <6.1.2.0.0.20050201141927.03be54f8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Looks very good and resolves the table of tables issue i had. Should cover both what i need as well as Weimings IMO. I will run through all use cases later; and if we get an ACK from Weiming i will fixup the doc with this update. cheers, jamal On Tue, 2005-02-01 at 14:27, Joel M. Halpern wrote: > Following up on this, I have been batting an idea for the path / index / > key encoding back and forth. The following changes the PATH and Selector > encoding, with the goal of simplifying the common cases: > > There is one more variation that occurs to me. This is not what I sent to > the list, and has some advantages and disadvantages. Tell me what you think. > > Suppose we declare that block and content indexing can only be applied at > the end of a path. Given nesting, this does not restrict what can be > described, just where one has to split the TLVs. > Then, we declare that indexes are included in the path sequence. > > Suppose we take two flag bits, and declare the meanings as: > 00 last not a table (normal case), includes the case where the last > is an indexed selection of a table element. > 01 last is the entire table > 10 last is a block selection from the table. See BLK TLV > 11 last is a content keyed selection from the table, see KEY TLV > And the there is exactly one BLK or KEY TLV, and that is present only if > the bits are set. > (Arguably, the 01 combination is redundant, but the bits are available and > it provides clarity.) > > So, to select x1 from table2 entry 4 inside table1 entry 10 we would have > OPER TLV > PATH flag = 00, count = 5, IDS = 1.10.2.4.1 > as we would like. > > To select, from all table1s, the x1s of the 4the element of table2, we > would have > OPER TLV: (whatever operation is being performed > PATH-DATA TLV > flag = 01, count=1, IDS = 1 > PATH-DATA TLV > flag = 00, count=3, IDS = 2.4.1 > > To select an x2 based on the value of x1 (where x1 as a key has KeyID 1) > from the 10th element of table1, we would have > OPER TLV: (whatever operation is being performed) > PATH-DATA TLV > flag = 11, count = 3, IDS = 1.10.2 > KEYTLV, KEYID = 1, DATARAW = x1value > PATH-DATA TLV > flag = 00, count = 1, IDS = 2 (to select x2) > > > If we go with this, the syntax would become: > OPER TLV := + > PATH-DATA := [DATAINFO] > PATH := flags IDcount > DATAINFO := [SELECTOR] * > SELECTOR := BLKINFO | KEYINFO > DATA := DATARAW | + > KEYINFO := KeyID DATARAW > IDXINFO := uint32 > DATARAW := encoded data representing ForCES LFB information. > > Where IDs would include subscripts, and > SELECTOR would only occur if the flags indicated it should, and would only > apply to the table that would be the end of the PATH at the TLV > level. This would mean that nested PATH-DATA is used both for multiple > selection with common part extraction and for intermediate content keyed/ > block selection. > > Yours, > Joel > > At 09:52 AM 2/1/2005, Joel M. Halpern wrote: > >Since things went momentarily quiet, let me take a crack at what I think > >we have discussed. > > > >Weiming has asked for some efficiency in referencing related components. > >I have asked that we use unique, pre-declared keys. > >Jamal (and others I think) have asked for block operations. > >We are still discussing where index (subscript) values go. For this > >description, I am going to put them with content keys. > > I would really like to be able to put the common case of simple > > subscripts > > into the data path. This can be done using a flag if we restrict content > > keying to the leaf reference. As we do not have agreement on that, I am > > NOT including that in this description. > > > >I think that would give: > > > >OPER TLV := + > >PATH-DATA := [DATAINFO] > >PATH := flags IDcount > >DATAINFO := * * > >SELECTOR := BLKINFO | KEYINFO | IDXINFO > >DATA := DATARAW | + > >KEYINFO := KeyID DATARAW > >IDXINFO := uint32 > >DATARAW := encoded data representing ForCES LFB information. > > This can represent a simple value, a structure, a string, an array, > > or any other declared ForCES type. > > The questions of whether this is a packed representation, a TLV > > structure, or something else is a separable, and separate, discussion. > > > >IDs are identifiers of elements of LFBs or structures. > >The number of Selectors must either the same as the number of non-terminal > >array types selected by the IDs, plus an additional optional selector if > >the full ID list selects an array and a single element of the array is > >being referenced rather than the whole array. > > > >A Selector is either a blk / range selector TLV or it is an index TLV > >holding an unsigned integer, or it is a keying TLV holding a key > >identifier and a DATARAW. > > > >The question of the interaction between blk selectors and the following > >data element(s) is not fully resolved. It seems desirable to allow the > >following two cases: > > If a block selector is followed by a single DATA TLV, then the Data > > (inner selection and/or value) is applied to each of the elements of > > the block. > > If a block selector is followed by a number of DATA TLVs equal to the > > size of the block, then each DATA TLV corresponds to one element of > > the block. > >Do we need both of these? > >Presumably, if the number is not 1 and does not match it is an error. > > > >Note that using two BLKINFO selectors relative to nested arrays is legal, > >and should be defined to work, but is very prone to unexpected > >results. (The number of elements that actually match the selector may not > >be the same for different inner array occurrances.) > > > >Inner PATH-DATA will normally be used only when more than one item is > >being selected. It allows the factoring out of the common > >subexpressions. This may allow some efficiency in implementation and does > >allow some efficiency in bits on the wire. > > > >Yours, > >Joel M. Halpern > > > >At 03:42 AM 1/29/2005, Wang,Weiming wrote: > >> > 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] From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 1 23:44: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 XAA25555 for ; Tue, 1 Feb 2005 23:44:00 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCf5-00036S-Mo for forces-archive@IETF.ORG; Wed, 02 Feb 2005 00:02: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 <3.00F680C0@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 23:43:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56104936 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 23:43:39 -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, 31 Jan 2005 08:22:51 -0500 Received: from [219.82.185.143] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Mon, 31 Jan 2005 21:51:52 +0800 (CST) 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> <6.1.2.0.0.20050130114248.0643eec0@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: <001301c50798$68ecf3f0$020aa8c0@wwm1> Date: Mon, 31 Jan 2005 21:25:54 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [3]Re: path data textt update > I would ask at the same time whether you can live with a more restricted > form of content addressing. I actually agree that to use Key like restriction for allocating FE's searching ability would benifit FE implementation in some cases, as well as the protocol appearance, but what bother me a little when I think of it more, is: 1. seems a little redundant when we define the Keys. Still take an example as: table2: type array, ID = 4 elements are: j1, type u32, ID = 10 j2, type u32, ID = 20 Now, if we allow j1 and j2 as KEYs, then I suppose the KEY definition might become something like: table2: type array, ID = 4 Keys are: Key1, type u32, ID=1, Value=10 ; the Key1 value is the ID of j1 Key2, type u32, ID=2, Value=20 ; the Key2 value is the ID of j2 elements are: j1, type u32, ID = 10 j2, type u32, ID = 20 Then we can use following format to delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10 as: Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} KEYINFO = {KEYID =1 KEY_DATA=100} KEYINFO = {KEYID =2 KEY_DATA=200} To check the Key definitions above, I just have a feeling that it more or less shows a feeling of some repetitions, especially when in the cases where all fields might have to be set as Keys. 2. In the cases where Keys are more than more FieldIDs to represent, it may also makes the XML definition quite complex. For example, table2: type array, ID = 4 elements are: j1, struct SomeAdd, ID = 10 j2, type u32, ID = 20 where, struct SomeAdd { d1, type ... ID=1 d2, type ... ID=2 } Now we need to limit j1.d1 as the Key, then, the definition might become as: Key1, type u32, ID=1, Value=10.1 ; the Key1 value is the subpath of j1.d1 I'm just still not very clear if it's easy or not to have XML to do this work. I also noticed that you mentioned last time that it's may be impractical to use things like property of "Search allowed" "Search not allowed" for FieldID definitions, because above SomeAdd struct may be used by more than one LFBs. To summarize my views on the Key, I just think there may lay some details to address with the use of Key still, and if we can not find a better way for searching restriction and still think it is quite necessary, I then can live with the use of Key. Yours, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 1 23:44: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 XAA25575 for ; Tue, 1 Feb 2005 23:44:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCfJ-00036S-1O for forces-archive@IETF.ORG; Wed, 02 Feb 2005 00:02: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 <23.00F6812F@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 23:43:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56104964 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 23:43:54 -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, 31 Jan 2005 09:30:57 -0500 Received: from [219.82.185.143] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Mon, 31 Jan 2005 22:59:57 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> 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: <004d01c507a1$eb5b3780$020aa8c0@wwm1> Date: Mon, 31 Jan 2005 22:34:00 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Jamal, Pls allow me to reply your two posts in this one, because I see the focus is the same. ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Monday, January 31, 2005 4:05 AM Subject: Re: path data textt update > > KEYINFO does not set any value; it is merely describing how to search > and find what to delete. I see the points now. I think it is the Message Type and the Operation TLV Type together that will define "SET", "DELETE", or "QUERY"(which actually a find), rather than the operations will be implied by KEYINFO or SUBPATHINFO. When the command is "SET", the SUBPATH-DATA defines the the fields and the data to be set. When the command is a "DELETE" or "QUERY", the SUBPATH-DATA or the KEY-DATA can then be used as a content searching fields and matching data. Anyway, I think SUBPATH is only an expression instead of an operation, and a KEY is only a special field for searching. Come back to our former example again: > Path: IDCount = 1, IDs=4 > SELECTOR := > BLK_CNT_INDEX TLV = {10,10} > KEYINFO = {KEYID =1 KEY_DATA=100} > KEYINFO = {KEYID =2 KEY_DATA=200} I think your above expression actually fit for following table field definition: table2: type array, ID = 4 Keys are: Key1, type u32, ID=1, Value=10 ; the Key1 value is the ID of j1 Key2, type u32, ID=2, Value=20 ; the Key2 value is the ID of j2 elements are: j1, type u32, ID = 10 j2, type u32, ID = 20 Instead of: > table2: type array, ID = 4 > elements are: > j1, type u32, ID = 1 > j2, type u32, ID = 2 I'm afraid if you have a different understanding of KEY definition as: > table2: type array, ID = 4 > elements are: > j1, type u32, ID = 1, searchKey="YES", > j2, type u32, ID = 2, searchKey="YES", This was a method I ever proposed before, but just being pointed by Joel of some practical problem (when some fields may be globally defined, which makes it hard to do so). I'm quite sure that Joel's current Key idea is not as above. To use a subpath to define above operation to include the KEY is also possible, as: OpTLV Type="Delete" ; note this limits the followed subpath-data is not for setting values. Path: IDCount = 1, IDs=4 SELECTOR := BLK_CNT_INDEX TLV = {10,10} SUBPATHINFO TLV V = {IDcounts(1), IDs(1), Data(100)} ; here, ID=1 points to the Key1 field SUBPATHINFO TLV V = {IDcounts(1), IDs(2), Data(200)} ; here, ID=2 points to the Key2 field Apart from adding IDcounts, the format is actually identical to KEYINFO TLV. Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 00:05: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 AAA27370 for ; Wed, 2 Feb 2005 00:05:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwD0O-0003UT-TQ for forces-archive@IETF.ORG; Wed, 02 Feb 2005 00:24: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 <9.00F68130@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 0:05:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56107611 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 00:05:47 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 00:05:12 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8976377 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 00:05:11 -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> <6.1.2.0.0.20050130114248.0643eec0@localhost> <001301c50798$68ecf3f0$020aa8c0@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050201235457.065da878@localhost> Date: Wed, 2 Feb 2005 00:04:36 -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: <001301c50798$68ecf3f0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 A typical key declaration would be in the array declaration. For example, suppose we have structure foostruct ipv4address: id = 1, type = bytestring4 ipv4prefixlength: id = 2, type = integer 0..32 addressmatchclass: id = 3, type = int assoicatedinfo: id = 4, type = somestructure Then in some LFB we have an array declaration lfbtable: id = 1, array, variable, type = foostruct key akey: keyid = 1, ipv4address, ipv4prefixlength declares that the array has a key, made up of the ipv4 address and ipv4 prefix length. And the keyid for this key is 1 (The name akey is just for human consumption). If there is another unique field or field combination that can be used as a key, that would be an additional key line. Maybe somestruct has a entryid field, so we get key bkey: keyid = 2, associatedinfo.entryid assuming that entryids are unique. There is no need to declare the type of the key because the key is not a field distinct from those within the structure of the array element. Rather, the key is a declaration about information within that structure. Thus, when one finds a path that references lfbtable, with content keying, then if one finds keyid 1 in the keying TLV, the FE knows that the reference is to the ipv4address and prefix length, and that the data will be the combination of those two fields as if they were a structure. If the keyid in the TLV is 2, then the FE knows that the entryid is being used, and that the information is whatever type entryid was declared with. The use of the keyid in the array declaration means that in this array, the field or field combination declared as a key will never be duplicated across entries within the array. Does this make more sense? (Translating this into the XML is pretty easy, once we have agreed on the meaning.) Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 00:34: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 XAA25560 for ; Tue, 1 Feb 2005 23:44:00 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwCfI-00036S-MQ for forces-archive@IETF.ORG; Wed, 02 Feb 2005 00:02: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 <12.00F68104@cherry.ease.lsoft.com>; Tue, 1 Feb 2005 23:43:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56104954 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 1 Feb 2005 23:43:48 -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, 31 Jan 2005 08:40:34 -0500 Received: from [219.82.185.143] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Mon, 31 Jan 2005 22:09: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> <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> <1107114937.7840.56.camel@jzny.localdomain> 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: <002801c5079a$e46528c0$020aa8c0@wwm1> Date: Mon, 31 Jan 2005 21:43:42 +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.4 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: updated path data text > > 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? Maybe the word Enum is not so relevant, bu what I mean for ENUM_INDEX is for the descrete index expressions like: ENUM_INDEX TLV the Type = ENUM_INDEX_TLV the Value = {1, 3, 5, 7, 9} representing the index of 1,3,5,7,9. Jamal, I see your other remain comments relates to the other post, please allow me reply in the followed later post. Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 10:14: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 KAA14189 for ; Wed, 2 Feb 2005 10:14:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMVi-0001x7-6C for forces-archive@IETF.ORG; Wed, 02 Feb 2005 10:33: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 <2.00F68C61@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 10:14:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56180468 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 10:14:32 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 09:49:46 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8983206 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 09:49:46 -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> <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> <6.1.2.0.0.20050201093343.03aaae98@localhost> <6.1.2.0.0.20050201141927.03be54f8@localhost> <00c801c5092e$9a5c4110$020aa8c0@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050202094440.02b13460@localhost> Date: Wed, 2 Feb 2005 09:49:20 -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: <00c801c5092e$9a5c4110$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d For simplicity and generality, and to avoid accidentally limiting ourselves, my view is that field identifiers and table indexes should both be represented in 32 bit unsigned inttegers. If we were to leave subscripts separate from the path elements, we could argue that subscripts would be 32 bits, but field identifiers would be 16 bits. On the other hand, one can argue that it is easier to process the path components if they are 32 bits long. To put it differently, I would prefer to concentrate on whether the combined path is the right thing. If it is, then we can afford to use 32 bit field identifiers. If it is not right to combine them, then we can decide whether to use 16 or 32 bit field identifiers. Yours, Joel At 08:53 AM 2/2/2005, Weiming Wang wrote: >Joel, > >Before we decide how index is placed in the path, I have a related question to >ask first. I see that the bits for index may be different from that for >fields, >for index may probably range more than 64k, but fields may be enough with >32bits. I haven't followed the related discussions before, therefore, do >we have >any consensus on the bits for fields and indices? > >Yours, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 10:21: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 KAA15542 for ; Wed, 2 Feb 2005 10:21:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMbm-00027i-BX for forces-archive@IETF.ORG; Wed, 02 Feb 2005 10:40: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 <21.00F68B92@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 10:19:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56180784 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 10: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; Wed, 2 Feb 2005 10:12:50 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8983319 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 10:12:49 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050202094928.062d7e30@localhost> Date: Wed, 2 Feb 2005 10:12:18 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009701c5092b$ed6db1c0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 I think that there are only three operations at the moment: GET SET NOTIFY In terms of the format I presented, the structure of these operations is as follows. A GET request includes one or more base path TLVs and each may include one or more nested path TLVs. Each path TLV may include a KEY TLV for content selection, where the data in the key TLV is the value of the selected key field. A GET response will look like a GET request, with DATA filled in along with each terminal PATH TLV. A SET request include one or more base path TLVs each of which may include one or more nested path TLVs. Each Path TLV may include a KEY TLV to indicate which element of the table is being selected, where the data value in the KEY TLV represents a value being sought. Flags indicate what should happen if the selected entry (index or content selected) is not found. The flags can allow or prohibit creation of an entry that does not exist, and allow or prohibit modification of an entry that does exist. (The combination must not create and must not modify is not particularly useful.) Each terminal path TLV will also have a data block providing the information that is to be placed into the selected element. The selected element may be the whole item identified by a key. It may be a field in the structured identified by a key. There are a couple of interesting cases to be covered. 1) It would be nice to be able to say "create, and give me an index". This would be a case where no index and no key is provided, but a single element is being created. It would seem that we can cover this with the flags. The returned result will include the information as to what index was assigned to the value 2) Any create operation in a table must be checked by the FE logic to ensure that all key values of the new data content are unique in the table. This is a consequence of the requirement that keys be unique. This applies whether the create is using indexing or content keying to identify the new value. 3) Similarly, any modify operation that modifies a table key must be checked by the FE to ensure that uniqueness is met. 3') The corollary to the above is that swapping the key values between two entries may be a little tricky. If both SETs are in the same OPERATION TLV should we require the FE to be smart enough to realize that the values are unique after both changes? Or should we require that one of them get changed to an unused value first? 4) It is perfectly valid to specify a create operation for an entire entry in a table, and specify a key. Depending upon flag settings this will either ensure that the key is not used, or allow overwriting of the entry if it is already there. It is actually valid for the data being written to have a different (but still unique) key value. (It would probably only be useful in a modify operation.) Said another way, changing keys on entries is allowed as long as uniqueness is preserved. Yours, Joel PS: No, I did not talk about Notify. I expect it looks a lot like a GET response, but I have not thought about it much. At 08:34 AM 2/2/2005, Weiming Wang wrote: >Jamal, > >----- Original Message ----- >From: "Jamal Hadi Salim" >Subject: Re: path data textt update > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > Example: "replace all entries which match key1=10 with 1111" > > or "for all entries with KEY1=10.0.0.24/32, replace table.nh with value > > 3" > > > > I think these are valid operations - therefore search key needs to > > be represented separately from subpath and should not have dependence of > > what the msg type is. >I'm afraid You'v raised a very good point that we need to address >specifically, >that is, how a MODIFY/REPLACE operation will affect our current BNF. >Obviously a >MODIFY operation usually needs to include two data parts in the message: >the old >data(or condition), the new data. I now understand what you are trying is >to use >the KEY to specifically INDICATE it is the old data (or condition) part. I >understand more that this kind of INDICATE is actually realized by the type in >the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" is >specified for the old data (or condition) only. With this thought, I >suppose you >may also mean every field in an LFB attribute can be a KEY, because every >field >can probably be replaced/modified. > >As a result, I have to say yes, such KEYINFO TLV is necessary, or in another >word, should be separately expressed in BNF, but I also have to say the data >format for the KEYINFO TLV is actually the same as the general PATH-DATA >format, >that is, the KEYID there is actually a subpath instead of only a KeyID. > >Now come back to the KEY idea Joel proposed. I think a best way to say Joel's >idea is "not all subfields are allowed as searching indices". I'm sure >this kind >of Keys are only a subset of keys used in the KEYINFO TLV for MODIFY/REPLACE >operations, because as I mentioned above, we should allow all writable >fields in >an attributes replacable, though we not allow some fields as searching >indices. >As a result, to better solve this, I'm afraid we need to see how KEYINFO TLV >should actually be composed. My idea is, for MODIFY operations, the old >data (or >condition) part may include general subpath-data, as well as KEYs as Joel >proposed. > >I'm keeping thinking of this ... > >Cheers, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 10:38:37 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 KAA18066 for ; Wed, 2 Feb 2005 10:38:37 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMsu-0002mB-In for forces-archive@IETF.ORG; Wed, 02 Feb 2005 10:57: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 <11.00F68B8E@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 10:38:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56182994 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 10:38:38 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 10:37:50 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020207365985:45921 ; Wed, 2 Feb 2005 07:36:59 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$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 02/02/2005 07:37:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/02/2005 07:37:02 AM, Serialize complete at 02/02/2005 07:37:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1107358666.1074.21.camel@jzny.localdomain> Date: Wed, 2 Feb 2005 10:37:46 -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: Weiming Wang Comments: cc: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009701c5092b$ed6db1c0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:34, Weiming Wang wrote: > Jamal, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: path data textt update > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > Example: "replace all entries which match key1=10 with 1111" > > or "for all entries with KEY1=10.0.0.24/32, replace table.nh with value > > 3" > > > > I think these are valid operations - therefore search key needs to > > be represented separately from subpath and should not have dependence of > > what the msg type is. > I'm afraid You'v raised a very good point that we need to address specifically, > that is, how a MODIFY/REPLACE operation will affect our current BNF. Obviously a > MODIFY operation usually needs to include two data parts in the message: the old > data(or condition), the new data. I now understand what you are trying is to use > the KEY to specifically INDICATE it is the old data (or condition) part. I > understand more that this kind of INDICATE is actually realized by the type in > the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" is > specified for the old data (or condition) only. Indeed. The selector is essentialy a set of *filters* to refine the path towards the data. - field and index dont require any extra computation i.e the map reads "go left, turn right, go left and at the stop sign is where the treasure is found" vs - keyinfo requires computation at the FE to draw the map i.e "go left onto the freeway, every time you see a green sign reading Weiming turn left to get to the treasure repeat this until you see a red sign which reads Joel" We are saying the selector can have both path filters. We are also restricting what keys(green, red) can be used. > With this thought, I suppose you > may also mean every field in an LFB attribute can be a KEY, because every field > can probably be replaced/modified. > Well, thats where we started ;-> But since keyinfo is now restricted to a few things in the LFB .. This is why i asked you in one email if you changed your position ;-> > As a result, I have to say yes, such KEYINFO TLV is necessary, or in another > word, should be separately expressed in BNF, but I also have to say the data > format for the KEYINFO TLV is actually the same as the general PATH-DATA format, > that is, the KEYID there is actually a subpath instead of only a KeyID. > But then i see this as a contradiction with key restriction. Of course it could be done, all you would need is the flag to say "this subpath is a search"; > Now come back to the KEY idea Joel proposed. I think a best way to say Joel's > idea is "not all subfields are allowed as searching indices". I'm sure this kind > of Keys are only a subset of keys used in the KEYINFO TLV for MODIFY/REPLACE > operations, because as I mentioned above, we should allow all writable fields in > an attributes replacable, though we not allow some fields as searching indices. > As a result, to better solve this, I'm afraid we need to see how KEYINFO TLV > should actually be composed. My idea is, for MODIFY operations, the old data (or > condition) part may include general subpath-data, as well as KEYs as Joel > proposed. > Joel? cheers, jamal > I'm keeping thinking of this ... > > Cheers, > Weiming > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 11:00: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 LAA20869 for ; Wed, 2 Feb 2005 11:00:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNEN-0003XV-Lt for forces-archive@IETF.ORG; Wed, 02 Feb 2005 11:19: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 <2.00F68D80@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 11:00:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56188517 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 11:00:31 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 10:43:11 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8983527 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 10:43:10 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <1107358666.1074.21.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20050202104013.06487630@localhost> Date: Wed, 2 Feb 2005 10:42:31 -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: <1107358666.1074.21.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 I think there are two very separate questions. Structurally, all fields need to be writeable. (Certain LFB definitions may make some fields read only, and some implementations may make additional fields read only, but that is handled by capabilities and errors, not by protocol structures.) However, "searching" (key fields) needs to be carefully restricted. "Searches" must match 0 or 1 element (keys must be unique) and both the CE and the FE must know what is expected with regard to supported keys (predeclaration, plus possibly some capability information.) Yours, Joel At 10:37 AM 2/2/2005, Jamal Hadi Salim wrote: > > Now come back to the KEY idea Joel proposed. I think a best way to say > Joel's > > idea is "not all subfields are allowed as searching indices". I'm sure > this kind > > of Keys are only a subset of keys used in the KEYINFO TLV for > MODIFY/REPLACE > > operations, because as I mentioned above, we should allow all writable > fields in > > an attributes replacable, though we not allow some fields as searching > indices. > > As a result, to better solve this, I'm afraid we need to see how > KEYINFO TLV > > should actually be composed. My idea is, for MODIFY operations, the old > data (or > > condition) part may include general subpath-data, as well as KEYs as Joel > > proposed. > > > >Joel? From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 11:16: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 LAA23001 for ; Wed, 2 Feb 2005 11:16:21 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNTR-00044v-R8 for forces-archive@IETF.ORG; Wed, 02 Feb 2005 11:35: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 <4.00F68D2D@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 11:16:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56190715 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 11:16:17 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 11:15: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 2005020208150452:46023 ; Wed, 2 Feb 2005 08:15:04 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@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 02/02/2005 08:15:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/02/2005 08:15:06 AM, Serialize complete at 02/02/2005 08:15:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1107360951.1073.57.camel@jzny.localdomain> Date: Wed, 2 Feb 2005 11:15:51 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050202094928.062d7e30@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 10:12, Joel M. Halpern wrote: > I think that there are only three operations at the moment: > GET > SET > NOTIFY > > In terms of the format I presented, the structure of these operations is as > follows. > A GET request includes one or more base path TLVs and each may include one > or more nested path TLVs. Each path TLV may include a KEY TLV for content > selection, where the data in the key TLV is the value of the selected key > field. > A GET response will look like a GET request, with DATA filled in along with > each terminal PATH TLV. Whatever the dump coming back is, it should be a syntacticaly legit SETable view. i.e i should be able to s/GET/SET and have valid format that i can shove at the FE. > A SET request include one or more base path TLVs each of which may include > one or more nested path TLVs. Each Path TLV may include a KEY TLV to > indicate which element of the table is being selected, where the data value > in the KEY TLV represents a value being sought. Flags indicate what should > happen if the selected entry (index or content selected) is not found. The > flags can allow or prohibit creation of an entry that does not exist, and > allow or prohibit modification of an entry that does exist. (The > combination must not create and must not modify is not particularly useful.) > Each terminal path TLV will also have a data block providing the > information that is to be placed into the selected element. Should be noted that given an LFB definition, a receiver of a path - once derived(eg computed from content key) should be able to decode/encode data to such a path target. Wasnt sure if "terminal" would be the right term in this case since it could be a full tree at the hierachy root (example table)or a leaf (example a cell in a table). Maybe a "path target" would be more descriptive. > The selected element may be the whole item identified by a key. It may be > a field in the structured identified by a key. > > There are a couple of interesting cases to be covered. > 1) It would be nice to be able to say "create, and give me an index". This > would be a case where no index and no key is provided, but a single element > is being created. IMO, This should be possible with current grammar. If you create entry at a table for example, you dont need to specify the IDXINFO.i.e path is tableid. FE gives you the next available Index > It would seem that we can cover this with the > flags. The returned result will include the information as to what index > was assigned to the value We do have flags in the main header already that cover this. You can ask for a brief response back (which will just give you an ACK) or a verbose response which will give you things like the full created info. Unless you want to refine this further and move it to the operation flags. > 2) Any create operation in a table must be checked by the FE logic to > ensure that all key values of the new data content are unique in the > table. This is a consequence of the requirement that keys be unique. This > applies whether the create is using indexing or content keying to identify > the new value. I would say this is a necessary part of boundary/error checking. Any implementation that doesnt check for bounds is problematic - i wouldnt call it a interop issue. > 3) Similarly, any modify operation that modifies a table key must be > checked by the FE to ensure that uniqueness is met. > > 3') The corollary to the above is that swapping the key values between two > entries may be a little tricky. If both SETs are in the same OPERATION TLV > should we require the FE to be smart enough to realize that the values are > unique after both changes? Or should we require that one of them get > changed to an unused value first? > Not sure i followed this one: Are we talking atomic transactions? If they are independent transactions, why care? > 4) It is perfectly valid to specify a create operation for an entire entry > in a table, and specify a key. Depending upon flag settings this will > either ensure that the key is not used, or allow overwriting of the entry > if it is already there. It is actually valid for the data being written to > have a different (but still unique) key value. (It would probably only be > useful in a modify operation.) Said another way, changing keys on entries > is allowed as long as uniqueness is preserved. > You have a path and a selector. Together they tell you how to get to the data. Why would you want to introduce information that is not used? In the case of content based table, the KEYINFO will refine which entry is of interest and the DATA will overwrite the key value in the table if needed. Theres another one: In some cases it may not make sense to create. Example - you can modify a table cell but you cant create it --> it has to exist. Its existence is dependent on a row being created first. The other approach would be to intepret the creation of the cell as an implict creation of the row. I prefer the former because it simplifies the logic. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 12:30: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 MAA02562 for ; Wed, 2 Feb 2005 12:30:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOdE-0006el-4V for forces-archive@IETF.ORG; Wed, 02 Feb 2005 12:49: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 <0.00F6901F@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 12:30:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56197100 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 12:30:30 -0500 Approved-By: alistair.munro@U4EATECH.COM Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 12:29:27 -0500 Received: from ncs.bris.ac.uk ([137.222.10.36]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1CwOJd-000370-Vw for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 17:29:27 +0000 Received: from een9169.een.bris.ac.uk ([137.222.189.169]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1CwOJd-00079U-4y for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 17:29:21 +0000 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:018WmCWVbO480pqvvDH1fPr8Ipy/h8MWPfsLsu0/t9H1SX98Q=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Message-ID: <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> Date: Wed, 2 Feb 2005 17:29:20 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107360951.1073.57.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi All, >> I think that there are only three operations at the moment: >> GET >> SET >> NOTIFY >> .... > Whatever the dump coming back is, it should be a syntacticaly legit > SETable view. i.e i should be able to s/GET/SET and have valid format > that i can shove at the FE. I would like to see this. Do we not need sequence( or request/action?) ids and stuff like that per operation to accommodate timeouts and FE failures/refusals, and link transactions across multiple FEs? Apologies if I missed this but the path data exchange got a bit involved and I nodded off. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 12:53: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 MAA05402 for ; Wed, 2 Feb 2005 12:53:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOzD-0007Pt-AY for forces-archive@IETF.ORG; Wed, 02 Feb 2005 13:12: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 <1.00F68F54@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 12:53:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56198967 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 12:53: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, 2 Feb 2005 12:52: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 2005020209520317:46374 ; Wed, 2 Feb 2005 09:52:03 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> 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 02/02/2005 09:52:03 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/02/2005 09:52:05 AM, Serialize complete at 02/02/2005 09:52:05 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1107366770.1074.87.camel@jzny.localdomain> Date: Wed, 2 Feb 2005 12:52:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Alistair, On Wed, 2005-02-02 at 12:29, Alistair Munro wrote: > Do we not need sequence( or request/action?) ids and stuff like that per > operation to accommodate timeouts and FE failures/refusals, and link > transactions across multiple FEs? Apologies if I missed this but the path > data exchange got a bit involved and I nodded off. > The main header's seq number is intended to cover the transaction of all operations within a message. I would say the combo of the FEID+LFBID+instanceID+sequence number should provide sufficient corelation data to maintain state and handle atomicity of a transaction across FEs. At least for unicast FEID it is. For Multi/Broadcast FEIDs an extra state corelation in my opinion would need to be maintained at the CE LFB level. Not sure if i am on target for what you were asking. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 2 13:03: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 NAA06570 for ; Wed, 2 Feb 2005 13:03:31 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwP8t-0007mP-SN for forces-archive@IETF.ORG; Wed, 02 Feb 2005 13:22: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 <12.00F6901D@cherry.ease.lsoft.com>; Wed, 2 Feb 2005 13:03:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56201105 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 2 Feb 2005 13:03:08 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 2 Feb 2005 12:43:32 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8985452 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 02 Feb 2005 12:43:31 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.2.0.14.0.20050202123716.030ff900@localhost> Date: Wed, 2 Feb 2005 12:42:56 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 All we are saying here (assuming the simple case where there are no errors) is that we start with a GET operation TLV. It contains a collection of PATH-DATA TLVs that identify items of interest. we get a GET-RESPONSE operation TLV. It contains a collection of PATH-DATA TLVs for those same items, which include the actual data that was request. The arrangement of the PATH-DATA TLVs and the data within them is such that if you replace the GET-RESPONSE code with a SET code, the contents of the GET-RESPONSE are valid contents for a SET request to set the identified items to the values that they had. (Of course, if you do it immediately nothing will happen since those are the values. But if you changed things, and then did the set, you would get what you expect.) The are caveats o course. Some of the elements may not be writeable. If content keying is used and keys have changed, then there may be no targets for some sets. Jamal's point was not that it must always work, but rather that syntactically the structure should be the same. Which it should. And which I believe it is with the structure we are discussing. Yours, Joel At 12:29 PM 2/2/2005, Alistair Munro wrote: >Hi All, > >>>I think that there are only three operations at the moment: >>>GET >>>SET >>>NOTIFY >.... >>Whatever the dump coming back is, it should be a syntacticaly legit >>SETable view. i.e i should be able to s/GET/SET and have valid format >>that i can shove at the FE. > >I would like to see this. > >Do we not need sequence( or request/action?) ids and stuff like that per >operation to accommodate timeouts and FE failures/refusals, and link >transactions across multiple FEs? Apologies if I missed this but the path >data exchange got a bit involved and I nodded off. > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 3 08:40: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 IAA21695 for ; Thu, 3 Feb 2005 08:40:18 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwhW6-000688-60 for forces-archive@IETF.ORG; Thu, 03 Feb 2005 08:59: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 <19.00F6A578@cherry.ease.lsoft.com>; Thu, 3 Feb 2005 8:40:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56313352 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 3 Feb 2005 08:40:15 -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, 2 Feb 2005 08:31:30 -0500 Received: from [219.82.182.177] by 202.96.99.56 with StormMail ESMTP id 6322.3606408285; Wed, 2 Feb 2005 22:00:49 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> 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: <009701c5092b$ed6db1c0$020aa8c0@wwm1> Date: Wed, 2 Feb 2005 21:34:25 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: path data textt update Comments: To: hadi@znyx.com, joel@STEVECROCKER.COM To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: path data textt update > > What about SET | REPLACE? This is not DEL or QUERY .... > Example: "replace all entries which match key1=10 with 1111" > or "for all entries with KEY1=10.0.0.24/32, replace table.nh with value > 3" > > I think these are valid operations - therefore search key needs to > be represented separately from subpath and should not have dependence of > what the msg type is. I'm afraid You'v raised a very good point that we need to address specifically, that is, how a MODIFY/REPLACE operation will affect our current BNF. Obviously a MODIFY operation usually needs to include two data parts in the message: the old data(or condition), the new data. I now understand what you are trying is to use the KEY to specifically INDICATE it is the old data (or condition) part. I understand more that this kind of INDICATE is actually realized by the type in the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" is specified for the old data (or condition) only. With this thought, I suppose you may also mean every field in an LFB attribute can be a KEY, because every field can probably be replaced/modified. As a result, I have to say yes, such KEYINFO TLV is necessary, or in another word, should be separately expressed in BNF, but I also have to say the data format for the KEYINFO TLV is actually the same as the general PATH-DATA format, that is, the KEYID there is actually a subpath instead of only a KeyID. Now come back to the KEY idea Joel proposed. I think a best way to say Joel's idea is "not all subfields are allowed as searching indices". I'm sure this kind of Keys are only a subset of keys used in the KEYINFO TLV for MODIFY/REPLACE operations, because as I mentioned above, we should allow all writable fields in an attributes replacable, though we not allow some fields as searching indices. As a result, to better solve this, I'm afraid we need to see how KEYINFO TLV should actually be composed. My idea is, for MODIFY operations, the old data (or condition) part may include general subpath-data, as well as KEYs as Joel proposed. I'm keeping thinking of this ... Cheers, Weiming From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Thu Feb 3 22:40:25 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 WAA27740 for ; Thu, 3 Feb 2005 22:40:25 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwudF-0002Ve-Mn for forces-archive@IETF.ORG; Thu, 03 Feb 2005 22:59:46 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F6B74C@cherry.ease.lsoft.com>; Thu, 3 Feb 2005 22:40:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56391663 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 3 Feb 2005 22:40:23 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 3 Feb 2005 22:40:23 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020319392715:56549 ; Thu, 3 Feb 2005 19:39:27 -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 02/03/2005 07:39:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/03/2005 07:39:34 PM, Serialize complete at 02/03/2005 07:39:34 PM Content-Type: multipart/mixed; boundary="=-i2zX/FgWIay6XFkyj+mf" Approved-By: Jamal Hadi Salim Message-ID: <1107488414.1072.9.camel@jzny.localdomain> Date: Thu, 3 Feb 2005 22:40:14 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: more updates to path-data text To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d1013c8bad83fa4e4ccb34a7376b19d5 --=-i2zX/FgWIay6XFkyj+mf Content-Type: text/plain Content-Transfer-Encoding: 7bit More updates. Joel, Look at examples 6-9; there may be some lack of clarity still. $Log: data_path2.txt,v $ Revision 1.9 2005/02/03 22:35:49 hadi rearranged text and redid the use cases to match changed BNF Revision 1.8 2005/02/02 20:19:10 hadi incorporating Joels text and Weimings input cheers, jamal --=-i2zX/FgWIay6XFkyj+mf 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 desire to speed up the path-data discussion up. NOTE: By the time we get to the path-data part of the message we already know what the FE, LFB and instance of LFB being referenced is. 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] 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) Atomicity for operations is defined in the main header flags. 4) verbosity needed in response is defined in main headers flags. Terminology ----------- Add details of different terms here (example terminal, path target etc) A possible path-data layout. ---------------------------- The BNF used here is conformant to the syntax used by the DIAMTER protocol. i.e i ) A TLV will have the word "TLV" following it ii) <> encloses a _mandatory_ component iii) [] encloses an optional component iv) + implies "one or more" v) Missing <> or [] implies a literal/terminal TODO: Fix this later to conform to the ABNF described in RFC 2234. OPER TLV : = + PATH-DATA TLV := [DATAINFO] PATH := flags IDcount IDs DATAINFO := [SELECTOR] [DATA] SELECTOR := [BLKINFO] | [KEYINFO] DATA := [DATARAW] | + KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] DATARAW TLV := encoded data which may nest DATARAW TLVs TODO: Fix this grammar so it matches the RFC 2234 ABNF style description -> PATH: The path to the data being referenced -> flags (16 bits) are used to further refine the operation to be applied on the Path. More on these later. -> IDcount(16 bit): count of 32 bit IDs -> IDs: one or more 32bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. -> DATAINFO Optional piece that selects the path further and may optionaly contain DATA if needed by the operation. As an example a GET or DEL may not have DATA. -> SELECTOR is an optional construct that further defines the PATH. The presence of a selector is dependent on the PATH IDs and the flags. The PATH would point to a table and the flags would define what selector follows (one of BLKINFO or KEYINFO). Refer to flags description further below. -> DATA may contain DATARAW or further PATH-DATA selection -> DATARAW contains "the data" whose path is selected. DATARAW --------- This data is packed in such a way that a receiver of such data with knowledge of the path can correlate what it means by infering in the LFB definition. This is an optimization that helps packing the data. In other words: "It is assumed that the type of the data can be inferred by the context in which data is used. Hence, data will not include its type information. The basis for the inference is typically the LFB class id and the path." OPEN ISSUE: There is another view of how DATA should be represented posted a while back by Zsolt/Steve. We need to review it and compare against the scheme described here. The criteria is a) efficiency of encoding b)efficiency of parsing and decoding and c) the packaging overhead. DATA PACKING RULEs The scheme used in this doc adheres to the following rules: a)The Value of DATARAW TLV will contain the data being transported. This data will be as was described in the LFB definition. b) By definition in the Forces protocol, all TLVs are 32 bit aligned. Therefore because DATARAW is a TLV, elements not aligned in 32 bit values will be padded. As an example a 16 bit value will have an extra 16 bit pad; however two 16 bits values in a structure will be shipped together with no padding etc. c) Variable sized data will be encapsulated inside another DATARAW TLV inside the V of the outer TLV. For example of this see use case #13. d) When a table is refered in the PATH (ids), then the RAWDATA's V will contain that tables row content prefixed by its 32 bit index/subscript OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing to a row in table; in such a case, the RAWDATA's V will only contain the content sans the index in order to avoid ambiguity. flags ----- NOTE: got rid of exclusivity flag based on discussions with Joel. I) SELECTOR Bits Two bits are reserved for selecting what follows the path and refines it. This could be either BLKINFO or KEYINFO. -->00: indicates absence of the selector -->01(F_SELTAB): indicates what follows is a table. The path should be sufficient to point to a table; so this flag is redundant but here for completion sake -->10(F_SELBLK): indicates that what follows is a BLKINFO -->11(F_SELKEY): Indicates what follows is a KEYINFO II) OPERATION Bits --> 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. OPEN!! Controvesial, still under investigation flags: --> F_APPEND Add to the end of the object list/table. This could create xplicates (i.e dup/triplicates etc) --> F_PREPEND Add as the first entry in a table. This could create xplicates (i.e dup/triplicates etc) Relation of operational flags with global message flags: --------------------------------------------------------- Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. 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*(CNT of indices) Content path selection --------------------- The KEY_INFO TLV will describe the KEY as well as associated KEY data. KEYs used for content searches are restricted and described in the LFB definition. The use cases below show some sample operations. 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 KEY: nhkey, ID = 1, V = t2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 KEY: akey, ID = 1, V = { j1,j2 } 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 KEY: mykey, ID = 1, V = { j1} table5: type array, ID = 7 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements { x1: ID 1, x2: ID2 } KEY: tkey, ID = 1, V = { x1} TODO: DRAW a sample diagram of a table that shows rows and columns since that seems to have caused confusion All examples will show an attribute suffixed with "v" or "val" to indicate the value of the referenced attribute. example for attribute foo2, foo1v or foo1value will indicate the value of foo1. TODO: FIXME - Some examples show results while others dont - Some examples show operations in hierachy others dont 1) To get foo1 OPER = GET Path-data TLV: IDCount = 1, IDs = 1 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 1 DATARAW TLV L = 8, V = foo1v 2) to set foo2 to 10 OPER = SET Path-data TLV: flags = F_REPLACE, IDCount = 1, IDs = 2 DATARAW 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) OPER = GET Path-data TLV: IDCount = 1, IDs = 4 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 4 DATARAW TLV: L = XXX, V= a series of: index, j1value,j2value entries 4) Block operations To create entry 0-5 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) 5) Block operations (with holes) To replace entry 0,2 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_REPLACE | F_SELBLK , IDCount = 1, IDs=4 BLK_LIST_INDEX TLV, L = XXX V = 0,2 DATARAW TLV, Length = XXX, V = j1value,j2value j1value,j2value 6) Getting rows To get first entry of table2 OPER = GET Path-data TLV: IDCount = 2, IDs=4.0 Result: Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV, Length = XXX 0, j1value,j2value Another valid response is: Path-data TLV: IDCount = 2, IDs=4.0 DATARAW TLV, Length = XXX, V = j1value,j2value entry 7) to get entry 0-5 of table2 using BLK operations OPER = GET Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 TBD: What to do when say entry 1 doesnt exist? Assuming all of entries 0-5 available Result: Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) 8) Create a row in table2, index 5 OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK, IDCount = 1, IDs=4 BLK_LIST_INDEX TLV V = 5 DATARAW TLV, Length = XXX j1value,j2value QUESTION: Would it have been fair instead to say: flags = F_CREATE, IDCount = 1, IDs=4.5 DATARAW TLV, Length = XXX j1value,j2value OR: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX 5, j1value,j2value 9) an example of "create and give me an index" Assuming we asked for verbose response back. Talk to Joel, i think we need a flag "need IDX" OPER = SET Path-data TLV: flags = F_NEEDIDX, F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX j1value,j2value Result OPER = SET Path-data TLV: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX index, j1value,j2value 10) Dump contents of table1, OPER = GET Path-data TLV: IDCount = 1, IDs=3 Result: Path-data TLV IDCount = 1, IDs=3 DATARAW TLV, Length = XXXX index, t1value, t2value . . 11) get _all_ entries for table4 where j1=100 Assuming j1 is an accepted key and its keyid is 1 OPER = GET Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO TLV = {KEYID =1 KEY_DATA=100} Result: Path-data TLV: IDCount = 1, IDs=6 DATARAW TLV, Length = XXXX index, j1value,j2value index, j1value,j2value index, j1value,j2value 12) delete first 10 entries with j1=100, and j2=200 in table 2, starting at index 10. OPER = DEL Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Path-data TLV: flags = F_SELBLK IDCount = 1, IDs=4 BLK_CNT_INDEX TLV start = 10 count = 10 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-data TLV: IDCount = 1, IDs=4 DATARAW TLV, Length = XXXX index,j1value,j2value index,j1value,j2value index,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. OPER = GET Path-data TLV: IDCount = 1, IDs=5 Result: Path-data TLV: IDCount = 1, IDs=5 DATARAW TLV, Length = XXXX index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev . . . 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. OPER = SET Path-TLV: flags = F_CREATE, IDCount = 2, IDs=4.20 DATARAW TLV, V= j1value,j2value // Operation 2: Update table1 entries which // were pointing to t2 = 10 to now point to 20 OPER = SET Path-data TLV: flags = F_REPLACE | F_SELKEY, IDCount = 1, IDs=3 KEYINFO = {KEYID = 1 KEY_DATA=10} DATARAW TLV, V= 20 Result: //first operation, SET OPER = SET Path-data TLV IDCount = 1, IDs=4 DATARAW TLV, V = 20,j1value,j2value //second opertion SET - assuming 3 entries were updated OPER = SET Path-data TLV IDCount = 1, IDs=3 // assuming 16, 36,95 were set DATARAW TLV, Length = XXXX 16,t1value, 20 36,t1value, 20 95,t1value, 20 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-data TLV Flags = F_SELBLK, IDCount = 1, IDs=6 // select the rows BLK_LIST_INDEX, L = XXX V = {1,3,5,7,9} // select individual columns and set Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {100} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=2 DATARAW TLV: L=XXXX, V = {200} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=3 DATARAW TLV: L=XXXX, V = {300} 16) Table of table examples a) to get x1 from table10 row with index 4, inside table5 entry 10 we would have: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 Results: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 DATARAW TLV: L=XXXX, V = {x1 value} b) from all table5's rows, get the x1s of the 4th element of their table10 operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 Results: operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 DATARAW TLV: L=XXXX, V = {x1 values} Note that the length of the DATARAW TLV will tell how many x1 entries are there (assuming we know what the size of each x1 is) c) from table5's row 10 table10, get X2s based on on the value of x1 equlaing 10 (recal x1 is KeyID 1) operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 //select x2 Results: operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 DATARAW TLV: L=XXXX, V = {x2 values} Note that the length of the DATARAW TLV will tell how many x2 entries are there (assuming we know what the size of each x2 is) $Log: data_path2.txt,v $ Revision 1.9 2005/02/04 22:35:49 hadi rearranged text and redid the use cases to match changed BNF Revision 1.8 2005/02/02 20:19:10 hadi incorporating Joels text and Weimings input 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 --=-i2zX/FgWIay6XFkyj+mf-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 3 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 XAA01169 for ; Thu, 3 Feb 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 1CwvLC-0003kA-Nm for forces-archive@IETF.ORG; Thu, 03 Feb 2005 23:45: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 <2.00F6BA71@cherry.ease.lsoft.com>; Thu, 3 Feb 2005 23:25:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56395371 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 3 Feb 2005 23:25:43 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 3 Feb 2005 23:25:43 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9007962 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 03 Feb 2005 23:25:43 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1107488414.1072.9.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050203231303.0317aa70@localhost> Date: Thu, 3 Feb 2005 23:25:22 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: more updates to path-data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107488414.1072.9.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I think the second response in example 6 is the correct one. The first response would be a response to getting all of table2, when it only had a row at index 0 and nothing else. The difference is that if one SETs the table with the first response, one will throw away all the other rows. If one SETs the table with the second response, one SETs the correct entry. Of the three alternatives listed in example 8, the first and second are both correct. I actually prefer the second, but I believe the protocol should allow both. (As discussed above, the third alternative would mean "reduce the entire table to a single row at index 5, with the specified vale." While occasionally useful, that is not what was intended. I am not sure if 9 "needs" a NEEDIDX flag, but I would like it to have one. For examples 4 and 7, what you describe seems correct. I was wondering if as a tradeoff of clarity for slightly reduced efficiency we should use 6 DATARAW TLVs? Redundancy warning: As we have discussed, but not resolved, I believe example 11 will return exactly 1 entry, and the text for example 12 describes something that can not happen. (I think that the message shown for example 12 actually references the 10 elements starting at index 10 of the inner table with ID4 inside table2. Debating how to represent what the text describes is only useful if we decide that keys are not unique and therefore the described case can occur.) Thanks, Joel At 10:40 PM 2/3/2005, Jamal Hadi Salim wrote: >More updates. Joel, Look at examples 6-9; there may be some lack >of clarity still. > >$Log: data_path2.txt,v $ >Revision 1.9 2005/02/03 22:35:49 hadi >rearranged text and redid the use cases to match >changed BNF > >Revision 1.8 2005/02/02 20:19:10 hadi >incorporating Joels text and Weimings input > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 4 09:04: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 JAA28148 for ; Fri, 4 Feb 2005 09:04:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx4NE-0002FD-Hl for forces-archive@IETF.ORG; Fri, 04 Feb 2005 09:23: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 <9.00F6C401@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 9:04:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56460187 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 09:04:24 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 09:04:24 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020406033316:57646 ; Fri, 4 Feb 2005 06:03:33 -0800 References: <1107488414.1072.9.camel@jzny.localdomain> <6.2.0.14.0.20050203231303.0317aa70@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 02/04/2005 06:03:33 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/04/2005 06:03:35 AM, Serialize complete at 02/04/2005 06:03:35 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107525860.1948.32.camel@jzny.localdomain> Date: Fri, 4 Feb 2005 09:04:21 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: more updates to path-data text To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050203231303.0317aa70@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit On Thu, 2005-02-03 at 23:25, Joel M. Halpern wrote: > I think the second response in example 6 is the correct one. The first > response would be a response to getting all of table2, when it only had a > row at index 0 and nothing else. > The difference is that if one SETs the table with the first response, one > will throw away all the other rows. If one SETs the table with the second > response, one SETs the correct entry. This makes sense; fixed. > Of the three alternatives listed in example 8, the first and second are > both correct. I actually prefer the second, but I believe the protocol > should allow both. (As discussed above, the third alternative would mean > "reduce the entire table to a single row at index 5, with the specified > vale." While occasionally useful, that is not what was intended. I left those two for illustration purposes but deleted the one. > I am not sure if 9 "needs" a NEEDIDX flag, but I would like it to have one. Hrm, you are right - and its actually a point i made in an earlier mail ;-> Too tired when i was typing that text in. I think the NEEDIDX would help give a quick hint .. but is not totaly necessary. Add it? > For examples 4 and 7, what you describe seems correct. I was wondering if > as a tradeoff of clarity for slightly reduced efficiency we should use 6 > DATARAW TLVs? > While 6 DATARAWs would be valid, isnt the following both legit and efficient (in packing and parsing effort)? Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV: L = XXX, V= 0,j1value,j2value 1,j1value,j2value 2,j1value,j2value 3,j1value,j2value 4,j1value,j2value 5,j1value,j2value L will tell you how many rows you have packed. > > Redundancy warning: > As we have discussed, but not resolved, I believe example 11 will > return exactly 1 entry, I didnt follow; there was a small mistake - it should read: ------ 11) get _all_ row entries from table4 where j1=100 OPER = GET Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO TLV = {KEYID =1 KEY_DATA=100} Result: Path-data TLV: IDCount = 1, IDs=6 DATARAW TLV, Length = XXXX index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value ------- note j1 KEYID 1 for table 4. i used j1 and j2 in two tables - may have created confusion. > and the text for example 12 describes something > that can not happen. (I think that the message shown for example 12 > actually references the 10 elements starting at index 10 of the inner table > with ID4 inside table2. ;-> Agreed since we show start and end of TLVs visually. > Debating how to represent what the text describes > is only useful if we decide that keys are not unique and therefore the > described case can occur.) Would representing the text as below serve better to express the need to use the two selectors to zone on the data of interest? ------- 12) delete first 10 row entries with KEY match (j1=100, j2=200) in table 2, starting at index 10. OPER = DEL Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Path-data TLV: flags = F_SELBLK IDCount = 1, IDs=4 BLK_CNT_INDEX TLV start = 10 count = 10 Result: This assumes we have asked for the full results back in the main header. Assuming we deleted 3 at indeces 11, 13, and 18. Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV, Length = XXXX 11,j1value,j2value 13,j1value,j2value 18,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 -------- cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 4 12:16: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 MAA15683 for ; Fri, 4 Feb 2005 12:16:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7Mk-0006rO-Ou for forces-archive@IETF.ORG; Fri, 04 Feb 2005 12:35: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 <19.00F6C76E@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 12:16:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56480868 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 12:16:05 -0500 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 12:16:04 -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 j14HG4lI125638 for ; Fri, 4 Feb 2005 17:16:04 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j14HG4pX106290 for ; Fri, 4 Feb 2005 17:16:04 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j14HG4wp023145 for ; Fri, 4 Feb 2005 17:16:04 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j14HG3BJ023129 for ; Fri, 4 Feb 2005 17:16:03 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 SAA41468 for ; Fri, 4 Feb 2005 18:16:03 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.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> <6.1.2.0.0.20050130114248.0643eec0@localhost> <001301c50798$68ecf3f0$020aa8c0@wwm1> <6.1.2.0.0.20050201235457.065da878@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Robert Haas Message-ID: <4203ADCF.4070908@zurich.ibm.com> Date: Fri, 4 Feb 2005 18:15:59 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [3]Re: path data textt update To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050201235457.065da878@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Joel M. Halpern wrote: > > > The use of the keyid in the array declaration means that in this > array, the field or field combination declared as a key will never be > duplicated across entries within the array. > I'd argue against forcing the uniqueness of the content keys. For instance, it is useful to be able to change in one shot the DSCP-marking of all classification rules matching packets from a certain origin (= the non-unique key). In order to uniquely address an entry, its index should be used, for which ForCES can and will guarantee uniqueness, unlike content keys that depend on the actual data. Regards, -Robert From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 4 12:21: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 MAA16294 for ; Fri, 4 Feb 2005 12:21:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7SG-000723-CY for forces-archive@IETF.ORG; Fri, 04 Feb 2005 12:41: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 <10.00F6C9BF@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 12:21:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56481178 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 12:21:39 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 12:21:39 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9016573 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 04 Feb 2005 12:21:38 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 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> <6.1.2.0.0.20050130114248.0643eec0@localhost> <001301c50798$68ecf3f0$020aa8c0@wwm1> <6.1.2.0.0.20050201235457.065da878@localhost> <4203ADCF.4070908@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050204122024.031847f0@localhost> Date: Fri, 4 Feb 2005 12:21:18 -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: <4203ADCF.4070908@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This seems to require that the FE be able to search its tables for arbitrary information. Given that the CE has the knowledge, and has the more powerful environment, I am inclined to think it is more sensible to make the CE do the work. Yours, Joel At 12:15 PM 2/4/2005, Robert Haas wrote: >Joel M. Halpern wrote: > >> >> >>The use of the keyid in the array declaration means that in this array, >>the field or field combination declared as a key will never be duplicated >>across entries within the array. >I'd argue against forcing the uniqueness of the content keys. For >instance, it is useful to be able to change in one shot the DSCP-marking >of all classification rules matching packets from a certain origin (= the >non-unique key). > >In order to uniquely address an entry, its index should be used, for which >ForCES can and will guarantee uniqueness, unlike content keys that depend >on the actual data. > > >Regards, >-Robert From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 4 12:32: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 MAA17588 for ; Fri, 4 Feb 2005 12:32:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7cB-0007Lc-V0 for forces-archive@IETF.ORG; Fri, 04 Feb 2005 12:51:38 -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.00F6C866@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 12:31:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56487413 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 12:31:54 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 12:31:54 -0500 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1Cx7JA-00028L-9J for FORCES@PEACH.EASE.LSOFT.COM; Fri, 04 Feb 2005 17:31:54 +0000 Received: from een9169.een.bris.ac.uk ([137.222.189.169]) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Cx7J4-0006ss-SW for FORCES@PEACH.EASE.LSOFT.COM; Fri, 04 Feb 2005 17:31:46 +0000 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <1107366770.1074.87.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:010KdkPTUMxbEI6N2n/jYNkaYICdpgEEIdkp8NEd1h/jPV2ag=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: Date: Fri, 4 Feb 2005 17:31:46 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107366770.1074.87.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi Jamal, > The main header's seq number is intended to cover the transaction of all > operations within a message. > I would say the combo of the FEID+LFBID+instanceID+sequence number > should provide sufficient corelation data to maintain state and handle > atomicity of a transaction across FEs. At least for unicast FEID it is. > For Multi/Broadcast FEIDs an extra state corelation in my opinion would > need to be maintained at the CE LFB level. > Not sure if i am on target for what you were asking. Fine, thanks, on the identification side. I can see the mechanisms in place even if they need to be filled in a bit. Not so fine on the atomicity issues, because I'm not so clear about the possible combinations of the operations delimited by the sequence number in the "main header", nor about how the all-or-none is achieved. My references are your e-mailed documents: config+response.txt (12/20/2004) and data_path2.txt (02/03/2005) - are these the ones I should be reading? I don't see (from config+response.txt) how rollback and commit functions are achieved. There is a lot of mention of 2-phase commit but I haven't been able to identify the phases from the description so far. I wondered also about recovery, but I don't see any mention of this. Please point me to anything I missed, and I don't want to disrupt the current thread with this (orthogonal) issue. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 4 13:13:17 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 NAA20806 for ; Fri, 4 Feb 2005 13:13:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx8G7-0008JK-Pj for forces-archive@IETF.ORG; Fri, 04 Feb 2005 13:32: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 <11.00F6C941@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 13:13:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56490311 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 13:13:17 -0500 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 13:13:16 -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 j14IDGbP188238 for ; Fri, 4 Feb 2005 18:13:16 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 j14IDGxO184344 for ; Fri, 4 Feb 2005 19:13:16 +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 j14IDFoV013065 for ; Fri, 4 Feb 2005 19:13:16 +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 j14IDFrY013062; Fri, 4 Feb 2005 19:13:15 +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 TAA53306; Fri, 4 Feb 2005 19:13:15 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.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> <6.1.2.0.0.20050130114248.0643eec0@localhost> <001301c50798$68ecf3f0$020aa8c0@wwm1> <6.1.2.0.0.20050201235457.065da878@localhost> <4203ADCF.4070908@zurich.ibm.com> <6.2.0.14.0.20050204122024.031847f0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id j14IDGbP188238 Approved-By: Robert Haas Message-ID: <4203BB39.2080005@zurich.ibm.com> Date: Fri, 4 Feb 2005 19:13:13 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [3]Re: path data textt update Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050204122024.031847f0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > This seems to require that the FE be able to search its tables for=20 > arbitrary information. I did not mean arbitrary information: this information would have to be=20 declared as key too. Only that such keys are not necessarily leading to=20 an always unique match. > Given that the CE has the knowledge, and has the more powerful=20 > environment, I am inclined to think it is more sensible to make the CE=20 > do the work. This is a tradeoff between protocol efficiency vs complexity imposed on=20 the FE, clearly. I certainly agree that the mere fact of supporting complex content=20 search keys does not improve protocol efficiency (the CE can do the SQL=20 work and figure out the index of the entry to set, instead of asking the=20 FE to do this), and in fact it worsens FE complexity. But I see gains in protocol efficiency if a SET operation for multiple=20 matching entries can be executed with a single PATH/SUBPATH vs as many=20 PATH/SUBPATHS as there are entries to be changed. Irrespectively of whether keys lead to unique matches or not: if a=20 search is done on a content key for which the underlying LFB does not=20 implement efficient lookup (i.e., it must traverses all 100k entries to=20 find the matching one), then trouble is on the way. Do we assume here=20 that the only allowed content-search keys are the well-known datapath=20 keys for which lookup is (anyway) optimized ? Regards, -Robert > > Yours, > Joel > > At 12:15 PM 2/4/2005, Robert Haas wrote: > >> Joel M. Halpern wrote: >> >>> >>> >>> The use of the keyid in the array declaration means that in this=20 >>> array, the field or field combination declared as a key will never=20 >>> be duplicated across entries within the array. >> >> I'd argue against forcing the uniqueness of the content keys. For=20 >> instance, it is useful to be able to change in one shot the=20 >> DSCP-marking of all classification rules matching packets from a=20 >> certain origin (=3D the non-unique key). >> >> In order to uniquely address an entry, its index should be used, for=20 >> which ForCES can and will guarantee uniqueness, unlike content keys=20 >> that depend on the actual data. >> >> >> Regards, >> -Robert > > > --=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 Feb 4 16:54: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 QAA10674 for ; Fri, 4 Feb 2005 16:54:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxBiD-0005T1-0i for forces-archive@IETF.ORG; Fri, 04 Feb 2005 17: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 <4.00F6CEDF@cherry.ease.lsoft.com>; Fri, 4 Feb 2005 16:54:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56507475 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 4 Feb 2005 16:54:28 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Feb 2005 16:54:27 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020413533645:59794 ; Fri, 4 Feb 2005 13:53:36 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <1107366770.1074.87.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 02/04/2005 01:53:36 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/04/2005 01:53:39 PM, Serialize complete at 02/04/2005 01:53:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107554064.1074.37.camel@jzny.localdomain> Date: Fri, 4 Feb 2005 16:54:24 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Hi Alistair, On Fri, 2005-02-04 at 12:31, Alistair Munro wrote: > Not so fine on the atomicity issues, because I'm not so clear about the > possible combinations of the operations delimited by the sequence number in > the "main header", nor about how the all-or-none is achieved. I suppose this is as good time as any to discuss this - I was hoping we could get the datapath stuff out of the way first. There are two schools of thoughts which are being tossed around. We try to support both and leave the details to implementation (the intelligence is at the CE). 1) The CE knows exact details about the resources at the FE (memory etc). When it says "ADD" it knows that would work etc. In this scenario, it is contended by the proponents of this optimization that when a CE decides to send a command to an FE it will work %100. so the all or none compute is done at the CE. 2) the classical 2pc scheme; undo/rollback when things go wrong. undoing happens by the CEs orders after an error response from any one FE being synchronized is received. I believe #2 is the scenario you are asking about, correct? A 2 phase commit starts with a START | ATOMIC flag on its first message of a transaction. A transaction may span multiple messages. Its up to the CE to keep track of the different seq #s making up a transaction. This may then be followed by more messages which are part of the same atomic transaction. The transaction terminates with an empty DONE msg type. It is expected that any failure of resources would be detected before the DONE msg is sent from the CE. i.e once the DONE is issued it is expected that the FE will succesfully install the policies i.e the commit will succeed. We may also need an ABORT message or maybe a done with an ABORT flag to undo. Does this sound sensible? > My references are your e-mailed documents: config+response.txt (12/20/2004) > and data_path2.txt (02/03/2005) - are these the ones I should be reading? I think those two will pretty much get you into the thick of it (as far as current discussion level is). I try to track state in those two so we avoid conflict about what was said or agreed on later (which has slowed us down in the past). > I don't see (from config+response.txt) how rollback and commit functions > are achieved. There is a lot of mention of 2-phase commit but I haven't > been able to identify the phases from the description so far. > a lot of email exchanges on the list but nothing captured in a doc. I will update as the discussions take effect. Also a lot of deferal for later discussion trying to shoot the big issues first. > I wondered also about recovery, but I don't see any mention of this. > > Please point me to anything I missed, and I don't want to disrupt the > current thread with this (orthogonal) issue. We can certainly proceed with this as well. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 5 03:40: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 DAA12266 for ; Sat, 5 Feb 2005 03:40:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxLmx-00028U-9S for forces-archive@IETF.ORG; Sat, 05 Feb 2005 03:59: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 <4.00F6DABF@cherry.ease.lsoft.com>; Sat, 5 Feb 2005 3:39:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56548515 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 5 Feb 2005 03:39:57 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 5 Feb 2005 03:39:55 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Sat, 5 Feb 2005 17:09:54 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sat, 5 Feb 2005 16:39:16 +0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@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 Approved-By: "Wang,Weiming" Message-ID: <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> Date: Sat, 5 Feb 2005 16:39:06 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Joel, With theGET-RESPONSE and the SET-RESPONSE in mind, I think of a possible limitation by use of the format: DATA := [DATARAW] | + because this format excludes the format instance as "data, nested path-data, data". I just think this format instance is necessary for easy RESPONSE, i.e., just let added response data packed at the end of the data. Based on this thought, I think if we should expand the above format to: DATA:= [DATARAW] * [DATARAW] Moreover, if we allow chained DATARAW TLVs format, then it is better with the format: DATA:= * * * because I think the chained DATARAW TLVs may be more efficient than ested TLVs in DATARAW TLV here. Cheers, Weiming ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: Protocol Operations > All we are saying here (assuming the simple case where there are no errors) > is that > we start with a GET operation TLV. It contains a collection of PATH-DATA > TLVs that identify items of interest. > we get a GET-RESPONSE operation TLV. It contains a collection of PATH-DATA > TLVs for those same items, which include the actual data that was request. > The arrangement of the PATH-DATA TLVs and the data within them is such that > if you replace the GET-RESPONSE code with a SET code, the contents of the > GET-RESPONSE are valid contents for a SET request to set the identified > items to the values that they had. (Of course, if you do it immediately > nothing will happen since those are the values. But if you changed things, > and then did the set, you would get what you expect.) From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 5 12:20:35 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 MAA15963 for ; Sat, 5 Feb 2005 12:20:35 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxTup-0003tV-6q for forces-archive@IETF.ORG; Sat, 05 Feb 2005 12:40: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 <16.00F6E119@cherry.ease.lsoft.com>; Sat, 5 Feb 2005 12:20:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56608875 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 5 Feb 2005 12:20:30 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 5 Feb 2005 12:20:30 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9032728 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 05 Feb 2005 12:20:29 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050205121611.0316ac80@localhost> Date: Sat, 5 Feb 2005 12:19:58 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I believe that the case you want is already covered. And the nesting makes the applicability clear. For the operations that include data (SET Request and GET Response), the PATH-DATA information will include a DATA TLV. If we have fully identified the target of the operation, then the DATA will be a DATARAW. If we have not yet fully identified the target, then the DTA will be one or more PATH-DATA items, each of which will contain a DATA TLV. Thus, these DATA TLVs can and will in turn contain either DATARAW or further elaborating PATH-DATA, such that eventually, down each branch, one arrives at a DATARAW. If the reason for the second DATARAW was to handle some other case, then I am sorry but I do not know what that is. Yours, Joel M. Halpern At 03:39 AM 2/5/2005, Wang,Weiming wrote: >Joel, > >With theGET-RESPONSE and the SET-RESPONSE in mind, I think of a possible >limitation by use of the format: >DATA := [DATARAW] | + >because this format excludes the format instance as "data, nested path-data, >data". I just think this format instance is necessary for easy RESPONSE, i.e., >just let added response data packed at the end of the data. >Based on this thought, I think if we should expand the above format to: > >DATA:= [DATARAW] * [DATARAW] > >Moreover, if we allow chained DATARAW TLVs format, then it is better with the >format: > >DATA:= * * * > >because I think the chained DATARAW TLVs may be more efficient than ested TLVs >in DATARAW TLV here. > >Cheers, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: Protocol Operations > > > > All we are saying here (assuming the simple case where there are no errors) > > is that > > we start with a GET operation TLV. It contains a collection of PATH-DATA > > TLVs that identify items of interest. > > we get a GET-RESPONSE operation TLV. It contains a collection of PATH-DATA > > TLVs for those same items, which include the actual data that was request. > > The arrangement of the PATH-DATA TLVs and the data within them is such that > > if you replace the GET-RESPONSE code with a SET code, the contents of the > > GET-RESPONSE are valid contents for a SET request to set the identified > > items to the values that they had. (Of course, if you do it immediately > > nothing will happen since those are the values. But if you changed things, > > and then did the set, you would get what you expect.) From ayshsfjsdljuvt@world4fun.ch Sat Feb 5 18:04: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 SAA07835; Sat, 5 Feb 2005 18:04:18 -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 1CxZHX-0001jF-QY; Sat, 05 Feb 2005 18:24:04 -0500 Received: from [221.211.176.33] (helo=USER-0919D6E94A) by mx2.foretec.com with smtp (Exim 4.24) id 1CxYyO-0000uz-QZ; Sat, 05 Feb 2005 18:04:17 -0500 Received: from mercantile.dostmail.com ([64.202.167.192]) by eastland.dostmail.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0T0Y6287WKH7RA57@eastland.dostmail.com> for leah.barber@ietf.org; Sun, 06 Feb 2005 00:59:55 +0200 (IST) Received: from icarus.fotofutura.com ([81.27.32.130]) by mercantile.dostmail.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0W8G608XMQG2CZ05@mercantile.dostmail.com> for leah.barber@ietf.org (ORCPT leah.barber@ietf.org); Sun, 06 Feb 2005 00:59:55 +0200 (IST) Received: from Madelyn (IGLD-21-373-675-752.fotofutura.com [69.55.64.39]) by balder.fotofutura.com (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DWZ08169 (AUTH Bourgeois); Sat, 05 Feb 2005 18:50:55 -0400 (IST) Date: Sun, 06 Feb 2005 00:59:55 +0200 From: Kathleen Combs Subject: Specal Offer f0r Wnd0ws 20oO Server To: "Leah.barber" Message-ID: <999406367546.EHO85634@cais.com> MIME-version: 1.0 Content-Type: multipart/alternative; boundary="----_001_7990_18Z48II5.30PA3394" X-Mailer: Microsoft CDO for Windows 2000 X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. ------_001_7990_18Z48II5.30PA3394 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit ------_001_7990_18Z48II5.30PA3394 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit PrIce c0mpar1sOn

Bundle 1:
WiND0WS X*P Pro + 0FFICE X'P Pro fOr as low as 8O$

Brand New Lega| s0ftware at Affordable Pr!ces

BundLe 2:
Macromedia Dreamwaver MX 2OO4 + F|ash MX 20O4 - 10o DO|lars

Great Sale

Bundle 3:
AdObe PhOt0shop 7, Premiere 7, 1LlustratOr 10 - 120 DOl|ars

Hurry
The Offer is va|Id Unt|Ll February 18th
StOck is Limited





updates your details

Madelyn Bourgeois
Dietician
Synergene, Attard, BZN12,, Malta
Phone: 112-911-6571
Mobile: 716-877-5597
Email: ayshsfjsdljuvt@world4fun.ch

please do not reply to this message

This freeware is a 27 second trial version

NOTES:

The contents of this information is for your exclusive use and should not be bilk grandmother

leer activation elk

Time: Sun, 06 Feb 2005 00:59:55 +0200 ------_001_7990_18Z48II5.30PA3394-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 6 02:41: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 CAA00599 for ; Sun, 6 Feb 2005 02:41:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxhMM-0002mS-UD for forces-archive@IETF.ORG; Sun, 06 Feb 2005 03:01: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 <20.00F6FD2F@cherry.ease.lsoft.com>; 6 Feb 2005 2:41:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56661163 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 6 Feb 2005 02:41:39 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 6 Feb 2005 02:41:39 -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 j167fcrE002511 for ; Sun, 6 Feb 2005 07:41:38 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 j167fcaD013075 for ; Sun, 6 Feb 2005 07:41:38 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005020523413823403 for ; Sat, 05 Feb 2005 23:41:38 -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); Sat, 5 Feb 2005 23:41:38 -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 in Minneapolis, MN Thread-Index: AcUKxIkFLF+yWIX+S6mTCEoNMNVtMgBMtqZw X-OriginalArrivalTime: 06 Feb 2005 07:41:38.0451 (UTC) FILETIME=[4A91B630:01C50C1F] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Sat, 5 Feb 2005 23:41:38 -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 in Minneapolis, MN To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable FYI... =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Friday, February 04, 2005 6:01 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 Mon Feb 7 10:54: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 KAA11376 for ; Mon, 7 Feb 2005 10:54:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBWi-0003Zv-EZ for forces-archive@IETF.ORG; Mon, 07 Feb 2005 11: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 <9.00F74940@cherry.ease.lsoft.com>; Mon, 7 Feb 2005 10:54:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56864747 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 7 Feb 2005 10:54:00 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 7 Feb 2005 10:53: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 2005020707543566:637 ; Mon, 7 Feb 2005 07:54:35 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@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 02/07/2005 07:54:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/07/2005 07:54:37 AM, Serialize complete at 02/07/2005 07:54:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107791636.1080.33.camel@jzny.localdomain> Date: Mon, 7 Feb 2005 10:53:56 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050205121611.0316ac80@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit I believe the example from Weiming is a corner case that is not needed in the majority of the cases. Could this not be achieved some other way example by having multiple path-datas with data in them? I have intentionaly avoided making the DATA lvalue a TLV; this is to allow for some efficiency - by making it a TLV it means we always have to have a DATARAW TLV encapsulated by a DATA TLV and none of the examples (which in my opinion cover the majority of possible uses) so far have needed it. Again heres the BNF as described so far: ------- i ) A TLV will have the word "TLV" following it ii) <> encloses a _mandatory_ component iii) [] encloses an optional component iv) + implies "one or more" v) Missing <> or [] implies a literal/terminal TODO: Fix this later to conform to the ABNF described in RFC 2234. OPER TLV : = + PATH-DATA TLV := [DATAINFO] PATH := flags IDcount IDs DATAINFO := [SELECTOR] [DATA] SELECTOR := [BLKINFO] | [KEYINFO] DATA := [DATARAW] | + KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] DATARAW TLV := encoded data which may nest DATARAW TLVs -- cheers, jamal On Sat, 2005-02-05 at 12:19, Joel M. Halpern wrote: > I believe that the case you want is already covered. And the nesting makes > the applicability clear. > > For the operations that include data (SET Request and GET Response), the > PATH-DATA information will include a DATA TLV. If we have fully identified > the target of the operation, then the DATA will be a DATARAW. > If we have not yet fully identified the target, then the DTA will be one or > more PATH-DATA items, each of which will contain a DATA TLV. Thus, these > DATA TLVs can and will in turn contain either DATARAW or further > elaborating PATH-DATA, such that eventually, down each branch, one arrives > at a DATARAW. > > If the reason for the second DATARAW was to handle some other case, then I > am sorry but I do not know what that is. > > Yours, > Joel M. Halpern > > At 03:39 AM 2/5/2005, Wang,Weiming wrote: > >Joel, > > > >With theGET-RESPONSE and the SET-RESPONSE in mind, I think of a possible > >limitation by use of the format: > >DATA := [DATARAW] | + > >because this format excludes the format instance as "data, nested path-data, > >data". I just think this format instance is necessary for easy RESPONSE, i.e., > >just let added response data packed at the end of the data. > >Based on this thought, I think if we should expand the above format to: > > > >DATA:= [DATARAW] * [DATARAW] > > > >Moreover, if we allow chained DATARAW TLVs format, then it is better with the > >format: > > > >DATA:= * * * > > > >because I think the chained DATARAW TLVs may be more efficient than ested TLVs > >in DATARAW TLV here. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >Subject: Re: Protocol Operations > > > > > > > All we are saying here (assuming the simple case where there are no errors) > > > is that > > > we start with a GET operation TLV. It contains a collection of PATH-DATA > > > TLVs that identify items of interest. > > > we get a GET-RESPONSE operation TLV. It contains a collection of PATH-DATA > > > TLVs for those same items, which include the actual data that was request. > > > The arrangement of the PATH-DATA TLVs and the data within them is such that > > > if you replace the GET-RESPONSE code with a SET code, the contents of the > > > GET-RESPONSE are valid contents for a SET request to set the identified > > > items to the values that they had. (Of course, if you do it immediately > > > nothing will happen since those are the values. But if you changed things, > > > and then did the set, you would get what you expect.) From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 7 15:13: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 PAA07545 for ; Mon, 7 Feb 2005 15:13:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyFa7-0001Sz-K1 for forces-archive@IETF.ORG; Mon, 07 Feb 2005 15:34:08 -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.00F7528C@cherry.ease.lsoft.com>; Mon, 7 Feb 2005 15:13:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56891552 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 7 Feb 2005 15:13:43 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 7 Feb 2005 15:13:43 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020712141829:1468 ; Mon, 7 Feb 2005 12:14:18 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.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 02/07/2005 12:14:18 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/07/2005 12:14:21 PM, Serialize complete at 02/07/2005 12:14:21 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107807219.1078.123.camel@jzny.localdomain> Date: Mon, 7 Feb 2005 15:13:39 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107791636.1080.33.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit An alternative thought: Would it be acceptable that a DATA TLV will only be needed in the scenario when someone wants to nest either DATARAW or PATH-DATA? I am not sure how to represent that in the BNF. I am also willing to go on the DATA TLV always if this is going to cause any ambiguities or is going to speed up progress so we can put closure to things. I cant say i am thrilled with it though. cheers, jamal On Mon, 2005-02-07 at 10:53, Jamal Hadi Salim wrote: > I believe the example from Weiming is a corner case that is not needed > in the majority of the cases. > > Could this not be achieved some other way example by having multiple > path-datas with data in them? > I have intentionaly avoided making the DATA lvalue a TLV; this is to allow > for some efficiency - by making it a TLV it means we always have > to have a DATARAW TLV encapsulated by a DATA TLV and none of the > examples (which in my opinion cover the majority of possible uses) > so far have needed it. > > Again heres the BNF as described so far: > > ------- > i ) A TLV will have the word "TLV" following it > ii) <> encloses a _mandatory_ component > iii) [] encloses an optional component > iv) + implies "one or more" > v) Missing <> or [] implies a literal/terminal > > TODO: Fix this later to conform to the ABNF described in RFC 2234. > > OPER TLV : = + > PATH-DATA TLV := [DATAINFO] > PATH := flags IDcount IDs > DATAINFO := [SELECTOR] [DATA] > SELECTOR := [BLKINFO] | [KEYINFO] > DATA := [DATARAW] | + > KEYINFO TLV := KEYID KEY_DATA > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] > DATARAW TLV := encoded data which may nest DATARAW TLVs > -- > > cheers, > jamal > > On Sat, 2005-02-05 at 12:19, Joel M. Halpern wrote: > > I believe that the case you want is already covered. And the nesting makes > > the applicability clear. > > > > For the operations that include data (SET Request and GET Response), the > > PATH-DATA information will include a DATA TLV. If we have fully identified > > the target of the operation, then the DATA will be a DATARAW. > > If we have not yet fully identified the target, then the DTA will be one or > > more PATH-DATA items, each of which will contain a DATA TLV. Thus, these > > DATA TLVs can and will in turn contain either DATARAW or further > > elaborating PATH-DATA, such that eventually, down each branch, one arrives > > at a DATARAW. > > > > If the reason for the second DATARAW was to handle some other case, then I > > am sorry but I do not know what that is. > > > > Yours, > > Joel M. Halpern > > > > At 03:39 AM 2/5/2005, Wang,Weiming wrote: > > >Joel, > > > > > >With theGET-RESPONSE and the SET-RESPONSE in mind, I think of a possible > > >limitation by use of the format: > > >DATA := [DATARAW] | + > > >because this format excludes the format instance as "data, nested path-data, > > >data". I just think this format instance is necessary for easy RESPONSE, i.e., > > >just let added response data packed at the end of the data. > > >Based on this thought, I think if we should expand the above format to: > > > > > >DATA:= [DATARAW] * [DATARAW] > > > > > >Moreover, if we allow chained DATARAW TLVs format, then it is better with the > > >format: > > > > > >DATA:= * * * > > > > > >because I think the chained DATARAW TLVs may be more efficient than ested TLVs > > >in DATARAW TLV here. > > > > > >Cheers, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Re: Protocol Operations > > > > > > > > > > All we are saying here (assuming the simple case where there are no errors) > > > > is that > > > > we start with a GET operation TLV. It contains a collection of PATH-DATA > > > > TLVs that identify items of interest. > > > > we get a GET-RESPONSE operation TLV. It contains a collection of PATH-DATA > > > > TLVs for those same items, which include the actual data that was request. > > > > The arrangement of the PATH-DATA TLVs and the data within them is such that > > > > if you replace the GET-RESPONSE code with a SET code, the contents of the > > > > GET-RESPONSE are valid contents for a SET request to set the identified > > > > items to the values that they had. (Of course, if you do it immediately > > > > nothing will happen since those are the values. But if you changed things, > > > > and then did the set, you would get what you expect.) From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 7 17:28: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 RAA06767 for ; Mon, 7 Feb 2005 17:28:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHgC-0001tJ-KH for forces-archive@IETF.ORG; Mon, 07 Feb 2005 17:48:38 -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.00F75908@cherry.ease.lsoft.com>; Mon, 7 Feb 2005 17:28:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56902196 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 7 Feb 2005 17:28:11 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 7 Feb 2005 17:28:11 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9069305 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 07 Feb 2005 17:28:11 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050207171834.031b6ac8@localhost> Date: Mon, 7 Feb 2005 17:26:33 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107807219.1078.123.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de I actually think we could get away with: DATAINFO := [SELECTOR] [ | +] and just leave out the "DATA" line. I believe this allows the nesting, is decidable by the parser, and does what we need. we can in fact collapse further in the BNF to: PATH-DATA TLV := [SELECTOR] [+ | +] The length of the PATH-DATA TLV will keep us from falling off the end looking for something that is not part of this TLV. If we treat an omitted SELECTOR as a single item selector, we can then state the rules. On a SET Request or GET Response (or a verbose SET response) every PATH-DATA TLV must have a number of DATA or PATH-DATA TLVs equal to the number of "selected" items. On a GET request each PATH-DATA TLV may have a number of PATH-DATA TLVs equal to the number of selectors, but must not have a DATA TLV. If we want to allow the special case of mapping data across a selector, we could allow a selector of count greater than 1 and 1 DATA or PATH-DATA TLV. I would prefer not to allow that. But some of the examples have suggested it, and it is at least syntactically well formed. Yours, Joel At 03:13 PM 2/7/2005, Jamal Hadi Salim wrote: >An alternative thought: >Would it be acceptable that a DATA TLV will only be needed in the >scenario when someone wants to nest either DATARAW or PATH-DATA? >I am not sure how to represent that in the BNF. I am also willing >to go on the DATA TLV always if this is going to cause any ambiguities >or is going to speed up progress so we can put closure to things. >I cant say i am thrilled with it though. > >cheers, >jamal > >On Mon, 2005-02-07 at 10:53, Jamal Hadi Salim wrote: > > I believe the example from Weiming is a corner case that is not needed > > in the majority of the cases. > > > > Could this not be achieved some other way example by having multiple > > path-datas with data in them? > > I have intentionaly avoided making the DATA lvalue a TLV; this is to allow > > for some efficiency - by making it a TLV it means we always have > > to have a DATARAW TLV encapsulated by a DATA TLV and none of the > > examples (which in my opinion cover the majority of possible uses) > > so far have needed it. > > > > Again heres the BNF as described so far: > > > > ------- > > i ) A TLV will have the word "TLV" following it > > ii) <> encloses a _mandatory_ component > > iii) [] encloses an optional component > > iv) + implies "one or more" > > v) Missing <> or [] implies a literal/terminal > > > > TODO: Fix this later to conform to the ABNF described in RFC 2234. > > > > OPER TLV : = + > > PATH-DATA TLV := [DATAINFO] > > PATH := flags IDcount IDs > > DATAINFO := [SELECTOR] [DATA] > > SELECTOR := [BLKINFO] | [KEYINFO] > > DATA := [DATARAW] | + > > KEYINFO TLV := KEYID KEY_DATA > > BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] > > DATARAW TLV := encoded data which may nest DATARAW TLVs > > -- > > > > cheers, > > jamal > > > > On Sat, 2005-02-05 at 12:19, Joel M. Halpern wrote: > > > I believe that the case you want is already covered. And the nesting > makes > > > the applicability clear. > > > > > > For the operations that include data (SET Request and GET Response), the > > > PATH-DATA information will include a DATA TLV. If we have fully > identified > > > the target of the operation, then the DATA will be a DATARAW. > > > If we have not yet fully identified the target, then the DTA will be > one or > > > more PATH-DATA items, each of which will contain a DATA TLV. Thus, > these > > > DATA TLVs can and will in turn contain either DATARAW or further > > > elaborating PATH-DATA, such that eventually, down each branch, one > arrives > > > at a DATARAW. > > > > > > If the reason for the second DATARAW was to handle some other case, > then I > > > am sorry but I do not know what that is. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 03:39 AM 2/5/2005, Wang,Weiming wrote: > > > >Joel, > > > > > > > >With theGET-RESPONSE and the SET-RESPONSE in mind, I think of a > possible > > > >limitation by use of the format: > > > >DATA := [DATARAW] | + > > > >because this format excludes the format instance as "data, nested > path-data, > > > >data". I just think this format instance is necessary for easy > RESPONSE, i.e., > > > >just let added response data packed at the end of the data. > > > >Based on this thought, I think if we should expand the above format to: > > > > > > > >DATA:= [DATARAW] * [DATARAW] > > > > > > > >Moreover, if we allow chained DATARAW TLVs format, then it is better > with the > > > >format: > > > > > > > >DATA:= * * * > > > > > > > >because I think the chained DATARAW TLVs may be more efficient than > ested TLVs > > > >in DATARAW TLV here. > > > > > > > >Cheers, > > > >Weiming > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > All we are saying here (assuming the simple case where there are > no errors) > > > > > is that > > > > > we start with a GET operation TLV. It contains a collection of > PATH-DATA > > > > > TLVs that identify items of interest. > > > > > we get a GET-RESPONSE operation TLV. It contains a collection of > PATH-DATA > > > > > TLVs for those same items, which include the actual data that was > request. > > > > > The arrangement of the PATH-DATA TLVs and the data within them is > such that > > > > > if you replace the GET-RESPONSE code with a SET code, the > contents of the > > > > > GET-RESPONSE are valid contents for a SET request to set the > identified > > > > > items to the values that they had. (Of course, if you do it > immediately > > > > > nothing will happen since those are the values. But if you > changed things, > > > > > and then did the set, you would get what you expect.) From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 07:00: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 HAA01307 for ; Tue, 8 Feb 2005 07:00:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUMV-0002QV-LC for forces-archive@IETF.ORG; Tue, 08 Feb 2005 07:21: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.00F778AC@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 7:00:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 56988823 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 07:00:39 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 07:00:39 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9078272; Tue, 08 Feb 2005 07:00:39 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208065427.03174150@localhost> Date: Tue, 8 Feb 2005 06:59:25 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 You raise an interesting question of where the element by element SET results go. One of the drawbacks of allowing multiple path-data elements inside a operation TLV is that it no longer suffices to return the response code at the operation TLV level. Therefore, I would presume, we will have to return the response codes in the individual path-data TLVs. I would not want to return the results as a separate parallel TLV, as that would imply some kind of matching that would get quite confusing. I suppose that means that the actual syntax becomes: DATAINFO := [SELECTOR] [+ | + | +] Where SET Result is used only in the response to a SET, and occurs where the DATARAW elements were in the set request, indicating for each dataraw whether it was successfully set. Yours, Joel At 11:22 PM 2/7/2005, Wang,Weiming wrote: >It quite gets to me that the list server often ate my posts. I do have >sent some mails but that cann't be seen on the list till now. > >Hopefully this post can work. > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: Protocol Operations > > > > I actually think we could get away with: > > > > DATAINFO := [SELECTOR] [ | +] > > > > and just leave out the "DATA" line. I believe this allows the nesting, is > > decidable by the parser, and does what we need. > > > > we can in fact collapse further in the BNF to: > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > >Yes, this makes it more clear, but I still see the value to modify it to: > >PATH-DATA TLV := [SELECTOR] [+] [+] > >I suppose a SET request that has format as "path path-data1 path-data2 >path-data3", whos response will have format as "path path-data1 path-data2 >path-data3 data", the last data TLV is for the SET result responses. > >Cheers, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 09:16: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 JAA11592 for ; Tue, 8 Feb 2005 09:16:21 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWTm-0005Zz-TT for forces-archive@IETF.ORG; Tue, 08 Feb 2005 09:36: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 <6.00F77CB3@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 9:16:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57002866 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 09:16:12 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 09:16:12 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020806164724:8017 ; Tue, 8 Feb 2005 06:16:47 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@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 02/08/2005 06:16:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 06:16:50 AM, Serialize complete at 02/08/2005 06:16:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107872168.1088.75.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 09:16:08 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050208065427.03174150@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit I am not sure i got the SETRESULT; going by what Weiming asked for earlier, we have the following facilities: To set data to a 3-deep path offset: path-data path1 optional selector path-data path2 optional selector path-data path3 optional selector dataraw If a response is asked back, thats exactly how the response would look like as well. The other way which is to set data on multiple nested paths: path-data path1 optional selector dataraw path-data path2 optional selector dataraw path-data path3 optional selector dataraw Granted the end result will be grossly ineefficient since it will have a lot of redundant information in the three path-datas above if path1 is relative to path2 and path3 is realtive to path2. For this we can use what i have seen in a few classifiers as an optimization; these sorts of classifiers hacve a "continue" construct which translates to "continue looking up where you last left off". We can have something similar as a flag - so on path2 and path3 it would say "the previous path+selector counts as part of this path". So path1 + its selectors will be part of path2+ its selectors, which is also part of path3 and its selectors. Clearly the flag is not useful on the first path-data it involves inheritance and can be ignored there. Heres my worry: I think what Weiming wants in this case is a corner case which while we must satisfy the end result should not break the simple design rule of "optimize for the majority" cheers, jamal On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > You raise an interesting question of where the element by element SET > results go. > > One of the drawbacks of allowing multiple path-data elements inside a > operation TLV is that it no longer suffices to return the response code at > the operation TLV level. > Therefore, I would presume, we will have to return the response codes in > the individual path-data TLVs. > I would not want to return the results as a separate parallel TLV, as that > would imply some kind of matching that would get quite confusing. I > suppose that means that the actual syntax becomes: > > DATAINFO := [SELECTOR] [+ | + | +] > > Where SET Result is used only in the response to a SET, and occurs where > the DATARAW elements were in the set request, indicating for each dataraw > whether it was successfully set. > > Yours, > Joel > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > >It quite gets to me that the list server often ate my posts. I do have > >sent some mails but that cann't be seen on the list till now. > > > >Hopefully this post can work. > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >Subject: Re: Protocol Operations > > > > > > > I actually think we could get away with: > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > and just leave out the "DATA" line. I believe this allows the nesting, is > > > decidable by the parser, and does what we need. > > > > > > we can in fact collapse further in the BNF to: > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > >Yes, this makes it more clear, but I still see the value to modify it to: > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > >I suppose a SET request that has format as "path path-data1 path-data2 > >path-data3", whos response will have format as "path path-data1 path-data2 > >path-data3 data", the last data TLV is for the SET result responses. > > > >Cheers, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 11:10:02 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 LAA20867 for ; Tue, 8 Feb 2005 11:10:02 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYFo-000808-DQ for forces-archive@IETF.ORG; Tue, 08 Feb 2005 11:30: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 <23.00F78044@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 11:09:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57014038 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 11:09:57 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 11:09:57 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9082290 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 11:09:57 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208110708.031b5de8@localhost> Date: Tue, 8 Feb 2005 11:08:49 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107872168.1088.75.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 The question I think we need to cover is "what happens if some of the SETs work, and some do not." Given that the values are known by the requestor, I can not see any point in returning the dataraw elements in the SET response. So I am suggesting that each dataraw in the request is replaced in the response with a success code. For a GET response, get elements which succeed would have a dataraw, while those which fail would have a result TLV indicating what the problem was. Yours, Joel At 09:16 AM 2/8/2005, Jamal Hadi Salim wrote: >I am not sure i got the SETRESULT; going by what Weiming asked for >earlier, we have the following facilities: > >To set data to a 3-deep path offset: >path-data > path1 > optional selector > path-data > path2 > optional selector > path-data > path3 > optional selector > dataraw > > >If a response is asked back, thats exactly how the response would look >like as well. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:01: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 MAA25102 for ; Tue, 8 Feb 2005 12:01:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZ3p-0000oW-Bb for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:22: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.00F78191@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 11:49:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57019614 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 11:49:46 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 11:49:24 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j18GnMMA025837; Tue, 8 Feb 2005 16:49:22 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 j18GnCSf020951; Tue, 8 Feb 2005 16:49:20 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 M2005020808491824917 ; Tue, 08 Feb 2005 08:49: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); Tue, 8 Feb 2005 08:49:17 -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 Operations Thread-Index: AcUN6MbD4hFslqHzRc+LN4iktyNXQAAFSAmw X-OriginalArrivalTime: 08 Feb 2005 16:49:17.0455 (UTC) FILETIME=[20E351F0:01C50DFE] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 8 Feb 2005 08:49:15 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable (speaking just as another technical guy here)=20 This seems overly complex to me. Is there a common case that motivates the need for this? -David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Tuesday, February 08, 2005 6:16 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Protocol Operations >=20 > I am not sure i got the SETRESULT; going by what Weiming asked for > earlier, we have the following facilities: >=20 > To set data to a 3-deep path offset: > path-data > path1 > optional selector > path-data > path2 > optional selector > path-data > path3 > optional selector > dataraw >=20 >=20 > If a response is asked back, thats exactly how the response would look > like as well. >=20 > The other way which is to set data on multiple nested paths: >=20 > path-data > path1 > optional selector > dataraw > path-data > path2 > optional selector > dataraw > path-data > path3 > optional selector > dataraw >=20 > Granted the end result will be grossly ineefficient since it=20 > will have a > lot of redundant information in the three path-datas above if path1 is > relative to path2 and path3 is realtive to path2. > For this we can use what i have seen in a few classifiers as an > optimization; these sorts of classifiers hacve a "continue" construct > which translates to "continue looking up where you last left off". > We can have something similar as a flag - so on path2 and=20 > path3 it would > say "the previous path+selector counts as part of this path".=20 > So path1 + > its selectors will be part of path2+ its selectors, which is also part > of path3 and its selectors. Clearly the flag is not useful on=20 > the first > path-data it involves inheritance and can be ignored there. >=20 > Heres my worry: I think what Weiming wants in this case is a=20 > corner case > which while we must satisfy the end result should not break the simple > design rule of "optimize for the majority" >=20 > cheers, > jamal >=20 > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > You raise an interesting question of where the element by=20 > element SET=20 > > results go. > >=20 > > One of the drawbacks of allowing multiple path-data=20 > elements inside a=20 > > operation TLV is that it no longer suffices to return the=20 > response code at=20 > > the operation TLV level. > > Therefore, I would presume, we will have to return the=20 > response codes in=20 > > the individual path-data TLVs. > > I would not want to return the results as a separate=20 > parallel TLV, as that=20 > > would imply some kind of matching that would get quite=20 > confusing. I=20 > > suppose that means that the actual syntax becomes: > >=20 > > DATAINFO :=3D [SELECTOR] [+ | + | +] > >=20 > > Where SET Result is used only in the response to a SET, and=20 > occurs where=20 > > the DATARAW elements were in the set request, indicating=20 > for each dataraw=20 > > whether it was successfully set. > >=20 > > Yours, > > Joel > >=20 > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > >It quite gets to me that the list server often ate my=20 > posts. I do have=20 > > >sent some mails but that cann't be seen on the list till now. > > > > > >Hopefully this post can work. > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Re: Protocol Operations > > > > > > > > > > I actually think we could get away with: > > > > > > > > DATAINFO :=3D [SELECTOR] [ | +] > > > > > > > > and just leave out the "DATA" line. I believe this=20 > allows the nesting, is > > > > decidable by the parser, and does what we need. > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > PATH-DATA TLV :=3D [SELECTOR] [+ | +] > > > > > >Yes, this makes it more clear, but I still see the value=20 > to modify it to: > > > > > >PATH-DATA TLV :=3D [SELECTOR] [+] [+] > > > > > >I suppose a SET request that has format as "path=20 > path-data1 path-data2=20 > > >path-data3", whos response will have format as "path=20 > path-data1 path-data2=20 > > >path-data3 data", the last data TLV is for the SET result=20 > responses. > > > > > >Cheers, > > >Weiming >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:01: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 MAA25120 for ; Tue, 8 Feb 2005 12:01:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZ3q-0000oW-4L for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:22: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 <18.00F77FEC@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 11:59:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57021905 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 11:59:46 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 11:59:46 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020809001170:8650 ; Tue, 8 Feb 2005 09:00:11 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <6.2.0.14.0.20050208110708.031b5de8@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 02/08/2005 09:00:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 09:00:23 AM, Serialize complete at 02/08/2005 09:00:23 AM Content-Type: multipart/mixed; boundary="=-DCSDAucQ2mlIRxaEWRc3" Approved-By: Jamal Hadi Salim Message-ID: <1107881971.1072.30.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 11:59:31 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050208110708.031b5de8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f --=-DCSDAucQ2mlIRxaEWRc3 Content-Type: text/plain Content-Transfer-Encoding: 7bit In the main header we have flags for this - if need be we can move some of them to the path flags. Attached the text from earlier. Refer to section which reads "Responses"; i really dont wana distract the current discussion until we put closure to it, so if you think we oughta move the response flags in, we could although i think it will introduce complexity. Maybe we should defer this discussion? cheers, jamal On Tue, 2005-02-08 at 11:08, Joel M. Halpern wrote: > The question I think we need to cover is "what happens if some of the SETs > work, and some do not." > > Given that the values are known by the requestor, I can not see any point > in returning the dataraw elements in the SET response. > > So I am suggesting that each dataraw in the request is replaced in the > response with a success code. > > For a GET response, get elements which succeed would have a dataraw, while > those which fail would have a result TLV indicating what the problem was. > > Yours, > Joel > > At 09:16 AM 2/8/2005, Jamal Hadi Salim wrote: > >I am not sure i got the SETRESULT; going by what Weiming asked for > >earlier, we have the following facilities: > > > >To set data to a 3-deep path offset: > >path-data > > path1 > > optional selector > > path-data > > path2 > > optional selector > > path-data > > path3 > > optional selector > > dataraw > > > > > >If a response is asked back, thats exactly how the response would look > >like as well. --=-DCSDAucQ2mlIRxaEWRc3 Content-Disposition: attachment; filename=config+response Content-Type: text/plain; name=config+response; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In the master slave-relationship the CE instructs the FE on how to execute operations and how to report back the results. Execution --------- There are 3 execution modes that could be requested for operations spanning on one or more LFB selectors: 1) "all-or-none" Atomic transaction. I believe the SNMP way of life. The FE executes operations till the first one fails. If one fails to execute all fail and any applied ones MUST be undone. A 2pc in which the first phase ensures that resources exist applies could be used. A second scheme may skip the 2pc and proceed towards configuration. This would be implementation specific. The 2pc scheme is expected to support the latter. All messages that are atomically executed will have the global ATOMIC flag on. A 2 phase commit starts with a START flag on its first ATOMIC message and terminates with an empty DONE msg type. Global flags: ATOMIC, START (used by 2PC) New msg type: DONE(used by 2PC) 2) "one of N" independent operations. In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more operations fail. This mode is signalled by a missing ATOMIC flag. 3) "go to N" loose transaction In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything upto failed is not undone unlike #1. flag: GOTON (global) Multipart messages and the relationships to the above: ------------------------------------------------------ a) Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. b) There has to be consistency across the multi parts of the messages. In other words the first message starting with mode #1 above, implies the rest do. Any incosistency implies a cancelled transaction in which all messages are dropped and the sender NACKED. Responses: ---------- The CE expects the FE to report back the execution results when it asks for them. The CE also tells the FE to format them in a certain way. The reporting and its formating are still constrained by the execution requests. These are controlled by the ACK indicators(2 bit) 1) Full response. Essentially what sent is responded to in full with status of whether it failed or succeeded. This is paranoia mode which uses a lot more bandwidth than other modes (allows sender to validate what was sent). 2) Partial: Request for a report with only a success or failure. In other words, depending on the mode - the message could ask only to be told briefly whether the operation succeeded or failed. Great on bandwidth - sensible on reliable TML. 3) errors only Asks to be told only when theres an error that happened. Flags: NACK only Useful when execution success is certain and reliable delivery An example is when you are doing periodic sync updates in which you dont care if a message or two get lost. But you care if the update didnt succeed. 4) Ask for no notification Example unidirectional heartbeat. A more involved heartbeat would occasionally ask for acknowledgement or a full response(a pong to the ping) always. --=-DCSDAucQ2mlIRxaEWRc3-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:04: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 MAA25318 for ; Tue, 8 Feb 2005 12:04:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZ6E-0000qd-EN for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:24: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 <4.00F781C2@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 12:04:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57023429 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 12:04:08 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 12:04:07 -0500 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1CyYmM-0006yl-6J for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 17:04:07 +0000 Received: from een9169.een.bris.ac.uk ([137.222.189.169]) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1CyYmL-0005fp-SP for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 17:03:57 +0000 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <6.2.0.14.0.20050208110708.031b5de8@localhost> Originator-Info: login-token=Mulberry:01/TMZrGKYeiA1dJIWK2OZRhU1lY/PPW+pRw46nZLQK2Bhjhc=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: <9DDA3AB932D7114FEFEEB106@EEN9169.een.bris.ac.uk> Date: Tue, 8 Feb 2005 17:03:57 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050208110708.031b5de8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi Joel, all, > The question I think we need to cover is "what happens if some of the > SETs work, and some do not." If we are going to be strict about commitment then the entire collection should be undone if any component fails. Is this being too severe? Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:10: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 MAA25766 for ; Tue, 8 Feb 2005 12:09:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZBm-0000zA-K8 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:30: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 <13.00F78150@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 12:09:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57023873 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 12:09:54 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 12:09:54 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9082902 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 12:09:54 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <6.2.0.14.0.20050208110708.031b5de8@localhost> <9DDA3AB932D7114FEFEEB106@EEN9169.een.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208120703.03168980@localhost> Date: Tue, 8 Feb 2005 12:08:30 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <9DDA3AB932D7114FEFEEB106@EEN9169.een.bris.ac.uk> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The last discussion I can recall about atomicity / rollback seemed to end up with: Under normal circumstances multiple requests in a PDU can be performed / succedd / failed individually. There would be flags to define transaction boundaries to allow a collection of requests to succeed / fail together, and this would cross PDU boundaries. Yours, Joel At 12:03 PM 2/8/2005, Alistair Munro wrote: >Hi Joel, all, > >>The question I think we need to cover is "what happens if some of the >>SETs work, and some do not." > >If we are going to be strict about commitment then the entire collection >should be undone if any component fails. Is this being too severe? > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:13: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 MAA26080 for ; Tue, 8 Feb 2005 12:13:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZFQ-000144-VL for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:34: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 <6.00F78266@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 12:13:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57024206 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 12:13:37 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 12:13:37 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020809141104:8705 ; Tue, 8 Feb 2005 09:14:11 -0800 References: 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 02/08/2005 09:14:11 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 09:14:14 AM, Serialize complete at 02/08/2005 09:14:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107882811.1072.46.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 12:13:32 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 11:49, Putzolu, David wrote: > (speaking just as another technical guy here) > > This seems overly complex to me. Is there a common case that motivates > the need for this? > Weiming wants to be able to set data values as he walks hierachies of attributes. As an example, tables which may have cells pointing to other tables which may have cells pointing to other tables etc - and you want to set cell in first table, then cell in following table etc. I think its a reasonable desire, but i contend it is not common. It is fair to punish the uncommon cases and have them do more work (parsing). Hence i would claim its ok to complicate things for that scenario. Unless i missed the target of your comment as to what is complex. [Take a look at some of the examples in the text where i have been capturing things to see some of what i think is common]. cheers, jamal > -David > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Tuesday, February 08, 2005 6:16 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Protocol Operations > > > > I am not sure i got the SETRESULT; going by what Weiming asked for > > earlier, we have the following facilities: > > > > To set data to a 3-deep path offset: > > path-data > > path1 > > optional selector > > path-data > > path2 > > optional selector > > path-data > > path3 > > optional selector > > dataraw > > > > > > If a response is asked back, thats exactly how the response would look > > like as well. > > > > The other way which is to set data on multiple nested paths: > > > > path-data > > path1 > > optional selector > > dataraw > > path-data > > path2 > > optional selector > > dataraw > > path-data > > path3 > > optional selector > > dataraw > > > > Granted the end result will be grossly ineefficient since it > > will have a > > lot of redundant information in the three path-datas above if path1 is > > relative to path2 and path3 is realtive to path2. > > For this we can use what i have seen in a few classifiers as an > > optimization; these sorts of classifiers hacve a "continue" construct > > which translates to "continue looking up where you last left off". > > We can have something similar as a flag - so on path2 and > > path3 it would > > say "the previous path+selector counts as part of this path". > > So path1 + > > its selectors will be part of path2+ its selectors, which is also part > > of path3 and its selectors. Clearly the flag is not useful on > > the first > > path-data it involves inheritance and can be ignored there. > > > > Heres my worry: I think what Weiming wants in this case is a > > corner case > > which while we must satisfy the end result should not break the simple > > design rule of "optimize for the majority" > > > > cheers, > > jamal > > > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > You raise an interesting question of where the element by > > element SET > > > results go. > > > > > > One of the drawbacks of allowing multiple path-data > > elements inside a > > > operation TLV is that it no longer suffices to return the > > response code at > > > the operation TLV level. > > > Therefore, I would presume, we will have to return the > > response codes in > > > the individual path-data TLVs. > > > I would not want to return the results as a separate > > parallel TLV, as that > > > would imply some kind of matching that would get quite > > confusing. I > > > suppose that means that the actual syntax becomes: > > > > > > DATAINFO := [SELECTOR] [+ | + | +] > > > > > > Where SET Result is used only in the response to a SET, and > > occurs where > > > the DATARAW elements were in the set request, indicating > > for each dataraw > > > whether it was successfully set. > > > > > > Yours, > > > Joel > > > > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > >It quite gets to me that the list server often ate my > > posts. I do have > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > >Hopefully this post can work. > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > > > > > and just leave out the "DATA" line. I believe this > > allows the nesting, is > > > > > decidable by the parser, and does what we need. > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > > > > > >Yes, this makes it more clear, but I still see the value > > to modify it to: > > > > > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > > > > > >I suppose a SET request that has format as "path > > path-data1 path-data2 > > > >path-data3", whos response will have format as "path > > path-data1 path-data2 > > > >path-data3 data", the last data TLV is for the SET result > > responses. > > > > > > > >Cheers, > > > >Weiming > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 12:17: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 MAA26368 for ; Tue, 8 Feb 2005 12:17:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyZJ5-00019A-7Y for forces-archive@IETF.ORG; Tue, 08 Feb 2005 12:37: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 <9.00F78144@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 12:17:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57024583 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 12:17:23 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 12:17:22 -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 j18HHMF2016632; Tue, 8 Feb 2005 17:17:22 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 j18HHCSl015947; Tue, 8 Feb 2005 17:17:22 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 M2005020809172200503 ; Tue, 08 Feb 2005 09:17:22 -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); Tue, 8 Feb 2005 09:17:22 -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 Operations Thread-Index: AcUOAZR4kE1+MShSSLKRPVRRZ4xWDQAADt8w X-OriginalArrivalTime: 08 Feb 2005 17:17:22.0289 (UTC) FILETIME=[0D209610:01C50E02] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 8 Feb 2005 09:17:21 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Thanks Jamal. I would be very hesitant to put in more complexity to the protocol=20 than there already is, especially as it already is fairly rich. I've always viewed complexity as a penalty on the entire protocol, so I guess I would phrase the question presented below slightly differently: Is it fair to punish the entire protocol with additional complexity to benefit an uncommon case? Regards, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, February 08, 2005 9:14 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations On Tue, 2005-02-08 at 11:49, Putzolu, David wrote: > (speaking just as another technical guy here)=20 >=20 > This seems overly complex to me. Is there a common case that motivates > the need for this? >=20 Weiming wants to be able to set data values as he walks hierachies of attributes. As an example, tables which may have cells pointing to other tables which may have cells pointing to other tables etc - and you want to set cell in first table, then cell in following table etc.=20 I think its a reasonable desire, but i contend it is not common. It is fair to punish the uncommon cases and have them do more work (parsing). Hence i would claim its ok to complicate things for that scenario. Unless i missed the target of your comment as to what is complex. [Take a look at some of the examples in the text where i have been capturing things to see some of what i think is common]. cheers, jamal > -David >=20 >=20 > > -----Original Message----- > > From: Forwarding and Control Element Separation=20 > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Tuesday, February 08, 2005 6:16 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Protocol Operations > >=20 > > I am not sure i got the SETRESULT; going by what Weiming asked for > > earlier, we have the following facilities: > >=20 > > To set data to a 3-deep path offset: > > path-data > > path1 > > optional selector > > path-data > > path2 > > optional selector > > path-data > > path3 > > optional selector > > dataraw > >=20 > >=20 > > If a response is asked back, thats exactly how the response would look > > like as well. > >=20 > > The other way which is to set data on multiple nested paths: > >=20 > > path-data > > path1 > > optional selector > > dataraw > > path-data > > path2 > > optional selector > > dataraw > > path-data > > path3 > > optional selector > > dataraw > >=20 > > Granted the end result will be grossly ineefficient since it=20 > > will have a > > lot of redundant information in the three path-datas above if path1 is > > relative to path2 and path3 is realtive to path2. > > For this we can use what i have seen in a few classifiers as an > > optimization; these sorts of classifiers hacve a "continue" construct > > which translates to "continue looking up where you last left off". > > We can have something similar as a flag - so on path2 and=20 > > path3 it would > > say "the previous path+selector counts as part of this path".=20 > > So path1 + > > its selectors will be part of path2+ its selectors, which is also part > > of path3 and its selectors. Clearly the flag is not useful on=20 > > the first > > path-data it involves inheritance and can be ignored there. > >=20 > > Heres my worry: I think what Weiming wants in this case is a=20 > > corner case > > which while we must satisfy the end result should not break the simple > > design rule of "optimize for the majority" > >=20 > > cheers, > > jamal > >=20 > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > You raise an interesting question of where the element by=20 > > element SET=20 > > > results go. > > >=20 > > > One of the drawbacks of allowing multiple path-data=20 > > elements inside a=20 > > > operation TLV is that it no longer suffices to return the=20 > > response code at=20 > > > the operation TLV level. > > > Therefore, I would presume, we will have to return the=20 > > response codes in=20 > > > the individual path-data TLVs. > > > I would not want to return the results as a separate=20 > > parallel TLV, as that=20 > > > would imply some kind of matching that would get quite=20 > > confusing. I=20 > > > suppose that means that the actual syntax becomes: > > >=20 > > > DATAINFO :=3D [SELECTOR] [+ | + | = +] > > >=20 > > > Where SET Result is used only in the response to a SET, and=20 > > occurs where=20 > > > the DATARAW elements were in the set request, indicating=20 > > for each dataraw=20 > > > whether it was successfully set. > > >=20 > > > Yours, > > > Joel > > >=20 > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > >It quite gets to me that the list server often ate my=20 > > posts. I do have=20 > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > >Hopefully this post can work. > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > DATAINFO :=3D [SELECTOR] [ | +] > > > > > > > > > > and just leave out the "DATA" line. I believe this=20 > > allows the nesting, is > > > > > decidable by the parser, and does what we need. > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > PATH-DATA TLV :=3D [SELECTOR] [+ | +] > > > > > > > >Yes, this makes it more clear, but I still see the value=20 > > to modify it to: > > > > > > > >PATH-DATA TLV :=3D [SELECTOR] [+] [+] > > > > > > > >I suppose a SET request that has format as "path=20 > > path-data1 path-data2=20 > > > >path-data3", whos response will have format as "path=20 > > path-data1 path-data2=20 > > > >path-data3 data", the last data TLV is for the SET result=20 > > responses. > > > > > > > >Cheers, > > > >Weiming > >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 13:24: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 NAA02036 for ; Tue, 8 Feb 2005 13:24:25 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaLu-0002i5-0A for forces-archive@IETF.ORG; Tue, 08 Feb 2005 13:44: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 <14.00F783AE@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 13:24:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57030470 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 13:24:24 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 13:22:25 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j18IMPMA007820; Tue, 8 Feb 2005 18:22: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 j18IMMSb007643; Tue, 8 Feb 2005 18:22:22 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 M2005020810221516673 ; Tue, 08 Feb 2005 10:22:18 -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); Tue, 8 Feb 2005 10:22:09 -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 Operations Thread-Index: AcUJOuELu42gMp+DTQumovIZabh0mwEy3CEg X-OriginalArrivalTime: 08 Feb 2005 18:22:09.0397 (UTC) FILETIME=[1A063250:01C50E0B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042EC8E2@orsmsx408> Date: Tue, 8 Feb 2005 10:22:05 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Hi Joel, I was wondering we don't need the following Operations: DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL. Let me know what I am missing here, but these Operations do need to be supported. Another comment on the protocol grammar, I still don't see a good reason why we need Flags in PATH. The Operation Flag bits can clearly be supported via the Operation type (ADD, Del, UPDATE) and the Selector bits can also be a subfield in the Operation, rather that part of each PATH. Having Flags as part of PATH seems quite inefficient to me.=20 Also, is this correct in the current grammar -> DATA :=3D [DATARAW] | + ?? Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Wednesday, February 02, 2005 7:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Protocol Operations I think that there are only three operations at the moment: GET SET NOTIFY In terms of the format I presented, the structure of these operations is as=20 follows. A GET request includes one or more base path TLVs and each may include one=20 or more nested path TLVs. Each path TLV may include a KEY TLV for content=20 selection, where the data in the key TLV is the value of the selected key=20 field. A GET response will look like a GET request, with DATA filled in along with=20 each terminal PATH TLV. A SET request include one or more base path TLVs each of which may include=20 one or more nested path TLVs. Each Path TLV may include a KEY TLV to=20 indicate which element of the table is being selected, where the data value=20 in the KEY TLV represents a value being sought. Flags indicate what should=20 happen if the selected entry (index or content selected) is not found. The=20 flags can allow or prohibit creation of an entry that does not exist, and=20 allow or prohibit modification of an entry that does exist. (The=20 combination must not create and must not modify is not particularly useful.) Each terminal path TLV will also have a data block providing the=20 information that is to be placed into the selected element. The selected element may be the whole item identified by a key. It may be=20 a field in the structured identified by a key. There are a couple of interesting cases to be covered. 1) It would be nice to be able to say "create, and give me an index". This=20 would be a case where no index and no key is provided, but a single element=20 is being created. It would seem that we can cover this with the=20 flags. The returned result will include the information as to what index=20 was assigned to the value 2) Any create operation in a table must be checked by the FE logic to=20 ensure that all key values of the new data content are unique in the=20 table. This is a consequence of the requirement that keys be unique. This=20 applies whether the create is using indexing or content keying to identify=20 the new value. 3) Similarly, any modify operation that modifies a table key must be=20 checked by the FE to ensure that uniqueness is met. 3') The corollary to the above is that swapping the key values between two=20 entries may be a little tricky. If both SETs are in the same OPERATION TLV=20 should we require the FE to be smart enough to realize that the values are=20 unique after both changes? Or should we require that one of them get=20 changed to an unused value first? 4) It is perfectly valid to specify a create operation for an entire entry=20 in a table, and specify a key. Depending upon flag settings this will=20 either ensure that the key is not used, or allow overwriting of the entry=20 if it is already there. It is actually valid for the data being written to=20 have a different (but still unique) key value. (It would probably only be=20 useful in a modify operation.) Said another way, changing keys on entries=20 is allowed as long as uniqueness is preserved. Yours, Joel PS: No, I did not talk about Notify. I expect it looks a lot like a GET response, but I have not thought about it much. At 08:34 AM 2/2/2005, Weiming Wang wrote: >Jamal, > >----- Original Message ----- >From: "Jamal Hadi Salim" >Subject: Re: path data textt update > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > Example: "replace all entries which match key1=3D10 with 1111" > > or "for all entries with KEY1=3D10.0.0.24/32, replace table.nh with value > > 3" > > > > I think these are valid operations - therefore search key needs to > > be represented separately from subpath and should not have dependence of > > what the msg type is. >I'm afraid You'v raised a very good point that we need to address=20 >specifically, >that is, how a MODIFY/REPLACE operation will affect our current BNF.=20 >Obviously a >MODIFY operation usually needs to include two data parts in the message:=20 >the old >data(or condition), the new data. I now understand what you are trying is=20 >to use >the KEY to specifically INDICATE it is the old data (or condition) part. I >understand more that this kind of INDICATE is actually realized by the type in >the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" is >specified for the old data (or condition) only. With this thought, I=20 >suppose you >may also mean every field in an LFB attribute can be a KEY, because every=20 >field >can probably be replaced/modified. > >As a result, I have to say yes, such KEYINFO TLV is necessary, or in another >word, should be separately expressed in BNF, but I also have to say the data >format for the KEYINFO TLV is actually the same as the general PATH-DATA=20 >format, >that is, the KEYID there is actually a subpath instead of only a KeyID. > >Now come back to the KEY idea Joel proposed. I think a best way to say Joel's >idea is "not all subfields are allowed as searching indices". I'm sure=20 >this kind >of Keys are only a subset of keys used in the KEYINFO TLV for MODIFY/REPLACE >operations, because as I mentioned above, we should allow all writable=20 >fields in >an attributes replacable, though we not allow some fields as searching=20 >indices. >As a result, to better solve this, I'm afraid we need to see how KEYINFO TLV >should actually be composed. My idea is, for MODIFY operations, the old >data (or >condition) part may include general subpath-data, as well as KEYs as Joel >proposed. > >I'm keeping thinking of this ... > >Cheers, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 13:50: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 NAA04138 for ; Tue, 8 Feb 2005 13:50:37 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyalD-0003IQ-JR for forces-archive@IETF.ORG; Tue, 08 Feb 2005 14:10:58 -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.00F7846B@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 13:50:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57032838 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 13:50:32 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 13:50:27 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9084730 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 13:50:25 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <468F3FDA28AA87429AD807992E22D07E042EC8E2@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208134618.03166458@localhost> Date: Tue, 8 Feb 2005 13:49:29 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042EC8E2@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 We may need a Delete operation to remove table entries. UPDATE / REPLACE / CREATE are currently expected to be flag settings on SET. Depending upon whether we can simplify the protocol operation structure, and whether one prefers flats or type codes, we might be able to make the operations instead of flags. I don't have much of a preference. Jamal like's flags, so I was going with that. SUBSCRIBE / UNSUBSCRIBE is supposed to be a variable setting. Remember that there is only one active CE. Hence, if we have an LFB variable for whether a given event is to be reported, the CE can set or unset that variable. This avoids creating extra state that affects operations but is invisible. (Not sure what CANCEL would be, so I don't know how that would be covered.) Yours, Joel At 01:22 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Hi Joel, > >I was wondering we don't need the following Operations: >DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, >CANCEL. > >Let me know what I am missing here, but these Operations do need to be >supported. > >Another comment on the protocol grammar, I still don't see a good reason >why we need Flags in PATH. The Operation Flag bits can clearly be >supported via the Operation type (ADD, Del, UPDATE) and the Selector >bits can also be a subfield in the Operation, rather that part of each >PATH. Having Flags as part of PATH seems quite inefficient to me. > >Also, is this correct in the current grammar -> >DATA := [DATARAW] | + ?? > > >Regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 02, 2005 7:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Protocol Operations > >I think that there are only three operations at the moment: >GET >SET >NOTIFY > >In terms of the format I presented, the structure of these operations is >as >follows. >A GET request includes one or more base path TLVs and each may include >one >or more nested path TLVs. Each path TLV may include a KEY TLV for >content >selection, where the data in the key TLV is the value of the selected >key >field. >A GET response will look like a GET request, with DATA filled in along >with >each terminal PATH TLV. > >A SET request include one or more base path TLVs each of which may >include >one or more nested path TLVs. Each Path TLV may include a KEY TLV to >indicate which element of the table is being selected, where the data >value >in the KEY TLV represents a value being sought. Flags indicate what >should >happen if the selected entry (index or content selected) is not found. >The >flags can allow or prohibit creation of an entry that does not exist, >and >allow or prohibit modification of an entry that does exist. (The >combination must not create and must not modify is not particularly >useful.) >Each terminal path TLV will also have a data block providing the >information that is to be placed into the selected element. >The selected element may be the whole item identified by a key. It may >be >a field in the structured identified by a key. > >There are a couple of interesting cases to be covered. >1) It would be nice to be able to say "create, and give me an index". >This >would be a case where no index and no key is provided, but a single >element >is being created. It would seem that we can cover this with the >flags. The returned result will include the information as to what >index >was assigned to the value >2) Any create operation in a table must be checked by the FE logic to >ensure that all key values of the new data content are unique in the >table. This is a consequence of the requirement that keys be unique. >This >applies whether the create is using indexing or content keying to >identify >the new value. >3) Similarly, any modify operation that modifies a table key must be >checked by the FE to ensure that uniqueness is met. >3') The corollary to the above is that swapping the key values between >two >entries may be a little tricky. If both SETs are in the same OPERATION >TLV >should we require the FE to be smart enough to realize that the values >are >unique after both changes? Or should we require that one of them get >changed to an unused value first? >4) It is perfectly valid to specify a create operation for an entire >entry >in a table, and specify a key. Depending upon flag settings this will >either ensure that the key is not used, or allow overwriting of the >entry >if it is already there. It is actually valid for the data being written >to >have a different (but still unique) key value. (It would probably only >be >useful in a modify operation.) Said another way, changing keys on >entries >is allowed as long as uniqueness is preserved. > >Yours, >Joel > >PS: No, I did not talk about Notify. I expect it looks a lot like a GET > >response, but I have not thought about it much. > >At 08:34 AM 2/2/2005, Weiming Wang wrote: > >Jamal, > > > >----- Original Message ----- > >From: "Jamal Hadi Salim" > >Subject: Re: path data textt update > > > > > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > > Example: "replace all entries which match key1=10 with 1111" > > > or "for all entries with KEY1=10.0.0.24/32, replace table.nh with >value > > > 3" > > > > > > I think these are valid operations - therefore search key needs to > > > be represented separately from subpath and should not have >dependence of > > > what the msg type is. > >I'm afraid You'v raised a very good point that we need to address > >specifically, > >that is, how a MODIFY/REPLACE operation will affect our current BNF. > >Obviously a > >MODIFY operation usually needs to include two data parts in the >message: > >the old > >data(or condition), the new data. I now understand what you are trying >is > >to use > >the KEY to specifically INDICATE it is the old data (or condition) >part. I > >understand more that this kind of INDICATE is actually realized by the >type in > >the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" >is > >specified for the old data (or condition) only. With this thought, I > >suppose you > >may also mean every field in an LFB attribute can be a KEY, because >every > >field > >can probably be replaced/modified. > > > >As a result, I have to say yes, such KEYINFO TLV is necessary, or in >another > >word, should be separately expressed in BNF, but I also have to say the >data > >format for the KEYINFO TLV is actually the same as the general >PATH-DATA > >format, > >that is, the KEYID there is actually a subpath instead of only a KeyID. > > > >Now come back to the KEY idea Joel proposed. I think a best way to say >Joel's > >idea is "not all subfields are allowed as searching indices". I'm sure > >this kind > >of Keys are only a subset of keys used in the KEYINFO TLV for >MODIFY/REPLACE > >operations, because as I mentioned above, we should allow all writable > >fields in > >an attributes replacable, though we not allow some fields as searching > >indices. > >As a result, to better solve this, I'm afraid we need to see how >KEYINFO TLV > >should actually be composed. My idea is, for MODIFY operations, the old > > >data (or > >condition) part may include general subpath-data, as well as KEYs as >Joel > >proposed. > > > >I'm keeping thinking of this ... > > > >Cheers, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 13:54: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 NAA04441 for ; Tue, 8 Feb 2005 13:54:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyapL-0003OV-73 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 14:15:12 -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.00F785F7@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 13:54:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57033010 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 13:54:45 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 13:54:44 -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 j18Isi6O024784; Tue, 8 Feb 2005 18:54:44 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 j18Isd1J003715; Tue, 8 Feb 2005 18:54:44 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 M2005020810544427260 ; Tue, 08 Feb 2005 10:54:44 -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); Tue, 8 Feb 2005 10:54:44 -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 Operations Thread-Index: AcUODxbRBimMi+PDQQKQymC4XQc3FAAAEl2A X-OriginalArrivalTime: 08 Feb 2005 18:54:44.0518 (UTC) FILETIME=[A75DFC60:01C50E0F] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 8 Feb 2005 10:54:43 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: quoted-printable (chair hat off as usual...) I don't have any objection to flags. I would prefer to use *either* operations *or* flags, but not both. Having two ways to do the same thing in a protocol usually just leads to more test cases and interop problems. -David =20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 08, 2005 10:49 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations We may need a Delete operation to remove table entries. UPDATE / REPLACE / CREATE are currently expected to be flag settings on=20 SET. Depending upon whether we can simplify the protocol operation=20 structure, and whether one prefers flats or type codes, we might be able to=20 make the operations instead of flags. I don't have much of a=20 preference. Jamal like's flags, so I was going with that. SUBSCRIBE / UNSUBSCRIBE is supposed to be a variable setting. Remember=20 that there is only one active CE. Hence, if we have an LFB variable for whether a given event is to be reported, the CE can set or unset that=20 variable. This avoids creating extra state that affects operations but is=20 invisible. (Not sure what CANCEL would be, so I don't know how that would be covered.) Yours, Joel At 01:22 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Hi Joel, > >I was wondering we don't need the following Operations: >DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, >CANCEL. > >Let me know what I am missing here, but these Operations do need to be >supported. > >Another comment on the protocol grammar, I still don't see a good reason >why we need Flags in PATH. The Operation Flag bits can clearly be >supported via the Operation type (ADD, Del, UPDATE) and the Selector >bits can also be a subfield in the Operation, rather that part of each >PATH. Having Flags as part of PATH seems quite inefficient to me. > >Also, is this correct in the current grammar -> >DATA :=3D [DATARAW] | + ?? > > >Regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 02, 2005 7:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Protocol Operations > >I think that there are only three operations at the moment: >GET >SET >NOTIFY > >In terms of the format I presented, the structure of these operations is >as >follows. >A GET request includes one or more base path TLVs and each may include >one >or more nested path TLVs. Each path TLV may include a KEY TLV for >content >selection, where the data in the key TLV is the value of the selected >key >field. >A GET response will look like a GET request, with DATA filled in along >with >each terminal PATH TLV. > >A SET request include one or more base path TLVs each of which may >include >one or more nested path TLVs. Each Path TLV may include a KEY TLV to >indicate which element of the table is being selected, where the data >value >in the KEY TLV represents a value being sought. Flags indicate what >should >happen if the selected entry (index or content selected) is not found. >The >flags can allow or prohibit creation of an entry that does not exist, >and >allow or prohibit modification of an entry that does exist. (The >combination must not create and must not modify is not particularly >useful.) >Each terminal path TLV will also have a data block providing the >information that is to be placed into the selected element. >The selected element may be the whole item identified by a key. It may >be >a field in the structured identified by a key. > >There are a couple of interesting cases to be covered. >1) It would be nice to be able to say "create, and give me an index". >This >would be a case where no index and no key is provided, but a single >element >is being created. It would seem that we can cover this with the >flags. The returned result will include the information as to what >index >was assigned to the value >2) Any create operation in a table must be checked by the FE logic to >ensure that all key values of the new data content are unique in the >table. This is a consequence of the requirement that keys be unique. >This >applies whether the create is using indexing or content keying to >identify >the new value. >3) Similarly, any modify operation that modifies a table key must be >checked by the FE to ensure that uniqueness is met. >3') The corollary to the above is that swapping the key values between >two >entries may be a little tricky. If both SETs are in the same OPERATION >TLV >should we require the FE to be smart enough to realize that the values >are >unique after both changes? Or should we require that one of them get >changed to an unused value first? >4) It is perfectly valid to specify a create operation for an entire >entry >in a table, and specify a key. Depending upon flag settings this will >either ensure that the key is not used, or allow overwriting of the >entry >if it is already there. It is actually valid for the data being written >to >have a different (but still unique) key value. (It would probably only >be >useful in a modify operation.) Said another way, changing keys on >entries >is allowed as long as uniqueness is preserved. > >Yours, >Joel > >PS: No, I did not talk about Notify. I expect it looks a lot like a GET > >response, but I have not thought about it much. > >At 08:34 AM 2/2/2005, Weiming Wang wrote: > >Jamal, > > > >----- Original Message ----- > >From: "Jamal Hadi Salim" > >Subject: Re: path data textt update > > > > > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > > Example: "replace all entries which match key1=3D10 with 1111" > > > or "for all entries with KEY1=3D10.0.0.24/32, replace table.nh = with >value > > > 3" > > > > > > I think these are valid operations - therefore search key needs to > > > be represented separately from subpath and should not have >dependence of > > > what the msg type is. > >I'm afraid You'v raised a very good point that we need to address > >specifically, > >that is, how a MODIFY/REPLACE operation will affect our current BNF. > >Obviously a > >MODIFY operation usually needs to include two data parts in the >message: > >the old > >data(or condition), the new data. I now understand what you are trying >is > >to use > >the KEY to specifically INDICATE it is the old data (or condition) >part. I > >understand more that this kind of INDICATE is actually realized by the >type in > >the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" >is > >specified for the old data (or condition) only. With this thought, I > >suppose you > >may also mean every field in an LFB attribute can be a KEY, because >every > >field > >can probably be replaced/modified. > > > >As a result, I have to say yes, such KEYINFO TLV is necessary, or in >another > >word, should be separately expressed in BNF, but I also have to say the >data > >format for the KEYINFO TLV is actually the same as the general >PATH-DATA > >format, > >that is, the KEYID there is actually a subpath instead of only a KeyID. > > > >Now come back to the KEY idea Joel proposed. I think a best way to say >Joel's > >idea is "not all subfields are allowed as searching indices". I'm sure > >this kind > >of Keys are only a subset of keys used in the KEYINFO TLV for >MODIFY/REPLACE > >operations, because as I mentioned above, we should allow all writable > >fields in > >an attributes replacable, though we not allow some fields as searching > >indices. > >As a result, to better solve this, I'm afraid we need to see how >KEYINFO TLV > >should actually be composed. My idea is, for MODIFY operations, the old > > >data (or > >condition) part may include general subpath-data, as well as KEYs as >Joel > >proposed. > > > >I'm keeping thinking of this ... > > > >Cheers, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:02: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 OAA05091 for ; Tue, 8 Feb 2005 14:02:57 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaxA-0003Z7-VH for forces-archive@IETF.ORG; Tue, 08 Feb 2005 14:23: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 <6.00F786A2@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:02:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57035944 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:02:55 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:02:54 -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 j18J2sw7013802; Tue, 8 Feb 2005 19:02:54 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 j18J2V1J009529; Tue, 8 Feb 2005 19:02:54 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 M2005020811025428555 ; Tue, 08 Feb 2005 11:02:54 -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); Tue, 8 Feb 2005 11:02:54 -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 Operations Thread-Index: AcUODxdfzf9J6R7bRGSMEJ0z09xmpgAAJwdA X-OriginalArrivalTime: 08 Feb 2005 19:02:54.0428 (UTC) FILETIME=[CB6051C0:01C50E10] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042ECA60@orsmsx408> Date: Tue, 8 Feb 2005 11:02:53 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: quoted-printable Having Operations as part of Flags, seems quite inefficient to me. We will have a single Operation TLV which could have multiple PATHs. It will be a lot simpler as well as efficient to have the Operation defined in the beginning of this TLV, rather than in each PATH Flag. Thus my preference.=20 Regarding Subscribe, Unsubscribe, I am fine with having it as a LFB variable setting, but this should be clearly explained in the text.=20 The reason for CANCEL command was basically to nullify or cancel a previously configured operation on the FE which is not done in a certain period of time. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 08, 2005 10:49 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations We may need a Delete operation to remove table entries. UPDATE / REPLACE / CREATE are currently expected to be flag settings on=20 SET. Depending upon whether we can simplify the protocol operation=20 structure, and whether one prefers flats or type codes, we might be able to=20 make the operations instead of flags. I don't have much of a=20 preference. Jamal like's flags, so I was going with that. SUBSCRIBE / UNSUBSCRIBE is supposed to be a variable setting. Remember=20 that there is only one active CE. Hence, if we have an LFB variable for whether a given event is to be reported, the CE can set or unset that=20 variable. This avoids creating extra state that affects operations but is=20 invisible. (Not sure what CANCEL would be, so I don't know how that would be covered.) Yours, Joel At 01:22 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Hi Joel, > >I was wondering we don't need the following Operations: >DEL, UPDATE/REPLACE, DEL ALL, EVENT SUBSCRIBE, EVENT UNSUBSCRIBE, >CANCEL. > >Let me know what I am missing here, but these Operations do need to be >supported. > >Another comment on the protocol grammar, I still don't see a good reason >why we need Flags in PATH. The Operation Flag bits can clearly be >supported via the Operation type (ADD, Del, UPDATE) and the Selector >bits can also be a subfield in the Operation, rather that part of each >PATH. Having Flags as part of PATH seems quite inefficient to me. > >Also, is this correct in the current grammar -> >DATA :=3D [DATARAW] | + ?? > > >Regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Wednesday, February 02, 2005 7:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Protocol Operations > >I think that there are only three operations at the moment: >GET >SET >NOTIFY > >In terms of the format I presented, the structure of these operations is >as >follows. >A GET request includes one or more base path TLVs and each may include >one >or more nested path TLVs. Each path TLV may include a KEY TLV for >content >selection, where the data in the key TLV is the value of the selected >key >field. >A GET response will look like a GET request, with DATA filled in along >with >each terminal PATH TLV. > >A SET request include one or more base path TLVs each of which may >include >one or more nested path TLVs. Each Path TLV may include a KEY TLV to >indicate which element of the table is being selected, where the data >value >in the KEY TLV represents a value being sought. Flags indicate what >should >happen if the selected entry (index or content selected) is not found. >The >flags can allow or prohibit creation of an entry that does not exist, >and >allow or prohibit modification of an entry that does exist. (The >combination must not create and must not modify is not particularly >useful.) >Each terminal path TLV will also have a data block providing the >information that is to be placed into the selected element. >The selected element may be the whole item identified by a key. It may >be >a field in the structured identified by a key. > >There are a couple of interesting cases to be covered. >1) It would be nice to be able to say "create, and give me an index". >This >would be a case where no index and no key is provided, but a single >element >is being created. It would seem that we can cover this with the >flags. The returned result will include the information as to what >index >was assigned to the value >2) Any create operation in a table must be checked by the FE logic to >ensure that all key values of the new data content are unique in the >table. This is a consequence of the requirement that keys be unique. >This >applies whether the create is using indexing or content keying to >identify >the new value. >3) Similarly, any modify operation that modifies a table key must be >checked by the FE to ensure that uniqueness is met. >3') The corollary to the above is that swapping the key values between >two >entries may be a little tricky. If both SETs are in the same OPERATION >TLV >should we require the FE to be smart enough to realize that the values >are >unique after both changes? Or should we require that one of them get >changed to an unused value first? >4) It is perfectly valid to specify a create operation for an entire >entry >in a table, and specify a key. Depending upon flag settings this will >either ensure that the key is not used, or allow overwriting of the >entry >if it is already there. It is actually valid for the data being written >to >have a different (but still unique) key value. (It would probably only >be >useful in a modify operation.) Said another way, changing keys on >entries >is allowed as long as uniqueness is preserved. > >Yours, >Joel > >PS: No, I did not talk about Notify. I expect it looks a lot like a GET > >response, but I have not thought about it much. > >At 08:34 AM 2/2/2005, Weiming Wang wrote: > >Jamal, > > > >----- Original Message ----- > >From: "Jamal Hadi Salim" > >Subject: Re: path data textt update > > > > > > > > > > What about SET | REPLACE? This is not DEL or QUERY .... > > > Example: "replace all entries which match key1=3D10 with 1111" > > > or "for all entries with KEY1=3D10.0.0.24/32, replace table.nh = with >value > > > 3" > > > > > > I think these are valid operations - therefore search key needs to > > > be represented separately from subpath and should not have >dependence of > > > what the msg type is. > >I'm afraid You'v raised a very good point that we need to address > >specifically, > >that is, how a MODIFY/REPLACE operation will affect our current BNF. > >Obviously a > >MODIFY operation usually needs to include two data parts in the >message: > >the old > >data(or condition), the new data. I now understand what you are trying >is > >to use > >the KEY to specifically INDICATE it is the old data (or condition) >part. I > >understand more that this kind of INDICATE is actually realized by the >type in > >the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" >is > >specified for the old data (or condition) only. With this thought, I > >suppose you > >may also mean every field in an LFB attribute can be a KEY, because >every > >field > >can probably be replaced/modified. > > > >As a result, I have to say yes, such KEYINFO TLV is necessary, or in >another > >word, should be separately expressed in BNF, but I also have to say the >data > >format for the KEYINFO TLV is actually the same as the general >PATH-DATA > >format, > >that is, the KEYID there is actually a subpath instead of only a KeyID. > > > >Now come back to the KEY idea Joel proposed. I think a best way to say >Joel's > >idea is "not all subfields are allowed as searching indices". I'm sure > >this kind > >of Keys are only a subset of keys used in the KEYINFO TLV for >MODIFY/REPLACE > >operations, because as I mentioned above, we should allow all writable > >fields in > >an attributes replacable, though we not allow some fields as searching > >indices. > >As a result, to better solve this, I'm afraid we need to see how >KEYINFO TLV > >should actually be composed. My idea is, for MODIFY operations, the old > > >data (or > >condition) part may include general subpath-data, as well as KEYs as >Joel > >proposed. > > > >I'm keeping thinking of this ... > > > >Cheers, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:20: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 OAA06089 for ; Tue, 8 Feb 2005 14:20:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybDl-0003qs-V0 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 14:40: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 <20.00F78619@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:20:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57037293 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:19:55 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:19:54 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9085031 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 14:19:54 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <468F3FDA28AA87429AD807992E22D07E042ECA60@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208141557.03164e90@localhost> Date: Tue, 8 Feb 2005 14:19:01 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECA60@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 I would expect "cancel" to operate on a request level. That is, a PDU carrying OPERATION TLVs would have an ID of some sort for the whole PDU, and a Cancel message would use that same overall ID to indicate what was being cancelled. That is, "cancel" is at a higher syntactic level than we have been discussing. As a separate matter, I think that Cancel is likely to be ambiguous in effect, so I am not sure that we should try to support it. The race conditions are "interesting". Yours, Joel At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote: >The reason for CANCEL command was basically to nullify or cancel a >previously configured operation on the FE which is not done in a certain >period of time. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:39: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 OAA07768 for ; Tue, 8 Feb 2005 14:39:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybWl-0004Ip-M7 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:00: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 <9.00F786D8@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:39:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57038984 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:39:39 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:39:39 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020811401502:9365 ; Tue, 8 Feb 2005 11:40:15 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECA60@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 02/08/2005 11:40:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 11:40:17 AM, Serialize complete at 02/08/2005 11:40:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107891577.1269.98.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 14:39:37 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECA60@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 14:02, Khosravi, Hormuzd M wrote: > Having Operations as part of Flags, seems quite inefficient to me. > We will have a single Operation TLV which could have multiple PATHs. > It will be a lot simpler as well as efficient to have the Operation > defined in the beginning of this TLV, rather than in each PATH Flag. > Thus my preference. I think you meant having "flags as part of the operations" as opposed to "operations as part of Flags"? Otherwise i am not sure which flags you are refering to. Did you read the text i have been posting? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:49: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 OAA08632 for ; Tue, 8 Feb 2005 14:49:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybgB-0004YJ-Q8 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:09: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 <2.00F78993@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:49:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57040137 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:49:19 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:49:19 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j18JnJMA015755; Tue, 8 Feb 2005 19:49:19 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 j18JnESf018073; Tue, 8 Feb 2005 19:49:19 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 M2005020811491803544 ; Tue, 08 Feb 2005 11:49:18 -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); Tue, 8 Feb 2005 11:49: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: [FORCES] Protocol Operations Thread-Index: AcUOFfTpoYs1AVDTTPmZzFdlzL8yvAAACULw X-OriginalArrivalTime: 08 Feb 2005 19:49:19.0075 (UTC) FILETIME=[4727BB30:01C50E17] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042ECBD0@orsmsx408> Date: Tue, 8 Feb 2005 11:49:18 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Yes, I did the text you posted (data_path2.txt) and made the comments based on that. Having Flags in the PATH which define Operations, such as F_REPLACE, F_CREATE, F_APPEND, F_PREPEND seems quite inefficient to me. These should be part of the top-level Operation itself, which defines the Operation TLV. The protocol should not have to parse each PATH to figure out what the operation is. Also, another comment I made -> is this correct in the current grammar -> DATA :=3D [DATARAW] | + ??=20 Let me know, Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Having Operations as part of Flags, seems quite inefficient to me. > We will have a single Operation TLV which could have multiple PATHs. > It will be a lot simpler as well as efficient to have the Operation > defined in the beginning of this TLV, rather than in each PATH Flag. > Thus my preference.=20 I think you meant having "flags as part of the operations" as opposed to "operations as part of Flags"? Otherwise i am not sure which flags you are refering to. Did you read the text i have been posting? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:57:04 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 OAA09396 for ; Tue, 8 Feb 2005 14: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 1CybnX-0004lk-RH for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:17: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 <5.00F788C5@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:57:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57040690 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:56:54 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:56:54 -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 j18Jus6O022391; Tue, 8 Feb 2005 19:56:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j18JurSd025114; Tue, 8 Feb 2005 19:56:54 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 M2005020811565404562 ; Tue, 08 Feb 2005 11:56:54 -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); Tue, 8 Feb 2005 11:56:54 -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 Operations Thread-Index: AcUOEzJtggOnbZVpQKyyiOyOQq37mAABNn6w X-OriginalArrivalTime: 08 Feb 2005 19:56:54.0218 (UTC) FILETIME=[56710AA0:01C50E18] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 8 Feb 2005 11:56:53 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable I'm somewhat worried by how difficult implementing this cancel operation would be. Does the FE have to buffer all commands it ever received (or at least over a window of time) and provide a way to roll them back, even if they where not flagged as a transaction? Seems exceedingly difficult from an implementation point of view!=20 -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 08, 2005 11:19 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations I would expect "cancel" to operate on a request level. That is, a PDU=20 carrying OPERATION TLVs would have an ID of some sort for the whole PDU, and a Cancel message would use that same overall ID to indicate what was being cancelled. That is, "cancel" is at a higher syntactic level than we=20 have been discussing. As a separate matter, I think that Cancel is likely to be ambiguous in=20 effect, so I am not sure that we should try to support it. The race=20 conditions are "interesting". Yours, Joel At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote: >The reason for CANCEL command was basically to nullify or cancel a >previously configured operation on the FE which is not done in a certain >period of time. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 14:59:50 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 OAA09642 for ; Tue, 8 Feb 2005 14:59:50 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybqE-0004p0-PT for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:20:11 -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.00F789CC@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 14:59:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57041049 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 14:59:47 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 14:59:47 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j18JxlMA020966; Tue, 8 Feb 2005 19:59: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 j18JxVSn027211; Tue, 8 Feb 2005 19:59: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 M2005020811594705616 ; Tue, 08 Feb 2005 11:59:47 -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); Tue, 8 Feb 2005 11:59:47 -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 Operations Thread-Index: AcUOEzJ9QrzOMrD7TVqI2b9RfKXVDAABLEtg X-OriginalArrivalTime: 08 Feb 2005 19:59:47.0563 (UTC) FILETIME=[BDC363B0:01C50E18] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042ECC18@orsmsx408> Date: Tue, 8 Feb 2005 11:59:45 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Joel,=20 I agree with your observations here, Cancel (if we decide to support it) should probably be new message type in the header itself. Jamal had introduced this one in the protocol, to support the timeliness requirement. I don't have strong preferences on this, but want to make sure we are all on the same page. What do you guys think about this command ? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 08, 2005 11:19 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations I would expect "cancel" to operate on a request level. That is, a PDU=20 carrying OPERATION TLVs would have an ID of some sort for the whole PDU, and a Cancel message would use that same overall ID to indicate what was being cancelled. That is, "cancel" is at a higher syntactic level than we=20 have been discussing. As a separate matter, I think that Cancel is likely to be ambiguous in=20 effect, so I am not sure that we should try to support it. The race=20 conditions are "interesting". Yours, Joel At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote: >The reason for CANCEL command was basically to nullify or cancel a >previously configured operation on the FE which is not done in a certain >period of time. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 15:06:39 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 PAA10203 for ; Tue, 8 Feb 2005 15:06:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cybwo-0004xs-ST for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:27:00 -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.00F789D2@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 15:06:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57041884 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 15:06:36 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 15:06: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 2005020812071139:9551 ; Tue, 8 Feb 2005 12:07:11 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECBD0@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 02/08/2005 12:07:11 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 12:07:13 PM, Serialize complete at 02/08/2005 12:07:13 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107893193.1072.134.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 15:06:33 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECBD0@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 14:49, Khosravi, Hormuzd M wrote: > Yes, I did the text you posted (data_path2.txt) and made the comments > based on that. > > Having Flags in the PATH which define Operations, such as F_REPLACE, > F_CREATE, F_APPEND, F_PREPEND seems quite inefficient to me. These > should be part of the top-level Operation itself, which defines the > Operation TLV. The protocol should not have to parse each PATH to figure > out what the operation is. The operation actually comes before the path-data. DEL for example is an operation; SET is another etc. This is then followed by the stuff you are seeing posted around which includes flags. The flags do not define the operation perse; they may refine it. Similarly, selectors may refine the path to the data. > Also, another comment I made -> is this correct in the current grammar > -> > DATA := [DATARAW] | + ?? > That hasnt changed as far as i am concerned; Joel posted another scheme of collapsing things but does not change the grammar. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 15:10:55 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 PAA10950 for ; Tue, 8 Feb 2005 15:10:55 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyc0x-00058o-Jm for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:31: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 <17.00F78AB8@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 15:10:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57042319 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 15:10:53 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 15:10: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 2005020812112809:9587 ; Tue, 8 Feb 2005 12:11:28 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECC18@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 02/08/2005 12:11:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 12:11:30 PM, Serialize complete at 02/08/2005 12:11:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107893450.1269.143.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 15:10:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECC18@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Kill the CANCEL now that we dont have TCP as the TML imposed on us. The idea was to cancel a locally or even remotely command stuck on a retransmit queue (due to TCPs head of line blocking). cheers, jamal On Tue, 2005-02-08 at 14:59, Khosravi, Hormuzd M wrote: > Joel, > > I agree with your observations here, Cancel (if we decide to support it) > should probably be new message type in the header itself. Jamal had > introduced this one in the protocol, to support the timeliness > requirement. I don't have strong preferences on this, but want to make > sure we are all on the same page. > > What do you guys think about this command ? > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Tuesday, February 08, 2005 11:19 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Protocol Operations > > I would expect "cancel" to operate on a request level. That is, a PDU > carrying OPERATION TLVs would have an ID of some sort for the whole PDU, > > and a Cancel message would use that same overall ID to indicate what was > > being cancelled. That is, "cancel" is at a higher syntactic level than > we > have been discussing. > > As a separate matter, I think that Cancel is likely to be ambiguous in > effect, so I am not sure that we should try to support it. The race > conditions are "interesting". > > Yours, > Joel > > At 02:02 PM 2/8/2005, Khosravi, Hormuzd M wrote: > >The reason for CANCEL command was basically to nullify or cancel a > >previously configured operation on the FE which is not done in a > certain > >period of time. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 15:17: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 PAA12036 for ; Tue, 8 Feb 2005 15:17:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyc7h-0005Lm-EW for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:38: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.00F789C7@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 15:17:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57042762 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 15:17:48 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 15:17:48 -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 j18KHm6O032115; Tue, 8 Feb 2005 20:17:48 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 j18KHbSt010746; Tue, 8 Feb 2005 20:17:48 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 M2005020812174809279 ; Tue, 08 Feb 2005 12:17:48 -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); Tue, 8 Feb 2005 12:17:48 -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 Operations Thread-Index: AcUOGbYuAhEUfU4WQ+uM4tbDj0LNcAAANCUQ X-OriginalArrivalTime: 08 Feb 2005 20:17:48.0537 (UTC) FILETIME=[4212EE90:01C50E1B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042ECC60@orsmsx408> Date: Tue, 8 Feb 2005 12:17:47 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable F_REPLACE / F_CREATE, etc can be represented as CREATE, REPLACE Operations instead of Flags in the several PATHs contained in a SET Operation TLV. Is there any value in having these as flags rather than the top level operation itself ? I have stated the cons of doing this. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >=20 > Having Flags in the PATH which define Operations, such as F_REPLACE, > F_CREATE, F_APPEND, F_PREPEND seems quite inefficient to me. These > should be part of the top-level Operation itself, which defines the > Operation TLV. The protocol should not have to parse each PATH to figure > out what the operation is. The operation actually comes before the path-data. DEL for example is an operation; SET is another etc. This is then followed by the stuff you are seeing posted around which includes flags. The flags do not define the operation perse; they may refine it. Similarly, selectors may refine the path to the data. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 15:33: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 PAA14346 for ; Tue, 8 Feb 2005 15:33:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CycMS-0005qc-KA for forces-archive@IETF.ORG; Tue, 08 Feb 2005 15:53: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 <1.00F78B5A@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 15:33:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57044108 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 15:33:05 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 15:33: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 2005020812333993:9747 ; Tue, 8 Feb 2005 12:33:39 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECC60@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 02/08/2005 12:33:40 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 12:33:42 PM, Serialize complete at 02/08/2005 12:33:42 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107894781.1073.174.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 15:33:01 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECC60@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 15:17, Khosravi, Hormuzd M wrote: > F_REPLACE / F_CREATE, etc can be represented as CREATE, REPLACE > Operations instead of Flags in the several PATHs contained in a SET > Operation TLV. Is there any value in having these as flags rather than > the top level operation itself ? I have stated the cons of doing this. You cannot remove the flags. If you could it may make sense to move those two to the operations level. As it stands right now, either have equal merit. If you look at the examples i posted, it is possible infact to replace and create different items within one SET operation - but i dont think this in itself stands as a reason for their existence. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 15:44: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 PAA15846 for ; Tue, 8 Feb 2005 15:44:03 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CycWz-0006J3-Po for forces-archive@IETF.ORG; Tue, 08 Feb 2005 16:04: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 <4.00F78B90@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 15:43:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57044898 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 15:43:52 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 15:43: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 2005020812442837:9821 ; Tue, 8 Feb 2005 12:44:28 -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 02/08/2005 12:44:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 12:44:30 PM, Serialize complete at 02/08/2005 12:44:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107895430.1073.186.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 15:43:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: path data discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit To the chairs: Could we put a time limit towards reaching rough consensus of some form on the path data? It is my belief that we have already covers what Weiming needs. I provide an example at the end of this email to show how to achieve that with the two examples i tried to show earlier (nested vs flat path-datas). I am then going to put that in the doc and release it. Could we put say a week after that to close discussion? I am sure there will be some small edges left over, but i think we are dragging over little issues at this point and the main obstacles are done with if we agree on this one last item. Joel and Weiming please read through long example at the end of this email and comment. cheers, jamal Weiming would like to update different items on a hierachy of data. So this example is there to show how that can be done with the current BNF. Consider table 6 which is defined as: table6: type array, ID = 8 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type type-A type-A: a1, type u32, ID 1, a2, type array ID2 ,array elements of type type-B type-B: b1, type u32, ID 1 b2, type u32, ID 2 So lets say we wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.1 to 222 table6.10.p2.20.a2.30.b1 to 333 in one message and one operation. There are two ways to do this: a) using nesting operation = SET Path-data TLV IDCount = 2, IDs=6.10 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : IDCount = 2, IDs=2.20 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=2.30.1 DATARAW TLV: L=XXXX, V = {333} b) using a flat path data operation = SET Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=6.10.1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : flags = F_REPLACE, IDCount = 5, IDs=6.10.1.20.1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 7, IDs=6.10.1.20.1.30.1 DATARAW TLV: L=XXXX, V = {333} As i was hinting in posting earlier, if you look at the IDs as you keep going to the next path, you will see that they repeat the previous path. If we could say "inherit previous path" via a flag such as F_INHERIT then we could have an optimization and save a few bytes (the first one will have 3 IDs but the next two will have 2 each) From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:00: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 QAA18458 for ; Tue, 8 Feb 2005 16:00:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CycnF-00077h-3T for forces-archive@IETF.ORG; Tue, 08 Feb 2005 16:21:10 -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.00F78BA3@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:00:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57046656 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:00:46 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:00:44 -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 j18L0iw7003426 for ; Tue, 8 Feb 2005 21:00:44 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 j18L0LT3015672 for ; Tue, 8 Feb 2005 21:00:44 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 M2005020813004317896 for ; Tue, 08 Feb 2005 13:00:43 -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, 8 Feb 2005 13:00:43 -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 Operations Thread-Index: AcUOHWl/inJa7/eWQfGab2iRG/rKHQAAriNw X-OriginalArrivalTime: 08 Feb 2005 21:00:43.0896 (UTC) FILETIME=[411B8780:01C50E21] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E042ECD47@orsmsx408> Date: Tue, 8 Feb 2005 13:00:43 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Here is what I am suggesting, The Operation TLV =3D =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation (ADD) | Flags | Length | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ + ~ | | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Operations =3D ADD/CREATE, DEL, UPDATE/REPLACE. I guess DEL ALL =3D=3D DEL followed by a Table ID (for example) so that = is not needed Flags =3D SELECTOR Bits -->00: indicates absence of the selector=20 -->01(F_SELTAB): indicates what follows is a table. The path should be sufficient to point to a table; so this flag is redundant but here for completion sake -->10(F_SELBLK): indicates that what follows is a BLKINFO -->11(F_SELKEY): Indicates what follows is a KEYINFO Let me know why this wont work, or what I am missing here ? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim You cannot remove the flags. If you could it may make sense to move those two to the operations level. As it stands right now, either have equal merit. If you look at the examples i posted, it is possible infact to replace and create different items within one SET operation - but i dont think this in itself stands as a reason for their existence.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:26: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 QAA24961 for ; Tue, 8 Feb 2005 16:26:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydBs-0000tG-Tn for forces-archive@IETF.ORG; Tue, 08 Feb 2005 16:46: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 <12.00F78D18@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:26:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57048131 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:26:09 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:26:09 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020813264530:10142 ; Tue, 8 Feb 2005 13:26:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECD47@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 02/08/2005 01:26:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 01:26:47 PM, Serialize complete at 02/08/2005 01:26:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107897967.1073.208.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 16:26:07 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECD47@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Hormuzd, I understood you earlier and yes that would work, but like i said earlier (text still at the end of this email actually): Why would this have _more_ merit than whats there right now. Essentially its a philosphical question: Is the glass half full or half empty? If you feel strongly about it, please open an issue report and we can revisit it later. cheers, jamal On Tue, 2005-02-08 at 16:00, Khosravi, Hormuzd M wrote: > Here is what I am suggesting, > > The Operation TLV = > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation (ADD) | Flags | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ + > ~ > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Operations = ADD/CREATE, DEL, UPDATE/REPLACE. > I guess DEL ALL == DEL followed by a Table ID (for example) so that is > not needed > Flags = SELECTOR Bits > -->00: indicates absence of the selector > -->01(F_SELTAB): indicates what follows is a table. The > path should be sufficient to point to a table; so this flag > is redundant but here for completion sake > -->10(F_SELBLK): indicates that what follows is a BLKINFO > -->11(F_SELKEY): Indicates what follows is a KEYINFO > > Let me know why this wont work, or what I am missing here ? > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > You cannot remove the flags. If you could it may make sense to move > those two to the operations level. As it stands right now, either have > equal merit. If you look at the examples i posted, it is possible infact > to replace and create different items within one SET operation - but i > dont think this in itself stands as a reason for their existence. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:29: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 QAA25669 for ; Tue, 8 Feb 2005 16:29:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydFA-00015W-Kq for forces-archive@IETF.ORG; Tue, 08 Feb 2005 16:50: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.00F78D58@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:29:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57048341 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:29:37 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:29:37 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9086707 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 16:29:37 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <468F3FDA28AA87429AD807992E22D07E042ECBD0@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208162003.03169298@localhost> Date: Tue, 8 Feb 2005 16:28:12 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E042ECBD0@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At the moment, in fact, the following are allowed in a SET operation inside a path-data TLV after the path and the optional selector: IF there is no selector: (1) one DATARAW or (2) multiple PATH-DATA TLVs, each of which is to be interpretted in the context of the containing path-data If there is a selector, and it selects one thing, then the above still applies. If there is a selector, and it selects multiple things, then one is allowed to have (3) one DATARAW, to be applied to all the items selected (4) n DATARAW, equal to the number of items selected (5) n PATH-DATA, one to be applied to each item selected (6) one PATH-DATA to be mapped against each item selected. The Selector is used for content keying (which selects a single item) or for BLK selection. Note that if key's are not unique then it is not possible o know how many things will be selected by a content selection. Please let us stay away from that. Note further that at the moment we at least have the simplification that one can not do blocks and keys at the same time. Note that all 6 of the cases above have been requested explicitly on the list. I would be more than happy to see a reduction in the number of combinations we support. And I am VERY happy to see any comments from someone other than me, Weiming, and Jamal. Thank you, Joel PS: Successful GET responses look like SET requests. GET requests can not have DATARAW elements, but can have nested PATH-DATA. DELETE requests would parallel GETs. At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Also, another comment I made -> is this correct in the current grammar >-> >DATA := [DATARAW] | + ?? From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:36: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 QAA27352 for ; Tue, 8 Feb 2005 16:36:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydLT-0001a1-8S for forces-archive@IETF.ORG; Tue, 08 Feb 2005 16:56: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 <6.00F78DCD@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:36:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57049117 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:36:07 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:36: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 2005020813363627:10221 ; Tue, 8 Feb 2005 13:36:36 -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 02/08/2005 01:36:36 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 01:36:44 PM, Serialize complete at 02/08/2005 01:36:44 PM Content-Type: multipart/mixed; boundary="=-qDgtwZNqhKbZYDmIwlns" Approved-By: Jamal Hadi Salim Message-ID: <1107898558.1072.219.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 16:35:58 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: even more updated path data doc To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 66037b5f7faeb7f674181c7897ecb680 --=-qDgtwZNqhKbZYDmIwlns Content-Type: text/plain Content-Transfer-Encoding: 7bit Ok, new update; change log $Log: data_path2.txt,v $ -Revision 1.9 2005/02/04 03:35:49 hadi +Revision 1.11 2005/02/08 21:34:07 hadi +added example per Weimings trail with data sets +this is example 17 now + +Revision 1.10 2005/02/08 20:48:48 hadi +updated with Joels comment on rearranging BNF +Its not very readable, so just put a comment on how it +would look like and leave it as it was before. + --=-qDgtwZNqhKbZYDmIwlns 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 desire to speed up the path-data discussion up. NOTE: By the time we get to the path-data part of the message we already know what the FE, LFB and instance of LFB being referenced is. 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] 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) Atomicity for operations is defined in the main header flags. 4) verbosity needed in response is defined in main headers flags. Terminology ----------- Add details of different terms here (example terminal, path target etc) A possible path-data layout --------------------------- The BNF used here is conformant to the syntax used by the DIAMTER protocol. i.e. i ) A TLV will have the word "TLV" following it ii) <> encloses a _mandatory_ component iii) [] encloses an optional component iv) + implies "one or more" v) Missing <> or [] implies a literal/terminal TODO: Fix this later to conform to the ABNF described in RFC 2234. OPER TLV : = + PATH-DATA TLV := [DATAINFO] PATH := flags IDcount IDs DATAINFO := [SELECTOR] [DATA] SELECTOR := [BLKINFO] | [KEYINFO] DATA := [DATARAW] | + KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] DATARAW TLV := encoded data which may nest DATARAW TLVs TODO: Fix this grammar so it matches the RFC 2234 ABNF style description -> PATH: The path to the data being referenced -> flags (16 bits) are used to further refine the operation to be applied on the Path. More on these later. -> IDcount(16 bit): count of 32 bit IDs -> IDs: one or more 32bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. -> DATAINFO Optional piece that selects the path further and may optionaly contain DATA if needed by the operation. As an example a GET or DEL may not have DATA. -> SELECTOR is an optional construct that further defines the PATH. The presence of a selector is dependent on the PATH IDs and the flags. The PATH would point to a table and the flags would define what selector follows (one of BLKINFO or KEYINFO). Refer to flags description further below. -> DATA may contain DATARAW or further PATH-DATA selection -> DATARAW contains "the data" whose path is selected. NOTE NOTE: ---------- PATH, DATAINFO and DATA are really place holders and not TLVs. For this reason, one could describe the PATH-DATA TLV as: PATH-DATA TLV := [[SELECTOR] [DATA]] or PATH-DATA TLV := [[SELECTOR] [[DATARAW] | +]] or simply: PATH-DATA TLV := [[SELECTOR] [[DATARAW] | +]] However since this is not good eye candy, we will leave the BNF as described above. DATARAW --------- This data is packed in such a way that a receiver of such data with knowledge of the path can correlate what it means by infering in the LFB definition. This is an optimization that helps packing the data. In other words: "It is assumed that the type of the data can be inferred by the context in which data is used. Hence, data will not include its type information. The basis for the inference is typically the LFB class id and the path." OPEN ISSUE: There is another view of how DATA should be represented posted a while back by Zsolt/Steve. We need to review it and compare against the scheme described here. The criteria is a) efficiency of encoding b)efficiency of parsing and decoding and c) the packaging overhead. DATA PACKING RULEs The scheme used in this doc adheres to the following rules: a)The Value of DATARAW TLV will contain the data being transported. This data will be as was described in the LFB definition. b) By definition in the Forces protocol, all TLVs are 32 bit aligned. Therefore because DATARAW is a TLV, elements not aligned in 32 bit values will be padded. As an example a 16 bit value will have an extra 16 bit pad; however two 16 bits values in a structure will be shipped together with no padding etc. c) Variable sized data will be encapsulated inside another DATARAW TLV inside the V of the outer TLV. For example of this see use case #13. d) When a table is refered in the PATH (ids), then the RAWDATA's V will contain that tables row content prefixed by its 32 bit index/subscript OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing to a row in table; in such a case, the RAWDATA's V will only contain the content sans the index in order to avoid ambiguity. flags ----- NOTE: got rid of exclusivity flag based on discussions with Joel. I) SELECTOR Bits Two bits are reserved for selecting and further refining what follows the path. This could be either BLKINFO or KEYINFO. -->00: indicates absence of the selector This is the only case where the path is allowed to have a mix of field IDs and indexes. -->01(F_SELTAB): indicates what follows is a table. The path should be sufficient to point to a table; so this flag is redundant but here for completion sake -->10(F_SELBLK): indicates that what follows is a BLKINFO -->11(F_SELKEY): Indicates what follows is a KEYINFO II) OPERATION Bits --> 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. OPEN!! Controvesial, still under investigation flags: --> F_APPEND Add to the end of the object list/table. This could create xplicates (i.e dup/triplicates etc) --> F_PREPEND Add as the first entry in a table. This could create xplicates (i.e dup/triplicates etc) --> F_NEEDIX Utility flag used in conjunction with F_CREATE to indicate a request for a table row entry without specifying the row index. In such a case the recepient (FE) which receives this request will select the available index and report it back if the main header requested for a verbose response. Relation of operational flags with global message flags: --------------------------------------------------------- Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. 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*(CNT of indices) Content path selection --------------------- The KEY_INFO TLV will describe the KEY as well as associated KEY data. KEYs used for content searches are restricted and described in the LFB definition. The use cases below show some sample operations. 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 KEY: nhkey, ID = 1, V = t2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 KEY: akey, ID = 1, V = { j1,j2 } 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 KEY: mykey, ID = 1, V = { j1} table5: type array, ID = 7 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type-X Type-X: x1, ID 1, type u32 x2, ID2 , type u32 KEY: tkey, ID = 1, V = { x1} TODO: DRAW a sample diagram of a table that shows rows and columns since that seems to have caused confusion All examples will show an attribute suffixed with "v" or "val" to indicate the value of the referenced attribute. example for attribute foo2, foo1v or foo1value will indicate the value of foo1. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection. TODO: FIXME - Some examples show results while others dont - Some examples show operations in hierachy others dont 1) To get foo1 OPER = GET Path-data TLV: IDCount = 1, IDs = 1 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 1 DATARAW TLV L = 8, V = foo1v 2) to set foo2 to 10 OPER = SET Path-data TLV: flags = F_REPLACE, IDCount = 1, IDs = 2 DATARAW 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) OPER = GET Path-data TLV: IDCount = 1, IDs = 4 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 4 DATARAW TLV: L = XXX, V= a series of: index, j1value,j2value entries 4) Block operations To create entry 0-5 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) ALTERNATIVE (consumes more bits on the wire in this case): OPER = SET Path-data TLV: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV: L = XXX, V= 0, j1value, j2value 1, j1value, j2value 2, j1value, j2value 3, j1value, j2value 4, j1value, j2value 5, j1value, j2value 5) Block operations (with holes) To replace entry 0,2 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_REPLACE | F_SELBLK , IDCount = 1, IDs=4 BLK_LIST_INDEX TLV, L = XXX V = 0,2 DATARAW TLV, Length = XXX, V = j1value,j2value j1value,j2value 6) Getting rows To get first entry of table2 OPER = GET Path-data TLV: IDCount = 2, IDs=4.0 Result: Path-data TLV: IDCount = 2, IDs=4.0 DATARAW TLV, Length = XXX, V = j1value,j2value entry 7) to get entry 0-5 of table2 using BLK operations OPER = GET Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 TBD: What to do when say entry 1 doesnt exist? Assuming all of entries 0-5 available Result: Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) Alternative: Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV: L = XXX, V= 0, j1value, j2value 1, j1value, j2value 2, j1value, j2value 3, j1value, j2value 4, j1value, j2value 5, j1value, j2value 8) Create a row in table2, index 5 OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK, IDCount = 1, IDs=4 BLK_LIST_INDEX TLV V = 5 DATARAW TLV, Length = XXX j1value,j2value OR: flags = F_CREATE, IDCount = 1, IDs=4.5 DATARAW TLV, Length = XXX j1value,j2value 9) an example of "create and give me an index" Assuming we asked for verbose response back. Talk to Joel, i think we need a flag "need IDX" OPER = SET Path-data TLV: flags = F_NEEDIDX, F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX j1value,j2value Result OPER = SET Path-data TLV: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX index, j1value,j2value 10) Dump contents of table1, OPER = GET Path-data TLV: IDCount = 1, IDs=3 Result: Path-data TLV IDCount = 1, IDs=3 DATARAW TLV, Length = XXXX index, t1value, t2value . . 11) get _all_ row entries from table4 where j1=100 Assuming j1 is an accepted key and its keyid is 1 OPER = GET Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO TLV = {KEYID =1 KEY_DATA=100} Result: Path-data TLV: IDCount = 1, IDs=6 DATARAW TLV, Length = XXXX index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value 12) delete first 10 row entries with KEY match (j1=100, j2=200) in table 2, starting at index 10. OPER = DEL Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Path-data TLV: flags = F_SELBLK IDCount = 1, IDs=4 BLK_CNT_INDEX TLV start = 10 count = 10 Result: This assumes we have asked for the full results back in the main header. Assuming we deleted 3 at indeces 11, 13, and 18. Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV, Length = XXXX 11,j1value,j2value 13,j1value,j2value 18,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. OPER = GET Path-data TLV: IDCount = 1, IDs=5 Result: Path-data TLV: IDCount = 1, IDs=5 DATARAW TLV, Length = XXXX index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev . . . 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. OPER = SET Path-TLV: flags = F_CREATE, IDCount = 2, IDs=4.20 DATARAW TLV, V= j1value,j2value // Operation 2: Update table1 entries which // were pointing to t2 = 10 to now point to 20 OPER = SET Path-data TLV: flags = F_REPLACE | F_SELKEY, IDCount = 1, IDs=3 KEYINFO = {KEYID = 1 KEY_DATA=10} DATARAW TLV, V= 20 Result: //first operation, SET OPER = SET Path-data TLV IDCount = 1, IDs=4 DATARAW TLV, V = 20,j1value,j2value //second opertion SET - assuming 3 entries were updated OPER = SET Path-data TLV IDCount = 1, IDs=3 // assuming 16, 36,95 were set DATARAW TLV, Length = XXXX 16,t1value, 20 36,t1value, 20 95,t1value, 20 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-data TLV Flags = F_SELBLK, IDCount = 1, IDs=6 // select the rows BLK_LIST_INDEX, L = XXX V = {1,3,5,7,9} // select individual columns and set Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {100} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=2 DATARAW TLV: L=XXXX, V = {200} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=3 DATARAW TLV: L=XXXX, V = {300} 16) Table of table examples a) to get x1 from table10 row with index 4, inside table5 entry 10 we would have: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 Results: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 DATARAW TLV: L=XXXX, V = {x1 value} b) from all table5's rows, get the x1s of the 4th element of their table10 operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 Results: operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 DATARAW TLV: L=XXXX, V = {x1 values} Note that the length of the DATARAW TLV will tell how many x1 entries are there (assuming we know what the size of each x1 is) c) from table5's row 10 table10, get X2s based on on the value of x1 equlaing 10 (recal x1 is KeyID 1) operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 //select x2 Results: operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 DATARAW TLV: L=XXXX, V = {x2 values} Note that the length of the DATARAW TLV will tell how many x2 entries are there (assuming we know what the size of each x2 is) 17) Further example of table of table Weiming would like to update different items on a hierachy of data. So this example is there to show how that can be done with the current BNF. Consider table 6 which is defined as: table6: type array, ID = 8 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type type-A type-A: a1, type u32, ID 1, a2, type array ID2 ,array elements of type type-B type-B: b1, type u32, ID 1 b2, type u32, ID 2 So lets say we wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.1 to 222 table6.10.p2.20.a2.30.b1 to 333 in one message and one operation. There are two ways to do this: a) using nesting operation = SET Path-data TLV IDCount = 2, IDs=6.10 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : IDCount = 2, IDs=2.20 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=2.30.1 DATARAW TLV: L=XXXX, V = {333} b) using a flat path data operation = SET Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=6.10.1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : flags = F_REPLACE, IDCount = 5, IDs=6.10.1.20.1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 7, IDs=6.10.1.20.1.30.1 DATARAW TLV: L=XXXX, V = {333} As i was hinting in posting earlier, if you look at the IDs as you keep going to the next path, you will see that they repeat the previous path. If we could say "inherit previous path" via a flag such as F_INHERIT then we could have an optimization and save a few bytes. $Log: data_path2.txt,v $ Revision 1.10 2005/02/08 20:48:48 hadi updated with Joels comment on rearranging BNF Its not very readable, so just put a comment on how it would look like and leave it as it was before. Revision 1.9 2005/02/03 22:35:49 hadi rearranged text and redid the use cases to match changed BNF Revision 1.8 2005/02/02 20:19:10 hadi incorporating Joels text and Weimings input 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 --=-qDgtwZNqhKbZYDmIwlns-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:42: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 QAA29027 for ; Tue, 8 Feb 2005 16:42:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydRG-00027k-2D for forces-archive@IETF.ORG; Tue, 08 Feb 2005 17:02: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.00F78DAF@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:42:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57049407 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:42:05 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:42:05 -0500 Received: from ncs.bris.ac.uk ([137.222.10.36]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1Cyd7T-00074l-El for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 21:42:05 +0000 Received: from host81-157-60-147.range81-157.btcentralplus.com ([81.157.60.147] helo=[192.168.0.3]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Cyd7T-0000zh-3h for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 21:42:03 +0000 References: <468F3FDA28AA87429AD807992E22D07E042ECC18@orsmsx408> <1107893450.1269.143.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:01JHAZVInVeshcsZK+UorWRr1c0o93ZJbmR7Zh2pJ4Uoeejr8=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 X-Spam-Level: / Approved-By: Alistair Munro Message-ID: Date: Tue, 8 Feb 2005 21:42:01 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107893450.1269.143.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi all, Going back to earlier messages today, personally, I am happy with GET, SET and NOTIFY, or ADD, REPLACE, etc. as top level commands. Joel wrote recently to answer part of my earlier question about rollback (or cancelling), which, as he deduced correctly, was about transaction boundaries - i.e. there's no problem provided you know what ID's are being rolled back and what operations they refer to. Given this, if you want to call it CANCEL, that's fine by me - better than some of the impenetrable transactional terms. I think I'm agreeing with Joel here, although I don't understand where the race arises - with just one CE at least, and with more than one, the atomicity/isolation rules are intended to avoid such races. But I don't think any scheme would work for multiple CEs controlling the same multiple FEs - "interesting" indeed! The other part of my question, which I didn't make clear, was that, for a CE controlling multiple FEs, *any* failure within a [sequence of] operations named by the same ID must cause all those operations with that ID to be rolled back for all FEs, including those that offered success. One-to-one there is no problem. > [Jamal wrote] Kill the CANCEL now that we dont have TCP as the TML imposed on us. > The idea was to cancel a locally or even remotely command stuck on a > retransmit queue (due to TCPs head of line blocking). But I am out of touch here, and apologies if I'm covering old ground. Is TCP forbidden? I've used TCP to support this kind of thing and it sure does block. However, 2-phase commit is intended to get round this (among other failures) in a consistent way, although a severely untimely one in this case. The connection must be closed, which will freeze the operations and data in progress (isolation) consistently at both ends until the recovery or abort phase starts in a new connection. This isn't a transport layer issue per se: I think anything that behaved the same way as TCP would have a similar problem - any queue can block. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 16:47:17 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 QAA01014 for ; Tue, 8 Feb 2005 16:47:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydWB-0002gu-5V for forces-archive@IETF.ORG; Tue, 08 Feb 2005 17:07: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 <2.00F78EB8@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 16:47:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57049637 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 16:46:50 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 16:46:50 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j18LkoMA008653; Tue, 8 Feb 2005 21:46:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j18LkoSd022088; Tue, 8 Feb 2005 21:46:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005020813465020399 ; Tue, 08 Feb 2005 13:46:50 -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); Tue, 8 Feb 2005 13:46:31 -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 Operations Thread-Index: AcUOJWYl22tCi8y4SYCf04ENPJBJkgAAZ1Jg X-OriginalArrivalTime: 08 Feb 2005 21:46:31.0411 (UTC) FILETIME=[A6C10C30:01C50E27] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 8 Feb 2005 13:46:30 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Thanks for the nice clear explanation Joel. I believe I understand the use of (1) and (2). It seems to me that (3), (4), (5), and (6) are achievable using multiple (1)s and (2)s, perhaps in combination with the transactional flags. Is that true?=20 If it is true, I guess the question I would have is how common do we expect situations to arise where we need (3-6)? If it is a rare thing, then I would urge getting rid of the complexity and just paying a few extra bytes in encoding by doing multiple (1)s and (2s) in the rare cases where=20 multiple similar operations are actually needed. -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 08, 2005 1:28 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations At the moment, in fact, the following are allowed in a SET operation inside=20 a path-data TLV after the path and the optional selector: IF there is no selector: (1) one DATARAW or (2) multiple PATH-DATA TLVs, each of which is to be interpretted in the context of the containing path-data If there is a selector, and it selects one thing, then the above still applies. If there is a selector, and it selects multiple things, then one is allowed=20 to have (3) one DATARAW, to be applied to all the items selected (4) n DATARAW, equal to the number of items selected (5) n PATH-DATA, one to be applied to each item selected (6) one PATH-DATA to be mapped against each item selected. The Selector is used for content keying (which selects a single item) or for BLK selection. Note that if key's are not unique then it is not possible o know how many=20 things will be selected by a content selection. Please let us stay away from that. Note further that at the moment we at least have the simplification that one can not do blocks and keys at the same time. Note that all 6 of the cases above have been requested explicitly on the list. I would be more than happy to see a reduction in the number of=20 combinations we support. And I am VERY happy to see any comments from someone other than me,=20 Weiming, and Jamal. Thank you, Joel PS: Successful GET responses look like SET requests. GET requests can not=20 have DATARAW elements, but can have nested PATH-DATA. DELETE requests=20 would parallel GETs. At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Also, another comment I made -> is this correct in the current grammar >-> >DATA :=3D [DATARAW] | + ?? From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 17:59: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 RAA12478 for ; Tue, 8 Feb 2005 17:59:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyee1-0006QB-DJ for forces-archive@IETF.ORG; Tue, 08 Feb 2005 18:19: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.00F79134@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 17:59:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57055656 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 17:58:58 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 17:58:57 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020814592695:10899 ; Tue, 8 Feb 2005 14:59:26 -0800 References: <1107898558.1072.219.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 02/08/2005 02:59:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 02:59:35 PM, Serialize complete at 02/08/2005 02:59:35 PM Content-Type: multipart/mixed; boundary="=-uO80QMXEMvxOENdlHiom" Approved-By: Jamal Hadi Salim Message-ID: <1107903528.1089.52.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 17:58:48 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: even more updated path data doc To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107898558.1072.219.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 935fcc3d6c448ae30077dce3cfc94471 --=-uO80QMXEMvxOENdlHiom Content-Type: text/plain Content-Transfer-Encoding: 7bit oops posted version 1.10 instead of 1.11; repost - apologies for anyone who looked at the doc already. cheers, jamal --=-uO80QMXEMvxOENdlHiom 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 desire to speed up the path-data discussion up. NOTE: By the time we get to the path-data part of the message we already know what the FE, LFB and instance of LFB being referenced is. 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] 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) Atomicity for operations is defined in the main header flags. 4) verbosity needed in response is defined in main headers flags. Terminology ----------- Add details of different terms here (example terminal, path target etc) A possible path-data layout --------------------------- The BNF used here is conformant to the syntax used by the DIAMTER protocol. i.e. i ) A TLV will have the word "TLV" following it ii) <> encloses a _mandatory_ component iii) [] encloses an optional component iv) + implies "one or more" v) Missing <> or [] implies a literal/terminal TODO: Fix this later to conform to the ABNF described in RFC 2234. OPER TLV : = + PATH-DATA TLV := [DATAINFO] PATH := flags IDcount IDs DATAINFO := [SELECTOR] [DATA] SELECTOR := [BLKINFO] | [KEYINFO] DATA := [DATARAW] | + KEYINFO TLV := KEYID KEY_DATA BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX] DATARAW TLV := encoded data which may nest DATARAW TLVs TODO: Fix this grammar so it matches the RFC 2234 ABNF style description -> PATH: The path to the data being referenced -> flags (16 bits) are used to further refine the operation to be applied on the Path. More on these later. -> IDcount(16 bit): count of 32 bit IDs -> IDs: one or more 32bit IDs (whose count is given by IDcount) defining the main path. Depending on the flags, IDs could be field IDs only or a mix of field and dynamic IDs. -> DATAINFO Optional piece that selects the path further and may optionaly contain DATA if needed by the operation. As an example a GET or DEL may not have DATA. -> SELECTOR is an optional construct that further defines the PATH. The presence of a selector is dependent on the PATH IDs and the flags. The PATH would point to a table and the flags would define what selector follows (one of BLKINFO or KEYINFO). Refer to flags description further below. -> DATA may contain DATARAW or further PATH-DATA selection -> DATARAW contains "the data" whose path is selected. NOTE NOTE: ---------- PATH, DATAINFO and DATA are really place holders and not TLVs. For this reason, one could describe the PATH-DATA TLV as: PATH-DATA TLV := [[SELECTOR] [DATA]] or PATH-DATA TLV := [[SELECTOR] [[DATARAW] | +]] or simply: PATH-DATA TLV := [SELECTOR] [[DATARAW] | +] However since this is not good eye candy, we will leave the BNF as described above. DATARAW --------- This data is packed in such a way that a receiver of such data with knowledge of the path can correlate what it means by infering in the LFB definition. This is an optimization that helps packing the data. In other words: "It is assumed that the type of the data can be inferred by the context in which data is used. Hence, data will not include its type information. The basis for the inference is typically the LFB class id and the path." OPEN ISSUE: There is another view of how DATA should be represented posted a while back by Zsolt/Steve. We need to review it and compare against the scheme described here. The criteria is a) efficiency of encoding b)efficiency of parsing and decoding and c) the packaging overhead. DATA PACKING RULEs The scheme used in this doc adheres to the following rules: a)The Value of DATARAW TLV will contain the data being transported. This data will be as was described in the LFB definition. b) By definition in the Forces protocol, all TLVs are 32 bit aligned. Therefore because DATARAW is a TLV, elements not aligned in 32 bit values will be padded. As an example a 16 bit value will have an extra 16 bit pad; however two 16 bits values in a structure will be shipped together with no padding etc. c) Variable sized data will be encapsulated inside another DATARAW TLV inside the V of the outer TLV. For example of this see use case #13. d) When a table is refered in the PATH (ids), then the RAWDATA's V will contain that tables row content prefixed by its 32 bit index/subscript OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing to a row in table; in such a case, the RAWDATA's V will only contain the content sans the index in order to avoid ambiguity. flags ----- NOTE: got rid of exclusivity flag based on discussions with Joel. I) SELECTOR Bits Two bits are reserved for selecting and further refining what follows the path. This could be either BLKINFO or KEYINFO. -->00: indicates absence of the selector This is the only case where the path is allowed to have a mix of field IDs and indexes. -->01(F_SELTAB): indicates what follows is a table. The path should be sufficient to point to a table; so this flag is redundant but here for completion sake -->10(F_SELBLK): indicates that what follows is a BLKINFO -->11(F_SELKEY): Indicates what follows is a KEYINFO II) OPERATION Bits --> 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. OPEN!! Controvesial, still under investigation flags: --> F_APPEND Add to the end of the object list/table. This could create xplicates (i.e dup/triplicates etc) --> F_PREPEND Add as the first entry in a table. This could create xplicates (i.e dup/triplicates etc) --> F_NEEDIX Utility flag used in conjunction with F_CREATE to indicate a request for a table row entry without specifying the row index. In such a case the recepient (FE) which receives this request will select the available index and report it back if the main header requested for a verbose response. Relation of operational flags with global message flags: --------------------------------------------------------- Should be noted that other applicable flags such as atomicity indicators as well as result formaters are in the main headers flags area. 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*(CNT of indices) Content path selection --------------------- The KEY_INFO TLV will describe the KEY as well as associated KEY data. KEYs used for content searches are restricted and described in the LFB definition. The use cases below show some sample operations. 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 KEY: nhkey, ID = 1, V = t2 table2: type array, ID = 4 elements are: j1, type u32, ID = 1 j2, type u32, ID = 2 KEY: akey, ID = 1, V = { j1,j2 } 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 KEY: mykey, ID = 1, V = { j1} table5: type array, ID = 7 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type-X Type-X: x1, ID 1, type u32 x2, ID2 , type u32 KEY: tkey, ID = 1, V = { x1} TODO: DRAW a sample diagram of a table that shows rows and columns since that seems to have caused confusion All examples will show an attribute suffixed with "v" or "val" to indicate the value of the referenced attribute. example for attribute foo2, foo1v or foo1value will indicate the value of foo1. In the case where F_SEL** are missing (bits equal to 00) then the flags will not show any selection. TODO: FIXME - Some examples show results while others dont - Some examples show operations in hierachy others dont 1) To get foo1 OPER = GET Path-data TLV: IDCount = 1, IDs = 1 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 1 DATARAW TLV L = 8, V = foo1v 2) to set foo2 to 10 OPER = SET Path-data TLV: flags = F_REPLACE, IDCount = 1, IDs = 2 DATARAW 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) OPER = GET Path-data TLV: IDCount = 1, IDs = 4 Result: OPER = GET Path-data TLV: IDCount = 1, IDs = 4 DATARAW TLV: L = XXX, V= a series of: index, j1value,j2value entries 4) Block operations To create entry 0-5 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) ALTERNATIVE (consumes more bits on the wire in this case): OPER = SET Path-data TLV: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV: L = XXX, V= 0, j1value, j2value 1, j1value, j2value 2, j1value, j2value 3, j1value, j2value 4, j1value, j2value 5, j1value, j2value 5) Block operations (with holes) To replace entry 0,2 of table2 (I am going to ignore error conditions for now) OPER = SET Path-data TLV: flags = F_REPLACE | F_SELBLK , IDCount = 1, IDs=4 BLK_LIST_INDEX TLV, L = XXX V = 0,2 DATARAW TLV, Length = XXX, V = j1value,j2value j1value,j2value 6) Getting rows To get first entry of table2 OPER = GET Path-data TLV: IDCount = 2, IDs=4.0 Result: Path-data TLV: IDCount = 2, IDs=4.0 DATARAW TLV, Length = XXX, V = j1value,j2value entry 7) to get entry 0-5 of table2 using BLK operations OPER = GET Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 TBD: What to do when say entry 1 doesnt exist? Assuming all of entries 0-5 available Result: Path-data TLV: flags = F_SELBLK, IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= a series of j1value,j2value entries (6 in total) Alternative: Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV: L = XXX, V= 0, j1value, j2value 1, j1value, j2value 2, j1value, j2value 3, j1value, j2value 4, j1value, j2value 5, j1value, j2value 8) Create a row in table2, index 5 OPER = SET Path-data TLV: flags = F_CREATE | F_SELBLK, IDCount = 1, IDs=4 BLK_LIST_INDEX TLV V = 5 DATARAW TLV, Length = XXX j1value,j2value OR: flags = F_CREATE, IDCount = 1, IDs=4.5 DATARAW TLV, Length = XXX j1value,j2value 9) an example of "create and give me an index" Assuming we asked for verbose response back. Talk to Joel, i think we need a flag "need IDX" OPER = SET Path-data TLV: flags = F_NEEDIDX, F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX j1value,j2value Result OPER = SET Path-data TLV: flags = F_CREATE, IDCount = 1, IDs=4 DATARAW TLV, Length = XXX index, j1value,j2value 10) Dump contents of table1, OPER = GET Path-data TLV: IDCount = 1, IDs=3 Result: Path-data TLV IDCount = 1, IDs=3 DATARAW TLV, Length = XXXX index, t1value, t2value . . 11) get _all_ row entries from table4 where j1=100 Assuming j1 is an accepted key and its keyid is 1 OPER = GET Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=6 KEYINFO TLV = {KEYID =1 KEY_DATA=100} Result: Path-data TLV: IDCount = 1, IDs=6 DATARAW TLV, Length = XXXX index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value index, j1value,j2value, j3value, j4value 12) delete first 10 row entries with KEY match (j1=100, j2=200) in table 2, starting at index 10. OPER = DEL Path-data TLV: flags = F_SELKEY IDCount = 1, IDs=4 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} Path-data TLV: flags = F_SELBLK IDCount = 1, IDs=4 BLK_CNT_INDEX TLV start = 10 count = 10 Result: This assumes we have asked for the full results back in the main header. Assuming we deleted 3 at indeces 11, 13, and 18. Path-data TLV: IDCount = 1, IDs=4 DATARAW TLV, Length = XXXX 11,j1value,j2value 13,j1value,j2value 18,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. OPER = GET Path-data TLV: IDCount = 1, IDs=5 Result: Path-data TLV: IDCount = 1, IDs=5 DATARAW TLV, Length = XXXX index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev index, someidv, TLV: T=DATA, L = 4+strlen(namev), V = namev . . . 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. OPER = SET Path-TLV: flags = F_CREATE, IDCount = 2, IDs=4.20 DATARAW TLV, V= j1value,j2value // Operation 2: Update table1 entries which // were pointing to t2 = 10 to now point to 20 OPER = SET Path-data TLV: flags = F_REPLACE | F_SELKEY, IDCount = 1, IDs=3 KEYINFO = {KEYID = 1 KEY_DATA=10} DATARAW TLV, V= 20 Result: //first operation, SET OPER = SET Path-data TLV IDCount = 1, IDs=4 DATARAW TLV, V = 20,j1value,j2value //second opertion SET - assuming 3 entries were updated OPER = SET Path-data TLV IDCount = 1, IDs=3 // assuming 16, 36,95 were set DATARAW TLV, Length = XXXX 16,t1value, 20 36,t1value, 20 95,t1value, 20 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-data TLV Flags = F_SELBLK, IDCount = 1, IDs=6 // select the rows BLK_LIST_INDEX, L = XXX V = {1,3,5,7,9} // select individual columns and set Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {100} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=2 DATARAW TLV: L=XXXX, V = {200} Path-data TLV : Flags = F_REPLACE, IDCount = 1, IDs=3 DATARAW TLV: L=XXXX, V = {300} 16) Table of table examples a) to get x1 from table10 row with index 4, inside table5 entry 10 we would have: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 Results: operation = GET Path-data TLV IDCount = 1, IDs=7.10.2.4.1 DATARAW TLV: L=XXXX, V = {x1 value} b) from all table5's rows, get the x1s of the 4th element of their table10 operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 Results: operation = GET Path-data TLV flag = F_SELTAB, IDCount=1, IDS = 7 PATH-DATA TLV IDCount=3, IDS = 2.4.1 DATARAW TLV: L=XXXX, V = {x1 values} Note that the length of the DATARAW TLV will tell how many x1 entries are there (assuming we know what the size of each x1 is) c) from table5's row 10 table10, get X2s based on on the value of x1 equlaing 10 (recal x1 is KeyID 1) operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 //select x2 Results: operation = GET Path-data TLV flag = F_SELKEY, IDCount=3, IDS = 7.10.2 KEYINFO TLV, KEYID = 1, KEYDATA = 10 Path-data TLV IDCount = 1, IDS = 2 DATARAW TLV: L=XXXX, V = {x2 values} Note that the length of the DATARAW TLV will tell how many x2 entries are there (assuming we know what the size of each x2 is) 17) Further example of table of table Weiming would like to update different items on a hierachy of data. So this example is there to show how that can be done with the current BNF. Consider table 6 which is defined as: table6: type array, ID = 8 elements are: p1, type u32, ID = 1 p2, type array, ID = 2, array elements of type type-A type-A: a1, type u32, ID 1, a2, type array ID2 ,array elements of type type-B type-B: b1, type u32, ID 1 b2, type u32, ID 2 So lets say we wanted to set by replacing: table6.10.p1 to 111 table6.10.p2.20.a1 to 222 table6.10.p2.20.a2.30.b1 to 333 in one message and one operation. There are two ways to do this: a) using nesting operation = SET Path-data TLV IDCount = 2, IDs=6.10 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : IDCount = 2, IDs=2.20 Path-data TLV : flags = F_REPLACE, IDCount = 1, IDs=1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=2.30.1 DATARAW TLV: L=XXXX, V = {333} b) using a flat path data operation = SET Path-data TLV : flags = F_REPLACE, IDCount = 3, IDs=6.10.1 DATARAW TLV: L=XXXX, V = {111} Path-data TLV : flags = F_REPLACE, IDCount = 5, IDs=6.10.1.20.1 DATARAW TLV: L=XXXX, V = {222} Path-data TLV : flags = F_REPLACE, IDCount = 7, IDs=6.10.1.20.1.30.1 DATARAW TLV: L=XXXX, V = {333} As i was hinting in posting earlier, if you look at the IDs as you keep going to the next path, you will see that they repeat the previous path. If we could say "inherit previous path" via a flag such as F_INHERIT then we could have an optimization and save a few bytes. $Log: data_path2.txt,v $ Revision 1.11 2005/02/08 21:34:07 hadi added example per Weimings trail with data sets this is example 17 now Revision 1.10 2005/02/08 20:48:48 hadi updated with Joels comment on rearranging BNF Its not very readable, so just put a comment on how it would look like and leave it as it was before. Revision 1.9 2005/02/03 22:35:49 hadi rearranged text and redid the use cases to match changed BNF Revision 1.8 2005/02/02 20:19:10 hadi incorporating Joels text and Weimings input 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 --=-uO80QMXEMvxOENdlHiom-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 18: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 SAA15784 for ; Tue, 8 Feb 2005 18:12:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeqQ-0007Ge-VG for forces-archive@IETF.ORG; Tue, 08 Feb 2005 18:32:38 -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.00F790EA@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 18:12:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57056808 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 18:12:11 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 18:12:11 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020815124615:11013 ; Tue, 8 Feb 2005 15:12:46 -0800 References: <468F3FDA28AA87429AD807992E22D07E042ECC18@orsmsx408> <1107893450.1269.143.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 02/08/2005 03:12:46 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 03:12:47 PM, Serialize complete at 02/08/2005 03:12:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107904328.1095.67.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 18:12:08 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 16:42, Alistair Munro wrote: [I will let Joel respond to that first piece] > > [Jamal wrote] Kill the CANCEL now that we dont have TCP as the TML > imposed on us. > > The idea was to cancel a locally or even remotely command stuck on a > > retransmit queue (due to TCPs head of line blocking). > > But I am out of touch here, and apologies if I'm covering old ground. Is > TCP forbidden? I've used TCP to support this kind of thing and it sure does > block. However, 2-phase commit is intended to get round this (among other > failures) in a consistent way, although a severely untimely one in this > case. The connection must be closed, which will freeze the operations and > data in progress (isolation) consistently at both ends until the recovery > or abort phase starts in a new connection. This isn't a transport layer > issue per se: I think anything that behaved the same way as TCP would have > a similar problem - any queue can block. You are correct there are two levels of blocking: at a message and transactional level. I was worried about the former. TCP is known to have HOL issues. Many studies have shown this (so dont ask me to justify this). Theres one good reason why people end up electing to use SCTP instead. What i was hoping to achieve when i proposed the CANCEL message is the idea as described by SCTP in RFC 3758 in regards to timeliness. So its not exactly 2pc thats at stake here - many fine distributed databases are known to do 2pc over TCP. Oracle if memory serves right allows both TCP and UDP as transport (not sure which one it defaults to). I am hoping not to distract current discussion - this is a valid discussion but maybe getting into TML land (and i would rather spend time knocking the big ticket items). I apologize in advance if that didnt come out right. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 18:28: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 SAA21674 for ; Tue, 8 Feb 2005 18:28:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyf6f-0000Fp-Rb for forces-archive@IETF.ORG; Tue, 08 Feb 2005 18:49: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 <12.00F791E1@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 18:28:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57057379 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 18:28:54 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 18:28:54 -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 j18NSr6O020659; Tue, 8 Feb 2005 23:28:53 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j18NSlSd002219; Tue, 8 Feb 2005 23:28:53 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 M2005020815284702344 ; Tue, 08 Feb 2005 15:28:47 -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); Tue, 8 Feb 2005 15:28:24 -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 Operations Thread-Index: AcUOJVQwAFcPAIp1SdaGGbDg9WSGGAADaAiA X-OriginalArrivalTime: 08 Feb 2005 23:28:24.0888 (UTC) FILETIME=[E2AB9B80:01C50E35] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04320E10@orsmsx408> Date: Tue, 8 Feb 2005 15:28:23 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Joel, I completely agree with your comment regarding the key for content selection, I think this should be fixed and defined by the LFB definition. I would also like to see a reduction in the number of combinations possible. The more combinations we have, the more difficult it will be to get interoperable implementations. Regards Hormuzd P.s. I am happy to contribute...hopefully my comments are helpful. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Note that if key's are not unique then it is not possible o know how many=20 things will be selected by a content selection. Please let us stay away from that. Note further that at the moment we at least have the simplification that one can not do blocks and keys at the same time. Note that all 6 of the cases above have been requested explicitly on the list. I would be more than happy to see a reduction in the number of=20 combinations we support. And I am VERY happy to see any comments from someone other than me,=20 Weiming, and Jamal. Thank you, Joel PS: Successful GET responses look like SET requests. GET requests can not=20 have DATARAW elements, but can have nested PATH-DATA. DELETE requests=20 would parallel GETs. At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote: >Also, another comment I made -> is this correct in the current grammar >-> >DATA :=3D [DATARAW] | + ?? From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 18:35:02 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 SAA22016 for ; Tue, 8 Feb 2005 18:35:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyfCX-0000On-Bi for forces-archive@IETF.ORG; Tue, 08 Feb 2005 18:55: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 <14.00F7912E@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 18:34:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57058109 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 18:34:53 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 18:34:53 -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 j18NYq6O022931; Tue, 8 Feb 2005 23:34:52 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 j18NYcSj006784; Tue, 8 Feb 2005 23:34:52 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 M2005020815345215891 ; Tue, 08 Feb 2005 15:34:52 -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, 8 Feb 2005 15:34:52 -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 Operations Thread-Index: AcUOJNcXhwZ4QIDoQH252hOafXbm0wAER29A X-OriginalArrivalTime: 08 Feb 2005 23:34:52.0180 (UTC) FILETIME=[C983AD40:01C50E36] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04320E30@orsmsx408> Date: Tue, 8 Feb 2005 15:34:50 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Jamal, I don't think this is philosophical at all, its very much technical... Let me repeat the reasons that I gave with some numbers, may be that will help. If I have to update 10 entries in a LFB table, it would be a lot efficient in terms of parsing as well as message size to represent that as an Operation TLV, with Operation=3DUPDATE, rather than an Operation TLV, with Operation=3DSET and 10 PATHs, each with FLAG=3DF_UPDATE. This = is pretty straight forward, what am I missing here ?? I don't think I need to open another issue for this since it is in the context of Path-data which is being discussed here. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, February 08, 2005 1:26 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations Hormuzd, I understood you earlier and yes that would work, but like i said earlier (text still at the end of this email actually): Why would this have _more_ merit than whats there right=20 now. Essentially its a philosphical question: Is the glass half full or half empty?=20 If you feel strongly about it, please open an issue report and we can revisit it later.=20 cheers, jamal On Tue, 2005-02-08 at 16:00, Khosravi, Hormuzd M wrote: > Here is what I am suggesting, >=20 > The Operation TLV =3D > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation (ADD) | Flags | Length > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > ~ + > ~ > | > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >=20 > Operations =3D ADD/CREATE, DEL, UPDATE/REPLACE. > I guess DEL ALL =3D=3D DEL followed by a Table ID (for example) so = that is > not needed > Flags =3D SELECTOR Bits > -->00: indicates absence of the selector=20 > -->01(F_SELTAB): indicates what follows is a table. The > path should be sufficient to point to a table; so this flag > is redundant but here for completion sake > -->10(F_SELBLK): indicates that what follows is a BLKINFO > -->11(F_SELKEY): Indicates what follows is a KEYINFO >=20 > Let me know why this wont work, or what I am missing here ? >=20 > Thanks > Hormuzd >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >=20 > You cannot remove the flags. If you could it may make sense to move > those two to the operations level. As it stands right now, either have > equal merit. If you look at the examples i posted, it is possible infact > to replace and create different items within one SET operation - but i > dont think this in itself stands as a reason for their existence.=20 >=20 > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 19:23: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 TAA24876 for ; Tue, 8 Feb 2005 19:23:10 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyfx8-0001Km-IS for forces-archive@IETF.ORG; Tue, 08 Feb 2005 19:43: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 <23.00F793AC@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 19:23:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57060788 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 19:23:10 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 19:23: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 2005020816234556:11597 ; Tue, 8 Feb 2005 16:23:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E04320E30@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 02/08/2005 04:23:46 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 04:23:47 PM, Serialize complete at 02/08/2005 04:23:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107908587.1095.98.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 19:23:08 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04320E30@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Hormuzd, Earlier i asked if you had read the doc - you said you did. Heres what you should do: Create an example to match what you describe below and show both schemes using sensible representation. From that derive that what you are proposing is better. It would be a good exercise to go through all the examples if you have cycles. I doubt you will find theres a sufficient difference to be worth the time or bandwidth so far consumed by this discussion. Thats where the issue becomes a philosphical one. I was asking for you to defer this to later because this is one of those things that could distract the core discussion. cheers, jamal On Tue, 2005-02-08 at 18:34, Khosravi, Hormuzd M wrote: > Jamal, > > I don't think this is philosophical at all, its very much technical... > Let me repeat the reasons that I gave with some numbers, may be that > will help. > > If I have to update 10 entries in a LFB table, it would be a lot > efficient in terms of parsing as well as message size to represent that > as an Operation TLV, with Operation=UPDATE, rather than an Operation > TLV, with Operation=SET and 10 PATHs, each with FLAG=F_UPDATE. This is > pretty straight forward, what am I missing here ?? > > I don't think I need to open another issue for this since it is in the > context of Path-data which is being discussed here. > > Regards > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Tuesday, February 08, 2005 1:26 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Protocol Operations > > Hormuzd, > I understood you earlier and yes that would work, but like i said > earlier (text still at the end of this email actually): > Why would this have _more_ merit than whats there right > now. Essentially its a philosphical question: Is the glass half full or > half empty? > If you feel strongly about it, please open an issue report > and we can revisit it later. > > cheers, > jamal > > On Tue, 2005-02-08 at 16:00, Khosravi, Hormuzd M wrote: > > Here is what I am suggesting, > > > > The Operation TLV = > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Operation (ADD) | Flags | Length > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ + > > ~ > > | > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Operations = ADD/CREATE, DEL, UPDATE/REPLACE. > > I guess DEL ALL == DEL followed by a Table ID (for example) so that is > > not needed > > Flags = SELECTOR Bits > > -->00: indicates absence of the selector > > -->01(F_SELTAB): indicates what follows is a table. The > > path should be sufficient to point to a table; so this flag > > is redundant but here for completion sake > > -->10(F_SELBLK): indicates that what follows is a BLKINFO > > -->11(F_SELKEY): Indicates what follows is a KEYINFO > > > > Let me know why this wont work, or what I am missing here ? > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > You cannot remove the flags. If you could it may make sense to move > > those two to the operations level. As it stands right now, either have > > equal merit. If you look at the examples i posted, it is possible > infact > > to replace and create different items within one SET operation - but i > > dont think this in itself stands as a reason for their existence. > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 20:17: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 UAA27444 for ; Tue, 8 Feb 2005 20:17:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cygnk-0002DC-09 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 20:37: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 <1.00F795B3@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 20:17:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57064868 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 20:17:31 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 20:17:30 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j191HUMA022215; Wed, 9 Feb 2005 01:17:30 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 j191HQSf010424; Wed, 9 Feb 2005 01:17:28 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 M2005020817165305571 ; Tue, 08 Feb 2005 17:16:55 -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); Tue, 8 Feb 2005 17:16:52 -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 Operations Thread-Index: AcUOPYz+UdO0EIakSHmIL6yi8DWSQQAAjGYw X-OriginalArrivalTime: 09 Feb 2005 01:16:52.0769 (UTC) FILETIME=[09AB7110:01C50E45] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E043210B0@orsmsx408> Date: Tue, 8 Feb 2005 17:16:51 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Alright, here you go...=20 (BTW, I believe that getting the Operations right is a core issue being discussed->based on the subject of this email.) This is an example based on the text that you sent out.. (Note the difference...based on the size of Flags, you save X*Y bytes, as well as parsing overhead, where X is no. of entries and Y is size of Flag. Also note, I have used IDs=3D4 i.e. table 2 as an example here, = you could be replacing entries in 3 different tables as well) Current Approach -->> operation =3D SET Path-data TLV :=20 Flags =3D F_REPLACE, IDCount =3D 1, IDs=3D4 DATARAW TLV: L=3DXXXX, V =3D {1, j1value, j2value} Path-data TLV :=20 Flags =3D F_REPLACE, IDCount =3D 1, IDs=3D4 DATARAW TLV: L=3DXXXX, V =3D {3, j1value, j2value} Path-data TLV :=20 Flags =3D F_REPLACE, IDCount =3D 1, IDs=3D4 DATARAW TLV: L=3DXXXX, V =3D {15, j1value, j2value} New Proposal -->> Operation =3D REPLACE Path-data TLV:=20 IDCount =3D 1, IDs=3D4 DATARAW TLV: L =3D XXX, V=3D1, j1value, j2value Path-data TLV:=20 IDCount =3D 1, IDs=3D4 DATARAW TLV: L =3D XXX, V=3D3, j1value, j2value Path-data TLV:=20 IDCount =3D 1, IDs=3D4 DATARAW TLV: L =3D XXX, V=3D15, j1value, j2value Hopefully this is a satisfactory explanation. Let me know if I misunderstood something. One argument for this is efficient and the other is interoperability concerns that David posted. (multiple ways of doing the same thing -> setting Operation in this case) regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Tuesday, February 08, 2005 4:23 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations Hormuzd, Earlier i asked if you had read the doc - you said you did. Heres what you should do: Create an example to match what you describe below and show both schemes using sensible representation. From that=20 derive that what you are proposing is better. It would be a good exercise to go through all the examples if you have cycles. I doubt you will find theres a sufficient difference to be worth the time or bandwidth so far consumed by this discussion.=20 Thats where the issue becomes a philosphical one. I was asking for you to defer this to later because this is one of=20 those things that could distract the core discussion.=20 cheers, jamal =20 On Tue, 2005-02-08 at 18:34, Khosravi, Hormuzd M wrote: > Jamal, >=20 > I don't think this is philosophical at all, its very much technical... > Let me repeat the reasons that I gave with some numbers, may be that > will help. >=20 > If I have to update 10 entries in a LFB table, it would be a lot > efficient in terms of parsing as well as message size to represent that > as an Operation TLV, with Operation=3DUPDATE, rather than an Operation > TLV, with Operation=3DSET and 10 PATHs, each with FLAG=3DF_UPDATE. = This is > pretty straight forward, what am I missing here ?? >=20 > I don't think I need to open another issue for this since it is in the > context of Path-data which is being discussed here. >=20 > Regards > Hormuzd >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Tuesday, February 08, 2005 1:26 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Protocol Operations >=20 > Hormuzd, > I understood you earlier and yes that would work, but like i said > earlier (text still at the end of this email actually): > Why would this have _more_ merit than whats there right=20 > now. Essentially its a philosphical question: Is the glass half full or > half empty?=20 > If you feel strongly about it, please open an issue report > and we can revisit it later.=20 >=20 > cheers, > jamal >=20 > On Tue, 2005-02-08 at 16:00, Khosravi, Hormuzd M wrote: > > Here is what I am suggesting, > >=20 > > The Operation TLV =3D > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Operation (ADD) | Flags | Length > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > > | > > ~ + > > ~ > > | > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >=20 > > Operations =3D ADD/CREATE, DEL, UPDATE/REPLACE. > > I guess DEL ALL =3D=3D DEL followed by a Table ID (for example) so = that is > > not needed > > Flags =3D SELECTOR Bits > > -->00: indicates absence of the selector=20 > > -->01(F_SELTAB): indicates what follows is a table. The > > path should be sufficient to point to a table; so this flag > > is redundant but here for completion sake > > -->10(F_SELBLK): indicates that what follows is a BLKINFO > > -->11(F_SELKEY): Indicates what follows is a KEYINFO > >=20 > > Let me know why this wont work, or what I am missing here ? > >=20 > > Thanks > > Hormuzd > >=20 > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > >=20 > > You cannot remove the flags. If you could it may make sense to move > > those two to the operations level. As it stands right now, either have > > equal merit. If you look at the examples i posted, it is possible > infact > > to replace and create different items within one SET operation - but i > > dont think this in itself stands as a reason for their existence.=20 > >=20 > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 20:35: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 UAA28383 for ; Tue, 8 Feb 2005 20:35:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyh5R-0002UO-LP for forces-archive@IETF.ORG; Tue, 08 Feb 2005 20:56: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 <5.00F7956F@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 20:35:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57065796 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 20:35:45 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 20:35:45 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020817362096:12142 ; Tue, 8 Feb 2005 17:36:20 -0800 References: <468F3FDA28AA87429AD807992E22D07E043210B0@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 02/08/2005 05:36:21 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/08/2005 05:36:22 PM, Serialize complete at 02/08/2005 05:36:22 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107912942.1088.126.camel@jzny.localdomain> Date: Tue, 8 Feb 2005 20:35:42 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E043210B0@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 20:16, Khosravi, Hormuzd M wrote: > Hopefully this is a satisfactory explanation. Not so fast. Pick one with nested TLVs. Take Example 15. Maybe the meanings of the flags will become obvious after that. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 8 20:46:04 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 UAA28913 for ; Tue, 8 Feb 2005 20:46:04 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyhFI-0002fe-S7 for forces-archive@IETF.ORG; Tue, 08 Feb 2005 21:06: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.00F796B3@cherry.ease.lsoft.com>; Tue, 8 Feb 2005 20:46:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57066080 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 8 Feb 2005 20:45:58 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Feb 2005 20:45:58 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9089781 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 08 Feb 2005 20:45:57 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050208204236.03191ec8@localhost> Date: Tue, 8 Feb 2005 20:45:19 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Yes, at what I consider a modest cost in bytes, all of cases (3), (4), (5), and (6) can be covered by (1) and (2). (In fact, at a somewhat larger cost in bytes (2) could be covered by (1).) Doing just (1) and (2) would be a reasonable tradeoff that would produce what I would consider a clearer and more robust structure. Thank you, Joel At 04:46 PM 2/8/2005, Putzolu, David wrote: >Thanks for the nice clear explanation Joel. > >I believe I understand the use of (1) and (2). > >It seems to me that (3), (4), (5), and (6) are achievable >using multiple (1)s and (2)s, perhaps in combination with >the transactional flags. Is that true? > >If it is true, I guess the question I would have is how >common do we expect situations to arise where we need (3-6)? >If it is a rare thing, then I would urge getting rid of >the complexity and just paying a few extra bytes in encoding >by doing multiple (1)s and (2s) in the rare cases where >multiple similar operations are actually needed. > >-David > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Tuesday, February 08, 2005 1:28 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Protocol Operations > >At the moment, in fact, the following are allowed in a SET operation >inside >a path-data TLV after the path and the optional selector: > >IF there is no selector: > (1) one DATARAW or > (2) multiple PATH-DATA TLVs, each of which is to be interpretted in > >the context of the containing path-data > >If there is a selector, and it selects one thing, then the above still >applies. > >If there is a selector, and it selects multiple things, then one is >allowed >to have > (3) one DATARAW, to be applied to all the items selected > (4) n DATARAW, equal to the number of items selected > (5) n PATH-DATA, one to be applied to each item selected > (6) one PATH-DATA to be mapped against each item selected. > >The Selector is used for content keying (which selects a single item) or > >for BLK selection. >Note that if key's are not unique then it is not possible o know how >many >things will be selected by a content selection. Please let us stay away > >from that. >Note further that at the moment we at least have the simplification that > >one can not do blocks and keys at the same time. > >Note that all 6 of the cases above have been requested explicitly on the > >list. I would be more than happy to see a reduction in the number of >combinations we support. > >And I am VERY happy to see any comments from someone other than me, >Weiming, and Jamal. > >Thank you, >Joel > >PS: Successful GET responses look like SET requests. GET requests can >not >have DATARAW elements, but can have nested PATH-DATA. DELETE requests >would parallel GETs. > >At 02:49 PM 2/8/2005, Khosravi, Hormuzd M wrote: > >Also, another comment I made -> is this correct in the current grammar > >-> > >DATA := [DATARAW] | + ?? From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 01:11: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 BAA27743 for ; Wed, 9 Feb 2005 01:11:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CylOH-0007Do-9I for forces-archive@IETF.ORG; Wed, 09 Feb 2005 01:31:58 -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.00F7A0E9@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 1:11:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57085011 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 01:11:28 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 01:11:27 -0500 Received: from [220.192.124.241] by 202.96.99.56 with StormMail ESMTP id 6322.2796546638; Wed, 9 Feb 2005 14:42:10 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E043210B0@orsmsx408> <1107912942.1088.126.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 Approved-By: "Wang,Weiming" Message-ID: <004401c50e6e$2e5b1640$f17cc0dc@WwmLapSamsung> Date: Wed, 9 Feb 2005 14:10:01 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: base64 SGkgSmFtYWwsIEhvcm11emQsZXQgYWwsDQoNCkkgaGF2ZSB0byBzYXkgSSBhY3R1YWxseSBoYXZl IHF1aXRlIHRoZSBzYW1lIHRob3VnaHRzIG9uIHRoZSBmbGFncyB3aXRoIEhvcm11emQuIEkgdGhp bmsgd2UgaGF2ZSBhbHJlYWR5IGFncmVlZCBvbiB0aGUgZm9sbG93aW5nIG9wZXJhdGlvbiBzdHJ1 Y3R1cmU6DQoNCk1lc3NhZ2UgTGV2ZWw6ICBDb25maWd1cmUgICAgUXVlcnkNCiAgICAgICAgICAg ICAgICAvICAgfCAgIFwNCk9wVExWIExldmVsOiAgIFNldCBEZWwgTW9kaWZ5DQoNCk15IHRob3Vn aHRzIGlzIHVzaW5nIHRoZXNlIHR3byBsZXZlbHMgb2YgY29kaW5nIGZvciBhc3NpZ25tZW50IG9m IG9wZXJhdGlvbnMgaGF2ZSBhbHJlYWR5IGJlZW4gZW5vdWdoIGFuZCByaWNoLiBUbyB1c2UgZnVy dGhlciBmbGFncyBpbiBldmVyeSBwYXRoLWRhdGEgZm9yIG9wcyBtYXkgbWFrZSBvdXIgcHJvZHVj dC0gdGhlIHByb3RvY29sIHJpY2ggbW9yZSB0aGFuIG5lY2Vzc2FyeSwgYW5kIGJlY29tZSBxdWl0 ZSBjb21wbGV4Lg0KDQpOb3RlIHRoYXQsIHdlIGNhbiB0YWtlIGEgJ1NldCcgb3AgYXMgdG8gc2V0 IHNvbWUgZGF0YSB0byBGRSwgdGh1cywgd2UgZG9uJ3QgbmVlZCB0byBmdXJ0aGVyIHJlY29nbml6 ZSB0aGUgb3AgYmVpbmcgYSByZXBsYWNlICh1cGRhdGUpIG9yIGEgbmV3IGNyZWF0ZS4gVGFrZSBK YW1hbCdzIGV4YW1wbGUgMTUgYXMgYW4gaW5zdGFuY2UsIEkgdGhpbmsgd2UgZG9uJ3QgbmVlZCB0 byBhc3NpZ24gdGhhdCBpdCBpcyBhIHJlcGxhY2Uga2luZCBvZiBTZXQsIGl0J3MganVzdCBhIFNl dC4NCg0KQ2hlZXJzLA0KV2VpbWluZw0KICANCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiSmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpTdWJqZWN0OiBSZTog UHJvdG9jb2wgT3BlcmF0aW9ucw0KDQoNCj4gT24gVHVlLCAyMDA1LTAyLTA4IGF0IDIwOjE2LCBL aG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiANCj4gPiBIb3BlZnVsbHkgdGhpcyBpcyBhIHNh dGlzZmFjdG9yeSBleHBsYW5hdGlvbi4NCj4gDQo+IE5vdCBzbyBmYXN0Lg0KPiBQaWNrIG9uZSB3 aXRoIG5lc3RlZCBUTFZzLiBUYWtlIEV4YW1wbGUgMTUuIE1heWJlIHRoZSBtZWFuaW5ncyBvZiB0 aGUNCj4gZmxhZ3Mgd2lsbCBiZWNvbWUgb2J2aW91cyBhZnRlciB0aGF0Lg0KPiANCj4gY2hlZXJz LA0KPiBqYW1hbA0KPiANCg== From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 01:27: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 BAA28172 for ; Wed, 9 Feb 2005 01:27:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyle7-0007QE-30 for forces-archive@IETF.ORG; Wed, 09 Feb 2005 01:48: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 <17.00F7A3B1@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 1:27:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57085644 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 01:27:42 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 01:27:42 -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 j196Rgvw013206; Wed, 9 Feb 2005 06:27:42 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 j196RgZJ003993; Wed, 9 Feb 2005 06:27:42 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 M2005020822274203404 ; Tue, 08 Feb 2005 22:27:42 -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); Tue, 8 Feb 2005 22:27:42 -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 Operations Thread-Index: AcUOR7S6m718t3ctTk+Munqfo0P81gAJ7FLw X-OriginalArrivalTime: 09 Feb 2005 06:27:42.0390 (UTC) FILETIME=[75B5C560:01C50E70] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E043212AD@orsmsx408> Date: Tue, 8 Feb 2005 22:27:41 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Jamal, I did look at example 15, it was similar to what I sent out. Here is how that would be encoded without using Flags in PATH... 15) Selective setting=20 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 =3D REPLACE | F_SELBLK Path-data TLV=20 IDCount =3D 1, IDs=3D6 // select the rows BLK_LIST_INDEX, L =3D XXX V =3D {1,3,5,7,9} // select individual columns and set Path-data TLV :=20 IDCount =3D 1, IDs=3D1 DATARAW TLV: L=3DXXXX, V =3D {100} Path-data TLV :=20 IDCount =3D 1, IDs=3D2 DATARAW TLV: L=3DXXXX, V =3D {200} Path-data TLV :=20 IDCount =3D 1, IDs=3D3 DATARAW TLV: L=3DXXXX, V =3D {300} =20 Pls feel free to point out if something is broken in what I am proposing. I am open to hear about that. Right now your questioning makes me feel like I am giving some high school test again:)) Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Hopefully this is a satisfactory explanation. Not so fast. Pick one with nested TLVs. Take Example 15. Maybe the meanings of the flags will become obvious after that. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 01:51:17 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 BAA29218 for ; Wed, 9 Feb 2005 01:51:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cym0h-0007ld-I3 for forces-archive@IETF.ORG; Wed, 09 Feb 2005 02:11: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 <15.00F7A422@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 1:51:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57086940 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 01:51:11 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 01:51:08 -0500 Received: from [220.192.124.119] by 202.96.99.56 with StormMail ESMTP id 6322.2105028806; Wed, 9 Feb 2005 15:21:55 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.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 Approved-By: "Wang,Weiming" Message-ID: <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> Date: Wed, 9 Feb 2005 14:50:12 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: base64 SGkgSmFtYWwsRGF2aWQsSm9lbCxldCBhbCwNCg0KSSB0aGluayBKb2VsIGNvdWdodCBteSB3b3Jy eSB3ZWxsLiBJdCdzIHJlYWxseSBub3QgYSBjb3VybmVyIGNhc2UuIE1heWJlIEkgY2FuIHNpbXBs aWZ5IG15IHdvcnJ5IGFzIHdoZXJlIGV2ZW50dWFsbHkgd2UgY2FuIHB1dCB0aGUgJ1NldCBSZXN1 bHQiIHJlc3BvbnNlIGluIHRoZSBCTkY/IElzIGl0IGluIHRoZSBEYXRhcmF3IGFsb25nIHdpdGgg dGhlIG9yaWdpbmFsIHNldCBEYXRhcmF3PyBOb3cgd2UgaGF2ZSBtb3JlIHRoYW4gb25lIFBhdGgt RGF0YXMgbmVzdGVkLCBteSBzdWdnZXN0aW9uIGlzLCBpbnN0ZWFkIG9mIGFsbG93aW5nIHNlcGFy YXRlICdTZXQgUmVzdWx0IiByZXNwb25zZSBpbiBpbmRpdmlkdWFsIERhdGFyYXdzIGluIHRoZXNl IFBhdGgtRGF0YXMsIHdlIGV2ZW4gbmVlZCBhIGdlbmVyYWwgJ1NldCByZXN1bHQnIHJlc3BvbnNl IGZvciBhbGwgdGhlc2UgUGF0aC1EYXRhcyB3aGljaCBpcyBuZXN0ZWQgaW4gb25lIHRvcCBsZXZl bCBQYXRoLURhdGEuDQoNClBscyBhbGxvdyBtZSB0byB1c2UgYW4gZXhhbXBsZSB0byBzaG93LiBO b3RlIHRoYXQgdGhpcyBleGFtcGxlIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBjYXNlIEphbWFsJ3Mg ZXhhbXBsZSBpcyBmb3IuIFdlIHNob3cgaGVyZSBpcyBvbmx5IGEgcGxhbmUgdGFibGUgcmF0aGVy IHRoYW4gYSBuZXN0ZWQgdGFibGUuIA0KDQp0YWJsZTI6IHR5cGUgYXJyYXksIElEID0gNA0KIGVs ZW1lbnRzIGFyZToNCiBqMSwgdHlwZSB1MzIsIElEID0gMQ0KIGoyLCB0eXBlIHUzMiwgSUQgPSAy DQogajMsIHR5cGUgdTMyLCBJRCA9IDMNCiBqNCwgdHlwZSB1MzIsIElEID0gNA0KDQpOb3csIHRo ZSBjb25maWd1cmUgdGFzayBpczogdG8gc2V0IHRoZSBqMSB0byAxMDAsIGFuZCBqMiB0byAyMDAs IGozIHRvIDMwMCwgYW5kDQpyZW1haW4gajQgYXMgaXQgaXMsICBmb3IgIEluZGV4IG9mIHRoZSB0 YWJsZSAoMSwgMywgNSwgNywgOSkuDQoNCldlIGNhbiBzZXR1cCBhIFNldCBtZXNzYWdlIGZvciB0 aGlzIHRhc2sgYXMgYmVsb3c6IA0KDQpPcD1TZXQNClBhdGgoNCkgSW5kZXhUTFYoMSwzLDUsNyw5 KSBwYXRoKDEpLURhdGEoMTAwKSBwYXRoKDIpLURhdGEoMjAwKSBwYXRoKDMpLURhdGEoMzAwKQ0K DQpUd28gd2F5cyB0byB0aGUgUmVzcG9uc2UgdG8gdGhpcyBTZXQgbWVzc2FnZToNCjEuDQpPcD1T ZXRSZXNwb25zZQ0KUGF0aCg0KSBJbmRleFRMVigxLDMsNSw3LDkpIHBhdGgoMSkte0RhdGEoMTAw KSxEYXRhU2V0UmVzdWx0fSBwYXRoKDIpLXtEYXRhKDIwMCksRGF0YVNldFJlc3VsdH0gIHBhdGgo Mykte0RhdGEoMzAwKSxEYXRhU2V0UmVzdWx0fSANCiANCg0KMi4NCk9wPVNldFJlc3BvbnNlDQpQ YXRoKDQpIEluZGV4VExWKDEsMyw1LDcsOSkgcGF0aCgxKS1EYXRhKDEwMCkgcGF0aCgyKS1EYXRh KDIwMCkgcGF0aCgzKS1EYXRhKDMwMCkgRGF0YVRMVmZvclNldFJlc3VsdA0KDQpJIGp1c3QgdGhp bmsgdGhhdCB0aGUgMiBpcyBtb3JlIGVmZmljaWVudC4NCg0KQ2hlZXJzLA0KV2VpbWluZw0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxo YWRpQHpueXguY29tPg0KU3ViamVjdDogUmU6IFByb3RvY29sIE9wZXJhdGlvbnMNCg0KDQo+IEkg YW0gbm90IHN1cmUgaSBnb3QgdGhlIFNFVFJFU1VMVDsgZ29pbmcgYnkgd2hhdCBXZWltaW5nIGFz a2VkIGZvcg0KPiBlYXJsaWVyLCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgZmFjaWxpdGllczoNCj4g DQo+IFRvIHNldCBkYXRhIHRvIGEgMy1kZWVwIHBhdGggb2Zmc2V0Og0KPiBwYXRoLWRhdGENCj4g cGF0aDENCj4gb3B0aW9uYWwgc2VsZWN0b3INCj4gcGF0aC1kYXRhDQo+IHBhdGgyDQo+IG9wdGlv bmFsIHNlbGVjdG9yDQo+IHBhdGgtZGF0YQ0KPiBwYXRoMw0KPiBvcHRpb25hbCBzZWxlY3Rvcg0K PiBkYXRhcmF3DQo+IA0KPiANCj4gSWYgYSByZXNwb25zZSBpcyBhc2tlZCBiYWNrLCB0aGF0cyBl eGFjdGx5IGhvdyB0aGUgcmVzcG9uc2Ugd291bGQgbG9vaw0KPiBsaWtlIGFzIHdlbGwuDQo+IA0K PiBUaGUgb3RoZXIgd2F5IHdoaWNoIGlzIHRvIHNldCBkYXRhIG9uIG11bHRpcGxlIG5lc3RlZCBw YXRoczoNCj4gDQo+IHBhdGgtZGF0YQ0KPiBwYXRoMQ0KPiBvcHRpb25hbCBzZWxlY3Rvcg0KPiBk YXRhcmF3DQo+IHBhdGgtZGF0YQ0KPiBwYXRoMg0KPiBvcHRpb25hbCBzZWxlY3Rvcg0KPiBkYXRh cmF3DQo+IHBhdGgtZGF0YQ0KPiBwYXRoMw0KPiBvcHRpb25hbCBzZWxlY3Rvcg0KPiBkYXRhcmF3 DQo+IA0KPiBHcmFudGVkIHRoZSBlbmQgcmVzdWx0IHdpbGwgYmUgZ3Jvc3NseSBpbmVlZmZpY2ll bnQgc2luY2UgaXQgd2lsbCBoYXZlIGENCj4gbG90IG9mIHJlZHVuZGFudCBpbmZvcm1hdGlvbiBp biB0aGUgdGhyZWUgcGF0aC1kYXRhcyBhYm92ZSBpZiBwYXRoMSBpcw0KPiByZWxhdGl2ZSB0byBw YXRoMiBhbmQgcGF0aDMgaXMgcmVhbHRpdmUgdG8gcGF0aDIuDQo+IEZvciB0aGlzIHdlIGNhbiB1 c2Ugd2hhdCBpIGhhdmUgc2VlbiBpbiBhIGZldyBjbGFzc2lmaWVycyBhcyBhbg0KPiBvcHRpbWl6 YXRpb247IHRoZXNlIHNvcnRzIG9mIGNsYXNzaWZpZXJzIGhhY3ZlIGEgICJjb250aW51ZSIgY29u c3RydWN0DQo+IHdoaWNoIHRyYW5zbGF0ZXMgdG8gImNvbnRpbnVlIGxvb2tpbmcgdXAgd2hlcmUg eW91IGxhc3QgbGVmdCBvZmYiLg0KPiBXZSBjYW4gaGF2ZSBzb21ldGhpbmcgc2ltaWxhciBhcyBh IGZsYWcgLSBzbyBvbiBwYXRoMiBhbmQgcGF0aDMgaXQgd291bGQNCj4gc2F5ICJ0aGUgcHJldmlv dXMgcGF0aCtzZWxlY3RvciBjb3VudHMgYXMgcGFydCBvZiB0aGlzIHBhdGgiLiBTbyBwYXRoMSAr DQo+IGl0cyBzZWxlY3RvcnMgd2lsbCBiZSBwYXJ0IG9mIHBhdGgyKyBpdHMgc2VsZWN0b3JzLCB3 aGljaCBpcyBhbHNvIHBhcnQNCj4gb2YgcGF0aDMgYW5kIGl0cyBzZWxlY3RvcnMuIENsZWFybHkg dGhlIGZsYWcgaXMgbm90IHVzZWZ1bCBvbiB0aGUgZmlyc3QNCj4gcGF0aC1kYXRhIGl0IGludm9s dmVzIGluaGVyaXRhbmNlIGFuZCBjYW4gYmUgaWdub3JlZCB0aGVyZS4NCj4gDQo+IEhlcmVzIG15 IHdvcnJ5OiBJIHRoaW5rIHdoYXQgV2VpbWluZyB3YW50cyBpbiB0aGlzIGNhc2UgaXMgYSBjb3Ju ZXIgY2FzZQ0KPiB3aGljaCB3aGlsZSB3ZSBtdXN0IHNhdGlzZnkgdGhlIGVuZCByZXN1bHQgc2hv dWxkIG5vdCBicmVhayB0aGUgc2ltcGxlDQo+IGRlc2lnbiBydWxlIG9mICJvcHRpbWl6ZSBmb3Ig dGhlIG1ham9yaXR5Ig0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0KPiANCj4gT24gVHVlLCAyMDA1 LTAyLTA4IGF0IDA2OjU5LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gWW91IHJhaXNlIGFu IGludGVyZXN0aW5nIHF1ZXN0aW9uIG9mIHdoZXJlIHRoZSBlbGVtZW50IGJ5IGVsZW1lbnQgU0VU IA0KPiA+IHJlc3VsdHMgZ28uDQo+ID4gDQo+ID4gT25lIG9mIHRoZSBkcmF3YmFja3Mgb2YgYWxs b3dpbmcgbXVsdGlwbGUgcGF0aC1kYXRhIGVsZW1lbnRzIGluc2lkZSBhIA0KPiA+IG9wZXJhdGlv biBUTFYgaXMgdGhhdCBpdCBubyBsb25nZXIgc3VmZmljZXMgdG8gcmV0dXJuIHRoZSByZXNwb25z ZSBjb2RlIGF0IA0KPiA+IHRoZSBvcGVyYXRpb24gVExWIGxldmVsLg0KPiA+IFRoZXJlZm9yZSwg SSB3b3VsZCBwcmVzdW1lLCB3ZSB3aWxsIGhhdmUgdG8gcmV0dXJuIHRoZSByZXNwb25zZSBjb2Rl cyBpbiANCj4gPiB0aGUgaW5kaXZpZHVhbCBwYXRoLWRhdGEgVExWcy4NCj4gPiBJIHdvdWxkIG5v dCB3YW50IHRvIHJldHVybiB0aGUgcmVzdWx0cyBhcyBhIHNlcGFyYXRlIHBhcmFsbGVsIFRMViwg YXMgdGhhdCANCj4gPiB3b3VsZCBpbXBseSBzb21lIGtpbmQgb2YgbWF0Y2hpbmcgdGhhdCB3b3Vs ZCBnZXQgcXVpdGUgY29uZnVzaW5nLiAgSSANCj4gPiBzdXBwb3NlIHRoYXQgbWVhbnMgdGhhdCB0 aGUgYWN0dWFsIHN5bnRheCBiZWNvbWVzOg0KPiA+IA0KPiA+IERBVEFJTkZPIDo9IFtTRUxFQ1RP Ul0gWzxQQVRILURBVEE+KyB8IDxEQVRBUkFXPisgfCA8U0VUUkVTVUxUPitdDQo+ID4gDQo+ID4g V2hlcmUgU0VUIFJlc3VsdCBpcyB1c2VkIG9ubHkgaW4gdGhlIHJlc3BvbnNlIHRvIGEgU0VULCBh bmQgb2NjdXJzIHdoZXJlIA0KPiA+IHRoZSBEQVRBUkFXIGVsZW1lbnRzIHdlcmUgaW4gdGhlIHNl dCByZXF1ZXN0LCBpbmRpY2F0aW5nIGZvciBlYWNoIGRhdGFyYXcgDQo+ID4gd2hldGhlciBpdCB3 YXMgc3VjY2Vzc2Z1bGx5IHNldC4NCj4gPiANCj4gPiBZb3VycywNCj4gPiBKb2VsDQo+ID4gDQo+ ID4gQXQgMTE6MjIgUE0gMi83LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPiA+SXQgcXVp dGUgZ2V0cyB0byBtZSB0aGF0IHRoZSBsaXN0IHNlcnZlciBvZnRlbiBhdGUgbXkgcG9zdHMuIEkg ZG8gaGF2ZSANCj4gPiA+c2VudCBzb21lIG1haWxzIGJ1dCB0aGF0IGNhbm4ndCBiZSBzZWVuIG9u IHRoZSBsaXN0IHRpbGwgbm93Lg0KPiA+ID4NCj4gPiA+SG9wZWZ1bGx5ICB0aGlzIHBvc3QgY2Fu IHdvcmsuDQo+ID4gPg0KPiA+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gPkZy b206ICJKb2VsIE0uIEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+ID4gPlN1Ympl Y3Q6IFJlOiBQcm90b2NvbCBPcGVyYXRpb25zDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gSSBhY3R1 YWxseSB0aGluayB3ZSBjb3VsZCBnZXQgYXdheSB3aXRoOg0KPiA+ID4gPg0KPiA+ID4gPiBEQVRB SU5GTyA6PSBbU0VMRUNUT1JdIFs8REFUQVJBVz4gfCA8UEFUSC1EQVRBPitdDQo+ID4gPiA+DQo+ ID4gPiA+IGFuZCBqdXN0IGxlYXZlIG91dCB0aGUgIkRBVEEiIGxpbmUuICBJIGJlbGlldmUgdGhp cyBhbGxvd3MgdGhlIG5lc3RpbmcsIGlzDQo+ID4gPiA+IGRlY2lkYWJsZSBieSB0aGUgcGFyc2Vy LCBhbmQgZG9lcyB3aGF0IHdlIG5lZWQuDQo+ID4gPiA+DQo+ID4gPiA+IHdlIGNhbiBpbiBmYWN0 IGNvbGxhcHNlIGZ1cnRoZXIgaW4gdGhlIEJORiB0bzoNCj4gPiA+ID4NCj4gPiA+ID4gUEFUSC1E QVRBIFRMViA6PSA8UEFUSD4gW1NFTEVDVE9SXSBbPERBVEE+KyB8IDxQQVRILURBVEE+K10NCj4g PiA+DQo+ID4gPlllcywgdGhpcyBtYWtlcyBpdCBtb3JlIGNsZWFyLCBidXQgSSBzdGlsbCBzZWUg dGhlIHZhbHVlIHRvIG1vZGlmeSBpdCB0bzoNCj4gPiA+DQo+ID4gPlBBVEgtREFUQSBUTFYgOj0g PFBBVEg+IFtTRUxFQ1RPUl0gWzxQQVRILURBVEE+K10gWzxEQVRBPitdDQo+ID4gPg0KPiA+ID5J IHN1cHBvc2UgIGEgU0VUIHJlcXVlc3QgdGhhdCBoYXMgZm9ybWF0IGFzICJwYXRoIHBhdGgtZGF0 YTEgcGF0aC1kYXRhMiANCj4gPiA+cGF0aC1kYXRhMyIsIHdob3MgcmVzcG9uc2Ugd2lsbCBoYXZl IGZvcm1hdCBhcyAicGF0aCBwYXRoLWRhdGExIHBhdGgtZGF0YTIgDQo+ID4gPnBhdGgtZGF0YTMg ZGF0YSIsIHRoZSBsYXN0IGRhdGEgVExWIGlzIGZvciB0aGUgU0VUIHJlc3VsdCByZXNwb25zZXMu DQo+ID4gPg0KPiA+ID5DaGVlcnMsDQo+ID4gPldlaW1pbmcNCj4gDQo= From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 02:19:25 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 CAA20268 for ; Wed, 9 Feb 2005 02:19:25 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CymRx-0008Fu-Kk for forces-archive@IETF.ORG; Wed, 09 Feb 2005 02:39:51 -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.00F7A59E@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 2:19:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57088501 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 02:19:15 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 02:19:15 -0500 Received: from ncs.bris.ac.uk ([137.222.10.36]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1Cym80-0006nI-Gv for FORCES@PEACH.EASE.LSOFT.COM; Wed, 09 Feb 2005 07:19:14 +0000 Received: from host81-157-60-147.range81-157.btcentralplus.com ([81.157.60.147] helo=[192.168.0.3]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1Cym80-0006qQ-6q for FORCES@PEACH.EASE.LSOFT.COM; Wed, 09 Feb 2005 07:19:12 +0000 References: <468F3FDA28AA87429AD807992E22D07E042ECC18@orsmsx408> <1107893450.1269.143.camel@jzny.localdomain> <1107904328.1095.67.camel@jzny.localdomain> Originator-Info: login-token=Mulberry:01B2itZGzNDtg/qSbONW3O2s0/yiOHR3ne28ZE0iaINWqWIs8=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 X-Spam-Level: / Approved-By: Alistair Munro Message-ID: Date: Wed, 9 Feb 2005 07:19:11 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107904328.1095.67.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi Jamal, > You are correct there are two levels of blocking: at a message and > transactional level. I was worried about the former. TCP is known to > have HOL issues. Many studies have shown this (so dont ask me to justify > this). Yes, I'm clear on this myself. I'll check the SCTP approach. > I am hoping not to distract current discussion - this is a valid > discussion but maybe getting into TML land (and i would rather spend > time knocking the big ticket items). > I apologize in advance if that didnt come out right. No problem - I don't want to distract people either, but having had CANCEL thrown into the mix, I didn't want to let it pass uncommented. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 07:07: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 HAA22715 for ; Wed, 9 Feb 2005 07:07:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyqx2-0005Df-Gm for forces-archive@IETF.ORG; Wed, 09 Feb 2005 07:28: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 <0.00F7B092@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 7:07:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57131624 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 07:07:41 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 07:07:40 -0500 Received: from [69.170.17.195] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9097631 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 09 Feb 2005 07:07:40 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050209065916.033050a0@localhost> Date: Wed, 9 Feb 2005 07:06:50 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 There are actual several aspects to this example. 1) I do not think that SET responses need to carry the DATARAW. The CE knows what it sent. 1') Therefore, I would think it suffices to replace the DATARAW with the SETRESULT TLV. If we really want the data shipped back, we can put it inside the SETRESULT. 2) This particular example shows the combination of multiple target paths and multiple instances. This cross mapping creates two problems such that I would strongly prefer not to do this. 2a) The FE in processing this request has to realize that the multiple inner path-data elements are not intneded to be used one each for he selector targets, but rather are all supposed to be used for all the selector targets. This is actually a behavior (7) which I did not describe in my earlier note because it seems undecidable. 2b) Even if we used the simpler case that correspond to case (6), where all that is being set was j1 in each selector target, there is still a problem of how the result is returned. The only thing I can see to do is for the FE to explode the single PATH-DATA into a collection of PATH-DATA, as many as the selector elements, to hold the SET RESULTS. The complexity of this result is part of the cost of behaviors (3) and (6). Yours, Joel M. Halpern At 01:50 AM 2/9/2005, Wang,Weiming wrote: >Hi Jamal,David,Joel,et al, > >I think Joel cought my worry well. It's really not a courner case. Maybe I >can simplify my worry as where eventually we can put the 'Set Result" >response in the BNF? Is it in the Dataraw along with the original set >Dataraw? Now we have more than one Path-Datas nested, my suggestion is, >instead of allowing separate 'Set Result" response in individual Dataraws >in these Path-Datas, we even need a general 'Set result' response for all >these Path-Datas which is nested in one top level Path-Data. > >Pls allow me to use an example to show. Note that this example is >different from the case Jamal's example is for. We show here is only a >plane table rather than a nested table. > >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). > >We can setup a Set message for this task as below: > >Op=Set >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) >path(3)-Data(300) > >Two ways to the Response to this Set message: >1. >Op=SetResponse >Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} >path(2)-{Data(200),DataSetResult} path(3)-{Data(300),DataSetResult} > > >2. >Op=SetResponse >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) >path(3)-Data(300) DataTLVforSetResult > >I just think that the 2 is more efficient. > >Cheers, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" >Subject: Re: Protocol Operations > > > > I am not sure i got the SETRESULT; going by what Weiming asked for > > earlier, we have the following facilities: > > > > To set data to a 3-deep path offset: > > path-data > > path1 > > optional selector > > path-data > > path2 > > optional selector > > path-data > > path3 > > optional selector > > dataraw > > > > > > If a response is asked back, thats exactly how the response would look > > like as well. > > > > The other way which is to set data on multiple nested paths: > > > > path-data > > path1 > > optional selector > > dataraw > > path-data > > path2 > > optional selector > > dataraw > > path-data > > path3 > > optional selector > > dataraw > > > > Granted the end result will be grossly ineefficient since it will have a > > lot of redundant information in the three path-datas above if path1 is > > relative to path2 and path3 is realtive to path2. > > For this we can use what i have seen in a few classifiers as an > > optimization; these sorts of classifiers hacve a "continue" construct > > which translates to "continue looking up where you last left off". > > We can have something similar as a flag - so on path2 and path3 it would > > say "the previous path+selector counts as part of this path". So path1 + > > its selectors will be part of path2+ its selectors, which is also part > > of path3 and its selectors. Clearly the flag is not useful on the first > > path-data it involves inheritance and can be ignored there. > > > > Heres my worry: I think what Weiming wants in this case is a corner case > > which while we must satisfy the end result should not break the simple > > design rule of "optimize for the majority" > > > > cheers, > > jamal > > > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > You raise an interesting question of where the element by element SET > > > results go. > > > > > > One of the drawbacks of allowing multiple path-data elements inside a > > > operation TLV is that it no longer suffices to return the response > code at > > > the operation TLV level. > > > Therefore, I would presume, we will have to return the response codes in > > > the individual path-data TLVs. > > > I would not want to return the results as a separate parallel TLV, as > that > > > would imply some kind of matching that would get quite confusing. I > > > suppose that means that the actual syntax becomes: > > > > > > DATAINFO := [SELECTOR] [+ | + | +] > > > > > > Where SET Result is used only in the response to a SET, and occurs where > > > the DATARAW elements were in the set request, indicating for each > dataraw > > > whether it was successfully set. > > > > > > Yours, > > > Joel > > > > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > >It quite gets to me that the list server often ate my posts. I do have > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > >Hopefully this post can work. > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > > > > > and just leave out the "DATA" line. I believe this allows the > nesting, is > > > > > decidable by the parser, and does what we need. > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > > > > > >Yes, this makes it more clear, but I still see the value to modify > it to: > > > > > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > > > > > >I suppose a SET request that has format as "path path-data1 path-data2 > > > >path-data3", whos response will have format as "path path-data1 > path-data2 > > > >path-data3 data", the last data TLV is for the SET result responses. > > > > > > > >Cheers, > > > >Weiming > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 08:04: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 IAA28749 for ; Wed, 9 Feb 2005 08:04:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyrpj-0006Xr-8P for forces-archive@IETF.ORG; Wed, 09 Feb 2005 08:24: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 <0.00F7B270@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 8:04:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57134311 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 08:04:11 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 08:04:11 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020905044580:13528 ; Wed, 9 Feb 2005 05:04:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E043212AD@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 02/09/2005 05:04:46 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 05:04:48 AM, Serialize complete at 02/09/2005 05:04:48 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107954247.1088.284.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 08:04:08 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E043212AD@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit On Wed, 2005-02-09 at 01:27, Khosravi, Hormuzd M wrote: > Jamal, > > I did look at example 15, it was similar to what I sent out. > Here is how that would be encoded without using Flags in PATH... > > 15) Selective setting > 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 = REPLACE | F_SELBLK > Path-data TLV > IDCount = 1, IDs=6 > // select the rows > BLK_LIST_INDEX, L = XXX > V = {1,3,5,7,9} > // select individual columns and set > Path-data TLV : > IDCount = 1, IDs=1 > DATARAW TLV: L=XXXX, V = {100} > Path-data TLV : > IDCount = 1, IDs=2 > DATARAW TLV: L=XXXX, V = {200} > Path-data TLV : > IDCount = 1, IDs=3 > DATARAW TLV: L=XXXX, V = {300} > > Pls feel free to point out if something is broken in what I am > proposing. I am open to hear about that. The details are in the doc Hormuzd but because you tried i will try to be more patient with this response. F_SELBLK is per path. The document says: ----- -->00: indicates absence of the selector This is the only case where the path is allowed to have a mix of field IDs and indexes. -->01(F_SELTAB): indicates what follows is a table. The path should be sufficient to point to a table; so this flag is redundant but here for completion sake -->10(F_SELBLK): indicates that what follows is a BLKINFO -->11(F_SELKEY): Indicates what follows is a KEYINFO ----- As you can see all the other paths in that example do not need a F_SELBLK except for the outer/first one. And only items with data need a replace but not ones with pure paths. To make it more inmteresting, there are examples where you would have F_SELBLK flags first and then F_SELKEY next and then REPLACE at the most inner nest where the data is to be found. This was why earlier i said you cant get rid of the flags from the path because they are used to refine the path, and not just the operation. So removing the replace and create and putting them in the operations T, while looks of value, it does not change anything in terms of reducing the bit count because those flags are needed regardless. Hence my statement earlier that i didnt see they were any different in merit precisley because you are *not* gonna be able to remove the flags with path semantics; again if you could remove _all flags_ then what you are proposing will be valuable. Removing just the operation enhancing flags is of cosmetic/philosophical value and should be defered to a later discussion. The other thing i pointed out was that infact you could have both a create refinement to SET as well as replace within the same operation TLV (but that was a side effect more than a design intent). Having said all the above, if the document is unclear it needs to be fixed; it is not acceptable for the doc to do a poor job at explaining things. > Right now your questioning > makes me feel like I am giving some high school test again:)) > Did you mean "taking" high school test? ;-> I didnt wanna go here, but i have plenty of time this morning: My reaction is out of frustration. a) I feel this is a distraction from our biggest show stopper and we are close to nailing that one. i.e I dont think this is big enough an issue to be taking the bandwidth it is taking (at least not at this moment). Its like focussing on a pebble when theres a rock to be moved. b) I honestly dont feel we are having a meaningful discussion - because i perceive that you havent read the document or if you have then you just did a 1 minute scan. Actually i think i could live with b) if we didnt have issue a). cheers, jamal PS:- Dont get me wrong because this may sound elitist: Even at the IETF meetings there are things done to improve the focus of the discussion - I am sure you have walked into a meeting where they would reserve the two front rows for "people who have read the draft". You could walk to the mike and start with "I havent read the document but .." or "I have quickly scanned the document but ..' On the list such disclaimers are still acceptable (Alistair for example does a good job at that).. And the eventual answer to someone who walks to the mike maybe "read the document for details". I see my views as no different from any of the above. From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 08:12: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 IAA29635 for ; Wed, 9 Feb 2005 08:12:55 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyry9-0006ir-Cv for forces-archive@IETF.ORG; Wed, 09 Feb 2005 08:33: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.00F7B004@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 8:12:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57134549 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 08:12:52 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 08:12: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 2005020905132555:13547 ; Wed, 9 Feb 2005 05:13:25 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@! jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@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 02/09/2005 05:13:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 05:13:28 AM, Serialize complete at 02/09/2005 05:13:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107954766.1544.300.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 08:12:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Weiming, I just noticed that Joel responded on another email so i will follow up there. Question: Other than these new issues; is the BNF good for what you wanted? Are you happy it can do path data interleaving that is sufficient for what you want. If the answer is yes, that would be one chapter we can close. Please respond when you get the time (I think I know where Joel stands). cheers, jamal On Wed, 2005-02-09 at 01:50, Wang,Weiming wrote: > Hi Jamal,David,Joel,et al, > > I think Joel cought my worry well. It's really not a courner case. Maybe I can simplify my worry as where eventually we can put the 'Set Result" response in the BNF? Is it in the Dataraw along with the original set Dataraw? Now we have more than one Path-Datas nested, my suggestion is, instead of allowing separate 'Set Result" response in individual Dataraws in these Path-Datas, we even need a general 'Set result' response for all these Path-Datas which is nested in one top level Path-Data. > > Pls allow me to use an example to show. Note that this example is different from the case Jamal's example is for. We show here is only a plane table rather than a nested table. > > 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). > > We can setup a Set message for this task as below: > > Op=Set > Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300) > > Two ways to the Response to this Set message: > 1. > Op=SetResponse > Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} path(2)-{Data(200),DataSetResult} path(3)-{Data(300),DataSetResult} > > > 2. > Op=SetResponse > Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300) DataTLVforSetResult > > I just think that the 2 is more efficient. > > Cheers, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: Protocol Operations > > > > I am not sure i got the SETRESULT; going by what Weiming asked for > > earlier, we have the following facilities: > > > > To set data to a 3-deep path offset: > > path-data > > path1 > > optional selector > > path-data > > path2 > > optional selector > > path-data > > path3 > > optional selector > > dataraw > > > > > > If a response is asked back, thats exactly how the response would look > > like as well. > > > > The other way which is to set data on multiple nested paths: > > > > path-data > > path1 > > optional selector > > dataraw > > path-data > > path2 > > optional selector > > dataraw > > path-data > > path3 > > optional selector > > dataraw > > > > Granted the end result will be grossly ineefficient since it will have a > > lot of redundant information in the three path-datas above if path1 is > > relative to path2 and path3 is realtive to path2. > > For this we can use what i have seen in a few classifiers as an > > optimization; these sorts of classifiers hacve a "continue" construct > > which translates to "continue looking up where you last left off". > > We can have something similar as a flag - so on path2 and path3 it would > > say "the previous path+selector counts as part of this path". So path1 + > > its selectors will be part of path2+ its selectors, which is also part > > of path3 and its selectors. Clearly the flag is not useful on the first > > path-data it involves inheritance and can be ignored there. > > > > Heres my worry: I think what Weiming wants in this case is a corner case > > which while we must satisfy the end result should not break the simple > > design rule of "optimize for the majority" > > > > cheers, > > jamal > > > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > You raise an interesting question of where the element by element SET > > > results go. > > > > > > One of the drawbacks of allowing multiple path-data elements inside a > > > operation TLV is that it no longer suffices to return the response code at > > > the operation TLV level. > > > Therefore, I would presume, we will have to return the response codes in > > > the individual path-data TLVs. > > > I would not want to return the results as a separate parallel TLV, as that > > > would imply some kind of matching that would get quite confusing. I > > > suppose that means that the actual syntax becomes: > > > > > > DATAINFO := [SELECTOR] [+ | + | +] > > > > > > Where SET Result is used only in the response to a SET, and occurs where > > > the DATARAW elements were in the set request, indicating for each dataraw > > > whether it was successfully set. > > > > > > Yours, > > > Joel > > > > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > >It quite gets to me that the list server often ate my posts. I do have > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > >Hopefully this post can work. > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > > > > > and just leave out the "DATA" line. I believe this allows the nesting, is > > > > > decidable by the parser, and does what we need. > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > > > > > >Yes, this makes it more clear, but I still see the value to modify it to: > > > > > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > > > > > >I suppose a SET request that has format as "path path-data1 path-data2 > > > >path-data3", whos response will have format as "path path-data1 path-data2 > > > >path-data3 data", the last data TLV is for the SET result responses. > > > > > > > >Cheers, > > > >Weiming > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 08:36: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 IAA01297 for ; Wed, 9 Feb 2005 08:36:43 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CysLB-0007Ej-Cq for forces-archive@IETF.ORG; Wed, 09 Feb 2005 08:57: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 <21.00F7B215@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 8:36:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57141393 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 08:36:41 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 08:36: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 2005020905371259:13596 ; Wed, 9 Feb 2005 05:37:12 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@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 02/09/2005 05:37:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 05:37:16 AM, Serialize complete at 02/09/2005 05:37:16 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107956192.1095.325.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 08:36:33 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050209065916.033050a0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit On Wed, 2005-02-09 at 07:06, Joel M. Halpern wrote: > There are actual several aspects to this example. > > 1) I do not think that SET responses need to carry the DATARAW. The CE > knows what it sent. > 1') Therefore, I would think it suffices to replace the DATARAW with the > SETRESULT TLV. If we really want the data shipped back, we can put it > inside the SETRESULT. We already have a verbosity flag on the main header that i posted on earlier; a request for a verbose response indicates desire to have DATARAW sent back. i.e in a response to a config/set you get a configresponse/set with only thing being different is the configs when the set is echoed back. Is using the SETRESULT going to reduce the number of bits on the wire? Reading Weimings example i see in fact it uses more bits than just echoing back the the set operation (but that maybe unintended). Does SETRESULT provide more simplicty than what we already have? If i read Weiming correctly he wants to move this request flag into the path flags. Thats going to create complexity IMO. > 2) This particular example shows the combination of multiple target paths > and multiple instances. This cross mapping creates two problems such that > I would strongly prefer not to do this. > 2a) The FE in processing this request has to realize that the multiple > inner path-data elements are not intneded to be used one each for he > selector targets, but rather are all supposed to be used for all the > selector targets. This is actually a behavior (7) which I did not describe > in my earlier note because it seems undecidable. > 2b) Even if we used the simpler case that correspond to case (6), where all > that is being set was j1 in each selector target, there is still a problem > of how the result is returned. The only thing I can see to do is for the > FE to explode the single PATH-DATA into a collection of PATH-DATA, as many > as the selector elements, to hold the SET RESULTS. The complexity of this > result is part of the cost of behaviors (3) and (6). Or to just echo back the operation on success when verbosity is requested, no? cheers, jamal > Yours, > Joel M. Halpern > > At 01:50 AM 2/9/2005, Wang,Weiming wrote: > >Hi Jamal,David,Joel,et al, > > [..] > >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). > > > >We can setup a Set message for this task as below: > > > >Op=Set > >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) > >path(3)-Data(300) > > > >Two ways to the Response to this Set message: > >1. > >Op=SetResponse > >Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} > >path(2)-{Data(200),DataSetResult} path(3)-{Data(300),DataSetResult} > > > > > >2. > >Op=SetResponse > >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) > >path(3)-Data(300) DataTLVforSetResult > > > >I just think that the 2 is more efficient. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Jamal Hadi Salim" > >Subject: Re: Protocol Operations > > > > > > > I am not sure i got the SETRESULT; going by what Weiming asked for > > > earlier, we have the following facilities: > > > > > > To set data to a 3-deep path offset: > > > path-data > > > path1 > > > optional selector > > > path-data > > > path2 > > > optional selector > > > path-data > > > path3 > > > optional selector > > > dataraw > > > > > > > > > If a response is asked back, thats exactly how the response would look > > > like as well. > > > > > > The other way which is to set data on multiple nested paths: > > > > > > path-data > > > path1 > > > optional selector > > > dataraw > > > path-data > > > path2 > > > optional selector > > > dataraw > > > path-data > > > path3 > > > optional selector > > > dataraw > > > > > > Granted the end result will be grossly ineefficient since it will have a > > > lot of redundant information in the three path-datas above if path1 is > > > relative to path2 and path3 is realtive to path2. > > > For this we can use what i have seen in a few classifiers as an > > > optimization; these sorts of classifiers hacve a "continue" construct > > > which translates to "continue looking up where you last left off". > > > We can have something similar as a flag - so on path2 and path3 it would > > > say "the previous path+selector counts as part of this path". So path1 + > > > its selectors will be part of path2+ its selectors, which is also part > > > of path3 and its selectors. Clearly the flag is not useful on the first > > > path-data it involves inheritance and can be ignored there. > > > > > > Heres my worry: I think what Weiming wants in this case is a corner case > > > which while we must satisfy the end result should not break the simple > > > design rule of "optimize for the majority" > > > > > > cheers, > > > jamal > > > > > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > > You raise an interesting question of where the element by element SET > > > > results go. > > > > > > > > One of the drawbacks of allowing multiple path-data elements inside a > > > > operation TLV is that it no longer suffices to return the response > > code at > > > > the operation TLV level. > > > > Therefore, I would presume, we will have to return the response codes in > > > > the individual path-data TLVs. > > > > I would not want to return the results as a separate parallel TLV, as > > that > > > > would imply some kind of matching that would get quite confusing. I > > > > suppose that means that the actual syntax becomes: > > > > > > > > DATAINFO := [SELECTOR] [+ | + | +] > > > > > > > > Where SET Result is used only in the response to a SET, and occurs where > > > > the DATARAW elements were in the set request, indicating for each > > dataraw > > > > whether it was successfully set. > > > > > > > > Yours, > > > > Joel > > > > > > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > > >It quite gets to me that the list server often ate my posts. I do have > > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > > > >Hopefully this post can work. > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > > > > > > > and just leave out the "DATA" line. I believe this allows the > > nesting, is > > > > > > decidable by the parser, and does what we need. > > > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > > > > > > > >Yes, this makes it more clear, but I still see the value to modify > > it to: > > > > > > > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > > > > > > > >I suppose a SET request that has format as "path path-data1 path-data2 > > > > >path-data3", whos response will have format as "path path-data1 > > path-data2 > > > > >path-data3 data", the last data TLV is for the SET result responses. > > > > > > > > > >Cheers, > > > > >Weiming > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 09:29: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 JAA05393 for ; Wed, 9 Feb 2005 09:29:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyt9r-0008Uz-BN for forces-archive@IETF.ORG; Wed, 09 Feb 2005 09:49: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.00F7B34C@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 9:29:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57145480 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 09:28:42 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 09:28:42 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9099571 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 09 Feb 2005 09:28:42 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050209092514.03183378@localhost> Date: Wed, 9 Feb 2005 09:28:02 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107956192.1095.325.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 If we adopt an "all or none" rule for SETs in a single operation TLV, then we don't need the SETRESULT TLV. However, our current approach is that each inividual SET may succeed or fail individually. In that case, the results must somehow indicate which ones succeeded and which ones failed. The obvious place structurally to put the success or failure is with the indivdual item that succeeded or failed. Which is why I am suggesting replacing the DATARAW items in the request with the SETRESULT in the response. If the request wanted verbose response, then the DATARAW should be included inside the SETRESULT. (As an aside, could someone explain the value of a verbose set response. I seem to have missed the use case that motivates it?) Thank you, Joel At 08:36 AM 2/9/2005, Jamal Hadi Salim wrote: >On Wed, 2005-02-09 at 07:06, Joel M. Halpern wrote: > > There are actual several aspects to this example. > > > > 1) I do not think that SET responses need to carry the DATARAW. The CE > > knows what it sent. > > 1') Therefore, I would think it suffices to replace the DATARAW with the > > SETRESULT TLV. If we really want the data shipped back, we can put it > > inside the SETRESULT. > >We already have a verbosity flag on the main header that i posted on >earlier; a request for a verbose response indicates desire to have >DATARAW sent back. >i.e in a response to a config/set you get a configresponse/set with only >thing being different is the configs when the set is echoed back. > >Is using the SETRESULT going to reduce the number of bits on the wire? >Reading Weimings example i see in fact it uses more bits than just >echoing back the the set operation (but that maybe unintended). >Does SETRESULT provide more simplicty than what we already have? >If i read Weiming correctly he wants to move this request flag into the >path flags. Thats going to create complexity IMO. > > > 2) This particular example shows the combination of multiple target paths > > and multiple instances. This cross mapping creates two problems such that > > I would strongly prefer not to do this. > > 2a) The FE in processing this request has to realize that the multiple > > inner path-data elements are not intneded to be used one each for he > > selector targets, but rather are all supposed to be used for all the > > selector targets. This is actually a behavior (7) which I did not > describe > > in my earlier note because it seems undecidable. > > 2b) Even if we used the simpler case that correspond to case (6), where > all > > that is being set was j1 in each selector target, there is still a problem > > of how the result is returned. The only thing I can see to do is for the > > FE to explode the single PATH-DATA into a collection of PATH-DATA, as many > > as the selector elements, to hold the SET RESULTS. The complexity of this > > result is part of the cost of behaviors (3) and (6). > >Or to just echo back the operation on success when verbosity is >requested, no? > >cheers, >jamal > > > Yours, > > Joel M. Halpern > > > > At 01:50 AM 2/9/2005, Wang,Weiming wrote: > > >Hi Jamal,David,Joel,et al, > > > >[..] > > >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). > > > > > >We can setup a Set message for this task as below: > > > > > >Op=Set > > >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) > > >path(3)-Data(300) > > > > > >Two ways to the Response to this Set message: > > >1. > > >Op=SetResponse > > >Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} > > >path(2)-{Data(200),DataSetResult} path(3)-{Data(300),DataSetResult} > > > > > > > > >2. > > >Op=SetResponse > > >Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) > > >path(3)-Data(300) DataTLVforSetResult > > > > > >I just think that the 2 is more efficient. > > > > > >Cheers, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Jamal Hadi Salim" > > >Subject: Re: Protocol Operations > > > > > > > > > > I am not sure i got the SETRESULT; going by what Weiming asked for > > > > earlier, we have the following facilities: > > > > > > > > To set data to a 3-deep path offset: > > > > path-data > > > > path1 > > > > optional selector > > > > path-data > > > > path2 > > > > optional selector > > > > path-data > > > > path3 > > > > optional selector > > > > dataraw > > > > > > > > > > > > If a response is asked back, thats exactly how the response would look > > > > like as well. > > > > > > > > The other way which is to set data on multiple nested paths: > > > > > > > > path-data > > > > path1 > > > > optional selector > > > > dataraw > > > > path-data > > > > path2 > > > > optional selector > > > > dataraw > > > > path-data > > > > path3 > > > > optional selector > > > > dataraw > > > > > > > > Granted the end result will be grossly ineefficient since it will > have a > > > > lot of redundant information in the three path-datas above if path1 is > > > > relative to path2 and path3 is realtive to path2. > > > > For this we can use what i have seen in a few classifiers as an > > > > optimization; these sorts of classifiers hacve a "continue" construct > > > > which translates to "continue looking up where you last left off". > > > > We can have something similar as a flag - so on path2 and path3 it > would > > > > say "the previous path+selector counts as part of this path". So > path1 + > > > > its selectors will be part of path2+ its selectors, which is also part > > > > of path3 and its selectors. Clearly the flag is not useful on the first > > > > path-data it involves inheritance and can be ignored there. > > > > > > > > Heres my worry: I think what Weiming wants in this case is a corner > case > > > > which while we must satisfy the end result should not break the simple > > > > design rule of "optimize for the majority" > > > > > > > > cheers, > > > > jamal > > > > > > > > On Tue, 2005-02-08 at 06:59, Joel M. Halpern wrote: > > > > > You raise an interesting question of where the element by element SET > > > > > results go. > > > > > > > > > > One of the drawbacks of allowing multiple path-data elements inside a > > > > > operation TLV is that it no longer suffices to return the response > > > code at > > > > > the operation TLV level. > > > > > Therefore, I would presume, we will have to return the response > codes in > > > > > the individual path-data TLVs. > > > > > I would not want to return the results as a separate parallel > TLV, as > > > that > > > > > would imply some kind of matching that would get quite confusing. I > > > > > suppose that means that the actual syntax becomes: > > > > > > > > > > DATAINFO := [SELECTOR] [+ | + | +] > > > > > > > > > > Where SET Result is used only in the response to a SET, and > occurs where > > > > > the DATARAW elements were in the set request, indicating for each > > > dataraw > > > > > whether it was successfully set. > > > > > > > > > > Yours, > > > > > Joel > > > > > > > > > > At 11:22 PM 2/7/2005, Wang,Weiming wrote: > > > > > >It quite gets to me that the list server often ate my posts. I > do have > > > > > >sent some mails but that cann't be seen on the list till now. > > > > > > > > > > > >Hopefully this post can work. > > > > > > > > > > > >----- Original Message ----- > > > > > >From: "Joel M. Halpern" > > > > > >Subject: Re: Protocol Operations > > > > > > > > > > > > > > > > > > > I actually think we could get away with: > > > > > > > > > > > > > > DATAINFO := [SELECTOR] [ | +] > > > > > > > > > > > > > > and just leave out the "DATA" line. I believe this allows the > > > nesting, is > > > > > > > decidable by the parser, and does what we need. > > > > > > > > > > > > > > we can in fact collapse further in the BNF to: > > > > > > > > > > > > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > > > > > > > > > >Yes, this makes it more clear, but I still see the value to modify > > > it to: > > > > > > > > > > > >PATH-DATA TLV := [SELECTOR] [+] [+] > > > > > > > > > > > >I suppose a SET request that has format as "path path-data1 > path-data2 > > > > > >path-data3", whos response will have format as "path path-data1 > > > path-data2 > > > > > >path-data3 data", the last data TLV is for the SET result responses. > > > > > > > > > > > >Cheers, > > > > > >Weiming > > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 10:59: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 KAA13029 for ; Wed, 9 Feb 2005 10:59:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyuYy-00025W-6X for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:19:38 -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.00F7B892@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 10:59:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57154622 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 10:58:59 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 10:58: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 2005020907593322:13939 ; Wed, 9 Feb 2005 07:59:33 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzny.localdomain> <6.2.0.14.0.20050209092514.03183378@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 02/09/2005 07:59:33 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 07:59:35 AM, Serialize complete at 02/09/2005 07:59:35 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107964736.1076.37.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 10:58:56 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations - message response formating To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050209092514.03183378@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit I think it is safe to say we have moved on to a slightly different discussion. So i changed the subject slightly. On Wed, 2005-02-09 at 09:28, Joel M. Halpern wrote: > If we adopt an "all or none" rule for SETs in a single operation TLV, then > we don't need the SETRESULT TLV. > However, our current approach is that each inividual SET may succeed or > fail individually. > In that case, the results must somehow indicate which ones succeeded and > which ones failed. > Ok, Good point. My take so far has been the granularity for atomicity at the operational level. Within one operation theres an implicit all or none view and that if you are sensitive about this then you will split things into different operations (which maybe of the same type). However, I think this may be insufficient. > The obvious place structurally to put the success or failure is with the > indivdual item that succeeded or failed. Which is why I am suggesting > replacing the DATARAW items in the request with the SETRESULT in the > response. If the request wanted verbose response, then the DATARAW should > be included inside the SETRESULT. > Theres several verbosity levels to this: 1a) I may not care at all about the SET result. 1b) Or i may care only to know if it got at the other end. In which case i would just ask for a main header ACK to ensure that the FE received my message but nothing more. Use case: Example unidirectional heartbeat. A more involved heartbeat would occasionally ask for acknowledgement or a full response(a pong to the ping) always but thats a se. 2a) If the error codes being returned are simple pass/failed type then echoing back the SET in configresponse with a flag (currently inside the operation) in my opinion should suffice. 2b) I should be able to request for the above but also get a shortcut in the main header flags which says "you need to look at the operational flags further". The NACK flag should suffice to indicate this in the main header. Use case: Useful when execution success is certain and reliable delivery since saves on bandwidth. An example is when you are doing periodic sync updates in which you dont care if a message or two get lost. But you care if the update didnt succeed. 3)If the error code is to nail it down to details such as "we couldnt install this entry because the table was full" then i can see we would need per data being created/replaced a TLV of some form which would describe what happened. Maybe the TLV is only needed in the case of a failure. An improvement over 2(same use case), just more bandwidth intensive. 4) Like mentioned so far you may want the dataraw to be reported back. Essentially what sent is responded to in full with status regardless of whether it failed or succeeded. Use case: This is paranoia mode which uses a lot more bandwidth than other modes (allows sender to validate what was sent). > (As an aside, could someone explain the value of a verbose set response. I > seem to have missed the use case that motivates it?) Refer to 4 above. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:12: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 LAA13967 for ; Wed, 9 Feb 2005 11:12:25 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyulr-0002MO-SO for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:32:58 -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.00F7B81B@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:12:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57156542 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:12:19 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:12:19 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9100670 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 09 Feb 2005 11:12:19 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzny.localdomain> <6.2.0.14.0.20050209092514.03183378@localhost> <1107964736.1076.37.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050209110855.031a0d60@localhost> Date: Wed, 9 Feb 2005 11:11:12 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Protocol Operations - message response formating To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1107964736.1076.37.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I understand the description. What I don't understand is why we need to support this mode. If the CE is that paranoid, it can do a GET after it does the SET. Having an option to echo the data back in the SET response adds more protocol complexity without an added value I can understand. On the rest of it, the issue seems to come back to the ganularity. If the WG agrees that an operation TLV always succeeds or fails together, then I am happy not to introduce SETRESULT TLVs buried inside the OPERATION response. Yours, Joel At 10:58 AM 2/9/2005, Jamal Hadi Salim wrote: >4) Like mentioned so far you may want the dataraw to be reported back. > >Essentially what sent is responded to in full with status regardless of >whether it failed or succeeded. > >Use case: >This is paranoia mode which uses a lot more bandwidth than other modes >(allows sender to validate what was sent). > > > > (As an aside, could someone explain the value of a verbose set > response. I > > seem to have missed the use case that motivates it?) > >Refer to 4 above. From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:20: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 LAA14459 for ; Wed, 9 Feb 2005 11:20:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyutF-0002XH-DH for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:40: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.00F7B884@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:20:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57156920 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:20:00 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:19:56 -0500 Received: from [220.192.124.205] by 202.96.99.56 with StormMail ESMTP id 6322.3606408285; Thu, 10 Feb 2005 00:49:51 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.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 Approved-By: "Wang,Weiming" Message-ID: <00b101c50ec3$0e3345e0$907cc0dc@WwmLapSamsung> Date: Thu, 10 Feb 2005 00:13:50 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com, "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: base64 SGkgSmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwg SGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpTdWJqZWN0OiBSZTogUHJvdG9jb2wgT3BlcmF0 aW9ucw0KPiANCj4gSXMgdXNpbmcgdGhlIFNFVFJFU1VMVCBnb2luZyB0byByZWR1Y2UgdGhlIG51 bWJlciBvZiBiaXRzIG9uIHRoZSB3aXJlPw0KPiBSZWFkaW5nIFdlaW1pbmdzIGV4YW1wbGUgaSBz ZWUgaW4gZmFjdCBpdCB1c2VzIG1vcmUgYml0cyB0aGFuIGp1c3QNCj4gZWNob2luZyBiYWNrIHRo ZSB0aGUgc2V0IG9wZXJhdGlvbiAoYnV0IHRoYXQgbWF5YmUgdW5pbnRlbmRlZCkuDQo+IERvZXMg U0VUUkVTVUxUIHByb3ZpZGUgbW9yZSBzaW1wbGljdHkgdGhhbiB3aGF0IHdlIGFscmVhZHkgaGF2 ZT8NCj4gSWYgaSByZWFkIFdlaW1pbmcgY29ycmVjdGx5IGhlIHdhbnRzIHRvIG1vdmUgdGhpcyBy ZXF1ZXN0IGZsYWcgaW50byB0aGUNCj4gcGF0aCBmbGFncy4gVGhhdHMgZ29pbmcgdG8gY3JlYXRl IGNvbXBsZXhpdHkgSU1PLg0KSSdtIGFmcmFpZCB0aGlzIGlzIG5vdCB0aGUgcG9pbnQgYXQgYWxs LiBUaGUgYWN0dWFsIHBvaW50IGlzLCBJIHRoaW5rIHRoZSAjMiBpbiBteSBleGFtcGxlIGFzOiAN Cg0KIzI6DQpPcD1TZXRSZXNwb25zZQ0KUGF0aCg0KSBJbmRleFRMVigxLDMsNSw3LDkpIHBhdGgo MSktRGF0YSgxMDApIHBhdGgoMiktRGF0YSgyMDApIHBhdGgoMyktRGF0YSgzMDApIERhdGFUTFZm b3JTZXRSZXN1bHQNCg0KbWF5IGFsc28gYmUgYSBuZWNlc3NhcnkgZm9ybWF0IGZvciBzZXQgcmVz cG9uc2VzLCBoZW5zZSBvdXIgQk5GIHNob3VsZCBzdXBwb3J0IGl0IGFzIHdlbGwgYXMgIzEgd2F5 LlRoZW4sIGlmIHdlIGRlZmluZSBQYXRoLURhdGEgVExWIGFzOg0KUEFUSC1EQVRBIFRMViA6PSA8 UEFUSD4gW1NFTEVDVE9SXSBbPERBVEE+KyB8IDxQQVRILURBVEE+K10NCml0IHdpbGwgbm90IHN1 cHBvcnQgdGhlICMyIGZvcm1hdC4gQXMgYSByZXN1bHQsIEkgc3VnZ2VzdCANClBBVEgtREFUQSBU TFYgOj0gPFBBVEg+IFtTRUxFQ1RPUl0gWzxQQVRILURBVEE+K10gWzxEQVRBPitdDQp3aGljaCB3 aWxsIHN1cHBvcnQgIzIgZm9ybWF0IGFzIHdlbGwgYXMgIzEgZm9ybWF0Lg0KDQpCdXQgSSBoYXZl IHRvIHNheSB0aGlzIGlzIGEgc3ViIGlzc3VlIGN1cnJlbnRseSwgSSBjYW4gbGl2ZSB3aXRoIGRl ZmVyIGl0IGxhdGVyLiANCg0KQ2hlZXJzLA0KV2VpbWluZw0KICANCj4gDQo+ID4gMikgVGhpcyBw YXJ0aWN1bGFyIGV4YW1wbGUgc2hvd3MgdGhlIGNvbWJpbmF0aW9uIG9mIG11bHRpcGxlIHRhcmdl dCBwYXRocyANCj4gPiBhbmQgbXVsdGlwbGUgaW5zdGFuY2VzLiAgVGhpcyBjcm9zcyBtYXBwaW5n IGNyZWF0ZXMgdHdvIHByb2JsZW1zIHN1Y2ggdGhhdCANCj4gPiBJIHdvdWxkIHN0cm9uZ2x5IHBy ZWZlciBub3QgdG8gZG8gdGhpcy4NCj4gPiAyYSkgVGhlIEZFIGluIHByb2Nlc3NpbmcgdGhpcyBy ZXF1ZXN0IGhhcyB0byByZWFsaXplIHRoYXQgdGhlIG11bHRpcGxlIA0KPiA+IGlubmVyIHBhdGgt ZGF0YSBlbGVtZW50cyBhcmUgbm90IGludG5lZGVkIHRvIGJlIHVzZWQgb25lIGVhY2ggZm9yIGhl IA0KPiA+IHNlbGVjdG9yIHRhcmdldHMsIGJ1dCByYXRoZXIgYXJlIGFsbCBzdXBwb3NlZCB0byBi ZSB1c2VkIGZvciBhbGwgdGhlIA0KPiA+IHNlbGVjdG9yIHRhcmdldHMuICBUaGlzIGlzIGFjdHVh bGx5IGEgYmVoYXZpb3IgKDcpIHdoaWNoIEkgZGlkIG5vdCBkZXNjcmliZSANCj4gPiBpbiBteSBl YXJsaWVyIG5vdGUgYmVjYXVzZSBpdCBzZWVtcyB1bmRlY2lkYWJsZS4NCj4gPiAyYikgRXZlbiBp ZiB3ZSB1c2VkIHRoZSBzaW1wbGVyIGNhc2UgdGhhdCBjb3JyZXNwb25kIHRvIGNhc2UgKDYpLCB3 aGVyZSBhbGwgDQo+ID4gdGhhdCBpcyBiZWluZyBzZXQgd2FzIGoxIGluIGVhY2ggc2VsZWN0b3Ig dGFyZ2V0LCB0aGVyZSBpcyBzdGlsbCBhIHByb2JsZW0gDQo+ID4gb2YgaG93IHRoZSByZXN1bHQg aXMgcmV0dXJuZWQuICBUaGUgb25seSB0aGluZyBJIGNhbiBzZWUgdG8gZG8gaXMgZm9yIHRoZSAN Cj4gPiBGRSB0byBleHBsb2RlIHRoZSBzaW5nbGUgUEFUSC1EQVRBIGludG8gYSBjb2xsZWN0aW9u IG9mIFBBVEgtREFUQSwgYXMgbWFueSANCj4gPiBhcyB0aGUgc2VsZWN0b3IgZWxlbWVudHMsIHRv IGhvbGQgdGhlIFNFVCBSRVNVTFRTLiAgVGhlIGNvbXBsZXhpdHkgb2YgdGhpcyANCj4gPiByZXN1 bHQgaXMgcGFydCBvZiB0aGUgY29zdCBvZiBiZWhhdmlvcnMgKDMpIGFuZCAoNikuDQo+IA0KPiBP ciB0byBqdXN0IGVjaG8gYmFjayB0aGUgb3BlcmF0aW9uIG9uIHN1Y2Nlc3Mgd2hlbiB2ZXJib3Np dHkgaXMNCj4gcmVxdWVzdGVkLCBubz8NCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4gDQo+ID4g WW91cnMsDQo+ID4gSm9lbCBNLiBIYWxwZXJuDQo+ID4gDQo+ID4gQXQgMDE6NTAgQU0gMi85LzIw MDUsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPiA+SGkgSmFtYWwsRGF2aWQsSm9lbCxldCBhbCwN Cj4gPiA+DQo+IFsuLl0NCj4gPiA+Tm93LCB0aGUgY29uZmlndXJlIHRhc2sgaXM6IHRvIHNldCB0 aGUgajEgdG8gMTAwLCBhbmQgajIgdG8gMjAwLCBqMyB0byANCj4gPiA+MzAwLCBhbmQNCj4gPiA+ cmVtYWluIGo0IGFzIGl0IGlzLCAgZm9yICBJbmRleCBvZiB0aGUgdGFibGUgKDEsIDMsIDUsIDcs IDkpLg0KPiA+ID4NCj4gPiA+V2UgY2FuIHNldHVwIGEgU2V0IG1lc3NhZ2UgZm9yIHRoaXMgdGFz ayBhcyBiZWxvdzoNCj4gPiA+DQo+ID4gPk9wPVNldA0KPiA+ID5QYXRoKDQpIEluZGV4VExWKDEs Myw1LDcsOSkgcGF0aCgxKS1EYXRhKDEwMCkgcGF0aCgyKS1EYXRhKDIwMCkgDQo+ID4gPnBhdGgo MyktRGF0YSgzMDApDQo+ID4gPg0KPiA+ID5Ud28gd2F5cyB0byB0aGUgUmVzcG9uc2UgdG8gdGhp cyBTZXQgbWVzc2FnZToNCj4gPiA+MS4NCj4gPiA+T3A9U2V0UmVzcG9uc2UNCj4gPiA+UGF0aCg0 KSBJbmRleFRMVigxLDMsNSw3LDkpIHBhdGgoMSkte0RhdGEoMTAwKSxEYXRhU2V0UmVzdWx0fSAN Cj4gPiA+cGF0aCgyKS17RGF0YSgyMDApLERhdGFTZXRSZXN1bHR9ICBwYXRoKDMpLXtEYXRhKDMw MCksRGF0YVNldFJlc3VsdH0NCj4gPiA+DQo+ID4gPg0KPiA+ID4yLg0KPiA+ID5PcD1TZXRSZXNw b25zZQ0KPiA+ID5QYXRoKDQpIEluZGV4VExWKDEsMyw1LDcsOSkgcGF0aCgxKS1EYXRhKDEwMCkg cGF0aCgyKS1EYXRhKDIwMCkgDQo+ID4gPnBhdGgoMyktRGF0YSgzMDApIERhdGFUTFZmb3JTZXRS ZXN1bHQNCj4gPiA+DQo+ID4gPkkganVzdCB0aGluayB0aGF0IHRoZSAyIGlzIG1vcmUgZWZmaWNp ZW50Lg0KPiA+ID4NCj4gPiA+Q2hlZXJzLA0KPiA+ID5XZWltaW5nDQo+ID4gPg0KPiA+ID4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gPkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8 aGFkaUB6bnl4LmNvbT4NCj4gPiA+U3ViamVjdDogUmU6IFByb3RvY29sIE9wZXJhdGlvbnMNCj4g PiA+DQo+ID4gPg0KPiA+ID4gPiBJIGFtIG5vdCBzdXJlIGkgZ290IHRoZSBTRVRSRVNVTFQ7IGdv aW5nIGJ5IHdoYXQgV2VpbWluZyBhc2tlZCBmb3INCj4gPiA+ID4gZWFybGllciwgd2UgaGF2ZSB0 aGUgZm9sbG93aW5nIGZhY2lsaXRpZXM6DQo+ID4gPiA+DQo+ID4gPiA+IFRvIHNldCBkYXRhIHRv IGEgMy1kZWVwIHBhdGggb2Zmc2V0Og0KPiA+ID4gPiBwYXRoLWRhdGENCj4gPiA+ID4gcGF0aDEN Cj4gPiA+ID4gb3B0aW9uYWwgc2VsZWN0b3INCj4gPiA+ID4gcGF0aC1kYXRhDQo+ID4gPiA+IHBh dGgyDQo+ID4gPiA+IG9wdGlvbmFsIHNlbGVjdG9yDQo+ID4gPiA+IHBhdGgtZGF0YQ0KPiA+ID4g PiBwYXRoMw0KPiA+ID4gPiBvcHRpb25hbCBzZWxlY3Rvcg0KPiA+ID4gPiBkYXRhcmF3DQo+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPiA+IElmIGEgcmVzcG9uc2UgaXMgYXNrZWQgYmFjaywgdGhhdHMg ZXhhY3RseSBob3cgdGhlIHJlc3BvbnNlIHdvdWxkIGxvb2sNCj4gPiA+ID4gbGlrZSBhcyB3ZWxs Lg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgb3RoZXIgd2F5IHdoaWNoIGlzIHRvIHNldCBkYXRhIG9u IG11bHRpcGxlIG5lc3RlZCBwYXRoczoNCj4gPiA+ID4NCj4gPiA+ID4gcGF0aC1kYXRhDQo+ID4g PiA+IHBhdGgxDQo+ID4gPiA+IG9wdGlvbmFsIHNlbGVjdG9yDQo+ID4gPiA+IGRhdGFyYXcNCj4g PiA+ID4gcGF0aC1kYXRhDQo+ID4gPiA+IHBhdGgyDQo+ID4gPiA+IG9wdGlvbmFsIHNlbGVjdG9y DQo+ID4gPiA+IGRhdGFyYXcNCj4gPiA+ID4gcGF0aC1kYXRhDQo+ID4gPiA+IHBhdGgzDQo+ID4g PiA+IG9wdGlvbmFsIHNlbGVjdG9yDQo+ID4gPiA+IGRhdGFyYXcNCj4gPiA+ID4NCj4gPiA+ID4g R3JhbnRlZCB0aGUgZW5kIHJlc3VsdCB3aWxsIGJlIGdyb3NzbHkgaW5lZWZmaWNpZW50IHNpbmNl IGl0IHdpbGwgaGF2ZSBhDQo+ID4gPiA+IGxvdCBvZiByZWR1bmRhbnQgaW5mb3JtYXRpb24gaW4g dGhlIHRocmVlIHBhdGgtZGF0YXMgYWJvdmUgaWYgcGF0aDEgaXMNCj4gPiA+ID4gcmVsYXRpdmUg dG8gcGF0aDIgYW5kIHBhdGgzIGlzIHJlYWx0aXZlIHRvIHBhdGgyLg0KPiA+ID4gPiBGb3IgdGhp cyB3ZSBjYW4gdXNlIHdoYXQgaSBoYXZlIHNlZW4gaW4gYSBmZXcgY2xhc3NpZmllcnMgYXMgYW4N Cj4gPiA+ID4gb3B0aW1pemF0aW9uOyB0aGVzZSBzb3J0cyBvZiBjbGFzc2lmaWVycyBoYWN2ZSBh ICAiY29udGludWUiIGNvbnN0cnVjdA0KPiA+ID4gPiB3aGljaCB0cmFuc2xhdGVzIHRvICJjb250 aW51ZSBsb29raW5nIHVwIHdoZXJlIHlvdSBsYXN0IGxlZnQgb2ZmIi4NCj4gPiA+ID4gV2UgY2Fu IGhhdmUgc29tZXRoaW5nIHNpbWlsYXIgYXMgYSBmbGFnIC0gc28gb24gcGF0aDIgYW5kIHBhdGgz IGl0IHdvdWxkDQo+ID4gPiA+IHNheSAidGhlIHByZXZpb3VzIHBhdGgrc2VsZWN0b3IgY291bnRz IGFzIHBhcnQgb2YgdGhpcyBwYXRoIi4gU28gcGF0aDEgKw0KPiA+ID4gPiBpdHMgc2VsZWN0b3Jz IHdpbGwgYmUgcGFydCBvZiBwYXRoMisgaXRzIHNlbGVjdG9ycywgd2hpY2ggaXMgYWxzbyBwYXJ0 DQo+ID4gPiA+IG9mIHBhdGgzIGFuZCBpdHMgc2VsZWN0b3JzLiBDbGVhcmx5IHRoZSBmbGFnIGlz IG5vdCB1c2VmdWwgb24gdGhlIGZpcnN0DQo+ID4gPiA+IHBhdGgtZGF0YSBpdCBpbnZvbHZlcyBp bmhlcml0YW5jZSBhbmQgY2FuIGJlIGlnbm9yZWQgdGhlcmUuDQo+ID4gPiA+DQo+ID4gPiA+IEhl cmVzIG15IHdvcnJ5OiBJIHRoaW5rIHdoYXQgV2VpbWluZyB3YW50cyBpbiB0aGlzIGNhc2UgaXMg YSBjb3JuZXIgY2FzZQ0KPiA+ID4gPiB3aGljaCB3aGlsZSB3ZSBtdXN0IHNhdGlzZnkgdGhlIGVu ZCByZXN1bHQgc2hvdWxkIG5vdCBicmVhayB0aGUgc2ltcGxlDQo+ID4gPiA+IGRlc2lnbiBydWxl IG9mICJvcHRpbWl6ZSBmb3IgdGhlIG1ham9yaXR5Ig0KPiA+ID4gPg0KPiA+ID4gPiBjaGVlcnMs DQo+ID4gPiA+IGphbWFsDQo+ID4gPiA+DQo+ID4gPiA+IE9uIFR1ZSwgMjAwNS0wMi0wOCBhdCAw Njo1OSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPiA+ID4gPiA+IFlvdSByYWlzZSBhbiBpbnRl cmVzdGluZyBxdWVzdGlvbiBvZiB3aGVyZSB0aGUgZWxlbWVudCBieSBlbGVtZW50IFNFVA0KPiA+ ID4gPiA+IHJlc3VsdHMgZ28uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbmUgb2YgdGhlIGRyYXdi YWNrcyBvZiBhbGxvd2luZyBtdWx0aXBsZSBwYXRoLWRhdGEgZWxlbWVudHMgaW5zaWRlIGENCj4g PiA+ID4gPiBvcGVyYXRpb24gVExWIGlzIHRoYXQgaXQgbm8gbG9uZ2VyIHN1ZmZpY2VzIHRvIHJl dHVybiB0aGUgcmVzcG9uc2UgDQo+ID4gPiBjb2RlIGF0DQo+ID4gPiA+ID4gdGhlIG9wZXJhdGlv biBUTFYgbGV2ZWwuDQo+ID4gPiA+ID4gVGhlcmVmb3JlLCBJIHdvdWxkIHByZXN1bWUsIHdlIHdp bGwgaGF2ZSB0byByZXR1cm4gdGhlIHJlc3BvbnNlIGNvZGVzIGluDQo+ID4gPiA+ID4gdGhlIGlu ZGl2aWR1YWwgcGF0aC1kYXRhIFRMVnMuDQo+ID4gPiA+ID4gSSB3b3VsZCBub3Qgd2FudCB0byBy ZXR1cm4gdGhlIHJlc3VsdHMgYXMgYSBzZXBhcmF0ZSBwYXJhbGxlbCBUTFYsIGFzIA0KPiA+ID4g dGhhdA0KPiA+ID4gPiA+IHdvdWxkIGltcGx5IHNvbWUga2luZCBvZiBtYXRjaGluZyB0aGF0IHdv dWxkIGdldCBxdWl0ZSBjb25mdXNpbmcuICBJDQo+ID4gPiA+ID4gc3VwcG9zZSB0aGF0IG1lYW5z IHRoYXQgdGhlIGFjdHVhbCBzeW50YXggYmVjb21lczoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IERB VEFJTkZPIDo9IFtTRUxFQ1RPUl0gWzxQQVRILURBVEE+KyB8IDxEQVRBUkFXPisgfCA8U0VUUkVT VUxUPitdDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaGVyZSBTRVQgUmVzdWx0IGlzIHVzZWQgb25s eSBpbiB0aGUgcmVzcG9uc2UgdG8gYSBTRVQsIGFuZCBvY2N1cnMgd2hlcmUNCj4gPiA+ID4gPiB0 aGUgREFUQVJBVyBlbGVtZW50cyB3ZXJlIGluIHRoZSBzZXQgcmVxdWVzdCwgaW5kaWNhdGluZyBm b3IgZWFjaCANCj4gPiA+IGRhdGFyYXcNCj4gPiA+ID4gPiB3aGV0aGVyIGl0IHdhcyBzdWNjZXNz ZnVsbHkgc2V0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gWW91cnMsDQo+ID4gPiA+ID4gSm9lbA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gQXQgMTE6MjIgUE0gMi83LzIwMDUsIFdhbmcsV2VpbWluZyB3 cm90ZToNCj4gPiA+ID4gPiA+SXQgcXVpdGUgZ2V0cyB0byBtZSB0aGF0IHRoZSBsaXN0IHNlcnZl ciBvZnRlbiBhdGUgbXkgcG9zdHMuIEkgZG8gaGF2ZQ0KPiA+ID4gPiA+ID5zZW50IHNvbWUgbWFp bHMgYnV0IHRoYXQgY2Fubid0IGJlIHNlZW4gb24gdGhlIGxpc3QgdGlsbCBub3cuDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID5Ib3BlZnVsbHkgIHRoaXMgcG9zdCBjYW4gd29yay4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID4gPiA+ RnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NCj4gPiA+ID4g PiA+U3ViamVjdDogUmU6IFByb3RvY29sIE9wZXJhdGlvbnMNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gPiBJIGFjdHVhbGx5IHRoaW5rIHdlIGNvdWxkIGdldCBhd2F5IHdp dGg6DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IERBVEFJTkZPIDo9IFtTRUxFQ1RPUl0g WzxEQVRBUkFXPiB8IDxQQVRILURBVEE+K10NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g YW5kIGp1c3QgbGVhdmUgb3V0IHRoZSAiREFUQSIgbGluZS4gIEkgYmVsaWV2ZSB0aGlzIGFsbG93 cyB0aGUgDQo+ID4gPiBuZXN0aW5nLCBpcw0KPiA+ID4gPiA+ID4gPiBkZWNpZGFibGUgYnkgdGhl IHBhcnNlciwgYW5kIGRvZXMgd2hhdCB3ZSBuZWVkLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiB3ZSBjYW4gaW4gZmFjdCBjb2xsYXBzZSBmdXJ0aGVyIGluIHRoZSBCTkYgdG86DQo+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFBBVEgtREFUQSBUTFYgOj0gPFBBVEg+IFtTRUxFQ1RP Ul0gWzxEQVRBPisgfCA8UEFUSC1EQVRBPitdDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID5ZZXMs IHRoaXMgbWFrZXMgaXQgbW9yZSBjbGVhciwgYnV0IEkgc3RpbGwgc2VlIHRoZSB2YWx1ZSB0byBt b2RpZnkgDQo+ID4gPiBpdCB0bzoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPlBBVEgtREFUQSBU TFYgOj0gPFBBVEg+IFtTRUxFQ1RPUl0gWzxQQVRILURBVEE+K10gWzxEQVRBPitdDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID5JIHN1cHBvc2UgIGEgU0VUIHJlcXVlc3QgdGhhdCBoYXMgZm9ybWF0 IGFzICJwYXRoIHBhdGgtZGF0YTEgcGF0aC1kYXRhMg0KPiA+ID4gPiA+ID5wYXRoLWRhdGEzIiwg d2hvcyByZXNwb25zZSB3aWxsIGhhdmUgZm9ybWF0IGFzICJwYXRoIHBhdGgtZGF0YTEgDQo+ID4g PiBwYXRoLWRhdGEyDQo+ID4gPiA+ID4gPnBhdGgtZGF0YTMgZGF0YSIsIHRoZSBsYXN0IGRhdGEg VExWIGlzIGZvciB0aGUgU0VUIHJlc3VsdCByZXNwb25zZXMuDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID5DaGVlcnMsDQo+ID4gPiA+ID4gPldlaW1pbmcNCj4gPiA+ID4NCg== From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:20: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 LAA14532 for ; Wed, 9 Feb 2005 11:20:45 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyutx-0002Yc-UW for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:41:18 -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.00F7B83E@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:20:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57157022 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:20:40 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:20:37 -0500 Received: from [220.192.124.205] by 202.96.99.56 with StormMail ESMTP id 6322.2105028806; Thu, 10 Feb 2005 00:51:29 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@! jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <1107954766.1544.300.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 Approved-By: "Wang,Weiming" Message-ID: <00ba01c50ec3$48e95530$907cc0dc@WwmLapSamsung> Date: Thu, 10 Feb 2005 00:16:46 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkFzIEkndiBhbHJlYWR5IHN0YXRlZCwgdGhlIGN1cnJlbnQgUGF0aC1EYXRhIEJO RiBtZWV0cyBteSB0aG91Z2h0cyBvbiB0aGUgc3VicGF0aHMgd2VsbC4gV2hhdCB3ZSBhcmUgbm93 IGRpc2N1c3NpbmcgYXJlIGp1c3Qgc29tZSBzdWItaXNzdWVzLCBJIHRoaW5rLiBPZiBjb3Vyc2Us IHRoZXkgYXJlIGFsc28gdmVyeSBpbXBvcnRhbnQuIFRoZXNlIHN1Yi1pc3N1ZXMgbWF5IGluY2x1 ZGU6DQoNCjEuIFdoZXRoZXIgb3Igbm90IHdlIHNob3VsZCBwdXQgT3BlcmF0aW9uIGZsYWdzIGlu IFBhdGggZmxhZ3MuSSd2IGp1c3QgY2hlY2tlZCB5b3VyIG1haWwgdG8gSG9ybXV6ZC4gT25lIHBv aW50IEknbSBhIGxpdHRsZSBoYXJkIHRvIGFncmVlIHdpdGggeW91IGlzIHdoZW4geW91IG1lbnRp b24gImJlY2F1c2Ugd2UgaGF2ZSB0byBoYXZlIHBhdGggZmxhZ3MsIHdoeSBub3QgdG8gaGF2ZSBz b21lIGZsYWdzIGluIGl0IGFsc28gZm9yIG9wZXJhdGlvbnMiLiBNeSB0aG91Z2h0IGlzLCBldmVu IGlmIHdlIGhhdmUgYml0cyByb29tIGZvciB0aGUgZmxhZ3MsIGl0IGlzIHN0aWxsIG5vdCB2YWx1 YWJsZSBlbm91Z2ggdG8gbWFrZSB0aGUgb3BlcmF0aW9uIHN0cnVjdHVyZSBtb3JlIGNvbXBsZXgg d2l0aCBvbmUgbW9yZSBwYXJzZSBsZXZlbC4NCg0KMi5UaGUgQk5GIGZvcm1hdCBmb3IgUmVzcG9u c2UgbWVzc2FnZXMuDQoNCjMuVGhlIGZsYWcgZm9yIEluZGV4IGFuZCBCbG9jayBvcGVyYXRpb24g bWF5IGFsc28gbmVlZCBtb3JlIGRpc2N1c3Npb24uIEknbSB0aGlua2luZyBpZiB3ZSBvbmx5IG5l ZWQgb25lIGJpdCBmbGFnIGluc3RlYWQgb2YgMiBiaXRzIGZvciB0aGlzIHB1cnBvc2UuDQoNClRo YXQncyB0aGF0IEkgY3VycmVudGx5IGNhbiB0aGluayBvZiBmb3IgdGhlIEJORi4gSSBob3BlIG90 aGVyIGd1eXMgY2FuIHByb3ZpZGUgbW9yZS4NCg0KQ2hlZXJzLA0KV2VpbWluZw0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQHpu eXguY29tPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50OiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDA5LCAyMDA1IDk6MTIgUE0NClN1YmplY3Q6IFJlOiBQcm90b2NvbCBPcGVy YXRpb25zDQoNCg0KPiBXZWltaW5nLA0KPiANCj4gSSBqdXN0IG5vdGljZWQgdGhhdCBKb2VsIHJl c3BvbmRlZCBvbiBhbm90aGVyIGVtYWlsIHNvIGkgd2lsbCBmb2xsb3cgdXANCj4gdGhlcmUuIFF1 ZXN0aW9uOg0KPiBPdGhlciB0aGFuIHRoZXNlIG5ldyBpc3N1ZXM7IGlzIHRoZSBCTkYgZ29vZCBm b3Igd2hhdCB5b3Ugd2FudGVkPw0KPiBBcmUgeW91IGhhcHB5IGl0IGNhbiBkbyBwYXRoIGRhdGEg aW50ZXJsZWF2aW5nIHRoYXQgaXMgc3VmZmljaWVudCBmb3INCj4gd2hhdCB5b3Ugd2FudC4gSWYg dGhlIGFuc3dlciBpcyB5ZXMsIHRoYXQgd291bGQgYmUgb25lIGNoYXB0ZXIgd2UgY2FuDQo+IGNs b3NlLiANCj4gUGxlYXNlIHJlc3BvbmQgd2hlbiB5b3UgZ2V0IHRoZSB0aW1lIChJIHRoaW5rIEkg a25vdyB3aGVyZSBKb2VsIHN0YW5kcykuDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA0KDQo= From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:28: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 LAA14881 for ; Wed, 9 Feb 2005 11:28:24 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyv1L-0002gT-Fb for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:48: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 <5.00F7B8D9@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:28:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57158006 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:28:18 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:28:17 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020908285222:14097 ; Wed, 9 Feb 2005 08:28:52 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <01e901c505e3$fef9dc70$845c21d2@Necom.hzic.edu.cn> <1107115504.7847.67.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzny.localdomain> <6.2.0.14.0.20050209092514.03183378@localhost> <1107964736.1076.37.camel@jzny.localdomain> <6.2.0.14.0.20050209110855.031a0d60@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 02/09/2005 08:28:52 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 08:28:54 AM, Serialize complete at 02/09/2005 08:28:54 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107966494.1078.62.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 11:28:14 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations - message response formating To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050209110855.031a0d60@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Wed, 2005-02-09 at 11:11, Joel M. Halpern wrote: > I understand the description. > > What I don't understand is why we need to support this mode. > > If the CE is that paranoid, it can do a GET after it does the SET. Having > an option to echo the data back in the SET response adds more protocol > complexity without an added value I can understand. > Ok, Joel we can kill it if noone wants it. I dont see it as added complexity really - but lets move on. > On the rest of it, the issue seems to come back to the ganularity. If the > WG agrees that an operation TLV always succeeds or fails together, then I > am happy not to introduce SETRESULT TLVs buried inside the OPERATION response. > I am fine with the way you had described it earlier i.e i dont think granularity at the operation level is sufficient. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:35: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 LAA15308 for ; Wed, 9 Feb 2005 11:35:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyv87-0002ps-Eo for forces-archive@IETF.ORG; Wed, 09 Feb 2005 11:55: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.00F7BA9A@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:35:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57158708 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:35:19 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:35:17 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020908355203:14134 ; Wed, 9 Feb 2005 08:35:52 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzn! y.localdomain> <00b901c50ec3$372d89b0$907cc0dc@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 02/09/2005 08:35:52 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 08:35:53 AM, Serialize complete at 02/09/2005 08:35:53 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107966914.1077.66.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 11:35:15 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00b901c50ec3$372d89b0$907cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Weiming, On Wed, 2005-02-09 at 11:13, Wang,Weiming wrote: > Hi Jamal, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: Protocol Operations > > > > Is using the SETRESULT going to reduce the number of bits on the wire? > > Reading Weimings example i see in fact it uses more bits than just > > echoing back the the set operation (but that maybe unintended). > > Does SETRESULT provide more simplicty than what we already have? > > If i read Weiming correctly he wants to move this request flag into the > > path flags. Thats going to create complexity IMO. > I'm afraid this is not the point at all. The actual point is, I think the #2 in my example as: > > #2: > Op=SetResponse > Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300) DataTLVforSetResult > Whats in the DataTLVforSetResult? Maybe that will clarify things. > may also be a necessary format for set responses, hense our BNF should support it as well as #1 > way.Then, if we define Path-Data TLV as: > PATH-DATA TLV := [SELECTOR] [+ | +] > it will not support the #2 format. As a result, I suggest > PATH-DATA TLV := [SELECTOR] [+] [+] > which will support #2 format as well as #1 format. > > But I have to say this is a sub issue currently, I can live with defer it later. However I see the above as belonging to the previous discussion - so we cant close that chapter, yet. Look at example 17 in the document i posted which addresses this issue at the cost of more bits. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:39: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 LAA15668 for ; Wed, 9 Feb 2005 11:39:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvCM-0002vI-CI for forces-archive@IETF.ORG; Wed, 09 Feb 2005 12:00: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 <13.00F7B94E@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:39:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57159027 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:39:43 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:39:43 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020908401792:14154 ; Wed, 9 Feb 2005 08:40:17 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@! jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <1107954766.1544.300.camel@jzny.localdomain> <00ba01c50ec3$48e95530$907cc0dc@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 02/09/2005 08:40:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 08:40:19 AM, Serialize complete at 02/09/2005 08:40:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107967180.1077.72.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 11:39:40 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Protocol Operations Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00ba01c50ec3$48e95530$907cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit On Wed, 2005-02-09 at 11:16, Wang,Weiming wrote: > Jamal, > > As I'v already stated, the current Path-Data BNF meets my thoughts on the > subpaths well. What we are now discussing are just some sub-issues, > I think. Of course, they are also very important. These sub-issues may include: Based on your last email i think we havent really closed the previous discussion; can you look at example 17 and say if it is sufficient for you with current grammar? It does end up being a little inefficient. What you list below are fine issues to followup next and i am going to respond under a separate subject to them. cheers, jamal > 1. Whether or not we should put Operation flags in Path flags.I'v just > checked your mail to Hormuzd. One point I'm a little hard to agree with > you is when you mention "because we have to have path flags, why not to > have some flags in it also for operations". My thought is, even if we have > bits room for the flags, it is still not valuable enough to make the operation > structure more complex with one more parse level. > > 2.The BNF format for Response messages. > > 3.The flag for Index and Block operation may also need more discussion. I'm thinking > if we only need one bit flag instead of 2 bits for this purpose. > > That's that I currently can think of for the BNF. I hope other guys can provide more. > > Cheers, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Wednesday, February 09, 2005 9:12 PM > Subject: Re: Protocol Operations > > > > Weiming, > > > > I just noticed that Joel responded on another email so i will follow up > > there. Question: > > Other than these new issues; is the BNF good for what you wanted? > > Are you happy it can do path data interleaving that is sufficient for > > what you want. If the answer is yes, that would be one chapter we can > > close. > > Please respond when you get the time (I think I know where Joel stands). > > > > cheers, > > jamal > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 11:58: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 LAA16705 for ; Wed, 9 Feb 2005 11:58:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvUT-0003IE-7t for forces-archive@IETF.ORG; Wed, 09 Feb 2005 12:19: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 <18.00F7B927@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 11:58:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57160320 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 11:58:20 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 11:58:20 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005020908585471:14272 ; Wed, 9 Feb 2005 08:58:54 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <004d01c507a1$eb5b3780$020aa8c0@wwm1> <1107342450.1105.12.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@! jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <1107954766.1544.300.camel@jzny.localdomain> <00ba01c50ec3$48e95530$907cc0dc@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 02/09/2005 08:58:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/09/2005 08:58:56 AM, Serialize complete at 02/09/2005 08:58:56 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1107968297.1075.97.camel@jzny.localdomain> Date: Wed, 9 Feb 2005 11:58:17 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Next protocol issues Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00ba01c50ec3$48e95530$907cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Weiming, On Wed, 2005-02-09 at 11:16, Wang,Weiming wrote: > > 1. Whether or not we should put Operation flags in Path flags.I'v just > checked your mail to Hormuzd. > One point I'm a little hard to agree with you is when you > mention "because we have to have path flags, > why not to have some flags in it also for operations". My thought is, > even if we have bits room for the > flags, it is still not valuable enough to make the operation structure > more complex with one more parse level. Hormuzds arguement has been that you save bits by moving the flags therefore you are more efficient that way. This is not true unless you move all flags out. Your arguement is different in that you say it is complexity and an extra parsing level. Parsing of flags is something you MUST look at everytime regardless when you encounter a path - so it is not adding extra parsing level or complexity. Heres what we should do: Lets have someone else respond and say they feel strongly with some good reasons (in other words not a "me too" response) then i will have no problem moving just the operation flags out of the path but not every flag as indicated by Hormuzd. > 2.The BNF format for Response messages. > > 3.The flag for Index and Block operation may also need more discussion. > I'm thinking if we only need one bit flag instead of 2 bits for this purpose. > All valid points. I will add this to my list that i posted earlier for Friday meeting (0r we can continue discussing here). cheers, jamal > That's that I currently can think of for the BNF. I hope other guys can provide more. > > Cheers, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Wednesday, February 09, 2005 9:12 PM > Subject: Re: Protocol Operations > > > > Weiming, > > > > I just noticed that Joel responded on another email so i will follow up > > there. Question: > > Other than these new issues; is the BNF good for what you wanted? > > Are you happy it can do path data interleaving that is sufficient for > > what you want. If the answer is yes, that would be one chapter we can > > close. > > Please respond when you get the time (I think I know where Joel stands). > > > > cheers, > > jamal > > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 9 14: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 OAA27385 for ; Wed, 9 Feb 2005 14: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 1CyxRb-0006TI-34 for forces-archive@IETF.ORG; Wed, 09 Feb 2005 14:24:11 -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.00F7C057@cherry.ease.lsoft.com>; Wed, 9 Feb 2005 14:03:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57173027 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 9 Feb 2005 14:03:32 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 9 Feb 2005 14:03:29 -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 j19J3Rvw031097; Wed, 9 Feb 2005 19:03:27 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 j19J3CkQ028277; Wed, 9 Feb 2005 19:03:24 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 M2005020911004513485 ; Wed, 09 Feb 2005 11:00:48 -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, 9 Feb 2005 11:00:27 -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 Operations - message response formating Thread-Index: AcUOwitoxdZkkdPxRQeeEVKaJDapCwAFz95A X-OriginalArrivalTime: 09 Feb 2005 19:00:27.0375 (UTC) FILETIME=[9E238FF0:01C50ED9] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Wed, 9 Feb 2005 11:00:26 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Protocol Operations - message response formating Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable I am in agreement that I would just prefer the CE do a GET after the SET if the ack is not sufficient. Every flag/option we can remove without=20 significantly hurting functionality is a step in the right direction. -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Wednesday, February 09, 2005 8:11 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Protocol Operations - message response formating I understand the description. What I don't understand is why we need to support this mode. If the CE is that paranoid, it can do a GET after it does the SET. Having=20 an option to echo the data back in the SET response adds more protocol=20 complexity without an added value I can understand. On the rest of it, the issue seems to come back to the ganularity. If the=20 WG agrees that an operation TLV always succeeds or fails together, then I=20 am happy not to introduce SETRESULT TLVs buried inside the OPERATION response. Yours, Joel At 10:58 AM 2/9/2005, Jamal Hadi Salim wrote: >4) Like mentioned so far you may want the dataraw to be reported back. > >Essentially what sent is responded to in full with status regardless of >whether it failed or succeeded. > >Use case: >This is paranoia mode which uses a lot more bandwidth than other modes >(allows sender to validate what was sent). > > > > (As an aside, could someone explain the value of a verbose set=20 > response. I > > seem to have missed the use case that motivates it?) > >Refer to 4 above. From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 03:37: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 DAA06869 for ; Thu, 10 Feb 2005 03:37:32 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzA9M-0005RA-LD for forces-archive@IETF.ORG; Thu, 10 Feb 2005 03:58: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 <6.00F7E60A@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 3:37:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57229576 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 03:37:28 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 03:37:26 -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 j1A8bQK8021722; Thu, 10 Feb 2005 08:37:26 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1A8bQhO029755; Thu, 10 Feb 2005 08:37:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021000372605557 ; Thu, 10 Feb 2005 00:37:26 -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); Thu, 10 Feb 2005 00:37:26 -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 Operations Thread-Index: AcUOp93r24KyThTTQySXiJaBXFTSyAAnQJgg X-OriginalArrivalTime: 10 Feb 2005 08:37:26.0220 (UTC) FILETIME=[BFA5B8C0:01C50F4B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04355957@orsmsx408> Date: Thu, 10 Feb 2005 00:37:25 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Jamal, I'll try to keep my response short since seems like this thread is causing you some frustration. Just to clarify...that was not my intention, I resisted posting some of these comments last week till I thought some of the bigger issues were resolved...sorry for the trouble. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim As you can see all the other paths in that example do not need a F_SELBLK except for the outer/first one.=20 And only items with data need a replace but not ones with pure paths. To make it more inmteresting, there are examples where you would have F_SELBLK flags first and then F_SELKEY next and then REPLACE at the most inner nest where the data is to be found. [Yes this is true as the grammar currently stands. But do we really need to have F_SELBLK and F_SELKEY in the same Op TLV? I did see some use cases around this, but the reason for F_SELKEY was basically for content based Query in a Query msg. So if we restrict this combination and if there is only 1 F_SELBLK in an Op TLV for a Config msg then we should be able to eliminate the need for Flags in each PATH. I was thinking along these lines...let me know if this makes sense to you?] This was why earlier i said you cant get rid of the flags from the path because they are used to refine the path, and not just the operation. [understood] So removing the replace and create and putting them in the operations T, while looks of value, it does not change anything in terms of reducing the bit count because those flags are needed regardless. Hence my statement earlier that i didnt see they were any different in merit precisley because you are *not* gonna be able to remove the flags with path semantics; again if you could remove _all flags_ then what you are proposing will be valuable.=20 [Yes, this is what I am trying to achieve...so we are on the same page here] Removing just the operation enhancing flags is of cosmetic/philosophical value and should be defered to a later discussion. [I believe there is still value in this, Weiming and David pointed out some reasons as well] Having said all the above, if the document is unclear it needs to be fixed; it is not acceptable for the doc to do a poor job at explaining things.=20 [Some of these things are not crystal clear in the doc, I think it could be improved] Overall comment, as the doc stands today there are too many alternatives for doing the same thing which is not good for interoperability and causes some confusion to the reader as well. We should try and improve this aspect, restrict some of the alternatives if possible. Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 09:42: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 JAA04559 for ; Thu, 10 Feb 2005 09:42:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzFqh-0005Mv-19 for forces-archive@IETF.ORG; Thu, 10 Feb 2005 10:03: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 <6.00F7F5C2@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 9:42:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57280922 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 09:42:30 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 09:42:27 -0500 Received: from [220.192.124.101] by 202.96.99.56 with StormMail ESMTP id 6322.2105028806; Thu, 10 Feb 2005 23:13:35 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzn! y.localdomain> <00b901c50ec3$372d89b0$907cc0dc@WwmLapSamsung> <1107966914.1077.66.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 Approved-By: "Wang,Weiming" Message-ID: <008701c50f7e$bcd4b640$657cc0dc@WwmLapSamsung> Date: Thu, 10 Feb 2005 21:45:40 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: base64 SGkgSmFtYWwsDQoNCj4gPiA+IElzIHVzaW5nIHRoZSBTRVRSRVNVTFQgZ29pbmcgdG8gcmVkdWNl IHRoZSBudW1iZXIgb2YgYml0cyBvbiB0aGUgd2lyZT8NCj4gPiA+IFJlYWRpbmcgV2VpbWluZ3Mg ZXhhbXBsZSBpIHNlZSBpbiBmYWN0IGl0IHVzZXMgbW9yZSBiaXRzIHRoYW4ganVzdA0KPiA+ID4g ZWNob2luZyBiYWNrIHRoZSB0aGUgc2V0IG9wZXJhdGlvbiAoYnV0IHRoYXQgbWF5YmUgdW5pbnRl bmRlZCkuDQo+ID4gPiBEb2VzIFNFVFJFU1VMVCBwcm92aWRlIG1vcmUgc2ltcGxpY3R5IHRoYW4g d2hhdCB3ZSBhbHJlYWR5IGhhdmU/DQo+ID4gPiBJZiBpIHJlYWQgV2VpbWluZyBjb3JyZWN0bHkg aGUgd2FudHMgdG8gbW92ZSB0aGlzIHJlcXVlc3QgZmxhZyBpbnRvIHRoZQ0KPiA+ID4gcGF0aCBm bGFncy4gVGhhdHMgZ29pbmcgdG8gY3JlYXRlIGNvbXBsZXhpdHkgSU1PLg0KPiA+IEknbSBhZnJh aWQgdGhpcyBpcyBub3QgdGhlIHBvaW50IGF0IGFsbC4gVGhlIGFjdHVhbCBwb2ludCBpcywgSSB0 aGluayB0aGUgIzIgaW4gbXkgZXhhbXBsZSBhczogDQo+ID4gDQo+ID4gIzI6DQo+ID4gT3A9U2V0 UmVzcG9uc2UNCj4gPiBQYXRoKDQpIEluZGV4VExWKDEsMyw1LDcsOSkgcGF0aCgxKS1EYXRhKDEw MCkgcGF0aCgyKS1EYXRhKDIwMCkgcGF0aCgzKS1EYXRhKDMwMCkgRGF0YVRMVmZvclNldFJlc3Vs dA0KPiA+IA0KPiANCj4gV2hhdHMgaW4gdGhlIERhdGFUTFZmb3JTZXRSZXN1bHQ/IE1heWJlIHRo YXQgd2lsbCBjbGFyaWZ5IHRoaW5ncy4NClRoZSBEYXRhVExWZm9yU2V0UmVzdWx0IGlzIHRoZSBz YW1lIGFzIEpvZWwncyBTZXRSZXN1bHQgaW4gdGhhdCBpdCByZXNwb25zZXMgYmFjayB0aGUgU2V0 IHJlc3VsdCwgZGlmZmVyZW50IGZyb20gSm9lbCdzIFNldFJlc3VsdCBpbiB0aGF0IEkgc3VwcG9z ZSB3ZSBtYXkgbmVlZCBhIGdlbmVyYWwgd2hvbGUgZWNobyBmb3IgZXZlcnkgb3BlcmF0aW9uLCBy YXRoZXIgdGhhbiBmb3IgZXZlcnkgcGF0aC1kYXRhIGVjaG8uDQoNCj4gDQo+ID4gbWF5IGFsc28g YmUgYSBuZWNlc3NhcnkgZm9ybWF0IGZvciBzZXQgcmVzcG9uc2VzLCBoZW5zZSBvdXIgQk5GIHNo b3VsZCBzdXBwb3J0IGl0IGFzIHdlbGwgYXMgIzEgDQo+ID4gd2F5LlRoZW4sIGlmIHdlIGRlZmlu ZSBQYXRoLURhdGEgVExWIGFzOg0KPiA+IFBBVEgtREFUQSBUTFYgOj0gPFBBVEg+IFtTRUxFQ1RP Ul0gWzxEQVRBPisgfCA8UEFUSC1EQVRBPitdDQo+ID4gaXQgd2lsbCBub3Qgc3VwcG9ydCB0aGUg IzIgZm9ybWF0LiBBcyBhIHJlc3VsdCwgSSBzdWdnZXN0IA0KPiA+IFBBVEgtREFUQSBUTFYgOj0g PFBBVEg+IFtTRUxFQ1RPUl0gWzxQQVRILURBVEE+K10gWzxEQVRBPitdDQo+ID4gd2hpY2ggd2ls bCBzdXBwb3J0ICMyIGZvcm1hdCBhcyB3ZWxsIGFzICMxIGZvcm1hdC4NCj4gPiANCj4gPiBCdXQg SSBoYXZlIHRvIHNheSB0aGlzIGlzIGEgc3ViIGlzc3VlIGN1cnJlbnRseSwgSSBjYW4gbGl2ZSB3 aXRoIGRlZmVyIGl0IGxhdGVyLiANCj4gDQo+IEhvd2V2ZXIgSSBzZWUgdGhlIGFib3ZlIGFzIGJl bG9uZ2luZyB0byB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiAtIHNvIHdlDQo+IGNhbnQgY2xvc2Ug dGhhdCBjaGFwdGVyLCB5ZXQuDQpJIGNhbiBub3QgdW5kZXJzdGFuZCB5b3VyIG1lYW5pbmcgaGVy ZSB2ZXJ5IHdlbGwuIFdoYXQgZG8geW91IG1lYW4gaGVyZSBieSBwcmV2aW91cyBkaXNjdXNzaW9u PyBEbyB5b3UgbWVhbiB0aGUgc3VicGF0aCBpc3N1ZT8gSSB0aGluayB0aGUgc3VicGF0aCBpZGVh IGlzIHJlYWxseSB0aGUgaWRlYSB3ZSBwcmVzZW50ZWQgaW4gdGhlIGN1cnJlbnQgQk5GLCB0aGVy ZWZvcmUgdGhpcyBwb2ludCBjYW4gYmUgY2xvc2VkIHRvIG1lLiBNb3Jlb3ZlcixJIGRvbid0IHNl ZSBhIGZhdGFsIHJlbGF0aW9uIG9mIHRoZSBTZXRSZXN1bHQgaXNzdWUgd2l0aCBzdWJwYXRoIGlz c3VlIGFjdHVhbGx5LCB0aGVyZWZvcmUgaXQncyBhIHN1Yi1pc3N1ZSBvbmx5IHRvIG1lIGZvciB0 aGUgYmlnIFBhaHQtRGF0YSBpc3N1ZS4NCj4gTG9vayBhdCBleGFtcGxlIDE3IGluIHRoZSBkb2N1 bWVudCBpIHBvc3RlZCB3aGljaCBhZGRyZXNzZXMgdGhpcyBpc3N1ZQ0KPiBhdCB0aGUgY29zdCBv ZiBtb3JlIGJpdHMuDQpJJ3YgY2hlY2tlZCB0aGUgZXhhbXBsZS4gSSB0aGluayB3ZSd2IGFscmVh ZHkgZGlzY3Vzc2VkIGFib3V0IHRoaXMgY2FzZS4gSSdtIG5vdCBzdXJlIHdoYXQncyB0aGUgcmVs YXRpb25zaGlwIG9mIHRoZSBleGFtcGxlIHdpdGggdGhlIHRvcGljIHdlIGRpc2N1c3NlZCBoZXJl Lg0KDQpDaGVlcnMsDQpXZWltaW5nDQoNCg0K From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 09:42: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 JAA04562 for ; Thu, 10 Feb 2005 09:42:47 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzFqs-0005Mv-TP for forces-archive@IETF.ORG; Thu, 10 Feb 2005 10:03: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 <4.00F7F56E@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 9:42:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57280947 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 09:42:40 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 09:42:37 -0500 Received: from [220.192.124.101] by 202.96.99.56 with StormMail ESMTP id 6322.2105028806; Thu, 10 Feb 2005 23:13:42 +0800 (CST) References: <1106764338.1073.32.camel@jzny.localdomain> <009701c5092b$ed6db1c0$020aa8c0@wwm1> <6.1.2.0.0.20050202094928.062d7e30@localhost> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@! jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <1107954766.1544.300.camel@jzny.localdomain> <00ba01c50ec3$48e95530$907cc0dc@WwmLapSamsung> <1107967180.1077.72.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 Approved-By: "Wang,Weiming" Message-ID: <008801c50f7e$c0a82c70$657cc0dc@WwmLapSamsung> Date: Thu, 10 Feb 2005 22:41:21 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Protocol Operations Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFk aSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQpTdWJqZWN0OiBSZTogUHJvdG9jb2wgT3BlcmF0aW9u cw0KDQoNCj4gQmFzZWQgb24geW91ciBsYXN0IGVtYWlsIGkgdGhpbmsgd2UgaGF2ZW50IHJlYWxs eSBjbG9zZWQgdGhlIHByZXZpb3VzDQo+IGRpc2N1c3Npb247IGNhbiB5b3UgbG9vayBhdCBleGFt cGxlIDE3IGFuZCBzYXkgaWYgaXQgaXMgc3VmZmljaWVudCBmb3IgDQo+IHlvdSB3aXRoIGN1cnJl bnQgZ3JhbW1hcj8gDQoNClNvcnJ5LCBidXQgSSBkbyB0aGluayB5b3Ugc3RpbGwgaGF2ZSBhIG1p c3VuZGVyc3RhbmRpbmcgb2YgbXkgcXVlc3Rpb24uIEkgaGF2ZSBubyBxdWVzdGlvbiB3aXRoIHRo ZSBCTkYgdXNlZCBpbiB0aGUgZXhhbXBsZSAxNyBhdCBhbGwuIFRoZSBwcm9ibGVtIG5vdyB3ZSBk aXNjdXNzIGlzIHdoYXQgdGhlIHJlc3BvbnNlIG1lc3NhZ2Ugc2hvdWxkIGxvb2sgbGlrZSBmb3Ig Q29uZmlndXJlIE1lc3NhZ2VzIHdpdGggU2V0IE9wZXJhdGlvbi4gSWYgeW91IHJlYWxseSB3YW50 IHRvIG1lIHRvIGFzayBhIHF1ZXN0aW9uIGFib3V0IHRoZSBleGFtcGxlIDE3LCBJIGp1c3Qgd2Fu dCB0byBhc2sgd2hhdCB0aGUgcmVzcG9uc2UgQk5GIHNob3VsZCBsb29rIGxpa2UgZm9yIHRoaXMg c2V0IG1lc3NhZ2UuDQoNCkNoZWVycywNCldlaW1pbmcNCg0K From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 09:53:17 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 JAA05288 for ; Thu, 10 Feb 2005 09:53:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzG12-0005ai-9f for forces-archive@IETF.ORG; Thu, 10 Feb 2005 10:14: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 <4.00F7F5DB@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 9:53:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57281595 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 09:53:14 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 09:53:14 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021006534825:22229 ; Thu, 10 Feb 2005 06:53:48 -0800 References: <468F3FDA28AA87429AD807992E22D07E04355957@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 02/10/2005 06:53:49 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/10/2005 06:53:50 AM, Serialize complete at 02/10/2005 06:53:50 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108047190.1113.455.camel@jzny.localdomain> Date: Thu, 10 Feb 2005 09:53:11 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Moving flags To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E04355957@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hormuzd, On Thu, 2005-02-10 at 03:37, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > As you can see all the other paths in that example do not need a > F_SELBLK except for the outer/first one. > And only items with data need a replace but not ones with pure paths. > To make it more inmteresting, there are examples where you would have > F_SELBLK flags first and then F_SELKEY next and then REPLACE at the most > inner nest where the data is to be found. > > [Yes this is true as the grammar currently stands. But do we really need > to have F_SELBLK and F_SELKEY in the same Op TLV? So far yes; I am actually not sure you can get rid of this. You could have nested paths with nestings which need to further path nesting as an example it's possible to select a cell within a table within a table and use content keying for the second table. > I did see some use > cases around this, but the reason for F_SELKEY was basically for content > based Query in a Query msg. So if we restrict this combination and if > there is only 1 F_SELBLK in an Op TLV for a Config msg then we should be > able to eliminate the need for Flags in each PATH. I was thinking along > these lines...let me know if this makes sense to you?] You could do things like above, but because you need nesting and to further refine paths as you nest paths, then the flags are a must have. Otherwise we end up overlooking some scenarios. > Removing just the operation > enhancing flags is of cosmetic/philosophical value and should be defered > to a later discussion. > [I believe there is still value in this, Weiming and David pointed out > some reasons as well] I havent seen any value in what Weiming proposed either. I dont recall seeing Davids reasons. What i told Weiming is it should be fine (if theres semi good reasons) to move the operational bits only outside but not every bit like you are suggesting. The problem is both of you quote efficiency as the driver for moving bits and i see none. Find another reason. > Having said all the above, if the document is unclear it needs to be > fixed; it is not acceptable for the doc to do a poor job at explaining > things. > [Some of these things are not crystal clear in the doc, I think it could > be improved] > It would be very helpful and appreciated if you point me particular sections so i can clean them up. To quote Joel "if we cant explain it they cant understand it". > Overall comment, as the doc stands today there are too many alternatives > for doing the same thing which is not good for interoperability and > causes some confusion to the reader as well. We should try and improve > this aspect, restrict some of the alternatives if possible. Agreed - although "restrict some of the alternatives if possible" is too wide a term though. I think the biggest culprit in alternatives is: a) efficiency of manipulating our most common data structures - the table b)content keys and c) ability to nest paths. I dont see us getting rid of any of the above. Getting rid of the above desires will surely reduce a lot of the "alternatives". The challenge as i see it for the moment though, is to get 3 people who have vastly different but strong views of the BNF to agree to one. That would be a great accomplishment (I posted on the list asking for the chairs to put a time limit for this goal - unfortunately got no response). I think once we get a good starting point, it would be fair to go back and review again. At least there will be a starting point we can base that discussion on. The reason i keep adding those use cases is to make sure that every counter example given by anyone is expressable via the BNF. Otherwise its not complete. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 10:02: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 KAA06172 for ; Thu, 10 Feb 2005 10:02:19 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzG9n-0005pB-Bd for forces-archive@IETF.ORG; Thu, 10 Feb 2005 10:23: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 <9.00F7F567@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 10:02:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57282515 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 10:02:17 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 10:02:17 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021007025150:22277 ; Thu, 10 Feb 2005 07:02:51 -0800 References: <1106764338.1073.32.camel@jzny.localdomain> <1107360951.1073.57.camel@jzny.localdomain> <03CD730D11000F055E186742@EEN9169.een.bris.ac.uk> <6.2.0.14.0.20050202123716.030ff900@localhost> <013301c50b5e$276d8f10$845c21d2@Necom.hzic.edu.cn> <6.2.0.14.0.20050205121611.0316ac80@localhost> <1107791636.1080.33.camel@jzny.localdomain> <1107807219.1078.123.camel@jzny.localdomain> <6.2.0.14.0.20050207171834.031b6ac8@localhost> <001a01c50d95$d5177660$317cc0dc@WwmLapSamsung> <6.2.0.14.0.20050208065427.03174150@localhost> <1107872168.1088.75.camel@jzny.localdomain> <00b101c50e73$bc211600$f17cc0dc@WwmLapSamsung> <6.2.0.14.0.20050209065916.033050a0@localhost> <1107956192.1095.325.camel@jzn! y.localdomain> <00b901c50ec3$372d89b0$907cc0dc@WwmLapSamsung> <1107966914.1077.66.camel@jzny.localdomain> <008701c50f7e$bcd4b640$657cc0dc@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 02/10/2005 07:02:52 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/10/2005 07:02:54 AM, Serialize complete at 02/10/2005 07:02:54 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108047734.1119.460.camel@jzny.localdomain> Date: Thu, 10 Feb 2005 10:02:15 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Protocol Operations Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <008701c50f7e$bcd4b640$657cc0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Weiming, On Thu, 2005-02-10 at 08:45, Wang,Weiming wrote: > > > > Whats in the DataTLVforSetResult? Maybe that will clarify things. > The DataTLVforSetResult is the same as Joel's SetResult in that it responses back the Set result, > different from Joel's SetResult in that I suppose we may need a general whole echo for every operation, > rather than for every path-data echo. > Ok, I will defer this for next discussion because it is trully a subissue. > > > > > may also be a necessary format for set responses, hense our BNF should support it as well as #1 > > > way.Then, if we define Path-Data TLV as: > > > PATH-DATA TLV := [SELECTOR] [+ | +] > > > it will not support the #2 format. As a result, I suggest > > > PATH-DATA TLV := [SELECTOR] [+] [+] > > > which will support #2 format as well as #1 format. > > > > > > But I have to say this is a sub issue currently, I can live with defer it later. > > > > However I see the above as belonging to the previous discussion - so we > > cant close that chapter, yet. > I can not understand your meaning here very well. What do you mean here by previous discussion? > Do you mean the subpath issue? I think the subpath idea is really the idea we presented in the current BNF, > therefore this point can be closed to me. Moreover,I don't see a fatal relation of the SetResult issue with > subpath issue actually, therefore it's a sub-issue only to me for the big Paht-Data issue. > > Look at example 17 in the document i posted which addresses this issue > > at the cost of more bits. > I'v checked the example. I think we'v already discussed about this case. I'm not sure what's the relationship > of the example with the topic we discussed here. Heres why i said its not closed yet: Current: PATH-DATA TLV := [SELECTOR] [+ | +] You suggest: PATH-DATA TLV := [SELECTOR] [+] [+] Theres some serious differences between the two. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 15:17: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 PAA02435 for ; Thu, 10 Feb 2005 15:17:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzL4Z-0004Oj-Ln for forces-archive@IETF.ORG; Thu, 10 Feb 2005 15:38:00 -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.00F8029B@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 15:17:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57314753 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 15:17:09 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 15:16:55 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9119765 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 15:16:55 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050210150006.0319cec8@localhost> Date: Thu, 10 Feb 2005 15:15:36 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Event declarations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 I am working on updating the model draft. As part of that, I am trying to figure out where / how "events" should be declared. The general idea is that the model will have event declarations, which also create a boolean variable. When the variable is True, the event is sent. I also assume that events will have a path to identify the event being signalled, and the event message will include an LFB instance identifier. (The simplest model for achieving that I can see is that we have an "EVENT-REPORT" Operation, which carries path-data and content data for each event being reported.) So now we turn to the model and ask the question "where should events be declared, and how should the content be declared?" One way to do it is that each information declaration (structure, array, and LFB) caninclude its own event statement. That statement would include a description of what the event means, and a declaration of the fields included in the data reported with the event. This provides a nice simple consistent place to declare events. The syntax would be clean. But, it assumes that every LFB that wants to use a given type definition is going to want to be able to provide the same events. Also, it would mean that the information reported by an event would have to come from that one structure. Both these restrictions feel problematic to me. The other alternative is to create an events section of the LFB declaration. This would then need to somehow describe for each event what condition it is triggered by, and what information is sent. The complication comes in when trying to declare evens triggered by entries in tables. It is easy to have an LFB level event triggered by too many bad packets. But suppose one has a port table, and the event is port down. Clearly, the event should be tied to the individual port. And clearly the reported elements should come from the corresponding failed element of the table. And maybe from some parallel tables. Hence, I start ending up with something in the LFB declaration that looks like: idx portstatus[idx} idx when status field becomes "down" portstatus[idx}.status, portinfo[idx].identity So that you can have one or more index variables to use in referring to events. you can indicate which ones are to appear in the event path and in what order The trigger clause may be just documentation? And the report clause, using the index variables, indicates what is to be reported. And this would also declare a boolean array, with variable ID 17, to use to indicate which of these events are to be generated. Is this a reasonable approach, or am I totally confused? Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 16:14:53 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 QAA11832 for ; Thu, 10 Feb 2005 16:14:53 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzLyO-0006zI-7J for forces-archive@IETF.ORG; Thu, 10 Feb 2005 16:35: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 <2.00F80572@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 16:14:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57320249 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 16:14:47 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 16:14: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 2005021013152086:24425 ; Thu, 10 Feb 2005 13:15:20 -0800 References: <6.2.0.14.0.20050210150006.0319cec8@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 02/10/2005 01:15:21 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/10/2005 01:15:23 PM, Serialize complete at 02/10/2005 01:15:23 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108070083.1075.136.camel@jzny.localdomain> Date: Thu, 10 Feb 2005 16:14:43 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Event declarations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050210150006.0319cec8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit On Thu, 2005-02-10 at 15:15, Joel M. Halpern wrote: > I am working on updating the model draft. > As part of that, I am trying to figure out where / how "events" should be > declared. > > The general idea is that the model will have event declarations, which also > create a boolean variable. When the variable is True, the event is sent. > I also assume that events will have a path to identify the event being > signalled, and the event message will include an LFB instance > identifier. (The simplest model for achieving that I can see is that we > have an "EVENT-REPORT" Operation, which carries path-data and content data > for each event being reported.) > > So now we turn to the model and ask the question "where should events be > declared, and how should the content be declared?" > > One way to do it is that each information declaration (structure, array, > and LFB) caninclude its own event statement. That statement would include > a description of what the event means, and a declaration of the fields > included in the data reported with the event. > This provides a nice simple consistent place to declare events. The syntax > would be clean. > > But, it assumes that every LFB that wants to use a given type definition is > going to want to be able to provide the same events. Also, it would mean > that the information reported by an event would have to come from that one > structure. Both these restrictions feel problematic to me. > > The other alternative is to create an events section of the LFB declaration. This would be my preference. I dont like the previous scheme for reasons you mentioned above. > This would then need to somehow describe for each event what condition it > is triggered by, and what information is sent. The complication comes in > when trying to declare evens triggered by entries in tables. It is easy to > have an LFB level event triggered by too many bad packets. But suppose one > has a port table, and the event is port down. Clearly, the event should be > tied to the individual port. And clearly the reported elements should come > from the corresponding failed element of the table. And maybe from some > parallel tables. > Hence, I start ending up with something in the LFB declaration that looks like: > > idx > portstatus[idx} > idx > when status field becomes "down" > portstatus[idx}.status, portinfo[idx].identity > I would see it slightly different. You have a table of portevents, one per row. The portevent definition will enumerate all possible port events and associated parameters and/or references of what to ship when triggered... (something along the lines of what you have above but loosing the indices and referencing/aliasing to the real data in the attribute found in the PortTable attribute table). i.e. PortCount ... ... EventPortTable 4 table of Events one row per Port PortEvent PortTable 3 table of Ports portdesc > So that you can have one or more index variables to use in referring to events. > you can indicate which ones are to appear in the event path and in what order didnt follow. > The trigger clause may be just documentation? A triger could be a simple "it changed". Eg i may be interested when someone changes the MTU or MAC address of an ethernet port. So documentation maybe sufficient; i dont think you can come up with a smart generic scheme to cover ranges etc. Maybe need to investigate rmon. One thing you havent mentioned is kicking of the event; in other words registration; you need both a register/unregister which specifies a path to the event of interest. Registration also has hierachical semantics: For example if i specify the path to be EventPortTable then i am registering for all events for all ports. If i specify a index to the table then i am registering only for that port; if i specify a cell within a table then i am registering only for that event within a port. Theres also other sort of events that are interesting like "PortTable has a new entry created for it" > And the report clause, using the index variables, indicates what is to be > reported. > And this would also declare a boolean array, with variable ID 17, to use to > indicate which of these events are to be generated. > Well, I would see several levels of reporting - back to the other favorite discussion 1) Event X that you registered for happened (eg "MTU on port 3 changed") 2) Event X that you registered for happened and heres the data (""MTU on port 3 changed new value=Y") > Is this a reasonable approach, or am I totally confused? I think a good start for a discussion but we may have different approaches. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 16:32:02 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 QAA14595 for ; Thu, 10 Feb 2005 16:32:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzMEs-0007t3-FL for forces-archive@IETF.ORG; Thu, 10 Feb 2005 16:52: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 <19.00F80411@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 16:31:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57321789 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 16:31:51 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 16:31:51 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9120559 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 16:31:51 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <6.2.0.14.0.20050210150006.0319cec8@localhost> <1108070083.1075.136.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050210162519.032e67f0@localhost> Date: Thu, 10 Feb 2005 16:30:13 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Event declarations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108070083.1075.136.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 A couple of questions that I think need to be elucidated: Should the declaration make clear that this relates to the PortTable? There are a number of different events that might be declared by the LFB designer. Presumably, these need to be stated. I would hope taht we are not requiring that the only granularity the LFB designer has is "there are events for any change to any structure element of this array, and for this array as a whole." Should we distinguish between events that are changes to a table (creation, deletion), and events which are changes to values in one or more cells in a table? Should the protocol support a short-hand for causing all events on all entries in a table to be reported? (If so, we are going to have to be careful for the variable which controls events on the table, such as create and delete, and the variable which controls events on all elements of the table.) It is clear that we want some events. It is clear that having all possible events turned on all the time would be a bad thing. So we need some declaration of events and some control over them. But if we do not try to keep that simple, this is another place we could bury ourselves in complexity. Yours, Joel At 04:14 PM 2/10/2005, Jamal Hadi Salim wrote: > > > EventPortTable > 4 > table of Events one row per Port > PortEvent > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 10 16:59: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 QAA19154 for ; Thu, 10 Feb 2005 16:59:47 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzMfp-000118-Tx for forces-archive@IETF.ORG; Thu, 10 Feb 2005 17:20: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 <8.00F805F5@cherry.ease.lsoft.com>; Thu, 10 Feb 2005 16:59:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57324049 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 10 Feb 2005 16:59:42 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Feb 2005 16:59:42 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021014001460:24741 ; Thu, 10 Feb 2005 14:00:14 -0800 References: <6.2.0.14.0.20050210150006.0319cec8@localhost> <1108070083.1075.136.camel@jzny.localdomain> <6.2.0.14.0.20050210162519.032e67f0@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 02/10/2005 02:00:14 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/10/2005 02:00:18 PM, Serialize complete at 02/10/2005 02:00:18 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108072775.1074.169.camel@jzny.localdomain> Date: Thu, 10 Feb 2005 16:59:35 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Event declarations To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050210162519.032e67f0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit On Thu, 2005-02-10 at 16:30, Joel M. Halpern wrote: > A couple of questions that I think need to be elucidated: > > Should the declaration make clear that this relates to the PortTable? > There are a number of different events that might be declared by the LFB > designer. Presumably, these need to be stated. Right - i see the declarations as which may be grouped together. You have expressed dislike for this in the past or i may have misunderstood you. > I would hope taht we are > not requiring that the only granularity the LFB designer has is "there are > events for any change to any structure element of this array, and for this > array as a whole." I think its valid to listen to events of that sort if you so wish (such as registering to listen to all of the portevents). But i would say the events need to be declared by the LFB definition author. > Should we distinguish between events that are changes to a table (creation, > deletion), and events which are changes to values in one or more cells in a > table? I think so. Thos will be events other than EventPortTable events. > Should the protocol support a short-hand for causing all events on all > entries in a table to be reported? You mean like i stated in my other email in hierachies? I would say yes. > (If so, we are going to have to be > careful for the variable which controls events on the table, such as create > and delete, and the variable which controls events on all elements of the > table.) makes sense. > It is clear that we want some events. yes ;-> > It is clear that having all possible events turned on all the time would be > a bad thing. nod. > So we need some declaration of events and some control over them. > yes indeed. > But if we do not try to keep that simple, this is another place we could > bury ourselves in complexity. > I hear ya. This thread is pretty green, hopefully we'll hear from some of the other usual suspects. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 11 01:38:53 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 BAA09472 for ; Fri, 11 Feb 2005 01:38:53 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzUmG-0006r6-AY for forces-archive@IETF.ORG; Fri, 11 Feb 2005 01:59: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 <18.00F81AD4@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 1:38:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57333830 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 01:38:49 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 01:38:49 -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 j1B6cia6003196; Fri, 11 Feb 2005 06:38:44 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 j1B6cSW6029680; Fri, 11 Feb 2005 06:38:44 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 M2005021022384213197 ; Thu, 10 Feb 2005 22:38:42 -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, 10 Feb 2005 22:38:42 -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] Event declarations Thread-Index: AcUPrYOs3Hf2OlGGRTSNQ7BcRYS22QAVkXCA X-OriginalArrivalTime: 11 Feb 2005 06:38:42.0314 (UTC) FILETIME=[53E1AEA0:01C51004] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04392598@orsmsx408> Date: Thu, 10 Feb 2005 22:38:41 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Event declarations Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Hi Joel, I am glad you started working on this aspect, this is definitely needed by the protocol. In general the model that you have proposed below for reporting events seems reasonable to me. On the specifics on the LFB definition, I would defer this to the Model team for now since I haven't been following the latest updates being made to the Model draft. I guess it would depend on the general design philosophy for the LFBs. Hope this helps, regards Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, February 10, 2005 12:16 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Event declarations I am working on updating the model draft. As part of that, I am trying to figure out where / how "events" should be=20 declared. The general idea is that the model will have event declarations, which also=20 create a boolean variable. When the variable is True, the event is sent. I also assume that events will have a path to identify the event being=20 signalled, and the event message will include an LFB instance=20 identifier. (The simplest model for achieving that I can see is that we have an "EVENT-REPORT" Operation, which carries path-data and content data=20 for each event being reported.) So now we turn to the model and ask the question "where should events be declared, and how should the content be declared?" One way to do it is that each information declaration (structure, array, and LFB) caninclude its own event statement. That statement would include=20 a description of what the event means, and a declaration of the fields=20 included in the data reported with the event. This provides a nice simple consistent place to declare events. The syntax=20 would be clean. But, it assumes that every LFB that wants to use a given type definition is=20 going to want to be able to provide the same events. Also, it would mean=20 that the information reported by an event would have to come from that one=20 structure. Both these restrictions feel problematic to me. The other alternative is to create an events section of the LFB declaration. This would then need to somehow describe for each event what condition it=20 is triggered by, and what information is sent. The complication comes in=20 when trying to declare evens triggered by entries in tables. It is easy to=20 have an LFB level event triggered by too many bad packets. But suppose one=20 has a port table, and the event is port down. Clearly, the event should be=20 tied to the individual port. And clearly the reported elements should come=20 from the corresponding failed element of the table. And maybe from some parallel tables. Hence, I start ending up with something in the LFB declaration that looks like: idx portstatus[idx} idx when status field becomes "down" portstatus[idx}.status, portinfo[idx].identity So that you can have one or more index variables to use in referring to events. you can indicate which ones are to appear in the event path and in what order The trigger clause may be just documentation? And the report clause, using the index variables, indicates what is to be=20 reported. And this would also declare a boolean array, with variable ID 17, to use to=20 indicate which of these events are to be generated. Is this a reasonable approach, or am I totally confused? Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 11 12:38: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 MAA18424 for ; Fri, 11 Feb 2005 12:38:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czf57-0004Wi-6F for forces-archive@IETF.ORG; Fri, 11 Feb 2005 12:59:58 -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.00F8335B@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 12:38:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57418926 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 12:38:48 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 12:38:48 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j1BHcl1k025334 for ; Fri, 11 Feb 2005 17:38: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 j1BHclDb178214 for ; Fri, 11 Feb 2005 18:38:47 +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 j1BHck62013494 for ; Fri, 11 Feb 2005 18:38:46 +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 j1BHckVI013477 for ; Fri, 11 Feb 2005 18:38: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 SAA57680 for ; Fri, 11 Feb 2005 18:38:46 +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 mtagate1.de.ibm.com id j1BHcl1k025334 Approved-By: Robert Haas Message-ID: <420CEDA2.6030609@zurich.ibm.com> Date: Fri, 11 Feb 2005 18:38:42 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable To summarize the ambiguity with the use of a BLOCK construct, here is an=20 illustration that should help: With only DATARAWs following the BLOCK construct, no ambiguity : For table entries 4 5 6, (BLOCK construct selection) (each table entry has fields name, surname, address) set entry with (a,b,c) set entry with (d,e,f) set entry with (g,h,i) necessarily results in: {...,(a,b,c),(d,e,f),(g,h,i),...} As a potential optimization, if all table entries are set with the same=20 value (a,b,c), then instead of writing: =20 For table entries 4 5 6, (each table entry has fields name, surname, address) set entry with (a,b,c) set entry with (a,b,c) set entry with (a,b,c) one could also write: For table entries 4 5 6, (each table entry has fields name, surname, address) set entry with (a,b,c) Now, if instead of DATARAWs, the BLOCK construct is followed by=20 PATHDATAs, then there is an ambiguity: For table entries 4 5 6, (each table entry has fields name, surname, address, city) set name with a set surname with b set address with c Does this result in (x means values that remain untouched): 1) according to the semantics of example 4:=20 {...,(a,x,x,x),(x,b,x,x),(x,x,c,x),...}=20 2) or according to the semantics of example 15:=20 {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...} That is the ambiguity. --=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 Feb 11 16:09: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 QAA14523 for ; Fri, 11 Feb 2005 16:09:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CziMY-0003lJ-QZ for forces-archive@IETF.ORG; Fri, 11 Feb 2005 16:30:11 -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.00F8394E@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 16:09:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57433525 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 16:08:55 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 16:08: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 2005021113092487:31792 ; Fri, 11 Feb 2005 13:09:24 -0800 References: <420CEDA2.6030609@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 02/11/2005 01:09:25 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/11/2005 01:09:29 PM, Serialize complete at 02/11/2005 01:09:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108156127.1075.59.camel@jzny.localdomain> Date: Fri, 11 Feb 2005 16:08:48 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Ambiguity in BLOCK semantics Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <420CEDA2.6030609@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 12:38, Robert Haas wrote: > To summarize the ambiguity with the use of a BLOCK construct, here is an > illustration that should help: > > > With only DATARAWs following the BLOCK construct, no ambiguity : > > For table entries 4 5 6, (BLOCK construct selection) > (each table entry has fields name, surname, address) > set entry with (a,b,c) > set entry with (d,e,f) > set entry with (g,h,i) > > necessarily results in: > > {...,(a,b,c),(d,e,f),(g,h,i),...} > The semantics are pretty simple. 1) "Find the target first" - this is like a classifier filter "match" and is provided by the path + selector 2) Once you find the target, apply the SET data (this is like the filter action) In your case above zone on table:rows 4,5,6; apply the data in order. > As a potential optimization, if all table entries are set with the same > value (a,b,c), then instead of writing: > > For table entries 4 5 6, > (each table entry has fields name, surname, address) > set entry with (a,b,c) > set entry with (a,b,c) > set entry with (a,b,c) This is also legit, but not efficient, given the commonality of the data set. > one could also write: > > For table entries 4 5 6, > (each table entry has fields name, surname, address) > set entry with (a,b,c) > This fixes the efficiency issue above. Essentially the rules for applying data are (This has absolutely nothing to do with BLK rather with the BNF, but using BLK to make a point) [n is 3 in above case]: Suppose that a block info TLV has highlighted "n" indices. In that case, a data TLV below that block info TLV may contain data for either 1 or n entries. Any other number of data entries is invalid. In other words: (a) If the TLV contains data for 1 entry, the implication is: "Apply this data to each of the n indices." (b) If the TLV contains data for n entries, the implication is: "Apply each piece of data, in sequence, to the n selected indices. I.e., apply the first piece of data to the first index, the second piece of data to the second index, etc." c) error (a) is an efficiency subset for b) - you can get rid of it although i dont see why you wouldnt want to. > > Now, if instead of DATARAWs, the BLOCK construct is followed by > PATHDATAs, then there is an ambiguity: > > For table entries 4 5 6, > (each table entry has fields name, surname, address, city) > set name with a > set surname with b > set address with c > Ok, in this case the path classifer says match on rows 4, 5, 6 cells name, surname, address. Clearly paths could be hierachical and the hierachy is definable by nesting TLVs.... The data target is the cells. > Does this result in (x means values that remain untouched): > > 1) according to the semantics of example 4: > {...,(a,x,x,x),(x,b,x,x),(x,x,c,x),...} > > > 2) or according to the semantics of example 15: > {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...} > > That is the ambiguity. I dont see it. You must classify the path first. Then you decide what data to apply. So lets repeat example 4 and 15 keeping in mind "classify path first then set the data" (Should be noted the idea of classifying then applying the data is defined with the BNF and has nothing to do with BLK): First Classify: - In example 4, the Path-data TLV specifies table2 (ID 4), then highlights a range of indices (0-5). So you have classified to those 6 rows. - In example 15, the first Path-data TLV specifies table4 (ID 6), then highlights a list of indices (let's modify the example to choose indices 5, 7, and 9). Classification selects table 6 then rows 5, 7 and 9 then each of the 3 different cells. Apply data to the target: Consider the two rules a) and b) I expressed above. I) In example 4: There is one Dataraw TLV after the block info TLV.The classification result has 6 targets (rows). That TLV contains 6 pieces of data. The data info TLV had selected 6 indices, so rule (b) applies. If i had 6 separate DATARAW TLVs then same rule would have applied. If i have one piece of DATARAW - it would have applied to all 6 (as per rule a)). II) Example 15: The classification rule says we have 3 path targets. There are three Dataraw TLVs after the block info TLV. In this scenario, apply the rules to each TLV independently. The first TLV contains one piece of data, therefore rule (a) applies, and the data value 100 is written to each of the 3 chosen rows. Each of the other two TLVs also contains one piece of data, therefore rule (a) applies again. Note although i specified this with BLK, the rules apply to KEY as well as simple indices. cheers, jamal From Crosbykdeqt@co.za Fri Feb 11 18:08: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 SAA08291; Fri, 11 Feb 2005 18:08:06 -0500 (EST) Message-Id: <200502112308.SAA08291@ietf.org> Received: from 200-207-166-225.dsl.telesp.net.br ([200.207.166.225]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzkDa-0002Ib-CD; Fri, 11 Feb 2005 18:29:07 -0500 Received: from oznetwork.com.au ([213.130.63.235]) by atkinson.ffis.com (InterMail vK.4.04.00.00 163-368-310 license 5rj736sb9650f3hd5e1sfi9444m5soe4) with ESMTP id <82864151286858.PUEC104.bishop@oznetwork.com.au> for ; Sat, 12 Feb 2005 05:00:43 +0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 12 Feb 2005 02:02:43 +0300 Received: from 207.217.121.209 by cosmetic.calculable.hotmail.msn.com with HTTP; Fri, 11 Feb 2005 19:04:43 -0400 GMT X-Originating-IP: [12.137.19.0] X-Originating-Email: [oregon@oznetwork.com.au] From: "Jessie Farris" To: sigtran-archive@ietf.org Subject: Re: Can you let me know what you wish for Date: Fri, 11 Feb 2005 22:05:43 -0100 Mime-Version: 1.0 Received: from oznetwork.com.au ([64.81.193.41]) by atkinson.ffis.com (InterMail vK.4.04.00.00 344-357-640 license 5rj736sb9650f3hd5e1sfi9444m5soe4) with ESMTP id <51975376684541.SJSQ3402.atkinson.ffis.com> for ; Fri, 11 Feb 2005 20:02:43 -0300 From: "Jessie Farris" To: "Sigtran-archive" Subject: Re: Can you let me know what you wish for Sender: "Jessie Farris" X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Fri, 11 Feb 2005 16:06:43 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID:




Goodbye




boor intentsavannah crematory gibletbespectacled sentiment chinamenlifestyle dextrous drawbackbipartite import gobblemoan hymn abbottconcrete hotbox yawlsorb docile bialystokbumptious cruise babelpm From Crosbykdeqt@co.za Fri Feb 11 18:08: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 SAA08876; Fri, 11 Feb 2005 18:08:46 -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 1CzkEN-0002QK-AW; Fri, 11 Feb 2005 18:29:48 -0500 Received: from [211.58.238.115] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Czju1-0007QV-JF; Fri, 11 Feb 2005 18:08:46 -0500 Received: from oznetwork.com.au ([213.130.63.235]) by atkinson.ffis.com (InterMail vK.4.04.00.00 163-368-310 license 5rj736sb9650f3hd5e1sfi9444m5soe4) with ESMTP id <82864151286858.PUEC104.bishop@oznetwork.com.au> for ; Sat, 12 Feb 2005 05:00:43 +0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 12 Feb 2005 02:02:43 +0300 Received: from 207.217.121.209 by cosmetic.calculable.hotmail.msn.com with HTTP; Fri, 11 Feb 2005 19:04:43 -0400 GMT X-Originating-IP: [12.137.19.0] X-Originating-Email: [oregon@oznetwork.com.au] From: "Jessie Farris" To: sigtran-archive@ietf.org Subject: Re: Can you let me know what you wish for Date: Fri, 11 Feb 2005 22:05:43 -0100 Mime-Version: 1.0 Received: from oznetwork.com.au ([64.81.193.41]) by atkinson.ffis.com (InterMail vK.4.04.00.00 344-357-640 license 5rj736sb9650f3hd5e1sfi9444m5soe4) with ESMTP id <51975376684541.SJSQ3402.atkinson.ffis.com> for ; Fri, 11 Feb 2005 20:02:43 -0300 From: "Jessie Farris" To: "Sigtran-archive" Subject: Re: Can you let me know what you wish for Sender: "Jessie Farris" Message-Id: X-Spam-Score: 22.2 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Fri, 11 Feb 2005 16:06:43 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID:




Goodbye




boor intentsavannah crematory gibletbespectacled sentiment chinamenlifestyle dextrous drawbackbipartite import gobblemoan hymn abbottconcrete hotbox yawlsorb docile bialystokbumptious cruise babelpm From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 11 22:21:02 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 WAA25443 for ; Fri, 11 Feb 2005 22:21:02 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzoAX-0006yF-Pd for forces-archive@IETF.ORG; Fri, 11 Feb 2005 22:42: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 <20.00F840CE@cherry.ease.lsoft.com>; Fri, 11 Feb 2005 22:21:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57459227 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 11 Feb 2005 22:21:01 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Feb 2005 22:21:01 -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 j1C3L0DI015341; Sat, 12 Feb 2005 03:21:00 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 j1C3KwW0001292; Sat, 12 Feb 2005 03:20:58 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 M2005021119205809061 ; Fri, 11 Feb 2005 19:20:58 -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, 11 Feb 2005 19:20:58 -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] Ambiguity in BLOCK semantics Thread-Index: AcUQfevN5sWZ0kN7S12Fq1PqvJh52QAKSYoQ X-OriginalArrivalTime: 12 Feb 2005 03:20:58.0434 (UTC) FILETIME=[DEDF0220:01C510B1] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Fri, 11 Feb 2005 19:20:57 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Ambiguity in BLOCK semantics Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Comments inline...(hat off as usual)=20 > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Friday, February 11, 2005 1:09 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Ambiguity in BLOCK semantics >=20 > On Fri, 2005-02-11 at 12:38, Robert Haas wrote: > > To summarize the ambiguity with the use of a BLOCK=20 > construct, here is an=20 > > illustration that should help: > > > >=20 > > With only DATARAWs following the BLOCK construct, no ambiguity : > >=20 > > For table entries 4 5 6, (BLOCK construct selection) > > (each table entry has fields name, surname, address) > > set entry with (a,b,c) > > set entry with (d,e,f) > > set entry with (g,h,i) > >=20 > > necessarily results in: > >=20 > > {...,(a,b,c),(d,e,f),(g,h,i),...} > >=20 >=20 > The semantics are pretty simple. >=20 > 1) "Find the target first" - this is like a classifier filter "match" > and is provided by the path + selector > 2) Once you find the target, apply the SET data (this is like=20 > the filter > action) >=20 > In your case above zone on table:rows 4,5,6; apply the data in order. >=20 >=20 > > As a potential optimization, if all table entries are set=20 > with the same=20 > > value (a,b,c), then instead of writing: > > =20 > > For table entries 4 5 6, > > (each table entry has fields name, surname, address) > > set entry with (a,b,c) > > set entry with (a,b,c) > > set entry with (a,b,c) >=20 > This is also legit, but not efficient, given the commonality of the > data set. >=20 > > one could also write: > >=20 > > For table entries 4 5 6, > > (each table entry has fields name, surname, address) > > set entry with (a,b,c) > >=20 >=20 > This fixes the efficiency issue above. I can see that the second is more efficient. I question whether it really is necessary however. In reading the above I tried to come up with a compelling (real-world) example. The best one that came to mind was a next-hop router going down. I.e. imagine a routing rable as follows: Dest IP Mask --> Next Hop IP ----------------------------------------------- 134.134.10.10 255.255.0.0 134.134.10.251 150.10.5.17 255.0.0.0 134.134.10.251 117.5.23.4 255.255.255.0 134.134.10.251 (default route)0.0.0.0 92.10.10.251 In the above example, the router in question has two next-hops it might forward to - one at 134.134.10.251, one at 92.10.10.251. If the first of the two next-hops above goes down, I could see a case where one would want to identically replace multiple table entries with the same data, i.e. replace the Next Hop IP on rows 1, 2, and 3 with the Next Hop IP on row 4. However, upon a bit more reflection, I don't really think it is necessary to provide protocol support for this operation. Instead, it should be solved by correctly defining the LFB used for (in this example) IP forwarding, i.e. by adding indirection: Dest IP Mask --> Next Hop IP Identifier ---------------------------------------------------------- 134.134.10.10 255.255.0.0 1 150.10.5.17 255.0.0.0 1 117.5.23.4 255.255.255.0 1 (default route)0.0.0.0 2 Next Hop IP Identifier --> Next Hop IP Addr ------------------------------------------- 1 134.134.10.251 2 92.10.10.251 In this case, if the next hop router at 134.134.10.251 goes down, one simply updates the 1st row in the the identifier->addr table above with the IP address of the default router (92.10.10.251). My gut feeling is that any common example where one wants the=20 ability to do "replace rows 1, 2, and 3 with identical value A" is=20 probably solvable by better LFB definition (via indirection)=20 instead of adding this operation to the protocol. Furthermore,=20 intelligently defining the LFBs to address such common examples=20 should be expected - adding protocol operations to compensate=20 for poor LFB definition would be a bad thing. Regards, David From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 00:18:53 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 AAA02570 for ; Sat, 12 Feb 2005 00:18:53 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czq0a-0000gn-L1 for forces-archive@IETF.ORG; Sat, 12 Feb 2005 00:39:58 -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.00F8479A@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 0:18:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57471285 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 00:18:50 -0500 Received: from 208.246.215.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 00:18:50 -0500 Received: from aatlas-lt.avici.com (b2-pc41.avici.com [10.2.100.41]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id j1C5Id7l030146; Sat, 12 Feb 2005 00:18:40 -0500 X-Sender: aatlas@pop.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Avici-MailScanner-Information: Please contact the ISP for more information Approved-By: Alia Atlas Message-ID: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> Date: Sat, 12 Feb 2005 00:17:20 -0500 Reply-To: Alia Atlas Sender: Forwarding and Control Element Separation From: Alia Atlas Subject: Re: Ambiguity in BLOCK semantics Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 At 10:20 PM 2/11/2005, Putzolu, David wrote: >I can see that the second is more efficient. I question whether >it really is necessary however. In reading the above I tried to >come up with a compelling (real-world) example. The best one that >came to mind was a next-hop router going down. I.e. imagine a >routing rable as follows: > >Dest IP Mask --> Next Hop IP >----------------------------------------------- >134.134.10.10 255.255.0.0 134.134.10.251 >150.10.5.17 255.0.0.0 134.134.10.251 >117.5.23.4 255.255.255.0 134.134.10.251 >(default route)0.0.0.0 92.10.10.251 > >In the above example, the router in question has two next-hops it >might forward to - one at 134.134.10.251, one at 92.10.10.251. >If the first of the two next-hops above goes down, I could see >a case where one would want to identically replace multiple table >entries with the same data, i.e. replace the Next Hop IP on rows >1, 2, and 3 with the Next Hop IP on row 4. > >However, upon a bit more reflection, I don't really think it >is necessary to provide protocol support for this operation. >Instead, it should be solved by correctly defining the LFB >used for (in this example) IP forwarding, i.e. by adding >indirection: > >Dest IP Mask --> Next Hop IP Identifier >---------------------------------------------------------- >134.134.10.10 255.255.0.0 1 >150.10.5.17 255.0.0.0 1 >117.5.23.4 255.255.255.0 1 >(default route)0.0.0.0 2 > >Next Hop IP Identifier --> Next Hop IP Addr >------------------------------------------- > 1 134.134.10.251 > 2 92.10.10.251 > >In this case, if the next hop router at 134.134.10.251 goes down, >one simply updates the 1st row in the the identifier->addr table >above with the IP address of the default router (92.10.10.251). > >My gut feeling is that any common example where one wants the >ability to do "replace rows 1, 2, and 3 with identical value A" is >probably solvable by better LFB definition (via indirection) >instead of adding this operation to the protocol. Furthermore, >intelligently defining the LFBs to address such common examples >should be expected - adding protocol operations to compensate >for poor LFB definition would be a bad thing. In the above example for the indirection, consider the case where there's a group of prefixes that pointed at a single Next Hop IP Identifier (1 as above). Now, as the result of a change, subset A wants to change to use the Next-Hop IP Identifier 2 and subset B wants to change to use the Next-Hop IP identifier 3. I don't believe this can be solved via better LFB definition. The use of better LFB definition with indirection only solves the set of cases where the set doesn't need to be broken up or new sets created. Alia From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 00:42: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 AAA04025 for ; Sat, 12 Feb 2005 00:42:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzqNE-0001BH-1H for forces-archive@IETF.ORG; Sat, 12 Feb 2005 01:03: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 <2.00F847E2@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 0:42:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57473763 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 00:42:14 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 00:42:13 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9143359 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 00:42:13 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050212003442.03190c40@localhost> Date: Sat, 12 Feb 2005 00:41:54 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 While thinking about this case (which is the one almost everyone seems to come up with independently) I was struck by the fact that the actual LFB structure will likely be more complex. I would expect that the table with the IP address and prefix length will have a subtable of next-hop information to support ECMP. Given that the entries which will need to be update will have different subscripts in different base entries, it seems that the use of this "apply all path-data to all selected entitites" gets harder and less applicable. It is true that one can construct cases where it applies. And they might turn out to be common. It is also true that we can add selectors to the protocol later. With very little complication. Yours, Joel At 12:17 AM 2/12/2005, Alia Atlas wrote: >Dest IP Mask --> Next Hop IP Identifier >---------------------------------------------------------- >134.134.10.10 255.255.0.0 1 >150.10.5.17 255.0.0.0 1 >117.5.23.4 255.255.255.0 1 >(default route)0.0.0.0 2 > >Next Hop IP Identifier --> Next Hop IP Addr >------------------------------------------- > 1 134.134.10.251 > 2 92.10.10.251 > >In this case, if the next hop router at 134.134.10.251 goes down, >one simply updates the 1st row in the the identifier->addr table >above with the IP address of the default router (92.10.10.251). > >My gut feeling is that any common example where one wants the >ability to do "replace rows 1, 2, and 3 with identical value A" is >probably solvable by better LFB definition (via indirection) >instead of adding this operation to the protocol. Furthermore, >intelligently defining the LFBs to address such common examples >should be expected - adding protocol operations to compensate >for poor LFB definition would be a bad thing. > >In the above example for the indirection, consider the case where there's >a group of prefixes that pointed at a single Next Hop IP Identifier (1 as >above). Now, as the result of a change, subset A wants to change to use >the Next-Hop IP Identifier 2 and subset B wants to change to use the >Next-Hop IP identifier 3. I don't believe this can be solved via better >LFB definition. > >The use of better LFB definition with indirection only solves the set of >cases where the set doesn't need to be broken up or new sets created. > >Alia From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 09:30: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 JAA05255 for ; Sat, 12 Feb 2005 09:30:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czycx-00043r-UV for forces-archive@IETF.ORG; Sat, 12 Feb 2005 09:52:08 -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.00F8538D@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 9:30:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57527648 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 09:30:54 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 09:30:54 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9149936 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 09:30:54 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050212092517.03186640@localhost> Date: Sat, 12 Feb 2005 09:30:22 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Optional elements? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab In revising the model document, I have been trying to capture items which were discussed, and tentatively agreed. One such item is that LFB attributes and structure elements could be "optional". That is, the LFB definition indicated which elements were required, and which elements not all FE were mandated to support. This makes sense to me. It does have the effect of complicating the encoding of structures (in what we have been calling a DATARAW.) The receiver of an encoded structure needs to know what fields are present. One could mandate that the sender and receiver agree (via an earlier exchange) on what fields are used. But since this difference might be on a per instance level, that seems ineffective. Thus, support for optional fields seems to mandate that the encoding of structures use a per-field TLV mechanism. This is a small efficiency cost for a significant flexibility gain. Confirmation from the working group that optional elements should be supported would be helpful. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 09:43: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 JAA05928 for ; Sat, 12 Feb 2005 09:43:20 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czyov-0004H4-Es for forces-archive@IETF.ORG; Sat, 12 Feb 2005 10:04: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 <16.00F853F1@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 9:43:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57528511 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 09:42:47 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 09:42:47 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9150004 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 09:42:47 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050212093025.0318c060@localhost> Date: Sat, 12 Feb 2005 09:42:12 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Meta-Information To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Various parts of the model have implicit meta information. For example, on any given attribute there is the question of whether it exists, and what permission (read, write, ...) the CE has on that attribute. For structures, it would be helpful to be able to get the information about the structure as a whole and each field in it. For arrays, in addition to the existence and read-write permission, it would be helpful to get the number of elements in the array, the array size limit, the lowest and highest used subscript, and the first unused subscript. So far, the model has used a hodge-podge of mechanisms to address this. Some of this is declared as attributes. Some is declared as capabilites. And some is not yet covered. Thinking about this, and after some discussion a while back with some of my co-authors, and then adjusting for list discussion since, I think that there is an approach that makes sense. We could define an operation, parallel to GET, that is GET-META. This would return the meta-information structure about the element targeted by the PATH-DATA in the GET-META. (An omitted path-data would get meta information about the LFB instance.) Does this make sense? If so, should the model document have the structure definition for the meta information about atomic types, structures, arrays, aliases, and derived types? There are some interesting LFB level questions that follow from this. Is the meta-information about the LFB instance just the information about which elements are supported, and their access permissions (the equivalent of the SupporedAttributes array in the FE Object?) Or is it a structure defined along with the LFB definition to represent all the capability information for the class? (Currently, capabilities are essentially specially declared read-onloy attributes in the class definition.) Is there a way to get meta-information about an LFB Class rather than an instance? (This would allow the CE to determine the writeable attributes of a class before actually creating an instance of this class, which seems convenient.) We could reserve instance ID 0 of each class so as to all a target of CLASS:0 of a GET-META operation to reference the class level information. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 11:24: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 LAA12706 for ; Sat, 12 Feb 2005 11:24:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D00PB-00060V-Nx for forces-archive@IETF.ORG; Sat, 12 Feb 2005 11:46: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 <0.00F8579C@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 11:24:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57539177 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 11:24:50 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 11:24:50 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021208252241:38580 ; Sat, 12 Feb 2005 08:25:22 -0800 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> <6.2.0.14.0.20050212003442.03190c40@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 02/12/2005 08:25:23 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/12/2005 08:25:24 AM, Serialize complete at 02/12/2005 08:25:24 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108225485.1126.346.camel@jzny.localdomain> Date: Sat, 12 Feb 2005 11:24:45 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050212003442.03190c40@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Sat, 2005-02-12 at 00:41, Joel M. Halpern wrote: > While thinking about this case (which is the one almost everyone seems to > come up with independently) I was struck by the fact that the actual LFB > structure will likely be more complex. I think the main challenge is that the LFB may need to be more accomodating. We cant assume a certain "design". The indirection example will make it really easy to parse for some FEs but not others; i know of ASICs where that would be a real nice straight mapping (since they do have such indirections) and of others where this would a complete pain and would require the intervention of the CE to chew things into something along the first example from David. Whats more interesting is i have seen desire to have NH as a LFB on its own right where the NHID would infact be an alias; > I would expect that the table with the IP address and prefix length will > have a subtable of next-hop information to support ECMP. And indeed this will make the case even more applicable. > Given that the entries which will need to be update will have different > subscripts in different base entries, it seems that the use of this "apply > all path-data to all selected entitites" gets harder and less applicable. There are a lot of use cases other than the one above (refer to the different ASIC models talk above); one thats applicable to me (dont know how common this is) is to change the MAC addresses of the NH in one shot in many many entries in an L2 table - the faster i can do this the better; it is very common for my case in rerouting/failover scenarios. Not sure about the rest of the world. Another place where this is applicable: a) There are tables where you could instantiate rows but not activate many rows; and then later issue "activate all in rows 1000-2000" or something along those lines. Essentialy some boolean set or reset. b) Scenario where i want to instantiate and initialize either a whole table or range of row entries with the same values. etc > It is true that one can construct cases where it applies. > And they might turn out to be common. > > It is also true that we can add selectors to the protocol later. With very > little complication. > Again like i mentioned earlier if we want to start simple, we might as well kill keys - because even that is an efficiency vehicle; the CE could do the chweing and have the FEs do a little more work. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 11:37:39 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 LAA13308 for ; Sat, 12 Feb 2005 11:37:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D00ba-0006DZ-8n for forces-archive@IETF.ORG; Sat, 12 Feb 2005 11:58: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 <23.00F856A8@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 11:37:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57540984 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 11:37:38 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 11:37:37 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9151566 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 11:37:37 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> <6.2.0.14.0.20050212003442.03190c40@localhost> <1108225485.1126.346.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050212113120.031aa510@localhost> Date: Sat, 12 Feb 2005 11:36:31 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108225485.1126.346.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 I would like to ask the question differently. I will grant that there will be some cases where the block construct, with outer product semantics (apply all following path-datas to all selected block entries) will be useful. We know that the same operations can be performed without the block selectors. We do not know how often the block will be useful. Or how large the blocks will be (which ought to dominate the efficiency calculation.) We do know that the 1-1 semantics also applies to many cases. We don't know how often the 1-1 semantics would be useful, or how much it would help. We do know that we can add block TLVs later if we need to. Given the relationship between what we do know and what we don't know, wouldn't it make more sense to defer he block? Note that we will still have the ability to handle the most important block: setting or getting an entire table. That is clearly needed, and is covered by the structure without block selectors. Yours, Joel At 11:24 AM 2/12/2005, Jamal Hadi Salim wrote: >On Sat, 2005-02-12 at 00:41, Joel M. Halpern wrote: > > While thinking about this case (which is the one almost everyone seems to > > come up with independently) I was struck by the fact that the actual LFB > > structure will likely be more complex. > >I think the main challenge is that the LFB may need to be more >accomodating. We cant assume a certain "design". The indirection example >will make it really easy to parse for some FEs but not others; i know of >ASICs where that would be a real nice straight mapping (since they do >have such indirections) and of others where this would a complete pain >and would require the intervention of the CE to chew things into >something along the first example from David. Whats more interesting is >i have seen desire to have NH as a LFB on its own right where the NHID >would infact be an alias; > > > I would expect that the table with the IP address and prefix length will > > have a subtable of next-hop information to support ECMP. > >And indeed this will make the case even more applicable. > > > Given that the entries which will need to be update will have different > > subscripts in different base entries, it seems that the use of this "apply > > all path-data to all selected entitites" gets harder and less applicable. > >There are a lot of use cases other than the one above (refer to the >different ASIC models talk above); one thats applicable to me (dont know >how common this is) is to change the MAC addresses of the NH in one shot >in many many entries in an L2 table - the faster i can do this the >better; it is very common for my case in rerouting/failover scenarios. >Not sure about the rest of the world. > >Another place where this is applicable: >a) There are tables where you could instantiate rows but not activate >many rows; and then later issue "activate all in rows 1000-2000" >or something along those lines. Essentialy some boolean set or reset. > >b) Scenario where i want to instantiate and initialize either a whole >table or range of row entries with the same values. > >etc > > > It is true that one can construct cases where it applies. > > And they might turn out to be common. > > > > It is also true that we can add selectors to the protocol later. With > very > > little complication. > > > >Again like i mentioned earlier if we want to start simple, we might as >well kill keys - because even that is an efficiency vehicle; the CE >could do the chweing and have the FEs do a little more work. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 13:07: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 NAA18654 for ; Sat, 12 Feb 2005 13:07:20 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D020N-0007rp-Uc for forces-archive@IETF.ORG; Sat, 12 Feb 2005 13:28: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 <19.00F857E4@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 13:07:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57546708 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 13:07:20 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 13:07:20 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021210074301:39350 ; Sat, 12 Feb 2005 10:07:43 -0800 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> <6.2.0.14.0.20050212003442.03190c40@localhost> <1108225485.1126.346.camel@jzny.localdomain> <6.2.0.14.0.20050212113120.031aa510@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 02/12/2005 10:07:45 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/12/2005 10:07:54 AM, Serialize complete at 02/12/2005 10:07:54 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108231627.1178.535.camel@jzny.localdomain> Date: Sat, 12 Feb 2005 13:07:07 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050212113120.031aa510@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Joel, I dont see any complexity adding BLKs. I think now that weve discovered we have different semantical connotations on what we mean by what follows a selector, we may never reach a compromise (I contend its complex just because of how you intepret what follows the selctor). I could susbtitute everything you said about the BLK and show you that you will have the same issue with KEYs in a cross product given the selector interpretation. The issue is the selector IMO - the only reason we have it is to improve efficiency of on the wire bits and parsing/compute reduction. How about this as a middle ground (because i cant think of a good way we can close this): Lets Keep those flags on the path; lets just have the draft talk that BLK is defered for now[1] and will be revisited later. Keeping the flags will guarantee that we can add them back if we ned to. cheers, jamal [1] I Know i will implement BLK even if it is to prove i am foolish - at this point i feel i will have better perfomance numbers (throughput and latency) than someone who doesnt in both real world(small CPUs, lots of IO, shared bandwidth etc) as well as benchmark scenarios for the same work set and same hardware. On Sat, 2005-02-12 at 11:36, Joel M. Halpern wrote: > I would like to ask the question differently. > > I will grant that there will be some cases where the block construct, with > outer product semantics (apply all following path-datas to all selected > block entries) will be useful. > We know that the same operations can be performed without the block selectors. > We do not know how often the block will be useful. Or how large the blocks > will be (which ought to dominate the efficiency calculation.) > > We do know that the 1-1 semantics also applies to many cases. > We don't know how often the 1-1 semantics would be useful, or how much it > would help. > > We do know that we can add block TLVs later if we need to. > > Given the relationship between what we do know and what we don't know, > wouldn't it make more sense to defer he block? > Note that we will still have the ability to handle the most important > block: setting or getting an entire table. That is clearly needed, and is > covered by the structure without block selectors. > > Yours, > Joel > > At 11:24 AM 2/12/2005, Jamal Hadi Salim wrote: > >On Sat, 2005-02-12 at 00:41, Joel M. Halpern wrote: > > > While thinking about this case (which is the one almost everyone seems to > > > come up with independently) I was struck by the fact that the actual LFB > > > structure will likely be more complex. > > > >I think the main challenge is that the LFB may need to be more > >accomodating. We cant assume a certain "design". The indirection example > >will make it really easy to parse for some FEs but not others; i know of > >ASICs where that would be a real nice straight mapping (since they do > >have such indirections) and of others where this would a complete pain > >and would require the intervention of the CE to chew things into > >something along the first example from David. Whats more interesting is > >i have seen desire to have NH as a LFB on its own right where the NHID > >would infact be an alias; > > > > > I would expect that the table with the IP address and prefix length will > > > have a subtable of next-hop information to support ECMP. > > > >And indeed this will make the case even more applicable. > > > > > Given that the entries which will need to be update will have different > > > subscripts in different base entries, it seems that the use of this "apply > > > all path-data to all selected entitites" gets harder and less applicable. > > > >There are a lot of use cases other than the one above (refer to the > >different ASIC models talk above); one thats applicable to me (dont know > >how common this is) is to change the MAC addresses of the NH in one shot > >in many many entries in an L2 table - the faster i can do this the > >better; it is very common for my case in rerouting/failover scenarios. > >Not sure about the rest of the world. > > > >Another place where this is applicable: > >a) There are tables where you could instantiate rows but not activate > >many rows; and then later issue "activate all in rows 1000-2000" > >or something along those lines. Essentialy some boolean set or reset. > > > >b) Scenario where i want to instantiate and initialize either a whole > >table or range of row entries with the same values. > > > >etc > > > > > It is true that one can construct cases where it applies. > > > And they might turn out to be common. > > > > > > It is also true that we can add selectors to the protocol later. With > > very > > > little complication. > > > > > > >Again like i mentioned earlier if we want to start simple, we might as > >well kill keys - because even that is an efficiency vehicle; the CE > >could do the chweing and have the FEs do a little more work. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 13:13: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 NAA19018 for ; Sat, 12 Feb 2005 13:13:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0260-0007xm-IV for forces-archive@IETF.ORG; Sat, 12 Feb 2005 13:34: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 <17.00F85A00@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 13:13:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57547121 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 13:13:06 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 13:13:06 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9152462 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 13:13:05 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> <6.2.0.14.0.20050212003442.03190c40@localhost> <1108225485.1126.346.camel@jzny.localdomain> <6.2.0.14.0.20050212113120.031aa510@localhost> <1108231627.1178.535.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.0.14.0.20050212131217.031b0f98@localhost> Date: Sat, 12 Feb 2005 13:12:37 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108231627.1178.535.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de I can live with that. Yours, Joel At 01:07 PM 2/12/2005, Jamal Hadi Salim wrote: >How about this as a middle ground (because i cant think of a good way we >can close this): >Lets Keep those flags on the path; lets just have the draft talk that >BLK is defered for now[1] and will be revisited later. Keeping the flags >will guarantee that we can add them back if we ned to. From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 12 17:18: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 RAA05497 for ; Sat, 12 Feb 2005 17:18:00 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D05uz-0004Ep-MZ for forces-archive@IETF.ORG; Sat, 12 Feb 2005 17: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 <18.00F85E60@cherry.ease.lsoft.com>; Sat, 12 Feb 2005 17:17:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57562362 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 12 Feb 2005 17:17:46 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Feb 2005 17:17:46 -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 j1CMHfSt021154; Sat, 12 Feb 2005 22:17:41 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 j1CMHeCN011348; Sat, 12 Feb 2005 22:17:41 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 M2005021214174009759 ; Sat, 12 Feb 2005 14:17:40 -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); Sat, 12 Feb 2005 14:17:40 -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] Ambiguity in BLOCK semantics Thread-Index: AcURLoaussDIVm5IRiuzM1EuRadVtQAIhj2Q X-OriginalArrivalTime: 12 Feb 2005 22:17:40.0722 (UTC) FILETIME=[AA9A4520:01C51150] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Sat, 12 Feb 2005 14:17:39 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Ambiguity in BLOCK semantics Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Seems like a reasonable approach to me. -David =20 > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Saturday, February 12, 2005 10:13 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Ambiguity in BLOCK semantics >=20 > I can live with that. > Yours, > Joel >=20 > At 01:07 PM 2/12/2005, Jamal Hadi Salim wrote: > >How about this as a middle ground (because i cant think of a=20 > good way we > >can close this): > >Lets Keep those flags on the path; lets just have the draft talk that > >BLK is defered for now[1] and will be revisited later.=20 > Keeping the flags > >will guarantee that we can add them back if we ned to. >=20 From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 13 21: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 VAA19007 for ; Sun, 13 Feb 2005 21: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 1D0Wdh-0005mJ-7B for forces-archive@IETF.ORG; Sun, 13 Feb 2005 22:11:12 -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.00F8963F@cherry.ease.lsoft.com>; 13 Feb 2005 21:49:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57680060 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 13 Feb 2005 21:49:36 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 13 Feb 2005 21:49:36 -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 j1E2na8q025008; Mon, 14 Feb 2005 02:49:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1E2nYsw031938; Mon, 14 Feb 2005 02:49:34 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021318493311954 ; Sun, 13 Feb 2005 18:49:33 -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); Sun, 13 Feb 2005 18:49:33 -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] Ambiguity in BLOCK semantics Thread-Index: AcURH2L5XV+kuFKHQs2QiAbuFQ8JMgBH/mnA X-OriginalArrivalTime: 14 Feb 2005 02:49:33.0842 (UTC) FILETIME=[D0649720:01C5123F] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Sun, 13 Feb 2005 18:49:33 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Ambiguity in BLOCK semantics Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > I think the main challenge is that the LFB may need to be more > accomodating. We cant assume a certain "design". The=20 > indirection example > will make it really easy to parse for some FEs but not=20 > others; i know of > ASICs where that would be a real nice straight mapping (since they do > have such indirections) and of others where this would a complete pain > and would require the intervention of the CE to chew things into > something along the first example from David. Whats more=20 > interesting is > i have seen desire to have NH as a LFB on its own right where the NHID > would infact be an alias;=20 While I agree that we cannot assume that a FE be designed in a certain way, I think we can assume that the FE software can "cook" the ForCES protocol into whatever the representation is that the FE hardware prefers. Put another way, I doubt (at least the a generation or two of) FE hardware will "natively" speak ForCES in the asics. Cheers, David From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 13 23:03: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 XAA23568 for ; Sun, 13 Feb 2005 23:03:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0XnY-0006zL-TC for forces-archive@IETF.ORG; Sun, 13 Feb 2005 23:25: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 <13.00F89A97@cherry.ease.lsoft.com>; 13 Feb 2005 23:03:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57684152 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 13 Feb 2005 23:01:06 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 13 Feb 2005 23:01:06 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021320013559:52037 ; Sun, 13 Feb 2005 20:01:35 -0800 References: <5.1.0.14.2.20050212001242.01ed2d30@pop.avici.com> <6.2.0.14.0.20050212003442.03190c40@localhost> <1108225485.1126.346.camel@jzny.localdomain> <6.2.0.14.0.20050212113120.031aa510@localhost> <1108231627.1178.535.camel@jzny.localdomain> <6.2.0.14.0.20050212131217.031b0f98@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 02/13/2005 08:01:35 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/13/2005 08:01:40 PM, Serialize complete at 02/13/2005 08:01:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108353660.1125.994.camel@jzny.localdomain> Date: Sun, 13 Feb 2005 23:01:01 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.0.14.0.20050212131217.031b0f98@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit It would be nice to hear from Weiming on this topic. cheers, jamal On Sat, 2005-02-12 at 13:12, Joel M. Halpern wrote: > I can live with that. > Yours, > Joel > > At 01:07 PM 2/12/2005, Jamal Hadi Salim wrote: > >How about this as a middle ground (because i cant think of a good way we > >can close this): > >Lets Keep those flags on the path; lets just have the draft talk that > >BLK is defered for now[1] and will be revisited later. Keeping the flags > >will guarantee that we can add them back if we ned to. From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 13 23:07: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 XAA23781 for ; Sun, 13 Feb 2005 23:07:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0Xqc-00072A-Kt for forces-archive@IETF.ORG; Sun, 13 Feb 2005 23:28: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 <8.00F89AA5@cherry.ease.lsoft.com>; 13 Feb 2005 23:07:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57685348 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 13 Feb 2005 23:06:57 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 13 Feb 2005 23:06:57 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021320072766:52075 ; Sun, 13 Feb 2005 20:07:27 -0800 References: 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 02/13/2005 08:07:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/13/2005 08:07:30 PM, Serialize complete at 02/13/2005 08:07:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108354013.1126.1001.camel@jzny.localdomain> Date: Sun, 13 Feb 2005 23:06:53 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Sun, 2005-02-13 at 21:49, Putzolu, David wrote: > > I think the main challenge is that the LFB may need to be more > > accomodating. We cant assume a certain "design". The > > indirection example > > will make it really easy to parse for some FEs but not > > others; i know of > > ASICs where that would be a real nice straight mapping (since they do > > have such indirections) and of others where this would a complete pain > > and would require the intervention of the CE to chew things into > > something along the first example from David. Whats more > > interesting is > > i have seen desire to have NH as a LFB on its own right where the NHID > > would infact be an alias; > > While I agree that we cannot assume that a FE be designed in > a certain way, I think we can assume that the FE software can > "cook" the ForCES protocol into whatever the representation is > that the FE hardware prefers. Indeed, except the way you represent in the LFB will make some s/ware in some FEs (and as a result associated CEs) work harder than others. The examples you provide are not very different from most ASICs layouts out there do things. So pick any of your two examples at the cost of the other. > Put another way, I doubt (at least > the a generation or two of) FE hardware will "natively" speak > ForCES in the asics. I would be pleasantly suprised if they did. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 12:24: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 MAA24224 for ; Mon, 14 Feb 2005 12:24:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kIC-0007ZI-34 for forces-archive@IETF.ORG; Mon, 14 Feb 2005 12:45: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 <18.00F8B636@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 12:24:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57777432 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 12:24:12 -0500 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 12:24:11 -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 j1EHOBmV137128 for ; Mon, 14 Feb 2005 17:24:11 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1EHOA2f184514 for ; Mon, 14 Feb 2005 18:24:10 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1EHOAmJ007468 for ; Mon, 14 Feb 2005 18:24:10 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1EHOAXb007465; Mon, 14 Feb 2005 18:24:10 +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 SAA83984; Mon, 14 Feb 2005 18:24:10 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1108354013.1126.1001.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 mtagate2.de.ibm.com id j1EHOBmV137128 Approved-By: Robert Haas Message-ID: <4210DEB8.3000400@zurich.ibm.com> Date: Mon, 14 Feb 2005 18:24:08 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Ambiguity in BLOCK semantics Comments: cc: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108354013.1126.1001.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable After discussing again with Jamal, I understood that his semantic of the=20 BLOCK selector actually does not leave room for ambiguity, given that a=20 simple (but not yet explicited) rule is used: In the previous example of For table entries 4 5 6, (each table entry has fields name, surname, address, city) set name with a set surname with b set address with c According to Jamal, this will always result in: 2) {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...} So I think the implict rule can be explicited as: all pathdata(s) that follow the BLOCK selector apply (in turn) to all=20 selections made by the BLOCK selector. Exception: if the pathdata that follow are more than a single DATARAW,=20 then each datapath maps to a selection (and they must be the same number=20 of both). This means for instance that: For table entries 4 5, (each table entry has fields name, surname, address, city) set name with a set name with b will result in: {...,(b,x,x,x),(b,x,x,x),...} Given that this removes the ambiguity, I guess we could keep the BLOCK=20 anyway ? Regards, -Robert Jamal Hadi Salim wrote: >On Sun, 2005-02-13 at 21:49, Putzolu, David wrote: > =20 > >>>I think the main challenge is that the LFB may need to be more >>>accomodating. We cant assume a certain "design". The=20 >>>indirection example >>>will make it really easy to parse for some FEs but not=20 >>>others; i know of >>>ASICs where that would be a real nice straight mapping (since they do >>>have such indirections) and of others where this would a complete pain >>>and would require the intervention of the CE to chew things into >>>something along the first example from David. Whats more=20 >>>interesting is >>>i have seen desire to have NH as a LFB on its own right where the NHID >>>would infact be an alias;=20 >>> =20 >>> >>While I agree that we cannot assume that a FE be designed in >>a certain way, I think we can assume that the FE software can >>"cook" the ForCES protocol into whatever the representation is >>that the FE hardware prefers. =20 >> =20 >> > >Indeed, except the way you represent in the LFB will make some s/ware in >some FEs (and as a result associated CEs) work harder than others.=20 >The examples you provide are not very different from most ASICs layouts >out there do things. So pick any of your two examples at the cost of the >other. > > =20 > >>Put another way, I doubt (at least >>the a generation or two of) FE hardware will "natively" speak >>ForCES in the asics. >> =20 >> > >I would be pleasantly suprised if they did. > >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 Feb 14 12:27: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 MAA24436 for ; Mon, 14 Feb 2005 12:27:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kLf-0007dF-NN for forces-archive@IETF.ORG; Mon, 14 Feb 2005 12:49: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 <8.00F8B70E@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 12:27:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57777605 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 12:27:50 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 12:27:50 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9183530 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 12:27:49 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050214122511.032ec258@localhost> Date: Mon, 14 Feb 2005 12:27:34 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4210DEB8.3000400@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable The ambiguity is that if those three SETs were three DATARAWs, then the=20 first would apply to entry 4, the second to entry 5, and the third to entry= =20 6. Thus, changing the TLV used to hold the follow on information will=20 change the semantics? (For an extreme case, suppose we had a PATH-DATA that meant "all". We=20 probably need this to allow someone to set an entire LFB anyway. So now,=20 if I use three DATARAWs it means one thing, and if I use three PATH-DATAs=20 with path=3D"all", it means something different?) Yours, Joel At 12:24 PM 2/14/2005, Robert Haas wrote: >After discussing again with Jamal, I understood that his semantic of the=20 >BLOCK selector actually does not leave room for ambiguity, given that a=20 >simple (but not yet explicited) rule is used: > >In the previous example of > >For table entries 4 5 6, >(each table entry has fields name, surname, address, city) > set name with a > set surname with b > set address with c > >According to Jamal, this will always result in: > >2) {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...} > >So I think the implict rule can be explicited as: > >all pathdata(s) that follow the BLOCK selector apply (in turn) to all=20 >selections made by the BLOCK selector. >Exception: if the pathdata that follow are more than a single DATARAW,=20 >then each datapath maps to a selection (and they must be the same number=20 >of both). > >This means for instance that: > >For table entries 4 5, >(each table entry has fields name, surname, address, city) > set name with a > set name with b > >will result in: >{...,(b,x,x,x),(b,x,x,x),...} > >Given that this removes the ambiguity, I guess we could keep the BLOCK=20 >anyway ? >Regards, >-Robert > >Jamal Hadi Salim wrote: > >>On Sun, 2005-02-13 at 21:49, Putzolu, David wrote: >> >> >>>>I think the main challenge is that the LFB may need to be more >>>>accomodating. We cant assume a certain "design". The indirection example >>>>will make it really easy to parse for some FEs but not others; i know of >>>>ASICs where that would be a real nice straight mapping (since they do >>>>have such indirections) and of others where this would a complete pain >>>>and would require the intervention of the CE to chew things into >>>>something along the first example from David. Whats more interesting is >>>>i have seen desire to have NH as a LFB on its own right where the NHID >>>>would infact be an alias; >>>While I agree that we cannot assume that a FE be designed in >>>a certain way, I think we can assume that the FE software can >>>"cook" the ForCES protocol into whatever the representation is >>>that the FE hardware prefers. >>> >> >>Indeed, except the way you represent in the LFB will make some s/ware in >>some FEs (and as a result associated CEs) work harder than others. The=20 >>examples you provide are not very different from most ASICs layouts >>out there do things. So pick any of your two examples at the cost of the >>other. >> >> >> >>>Put another way, I doubt (at least >>>the a generation or two of) FE hardware will "natively" speak >>>ForCES in the asics. >>> >> >>I would be pleasantly suprised if they did. >> >>cheers, >>jamal >> >> >> > >-- >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 Feb 14 13:04: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 NAA28307 for ; Mon, 14 Feb 2005 13:04:23 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kv3-00006y-4F for forces-archive@IETF.ORG; Mon, 14 Feb 2005 13:26: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 <9.00F8B87C@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 13:04:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57780355 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 13:04:23 -0500 Received: from 195.212.29.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 13:04:23 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j1EI4Mn1149766 for ; Mon, 14 Feb 2005 18:04:22 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 j1EI4M2f175180 for ; Mon, 14 Feb 2005 19:04:22 +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 j1EI4MeR015348 for ; Mon, 14 Feb 2005 19:04:22 +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 j1EI4Lvq015329; Mon, 14 Feb 2005 19:04:22 +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 TAA105546; Mon, 14 Feb 2005 19:04:21 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> <6.2.1.2.0.20050214122511.032ec258@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.de.ibm.com id j1EI4Mn1149766 Approved-By: Robert Haas Message-ID: <4210E824.7010807@zurich.ibm.com> Date: Mon, 14 Feb 2005 19:04:20 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Ambiguity in BLOCK semantics Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050214122511.032ec258@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > The ambiguity is that if those three SETs were three DATARAWs, then=20 > the first would apply to entry 4, the second to entry 5, and the third=20 > to entry 6. Thus, changing the TLV used to hold the follow on=20 > information will change the semantics? Right, this is what I captured in the rule. I agree it is not the=20 cleanest design. It would be worthwhile to distinguish the BLOCK=20 assignment (which is really what we are interested in here) vs the=20 INDIVIDUAL assignment. > > (For an extreme case, suppose we had a PATH-DATA that meant "all". We=20 > probably need this to allow someone to set an entire LFB anyway. Yes, a one-shot SET for all attributes of an LFB would be helpful, but=20 not mandatory. > So now, if I use three DATARAWs it means one thing, and if I use=20 > three PATH-DATAs with path=3D"all", it means something different?) An all-PATHDATA and a DATARAW should be considered equivalent (they set=20 all the values in both cases), so it does not make sense to have a=20 sequence of them overwrite eachother. To be precise the rule would be: all pathdata(s) that follow the BLOCK selector apply (in turn) to all=20 selections made by the BLOCK selector. Exception: if the pathdata that follow are more than a single DATARAW or=20 a single all-PATHDATA, then each pathdata maps to a selection (and they=20 must be the same number of both). Regards, -Robert > > Yours, > Joel > > At 12:24 PM 2/14/2005, Robert Haas wrote: > >> After discussing again with Jamal, I understood that his semantic of=20 >> the BLOCK selector actually does not leave room for ambiguity, given=20 >> that a simple (but not yet explicited) rule is used: >> >> In the previous example of >> >> For table entries 4 5 6, >> (each table entry has fields name, surname, address, city) >> set name with a >> set surname with b >> set address with c >> >> According to Jamal, this will always result in: >> >> 2) {...,(a,b,c,x),(a,b,c,x),(a,b,c,x),...} >> >> So I think the implict rule can be explicited as: >> >> all pathdata(s) that follow the BLOCK selector apply (in turn) to all=20 >> selections made by the BLOCK selector. >> Exception: if the pathdata that follow are more than a single=20 >> DATARAW, then each datapath maps to a selection (and they must be the=20 >> same number of both). >> >> This means for instance that: >> >> For table entries 4 5, >> (each table entry has fields name, surname, address, city) >> set name with a >> set name with b >> >> will result in: >> {...,(b,x,x,x),(b,x,x,x),...} >> >> Given that this removes the ambiguity, I guess we could keep the=20 >> BLOCK anyway ? >> Regards, >> -Robert >> >> Jamal Hadi Salim wrote: >> >>> On Sun, 2005-02-13 at 21:49, Putzolu, David wrote: >>> >>> >>>>> I think the main challenge is that the LFB may need to be more >>>>> accomodating. We cant assume a certain "design". The indirection=20 >>>>> example >>>>> will make it really easy to parse for some FEs but not others; i=20 >>>>> know of >>>>> ASICs where that would be a real nice straight mapping (since they = do >>>>> have such indirections) and of others where this would a complete=20 >>>>> pain >>>>> and would require the intervention of the CE to chew things into >>>>> something along the first example from David. Whats more=20 >>>>> interesting is >>>>> i have seen desire to have NH as a LFB on its own right where the=20 >>>>> NHID >>>>> would infact be an alias; >>>> >>>> While I agree that we cannot assume that a FE be designed in >>>> a certain way, I think we can assume that the FE software can >>>> "cook" the ForCES protocol into whatever the representation is >>>> that the FE hardware prefers. >>>> >>> >>> Indeed, except the way you represent in the LFB will make some=20 >>> s/ware in >>> some FEs (and as a result associated CEs) work harder than others.=20 >>> The examples you provide are not very different from most ASICs layou= ts >>> out there do things. So pick any of your two examples at the cost of=20 >>> the >>> other. >>> >>> >>> >>>> Put another way, I doubt (at least >>>> the a generation or two of) FE hardware will "natively" speak >>>> ForCES in the asics. >>>> >>> >>> I would be pleasantly suprised if they did. >>> >>> cheers, >>> jamal >>> >>> >>> >> >> --=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/~r= ha > > > --=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 Feb 14 13:08: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 NAA28625 for ; Mon, 14 Feb 2005 13:08:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kzN-0000CL-5I for forces-archive@IETF.ORG; Mon, 14 Feb 2005 13:30: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 <13.00F8B8F4@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 13:08:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57780766 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 13:08:51 -0500 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 13:08:51 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j1EI8pKb130360 for ; Mon, 14 Feb 2005 18:08:51 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1EI8p8D117086 for ; Mon, 14 Feb 2005 18:08:51 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1EI8pF6018125 for ; Mon, 14 Feb 2005 18:08:51 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1EI8orm018117; Mon, 14 Feb 2005 18:08:50 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 TAA45716; Mon, 14 Feb 2005 19:08:50 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41E54F81.1040607@zurich.ibm.com> <6.1.2.0.0.20050112121110.0395a900@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.uk.ibm.com id j1EI8pKb130360 Approved-By: Robert Haas Message-ID: <4210E931.7070905@zurich.ibm.com> Date: Mon, 14 Feb 2005 19:08:49 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: cc: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20050112121110.0395a900@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Coming back to implementation issues that fire up in the protocol: In the case of a single active CE, there can be multiple processes=20 "hiding" behind the same CE ID, i.e., a process updating firewalling=20 rules and another process updating the routing table, in parallel. We=20 must be able to: 1) correlate at the CE the responses from the FE with the commands that=20 were originated by each process. 2) forward at the CE FE-event notifications to the appropriate=20 processes that registered for it. So if the CE ID is the same for all these processes, something is=20 missing in the protocol to support 1) and 2) ... Unless the ForCES PL=20 decides to use different TCP/UDP ports for each process (I wouldn't=20 recommend this), but this will anyway not solve 2). BTW, the multi-CE problem is something one should still think of while=20 defining the model. Although the requirements draft only talks of a=20 single active CE for each FE, it is a scalability issue if I can't run=20 the firewalling and routing processes on two different boxes (i.e. two=20 CEs). So let's at least consider the impact of the multi-manager problem=20 on the model so we don't close all the doors for future support. Regards, -Robert Joel M. Halpern wrote: > I thought we had agreed that for now we would focus on a single active=20 > CE per FE> An FE that wants to be managed by several CEs is (I=20 > thought) to 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=20 > is probably that one should use different ports if one is going to run=20 > several CEs (or FEs) on the same machine / interface. I am not sure=20 > we can / should introduce an extra demux layer for the "native=20 > 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,=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=20 >> machine. So there is an association for each (CE-FE) pair. Or do we=20 >> consider associations to include more than two members ? Note that=20 >> multiple associations may share the same TCP/SCTP/... connection. >> >> Demultiplexing: Note that in the case where multiple CEs run on the=20 >> same machine, the CE ID can be viewed as a demultiplexor. The ForCES=20 >> protocol does not otherwise include correlators that would enable=20 >> callbacks to the appropriate CE on the response to a ForCES command=20 >> (or reception of an event). >> >> Access conflicts: The framework draft specifies that CE=20 >> synchronization is beyond the scope of ForCES. This means that, for=20 >> instance, two CEs changing the same LFB attribute value, is not=20 >> viewed at the ForCES level as a conflict. But if two CEs try to=20 >> perform interleaved 2-phase commit operations on the same attribute,=20 >> then ForCES should of course prevent 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=20 >> fired. I propose that a list of interested CE IDs is associated with=20 >> each event 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/~r= ha > > > --=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 Feb 14 14:33: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 OAA05289 for ; Mon, 14 Feb 2005 14:33:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mJP-00025C-5L for forces-archive@IETF.ORG; Mon, 14 Feb 2005 14:55: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 <7.00F8BD30@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 14:33:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57787334 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 14:33:33 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 14:33:33 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021411291676:19 ; Mon, 14 Feb 2005 11:29:16 -0800 References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> <6.2.1.2.0.20050214122511.032ec258@localhost> <4210E824.7010807@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 02/14/2005 11:29:17 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/14/2005 11:34:24 AM, Serialize complete at 02/14/2005 11:34:24 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108408684.1076.106.camel@jzny.localdomain> Date: Mon, 14 Feb 2005 14:28:21 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Ambiguity in BLOCK semantics Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4210E824.7010807@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit On Mon, 2005-02-14 at 13:04, Robert Haas wrote: > > So now, if I use three DATARAWs it means one thing, and if I use > > three PATH-DATAs with path="all", it means something different?) > sigh. Note that Joel and I have very different views of what it means to follow a selector. Otherwise there is no ambiguity _at all_, i.e the premise behind Joels arguement is innacurate in my view (as he does think of mine) and i was hoping we would settle it at some point - but if people want to talk about it now i am more than willing. It actually has nothing to do with BLK like i said earlier but rather in where you are in the hierachy; Take an example of a path we have to a table which has 100 entries (no BLK flag set). Say you provide one dataraw with one row entry; What does that semantically mean? To me it means you set those 100 rows to that dataraw's value. OTOH, if you have 100 row entries it means you sequentially set the value to those entries in the order they are provided. You have anything other than one or 100, its an error. no BLKs were used, but same rule applies. > An all-PATHDATA and a DATARAW should be considered equivalent (they set > all the values in both cases), so it does not make sense to have a > sequence of them overwrite eachother. > In the example above, its like sending 100 row entries with _exactly_ the same values. While legit may not be a sensible thing to do. > To be precise the rule would be: > > all pathdata(s) that follow the BLOCK selector apply (in turn) to all > selections made by the BLOCK selector. > Exception: if the pathdata that follow are more than a single DATARAW or > a single all-PATHDATA, then each pathdata maps to a selection (and they > must be the same number of both). > Like i was pointing in earlier email: "You must find the path to the target first"; once you do, only then can you use the supplied DATARAW and only then does it make sense to have a DATARAW! (i.e classify then apply data). If the path leads to parallel nodes in the hierachy, then all nodes have to have exactly that piece of data applied to them. To use your example: For table entries 4 5 6, (each table entry has fields name, surname, address, city) set name with a set surname with b set address with c let me break it down in several ways "//" which will show all cases as comments: 1) Applying data to a table --> Path to table X, which has 100 entries // We are now at the table X // any data that follows here will have to apply // to the whole table and so needs to pass the necessary error // checks ----> dataraw = { one or 100 rows worth of data each with name, surname, address, city} 2) Applying data to a select rows in a table --> Path to table X, // We are now at the table X ----> select row entries 4 5 6, // we have highlighted only rows 4, 5 and 6 // we can only have 1 or 3 rows worth of data ----> dataraw = { one or 3 rows worth of data each with name, surname, address, city} 3) Applying data to a select rows and columns in a table (your example) --> Path to table X, // We are now at the table X ----> select row entries 4 5 6, // we have highlighted only rows 4, 5 and 6 ----> select column name --------> data = { a } // given the path so far: we have tableX, row 4,5,6 and column "name" // clearly, unambigoulsy it means just that: i.e this data belongs // to tableX, rows 4, 5,6 column name. The error check needed // is to make sure that its of the correct length ----> select surname --------> data = { b } ----> select address --------> data = {c} -------------- Where is the ambiguity? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 14:34: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 OAA05378 for ; Mon, 14 Feb 2005 14:34:30 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mKF-00026d-Cw for forces-archive@IETF.ORG; Mon, 14 Feb 2005 14:56: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 <20.00F8BBF5@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 14:34:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57787422 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 14:34:29 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 14:34:28 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021411351915:59 ; Mon, 14 Feb 2005 11:35:19 -0800 References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> <6.2.1.2.0.20050214122511.032ec258@localhost> <4210E824.7010807@zurich.ibm.com> <1108408684.1076.106.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 02/14/2005 11:35:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/14/2005 11:35:20 AM, Serialize complete at 02/14/2005 11:35:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108409666.1074.110.camel@jzny.localdomain> Date: Mon, 14 Feb 2005 14:34:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Ambiguity in BLOCK semantics Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108408684.1076.106.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit The arrows were a little misleading so didnt show the nesting properly for #3; it should be; comments are the same as before: --> Path to table X, ----> select row entries 4 5 6, --------> select column name --------> dataraw = { a } --------> select surname --------> dataraw = { b } --------> select address --------> dataraw = {c} On Mon, 2005-02-14 at 14:28, Jamal Hadi Salim wrote: > 3) Applying data to a select rows and columns in a table (your example) > --> Path to table X, > // We are now at the table X > ----> select row entries 4 5 6, > // we have highlighted only rows 4, 5 and 6 > ----> select column name > --------> data = { a } > // given the path so far: we have tableX, row 4,5,6 and column "name" > // clearly, unambigoulsy it means just that: i.e this data belongs > // to tableX, rows 4, 5,6 column name. The error check needed > // is to make sure that its of the correct length > > ----> select surname > --------> data = { b } > ----> select address > --------> data = {c} > > -------------- > > Where is the ambiguity? > > cheers, > jamal From entmib@ietf.org Mon Feb 14 21:06: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 VAA14965; Mon, 14 Feb 2005 21:06:13 -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 1D0sRO-0006k5-DH; Mon, 14 Feb 2005 21:27:55 -0500 Received: from [61.246.232.53] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1D0s6M-0000E9-MB; Mon, 14 Feb 2005 21:06:12 -0500 From: "Informe Exclusivo" To: ForumSocial2005@ns.cnri.reston.va.us Subject: Forum Social, "revolucao intersticial" e anarquia X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Mon, 14 Feb 2005 21:06:12 -0500 X-Spam-Score: 29.3 (+++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Destaque Internacional - Informes de Conjuntura - Ano VII - Nos

FSM:InformeCompletoGratuitoEnCastellano -- SendFreeAutomaticTranslator

Destaque Internacional - Informes de Conjuntura - Ano VII - Nos. 161-162 - Buenos Aires / Madri - Fevereiro, 2005 - Responsável: Javier González.-

5 o. Fórum Social Mundial: "diversidade", "revolução intersticial" e sonho anárquico

* Uma radiografia atualizada do chamado "movimento de movimentos" alter-globalista, suas metas, sua função dinamizadora, suas discussões estratégicas e de bastidores, seu poder real e seus calcanhares de Aquiles

*Um informe exclusivo, com entrevistas a José Saramago, Frei Betto, Leonardo Boff, Ignacio Ramonet, presidente Chávez, Alina Guevara, John Holloway, Michael Hardt, Tariq Ali, Atilio Borón, João Pedro Stédile, Ricardo Alarcón e outros participantes do FSM

FSM:InformeCompletoGratuitoEmPortugues

Introdução

* "O maior lobby da Terra" * O 5o. FSM em cifras

1. Frei Betto, Gramsci e Lenine: "pressão popular" para "conquistar" o poder

* Os recados de Frei Betto * Gramsci: Parcelas gradativas do poder * Lenine: "Doença infantil do comunismo" * "Política, mística e religião": a "companheira Aparecida" * "A dialética é que tem razão" * Filha do "Che" Guevara: "métodos velhos" e "erros" a serem evitados

2. ¿Transformar o mundo sem tomar o poder, ou tomar o poder para transformar o mundo?

* Holloway e a "revolução intersticial" * Tariq Ali: tomar o poder para transformar o mundo * Atilio Borón: atualidade de Lenine * "Certeza fundamental da superioridade do comunismo" * Stédile: "nossa querida Rosa Luxemburgo" * Rosa Luxemburgo e dilemas atuais

3. Chávez: ¿"novo libertador", sucessor de Fidel Castro?

* Presidente venezuelano incendeia o FSM * Acordo com Cuba comunista e eixo latino-americano das esquerdas * Chávez explica a estratégia gradualista e defende Lula

4. Foro de São Paulo, Cuba e Lula

* Genoíno, Regalado etc. * Guarda-chuvas político * Perfil discreto, para não prejudicar Lula * "Centralismo, modelo ultrapassado" * Direitos humanos, Cuba e "Che" Guevara

5. "Teologia da libertação", indigenismo e "sociedade futura"

* Pe. Torres: indígenas, "reserva espiritual" * Indígenas: "Nós somos o outro mundo" * Amazônia continental: alvo estratégico * Marilene: "distinção entre Estado e Nação" * Campos: "plurinacionalidade e multietnicidade"

6. Desconstrução de teorias, utopias e teologias...

* Utopistas versus anti-utopistas * Saramago: não-utopia * Ramonet: anti-utopia * Gadotti: "a época das certezas passou" * Siddhartha Shivamurthy * Teologia da libertação e desconstrução * Revolução sexual * D. Casaldáliga: "mudar a religião" * Pe. Barros: "Superar a convicção de que o cristianismo é a única religião verdadeira" * Inflexão no alter-mundialismo: rumo à anarquia política e religiosa? * O caminho rumo a um estado de coisas "tribal" * Estruturalismo e vida tribal

7. "Território Social Mundial" e Acampamento da Juventude, laboratórios de um "outro mundo" autogestionário e anárquico

* Acampamento Intercontinental * "Reinvenção da vida em sociedade" * "Horizontalidade" e "autogestão" * "Centros de Ação" * "Axônios"

8. FSM, "matança dos inocentes" e "diversidade" intolerante

* Aborto: flagrante contradição * "Ajudar as católicas a serem a favor do aborto" * Ministras de Lula * "Diversidade" intolerante

9. Esquerdas reconhecem calcanhares de Aquiles

* FSM: Força e fraqueza * Altmann: "Mas terá valido a pena?" * "Frustração" e "adiamento": incapacidade de convencer * Pe. Torres: "Vamos tardar 30 anos em ter nova alternativa" * Frei Betto, Aleida Guevara, Borón * Leonardo Boff: estrela do PT rejeitada "com desdém" * Weissheimer: "auto-engano" de dirigentes do PT

Conclusão: ver, julgar, atuar

* Um "outro mundo" que já está nascendo * "Diversidade": rumo a novas formas de totalitarismo? * Mapa de vulnerabilidades

LINKS GRATUITOS

FSM:InformeCompletoGratuitoEmPortugues

FSM:InformeCompletoGratuitoEnCastellano

InformesCompletosGratuitosForunsAnterioresEmPortugues

InformesCompletosGratuitosForumsAnterioresEnCastellano

FSM:MinhaOpiniao

FSM:MiOpinion

Remover

From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 21: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 VAA16408 for ; Mon, 14 Feb 2005 21: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 1D0smq-00078y-7f for forces-archive@IETF.ORG; Mon, 14 Feb 2005 21:50:05 -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.00F8CD03@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 21:28:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57841509 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 21:28:21 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 21:28:21 -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 j1F2SJf4011487; Tue, 15 Feb 2005 02:28:19 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 j1F2SGah023331; Tue, 15 Feb 2005 02:28: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 M2005021418281609083 ; Mon, 14 Feb 2005 18:28:16 -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); Mon, 14 Feb 2005 18:28:16 -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] Multiple CEs talking to the same FE Thread-Index: AcUSwEFzRekzQ4f7Rp+70AYYkNYhpQARHGsg X-OriginalArrivalTime: 15 Feb 2005 02:28:16.0384 (UTC) FILETIME=[0161B800:01C51306] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> Date: Mon, 14 Feb 2005 18:28:15 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Multiple CEs talking to the same FE Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Robert, My comments on this inline....=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Coming back to implementation issues that fire up in the protocol: In the case of a single active CE, there can be multiple processes=20 "hiding" behind the same CE ID, i.e., a process updating firewalling=20 rules and another process updating the routing table, in parallel. We=20 must be able to: 1) correlate at the CE the responses from the FE with the commands that=20 were originated by each process. 2) forward at the CE FE-event notifications to the appropriate=20 processes that registered for it. So if the CE ID is the same for all these processes, something is=20 missing in the protocol to support 1) and 2) ... Unless the ForCES PL=20 decides to use different TCP/UDP ports for each process (I wouldn't=20 recommend this), but this will anyway not solve 2). [HK] This is more of an implementation issue than a protocol issue in my opinion. You could have the ForCES protocol daemon demuxing between different processes using a shim layer with standard IPC. The shim layer would take care of translating requests from different processes to different ForCES protocol message types, sequence nos, etc. Let me know if this sounds reasonable or I am missing something here? BTW, the multi-CE problem is something one should still think of while=20 defining the model. Although the requirements draft only talks of a=20 single active CE for each FE, it is a scalability issue if I can't run=20 the firewalling and routing processes on two different boxes (i.e. two=20 CEs). So let's at least consider the impact of the multi-manager problem on the model so we don't close all the doors for future support. [HK] I agree with Joel on this. I believe this is something which can be addresses in a later rev of the protocol draft. We should focus on getting the basic protocol messages/encoding correct at this point. That itself is not a straight forward task cause of the many tradeoffs. We can come back to the multi-CE issue in the next version of the protocol. Regards Hormuzd Joel M. Halpern wrote: > I thought we had agreed that for now we would focus on a single active > CE per FE> An FE that wants to be managed by several CEs is (I=20 > thought) to pretend it is several FEs, probably with distinct resources. > > The multi-manager problem is very very messy. > From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 21:38:39 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 VAA17107 for ; Mon, 14 Feb 2005 21:38:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0swn-0007K5-6v for forces-archive@IETF.ORG; Mon, 14 Feb 2005 22:00: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 <13.00F8CD95@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 21:38:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57841986 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 21:38:39 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 21:38:39 -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 j1F2cdf4015325; Tue, 15 Feb 2005 02:38:39 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 j1F2ccaj029251; Tue, 15 Feb 2005 02:38:39 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 M2005021418383810306 ; Mon, 14 Feb 2005 18:38:38 -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); Mon, 14 Feb 2005 18:38:38 -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] Ambiguity in BLOCK semantics-some qs? Thread-Index: AcUSuoyVKgkBlcb5S4y2o/465GLYFgAS37pg X-OriginalArrivalTime: 15 Feb 2005 02:38:38.0673 (UTC) FILETIME=[744B7C10:01C51307] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0440B555@orsmsx408> Date: Mon, 14 Feb 2005 18:38:37 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Ambiguity in BLOCK semantics-some qs? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Hi Joel, Jamal, I have a few questions in this regard which may or may be not directly related to the block semantics...I hope you wont mind providing me with the rationale... * Why do we need to support nested PATH-DATA in the grammar? i.e. DATA :=3D [DATARAW] | + instead of DATA :=3D [DATARAW] I believe we could support all the use cases using the latter, in a simpler way. * Why can be use the DATARAW itself to support Block operations? i.e. DATARAW TLV: L =3D XXX, V=3D 0, j1value, j2value 1, j1value, j2value 2, j1value, j2value 3, j1value, j2value 4, j1value, j2value 5, j1value, j2value We can do this to set the entire table, why not use the DATARAW directly to set a block of table entries? I think Joel had given me some reason for this on our conference call, but I missed it. I appologize in advance if I am asking something that is already discussed. If you could point me to the relevant emails, in case this was discussed it would be very helpful. Thanks a lot, Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 22:49: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 WAA22011 for ; Mon, 14 Feb 2005 22:49:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0u3h-0000RP-Rx for forces-archive@IETF.ORG; Mon, 14 Feb 2005 23:11: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 <17.00F8D171@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 22:49:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57846539 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 22:49:50 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 22:49:49 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9190204 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 22:49:50 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0440B555@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050214224300.031f4b40@localhost> Date: Mon, 14 Feb 2005 22:49:30 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics-some qs? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0440B555@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 One the nested PATH-DATA, this was an efficiency mechanism. As you say, everything it can do can be done without it. However, there are two important factors: 1) It is simple, well defined, easy to describe, and I think reasonably easy to implement. 2) It covers a case that is clearly likely, namely setting multiple things in the same portion of the LFB. I think it is a good efficiency tradeoff. My view on the DATARAW with indices is that it is for use when we are representing the whole table. It seems to me that one important use case for setting into a table is where we are resetting the table, creating the new entries and throwing away whatever was in the table before (just as setting a variable discards the old value.) If we used indices in a DATARAW for a table to enable selective block operations, then we would need some other way to handle setting the "whole" table. And it should be pointed out that this would still leave many of reasonable the uses of BLK unsupported. I would not be surprised if once we complete the protocol and get some implementation and ueage experience, we don't decide on some form of BLK. That is why we are being careful to make sure it is easy to add later. Yours, Joel At 09:38 PM 2/14/2005, Khosravi, Hormuzd M wrote: >Hi Joel, Jamal, > >I have a few questions in this regard which may or may be not directly >related to the block semantics...I hope you wont mind providing me with >the rationale... > >* Why do we need to support nested PATH-DATA in the grammar? >i.e. DATA := [DATARAW] | + instead of DATA := [DATARAW] >I believe we could support all the use cases using the latter, in a >simpler way. > > >* Why can be use the DATARAW itself to support Block operations? >i.e. DATARAW TLV: L = XXX, V= > 0, j1value, j2value > 1, j1value, j2value > 2, j1value, j2value > 3, j1value, j2value > 4, j1value, j2value > 5, j1value, j2value >We can do this to set the entire table, why not use the DATARAW directly >to set a block of table entries? I think Joel had given me some reason >for this on our conference call, but I missed it. > > >I appologize in advance if I am asking something that is already >discussed. >If you could point me to the relevant emails, in case this was discussed >it would be very helpful. > >Thanks a lot, >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 14 23:13:50 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 XAA23492 for ; Mon, 14 Feb 2005 23:13:50 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0uQv-0000uJ-3q for forces-archive@IETF.ORG; Mon, 14 Feb 2005 23:35: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 <9.00F8D2E3@cherry.ease.lsoft.com>; Mon, 14 Feb 2005 23:13:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57850016 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 14 Feb 2005 23:13:48 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Feb 2005 23:13:47 -0500 Received: from [219.82.176.163] by 202.96.99.56 with StormMail ESMTP id 6322.2105028806; Tue, 15 Feb 2005 12:45:57 +0800 (CST) References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> <6.2.1.2.0.20050214122511.032ec258@localhost> <4210E824.7010807@zurich.ibm.com> <1108408684.1076.106.camel@jzny.localdomain> 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 Approved-By: Weiming Wang Message-ID: <00ce01c51315$299ea170$020aa8c0@wwm1> Date: Tue, 15 Feb 2005 12:16:43 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Ambiguity in BLOCK semantics Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi all, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: Ambiguity in BLOCK semantics > Say you provide one dataraw with one row entry; What does that > semantically mean? To me it means you set those 100 rows to that > dataraw's value. > OTOH, if you have 100 row entries it means you sequentially set the > value to those entries in the order they are provided. > You have anything other than one or 100, its an error. > no BLKs were used, but same rule applies. I agree with Jamal's that the confusion that leads to the ambiguity debate is only about what a single row entry in dataraw really means, which means to apply to all rows selected or only to the first row? By explicitly describing this in our draft, we'll then kill the ambiguity, I think. I agree well that we define the meaning as applying to all rows selected. I also agree the one-or-all semantics, i.e., all partially encoded data other than one or all should be interpreted as errors. This question is purely an issue for data encoding grammar, and has nothing to do with block actually. Cheer, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 00:14:39 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 AAA28300 for ; Tue, 15 Feb 2005 00:14:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0vNm-0002Gc-Vw for forces-archive@IETF.ORG; Tue, 15 Feb 2005 00:36:23 -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.00F8D67B@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 0:14:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57856502 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 00:14:38 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 00:14:36 -0500 Received: from [219.82.176.163] by 202.96.99.56 with StormMail ESMTP id 6322.2305915701; Tue, 15 Feb 2005 13:46:48 +0800 (CST) References: <1108354013.1126.1001.camel@jzny.localdomain> <4210DEB8.3000400@zurich.ibm.com> <6.2.1.2.0.20050214122511.032ec258@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 Approved-By: Weiming Wang Message-ID: <010a01c5131d$a9162fb0$020aa8c0@wwm1> Date: Tue, 15 Feb 2005 13:17:32 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: Ambiguity in BLOCK semantics Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics The ambiguity is that if those three SETs were three DATARAWs, then the first would apply to entry 4, the second to entry 5, and the third to entry 6. Thus, changing the TLV used to hold the follow on information will change the semantics? (For an extreme case, suppose we had a PATH-DATA that meant "all". We probably need this to allow someone to set an entire LFB anyway. So now, if I use three DATARAWs it means one thing, and if I use three PATH-DATAs with path="all", it means something different?) [Weiming] In this case, I think should we only allow one PATH-DATA with the path='all'. If it has more than one PATH-DATA will 'all' path, it leads to an error, for it's duplicating. If it has three PATH-DATAs with individually path=index 4, index 5, and index 6, there will be no ambiguity. But I personall think the latter case should also be prohibited if the father PATH Selector has already selected the index 4, 5, and 6, because it is also a duplicating and will result in semantic confusion for nested PATH-DATA. I think in a tree structure formed by nested PATHs, the subpath will always inherit its father path rather than modify it so as to keep the whole path consistent. Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 03:18: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 DAA05220 for ; Tue, 15 Feb 2005 03:18:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0yFS-00063G-4V for forces-archive@IETF.ORG; Tue, 15 Feb 2005 03:39: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 <14.00F8DB9F@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 3:18:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57865062 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 03:17:58 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 03:17:58 -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 j1F8Ht8x014591; Tue, 15 Feb 2005 08:17:55 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 j1F8HsCC025353; Tue, 15 Feb 2005 08:17:55 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021500175423795 ; Tue, 15 Feb 2005 00:17:54 -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); Tue, 15 Feb 2005 00:17:54 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Multiple CEs talking to the same FE Thread-Index: AcUSwD/9BX04oegBT5eWdbe9LamADQAKzgkw X-OriginalArrivalTime: 15 Feb 2005 08:17:54.0577 (UTC) FILETIME=[D95BF010:01C51336] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 00:17:53 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Multiple CEs talking to the same FE Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable (hat off...) From a technical point of view, wouldn't it be sufficient for the process on the CE that is aggregating the multiple processes to just demux responses based on LFB ID? I.e. any replies regarding the firewalling LFB go to the CE firewall process, any replies regarding the routing table be directed to the CE routing process? -David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas > Sent: Monday, February 14, 2005 10:09 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Multiple CEs talking to the same FE >=20 > Coming back to implementation issues that fire up in the protocol: >=20 > In the case of a single active CE, there can be multiple processes=20 > "hiding" behind the same CE ID, i.e., a process updating firewalling=20 > rules and another process updating the routing table, in parallel. We=20 > must be able to: >=20 > 1) correlate at the CE the responses from the FE with the=20 > commands that=20 > were originated by each process. > 2) forward at the CE FE-event notifications to the appropriate=20 > processes that registered for it. >=20 > So if the CE ID is the same for all these processes, something is=20 > missing in the protocol to support 1) and 2) ... Unless the=20 > ForCES PL=20 > decides to use different TCP/UDP ports for each process (I wouldn't=20 > recommend this), but this will anyway not solve 2). >=20 > BTW, the multi-CE problem is something one should still think=20 > of while=20 > defining the model. Although the requirements draft only talks of a=20 > single active CE for each FE, it is a scalability issue if I=20 > can't run=20 > the firewalling and routing processes on two different boxes=20 > (i.e. two=20 > CEs). So let's at least consider the impact of the=20 > multi-manager problem=20 > on the model so we don't close all the doors for future support. >=20 > Regards, > -Robert >=20 > Joel M. Halpern wrote: >=20 > > I thought we had agreed that for now we would focus on a=20 > single active=20 > > CE per FE> An FE that wants to be managed by several CEs is (I=20 > > thought) to pretend it is several FEs, probably with=20 > distinct resources. > > > > The multi-manager problem is very very messy. > > > > The demultiplexing is a valid issue anyway. I think that=20 > the answer=20 > > is probably that one should use different ports if one is=20 > going to run=20 > > several CEs (or FEs) on the same machine / interface. I am=20 > not sure=20 > > we can / should introduce an extra demux layer for the "native=20 > > ethernet transport" case. > > > > Yours, > > Joel > > > > At 11:25 AM 1/12/2005, Robert Haas wrote: > > > >> Here are some considerations around many CEs talking to=20 > 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,=20 > QoS. These CEs=20 > >> may each run in a separate machine, or they may share the same=20 > >> machine. So there is an association for each (CE-FE) pair.=20 > Or do we=20 > >> consider associations to include more than two members ? Note that=20 > >> multiple associations may share the same TCP/SCTP/... connection. > >> > >> Demultiplexing: Note that in the case where multiple CEs=20 > run on the=20 > >> same machine, the CE ID can be viewed as a demultiplexor.=20 > The ForCES=20 > >> protocol does not otherwise include correlators that would enable=20 > >> callbacks to the appropriate CE on the response to a=20 > ForCES command=20 > >> (or reception of an event). > >> > >> Access conflicts: The framework draft specifies that CE=20 > >> synchronization is beyond the scope of ForCES. This means=20 > that, for=20 > >> instance, two CEs changing the same LFB attribute value, is not=20 > >> viewed at the ForCES level as a conflict. But if two CEs try to=20 > >> perform interleaved 2-phase commit operations on the same=20 > attribute,=20 > >> then ForCES should of course prevent it and report it. > >> > >> Event reporting: If multiple CEs subscribe to different=20 > events in an=20 > >> LFB, then the LFB must somehow know to which CE(s) events must be=20 > >> fired. I propose that a list of interested CE IDs is=20 > associated with=20 > >> each event 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 =20 > http://www.zurich.ibm.com/~rha > > > > > > >=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 =20 > http://www.zurich.ibm.com/~rha >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 10:17:04 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 KAA10327 for ; Tue, 15 Feb 2005 10:17:03 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14ml-0007FD-7O for forces-archive@IETF.ORG; Tue, 15 Feb 2005 10:38:51 -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 <22.00F8EBB0@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 10:16:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57925594 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:16:55 -0500 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 10:16:55 -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 j1FFGtmV098012 for ; Tue, 15 Feb 2005 15:16:55 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1FFGsDK155944 for ; Tue, 15 Feb 2005 16:16:54 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1FFGsqB028203 for ; Tue, 15 Feb 2005 16:16:54 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1FFGrka028190; Tue, 15 Feb 2005 16:16:54 +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 QAA64776; Tue, 15 Feb 2005 16:16:53 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id j1FFGtmV098012 Approved-By: Robert Haas Message-ID: <42121264.3010607@zurich.ibm.com> Date: Tue, 15 Feb 2005 16:16:52 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: quoted-printable Putzolu, David wrote: >(hat off...) > > =20 > That's a very polite (although fallen into disuse) way to greet someone ;= -) >>From a technical point of view, wouldn't it be sufficient >for the process on the CE that is aggregating the multiple >processes to just demux responses based on LFB ID? I.e. >any replies regarding the firewalling LFB go to the CE >firewall process, any replies regarding the routing table >be directed to the CE routing process? > =20 > This would not always work: both firewalling and routing processes may=20 want to query information from the same LFB (say, the port LFB). Regards, -Robert >-David > > =20 > >>-----Original Message----- >>From: Forwarding and Control Element Separation=20 >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>Sent: Monday, February 14, 2005 10:09 AM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: Re: [FORCES] Multiple CEs talking to the same FE >> >>Coming back to implementation issues that fire up in the protocol: >> >>In the case of a single active CE, there can be multiple processes=20 >>"hiding" behind the same CE ID, i.e., a process updating firewalling=20 >>rules and another process updating the routing table, in parallel. We=20 >>must be able to: >> >>1) correlate at the CE the responses from the FE with the=20 >>commands that=20 >>were originated by each process. >>2) forward at the CE FE-event notifications to the appropriate=20 >>processes that registered for it. >> >>So if the CE ID is the same for all these processes, something is=20 >>missing in the protocol to support 1) and 2) ... Unless the=20 >>ForCES PL=20 >>decides to use different TCP/UDP ports for each process (I wouldn't=20 >>recommend this), but this will anyway not solve 2). >> >>BTW, the multi-CE problem is something one should still think=20 >>of while=20 >>defining the model. Although the requirements draft only talks of a=20 >>single active CE for each FE, it is a scalability issue if I=20 >>can't run=20 >>the firewalling and routing processes on two different boxes=20 >>(i.e. two=20 >>CEs). So let's at least consider the impact of the=20 >>multi-manager problem=20 >>on the model so we don't close all the doors for future support. >> >>Regards, >>-Robert >> >>Joel M. Halpern wrote: >> >> =20 >> >>>I thought we had agreed that for now we would focus on a=20 >>> =20 >>> >>single active=20 >> =20 >> >>>CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>thought) to pretend it is several FEs, probably with=20 >>> =20 >>> >>distinct resources. >> =20 >> >>>The multi-manager problem is very very messy. >>> >>>The demultiplexing is a valid issue anyway. I think that=20 >>> =20 >>> >>the answer=20 >> =20 >> >>>is probably that one should use different ports if one is=20 >>> =20 >>> >>going to run=20 >> =20 >> >>>several CEs (or FEs) on the same machine / interface. I am=20 >>> =20 >>> >>not sure=20 >> =20 >> >>>we can / should introduce an extra demux layer for the "native=20 >>>ethernet transport" case. >>> >>>Yours, >>>Joel >>> >>>At 11:25 AM 1/12/2005, Robert Haas wrote: >>> >>> =20 >>> >>>>Here are some considerations around many CEs talking to=20 >>>> =20 >>>> >>the same FE,=20 >> =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,=20 >>>> =20 >>>> >>QoS. These CEs=20 >> =20 >> >>>>may each run in a separate machine, or they may share the same=20 >>>>machine. So there is an association for each (CE-FE) pair.=20 >>>> =20 >>>> >>Or do we=20 >> =20 >> >>>>consider associations to include more than two members ? Note that=20 >>>>multiple associations may share the same TCP/SCTP/... connection. >>>> >>>>Demultiplexing: Note that in the case where multiple CEs=20 >>>> =20 >>>> >>run on the=20 >> =20 >> >>>>same machine, the CE ID can be viewed as a demultiplexor.=20 >>>> =20 >>>> >>The ForCES=20 >> =20 >> >>>>protocol does not otherwise include correlators that would enable=20 >>>>callbacks to the appropriate CE on the response to a=20 >>>> =20 >>>> >>ForCES command=20 >> =20 >> >>>>(or reception of an event). >>>> >>>>Access conflicts: The framework draft specifies that CE=20 >>>>synchronization is beyond the scope of ForCES. This means=20 >>>> =20 >>>> >>that, for=20 >> =20 >> >>>>instance, two CEs changing the same LFB attribute value, is not=20 >>>>viewed at the ForCES level as a conflict. But if two CEs try to=20 >>>>perform interleaved 2-phase commit operations on the same=20 >>>> =20 >>>> >>attribute,=20 >> =20 >> >>>>then ForCES should of course prevent it and report it. >>>> >>>>Event reporting: If multiple CEs subscribe to different=20 >>>> =20 >>>> >>events in an=20 >> =20 >> >>>>LFB, then the LFB must somehow know to which CE(s) events must be=20 >>>>fired. I propose that a list of interested CE IDs is=20 >>>> =20 >>>> >>associated with=20 >> =20 >> >>>>each event 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 =20 >>>> =20 >>>> >>http://www.zurich.ibm.com/~rha >> =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 =20 >>http://www.zurich.ibm.com/~rha >> >> =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 Tue Feb 15 10:20: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 KAA10666 for ; Tue, 15 Feb 2005 10:20:09 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14pn-0007IZ-1Q for forces-archive@IETF.ORG; Tue, 15 Feb 2005 10:41:58 -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 <22.00F8EBCD@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 10:20:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57926164 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:20:04 -0500 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 10:19:44 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j1FFJhKb122612 for ; Tue, 15 Feb 2005 15:19:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1FFJhuj084412 for ; Tue, 15 Feb 2005 15:19:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1FFJhNh010061 for ; Tue, 15 Feb 2005 15:19:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1FFJgw5010055; Tue, 15 Feb 2005 15:19:42 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 QAA102404; Tue, 15 Feb 2005 16:19:42 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.uk.ibm.com id j1FFJhKb122612 Approved-By: Robert Haas Message-ID: <4212130D.4040601@zurich.ibm.com> Date: Tue, 15 Feb 2005 16:19:41 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Hormuzd, Khosravi, Hormuzd M wrote: >Robert, > >My comments on this inline....=20 > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas > >Coming back to implementation issues that fire up in the protocol: > >In the case of a single active CE, there can be multiple processes=20 >"hiding" behind the same CE ID, i.e., a process updating firewalling=20 >rules and another process updating the routing table, in parallel. We=20 >must be able to: > >1) correlate at the CE the responses from the FE with the commands that=20 >were originated by each process. >2) forward at the CE FE-event notifications to the appropriate=20 >processes that registered for it. > >So if the CE ID is the same for all these processes, something is=20 >missing in the protocol to support 1) and 2) ... Unless the ForCES PL=20 >decides to use different TCP/UDP ports for each process (I wouldn't=20 >recommend this), but this will anyway not solve 2). > >[HK] This is more of an implementation issue than a protocol issue in my >opinion. You could have the ForCES protocol daemon demuxing between >different processes using a shim layer with standard IPC. The shim layer >would take care of translating requests from different processes to >different ForCES protocol message types, sequence nos, etc. Let me know >if this sounds reasonable or I am missing something here? > =20 > How far did you go with your implementation of demuxing ? In our case,=20 we found that relying on sequence numbers or message types is not useful=20 when you want to direct an event notification coming from the FE to the=20 appropriate process in the CE. But maybe you found a way to solve that ? I hope that with our implementations we will find not only=20 implementation issues, but protocol issues too. I doubt we can get the=20 protocol right on the first shot. > >BTW, the multi-CE problem is something one should still think of while=20 >defining the model. Although the requirements draft only talks of a=20 >single active CE for each FE, it is a scalability issue if I can't run=20 >the firewalling and routing processes on two different boxes (i.e. two=20 >CEs). So let's at least consider the impact of the multi-manager problem > >on the model so we don't close all the doors for future support. > >[HK] I agree with Joel on this. I believe this is something which can be >addresses in a later rev of the protocol draft. We should focus on >getting the basic protocol messages/encoding correct at this point. That >itself is not a straight forward task cause of the many tradeoffs. We >can come back to the multi-CE issue in the next version of the protocol. > > =20 > I would treat this the same way we treated the keys: make provision for=20 multi-CE support in the model as early as possible as it may otherwise=20 become more difficult to include it later. For instance, whenever CEs register for events: the model should not=20 only indicate with a boolean if a CE has registered to be notified when=20 the event occurs, but also include a list of the CEs that have=20 registered for the same event. Limited complexity for the model, almost=20 no additional complexity for the protocol. Regards, -Robert >Regards >Hormuzd > >Joel M. Halpern wrote: > > =20 > >>I thought we had agreed that for now we would focus on a single active >> =20 >> > > =20 > >>CE per FE> An FE that wants to be managed by several CEs is (I=20 >>thought) to pretend it is several FEs, probably with distinct >> =20 >> >resources. > =20 > >>The multi-manager problem is very very messy. >> >> =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 Tue Feb 15 10:29: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 KAA12821 for ; Tue, 15 Feb 2005 10:29:40 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14yw-0007lx-Px for forces-archive@IETF.ORG; Tue, 15 Feb 2005 10:51: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 <1.00F8EC29@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 10:29:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57927021 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:29:24 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 10:29:24 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9197534 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:29:22 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <42121264.3010607@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050215102737.0320bed8@localhost> Date: Tue, 15 Feb 2005 10:29:02 -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: <42121264.3010607@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable It would seem to me that from the design point we are working, if two=20 components want to work with the same LFB then they will need close=20 coordination anyway. So a dispatch mechanism, while convenient, is not a=20 large benefit to the application. And it adds complexity to the protocol=20 just for that special case. Yours, Joel At 10:16 AM 2/15/2005, Robert Haas wrote: >Putzolu, David wrote: > >>(hat off...) >> >> >That's a very polite (although fallen into disuse) way to greet someone ;-) > >> From a technical point of view, wouldn't it be sufficient >>for the process on the CE that is aggregating the multiple >>processes to just demux responses based on LFB ID? I.e. >>any replies regarding the firewalling LFB go to the CE >>firewall process, any replies regarding the routing table >>be directed to the CE routing process? >> >This would not always work: both firewalling and routing processes may=20 >want to query information from the same LFB (say, the port LFB). > > >Regards, >-Robert > > >>-David >> >> >> >>>-----Original Message----- >>>From: Forwarding and Control Element Separation=20 >>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>>Sent: Monday, February 14, 2005 10:09 AM >>>To: FORCES@PEACH.EASE.LSOFT.COM >>>Subject: Re: [FORCES] Multiple CEs talking to the same FE >>> >>>Coming back to implementation issues that fire up in the protocol: >>> >>>In the case of a single active CE, there can be multiple processes=20 >>>"hiding" behind the same CE ID, i.e., a process updating firewalling=20 >>>rules and another process updating the routing table, in parallel. We=20 >>>must be able to: >>> >>>1) correlate at the CE the responses from the FE with the commands that= =20 >>>were originated by each process. >>>2) forward at the CE FE-event notifications to the appropriate=20 >>>processes that registered for it. >>> >>>So if the CE ID is the same for all these processes, something is=20 >>>missing in the protocol to support 1) and 2) ... Unless the ForCES PL=20 >>>decides to use different TCP/UDP ports for each process (I wouldn't=20 >>>recommend this), but this will anyway not solve 2). >>> >>>BTW, the multi-CE problem is something one should still think of while=20 >>>defining the model. Although the requirements draft only talks of a=20 >>>single active CE for each FE, it is a scalability issue if I can't run=20 >>>the firewalling and routing processes on two different boxes (i.e. two=20 >>>CEs). So let's at least consider the impact of the multi-manager problem= =20 >>>on the model so we don't close all the doors for future support. >>> >>>Regards, >>>-Robert >>> >>>Joel M. Halpern wrote: >>> >>> >>> >>>>I thought we had agreed that for now we would focus on a >>>single active >>> >>>>CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>>thought) to 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 probably that one should use different ports if one is >>>going to run >>> >>>>several CEs (or FEs) on the same machine / interface. I am >>>not sure >>> >>>>we can / should introduce an extra demux layer for the "native ethernet= =20 >>>>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 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 each run in a separate machine, or they may share the same=20 >>>>>machine. So there is an association for each (CE-FE) pair. >>>Or do we >>> >>>>>consider associations to include more than two members ? Note that=20 >>>>>multiple associations may share the same TCP/SCTP/... connection. >>>>> >>>>>Demultiplexing: Note that in the case where multiple CEs >>>run on the >>> >>>>>same machine, the CE ID can be viewed as a demultiplexor. >>>The ForCES >>> >>>>>protocol does not otherwise include correlators that would enable=20 >>>>>callbacks to the appropriate CE on the response to a >>>ForCES command >>> >>>>>(or reception of an event). >>>>> >>>>>Access conflicts: The framework draft specifies that CE=20 >>>>>synchronization is beyond the scope of ForCES. This means >>>that, for >>> >>>>>instance, two CEs changing the same LFB attribute value, is not viewed= =20 >>>>>at the ForCES level as a conflict. But if two CEs try to perform=20 >>>>>interleaved 2-phase commit operations on the same >>>attribute, >>> >>>>>then ForCES should of course prevent it and report it. >>>>> >>>>>Event reporting: If multiple CEs subscribe to different >>>events in an >>> >>>>>LFB, then the LFB must somehow know to which CE(s) events must be=20 >>>>>fired. I propose that a list of interested CE IDs is >>>associated with >>> >>>>>each event 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 >>> >>> >>>> >>>> >>>-- 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 >>> >>> >> >> >> > >-- >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 Feb 15 10:31:29 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 KAA13374 for ; Tue, 15 Feb 2005 10:31:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D150n-0007tQ-5K for forces-archive@IETF.ORG; Tue, 15 Feb 2005 10:53:18 -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.00F8EB51@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 10:31:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57927549 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:31:19 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 10:31:19 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9197582 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 10:31:18 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050215102940.0320bc48@localhost> Date: Tue, 15 Feb 2005 10:31:00 -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: <4212130D.4040601@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I am missing something. The event description I sent to the list had only the boolean. Neither the protocol nor the model have any notion of multiple CEs talking to the FE. Hence a list of CEs would not make a lot of sense to either entity. And since the protocol does not have support for talking to multiple CEs simultaneously, a list of CEs would in fact invite a non-supportable behavior. Yours, Joel M. Halpern At 10:19 AM 2/15/2005, Robert Haas wrote: >For instance, whenever CEs register for events: the model should not only >indicate with a boolean if a CE has registered to be notified when the >event occurs, but also include a list of the CEs that have registered for >the same event. Limited complexity for the model, almost no additional >complexity for the protocol. From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 11:12: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 LAA26975 for ; Tue, 15 Feb 2005 11:12:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15ej-0003Zh-6m for forces-archive@IETF.ORG; Tue, 15 Feb 2005 11:34: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 <14.00F8EC70@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 11:12:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57931354 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 11:12:43 -0500 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 11:12:22 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j1FGCMlI050878 for ; Tue, 15 Feb 2005 16:12:22 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1FGCL35127546 for ; Tue, 15 Feb 2005 16:12:21 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 j1FGCLhq020711 for ; Tue, 15 Feb 2005 16:12:21 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 j1FGCLUd020696; Tue, 15 Feb 2005 16:12:21 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 RAA90506; Tue, 15 Feb 2005 17:12:20 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> <6.2.1.2.0.20050215102940.0320bc48@localhost> 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 j1FGCMlI050878 Approved-By: Robert Haas Message-ID: <42121F64.90604@zurich.ibm.com> Date: Tue, 15 Feb 2005 17:12:20 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050215102940.0320bc48@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > I am missing something. > The event description I sent to the list had only the boolean. > Neither the protocol nor the model have any notion of multiple CEs=20 > talking to the FE. That's indeed the current (limited) view, I did not try to imply the=20 opposite. > Hence a list of CEs would not make a lot of sense to either entity. At this stage, I agree. But this can change in the future. IMHO, I doubt=20 operators will like the monolithic approach of a single active CE per=20 FE, although it would already be a substantial improvement to the=20 current proprietary situation. > And since the protocol does not have support for talking to multiple=20 > CEs simultaneously, a list of CEs would in fact invite a=20 > non-supportable behavior. Currently, nothing in the protocol prevents an FE from setting up=20 multiple associations, one for each CE. It is mostly a modelling issue. Regards, -Robert > > Yours, > Joel M. Halpern > > At 10:19 AM 2/15/2005, Robert Haas wrote: > >> For instance, whenever CEs register for events: the model should not=20 >> only indicate with a boolean if a CE has registered to be notified=20 >> when the event occurs, but also include a list of the CEs that have=20 >> registered for the same event. Limited complexity for the model,=20 >> almost no additional complexity for the protocol. > > > --=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 Feb 15 11:13: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 LAA27034 for ; Tue, 15 Feb 2005 11:13:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15f2-0003as-RF for forces-archive@IETF.ORG; Tue, 15 Feb 2005 11:34: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 <10.00F8EE5F@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 11:13:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57931347 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 11:12:43 -0500 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 11:12:20 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j1FGCKvK114396 for ; Tue, 15 Feb 2005 16:12:20 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1FGCJ9Q138222 for ; Tue, 15 Feb 2005 17:12:19 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1FGCJt1024368 for ; Tue, 15 Feb 2005 17:12:19 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j1FGCJKN024339; Tue, 15 Feb 2005 17:12:19 +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 RAA85182; Tue, 15 Feb 2005 17:12:18 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42121264.3010607@zurich.ibm.com> <6.2.1.2.0.20050215102737.0320bed8@localhost> 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.de.ibm.com id j1FGCKvK114396 Approved-By: Robert Haas Message-ID: <42121F60.10705@zurich.ibm.com> Date: Tue, 15 Feb 2005 17:12:16 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050215102737.0320bed8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > It would seem to me that from the design point we are working, if two=20 > components want to work with the same LFB then they will need close=20 > coordination anyway. How this coordination is implemented (such as a layer above ForCES that=20 ensures coordination among actions performed by various=20 processes/applications, or sth else) is beyond the ForCES protocol=20 specification. An FE will obey to all commands issued by a given CE ID,=20 even if it means contradicting operations issued by applications that=20 are badly synchronized/configured/coded. I do not want to hide that in my mind, in the case of multi-CEs (but not=20 in the case of multi-processes behind the same CE), the FE could=20 implement simple mechanisms to avoid such contradicting operations. For=20 instance, SET operations to any given LFB would only be allowed from one=20 CE. But all CEs could query all LFBs or subscribe to all events, as this=20 would not cause inconsistencies. > So a dispatch mechanism, while convenient, is not a large benefit to=20 > the application. And it adds complexity to the protocol just for that=20 > special case. I argue that correlators would be very useful even to the "coordination=20 layer" too, if not directly to the applications/processes running in the = CE. That's because the coordination layer anyway has to decide which=20 application/process should it send an event upon receing a notification=20 from the FE. And there could be more than one application interested in=20 notifications when security events occur. Regards, -Robert > > Yours, > Joel > > At 10:16 AM 2/15/2005, Robert Haas wrote: > >> Putzolu, David wrote: >> >>> (hat off...) >>> >>> >> That's a very polite (although fallen into disuse) way to greet=20 >> someone ;-) >> >>> From a technical point of view, wouldn't it be sufficient >>> for the process on the CE that is aggregating the multiple >>> processes to just demux responses based on LFB ID? I.e. >>> any replies regarding the firewalling LFB go to the CE >>> firewall process, any replies regarding the routing table >>> be directed to the CE routing process? >>> >> This would not always work: both firewalling and routing processes=20 >> may want to query information from the same LFB (say, the port LFB). >> >> >> Regards, >> -Robert >> >> >>> -David >>> >>> >>> >>>> -----Original Message----- >>>> From: Forwarding and Control Element Separation=20 >>>> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>>> Sent: Monday, February 14, 2005 10:09 AM >>>> To: FORCES@PEACH.EASE.LSOFT.COM >>>> Subject: Re: [FORCES] Multiple CEs talking to the same FE >>>> >>>> Coming back to implementation issues that fire up in the protocol: >>>> >>>> In the case of a single active CE, there can be multiple processes=20 >>>> "hiding" behind the same CE ID, i.e., a process updating=20 >>>> firewalling rules and another process updating the routing table,=20 >>>> in parallel. We must be able to: >>>> >>>> 1) correlate at the CE the responses from the FE with the commands=20 >>>> that were originated by each process. >>>> 2) forward at the CE FE-event notifications to the appropriate=20 >>>> processes that registered for it. >>>> >>>> So if the CE ID is the same for all these processes, something is=20 >>>> missing in the protocol to support 1) and 2) ... Unless the ForCES=20 >>>> PL decides to use different TCP/UDP ports for each process (I=20 >>>> wouldn't recommend this), but this will anyway not solve 2). >>>> >>>> BTW, the multi-CE problem is something one should still think of=20 >>>> while defining the model. Although the requirements draft only=20 >>>> talks of a single active CE for each FE, it is a scalability issue=20 >>>> if I can't run the firewalling and routing processes on two=20 >>>> different boxes (i.e. two CEs). So let's at least consider the=20 >>>> impact of the multi-manager problem on the model so we don't close=20 >>>> all the doors for future support. >>>> >>>> Regards, >>>> -Robert >>>> >>>> Joel M. Halpern wrote: >>>> >>>> >>>> >>>>> I thought we had agreed that for now we would focus on a >>>> >>>> single active >>>> >>>>> CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>>> thought) to 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 probably that one should use different ports if one is >>>> >>>> going to run >>>> >>>>> several CEs (or FEs) on the same machine / interface. I am >>>> >>>> not sure >>>> >>>>> we can / should introduce an extra demux layer for the "native=20 >>>>> 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 on early implementation experience: >>>>>> >>>>>> Associations: Multiple CEs may access the same FE, for instance=20 >>>>>> to accomplish different tasks, such as routing, security, >>>>> >>>> QoS. These CEs >>>> >>>>>> may each run in a separate machine, or they may share the same=20 >>>>>> machine. So there is an association for each (CE-FE) pair. >>>>> >>>> Or do we >>>> >>>>>> consider associations to include more than two members ? Note=20 >>>>>> that multiple associations may share the same TCP/SCTP/...=20 >>>>>> connection. >>>>>> >>>>>> Demultiplexing: Note that in the case where multiple CEs >>>>> >>>> run on the >>>> >>>>>> same machine, the CE ID can be viewed as a demultiplexor. >>>>> >>>> The ForCES >>>> >>>>>> protocol does not otherwise include correlators that would enable=20 >>>>>> callbacks to the appropriate CE on the response to a >>>>> >>>> ForCES command >>>> >>>>>> (or reception of an event). >>>>>> >>>>>> Access conflicts: The framework draft specifies that CE=20 >>>>>> synchronization is beyond the scope of ForCES. This means >>>>> >>>> that, for >>>> >>>>>> instance, two CEs changing the same LFB attribute value, is not=20 >>>>>> viewed at the ForCES level as a conflict. But if two CEs try to=20 >>>>>> perform interleaved 2-phase commit operations on the same >>>>> >>>> attribute, >>>> >>>>>> then ForCES should of course prevent it and report it. >>>>>> >>>>>> Event reporting: If multiple CEs subscribe to different >>>>> >>>> events in an >>>> >>>>>> LFB, then the LFB must somehow know to which CE(s) events must be=20 >>>>>> fired. I propose that a list of interested CE IDs is >>>>> >>>> associated with >>>> >>>>>> each event 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 >>>> >>>> >>>>> >>>>> >>>> -- 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 >>>> >>>> >>> >>> >>> >> >> --=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/~r= ha > > > --=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 Feb 15 11:32: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 LAA01510 for ; Tue, 15 Feb 2005 11:32:57 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15yE-00051y-7n for forces-archive@IETF.ORG; Tue, 15 Feb 2005 11:54: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 <18.00F8EC86@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 11:32:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57933504 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 11:32:50 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 11:32:50 -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 j1FGWn8U016647; Tue, 15 Feb 2005 16:32:49 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 j1FGW8Ce022864; Tue, 15 Feb 2005 16:32:49 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021508324805414 ; Tue, 15 Feb 2005 08:32:48 -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); Tue, 15 Feb 2005 08:32:48 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Multiple CEs talking to the same FE Thread-Index: AcUTeTIgzNOmpO5rSJq0Gtp0w44x6gAAegnQ X-OriginalArrivalTime: 15 Feb 2005 16:32:48.0780 (UTC) FILETIME=[FC7BBCC0:01C5137B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 08:32:46 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Multiple CEs talking to the same FE Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable (hat off :) I don't believe there are any "simple" mechanisms to avoid contradiction in the multi-master scenario. Only allowing=20 certain operations from certain CEs amounts to a capability system (ala Dennis & Van Horn). It is a well known (and 40 year old!) approach but would add a lot of implementation=20 complexity. Going back to the original example of a CE that has two processes that want to read the same LFB, why not demux the read on the CE? This pushes complexity to the CE and saves on both wire protocol complexity and bandwidth, which is the preferred approach. Cheers, David -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Tuesday, February 15, 2005 8:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Multiple CEs talking to the same FE Joel M. Halpern wrote: > It would seem to me that from the design point we are working, if two=20 > components want to work with the same LFB then they will need close=20 > coordination anyway. How this coordination is implemented (such as a layer above ForCES that=20 ensures coordination among actions performed by various=20 processes/applications, or sth else) is beyond the ForCES protocol=20 specification. An FE will obey to all commands issued by a given CE ID,=20 even if it means contradicting operations issued by applications that=20 are badly synchronized/configured/coded. I do not want to hide that in my mind, in the case of multi-CEs (but not = in the case of multi-processes behind the same CE), the FE could=20 implement simple mechanisms to avoid such contradicting operations. For=20 instance, SET operations to any given LFB would only be allowed from one = CE. But all CEs could query all LFBs or subscribe to all events, as this = would not cause inconsistencies. > So a dispatch mechanism, while convenient, is not a large benefit to = > the application. And it adds complexity to the protocol just for that = > special case. I argue that correlators would be very useful even to the "coordination=20 layer" too, if not directly to the applications/processes running in the = CE. That's because the coordination layer anyway has to decide which=20 application/process should it send an event upon receing a notification=20 from the FE. And there could be more than one application interested in=20 notifications when security events occur. Regards, -Robert > > Yours, > Joel > > At 10:16 AM 2/15/2005, Robert Haas wrote: > >> Putzolu, David wrote: >> >>> (hat off...) >>> >>> >> That's a very polite (although fallen into disuse) way to greet=20 >> someone ;-) >> >>> From a technical point of view, wouldn't it be sufficient >>> for the process on the CE that is aggregating the multiple >>> processes to just demux responses based on LFB ID? I.e. >>> any replies regarding the firewalling LFB go to the CE >>> firewall process, any replies regarding the routing table >>> be directed to the CE routing process? >>> >> This would not always work: both firewalling and routing processes=20 >> may want to query information from the same LFB (say, the port LFB). >> >> >> Regards, >> -Robert >> >> >>> -David >>> >>> >>> >>>> -----Original Message----- >>>> From: Forwarding and Control Element Separation=20 >>>> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>>> Sent: Monday, February 14, 2005 10:09 AM >>>> To: FORCES@PEACH.EASE.LSOFT.COM >>>> Subject: Re: [FORCES] Multiple CEs talking to the same FE >>>> >>>> Coming back to implementation issues that fire up in the protocol: >>>> >>>> In the case of a single active CE, there can be multiple processes=20 >>>> "hiding" behind the same CE ID, i.e., a process updating=20 >>>> firewalling rules and another process updating the routing table,=20 >>>> in parallel. We must be able to: >>>> >>>> 1) correlate at the CE the responses from the FE with the commands=20 >>>> that were originated by each process. >>>> 2) forward at the CE FE-event notifications to the appropriate=20 >>>> processes that registered for it. >>>> >>>> So if the CE ID is the same for all these processes, something is=20 >>>> missing in the protocol to support 1) and 2) ... Unless the ForCES = >>>> PL decides to use different TCP/UDP ports for each process (I=20 >>>> wouldn't recommend this), but this will anyway not solve 2). >>>> >>>> BTW, the multi-CE problem is something one should still think of=20 >>>> while defining the model. Although the requirements draft only=20 >>>> talks of a single active CE for each FE, it is a scalability issue=20 >>>> if I can't run the firewalling and routing processes on two=20 >>>> different boxes (i.e. two CEs). So let's at least consider the=20 >>>> impact of the multi-manager problem on the model so we don't close=20 >>>> all the doors for future support. >>>> >>>> Regards, >>>> -Robert >>>> >>>> Joel M. Halpern wrote: >>>> >>>> >>>> >>>>> I thought we had agreed that for now we would focus on a >>>> >>>> single active >>>> >>>>> CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>>> thought) to 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 probably that one should use different ports if one is >>>> >>>> going to run >>>> >>>>> several CEs (or FEs) on the same machine / interface. I am >>>> >>>> not sure >>>> >>>>> we can / should introduce an extra demux layer for the "native=20 >>>>> 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 on early implementation experience: >>>>>> >>>>>> Associations: Multiple CEs may access the same FE, for instance=20 >>>>>> to accomplish different tasks, such as routing, security, >>>>> >>>> QoS. These CEs >>>> >>>>>> may each run in a separate machine, or they may share the same=20 >>>>>> machine. So there is an association for each (CE-FE) pair. >>>>> >>>> Or do we >>>> >>>>>> consider associations to include more than two members ? Note=20 >>>>>> that multiple associations may share the same TCP/SCTP/...=20 >>>>>> connection. >>>>>> >>>>>> Demultiplexing: Note that in the case where multiple CEs >>>>> >>>> run on the >>>> >>>>>> same machine, the CE ID can be viewed as a demultiplexor. >>>>> >>>> The ForCES >>>> >>>>>> protocol does not otherwise include correlators that would enable = >>>>>> callbacks to the appropriate CE on the response to a >>>>> >>>> ForCES command >>>> >>>>>> (or reception of an event). >>>>>> >>>>>> Access conflicts: The framework draft specifies that CE=20 >>>>>> synchronization is beyond the scope of ForCES. This means >>>>> >>>> that, for >>>> >>>>>> instance, two CEs changing the same LFB attribute value, is not=20 >>>>>> viewed at the ForCES level as a conflict. But if two CEs try to=20 >>>>>> perform interleaved 2-phase commit operations on the same >>>>> >>>> attribute, >>>> >>>>>> then ForCES should of course prevent it and report it. >>>>>> >>>>>> Event reporting: If multiple CEs subscribe to different >>>>> >>>> events in an >>>> >>>>>> LFB, then the LFB must somehow know to which CE(s) events must be = >>>>>> fired. I propose that a list of interested CE IDs is >>>>> >>>> associated with >>>> >>>>>> each event 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 >>>> >>>> >>>>> >>>>> >>>> -- 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 >>>> >>>> >>> >>> >>> >> >> --=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 > > > --=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 Feb 15 11:45: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 LAA05749 for ; Tue, 15 Feb 2005 11:45:54 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D16Ap-0006OH-3A for forces-archive@IETF.ORG; Tue, 15 Feb 2005 12:07: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 <11.00F8EDEC@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 11:45:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57934446 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 11:45:53 -0500 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 11:45:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j1FGjq1k093906 for ; Tue, 15 Feb 2005 16:45:52 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 j1FGjqDK144146 for ; Tue, 15 Feb 2005 17:45:52 +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 j1FGjprh005797 for ; Tue, 15 Feb 2005 17:45:51 +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 j1FGjpZX005783; Tue, 15 Feb 2005 17:45:51 +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 RAA85014; Tue, 15 Feb 2005 17:45:50 +0100 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: 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.de.ibm.com id j1FGjq1k093906 Approved-By: Robert Haas Message-ID: <4212273D.3090807@zurich.ibm.com> Date: Tue, 15 Feb 2005 17:45:49 +0100 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: Multiple CEs talking to the same FE Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: quoted-printable Putzolu, David wrote: >(hat off :) > >I don't believe there are any "simple" mechanisms to avoid >contradiction in the multi-master scenario. > I understand that the simple mechanism I suggested would not be=20 sufficient, but somehow necessary. The rest belongs to CE-CE=20 communication which we don't cover (for now). > Only allowing=20 >certain operations from certain CEs amounts to a capability >system (ala Dennis & Van Horn). It is a well known (and 40 >year old!) approach but would add a lot of implementation=20 >complexity. > >Going back to the original example of a CE that has two >processes that want to read the same LFB, why not demux >the read on the CE? > Could you please elaborate what you mean ? I think a concrete example=20 could help. Regards, -Robert > This pushes complexity to the CE >and saves on both wire protocol complexity and bandwidth, >which is the preferred approach. > >Cheers, >David > > >-----Original Message----- >From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EAS= E.LSOFT.COM] On Behalf Of Robert Haas >Sent: Tuesday, February 15, 2005 8:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] Multiple CEs talking to the same FE > >Joel M. Halpern wrote: > > =20 > >>It would seem to me that from the design point we are working, if two=20 >>components want to work with the same LFB then they will need close=20 >>coordination anyway. >> =20 >> > >How this coordination is implemented (such as a layer above ForCES that=20 >ensures coordination among actions performed by various=20 >processes/applications, or sth else) is beyond the ForCES protocol=20 >specification. An FE will obey to all commands issued by a given CE ID,=20 >even if it means contradicting operations issued by applications that=20 >are badly synchronized/configured/coded. > >I do not want to hide that in my mind, in the case of multi-CEs (but not= =20 >in the case of multi-processes behind the same CE), the FE could=20 >implement simple mechanisms to avoid such contradicting operations. For=20 >instance, SET operations to any given LFB would only be allowed from one= =20 >CE. But all CEs could query all LFBs or subscribe to all events, as this= =20 >would not cause inconsistencies. > > =20 > >> So a dispatch mechanism, while convenient, is not a large benefit to=20 >>the application. And it adds complexity to the protocol just for that=20 >>special case. >> =20 >> > >I argue that correlators would be very useful even to the "coordination=20 >layer" too, if not directly to the applications/processes running in the= CE. >That's because the coordination layer anyway has to decide which=20 >application/process should it send an event upon receing a notification=20 >from the FE. And there could be more than one application interested in=20 >notifications when security events occur. > >Regards, >-Robert > > =20 > >>Yours, >>Joel >> >>At 10:16 AM 2/15/2005, Robert Haas wrote: >> >> =20 >> >>>Putzolu, David wrote: >>> >>> =20 >>> >>>>(hat off...) >>>> >>>> >>>> =20 >>>> >>>That's a very polite (although fallen into disuse) way to greet=20 >>>someone ;-) >>> >>> =20 >>> >>>>From a technical point of view, wouldn't it be sufficient >>>>for the process on the CE that is aggregating the multiple >>>>processes to just demux responses based on LFB ID? I.e. >>>>any replies regarding the firewalling LFB go to the CE >>>>firewall process, any replies regarding the routing table >>>>be directed to the CE routing process? >>>> >>>> =20 >>>> >>>This would not always work: both firewalling and routing processes=20 >>>may want to query information from the same LFB (say, the port LFB). >>> >>> >>>Regards, >>>-Robert >>> >>> >>> =20 >>> >>>>-David >>>> >>>> >>>> >>>> =20 >>>> >>>>>-----Original Message----- >>>>>From: Forwarding and Control Element Separation=20 >>>>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas >>>>>Sent: Monday, February 14, 2005 10:09 AM >>>>>To: FORCES@PEACH.EASE.LSOFT.COM >>>>>Subject: Re: [FORCES] Multiple CEs talking to the same FE >>>>> >>>>>Coming back to implementation issues that fire up in the protocol: >>>>> >>>>>In the case of a single active CE, there can be multiple processes=20 >>>>>"hiding" behind the same CE ID, i.e., a process updating=20 >>>>>firewalling rules and another process updating the routing table,=20 >>>>>in parallel. We must be able to: >>>>> >>>>>1) correlate at the CE the responses from the FE with the commands=20 >>>>>that were originated by each process. >>>>>2) forward at the CE FE-event notifications to the appropriate=20 >>>>>processes that registered for it. >>>>> >>>>>So if the CE ID is the same for all these processes, something is=20 >>>>>missing in the protocol to support 1) and 2) ... Unless the ForCES=20 >>>>>PL decides to use different TCP/UDP ports for each process (I=20 >>>>>wouldn't recommend this), but this will anyway not solve 2). >>>>> >>>>>BTW, the multi-CE problem is something one should still think of=20 >>>>>while defining the model. Although the requirements draft only=20 >>>>>talks of a single active CE for each FE, it is a scalability issue=20 >>>>>if I can't run the firewalling and routing processes on two=20 >>>>>different boxes (i.e. two CEs). So let's at least consider the=20 >>>>>impact of the multi-manager problem on the model so we don't close=20 >>>>>all the doors for future support. >>>>> >>>>>Regards, >>>>>-Robert >>>>> >>>>>Joel M. Halpern wrote: >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>>>I thought we had agreed that for now we would focus on a >>>>>> =20 >>>>>> >>>>>single active >>>>> >>>>> =20 >>>>> >>>>>>CE per FE> An FE that wants to be managed by several CEs is (I=20 >>>>>>thought) to pretend it is several FEs, probably with >>>>>> =20 >>>>>> >>>>>distinct resources. >>>>> >>>>> >>>>> =20 >>>>> >>>>>>The multi-manager problem is very very messy. >>>>>> >>>>>>The demultiplexing is a valid issue anyway. I think that >>>>>> =20 >>>>>> >>>>>the answer >>>>> >>>>> =20 >>>>> >>>>>>is probably that one should use different ports if one is >>>>>> =20 >>>>>> >>>>>going to run >>>>> >>>>> =20 >>>>> >>>>>>several CEs (or FEs) on the same machine / interface. I am >>>>>> =20 >>>>>> >>>>>not sure >>>>> >>>>> =20 >>>>> >>>>>>we can / should introduce an extra demux layer for the "native=20 >>>>>>ethernet transport" case. >>>>>> >>>>>>Yours, >>>>>>Joel >>>>>> >>>>>>At 11:25 AM 1/12/2005, Robert Haas wrote: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>>>Here are some considerations around many CEs talking to >>>>>>> =20 >>>>>>> >>>>>the same FE, >>>>> >>>>> =20 >>>>> >>>>>>>based on early implementation experience: >>>>>>> >>>>>>>Associations: Multiple CEs may access the same FE, for instance=20 >>>>>>>to accomplish different tasks, such as routing, security, >>>>>>> =20 >>>>>>> >>>>>QoS. These CEs >>>>> >>>>> =20 >>>>> >>>>>>>may each run in a separate machine, or they may share the same=20 >>>>>>>machine. So there is an association for each (CE-FE) pair. >>>>>>> =20 >>>>>>> >>>>>Or do we >>>>> >>>>> =20 >>>>> >>>>>>>consider associations to include more than two members ? Note=20 >>>>>>>that multiple associations may share the same TCP/SCTP/...=20 >>>>>>>connection. >>>>>>> >>>>>>>Demultiplexing: Note that in the case where multiple CEs >>>>>>> =20 >>>>>>> >>>>>run on the >>>>> >>>>> =20 >>>>> >>>>>>>same machine, the CE ID can be viewed as a demultiplexor. >>>>>>> =20 >>>>>>> >>>>>The ForCES >>>>> >>>>> =20 >>>>> >>>>>>>protocol does not otherwise include correlators that would enable=20 >>>>>>>callbacks to the appropriate CE on the response to a >>>>>>> =20 >>>>>>> >>>>>ForCES command >>>>> >>>>> =20 >>>>> >>>>>>>(or reception of an event). >>>>>>> >>>>>>>Access conflicts: The framework draft specifies that CE=20 >>>>>>>synchronization is beyond the scope of ForCES. This means >>>>>>> =20 >>>>>>> >>>>>that, for >>>>> >>>>> =20 >>>>> >>>>>>>instance, two CEs changing the same LFB attribute value, is not=20 >>>>>>>viewed at the ForCES level as a conflict. But if two CEs try to=20 >>>>>>>perform interleaved 2-phase commit operations on the same >>>>>>> =20 >>>>>>> >>>>>attribute, >>>>> >>>>> =20 >>>>> >>>>>>>then ForCES should of course prevent it and report it. >>>>>>> >>>>>>>Event reporting: If multiple CEs subscribe to different >>>>>>> =20 >>>>>>> >>>>>events in an >>>>> >>>>> =20 >>>>> >>>>>>>LFB, then the LFB must somehow know to which CE(s) events must be=20 >>>>>>>fired. I propose that a list of interested CE IDs is >>>>>>> =20 >>>>>>> >>>>>associated with >>>>> >>>>> =20 >>>>> >>>>>>>each event 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 >>>>>>> >>>>>>> =20 >>>>>>> >>>>>http://www.zurich.ibm.com/~rha >>>>> >>>>> >>>>> =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 >>>>> >>>>> >>>>> =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/~r= ha >>> =20 >>> >> >> =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 Tue Feb 15 17:46: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 RAA22804 for ; Tue, 15 Feb 2005 17:46:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1BoB-0004HK-Bl for forces-archive@IETF.ORG; Tue, 15 Feb 2005 18:08: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 <10.00F8FE0C@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 17:46:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57973586 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 17:46:47 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 17:46:47 -0500 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1D1BSu-00020M-FM for forces@peach.ease.lsoft.com; Tue, 15 Feb 2005 22:46:46 +0000 Received: from s86-5.nomadic.bris.ac.uk ([137.222.86.5] helo=een9174.een.bris.ac.uk) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1D1BSu-0001XH-6W for forces@peach.ease.lsoft.com; Tue, 15 Feb 2005 22:46:44 +0000 References: <4212273D.3090807@zurich.ibm.com> Originator-Info: login-token=Mulberry:01CGxVRm3RtrpArc6wNm7Sgq9AzstpSHrig6hF1s5qNmuayrE=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: Date: Tue, 15 Feb 2005 22:46:37 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: Multiple CEs talking to the same FE To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4212273D.3090807@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi All, I was out for a while but have just seen this thread. >> I don't believe there are any "simple" mechanisms to avoid >> contradiction in the multi-master scenario. I agree (did David write this?). We have a fairly complex case of 1 CE writing to the tables of collections of FEs already, which we can handle by established transactional tools. Now we make it more difficult by having collections of CEs writing to the tables of collections of FEs, some of which may belong to some of the CEs but not to others. Are there any scenarios for this situation? I don't think we can say it is implementation dependent, but we could say that the framework for such a situation and mechanisms to set it up (trust, capability, etc.) is outside the scope of ForCES? > I understand that the simple mechanism I suggested would not be > sufficient, but somehow necessary. The rest belongs to CE-CE > communication which we don't cover (for now). I am doubtful that the concept is supportable and that mechanisms could not be made reliable without signficant complexity. This isn't separation of switching from the control of switching any more. I don't expect my creditors (CEs) to coordinate debits from my account with me (also a CE but with a different business model) apart from authorising them once (which is the capability aspect); coordination is the bank's job as FE. Is this a reasonable analogy? >> Only allowing >> certain operations from certain CEs amounts to a capability >> system (ala Dennis & Van Horn). It is a well known (and 40 >> year old!) approach but would add a lot of implementation >> complexity. This only establishes the permission to do things, I think? This is necessary but it isn't a solution and I'm not sure it's specifically ForCES. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 19:05: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 TAA01574 for ; Tue, 15 Feb 2005 19:05:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1D21-0006Nh-7S for forces-archive@IETF.ORG; Tue, 15 Feb 2005 19:27:08 -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.00F9016C@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 19:05:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57977655 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 18:46:26 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 18:46: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 j1FNkQ8U014726 for ; Tue, 15 Feb 2005 23:46:26 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 j1FNkDCK028971 for ; Tue, 15 Feb 2005 23:46:26 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 M2005021515462527993 for ; Tue, 15 Feb 2005 15:46: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); Tue, 15 Feb 2005 15:46: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: [Issue #3] Proposed resolution, issue #3 Thread-Index: AcUTuIZDbUKBxBzeTfiW2ti5x5nL4w== X-OriginalArrivalTime: 15 Feb 2005 23:46:25.0809 (UTC) FILETIME=[8FD75010:01C513B8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 15:46:09 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: [Issue #3] Proposed resolution, issue #3 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable All, I have received the following proposed issue resolution text for issue #3 in the tracker, and updated the tracker appropriately. If this resolution is unacceptable please state that on the list in the next week: Issue 3 (editorial changes) -------------------------- Text Mod... "The ForCES query and query response messages are used by ForCES elements (CE or FE) to query LFBs in other ForCES element(s)." 6.4.1 The Operation TLV for the 'Query' message is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Operation =3D GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path to queried data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 19:06: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 TAA01689 for ; Tue, 15 Feb 2005 19:06:18 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1D36-0006QS-Mw for forces-archive@IETF.ORG; Tue, 15 Feb 2005 19:28:12 -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.00F9014D@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 19:06:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57978199 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 18:47:28 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 18:47:28 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j1FNlR8x025971 for ; Tue, 15 Feb 2005 23:47:27 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1FNjuCC020075 for ; Tue, 15 Feb 2005 23:47:27 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 M2005021515472706204 for ; Tue, 15 Feb 2005 15:47: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); Tue, 15 Feb 2005 15:47:27 -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: [Issue #4] Proposed resolution, issue #4 Thread-Index: AcUTuKyg4MeDIEWVREG4MCoertl6mw== X-OriginalArrivalTime: 15 Feb 2005 23:47:27.0496 (UTC) FILETIME=[B49C0080:01C513B8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 15:47:14 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: [Issue #4] Proposed resolution, issue #4 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable All,=20 I have received the following proposed resolution to issue #4 for the ForCES issue tracker, and updated the tracker appropriately. Please review the proposed resolution and let me know any feedback within a week. Issue 4 -------------------------- No changes needed (some of the comments are now obsolete, others are being discussed in context with other issues, e.g. HB) Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 19:07: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 TAA01826 for ; Tue, 15 Feb 2005 19:07:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1D4Q-0006Sn-8o for forces-archive@IETF.ORG; Tue, 15 Feb 2005 19:29: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 <10.00F90236@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 19:07:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57978447 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 18:48:15 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 18:48:15 -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 j1FNmEdX022521 for ; Tue, 15 Feb 2005 23:48:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1FNm5B4021541 for ; Tue, 15 Feb 2005 23:48:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021515481406310 for ; Tue, 15 Feb 2005 15:48:14 -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); Tue, 15 Feb 2005 15:48:13 -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: [Issue #5] Proposed resolution, issue #5 Thread-Index: AcUTuMk8TRzSnCvcQeu4CGO1EkCnJg== X-OriginalArrivalTime: 15 Feb 2005 23:48:13.0065 (UTC) FILETIME=[CFC54790:01C513B8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 15:48:02 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: [Issue #5] Proposed resolution, issue #5 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable All, I have received the following text for a proposed resolution for Issue #5 on the issue tracker. Please review and let me know if this resolution is acceptable within the next week: Issue 5 (editorial changes) -------------------------- Add text... "Events will be defined in the XML as attributes; i.e they will have a path to them that can be used by the config message to subscribe to." 6.5.1 Event Notification Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPER =3D REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path and Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 19:08: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 TAA01880 for ; Tue, 15 Feb 2005 19:08:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1D4u-0006Tq-3M for forces-archive@IETF.ORG; Tue, 15 Feb 2005 19:30:05 -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.00F90165@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 19:08:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57978542 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 18:48:41 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 18:48:40 -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 j1FNme8x026444 for ; Tue, 15 Feb 2005 23:48:40 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 j1FNmVCM030404 for ; Tue, 15 Feb 2005 23:48:40 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 M2005021515484028385 for ; Tue, 15 Feb 2005 15:48:40 -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); Tue, 15 Feb 2005 15:48:40 -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: [Issue #3] Proposed resolution, issue #3 Thread-Index: AcUTuIZDbUKBxBzeTfiW2ti5x5nL4wAAETcg X-OriginalArrivalTime: 15 Feb 2005 23:48:40.0080 (UTC) FILETIME=[DFDF7100:01C513B8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 15 Feb 2005 15:48:30 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: [Issue #3] Proposed resolution, issue #3 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Small correction - add the following to resolution of Issue #3: 6.4.2 Query Response Message Response oughta be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Operation =3D GET-RESP | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -David =20 -----Original Message----- From: Putzolu, David=20 Sent: Tuesday, February 15, 2005 3:46 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [Issue #3] Proposed resolution, issue #3 All, I have received the following proposed issue resolution text for issue #3 in the tracker, and updated the tracker appropriately. If this resolution is unacceptable please state that on the list in the next week: Issue 3 (editorial changes) -------------------------- Text Mod... "The ForCES query and query response messages are used by ForCES elements (CE or FE) to query LFBs in other ForCES element(s)." 6.4.1 The Operation TLV for the 'Query' message is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Operation =3D GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path to queried data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 20:36: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 UAA11127 for ; Tue, 15 Feb 2005 20:36:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ESq-0000We-M6 for forces-archive@IETF.ORG; Tue, 15 Feb 2005 20:58: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 <7.00F9068A@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 20:36:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57985613 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 20:12:48 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 20:12:48 -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 j1G1CldX030066; Wed, 16 Feb 2005 01:12:47 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1G1CjB0013549; Wed, 16 Feb 2005 01:12:47 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 M2005021517124716838 ; Tue, 15 Feb 2005 17:12:47 -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); Tue, 15 Feb 2005 17:12:47 -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] Ambiguity in BLOCK semantics-some qs? Thread-Index: AcUTEWvmRTpRC1ViR3uUN9MYBhrkVAAsa1xw X-OriginalArrivalTime: 16 Feb 2005 01:12:47.0471 (UTC) FILETIME=[A05A2FF0:01C513C4] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0446D2F9@orsmsx408> Date: Tue, 15 Feb 2005 17:12:46 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Ambiguity in BLOCK semantics-some qs? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Joel, Thanks for your reply...Pls see my comments inline..=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern One the nested PATH-DATA, this was an efficiency mechanism. As you say, everything it can do can be done without it. However, there are two important factors: 1) It is simple, well defined, easy to describe, and I think reasonably=20 easy to implement. 2) It covers a case that is clearly likely, namely setting multiple things=20 in the same portion of the LFB. I think it is a good efficiency tradeoff. [HK] I actually don't think I see any additional efficiency because of this. The example in the text that Jamal sent out...#17a&b doesn't give me the impression of one being more efficient. Let me know what I am missing. But if the efficiency is not significant, this is definitely something that strikes me as a good candidate for simplification. My view on the DATARAW with indices is that it is for use when we are=20 representing the whole table. It seems to me that one important use case=20 for setting into a table is where we are resetting the table, creating the=20 new entries and throwing away whatever was in the table before (just as=20 setting a variable discards the old value.) If we used indices in a=20 DATARAW for a table to enable selective block operations, then we would=20 need some other way to handle setting the "whole" table. [HK] Why is this the case? We can just use different Operation names, e.g. Add or Update to distinguish between the different scenarios. I don't think there is a need to distinguish the DATARAW semantics for block operations or setting the entire table. May be you can give me an example for why this wont work ? And it should be pointed out that this would still leave many of reasonable=20 the uses of BLK unsupported. [HK] Could you provide me with some example here? Thanks Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 20:38: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 UAA11324 for ; Tue, 15 Feb 2005 20:38:10 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ETy-0000Zh-B2 for forces-archive@IETF.ORG; Tue, 15 Feb 2005 21:00: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 <2.00F906E2@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 20:38:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57986059 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 20:19:12 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 20:19:12 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j1G1JB8x031132; Wed, 16 Feb 2005 01:19:11 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1G1JAB4017181; Wed, 16 Feb 2005 01:19:11 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 M2005021517191017480 ; Tue, 15 Feb 2005 17:19:11 -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); Tue, 15 Feb 2005 17:19:00 -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] Multiple CEs talking to the same FE Thread-Index: AcUTccwPi/K/yhX0R/e+dCHB4T6DOwAUzj7g X-OriginalArrivalTime: 16 Feb 2005 01:19:00.0253 (UTC) FILETIME=[7E8C34D0:01C513C5] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0446D317@orsmsx408> Date: Tue, 15 Feb 2005 17:18:55 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Multiple CEs talking to the same FE Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Robert,=20 -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 How far did you go with your implementation of demuxing ? In our case,=20 we found that relying on sequence numbers or message types is not useful when you want to direct an event notification coming from the FE to the=20 appropriate process in the CE. But maybe you found a way to solve that ? [HK] You could use a couple of approaches here. One you could send events to all processes and let them decide on which events are relevant to them. Or, you could use the LFB IDs in the Event messages to demux between the different processes, in this case your shim layer will have more intelligence. Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 15 21:51: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 VAA20705 for ; Tue, 15 Feb 2005 21:51:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1FcT-0003Bi-Hr for forces-archive@IETF.ORG; Tue, 15 Feb 2005 22:12: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 <22.00F908C7@cherry.ease.lsoft.com>; Tue, 15 Feb 2005 21:50:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 57991545 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 21:50:57 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Feb 2005 21:50:57 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9205847 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 15 Feb 2005 21:50:56 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0446D2F9@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050215212407.03225e58@localhost> Date: Tue, 15 Feb 2005 21:50:33 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Ambiguity in BLOCK semantics-some qs? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0446D2F9@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 How much efficiency one gets from the nested path-datas depends upon how deepd you think the table a structure constructs will get. If they are relatively shallow, the gains are marginal. If they are deep, then it is noticeable. Example 18 (I think) shows what happens when things get deep. In fact, the payoff likely comes when one is trying to set multiple (5+?) things within a nested context. Then it does start to matter. Whether this is worth it or not is something on which reasonable folks can differ. I am trying not to take the "kill all the lawyers" view of ideas, so since this one seems easy, it makes sense to me. Since the DATARAW is actually a nested construct of related TLVs (variable size structure, string, octetstring, and array) I suppose we could have one for "selected rows of an array". For me, DATARAW TLVs represent structures that are mapped in the definition. I may be being too picky. On the question of what this would not cover, the simplest example is for an array whose contents are a structure with more than 1 element (say x1, x2, ...). With block, one can indicate one wants to set just the x2 part of several array elements. If one starts extending DATARAW to say that, then the DATARAW becomes the path-data. Yours, Joel At 08:12 PM 2/15/2005, Khosravi, Hormuzd M wrote: >Joel, > >Thanks for your reply...Pls see my comments inline.. > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >One the nested PATH-DATA, this was an efficiency mechanism. As you say, > >everything it can do can be done without it. >However, there are two important factors: >1) It is simple, well defined, easy to describe, and I think reasonably >easy to implement. >2) It covers a case that is clearly likely, namely setting multiple >things >in the same portion of the LFB. >I think it is a good efficiency tradeoff. > >[HK] I actually don't think I see any additional efficiency because of >this. The example in the text that Jamal sent out...#17a&b doesn't give >me the impression of one being more efficient. Let me know what I am >missing. But if the efficiency is not significant, this is definitely >something that strikes me as a good candidate for simplification. > >My view on the DATARAW with indices is that it is for use when we are >representing the whole table. It seems to me that one important use >case >for setting into a table is where we are resetting the table, creating >the >new entries and throwing away whatever was in the table before (just as >setting a variable discards the old value.) If we used indices in a >DATARAW for a table to enable selective block operations, then we would >need some other way to handle setting the "whole" table. > >[HK] Why is this the case? We can just use different Operation names, >e.g. Add or Update to distinguish between the different scenarios. I >don't think there is a need to distinguish the DATARAW semantics for >block operations or setting the entire table. May be you can give me an >example for why this wont work ? > >And it should be pointed out that this would still leave many of >reasonable >the uses of BLK unsupported. >[HK] Could you provide me with some example here? > >Thanks >Hormuzd From qlvolhfaq@pasadena.net Wed Feb 16 02:52: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 CAA07961; Wed, 16 Feb 2005 02:52:23 -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 1D1KKB-00039P-9a; Wed, 16 Feb 2005 03:14:20 -0500 Received: from [218.237.147.156] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D1Jyt-00057j-4o; Wed, 16 Feb 2005 02:52:19 -0500 Received: from campaign.itl.net.ua ([216.34.107.232]) by tim.itl.net.ua (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 26 2004)) with ESMTP id <0B2N00RA036PE62@tim.itl.net.ua> for speechsc-admin@ietf.org; Wed, 16 Feb 2005 06:44:16 -0100 (IST) Received: from allay.ccnmail.com ([63.96.78.170]) by campaign.itl.net.ua (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Aug 20 2004)) with ESMTP id <0O8G00QG711SO90@campaign.itl.net.ua> for speechsc-admin@ietf.org (ORCPT speechsc-admin@ietf.org); Wed, 16 Feb 2005 09:43:16 +0200 (IST) Date: Wed, 16 Feb 2005 00:48:16 -0700 From: "Becky Klein" To: Subject: alert - videOs can c0st you your j0b Sender: "Becky Klein" Message-ID: <440498298555.ITP29078@allay.ccnmail.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Java.XTHDS.1598437701462213" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <0421956360376@KGVQUA> X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 17.1 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 This is a multi-part message in MIME format. --Java.XTHDS.1598437701462213 Content-Type: multipart/alternative; boundary="Java.HHKPP.30395250535484317159" --Java.HHKPP.30395250535484317159 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Minnesota, which can clinch a wild-card playoff spot with a loss by either Carolina or St. Louis this weekend, appeared on its way to retaking the lead. But a holding penalty on Birk -- the Vikings were flagged nine times for 78 yards -- wiped out a 16-yard run by Michael Bennett that would have given them the ball at the Green Bay 40 just before the 2-minute warning. --Java.HHKPP.30395250535484317159 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
 
 
 
remove
Minnesota, which can clin= ch a wild-card playoff spot with a loss by either Carolina or St. Louis this weekend, app= eared on its way to retaking the lead. But a holding penalty on Birk -- the Vikings= were flagged nine times for 78 yards -- wiped out a 16-yard run by Michael Benn= ett that would have given them the ball at the Green Bay 40 just before the 2-minut= e warning.
 
The Vikings (8-7), though= , couldn't get what they needed from a pass defense that has struggled all season.
 
Government spokesman Raan= an Gissin said four soldiers were killed.
 
Six people were taken to = hospital -- four badly hurt, one with moderate injuries and one lightly injured, milit= ary sources said.
 
The sources said another = soldier remained beneath the rubble.
 
Gissin said rescue operat= ions were continuing Sunday night.
 
The attack "indicates tha= t unless there is decisive and sustained effort taken to dismantle the terrorist organization, it will be impossible to move towards normalizations and tow= ards political negotiations," Gissin told a news crew. "And I think the responsibility on that lies with the Palestinian Authority."
 
Shortly after the first b= last, a second explosion was heard in southern Gaza, but its precise location was = not immediately known.
 
Hamas, in a phone call to= CNN, said it had set off the first explosion near Rafah in cooperation with a group = called the Fatah Hawks.
 
There was no immediate in= formation available on that group, although it was believed to be linked to the Fata= h movement formerly led by the late Palestinian leader Yasser Arafat.=
 
Israeli military sources = said it was a coordinated attack, with Palestinians firing mortar shells and guns at t= he post when the explosives were detonated.
 
It was not clear whether = there were Palestinian casualties.
 
News video of the afterma= th showed soldiers using stretchers to transport troops who appeared to be severely = wounded.
 
In a pamphlet distributed= after the attack, Hamas said it had used 1.5 tons of explosives and had recorded vid= eo of the incident.
 
Palestinians have used tu= nnels in the area to smuggle weapons from Egypt. Israel has carried out operations to c= rack down on the smuggling.
Shell explosion in schoolyard
 
An Israeli tank shell exp= loded in a Gaza schoolyard Sunday morning, wounding eight Palestinian schoolchildren,= Palestinian medical and security sources said.
 
The children between the = ages of 6 and 12 -- sustained moderate to light injuries, the sources said.
 
The violence happened in = Khan Yunis in central Gaza
 
Israeli military sources = said that forces in the area identified what they thought was a number of mortar she= lls being fired towards Israeli settlements nearby.
 
In response, the forces f= ired towards the positions with light weapons, but did not fire a tank shell, the milit= ary sources said.
--Java.HHKPP.30395250535484317159-- --Java.XTHDS.1598437701462213 Content-Type: image/gif; name="inimical71.gif" Content-Transfer-Encoding: base64 Content-ID: <813520c4d3c0$2180fea0$072aa4c0@KGVQUA> Content-Transfer-Encoding: base64 R0lGODlhlgCbAMQAAOrq6jS7EtXV1VJTTnd0cpCMijQzMrW0tNwYGKWjowUDBdqXl6AaGngyMkN4 M+heXiN1DoeDgCYhIF9dW398eGpoZbCtrJuYlhtFEBISEv8AADP/AMzMzP///0lHR////yH/C05F VFNDQVBFMi4wAwEAAAAh+QQFlgAfACwAAAAAlgCbAAAF/6CSjaRknmiqrmzrlvArz6tox3eu7/c0 +IQgRTgsGiPI5FHJJDYrQCLw56FCr8sn0pOZMKvXkbc4HZB2hhNvvcNm31p4Ib6MGn3WvHMe53rq VGJYZRI8amyIPW5yjI10UnB4eT+PSROCdx5pIpSDP2c3m4mjnHuOlaaonoB5Bn+sgyZjnoVddpK1 nLmkpKeofKm/lpJ2sMWDQWlXxFCYy2GhoLyJvk3A19XW2MzBUGBSuBKzzIXfz1zTMNPZ7O3b4ONf ekRp5lRVI673mmm76evdAmob6G7Rlk7vvJETt+iTrUD3/ElT96+UwIIEMQ45ZizZQyF4ZHFrNjEU v5K9NP9mVLnx4rNMYMrZ8yGSWUQ0+VDyYsnnQs+VQIdFsunEW66ZZj4S64fjUMVQQYu6w0b1Z9U7 8KzIK7HPYbwtMWroJMVQ2FWraKOqnQWTrZBN+uzIYqqPBtOxiFxKTeuz79mhUcdUHZlUsBJRaG7S wKtDb1C/fNUmJIPM04C4JA3PuTSWrqvPn8MyhgpoKuQEqCNLxmp5XriyRiSWBH1S7GjSpk+n3q37 r++WL7uOQ2cr9rS7i29DeoyWt4XnvFUDNggya5TLJxAmbTq7Hj/Et3VIoJwbuvkD508HHskO+6sh 4EfXDR3e0OrmztHrTw9ZFVHHIPEDkmh40RbfU+MFg9//gudx4OB+EPa3HnuTBYFdBfAR2Fk/VRD3 lA0KSjdHfhA+GCF/Ev713yOcYYidhih1KGN99t2HX4MmnhjdjtKdg9leBChDwHYwThSRUx8maOOI fuGYY44oMpkiQYS5dZlRNOpiG4JLMkHik1DqKKWIaS1jzkYdZpmPd+6piVuXTer3oAB01hlmlGT2 qF1I9aEgo0IHpqOkl9Wg5qSdiN7J45jM8XFlgAeCtoJNim2ZyKCqZGGonIl2qqh6eUamVSAxvNLm Zy4Kp8magV5KqFlScurprHiGCtRrpZppparEIckLphW+GqeDs9Iqpq230oRkTdQNeR2fFB03XYix Elus/7HQMfpbYPTBcGaAPiLnpghvcCRsX7Je6+l+2m7rCLQl/FgdpQ6tOVtn5WK40qbpqrsuu+6a haU08lporkf24pQXkGfx26+//2YbsMC1xVulVNAkXFFDmlYLprUgQ/zpxM3CJK6pB9sU7carVOXw xyGLPPKUGL9UlIegGACuzZTKxnInxcQq8aExy3wsizwf5rMzFtKlr2VLp3OLvg1/CbPRR1dY5aqG IERGzvHASxYPT+9hwY0lFq322lnTfM7AY2mGMNi43taqix1re+KdbMfcttvztkpwAam5qFNcOK8c TWJyn9vT1Q/7/TfgdQhuZOEUWP5Qn76SS7XZ6J5dRP8CkEc+85QSlqz54IVHbcOLnIunKcCEX5P2 7ZJPrufNiuv0uXziugnsBbQP9DLupy/qeNnLqPlKApyNwnW3/wxPPHqVXM9piU7qXmbNQTrfF5GI mMBJ4uFZb95mzBOg/XMmEj6095QDB5zw7odvt8ZqvrG+dV9yjvySV79HrC5GFzjg65ZVPonMLlup MgjpIiQ/0b3PYb1JnUuSQz1X9Il8IvBHfESYN/1EEHQPqmDtHjc/1H1PDr0SzY9cJ72JgGeEObAe EnhTsgtaME4uLCDDKiCD521mXIuLV85cp8MdEi9YGAyiEEtjiuD56XMFiN64ZBDCAgFlNxhb4fqk SLL/eRUFRu9hAg0vxSYrump5EJyaDyVGrbUkjYgyLNgRkRhCSampiSxEU9meKDTbKa8d4QpL0JTG R1YpUHbZwEOIikfIMrImFjLEYiYayR3z/aoOAZFkEhIwytA9hwjYyxT4MJnJbnDSio/0nP0MSUpu uOx/TnzhKs2oRUVqkpFIdOMHT1jK0WXxJT4BHQRzGaxdmimPzNLHF17ZuRz6rgw9fFstCZXKOrZv ObyEpisyNE7ICHNsjTRQwb75y9F1c0LOhJsSRcIhqo1vjWxAzjnXcMNFHgSZyQSdPQG0SxyqYFXS LCb6jnMGccSyi2/yAuZsectjqsg64FuohspJKI2i/5NVSSpBS1ZosJS506JTZOczG1ok2GShlyF9 aAZORgnMzfKmJ5WoBlV6s+u0lKUubQI+xTNUfoKFBBa6gACgx1Pq+OVpWiHPHa0Dwp9+ayNFtaZW f3WAPSrgPdt8Gy+NWTj3/CGsU4VCARxkv6r+NDtfC+lW5eMsIiW0pKLE6Q+TAZqm2ox0AGCqJGH3 1oaCwa0f7V0DJYIUCrlhr81gk1hV+s7BVoxGf/DopQwr0xE+a0Wn4Mw684pXnl0nQ0TtnUPlGq+H cs0kw1FINnM5hu+EjbSmnWzmPKlYTvJznwrL4WcdK8GARoALzMqtcrEZWZl+aK7AFa4NhzvYXdYu Y//1ZE9w6OWFwsB0ns8lS2eny9zq9tBRrRrtZHuWD2UZybmLBWr6ZNPY7eq0iowB2nLZaykPhneu /+2aeS92SingM6gNmcSRZppe9wbYUsKjG3V1Sw9pPfC4Co7uTOWJIP/69rf2jaBrhtQn/9EJw6P6 lXeeizj4Sm3EE/apoAZqTNl24sDtTZKMLvtg8rZGV67Jks6oNBImHsXF2Xnth30cY8JktY9DsSyp DMHbHms4nd8SDjgRm4g0SpW7T+4whLdIsMMu5RtVgS9DpsbdKScxwNEYMzV55bUlhLmPUU3rgN4M 5z7K+cECanOGt2hmqObPlE/NRZX77MclMxnMHJr/EZ/LN4mSitFQwOBwn/3852BeSVVGifRldRYe /RpaG2fW7H+vjOVCt6LFJ5m0Ucto2zRtOrWdZjFmJpFkvHY2FTZ9Qq0Je+s457oi0VzwOFtTYhuF w9bFtmZydM0PXvf6bdTjZ+NQDMPv1CXa0uZi7HLowV07rbxToKF6a2pcMnhbyeCGqKO7JmrCxtZH bKyzXt49783Kl9E7VvYAQPmd0bglyuDgUL9/u3ByB1zJA9/ZZeC9hm0/9ZLKuku8yd1w2D6cK75e 6RuLSwez4mPjuO64QwO+C1ibWYGFzlu4vHNnMaucIW08xJrf7WZ5C9cwfs34t1FOdDSoU+Mup2dq /8WD5tKaOtRzKXpvHZ3kWHPl0x/nONOB3NTpZTve4mZ0LSrlSHPTRLiR4ro86vZ1cGv85oKAZc6H DmBFVBu3S7miAaTe9k7anMFpbzHgh3n3VC+4vXsnOs3DztrBl5nf1Rw7YzP+7K4gBtpgr/qiqR51 Kteb4oCvl931+3BiYz7zx9bxxI1cdhs22uOCdrDj+e6Zf4d3yCSJr8KZbnXYnxdN/FY841cdoO4c Pe2tEK7jMngY4Q//9pBSZ4YlDVuRh5CZUcy+T1RtZb8DfL3gp75FjpD462u/Vvek/eYjL6j6Nlku PUgLKAZwfvRvn+8dfx34/XpUciE6i1CBIgI4Rv/3J3W2932/ZzwXED1nxR94ZH7cM4BRVH5U1nhT p2N1xCCpQQIN2CAFsAvuE4ESiGkFaIAN52UaqH21MB7d4yEVIIIjSILcJyj5VyOXVn8YVH4T0D0R cBQxaH9cRoM1iEBAhIPpsR0eMEEeiIRGSII78l2yVoFDiAbM14TYs4JKWCI9CIH0AxlBWHNT+Dok hTbnt4VdkIVQ8oAvSIBl6IUNZIIspoBFSCJ4lITbQ0G1EIJzuIe1M4NwiCCa8X+CuCmFgYP6Q39V uCD912NhmANNd4NzaC1nk3h2+ClEoodkhH1+6G+NqAjAhmg8iIUfAz0tp0KgIh0U+HcMhHII9kD/ 8JMuCdRQa0UsXfWA8ZeIKgKG56Nw6xdtd+WKlXQ8tpgPEQAdwwiBy5cRQTgKO1dw+bds7WSKbHge 3/V6IJeJVHJ7ERd9LtZAT8cIOLiJpYCNLzU37feITwV6q/YnFGUVPwiF+cSO3oQxb+hwaNYfYgNn 8uhUKUJHRwCPiYWCLIII6CMv+Gh5m1c92vWJzCR7swdo05J7Uohn9/gTgAJ5hLaPZOU2gXdruIc0 H1SRmXaR3pZ6jqhg0VhBBZaKG9eKWZE+HUJjSpB3avACzMh/KyGOqpeS6aZiIjmTbNeLpbZfzqSO xfaLQGk4M1ZMbVGS0xaPE3dvynSQN6dvL6mQ/1ZJkp6hT522kH/lhOm4cHr0ZRL5DwKplfPBaj/H ZqA0la2ji8lFUADZZVvDcjWZkAUybNjUbnwpIb13KVmZlGO1ejs5fc6olrwnWcyFSMD3dlvHk0CH bZchZknnlFsZZqMyVSPJTMpIbCepVrrEPpNVc9J3d5fpmDCJUQK1mmOIXkz0jc6SL3lHmSlgl3OB mL5naGwZmxuJfbVklOZzlnLJkuJlmWnpR7gZQu6FOHlVeqB5QWOCml0kEqqUW8TJjKLmJw9Xe85D Z0Lwm3gnk/ljjgIWQX0pFFI2l/FYRMZpkkoxYN95imWyjcdIVAZCAe0WT2eHbLXpjKHHi953OOpI aVwHo0I303xbcm1P934955OR5gLW+EcbJp6gWQYxGWpOJqBNh3WukWX7eY4RGhZcKWRt5JwyoiL3 MJ6ixQLs9n4SBzTXqXscdJkw6Wr29ZHvgp9lVXkU2k4/Zn3iBaF3eYAhWXhBZ080A0b0qaPt0gi4 YKE+AKKFdS9EmpjMSVxSNRilJJD181nrppPciZcCGqD2eKUFuplj1RMpal3ht6SmSSNPCacbok9/ okrvkI5XlRuN2aAyqp0hSk0uN0jVKajs4zLH9DSVhHFqt4zhdlDu6XNjqp0LanIux3MmipCKeZoj CpeNGAIAIfkEBQoAHwAsAAAAAJYAmwAABf9g5o1kaZ5oqq5s675w/HZ0bd94ru987//AoNBn8QyP yKRyydQdjM2odEodPqvYrFZ63Xq/4F03TC5rx+a0eoleu99EKHxOv7XrePc9zy/v+4Bef4GEVYOF iE2HiYxIi42QQI+RlGJylZiSl5mclp2fnqCiNpOjkKWmjKipiKushK6vgLGyfLS1eLe4dLq7cL2+ epvBqsPErcbHsMnKs8zNts/QudLTvNXWv9jZwtzL3oHA4Fni44bb5mTl6Vzo7F/r70zx8kr09Y7u +Fj3+0L9/jQFXANwYI+CBkMlVKdvIZuGDpMgjEgKIkUrFi8GmaiR40WPFEFGFOmQ5EKTCVHZGlQ5 kGVAl/5g7pOJj2Y9m/JwvtPJjmc6n+aAjhMKjqg3o9yQZlNqjek0p9CgNpOqjOoxq8SwBtPqi+su r7jA1hIri+wrs6zQplJriu0ot6LggpL7iW4nu5zwZtKLiW8lv5QARxJ8KqPGH4QbJS52eMviRI+R NT5jeLJCy1MiF9L8DTMVzuEqe7YjenQN0M5Mt1MdBXUf19FYKyqtGnYe29Rkz6NtGncd39d0PxRu j/do4HOQayMu0bhn5W+gd2N+5ImFA9iza9/Ovbv37+DDix9Pvrz58BRCAAAh+QQFlgAfACwAAAAA lgCbAAAF/6CSjWRpnmiqrmzrvnD8enRt33iu73zv/8Cg8JcZGo/IpHK5KzKf0KjU6Jxar9hnNcvt enXbr3h8DZPP6KQ5zW731u643ACf29H1u/6b3/uxfX+CUYGDhkqFh4pDiYuOPo2PkjmRk5Y0lZeT mZqPnJ2Ln6CHoqODpaZ/qKl7q6x3rq9zsbJxtLVtt7hpurtnvb5jwMF8xJfDxlzIyYDMksvOU9DR hNSh1orT2Eva22rep+CC3eKM5X7k50Dp6pDtsO927PFg9HLz9jf4+TX7/HT/2PjjNzBfQXsH6SWM t/BdQy8IIiJo0EViRIpBHlbUwJHBRo4aMK6LBjLkx45CNP9yYcDS40mTGeWIfFUS5kghDUqKzAnS JQ2LPi3WnKmTQc+fR4X6RIrSg1GQTofeeNqTqoYaQs0N0Ym1pg2uPGtyZSoWo9iyX49G7XnWhtWz V8nGjTnEatexdj0IPRsU7l24HNM2fcv3L2DDWnGWpBFWLVC5Lr3KDcnS8MS3IvEOJcxY8tsaeelu hbpW8uKpfUnrHSs4MOTOaq2mdq0UMWybN+smZUu7Keq2cnNILm1Ts9rVg1lnvb2UCBKdVaP7buw3 OI7hoRu7DI28t+ruc5HPdH4E6G60kz0uBy/8eHbjrq3Lts14fG7daPfanG+d/XX3ysUWYHJgYddS c+48J9b/bd/VRtxcw7WGAGgDwsTdcICd5p9oRmBmmVsZqhYhfe8J2CCAIdJ3nxEROmhZRxqO2F+J BMa3YXDrrbcifhGBKFEO/D3WHYJDUvgjcxhp9xeRmWl44IQpBeTjRSp+IyWDlLmIyJUvyoiESoZk aN+XXLr1ZGXVlCkGmOKwCY6b3sC5jZzY0GmNndTgGY2ezvDJjJ/JAGqMoMQQGoyhviC6i6K4MFqL o7JA+oqkrFCaiqWmYDqKpqBw2omnmoB6jJprklqMqV2Iaomqm6CaqqvKwJoFq8/I2oytVtDqCa65 8iqNr1Lo6oiw1wALBbHZGHusslowywSypDjLjbRbUkumNbVHQGuItuFgS4W334IbpbgckvuGuTui S4m6CbLbhAHwxivvvPTWa++9+Oar77789uvvviEAACH5BAUKAB8ALAAAAACWAJsAAAX/YOaNZGme aKqubOu+cPx2dG3feK7vfO//wKDQZ/EMj8ikcsnUHYzNqHRKHT6r2KxWet16v+BdN0wua8fmtHqJ XrvfRCh8Tr+163j3Pc8v7/uAXn+BhFWDhYhNh4mMSIuNkECPkZRicpWYkpeZnJadn56gojaTo5Cl poyoqYirrISur4Cxsny0tXi3uHS6u3C9vnqbwarDxK3Gx7DJyrPMzbbP0LnS07zV1r/Y2cLcy96B wOBZ4uOG2+Zk5elc6Oxf6+9M8fJK9PWO7vhY9/tC/f40BVwDcGCPggZDJVSnbyGbhg6TIIxICiJF KxYvBpmokeNFjxRBRhTpkORCkwlR2RpUOZBlQJf+YO6TiY9mPZvycL7TyY5nOp/mgI4TCo6oN6Pc kGZTao3pNKfQoDaTqozqMavEsAbT6ovrLq+4wNYSK4vsK7Os0KZSa4rtKLei4IKS+4luJ7uc8GbS i4lvJb+UAEcSfCqjxh+EGyUudnjL4kSPkTU+Y3iyQstTIhfS/A0zFc7hKnu2I3p0DdDOTLdTHQV1 H9fRWCsqrRp2HtvUZM+jbRp3Hd/XdD8Ubo/3aOBzkGsjLtG4Z+VvoHdjfuSJhQPYs2vfzr279+/g w4sfT768+fAUQgAAIfkEBTIAHwAsAAAAAJYAmwAABf+gko1kaZ5oqq5s675w/Hp0bd94ru987//A oPCXGRqPyKRyuSsyn9Co1OicWq/YZzXL7Xp12694fA2Tz+ikOedwBN5tdntOH9zqDjl+bsP363eA OnuCgYSFN2s2ARuNjo0BeTUOj5WQkh6Mj5g0mo6eGwGTlaKdj6U2lqh9lq2coK2OTTywlpiUsZs1 pKynA5U1tcG6vcA4uLmfw8myYDu1wjTIzHaZvDS2Hsa/2drEu62r0szEtbGzOtcQlZLTG3OwmPHW 5brukNiPBvvj53fs8NiZOvWmYEF+OBR5cwSBxKdI/Rg69AXuk7uGI9ZJNBdAwrSOIwZC+haxEYYS oEr/wWKRQ6EqCCdN7LtIAhTMUclKaISUIZcEmyHzOcJAEedQlPUesUz4LFekEh5oZthpcou5qiQW mjy1CaiTjz31FWsEEwOElUVgGTQYsyWtZCCL3IsVlIaEWBiD2tTHVaneTRlsjoUb8mqltkx5UG11 0sBcW1mNfpJJr1XgWHGFViWqTHKuvAYMk0zUI+PVUo8BR7YLK2bdxx0XSwwJdsRhz6pcpyW1Fg66 JiZklwx1FiLlwVBTubK93ElKCNCvRT38k3rhSiuc5SjIk8Ti4bpP4EBbV7M+5pYkBCXXbPr5u6ey kkeB0Iai+YvlWqc/Hnt5kX5dlh5t7JEFXkYCAbhB/3ZusUHKHKQg+J542/nnYIQSxnddgajt141o YjVYITne7VefDmhd+N4+kDnBjlkwtubeUTNdAyJD2qHIjGs0ndiUX+n455x1M2JVgkA9KmjHjQaK 2NJZ4QRHnY86Ajlid18JWVkoKKTk2JQV4cPkOzmCMQKMkhxngJpEsJkIm/zZFUMNalIoZws+KnTn Unvq2ZKb9sEpaHL8qEfooKvNkBgPhqrw5mpBAEonov8BehylVShKWptxTgopp5ExICoDgRLa5xaN /ndqnydSqKl9TDCgQQNYaGCrBmmk4WcPstpK6xW34prrGbvyEOyvVgQ7LLG8jkrqDcciW0MDzu7g rP+0NCiLELWjTtHtE9xOi+2mOfQa7Kw0mHvstOf6akMD7d7K7q0hqXvrs+XeOy+6HsDbLr7+2lrD ugEjYC6t6zr5brzu2utuvwzzW/C/A9ObwcQJ56CtBwjICzHD+G5MMMPZeqxwxQJ/LOrH5/4arbq0 wkytyBZ3nDK3K+tgM7/6cqwvzCwL6/PD8bps8qLQvnxisOrtc7BdT/cbrgHqoqzBCDsbnDMPBbMc M81Emzxyz/xkTC4OIAfFNAlZkyxu21cHHVLaEuzAtLlY30tC1QXPbXHfqe5jqpzWwm2r34ezHTG9 Q9+7NuBBn6tquvTqncHODOytN+SPr53c4HYxOoL/qAl7LsHBZwqu+N+dW3wn6Udr3K6hqOft68Wt Jw54Vloj0DTSC3dsaOmby1235cSzXrPBV9vOr86zj37s6bn7KjnuFtddcuJ5Qu8409v3bPjy31fv /KxZa6/DxJnXG3H7EizePORWjxu699HX7bDV12N/rPn+y5+xTEe5f5XAXrCb39psYDZYFa538HMC zramnmuNy1n6G1XTMChBC4IueInLFPW01oDA4SyDotqgBrfAwZOVSoR1GdyhfueBGSYqMo3ylJ4w BykbwjB1PkzIp+5nJket6lSUkUmqfsiqwN3AYc0rzxIvxaA1DfGDfjIiEnVYJyXeMIYpwN/tVDVF /yl6EYxkHOKaQKW+R7WRVUKkoeB06MY3gnCMk6thDv9kRzq60YXL+sIHA7lGQgpyioYEXiKxYKdF EtGRjBykIYsFyUpOgZKWzCQTMKnJTh6BkzT4wAcEcAMCiJIARiAAKT2QAFHWoAAH8KQVQOkBUa7y laccwgVcyUoBrJIDo5TlJY1gSxpEwJe7/AAqB3ABZE6ABglIwAQS4MsBqFKU0iRANHs5ygREYJus 9KYwP0nMYJpSlOhEpQDQGcxajhKdFmhlOuXpgXWmM5fYHCcVdgBLcdqgmAcIpjy1mUsAfMAC7hTA NRUaUGUy05UVWKdC63nQArRTn0JQiD1vGcpgSv/UA+ckKDuDmc+P0pOVvPwoSn15UIwOQSH9LMAN ACrQUyYzAtrEqTulaVJenlSlE7ClQ10aqXKS0qKjNKhDDQoApaKypDUdpUhpAMx2NhQARM2oEZy5 UlhONKK2jABVJ2oBASB0APa8gFeN6VSQ5jOrQKBlGiowVbjGVZjJbKldiTDOaMp0r3wdAgEGS1gd FJYLhB2sJelaAa0OYaR6nWlkg3AAjvJAnujEKiSBGlgh2NKeH6iGDfw6BM5e9rNvXaRpRWdUlC5V oQd1pi9RWdZYHtOWCC1rUsfaTRwMdADFBGsxQbrRv+pWoGYl7i+T28ze9rKZWAUrS0kpXAD8FZD/ PAirPekq1AhAFaFQbSo2QRtaiab1BvJUK03f2VKmtvKop2zqBSzgSvoq07vKlOdGKcpU/u7XvRdV ZA1qe9YaQJa6w83ne89ph5zil6fmxOZC0QtZsTq4v+69wDOTaVYLj9eglfVoS5E6ge26dakiBsAB NPwbHOz3n0lN7omX+VZs6pWa7IUwgiFL4RiLlbhJNadSpYpWdsZSorEVrzTzGVKgFlTImW0sdhkr ZQMHeMYdleZKHXrTCoT3xBpWa5WhmcsaeLm95symhAtQAOG6Nr/p5O9Dy3vRL194sg707JVDmmW2 thOpQYawTUf64wGX2cpCJSWA4ZzkX0b4zyNF/yhQQYvhbh76bEAgLXq1HM5ldnrAs+3nWMnK1VKC 0wbHVKg2s0ngZXpVxp+OtXI58FdRg9qb/mx1iwHL60f2mtdy/XUmg/1NfyJBsYz9QQU0fWxPm1mx lz31LFM55CtT1pWT5rQNyAuAMQeBzzC27A2UqtkybPXD1v4BPW2dWkNbOt0+ALeVxW1mCWcBlA+m qjhrW020urcG5q1vcjda4I6uUtM47m1EYZvbdzs7oc8tAIirK9Pmqli0SwDlb8f9TkUHuaVXRaec jYzqdvtZvKE9p0G/idqhznvL94Snfoe7yR0QeLSXpmouz+xNYGIVxK6V805LaXKQfnPZp1S5zv+x SmLJwve+SX+ybXOOBI3S3LV/lS2keaxgbLez6G+tLItD7FRwf1TeBg96SPnMZKqT07CHBbhU7evx Wyq4zXK2p9CLLlE205TpUR9qQAHv8rSvO/DqjCrG1UBtdnZb6G/OJWaVKnRyl7LaXM4s4k/e1nCr ffP4hScU5KrNUtsamqV+7rJZ/deFcyAH1OzwrZm5b22nevXPHK04Vw1ScJ669LSOQrCFXcnhE9+R xj9+ImnpV2Zv+uFAgL5hm79N3vMeo7Q8cA6K3oNUZ7rChw8t9o2a8Nwb05rQ5mf6OZts32JT04o9 qTEf3v5Jtnag56RvQ7355cl7XOTVJW7pVVj/4cd5Z0Vp3pYr2ddNZRdl3wVcKGZW78dUdYdjsYRz jhd0J4VbE1heK2Z/OvBiiCZ6+ddnFtVtF8Vm9qVjYIZj5UZmMdZwoRV+0QRigAZrgWR1V4Zb/gRu b8VUehVwaLZjvlSEPeZsBahfRYhQEmd5hLSAluWDNxZnA5VMOpZ4K8YBH4iBSFhfEDWBFrB6sWRf IKhnUVhmqTVcKsdSMgh1UXaEGBh0kfd0bFiG35Z+z1YNcVd/1gdttrZ611VK9Ids6VdshTZN0ZSA Cqh8gJV8jJiDj2hXjhiJi0iJRDWJlsgsmTh+m6hPmNiJggSK4/SJosgFpFiKjISKnnSKqjhM/3Uk A7AYi7I4i7T4KoTzirWYi7q4i7yYHN5mBurRVMI4jMRYjMZ4jMiYjMq4jMzYjM7YjGH4cMAoAUVY jdZ4jdiYjdq4jdzYjd74jeAIjtEojUIUjlp4juiYjuq4juzYju74jvAYj/IIjzhFAeT4JuY4j/q4 j/zYj/7ojvV4j4GSj/9YkAZ5kAcZkJimRwSJkA75kBC5jgqZZ5PSkBF5kRhZkBN5iwNpkRn5kSD5 jhvpawyZjfa4bOeoVpWVkirZkiwZe1o4Xy8pkXQFk1pIWCsZkzK5YipJay6pk7HnVz7ZkjtJlNRE fdBFk/a4kMF4jQUgE1ooAq7HARUgAlapAP/QVUMikJIikJVYmY5PeZX+RgFXqQCq9HoiYABUaZVR WZaVtUZaCJdlKZUcMJdqaUVXaZMpWX8k2ZTpSAIVYCjNRJfnWJUKUCixl5cxyZZomZRtmQGB2ZUX kJaR+ZV4iZZbWZdpmZZoqZad+Xp4uQ8UoJlbgJmqU0/qOJKF1JHoSJZfeQDAR5g3KZWMNZtFcJiL yZlr4piu2UywOV8DkJkHEBKdiZUl0JYR1TSfuZxrqQDoSJk12ZlqRZypyZerWZHWaJjrKJvNaZWe qUdhKXaHOQIUsJutKZznCJdxiZtrZJbu6Zya6Ri6iZvMqZ3nOJfNhJdW+WqtaZ3TeI32+Zf/Znme Zlmbw2mWkzmgk2kACUqeBJqS6+mZn7mb4+maj7mfy6mezfmch2mg+gmZ7Kia/2mNCdpPXamZUxmg tnmV1Lig3embuWmiGdBmJ5oAdEmhXZmZ0LmSJUmdG3qfA4qOcKmVOdmfS0mRcoKNhnKZpLmfhpmX Wqk6WOmiHCCYAnqbkpkVJPCWWBmcGaCZyAmW+FmY6GmXVUqfnFmdR8qR2KmO+ulV+Pmk+ymbUkml Bwqj6amYFzqj6zmdaKWjQYqOEyCWglqmZXmX9GmYeBqT/lmO2ciTIQmQi6qTDtmTICmijhqpmrqp /Yip+OiRnBqqF+mprCmqpnqqe7mmfUmNvKCKqq7aqY36qa86q5pKqm1Kq7iakbaapEAJqb76q8Aa rMI6rMRarMZ6rMharCcpkBW5rOb3rNAardI6rdRardZ6rdiardmqU0hqZqrTNOAaruI6ruRaruZ6 ruiaruq6ruiqVgvZe1kYr/I6r/Rar/Z6r/iar/q6r/zar8ZGkmKIlAI7sARbsAZ7sAibsAq7sAj7 rq24fA87bBFrSaw4sTVnschXKBq7sRzbsR77sSAbsiI7siRbsia7DyEAACH5BAUyAB8ALA8AgAB4 AAoAAAX/4Pdxy/Ms4regqbi+C5e+KcmqcSuS5i2apxnNxoLdhjRjUomDtRaaaPQhmrYeUikLG51F WQiNT5XVUMnZc7jL1VTLb0T8U7bW5essiiNto6wpbWt7ei5SMmE+fFODUIxfdIdtcWtUa3N5WpF5 lnVUjnsniGZXUz2GZqRopIlPkByiXDKLnYl5b7Wbcz9dKX2njWFUsjqRZ7xwH1gnUTKOtmKlbjqX mKnLvX122b3K3ZuamZDE1KrIQIRmoGjP0YHfu7rQYtyF1dXe03Ho4K/r64CQ6Wh3yFE+d6hQgOKi cNuzSPuOERP2Tp+xcnLIiZtWp0RHQcHkbBqzkdKhSB7xPXA0h4pTxRZ3dF0ckQlMmZR6Ak4x+GbM Ik2rXiWC0glXMUHH8sGsI5PhE5/FokqdOnVFsSFUs+6wqrVrixAAIfkEBTIAHwAsDwCAAHgACgAA Bf/g9x1UVSXieKXp5b5H68qomMysatYpsdM2mEo4DKJgQuTsRrRlFFDFQAStsCrR6OrjibagW4Ni +81OP5SsgiASKwxo70edab/tcPp6roa7s0dPGRUSYHxWPVAGiwaBWk6GYmQjgoRgF4qWY1xeXVBU ioqccKNcf4sUfBmME5yrbh5xmyQzVVdVJqmyA1KQd5K3swQuvBkxB09TYoVzhQqgVoV+d6UiWM8p mT/LLsmyOdDBUaRdHgWGmM4UwInYLMsp8GITa1KffAb0vfDV39lqK/48ugbuULBcqZBJwbQnHcMn kwjm4FdK0pt62Oig4EdRIqh82wBCKkApA0lb7XJypOlDCc61WSNLFtDnqJXFT/e0xctJzV+4d7/u fXD2BxSgl1o8MbpETd3EUDxXCbJzoRifn+0E7bEmVNW4odREjRBI0isYpGBQHkr3b9JYQL4Mge02 hScicb1S/ssyjdS1STgKCh5MeHBgIIUTF1HMWEQIACH5BAUyAB8ALA8AgAB4AAoAAAX/4Pdxy/Ms 4regqbi+C5e+KcmqcSuS5i2apxnNxoLdhjRjUomDtRaaaPQhmrYeUikLG51FWQiNT5XVUMnZc7jL 1VTLb0T8U7bW5essiiNto6wpbWt7ei5SMmE+fFODUIxfdIdtcWtUa3N5WpF5lnVUjnsniGZXUz2G ZqRopIlPkByiXDKLnYl5b7Wbcz9dKX2njWFUsjqRZ7xwH1gnUTKOtmKlbjqXmKnLvX122b3K3Zua mZDE1KrIQIRmoGjP0YHfu7rQYtyF1dXe03Ho4K/r64CQ6Wh3yFE+d6hQgOKicNuzSPuOERP2Tp+x cnLIiZtWp0RHQcHkbBqzkdKhSB7xPXA0h4pTxRZ3dF0ckQlMmZR6Ak4x+GbMIk2rXiWC0glXMUHH 8sGsI5PhE5/FokqdOnVFsSFUs+6wqrVrixAAIfkEBTIAHwAsDwCAAHgACgAABf/g9x1UVSXieKXp 5b5H68qomMysatYpsdM2mEo4DKJgQuTsRrRlFFDFQAStsCrR6OrjibagW4Ni+81OP5SsgiASKwxo 70edab/tcPp6roa7s0dPGRUSYHxWPVAGiwaBWk6GYmQjgoRgF4qWY1xeXVBUioqccKNcf4sUfBmM E5yrbh5xmyQzVVdVJqmyA1KQd5K3swQuvBkxB09TYoVzhQqgVoV+d6UiWM8pmT/LLsmyOdDBUaRd HgWGmM4UwInYLMsp8GITa1KffAb0vfDV39lqK/48ugbuULBcqZBJwbQnHcMnkwjm4FdK0pt62Oig 4EdRIqh82wBCKkApA0lb7XJypOlDCc61WSNLFtDnqJXFT/e0xctJzV+4d7/ufXD2BxSgl1o8MbpE Td3EUDxXCbJzoRifn+0E7bEmVNW4odREjRBI0isYpGBQHkr3b9JYQL4Mge02hScicb1S/ssyjdS1 STgKCh5MeHBgIIUTF1HMWEQIACH5BAUyAB8ALA8AgAB4AAoAAAX/4Pdxy/Ms4regqbi+C5e+Kcmq cSuS5i2apxnNxoLdhjRjUomDtRaaaPQhmrYeUikLG51FWQiNT5XVUMnZc7jL1VTLb0T8U7bW5ess iiNto6wpbWt7ei5SMmE+fFODUIxfdIdtcWtUa3N5WpF5lnVUjnsniGZXUz2GZqRopIlPkByiXDKL nYl5b7Wbcz9dKX2njWFUsjqRZ7xwH1gnUTKOtmKlbjqXmKnLvX122b3K3ZuamZDE1KrIQIRmoGjP 0YHfu7rQYtyF1dXe03Ho4K/r64CQ6Wh3yFE+d6hQgOKicNuzSPuOERP2Tp+xcnLIiZtWp0RHQcHk bBqzkdKhSB7xPXA0h4pTxRZ3dF0ckQlMmZR6Ak4x+GbMIk2rXiWC0glXMUHH8sGsI5PhE5/Fokqd OnVFsSFUs+6wqrVrixAAIfkEBTIAHwAsDwCAAHgACgAABf/g9x1UVSXieKXp5b5H68qomMysatYp sdM2mEo4DKJgQuTsRrRlFFDFQAStsCrR6OrjibagW4Ni+81OP5SsgiASKwxo70edab/tcPp6roa7 s0dPGRUSYHxWPVAGiwaBWk6GYmQjgoRgF4qWY1xeXVBUioqccKNcf4sUfBmME5yrbh5xmyQzVVdV JqmyA1KQd5K3swQuvBkxB09TYoVzhQqgVoV+d6UiWM8pmT/LLsmyOdDBUaRdHgWGmM4UwInYLMsp 8GITa1KffAb0vfDV39lqK/48ugbuULBcqZBJwbQnHcMnkwjm4FdK0pt62Oig4EdRIqh82wBCKkAp A0lb7XJypOlDCc61WSNLFtDnqJXFT/e0xctJzV+4d7/ufXD2BxSgl1o8MbpETd3EUDxXCbJzoRif n+0E7bEmVNW4odREjRBI0isYpGBQHkr3b9JYQL4Mge02hScicb1S/ssyjdS1STgKCh5MeHBgIIUT F1HMWEQIACH5BAUyAB8ALA8AgAB4AAoAAAX/4Pdxy/Ms4regqbi+C5e+KcmqcSuS5i2apxnNxoLd hjRjUomDtRaaaPQhmrYeUikLG51FWQiNT5XVUMnZc7jL1VTLb0T8U7bW5essiiNto6wpbWt7ei5S MmE+fFODUIxfdIdtcWtUa3N5WpF5lnVUjnsniGZXUz2GZqRopIlPkByiXDKLnYl5b7Wbcz9dKX2n jWFUsjqRZ7xwH1gnUTKOtmKlbjqXmKnLvX122b3K3ZuamZDE1KrIQIRmoGjP0YHfu7rQYtyF1dXe 03Ho4K/r64CQ6Wh3yFE+d6hQgOKicNuzSPuOERP2Tp+xcnLIiZtWp0RHQcHkbBqzkdKhSB7xPXA0 h4pTxRZ3dF0ckQlMmZR6Ak4x+GbMIk2rXiWC0glXMUHH8sGsI5PhE5/FokqdOnVFsSFUs+6wqrVr ixAAIfkEBQoAHwAsAAAAAJYAmwAABf9g5o1kaZ5oqq5s675w/HZ0bd94ru987//AoNBn8QyPyKRy ydQdjM2odEodPqvYrFZ63Xq/4F03TC5rx+a0eoleu99EKHxOv7XrePc9zy/v+4Bef4GEVYOFiE2H iYxIi42QQI+RlGJylZiSl5mclp2fnqCiNpOjkKWmjKipiKushK6vgLGyfLS1eLe4dLq7cL2+epvB qsPErcbHsMnKs8zNts/QudLTvNXWv9jZwtzL3oHA4Fni44bb5mTl6Vzo7F/r70zx8kr09Y7u+Fj3 +0L9/jQFXANwYI+CBkMlVKdvIZuGHz44PIJwIimIEi0GqaixA8eIEzlqFGmRZMiGHf/soUwpkCU5 jC4PwoypkGY7m1RMZjSoc2HPhCYdBvW5EmeOoUCLGrWjFORSpDxnLq3xM+pURVKvQt3plOvOaR+d Jr06TylZqAPRBlTrj+0+t/jgihWbDW49u3PBVU2bderetWa1BvY7+Glho3blJX63mF3jdI/NRR43 We9hnJW9Zea2ue5lm52thQb7meZoaKebpVa2+lhrYq+DxfY1e1dtXLdr5Za1+1VvVr9TBTc1fFRx UcdBJf+0vFNzTs8zRcc0vVJ1StcjZT9VOub2Rt+LkX043p4BCwfSq1/Pvr379/Djy59Pv779+/Ip hAAAOw== --Java.XTHDS.1598437701462213-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 03:08: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 DAA10057 for ; Wed, 16 Feb 2005 03:08:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Ka7-0003aM-H6 for forces-archive@IETF.ORG; Wed, 16 Feb 2005 03:30: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 <2.00F91665@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 3:08:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58014023 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 03:08:44 -0500 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 03:08:43 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 6322.804536222; Wed, 16 Feb 2005 16:40:56 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 16 Feb 2005 16:07:50 +0800 References: 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 Approved-By: "Wang,Weiming" Message-ID: <010d01c513fe$8b52af80$845c21d2@Necom.hzic.edu.cn> Date: Wed, 16 Feb 2005 16:07:22 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue #3] Proposed resolution, issue #3 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi David, ----- Original Message ----- From: "Putzolu, David" Subject: [Issue #3] Proposed resolution, issue #3 All, I have received the following proposed issue resolution text for issue #3 in the tracker, and updated the tracker appropriately. If this resolution is unacceptable please state that on the list in the next week: Issue 3 (editorial changes) -------------------------- Text Mod... "The ForCES query and query response messages are used by ForCES elements (CE or FE) to query LFBs in other ForCES element(s)." [Weiming] As a general description text, I don't know why we need specifically say "to query LFBs" here. Just feel a little not very fluent when the word "LFB" appears suddenly. 6.4.1 The Operation TLV for the 'Query' message is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Operation = GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path to queried data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Weiming] If we only use 'Path' here, we should define what a pure 'Path' is. Does it include the selector part and sub nested Path-DATAs? Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 07:05: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 HAA00080 for ; Wed, 16 Feb 2005 07:05:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1OHK-0001dS-Cq for forces-archive@IETF.ORG; Wed, 16 Feb 2005 07:27: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 <19.00F91CE5@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 7:05:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58054924 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 07:05:37 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 07:05:37 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9212455 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 07:05:37 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050216070034.033d76c0@localhost> Date: Wed, 16 Feb 2005 07:04:50 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Another aspect of nested path-data To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 I realized after my last note that there was another use we were making of nested path-data. This use does not strictly require nesting more than one path-data per level, but would be awkward to handle without any nesting. We are using nesting to flexibly support content keying on tables. To avoid ambiguity in when a table reference has a subscript, while still keeping the references in order (and allowing subscripting in the actual path) we ave specified that content keying (KEY TLVs) is always associated with the end of the path of the path-data. (For robustness we have also used a flag to indicate that such is being used.) For this to be workable, so that one can do content keying and still select fields (or even inner array elements) past where the content key is used, we use nested path-data. Using this with multiple path-data at the next level allows the content key (which contributes noticeably to the number of bytes in the path) to be shared by all of the directly nested path-data TLVs. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 11:31: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 LAA12580 for ; Wed, 16 Feb 2005 11:31:02 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1SQ8-0005Jb-Qw for forces-archive@IETF.ORG; Wed, 16 Feb 2005 11:53:05 -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 <22.00F927E7@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 11:30:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58083607 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 11:30:57 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 11:30: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 2005021608314842:2 ; Wed, 16 Feb 2005 08:31:48 -0800 References: <468F3FDA28AA87429AD807992E22D07E0446D2F9@orsmsx408> <6.2.1.2.0.20050215212407.03225e58@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 02/16/2005 08:31:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/16/2005 08:31:51 AM, Serialize complete at 02/16/2005 08:31:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108571448.1072.167.camel@jzny.localdomain> Date: Wed, 16 Feb 2005 11:30:52 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050215212407.03225e58@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Folks, First off let me say that the next release of the draft(which i am editing as we speak) will leave out using BLK selector. That does not mean it is dead; it just means its defered so we can make progress. Despite leaving out BLK, I have to say Iam pleased at the progress we made - thanks to everyone who chipped in. We do have finally something i would almost call usable and semi-agreeable to all. I am hoping any changes going forward (including BLK if we find it usable) will not deviate us from the main BNF and layout and will be mostly cosmetic in nature. Its always great to make progress in the presence of many good ideas. So thanks again. So this email is not about what goes into upcoming draft. However, since the discussion continues on the BLK avenue, I am going to contribute since i am a fan of BLK. 1) Efficiency factor. Is there anyone _doubting_ that BLK is more efficient for row table operations than without it? If there is i will provide the proof numbers. An average BLK operation will be cheaper on the wire than non-BLK and will have at least one less nest level. So BLK wins down both in b/width and parsing/compute. Again, if anyone wishes to contend this let me know so i can provide the numbers. If noone contends this, lkets cut the discussions and never bring it up but assume it for any future discussion. 2) Ambiguity: Theres none really as far as i am concerned. Its a difference of opinion more than anything else between Joel and myself. Joel has a certain view of what it means to follow a selector. which is different from mine. Maybe this is the most important thing that we need to be discussing. 3) simplicty. I fail to see this being used as an arguement for non-BLK. Lets take an average example (any other examples of the same nature would look similar - some would make BLK look better but they are corner cases as far as i am concerned): "create entry 0-5 of table2" I) Using BLK selector Path-data TLV: flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 BLK_RANGE_INDEX TLV start = 0 end = 5 DATARAW TLV: L = XXX, V= j1value,j2value entries (6 in total) II) not using BLK selector Path-data-TLV: flags = 0 , IDCount = 1, IDs=4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 0 DATARAW-TLV containing j1, j2 value for 0 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 1 DATARAW-TLV containing j1, j2 value for 1 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 2 DATARAW-TLV containing j1, j2 value for 2 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 3 DATARAW-TLV containing j1, j2 value for 3 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 4 DATARAW-TLV containing j1, j2 value for 4 PATH-DATA-TLV flags = 0, IDCount = 1, IDs = 5 DATARAW-TLV containing j1, j2 value for 5 So which one is simpler? To be honest i dont see them being that different to the machine parsing them - to the human eye the BLK one is good candy, but i wouldnt use this as a strength for BLK; so we probably shouldnt be discussing this "simplicty" angle either. This leaves us with #2 and #1 being a trump in favor of BLK. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 15:22: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 PAA17656 for ; Wed, 16 Feb 2005 15:22:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W25-0000JY-7N for forces-archive@IETF.ORG; Wed, 16 Feb 2005 15:44: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 <21.00F9306D@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 15:22:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58114194 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 15:22:17 -0500 Received: from 192.55.52.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 15:22:17 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.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 j1GKMGOk019954; Wed, 16 Feb 2005 20:22:16 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.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 j1GKLTcx020275; Wed, 16 Feb 2005 20:22:16 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021612221600766 ; Wed, 16 Feb 2005 12:22:16 -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, 16 Feb 2005 12:22: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] On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Thread-Index: AcUUROp1zdLS/IYmRjCJ3CCrRy/ikgAH/xKA X-OriginalArrivalTime: 16 Feb 2005 20:22:14.0350 (UTC) FILETIME=[33D0C6E0:01C51465] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0446DF06@orsmsx408> Date: Wed, 16 Feb 2005 12:22:13 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Jamal, Another contentious issue that you pointed me to was using KEY and BLK selector in the same Op TLV. Is this still contentious ? I agree with Joel's view that these cannot be combined. Do we have agreement on this ? 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, February 16, 2005 8:31 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Folks, First off let me say that the next release of the draft(which i am editing as we speak) will leave out using BLK selector. That does not mean it is dead; it just means its defered so we can make progress.=20 Despite leaving out BLK, I have to say Iam pleased at the progress we made - thanks to everyone who chipped in. We do have finally something i would almost call usable and semi-agreeable to all.=20 I am hoping any changes going forward (including BLK if we find it usable) will not deviate us from the main BNF and layout and will be mostly cosmetic in nature. =20 Its always great to make progress in the presence of many good ideas.=20 So thanks again. So this email is not about what goes into upcoming draft. However, since the discussion continues on the BLK avenue, I am going to contribute since i am a fan of BLK. 1) Efficiency factor. Is there anyone _doubting_ that BLK is more efficient for row table operations than without it? If there is i will provide the proof numbers. An average BLK operation will be cheaper on the wire than non-BLK and will have at least one less nest level. So BLK wins down both in b/width and parsing/compute. Again, if anyone wishes to contend this let me know so i can provide the numbers. If noone contends this, lkets cut the discussions and never bring it up but assume it for any future discussion. 2) Ambiguity: Theres none really as far as i am concerned. Its a difference of opinion more than anything else between Joel and myself. Joel has a certain view of what it means to follow a selector. which is different from mine.=20 Maybe this is the most important thing that we need to be discussing. 3) simplicty. I fail to see this being used as an arguement for non-BLK.=20 Lets take an average example (any other examples of the same nature would look similar - some would make BLK look better but they are corner cases as far as i am concerned): "create entry 0-5 of table2" I) Using BLK selector Path-data TLV:=20 flags =3D F_CREATE | F_SELBLK , IDCount =3D 1, IDs=3D4 BLK_RANGE_INDEX TLV start =3D 0 end =3D 5 DATARAW TLV: L =3D XXX, V=3D j1value,j2value entries (6 in total) II) not using BLK selector Path-data-TLV:=20 flags =3D 0 , IDCount =3D 1, IDs=3D4 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 0 DATARAW-TLV containing j1, j2 value for 0 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 1 DATARAW-TLV containing j1, j2 value for 1 =20 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 2 DATARAW-TLV containing j1, j2 value for 2 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 3 DATARAW-TLV containing j1, j2 value for 3 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 4 DATARAW-TLV containing j1, j2 value for 4=20 PATH-DATA-TLV flags =3D 0, IDCount =3D 1, IDs =3D 5 DATARAW-TLV containing j1, j2 value for 5 So which one is simpler? To be honest i dont see them being that different to the machine parsing them - to the human eye the BLK one is good candy, but i wouldnt use this as a strength for BLK;=20 so we probably shouldnt be discussing this "simplicty" angle either. This leaves us with #2 and #1 being a trump in favor of BLK. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 15:34:04 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 PAA20045 for ; Wed, 16 Feb 2005 15:34:03 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WDE-00010y-Fk for forces-archive@IETF.ORG; Wed, 16 Feb 2005 15:56:08 -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.00F92FBB@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 15:33:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58115599 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 15:33:50 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 15:33:46 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021612343533:684 ; Wed, 16 Feb 2005 12:34:35 -0800 References: <468F3FDA28AA87429AD807992E22D07E0446DF06@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 02/16/2005 12:34:35 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/16/2005 12:34:43 PM, Serialize complete at 02/16/2005 12:34:43 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108586019.1073.188.camel@jzny.localdomain> Date: Wed, 16 Feb 2005 15:33:39 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0446DF06@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit I dont think theres any contention on this issue. Maybe Weiming didnt like it? I dont remember. The short answer is yes, this is the way it is and the update to the draft will only mention BLK once and say this as well. cheers, jamal On Wed, 2005-02-16 at 15:22, Khosravi, Hormuzd M wrote: > Jamal, > > Another contentious issue that you pointed me to was using KEY and BLK > selector in the same Op TLV. Is this still contentious ? I agree with > Joel's view that these cannot be combined. > > Do we have agreement on this ? > > Thanks > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 16, 2005 8:31 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? > > Folks, > > First off let me say that the next release of the draft(which i am > editing as we speak) will leave out using BLK selector. That does not > mean it is dead; it just means its defered so we can make progress. > > Despite leaving out BLK, I have to say Iam pleased at the progress we > made - thanks to everyone who chipped in. We do have finally something i > would almost call usable and semi-agreeable to all. > I am hoping any changes going forward (including BLK if we find it > usable) will not deviate us from the main BNF and layout and will be > mostly cosmetic in nature. > > Its always great to make progress in the presence of many good ideas. > So thanks again. > > So this email is not about what goes into upcoming draft. > However, since the discussion continues on the BLK avenue, I am going to > contribute since i am a fan of BLK. > > 1) Efficiency factor. > Is there anyone _doubting_ that BLK is more efficient for row table > operations than without it? If there is i will provide the proof > numbers. > An average BLK operation will be cheaper on the wire > than non-BLK and will have at least one less nest level. > So BLK wins down both in b/width and parsing/compute. > > Again, if anyone wishes to contend this let me know so i can provide the > numbers. If noone contends this, lkets cut the discussions and never > bring it up but assume it for any future discussion. > > 2) Ambiguity: > Theres none really as far as i am concerned. Its a difference of opinion > > more than anything else between Joel and myself. > Joel has a certain view of what it means to follow a selector. > which is different from mine. > Maybe this is the most important thing that we need to be discussing. > > 3) simplicty. > I fail to see this being used as an arguement for non-BLK. > Lets take an average example (any other examples of the same nature > would look > similar - some would make BLK look better but they are corner cases as > far as i am concerned): > > "create entry 0-5 of table2" > I) Using BLK selector > > Path-data TLV: > flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 > BLK_RANGE_INDEX TLV > start = 0 > end = 5 > DATARAW TLV: L = XXX, V= > j1value,j2value entries (6 in total) > > II) not using BLK selector > > Path-data-TLV: > flags = 0 , IDCount = 1, IDs=4 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 0 > DATARAW-TLV containing j1, j2 value for 0 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 1 > DATARAW-TLV containing j1, j2 value for 1 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 2 > DATARAW-TLV containing j1, j2 value for 2 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 3 > DATARAW-TLV containing j1, j2 value for 3 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 4 > DATARAW-TLV containing j1, j2 value for 4 > PATH-DATA-TLV > flags = 0, IDCount = 1, IDs = 5 > DATARAW-TLV containing j1, j2 value for 5 > > > So which one is simpler? > To be honest i dont see them being that different to the machine parsing > them - to the human eye the BLK one is good candy, but i wouldnt use > this > as a strength for BLK; > so we probably shouldnt be discussing this "simplicty" angle either. > > This leaves us with #2 and #1 being a trump in favor of BLK. > > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 18:05:50 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 SAA08205 for ; Wed, 16 Feb 2005 18:05:50 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YaK-0006FX-RG for forces-archive@IETF.ORG; Wed, 16 Feb 2005 18:27: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 <13.00F9374F@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 18:05:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58129789 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 18:04:40 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 18:04:40 -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 j1GN4dKg028209; Wed, 16 Feb 2005 23:04:39 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1GN4bI8014064; Wed, 16 Feb 2005 23:04:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021615043923327 ; Wed, 16 Feb 2005 15:04:39 -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, 16 Feb 2005 15:04:39 -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] On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Thread-Index: AcUUZtzmDAbZEtWiS4aTIrbxoYnVMQAFKO0g X-OriginalArrivalTime: 16 Feb 2005 23:04:39.0610 (UTC) FILETIME=[E47171A0:01C5147B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E044A098D@orsmsx408> Date: Wed, 16 Feb 2005 15:04:38 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable I don't think Weiming had any comments on this one. So just to clarify, what you're saying is that "The KEY and BLK selectors cannot be combined in the same Op TLV". I think we are all on the same page, if this is the case. Thanks for the clarification, Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Wednesday, February 16, 2005 12:34 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? I dont think theres any contention on this issue. Maybe Weiming didnt like it? I dont remember. The short answer is=20 yes, this is the way it is and the update to the draft will only mention BLK once and say this as well. cheers, jamal On Wed, 2005-02-16 at 15:22, Khosravi, Hormuzd M wrote: > Jamal, >=20 > Another contentious issue that you pointed me to was using KEY and BLK > selector in the same Op TLV. Is this still contentious ? I agree with > Joel's view that these cannot be combined. >=20 > Do we have agreement on this ? >=20 > Thanks > Hormuzd=20 >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 16, 2005 8:31 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? >=20 > Folks, >=20 > First off let me say that the next release of the draft(which i am > editing as we speak) will leave out using BLK selector. That does not > mean it is dead; it just means its defered so we can make progress.=20 >=20 > Despite leaving out BLK, I have to say Iam pleased at the progress we > made - thanks to everyone who chipped in. We do have finally something i > would almost call usable and semi-agreeable to all.=20 > I am hoping any changes going forward (including BLK if we find it > usable) will not deviate us from the main BNF and layout and will be > mostly cosmetic in nature. > =20 > Its always great to make progress in the presence of many good ideas.=20 > So thanks again. >=20 > So this email is not about what goes into upcoming draft. > However, since the discussion continues on the BLK avenue, I am going to > contribute since i am a fan of BLK. >=20 > 1) Efficiency factor. > Is there anyone _doubting_ that BLK is more efficient for row table > operations than without it? If there is i will provide the proof > numbers. > An average BLK operation will be cheaper on the wire > than non-BLK and will have at least one less nest level. > So BLK wins down both in b/width and parsing/compute. >=20 > Again, if anyone wishes to contend this let me know so i can provide the > numbers. If noone contends this, lkets cut the discussions and never > bring it up but assume it for any future discussion. >=20 > 2) Ambiguity: > Theres none really as far as i am concerned. Its a difference of opinion >=20 > more than anything else between Joel and myself. > Joel has a certain view of what it means to follow a selector. > which is different from mine.=20 > Maybe this is the most important thing that we need to be discussing. >=20 > 3) simplicty. > I fail to see this being used as an arguement for non-BLK.=20 > Lets take an average example (any other examples of the same nature > would look > similar - some would make BLK look better but they are corner cases as > far as i am concerned): >=20 > "create entry 0-5 of table2" > I) Using BLK selector >=20 > Path-data TLV:=20 > flags =3D F_CREATE | F_SELBLK , IDCount =3D 1, IDs=3D4 > BLK_RANGE_INDEX TLV > start =3D 0 > end =3D 5 > DATARAW TLV: L =3D XXX, V=3D > j1value,j2value entries (6 in total) >=20 > II) not using BLK selector >=20 > Path-data-TLV:=20 > flags =3D 0 , IDCount =3D 1, IDs=3D4 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 0 > DATARAW-TLV containing j1, j2 value for 0 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 1 > DATARAW-TLV containing j1, j2 value for 1 =20 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 2 > DATARAW-TLV containing j1, j2 value for 2 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 3 > DATARAW-TLV containing j1, j2 value for 3 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 4 > DATARAW-TLV containing j1, j2 value for 4=20 > PATH-DATA-TLV > flags =3D 0, IDCount =3D 1, IDs =3D 5 > DATARAW-TLV containing j1, j2 value for 5 >=20 >=20 > So which one is simpler? > To be honest i dont see them being that different to the machine parsing > them - to the human eye the BLK one is good candy, but i wouldnt use > this > as a strength for BLK;=20 > so we probably shouldnt be discussing this "simplicty" angle either. >=20 > This leaves us with #2 and #1 being a trump in favor of BLK. >=20 >=20 > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 18:28: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 SAA11053 for ; Wed, 16 Feb 2005 18:28:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Yvw-0006oy-Na for forces-archive@IETF.ORG; Wed, 16 Feb 2005 18:50:18 -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.00F93854@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 18:28:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58130370 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 18:17:50 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 18:17:49 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005021615184240:865 ; Wed, 16 Feb 2005 15:18:42 -0800 References: <468F3FDA28AA87429AD807992E22D07E044A098D@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 02/16/2005 03:18:43 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/16/2005 03:18:44 PM, Serialize complete at 02/16/2005 03:18:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108595866.1061.26.camel@jzny.localdomain> Date: Wed, 16 Feb 2005 18:17:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E044A098D@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Sorry, no. My mistake. They cannot be in the same PATH-DATA under the same SELCTOR. But they can be in the same OPER TLV. When we started we allowed for them to appear in the same SELECTOR. Thats what Joel was asking for. cheers, jamal On Wed, 2005-02-16 at 18:04, Khosravi, Hormuzd M wrote: > I don't think Weiming had any comments on this one. > > So just to clarify, what you're saying is that "The KEY and BLK > selectors cannot be combined in the same Op TLV". I think we are all on > the same page, if this is the case. > > Thanks for the clarification, > Hormuzd > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Wednesday, February 16, 2005 12:34 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] On efficiency, ambiguity, and simplicty of BLK > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? > > I dont think theres any contention on this issue. > Maybe Weiming didnt like it? I dont remember. The short answer is > yes, this is the way it is and the update to the draft will only > mention BLK once and say this as well. > > cheers, > jamal > > On Wed, 2005-02-16 at 15:22, Khosravi, Hormuzd M wrote: > > Jamal, > > > > Another contentious issue that you pointed me to was using KEY and BLK > > selector in the same Op TLV. Is this still contentious ? I agree with > > Joel's view that these cannot be combined. > > > > Do we have agreement on this ? > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Wednesday, February 16, 2005 8:31 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK > > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? > > > > Folks, > > > > First off let me say that the next release of the draft(which i am > > editing as we speak) will leave out using BLK selector. That does not > > mean it is dead; it just means its defered so we can make progress. > > > > Despite leaving out BLK, I have to say Iam pleased at the progress we > > made - thanks to everyone who chipped in. We do have finally something > i > > would almost call usable and semi-agreeable to all. > > I am hoping any changes going forward (including BLK if we find it > > usable) will not deviate us from the main BNF and layout and will be > > mostly cosmetic in nature. > > > > Its always great to make progress in the presence of many good ideas. > > So thanks again. > > > > So this email is not about what goes into upcoming draft. > > However, since the discussion continues on the BLK avenue, I am going > to > > contribute since i am a fan of BLK. > > > > 1) Efficiency factor. > > Is there anyone _doubting_ that BLK is more efficient for row table > > operations than without it? If there is i will provide the proof > > numbers. > > An average BLK operation will be cheaper on the wire > > than non-BLK and will have at least one less nest level. > > So BLK wins down both in b/width and parsing/compute. > > > > Again, if anyone wishes to contend this let me know so i can provide > the > > numbers. If noone contends this, lkets cut the discussions and never > > bring it up but assume it for any future discussion. > > > > 2) Ambiguity: > > Theres none really as far as i am concerned. Its a difference of > opinion > > > > more than anything else between Joel and myself. > > Joel has a certain view of what it means to follow a selector. > > which is different from mine. > > Maybe this is the most important thing that we need to be discussing. > > > > 3) simplicty. > > I fail to see this being used as an arguement for non-BLK. > > Lets take an average example (any other examples of the same nature > > would look > > similar - some would make BLK look better but they are corner cases as > > far as i am concerned): > > > > "create entry 0-5 of table2" > > I) Using BLK selector > > > > Path-data TLV: > > flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 > > BLK_RANGE_INDEX TLV > > start = 0 > > end = 5 > > DATARAW TLV: L = XXX, V= > > j1value,j2value entries (6 in total) > > > > II) not using BLK selector > > > > Path-data-TLV: > > flags = 0 , IDCount = 1, IDs=4 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 0 > > DATARAW-TLV containing j1, j2 value for 0 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 1 > > DATARAW-TLV containing j1, j2 value for 1 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 2 > > DATARAW-TLV containing j1, j2 value for 2 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 3 > > DATARAW-TLV containing j1, j2 value for 3 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 4 > > DATARAW-TLV containing j1, j2 value for 4 > > PATH-DATA-TLV > > flags = 0, IDCount = 1, IDs = 5 > > DATARAW-TLV containing j1, j2 value for 5 > > > > > > So which one is simpler? > > To be honest i dont see them being that different to the machine > parsing > > them - to the human eye the BLK one is good candy, but i wouldnt use > > this > > as a strength for BLK; > > so we probably shouldnt be discussing this "simplicty" angle either. > > > > This leaves us with #2 and #1 being a trump in favor of BLK. > > > > > > cheers, > > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 16 20:30: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 UAA22867 for ; Wed, 16 Feb 2005 20:30:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1apu-0001mi-Ha for forces-archive@IETF.ORG; Wed, 16 Feb 2005 20:52:12 -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.00F93F6E@cherry.ease.lsoft.com>; Wed, 16 Feb 2005 20:30:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58139095 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 20:30:03 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Feb 2005 20:30:03 -0500 Received: from [69.170.19.42] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9220798 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 16 Feb 2005 20:30:02 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E044A098D@orsmsx408> <1108595866.1061.26.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050216202732.03262488@localhost> Date: Wed, 16 Feb 2005 20:29:41 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: On efficiency, ambiguity, and simplicty of BLK Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1108595866.1061.26.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 As you say, when a selector is allowed to have BLK again, the rule will be that you can not have both KEY and BLK as immediate descendents in the same PATH-DATA. There can certainly be two path-datas in the same OP, one with KEY, one with BLK, (and more). And one can even have a PATH-DATA with a BLK, and nested PATH-DATAs, one or more of which have KEYs. (or the reverse, etc.) Yours, Joel PS: All that is required to capture this is that the Selector BNF line will be an or: SELECTOR := KEYINFO-TLV / BLOCK-SELECTION-TLV At 06:17 PM 2/16/2005, Jamal Hadi Salim wrote: >Sorry, no. My mistake. >They cannot be in the same PATH-DATA under the same SELCTOR. But they >can be in the same OPER TLV. When we started we allowed for them to >appear in the same SELECTOR. Thats what Joel was asking for. > >cheers, >jamal > >On Wed, 2005-02-16 at 18:04, Khosravi, Hormuzd M wrote: > > I don't think Weiming had any comments on this one. > > > > So just to clarify, what you're saying is that "The KEY and BLK > > selectors cannot be combined in the same Op TLV". I think we are all on > > the same page, if this is the case. > > > > Thanks for the clarification, > > Hormuzd > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Sent: Wednesday, February 16, 2005 12:34 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] On efficiency, ambiguity, and simplicty of BLK > > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? > > > > I dont think theres any contention on this issue. > > Maybe Weiming didnt like it? I dont remember. The short answer is > > yes, this is the way it is and the update to the draft will only > > mention BLK once and say this as well. > > > > cheers, > > jamal > > > > On Wed, 2005-02-16 at 15:22, Khosravi, Hormuzd M wrote: > > > Jamal, > > > > > > Another contentious issue that you pointed me to was using KEY and BLK > > > selector in the same Op TLV. Is this still contentious ? I agree with > > > Joel's view that these cannot be combined. > > > > > > Do we have agreement on this ? > > > > > > Thanks > > > Hormuzd > > > > > > -----Original Message----- > > > From: Forwarding and Control Element Separation > > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > Sent: Wednesday, February 16, 2005 8:31 AM > > > To: FORCES@PEACH.EASE.LSOFT.COM > > > Subject: [FORCES] On efficiency, ambiguity, and simplicty of BLK > > > Selector WAS(Re: Ambiguity in BLOCK semantics-some qs? > > > > > > Folks, > > > > > > First off let me say that the next release of the draft(which i am > > > editing as we speak) will leave out using BLK selector. That does not > > > mean it is dead; it just means its defered so we can make progress. > > > > > > Despite leaving out BLK, I have to say Iam pleased at the progress we > > > made - thanks to everyone who chipped in. We do have finally something > > i > > > would almost call usable and semi-agreeable to all. > > > I am hoping any changes going forward (including BLK if we find it > > > usable) will not deviate us from the main BNF and layout and will be > > > mostly cosmetic in nature. > > > > > > Its always great to make progress in the presence of many good ideas. > > > So thanks again. > > > > > > So this email is not about what goes into upcoming draft. > > > However, since the discussion continues on the BLK avenue, I am going > > to > > > contribute since i am a fan of BLK. > > > > > > 1) Efficiency factor. > > > Is there anyone _doubting_ that BLK is more efficient for row table > > > operations than without it? If there is i will provide the proof > > > numbers. > > > An average BLK operation will be cheaper on the wire > > > than non-BLK and will have at least one less nest level. > > > So BLK wins down both in b/width and parsing/compute. > > > > > > Again, if anyone wishes to contend this let me know so i can provide > > the > > > numbers. If noone contends this, lkets cut the discussions and never > > > bring it up but assume it for any future discussion. > > > > > > 2) Ambiguity: > > > Theres none really as far as i am concerned. Its a difference of > > opinion > > > > > > more than anything else between Joel and myself. > > > Joel has a certain view of what it means to follow a selector. > > > which is different from mine. > > > Maybe this is the most important thing that we need to be discussing. > > > > > > 3) simplicty. > > > I fail to see this being used as an arguement for non-BLK. > > > Lets take an average example (any other examples of the same nature > > > would look > > > similar - some would make BLK look better but they are corner cases as > > > far as i am concerned): > > > > > > "create entry 0-5 of table2" > > > I) Using BLK selector > > > > > > Path-data TLV: > > > flags = F_CREATE | F_SELBLK , IDCount = 1, IDs=4 > > > BLK_RANGE_INDEX TLV > > > start = 0 > > > end = 5 > > > DATARAW TLV: L = XXX, V= > > > j1value,j2value entries (6 in total) > > > > > > II) not using BLK selector > > > > > > Path-data-TLV: > > > flags = 0 , IDCount = 1, IDs=4 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 0 > > > DATARAW-TLV containing j1, j2 value for 0 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 1 > > > DATARAW-TLV containing j1, j2 value for 1 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 2 > > > DATARAW-TLV containing j1, j2 value for 2 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 3 > > > DATARAW-TLV containing j1, j2 value for 3 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 4 > > > DATARAW-TLV containing j1, j2 value for 4 > > > PATH-DATA-TLV > > > flags = 0, IDCount = 1, IDs = 5 > > > DATARAW-TLV containing j1, j2 value for 5 > > > > > > > > > So which one is simpler? > > > To be honest i dont see them being that different to the machine > > parsing > > > them - to the human eye the BLK one is good candy, but i wouldnt use > > > this > > > as a strength for BLK; > > > so we probably shouldnt be discussing this "simplicty" angle either. > > > > > > This leaves us with #2 and #1 being a trump in favor of BLK. > > > > > > > > > cheers, > > > jamal From kera6nfu@kati.com Thu Feb 17 05:30: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 FAA03756; Thu, 17 Feb 2005 05:30:46 -0500 (EST) Received: from usen-221x255x150x211.ap-us01.usen.ad.jp ([221.255.150.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1jHD-0006ch-QA; Thu, 17 Feb 2005 05:52:57 -0500 Received: from angela.kera6nfu@kati.com ([132.151.6.1]) by splotch.kera6nfu@kati.com with MailEnable ESMTP; Thu, 17 Feb 2005 04:30:30 -0600 Date: Thu, 17 Feb 2005 04:30:30 -0600 Message-Id: <766000812440.98129@dagian> From: augnete cooke To: Discuss Subject: CiaIis - Stable Erections MIME-Version: 1.0 Content-Type: text/plain; charset="iso-6055-4" Content-Transfer-Encoding: 7Bit Content-Description: alphabet divergent docile X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7Bit Special offer! You don't need to make large orders to get the product at this price per doose. All the prices mentioned are retail prices! One Time DISC0UNT 0RDER for CiaIis And Wiaggra! ToDAY CiaIis only 3.00 per doose.Wiaggra is 0.87 per doose. The Cheapest Pharm On The Net That offers CiaIis ,Wiaggra Xonax ,M3ridia ,Pr0zac ,S0ma ,Pr0opecia And Many Meds... http://www.ultrameds4sale.com From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 18 13:27: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 NAA18093 for ; Fri, 18 Feb 2005 13:27:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2DBi-0004Vu-3j for forces-archive@IETF.ORG; Fri, 18 Feb 2005 13:49: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 <15.00FA8111@cherry.ease.lsoft.com>; Fri, 18 Feb 2005 13:26:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58487513 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 18 Feb 2005 13:26:35 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Feb 2005 13:26:32 -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 j1IIQWtp025477 for ; Fri, 18 Feb 2005 18:26: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 j1IIPJ04018367 for ; Fri, 18 Feb 2005 18:26:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005021809291802240 for ; Fri, 18 Feb 2005 09:29:19 -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); Fri, 18 Feb 2005 09:29:15 -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_01C515DF.5E1F2596" X-MS-Has-Attach: yes Thread-Topic: latest version of the model draft Thread-Index: AcUV36IbSFSaf+TwQ0qIlLVLKkTkIw== X-OriginalArrivalTime: 18 Feb 2005 17:29:15.0719 (UTC) FILETIME=[5E7EDD70:01C515DF] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E044D4568@orsmsx408> Date: Fri, 18 Feb 2005 09:31:09 -0800 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: latest version of the model draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.7 (/) X-Scan-Signature: efc1d63eba2748519780c8bd02913942 This is a multi-part message in MIME format. ------_=_NextPart_001_01C515DF.5E1F2596 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C515DF.5E1F2596" ------_=_NextPart_002_01C515DF.5E1F2596 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Joel and the model team for the comments, here is the latest version of the model draft. If there are no further issues, I plan to upload this version to the I-D site. (I won't have access to the internet over the weekend). =20 Regards, Ellen ------_=_NextPart_002_01C515DF.5E1F2596 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Joel and the model team for = the comments, here is the latest version of the model draft. If there are no further issues, I plan to upload this version to the I-D site. (I = won’t have access to the internet over the weekend).

 

Regards,

Ellen

------_=_NextPart_002_01C515DF.5E1F2596-- ------_=_NextPart_001_01C515DF.5E1F2596 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 ICAgICAgICAgICAgICBMLiBZYW5nIA0KICAgICAgRXhwaXJhdGlvbjogQXVndXN0IDIwMDUgICAg ICAgICAgICAgICAgICAgICAgICAgICBJbnRlbCBDb3JwLiANCiAgICAgIEZpbGU6IGRyYWZ0LWll dGYtZm9yY2VzLW1vZGVsLTA0LnR4dCAgICAgICAgIEouIEhhbHBlcm4gDQogICAgICBXb3JraW5n IEdyb3VwOiBGb3JDRVMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1lZ2lzdG8gU3lzdGVt cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4g R29wYWwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE5va2lhIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQS4gRGVLb2sgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEluZm9ibG94LCBJbmMuIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWi4gSGFyYXN6dGkgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBCbGFrZSAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vZHVs YXIgTmV0d29ya3MgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFLiBEZWxlZ2FuZXMgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEludGVsIENvcnAuIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgIEZvckNFUyBGb3J3YXJkaW5nIEVsZW1lbnQgTW9kZWwgDQogICAg DQogICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWZvcmNlcy1tb2Rl bC0wNC50eHQgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICAgDQogICAgICBTdGF0 dXMgb2YgdGhpcyBNZW1vIA0KICAgICAgIA0KICAgICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRl cm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KICAgICAgYWxsIHBy b3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSAN CiAgICAgIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNr IEZvcmNlIChJRVRGKSwgDQogICAgICBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMu ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSANCiAgICAgIGFsc28gZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIA0KICAgICAgIA0KICAgICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg DQogICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIA0KICAgICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIA0KICAgICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzIGBgd29yayBpbiANCiAgICAgIHByb2dyZXNz LicnIA0KICAgICAgIA0KICAgICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1h YnN0cmFjdHMudHh0LiANCiAgICAgICANCiAgICAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgIA0KICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAgICAgDQogICBBYnN0cmFjdCANCiAgICAgICAN CiAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9yd2FyZGluZyBlbGVtZW50IChGRSkg bW9kZWwgdXNlZCBpbiANCiAgICAgIHRoZSBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQg U2VwYXJhdGlvbiAoRm9yQ0VTKSBwcm90b2NvbC4gIA0KICAgICAgVGhlIG1vZGVsIHJlcHJlc2Vu dHMgdGhlIGNhcGFiaWxpdGllcywgc3RhdGUgYW5kIGNvbmZpZ3VyYXRpb24gb2YgDQogICAgICBm b3J3YXJkaW5nIGVsZW1lbnRzIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgRm9yQ0VTIHByb3Rv Y29sLCBzbyANCiAgICANCiAgICANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBG RSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICB0aGF0 IGNvbnRyb2wgZWxlbWVudHMgKENFcykgY2FuIGNvbnRyb2wgdGhlIEZFcyBhY2NvcmRpbmdseS4g IE1vcmUgDQogICAgICBzcGVjaWZpY2FsbHksIHRoZSBtb2RlbCBkZXNjcmliZXMgdGhlIGxvZ2lj YWwgZnVuY3Rpb25zIHRoYXQgYXJlIA0KICAgICAgcHJlc2VudCBpbiBhbiBGRSwgd2hhdCBjYXBh YmlsaXRpZXMgdGhlc2UgZnVuY3Rpb25zIHN1cHBvcnQsIGFuZCANCiAgICAgIGhvdyB0aGVzZSBm dW5jdGlvbnMgYXJlIG9yIGNhbiBiZSBpbnRlcmNvbm5lY3RlZC4gIFRoaXMgRkUgbW9kZWwgDQog ICAgICBpcyBpbnRlbmRlZCB0byBzYXRpc2Z5IHRoZSBtb2RlbCByZXF1aXJlbWVudHMgc3BlY2lm aWVkIGluIHRoZSANCiAgICAgIEZvckNFUyByZXF1aXJlbWVudHMgZHJhZnQsIFJGQyAzNTY0IFsx XS4gIEEgbGlzdCBvZiB0aGUgYmFzaWMgDQogICAgICBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tz IChMRkJzKSBpcyBhbHNvIGRlZmluZWQgaW4gdGhlIExGQiBjbGFzcyANCiAgICAgIGxpYnJhcnkg dG8gYWlkIHRoZSBlZmZvcnQgaW4gZGVmaW5pbmcgaW5kaXZpZHVhbCBMRkJzLiAgDQogICAgICAg DQogICBUYWJsZSBvZiBDb250ZW50cyAgDQogICAgDQogICAgICBBYnN0cmFjdC4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEgDQogICAgICAx LiBEZWZpbml0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQgDQogICAgICAyLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICAgICAgICAyLjEuIFJlcXVpcmVtZW50cyBv biB0aGUgRkUgbW9kZWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICAgICAgICAy LjIuIFRoZSBGRSBNb2RlbCBpbiBSZWxhdGlvbiB0byBGRSBJbXBsZW1lbnRhdGlvbnMuLi4uLi4u Li4uLjYgDQogICAgICAgICAyLjMuIFRoZSBGRSBNb2RlbCBpbiBSZWxhdGlvbiB0byB0aGUgRm9y Q0VTIFByb3RvY29sLi4uLi4uLi4uLjcgDQogICAgICAgICAyLjQuIE1vZGVsaW5nIExhbmd1YWdl IGZvciB0aGUgRkUgTW9kZWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAgICAyLjUu IERvY3VtZW50IFN0cnVjdHVyZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjggDQogICAgICAzLiBGRSBNb2RlbCBDb25jZXB0cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAgICAzLjEuIEZFIENhcGFiaWxpdHkgTW9kZWwg YW5kIFN0YXRlIE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAgICAzLjIuIExG QiAoTG9naWNhbCBGdW5jdGlvbmFsIEJsb2NrKSBNb2RlbGluZy4uLi4uLi4uLi4uLi4uLi4uMTEg DQogICAgICAgICAgICAzLjIuMS4gTEZCIE91dHB1dHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTMgDQogICAgICAgICAgICAzLjIuMi4gTEZCIElucHV0cy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgDQogICAgICAgICAgICAzLjIuMy4g UGFja2V0IFR5cGUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkgDQog ICAgICAgICAgICAzLjIuNC4gTWV0YWRhdGEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjAgDQogICAgICAgICAgICAzLjIuNS4gTEZCIFZlcnNpb25pbmcuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgDQogICAgICAgICAgICAzLjIuNi4gTEZC IEluaGVyaXRhbmNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgDQogICAg ICAgICAzLjMuIEZFIERhdGFwYXRoIE1vZGVsaW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMjggDQogICAgICAgICAgICAzLjMuMS4gQWx0ZXJuYXRpdmUgQXBwcm9hY2hlcyBm b3IgTW9kZWxpbmcgRkUgRGF0YXBhdGhzLi4uMjggDQogICAgICAgICAgICAzLjMuMi4gQ29uZmln dXJpbmcgdGhlIExGQiBUb3BvbG9neS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzMgDQogICAgICA0 LiBNb2RlbCBhbmQgU2NoZW1hIGZvciBMRkIgQ2xhc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMzcgDQogICAgICAgICA0LjEuIE5hbWVzcGFjZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzcgDQogICAgICAgICA0LjIuIDxMRkJMaWJyYXJ5PiBF bGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMzcgDQogICAgICAgICA0 LjMuIDxsb2FkPiBFbGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMzkgDQogICAgICAgICA0LjQuIDxmcmFtZURlZnM+IEVsZW1lbnQgZm9yIEZyYW1lIFR5cGUg RGVjbGFyYXRpb25zLi4uLi4uLi4uMzkgDQogICAgICAgICA0LjUuIDxkYXRhVHlwZURlZnM+IEVs ZW1lbnQgZm9yIERhdGEgVHlwZSBEZWZpbml0aW9ucy4uLi4uLi4uNDAgDQogICAgICAgICAgICA0 LjUuMS4gPHR5cGVSZWY+IEVsZW1lbnQgZm9yIEFsaWFzaW5nIEV4aXN0aW5nIERhdGEgVHlwZXMu NDIgDQogICAgICAgICAgICA0LjUuMi4gPGF0b21pYz4gRWxlbWVudCBmb3IgRGVyaXZpbmcgTmV3 IEF0b21pYyBUeXBlcy4uLi4uNDMgDQogICAgICAgICAgICA0LjUuMy4gPGFycmF5PiBFbGVtZW50 IHRvIERlZmluZSBBcnJheXMuLi4uLi4uLi4uLi4uLi4uLi4uNDMgDQogICAgICAgICAgICA0LjUu NC4gPHN0cnVjdD4gRWxlbWVudCB0byBEZWZpbmUgU3RydWN0dXJlcy4uLi4uLi4uLi4uLi4uNDcg DQogICAgICAgICAgICA0LjUuNS4gPHVuaW9uPiBFbGVtZW50IHRvIERlZmluZSBVbmlvbiBUeXBl cy4uLi4uLi4uLi4uLi4uNDggDQogICAgICAgICAgICA0LjUuNi4gQXVnbWVudGF0aW9ucy4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNTAgDQogICAgICAgICA0LjYuIDxtZXRh ZGF0YURlZnM+IEVsZW1lbnQgZm9yIE1ldGFkYXRhIERlZmluaXRpb25zLi4uLi4uLi4uNTEgDQog ICAgICAgICA0LjcuIDxMRkJDbGFzc0RlZnM+IEVsZW1lbnQgZm9yIExGQiBDbGFzcyBEZWZpbml0 aW9ucy4uLi4uLi4uNTIgDQogICAgICAgICAgICA0LjcuMS4gPGRlcml2ZWRGcm9tPiBFbGVtZW50 IHRvIEV4cHJlc3MgTEZCIEluaGVyaXRhbmNlLi4uNTQgDQogICAgICAgICAgICA0LjcuMi4gPGlu cHV0UG9ydHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBJbnB1dHMuLi4uLi4uLi4uNTQgDQogICAg DQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDJdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZF IE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAgICAg IDQuNy4zLiA8b3V0cHV0UG9ydHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBPdXRwdXRzLi4uLi4u Li41NyANCiAgICAgICAgICAgIDQuNy40LiA8YXR0cmlidXRlcz4gRWxlbWVudCB0byBEZWZpbmUg TEZCIE9wZXJhdGlvbmFsIA0KICAgICAgICAgICAgQXR0cmlidXRlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjU4IA0KICAgICAgICAgICAgNC43LjUuIDxj YXBhYmlsaXRpZXM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBDYXBhYmlsaXR5IA0KICAgICAgICAg ICAgQXR0cmlidXRlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjYxIA0KICAgICAgICAgICAgNC43LjYuIDxkZXNjcmlwdGlvbj4gRWxlbWVudCBmb3IgTEZC IE9wZXJhdGlvbmFsIA0KICAgICAgICAgICAgU3BlY2lmaWNhdGlvbi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYyIA0KICAgICAgICAgNC44LiBYTUwgU2NoZW1h IGZvciBMRkIgQ2xhc3MgTGlicmFyeSBEb2N1bWVudHMuLi4uLi4uLi4uLi4uLjYyIA0KICAgICAg NS4gRkUgQXR0cmlidXRlcyBhbmQgQ2FwYWJpbGl0aWVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjcyIA0KICAgICAgICAgNS4xLiBYTUwgZm9yIEZFT2JqZWN0IENsYXNzIGRlZmluaXRp b24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjczIA0KICAgICAgICAgNS4yLiBGRSBDYXBhYmlsaXRp ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgxIA0KICAgICAgICAg ICAgNS4yLjEuIE1vZGlmaWFibGVMRkJUb3BvbG9neS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjgxIA0KICAgICAgICAgICAgNS4yLjIuIFN1cHBvcnRlZExGQnMgYW5kIFN1cHBvcnRlZExG QlR5cGUuLi4uLi4uLi4uLi4uLi4uLjgyIA0KICAgICAgICAgICAgNS4yLjMuIFN1cHBvcnRlZEF0 dHJpYnV0ZVR5cGUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg0IA0KICAgICAgICAgNS4z LiBGRUF0dHJpYnV0ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Ljg0IA0KICAgICAgICAgICAgNS4zLjEuIEZFU3RhdHVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjg0IA0KICAgICAgICAgICAgNS4zLjIuIExGQlNlbGVjdG9ycyBh bmQgTEZCU2VsZWN0b3JUeXBlLi4uLi4uLi4uLi4uLi4uLi4uLjg0IA0KICAgICAgICAgICAgNS4z LjMuIExGQlRvcG9sb2d5IGFuZCBMRkJMaW5rVHlwZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg1 IA0KICAgICAgICAgICAgNS4zLjQuIEZFTmVpZ2hib3JzIGFuIEZFQ29uZmlndXJlZE5laWdoYm9y VHlwZS4uLi4uLi4uLi4uLjg1IA0KICAgICAgNi4gU2F0aXNmeWluZyB0aGUgUmVxdWlyZW1lbnRz IG9uIEZFIE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg2IA0KICAgICAgICAgNi4xLiBQb3J0 IEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg3IA0K ICAgICAgICAgNi4yLiBGb3J3YXJkaW5nIEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjg3IA0KICAgICAgICAgNi4zLiBRb1MgRnVuY3Rpb25zLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg4IA0KICAgICAgICAgNi40LiBHZW5lcmlj IEZpbHRlcmluZyBGdW5jdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg4IA0KICAg ICAgICAgNi41LiBWZW5kb3IgU3BlY2lmaWMgRnVuY3Rpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjg4IA0KICAgICAgICAgNi42LiBIaWdoLVRvdWNoIEZ1bmN0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg4IA0KICAgICAgICAgNi43LiBTZWN1cml0eSBG dW5jdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg4IA0KICAgICAg ICAgNi44LiBPZmYtbG9hZGVkIEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjg5IA0KICAgICAgICAgNi45LiBJUEZMT1cvUFNBTVAgRnVuY3Rpb25zLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjg5IA0KICAgICAgNy4gVXNpbmcgdGhlIEZFIG1vZGVs IGluIHRoZSBGb3JDRVMgUHJvdG9jb2wuLi4uLi4uLi4uLi4uLi4uLi4uLjg5IA0KICAgICAgICAg Ny4xLiBGRSBUb3BvbG9neSBRdWVyeS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjkxIA0KICAgICAgICAgNy4yLiBGRSBDYXBhYmlsaXR5IERlY2xhcmF0aW9ucy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjkzIA0KICAgICAgICAgNy4zLiBMRkIgVG9wb2xvZ3kgYW5k IFRvcG9sb2d5IENvbmZpZ3VyYWJpbGl0eSBRdWVyeS4uLi4uLi4uLjkzIA0KICAgICAgICAgNy40 LiBMRkIgQ2FwYWJpbGl0eSBEZWNsYXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjkzIA0KICAgICAgICAgNy41LiBTdGF0ZSBRdWVyeSBvZiBMRkIgQXR0cmlidXRlcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjk0IA0KICAgICAgICAgNy42LiBMRkIgQXR0cmlidXRlIE1hbmlw dWxhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk1IA0KICAgICAgICAgNy43LiBM RkIgVG9wb2xvZ3kgUmUtY29uZmlndXJhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk1 IA0KICAgICAgOC4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjk2IA0KICAgICAgOS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk2IA0KICAgICAgMTAuIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk2IA0K ICAgICAgMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjk2IA0KICAgICAgMTIuIEF1dGhvcnMnIEFkZHJlc3Nlcy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk3IA0KICAgICAgMTMuIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBSaWdodC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjk4IA0KICAg ICAgMTQuIElBTkEgY29uc2lkZXJhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjk4IA0KICAgICAgIA0KICAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3Vt ZW50ICANCiAgICAgICAgICAgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1 Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdIA0KDCAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSAN CiAgICANCiAgICANCiAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgDQogICAgICBOT1QiLCANCiAgICAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiANCiAg ICAgIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBb UkZDLTIxMTldLiANCiAgICAgICANCiAgIDEuIA0gICAgIERlZmluaXRpb25zIA0KICAgICAgIA0K ICAgICAgVGVybWlub2xvZ3kgYXNzb2NpYXRlZCB3aXRoIHRoZSBGb3JDRVMgcmVxdWlyZW1lbnRz IGlzIGRlZmluZWQgaW4gDQogICAgICBSRkMgMzU2NCBbMV0gYW5kIGlzIG5vdCBjb3BpZWQgaGVy ZS4gIFRoZSBmb2xsb3dpbmcgbGlzdCBvZiANCiAgICAgIHRlcm1pbm9sb2d5IHJlbGV2YW50IHRv IHRoZSBGRSBtb2RlbCBpcyBkZWZpbmVkIGluIHRoaXMgc2VjdGlvbi4gDQogICAgDQogICAgICBG RSBNb2RlbCAtLSBUaGUgRkUgbW9kZWwgaXMgZGVzaWduZWQgdG8gbW9kZWwgdGhlIGxvZ2ljYWwg DQogICAgICBwcm9jZXNzaW5nIGZ1bmN0aW9ucyBvZiBhbiBGRS4gIFRoZSBGRSBtb2RlbCBwcm9w b3NlZCBpbiB0aGlzIA0KICAgICAgZG9jdW1lbnQgaW5jbHVkZXMgdGhyZWUgY29tcG9uZW50czog dGhlIG1vZGVsaW5nIG9mIGluZGl2aWR1YWwgDQogICAgICBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxv Y2tzIChMRkIgbW9kZWwpLCB0aGUgbG9naWNhbCBpbnRlcmNvbm5lY3Rpb24gDQogICAgICBiZXR3 ZWVuIExGQnMgKExGQiB0b3BvbG9neSkgYW5kIHRoZSBGRSBsZXZlbCBhdHRyaWJ1dGVzLCBpbmNs dWRpbmcgDQogICAgICBGRSBjYXBhYmlsaXRpZXMuICBUaGUgRkUgbW9kZWwgcHJvdmlkZXMgdGhl IGJhc2lzIHRvIGRlZmluZSB0aGUgDQogICAgICBpbmZvcm1hdGlvbiBlbGVtZW50cyBleGNoYW5n ZWQgYmV0d2VlbiB0aGUgQ0UgYW5kIHRoZSBGRSBpbiB0aGUgDQogICAgICBGb3JDRVMgcHJvdG9j b2wuICANCiAgICAgICANCiAgICAgIERhdGFwYXRoIC0tIEEgY29uY2VwdHVhbCBwYXRoIHRha2Vu IGJ5IHBhY2tldHMgd2l0aGluIHRoZSANCiAgICAgIGZvcndhcmRpbmcgcGxhbmUgaW5zaWRlIGFu IEZFLiAgTm90ZSB0aGF0IG1vcmUgdGhhbiBvbmUgZGF0YXBhdGggDQogICAgICBjYW4gZXhpc3Qg d2l0aGluIGFuIEZFLiANCiAgICAgICANCiAgICAgIExGQiAoTG9naWNhbCBGdW5jdGlvbmFsIEJs b2NrKSBDbGFzcyAob3IgdHlwZSkgLS0gQSB0ZW1wbGF0ZSANCiAgICAgIHJlcHJlc2VudGluZyBh IGZpbmUtZ3JhaW5lZCwgbG9naWNhbGx5IHNlcGFyYWJsZSBhbmQgd2VsbC1kZWZpbmVkIA0KICAg ICAgcGFja2V0IHByb2Nlc3Npbmcgb3BlcmF0aW9uIGluIHRoZSBkYXRhcGF0aC4gIExGQiBjbGFz c2VzIGFyZSB0aGUgDQogICAgICBiYXNpYyBidWlsZGluZyBibG9ja3Mgb2YgdGhlIEZFIG1vZGVs LiANCiAgICAgICANCiAgICAgIExGQiBJbnN0YW5jZSAtLSBBcyBhIHBhY2tldCBmbG93cyB0aHJv dWdoIGFuIEZFIGFsb25nIGEgZGF0YXBhdGgsIA0KICAgICAgaXQgZmxvd3MgdGhyb3VnaCBvbmUg b3IgbXVsdGlwbGUgTEZCIGluc3RhbmNlcywgd2hlcmUgZWFjaCBMRkIgaXMgDQogICAgICBhbiBp bnN0YW5jZSBvZiBhIHNwZWNpZmljIExGQiBjbGFzcy4gIE11bHRpcGxlIGluc3RhbmNlcyBvZiB0 aGUgDQogICAgICBzYW1lIExGQiBjbGFzcyBjYW4gYmUgcHJlc2VudCBpbiBhbiBGRSdzIGRhdGFw YXRoLiAgTm90ZSB0aGF0IHdlIA0KICAgICAgb2Z0ZW4gcmVmZXIgdG8gTEZCcyB3aXRob3V0IGRp c3Rpbmd1aXNoaW5nIGJldHdlZW4gYW4gTEZCIGNsYXNzIA0KICAgICAgYW5kIExGQiBpbnN0YW5j ZSB3aGVuIHdlIGJlbGlldmUgdGhlIGltcGxpZWQgcmVmZXJlbmNlIGlzIG9idmlvdXMgDQogICAg ICBmb3IgdGhlIGdpdmVuIGNvbnRleHQuIA0KICAgICAgIA0KICAgICAgTEZCIE1vZGVsIC0tIFRo ZSBMRkIgbW9kZWwgZGVzY3JpYmVzIHRoZSBjb250ZW50IGFuZCBzdHJ1Y3R1cmVzIGluIA0KICAg ICAgYW4gTEZCLCBwbHVzIHRoZSBhc3NvY2lhdGVkIGRhdGEgZGVmaW5pdGlvbi4gIEZvdXIgdHlw ZXMgb2YgDQogICAgICBpbmZvcm1hdGlvbiBhcmUgZGVmaW5lZCBpbiB0aGUgTEZCIG1vZGVsLiAg VGhlIGNvcmUgcGFydCBvZiB0aGUgDQogICAgICBMRkIgbW9kZWwgaXMgdGhlIExGQiBjbGFzcyBk ZWZpbml0aW9uczsgdGhlIG90aGVyIHRocmVlIHR5cGVzIA0KICAgICAgZGVmaW5lIHRoZSBhc3Nv Y2lhdGVkIGRhdGEgaW5jbHVkaW5nIGNvbW1vbiBkYXRhIHR5cGVzLCBzdXBwb3J0ZWQgDQogICAg ICBmcmFtZSBmb3JtYXRzIGFuZCBtZXRhZGF0YS4gDQogICAgICAgDQogICAgICBMRkIgTWV0YWRh dGEgLS0gTWV0YWRhdGEgaXMgdXNlZCB0byBjb21tdW5pY2F0ZSBwZXItcGFja2V0IHN0YXRlIA0K ICAgICAgZnJvbSBvbmUgTEZCIHRvIGFub3RoZXIsIGJ1dCBpcyBub3Qgc2VudCBhY3Jvc3MgdGhl IG5ldHdvcmsuICBUaGUgDQogICAgICBGRSBtb2RlbCBkZWZpbmVzIGhvdyBzdWNoIG1ldGFkYXRh IGlzIGlkZW50aWZpZWQsIHByb2R1Y2VkIGFuZCANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAg IEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoM ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgY29uc3VtZWQgYnkgdGhlIExGQnMsIGJ1dCBu b3QgaG93IHRoZSBwZXItcGFja2V0IHN0YXRlIGlzIA0KICAgICAgaW1wbGVtZW50ZWQgd2l0aGlu IGFjdHVhbCBoYXJkd2FyZS4gDQogICAgICAgDQogICAgICBMRkIgQXR0cmlidXRlIC0tIE9wZXJh dGlvbmFsIHBhcmFtZXRlcnMgb2YgdGhlIExGQnMgdGhhdCBtdXN0IGJlIA0KICAgICAgdmlzaWJs ZSB0byB0aGUgQ0VzIGFyZSBjb25jZXB0dWFsaXplZCBpbiB0aGUgRkUgbW9kZWwgYXMgdGhlIExG QiANCiAgICAgIGF0dHJpYnV0ZXMuICBUaGUgTEZCIGF0dHJpYnV0ZXMgaW5jbHVkZTogZmxhZ3Ms IHNpbmdsZSBwYXJhbWV0ZXIgDQogICAgICBhcmd1bWVudHMsIGNvbXBsZXggYXJndW1lbnRzLCBh bmQgdGFibGVzIHRoYXQgdGhlIENFIGNhbiByZWFkIA0KICAgICAgb3IvYW5kIHdyaXRlIHZpYSB0 aGUgRm9yQ0VTIHByb3RvY29sLiANCiAgICAgICANCiAgICAgIExGQiBUb3BvbG9neSAtLSBBIHJl cHJlc2VudGF0aW9uIG9mIHRoZSBsb2dpY2FsIGludGVyY29ubmVjdGlvbiANCiAgICAgIGFuZCB0 aGUgcGxhY2VtZW50IG9mIExGQiBpbnN0YW5jZXMgYWxvbmcgdGhlIGRhdGFwYXRoIHdpdGhpbiBv bmUgDQogICAgICBGRS4gIFNvbWV0aW1lcyB0aGlzIHJlcHJlc2VudGF0aW9uIGlzIGNhbGxlZCBp bnRyYS1GRSB0b3BvbG9neSwgdG8gDQogICAgICBiZSBkaXN0aW5ndWlzaGVkIGZyb20gaW50ZXIt RkUgdG9wb2xvZ3kuICBMRkIgdG9wb2xvZ3kgaXMgb3V0c2lkZSANCiAgICAgIG9mIHRoZSBMRkIg bW9kZWwsIGJ1dCBpcyBwYXJ0IG9mIHRoZSBGRSBtb2RlbC4gDQogICAgICAgDQogICAgICBGRSBU b3BvbG9neSAtLSBBIHJlcHJlc2VudGF0aW9uIG9mIGhvdyBtdWx0aXBsZSBGRXMgd2l0aGluIGEg DQogICAgICBzaW5nbGUgTkUgYXJlIGludGVyY29ubmVjdGVkLiAgU29tZXRpbWVzIHRoaXMgaXMg Y2FsbGVkIGludGVyLUZFIA0KICAgICAgdG9wb2xvZ3ksIHRvIGJlIGRpc3Rpbmd1aXNoZWQgZnJv bSBpbnRyYS1GRSB0b3BvbG9neSAoaS5lLiwgTEZCIA0KICAgICAgdG9wb2xvZ3kpLiAgQW4gaW5k aXZpZHVhbCBGRSBtaWdodCBub3QgaGF2ZSB0aGUgZ2xvYmFsIGtub3dsZWRnZSANCiAgICAgIG9m IHRoZSBmdWxsIEZFIHRvcG9sb2d5LCBidXQgdGhlIGxvY2FsIHZpZXcgb2YgaXRzIGNvbm5lY3Rp dml0eSANCiAgICAgIHdpdGggb3RoZXIgRkVzIGlzIGNvbnNpZGVyZWQgdG8gYmUgcGFydCBvZiB0 aGUgRkUgbW9kZWwuICBUaGUgRkUgDQogICAgICB0b3BvbG9neSBpcyBkaXNjb3ZlcmVkIGJ5IHRo ZSBGb3JDRVMgYmFzZSBwcm90b2NvbCBvciBieSBzb21lIA0KICAgICAgb3RoZXIgbWVhbnMuIA0K ICAgICAgIA0KICAgICAgSW50ZXItRkUgVG9wb2xvZ3kgLS0gU2VlIEZFIFRvcG9sb2d5LiANCiAg ICAgICANCiAgICAgIEludHJhLUZFIFRvcG9sb2d5IC0tIFNlZSBMRkIgVG9wb2xvZ3kuICANCiAg ICAgICANCiAgICAgIExGQiBjbGFzcyBsaWJyYXJ5IC0tIEEgc2V0IG9mIExGQiBjbGFzc2VzIHRo YXQgaGFzIGJlZW4gaWRlbnRpZmllZCANCiAgICAgIGFzIHRoZSBtb3N0IGNvbW1vbiBmdW5jdGlv bnMgZm91bmQgaW4gbW9zdCBGRXMgYW5kIGhlbmNlIHNob3VsZCBiZSANCiAgICAgIGRlZmluZWQg Zmlyc3QgYnkgdGhlIEZvckNFUyBXb3JraW5nIEdyb3VwLiAgDQogICAgICAgDQogICAyLiANICAg ICBJbnRyb2R1Y3Rpb24gDQogICAgDQogICAgICBSRkMgMzc0NiBbMl0gc3BlY2lmaWVzIGEgZnJh bWV3b3JrIGJ5IHdoaWNoIGNvbnRyb2wgZWxlbWVudHMgKENFcykgDQogICAgICBjYW4gY29uZmln dXJlIGFuZCBtYW5hZ2Ugb25lIG9yIG1vcmUgc2VwYXJhdGUgZm9yd2FyZGluZyBlbGVtZW50cyAN CiAgICAgIChGRXMpIHdpdGhpbiBhIG5ldHdvcmtpbmcgZWxlbWVudCAoTkUpIHVzaW5nIHRoZSBG b3JDRVMgcHJvdG9jb2wuICANCiAgICAgIFRoZSBGb3JDRVMgYXJjaGl0ZWN0dXJlIGFsbG93cyBG b3J3YXJkaW5nIEVsZW1lbnRzIG9mIHZhcnlpbmcgDQogICAgICBmdW5jdGlvbmFsaXR5IHRvIHBh cnRpY2lwYXRlIGluIGEgRm9yQ0VTIG5ldHdvcmsgZWxlbWVudC4gIFRoZSANCiAgICAgIGltcGxp Y2F0aW9uIG9mIHRoaXMgdmFyeWluZyBmdW5jdGlvbmFsaXR5IGlzIHRoYXQgQ0VzIGNhbiBtYWtl IA0KICAgICAgb25seSBtaW5pbWFsIGFzc3VtcHRpb25zIGFib3V0IHRoZSBmdW5jdGlvbmFsaXR5 IHByb3ZpZGVkIGJ5IEZFcyANCiAgICAgIGluIGFuIE5FLiAgQmVmb3JlIENFcyBjYW4gY29uZmln dXJlIGFuZCBjb250cm9sIHRoZSBmb3J3YXJkaW5nIA0KICAgICAgYmVoYXZpb3Igb2YgRkVzLCBD RXMgbmVlZCB0byBxdWVyeSBhbmQgZGlzY292ZXIgdGhlIGNhcGFiaWxpdGllcyANCiAgICAgIGFu ZCBzdGF0ZXMgb2YgdGhlaXIgRkVzLiAgUkZDIDM2NTQgWzFdIG1hbmRhdGVzIHRoYXQgdGhlIA0K ICAgICAgY2FwYWJpbGl0aWVzLCBzdGF0ZXMgYW5kIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g YmUgZXhwcmVzc2VkIGluIA0KICAgICAgdGhlIGZvcm0gb2YgYW4gRkUgbW9kZWwuIA0KICAgICAg IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA1XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZv ckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAg ICBSRkMgMzQ0NCBbMTFdIG9ic2VydmVkIHRoYXQgaW5mb3JtYXRpb24gbW9kZWxzIChJTXMpIGFu ZCBkYXRhIA0KICAgICAgbW9kZWxzIChETXMpIGFyZSBkaWZmZXJlbnQgYmVjYXVzZSB0aGV5IHNl cnZlIGRpZmZlcmVudCBwdXJwb3Nlcy4gIA0KICAgICAgIlRoZSBtYWluIHB1cnBvc2Ugb2YgYW4g SU0gaXMgdG8gbW9kZWwgbWFuYWdlZCBvYmplY3RzIGF0IGEgDQogICAgICBjb25jZXB0dWFsIGxl dmVsLCBpbmRlcGVuZGVudCBvZiBhbnkgc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zIG9yIA0KICAg ICAgcHJvdG9jb2xzIHVzZWQiLiAgIkRNcywgY29udmVyc2VseSwgYXJlIGRlZmluZWQgYXQgYSBs b3dlciBsZXZlbCANCiAgICAgIG9mIGFic3RyYWN0aW9uIGFuZCBpbmNsdWRlIG1hbnkgZGV0YWls cy4gIFRoZXkgYXJlIGludGVuZGVkIGZvciANCiAgICAgIGltcGxlbWVudG9ycyBhbmQgaW5jbHVk ZSBwcm90b2NvbC1zcGVjaWZpYyBjb25zdHJ1Y3RzLiIgIFNvbWV0aW1lcyANCiAgICAgIGl0IGlz IGRpZmZpY3VsdCB0byBkcmF3IGEgY2xlYXIgbGluZSBiZXR3ZWVuIHRoZSB0d28uICBUaGUgRkUg DQogICAgICBtb2RlbCBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBwcmltYXJpbHkgYW4g aW5mb3JtYXRpb24gDQogICAgICBtb2RlbCwgYnV0IGFsc28gaW5jbHVkZXMgc29tZSBhc3BlY3Rz IG9mIGEgZGF0YSBtb2RlbCwgc3VjaCBhcyANCiAgICAgIGV4cGxpY2l0IGRlZmluaXRpb25zIG9m IHRoZSBMRkIgY2xhc3Mgc2NoZW1hIGFuZCBGRSBzY2hlbWEuICBJdCBpcyANCiAgICAgIGV4cGVj dGVkIHRoYXQgdGhpcyBGRSBtb2RlbCB3aWxsIGJlIHVzZWQgYXMgdGhlIGJhc2lzIHRvIGRlZmlu ZSANCiAgICAgIHRoZSBwYXlsb2FkIGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIHRo ZSBDRSBhbmQgRkUgaW4gdGhlIA0KICAgICAgRm9yQ0VTIHByb3RvY29sLiAgIA0KICAgICAgICAg ICANCiAgIDIuMS4gUmVxdWlyZW1lbnRzIG9uIHRoZSBGRSBtb2RlbCANCiAgICAgICANCiAgICAg IFJGQyAzNjU0IFsxXSBkZWZpbmVzIHJlcXVpcmVtZW50cyB0aGF0IG11c3QgYmUgc2F0aXNmaWVk IGJ5IGEgDQogICAgICBGb3JDRVMgRkUgbW9kZWwuICBUbyBzdW1tYXJpemUsIGFuIEZFIG1vZGVs IG11c3QgZGVmaW5lOiANCiAgICAgICAgLiBMb2dpY2FsbHkgc2VwYXJhYmxlIGFuZCBkaXN0aW5j dCBwYWNrZXQgZm9yd2FyZGluZyBvcGVyYXRpb25zIA0KICAgICAgICAgICBpbiBhbiBGRSBkYXRh cGF0aCAobG9naWNhbCBmdW5jdGlvbmFsIGJsb2NrcyBvciBMRkJzKTsgDQogICAgICAgIC4gVGhl IHBvc3NpYmxlIHRvcG9sb2dpY2FsIHJlbGF0aW9uc2hpcHMgKGFuZCBoZW5jZSB0aGUgDQogICAg ICAgICAgIHNlcXVlbmNlIG9mIHBhY2tldCBmb3J3YXJkaW5nIG9wZXJhdGlvbnMpIGJldHdlZW4g dGhlIHZhcmlvdXMgDQogICAgICAgICAgIExGQnM7IA0KICAgICAgICAuIFRoZSBwb3NzaWJsZSBv cGVyYXRpb25hbCBjYXBhYmlsaXRpZXMgKGUuZy4sIGNhcGFjaXR5IGxpbWl0cywgDQogICAgICAg ICAgIGNvbnN0cmFpbnRzLCBvcHRpb25hbCBmZWF0dXJlcywgZ3JhbnVsYXJpdHkgb2YgY29uZmln dXJhdGlvbikgDQogICAgICAgICAgIG9mIGVhY2ggdHlwZSBvZiBMRkI7IA0KICAgICAgICAuIFRo ZSBwb3NzaWJsZSBjb25maWd1cmFibGUgcGFyYW1ldGVycyAoaS5lLiwgYXR0cmlidXRlcykgb2Yg DQogICAgICAgICAgIGVhY2ggdHlwZSBvZiBMRkI7IA0KICAgICAgICAuIE1ldGFkYXRhIHRoYXQg bWF5IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIExGQnMuIA0KICAgICAgICANCiAgIDIuMi4gVGhlIEZF IE1vZGVsIGluIFJlbGF0aW9uIHRvIEZFIEltcGxlbWVudGF0aW9ucyANCiAgICAgICANCiAgICAg IFRoZSBGRSBtb2RlbCBwcm9wb3NlZCBoZXJlIGlzIGJhc2VkIG9uIGFuIGFic3RyYWN0aW9uIG9m IGRpc3RpbmN0IA0KICAgICAgbG9naWNhbCBmdW5jdGlvbmFsIGJsb2NrcyAoTEZCcyksIHdoaWNo IGFyZSBpbnRlcmNvbm5lY3RlZCBpbiBhIA0KICAgICAgZGlyZWN0ZWQgZ3JhcGgsIGFuZCByZWNl aXZlLCBwcm9jZXNzLCBtb2RpZnksIGFuZCB0cmFuc21pdCBwYWNrZXRzIA0KICAgICAgYWxvbmcg d2l0aCBtZXRhZGF0YS4gIFRoZSBGRSBtb2RlbCBzaG91bGQgYmUgZGVzaWduZWQgc3VjaCB0aGF0 IA0KICAgICAgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgZm9yd2FyZGluZyBkYXRh cGF0aCBjYW4gYmUgDQogICAgICBsb2dpY2FsbHkgbWFwcGVkIG9udG8gdGhlIG1vZGVsIHdpdGgg dGhlIGZ1bmN0aW9uYWxpdHkgYW5kIA0KICAgICAgc2VxdWVuY2Ugb2Ygb3BlcmF0aW9ucyBjb3Jy ZWN0bHkgY2FwdHVyZWQuICBIb3dldmVyLCB0aGUgbW9kZWwgaXMgDQogICAgICBub3QgaW50ZW5k ZWQgdG8gZGlyZWN0bHkgYWRkcmVzcyBob3cgYSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIA0K ICAgICAgbWFwcyB0byBhbiBMRkIgdG9wb2xvZ3kuICBJdCBpcyBsZWZ0IHRvIHRoZSBmb3J3YXJk aW5nIHBsYW5lIA0KICAgICAgdmVuZG9ycyB0byBkZWZpbmUgaG93IHRoZSBGRSBmdW5jdGlvbmFs aXR5IGlzIHJlcHJlc2VudGVkIHVzaW5nIA0KICAgICAgdGhlIEZFIG1vZGVsLiAgIE91ciBnb2Fs IGlzIHRvIGRlc2lnbiB0aGUgRkUgbW9kZWwgc3VjaCB0aGF0IGl0IGlzIA0KICAgICAgZmxleGli bGUgZW5vdWdoIHRvIGFjY29tbW9kYXRlIG1vc3QgY29tbW9uIGltcGxlbWVudGF0aW9ucy4gIA0K ICAgICAgIA0KDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0KDCAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAg ICANCiAgICAgIFRoZSBMRkIgdG9wb2xvZ3kgbW9kZWwgZm9yIGEgcGFydGljdWxhciBkYXRhcGF0 aCBpbXBsZW1lbnRhdGlvbiANCiAgICAgIE1VU1QgY29ycmVjdGx5IGNhcHR1cmUgdGhlIHNlcXVl bmNlIG9mIG9wZXJhdGlvbnMgb24gdGhlIHBhY2tldC4gIA0KICAgICAgTWV0YWRhdGEgZ2VuZXJh dGlvbiBieSBjZXJ0YWluIExGQnMgbXVzdCBhbHdheXMgcHJlY2VkZSBhbnkgdXNlIG9mIA0KICAg ICAgdGhhdCBtZXRhZGF0YSBieSBzdWJzZXF1ZW50IExGQnMgaW4gdGhlIHRvcG9sb2d5IGdyYXBo OyB0aGlzIGlzIA0KICAgICAgcmVxdWlyZWQgZm9yIGxvZ2ljYWxseSBjb25zaXN0ZW50IG9wZXJh dGlvbi4gIEZ1cnRoZXIsIA0KICAgICAgbW9kaWZpY2F0aW9uIG9mIHBhY2tldCBmaWVsZHMgdGhh dCBhcmUgc3Vic2VxdWVudGx5IHVzZWQgYXMgaW5wdXRzIA0KICAgICAgZm9yIGZ1cnRoZXIgcHJv Y2Vzc2luZyBtdXN0IG9jY3VyIGluIHRoZSBvcmRlciBzcGVjaWZpZWQgaW4gdGhlIA0KICAgICAg bW9kZWwgZm9yIHRoYXQgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiB0byBlbnN1cmUgY29ycmVj dG5lc3MuIA0KICAgIA0KICAgMi4zLiBUaGUgRkUgTW9kZWwgaW4gUmVsYXRpb24gdG8gdGhlIEZv ckNFUyBQcm90b2NvbCANCiAgICAgICANCiAgICAgIFRoZSBGb3JDRVMgYmFzZSBwcm90b2NvbCBp cyB1c2VkIGJ5IHRoZSBDRXMgYW5kIEZFcyB0byBtYWludGFpbiANCiAgICAgIHRoZSBjb21tdW5p Y2F0aW9uIGNoYW5uZWwgYmV0d2VlbiB0aGUgQ0VzIGFuZCBGRXMuICBUaGUgRm9yQ0VTIA0KICAg ICAgcHJvdG9jb2wgbWF5IGJlIHVzZWQgdG8gcXVlcnkgYW5kIGRpc2NvdmVyIHRoZSBpbnRlci1G RSB0b3BvbG9neS4gIA0KICAgICAgVGhlIGRldGFpbHMgb2YgYSBwYXJ0aWN1bGFyIGRhdGFwYXRo IGltcGxlbWVudGF0aW9uIGluc2lkZSBhbiBGRSwgDQogICAgICBpbmNsdWRpbmcgdGhlIExGQiB0 b3BvbG9neSwgYWxvbmcgd2l0aCB0aGUgb3BlcmF0aW9uYWwgDQogICAgICBjYXBhYmlsaXRpZXMg YW5kIGF0dHJpYnV0ZXMgb2YgZWFjaCBpbmRpdmlkdWFsIExGQiwgYXJlIGNvbnZleWVkIA0KICAg ICAgdG8gdGhlIENFIHdpdGhpbiBpbmZvcm1hdGlvbiBlbGVtZW50cyBpbiB0aGUgRm9yQ0VTIHBy b3RvY29sLiAgVGhlIA0KICAgICAgbW9kZWwgb2YgYW4gTEZCIGNsYXNzIHNob3VsZCBkZWZpbmUg YWxsIG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IA0KICAgICAgbmVlZHMgdG8gYmUgZXhjaGFuZ2Vk IGJldHdlZW4gYW4gRkUgYW5kIGEgQ0UgZm9yIHRoZSBwcm9wZXIgDQogICAgICBjb25maWd1cmF0 aW9uIGFuZCBtYW5hZ2VtZW50IG9mIHRoYXQgTEZCLiAgIA0KICAgICAgIA0KICAgICAgU3BlY2lm eWluZyB0aGUgdmFyaW91cyBwYXlsb2FkcyBvZiB0aGUgRm9yQ0VTIG1lc3NhZ2VzIGluIGEgDQog ICAgICBzeXN0ZW1hdGljIGZhc2hpb24gaXMgZGlmZmljdWx0IHdpdGhvdXQgYSBmb3JtYWwgZGVm aW5pdGlvbiBvZiB0aGUgDQogICAgICBvYmplY3RzIGJlaW5nIGNvbmZpZ3VyZWQgYW5kIG1hbmFn ZWQgKHRoZSBGRSBhbmQgdGhlIExGQnMgd2l0aGluKS4gIA0KICAgICAgVGhlIEZFIE1vZGVsIGRv Y3VtZW50IGRlZmluZXMgYSBzZXQgb2YgY2xhc3NlcyBhbmQgYXR0cmlidXRlcyBmb3IgDQogICAg ICBkZXNjcmliaW5nIGFuZCBtYW5pcHVsYXRpbmcgdGhlIHN0YXRlIG9mIHRoZSBMRkJzIHdpdGhp biBhbiBGRS4gIA0KICAgICAgVGhlc2UgY2xhc3MgZGVmaW5pdGlvbnMgdGhlbXNlbHZlcyB3aWxs IGdlbmVyYWxseSBub3QgYXBwZWFyIGluIA0KICAgICAgdGhlIEZvckNFUyBwcm90b2NvbC4gIFJh dGhlciwgRm9yQ0VTIHByb3RvY29sIG9wZXJhdGlvbnMgd2lsbCANCiAgICAgIHJlZmVyZW5jZSBj bGFzc2VzIGRlZmluZWQgaW4gdGhpcyBtb2RlbCwgaW5jbHVkaW5nIHJlbGV2YW50IA0KICAgICAg YXR0cmlidXRlcyBhbmQgdGhlIGRlZmluZWQgb3BlcmF0aW9ucy4gIA0KICAgICAgICANCiAgICAg IFNlY3Rpb24gNyBwcm92aWRlcyBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24gb24gaG93IHRoZSBG RSBtb2RlbCANCiAgICAgIHNob3VsZCBiZSB1c2VkIGJ5IHRoZSBGb3JDRVMgcHJvdG9jb2wuIA0K ICAgIA0KICAgMi40LiBNb2RlbGluZyBMYW5ndWFnZSBmb3IgdGhlIEZFIE1vZGVsIA0KICAgICAg IA0KICAgICAgRXZlbiB0aG91Z2ggbm90IGFic29sdXRlbHkgcmVxdWlyZWQsIGl0IGlzIGJlbmVm aWNpYWwgdG8gdXNlIGEgDQogICAgICBmb3JtYWwgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSB0byBy ZXByZXNlbnQgdGhlIGNvbmNlcHR1YWwgRkUgbW9kZWwgDQogICAgICBkZXNjcmliZWQgaW4gdGhp cyBkb2N1bWVudC4gIFVzZSBvZiBhIGZvcm1hbCBsYW5ndWFnZSBjYW4gaGVscCB0byANCiAgICAg IGVuZm9yY2UgY29uc2lzdGVuY3kgYW5kIGxvZ2ljYWwgY29tcGF0aWJpbGl0eSBhbW9uZyBMRkJz LiAgQSBmdWxsIA0KICAgICAgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHdyaXR0ZW4gdXNpbmcgc3Vj aCBhIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UuIA0KICAgICAgVGhlIGZvcm1hbCBkZWZpbml0aW9u IG9mIHRoZSBMRkIgY2xhc3NlcyBtYXkgZmFjaWxpdGF0ZSB0aGUgDQogICAgICBldmVudHVhbCBh dXRvbWF0aW9uIG9mIHNvbWUgb2YgdGhlIGNvZGUgZ2VuZXJhdGlvbiBwcm9jZXNzIGFuZCB0aGUg DQogICAgICBmdW5jdGlvbmFsIHZhbGlkYXRpb24gb2YgYXJiaXRyYXJ5IExGQiB0b3BvbG9naWVz LiANCiAgICAgICANCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICBIdW1hbiByZWFkYWJpbGl0eSB3YXMgdGhlIG1vc3QgaW1wb3J0YW50IGZh Y3RvciBjb25zaWRlcmVkIHdoZW4gDQogICAgICBzZWxlY3RpbmcgdGhlIHNwZWNpZmljYXRpb24g bGFuZ3VhZ2UsIHdoZXJlYXMgZW5jb2RpbmcsIGRlY29kaW5nIA0KICAgICAgYW5kIHRyYW5zbWlz c2lvbiBwZXJmb3JtYW5jZSB3YXMgbm90IGEgc2VsZWN0aW9uIGZhY3Rvci4gVGhlIA0KICAgICAg ZW5jb2RpbmcgbWV0aG9kIGZvciBvdmVyIHRoZSB3aXJlIHRyYW5zcG9ydCBpcyBub3QgZGVwZW5k ZW50IG9uIA0KICAgICAgdGhlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgY2hvc2VuIGFuZCBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIA0KICAgICAgZG9jdW1lbnQgYW5kIHVwIHRvIHRoZSBG b3JDRVMgcHJvdG9jb2wgdG8gZGVmaW5lLiAgIA0KICAgICAgIA0KICAgICAgWE1MIHdhcyBjaG9z ZW4gYXMgdGhlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgaW4gdGhpcyBkb2N1bWVudCwgDQogICAg ICBiZWNhdXNlIFhNTCBoYXMgdGhlIGFkdmFudGFnZSBvZiBiZWluZyBib3RoIGh1bWFuIGFuZCBt YWNoaW5lIA0KICAgICAgcmVhZGFibGUgd2l0aCB3aWRlbHkgYXZhaWxhYmxlIHRvb2xzIHN1cHBv cnQuICANCiAgICAgICANCiAgIDIuNS4gRG9jdW1lbnQgU3RydWN0dXJlIA0KICAgICAgIA0KICAg ICAgU2VjdGlvbiAzIHByb3ZpZGVzIGEgY29uY2VwdHVhbCBvdmVydmlldyBvZiB0aGUgRkUgbW9k ZWwsIGxheWluZyANCiAgICAgIHRoZSBmb3VuZGF0aW9uIGZvciB0aGUgbW9yZSBkZXRhaWxlZCBk aXNjdXNzaW9uIGFuZCBzcGVjaWZpY2F0aW9ucyANCiAgICAgIGluIHRoZSBzZWN0aW9ucyB0aGF0 IGZvbGxvdy4gIFNlY3Rpb24gNCBhbmQgNSBjb25zdGl0dXRlIHRoZSBjb3JlIA0KICAgICAgb2Yg dGhlIEZFIG1vZGVsLCBkZXRhaWxpbmcgdGhlIHR3byBtYWpvciBjb21wb25lbnRzIGluIHRoZSBG RSANCiAgICAgIG1vZGVsOiBMRkIgbW9kZWwgYW5kIEZFIGxldmVsIGF0dHJpYnV0ZXMgaW5jbHVk aW5nIGNhcGFiaWxpdHkgYW5kIA0KICAgICAgTEZCIHRvcG9sb2d5LiAgU2VjdGlvbiA2IGRpcmVj dGx5IGFkZHJlc3NlcyB0aGUgbW9kZWwgcmVxdWlyZW1lbnRzIA0KICAgICAgaW1wb3NlZCBieSB0 aGUgRm9yQ0VTIHJlcXVpcmVtZW50IGRyYWZ0IFsxXSB3aGlsZSBTZWN0aW9uIDcgDQogICAgICBl eHBsYWlucyBob3cgdGhlIEZFIG1vZGVsIHNob3VsZCBiZSB1c2VkIGluIHRoZSBGb3JDRVMgcHJv dG9jb2wuICANCiAgICANCiAgIDMuIA0gICAgIEZFIE1vZGVsIENvbmNlcHRzICANCiAgICAgICAN CiAgICAgIFNvbWUgb2YgdGhlIGltcG9ydGFudCBjb25jZXB0cyB1c2VkIHRocm91Z2hvdXQgdGhp cyBkb2N1bWVudCBhcmUgDQogICAgICBpbnRyb2R1Y2VkIGluIHRoaXMgc2VjdGlvbi4gIFNlY3Rp b24gMy4xIGV4cGxhaW5zIHRoZSBkaWZmZXJlbmNlIA0KICAgICAgYmV0d2VlbiBhIHN0YXRlIG1v ZGVsIGFuZCBhIGNhcGFiaWxpdHkgbW9kZWwsIGFuZCBkZXNjcmliZXMgaG93IA0KICAgICAgdGhl IHR3byBjYW4gYmUgY29tYmluZWQgaW4gdGhlIEZFIG1vZGVsLiAgU2VjdGlvbiAzLjIgaW50cm9k dWNlcyANCiAgICAgIHRoZSBjb25jZXB0IG9mIExGQnMgKExvZ2ljYWwgRnVuY3Rpb25hbCBCbG9j a3MpIGFzIHRoZSBiYXNpYyANCiAgICAgIGZ1bmN0aW9uYWwgYnVpbGRpbmcgYmxvY2tzIGluIHRo ZSBGRSBtb2RlbC4gIFNlY3Rpb24gMy4zIGRpc2N1c3NlcyANCiAgICAgIHRoZSBsb2dpY2FsIGlu dGVyLWNvbm5lY3Rpb24gYW5kIG9yZGVyaW5nIGJldHdlZW4gTEZCIGluc3RhbmNlcyANCiAgICAg IHdpdGhpbiBhbiBGRSwgdGhhdCBpcywgdGhlIExGQiB0b3BvbG9neS4gIA0KICAgICAgIA0KICAg ICAgVGhlIEZFIG1vZGVsIHByb3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgaXMgY29tcHJpc2VkIG9m IHR3byBtYWpvciANCiAgICAgIGNvbXBvbmVudHM6IHRoZSBMRkIgbW9kZWwgYW5kIEZFIGxldmVs IGF0dHJpYnV0ZXMsIGluY2x1ZGluZyBGRSANCiAgICAgIGNhcGFiaWxpdGllcyBhbmQgTEZCIHRv cG9sb2d5LiAgVGhlIExGQiBtb2RlbCBwcm92aWRlcyB0aGUgY29udGVudCANCiAgICAgIGFuZCBk YXRhIHN0cnVjdHVyZXMgdG8gZGVmaW5lIGVhY2ggaW5kaXZpZHVhbCBMRkIgY2xhc3MuICBGRSAN CiAgICAgIGF0dHJpYnV0ZXMgcHJvdmlkZSBpbmZvcm1hdGlvbiBhdCB0aGUgRkUgbGV2ZWwsIHBh cnRpY3VsYXJseSB0aGUgDQogICAgICBjYXBhYmlsaXRpZXMgb2YgdGhlIEZFIGF0IGEgY29hcnNl IGxldmVsLiAgUGFydCBvZiB0aGUgRkUgbGV2ZWwgDQogICAgICBpbmZvcm1hdGlvbiBpcyB0aGUg TEZCIHRvcG9sb2d5LCB3aGljaCBleHByZXNzZXMgdGhlIGxvZ2ljYWwgDQogICAgICBpbnRlci1j b25uZWN0aW9uIGJldHdlZW4gdGhlIExGQiBpbnN0YW5jZXMgYWxvbmcgdGhlIGRhdGFwYXRoKHMp IA0KICAgICAgd2l0aGluIHRoZSBGRS4gIERldGFpbHMgb2YgdGhlc2UgY29tcG9uZW50cyBhcmUg ZGVzY3JpYmVkIGluIA0KICAgICAgU2VjdGlvbiA0IGFuZCA1LiAgVGhlIGludGVudCBvZiB0aGlz IHNlY3Rpb24gaXMgdG8gZGlzY3VzcyB0aGVzZSANCiAgICAgIGNvbmNlcHRzIGF0IHRoZSBoaWdo IGxldmVsIGFuZCBsYXkgdGhlIGZvdW5kYXRpb24gZm9yIHRoZSBkZXRhaWxlZCANCiAgICAgIGRl c2NyaXB0aW9uIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuIA0KICAgICAgIA0KICAgMy4xLiBG RSBDYXBhYmlsaXR5IE1vZGVsIGFuZCBTdGF0ZSBNb2RlbCANCiAgICANCiAgIFlhbmcsIGV0IGFs LiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug OF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAg ICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgIA0KICAgICAgVGhlIEZvckNFUyBG RSBtb2RlbCBtdXN0IGRlc2NyaWJlIGJvdGggYSBjYXBhYmlsaXR5IGFuZCBhIHN0YXRlIA0KICAg ICAgbW9kZWwuICBUaGUgRkUgY2FwYWJpbGl0eSBtb2RlbCBkZXNjcmliZXMgdGhlIGNhcGFiaWxp dGllcyBhbmQgDQogICAgICBjYXBhY2l0aWVzIG9mIGFuIEZFIGJ5IHNwZWNpZnlpbmcgdGhlIHZh cmlhdGlvbiBpbiBmdW5jdGlvbnMgDQogICAgICBzdXBwb3J0ZWQgYW5kIGFueSBsaW1pdGF0aW9u cy4gIFRoZSBGRSBzdGF0ZSBtb2RlbCBkZXNjcmliZXMgdGhlIA0KICAgICAgY3VycmVudCBzdGF0 ZSBvZiB0aGUgRkUsIHRoYXQgaXMsIHRoZSBpbnN0YW50YW5lb3VzIHZhbHVlcyBvciANCiAgICAg IG9wZXJhdGlvbmFsIGJlaGF2aW9yIG9mIHRoZSBGRS4gIA0KICAgICAgIA0KICAgICAgQ29uY2Vw dHVhbGx5LCB0aGUgRkUgY2FwYWJpbGl0eSBtb2RlbCB0ZWxscyB0aGUgQ0Ugd2hpY2ggc3RhdGVz IA0KICAgICAgYXJlIGFsbG93ZWQgb24gYW4gRkUsIHdpdGggY2FwYWNpdHkgaW5mb3JtYXRpb24g aW5kaWNhdGluZyBjZXJ0YWluIA0KICAgICAgcXVhbnRpdGF0aXZlIGxpbWl0cyBvciBjb25zdHJh aW50cy4gIFRodXMsIHRoZSBDRSBoYXMgZ2VuZXJhbCANCiAgICAgIGtub3dsZWRnZSBhYm91dCBj b25maWd1cmF0aW9ucyB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIGEgcGFydGljdWxhciANCiAgICAg IEZFLiAgRm9yIGV4YW1wbGUsIGFuIEZFIGNhcGFiaWxpdHkgbW9kZWwgbWF5IGRlc2NyaWJlIHRo ZSBGRSBhdCBhIA0KICAgICAgY29hcnNlIGxldmVsIHN1Y2ggYXM6IA0KICAgICAgIA0KICAgICAg ICAuIHRoaXMgRkUgY2FuIGhhbmRsZSBJUHY0IGFuZCBJUHY2IGZvcndhcmRpbmc7IA0KICAgICAg ICAuIHRoaXMgRkUgY2FuIHBlcmZvcm0gY2xhc3NpZmljYXRpb24gb24gdGhlIGZvbGxvd2luZyBm aWVsZHM6IA0KICAgICAgICAgICBzb3VyY2UgSVAgYWRkcmVzcywgZGVzdGluYXRpb24gSVAgYWRk cmVzcywgc291cmNlIHBvcnQgDQogICAgICAgICAgIG51bWJlciwgZGVzdGluYXRpb24gcG9ydCBu dW1iZXIsIGV0YzsgDQogICAgICAgIC4gdGhpcyBGRSBjYW4gcGVyZm9ybSBtZXRlcmluZzsgDQog ICAgICAgIC4gdGhpcyBGRSBjYW4gaGFuZGxlIHVwIHRvIE4gcXVldWVzIChjYXBhY2l0eSk7IA0K ICAgICAgICAuIHRoaXMgRkUgY2FuIGFkZCBhbmQgcmVtb3ZlIGVuY2Fwc3VsYXRpbmcgaGVhZGVy cyBvZiB0eXBlcyANCiAgICAgICAgICAgaW5jbHVkaW5nIElQU2VjLCBHUkUsIEwyVFAuIA0KICAg IA0KICAgICAgV2hpbGUgb25lIGNvdWxkIHRyeSBhbmQgYnVpbGQgYW4gb2JqZWN0IG1vZGVsIHRv IGZ1bGx5IHJlcHJlc2VudCANCiAgICAgIHRoZSBGRSBjYXBhYmlsaXRpZXMsIG90aGVyIGVmZm9y dHMgZm91bmQgdGhpcyB0byBiZSBhIHNpZ25pZmljYW50IA0KICAgICAgdW5kZXJ0YWtpbmcuICBU aGUgbWFpbiBkaWZmaWN1bHR5IGFyaXNlcyBpbiBkZXNjcmliaW5nIGRldGFpbGVkIA0KICAgICAg bGltaXRzLCBzdWNoIGFzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBjbGFzc2lmaWVycywgcXVldWVz LCBidWZmZXIgDQogICAgICBwb29scywgYW5kIG1ldGVycyB0aGUgRkUgY2FuIHByb3ZpZGUuICBX ZSBiZWxpZXZlIHRoYXQgYSBnb29kIA0KICAgICAgYmFsYW5jZSBiZXR3ZWVuIHNpbXBsaWNpdHkg YW5kIGZsZXhpYmlsaXR5IGNhbiBiZSBhY2hpZXZlZCBmb3IgdGhlIA0KICAgICAgRkUgbW9kZWwg YnkgY29tYmluaW5nIGNvYXJzZSBsZXZlbCBjYXBhYmlsaXR5IHJlcG9ydGluZyB3aXRoIGFuIA0K ICAgICAgZXJyb3IgcmVwb3J0aW5nIG1lY2hhbmlzbS4gIFRoYXQgaXMsIGlmIHRoZSBDRSBhdHRl bXB0cyB0byANCiAgICAgIGluc3RydWN0IHRoZSBGRSB0byBzZXQgdXAgc29tZSBzcGVjaWZpYyBi ZWhhdmlvciBpdCBjYW5ub3QgDQogICAgICBzdXBwb3J0LCB0aGUgRkUgd2lsbCByZXR1cm4gYW4g ZXJyb3IgaW5kaWNhdGluZyB0aGUgcHJvYmxlbS4gIA0KICAgICAgRXhhbXBsZXMgb2Ygc2ltaWxh ciBhcHByb2FjaGVzIGluY2x1ZGUgRGlmZlNlcnYgUElCIFs0XSBhbmQgDQogICAgICBGcmFtZXdv cmsgUElCIFs1XS4gDQogICAgDQogICAgICBUaGUgRkUgc3RhdGUgbW9kZWwgcHJlc2VudHMgdGhl IHNuYXBzaG90IHZpZXcgb2YgdGhlIEZFIHRvIHRoZSBDRS4gIA0KICAgICAgRm9yIGV4YW1wbGUs IHVzaW5nIGFuIEZFIHN0YXRlIG1vZGVsLCBhbiBGRSBtYXkgYmUgZGVzY3JpYmVkIHRvIA0KICAg ICAgaXRzIGNvcnJlc3BvbmRpbmcgQ0UgYXMgdGhlIGZvbGxvd2luZzogIA0KICAgICAgICAuIG9u IGEgZ2l2ZW4gcG9ydCwgdGhlIHBhY2tldHMgYXJlIGNsYXNzaWZpZWQgdXNpbmcgYSBnaXZlbiAN CiAgICAgICAgICAgY2xhc3NpZmljYXRpb24gZmlsdGVyOyANCiAgICAgICAgLiB0aGUgZ2l2ZW4g Y2xhc3NpZmllciByZXN1bHRzIGluIHBhY2tldHMgYmVpbmcgbWV0ZXJlZCBpbiBhIA0KICAgICAg ICAgICBjZXJ0YWluIHdheSwgYW5kIHRoZW4gbWFya2VkIGluIGEgY2VydGFpbiB3YXk7IA0KICAg ICAgICAuIHRoZSBwYWNrZXRzIGNvbWluZyBmcm9tIHNwZWNpZmljIG1hcmtlcnMgYXJlIGRlbGl2 ZXJlZCBpbnRvIGEgDQogICAgICAgICAgIHNoYXJlZCBxdWV1ZSBmb3IgaGFuZGxpbmcsIHdoaWxl IG90aGVyIHBhY2tldHMgYXJlIGRlbGl2ZXJlZCANCiAgICAgICAgICAgdG8gYSBkaWZmZXJlbnQg cXVldWU7IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAg DQogICAgICAgIC4gYSBzcGVjaWZpYyBzY2hlZHVsZXIgd2l0aCBzcGVjaWZpYyBiZWhhdmlvciBh bmQgcGFyYW1ldGVycyANCiAgICAgICAgICAgd2lsbCBzZXJ2aWNlIHRoZXNlIGNvbGxlY3RlZCBx dWV1ZXMuIA0KICAgICAgIA0KICAgICAgRmlndXJlIDEgc2hvd3MgdGhlIGNvbmNlcHRzIG9mIEZF IHN0YXRlLCBjYXBhYmlsaXRpZXMgYW5kIA0KICAgICAgY29uZmlndXJhdGlvbiBpbiB0aGUgY29u dGV4dCBvZiBDRS1GRSBjb21tdW5pY2F0aW9uIHZpYSB0aGUgRm9yQ0VTIA0KICAgICAgcHJvdG9j b2wuIA0KICAgIA0KICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLSsgDQogICAgICAgICAgIHwgICAgICAgfCBGRSBjYXBh YmlsaXRpZXM6IHdoYXQgaXQgY2FuL2Nhbm5vdCBkby4gIHwgICAgICAgfCANCiAgICAgICAgICAg fCAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAg ICB8IA0KICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgIHwgDQogICAgICAgICAgIHwgICBDRSAgfCBGRSBzdGF0ZTogd2hh dCBpdCBpcyBub3cuICAgICAgICAgICAgICAgIHwgIEZFICAgfCANCiAgICAgICAgICAgfCAgICAg ICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICB8IA0K ICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgIHwgDQogICAgICAgICAgIHwgICAgICAgfCBGRSBjb25maWd1cmF0aW9uOiB3 aGF0IGl0IHNob3VsZCBiZS4gICAgIHwgICAgICAgfCANCiAgICAgICAgICAgfCAgICAgICB8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICB8IA0KICAgICAg ICAgICArLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsgDQogICAgICAgDQogICAgICBGaWd1cmUgMS4gSWxsdXN0cmF0aW9uIG9mIEZFIHN0 YXRlLCBjYXBhYmlsaXRpZXMgYW5kIGNvbmZpZ3VyYXRpb24gDQogICAgICAgICAgZXhjaGFuZ2Ug aW4gdGhlIGNvbnRleHQgb2YgQ0UtRkUgY29tbXVuaWNhdGlvbiB2aWEgRm9yQ0VTLiANCiAgICAN CiAgICAgIFRoZSBjb25jZXB0cyByZWxhdGluZyB0byBMRkJzLCBwYXJ0aWN1bGFybHkgY2FwYWJp bGl0eSBhdCB0aGUgTEZCIA0KICAgICAgbGV2ZWwgYW5kIExGQiB0b3BvbG9neSB3aWxsIGJlIGRp c2N1c3NlZCBpbiB0aGUgcmVzdCBvZiB0aGlzIA0KICAgICAgc2VjdGlvbi4gDQogICAgICAgDQog ICAgICBDYXBhYmlsaXR5IGluZm9ybWF0aW9uIGF0IHRoZSBMRkIgbGV2ZWwgaXMgYW4gaW50ZWdy YWwgcGFydCBvZiB0aGUgDQogICAgICBMRkIgbW9kZWwsIGFuZCBpcyBtb2RlbGVkIHRoZSBzYW1l IHdheSBhcyB0aGUgb3RoZXIgb3BlcmF0aW9uYWwgDQogICAgICBwYXJhbWV0ZXJzIGluc2lkZSBh biBMRkIuICBGb3IgZXhhbXBsZSwgd2hlbiBjZXJ0YWluIGZlYXR1cmVzIG9mIA0KICAgICAgYW4g TEZCIGNsYXNzIGFyZSBvcHRpb25hbCwgaXQgbXVzdCBiZSBwb3NzaWJsZSBmb3IgdGhlIENFIHRv IA0KICAgICAgZGV0ZXJtaW5lIHdoZXRoZXIgdGhvc2Ugb3B0aW9uYWwgZmVhdHVyZXMgYXJlIHN1 cHBvcnRlZCBieSBhIGdpdmVuIA0KICAgICAgTEZCIGluc3RhbmNlLiAgU3VjaCBjYXBhYmlsaXR5 IGluZm9ybWF0aW9uIGNhbiBiZSBtb2RlbGVkIGFzIGEgDQogICAgICByZWFkLW9ubHkgYXR0cmli dXRlIGluIHRoZSBMRkIgaW5zdGFuY2UsIHNlZSBTZWN0aW9uIDQuNy41IGZvciANCiAgICAgIGRl dGFpbHMuIA0KICAgICAgIA0KICAgICAgQ2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBhdCB0aGUgRkUg bGV2ZWwgbWF5IGRlc2NyaWJlIHRoZSBMRkIgDQogICAgICBjbGFzc2VzIHRoYXQgdGhlIEZFIGNh biBpbnN0YW50aWF0ZTsgdGhlIG51bWJlciBvZiBpbnN0YW5jZXMgb2YgDQogICAgICBlYWNoIHRo YXQgY2FuIGJlIGNyZWF0ZWQ7IHRoZSB0b3BvbG9naWNhbCAobGlua2FnZSkgbGltaXRhdGlvbnMg DQogICAgICBiZXR3ZWVuIHRoZXNlIExGQiBpbnN0YW5jZXMsIGV0Yy4gIFNlY3Rpb24gNSBkZWZp bmVzIHRoZSBGRSBsZXZlbCANCiAgICAgIGF0dHJpYnV0ZXMgaW5jbHVkaW5nIGNhcGFiaWxpdHkg aW5mb3JtYXRpb24uICANCiAgICAgICANCiAgICAgIE9uY2UgdGhlIEZFIGNhcGFiaWxpdHkgaXMg ZGVzY3JpYmVkIHRvIHRoZSBDRSwgdGhlIEZFIHN0YXRlIA0KICAgICAgaW5mb3JtYXRpb24gY2Fu IGJlIHJlcHJlc2VudGVkIGJ5IHR3byBsZXZlbHMuICBUaGUgZmlyc3QgbGV2ZWwgaXMgDQogICAg ICB0aGUgbG9naWNhbGx5IHNlcGFyYWJsZSBhbmQgZGlzdGluY3QgcGFja2V0IHByb2Nlc3Npbmcg ZnVuY3Rpb25zLCANCiAgICAgIGNhbGxlZCBMb2dpY2FsIEZ1bmN0aW9uYWwgQmxvY2tzIChMRkJz KS4gIFRoZSBzZWNvbmQgbGV2ZWwgb2YgDQogICAgICBpbmZvcm1hdGlvbiBkZXNjcmliZXMgaG93 IHRoZXNlIGluZGl2aWR1YWwgTEZCcyBhcmUgb3JkZXJlZCBhbmQgDQogICAgICBwbGFjZWQgYWxv bmcgdGhlIGRhdGFwYXRoIHRvIGRlbGl2ZXIgYSBjb21wbGV0ZSBmb3J3YXJkaW5nIHBsYW5lIA0K ICAgICAgc2VydmljZS4gIFRoZSBpbnRlcmNvbm5lY3Rpb24gYW5kIG9yZGVyaW5nIG9mIHRoZSBM RkJzIGlzIGNhbGxlZCANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0 IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0gDQoMICAgSW50ZXJuZXQgRHJh ZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAg IA0KICAgIA0KICAgICAgTEZCIFRvcG9sb2d5LiAgU2VjdGlvbiAzLjIgZGlzY3Vzc2VzIGhpZ2gg bGV2ZWwgY29uY2VwdHMgYXJvdW5kIA0KICAgICAgTEZCcywgd2hlcmVhcyBTZWN0aW9uIDMuMyBk aXNjdXNzZXMgTEZCIHRvcG9sb2d5IGlzc3Vlcy4gDQogICAgICAgDQogICAzLjIuIExGQiAoTG9n aWNhbCBGdW5jdGlvbmFsIEJsb2NrKSBNb2RlbGluZyANCiAgICAgICANCiAgICAgIEVhY2ggTEZC IHBlcmZvcm1zIGEgd2VsbC1kZWZpbmVkIGFjdGlvbiBvciBjb21wdXRhdGlvbiBvbiB0aGUgDQog ICAgICBwYWNrZXRzIHBhc3NpbmcgdGhyb3VnaCBpdC4gIFVwb24gY29tcGxldGlvbiBvZiBpdHMg cHJlc2NyaWJlZCANCiAgICAgIGZ1bmN0aW9uLCBlaXRoZXIgdGhlIHBhY2tldHMgYXJlIG1vZGlm aWVkIGluIGNlcnRhaW4gd2F5cyAoZS5nLiwgDQogICAgICBkZWNhcHN1bGF0b3IsIG1hcmtlciks IG9yIHNvbWUgcmVzdWx0cyBhcmUgZ2VuZXJhdGVkIGFuZCBzdG9yZWQsIA0KICAgICAgb2Z0ZW4g aW4gdGhlIGZvcm0gb2YgbWV0YWRhdGEgKGUuZy4sIGNsYXNzaWZpZXIpLiAgRWFjaCBMRkIgDQog ICAgICB0eXBpY2FsbHkgcGVyZm9ybXMgYSBzaW5nbGUgYWN0aW9uLiAgQ2xhc3NpZmllcnMsIHNo YXBlcnMgYW5kIA0KICAgICAgbWV0ZXJzIGFyZSBhbGwgZXhhbXBsZXMgb2Ygc3VjaCBMRkJzLiAg TW9kZWxpbmcgTEZCcyBhdCBzdWNoIGEgDQogICAgICBmaW5lIGdyYW51bGFyaXR5IGFsbG93cyB1 cyB0byB1c2UgYSBzbWFsbCBudW1iZXIgb2YgTEZCcyB0byANCiAgICAgIGV4cHJlc3MgdGhlIGhp Z2hlci1vcmRlciBGRSBmdW5jdGlvbnMgKHN1Y2ggYXMgYW4gSVB2NCBmb3J3YXJkZXIpIA0KICAg ICAgcHJlY2lzZWx5LCB3aGljaCBpbiB0dXJuIGNhbiBkZXNjcmliZSBtb3JlIGNvbXBsZXggbmV0 d29ya2luZyANCiAgICAgIGZ1bmN0aW9ucyBhbmQgdmVuZG9yIGltcGxlbWVudGF0aW9ucyBvZiBz b2Z0d2FyZSBhbmQgaGFyZHdhcmUuICANCiAgICAgIFRoZXNlIExGQnMgd2lsbCBiZSBkZWZpbmVk IGluIGRldGFpbCBpbiBvbmUgb3IgbW9yZSBkb2N1bWVudHMuIA0KICAgICAgIA0KICAgICAgQW4g TEZCIGhhcyBvbmUgb3IgbW9yZSBpbnB1dHMsIGVhY2ggb2Ygd2hpY2ggdGFrZXMgYSBwYWNrZXQg UCwgYW5kIA0KICAgICAgb3B0aW9uYWxseSBtZXRhZGF0YSBNOyBhbmQgcHJvZHVjZXMgb25lIG9y IG1vcmUgb3V0cHV0cywgZWFjaCBvZiANCiAgICAgIHdoaWNoIGNhcnJpZXMgYSBwYWNrZXQgUCcs IGFuZCBvcHRpb25hbGx5IG1ldGFkYXRhIE0nLiAgTWV0YWRhdGEgDQogICAgICBpcyBkYXRhIGFz c29jaWF0ZWQgd2l0aCB0aGUgcGFja2V0IGluIHRoZSBuZXR3b3JrIHByb2Nlc3NpbmcgDQogICAg ICBkZXZpY2UgKHJvdXRlciwgc3dpdGNoLCBldGMuKSBhbmQgaXMgcGFzc2VkIGZyb20gb25lIExG QiB0byB0aGUgDQogICAgICBuZXh0LCBidXQgaXMgbm90IHNlbnQgYWNyb3NzIHRoZSBuZXR3b3Jr LiAgSW4gZ2VuZXJhbCwgbXVsdGlwbGUgDQogICAgICBMRkJzIGFyZSBjb250YWluZWQgaW4gb25l IEZFLCBhcyBzaG93biBpbiBGaWd1cmUgMiwgYW5kIGFsbCB0aGUgDQogICAgICBMRkJzIHNoYXJl IHRoZSBzYW1lIEZvckNFUyBwcm90b2NvbCB0ZXJtaW5hdGlvbiBwb2ludCB0aGF0IA0KICAgICAg aW1wbGVtZW50cyB0aGUgRm9yQ0VTIHByb3RvY29sIGxvZ2ljIGFuZCBtYWludGFpbnMgdGhlIA0K ICAgICAgY29tbXVuaWNhdGlvbiBjaGFubmVsIHRvIGFuZCBmcm9tIHRoZSBDRS4gICANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0 IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQoMICAgSW50ZXJuZXQgRHJh ZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAg IA0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgQ0UgICAgIHwgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBeIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEZwIHJl ZmVyZW5jZSBwb2ludCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyANCiAgICAgICAgfCBGRSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAg ICAgfCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgfCANCiAgICAgICAgfCB8ICAgICAgICAgICAgICAgIEZvckNFUyBwcm90b2NvbCAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCANCiAgICAgICAgfCB8ICAgICAgICAgICAgICAg ICAgIHRlcm1pbmF0aW9uIHBvaW50ICAgICAgICAgICAgICAgICAgICAgIHwgfCANCiAgICAgICAg fCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgfCANCiAgICAgICAgfCAgICAgICAgICAgXiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBeICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgOiAgICAgICAg ICAgICAgICAgICAgICAgICAgICA6IEludGVybmFsIGNvbnRyb2wgICAgfCANCiAgICAgICAgfCAg ICAgICAgICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAgICA6ICAgICAgICAgICAgICAgICAg ICAgfCANCiAgICAgICAgfCAgICAgICArLS0tOi0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS06 LS0tLS0tLS0tLXwgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICB8ICAgOkxGQjEgICAgICB8 ICAgICAgICAgICAgIHwgICA6ICAgICBMRkIyIHwgICAgICAgICAgfCANCiAgICAgICAgfCA9PT09 PT58ICAgdiAgICAgICAgICB8PT09PT09PT09PT09PnwgICB2ICAgICAgICAgIHw9PT09PT0+Li4u fCANCiAgICAgICAgfCBJbnB1dHN8ICstLS0tLS0tLS0tKyB8T3V0cHV0cyAgICAgIHwgKy0tLS0t LS0tLS0rIHwgICAgICAgICAgfCANCiAgICAgICAgfCAoUCxNKSB8IHxBdHRyaWJ1dGVzfCB8KFAn LE0nKSAgICAgIHwgfEF0dHJpYnV0ZXN8IHwoUCIsTSIpICAgfCANCiAgICAgICAgfCAgICAgICB8 ICstLS0tLS0tLS0tKyB8ICAgICAgICAgICAgIHwgKy0tLS0tLS0tLS0rIHwgICAgICAgICAgfCAN CiAgICAgICAgfCAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLSsgICAgICAgICAgfCANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgIEZpZ3VyZSAyLiBHZW5lcmljIExGQiBEaWFncmFtIA0KICAgIA0KICAgICAgQW4gTEZC LCBhcyBzaG93biBpbiBGaWd1cmUgMiwgaGFzIGlucHV0cywgb3V0cHV0cyBhbmQgYXR0cmlidXRl cyANCiAgICAgIHRoYXQgY2FuIGJlIHF1ZXJpZWQgYW5kIG1hbmlwdWxhdGVkIGJ5IHRoZSBDRSBp bmRpcmVjdGx5IHZpYSBhbiBGcCANCiAgICAgIHJlZmVyZW5jZSBwb2ludCAoZGVmaW5lZCBpbiBS RkMgMzc0NiBbMl0pIGFuZCB0aGUgRm9yQ0VTIHByb3RvY29sIA0KICAgICAgdGVybWluYXRpb24g cG9pbnQuICBUaGUgaG9yaXpvbnRhbCBheGlzIGlzIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIA0K ICAgICAgZm9yIGNvbm5lY3RpbmcgdGhlIGlucHV0cyBhbmQgb3V0cHV0cyBvZiBMRkJzIHdpdGhp biB0aGUgc2FtZSBGRS4gDQogICAgICBUaGUgdmVydGljYWwgYXhpcyBiZXR3ZWVuIHRoZSBDRSBh bmQgdGhlIEZFIGRlbm90ZXMgdGhlIEZwIA0KICAgICAgcmVmZXJlbmNlIHBvaW50IHdoZXJlIGJp ZGlyZWN0aW9uYWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBDRSANCiAgICAgIGFuZCBGRSBv Y2N1cnM6IHRoZSBDRSB0byBGRSBjb21tdW5pY2F0aW9uIGlzIGZvciBjb25maWd1cmF0aW9uLCAN CiAgICAgIGNvbnRyb2wgYW5kIHBhY2tldCBpbmplY3Rpb24gd2hpbGUgRkUgdG8gQ0UgY29tbXVu aWNhdGlvbiBpcyB1c2VkIA0KICAgICAgZm9yIHBhY2tldCByZS1kaXJlY3Rpb24gdG8gdGhlIGNv bnRyb2wgcGxhbmUsIG1vbml0b3JpbmcgYW5kIA0KICAgICAgYWNjb3VudGluZyBpbmZvcm1hdGlv biwgZXJyb3JzLCBldGMuICBOb3RlIHRoYXQgdGhlIGludGVyYWN0aW9uIA0KICAgICAgYmV0d2Vl biB0aGUgQ0UgYW5kIHRoZSBMRkIgaXMgb25seSBhYnN0cmFjdCBhbmQgaW5kaXJlY3QuICBUaGUg DQogICAgICByZXN1bHQgb2Ygc3VjaCBhbiBpbnRlcmFjdGlvbiBpcyBmb3IgdGhlIENFIHRvIGlu ZGlyZWN0bHkgDQogICAgICBtYW5pcHVsYXRlIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBMRkIgaW5z dGFuY2VzLiAgIA0KICAgIA0KICAgICAgQSBuYW1lc3BhY2UgaXMgdXNlZCB0byBhc3NvY2lhdGUg YSB1bmlxdWUgbmFtZSBvciBJRCB3aXRoIGVhY2ggTEZCIA0KICAgICAgY2xhc3MuICBUaGUgbmFt ZXNwYWNlIG11c3QgYmUgZXh0ZW5zaWJsZSBzbyB0aGF0IGEgbmV3IExGQiBjbGFzcyANCiAgICAg IGNhbiBiZSBhZGRlZCBsYXRlciB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgaW5ub3ZhdGlvbiBpbiB0 aGUgDQogICAgICBmb3J3YXJkaW5nIHBsYW5lLiAgICAgDQogICAgDQogICBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJd IA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgIExGQiBvcGVyYXRpb24g bXVzdCBiZSBzcGVjaWZpZWQgaW4gdGhlIG1vZGVsIHRvIGFsbG93IHRoZSBDRSB0byANCiAgICAg IHVuZGVyc3RhbmQgdGhlIGJlaGF2aW9yIG9mIHRoZSBmb3J3YXJkaW5nIGRhdGFwYXRoLiAgRm9y IGluc3RhbmNlLCANCiAgICAgIHRoZSBDRSBtdXN0IHVuZGVyc3RhbmQgYXQgd2hhdCBwb2ludCBp biB0aGUgZGF0YXBhdGggdGhlIElQdjQgDQogICAgICBoZWFkZXIgVFRMIGlzIGRlY3JlbWVudGVk LiAgVGhhdCBpcywgdGhlIENFIG5lZWRzIHRvIGtub3cgaWYgYSANCiAgICAgIGNvbnRyb2wgcGFj a2V0IGNvdWxkIGJlIGRlbGl2ZXJlZCB0byBpdCBlaXRoZXIgYmVmb3JlIG9yIGFmdGVyIA0KICAg ICAgdGhpcyBwb2ludCBpbiB0aGUgZGF0YXBhdGguICBJbiBhZGRpdGlvbiwgdGhlIENFIG11c3Qg dW5kZXJzdGFuZCANCiAgICAgIHdoZXJlIGFuZCB3aGF0IHR5cGUgb2YgaGVhZGVyIG1vZGlmaWNh dGlvbnMgKGUuZy4sIHR1bm5lbCBoZWFkZXIgDQogICAgICBhcHBlbmQgb3Igc3RyaXApIGFyZSBw ZXJmb3JtZWQgK2J5IHRoZSBGRXMuICBGdXJ0aGVyLCB0aGUgQ0UgbXVzdCANCiAgICAgIHZlcmlm eSB0aGF0IHRoZSB2YXJpb3VzIExGQnMgYWxvbmcgYSBkYXRhcGF0aCB3aXRoaW4gYW4gRkUgYXJl IA0KICAgICAgY29tcGF0aWJsZSB0byBsaW5rIHRvZ2V0aGVyLiANCiAgICAgICANCiAgICAgIFRo ZXJlIGlzIHZhbHVlIHRvIHZlbmRvcnMgaWYgdGhlIG9wZXJhdGlvbiBvZiBMRkIgY2xhc3NlcyBj YW4gYmUgDQogICAgICBleHByZXNzZWQgaW4gc3VmZmljaWVudCBkZXRhaWwgc28gdGhhdCBwaHlz aWNhbCBkZXZpY2VzIA0KICAgICAgaW1wbGVtZW50aW5nIGRpZmZlcmVudCBMRkIgZnVuY3Rpb25z IGNhbiBiZSBpbnRlZ3JhdGVkIGVhc2lseSBpbnRvIA0KICAgICAgYW4gRkUgZGVzaWduLiAgVGhl cmVmb3JlLCBhIHNlbWktZm9ybWFsIHNwZWNpZmljYXRpb24gaXMgbmVlZGVkOyANCiAgICAgIHRo YXQgaXMsIGEgdGV4dCBkZXNjcmlwdGlvbiBvZiB0aGUgTEZCIG9wZXJhdGlvbiAoaHVtYW4gcmVh ZGFibGUpLCANCiAgICAgIGJ1dCBzdWZmaWNpZW50bHkgc3BlY2lmaWMgYW5kIHVuYW1iaWd1b3Vz IHRvIGFsbG93IGNvbmZvcm1hbmNlIA0KICAgICAgdGVzdGluZyBhbmQgZWZmaWNpZW50IGRlc2ln biwgc28gdGhhdCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gDQogICAgICBkaWZmZXJlbnQgQ0Vz IGFuZCBGRXMgY2FuIGJlIGFjaGlldmVkLiAgDQogICAgICAgDQogICAgICBUaGUgTEZCIGNsYXNz IG1vZGVsIHNwZWNpZmllcyBpbmZvcm1hdGlvbiBzdWNoIGFzOiANCiAgICAgICAgLiBudW1iZXIg b2YgaW5wdXRzIGFuZCBvdXRwdXRzIChhbmQgd2hldGhlciB0aGV5IGFyZSANCiAgICAgICAgICAg Y29uZmlndXJhYmxlKSANCiAgICAgICAgLiBtZXRhZGF0YSByZWFkL2NvbnN1bWVkIGZyb20gaW5w dXRzOyANCiAgICAgICAgLiBtZXRhZGF0YSBwcm9kdWNlZCBhdCB0aGUgb3V0cHV0czsgDQogICAg ICAgIC4gcGFja2V0IHR5cGUocykgYWNjZXB0ZWQgYXQgdGhlIGlucHV0cyBhbmQgZW1pdHRlZCBh dCB0aGUgDQogICAgICAgICAgIG91dHB1dHM7IA0KICAgICAgICAuIHBhY2tldCBjb250ZW50IG1v ZGlmaWNhdGlvbnMgKGluY2x1ZGluZyBlbmNhcHN1bGF0aW9uIG9yIA0KICAgICAgICAgICBkZWNh cHN1bGF0aW9uKTsgDQogICAgICAgIC4gcGFja2V0IHJvdXRpbmcgY3JpdGVyaWEgKHdoZW4gbXVs dGlwbGUgb3V0cHV0cyBvbiBhbiBMRkIgYXJlIA0KICAgICAgICAgICBwcmVzZW50KTsgDQogICAg ICAgIC4gcGFja2V0IHRpbWluZyBtb2RpZmljYXRpb25zOyANCiAgICAgICAgLiBwYWNrZXQgZmxv dyBvcmRlcmluZyBtb2RpZmljYXRpb25zOyANCiAgICAgICAgLiBMRkIgY2FwYWJpbGl0eSBpbmZv cm1hdGlvbjsgDQogICAgICAgIC4gTEZCIG9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMsIGV0Yy4gDQog ICAgICAgDQogICAgICBTZWN0aW9uIDQgb2YgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGRldGFp bGVkIGRpc2N1c3Npb24gb2YgdGhlIA0KICAgICAgTEZCIG1vZGVsIHdpdGggYSBmb3JtYWwgc3Bl Y2lmaWNhdGlvbiBvZiBMRkIgY2xhc3Mgc2NoZW1hLiAgVGhlIA0KICAgICAgcmVzdCBvZiBTZWN0 aW9uIDMuMiBvbmx5IGludGVuZHMgdG8gcHJvdmlkZSBhIGNvbmNlcHR1YWwgb3ZlcnZpZXcgDQog ICAgICBvZiBzb21lIGltcG9ydGFudCBpc3N1ZXMgaW4gTEZCIG1vZGVsaW5nLCB3aXRob3V0IGNv dmVyaW5nIGFsbCB0aGUgDQogICAgICBzcGVjaWZpYyBkZXRhaWxzLiANCiAgICAgICAgIA0KICAg My4yLjEuIExGQiBPdXRwdXRzIA0KICAgICAgIA0KICAgICAgQW4gTEZCIG91dHB1dCBpcyBhIGNv bmNlcHR1YWwgcG9ydCBvbiBhbiBMRkIgdGhhdCBjYW4gc2VuZCANCiAgICAgIGluZm9ybWF0aW9u IHRvIGFub3RoZXIgTEZCLiAgVGhlIGluZm9ybWF0aW9uIGlzIHR5cGljYWxseSBhIHBhY2tldCAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSAxM10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg YW5kIGl0cyBhc3NvY2lhdGVkIG1ldGFkYXRhLCBhbHRob3VnaCBpbiBzb21lIGNhc2VzIGl0IG1p Z2h0IA0KICAgICAgY29uc2lzdCBvZiBvbmx5IG1ldGFkYXRhLCBpLmUuLCB3aXRoIG5vIHBhY2tl dCBkYXRhLiANCiAgICAgICANCiAgICAgIEEgc2luZ2xlIExGQiBvdXRwdXQgY2FuIGJlIGNvbm5l Y3RlZCB0byBvbmx5IG9uZSBMRkIgaW5wdXQuICBUaGlzIA0KICAgICAgaXMgcmVxdWlyZWQgdG8g bWFrZSB0aGUgcGFja2V0IGZsb3cgdGhyb3VnaCB0aGUgTEZCIHRvcG9sb2d5IA0KICAgICAgdW5h bWJpZ3VvdXNseS4gDQogICAgICAgDQogICAgICBTb21lIExGQnMgd2lsbCBoYXZlIGEgc2luZ2xl IG91dHB1dCwgYXMgZGVwaWN0ZWQgaW4gRmlndXJlIDMuYS4gDQogICAgICAgDQogICAgICAgICAr LS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAg ICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg T1VUICstLT4gDQogICAgICAgIC4uLiAgICAgICAgICBPVVQgKy0tPiAgICAgICAgICAgLi4uICAg ICAgICAgICAgICAgIHwgDQogICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwgICAgRVhDRVBUSU9OT1VUICstLT4gDQogICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0t KyAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAg IGEuIE9uZSBvdXRwdXQgICAgICAgICAgICAgICBiLiBUd28gZGlzdGluY3Qgb3V0cHV0cyANCiAg ICAgICANCiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAg ICBFWENFUFRJT05PVVQgKy0tPiANCiAgICAgICAgIHwgICAgICAgICBPVVQ6MSArLS0+ICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgLi4uICAgICAgICBPVVQ6MiArLS0+ ICAgICAgICAgICAuLi4gICAgICAgICAgT1VUOjEgKy0tPiANCiAgICAgICAgIHwgICAgICAgICAu Li4gICArLi4uICAgICAgICAgICAgfCAgICAgICAgICAgT1VUOjIgKy0tPiANCiAgICAgICAgIHwg ICAgICAgICBPVVQ6biArLS0+ICAgICAgICAgICAgfCAgICAgICAgICAgLi4uICAgKy4uLiANCiAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgfCAgICAgICAgICAgT1VUOm4g Ky0tPiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICAgICANCiAgICAgICAgYy4gT25lIG91dHB1dCBncm91cCAgICAgICBk LiBPbmUgb3V0cHV0IGFuZCBvbmUgb3V0cHV0IGdyb3VwIA0KICAgICAgIA0KICAgICAgRmlndXJl IDMuIEV4YW1wbGVzIG9mIExGQnMgd2l0aCB2YXJpb3VzIG91dHB1dCBjb21iaW5hdGlvbnMuIA0K ICAgICAgIA0KICAgICAgVG8gYWNjb21tb2RhdGUgYSBub24tdHJpdmlhbCBMRkIgdG9wb2xvZ3ks IG11bHRpcGxlIExGQiBvdXRwdXRzIA0KICAgICAgYXJlIG5lZWRlZCBzbyB0aGF0IGFuIExGQiBj bGFzcyBjYW4gZm9yayB0aGUgZGF0YXBhdGguICBUd28gDQogICAgICBtZWNoYW5pc21zIGFyZSBw cm92aWRlZCBmb3IgZm9ya2luZzogbXVsdGlwbGUgc2luZ2xldG9uIG91dHB1dHMgDQogICAgICBh bmQgb3V0cHV0IGdyb3Vwcywgd2hpY2ggY2FuIGJlIGNvbWJpbmVkIGluIHRoZSBzYW1lIExGQiBj bGFzcy4gDQogICAgICAgDQogICAgICBNdWx0aXBsZSBzZXBhcmF0ZSBzaW5nbGV0b24gb3V0cHV0 cyBhcmUgZGVmaW5lZCBpbiBhbiBMRkIgY2xhc3MgdG8gDQogICAgICBtb2RlbCBhIHByZS1kZXRl cm1pbmVkIG51bWJlciBvZiBzZW1hbnRpY2FsbHkgZGlmZmVyZW50IG91dHB1dHMuIA0KICAgICAg VGhhdCBpcywgdGhlIG51bWJlciBvZiBvdXRwdXRzIG11c3QgYmUga25vd24gd2hlbiB0aGUgTEZC IGNsYXNzIGlzIA0KICAgICAgZGVmaW5lZC4gIEFkZGl0aW9uYWwgc2luZ2xldG9uIG91dHB1dHMg Y2Fubm90IGJlIGNyZWF0ZWQgYXQgTEZCIA0KICAgICAgaW5zdGFudGlhdGlvbiB0aW1lLCBub3Ig Y2FuIHRoZXkgYmUgY3JlYXRlZCBvbiB0aGUgZmx5IGFmdGVyIHRoZSANCiAgICAgIExGQiBpcyBp bnN0YW50aWF0ZWQuIA0KICAgICAgIA0KICAgICAgRm9yIGV4YW1wbGUsIGFuIElQdjQgTFBNIChM b25nZXN0LVByZWZpeC1NYXRjaGluZykgTEZCIG1heSBoYXZlIA0KICAgICAgb25lIG91dHB1dChP VVQpIHRvIHNlbmQgdGhvc2UgcGFja2V0cyBmb3Igd2hpY2ggdGhlIExQTSBsb29rLXVwIA0KICAg ICAgd2FzIHN1Y2Nlc3NmdWwsIHBhc3NpbmcgYSBNRVRBX1JPVVRFSUQgYXMgbWV0YWRhdGE7IGFu ZCBoYXZlIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAg DQogICAgICBhbm90aGVyIG91dHB1dCAoRVhDRVBUSU9OT1VUKSBmb3Igc2VuZGluZyBleGNlcHRp b24gcGFja2V0cyB3aGVuIA0KICAgICAgdGhlIExQTSBsb29rLXVwIGZhaWxlZC4gIFRoaXMgZXhh bXBsZSBpcyBkZXBpY3RlZCBpbiBGaWd1cmUgMy5iLiAgDQogICAgICBQYWNrZXRzIGVtaXR0ZWQg YnkgdGhlc2UgdHdvIG91dHB1dHMgbm90IG9ubHkgcmVxdWlyZSBkaWZmZXJlbnQgDQogICAgICBk b3duc3RyZWFtIHRyZWF0bWVudCwgYnV0IHRoZXkgYXJlIGEgcmVzdWx0IG9mIHR3byBkaWZmZXJl bnQgDQogICAgICBjb25kaXRpb25zIGluIHRoZSBMRkIgYW5kIGVhY2ggb3V0cHV0IGNhcnJpZXMg ZGlmZmVyZW50IG1ldGFkYXRhLiAgDQogICAgICBUaGlzIGNvbmNlcHQgYXNzdW1lcyB0aGUgbnVt YmVyIG9mIGRpc3RpbmN0IG91dHB1dHMgaXMga25vd24gd2hlbiANCiAgICAgIHRoZSBMRkIgY2xh c3MgaXMgZGVmaW5lZC4gRm9yIGVhY2ggc2luZ2xldG9uIG91dHB1dCwgdGhlIExGQiBjbGFzcyAN CiAgICAgIGRlZmluaXRpb24gZGVmaW5lcyB0aGUgdHlwZXMgb2YgZnJhbWVzIGFuZCBtZXRhZGF0 YSB0aGUgb3V0cHV0IA0KICAgICAgZW1pdHMuIA0KICAgICAgIA0KICAgICAgQW4gb3V0cHV0IGdy b3VwLCBvbiB0aGUgb3RoZXIgaGFuZCwgaXMgdXNlZCB0byBtb2RlbCB0aGUgY2FzZSANCiAgICAg IHdoZXJlIGEgZmxvdyBvZiBzaW1pbGFyIHBhY2tldHMgd2l0aCBhbiBpZGVudGljYWwgc2V0IG9m IG1ldGFkYXRhIA0KICAgICAgbmVlZHMgdG8gYmUgc3BsaXQgaW50byBtdWx0aXBsZSBwYXRocy4g SW4gdGhpcyBjYXNlLCB0aGUgbnVtYmVyIG9mIA0KICAgICAgc3VjaCBwYXRocyBpcyBub3Qga25v d24gd2hlbiB0aGUgTEZCIGNsYXNzIGlzIGRlZmluZWQgYmVjYXVzZSBpdCANCiAgICAgIGlzIG5v dCBhbiBpbmhlcmVudCBwcm9wZXJ0eSBvZiB0aGUgTEZCIGNsYXNzLiAgQW4gb3V0cHV0IGdyb3Vw IA0KICAgICAgY29uc2lzdHMgb2YgYSBudW1iZXIgb2Ygb3V0cHV0cywgY2FsbGVkIHRoZSBvdXRw dXQgaW5zdGFuY2VzIG9mIA0KICAgICAgdGhlIGdyb3VwLCB3aGVyZSBhbGwgb3V0cHV0IGluc3Rh bmNlcyBzaGFyZSB0aGUgc2FtZSBmcmFtZSBhbmQgDQogICAgICBtZXRhZGF0YSBlbWlzc2lvbiBk ZWZpbml0aW9ucyAoc2VlIEZpZ3VyZSAzLmMpLiAgRWFjaCBvdXRwdXQgDQogICAgICBpbnN0YW5j ZSBjYW4gY29ubmVjdCB0byBhIGRpZmZlcmVudCBkb3duc3RyZWFtIExGQiwganVzdCBhcyBpZiAN CiAgICAgIHRoZXkgd2VyZSBzZXBhcmF0ZSBzaW5nbGV0b24gb3V0cHV0cywgYnV0IHRoZSBudW1i ZXIgb2Ygb3V0cHV0IA0KICAgICAgaW5zdGFuY2VzIGNhbiBkaWZmZXIgYmV0d2VlbiBMRkIgaW5z dGFuY2VzIG9mIHRoZSBzYW1lIExGQiBjbGFzcy4gIA0KICAgICAgVGhlIGNsYXNzIGRlZmluaXRp b24gbWF5IGluY2x1ZGUgYSBsb3dlciBhbmQvb3IgYW4gdXBwZXIgbGltaXQgb24gDQogICAgICB0 aGUgbnVtYmVyIG9mIG91dHB1dHMuICBJbiBhZGRpdGlvbiwgZm9yIGNvbmZpZ3VyYWJsZSBGRXMs IHRoZSBGRSANCiAgICAgIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gbWF5IGRlZmluZSBmdXJ0aGVy IGxpbWl0cyBvbiB0aGUgbnVtYmVyIG9mIA0KICAgICAgaW5zdGFuY2VzIGluIHNwZWNpZmljIG91 dHB1dCBncm91cHMgZm9yIGNlcnRhaW4gTEZCcy4gIFRoZSBhY3R1YWwgDQogICAgICBudW1iZXIg b2Ygb3V0cHV0IGluc3RhbmNlcyBpbiBhIGdyb3VwIGlzIGFuIGF0dHJpYnV0ZSBvZiB0aGUgTEZC IA0KICAgICAgaW5zdGFuY2UsIHdoaWNoIGlzIHJlYWQtb25seSBmb3Igc3RhdGljIHRvcG9sb2dp ZXMsIGFuZCByZWFkLXdyaXRlIA0KICAgICAgZm9yIGR5bmFtaWMgdG9wb2xvZ2llcy4gIFRoZSBv dXRwdXQgaW5zdGFuY2VzIGluIGEgZ3JvdXAgYXJlIA0KICAgICAgbnVtYmVyZWQgc2VxdWVudGlh bGx5LCBmcm9tIDAgdG8gTi0xLCBhbmQgYXJlIGFkZHJlc3NhYmxlIGZyb20gDQogICAgICB3aXRo aW4gdGhlIExGQi4gIFRoZSBMRkIgaGFzIGEgYnVpbHQtaW4gbWVjaGFuaXNtIHRvIHNlbGVjdCBv bmUgDQogICAgICBzcGVjaWZpYyBvdXRwdXQgaW5zdGFuY2UgZm9yIGVhY2ggcGFja2V0LiAgVGhp cyBtZWNoYW5pc20gaXMgDQogICAgICBkZXNjcmliZWQgaW4gdGhlIHRleHR1YWwgZGVmaW5pdGlv biBvZiB0aGUgY2xhc3MgYW5kIGlzIHR5cGljYWxseSANCiAgICAgIGNvbmZpZ3VyYWJsZSB2aWEg c29tZSBhdHRyaWJ1dGVzIG9mIHRoZSBMRkIuIA0KICAgICAgIA0KICAgICAgRm9yIGV4YW1wbGUs IGNvbnNpZGVyIGEgcmUtZGlyZWN0b3IgTEZCLCB3aG9zZSBzb2xlIHB1cnBvc2UgaXMgdG8gDQog ICAgICBkaXJlY3QgcGFja2V0cyB0byBvbmUgb2YgTiBkb3duc3RyZWFtIHBhdGhzIGJhc2VkIG9u IG9uZSBvZiB0aGUgDQogICAgICBtZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggZWFjaCBhcnJpdmlu ZyBwYWNrZXQuICBTdWNoIGFuIExGQiBpcyANCiAgICAgIGZhaXJseSB2ZXJzYXRpbGUgYW5kIGNh biBiZSB1c2VkIGluIG1hbnkgZGlmZmVyZW50IHBsYWNlcyBpbiBhIA0KICAgICAgdG9wb2xvZ3ku ICBGb3IgZXhhbXBsZSwgYSByZWRpcmVjdG9yIGNhbiBiZSB1c2VkIHRvIGRpdmlkZSB0aGUgDQog ICAgICBkYXRhIHBhdGggaW50byBhbiBJUHY0IGFuZCBhbiBJUHY2IHBhdGggYmFzZWQgb24gYSBG UkFNRVRZUEUgDQogICAgICBtZXRhZGF0YSAoTj0yKSwgb3IgdG8gZm9yayBpbnRvIGNvbG9yIHNw ZWNpZmljIHBhdGhzIGFmdGVyIA0KICAgICAgbWV0ZXJpbmcgdXNpbmcgdGhlIENPTE9SIG1ldGFk YXRhIChyZWQsIHllbGxvdywgZ3JlZW47IE49MyksIGV0Yy4gDQogICAgICAgDQogICAgICBVc2lu ZyBhbiBvdXRwdXQgZ3JvdXAgaW4gdGhlIGFib3ZlIExGQiBjbGFzcyBwcm92aWRlcyB0aGUgZGVz aXJlZCANCiAgICAgIGZsZXhpYmlsaXR5IHRvIGFkYXB0IGVhY2ggaW5zdGFuY2Ugb2YgdGhpcyBj bGFzcyB0byB0aGUgcmVxdWlyZWQgDQogICAgICBvcGVyYXRpb24uICBUaGUgbWV0YWRhdGEgdG8g YmUgdXNlZCBhcyBhIHNlbGVjdG9yIGZvciB0aGUgb3V0cHV0IA0KICAgICAgaW5zdGFuY2UgaXMg YSBwcm9wZXJ0eSBvZiB0aGUgTEZCLiAgRm9yIGVhY2ggcGFja2V0LCB0aGUgdmFsdWUgb2YgDQog ICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMTVdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VT IEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHRo ZSBzcGVjaWZpZWQgbWV0YWRhdGEgbWF5IGJlIHVzZWQgYXMgYSBkaXJlY3QgaW5kZXggdG8gdGhl IG91dHB1dCANCiAgICAgIGluc3RhbmNlLiAgQWx0ZXJuYXRpdmVseSwgdGhlIExGQiBtYXkgaGF2 ZSBhIGNvbmZpZ3VyYWJsZSBzZWxlY3RvciANCiAgICAgIHRhYmxlIHRoYXQgbWFwcyBhIG1ldGFk YXRhIHZhbHVlIHRvIG91dHB1dCBpbnN0YW5jZS4gDQogICAgICAgDQogICAgICBOb3RlIHRoYXQg b3RoZXIgTEZCcyBtYXkgYWxzbyB1c2UgdGhlIG91dHB1dCBncm91cCBjb25jZXB0IHRvIA0KICAg ICAgYnVpbGQgaW4gc2ltaWxhciBhZGFwdGl2ZSBmb3JraW5nIGNhcGFiaWxpdHkuICBGb3IgZXhh bXBsZSwgYSANCiAgICAgIGNsYXNzaWZpZXIgTEZCIHdpdGggb25lIGlucHV0IGFuZCBOIG91dHB1 dHMgY2FuIGJlIGRlZmluZWQgZWFzaWx5IA0KICAgICAgYnkgdXNpbmcgdGhlIG91dHB1dCBncm91 cCBjb25jZXB0LiAgQWx0ZXJuYXRpdmVseSwgYSBjbGFzc2lmaWVyIA0KICAgICAgTEZCIHdpdGgg b25lIHNpbmdsZXRvbiBvdXRwdXQgaW4gY29tYmluYXRpb24gd2l0aCBhbiBleHBsaWNpdCBOLQ0K ICAgICAgb3V0cHV0IHJlLWRpcmVjdG9yIExGQiBtb2RlbHMgdGhlIHNhbWUgcHJvY2Vzc2luZyBi ZWhhdmlvci4gIFRoZSANCiAgICAgIGRlY2lzaW9uIG9mIHdoZXRoZXIgdG8gdXNlIHRoZSBvdXRw dXQgZ3JvdXAgbW9kZWwgZm9yIGEgY2VydGFpbiANCiAgICAgIExGQiBjbGFzcyBpcyBsZWZ0IHRv IHRoZSBMRkIgY2xhc3MgZGVzaWduZXJzLiANCiAgICAgICANCiAgICAgIFRoZSBtb2RlbCBhbGxv d3MgdGhlIG91dHB1dCBncm91cCBiZSBjb21iaW5lZCB3aXRoIG90aGVyIHNpbmdsZXRvbiANCiAg ICAgIG91dHB1dChzKSBpbiB0aGUgc2FtZSBjbGFzcywgYXMgZGVtb25zdHJhdGVkIGluIEZpZ3Vy ZSAzLmQuICBUaGUgDQogICAgICBMRkIgaGVyZSBoYXMgdHdvIHR5cGVzIG9mIG91dHB1dHMsIE9V VCwgZm9yIG5vcm1hbCBwYWNrZXQgb3V0cHV0LCANCiAgICAgIGFuZCBFWENFUFRJT05PVVQgZm9y IHBhY2tldHMgdGhhdCB0cmlnZ2VyZWQgc29tZSBleGNlcHRpb24uICBUaGUgDQogICAgICBub3Jt YWwgT1VUIGhhcyBtdWx0aXBsZSBpbnN0YW5jZXMsIHRodXMsIGl0IGlzIGFuIG91dHB1dCBncm91 cC4gDQogICAgICAgDQogICAgICBJbiBzdW1tYXJ5LCB0aGUgTEZCIGNsYXNzIG1heSBkZWZpbmUg b25lIG91dHB1dCwgbXVsdGlwbGUgDQogICAgICBzaW5nbGV0b24gb3V0cHV0cywgb25lIG9yIG1v cmUgb3V0cHV0IGdyb3Vwcywgb3IgYSBjb21iaW5hdGlvbiANCiAgICAgIHRoZXJlb2YuIE11bHRp cGxlIHNpbmdsZXRvbiBvdXRwdXRzIHNob3VsZCBiZSB1c2VkIHdoZW4gdGhlIExGQiANCiAgICAg IG11c3QgcHJvdmlkZSBmb3IgZm9ya2luZyB0aGUgZGF0YXBhdGgsIGFuZCBhdCBsZWFzdCBvbmUg b2YgdGhlIA0KICAgICAgZm9sbG93aW5nIGNvbmRpdGlvbnMgaG9sZDogDQogICAgICAgIC4gdGhl IG51bWJlciBvZiBkb3duc3RyZWFtIGRpcmVjdGlvbnMgYXJlIGluaGVyZW50IGZyb20gdGhlIA0K ICAgICAgICAgICBkZWZpbml0aW9uIG9mIHRoZSBjbGFzcyBhbmQgaGVuY2UgZml4ZWQ7IA0KICAg ICAgICAuIHRoZSBmcmFtZSB0eXBlIGFuZCBzZXQgb2YgbWV0YWRhdGEgZW1pdHRlZCBvbiBhbnkg b2YgdGhlIA0KICAgICAgICAgICBvdXRwdXRzIGFyZSBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBm cm9tIHdoYXQgaXMgZW1pdHRlZCBvbiAgDQogICAgICAgICAgIHRoZSBvdGhlciAgb3V0cHV0cyAo aS5lLiwgdGhleSBjYW5ub3Qgc2hhcmUgZnJhbWUtdHlwZSBhbmQgDQogICAgICAgICAgIG1ldGFk YXRhIGRlZmluaXRpb25zKTsgDQogICAgICAgDQogICAgICBBbiBvdXRwdXQgZ3JvdXAgaXMgYXBw cm9wcmlhdGUgd2hlbiB0aGUgTEZCIG11c3QgcHJvdmlkZSBmb3IgDQogICAgICBmb3JraW5nIHRo ZSBkYXRhcGF0aCwgYW5kIGF0IGxlYXN0IG9uZSBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMg DQogICAgICBob2xkOiANCiAgICAgICAgLiB0aGUgbnVtYmVyIG9mIGRvd25zdHJlYW0gZGlyZWN0 aW9ucyBpcyBub3Qga25vd24gd2hlbiB0aGUgTEZCIA0KICAgICAgICAgICBjbGFzcyBpcyBkZWZp bmVkOyANCiAgICAgICAgLiB0aGUgZnJhbWUgdHlwZSBhbmQgc2V0IG9mIG1ldGFkYXRhIGVtaXR0 ZWQgb24gdGhlc2Ugb3V0cHV0cyANCiAgICAgICAgICAgYXJlIHN1ZmZpY2llbnRseSBzaW1pbGFy IG9yIGlkZWFsbHkgaWRlbnRpY2FsLCBzdWNoIHRoZXkgY2FuIA0KICAgICAgICAgICBzaGFyZSB0 aGUgc2FtZSBvdXRwdXQgZGVmaW5pdGlvbi4gDQogICAgICAgDQogICAzLjIuMi4gTEZCIElucHV0 cyANCiAgICAgICANCiAgICAgIEFuIExGQiBpbnB1dCBpcyBhIGNvbmNlcHR1YWwgcG9ydCBvbiBh biBMRkIgd2hlcmUgdGhlIExGQiBjYW4gDQogICAgICByZWNlaXZlIGluZm9ybWF0aW9uIGZyb20g b3RoZXIgTEZCcy4gIFRoZSBpbmZvcm1hdGlvbiBpcyB0eXBpY2FsbHkgDQogICAgICBhIHBhY2tl dCBhbmQgYXNzb2NpYXRlZCBtZXRhZGF0YSwgYWx0aG91Z2ggaW4gc29tZSBjYXNlcyBpdCBtaWdo dCANCiAgICAgIGNvbnNpc3Qgb2Ygb25seSBtZXRhZGF0YSwgd2l0aG91dCBhbnkgcGFja2V0IGRh dGEuIA0KICAgICAgIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE2XSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICBGb3IgTEZCIGluc3RhbmNlcyB0aGF0IHJlY2VpdmUgcGFja2V0cyBmcm9t IG1vcmUgdGhhbiBvbmUgb3RoZXIgDQogICAgICBMRkIgaW5zdGFuY2UgKGZhbi1pbikuIFRoZXJl IGFyZSB0aHJlZSB3YXlzIHRvIG1vZGVsIGZhbi1pbiwgYWxsIA0KICAgICAgc3VwcG9ydGVkIGJ5 IHRoZSBMRkIgbW9kZWwgYW5kIGNhbiBiZSBjb21iaW5lZCBpbiB0aGUgc2FtZSBMRkI6IA0KICAg ICAgICAuIEltcGxpY2l0IG11bHRpcGxleGluZyB2aWEgYSBzaW5nbGUgaW5wdXQgDQogICAgICAg IC4gRXhwbGljaXQgbXVsdGlwbGV4aW5nIHZpYSBtdWx0aXBsZSBzaW5nbGV0b24gaW5wdXRzIA0K ICAgICAgICAuIEV4cGxpY2l0IG11bHRpcGxleGluZyB2aWEgYSBncm91cCBvZiBpbnB1dHMgKGlu cHV0IGdyb3VwKSANCiAgICAgICANCiAgICAgIFRoZSBzaW1wbGVzdCBmb3JtIG9mIG11bHRpcGxl eGluZyB1c2VzIGEgc2luZ2xldG9uIGlucHV0IChGaWd1cmUgDQogICAgICA0LmEpLiAgTW9zdCBM RkJzIHdpbGwgaGF2ZSBvbmx5IG9uZSBzaW5nbGV0b24gaW5wdXQuICBNdWx0aXBsZXhpbmcgDQog ICAgICBpbnRvIGEgc2luZ2xlIGlucHV0IGlzIHBvc3NpYmxlIGJlY2F1c2UgdGhlIG1vZGVsIGFs bG93cyBtb3JlIHRoYW4gDQogICAgICBvbmUgTEZCIG91dHB1dCB0byBjb25uZWN0IHRvIHRoZSBz YW1lIExGQiBpbnB1dC4gIFRoaXMgcHJvcGVydHkgDQogICAgICBhcHBsaWVzIHRvIGFueSBMRkIg aW5wdXQgd2l0aG91dCBhbnkgc3BlY2lhbCBwcm92aXNpb25zIGluIHRoZSBMRkIgDQogICAgICBj bGFzcy4gIE11bHRpcGxleGluZyBpbnRvIGEgc2luZ2xlIGlucHV0IGlzIGFwcGxpY2FibGUgd2hl biB0aGUgDQogICAgICBwYWNrZXRzIGZyb20gdGhlIHVwc3RyZWFtIExGQnMgYXJlIHNpbWlsYXIg aW4gZnJhbWUtdHlwZSBhbmQgDQogICAgICBhY2NvbXBhbnlpbmcgbWV0YWRhdGEsIGFuZCByZXF1 aXJlIHNpbWlsYXIgcHJvY2Vzc2luZy4gIE5vdGUgdGhhdCANCiAgICAgIHRoaXMgbW9kZWwgZG9l cyBub3QgYWRkcmVzcyBob3cgcG90ZW50aWFsIGNvbnRlbnRpb24gaXMgaGFuZGxlZCANCiAgICAg IHdoZW4gbXVsdGlwbGUgcGFja2V0cyBhcnJpdmUgc2ltdWx0YW5lb3VzbHkuICBJZiBjb250ZW50 aW9uIA0KICAgICAgaGFuZGxpbmcgbmVlZHMgdG8gYmUgZXhwbGljaXRseSBtb2RlbGVkLCBvbmUg b2YgdGhlIG90aGVyIHR3byANCiAgICAgIG1vZGVsaW5nIHNvbHV0aW9ucyBtdXN0IGJlIHVzZWQu IA0KICAgICAgIA0KICAgICAgVGhlIHNlY29uZCBtZXRob2QgdG8gbW9kZWwgZmFuLWluIHVzZXMg aW5kaXZpZHVhbGx5IGRlZmluZWQgDQogICAgICBzaW5nbGV0b24gaW5wdXRzIChGaWd1cmUgNC5i KS4gIFRoaXMgbW9kZWwgaXMgbWVhbnQgZm9yIHNpdHVhdGlvbnMgDQogICAgICB3aGVyZSB0aGUg TEZCIG5lZWRzIHRvIGhhbmRsZSBkaXN0aW5jdCB0eXBlcyBvZiBwYWNrZXQgc3RyZWFtcywgDQog ICAgICByZXF1aXJpbmcgaW5wdXQtc3BlY2lmaWMgaGFuZGxpbmcgaW5zaWRlIHRoZSBMRkIsIGFu ZCB3aGVyZSB0aGUgDQogICAgICBudW1iZXIgb2Ygc3VjaCBkaXN0aW5jdCBjYXNlcyBpcyBrbm93 biB3aGVuIHRoZSBMRkIgY2xhc3MgaXMgDQogICAgICBkZWZpbmVkLiAgRm9yIGV4YW1wbGUsIGEg TGF5ZXIgMiBEZWNhcHN1bGF0aW9uL0VuY2Fwc3VsYXRpb24gTEZCIA0KICAgICAgbWF5IGhhdmUg dHdvIGlucHV0cywgb25lIGZvciByZWNlaXZpbmcgTGF5ZXIgMiBmcmFtZXMgZm9yIA0KICAgICAg ZGVjYXBzdWxhdGlvbiwgYW5kIG9uZSBmb3IgcmVjZWl2aW5nIExheWVyIDMgZnJhbWVzIGZvciAN CiAgICAgIGVuY2Fwc3VsYXRpb24uICBUaGlzIExGQiB0eXBlIGV4cGVjdHMgZGlmZmVyZW50IGZy YW1lcyAoTDIgdnMuIEwzKSANCiAgICAgIGF0IGl0cyBpbnB1dHMsIGVhY2ggd2l0aCBkaWZmZXJl bnQgc2V0cyBvZiBtZXRhZGF0YSwgYW5kIHdvdWxkIA0KICAgICAgdGh1cyBhcHBseSBkaWZmZXJl bnQgcHJvY2Vzc2luZyBvbiBmcmFtZXMgYXJyaXZpbmcgYXQgdGhlc2UgDQogICAgICBpbnB1dHMu ICBUaGlzIG1vZGVsIGlzIGNhcGFibGUgb2YgZXhwbGljaXRseSBhZGRyZXNzaW5nIHBhY2tldCAN CiAgICAgIGNvbnRlbnRpb24gYnkgZGVmaW5pbmcgaG93IHRoZSBMRkIgY2xhc3MgaGFuZGxlcyB0 aGUgY29udGVuZGluZyANCiAgICAgIHBhY2tldHMuIA0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg IEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQog ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAgICB8IExGQiBYICAgICAgICArLS0tKyAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLSsgICB8ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgdiAgIHwgICAgICAgICAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgIHwgTEZCIFkgICAgICAgICstLS0rLS0+fGlu cHV0ICAgICBNZXRlciBMRkIgICAgIHwgDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tKyAgIF4gICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICB8ICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgfCBMRkIgWiAgICAgICAgfC0tLSsgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0rICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgIA0KICAgICAgKGEpIEFu IExGQiBjb25uZWN0cyB3aXRoIG11bHRpcGxlIHVwc3RyZWFtIExGQnMgdmlhIGEgc2luZ2xlIA0K ICAgICAgaW5wdXQuIA0KICAgICAgIA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LSsgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAg fCBMRkIgWCAgICAgICAgKy0tLSsgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgKy0tPnxsYXllcjIgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgfCBMRkIgWSAgICAgICAg Ky0tLS0tLT58bGF5ZXIzICAgICBMRkIgICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAg IA0KICAgICAgKGIpIEFuIExGQiBjb25uZWN0cyB3aXRoIG11bHRpcGxlIHVwc3RyZWFtIExGQnMg dmlhIHR3byBzZXBhcmF0ZSANCiAgICAgICAgICBzaW5nbGV0b24gaW5wdXRzLiANCiAgICAgICAN CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgICAgIHwgUXVldWUgTEZCICMxICstLS0rICAg fCAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tKyAgIHwgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8IA0K ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICArLS0+fGluOjAgICBcICAgICAg ICAgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgfCBRdWV1ZSBMRkIgIzIgKy0tLS0tLT58 aW46MSAgIHwgaW5wdXQgZ3JvdXAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0rICAgICAgIHwuLi4gICAgfCAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0+fGluOk4tMSAvICAgICAgICAgICAgICAgIHwgDQog ICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgfCANCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rICAgfCAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgIHwgUXVldWUgTEZC ICNOIHwtLS0rICAgfCAgICAgU2NoZWR1bGVyIExGQiAgICAgIHwgDQogICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAg ICAgICANCiAgICAgIChjKSBBIFNjaGVkdWxlciBMRkIgdXNlcyBhbiBpbnB1dCBncm91cCB0byBk aWZmZXJlbnRpYXRlIHdoaWNoIA0KICAgICAgcXVldWUgTEZCIHBhY2tldHMgYXJlIGNvbWluZyBm cm9tLiANCiAgICAgICANCiAgICAgICAgICAgICAgICBGaWd1cmUgMy4gSW5wdXQgbW9kZWxpbmcg Y29uY2VwdHMgKGV4YW1wbGVzKS4gDQogICAgICAgDQogICAgICBUaGUgdGhpcmQgbWV0aG9kIHRv IG1vZGVsIGZhbi1pbiB1c2VzIHRoZSBjb25jZXB0IG9mIGFuIGlucHV0IA0KICAgICAgZ3JvdXAu ICBUaGUgY29uY2VwdCBpcyBzaW1pbGFyIHRvIHRoZSBvdXRwdXQgZ3JvdXAgaW50cm9kdWNlZCBp biANCiAgICAgIHRoZSBwcmV2aW91cyBzZWN0aW9uLCBhbmQgaXMgZGVwaWN0ZWQgaW4gRmlndXJl IDQuYy4gIEFuIGlucHV0IA0KICAgICAgZ3JvdXAgY29uc2lzdHMgb2YgYSBudW1iZXIgb2YgaW5w dXQgaW5zdGFuY2VzLCBhbGwgc2hhcmluZyB0aGUgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAg ICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMThdIA0K DCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBB dWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHByb3BlcnRpZXMgKHNhbWUgZnJhbWUgYW5k IG1ldGFkYXRhIGV4cGVjdGF0aW9ucykuICBUaGUgaW5wdXQgDQogICAgICBpbnN0YW5jZXMgYXJl IG51bWJlcmVkIGZyb20gMCB0byBOLTEuICBGcm9tIHRoZSBvdXRzaWRlLCB0aGVzZSANCiAgICAg IGlucHV0cyBhcHBlYXIgYXMgbm9ybWFsIGlucHV0cywgaS5lLiwgYW55IGNvbXBhdGlibGUgdXBz dHJlYW0gTEZCIA0KICAgICAgY2FuIGNvbm5lY3QgaXRzIG91dHB1dCB0byBvbmUgb2YgdGhlc2Ug aW5wdXRzLiAgV2hlbiBhIHBhY2tldCBpcyANCiAgICAgIHByZXNlbnRlZCB0byB0aGUgTEZCIGF0 IGEgcGFydGljdWxhciBpbnB1dCBpbnN0YW5jZSwgdGhlIGluZGV4IG9mIA0KICAgICAgdGhlIGlu cHV0IHdoZXJlIHRoZSBwYWNrZXQgYXJyaXZlZCBpcyBrbm93biB0byB0aGUgTEZCIGFuZCB0aGlz IA0KICAgICAgaW5mb3JtYXRpb24gbWF5IGJlIHVzZWQgaW4gdGhlIGludGVybmFsIHByb2Nlc3Np bmcuICBGb3IgZXhhbXBsZSwgDQogICAgICB0aGUgaW5wdXQgaW5kZXggY2FuIGJlIHVzZWQgYXMg YSB0YWJsZSBzZWxlY3Rvciwgb3IgYXMgYW4gZXhwbGljaXQgDQogICAgICBwcmVjZWRlbmNlIHNl bGVjdG9yIHRvIHJlc29sdmUgY29udGVudGlvbi4gIEFzIHdpdGggb3V0cHV0IGdyb3VwcywgDQog ICAgICB0aGUgbnVtYmVyIG9mIGlucHV0IGluc3RhbmNlcyBpbiBhbiBpbnB1dCBncm91cCBpcyBu b3QgZGVmaW5lZCBpbiANCiAgICAgIHRoZSBMRkIgY2xhc3MuICBIb3dldmVyLCB0aGUgY2xhc3Mg ZGVmaW5pdGlvbiBtYXkgaW5jbHVkZSANCiAgICAgIHJlc3RyaWN0aW9ucyBvbiB0aGUgcmFuZ2Ug b2YgcG9zc2libGUgdmFsdWVzLiAgSW4gYWRkaXRpb24sIGlmIGFuIA0KICAgICAgRkUgc3VwcG9y dHMgY29uZmlndXJhYmxlIHRvcG9sb2dpZXMsIGl0IG1heSBpbXBvc2UgZnVydGhlciANCiAgICAg IGxpbWl0YXRpb25zIG9uIHRoZSBudW1iZXIgb2YgaW5zdGFuY2VzIGZvciBhIHBhcnRpY3VsYXIg cG9ydCANCiAgICAgIGdyb3VwKHMpIG9mIGEgcGFydGljdWxhciBMRkIgY2xhc3MuICBXaXRoaW4g dGhlc2UgbGltaXRhdGlvbnMsIA0KICAgICAgZGlmZmVyZW50IGluc3RhbmNlcyBvZiB0aGUgc2Ft ZSBjbGFzcyBtYXkgaGF2ZSBhIGRpZmZlcmVudCBudW1iZXIgDQogICAgICBvZiBpbnB1dCBpbnN0 YW5jZXMuICBUaGUgbnVtYmVyIG9mIGFjdHVhbCBpbnB1dCBpbnN0YW5jZXMgaW4gdGhlIA0KICAg ICAgZ3JvdXAgaXMgYW4gYXR0cmlidXRlIG9mIHRoZSBMRkIgY2xhc3MsIHdoaWNoIGlzIHJlYWQt b25seSBmb3IgDQogICAgICBzdGF0aWMgdG9wb2xvZ2llcywgYW5kIGlzIHJlYWQtd3JpdGUgZm9y IGNvbmZpZ3VyYWJsZSB0b3BvbG9naWVzLiANCiAgICAgICANCiAgICAgIEFzIGFuIGV4YW1wbGUg Zm9yIHRoZSBpbnB1dCBncm91cCwgY29uc2lkZXIgdGhlIFNjaGVkdWxlciBMRkIgDQogICAgICBk ZXBpY3RlZCBpbiBGaWd1cmUgMy5jLiAgU3VjaCBhbiBMRkIgcmVjZWl2ZXMgcGFja2V0cyBmcm9t IGEgDQogICAgICBudW1iZXIgb2YgUXVldWUgTEZCcyB2aWEgYSBudW1iZXIgb2YgaW5wdXQgaW5z dGFuY2VzLCBhbmQgdXNlcyB0aGUgDQogICAgICBpbnB1dCBpbmRleCBpbmZvcm1hdGlvbiB0byBj b250cm9sIGNvbnRlbnRpb24gcmVzb2x1dGlvbiBhbmQgDQogICAgICBzY2hlZHVsaW5nLiANCiAg ICAgICANCiAgICAgIEluIHN1bW1hcnksIHRoZSBMRkIgY2xhc3MgbWF5IGRlZmluZSBvbmUgaW5w dXQsIG11bHRpcGxlIHNpbmdsZXRvbiANCiAgICAgIGlucHV0cywgb25lIG9yIG1vcmUgaW5wdXQg Z3JvdXBzLCBvciBhIGNvbWJpbmF0aW9uIHRoZXJlb2YuICBBbnkgDQogICAgICBpbnB1dCBhbGxv d3MgZm9yIGltcGxpY2l0IG11bHRpcGxleGluZyBvZiBzaW1pbGFyIHBhY2tldCBzdHJlYW1zIA0K ICAgICAgdmlhIGNvbm5lY3RpbmcgbXVsdGlwbGUgb3V0cHV0cyB0byB0aGUgc2FtZSBpbnB1dC4g IEV4cGxpY2l0IA0KICAgICAgbXVsdGlwbGUgc2luZ2xldG9uIGlucHV0cyBhcmUgdXNlZnVsIHdo ZW4gZWl0aGVyIHRoZSBjb250ZW50aW9uIA0KICAgICAgaGFuZGxpbmcgbXVzdCBiZSBoYW5kbGVk IGV4cGxpY2l0bHksIG9yIHdoZW4gdGhlIExGQiBjbGFzcyBtdXN0IA0KICAgICAgcmVjZWl2ZSBh bmQgcHJvY2VzcyBhIGtub3duIG51bWJlciBvZiBkaXN0aW5jdCB0eXBlcyBvZiBwYWNrZXQgDQog ICAgICBzdHJlYW1zLiAgQW4gaW5wdXQgZ3JvdXAgaXMgc3VpdGFibGUgd2hlbiBjb250ZW50aW9u IGhhbmRsaW5nIG11c3QgDQogICAgICBiZSBtb2RlbGVkIGV4cGxpY2l0bHksIGJ1dCB0aGUgbnVt YmVyIG9mIGlucHV0cyBhcmUgbm90IGluaGVyZW50IA0KICAgICAgZnJvbSB0aGUgY2xhc3MgKGFu ZCBoZW5jZSBpcyBub3Qga25vd24gd2hlbiB0aGUgY2xhc3MgaXMgZGVmaW5lZCksIA0KICAgICAg b3Igd2hlbiBpdCBpcyBjcml0aWNhbCBmb3IgTEZCIG9wZXJhdGlvbiB0byBrbm93IGV4YWN0bHkg b24gd2hpY2ggDQogICAgICBpbnB1dCB0aGUgcGFja2V0IHdhcyByZWNlaXZlZC4gDQogICAgDQog ICAzLjIuMy4gUGFja2V0IFR5cGUgDQogICAgICAgDQogICAgICBXaGVuIExGQiBjbGFzc2VzIGFy ZSBkZWZpbmVkLCB0aGUgaW5wdXQgYW5kIG91dHB1dCBwYWNrZXQgZm9ybWF0cyANCiAgICAgIChl LmcuLCBJUHY0LCBJUHY2LCBFdGhlcm5ldCwgZXRjLikgbXVzdCBiZSBzcGVjaWZpZWQuICBUaGVz ZSBhcmUgDQogICAgICB0aGUgdHlwZXMgb2YgcGFja2V0cyBhIGdpdmVuIExGQiBpbnB1dCBpcyBj YXBhYmxlIG9mIHJlY2VpdmluZyBhbmQgDQogICAgICBwcm9jZXNzaW5nLCBvciBhIGdpdmVuIExG QiBvdXRwdXQgaXMgY2FwYWJsZSBvZiBwcm9kdWNpbmcuICBUaGlzIA0KICAgICAgcmVxdWlyZXMg ZGlzdGluY3QgcGFja2V0IHR5cGVzIGJlIHVuaXF1ZWx5IGxhYmVsZWQgd2l0aCBhIHN5bWJvbGlj IA0KICAgICAgbmFtZSBhbmQvb3IgSUQuIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhw aXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XSANCgwgICBJ bnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0 IDIwMDUgDQogICAgDQogICAgDQogICAgICAgDQogICAgICBOb3RlIHRoYXQgZWFjaCBMRkIgaGFz IGEgc2V0IG9mIHBhY2tldCB0eXBlcyB0aGF0IGl0IG9wZXJhdGVzIG9uLCANCiAgICAgIGJ1dCBk b2VzIG5vdCBjYXJlIHdoZXRoZXIgdGhlIHVuZGVybHlpbmcgaW1wbGVtZW50YXRpb24gaXMgcGFz c2luZyANCiAgICAgIGEgZ3JlYXRlciBwb3J0aW9uIG9mIHRoZSBwYWNrZXRzLiAgRm9yIGV4YW1w bGUsIGFuIElQdjQgTEZCIG1pZ2h0IA0KICAgICAgb25seSBvcGVyYXRlIG9uIElQdjQgcGFja2V0 cywgYnV0IHRoZSB1bmRlcmx5aW5nIGltcGxlbWVudGF0aW9uIA0KICAgICAgbWF5IG9yIG1heSBu b3QgYmUgc3RyaXBwaW5nIHRoZSBMMiBoZWFkZXIgYmVmb3JlIGhhbmRpbmcgaXQgb3ZlciAtDQog ICAgICAtIHdoZXRoZXIgdGhhdCBpcyBoYXBwZW5pbmcgb3Igbm90IGlzIG9wYXF1ZSB0byB0aGUg Q0UuIA0KICAgIA0KICAgMy4yLjQuIE1ldGFkYXRhIA0KICAgICAgIA0KICAgICAgTWV0YWRhdGEg aXMgdGhlIHBlci1wYWNrZXQgc3RhdGUgdGhhdCBpcyBwYXNzZWQgZnJvbSBvbmUgTEZCIHRvIA0K ICAgICAgYW5vdGhlci4gVGhlIG1ldGFkYXRhIGlzIHBhc3NlZCB3aXRoIHRoZSBwYWNrZXQgdG8g YXNzaXN0IA0KICAgICAgc3Vic2VxdWVudCBMRkJzIHRvIHByb2Nlc3MgdGhhdCBwYWNrZXQuICBU aGUgRm9yQ0VTIG1vZGVsIGNhcHR1cmVzIA0KICAgICAgaG93IHRoZSBwZXItcGFja2V0IHN0YXRl IGluZm9ybWF0aW9uIGlzIHByb3BhZ2F0ZWQgZnJvbSBvbmUgTEZCIHRvIA0KICAgICAgb3RoZXIg TEZCcy4gIFByYWN0aWNhbGx5LCBzdWNoIG1ldGFkYXRhIHByb3BhZ2F0aW9uIGNhbiBoYXBwZW4g DQogICAgICB3aXRoaW4gb25lIEZFLCBvciBjcm9zcyB0aGUgRkUgYm91bmRhcnkgYmV0d2VlbiB0 d28gaW50ZXJjb25uZWN0ZWQgDQogICAgICBGRXMuICBXZSBiZWxpZXZlIHRoYXQgdGhlIHNhbWUg bWV0YWRhdGEgbW9kZWwgY2FuIGJlIHVzZWQgZm9yIA0KICAgICAgZWl0aGVyIHNpdHVhdGlvbjsg aG93ZXZlciwgb3VyIGZvY3VzIGhlcmUgaXMgZm9yIGludHJhLUZFIA0KICAgICAgbWV0YWRhdGEu IA0KICAgICAgIA0KICAgMy4yLjQuMS4gTWV0YWRhdGEgVm9jYWJ1bGFyeSANCiAgICAgICANCiAg ICAgIE1ldGFkYXRhIGhhcyBoaXN0b3JpY2FsbHkgYmVlbiB1bmRlcnN0b29kIHRvIG1lYW4gImRh dGEgYWJvdXQgDQogICAgICBkYXRhIi4gIFdoaWxlIHRoaXMgZGVmaW5pdGlvbiBpcyBhIHN0YXJ0 LCBpdCBpcyBpbmFkZXF1YXRlIHRvIA0KICAgICAgZGVzY3JpYmUgdGhlIG11bHRpcGxlIGZvcm1z IG9mIG1ldGFkYXRhLCB3aGljaCBtYXkgYXBwZWFyIHdpdGhpbiBhIA0KICAgICAgY29tcGxleCBu ZXR3b3JrIGVsZW1lbnQuICBUaGUgZGlzY3Vzc2lvbiBoZXJlIGNhdGVnb3JpemVzIGZvcm1zIG9m IA0KICAgICAgbWV0YWRhdGEgYnkgdHdvIG9ydGhvZ29uYWwgYXhlcy4gDQogICAgICAgDQogICAg ICBUaGUgZmlyc3QgYXhpcyBpcyAiaW50ZXJuYWwiIHZlcnN1cyAiZXh0ZXJuYWwiLCB3aGljaCBk ZXNjcmliZXMgDQogICAgICB3aGVyZSB0aGUgbWV0YWRhdGEgZXhpc3RzIGluIHRoZSBuZXR3b3Jr IG1vZGVsIG9yIGltcGxlbWVudGF0aW9uLiAgDQogICAgICBGb3IgZXhhbXBsZSwgYSBwYXJ0aWN1 bGFyIHZlbmRvciBpbXBsZW1lbnRhdGlvbiBvZiBhbiBJUHY0IA0KICAgICAgZm9yd2FyZGVyIG1h eSBtYWtlIGRlY2lzaW9ucyBpbnNpZGUgb2YgYSBjaGlwIHRoYXQgYXJlIG5vdCB2aXNpYmxlIA0K ICAgICAgZXh0ZXJuYWxseS4gIFRob3NlIGRlY2lzaW9ucyBhcmUgbWV0YWRhdGEgZm9yIHRoZSBw YWNrZXQgdGhhdCBpcyANCiAgICAgICJpbnRlcm5hbCIgdG8gdGhlIGNoaXAuICBXaGVuIGEgcGFj a2V0IGlzIGZvcndhcmRlZCBvdXQgb2YgdGhlIA0KICAgICAgY2hpcCwgaXQgbWF5IGJlIG1hcmtl ZCB3aXRoIGEgdHJhZmZpYyBtYW5hZ2VtZW50IGhlYWRlci4gIFRoYXQgDQogICAgICBoZWFkZXIs IHdoaWNoIGlzIG1ldGFkYXRhIGZvciB0aGUgcGFja2V0LCBpcyB2aXNpYmxlIG91dHNpZGUgb2Yg DQogICAgICB0aGUgY2hpcCwgYW5kIGlzIHRoZXJlZm9yZSBjYWxsZWQgImV4dGVybmFsIiBtZXRh ZGF0YS4gDQogICAgICAgDQogICAgICBUaGUgc2Vjb25kIGF4aXMgaXMgImltcGxpY2l0IiB2ZXJz dXMgImV4cHJlc3NlZCIsIHdoaWNoIHNwZWNpZmllcyANCiAgICAgIHdoZXRoZXIgb3Igbm90IHRo ZSBtZXRhZGF0YSBoYXMgYSB2aXNpYmxlIHBoeXNpY2FsIHJlcHJlc2VudGF0aW9uLiANCiAgICAg IEZvciBleGFtcGxlLCB0aGUgdHJhZmZpYyBtYW5hZ2VtZW50IGhlYWRlciBkZXNjcmliZWQgaW4g dGhlIA0KICAgICAgcHJldmlvdXMgcGFyYWdyYXBoIG1heSBiZSByZXByZXNlbnRlZCBhcyBhIHNl cmllcyBvZiBiaXRzIGluIHNvbWUgDQogICAgICBmb3JtYXQsIGFuZCB0aGF0IGhlYWRlciBpcyBh c3NvY2lhdGVkIHdpdGggdGhlIHBhY2tldC4gIFRob3NlIGJpdHMgDQogICAgICBoYXZlIHBoeXNp Y2FsIHJlcHJlc2VudGF0aW9uLCBhbmQgYXJlIHRoZXJlZm9yZSAiZXhwcmVzc2VkIiANCiAgICAg IG1ldGFkYXRhLiAgSWYgdGhlIG1ldGFkYXRhIGRvZXMgbm90IGhhdmUgYSBwaHlzaWNhbCANCiAg ICAgIHJlcHJlc2VudGF0aW9uLCBpdCBpcyBjYWxsZWQgImltcGxpY2l0IiBtZXRhZGF0YS4gIFRo aXMgc2l0dWF0aW9uIA0KICAgICAgb2NjdXJzLCBmb3IgZXhhbXBsZSwgd2hlbiBhIHBhcnRpY3Vs YXIgcGF0aCB0aHJvdWdoIGEgbmV0d29yayANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4 cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0gDQoMICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgZGV2aWNlIGlzIGludGVuZGVkIHRvIGJlIHRyYXZl cnNlZCBvbmx5IGJ5IHBhcnRpY3VsYXIga2luZHMgb2YgDQogICAgICBwYWNrZXRzLCBzdWNoIGFz IGFuIElQdjQgcm91dGVyLiAgQW4gaW1wbGVtZW50YXRpb24gbWF5IG5vdCBtYXJrIA0KICAgICAg ZXZlcnkgcGFja2V0IGFsb25nIHRoaXMgcGF0aCBhcyBiZWluZyBvZiB0eXBlICJJUHY0IiwgYnV0 IHRoZSANCiAgICAgIGludGVudGlvbiBvZiB0aGUgZGVzaWduZXJzIGlzIHRoYXQgZXZlcnkgcGFj a2V0IGlzIG9mIHRoYXQgdHlwZS4gIA0KICAgICAgVGhpcyB1bmRlcnN0YW5kaW5nIGNhbiBiZSB0 aG91Z2h0IG9mIGFzIG1ldGFkYXRhIGFib3V0IHRoZSBwYWNrZXQsIA0KICAgICAgd2hpY2ggaXMg aW1wbGljaXRseSBhdHRhY2hlZCB0byB0aGUgcGFja2V0IHRocm91Z2ggdGhlIGludGVudCBvZiAN CiAgICAgIHRoZSBkZXNpZ25lcnMuIA0KICAgICAgIA0KICAgICAgSW4gdGhlIEZvckNFUyBtb2Rl bCwgd2UgZG8gTk9UIGRpc2N1c3Mgb3IgcmVwcmVzZW50IG1ldGFkYXRhIA0KICAgICAgImludGVy bmFsIiB0byB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIG9mIExGQnMuICBPdXIgZm9jdXMgaXMgc29s ZWx5IA0KICAgICAgb24gbWV0YWRhdGEgImV4dGVybmFsIiB0byB0aGUgTEZCcywgYW5kIHRoZXJl Zm9yZSB2aXNpYmxlIGluIHRoZSANCiAgICAgIEZvckNFUyBtb2RlbC4gIFRoZSBtZXRhZGF0YSBk aXNjdXNzZWQgd2l0aGluIHRoaXMgbW9kZWwgbWF5LCBvciANCiAgICAgIG1heSBub3QsIGJlIHZp c2libGUgb3V0c2lkZSBvZiB0aGUgcGFydGljdWxhciBGRSBpbXBsZW1lbnRpbmcgdGhlIA0KICAg ICAgTEZCIG1vZGVsLiAgSW4gdGhpcyByZWdhcmQsIHRoZSBzY29wZSBvZiB0aGUgbWV0YWRhdGEg d2l0aGluIA0KICAgICAgRm9yQ0VTIGlzIHZlcnkgbmFycm93bHkgZGVmaW5lZC4gDQogICAgICAg DQogICAgICBOb3RlIGFsc28gdGhhdCB3aGlsZSB3ZSBkZWZpbmUgbWV0YWRhdGEgd2l0aGluIHRo aXMgbW9kZWwsIGl0IGlzIA0KICAgICAgb25seSBhIG1vZGVsLiAgVGhlcmUgaXMgbm8gcmVxdWly ZW1lbnQgdGhhdCB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIA0KICAgICAgb2YgRm9yQ0VTIHVzZSB0 aGUgZXhhY3QgbWV0YWRhdGEgcmVwcmVzZW50YXRpb25zIGRlc2NyaWJlZCBpbiB0aGlzIA0KICAg ICAgZG9jdW1lbnQuICBUaGUgb25seSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudCBpcyB0aGF0 IHZlbmRvcnMgDQogICAgICBpbXBsZW1lbnQgdGhlIEZvckNFUyBwcm90b2NvbCwgbm90IHRoZSBt b2RlbC4gDQogICAgICAgDQogICAzLjIuNC4yLiBNZXRhZGF0YSBsaWZlY3ljbGUgd2l0aGluIHRo ZSBGb3JDRVMgbW9kZWwgDQogICAgDQogICAgICBFYWNoIG1ldGFkYXRhIGNhbiBiZSBjb252ZW5p ZW50bHkgbW9kZWxlZCBhcyBhIDxsYWJlbCwgdmFsdWU+IA0KICAgICAgcGFpciwgd2hlcmUgdGhl IGxhYmVsIGlkZW50aWZpZXMgdGhlIHR5cGUgb2YgaW5mb3JtYXRpb24sIChlLmcuLCANCiAgICAg ICJjb2xvciIpLCBhbmQgaXRzIHZhbHVlIGhvbGRzIHRoZSBhY3R1YWwgaW5mb3JtYXRpb24gKGUu Zy4sIA0KICAgICAgInJlZCIpLiAgVGhlIHRhZyBoZXJlIGlzIHNob3duIGFzIGEgdGV4dHVhbCBs YWJlbCwgYnV0IGl0IGNhbiBiZSANCiAgICAgIHJlcGxhY2VkIG9yIGFzc29jaWF0ZWQgd2l0aCBh IHVuaXF1ZSBudW1lcmljIHZhbHVlIChpZGVudGlmaWVyKS4gICANCiAgICAgICANCiAgICAgIFRo ZSBtZXRhZGF0YSBsaWZlLWN5Y2xlIGlzIGRlZmluZWQgaW4gdGhpcyBtb2RlbCB1c2luZyB0aHJl ZSB0eXBlcyANCiAgICAgIG9mIGV2ZW50czogIndyaXRlIiwgInJlYWQiIGFuZCAiY29uc3VtZSIu ICBUaGUgZmlyc3QgIndyaXRlIiANCiAgICAgIGltcGxpY2l0bHkgY3JlYXRlcyBhbmQgaW5pdGlh bGl6ZXMgdGhlIHZhbHVlIG9mIHRoZSBtZXRhZGF0YSwgYW5kIA0KICAgICAgaGVuY2Ugc3RhcnRz IHRoZSBsaWZlLWN5Y2xlLiAgVGhlIGV4cGxpY2l0ICJjb25zdW1lIiBldmVudCANCiAgICAgIHRl cm1pbmF0ZXMgdGhlIGxpZmUtY3ljbGUuICBXaXRoaW4gdGhlIGxpZmUtY3ljbGUsIHRoYXQgaXMs IGFmdGVyIA0KICAgICAgYSAid3JpdGUiIGV2ZW50LCBidXQgYmVmb3JlIHRoZSBuZXh0ICJjb25z dW1lIiBldmVudCwgdGhlcmUgY2FuIGJlIA0KICAgICAgYW4gYXJiaXRyYXJ5IG51bWJlciBvZiAi d3JpdGUiIGFuZCAicmVhZCIgZXZlbnRzLiAgVGhlc2UgInJlYWQiIA0KICAgICAgYW5kICJ3cml0 ZSIgZXZlbnRzIGNhbiBiZSBtaXhlZCBpbiBhbiBhcmJpdHJhcnkgb3JkZXIgd2l0aGluIHRoZSAN CiAgICAgIGxpZmUtY3ljbGUuICBPdXRzaWRlIG9mIHRoZSBsaWZlLWN5Y2xlIG9mIHRoZSBtZXRh ZGF0YSwgdGhhdCBpcywgDQogICAgICBiZWZvcmUgdGhlIGZpcnN0ICJ3cml0ZSIgZXZlbnQsIG9y IGJldHdlZW4gYSAiY29uc3VtZSIgZXZlbnQgYW5kIA0KICAgICAgdGhlIG5leHQgIndyaXRlIiBl dmVudCwgdGhlIG1ldGFkYXRhIHNob3VsZCBiZSByZWdhcmRlZCBub24tDQogICAgICBleGlzdGVu dCBvciBub24taW5pdGlhbGl6ZWQuICBUaHVzLCByZWFkaW5nIGEgbWV0YWRhdGEgb3V0c2lkZSBv ZiANCiAgICAgIGl0cyBsaWZlLWN5Y2xlIGlzIGNvbnNpZGVyZWQgYW4gZXJyb3IuICANCiAgICAg ICANCiAgICAgIFRvIGVuc3VyZSBpbnRlci1vcGVyYWJpbGl0eSBiZXR3ZWVuIExGQnMsIHRoZSBM RkIgY2xhc3MgDQogICAgICBzcGVjaWZpY2F0aW9uIG11c3QgZGVmaW5lIHdoYXQgbWV0YWRhdGEg dGhlIExGQiBjbGFzcyAicmVhZHMiIG9yIA0KICAgICAgImNvbnN1bWVzIiBvbiBpdHMgaW5wdXQo cykgYW5kIHdoYXQgbWV0YWRhdGEgaXQgInByb2R1Y2VzIiBvbiBpdHMgDQogICAgDQogICBZYW5n LCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgMjFdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAg ICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIG91dHB1dChzKS4gIEZv ciBtYXhpbXVtIGV4dGVuc2liaWxpdHksIHRoaXMgZGVmaW5pdGlvbiBzaG91bGQgDQogICAgICBu ZWl0aGVyIHNwZWNpZnkgd2hpY2ggTEZCcyB0aGUgbWV0YWRhdGEgaXMgZXhwZWN0ZWQgdG8gY29t ZSBmcm9tIA0KICAgICAgZm9yIGEgY29uc3VtZXIgTEZCLCBub3Igd2hpY2ggTEZCcyBhcmUgZXhw ZWN0ZWQgdG8gY29uc3VtZSANCiAgICAgIG1ldGFkYXRhIGZvciBhIGdpdmVuIHByb2R1Y2VyIExG Qi4gDQogICAgDQogICAgICBXaGlsZSBpdCBpcyBpbXBvcnRhbnQgdG8gZGVmaW5lIHRoZSBtZXRh ZGF0YSB0eXBlcyBwYXNzaW5nIGJldHdlZW4gDQogICAgICBMRkJzLCBpdCBpcyBub3QgYXBwcm9w cmlhdGUgdG8gZGVmaW5lIHRoZSBleGFjdCBlbmNvZGluZyBtZWNoYW5pc20gDQogICAgICB1c2Vk IGJ5IExGQnMgZm9yIHRoYXQgbWV0YWRhdGEuICBEaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIGFy ZSANCiAgICAgIGFsbG93ZWQgdG8gdXNlIGRpZmZlcmVudCBlbmNvZGluZyBtZWNoYW5pc21zIGZv ciBtZXRhZGF0YS4gIEZvciANCiAgICAgIGV4YW1wbGUsIG9uZSBpbXBsZW1lbnRhdGlvbiBtYXkg c3RvcmUgbWV0YWRhdGEgaW4gcmVnaXN0ZXJzIG9yIA0KICAgICAgc2hhcmVkIG1lbW9yeSwgd2hp bGUgYW5vdGhlciBpbXBsZW1lbnRhdGlvbiBtYXkgZW5jb2RlIG1ldGFkYXRhIA0KICAgICAgaW4t YmFuZCBhcyBhIHByZWFtYmxlIGluIHRoZSBwYWNrZXRzLiANCiAgICAgICANCiAgICAgIEF0IGFu eSBsaW5rIGJldHdlZW4gdHdvIExGQnMsIHRoZSBwYWNrZXQgaXMgbWFya2VkIHdpdGggYSBmaW5p dGUgDQogICAgICBzZXQgb2YgYWN0aXZlIG1ldGFkYXRhLCB3aGVyZSBhY3RpdmUgbWVhbnMgdGhl IG1ldGFkYXRhIGlzIHdpdGhpbiANCiAgICAgIGl0cyBsaWZlLWN5Y2xlLiAgVGhlcmUgYXJlIHR3 byBjb3JvbGxhcmllcyBvZiB0aGlzIG1vZGVsOiANCiAgICAgICANCiAgICAgIDEuIE5vIHVuLWlu aXRpYWxpemVkIG1ldGFkYXRhIGV4aXN0cyBpbiB0aGUgbW9kZWwuIA0KICAgICAgIA0KICAgICAg Mi4gTm8gbW9yZSB0aGFuIG9uZSBvY2N1cnJlbmNlIG9mIGVhY2ggbWV0YWRhdGEgdGFnIGNhbiBi ZSANCiAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCBhIHBhY2tldCBhdCBhbnkgZ2l2ZW4gdGltZS4g DQogICAgICAgIA0KICAgMy4yLjQuMy4gTEZCIE9wZXJhdGlvbnMgb24gTWV0YWRhdGEgDQogICAg ICAgDQogICAgICBXaGVuIHRoZSBwYWNrZXQgaXMgcHJvY2Vzc2VkIGJ5IGFuIExGQiAoaS5lLiwg YmV0d2VlbiB0aGUgdGltZSBpdCANCiAgICAgIGlzIHJlY2VpdmVkIGFuZCBmb3J3YXJkZWQgYnkg dGhlIExGQiksIHRoZSBMRkIgbWF5IHBlcmZvcm0gcmVhZCwgDQogICAgICB3cml0ZSBhbmQvb3Ig Y29uc3VtZSBvcGVyYXRpb25zIG9uIGFueSBhY3RpdmUgbWV0YWRhdGEgYXNzb2NpYXRlZCANCiAg ICAgIHdpdGggdGhlIHBhY2tldC4gIElmIHRoZSBMRkIgaXMgY29uc2lkZXJlZCB0byBiZSBhIGJs YWNrIGJveCwgb25lIA0KICAgICAgb2YgdGhlIGZvbGxvd2luZyBvcGVyYXRpb25zIGlzIHBlcmZv cm1lZCBvbiBlYWNoIGFjdGl2ZSBtZXRhZGF0YS4gDQogICAgICAgDQogICAgICAgIC4gSUdOT1JF OiAgICAgICAgICAgaWdub3JlcyBhbmQgZm9yd2FyZHMgdGhlIG1ldGFkYXRhIA0KICAgICAgICAu IFJFQUQ6ICAgICAgICAgICAgIHJlYWRzIGFuZCBmb3J3YXJkcyB0aGUgbWV0YWRhdGEgDQogICAg ICAgIC4gUkVBRC9SRS1XUklURTogICAgcmVhZHMsIG92ZXItd3JpdGVzIGFuZCBmb3J3YXJkcyB0 aGUgDQogICAgICAgICAgIG1ldGFkYXRhIA0KICAgICAgICAuIFdSSVRFOiAgICAgICAgICAgIHdy aXRlcyBhbmQgZm9yd2FyZHMgdGhlIG1ldGFkYXRhIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAoY2FuIGFsc28gYmUgdXNlZCB0byBjcmVhdGUgbmV3IG1ldGFkYXRhKSANCiAgICAgICAg LiBSRUFELUFORC1DT05TVU1FOiByZWFkcyBhbmQgY29uc3VtZXMgdGhlIG1ldGFkYXRhIA0KICAg ICAgICAuIENPTlNVTUUgICAgICAgICAgIGNvbnN1bWVzIG1ldGFkYXRhIHdpdGhvdXQgcmVhZGlu ZyANCiAgICAgICANCiAgICAgIFRoZSBsYXN0IHR3byBvcGVyYXRpb25zIHRlcm1pbmF0ZSB0aGUg bGlmZS1jeWNsZSBvZiB0aGUgbWV0YWRhdGEsIA0KICAgICAgbWVhbmluZyB0aGF0IHRoZSBtZXRh ZGF0YSBpcyBub3QgZm9yd2FyZGVkIHdpdGggdGhlIHBhY2tldCB3aGVuIA0KICAgICAgdGhlIHBh Y2tldCBpcyBzZW50IHRvIHRoZSBuZXh0IExGQi4gDQogICAgICAgDQogICAgICBJbiBvdXIgbW9k ZWwsIGEgbmV3IG1ldGFkYXRhIGlzIGdlbmVyYXRlZCBieSBhbiBMRkIgd2hlbiB0aGUgTEZCIA0K ICAgICAgYXBwbGllcyBhIFdSSVRFIG9wZXJhdGlvbiB0byBhIG1ldGFkYXRhIHR5cGUgdGhhdCB3 YXMgbm90IHByZXNlbnQgDQogICAgICB3aGVuIHRoZSBwYWNrZXQgd2FzIHJlY2VpdmVkIGJ5IHRo ZSBMRkIuICBTdWNoIGltcGxpY2l0IGNyZWF0aW9uIA0KDQogICAgDQogICBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjJd IA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIG1heSBiZSB1bmludGVudGlvbmFsIGJ5 IHRoZSBMRkIsIHRoYXQgaXMsIHRoZSBMRkIgbWF5IGFwcGx5IHRoZSANCiAgICAgIFdSSVRFIG9w ZXJhdGlvbiB3aXRob3V0IGtub3dpbmcgb3IgY2FyaW5nIGlmIHRoZSBnaXZlbiBtZXRhZGF0YSAN CiAgICAgIGV4aXN0ZWQgb3Igbm90LiAgSWYgaXQgZXhpc3RlZCwgdGhlIG1ldGFkYXRhIGdldHMg b3Zlci13cml0dGVuOyBpZiANCiAgICAgIGl0IGRpZCBub3QgZXhpc3QsIHRoZSBtZXRhZGF0YSBp cyBjcmVhdGVkLiANCiAgICAgICANCiAgICAgIEZvciBMRkJzIHRoYXQgaW5zZXJ0IHBhY2tldHMg aW50byB0aGUgbW9kZWwsIFdSSVRFIGlzIHRoZSBvbmx5IA0KICAgICAgbWVhbmluZ2Z1bCBtZXRh ZGF0YSBvcGVyYXRpb24uIA0KICAgICAgIA0KICAgICAgRm9yIExGQnMgdGhhdCByZW1vdmUgdGhl IHBhY2tldCBmcm9tIHRoZSBtb2RlbCwgdGhleSBtYXkgZWl0aGVyIA0KICAgICAgUkVBRC1BTkQt Q09OU1VNRSAocmVhZCkgb3IgQ09OU1VNRSAoaWdub3JlKSBlYWNoIGFjdGl2ZSBtZXRhZGF0YSAN CiAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgcGFja2V0LiANCiAgICAgICANCiAgIDMuMi40LjQu IE1ldGFkYXRhIFByb2R1Y3Rpb24gYW5kIENvbnN1bXB0aW9uIA0KICAgICAgIA0KICAgICAgRm9y IGEgZ2l2ZW4gbWV0YWRhdGEgb24gYSBnaXZlbiBwYWNrZXQgcGF0aCwgdGhlcmUgbXVzdCBiZSBh dCANCiAgICAgIGxlYXN0IG9uZSBwcm9kdWNlciBMRkIgdGhhdCBjcmVhdGVzIHRoYXQgbWV0YWRh dGEgYW5kIHNob3VsZCBiZSBhdCANCiAgICAgIGxlYXN0IG9uZSBjb25zdW1lciBMRkIgdGhhdCBu ZWVkcyB0aGF0IG1ldGFkYXRhLiAgSW4gdGhpcyBtb2RlbCwgDQogICAgICB0aGUgcHJvZHVjZXIg YW5kIGNvbnN1bWVyIExGQnMgb2YgYSBtZXRhZGF0YSBhcmUgbm90IHJlcXVpcmVkIHRvIA0KICAg ICAgYmUgYWRqYWNlbnQuICBJbiBhZGRpdGlvbiwgdGhlcmUgbWF5IGJlIG11bHRpcGxlIHByb2R1 Y2VycyBhbmQgDQogICAgICBjb25zdW1lcnMgZm9yIHRoZSBzYW1lIG1ldGFkYXRhLiAgV2hlbiBh IHBhY2tldCBwYXRoIGludm9sdmVzIA0KICAgICAgbXVsdGlwbGUgcHJvZHVjZXJzIG9mIHRoZSBz YW1lIG1ldGFkYXRhLCB0aGVuIHN1YnNlcXVlbnQgcHJvZHVjZXJzIA0KICAgICAgb3ZlcndyaXRl IHRoYXQgbWV0YWRhdGEgdmFsdWUuIA0KICAgIA0KICAgICAgVGhlIG1ldGFkYXRhIHRoYXQgaXMg cHJvZHVjZWQgYnkgYW4gTEZCIGlzIHNwZWNpZmllZCBieSB0aGUgTEZCIA0KICAgICAgY2xhc3Mg ZGVmaW5pdGlvbiBvbiBhIHBlciBvdXRwdXQgcG9ydCBncm91cCBiYXNpcy4gIEEgcHJvZHVjZXIg bWF5IA0KICAgICAgYWx3YXlzIGdlbmVyYXRlIHRoZSBtZXRhZGF0YSBvbiB0aGUgcG9ydCBncm91 cCwgb3IgbWF5IGdlbmVyYXRlIGl0IA0KICAgICAgb25seSB1bmRlciBjZXJ0YWluIGNvbmRpdGlv bnMuICBXZSBjYWxsIHRoZSBmb3JtZXIgYW4gDQogICAgICAidW5jb25kaXRpb25hbCIgbWV0YWRh dGEsIHdoZXJlYXMgdGhlIGxhdHRlciBpcyBhICJjb25kaXRpb25hbCIgDQogICAgICBtZXRhZGF0 YS4gIEluIHRoZSBjYXNlIG9mIGNvbmRpdGlvbmFsIG1ldGFkYXRhLCBpdCBzaG91bGQgYmUgDQog ICAgICBwb3NzaWJsZSB0byBkZXRlcm1pbmUgZnJvbSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgTEZC IHdoZW4gYSANCiAgICAgICJjb25kaXRpb25hbCIgbWV0YWRhdGEgaXMgcHJvZHVjZWQuIA0KICAg ICAgIA0KICAgICAgVGhlIGNvbnN1bWVyIGJlaGF2aW9yIG9mIGFuIExGQiwgdGhhdCBpcywgdGhl IG1ldGFkYXRhIHRoYXQgdGhlIA0KICAgICAgTEZCIG5lZWRzIGZvciBpdHMgb3BlcmF0aW9uLCBp cyBkZWZpbmVkIGluIHRoZSBMRkIgY2xhc3MgDQogICAgICBkZWZpbml0aW9uIG9uIGEgcGVyIGlu cHV0IHBvcnQgZ3JvdXAgYmFzaXMuICBBbiBpbnB1dCBwb3J0IGdyb3VwIA0KICAgICAgbWF5ICJy ZXF1aXJlIiBhIGdpdmVuIG1ldGFkYXRhLCBvciBtYXkgdHJlYXQgaXQgYXMgIm9wdGlvbmFsIiAN CiAgICAgIGluZm9ybWF0aW9uLiAgSW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgTEZCIGNsYXNzIGRl ZmluaXRpb24gbXVzdCANCiAgICAgIGV4cGxpY2l0bHkgZGVmaW5lIHdoYXQgaGFwcGVucyBpZiBh biBvcHRpb25hbCBtZXRhZGF0YSBpcyBub3QgDQogICAgICBwcm92aWRlZC4gIE9uZSBhcHByb2Fj aCBpcyB0byBzcGVjaWZ5IGEgZGVmYXVsdCB2YWx1ZSBmb3IgZWFjaCANCiAgICAgIG9wdGlvbmFs IG1ldGFkYXRhLCBhbmQgYXNzdW1lIHRoYXQgdGhlIGRlZmF1bHQgdmFsdWUgaXMgdXNlZCBpZiAN CiAgICAgIHRoZSBtZXRhZGF0YSBpcyBub3QgcHJvdmlkZWQgd2l0aCB0aGUgcGFja2V0LiANCiAg ICAgICANCiAgICAgIFdoZW4gYSBjb25zdW1lciBMRkIgcmVxdWlyZXMgYSBnaXZlbiBtZXRhZGF0 YSwgaXQgaGFzIGRlcGVuZGVuY2llcyANCiAgICAgIG9uIGl0cyB1cC1zdHJlYW0gTEZCcy4gIFRo YXQgaXMsIHRoZSBjb25zdW1lciBMRkIgY2FuIG9ubHkgDQogICAgICBmdW5jdGlvbiBpZiB0aGVy ZSBpcyBhdCBsZWFzdCBvbmUgcHJvZHVjZXIgb2YgdGhhdCBtZXRhZGF0YSBhbmQgbm8gDQogICAg ICBpbnRlcm1lZGlhdGUgTEZCIGNvbnN1bWVzIHRoZSBtZXRhZGF0YS4gDQogICAgICAgDQogICAg DQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMjNdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZF IE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoZSBt b2RlbCBzaG91bGQgZXhwb3NlIHRoZXNlIGludGVyLWRlcGVuZGVuY2llcy4gIEZ1cnRoZXJtb3Jl LCBpdCANCiAgICAgIHNob3VsZCBiZSBwb3NzaWJsZSB0byB0YWtlIGludGVyLWRlcGVuZGVuY2ll cyBpbnRvIGNvbnNpZGVyYXRpb24gDQogICAgICB3aGVuIGNvbnN0cnVjdGluZyBMRkIgdG9wb2xv Z2llcywgYW5kIGFsc28gdGhhdCB0aGUgZGVwZW5kZW5jaWVzIA0KICAgICAgY2FuIGJlIHZlcmlm aWVkIHdoZW4gdmFsaWRhdGluZyB0b3BvbG9naWVzLiANCiAgICAgICANCiAgICAgIEZvciBleHRl bnNpYmlsaXR5IHJlYXNvbnMsIHRoZSBMRkIgc3BlY2lmaWNhdGlvbiBzaG91bGQgZGVmaW5lIA0K ICAgICAgd2hhdCBtZXRhZGF0YSB0aGUgTEZCIHJlcXVpcmVzIHdpdGhvdXQgc3BlY2lmeWluZyB3 aGljaCBMRkIocykgaXQgDQogICAgICBleHBlY3RzIGEgY2VydGFpbiBtZXRhZGF0YSB0byBjb21l IGZyb20uICBTaW1pbGFybHksIExGQnMgc2hvdWxkIA0KICAgICAgc3BlY2lmeSB3aGF0IG1ldGFk YXRhIHRoZXkgcHJvZHVjZSB3aXRob3V0IHNwZWNpZnlpbmcgd2hpY2ggTEZCcyANCiAgICAgIHRo ZSBtZXRhZGF0YSBpcyBtZWFudCBmb3IuIA0KICAgICAgIA0KICAgICAgV2hlbiBzcGVjaWZ5aW5n IHRoZSBtZXRhZGF0YSB0YWdzLCBzb21lIGhhcm1vbml6YXRpb24gZWZmb3J0IG11c3QgDQogICAg ICBiZSBtYWRlIHNvIHRoYXQgdGhlIHByb2R1Y2VyIExGQiBjbGFzcyB1c2VzIHRoZSBzYW1lIHRh ZyBhcyBpdHMgDQogICAgICBpbnRlbmRlZCBjb25zdW1lcihzKSwgb3IgdmljZSB2ZXJzYS4gDQog ICAgICAgDQogICAzLjIuNC41LiBGaXhlZCwgVmFyaWFibGUgYW5kIENvbmZpZ3VyYWJsZSBUYWcg IA0KICAgICAgIA0KICAgICAgV2hlbiB0aGUgcHJvZHVjZWQgbWV0YWRhdGEgaXMgZGVmaW5lZCBm b3IgYSBnaXZlbiBMRkIgY2xhc3MsIG1vc3QgDQogICAgICBtZXRhZGF0YSB3aWxsIGJlIHNwZWNp ZmllZCB3aXRoIGEgZml4ZWQgdGFnLiAgRm9yIGV4YW1wbGUsIGEgUmF0ZSANCiAgICAgIE1ldGVy IExGQiB3aWxsIGFsd2F5cyBwcm9kdWNlIHRoZSAiQ29sb3IiIG1ldGFkYXRhLiANCiAgICAgICAN CiAgICAgIEEgc21hbGwgc3Vic2V0IG9mIExGQnMgbmVlZCB0aGUgY2FwYWJpbGl0eSB0byBwcm9k dWNlIG9uZSBvciBtb3JlIA0KICAgICAgb2YgdGhlaXIgbWV0YWRhdGEgd2l0aCB0YWdzIHRoYXQg YXJlIG5vdCBmaXhlZCBpbiB0aGUgTEZCIGNsYXNzIA0KICAgICAgZGVmaW5pdGlvbiwgYnV0IGlu c3RlYWQgY2FuIGJlIHNlbGVjdGVkIHBlciBMRkIgaW5zdGFuY2UuICBBbiANCiAgICAgIGV4YW1w bGUgb2Ygc3VjaCBhbiBMRkIgY2xhc3MgaXMgYSBHZW5lcmljIENsYXNzaWZpZXIgTEZCLiAgV2Ug Y2FsbCANCiAgICAgIHRoaXMgY2FwYWJpbGl0eSAidmFyaWFibGUgdGFnIG1ldGFkYXRhIHByb2R1 Y3Rpb24iLiAgSWYgYW4gTEZCIA0KICAgICAgcHJvZHVjZXMgbWV0YWRhdGEgd2l0aCBhIHZhcmlh YmxlIHRhZywgdGhlIGNvcnJlc3BvbmRpbmcgTEZCIA0KICAgICAgYXR0cmlidXRlLCBjYWxsZWQg dGhlIHRhZyBzZWxlY3Rvciwgc3BlY2lmaWVzIHRoZSB0YWcgZm9yIGVhY2ggDQogICAgICBzdWNo IG1ldGFkYXRhLiAgVGhpcyBtZWNoYW5pc20gaW1wcm92ZXMgdGhlIHZlcnNhdGlsaXR5IG9mIGNl cnRhaW4gDQogICAgICBtdWx0aS1wdXJwb3NlIExGQiBjbGFzc2VzLCBzaW5jZSBpdCBhbGxvd3Mg dGhlIHNhbWUgTEZCIGNsYXNzIHRvIA0KICAgICAgYmUgdXNlZCBpbiBkaWZmZXJlbnQgdG9wb2xv Z2llcywgcHJvZHVjaW5nIHRoZSByaWdodCBtZXRhZGF0YSB0YWdzIA0KICAgICAgYWNjb3JkaW5n IHRvIHRoZSBuZWVkcyBvZiB0aGUgdG9wb2xvZ3kuIA0KICAgICAgICANCiAgICAgIERlcGVuZGlu ZyBvbiB0aGUgY2FwYWJpbGl0eSBvZiB0aGUgRkUsIHRoZSB0YWcgc2VsZWN0b3IgY2FuIGJlIA0K ICAgICAgZWl0aGVyIGEgcmVhZC1vbmx5IG9yIGEgcmVhZC13cml0ZSBhdHRyaWJ1dGUuICBJZiB0 aGUgc2VsZWN0b3IgaXMgDQogICAgICByZWFkLW9ubHksIHRoZSB0YWcgY2Fubm90IGJlIG1vZGlm aWVkIGJ5IHRoZSBDRS4gIElmIHRoZSBzZWxlY3RvciANCiAgICAgIGlzIHJlYWQtd3JpdGUsIHRo ZSB0YWcgY2FuIGJlIGNvbmZpZ3VyZWQgYnkgdGhlIENFLCBoZW5jZSB3ZSBjYWxsIA0KICAgICAg dGhpcyAiY29uZmlndXJhYmxlIHRhZyBtZXRhZGF0YSBwcm9kdWN0aW9uLiIgIE5vdGUgdGhhdCB1 c2luZyB0aGlzIA0KICAgICAgZGVmaW5pdGlvbiwgY29uZmlndXJhYmxlIHRhZyBtZXRhZGF0YSBw cm9kdWN0aW9uIGlzIGEgc3Vic2V0IG9mIA0KICAgICAgdmFyaWFibGUgdGFnIG1ldGFkYXRhIHBy b2R1Y3Rpb24uIA0KICAgICAgIA0KICAgICAgU2ltaWxhciBjb25jZXB0cyBjYW4gYmUgaW50cm9k dWNlZCBmb3IgdGhlIGNvbnN1bWVyIExGQnMgdG8gDQogICAgICBzYXRpc2Z5IGRpZmZlcmVudCBt ZXRhZGF0YSBuZWVkcy4gIE1vc3QgTEZCIGNsYXNzZXMgd2lsbCBzcGVjaWZ5IA0KICAgICAgdGhl aXIgbWV0YWRhdGEgbmVlZHMgdXNpbmcgZml4ZWQgbWV0YWRhdGEgdGFncy4gIEZvciBleGFtcGxl LCBhIA0KICAgICAgTmV4dCBIb3AgTEZCIG1heSBhbHdheXMgcmVxdWlyZSBhICJOZXh0SG9wSWQi IG1ldGFkYXRhOyBidXQgdGhlIA0KICAgICAgUmVkaXJlY3RvciBMRkIgbWF5IG5lZWQgYSAiQ2xh c3NJRCIgbWV0YWRhdGEgaW4gb25lIGluc3RhbmNlLCBhbmQgDQogICAgICBhICJQcm90b2NvbFR5 cGUiIG1ldGFkYXRhIGluIGFub3RoZXIgaW5zdGFuY2UgYXMgYSBiYXNpcyBmb3IgDQogICAgDQog ICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMjRdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1v ZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIHNlbGVjdGlu ZyB0aGUgcmlnaHQgb3V0cHV0IHBvcnQuICBJbiB0aGlzIGNhc2UsIGFuIExGQiBhdHRyaWJ1dGUg DQogICAgICBpcyB1c2VkIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIG1ldGFkYXRhIHRhZyBhdCBy dW4tdGltZS4gIFRoaXMgDQogICAgICBtZXRhZGF0YSB0YWcgc2VsZWN0b3IgYXR0cmlidXRlIG1h eSBiZSByZWFkLW9ubHkgb3IgcmVhZC13cml0ZSwgDQogICAgICBkZXBlbmRpbmcgb24gdGhlIGNh cGFiaWxpdGllcyBvZiB0aGUgTEZCIGluc3RhbmNlIGFuZCB0aGUgRkUuIA0KICAgICAgIA0KICAg My4yLjQuNi4gTWV0YWRhdGEgVXNhZ2UgQ2F0ZWdvcmllcyANCiAgICAgICANCiAgICAgIERlcGVu ZGluZyBvbiB0aGUgcm9sZSBhbmQgdXNhZ2Ugb2YgYSBtZXRhZGF0YSwgdmFyaW91cyBhbW91bnRz IG9mIA0KICAgICAgZW5jb2RpbmcgaW5mb3JtYXRpb24gbXVzdCBiZSBwcm92aWRlZCB3aGVuIHRo ZSBtZXRhZGF0YSBpcyANCiAgICAgIGRlZmluZWQsIHdoZXJlIHNvbWUgY2FzZXMgb2ZmZXIgbGVz cyBmbGV4aWJpbGl0eSBpbiB0aGUgdmFsdWUgDQogICAgICBzZWxlY3Rpb24gdGhhbiBvdGhlcnMu IA0KICAgICAgIA0KICAgICAgVGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIG1ldGFkYXRhIHJlbGF0 ZWQgdG8gbWV0YWRhdGEgdXNhZ2U6IA0KICAgICAgICAuIFJlbGF0aW9uYWwgKG9yIGJpbmRpbmcp IG1ldGFkYXRhIA0KICAgICAgICAuIEVudW1lcmF0ZWQgbWV0YWRhdGEgDQogICAgICAgIC4gRXhw bGljaXQvZXh0ZXJuYWwgdmFsdWUgbWV0YWRhdGEgDQogICAgICAgDQogICAgICBUaGUgcHVycG9z ZSBvZiB0aGUgcmVsYXRpb25hbCBtZXRhZGF0YSBpcyB0byByZWZlciBpbiBvbmUgTEZCIA0KICAg ICAgaW5zdGFuY2UgKHByb2R1Y2VyIExGQikgdG8gYSAidGhpbmciIGluIGFub3RoZXIgZG93bnN0 cmVhbSBMRkIgDQogICAgICBpbnN0YW5jZSAoY29uc3VtZXIgTEZCKSwgd2hlcmUgdGhlICJ0aGlu ZyIgaXMgdHlwaWNhbGx5IGFuIGVudHJ5IA0KICAgICAgaW4gYSB0YWJsZSBhdHRyaWJ1dGUgb2Yg dGhlIGNvbnN1bWVyIExGQi4gDQogICAgICAgDQogICAgICBGb3IgZXhhbXBsZSwgdGhlIFByZWZp eCBMb29rdXAgTEZCIGV4ZWN1dGVzIGFuIExQTSBzZWFyY2ggdXNpbmcgDQogICAgICBpdHMgcHJl Zml4IHRhYmxlIGFuZCByZXNvbHZlcyB0byBhIG5leHQtaG9wIHJlZmVyZW5jZS4gIFRoaXMgDQog ICAgICByZWZlcmVuY2UgbmVlZHMgdG8gYmUgcGFzc2VkIGFzIG1ldGFkYXRhIGJ5IHRoZSBQcmVm aXggTG9va3VwIExGQiANCiAgICAgIChwcm9kdWNlcikgdG8gdGhlIE5leHQgSG9wIExGQiAoY29u c3VtZXIpLCBhbmQgbXVzdCByZWZlciB0byBhIA0KICAgICAgc3BlY2lmaWMgZW50cnkgaW4gdGhl IG5leHQtaG9wIHRhYmxlIHdpdGhpbiB0aGUgY29uc3VtZXIuIA0KICAgICAgIA0KICAgICAgRXhw cmVzc2luZyBhbmQgcHJvcGFnYXRpbmcgc3VjaCBhIGJpbmRpbmcgcmVsYXRpb25zaGlwIGlzIHBy b2JhYmx5IA0KICAgICAgdGhlIG1vc3QgY29tbW9uIHVzYWdlIG9mIG1ldGFkYXRhLiAgT25lIG9y IG1vcmUgb2JqZWN0cyBpbiB0aGUgDQogICAgICBwcm9kdWNlciBMRkIgYXJlIGJvdW5kIHRvIGEg c3BlY2lmaWMgb2JqZWN0IGluIHRoZSBjb25zdW1lciBMRkIuICANCiAgICAgIFN1Y2ggYSByZWxh dGlvbnNoaXAgaXMgZXN0YWJsaXNoZWQgYnkgdGhlIENFIGV4cGxpY2l0bHkgYnkgDQogICAgICBw cm9wZXJseSBjb25maWd1cmluZyB0aGUgYXR0cmlidXRlcyBpbiBib3RoIExGQnMuICBBdmFpbGFi bGUgDQogICAgICBtZXRob2RzIGluY2x1ZGUgdGhlIGZvbGxvd2luZzogDQogICAgICAgDQogICAg ICBUaGUgYmluZGluZyBtYXkgYmUgZXhwcmVzc2VkIGJ5IHRhZ2dpbmcgdGhlIGludm9sdmVkIG9i amVjdHMgaW4gDQogICAgICBib3RoIExGQnMgd2l0aCB0aGUgc2FtZSB1bmlxdWUsIGJ1dCBvdGhl cndpc2UgYXJiaXRyYXJ5LCANCiAgICAgIGlkZW50aWZpZXIuICBUaGUgdmFsdWUgb2YgdGhlIHRh ZyBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgYnkgdGhlIA0KICAgICAgQ0UgYnkgd3JpdGluZyB0 aGUgdmFsdWUgaW50byBib3RoIExGQnMsIGFuZCB0aGlzIHZhbHVlIGlzIGFsc28gDQogICAgICBj YXJyaWVkIGJ5IHRoZSBtZXRhZGF0YSBiZXR3ZWVuIHRoZSBMRkJzLiANCiAgICAgICANCiAgICAg IEFub3RoZXIgd2F5IG9mIHNldHRpbmcgdXAgYmluZGluZyByZWxhdGlvbnMgaXMgdG8gdXNlIGEg bmF0dXJhbGx5IA0KICAgICAgb2NjdXJyaW5nIHVuaXF1ZSBpZGVudGlmaWVyIG9mIHRoZSBjb25z dW1lcidzIG9iamVjdCBhcyBhIA0KICAgICAgcmVmZXJlbmNlIGFuZCBhcyBhIHZhbHVlIG9mIHRo ZSBtZXRhZGF0YSAoZS5nLiwgdGhlIGFycmF5IGluZGV4IG9mIA0KICAgICAgYSB0YWJsZSBlbnRy eSkuICBJbiB0aGlzIGNhc2UsIHRoZSBpbmRleCBpcyBlaXRoZXIgcmVhZCBvciANCiAgICAgIGlu ZmVycmVkIGJ5IHRoZSBDRSBieSBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGNvbnN1bWVyIExGQi4g IE9uY2UgDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAg IA0KICAgICAgdGhlIENFIG9idGFpbnMgdGhlIGluZGV4LCBpdCBuZWVkcyB0byB3cml0ZSBpdCBp bnRvIHRoZSBwcm9kdWNlciANCiAgICAgIExGQiB0byBlc3RhYmxpc2ggdGhlIGJpbmRpbmcuIA0K ICAgICAgIA0KICAgICAgSW1wb3J0YW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgYmluZGluZyB1 c2FnZSBvZiBtZXRhZGF0YSBhcmU6IA0KICAgICAgIA0KICAgICAgICAuIFRoZSB2YWx1ZSBvZiB0 aGUgbWV0YWRhdGEgc2hvd3MgdXAgaW4gdGhlIENFLUZFIGNvbW11bmljYXRpb24gDQogICAgICAg ICAgIGZvciBCT1RIIHRoZSBjb25zdW1lciBhbmQgdGhlIHByb2R1Y2VyLiAgVGhhdCBpcywgdGhl IA0KICAgICAgICAgICBtZXRhZGF0YSB2YWx1ZSBtdXN0IGJlIGNhcnJpZWQgb3ZlciB0aGUgRm9y Q0VTIHByb3RvY29sLiAgDQogICAgICAgICAgIFVzaW5nIHRoZSB0YWdnaW5nIHRlY2huaXF1ZSwg dGhlIHZhbHVlIGlzIFdSSVRURU4gdG8gYm90aCANCiAgICAgICAgICAgTEZCcy4gIFVzaW5nIHRo ZSBvdGhlciB0ZWNobmlxdWUsIHRoZSB2YWx1ZSBpcyBXUklUVEVOIHRvIA0KICAgICAgICAgICBv bmx5IHRoZSBwcm9kdWNlciBMRkIgYW5kIG1heSBiZSBSRUFEIGZyb20gdGhlIGNvbnN1bWVyIExG Qi4gDQogICAgICAgDQogICAgICAgIC4gVGhlIG1ldGFkYXRhIHZhbHVlIGlzIGlycmVsZXZhbnQg dG8gdGhlIENFLCB0aGUgYmluZGluZyBpcyANCiAgICAgICAgICAgc2ltcGx5IGV4cHJlc3NlZCBi eSB1c2luZyB0aGUgU0FNRSB2YWx1ZSBhdCB0aGUgY29uc3VtZXIgYW5kIA0KICAgICAgICAgICBw cm9kdWNlciBMRkJzLiANCiAgICAgICANCiAgICAgICAgLiBIZW5jZSB0aGUgbWV0YWRhdGEgZGVm aW5pdGlvbiBpcyBub3QgcmVxdWlyZWQgdG8gaW5jbHVkZSANCiAgICAgICAgICAgdmFsdWUgYXNz aWdubWVudHMuICBUaGUgb25seSBleGNlcHRpb24gaXMgd2hlbiBzb21lIHNwZWNpYWwgDQogICAg ICAgICAgIHZhbHVlKHMpIG9mIHRoZSBtZXRhZGF0YSBtdXN0IGJlIHJlc2VydmVkIHRvIGNvbnZl eSBzcGVjaWFsIA0KICAgICAgICAgICBldmVudHMuICBFdmVuIHRob3VnaCB0aGVzZSBzcGVjaWFs IGNhc2VzIG11c3QgYmUgZGVmaW5lZCB3aXRoIA0KICAgICAgICAgICB0aGUgbWV0YWRhdGEgc3Bl Y2lmaWNhdGlvbiwgdGhlaXIgZW5jb2RlZCB2YWx1ZXMgY2FuIGJlIA0KICAgICAgICAgICBzZWxl Y3RlZCBhcmJpdHJhcmlseS4gIEZvciBleGFtcGxlLCBmb3IgdGhlIFByZWZpeCBMb29rdXAgTEZC IA0KICAgICAgICAgICBleGFtcGxlLCBhIHNwZWNpYWwgdmFsdWUgbWF5IGJlIHJlc2VydmVkIHRv IHNpZ25hbCB0aGUgTk8tDQogICAgICAgICAgIE1BVENIIGNhc2UsIGFuZCB0aGUgdmFsdWUgb2Yg emVybyBtYXkgYmUgYXNzaWduZWQgZm9yIHRoaXMgDQogICAgICAgICAgIHB1cnBvc2UuIA0KICAg ICAgICANCiAgICAgIFRoZSBzZWNvbmQgY2xhc3Mgb2YgbWV0YWRhdGEgaXMgdGhlIGVudW1lcmF0 ZWQgdHlwZS4gIEFuIGV4YW1wbGUgDQogICAgICBpcyB0aGUgIkNvbG9yIiBtZXRhZGF0YSB0aGF0 IGlzIHByb2R1Y2VkIGJ5IGEgTWV0ZXIgTEZCLiBBcyB0aGUgDQogICAgICBuYW1lIHN1Z2dlc3Rz LCBlbnVtZXJhdGVkIG1ldGFkYXRhIGhhcyBhIHJlbGF0aXZlbHkgc21hbGwgbnVtYmVyIA0KICAg ICAgb2YgcG9zc2libGUgdmFsdWVzLCBlYWNoIHdpdGggYSBzcGVjaWZpYyBtZWFuaW5nLiAgQWxs IHBvc3NpYmxlIA0KICAgICAgY2FzZXMgbXVzdCBiZSBlbnVtZXJhdGVkIHdoZW4gZGVmaW5pbmcg dGhpcyBjbGFzcyBvZiBtZXRhZGF0YS4gIA0KICAgICAgQWx0aG91Z2ggYSB2YWx1ZSBlbmNvZGlu ZyBtdXN0IGJlIGluY2x1ZGVkIGluIHRoZSBzcGVjaWZpY2F0aW9uLCANCiAgICAgIHRoZSBhY3R1 YWwgdmFsdWVzIGNhbiBiZSBzZWxlY3RlZCBhcmJpdHJhcmlseSAoZS5nLiwgPFJlZD0wLCANCiAg ICAgIFllbGxvdz0xLCBHcmVlbj0yPiBhbmQgPFJlZD0zLCBZZWxsb3c9MiwgR3JlZW4gMT4gd291 bGQgYmUgYm90aCANCiAgICAgIHZhbGlkIGVuY29kaW5ncywgd2hhdCBpcyBpbXBvcnRhbnQgaXMg dGhhdCBhbiBlbmNvZGluZyBpcyANCiAgICAgIHNwZWNpZmllZCkuIA0KICAgICAgIA0KICAgICAg VGhlIHZhbHVlIG9mIHRoZSBlbnVtZXJhdGVkIG1ldGFkYXRhIG1heSBvciBtYXkgbm90IGJlIGNv bnZleWVkIA0KICAgICAgdmlhIHRoZSBGb3JDRVMgcHJvdG9jb2wgYmV0d2VlbiB0aGUgQ0UgYW5k IEZFLiANCiAgICAgICANCiAgICAgIFRoZSB0aGlyZCBjbGFzcyBvZiBtZXRhZGF0YSBpcyB0aGUg ZXhwbGljaXQgdHlwZS4gIFRoaXMgcmVmZXJzIHRvIA0KICAgICAgY2FzZXMgd2hlcmUgdGhlIG1l dGFkYXRhIHZhbHVlIGlzIGV4cGxpY2l0bHkgdXNlZCBieSB0aGUgY29uc3VtZXIgDQogICAgICBM RkIgdG8gY2hhbmdlIHNvbWUgcGFja2V0IGhlYWRlciBmaWVsZHMuICBJbiBvdGhlciB3b3Jkcywg dGhlIA0KICAgICAgdmFsdWUgaGFzIGEgZGlyZWN0IGFuZCBleHBsaWNpdCBpbXBhY3Qgb24gc29t ZSBmaWVsZCBhbmQgd2lsbCBiZSANCiAgICAgIHZpc2libGUgZXh0ZXJuYWxseSB3aGVuIHRoZSBw YWNrZXQgbGVhdmVzIHRoZSBORS4gIEV4YW1wbGVzIGFyZTogDQogICAgICBUVEwgaW5jcmVtZW50 IGdpdmVuIHRvIGEgSGVhZGVyIE1vZGlmaWVyIExGQiwgYW5kIERTQ1AgdmFsdWUgZm9yIGEgDQog ICAgICBSZW1hcmtlciBMRkIuICBGb3IgZXhwbGljaXQgbWV0YWRhdGEsIHRoZSB2YWx1ZSBlbmNv ZGluZyBtdXN0IGJlIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3Qg MjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDI2XSANCgwgICBJbnRlcm5ldCBEcmFm dCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAg DQogICAgDQogICAgICBleHBsaWNpdGx5IHByb3ZpZGVkIGluIHRoZSBtZXRhZGF0YSBkZWZpbml0 aW9uLiAgVGhlIHZhbHVlcyBjYW5ub3QgDQogICAgICBiZSBzZWxlY3RlZCBhcmJpdHJhcmlseSBh bmQgc2hvdWxkIGNvbmZvcm0gdG8gd2hhdCBpcyBjb21tb25seSANCiAgICAgIGV4cGVjdGVkLiAg Rm9yIGV4YW1wbGUsIGEgVFRMIGluY3JlbWVudCBtZXRhZGF0YSBzaG91bGQgYmUgZW5jb2RlZCAN CiAgICAgIGFzIHplcm8gZm9yIHRoZSBubyBpbmNyZW1lbnQgY2FzZSwgb25lIGZvciB0aGUgc2lu Z2xlIGluY3JlbWVudCANCiAgICAgIGNhc2UsIGV0Yy4gIEEgRFNDUCBtZXRhZGF0YSBzaG91bGQg dXNlIDAgdG8gZW5jb2RlIERTQ1A9MCwgMSB0byANCiAgICAgIGVuY29kZSBEU0NQPTEsIGV0Yy4g DQogICAgICAgDQogICAzLjIuNS4gTEZCIFZlcnNpb25pbmcgDQogICAgICAgDQogICAgICBMRkIg Y2xhc3MgdmVyc2lvbmluZyBpcyBhIG1ldGhvZCB0byBlbmFibGUgaW5jcmVtZW50YWwgZXZvbHV0 aW9uIA0KICAgICAgb2YgTEZCIGNsYXNzZXMuIEluIGdlbmVyYWwsIGFuIEZFIGlzIG5vdCBhbGxv d2VkIHRvIGNvbnRhaW4gYW4gTEZCIA0KICAgICAgaW5zdGFuY2UgZm9yIG1vcmUgdGhhbiBvbmUg dmVyc2lvbiBvZiBhIHBhcnRpY3VsYXIgY2xhc3MuICANCiAgICAgIEluaGVyaXRhbmNlIChkaXNj dXNzZWQgbmV4dCBpbiBTZWN0aW9uIDMuMi42KSBoYXMgc3BlY2lhbCBydWxlcy4gDQogICAgICBJ ZiBhbiBGRSBkYXRhcGF0aCBtb2RlbCBjb250YWluaW5nIGFuIExGQiBpbnN0YW5jZSBvZiBhIHBh cnRpY3VsYXIgDQogICAgICBjbGFzcyBDIGFsc28gc2ltdWx0YW5lb3VzbHkgY29udGFpbnMgYW4g TEZCIGluc3RhbmNlIG9mIGEgY2xhc3MgQycgDQogICAgICBpbmhlcml0ZWQgZnJvbSBjbGFzcyBD OyBDIGNvdWxkIGhhdmUgYSBkaWZmZXJlbnQgdmVyc2lvbiB0aGFuIEMnLiANCiAgICANCiAgICAg IExGQiBjbGFzcyB2ZXJzaW9uaW5nIGlzIHN1cHBvcnRlZCBieSByZXF1aXJpbmcgYSB2ZXJzaW9u IHN0cmluZyBpbiANCiAgICAgIHRoZSBjbGFzcyBkZWZpbml0aW9uLiAgQ0VzIG1heSBzdXBwb3J0 IG11bHRpcGxlIHZlcnNpb25zIG9mIGEgDQogICAgICBwYXJ0aWN1bGFyIExGQiBjbGFzcyB0byBw cm92aWRlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGJ1dCBGRXMgDQogICAgICBhcmUgbm90IGFs bG93ZWQgdG8gc3VwcG9ydCBtb3JlIHRoYW4gb25lIHZlcnNpb24gb2YgYSBwYXJ0aWN1bGFyIA0K ICAgICAgY2xhc3MuIA0KICAgICAgIA0KICAgMy4yLjYuIExGQiBJbmhlcml0YW5jZSANCiAgICAg ICANCiAgICAgIExGQiBjbGFzcyBpbmhlcml0YW5jZSBpcyBzdXBwb3J0ZWQgaW4gdGhlIEZFIG1v ZGVsIGFzIGEgbWV0aG9kIHRvIA0KICAgICAgZGVmaW5lIG5ldyBMRkIgY2xhc3Nlcy4gIFRoaXMg YWxzbyBhbGxvd3MgRkUgdmVuZG9ycyB0byBhZGQgDQogICAgICB2ZW5kb3Itc3BlY2lmaWMgZXh0 ZW5zaW9ucyB0byBzdGFuZGFyZGl6ZWQgTEZCcy4gIEFuIExGQiBjbGFzcyANCiAgICAgIHNwZWNp ZmljYXRpb24gTVVTVCBzcGVjaWZ5IHRoZSBiYXNlIGNsYXNzIGFuZCB2ZXJzaW9uIG51bWJlciBp dCANCiAgICAgIGluaGVyaXRzIGZyb20gKHRoZSBkZWZhdWx0IGlzIHRoZSBiYXNlIExGQiBjbGFz cykuICBNdWx0aXBsZS0NCiAgICAgIGluaGVyaXRhbmNlIGlzIG5vdCBhbGxvd2VkLCBob3dldmVy LCB0byBhdm9pZCB1bm5lY2Vzc2FyeSANCiAgICAgIGNvbXBsZXhpdHkuICANCiAgICAgICANCiAg ICAgIEluaGVyaXRhbmNlIHNob3VsZCBiZSB1c2VkIG9ubHkgd2hlbiB0aGVyZSBpcyBzaWduaWZp Y2FudCByZXVzZSBvZiANCiAgICAgIHRoZSBiYXNlIExGQiBjbGFzcyBkZWZpbml0aW9uLiAgQSBz ZXBhcmF0ZSBMRkIgY2xhc3Mgc2hvdWxkIGJlIA0KICAgICAgZGVmaW5lZCBpZiBsaXR0bGUgb3Ig bm8gcmV1c2UgaXMgcG9zc2libGUgYmV0d2VlbiB0aGUgZGVyaXZlZCBhbmQgDQogICAgICB0aGUg YmFzZSBMRkIgY2xhc3MuIA0KICAgICAgIA0KICAgICAgQW4gaW50ZXJlc3RpbmcgaXNzdWUgcmVs YXRlZCB0byBjbGFzcyBpbmhlcml0YW5jZSBpcyBiYWNrd2FyZCANCiAgICAgIGNvbXBhdGliaWxp dHkgYmV0d2VlbiBhIGRlc2NlbmRhbnQgYW5kIGFuIGFuY2VzdG9yIGNsYXNzLiAgIA0KICAgICAg Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBoeXBvdGhldGljYWwgc2NlbmFyaW8gd2hlcmUgYSBzdGFu ZGFyZGl6ZWQgDQogICAgICBMRkIgY2xhc3MgIkwxIiBleGlzdHMuICBWZW5kb3IgQSBidWlsZHMg YW4gRkUgdGhhdCBpbXBsZW1lbnRzIExGQiANCiAgICAgICJMMSIgYW5kIHZlbmRvciBCIGJ1aWxk cyBhIENFIHRoYXQgY2FuIHJlY29nbml6ZSBhbmQgb3BlcmF0ZSBvbiANCiAgICAgIExGQiAiTDEi LiAgU3VwcG9zZSB0aGF0IGEgbmV3IExGQiBjbGFzcywgIkwyIiwgaXMgZGVmaW5lZCBiYXNlZCBv biANCiAgICAgIHRoZSBleGlzdGluZyAiTDEiIGNsYXNzIGJ5IGV4dGVuZGluZyBpdHMgY2FwYWJp bGl0aWVzIA0KICAgICAgaW5jcmVtZW50YWxseS4gTGV0IHVzIGV4YW1pbmUgdGhlIEZFIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUgDQogICAgICBieSBjb25zaWRlcmluZyB3aGF0IHdvdWxk IGhhcHBlbiBpZiB2ZW5kb3IgQiB1cGdyYWRlcyBpdHMgRkUgZnJvbSANCiAgICANCiAgIFlhbmcs IGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAyN10gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgIkwxIiB0byAiTDIiIGFu ZCB2ZW5kb3IgQydzIENFIGlzIG5vdCBjaGFuZ2VkLiAgVGhlIG9sZCBMMS1iYXNlZCANCiAgICAg IENFIGNhbiBpbnRlcm9wZXJhdGUgd2l0aCB0aGUgbmV3IEwyLWJhc2VkIEZFIGlmIHRoZSBkZXJp dmVkIExGQiANCiAgICAgIGNsYXNzICJMMiIgaXMgaW5kZWVkIGJhY2t3YXJkIGNvbXBhdGlibGUg d2l0aCB0aGUgYmFzZSBjbGFzcyAiTDEiLiAgIA0KICAgICAgIA0KICAgICAgVGhlIHJldmVyc2Ug c2NlbmFyaW8gaXMgYSBtdWNoIGxlc3MgcHJvYmxlbWF0aWMgY2FzZSwgaS5lLiwgd2hlbiANCiAg ICAgIENFIHZlbmRvciBCIHVwZ3JhZGVzIHRvIHRoZSBuZXcgTEZCIGNsYXNzICJMMiIsIGJ1dCB0 aGUgRkUgaXMgbm90IA0KICAgICAgdXBncmFkZWQuICBOb3RlIHRoYXQgYXMgbG9uZyBhcyB0aGUg Q0UgaXMgY2FwYWJsZSBvZiB3b3JraW5nIHdpdGggDQogICAgICBvbGRlciBMRkIgY2xhc3Nlcywg dGhpcyBwcm9ibGVtIGRvZXMgbm90IGFmZmVjdCB0aGUgbW9kZWw7IGhlbmNlIA0KICAgICAgd2Ug d2lsbCB1c2UgdGhlIHRlcm0gImJhY2t3YXJkIGNvbXBhdGliaWxpdHkiIHRvIHJlZmVyIHRvIHRo ZSANCiAgICAgIGZpcnN0IHNjZW5hcmlvIGNvbmNlcm5pbmcgRkUgYmFja3dhcmQgY29tcGF0aWJp bGl0eS4gDQogICAgICAgDQogICAgICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5IGNhbiBiZSBkZXNp Z25lZCBpbnRvIHRoZSBpbmhlcml0YW5jZSBtb2RlbCANCiAgICAgIGJ5IGNvbnN0cmFpbmluZyBM RkIgaW5oZXJpdGFuY2UgdG8gcmVxdWlyZSB0aGUgZGVyaXZlZCBjbGFzcyBiZSBhIA0KICAgICAg ZnVuY3Rpb25hbCBzdXBlcnNldCBvZiB0aGUgYmFzZSBjbGFzcyAoaS5lLiB0aGUgZGVyaXZlZCBj bGFzcyBjYW4gDQogICAgICBvbmx5IGFkZCBmdW5jdGlvbnMgdG8gdGhlIGJhc2UgY2xhc3MsIGJ1 dCBub3QgcmVtb3ZlIGZ1bmN0aW9ucykuICANCiAgICAgIEFkZGl0aW9uYWxseSwgdGhlIGZvbGxv d2luZyBtZWNoYW5pc21zIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IEZFIA0KICAgICAgYmFja3dh cmQgY29tcGF0aWJpbGl0eTogDQogICAgICAgIDEuIFdoZW4gZGV0ZWN0aW5nIGFuIExGQiBpbnN0 YW5jZSBvZiBhbiBMRkIgdHlwZSB0aGF0IGlzIA0KICAgICAgICAgICB1bmtub3duIHRvIHRoZSBD RSwgdGhlIENFIE1VU1QgYmUgYWJsZSB0byBxdWVyeSB0aGUgYmFzZSANCiAgICAgICAgICAgY2xh c3Mgb2Ygc3VjaCBhbiBMRkIgZnJvbSB0aGUgRkUuIA0KICAgICAgICAyLiBUaGUgTEZCIGluc3Rh bmNlIG9uIHRoZSBGRSBTSE9VTEQgc3VwcG9ydCBhIGJhY2t3YXJkIA0KICAgICAgICAgICBjb21w YXRpYmlsaXR5IG1vZGUgKG1lYW5pbmcgdGhlIExGQiBpbnN0YW5jZSByZXZlcnRzIGl0c2VsZiAN CiAgICAgICAgICAgYmFjayB0byB0aGUgYmFzZSBjbGFzcyBpbnN0YW5jZSksIGFuZCB0aGUgQ0Ug U0hPVUxEIGJlIGFibGUgDQogICAgICAgICAgIHRvIGNvbmZpZ3VyZSB0aGUgTEZCIHRvIHJ1biBp biBzdWNoIGEgbW9kZS4gDQogICAgICAgDQogICAzLjMuIEZFIERhdGFwYXRoIE1vZGVsaW5nICAN CiAgICAgICANCiAgICAgIFBhY2tldHMgY29taW5nIGludG8gdGhlIEZFIGZyb20gaW5ncmVzcyBw b3J0cyBnZW5lcmFsbHkgZmxvdyANCiAgICAgIHRocm91Z2ggbXVsdGlwbGUgTEZCcyBiZWZvcmUg bGVhdmluZyBvdXQgb2YgdGhlIGVncmVzcyBwb3J0cy4gIEhvdyANCiAgICAgIGFuIEZFIHRyZWF0 cyBhIHBhY2tldCBkZXBlbmRzIG9uIG1hbnkgZmFjdG9ycywgc3VjaCBhcyB0eXBlIG9mIHRoZSAN CiAgICAgIHBhY2tldCAoZS5nLiwgSVB2NCwgSVB2NiBvciBNUExTKSwgYWN0dWFsIGhlYWRlciB2 YWx1ZXMsIHRpbWUgb2YgDQogICAgICBhcnJpdmFsLCBldGMuICBUaGUgcmVzdWx0IG9mIExGQiBw cm9jZXNzaW5nIG1heSBoYXZlIGFuIGltcGFjdCBvbiANCiAgICAgIGhvdyB0aGUgcGFja2V0IGlz IHRvIGJlIHRyZWF0ZWQgaW4gZG93bnN0cmVhbSBMRkJzLiAgVGhpcyANCiAgICAgIGRpZmZlcmVu dGlhdGlvbiBvZiBwYWNrZXQgdHJlYXRtZW50IGRvd25zdHJlYW0gY2FuIGJlIA0KICAgICAgY29u Y2VwdHVhbGl6ZWQgYXMgaGF2aW5nIGFsdGVybmF0aXZlIGRhdGFwYXRocyBpbiB0aGUgRkUuICBG b3IgDQogICAgICBleGFtcGxlLCB0aGUgcmVzdWx0IG9mIGEgNi10dXBsZSBjbGFzc2lmaWNhdGlv biBwZXJmb3JtZWQgYnkgYSANCiAgICAgIGNsYXNzaWZpZXIgTEZCIGNvdWxkIGNvbnRyb2wgd2hp Y2ggcmF0ZSBtZXRlciBpcyBhcHBsaWVkIHRvIHRoZSANCiAgICAgIHBhY2tldCBieSBhIHJhdGUg bWV0ZXIgTEZCIGluIGEgbGF0ZXIgc3RhZ2UgaW4gdGhlIGRhdGFwYXRoLiAgIA0KICAgICAgIA0K ICAgICAgTEZCIHRvcG9sb2d5IGlzIGEgZGlyZWN0ZWQgZ3JhcGggcmVwcmVzZW50YXRpb24gb2Yg dGhlIGxvZ2ljYWwgDQogICAgICBkYXRhcGF0aHMgd2l0aGluIGFuIEZFLCB3aXRoIHRoZSBub2Rl cyByZXByZXNlbnRpbmcgdGhlIExGQiANCiAgICAgIGluc3RhbmNlcyBhbmQgdGhlIGRpcmVjdGVk IGxpbmsgZGVwaWN0aW5nIHRoZSBwYWNrZXQgZmxvdyANCiAgICAgIGRpcmVjdGlvbiBmcm9tIG9u ZSBMRkIgdG8gdGhlIG5leHQuICBTZWN0aW9uIDMuMy4xIGRpc2N1c3NlcyBob3cgDQogICAgICB0 aGUgRkUgZGF0YXBhdGhzIGNhbiBiZSBtb2RlbGVkIGFzIExGQiB0b3BvbG9neTsgd2hpbGUgU2Vj dGlvbiANCiAgICAgIDMuMy4yIGZvY3VzZXMgb24gaXNzdWVzIHJlbGF0ZWQgdG8gTEZCIHRvcG9s b2d5IHJlY29uZmlndXJhdGlvbi4gICANCiAgICAgICANCiAgIDMuMy4xLiBBbHRlcm5hdGl2ZSBB cHByb2FjaGVzIGZvciBNb2RlbGluZyBGRSBEYXRhcGF0aHMgDQogICAgDQogICBZYW5nLCBldCBh bC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjhdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAg ICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgIFRoZXJlIGFyZSB0 d28gYmFzaWMgd2F5cyB0byBleHByZXNzIHRoZSBkaWZmZXJlbnRpYXRpb24gaW4gcGFja2V0IA0K ICAgICAgdHJlYXRtZW50IHdpdGhpbiBhbiBGRSwgb25lIHJlcHJlc2VudHMgdGhlIGRhdGFwYXRo IGRpcmVjdGx5IGFuZCANCiAgICAgIGdyYXBoaWNhbGx5ICh0b3BvbG9naWNhbCBhcHByb2FjaCkg YW5kIHRoZSBvdGhlciB1dGlsaXplcyBtZXRhZGF0YSANCiAgICAgICh0aGUgZW5jb2RlZCBzdGF0 ZSBhcHByb2FjaCkuIA0KICAgICAgIA0KICAgICAgICAuIFRvcG9sb2dpY2FsIEFwcHJvYWNoIA0K ICAgICAgIA0KICAgICAgICBVc2luZyB0aGlzIGFwcHJvYWNoLCBkaWZmZXJlbnRpYWwgcGFja2V0 IHRyZWF0bWVudCBpcyBleHByZXNzZWQgDQogICAgICAgIGJ5IHNwbGl0dGluZyB0aGUgTEZCIHRv cG9sb2d5IGludG8gYWx0ZXJuYXRpdmUgcGF0aHMuICBJbiBvdGhlciANCiAgICAgICAgd29yZHMs IGlmIHRoZSByZXN1bHQgb2YgYW4gTEZCIG11c3QgY29udHJvbCBob3cgdGhlIHBhY2tldCBpcyAN CiAgICAgICAgZnVydGhlciBwcm9jZXNzZWQsIHRoZW4gc3VjaCBhbiBMRkIgd2lsbCBoYXZlIHNl cGFyYXRlIG91dHB1dCANCiAgICAgICAgcG9ydHMsIG9uZSBmb3IgZWFjaCBhbHRlcm5hdGl2ZSB0 cmVhdG1lbnQsIGNvbm5lY3RlZCB0byANCiAgICAgICAgc2VwYXJhdGUgc3ViLWdyYXBocywgZWFj aCBleHByZXNzaW5nIHRoZSByZXNwZWN0aXZlIHRyZWF0bWVudCANCiAgICAgICAgZG93bnN0cmVh bS4gDQogICAgICAgDQogICAgICAgIC4gRW5jb2RlZCBTdGF0ZSBBcHByb2FjaCANCiAgICAgICAN CiAgICAgICAgQW4gYWx0ZXJuYXRlIHdheSBvZiBleHByZXNzaW5nIGRpZmZlcmVudGlhbCB0cmVh dG1lbnQgaXMgYnkgDQogICAgICAgIHVzaW5nIG1ldGFkYXRhLiAgVGhlIHJlc3VsdCBvZiB0aGUg b3BlcmF0aW9uIG9mIGFuIExGQiBjYW4gYmUgDQogICAgICAgIGVuY29kZWQgaW4gYSBtZXRhZGF0 YSwgd2hpY2ggaXMgcGFzc2VkIGFsb25nIHdpdGggdGhlIHBhY2tldCB0byANCiAgICAgICAgZG93 bnN0cmVhbSBMRkJzLiAgQSBkb3duc3RyZWFtIExGQiwgaW4gdHVybiwgY2FuIHVzZSB0aGUgDQog ICAgICAgIG1ldGFkYXRhIGFuZCBpdHMgdmFsdWUgKGUuZy4sIGFzIGFuIGluZGV4IGludG8gc29t ZSB0YWJsZSkgdG8gDQogICAgICAgIGRldGVybWluZSBob3cgdG8gdHJlYXQgdGhlIHBhY2tldC4g DQogICAgICAgDQogICAgICBUaGVvcmV0aWNhbGx5LCBlaXRoZXIgYXBwcm9hY2ggY291bGQgc3Vi c3RpdHV0ZSBmb3IgdGhlIG90aGVyLCBzbyANCiAgICAgIG9uZSBjb3VsZCBjb25zaWRlciB1c2lu ZyBhIHNpbmdsZSBwdXJlIGFwcHJvYWNoIHRvIGRlc2NyaWJlIGFsbCANCiAgICAgIGRhdGFwYXRo cyBpbiBhbiBGRS4gIEhvd2V2ZXIsIG5laXRoZXIgbW9kZWwgYnkgaXRzZWxmIHJlc3VsdHMgaW4g DQogICAgICB0aGUgYmVzdCByZXByZXNlbnRhdGlvbiBmb3IgYWxsIHByYWN0aWNhbGx5IHJlbGV2 YW50IGNhc2VzLiAgRm9yIGEgDQogICAgICBnaXZlbiBGRSB3aXRoIGNlcnRhaW4gbG9naWNhbCBk YXRhcGF0aHMsIGFwcGx5aW5nIHRoZSB0d28gDQogICAgICBkaWZmZXJlbnQgbW9kZWxpbmcgYXBw cm9hY2hlcyB3aWxsIHJlc3VsdCBpbiB2ZXJ5IGRpZmZlcmVudCANCiAgICAgIGxvb2tpbmcgTEZC IHRvcG9sb2d5IGdyYXBocy4gIEEgbW9kZWwgdXNpbmcgb25seSB0aGUgdG9wb2xvZ2ljYWwgDQog ICAgICBhcHByb2FjaCBtYXkgcmVxdWlyZSBhIHZlcnkgbGFyZ2UgZ3JhcGggd2l0aCBtYW55IGxp bmtzIG9yIHBhdGhzLCANCiAgICAgIGFuZCBub2RlcyAoaS5lLiwgTEZCIGluc3RhbmNlcykgdG8g ZXhwcmVzcyBhbGwgYWx0ZXJuYXRpdmUgDQogICAgICBkYXRhcGF0aHMuICBPbiB0aGUgb3RoZXIg aGFuZCwgYSBtb2RlbCB1c2luZyBvbmx5IHRoZSBlbmNvZGVkIA0KICAgICAgc3RhdGUgbW9kZWwg d291bGQgYmUgcmVzdHJpY3RlZCB0byBhIHN0cmluZyBvZiBMRkJzLCB3aGljaCBpcyBub3QgDQog ICAgICBhbiBpbnR1aXRpdmUgd2F5IHRvIGRlc2NyaWJlIGRpZmZlcmVudCBkYXRhcGF0aHMgKHN1 Y2ggYXMgTVBMUyBhbmQgDQogICAgICBJUHY0KS4gIFRoZXJlZm9yZSwgYSBtaXggb2YgdGhlc2Ug dHdvIGFwcHJvYWNoZXMgd2lsbCBsaWtlbHkgYmUgDQogICAgICB1c2VkIGZvciBhIHByYWN0aWNh bCBtb2RlbC4gIEluIGZhY3QsIGFzIHdlIGlsbHVzdHJhdGUgYmVsb3csIHRoZSANCiAgICAgIHR3 byBhcHByb2FjaGVzIGNhbiBiZSBtaXhlZCBldmVuIHdpdGhpbiB0aGUgc2FtZSBMRkIuICANCiAg ICAgICANCiAgICAgIFVzaW5nIGEgc2ltcGxlIGV4YW1wbGUgb2YgYSBjbGFzc2lmaWVyIHdpdGgg TiBjbGFzc2lmaWNhdGlvbiANCiAgICAgIG91dHB1dHMgZm9sbG93ZWQgYnkgb3RoZXIgTEZCcywg RmlndXJlIDUoYSkgc2hvd3Mgd2hhdCB0aGUgTEZCIA0KICAgICAgdG9wb2xvZ3kgbG9va3MgbGlr ZSB3aGVuIHVzaW5nIHRoZSBwdXJlIHRvcG9sb2dpY2FsIGFwcHJvYWNoLiAgDQogICAgICBFYWNo IG91dHB1dCBmcm9tIHRoZSBjbGFzc2lmaWVyIGdvZXMgdG8gb25lIG9mIHRoZSBOIExGQnMgd2hl cmUgbm8gDQogICAgICBtZXRhZGF0YSBpcyBuZWVkZWQuICBUaGUgdG9wb2xvZ2ljYWwgYXBwcm9h Y2ggaXMgc2ltcGxlLCANCiAgICAgIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgZ3JhcGhpY2FsbHkgaW50 dWl0aXZlLiAgSG93ZXZlciwgaWYgTiBpcyBsYXJnZSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyOV0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgYW5kIHRoZSBOIG5vZGVzIGZvbGxvd2lu ZyB0aGUgY2xhc3NpZmllciAoTEZCIzEsIExGQiMyLCAuLi4sIA0KICAgICAgTEZCI04pIGFsbCBi ZWxvbmcgdG8gdGhlIHNhbWUgTEZCIHR5cGUgKGUuZy4sIG1ldGVyKSwgYnV0IGVhY2ggaGFzIA0K ICAgICAgaXRzIG93biBpbmRlcGVuZGVudCBhdHRyaWJ1dGVzLCB0aGUgZW5jb2RlZCBzdGF0ZSBh cHByb2FjaCBnaXZlcyBhIA0KICAgICAgbXVjaCBzaW1wbGVyIHRvcG9sb2d5IHJlcHJlc2VudGF0 aW9uLCBhcyBzaG93biBpbiBGaWd1cmUgNShiKS4gIA0KICAgICAgVGhlIGVuY29kZWQgc3RhdGUg YXBwcm9hY2ggcmVxdWlyZXMgdGhhdCBhIHRhYmxlIG9mIE4gcm93cyBvZiANCiAgICAgIG1ldGVy IGF0dHJpYnV0ZXMgaXMgcHJvdmlkZWQgaW4gdGhlIE1ldGVyIG5vZGUgaXRzZWxmLCB3aXRoIGVh Y2ggDQogICAgICByb3cgcmVwcmVzZW50aW5nIHRoZSBhdHRyaWJ1dGVzIGZvciBvbmUgbWV0ZXIg aW5zdGFuY2UuICBBIA0KICAgICAgbWV0YWRhdGEgTSBpcyBhbHNvIG5lZWRlZCB0byBwYXNzIGFs b25nIHdpdGggdGhlIHBhY2tldCBQIGZyb20gdGhlIA0KICAgICAgY2xhc3NpZmllciB0byB0aGUg bWV0ZXIsIHNvIHRoYXQgdGhlIG1ldGVyIGNhbiB1c2UgTSBhcyBhIGxvb2stdXAgDQogICAgICBr ZXkgKGluZGV4KSB0byBmaW5kIHRoZSBjb3JyZXNwb25kaW5nIHJvdyBvZiB0aGUgYXR0cmlidXRl cyB0aGF0IA0KICAgICAgc2hvdWxkIGJlIHVzZWQgZm9yIGFueSBwYXJ0aWN1bGFyIHBhY2tldCBQ LiANCiAgICAgICANCiAgICAgIFdoYXQgaWYgdGhvc2UgTiBub2RlcyAoTEZCIzEsIExGQiMyLCAu Li4sIExGQiNOKSBhcmUgbm90IG9mIHRoZSANCiAgICAgIHNhbWUgdHlwZT8gRm9yIGV4YW1wbGUs IGlmIExGQiMxIGlzIGEgcXVldWUgd2hpbGUgdGhlIHJlc3QgYXJlIGFsbCANCiAgICAgIG1ldGVy cywgd2hhdCBpcyB0aGUgYmVzdCB3YXkgdG8gcmVwcmVzZW50IHN1Y2ggZGF0YXBhdGhzPyAgV2hp bGUgDQogICAgICBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0byB1c2UgZWl0aGVyIHRoZSBwdXJlIHRv cG9sb2dpY2FsIGFwcHJvYWNoIA0KICAgICAgb3IgdGhlIHB1cmUgZW5jb2RlZCBzdGF0ZSBhcHBy b2FjaCwgdGhlIG5hdHVyYWwgY29tYmluYXRpb24gb2YgdGhlIA0KICAgICAgdHdvIGFwcGVhcnMg dG8gYmUgdGhlIGJlc3Qgb3B0aW9uLiBGaWd1cmUgNShjKSBkZXBpY3RzIHR3byANCiAgICAgIGRp ZmZlcmVudCBmdW5jdGlvbmFsIGRhdGFwYXRocyB1c2luZyB0aGUgdG9wb2xvZ2ljYWwgYXBwcm9h Y2ggDQogICAgICB3aGlsZSBsZWF2aW5nIHRoZSBOLTEgbWV0ZXIgaW5zdGFuY2VzIGRpc3Rpbmd1 aXNoZWQgYnkgbWV0YWRhdGEgDQogICAgICBvbmx5LCBhcyBzaG93biBpbiBGaWd1cmUgNShjKS4g IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t KyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAgICAgICB8ICAgTEZCIzEg IHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0+fChBdHRyaWIt MSl8IA0KICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICB8ICAgICAgICAgICstLS0tLS0t LS0tKyANCiAgICAgICAgICAgfCAgICAgICAgICAgIDF8LS0tLS0tKyAgIFAgICAgICArLS0tLS0t LS0tLSsgDQogICAgICAgICAgIHwgICAgICAgICAgICAyfC0tLS0tLS0tLS0tLS0tLS0+fCAgIExG QiMyICB8IA0KICAgICAgICAgICB8IGNsYXNzaWZpZXIgM3wgICAgICAgICAgICAgICAgIHwoQXR0 cmliLTIpfCANCiAgICAgICAgICAgfCAgICAgICAgICAuLi58Li4uICAgICAgICAgICAgICArLS0t LS0tLS0tLSsgDQogICAgICAgICAgIHwgICAgICAgICAgICBOfC0tLS0tLSsgICAgICAgICAgLi4u IA0KICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICB8ICAgUCAgICAgICstLS0tLS0tLS0t KyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLT58ICAgTEZCI04g IHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfChBdHRyaWIt Til8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgNShhKSBVc2luZyBwdXJlIHRvcG9sb2dpY2FsIGFwcHJvYWNoICANCiAgICAgICANCiAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgDQog ICAgICAgICAgIHwgICAgICAgICAgICAxfCAgICAgICAgICAgICAgICAgfCAgIE1ldGVyICAgICB8 IA0KICAgICAgICAgICB8ICAgICAgICAgICAgMnwgICAoUCwgTSkgICAgICAgIHwgKEF0dHJpYi0x KSAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAgIDN8LS0tLS0tLS0tLS0tLS0tLT58IChBdHRy aWItMikgIHwgDQogICAgICAgICAgIHwgICAgICAgICAgLi4ufCAgICAgICAgICAgICAgICAgfCAg IC4uLiAgICAgICB8IA0KICAgICAgICAgICB8ICAgICAgICAgICAgTnwgICAgICAgICAgICAgICAg IHwgKEF0dHJpYi1OKSAgfCANCiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLSsgDQogICAgICAgDQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwu ICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDMw XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAg ICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICA1KGIpIFVzaW5nIHB1cmUg ZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCB0byByZXByZXNlbnQgdGhlIExGQiANCiAgICAgICAgICAg dG9wb2xvZ3kgaW4gNShhKSwgaWYgTEZCIzEsIExGQiMyLCAuLi4sIGFuZCBMRkIjTiBhcmUgb2Yg dGhlIA0KICAgICAgICAgICAgICAgICAgICAgICAgIHNhbWUgdHlwZSAoZS5nLiwgbWV0ZXIpLiAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0rIA0KICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgKFAsIE0pICAgICAgIHwg cXVldWUgICAgICAgfCANCiAgICAgICAgICAgfCAgICAgICAgICAgIDF8LS0tLS0tLS0tLS0tLT58 IChBdHRyaWItMSkgIHwgDQogICAgICAgICAgIHwgICAgICAgICAgICAyfCAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAgICB8ICAgICAgICAgICAgM3wgKFAsIE0pICAgICAg ICstLS0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgfCAgICAgICAgICAuLi58LS0tLS0tLS0tLS0t LT58ICAgTWV0ZXIgICAgIHwgICANCiAgICAgICAgICAgfCAgICAgICAgICAgIE58ICAgICAgICAg ICAgICB8IChBdHRyaWItMikgIHwgDQogICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAg ICAgICAgfCAgIC4uLiAgICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgKEF0dHJpYi1OKSAgfCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAgICA1KGMpIFVzaW5n IGEgY29tYmluYXRpb24gb2YgdGhlIHR3bywgaWYgTEZCIzEsIExGQiMyLCAuLi4sIA0KICAgICAg ICAgICAgIGFuZCBMRkIjTiBhcmUgb2YgZGlmZmVyZW50IHR5cGVzIChlLmcuLCBxdWV1ZSBhbmQg bWV0ZXIpLiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICBGaWd1cmUgNS4gQW4gZXhhbXBsZSBvZiBob3cgdG8gbW9kZWwgRkUgZGF0 YXBhdGhzIA0KICAgIA0KICAgICAgRnJvbSB0aGlzIGV4YW1wbGUsIHdlIGRlbW9uc3RyYXRlIHRo YXQgZWFjaCBhcHByb2FjaCBoYXMgYSANCiAgICAgIGRpc3RpbmN0IGFkdmFudGFnZSBkZXBlbmRp bmcgb24gdGhlIHNpdHVhdGlvbi4gIFVzaW5nIHRoZSBlbmNvZGVkIA0KICAgICAgc3RhdGUgYXBw cm9hY2gsIGZld2VyIGNvbm5lY3Rpb25zIGFyZSB0eXBpY2FsbHkgbmVlZGVkIGJldHdlZW4gYSAN CiAgICAgIGZhbi1vdXQgbm9kZSBhbmQgaXRzIG5leHQgTEZCIGluc3RhbmNlcyBvZiB0aGUgc2Ft ZSB0eXBlIGJlY2F1c2UgDQogICAgICBlYWNoIHBhY2tldCBjYXJyaWVzIG1ldGFkYXRhIHRoZSBm b2xsb3dpbmcgbm9kZXMgY2FuIGludGVycHJldCBhbmQgDQogICAgICBoZW5jZSBpbnZva2UgYSBk aWZmZXJlbnQgcGFja2V0IHRyZWF0bWVudC4gIEZvciB0aG9zZSBjYXNlcywgYSANCiAgICAgIHB1 cmUgdG9wb2xvZ2ljYWwgYXBwcm9hY2ggZm9yY2VzIG9uZSB0byBidWlsZCBlbGFib3JhdGUgZ3Jh cGhzIA0KICAgICAgd2l0aCBtYW55IG1vcmUgY29ubmVjdGlvbnMgYW5kIG9mdGVuIHJlc3VsdHMg aW4gYW4gdW53aWVsZHkgZ3JhcGguICANCiAgICAgIE9uIHRoZSBvdGhlciBoYW5kLCBhIHRvcG9s b2dpY2FsIGFwcHJvYWNoIGlzIHRoZSBtb3N0IGludHVpdGl2ZSANCiAgICAgIGZvciByZXByZXNl bnRpbmcgZnVuY3Rpb25hbGx5IGRpZmZlcmVudCBkYXRhcGF0aHMuIA0KICAgICAgIA0KICAgICAg Rm9yIGNvbXBsZXggdG9wb2xvZ2llcywgYSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvIGlzIHRoZSBt b3N0IA0KICAgICAgZmxleGlibGUuICBBIGdlbmVyYWwgZGVzaWduIGd1aWRlbGluZSBpcyBwcm92 aWRlZCB0byBpbmRpY2F0ZSANCiAgICAgIHdoaWNoIGFwcHJvYWNoIGlzIGJlc3QgdXNlZCBmb3Ig YSBwYXJ0aWN1bGFyIHNpdHVhdGlvbi4gIFRoZSANCiAgICAgIHRvcG9sb2dpY2FsIGFwcHJvYWNo IHNob3VsZCBwcmltYXJpbHkgYmUgdXNlZCB3aGVuIHRoZSBwYWNrZXQgDQogICAgICBkYXRhcGF0 aCBmb3JrcyB0byBkaXN0aW5jdCBMRkIgY2xhc3NlcyAobm90IGp1c3QgZGlzdGluY3QgDQogICAg ICBwYXJhbWV0ZXJpemF0aW9ucyBvZiB0aGUgc2FtZSBMRkIgY2xhc3MpLCBhbmQgd2hlbiB0aGUg ZmFuLW91dHMgZG8gDQogICAgICBub3QgcmVxdWlyZSBjaGFuZ2VzLCBzdWNoIGFzIGFkZGluZy9y ZW1vdmluZyBMRkIgb3V0cHV0cywgb3IgDQogICAgICByZXF1aXJlIG9ubHkgdmVyeSBpbmZyZXF1 ZW50IGNoYW5nZXMuICBDb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIA0KICAgICAgdGhhdCBuZWVk cyB0byBjaGFuZ2UgZnJlcXVlbnRseSBzaG91bGQgYmUgZXhwcmVzc2VkIGJ5IHVzaW5nIHRoZSAN CiAgICAgIGludGVybmFsIGF0dHJpYnV0ZXMgb2Ygb25lIG9yIG1vcmUgTEZCcyAoYW5kIGhlbmNl IHVzaW5nIHRoZSANCiAgICAgIGVuY29kZWQgc3RhdGUgYXBwcm9hY2gpLiANCiAgICAgICANCg0K DQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDMxXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg IEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgICstLS0tLS0tLS0t KyAgViAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgKy0tLS0tLSsgICAgICAgIHwgDQogICAg ICAgICAgIHwgICAgICAgICAgfCAgfCAgICAgIHwgICAgICAgICAgfGlmIElQLWluLUlQfCAgICAg IHwgICAgICAgIHwgDQogICAgICAtLS0tPnwgaW5ncmVzcyAgfC0+Ky0tLS0tPnxjbGFzc2lmaWVy fC0tLS0tLS0tLS0+fERlY2FwLnwtLS0tPi0tLSsgDQogICAgICAgICAgIHwgcG9ydHMgICAgfCAg ICAgICAgIHwgICAgICAgICAgfC0tLS0rICAgICAgfCAgICAgIHwgDQogICAgICAgICAgICstLS0t LS0tLS0tKyAgICAgICAgICstLS0tLS0tLS0tKyAgICB8b3RoZXJzKy0tLS0tLSsgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgViANCiAgICAgICAgICAgKGEpICBU aGUgTEZCIHRvcG9sb2d5IHdpdGggYSBsb2dpY2FsIGxvb3AgDQogICAgDQogICAgICAgICAgKy0t LS0tLS0rICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICstLS0tLS0rICAgKy0tLS0tLS0tLS0t KyANCiAgICAgICAgICB8ICAgICAgIHwgICB8ICAgICAgICAgICB8aWYgSVAtaW4tSVAgfCAgICAg IHwgICB8ICAgICAgICAgICB8IA0KICAgICAgLS0tPnxpbmdyZXNzfC0tPnxjbGFzc2lmaWVyMXwt LS0tLS0tLS0tLT58RGVjYXAufC0tPitjbGFzc2lmaWVyMnwtDQogICA+IA0KICAgICAgICAgIHwg cG9ydHMgfCAgIHwgICAgICAgICAgIHwtLS0tKyAgICAgICB8ICAgICAgfCAgIHwgICAgICAgICAg IHwgDQogICAgICAgICAgKy0tLS0tLS0rICAgKy0tLS0tLS0tLS0tKyAgICB8b3RoZXJzICstLS0t LS0rICAgKy0tLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWIA0KICAgICAg ICAgICAoYikgIFRoZSBMRkIgdG9wb2xvZ3kgd2l0aG91dCB0aGUgbG9vcCB1dGlsaXppbmcgdHdv IA0KICAgICAgICAgICAgICAgIGluZGVwZW5kZW50IGNsYXNzaWZpZXIgaW5zdGFuY2VzLiANCiAg ICAgICANCiAgICAgICAgICAgICAgICAgICBGaWd1cmUgNi4gQW4gTEZCIHRvcG9sb2d5IGV4YW1w bGUuIA0KICAgIA0KICAgICAgSXQgaXMgaW1wb3J0YW50IHRvIHBvaW50IG91dCB0aGF0IHRoZSBM RkIgdG9wb2xvZ3kgZGVzY3JpYmVkIGhlcmUgDQogICAgICBpcyB0aGUgbG9naWNhbCB0b3BvbG9n eSwgbm90IHRoZSBwaHlzaWNhbCB0b3BvbG9neSBvZiBob3cgdGhlIEZFIA0KICAgICAgaGFyZHdh cmUgaXMgYWN0dWFsbHkgbGFpZCBvdXQuICBOZXZlcnRoZWxlc3MsIHRoZSBhY3R1YWwgDQogICAg ICBpbXBsZW1lbnRhdGlvbiBtYXkgc3RpbGwgaW5mbHVlbmNlIGhvdyB0aGUgZnVuY3Rpb25hbGl0 eSBpcyBtYXBwZWQgDQogICAgICB0byB0aGUgTEZCIHRvcG9sb2d5LiAgRmlndXJlIDYgc2hvd3Mg b25lIHNpbXBsZSBGRSBleGFtcGxlLiAgSW4gDQogICAgICB0aGlzIGV4YW1wbGUsIGFuIElQLWlu LUlQIHBhY2tldCBmcm9tIGFuIElQU2VjIGFwcGxpY2F0aW9uIGxpa2UgDQogICAgICBWUE4gbWF5 IGdvIHRvIHRoZSBjbGFzc2lmaWVyIGZpcnN0IGFuZCBoYXZlIHRoZSBjbGFzc2lmaWNhdGlvbiAN CiAgICAgIGRvbmUgYmFzZWQgb24gdGhlIG91dGVyIElQIGhlYWRlcjsgdXBvbiBiZWluZyBjbGFz c2lmaWVkIGFzIGFuIElQLQ0KICAgICAgaW4tSVAgcGFja2V0LCB0aGUgcGFja2V0IGlzIHRoZW4g c2VudCB0byBhIGRlY2Fwc3VsYXRvciB0byBzdHJpcCANCiAgICAgIG9mZiB0aGUgb3V0ZXIgSVAg aGVhZGVyLCBmb2xsb3dlZCBieSBhIGNsYXNzaWZpZXIgYWdhaW4gdG8gcGVyZm9ybSANCiAgICAg IGNsYXNzaWZpY2F0aW9uIG9uIHRoZSBpbm5lciBJUCBoZWFkZXIuIElmIHRoZSBzYW1lIGNsYXNz aWZpZXIgDQogICAgICBoYXJkd2FyZSBvciBzb2Z0d2FyZSBpcyB1c2VkIGZvciBib3RoIG91dGVy IGFuZCBpbm5lciBJUCBoZWFkZXIgDQogICAgICBjbGFzc2lmaWNhdGlvbiB3aXRoIHRoZSBzYW1l IHNldCBvZiBmaWx0ZXJpbmcgcnVsZXMsIGEgbG9naWNhbCANCiAgICAgIGxvb3AgaXMgbmF0dXJh bGx5IHByZXNlbnQgaW4gdGhlIExGQiB0b3BvbG9neSwgYXMgc2hvd24gaW4gRmlndXJlIA0KICAg ICAgNihhKS4gIEhvd2V2ZXIsIGlmIHRoZSBjbGFzc2lmaWNhdGlvbiBpcyBpbXBsZW1lbnRlZCBi eSB0d28gDQogICAgICBkaWZmZXJlbnQgcGllY2VzIG9mIGhhcmR3YXJlIG9yIHNvZnR3YXJlIHdp dGggZGlmZmVyZW50IGZpbHRlcnMgDQogICAgICAoaS5lLiwgb25lIHNldCBvZiBmaWx0ZXJzIGZv ciB0aGUgb3V0ZXIgSVAgaGVhZGVyIGFuZCBhbm90aGVyIHNldCANCiAgICAgIGZvciB0aGUgaW5u ZXIgSVAgaGVhZGVyKSwgdGhlbiBpdCBpcyBtb3JlIG5hdHVyYWwgdG8gbW9kZWwgdGhlbSBhcyAN CiAgICAgIHR3byBkaWZmZXJlbnQgaW5zdGFuY2VzIG9mIGNsYXNzaWZpZXIgTEZCLCBhcyBzaG93 biBpbiBGaWd1cmUgDQogICAgICA2KGIpLiANCiAgICANCiAgICAgIFRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIExGQiBjbGFzcywgDQogICAgICBl YWNoIExGQiBpbnN0YW5jZSBoYXMgaXRzIG93biBMRkIgaW5zdGFuY2UgSUQuICBPbmUgd2F5IHRv IGVuY29kZSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzMl0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAg ICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAg IA0KICAgICAgdGhlIExGQiBpbnN0YW5jZSBJRCBpcyB0byBlbmNvZGUgaXQgYXMgeC55IHdoZXJl IHggaXMgdGhlIExGQiANCiAgICAgIGNsYXNzIElEIGFuZCB5IGlzIHRoZSBpbnN0YW5jZSBJRCB3 aXRoaW4gZWFjaCBMRkIgY2xhc3MuIA0KICAgICAgIA0KICAgMy4zLjIuIENvbmZpZ3VyaW5nIHRo ZSBMRkIgVG9wb2xvZ3kgIA0KICAgICAgIA0KICAgICAgV2hpbGUgdGhlcmUgaXMgbGl0dGxlIGRv dWJ0IHRoYXQgYW4gaW5kaXZpZHVhbCBMRkIgbXVzdCBiZSANCiAgICAgIGNvbmZpZ3VyYWJsZSwg dGhlIGNvbmZpZ3VyYWJpbGl0eSBxdWVzdGlvbiBpcyBtb3JlIGNvbXBsaWNhdGVkIGZvciANCiAg ICAgIExGQiB0b3BvbG9neS4gIFNpbmNlIHRoZSBMRkIgdG9wb2xvZ3kgaXMgcmVhbGx5IHRoZSBn cmFwaGljIA0KICAgICAgcmVwcmVzZW50YXRpb24gb2YgdGhlIGRhdGFwYXRocyB3aXRoaW4gYW4g RkUsIGNvbmZpZ3VyaW5nIHRoZSBMRkIgDQogICAgICB0b3BvbG9neSBtZWFucyBkeW5hbWljYWxs eSBjaGFuZ2luZyB0aGUgZGF0YXBhdGhzLCBpbmNsdWRpbmcgDQogICAgICBjaGFuZ2luZyB0aGUg TEZCcyBhbG9uZyB0aGUgZGF0YXBhdGhzIG9uIGFuIEZFIChlLmcuLCBjcmVhdGluZywgDQogICAg ICBpbnN0YW50aWF0aW5nIG9yIGRlbGV0aW5nIExGQnMpIGFuZCBzZXR0aW5nIHVwIG9yIGRlbGV0 aW5nIA0KICAgICAgaW50ZXJjb25uZWN0aW9ucyBiZXR3ZWVuIG91dHB1dHMgb2YgdXBzdHJlYW0g TEZCcyB0byBpbnB1dHMgb2YgDQogICAgICBkb3duc3RyZWFtIExGQnMuICAgDQogICAgICAgDQog ICAgICBXaHkgd291bGQgdGhlIGRhdGFwYXRocyBvbiBhbiBGRSBldmVyIGNoYW5nZSBkeW5hbWlj YWxseT8gIFRoZSANCiAgICAgIGRhdGFwYXRocyBvbiBhbiBGRSBhcmUgc2V0IHVwIGJ5IHRoZSBD RSB0byBwcm92aWRlIGNlcnRhaW4gZGF0YSANCiAgICAgIHBsYW5lIHNlcnZpY2VzIChlLmcuLCBE aWZmU2VydiwgVlBOLCBldGMuKSB0byB0aGUgTmV0d29yayANCiAgICAgIEVsZW1lbnQncyAoTkUp IGN1c3RvbWVycy4gIFRoZSBwdXJwb3NlIG9mIHJlY29uZmlndXJpbmcgdGhlIA0KICAgICAgZGF0 YXBhdGhzIGlzIHRvIGVuYWJsZSB0aGUgQ0UgdG8gY3VzdG9taXplIHRoZSBzZXJ2aWNlcyB0aGUg TkUgaXMgDQogICAgICBkZWxpdmVyaW5nIGF0IHJ1biB0aW1lLiAgVGhlIENFIG5lZWRzIHRvIGNo YW5nZSB0aGUgZGF0YXBhdGhzIHdoZW4gDQogICAgICB0aGUgc2VydmljZSByZXF1aXJlbWVudHMg Y2hhbmdlLCBzdWNoIGFzIGFkZGluZyBhIG5ldyBjdXN0b21lciBvciANCiAgICAgIHdoZW4gYW4g ZXhpc3RpbmcgY3VzdG9tZXIgY2hhbmdlcyB0aGVpciBzZXJ2aWNlLiAgSG93ZXZlciwgbm90ZSAN CiAgICAgIHRoYXQgbm90IGFsbCBkYXRhcGF0aCBjaGFuZ2VzIHJlc3VsdCBpbiBjaGFuZ2VzIGlu IHRoZSBMRkIgDQogICAgICB0b3BvbG9neSBncmFwaC4gQ2hhbmdlcyBpbiB0aGUgZ3JhcGggYXJl IGRlcGVuZGVudCBvbiB0aGUgYXBwcm9hY2ggDQogICAgICB1c2VkIHRvIG1hcCB0aGUgZGF0YXBh dGhzIGludG8gTEZCIHRvcG9sb2d5LiAgQXMgZGlzY3Vzc2VkIGluIA0KICAgICAgMy4zLjEsIHRo ZSB0b3BvbG9naWNhbCBhcHByb2FjaCBhbmQgZW5jb2RlZCBzdGF0ZSBhcHByb2FjaCBjYW4gDQog ICAgICByZXN1bHQgaW4gdmVyeSBkaWZmZXJlbnQgbG9va2luZyBMRkIgdG9wb2xvZ2llcyBmb3Ig dGhlIHNhbWUgDQogICAgICBkYXRhcGF0aHMuICBJbiBnZW5lcmFsLCBhbiBMRkIgdG9wb2xvZ3kg YmFzZWQgb24gYSBwdXJlIA0KICAgICAgdG9wb2xvZ2ljYWwgYXBwcm9hY2ggaXMgbGlrZWx5IHRv IGV4cGVyaWVuY2UgbW9yZSBmcmVxdWVudCANCiAgICAgIHRvcG9sb2d5IHJlY29uZmlndXJhdGlv biB0aGFuIG9uZSBiYXNlZCBvbiBhbiBlbmNvZGVkIHN0YXRlIA0KICAgICAgYXBwcm9hY2guICBI b3dldmVyLCBldmVuIGFuIExGQiB0b3BvbG9neSBiYXNlZCBlbnRpcmVseSBvbiBhbiANCiAgICAg IGVuY29kZWQgc3RhdGUgYXBwcm9hY2ggbWF5IGhhdmUgdG8gY2hhbmdlIHRoZSB0b3BvbG9neSBh dCB0aW1lcywgDQogICAgICBmb3IgZXhhbXBsZSwgdG8gYnlwYXNzIHNvbWUgTEZCcyBvciBpbnNl cnQgbmV3IExGQnMuICBTaW5jZSBhIG1peCANCiAgICAgIG9mIHRoZXNlIHR3byBhcHByb2FjaGVz IGlzIHVzZWQgdG8gbW9kZWwgdGhlIGRhdGFwYXRocywgTEZCIA0KICAgICAgdG9wb2xvZ3kgcmVj b25maWd1cmF0aW9uIGlzIGNvbnNpZGVyZWQgYW4gaW1wb3J0YW50IGFzcGVjdCBvZiB0aGUgDQog ICAgICBGRSBtb2RlbC4gIA0KICAgICAgIA0KICAgICAgV2Ugd2FudCB0byBwb2ludCBvdXQgdGhh dCBhbGxvd2luZyBhIGNvbmZpZ3VyYWJsZSBMRkIgdG9wb2xvZ3kgaW4gDQogICAgICB0aGUgRkUg bW9kZWwgZG9lcyBub3QgbWFuZGF0ZSB0aGF0IGFsbCBGRXMgbXVzdCBoYXZlIHRoaXMgDQogICAg ICBjYXBhYmlsaXR5LiAgRXZlbiBpZiBhbiBGRSBzdXBwb3J0cyBjb25maWd1cmFibGUgTEZCIHRv cG9sb2d5LCB0aGUgDQogICAgICBGRSBtYXkgaW1wb3NlIGxpbWl0YXRpb25zIG9uIHdoYXQgY2Fu IGFjdHVhbGx5IGJlIGNvbmZpZ3VyZWQuICANCiAgICAgIFBlcmZvcm1hbmNlLW9wdGltaXplZCBo YXJkd2FyZSBpbXBsZW1lbnRhdGlvbnMgbWF5IGhhdmUgemVybyBvciANCiAgICAgIHZlcnkgbGlt aXRlZCBjb25maWd1cmFiaWxpdHksIHdoaWxlIEZFIGltcGxlbWVudGF0aW9ucyBydW5uaW5nIG9u IA0KICAgICAgbmV0d29yayBwcm9jZXNzb3JzIG1heSBwcm92aWRlIG1vcmUgZmxleGliaWxpdHkg YW5kIA0KICAgICAgY29uZmlndXJhYmlsaXR5LiAgSXQgaXMgZW50aXJlbHkgdXAgdG8gdGhlIEZF IGRlc2lnbmVycyB0byBkZWNpZGUgDQogICAgICB3aGV0aGVyIG9yIG5vdCB0aGUgRkUgYWN0dWFs bHkgaW1wbGVtZW50cyByZWNvbmZpZ3VyYXRpb24gYW5kIGlmIA0KICAgIA0KICAgWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDMzXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAg ICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBzbywgaG93IG11Y2guICBXaGV0 aGVyIGEgc2ltcGxlIHJ1bnRpbWUgc3dpdGNoIGlzIHVzZWQgdG8gZW5hYmxlIA0KICAgICAgb3Ig ZGlzYWJsZSAoaS5lLiwgYnlwYXNzKSBjZXJ0YWluIExGQnMsIG9yIG1vcmUgZmxleGlibGUgc29m dHdhcmUgDQogICAgICByZWNvbmZpZ3VyYXRpb24gaXMgdXNlZCwgaXMgaW1wbGVtZW50YXRpb24g ZGV0YWlsIGludGVybmFsIHRvIHRoZSANCiAgICAgIEZFIGFuZCBvdXRzaWRlIG9mIHRoZSBzY29w ZSBvZiBGRSBtb2RlbC4gIEluIGVpdGhlciBjYXNlLCB0aGUgDQogICAgICBDRShzKSBtdXN0IGJl IGFibGUgdG8gbGVhcm4gdGhlIEZFJ3MgY29uZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMuICANCiAg ICAgIFRoZXJlZm9yZSwgdGhlIEZFIG1vZGVsIG11c3QgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3Ig ZGVzY3JpYmluZyANCiAgICAgIHRoZSBMRkIgdG9wb2xvZ3kgY29uZmlndXJhdGlvbiBjYXBhYmls aXRpZXMgb2YgYW4gRkUuICBUaGVzZSANCiAgICAgIGNhcGFiaWxpdGllcyBtYXkgaW5jbHVkZSAo c2VlIFNlY3Rpb24gNSBmb3IgZnVsbCBkZXRhaWxzKTogDQogICAgICAgIC4gV2hpY2ggTEZCIGNs YXNzZXMgdGhlIEZFIGNhbiBpbnN0YW50aWF0ZSANCiAgICAgICAgLiBNYXhpbXVtIG51bWJlciBv ZiBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgTEZCIGNsYXNzIHRoYXQgY2FuIGJlIA0KICAgICAgICAg ICBjcmVhdGVkIA0KICAgICAgICAuIEFueSB0b3BvbG9naWNhbCBsaW1pdGF0aW9ucywgRm9yIGV4 YW1wbGU6IA0KICAgICAgICAgICAgIG8gVGhlIG1heGltdW0gbnVtYmVyIG9mIGluc3RhbmNlcyBv ZiB0aGUgc2FtZSBjbGFzcyBvciBhbnkgDQogICAgICAgICAgICAgICAgY2xhc3MgdGhhdCBjYW4g YmUgY3JlYXRlZCBvbiBhbnkgZ2l2ZW4gYnJhbmNoIG9mIHRoZSANCiAgICAgICAgICAgICAgICBn cmFwaCANCiAgICAgICAgICAgICBvIE9yZGVyaW5nIHJlc3RyaWN0aW9ucyBvbiBMRkJzIChlLmcu LCBhbnkgaW5zdGFuY2Ugb2YgTEZCIA0KICAgICAgICAgICAgICAgIGNsYXNzIEEgbXVzdCBiZSBh bHdheXMgZG93bnN0cmVhbSBvZiBhbnkgaW5zdGFuY2Ugb2YgTEZCIA0KICAgICAgICAgICAgICAg IGNsYXNzIEIpLiANCiAgICAgICANCiAgICAgIE5vdGUgdGhhdCBldmVuIHdoZW4gdGhlIENFIGlz IGFsbG93ZWQgdG8gY29uZmlndXJlIExGQiB0b3BvbG9neSANCiAgICAgIGZvciB0aGUgRkUsIHRo ZSBDRSBpcyBub3QgZXhwZWN0ZWQgdG8gYmUgYWJsZSB0byBpbnRlcnByZXQgYW4gDQogICAgICBh cmJpdHJhcnkgTEZCIHRvcG9sb2d5IGFuZCBkZXRlcm1pbmUgd2hpY2ggc3BlY2lmaWMgc2Vydmlj ZSBvciANCiAgICAgIGFwcGxpY2F0aW9uIChlLmcuIFZQTiwgRGlmZlNlcnYsIGV0Yy4pIGlzIHN1 cHBvcnRlZCBieSB0aGUgRkUuICANCiAgICAgIEhvd2V2ZXIsIG9uY2UgdGhlIENFIHVuZGVyc3Rh bmRzIHRoZSBjb2Fyc2UgY2FwYWJpbGl0eSBvZiBhbiBGRSwgDQogICAgICBpdCBpcyB0aGUgcmVz cG9uc2liaWxpdHkgb2YgdGhlIENFIHRvIGNvbmZpZ3VyZSB0aGUgTEZCIHRvcG9sb2d5IA0KICAg ICAgdG8gaW1wbGVtZW50IHRoZSBuZXR3b3JrIHNlcnZpY2UgdGhlIE5FIGlzIHN1cHBvc2VkIHRv IHByb3ZpZGUuICANCiAgICAgIFRodXMsIHRoZSBtYXBwaW5nIHRoZSBDRSBoYXMgdG8gdW5kZXJz dGFuZCBpcyBmcm9tIHRoZSBoaWdoIGxldmVsIA0KICAgICAgTkUgc2VydmljZSB0byBhIHNwZWNp ZmljIExGQiB0b3BvbG9neSwgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kLiANCiAgICAgIFRoZSBD RSBpcyBub3QgZXhwZWN0ZWQgdG8gaGF2ZSB0aGUgdWx0aW1hdGUgaW50ZWxsaWdlbmNlIHRvIA0K ICAgICAgdHJhbnNsYXRlIGFueSBoaWdoIGxldmVsIHNlcnZpY2UgcG9saWN5IGludG8gdGhlIGNv bmZpZ3VyYXRpb24gDQogICAgICBkYXRhIGZvciB0aGUgRkVzLiAgSG93ZXZlciwgaXQgaXMgY29u Y2VpdmFibGUgdGhhdCB3aXRoaW4gYSBnaXZlbiANCiAgICAgIG5ldHdvcmsgc2VydmljZSBkb21h aW4sIGEgY2VydGFpbiBhbW91bnQgb2YgaW50ZWxsaWdlbmNlIGNhbiBiZSANCiAgICAgIHByb2dy YW1tZWQgaW50byB0aGUgQ0UgdG8gZ2l2ZSB0aGUgQ0UgYSBnZW5lcmFsIHVuZGVyc3RhbmRpbmcg b2YgDQogICAgICB0aGUgTEZCcyBpbnZvbHZlZCB0byBhbGxvdyB0aGUgdHJhbnNsYXRpb24gZnJv bSBhIGhpZ2ggbGV2ZWwgDQogICAgICBzZXJ2aWNlIHBvbGljeSB0byB0aGUgbG93IGxldmVsIEZF IGNvbmZpZ3VyYXRpb24gdG8gYmUgZG9uZSANCiAgICAgIGF1dG9tYXRpY2FsbHkuICBOb3RlIHRo YXQgdGhpcyBpcyBjb25zaWRlcmVkIGFuIGltcGxlbWVudGF0aW9uIA0KICAgICAgaXNzdWUgaW50 ZXJuYWwgdG8gdGhlIGNvbnRyb2wgcGxhbmUgYW5kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSAN CiAgICAgIEZFIG1vZGVsLiBUaGVyZWZvcmUsIGl0IGlzIG5vdCBkaXNjdXNzZWQgYW55IGZ1cnRo ZXIgaW4gdGhpcyANCiAgICAgIGRyYWZ0LiAgDQogICAgDQoNCg0KDQoNCg0KDQoNCiAgICANCiAg IFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAzNF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9k ZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICArLS0t LS0tLS0tLSsgICAgICstLS0tLS0tLS0tLSsgICAgICAgDQogICAgICAtLS0tPnwgSW5ncmVzcyAg fC0tLS0+fGNsYXNzaWZpZXIgfC0tLS0tLS0tLS0tLS0tKyAgDQogICAgICAgICAgIHwgICAgICAg ICAgfCAgICAgfGNoaXAgICAgICAgfCAgICAgICAgICAgICAgfCANCiAgICAgICAgICAgKy0tLS0t LS0tLS0rICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHYgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsgDQogICAgICAgICAgICAgKy0tLS0tLS0tKyAgICB8ICAgTmV0d29yayBQcm9jZXNzb3IgICAg ICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgIDwtLS0tfCBFZ3Jlc3MgfCAgICB8ICAgKy0t LS0tLSsgICAgKy0tLS0tLSsgICArLS0tLS0tLSsgICAgICAgIHwgDQogICAgICAgICAgICAgKy0t LS0tLS0tKyAgICB8ICAgfE1ldGVyIHwgICAgfE1hcmtlcnwgICB8RHJvcHBlcnwgICAgICAgIHwg DQogICAgICAgICAgICAgICAgICAgXiAgICAgICB8ICAgKy0tLS0tLSsgICAgKy0tLS0tLSsgICAr LS0tLS0tLSsgICAgICAgIHwgDQogICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICstLS0tLS0tLS0t Ky0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgDQogICAgICAgIHwgICAgKy0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0t LSsgICArLS0tLS0tKyAgICArLS0tLS0tLS0tKyAgIHwgDQogICAgICAgIHwgICAgfEZvcndhcmRl cnw8LS0tLS0tfFNjaGVkdWxlcnw8LS18UXVldWUgfCAgICB8Q291bnRlciAgfCAgIHwgDQogICAg ICAgIHwgICAgKy0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLSsgICArLS0tLS0tKyAgICArLS0t LS0tLS0tKyAgIHwgDQogICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgKGEpICBUaGUgQ2FwYWJpbGl0eSBvZiB0aGUgRkUsIHJl cG9ydGVkIHRvIHRoZSBDRSANCiAgICANCiAgICAgICAgICAgICArLS0tLS0rICAgICstLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICArLS0tKyAgDQogICAgICAgICAgICAgfCAgICBBfC0tLT58 UXVldWUxIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgIHwgICANCiAgICAgIC0tLS0tLT58ICAg ICB8ICAgICstLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgKy0tLSsgDQogICAg ICAgICAgICAgfCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwg IHwgICB8IA0KICAgICAgICAgICAgIHwgICAgIHwgICAgKy0tLS0tLS0rICAgICAgKy0tLS0tLS0r ICAgICAgIHwgICB8ICB8ICAgfCANCiAgICAgICAgICAgICB8ICAgIEJ8LS0tPnxNZXRlcjEgfC0t LS0tPnxRdWV1ZTIgfC0tLS0tLT58ICAgfC0+fCAgIHwgDQogICAgICAgICAgICAgfCAgICAgfCAg ICB8ICAgICAgIHwgICAgICArLS0tLS0tLSsgICAgICAgfCAgIHwgIHwgICB8IA0KICAgICAgICAg ICAgIHwgICAgIHwgICAgfCAgICAgICB8LS0rICAgICAgICAgICAgICAgICAgIHwgICB8ICB8ICAg fCANCiAgICAgICAgICAgICArLS0tLS0rICAgICstLS0tLS0tKyAgfCAgICstLS0tLS0tKyAgICAg ICB8ICAgfCAgKy0tLSsgDQogICAgICAgICAgIGNsYXNzaWZpZXIgICAgICAgICAgICAgICstLT58 RHJvcHBlcnwgICAgICAgfCAgIHwgIElQdjQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLSsgICAgICAgKy0tLSsgIEZ3ZC4gDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2NoZWR1bGVyIA0KICAgIA0KICAg ICAgICAgICAgICAgICAgIChiKSAgT25lIExGQiB0b3BvbG9neSBhcyBjb25maWd1cmVkIGJ5IHRo ZSBDRSBhbmQgDQogICAgICAgICAgICAgICAgICAgICAgICBhY2NlcHRlZCBieSB0aGUgRkUgICAg ICAgICAgICAgICANCiAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgIA0KICAgWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDM1XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUXVldWUxIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0rICAgICAgICAgICAgICAgICAgICArLS0rIA0KICAgICAgICAgICAgICAgICAg ICAgICAgIHwgIEF8LS0tLS0tLS0tLS0tLS0tLS0tLT58ICB8LS0rIA0KICAgICAgICAgICAgICAg ICAgICAgICstPnwgICB8ICAgICAgICAgICAgICAgICAgICB8ICB8ICB8IA0KICAgICAgICAgICAg ICAgICAgICAgIHwgIHwgIEJ8LS0rICArLS0rICAgKy0tKyAgICArLS0rICB8IA0KICAgICAgICAg ICAgICAgICAgICAgIHwgICstLS0rICB8ICB8ICB8ICAgfCAgfCAgICAgICAgICB8IA0KICAgICAg ICAgICAgICAgICAgICAgIHwgTWV0ZXIxICArLT58ICB8LS0+fCAgfCAgICAgICAgICB8IA0KICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICB8ICAgfCAgfCAgICAgICAgICB8ICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgKy0tKyAgICstLSsgICAg ICAgICAgfCAgICAgICAgICBJcHY0IA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBD b3VudGVyMSBEcm9wcGVyMSBRdWV1ZTJ8ICAgICstLSsgIEZ3ZC4gDQogICAgICAgICAgICAgICst LS0rICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICstLSsgICstLS0+fEEgfCAgKy0rIA0K ICAgICAgICAgICAgICB8ICBBfC0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8LS0t LS0tPnxCIHwgIHwgfCANCiAgICAgICAtLS0tLS0+fCAgQnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0+fCAgfCAgKy0tLT58QyB8LT58IHwtPiANCiAgICAgICAgICAgICAgfCAgQ3wtLS0r ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tKyAgfCArLT58RCB8ICB8IHwgDQogICAgICAg ICAgICAgIHwgIER8LSsgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfCAgKy0t KyAgKy0rIA0KICAgICAgICAgICAgICArLS0tKyB8IHwgICAgKy0tLSsgICAgICAgICAgICAgICAg ICBRdWV1ZTN8IHwgU2NoZWR1bGVyIA0KICAgICAgICAgIENsYXNzaWZpZXIxIHwgfCAgfCAgQXwt LS0tLS0tLS0tLS0+ICAgICAgICstLSsgIHwgfCANCiAgICAgICAgICAgICAgICAgICAgICB8ICst PnwgICB8ICAgICAgICAgICAgICAgICAgICB8ICB8LS0rIHwgDQogICAgICAgICAgICAgICAgICAg ICAgfCAgICB8ICBCfC0tKyAgKy0tKyArLS0tLS0tLS0+fCAgfCAgICB8IA0KICAgICAgICAgICAg ICAgICAgICAgIHwgICAgKy0tLSsgIHwgIHwgIHwgfCAgICAgICAgICstLSsgICAgfCANCiAgICAg ICAgICAgICAgICAgICAgICB8ICBNZXRlcjIgICArLT58ICB8LSsgICAgICAgICAgICAgICAgIHwg DQogICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICstLSsgICAgICAg ICAgIFF1ZXVlNCAgfCANCiAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgTWFya2Vy MSAgICAgICAgICArLS0rICAgIHwgDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0+fCAgfC0tLS0rICANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLSsgDQogICAgICAgICAgICAgICAgICAgKGMp ICBBbm90aGVyIExGQiB0b3BvbG9neSBhcyBjb25maWd1cmVkIGJ5IHRoZSBDRSBhbmQgDQogICAg ICAgICAgICAgICAgICAgICAgICBhY2NlcHRlZCBieSB0aGUgRkUgDQogICAgICAgDQogICAgICAg ICAgIEZpZ3VyZSA3LiBBbiBleGFtcGxlIG9mIGNvbmZpZ3VyaW5nIExGQiB0b3BvbG9neS4gDQog ICAgICAgDQogICAgICBGaWd1cmUgNyBzaG93cyBhbiBleGFtcGxlIHdoZXJlIGEgUW9TLWVuYWJs ZWQgcm91dGVyIGhhcyBzZXZlcmFsIA0KICAgICAgbGluZSBjYXJkcyB0aGF0IGhhdmUgYSBmZXcg aW5ncmVzcyBwb3J0cyBhbmQgZWdyZXNzIHBvcnRzLCBhIA0KICAgICAgc3BlY2lhbGl6ZWQgY2xh c3NpZmljYXRpb24gY2hpcCwgYSBuZXR3b3JrIHByb2Nlc3NvciBjb250YWluaW5nIA0KICAgICAg Y29kZXMgZm9yIEZFIGJsb2NrcyBsaWtlIG1ldGVyLCBtYXJrZXIsIGRyb3BwZXIsIGNvdW50ZXIs IHF1ZXVlLCANCiAgICAgIHNjaGVkdWxlciBhbmQgSXB2NCBmb3J3YXJkZXIuICBTb21lIG9mIHRo ZSBMRkIgdG9wb2xvZ3kgaXMgYWxyZWFkeSANCiAgICAgIGZpeGVkIGFuZCBoYXMgdG8gcmVtYWlu IHN0YXRpYyBkdWUgdG8gdGhlIHBoeXNpY2FsIGxheW91dCBvZiB0aGUgDQogICAgICBsaW5lIGNh cmRzLiAgRm9yIGV4YW1wbGUsIGFsbCBvZiB0aGUgaW5ncmVzcyBwb3J0cyBtaWdodCBiZSBoYXJk LQ0KICAgICAgd2lyZWQgaW50byB0aGUgY2xhc3NpZmljYXRpb24gY2hpcCBzbyBhbGwgcGFja2V0 cyBtdXN0IGZsb3cgZnJvbSANCiAgICAgIHRoZSBpbmdyZXNzIHBvcnQgaW50byB0aGUgY2xhc3Np ZmljYXRpb24gZW5naW5lLiAgT24gdGhlIG90aGVyIA0KICAgICAgaGFuZCwgdGhlIExGQnMgb24g dGhlIG5ldHdvcmsgcHJvY2Vzc29yIGFuZCB0aGVpciBleGVjdXRpb24gb3JkZXIgDQogICAgICBh cmUgcHJvZ3JhbW1hYmxlLiBIb3dldmVyLCBjZXJ0YWluIGNhcGFjaXR5IGxpbWl0cyBhbmQgbGlu a2FnZSANCiAgICAgIGNvbnN0cmFpbnRzIGNvdWxkIGV4aXN0IGJldHdlZW4gdGhlc2UgTEZCcy4g RXhhbXBsZXMgb2YgdGhlIA0KICAgICAgY2FwYWNpdHkgbGltaXRzIG1pZ2h0IGJlOiA4IG1ldGVy czsgMTYgcXVldWVzIGluIG9uZSBGRTsgdGhlIA0KICAgICAgc2NoZWR1bGVyIGNhbiBoYW5kbGUg YXQgbW9zdCB1cCB0byAxNiBxdWV1ZXM7IGV0Yy4gIFRoZSBsaW5rYWdlIA0KICAgICAgY29uc3Ry YWludHMgbWlnaHQgZGljdGF0ZSB0aGF0IHRoZSBjbGFzc2lmaWNhdGlvbiBlbmdpbmUgbWF5IGJl IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDM2XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZv ckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAg ICBmb2xsb3dlZCBieSBhIG1ldGVyLCBtYXJrZXIsIGRyb3BwZXIsIGNvdW50ZXIsIHF1ZXVlIG9y IElQdjQgDQogICAgICBmb3J3YXJkZXIsIGJ1dCBub3QgYSBzY2hlZHVsZXI7IHF1ZXVlcyBjYW4g b25seSBiZSBmb2xsb3dlZCBieSBhIA0KICAgICAgc2NoZWR1bGVyOyBhIHNjaGVkdWxlciBtdXN0 IGJlIGZvbGxvd2VkIGJ5IHRoZSBJUHY0IGZvcndhcmRlcjsgdGhlIA0KICAgICAgbGFzdCBMRkIg aW4gdGhlIGRhdGFwYXRoIGJlZm9yZSBnb2luZyBpbnRvIHRoZSBlZ3Jlc3MgcG9ydHMgbXVzdCAN CiAgICAgIGJlIHRoZSBJUHY0IGZvcndhcmRlciwgZXRjLiAgDQogICAgDQogICAgICBPbmNlIHRo ZSBGRSByZXBvcnRzIHRoZXNlIGNhcGFiaWxpdGllcyBhbmQgY2FwYWNpdHkgbGltaXRzIHRvIHRo ZSANCiAgICAgIENFLCBpdCBpcyBub3cgdXAgdG8gdGhlIENFIHRvIHRyYW5zbGF0ZSB0aGUgUW9T IHBvbGljeSBpbnRvIGEgDQogICAgICBkZXNpcmFibGUgY29uZmlndXJhdGlvbiBmb3IgdGhlIEZF LiAgRmlndXJlIDcoYSkgZGVwaWN0cyB0aGUgRkUgDQogICAgICBjYXBhYmlsaXR5IHdoaWxlIDco YikgYW5kIDcoYykgZGVwaWN0IHR3byBkaWZmZXJlbnQgdG9wb2xvZ2llcyANCiAgICAgIHRoYXQg dGhlIENFIG1heSByZXF1ZXN0IHRoZSBGRSB0byBjb25maWd1cmUuICBOb3RlIHRoYXQgYm90aCB0 aGUgDQogICAgICBpbmdyZXNzIGFuZCBlZ3Jlc3MgYXJlIG9taXR0ZWQgaW4gKGIpIGFuZCAoYykg dG8gc2ltcGxpZnkgdGhlIA0KICAgICAgcmVwcmVzZW50YXRpb24uICBUaGUgdG9wb2xvZ3kgaW4g NyhjKSBpcyBjb25zaWRlcmFibHkgbW9yZSBjb21wbGV4IA0KICAgICAgdGhhbiA3KGIpIGJ1dCBi b3RoIGFyZSBmZWFzaWJsZSB3aXRoaW4gdGhlIEZFIGNhcGFiaWxpdGllcywgYW5kIHNvIA0KICAg ICAgdGhlIEZFIHNob3VsZCBhY2NlcHQgZWl0aGVyIGNvbmZpZ3VyYXRpb24gcmVxdWVzdCBmcm9t IHRoZSBDRS4gICANCiAgICANCiAgIDQuIA0gICAgIE1vZGVsIGFuZCBTY2hlbWEgZm9yIExGQiBD bGFzc2VzIA0KICAgICAgIA0KICAgICAgVGhlIG1haW4gZ29hbCBvZiB0aGUgRkUgbW9kZWwgaXMg dG8gcHJvdmlkZSBhbiBhYnN0cmFjdCwgZ2VuZXJpYywgDQogICAgICBtb2R1bGFyLCBpbXBsZW1l bnRhdGlvbi1pbmRlcGVuZGVudCByZXByZXNlbnRhdGlvbiBvZiB0aGUgRkVzLiAgDQogICAgICBU aGlzIGlzIGZhY2lsaXRhdGVkIHVzaW5nIHRoZSBjb25jZXB0IG9mIExGQnMsIHdoaWNoIGFyZSAN CiAgICAgIGluc3RhbnRpYXRlZCBmcm9tIExGQiBjbGFzc2VzLiAgTEZCIGNsYXNzZXMgYW5kIGFz c29jaWF0ZWQgDQogICAgICBkZWZpbml0aW9ucyB3aWxsIGJlIHByb3ZpZGVkIGluIGEgY29sbGVj dGlvbiBvZiBYTUwgZG9jdW1lbnRzLiBUaGUgDQogICAgICBjb2xsZWN0aW9uIG9mIHRoZXNlIFhN TCBkb2N1bWVudHMgaXMgY2FsbGVkIGEgTEZCIGNsYXNzIGxpYnJhcnksIA0KICAgICAgYW5kIGVh Y2ggZG9jdW1lbnQgaXMgY2FsbGVkIGFuIExGQiBjbGFzcyBsaWJyYXJ5IGRvY3VtZW50IChvciAN CiAgICAgIGxpYnJhcnkgZG9jdW1lbnQsIGZvciBzaG9ydCkuICBFYWNoIG9mIHRoZSBsaWJyYXJ5 IGRvY3VtZW50cyB3aWxsIA0KICAgICAgY29uZm9ybSB0byB0aGUgc2NoZW1hIHByZXNlbnRlZCBp biB0aGlzIHNlY3Rpb24uICBUaGUgcm9vdCBlbGVtZW50IA0KICAgICAgb2YgdGhlIGxpYnJhcnkg ZG9jdW1lbnQgaXMgdGhlIDxMRkJMaWJyYXJ5PiBlbGVtZW50LiANCiAgICAgICANCiAgICAgIEl0 IGlzIG5vdCBleHBlY3RlZCB0aGF0IGxpYnJhcnkgZG9jdW1lbnRzIHdpbGwgYmUgZXhjaGFuZ2Vk IA0KICAgICAgYmV0d2VlbiBGRXMgYW5kIENFcyAib3Zlci10aGUtd2lyZSIuICBCdXQgdGhlIG1v ZGVsIHdpbGwgc2VydmUgYXMgDQogICAgICBhbiBpbXBvcnRhbnQgcmVmZXJlbmNlIGZvciB0aGUg ZGVzaWduIGFuZCBkZXZlbG9wbWVudCBvZiB0aGUgQ0VzIA0KICAgICAgKHNvZnR3YXJlKSBhbmQg RkVzIChtb3N0bHkgdGhlIHNvZnR3YXJlIHBhcnQpLiAgSXQgd2lsbCBhbHNvIHNlcnZlIA0KICAg ICAgYXMgYSBkZXNpZ24gaW5wdXQgd2hlbiBzcGVjaWZ5aW5nIHRoZSBGb3JDRVMgcHJvdG9jb2wg ZWxlbWVudHMgZm9yIA0KICAgICAgQ0UtRkUgY29tbXVuaWNhdGlvbi4gDQogICAgICAgDQogICA0 LjEuIE5hbWVzcGFjZSANCiAgICAgICANCiAgICAgIFRoZSBMRkJMaWJyYXJ5IGVsZW1lbnQgYW5k IGFsbCBvZiBpdHMgc3ViLWVsZW1lbnRzIGFyZSBkZWZpbmVkIGluIA0KICAgICAgdGhlIGZvbGxv d2luZyBuYW1lc3BhY2U6IA0KICAgICAgIA0KICAgICAgICAgaHR0cDovL2lldGYub3JnL2ZvcmNl cy8xLjAvbGZibW9kZWwgDQogICAgICAgDQogICA0LjIuIDxMRkJMaWJyYXJ5PiBFbGVtZW50IA0K ICAgICAgIA0KICAgICAgVGhlIDxMRkJMaWJyYXJ5PiBlbGVtZW50IHNlcnZlcyBhcyBhIHJvb3Qg ZWxlbWVudCBvZiBhbGwgbGlicmFyeSANCiAgICAgIGRvY3VtZW50cy4gSXQgY29udGFpbnMgb25l IG9yIG1vcmUgb2YgdGhlIGZvbGxvd2luZyBtYWluIGJsb2NrczogDQogICAgDQogICBZYW5nLCBl dCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgMzddIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAg ICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICANCiAgICAgICAgLiA8ZnJh bWVUeXBlRGVmcz4gZm9yIHRoZSBmcmFtZSBkZWNsYXJhdGlvbnM7IA0KICAgICAgICAuIDxkYXRh VHlwZURlZnM+IGZvciBkZWZpbmluZyBjb21tb24gZGF0YSB0eXBlczsgDQogICAgICAgIC4gPG1l dGFkYXRhRGVmcz4gZm9yIGRlZmluaW5nIG1ldGFkYXRhLCBhbmQgDQogICAgICAgIC4gPExGQkNs YXNzRGVmcz4gZm9yIGRlZmluaW5nIExGQiBjbGFzc2VzLiANCiAgICAgICANCiAgICAgIEVhY2gg YmxvY2sgaXMgb3B0aW9uYWwsIHRoYXQgaXMsIG9uZSBsaWJyYXJ5IGRvY3VtZW50IG1heSBjb250 YWluIA0KICAgICAgb25seSBtZXRhZGF0YSBkZWZpbml0aW9ucywgYW5vdGhlciBtYXkgY29udGFp biBvbmx5IExGQiBjbGFzcyANCiAgICAgIGRlZmluaXRpb25zLCB5ZXQgYW5vdGhlciBtYXkgY29u dGFpbiBhbGwgb2YgdGhlIGFib3ZlLiANCiAgICAgICANCiAgICAgIEluIGFkZGl0aW9uIHRvIHRo ZSBhYm92ZSBtYWluIGJsb2NrcywgYSBsaWJyYXJ5IGRvY3VtZW50IGNhbiANCiAgICAgIGltcG9y dCBvdGhlciBsaWJyYXJ5IGRvY3VtZW50cyBpZiBpdCBuZWVkcyB0byByZWZlciB0byBkZWZpbml0 aW9ucyANCiAgICAgIGNvbnRhaW5lZCBpbiB0aGUgaW5jbHVkZWQgZG9jdW1lbnQuICBUaGlzIGNv bmNlcHQgaXMgc2ltaWxhciB0byANCiAgICAgIHRoZSAiI2luY2x1ZGUiIGRpcmVjdGl2ZSBpbiBD LiAgSW1wb3J0aW5nIGlzIGV4cHJlc3NlZCBieSB0aGUgDQogICAgICA8bG9hZD4gZWxlbWVudHMs IHdoaWNoIG11c3QgcHJlY2VkZSBhbGwgdGhlIGFib3ZlIGVsZW1lbnRzIGluIHRoZSANCiAgICAg IGRvY3VtZW50LiAgRm9yIHVuaXF1ZSByZWZlcmVuY2luZywgZWFjaCBMRkJMaWJyYXJ5IGluc3Rh bmNlIA0KICAgICAgZG9jdW1lbnQgaGFzIGEgdW5pcXVlIGxhYmVsIGRlZmluZWQgaW4gdGhlICJw cm92aWRlIiBhdHRyaWJ1dGUgb2YgDQogICAgICB0aGUgTEZCTGlicmFyeSBlbGVtZW50LiANCiAg ICAgICANCiAgICAgIFRoZSA8TEZCTGlicmFyeT4gZWxlbWVudCBhbHNvIGluY2x1ZGVzIGFuIG9w dGlvbmFsIDxkZXNjcmlwdGlvbj4gDQogICAgICBlbGVtZW50LCB3aGljaCBjYW4gYmUgdXNlZCB0 byBwcm92aWRlIHRleHR1YWwgZGVzY3JpcHRpb24gYWJvdXQgDQogICAgICB0aGUgbGlicmFyeSBk b2N1bWVudC4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93aW5nIGlzIGEgc2tlbGV0b24gb2Yg YSBsaWJyYXJ5IGRvY3VtZW50OiANCiAgICAgICANCiAgICAgIDw/eG1sIHZlcnNpb249IjEuMCIg ZW5jb2Rpbmc9IlVURi04Ij8+IA0KICAgICAgPExGQkxpYnJhcnkgeG1sbnM9Imh0dHA6Ly9pZXRm Lm9yZy9mb3JjZXMvMS4wL2xmYm1vZGVsIiANCiAgICAgICAgcHJvdmlkZXM9InRoaXNfbGlicmFy eSI+IA0KICAgICAgICAgDQogICAgICAgIDxkZXNjcmlwdGlvbj4gDQogICAgICAgICAgLi4uIA0K ICAgICAgICA8L2Rlc2NyaXB0aW9uPiANCiAgICAgICANCiAgICAgICAgPCEtLSBMb2FkaW5nIGV4 dGVybmFsIGxpYnJhcmllcyAob3B0aW9uYWwpIC0tPiANCiAgICAgICAgPGxvYWQgbGlicmFyeT0i YW5vdGhlcl9saWJyYXJ5Ii8+IA0KICAgICAgICAuLi4gDQogICAgICAgDQogICAgICAgIDwhLS0g RlJBTUUgVFlQRSBERUZJTklUSU9OUyAob3B0aW9uYWwpIC0tPiANCiAgICAgICAgPGZyYW1lVHlw ZURlZnM+IA0KICAgICAgICAgIC4uLiANCiAgICAgICAgPC9mcmFtZVR5cGVEZWZzPiANCiAgICAg ICANCiAgICAgICAgPCEtLSBEQVRBIFRZUEUgREVGSU5JVElPTlMgKG9wdGlvbmFsKSAtLT4gDQog ICAgICAgIDxkYXRhVHlwZURlZnM+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJl cyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDM4XSANCgwgICBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIw MDUgDQogICAgDQogICAgDQogICAgICAgICAgLi4uIA0KICAgICAgICA8L2RhdGFUeXBlRGVmcz4g DQogICAgICAgDQogICAgICAgIDwhLS0gTUVUQURBVEEgREVGSU5JVElPTlMgKG9wdGlvbmFsKSAt LT4gDQogICAgICAgIDxtZXRhZGF0YURlZnM+IA0KICAgICAgICAgIC4uLiANCiAgICAgICAgPC9t ZXRhZGF0YURlZnM+IA0KICAgICAgIA0KICAgICAgICA8IZdMRkIgQ0xBU1MgREVGSU5JVElPTlMg KG9wdGlvbmFsKSAtLT4gDQogICAgICAgIDxMRkJDTGFzc0RlZnM+IA0KICAgICAgICAgIC4uLiAN CiAgICAgICAgPC9MRkJDTGFzc0RlZnM+IA0KICAgICAgPC9MRkJMaWJyYXJ5PiANCiAgICAgICAN CiAgICAgICANCiAgIDQuMy4gPGxvYWQ+IEVsZW1lbnQgDQogICAgICAgDQogICAgICBUaGlzIGVs ZW1lbnQgaXMgdXNlZCB0byByZWZlciB0byBhbm90aGVyIExGQiBsaWJyYXJ5IGRvY3VtZW50LiAg IA0KICAgICAgU2ltaWxhciB0byB0aGUgIiNpbmNsdWRlIiBkaXJlY3RpdmUgaW4gQywgdGhpcyBt YWtlcyB0aGUgb2JqZWN0cyANCiAgICAgIChtZXRhZGF0YSB0eXBlcywgZGF0YSB0eXBlcywgZXRj LikgZGVmaW5lZCBpbiB0aGUgcmVmZXJyZWQgbGlicmFyeSANCiAgICAgIGRvY3VtZW50IGF2YWls YWJsZSBmb3IgcmVmZXJlbmNpbmcgaW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQuIA0KICAgICAgIA0K ICAgICAgVGhlIGxvYWQgZWxlbWVudCBtdXN0IGNvbnRhaW4gdGhlIGxhYmVsIG9mIHRoZSBsaWJy YXJ5IGRvY3VtZW50IHRvIA0KICAgICAgYmUgaW5jbHVkZWQgYW5kIG1heSBjb250YWluIGEgVVJM IHRvIHNwZWNpZnkgd2hlcmUgdGhlIGxpYnJhcnkgY2FuIA0KICAgICAgYmUgcmV0cmlldmVkLiAg VGhlIGxvYWQgZWxlbWVudCBjYW4gYmUgcmVwZWF0ZWQgdW5saW1pdGVkIHRpbWVzLiAgDQogICAg ICBUaHJlZSBleGFtcGxlcyBmb3IgdGhlIDxsb2FkPiBlbGVtZW50czogDQogICAgICAgDQogICAg ICA8bG9hZCBsaWJyYXJ5PSJhX2xpYnJhcnkiLz4gDQogICAgICA8bG9hZCBsaWJyYXJ5PSJhbm90 aGVyX2xpYnJhcnkiIGxvY2F0aW9uPSJhbm90aGVyX2xpYi54bWwiLz4gDQogICAgICA8bG9hZCBs aWJyYXJ5PSJ5ZXRhbm90aGVyX2xpYnJhcnkiIA0KICAgICAgbG9jYXRpb249Imh0dHA6Ly93d3cu cGV0cmltZWF0LmNvbS9mb3JjZXMvMS4wL2xmYm1vZGVsL2xwbS54bWwiLz4gDQogICAgDQogICA0 LjQuIDxmcmFtZURlZnM+IEVsZW1lbnQgZm9yIEZyYW1lIFR5cGUgRGVjbGFyYXRpb25zIA0KICAg ICAgIA0KICAgICAgRnJhbWUgbmFtZXMgYXJlIHVzZWQgaW4gdGhlIExGQiBkZWZpbml0aW9uIHRv IGRlZmluZSB0aGUgdHlwZXMgb2YgDQogICAgICBmcmFtZXMgdGhlIExGQiBleHBlY3RzIGF0IGl0 cyBpbnB1dCBwb3J0KHMpIGFuZCBlbWl0cyBhdCBpdHMgDQogICAgICBvdXRwdXQgcG9ydChzKS4g IFRoZSA8ZnJhbWVEZWZzPiBvcHRpb25hbCBlbGVtZW50IGluIHRoZSBsaWJyYXJ5IA0KICAgICAg ZG9jdW1lbnQgY29udGFpbnMgb25lIG9yIG1vcmUgPGZyYW1lRGVmPiBlbGVtZW50cywgZWFjaCBk ZWNsYXJpbmcgDQogICAgICBvbmUgZnJhbWUgdHlwZS4gDQogICAgICAgDQogICAgICBFYWNoIGZy YW1lIGRlZmluaXRpb24gY29udGFpbnMgYSB1bmlxdWUgbmFtZSAoTk1UT0tFTikgYW5kIGEgYnJp ZWYgDQogICAgICBzeW5vcHNpcy4gIEluIGFkZGl0aW9uLCBhbiBvcHRpb25hbCBkZXRhaWxlZCBk ZXNjcmlwdGlvbiBtYXkgYmUgDQogICAgICBwcm92aWRlZC4gDQogICAgICAgDQogICAgDQogICBZ YW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMzldIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVs ICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFVuaXF1ZW5lc3Mg b2YgZnJhbWUgdHlwZXMgbXVzdCBiZSBlbnN1cmVkIGFtb25nIGZyYW1lIHR5cGVzIA0KICAgICAg ZGVmaW5lZCBpbiB0aGUgc2FtZSBsaWJyYXJ5IGRvY3VtZW50IGFuZCBpbiBhbGwgZGlyZWN0bHkg b3IgDQogICAgICBpbmRpcmVjdGx5IGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAgDQogICAg ICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGRlZmluZXMgdHdvIGZyYW1lIHR5cGVz OiANCiAgICAgICANCiAgICAgIDxmcmFtZURlZnM+IA0KICAgICAgICA8ZnJhbWVEZWY+IA0KICAg ICAgICAgIDxuYW1lPmlwdjQ8L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNpcz5JUHY0IHBhY2tl dDwvc3lub3BzaXM+IA0KICAgICAgICAgIDxkZXNjcmlwdGlvbj4gDQogICAgICAgICAgICBUaGlz IGZyYW1lIHR5cGUgcmVmZXJzIHRvIGFuIElQdjQgcGFja2V0LiANCiAgICAgICAgICA8L2Rlc2Ny aXB0aW9uPiANCiAgICAgICAgPC9mcmFtZURlZj4gDQogICAgICAgICAgPGZyYW1lRGVmPiANCiAg ICAgICAgICA8bmFtZT5pcHY2PC9uYW1lPiANCiAgICAgICAgICA8c3lub3BzaXM+SVB2NiBwYWNr ZXQ8L3N5bm9wc2lzPiANCiAgICAgICAgICA8ZGVzY3JpcHRpb24+IA0KICAgICAgICAgICAgVGhp cyBmcmFtZSB0eXBlIHJlZmVycyB0byBhbiBJUHY2IHBhY2tldC4gDQogICAgICAgICAgPC9kZXNj cmlwdGlvbj4gDQogICAgICAgIDwvZnJhbWVEZWY+IA0KICAgICAgICAuLi4gDQogICAgICA8L2Zy YW1lRGVmcz4gDQogICAgICAgIA0KICAgNC41LiA8ZGF0YVR5cGVEZWZzPiBFbGVtZW50IGZvciBE YXRhIFR5cGUgRGVmaW5pdGlvbnMgIA0KICAgICAgIA0KICAgICAgVGhlIChvcHRpb25hbCkgPGRh dGFUeXBlRGVmcz4gZWxlbWVudCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgDQogICAgICBjb21tb25s eSB1c2VkIGRhdGEgdHlwZXMuIEl0IGNvbnRhaW5zIG9uZSBvciBtb3JlIDxkYXRhVHlwZURlZj4g DQogICAgICBlbGVtZW50cywgZWFjaCBkZWZpbmluZyBhIGRhdGEgdHlwZSB3aXRoIGEgdW5pcXVl IG5hbWUuIFN1Y2ggZGF0YSANCiAgICAgIHR5cGVzIGNhbiBiZSB1c2VkIGluIHNldmVyYWwgcGxh Y2VzIGluIHRoZSBsaWJyYXJ5IGRvY3VtZW50cywgDQogICAgICBpbmNsdWRpbmc6IA0KICAgICAg IA0KICAgICAgICAgLiAgRGVmaW5pbmcgb3RoZXIgZGF0YSB0eXBlcyANCiAgICAgICAgIC4gIERl ZmluaW5nIG1ldGFkYXRhIA0KICAgICAgICAgLiAgRGVmaW5pbmcgYXR0cmlidXRlcyBvZiBMRkIg Y2xhc3NlcyANCiAgICAgICANCiAgICAgIFRoaXMgaXMgc2ltaWxhciB0byB0aGUgY29uY2VwdCBv ZiBoYXZpbmcgYSBjb21tb24gaGVhZGVyIGZpbGUgZm9yIA0KICAgICAgc2hhcmVkIGRhdGEgdHlw ZXMuIA0KICAgICAgIA0KICAgICAgRWFjaCA8ZGF0YVR5cGVEZWY+IGVsZW1lbnQgY29udGFpbnMg YSB1bmlxdWUgbmFtZSAoTk1UT0tFTiksIGEgDQogICAgICBicmllZiBzeW5vcHNpcywgYW4gb3B0 aW9uYWwgbG9uZ2VyIGRlc2NyaXB0aW9uLCBhbmQgYSB0eXBlIA0KICAgICAgZGVmaW5pdGlvbiBl bGVtZW50LiAgVGhlIG5hbWUgbXVzdCBiZSB1bmlxdWUgYW1vbmcgYWxsIGRhdGEgdHlwZXMgDQog ICAgICBkZWZpbmVkIGluIHRoZSBzYW1lIGxpYnJhcnkgZG9jdW1lbnQgYW5kIGluIGFueSBkaXJl Y3RseSBvciANCiAgICAgIGluZGlyZWN0bHkgaW5jbHVkZWQgbGlicmFyeSBkb2N1bWVudHMuIEZv ciBleGFtcGxlOiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIw MDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA0MF0gDQoMICAgSW50ZXJuZXQgRHJhZnQg ICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0K ICAgIA0KICAgICAgIA0KICAgICAgPGRhdGFUeXBlRGVmcz4gDQogICAgICAgIDxkYXRhVHlwZURl Zj4gDQogICAgICAgICAgPG5hbWU+aWVlZW1hY2FkZHI8L25hbWU+IA0KICAgICAgICAgIDxzeW5v cHNpcz40OC1iaXQgSUVFRSBNQUMgYWRkcmVzczwvc3lub3BzaXM+IA0KICAgICAgICAgIC4uLiB0 eXBlIGRlZmluaXRpb24gLi4uIA0KICAgICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICAgICAgPGRh dGFUeXBlRGVmPiANCiAgICAgICAgICA8bmFtZT5pcHY0YWRkcjwvbmFtZT4gDQogICAgICAgICAg PHN5bm9wc2lzPklQdjQgYWRkcmVzczwvc3lub3BzaXM+IA0KICAgICAgICAgIC4uLiB0eXBlIGRl ZmluaXRpb24gLi4uIA0KICAgICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICAgICAgLi4uIA0KICAg ICAgPC9kYXRhVHlwZURlZnM+ICAgDQogICAgICAgDQogICAgICBUaGVyZSBhcmUgdHdvIGtpbmRz IG9mIGRhdGEgdHlwZXM6IGF0b21pYyBhbmQgY29tcG91bmQuICBBdG9taWMgDQogICAgICBkYXRh IHR5cGVzIGFyZSBhcHByb3ByaWF0ZSBmb3Igc2luZ2xlLXZhbHVlIHZhcmlhYmxlcyAoZS5nLiAN CiAgICAgIGludGVnZXIsIEFTQ0lJIHN0cmluZywgYnl0ZSBhcnJheSkuIA0KICAgICAgIA0KICAg ICAgVGhlIGZvbGxvd2luZyBidWlsdC1pbiBhdG9taWMgZGF0YSB0eXBlcyBhcmUgcHJvdmlkZWQs IGJ1dCANCiAgICAgIGFkZGl0aW9uYWwgYXRvbWljIGRhdGEgdHlwZXMgY2FuIGJlIGRlZmluZWQg d2l0aCB0aGUgPHR5cGVSZWY+IGFuZCANCiAgICAgIDxhdG9taWM+IGVsZW1lbnRzOiANCiAgICAg ICANCiAgICAgICAgIDxuYW1lPiAgICAgICAgICAgICAgICAgICBNZWFuaW5nIA0KICAgICAgICAg LS0tLSAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0gDQogICAgICAgICBjaGFyICAgICAgICAg ICAgICAgICAgICAgOC1iaXQgc2lnbmVkIGludGVnZXIgDQogICAgICAgICB1Y2hhciAgICAgICAg ICAgICAgICAgICAgOC1iaXQgdW5zaWduZWQgaW50ZWdlciANCiAgICAgICAgIGludDE2ICAgICAg ICAgICAgICAgICAgICAxNi1iaXQgc2lnbmVkIGludGVnZXIgDQogICAgICAgICB1aW50MTYgICAg ICAgICAgICAgICAgICAgMTYtYml0IHVuc2lnbmVkIGludGVnZXIgDQogICAgICAgICBpbnQzMiAg ICAgICAgICAgICAgICAgICAgMzItYml0IHNpZ25lZCBpbnRlZ2VyIA0KICAgICAgICAgdWludDMy ICAgICAgICAgICAgICAgICAgIDMyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyIA0KICAgICAgICAgaW50 NjQgICAgICAgICAgICAgICAgICAgIDY0LWJpdCBzaWduZWQgaW50ZWdlciANCiAgICAgICAgIHVp bnQ2NCAgICAgICAgICAgICAgICAgICA2NC1iaXQgdW5pc2duZWQgaW50ZWdlciANCiAgICAgICAg IGJvb2xlYW4gICAgICAgICAgICAgICAgICBBIHRydWUgLyBmYWxzZSB2YWx1ZSB3aGVyZSANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwID0gZmFsc2UsIDEgPSB0cnVlIA0KICAg ICAgICAgc3RyaW5nW05dICAgICAgICAgICAgICAgIEFTQ0lJIG51bGwtdGVybWluYXRlZCBzdHJp bmcgd2l0aCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBidWZmZXIgb2YgTiBj aGFyYWN0ZXJzIChzdHJpbmcgbWF4IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGxlbmd0aCBpcyBOLTEpIA0KICAgICAgICAgYnl0ZVtOXSAgICAgICAgICAgICAgICAgIEEgYnl0 ZSBhcnJheSBvZiBOIGJ5dGVzIA0KICAgICAgICAgb2N0ZXRzdHJpbmdbTl0gICAgICAgICAgIEEg YnVmZmVyIG9mIE4gb2N0ZXRzLCB3aGljaCBtYXkgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udGFpbiBmZXdlciB0aGFuIE4gb2N0ZXRzLiAgSGVuY2UgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGVuY29kZWQgdmFsdWUgd2lsbCBhbHdheXMgaGF2 ZSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIGxlbmd0aC4gDQoNCiAgICAN CiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA0MV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUg TW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgZmxv YXQxNiAgICAgICAgICAgICAgICAgIDE2LWJpdCBmbG9hdGluZyBwb2ludCBudW1iZXIgDQogICAg ICAgICBmbG9hdDMyICAgICAgICAgICAgICAgICAgMzItYml0IElFRUUgZmxvYXRpbmcgcG9pbnQg bnVtYmVyIA0KICAgICAgICAgZmxvYXQ2NCAgICAgICAgICAgICAgICAgIDY0LWJpdCBJRUVFIGZs b2F0aW5nIHBvaW50IG51bWJlciANCiAgICAgICANCiAgICAgIFRoZXNlIGJ1aWx0LWluIGRhdGEg dHlwZXMgY2FuIGJlIHJlYWRpbHkgdXNlZCB0byBkZWZpbmUgbWV0YWRhdGEgDQogICAgICBvciBM RkIgYXR0cmlidXRlcywgYnV0IGNhbiBhbHNvIGJlIHVzZWQgYXMgYnVpbGRpbmcgYmxvY2tzIHdo ZW4gDQogICAgICBkZWZpbmluZyBuZXcgZGF0YSB0eXBlcy4gIFRoZSBib29sZWFuIGRhdGEgdHlw ZSBpcyBkZWZpbmVkIGhlcmUgDQogICAgICBiZWNhdXNlIGl0IGlzIHNvIGNvbW1vbiwgZXZlbiB0 aG91Z2ggaXQgY2FuIGJlIGJ1aWx0IGJ5IHN1Yi0NCiAgICAgIHJhbmdpbmcgdGhlIHVjaGFyIGRh dGEgdHlwZS4gDQogICAgICAgDQogICAgICBDb21wb3VuZCBkYXRhIHR5cGVzIGNhbiBidWlsZCBv biBhdG9taWMgZGF0YSB0eXBlcyBhbmQgb3RoZXIgDQogICAgICBjb21wb3VuZCBkYXRhIHR5cGVz LiAgQ29tcG91bmQgZGF0YSB0eXBlcyBjYW4gYmUgZGVmaW5lZCBpbiBvbmUgb2YgDQogICAgICBm b3VyIHdheXMuICBUaGV5IG1heSBiZSBkZWZpbmVkIGFzIGFuIGFycmF5IG9mIGVsZW1lbnRzIG9m IHNvbWUgDQogICAgICBjb21wb3VuZCBvciBhdG9taWMgZGF0YSB0eXBlLiAgVGhleSBtYXkgYmUg YSBzdHJ1Y3R1cmUgb2YgbmFtZWQgDQogICAgICBlbGVtZW50cyBvZiBjb21wb3VuZCBvciBhdG9t aWMgZGF0YSB0eXBlcyAoYWxhIEMgc3RydWN0dXJlcykuICANCiAgICAgIFRoZXkgbWF5IGJlIGEg dW5pb24gb2YgbmFtZWQgZWxlbWVudHMgb2YgY29tcG91bmQgb3IgYXRvbWljIGRhdGEgDQogICAg ICB0eXBlcyAoYWxhIEMgdW5pb25zKS4gIFRoZXkgbWF5IGFsc28gYmUgZGVmaW5lZCBhcyBhdWdt ZW50YXRpb25zIA0KICAgICAgKGV4cGxhaW5lZCBiZWxvdyBpbiA0LjUuNikgb2YgZXhpc3Rpbmcg Y29tcG91bmQgZGF0YSB0eXBlcy4gDQogICAgICAgDQogICAgICBHaXZlbiB0aGF0IHRoZSBGT1JD RVMgcHJvdG9jb2wgd2lsbCBiZSBnZXR0aW5nIGFuZCBzZXR0aW5nIA0KICAgICAgYXR0cmlidXRl IHZhbHVlcywgYWxsIGF0b21pYyBkYXRhIHR5cGVzIHVzZWQgaGVyZSBtdXN0IGJlIGFibGUgdG8g DQogICAgICBiZSBjb252ZXllZCBpbiB0aGUgRk9SQ0VTIHByb3RvY29sLiAgRnVydGhlciwgdGhl IEZPUkNFUyBwcm90b2NvbCANCiAgICAgIHdpbGwgbmVlZCBhIG1lY2hhbmlzbSB0byBjb252ZXkg Y29tcG91bmQgZGF0YSB0eXBlcy4gIEhvd2V2ZXIsIHRoZSANCiAgICAgIGRldGFpbHMgb2Ygc3Vj aCByZXByZXNlbnRhdGlvbnMgYXJlIGZvciB0aGUgcHJvdG9jb2wgZG9jdW1lbnQgdG8gDQogICAg ICBkZWZpbmUsIG5vdCB0aGUgbW9kZWwgZG9jdW1lbnQuIA0KICAgIA0KICAgICAgRm9yIHRoZSBk ZWZpbml0aW9uIG9mIHRoZSBhY3R1YWwgdHlwZSBpbiB0aGUgPGRhdGFUeXBlRGVmPiANCiAgICAg IGVsZW1lbnQsIHRoZSBmb2xsb3dpbmcgZWxlbWVudHMgYXJlIGF2YWlsYWJsZTogPHR5cGVSZWY+ LCANCiAgICAgIDxhdG9taWM+LCA8YXJyYXk+LCA8c3RydWN0PiwgYW5kIDx1bmlvbj4uIA0KICAg ICAgIA0KICAgICAgVGhlIHByZWRlZmluZWQgdHlwZSBhbGlhcyBpcyBzb21ld2hlcmUgYmV0d2Vl biB0aGUgYXRvbWljIGFuZCANCiAgICAgIGNvbXBvdW5kIGRhdGEgdHlwZXMuICBJdCBiZWhhdmVz IGxpa2UgYSBzdHJ1Y3R1cmUsIG9uZSBlbGVtZW50IG9mIA0KICAgICAgd2hpY2ggaGFzIHNwZWNp YWwgYmVoYXZpb3IuICBHaXZlbiB0aGF0IHRoZSBzcGVjaWFsIGJlaGF2aW9yIGlzIA0KICAgICAg dGllZCB0byB0aGUgb3RoZXIgcGFydHMgb2YgdGhlIHN0cnVjdHVyZSwgdGhlIGNvbXBvdW5kIHJl c3VsdCBpcyANCiAgICAgIHRyZWF0ZWQgYXMgYSBwcmVkZWZpbmVkIGNvbnN0cnVjdC4gDQogICAg ICAgDQogICAgICBbRURJVE9SOiBIb3cgdG8gc3VwcG9ydCBhdWdtZW50YXRpb24gaXMgZm9yIGZ1 cnRoZXIgc3R1ZHkuXSANCiAgICAgICANCiAgIDQuNS4xLiA8dHlwZVJlZj4gRWxlbWVudCBmb3Ig QWxpYXNpbmcgRXhpc3RpbmcgRGF0YSBUeXBlcyANCiAgICAgICANCiAgICAgIFRoZSA8dHlwZVJl Zj4gZWxlbWVudCByZWZlcnMgdG8gYW4gZXhpc3RpbmcgZGF0YSB0eXBlIGJ5IGl0cyBuYW1lLiAg DQogICAgICBUaGUgcmVmZXJyZWQgZGF0YSB0eXBlIG11c3QgYmUgZGVmaW5lZCBlaXRoZXIgaW4g dGhlIHNhbWUgbGlicmFyeSANCiAgICAgIGRvY3VtZW50LCBvciBpbiBvbmUgb2YgdGhlIGluY2x1 ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAgSWYgdGhlIA0KICAgICAgcmVmZXJyZWQgZGF0YSB0eXBl IGlzIGFuIGF0b21pYyBkYXRhIHR5cGUsIHRoZSBuZXdseSBkZWZpbmVkIHR5cGUgDQogICAgICB3 aWxsIGFsc28gYmUgcmVnYXJkZWQgYXMgYXRvbWljLiAgSWYgdGhlIHJlZmVycmVkIGRhdGEgdHlw ZSBpcyBhIA0KDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdIA0KDCAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAg ICANCiAgICAgIGNvbXBvdW5kIHR5cGUsIHRoZSBuZXcgdHlwZSB3aWxsIGFsc28gYmUgY29tcG91 bmQuICBTb21lIHVzYWdlIA0KICAgICAgZXhhbXBsZXMgZm9sbG93OiANCiAgICAgICANCiAgICAg IDxkYXRhVHlwZURlZj4gDQogICAgICAgIDxuYW1lPnNob3J0PC9uYW1lPiANCiAgICAgICAgPHN5 bm9wc2lzPkFsaWFzIHRvIGludDE2PC9zeW5vcHNpcz4gDQogICAgICAgIDx0eXBlUmVmPmludDE2 PC90eXBlUmVmPiANCiAgICAgIDwvZGF0YVR5cGVEZWY+IA0KICAgICAgPGRhdGFUeXBlRGVmPiAN CiAgICAgICAgPG5hbWU+aWVlZW1hY2FkZHI8L25hbWU+IA0KICAgICAgICA8c3lub3BzaXM+NDgt Yml0IElFRUUgTUFDIGFkZHJlc3M8L3N5bm9wc2lzPiANCiAgICAgICAgPHR5cGVSZWY+Ynl0ZVs2 XTwvdHlwZVJlZj4gDQogICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICAgICANCiAgIDQuNS4yLiA8 YXRvbWljPiBFbGVtZW50IGZvciBEZXJpdmluZyBOZXcgQXRvbWljIFR5cGVzIA0KICAgICAgIA0K ICAgICAgVGhlIDxhdG9taWM+IGVsZW1lbnQgYWxsb3dzIHRoZSBkZWZpbml0aW9uIG9mIGEgbmV3 IGF0b21pYyB0eXBlIA0KICAgICAgZnJvbSBhbiBleGlzdGluZyBhdG9taWMgdHlwZSwgYXBwbHlp bmcgcmFuZ2UgcmVzdHJpY3Rpb25zIGFuZC9vciANCiAgICAgIHByb3ZpZGluZyBzcGVjaWFsIGVu dW1lcmF0ZWQgdmFsdWVzLiAgTm90ZSB0aGF0IHRoZSA8YXRvbWljPiANCiAgICAgIGVsZW1lbnQg Y2FuIG9ubHkgdXNlIGF0b21pYyB0eXBlcyBhcyBiYXNlIHR5cGVzLCBhbmQgaXRzIHJlc3VsdCBp cyANCiAgICAgIGFsd2F5cyBhbm90aGVyIGF0b21pYyB0eXBlLiANCiAgICAgICANCiAgICAgIEZv ciBleGFtcGxlLCB0aGUgZm9sbG93aW5nIHNuaXBwZXQgZGVmaW5lcyBhIG5ldyAiZHNjcCIgZGF0 YSB0eXBlOiANCiAgICAgICANCiAgICAgIDxkYXRhVHlwZURlZj4gDQogICAgICAgIDxuYW1lPmRz Y3A8L25hbWU+IA0KICAgICAgICA8c3lub3BzaXM+RGlmZnNlcnYgY29kZSBwb2ludC48L3N5bm9w c2lzPiANCiAgICAgICAgPGF0b21pYz4gDQogICAgICAgICAgPGJhc2VUeXBlPnVjaGFyPC9iYXNl VHlwZT4gDQogICAgICAgICAgPHJhbmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAgICAgPGFsbG93 ZWRSYW5nZSBtaW49IjAiIG1heD0iNjMiLz4gDQogICAgICAgICAgPC9yYW5nZVJlc3RyaWN0aW9u PiANCiAgICAgICAgICA8c3BlY2lhbFZhbHVlcz4gDQogICAgICAgICAgICA8c3BlY2lhbFZhbHVl IHZhbHVlPSIwIj4gDQogICAgICAgICAgICAgIDxuYW1lPkRTQ1AtQkU8L25hbWU+IA0KICAgICAg ICAgICAgICA8c3lub3BzaXM+QmVzdCBFZmZvcnQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgIDwv c3BlY2lhbFZhbHVlPiANCiAgICAgICAgICAgIC4uLiANCiAgICAgICAgICA8L3NwZWNpYWxWYWx1 ZXM+IA0KICAgICAgICA8L2F0b21pYz4gDQogICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICANCiAg IDQuNS4zLiA8YXJyYXk+IEVsZW1lbnQgdG8gRGVmaW5lIEFycmF5cyANCiAgICAgICANCiAgICAg IFRoZSA8YXJyYXk+IGVsZW1lbnQgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGEgbmV3IGNvbXBvdW5k IGRhdGEgdHlwZSANCiAgICAgIGFzIGFuIGFycmF5IG9mIGEgY29tcG91bmQgb3IgYW4gYXRvbWlj IGRhdGEgdHlwZS4gVGhlIHR5cGUgb2YgdGhlIA0KICAgICAgYXJyYXkgZW50cnkgY2FuIGJlIHNw ZWNpZmllZCBlaXRoZXIgYnkgcmVmZXJyaW5nIHRvIGFuIGV4aXN0aW5nIA0KICAgIA0KICAgWWFu ZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDQzXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAg ICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICB0eXBlICh1c2luZyB0 aGUgPHR5cGVSZWY+IGVsZW1lbnQpIG9yIGRlZmluaW5nIGFuIHVubmFtZWQgdHlwZSANCiAgICAg IGluc2lkZSB0aGUgPGFycmF5PiBlbGVtZW50IHVzaW5nIGFueSBvZiB0aGUgPGF0b21pYz4sIDxh cnJheT4sIA0KICAgICAgPHN0cnVjdD4sIG9yIDx1bmlvbj4gZWxlbWVudHMuIA0KICAgICAgIA0K ICAgICAgVGhlIGFycmF5IGNhbiBiZSAiZml4ZWQtc2l6ZSIgb3IgInZhcmlhYmxlLXNpemUiLCB3 aGljaCBpcyANCiAgICAgIHNwZWNpZmllZCBieSB0aGUgInR5cGUiIGF0dHJpYnV0ZSBvZiB0aGUg PGFycmF5PiBlbGVtZW50LiBUaGUgDQogICAgICBkZWZhdWx0IGlzICJ2YXJpYWJsZS1zaXplIi4g IEZvciB2YXJpYWJsZSBzaXplIGFycmF5cywgYW4gb3B0aW9uYWwgDQogICAgICAibWF4LWxlbmd0 aCIgYXR0cmlidXRlIHNwZWNpZmllcyB0aGUgbWF4aW11bSBhbGxvd2VkIGxlbmd0aC4gVGhpcyAN CiAgICAgIGF0dHJpYnV0ZSBzaG91bGQgYmUgdXNlZCB0byBlbmNvZGUgc2VtYW50aWMgbGltaXRh dGlvbnMsIG5vdCANCiAgICAgIGltcGxlbWVudGF0aW9uIGxpbWl0YXRpb25zLiBUaGUgbGF0dGVy IHNob3VsZCBiZSBoYW5kbGVkIGJ5IA0KICAgICAgY2FwYWJpbGl0eSBhdHRyaWJ1dGVzIG9mIExG QiBjbGFzc2VzLCBhbmQgc2hvdWxkIG5ldmVyIGJlIGluY2x1ZGVkIA0KICAgICAgaW4gZGF0YSB0 eXBlIGRlZmluaXRpb25zLiBJZiB0aGUgIm1heC1sZW5ndGgiIGF0dHJpYnV0ZSBpcyBub3QgDQog ICAgICBwcm92aWRlZCwgdGhlIGFycmF5IGlzIHJlZ2FyZGVkIGFzIG9mIHVubGltaXRlZC1zaXpl LiANCiAgICAgICANCiAgICAgIEZvciBmaXhlZC1zaXplIGFycmF5cywgYSAibGVuZ3RoIiBhdHRy aWJ1dGUgbXVzdCBiZSBwcm92aWRlZCB0aGF0IA0KICAgICAgc3BlY2lmaWVzIHRoZSBjb25zdGFu dCBzaXplIG9mIHRoZSBhcnJheS4gDQogICAgICAgDQogICAgICBUaGUgcmVzdWx0IG9mIHRoaXMg Y29uc3RydWN0IGlzIGFsd2F5cyBhIGNvbXBvdW5kIHR5cGUsIGV2ZW4gaWYgDQogICAgICB0aGUg YXJyYXkgaGFzIGEgZml4ZWQgc2l6ZSBvZiAxLiANCiAgICANCiAgICAgIEFycmF5cyBjYW4gb25s eSBiZSBzdWJzY3JpcHRlZCBieSBpbnRlZ2VycywgYW5kIHdpbGwgYmUgcHJlc3VtZWQgDQogICAg ICB0byBzdGFydCB3aXRoIGluZGV4IDAuIA0KICAgICAgIA0KICAgICAgSW4gYWRkaXRpb24gdG8g dGhlaXIgc3Vic2NyaXB0cywgYXJyYXlzIG1heSBiZSBkZWNsYXJlZCB0byBoYXZlIA0KICAgICAg Y29udGVudCBrZXlzLiAgU3VjaCBhIGRlY2xhcmF0aW9uIGhhcyBzZXZlcmFsIGVmZmVjdHM6IA0K ICAgICAgIA0KICAgICAgICAuIEFueSBkZWNsYXJlZCBrZXkgY2FuIGJlIHVzZWQgaW4gdGhlIEZv ckNFUyBwcm90b2NvbCB0byBzZWxlY3QgDQogICAgICAgICAgIGFuIGVsZW1lbnQgZm9yIG9wZXJh dGlvbnMgKGZvciBkZXRhaWxzLCBzZWUgdGhlIHByb3RvY29sKS4gDQogICAgICAgDQogICAgICAg IC4gSW4gYW55IGluc3RhbmNlIG9mIHRoZSBhcnJheSwgZWFjaCBkZWNsYXJlZCBrZXkgbXVzdCBi ZSANCiAgICAgICAgICAgdW5pcXVlIHdpdGhpbiB0aGF0IGluc3RhbmNlLiAgTm8gdHdvIGVsZW1l bnRzIG9mIGFuIGFycmF5IG1heSANCiAgICAgICAgICAgaGF2ZSB0aGUgc2FtZSB2YWx1ZXMgb24g YWxsIHRoZSBmaWVsZHMgd2hpY2ggbWFrZSB1cCBhIGtleS4gDQogICAgICAgDQogICAgICBFYWNo IGtleSBpcyBkZWNsYXJlZCB3aXRoIGEga2V5SUQgZm9yIHVzZSBpbiB0aGUgcHJvdG9jb2wsIHdo ZXJlIA0KICAgICAgdGhlIHVuaXF1ZSBrZXkgaXMgZm9ybWVkIGJ5IGNvbWJpbmluZyBvbmUgb3Ig bW9yZSBzcGVjaWZpZWQga2V5IA0KICAgICAgZmllbGRzLiAgVG8gc3VwcG9ydCB0aGUgY2FzZSB3 aGVyZSBhbiBhcnJheSBvZiBhbiBhdG9taWMgdHlwZSB3aXRoIA0KICAgICAgdW5pcXVlIHZhbHVl cyBjYW4gYmUgcmVmZXJlbmNlZCBieSB0aG9zZSB2YWx1ZXMsIHRoZSBrZXkgZmllbGQgDQogICAg ICBpZGVudGlmaWVyIG1heSBiZSAiKiIgKGkuZS4sIHRoZSBhcnJheSBlbnRyeSBpcyB0aGUga2V5 KS4gIElmIHRoZSANCiAgICAgIHZhbHVlIHR5cGUgb2YgdGhlIGFycmF5IGlzIGEgc3RydWN0dXJl IG9yIGFuIGFycmF5LCB0aGVuIHRoZSBrZXkgDQogICAgICBpcyBvbmUgb3IgbW9yZSBmaWVsZHMs IGVhY2ggaWRlbnRpZmllZCBieSBuYW1lLiAgU2luY2UgdGhlIGZpZWxkIA0KICAgICAgbWF5IGJl IGFuIGVsZW1lbnQgb2YgdGhlIHN0cnVjdHVyZSwgdGhlIGVsZW1lbnQgb2YgYW4gZWxlbWVudCBv ZiBhIA0KICAgICAgc3RydWN0dXJlLCBvciBmdXJ0aGVyIG5lc3RlZCwgdGhlIGZpZWxkIG5hbWUg aXMgYWN0dWFsbHkgYSANCiAgICAgIGNvbmNhdGVuYXRlZCBzZXF1ZW5jZSBvZiBwYXJ0IGlkZW50 aWZpZXJzLCBzZXBhcmF0ZWQgYnkgZGVjaW1hbCANCiAgICAgIHBvaW50cyAoky6UKS4gIFRoZSBz eW50YXggZm9yIGtleSBmaWVsZCBpZGVudGlmaWNhdGlvbiBpcyBnaXZlbiANCiAgICAgIGZvbGxv d2luZyB0aGUgYXJyYXkgZXhhbXBsZXMuIA0KICAgICAgIA0KDQogICAgDQogICBZYW5nLCBldCBh bC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug NDRdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAg ICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoZSBmb2xsb3dpbmcgZXhhbXBs ZSBzaG93cyB0aGUgZGVmaW5pdGlvbiBvZiBhIGZpeGVkIHNpemUgYXJyYXkgDQogICAgICB3aXRo IGEgcHJlLWRlZmluZWQgZGF0YSB0eXBlIGFzIHRoZSBhcnJheSBlbGVtZW50czogDQogICAgICAg DQogICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICA8bmFtZT5kc2NwLW1hcHBpbmctdGFibGU8 L25hbWU+IA0KICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgIEEgdGFibGUgb2YgNjQgRFND UCB2YWx1ZXMsIHVzZWQgdG8gcmUtbWFwIGNvZGUgc3BhY2UuIA0KICAgICAgICA8L3N5bm9wc2lz PiANCiAgICAgICAgPGFycmF5IHR5cGU9ImZpeGVkLXNpemUiIGxlbmd0aD0iNjQiPiANCiAgICAg ICAgICAgIDx0eXBlUmVmPmRzY3A8L3R5cGVSZWY+IA0KICAgICAgICA8L2FycmF5PiANCiAgICAg IDwvZGF0YVR5cGVEZWY+IA0KICAgICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGRl ZmluZXMgYSB2YXJpYWJsZSBzaXplIGFycmF5IHdpdGggYW4gdXBwZXIgDQogICAgICBsaW1pdCBv biBpdHMgc2l6ZTogDQogICAgICAgDQogICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICA8bmFt ZT5tYWMtYWxpYXMtdGFibGU8L25hbWU+IA0KICAgICAgICA8c3lub3BzaXM+QSB0YWJsZSB3aXRo IHVwIHRvIDggSUVFRSBNQUMgYWRkcmVzc2VzPC9zeW5vcHNpcz4gDQogICAgICAgIDxhcnJheSB0 eXBlPSJ2YXJpYWJsZS1zaXplIiBtYXgtbGVuZ3RoPSI4Ij4gDQogICAgICAgICAgICA8dHlwZVJl Zj5pZWVlbWFjYWRkcjwvdHlwZVJlZj4gDQogICAgICAgIDwvYXJyYXk+IA0KICAgICAgPC9kYXRh VHlwZURlZj4gDQogICAgDQogICAgICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhlIGRl ZmluaXRpb24gb2YgYW4gYXJyYXkgd2l0aCBhIA0KICAgICAgbG9jYWwgKHVubmFtZWQpIHR5cGUg ZGVmaW5pdGlvbjogDQogICAgICAgDQogICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICA8bmFt ZT5jbGFzc2lmaWNhdGlvbi10YWJsZTwvbmFtZT4gDQogICAgICAgIDxzeW5vcHNpcz4gDQogICAg ICAgICAgQSB0YWJsZSBvZiBjbGFzc2lmaWNhdGlvbiBydWxlcyBhbmQgcmVzdWx0IG9wY29kZXMu IA0KICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgPGFycmF5IHR5cGU9InZhcmlhYmxlLXNp emUiPiANCiAgICAgICAgICA8c3RydWN0PiANCiAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJ RD2UMZQ+IA0KICAgICAgICAgICAgICA8bmFtZT5ydWxlPC9uYW1lPiANCiAgICAgICAgICAgICAg PHN5bm9wc2lzPlRoZSBydWxlIHRvIG1hdGNoPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgIDx0 eXBlUmVmPmNsYXNzcnVsZTwvdHlwZVJlZj4gDQogICAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAg ICAgICAgICAgPGVsZW1lbnQgk2VsZW1lbnRJRD2UMpQ+IA0KICAgICAgICAgICAgICA8bmFtZT5v cGNvZGU8L25hbWU+IA0KICAgICAgICAgICAgICA8c3lub3BzaXM+VGhlIHJlc3VsdCBjb2RlPC9z eW5vcHNpcz4gDQogICAgICAgICAgICAgIDx0eXBlUmVmPm9wY29kZTwvdHlwZVJlZj4gDQogICAg ICAgICAgICA8L2VsZW1lbnQ+IA0KICAgICAgICAgIDwvc3RydWN0PiANCiAgICAgICAgPC9hcnJh eT4gDQogICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4 cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA0NV0gDQoMICAg SW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3Vz dCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgIA0KICAgICAgSW4gdGhlIGFib3ZlIGV4YW1wbGUs IGVhY2ggZW50cnkgb2YgdGhlIGFycmF5IGlzIGEgPHN0cnVjdD4gb2YgdHdvIA0KICAgICAgZmll bGRzICgicnVsZSIgYW5kICJvcGNvZGUiKS4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93aW5n IGV4YW1wbGUgc2hvd3MgYSB0YWJsZSBvZiBJUCBQcmVmaXggaW5mb3JtYXRpb24gdGhhdCANCiAg ICAgIGNhbiBiZSBhY2Nlc3NlZCBieSBhIG11bHRpLWZpZWxkIGNvbnRlbnQga2V5IG9uIHRoZSBJ UCBBZGRyZXNzIGFuZCANCiAgICAgIHByZWZpeCBsZW5ndGguICBUaGlzIG1lYW5zIHRoYXQgaW4g YW55IGluc3RhbmNlIG9mIHRoaXMgdGFibGUsIG5vIA0KICAgICAgdHdvIGVudHJpZXMgY2FuIGhh dmUgdGhlIHNhbWUgSVAgYWRkcmVzcyBhbmQgcHJlZml4IGxlbmd0aC4gDQogICAgICAgDQogICAg ICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICA8bmFtZT5pcFByZWZpeEluZm9fdGFibGU8L25hbWU+ IA0KICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgIEEgdGFibGUgb2YgaW5mb3JtYXRpb24g YWJvdXQga25vd24gcHJlZml4ZXMgDQogICAgICAgIDwvc3lub3BzaXM+IA0KICAgICAgICA8YXJy YXkgdHlwZT2UdmFyaWFibGUtc2l6ZZQ+IA0KICAgICAgICAgIDxzdHJ1Y3Q+IA0KICAgICAgICAg ICAgPGVsZW1lbnQgZWxlbWVudElEPZQxlD4gDQogICAgICAgICAgICAgIDxuYW1lPmFkZHJlc3Mt cHJlZml4PC9uYW1lPiANCiAgICAgICAgICAgICAgPHN5bm9wc2lzPnRoZSBwcmVmaXggYmVpbmcg ZGVzY3JpYmVkPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgIDx0eXBlUmVmPmlwdjRQcmVmaXg8 L3R5cGVSZWY+IA0KICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgIDxlbGVtZW50 IGVsZW1lbnRJRD2UMpQ+IA0KICAgICAgICAgICAgICA8bmFtZT5zb3VyY2U8L25hbWU+IA0KICAg ICAgICAgICAgICA8c3lub3BzaXM+d2hlcmUgaXMgdGhpcyBmcm9tPC9zeW5vcHNpcz4gDQogICAg ICAgICAgICAgIDx0eXBlUmVmPnVpbnQxNjwvdHlwZVJlZj4gDQogICAgICAgICAgICA8L2VsZW1l bnQ+IA0KICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPZQzlD4gDQogICAgICAgICAgICAg IDxuYW1lPnByZWZJbmZvPC9uYW1lPiANCiAgICAgICAgICAgICAgPHN5bm9wc2lzPnRoZSBpbmZv cm1hdGlvbiB3ZSBjYXJlIGFib3V0PC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgIDx0eXBlUmVm Pmh5cG90aGV0aWNhbC1pbmZvLXR5cGU8L3R5cGVSZWY+IA0KICAgICAgICAgICAgPC9lbGVtZW50 PiANCiAgICAgICAgICA8L3N0cnVjdD4gDQogICAgICAgICAgPGtleSBrZXlJRD2UMZQ+IA0KICAg ICAgICAgICAgPGtleUZpZWxkPiBhZGRyZXNzLXByZWZpeC5pcHY0YWRkciA8L2tleUZpZWxkPiAN CiAgICAgICAgICAgIDxrZXlGaWVsZD4gYWRkcmVzcy1wcmVmaXgucHJlZml4bGVuIDwva2V5Rmll bGQ+IA0KICAgICAgICAgICAgPGtleUZpZWxkPiBzb3VyY2UgPC9rZXlGaWVsZD4gDQogICAgICAg ICAgPC9rZXk+IA0KICAgICAgICA8L2FycmF5PiANCiAgICAgIDwvZGF0YVR5cGVEZWY+IA0KICAg ICAgIA0KICAgICAgTm90ZSB0aGF0IHRoZSBrZXlGaWVsZCBlbGVtZW50cyBjb3VsZCBhbHNvIGhh dmUgYmVlbiBzaW1wbHkgDQogICAgICBhZGRyZXNzLXByZWZpeCBhbmQgc291cmNlLCBzaW5jZSBh bGwgb2YgdGhlIGZpZWxkcyBvZiBhZGRyZXNzLQ0KICAgICAgcHJlZml4IGFyZSBiZWluZyB1c2Vk LiANCiAgICANCiAgIDQuNS4zLjEgS2V5IEZpZWxkIFJlZmVyZW5jZXMgDQogICAgICBJbiBvcmRl ciB0byB1c2Uga2V5IGRlY2xhcmF0aW9ucywgb25lIG11c3QgcmVmZXIgdG8gZmllbGRzIHRoYXQg DQogICAgICBhcmUgcG90ZW50aWFsbHkgbmVzdGVkIGluc2lkZSBvdGhlciBmaWVsZHMgaW4gdGhl IGFycmF5LiAgSWYgdGhlcmUgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1 Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNDZdIA0KDCAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSAN CiAgICANCiAgICANCiAgICAgIGFyZSBuZXN0ZWQgYXJyYXlzLCBvbmUgbWlnaHQgZXZlbiB1c2Ug YW4gYXJyYXkgZWxlbWVudCBhcyBhIGtleSANCiAgICAgIChidXQgZ3JlYXQgY2FyZSB3b3VsZCBi ZSBuZWVkZWQgdG8gZW5zdXJlIHVuaXF1ZW5lc3MuKSANCiAgICAgICANCiAgICAgIFRoZSBrZXkg aXMgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSB2YWx1ZXMgb2YgZWFjaCBmaWVsZCBkZWNsYXJlZCBp biANCiAgICAgIGEga2V5RmllbGQgZWxlbWVudC4gDQogICAgICAgDQogICAgICBUaGVyZWZvcmUs IHRoZSB2YWx1ZSBvZiBhIGtleUZpZWxkIGVsZW1lbnQgaXMgZGVmaW5lZCBhcyBhIA0KICAgICAg Y29uY2F0ZW5hdGVkIFNlcXVlbmNlIG9mIGZpZWxkIGlkZW50aWZpZXJzLCBzZXBhcmF0ZWQgYnkg YSAiLiIgDQogICAgICAocGVyaW9kKSBjaGFyYWN0ZXIuICBXaGl0ZXNwYWNlIGlzIHBlcm1pdHRl ZCBhbmQgaWdub3JlZC4gDQogICAgICAgDQogICAgICBBIHZhbGlkIHN0cmluZyBmb3IgYSBzaW5n bGUgZmllbGQgaWRlbnRpZmllciB3aXRoaW4gYSBrZXlGaWVsZCANCiAgICAgIGRlcGVuZHMgdXBv biB0aGUgY3VycmVudCBjb250ZXh0LiAgSW5pdGlhbGx5LCBpbiBhbiBhcnJheSBrZXkgDQogICAg ICBkZWNsYXJhdGlvbiwgdGhlIGNvbnRleHQgaXMgdGhlIHR5cGUgb2YgdGhlIGFycmF5LiAgUHJv Z3Jlc3NpdmVseSwgDQogICAgICB0aGUgY29udGV4dCBpcyB3aGF0ZXZlciB0eXBlIGlzIHNlbGVj dGVkIGJ5IHRoZSBmaWVsZCBpZGVudGlmaWVycyANCiAgICAgIHByb2Nlc3NlZCBzbyBmYXIgaW4g dGhlIGN1cnJlbnQga2V5IGZpZWxkIGRlY2xhcmF0aW9uLiANCiAgICAgICANCiAgICAgIFdoZW4g dGhlIGN1cnJlbnQgY29udGV4dCBpcyBhbiBhcnJheSwgKGUuZy4sIHdoZW4gZGVjbGFyaW5nIGEg a2V5IA0KICAgICAgZm9yIGFuIGFycmF5IHdob3NlIGNvbnRlbnQgaXMgYW4gYXJyYXkpIHRoZW4g dGhlIG9ubHkgdmFsaWQgdmFsdWUgDQogICAgICBmb3IgdGhlIGZpZWxkIGlkZW50aWZpZXIgaXMg YW4gZXhwbGljaXQgbnVtYmVyLiANCiAgICAgICAgIA0KICAgICAgV2hlbiB0aGUgY3VycmVudCBj b250ZXh0IGlzIGEgc3RydWN0dXJlLCB0aGUgdmFsaWQgdmFsdWVzIGZvciB0aGUgDQogICAgICBm aWVsZCBpZGVudGlmaWVycyBhcmUgdGhlIG5hbWVzIG9mIHRoZSBlbGVtZW50cyBvZiB0aGUgc3Ry dWN0dXJlLiAgDQogICAgICBJbiB0aGUgc3BlY2lhbCBjYXNlIG9mIGRlY2xhcmluZyBhIGtleSBm b3IgYW4gYXJyYXkgY29udGFpbmluZyBhbiANCiAgICAgIGF0b21pYyB0eXBlLCB3aGVyZSB0aGF0 IGNvbnRlbnQgaXMgdW5pcXVlIGFuZCBpcyB0byBiZSB1c2VkIGFzIGEgDQogICAgICBrZXksIHRo ZSB2YWx1ZSAiKiIgY2FuIGJlIHVzZWQgYXMgdGhlIHNpbmdsZSBrZXkgZmllbGQgaWRlbnRpZmll ci4gDQogICAgICAgDQogICA0LjUuNC4gPHN0cnVjdD4gRWxlbWVudCB0byBEZWZpbmUgU3RydWN0 dXJlcyANCiAgICAgICANCiAgICAgIEEgc3RydWN0dXJlIGlzIGNvbXByaXNlZCBvZiBhIGNvbGxl Y3Rpb24gb2YgZGF0YSBlbGVtZW50cy4gIEVhY2ggDQogICAgICBkYXRhIGVsZW1lbnQgaGFzIGEg ZGF0YSB0eXBlIChlaXRoZXIgYW4gYXRvbWljIHR5cGUgb3IgYW4gZXhpc3RpbmcgDQogICAgICBj b21wb3VuZCB0eXBlKSBhbmQgaXMgYXNzaWduZWQgYSBuYW1lIHVuaXF1ZSB3aXRoaW4gdGhlIHNj b3BlIG9mIA0KICAgICAgdGhlIGNvbXBvdW5kIGRhdGEgdHlwZSBiZWluZyBkZWZpbmVkLiAgVGhl c2Ugc2VydmUgdGhlIHNhbWUgDQogICAgICBmdW5jdGlvbiBhcyAic3RydWN0IiBpbiBDLCBldGMu ICAgDQogICAgICAgDQogICAgICBUaGUgYWN0dWFsIHR5cGUgb2YgdGhlIGZpZWxkIGNhbiBiZSBk ZWZpbmVkIGJ5IHJlZmVycmluZyB0byBhbiANCiAgICAgIGV4aXN0aW5nIHR5cGUgKHVzaW5nIHRo ZSA8dHlwZURlZj4gZWxlbWVudCksIG9yIGNhbiBiZSBhIGxvY2FsbHkgDQogICAgICBkZWZpbmVk ICh1bm5hbWVkKSB0eXBlIGNyZWF0ZWQgYnkgYW55IG9mIHRoZSA8YXRvbWljPiwgPGFycmF5Piwg DQogICAgICA8c3RydWN0Piwgb3IgPHVuaW9uPiBlbGVtZW50cy4gIA0KICAgICAgIA0KICAgICAg QSBzdHJ1Y3R1cmUgZGVmaW5pdGlvbiBpcyBhIHNlcmllcyBvZiBlbGVtZW50IGRlY2xhcmF0aW9u cy4gIEVhY2ggDQogICAgICBlbGVtZW50IGNhcnJpZXMgYW4gZWxlbWVudElEIGZvciB1c2UgYnkg dGhlIEZvckNFUyBwcm90b2NvbC4gSW4gDQogICAgICBhZGRpdGlvbiwgdGhlIGVsZW1lbnQgY29u dGFpbnMgdGhlIG5hbWUsIGEgc3lub3BzaXMsIGFuIG9wdGlvbmFsIA0KICAgICAgZGVzY3JpcHRp b24sIGFuIG9wdGlvbmFsIGRlY2xhcmF0aW9uIHRoYXQgdGhlIGVsZW1lbnQgaXRzZWxmIGlzIA0K ICAgICAgb3B0aW9uYWwsIGFuZCB0aGUgdHlwZVJlZiBkZWNsYXJhdGlvbiB0aGF0IHNwZWNpZmll cyB0aGUgZWxlbWVudCANCiAgICAgIHR5cGUuIA0KICAgICAgIA0KDQogICAgDQogICBZYW5nLCBl dCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNDddIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAg ICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIEZvciBhIGRhdGFUeXBlRGVm aW5pdGlvbiBvZiBhIHN0cnVjdCwgdGhlIHN0cnVjdHVyZSBkZWZpbml0aW9uIG1heSANCiAgICAg IGJlIGluaGVyaXRlZCBmcm9tLCBhbmQgYXVnbWVudCwgYSBwcmV2aW91c2x5IGRlZmluZWQgc3Ry dWN0dXJlZCANCiAgICAgIHR5cGUuICBUaGlzIGlzIGluZGljYXRlZCBieSBpbmNsdWRpbmcgdGhl IGRlcml2ZWRGcm9tIGF0dHJpYnV0ZSBvbiANCiAgICAgIHRoZSBzdHJ1Y3QgZGVjbGFyYXRpb24u IA0KICAgICAgIA0KICAgICAgVGhlIHJlc3VsdCBvZiB0aGlzIGNvbnN0cnVjdCBpcyBhbHdheXMg cmVnYXJkZWQgYSBjb21wb3VuZCB0eXBlLCANCiAgICAgIGV2ZW4gd2hlbiB0aGUgPHN0cnVjdD4g Y29udGFpbnMgb25seSBvbmUgZmllbGQuIA0KICAgICAgIA0KICAgICAgQW4gZXhhbXBsZTogDQog ICAgICAgDQogICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICA8bmFtZT5pcHY0cHJlZml4PC9u YW1lPiANCiAgICAgICAgPHN5bm9wc2lzPiANCiAgICAgICAgICBJUHY0IHByZWZpeCBkZWZpbmVk IGJ5IGFuIGFkZHJlc3MgYW5kIGEgcHJlZml4IGxlbmd0aCANCiAgICAgICAgPC9zeW5vcHNpcz4g DQogICAgICAgIDxzdHJ1Y3Q+IA0KICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD2UMZQ+IA0K ICAgICAgICAgICAgPG5hbWU+YWRkcmVzczwvbmFtZT4gDQogICAgICAgICAgICA8c3lub3BzaXM+ QWRkcmVzcyBwYXJ0PC9zeW5vcHNpcz4gDQogICAgICAgICAgICA8dHlwZVJlZj5pcHY0YWRkcjwv dHlwZVJlZj4gDQogICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICA8ZWxlbWVudCBlbGVt ZW50SUQ9lDKUPiANCiAgICAgICAgICAgIDxuYW1lPnByZWZpeGxlbjwvbmFtZT4gDQogICAgICAg ICAgICA8c3lub3BzaXM+UHJlZml4IGxlbmd0aCBwYXJ0PC9zeW5vcHNpcz4gDQogICAgICAgICAg ICA8YXRvbWljPiANCiAgICAgICAgICAgICAgPGJhc2VUeXBlPnVjaGFyPC9iYXNlVHlwZT4gDQog ICAgICAgICAgICAgIDxyYW5nZVJlc3RyaWN0aW9uPiANCiAgICAgICAgICAgICAgICA8YWxsb3dl ZFJhbmdlIG1pbj0iMCIgbWF4PSIzMiIvPiANCiAgICAgICAgICAgICAgPC9yYW5nZVJlc3RyaWN0 aW9uPiANCiAgICAgICAgICAgIDwvYXRvbWljPiANCiAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAg ICAgICA8L3N0cnVjdD4gDQogICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICANCiAgIDQuNS41LiA8 dW5pb24+IEVsZW1lbnQgdG8gRGVmaW5lIFVuaW9uIFR5cGVzIA0KICAgICAgIA0KICAgICAgU2lt aWxhciB0byB0aGUgdW5pb24gZGVjbGFyYXRpb24gaW4gQywgdGhpcyBjb25zdHJ1Y3QgYWxsb3dz IHRoZSANCiAgICAgIGRlZmluaXRpb24gb2Ygb3ZlcmxheSB0eXBlcy4gIEl0cyBmb3JtYXQgaXMg aWRlbnRpY2FsIHRvIHRoZSANCiAgICAgIDxzdHJ1Y3Q+IGVsZW1lbnQuIA0KICAgICAgIA0KICAg ICAgVGhlIHJlc3VsdCBvZiB0aGlzIGNvbnN0cnVjdCBpcyBhbHdheXMgcmVnYXJkZWQgYSBjb21w b3VuZCB0eXBlLCANCiAgICAgIGV2ZW4gd2hlbiB0aGUgdW5pb24gY29udGFpbnMgb25seSBvbmUg ZWxlbWVudC4gDQogICAgDQogICA0LjUuNiA8YWxpYXM+IEVsZW1lbnQgDQogICAgDQogICAgICBJ dCBpcyBzb21ldGltZXMgbmVjZXNzYXJ5IHRvIGhhdmUgYW4gZWxlbWVudCBpbiBhbiBMRkIgb3Ig DQogICAgICBzdHJ1Y3R1cmUgcmVmZXIgdG8gaW5mb3JtYXRpb24gaW4gb3RoZXIgTEZCcy4gIFRo ZSA8YWxpYXM+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAw NSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQ4XSANCgwgICBJbnRlcm5ldCBEcmFmdCAg ICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQog ICAgDQogICAgICBkZWNsYXJhdGlvbiBjcmVhdGVzIHRoZSBjb25zdHJ1Y3RzIGZvciB0aGlzLiAg QW4gPGFsaWFzPiBlbGVtZW50IA0KICAgICAgY3JlYXRlcyBhIHN0cnVjdHVyZSB3aXRoIGZpZWxk cyB0byBjb250cm9sIHRoZSBhbGlhcyBhbmQgYSBmaWVsZCANCiAgICAgIHRvIGFjY2VzcyB0aGUg YWxpYXNlZCBpbmZvcm1hdGlvbi4gICANCiAgICAgICANCiAgICAgIEFuIDxhbGlhcz4gZGVjbGFy YXRpb24gaXMgdXNlZCB3aGVyZXZlciBhIHR5cGUgcmVmZXJlbmNlIGNhbiANCiAgICAgIG9jY3Vy LCBqdXN0IGxpa2UgYSA8c3RydWN0PiBvciA8YXJyYXk+LiAgQSB0eXBpY2FsIGFsaWFzIHVzYWdl IA0KICAgICAgd291bGQgbG9vayBsaWtlOiANCiAgICAgICANCiAgICAgIDxkYXRhVHlwZURlZj4g DQogICAgICAgIDxuYW1lPmFuQWxpYXNlZFZhcmlhYmxlPC9uYW1lPiANCiAgICAgICAgPHN5bm9w c2lzPmEgcmVmZXJlbmNlIHRvIHNvbWV0aGluZywgc29tZXdoZXJlPC9zeW5vcHNpcz4gDQogICAg ICAgIDxhbGlhcz50aGUtdW5kZXJseWluZy10eXBlPC9hbGlhcz4gDQogICAgICA8L2RhdGFUeXBl RGVmPiANCiAgICAgICANCiAgICAgIFRoaXMgZGVmaW5pdGlvbiBkZWNsYXJlcyBhIHR5cGUgdG8g YmUgdXNlZCBmb3IgYW4gYWxpYXMgdG8gdGhpbmdzIA0KICAgICAgb2YgdHlwZSCTdGhlLXVuZGVy bHlpbmctdHlwZZQuICBUaGlzIHdvdWxkIG1vcmUgbGlrZWx5IG9jY3VyIA0KICAgICAgaW5zaWRl IGEgc3RydWN0dXJlIHJhdGhlciB0aGFuIGRpcmVjdGx5IGluIGEgZGF0YVR5cGVEZWYuIA0KICAg ICAgIA0KICAgICAgQW4gYWxpYXMgaXMgYSBjb21wbGV4IHN0cnVjdHVyZSBpbiBvcmRlciB0byBo b2xkIHRoZSBwaWVjZXMgDQogICAgICBuZWNlc3NhcnkgdG8gbWFrZSBpdCB1c2VmdWwuICBJZiAi YWxpYXMiIHdhcyBhbiBhY3R1YWwgZGVjbGFyZWQgDQogICAgICBzdHJ1Y3R1cmUsIGFuZCBpZiAi dGllZFJlZmVyZW5jZSIgd2FzIGEgdXNhYmxlIHR5cGUsIHRoZSBzdHJ1Y3R1cmUgDQogICAgICBk ZWNsYXJhdGlvbiB3b3VsZCBsb29rIGxpa2U6IA0KICAgICAgIA0KICAgICAgPGRhdGFUeXBlRGVm PiANCiAgICAgICAgPG5hbWU+YWxpYXM8L25hbWU+IA0KICAgICAgICA8c3lub3BzaXM+YSByZWZl cmVuY2UgdG8gaW5mb3JtYXRpb24gaW4gYW5vdGhlciBMRkI8L3N5bm9wc2lzPiANCiAgICAgICAg PHN0cnVjdD4gDQogICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPZQxlD4gDQogICAgICAgICAg ICA8bmFtZT5yZWZlcmVuY2VDbGFzczwvbmFtZT4gDQogICAgICAgICAgICA8c3lub3BzaXM+IA0K ICAgICAgICAgICAgICBUaGUgY2xhc3Mgb2YgTEZCIHRoaXMgYWxpYXMgaXMgY3VycmVudGx5IHBv aW50aW5nIHRvIA0KICAgICAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICA8dHlwZVJl Zj51aW50MzI8L3R5cGVSZWY+IA0KICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgPGVs ZW1lbnQgZWxlbWVudElEPZQylD4gDQogICAgICAgICAgICA8bmFtZT5yZWZlcmVuY2VJbnN0YW5j ZTwvbmFtZT4gDQogICAgICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgICBUaGUgTEZC IEluc3RhbmNlIHRoaXMgYWxpYXMgaXMgY3VycmVudGx5IHBvaW50aW5nIHRvIA0KICAgICAgICAg ICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+IA0K ICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPZQzlD4g DQogICAgICAgICAgICA8bmFtZT5yZWZlcmVuY2VQYXRoPC9uYW1lPiANCiAgICAgICAgICAgIDxz eW5vcHNpcz4gDQogICAgICAgICAgICAgIFRoZSBwYXRoIHRvIHRoZSBMRkIgZmllbGQgdGhpcyBh bGlhcyBpcyBjdXJyZW50bHkgDQogICAgICAgICAgICAgIHBvaW50aW5nIHRvIA0KICAgICAgICAg ICAgPC9zeW5vcHNpcz4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3Vz dCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNDldIA0KDCAgIEludGVybmV0IERy YWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAg ICANCiAgICANCiAgICAgICAgICAgIDx0eXBlUmVmKW9jdGV0U3RyaW5nWzEyOF08L3R5cGVSZWY+ IA0KICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPZQ0 lD4gDQogICAgICAgICAgICA8bmFtZT5yZWZlcmVuY2VDbGFzczwvbmFtZT4gDQogICAgICAgICAg ICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgICBUaGUgZWxlbWVudCB0byB1c2UgdG8gZm9sbG93 IHRoZSBhbGlhcyANCiAgICAgICAgICAgIDwvc3lub3BzaXM+IA0KICAgICAgICAgICAgPHR5cGVS ZWY+dGllZFJlZmVyZW5jZTwvdHlwZVJlZj4gDQogICAgICAgICAgPC9lbGVtZW50PiANCiAgICAg ICAgPC9zdHJ1Y3Q+IA0KICAgICAgPC9kYXRhVHlwZURlZj4gDQogICAgICAgDQogICAgICBUaGUg cmVmZXJlbmNlUGF0aCBpcyB0aGUgaWRlbnRpZmllciBpbiB0aGUgZm9ybSB1c2VkIGJ5IHRoZSBG b3JDRVMgDQogICAgICBwcm90b2NvbCBmb3IgdGhlIGFjdHVhbCBmaWVsZCBiZWluZyByZWZlcmVu Y2VkLiAgSXRzIHR5cGUgbXVzdCBiZSANCiAgICAgIHRoZSBzYW1lIGFzIHRoZSB0eXBlIGRlY2xh cmVkIGZvciB0aGUgYWxpYXMuIChBbmQgdGhlIEZFIE1VU1QgDQogICAgICBlbnN1cmUgdGhlIHR5 cGVzIGFyZSB0aGUgc2FtZSBvbiBhbnkgZWZmb3J0IHRvIHNldCB0aGUgDQogICAgICByZWZlcmVu Y2VDbGFzcywgcmVmZXJlbmNlSW5zdGFuY2UsIG9yIHJlZmVyZW5jZVBhdGggZWxlbWVudHMpLiAg DQogICAgICBOb3RlIHRoYXQgIjEyOCIgaXMgdGhlIGxlbmd0aCBsaW1pdCBmb3IgcGF0aHMgaW4g dGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sLikgIFRodXMsIGJ5IHNldHRpbmcgdGhlIHRocmVl IGNvbnRyb2wgZmllbGRzLCB0aGUgQ0UgDQogICAgICBjb250cm9scyB3aGljaCBMRkIgYW5kIHRo ZSBmaWVsZCBpbiB0aGF0IExGQiwgdGhlIGFsaWFzIGRhdGEgDQogICAgICBwb2ludHMgdG8uICBU eXBpY2FsbHksIHRoaXMgd2lsbCBiZSBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhlIExGQiANCiAg ICAgIGNvbnRhaW5pbmcgdGhlIGVsZW1lbnQgd2l0aCBhbiA8YWxpYXM+IGRlY2xhcmF0aW9uLiAN CiAgICANCiAgIDQuNS42LiBBdWdtZW50YXRpb25zIA0KICAgICAgIA0KICAgICAgQ29tcG91bmQg dHlwZXMgY2FuIGFsc28gYmUgZGVmaW5lZCBhcyBhdWdtZW50YXRpb25zIG9mIGV4aXN0aW5nIA0K ICAgICAgY29tcG91bmQgdHlwZXMuICBJZiB0aGUgZXhpc3RpbmcgY29tcG91bmQgdHlwZSBpcyBh IHN0cnVjdHVyZSwgDQogICAgICBhdWdtZW50YXRpb24gbWF5IGFkZCBuZXcgZWxlbWVudHMgdG8g dGhlIHR5cGUuICBUaGUgdHlwZSBvZiBhbiANCiAgICAgIGV4aXN0aW5nIGVsZW1lbnQgY2FuIG9u bHkgYmUgcmVwbGFjZWQgd2l0aCBhbiBhdWdtZW50YXRpb24gZGVyaXZlZCANCiAgICAgIGZyb20g dGhlIGN1cnJlbnQgdHlwZSwgYW4gZXhpc3RpbmcgZWxlbWVudCBjYW5ub3QgYmUgZGVsZXRlZC4g IElmIA0KICAgICAgdGhlIGV4aXN0aW5nIGNvbXBvdW5kIHR5cGUgaXMgYW4gYXJyYXksIGF1Z21l bnRhdGlvbiBtZWFucyANCiAgICAgIGF1Z21lbnRhdGlvbiBvZiB0aGUgYXJyYXkgZWxlbWVudCB0 eXBlLiANCiAgICAgICANCiAgICAgIE9uZSBjb25zZXF1ZW5jZSBvZiB0aGlzIGlzIHRoYXQgYXVn bWVudGF0aW9ucyBhcmUgY29tcGF0aWJsZSB3aXRoIA0KICAgICAgdGhlIGNvbXBvdW5kIHR5cGUg ZnJvbSB3aGljaCB0aGV5IGFyZSBkZXJpdmVkLiAgQXMgc3VjaCwgDQogICAgICBhdWdtZW50YXRp b25zIGFyZSB1c2VmdWwgaW4gZGVmaW5pbmcgYXR0cmlidXRlcyBmb3IgTEZCIHN1YmNsYXNzZXMg DQogICAgICB3aXRoIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuICBJbiBhZGRpdGlvbiB0byBhZGRp bmcgbmV3IGF0dHJpYnV0ZXMgDQogICAgICB0byBhIGNsYXNzLCB0aGUgZGF0YSB0eXBlIG9mIGFu IGV4aXN0aW5nIGF0dHJpYnV0ZSBtYXkgYmUgcmVwbGFjZWQgDQogICAgICBieSBhbiBhdWdtZW50 YXRpb24gb2YgdGhhdCBhdHRyaWJ1dGUsIGFuZCBzdGlsbCBtZWV0IHRoZSANCiAgICAgIGNvbXBh dGliaWxpdHkgcnVsZXMgZm9yIHN1YmNsYXNzZXMuICAgDQogICAgICAgDQogICAgICBGb3IgZXhh bXBsZSwgY29uc2lkZXIgYSBzaW1wbGUgYmFzZSBMRkIgY2xhc3MgQSB0aGF0IGhhcyBvbmx5IG9u ZSANCiAgICAgIGF0dHJpYnV0ZSAoYXR0cjEpIG9mIHR5cGUgWC4gIE9uZSB3YXkgdG8gZGVyaXZl IGNsYXNzIEExIGZyb20gQSANCiAgICAgIGNhbiBiZSBieSBzaW1wbHkgYWRkaW5nIGEgc2Vjb25k IGF0dHJpYnV0ZSAob2YgYW55IHR5cGUpLiAgQW5vdGhlciANCiAgICAgIHdheSB0byBkZXJpdmUg YSBjbGFzcyBBMiBmcm9tIEEgY2FuIGJlIGJ5IHJlcGxhY2luZyB0aGUgb3JpZ2luYWwgDQogICAg ICBhdHRyaWJ1dGUgKGF0dHIxKSBpbiBBIG9mIHR5cGUgWCB3aXRoIG9uZSBvZiB0eXBlIFksIHdo ZXJlIFkgaXMgYW4gDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0 IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1MF0gDQoMICAgSW50ZXJuZXQgRHJh ZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAg IA0KICAgIA0KICAgICAgYXVnbWVudGF0aW9uIG9mIFguICBCb3RoIGNsYXNzZXMgQTEgYW5kIEEy IGFyZSBiYWNrd2FyZCBjb21wYXRpYmxlIA0KICAgICAgd2l0aCBjbGFzcyBBLiANCiAgICAgICAN CiAgICAgIFRoZSBzeW50YXggZm9yIGF1Z21lbnRhdGlvbnMgaXMgdG8gaW5jbHVkZSBhIGRlcml2 ZWRGcm9tIGF0dHJpYnV0ZSANCiAgICAgIGluIGEgc3RydWN0dXJlIGRlZmluaXRpb24sIGluZGlj YXRpbmcgd2hhdCBzdHJ1Y3R1cmUgdHlwZSBpcyBiZWluZyANCiAgICAgIGF1Z21lbnRlZC4gIEVs ZW1lbnQgbmFtZXMgYW5kIGVsZW1lbnQgSURzIHdpdGhpbiB0aGUgYXVnbWVudGF0aW9uIA0KICAg ICAgbXVzdCBub3QgYmUgdGhlIHNhbWUgYXMgdGhvc2UgaW4gdGhlIHN0cnVjdHVyZSB0eXBlIGJl aW5nIA0KICAgICAgYXVnbWVudGVkLiANCiAgICAgICANCiAgICAgIFtFRElUT1I6IFRoaXMgaXMg YSBwcmVsaW1pbmFyeSBwcm9wb3NhbCBmb3IgaGFuZGxpbmcgYXVnbWVudGF0aW9uIA0KICAgICAg b2Ygc3RydWN0dXJlcy5dIA0KICAgIA0KICAgNC42LiA8bWV0YWRhdGFEZWZzPiBFbGVtZW50IGZv ciBNZXRhZGF0YSBEZWZpbml0aW9ucyANCiAgICANCiAgICAgIFRoZSAob3B0aW9uYWwpIDxtZXRh ZGF0YURlZnM+IGVsZW1lbnQgaW4gdGhlIGxpYnJhcnkgZG9jdW1lbnQgDQogICAgICBjb250YWlu cyBvbmUgb3IgbW9yZSA8bWV0YWRhdGFEZWY+IGVsZW1lbnRzLiAgRWFjaCA8bWV0YWRhdGFEZWY+ IA0KICAgICAgZWxlbWVudCBkZWZpbmVzIGEgbWV0YWRhdGEuIA0KICAgICAgIA0KICAgICAgRWFj aCA8bWV0YWRhdGFEZWY+IGVsZW1lbnQgY29udGFpbnMgYSB1bmlxdWUgbmFtZSAoTk1UT0tFTiku IA0KICAgICAgVW5pcXVlbmVzcyBpcyBkZWZpbmVkIHRvIGJlIG92ZXIgYWxsIG1ldGFkYXRhIGRl ZmluZWQgaW4gdGhpcyANCiAgICAgIGxpYnJhcnkgZG9jdW1lbnQgYW5kIGluIGFsbCBkaXJlY3Rs eSBvciBpbmRpcmVjdGx5IGluY2x1ZGVkIA0KICAgICAgbGlicmFyeSBkb2N1bWVudHMuIFRoZSA8 bWV0YWRhdGFEZWY+IGVsZW1lbnQgYWxzbyBjb250YWlucyBhIGJyaWVmIA0KICAgICAgc3lub3Bz aXMsIGFuIG9wdGlvbmFsIGRldGFpbGVkIGRlc2NyaXB0aW9uLCBhbmQgYSBjb21wdWxzb3J5IHR5 cGUgDQogICAgICBkZWZpbml0aW9uIGluZm9ybWF0aW9uLiBPbmx5IGF0b21pYyBkYXRhIHR5cGVz IGNhbiBiZSB1c2VkIGFzIA0KICAgICAgdmFsdWUgdHlwZXMgZm9yIG1ldGFkYXRhLiAgDQogICAg ICAgDQogICAgICBUd28gZm9ybXMgb2YgdHlwZSBkZWZpbml0aW9ucyBhcmUgYWxsb3dlZC4gVGhl IGZpcnN0IGZvcm0gdXNlcyB0aGUgDQogICAgICA8dHlwZVJlZj4gZWxlbWVudCB0byByZWZlciB0 byBhbiBleGlzdGluZyBhdG9taWMgZGF0YSB0eXBlIGRlZmluZWQgDQogICAgICBpbiB0aGUgPGRh dGFUeXBlRGVmcz4gZWxlbWVudCBvZiB0aGUgc2FtZSBsaWJyYXJ5IGRvY3VtZW50IG9yIGluIA0K ICAgICAgb25lIG9mIHRoZSBpbmNsdWRlZCBsaWJyYXJ5IGRvY3VtZW50cy4gVGhlIHVzYWdlIG9m IHRoZSA8dHlwZVJlZj4gDQogICAgICBlbGVtZW50IGlzIGlkZW50aWNhbCB0byBob3cgaXQgaXMg dXNlZCBpbiB0aGUgPGRhdGFUeXBlRGVmPiANCiAgICAgIGVsZW1lbnRzLCBleGNlcHQgaGVyZSBp dCBjYW4gb25seSByZWZlciB0byBhdG9taWMgdHlwZXMuIA0KICAgICAgIA0KICAgICAgW0VESVRP UjogVGhlIGxhdHRlciByZXN0cmljdGlvbiBpcyBub3QgeWV0IGVuZm9yY2VkIGJ5IHRoZSBYTUwg DQogICAgICBzY2hlbWEuXSANCiAgICAgICANCiAgICAgIFRoZSBzZWNvbmQgZm9ybSBpcyBhbiBl eHBsaWNpdCB0eXBlIGRlZmluaXRpb24gdXNpbmcgdGhlIDxhdG9taWM+IA0KICAgICAgZWxlbWVu dC4gVGhpcyBlbGVtZW50IGlzIHVzZWQgaGVyZSBpbiB0aGUgc2FtZSB3YXkgYXMgaW4gdGhlIA0K ICAgICAgPGRhdGFUeXBlRGVmPiBlbGVtZW50cy4gDQogICAgDQogICAgICBUaGUgZm9sbG93aW5n IGV4YW1wbGUgc2hvd3MgYm90aCB1c2FnZXM6IA0KICAgICAgICANCiAgICAgIDxtZXRhZGF0YURl ZnM+IA0KICAgICAgICA8bWV0YWRhdGFEZWY+IA0KICAgICAgICAgIDxuYW1lPk5FWFRIT1BJRDwv bmFtZT4gDQogICAgICAgICAgPHN5bm9wc2lzPlJlZmVycyB0byBhIE5leHQgSG9wIGVudHJ5IGlu IE5IIExGQjwvc3lub3BzaXM+IA0KICAgICAgICAgIDx0eXBlUmVmPmludDMyPC90eXBlUmVmPiAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA1MV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg ICA8L21ldGFkYXRhRGVmPiANCiAgICAgICAgPG1ldGFkYXRhRGVmPiANCiAgICAgICAgICA8bmFt ZT5DTEFTU0lEPC9uYW1lPiANCiAgICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgUmVz dWx0IG9mIGNsYXNzaWZpY2F0aW9uICgwIG1lYW5zIG5vIG1hdGNoKS4gDQogICAgICAgICAgPC9z eW5vcHNpcz4gDQogICAgICAgICAgPGF0b21pYz4gDQogICAgICAgICAgICA8YmFzZVR5cGU+aW50 MzI8L2Jhc2VUeXBlPiANCiAgICAgICAgICAgIDxzcGVjaWFsVmFsdWVzPiANCiAgICAgICAgICAg ICAgPHNwZWNpYWxWYWx1ZSB2YWx1ZT0iMCI+IA0KICAgICAgICAgICAgICAgIDxuYW1lPk5PTUFU Q0g8L25hbWU+IA0KICAgICAgICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICAgICAg ICBDbGFzc2lmaWNhdGlvbiBkaWRuknQgcmVzdWx0IGluIG1hdGNoLiANCiAgICAgICAgICAgICAg ICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgPC9zcGVjaWFsVmFsdWU+IA0KICAgICAgICAg ICAgPC9zcGVjaWFsVmFsdWVzPiANCiAgICAgICAgICA8L2F0b21pYz4gDQogICAgICAgIDwvbWV0 YWRhdGFEZWY+IA0KICAgICAgPC9tZXRhZGF0YURlZnM+IA0KICAgICAgIA0KICAgNC43LiA8TEZC Q2xhc3NEZWZzPiBFbGVtZW50IGZvciBMRkIgQ2xhc3MgRGVmaW5pdGlvbnMgDQogICAgICAgDQog ICAgICBUaGUgKG9wdGlvbmFsKSA8TEZCQ2xhc3NEZWZzPiBlbGVtZW50IGNhbiBiZSB1c2VkIHRv IGRlZmluZSBvbmUgb3IgDQogICAgICBtb3JlIExGQiBjbGFzc2VzIHVzaW5nIDxMRkJDbGFzc0Rl Zj4gZWxlbWVudHMuICBFYWNoIDxMRkJDbGFzc0RlZj4gDQogICAgICBlbGVtZW50IGRlZmluZXMg YW4gTEZCIGNsYXNzIGFuZCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIGVsZW1lbnRzOiANCiAgICAg ICAgLiA8bmFtZT4gcHJvdmlkZXMgdGhlIHN5bWJvbGljIG5hbWUgb2YgdGhlIExGQiBjbGFzcy4g IEV4YW1wbGU6IA0KICAgICAgICAgICJpcHY0bHBtIiANCiAgICAgICAgLiA8c3lub3BzaXM+IHBy b3ZpZGVzIGEgc2hvcnQgc3lub3BzaXMgb2YgdGhlIExGQiBjbGFzcy4gDQogICAgICAgICAgRXhh bXBsZTogIklQdjQgTG9uZ2VzdCBQcmVmaXggTWF0Y2ggTG9va3VwIExGQiIgDQogICAgICAgIC4g PHZlcnNpb24+IGlzIHRoZSB2ZXJzaW9uIGluZGljYXRvciANCiAgICAgICAgLiA8ZGVyaXZlZEZy b20+IGlzIHRoZSBpbmhlcml0YW5jZSBpbmRpY2F0b3IgDQogICAgICAgIC4gPGlucHV0UG9ydHM+ IGxpc3RzIHRoZSBpbnB1dCBwb3J0cyBhbmQgdGhlaXIgc3BlY2lmaWNhdGlvbnMgDQogICAgICAg IC4gPG91dHB1dFBvcnRzPiBsaXN0cyB0aGUgb3V0cHV0IHBvcnRzIGFuZCB0aGVpciBzcGVjaWZp Y2F0aW9ucyANCiAgICAgICAgLiA8YXR0cmlidXRlcz4gZGVmaW5lcyB0aGUgb3BlcmF0aW9uYWwg YXR0cmlidXRlcyBvZiB0aGUgTEZCIA0KICAgICAgICAuIDxjYXBhYmlsaXRpZXM+IGRlZmluZXMg dGhlIGNhcGFiaWxpdHkgYXR0cmlidXRlcyBvZiB0aGUgTEZCIA0KICAgICAgICAuIDxkZXNjcmlw dGlvbj4gY29udGFpbnMgdGhlIG9wZXJhdGlvbmFsIHNwZWNpZmljYXRpb24gb2YgdGhlIA0KICAg ICAgICAgIExGQiANCiAgICAgICAgLiBUaGUgTEZCQ2xhc3NJRCBhdHRyaWJ1dGUgb2YgdGhlIExG QkNsYXNzRGVmIGVsZW1lbnQgZGVmaW5lcyANCiAgICAgICAgICB0aGUgSUQgZm9yIHRoaXMgY2xh c3MuICBUaGVzZSBtdXN0IGJlIGdsb2JhbGx5IHVuaXF1ZS4gDQogICAgICAgDQogICAgICBbRURJ VE9SOiBMRkIgY2xhc3MgbmFtZXMgc2hvdWxkIGJlIHVuaXF1ZSBub3Qgb25seSBhbW9uZyBjbGFz c2VzIA0KICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFuZCBpbiBhbGwgaW5jbHVkZWQg ZG9jdW1lbnRzLCBidXQgYWxzbyANCiAgICAgIHVuaXF1ZSBhY3Jvc3MgYSBsYXJnZSBjb2xsZWN0 aW9uIG9mIGxpYnJhcmllcy4gIE9idmlvdXNseSBzb21lIA0KICAgICAgZ2xvYmFsIGNvbnRyb2wg aXMgbmVlZGVkIHRvIGVuc3VyZSBzdWNoIHVuaXF1ZW5lc3MuICBUaGlzIHN1YmplY3QgDQogICAg ICByZXF1aXJlcyBmdXJ0aGVyIHN0dWR5LiAgVGhlIHVuaXF1ZW5lc3Mgb2YgdGhlIGNsYXNzIElE cyBhbHNvIA0KICAgICAgcmVxdWlyZXMgZnVydGhlciBzdHVkeS5dIA0KICAgICAgIA0KICAgIA0K ICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDUyXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBN b2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBIZXJlIGlz IGEgc2tlbGV0b24gb2YgYW4gZXhhbXBsZSBMRkIgY2xhc3MgZGVmaW5pdGlvbjogDQogICAgICAg DQogICAgICA8TEZCQ2xhc3NEZWZzPiANCiAgICAgICAgPExGQkNsYXNzRGVmIExGQkNsYXNzSUQ9 lDEyMzQ1lD4gDQogICAgICAgICAgPG5hbWU+aXB2NGxwbTwvbmFtZT4gDQogICAgICAgICAgPHN5 bm9wc2lzPklQdjQgTG9uZ2VzdCBQcmVmaXggTWF0Y2ggTG9va3VwIExGQjwvc3lub3BzaXM+IA0K ICAgICAgICAgIDx2ZXJzaW9uPjEuMDwvdmVyc2lvbj4gDQogICAgICAgICAgPGRlcml2ZWRGcm9t PmJhc2VjbGFzczwvZGVyaXZlZEZyb20+IA0KICAgICAgIA0KICAgICAgICAgIDxpbnB1dFBvcnRz PiANCiAgICAgICAgICAgIC4uLiANCiAgICAgICAgICA8L2lucHV0UG9ydHM+IA0KICAgICAgIA0K ICAgICAgICAgIDxvdXRwdXRQb3J0cz4gDQogICAgICAgICAgICAuLi4gDQogICAgICAgICAgPC9v dXRwdXRQb3J0cz4gDQogICAgICAgDQogICAgICAgICAgPGF0dHJpYnV0ZXM+IA0KICAgICAgICAg ICAgLi4uIA0KICAgICAgICAgIDwvYXR0cmlidXRlcz4gDQogICAgICAgDQogICAgICAgICAgPGNh cGFiaWxpdGllcz4gDQogICAgICAgICAgICAuLi4gDQogICAgICAgICAgPC9jYXBhYmlsaXRpZXM+ IA0KICAgICAgIA0KICAgICAgICAgIDxkZXNjcmlwdGlvbj4gDQogICAgICAgICAgICBUaGlzIExG QiByZXByZXNlbnRzIHRoZSBJUHY0IGxvbmdlc3QgcHJlZml4IG1hdGNoIGxvb2t1cCANCiAgICAg ICAgICAgIG9wZXJhdGlvbi4gDQogICAgICAgICAgICBUaGUgbW9kZWxlZCBiZWhhdmlvciBpcyBh cyBmb2xsb3dzOiANCiAgICAgICAgICAgICAgIEJsYWgtYmxhaC1ibGFoLiANCiAgICAgICAgICA8 L2Rlc2NyaXB0aW9uPiANCiAgICAgICANCiAgICAgICAgPC9MRkJDbGFzc0RlZj4gDQogICAgICAg IC4uLiANCiAgICAgIDwvTEZCQ2xhc3NEZWZzPiANCiAgICAgICANCiAgICAgIFRoZSBpbmRpdmlk dWFsIGF0dHJpYnV0ZXMgYW5kIGNhcGFiaWxpdGllcyB3aWxsIGhhdmUgZWxlbWVudElEcyANCiAg ICAgIGZvciB1c2UgYnkgdGhlIEZvckNFUyBwcm90b2NvbC4gIFRoZXNlIHBhcmFsbGVsIHRoZSBl bGVtZW50SURzIA0KICAgICAgdXNlZCBpbiBzdHJ1Y3RzLCBhbmQgYXJlIHVzZWQgdGhlIHNhbWUg d2F5LiAgQXR0cmlidXRlIGFuZCANCiAgICAgIGNhcGFiaWxpdHkgZWxlbWVudElEcyBtdXN0IGJl IHVuaXF1ZSB3aXRoaW4gdGhlIExGQiBjbGFzcyANCiAgICAgIGRlZmluaXRpb24uIA0KICAgICAg IA0KICAgICAgTm90ZSB0aGF0IHRoZSA8bmFtZT4sIDxzeW5vcHNpcz4sIGFuZCA8dmVyc2lvbj4g ZWxlbWVudHMgYXJlIA0KICAgICAgcmVxdWlyZWQsIGFsbCBvdGhlciBlbGVtZW50cyBhcmUgb3B0 aW9uYWwgaW4gPExGQkNsYXNzRGVmPi4gDQogICAgICBIb3dldmVyLCB3aGVuIHRoZXkgYXJlIHBy ZXNlbnQsIHRoZXkgbXVzdCBvY2N1ciBpbiB0aGUgYWJvdmUgDQogICAgICBvcmRlci4gIA0KICAg ICAgICAgDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNTNdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAg ICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICAN CiAgIDQuNy4xLiA8ZGVyaXZlZEZyb20+IEVsZW1lbnQgdG8gRXhwcmVzcyBMRkIgSW5oZXJpdGFu Y2UgDQogICAgICAgDQogICAgICBUaGUgb3B0aW9uYWwgPGRlcml2ZWRGcm9tPiBlbGVtZW50IGNh biBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgDQogICAgICB0aGlzIGNsYXNzIGlzIGEgZGVyaXZh dGl2ZSBvZiBzb21lIG90aGVyIGNsYXNzLiAgVGhlIGNvbnRlbnQgb2YgDQogICAgICB0aGlzIGVs ZW1lbnQgbXVzdCBiZSB0aGUgdW5pcXVlIG5hbWUgKDxuYW1lPikgb2YgYW5vdGhlciBMRkIgDQog ICAgICBjbGFzcy4gIFRoZSByZWZlcnJlZCBMRkIgY2xhc3MgbXVzdCBiZSBkZWZpbmVkIGluIHRo ZSBzYW1lIGxpYnJhcnkgDQogICAgICBkb2N1bWVudCBvciBpbiBvbmUgb2YgdGhlIGluY2x1ZGVk IGxpYnJhcnkgZG9jdW1lbnRzLiANCiAgICAgICANCiAgICAgIFtFRElUT1I6IFRoZSA8ZGVyaXZl ZEZyb20+IGVsZW1lbnQgd2lsbCBsaWtlbHkgbmVlZCB0byBzcGVjaWZ5IHRoZSANCiAgICAgIHZl cnNpb24gb2YgdGhlIGFuY2VzdG9yLCB3aGljaCBpcyBub3QgaW5jbHVkZWQgaW4gdGhlIHNjaGVt YSB5ZXQuICANCiAgICAgIFRoZSBwcm9jZXNzIGFuZCBydWxlcyBvZiBjbGFzcyBkZXJpdmF0aW9u IGFyZSBzdGlsbCBiZWluZyANCiAgICAgIHN0dWRpZWQuXSANCiAgICAgICANCiAgICAgIEl0IGlz IGFzc3VtZWQgdGhhdCB0aGUgZGVyaXZlZCBjbGFzcyBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZSB3 aXRoIA0KICAgICAgdGhlIGJhc2UgY2xhc3MuICAgDQogICAgICAgDQogICA0LjcuMi4gPGlucHV0 UG9ydHM+IEVsZW1lbnQgdG8gRGVmaW5lIExGQiBJbnB1dHMgDQogICAgICAgDQogICAgICBUaGUg b3B0aW9uYWwgPGlucHV0UG9ydHM+IGVsZW1lbnQgaXMgdXNlZCB0byBkZWZpbmUgaW5wdXQgcG9y dHMuICANCiAgICAgIEFuIExGQiBjbGFzcyBtYXkgaGF2ZSB6ZXJvLCBvbmUsIG9yIG1vcmUgaW5w dXRzLiAgSWYgdGhlIExGQiBjbGFzcyANCiAgICAgIGhhcyBubyBpbnB1dCBwb3J0cywgdGhlIDxp bnB1dFBvcnRzPiBlbGVtZW50IG11c3QgYmUgb21pdHRlZC4gIFRoZSANCiAgICAgIDxpbnB1dFBv cnRzPiBlbGVtZW50IGNhbiBjb250YWluIG9uZSBvciBtb3JlIDxpbnB1dFBvcnQ+IGVsZW1lbnRz LCANCiAgICAgIG9uZSBmb3IgZWFjaCBwb3J0IG9yIHBvcnQtZ3JvdXAuICBXZSBhc3N1bWUgdGhh dCBtb3N0IExGQnMgd2lsbCANCiAgICAgIGhhdmUgZXhhY3RseSBvbmUgaW5wdXQuICBNdWx0aXBs ZSBpbnB1dHMgd2l0aCB0aGUgc2FtZSBpbnB1dCB0eXBlIA0KICAgICAgYXJlIG1vZGVsZWQgYXMg b25lIGlucHV0IGdyb3VwLiAgSW5wdXQgZ3JvdXBzIGFyZSBkZWZpbmVkIHRoZSBzYW1lIA0KICAg ICAgd2F5IGFzIGlucHV0IHBvcnRzIGJ5IHRoZSA8aW5wdXRQb3J0PiBlbGVtZW50LCBkaWZmZXJl bnRpYXRlZCBvbmx5IA0KICAgICAgYnkgYW4gb3B0aW9uYWwgImdyb3VwIiBhdHRyaWJ1dGUuIA0K ICAgICAgIA0KICAgICAgTXVsdGlwbGUgaW5wdXRzIHdpdGggZGlmZmVyZW50IGlucHV0IHR5cGVz IHNob3VsZCBiZSBhdm9pZGVkIGlmIA0KICAgICAgcG9zc2libGUgKHNlZSBkaXNjdXNzaW9uIGlu IFNlY3Rpb24gMy4yLjEpLiAgU29tZSBzcGVjaWFsIExGQnMgDQogICAgICB3aWxsIGhhdmUgbm8g aW5wdXRzIGF0IGFsbC4gIEZvciBleGFtcGxlLCBhIHBhY2tldCBnZW5lcmF0b3IgTEZCIA0KICAg ICAgZG9lcyBub3QgbmVlZCBhbiBpbnB1dC4gDQogICAgICAgDQogICAgICBTaW5nbGUgaW5wdXQg cG9ydHMgYW5kIGlucHV0IHBvcnQgZ3JvdXBzIGFyZSBib3RoIGRlZmluZWQgYnkgdGhlIA0KICAg ICAgPGlucHV0UG9ydD4gZWxlbWVudCwgdGhleSBhcmUgZGlmZmVyZW50aWF0ZWQgYnkgb25seSBh biBvcHRpb25hbCANCiAgICAgICJncm91cCIgYXR0cmlidXRlLiANCiAgICAgICANCiAgICAgIFRo ZSA8aW5wdXRQb3J0PiBlbGVtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgZWxlbWVudHM6IA0K ICAgICAgLiA8bmFtZT4gcHJvdmlkZXMgdGhlIHN5bWJvbGljIG5hbWUgb2YgdGhlIGlucHV0LiAg RXhhbXBsZTogImluIi4gIA0KICAgICAgICBOb3RlIHRoYXQgdGhpcyBzeW1ib2xpYyBuYW1lIG11 c3QgYmUgdW5pcXVlIG9ubHkgd2l0aGluIHRoZSANCiAgICAgICAgc2NvcGUgb2YgdGhlIExGQiBj bGFzcy4gDQogICAgICAuIDxzeW5vcHNpcz4gY29udGFpbnMgYSBicmllZiBkZXNjcmlwdGlvbiBv ZiB0aGUgaW5wdXQuICBFeGFtcGxlOiANCiAgICAgICAgIk5vcm1hbCBwYWNrZXQgaW5wdXQiLiAN CiAgICAgIC4gPGV4cGVjdGF0aW9uPiBsaXN0cyBhbGwgYWxsb3dlZCBmcmFtZSBmb3JtYXRzLiAg RXhhbXBsZTogDQogICAgICAgIHsiaXB2NCIgYW5kICJpcHY2In0uICBOb3RlIHRoYXQgdGhpcyBs aXN0IHNob3VsZCByZWZlciB0byBuYW1lcyANCiAgICAgICAgc3BlY2lmaWVkIGluIHRoZSA8ZnJh bWVEZWZzPiBlbGVtZW50IG9mIHRoZSBzYW1lIGxpYnJhcnkgDQogICAgICAgIGRvY3VtZW50IG9y IGluIGFueSBpbmNsdWRlZCBsaWJyYXJ5IGRvY3VtZW50cy4gIFRoZSANCiAgICANCiAgIFlhbmcs IGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSA1NF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICA8ZXhwZWN0YXRpb24+ IGVsZW1lbnQgY2FuIGFsc28gcHJvdmlkZSBhIGxpc3Qgb2YgcmVxdWlyZWQgDQogICAgICAgIG1l dGFkYXRhLiAgRXhhbXBsZTogeyJjbGFzc2lkIiwgInZpZmlkIn0uICBUaGlzIGxpc3Qgc2hvdWxk IA0KICAgICAgICByZWZlciB0byBuYW1lcyBvZiBtZXRhZGF0YSBkZWZpbmVkIGluIHRoZSA8bWV0 YWRhdGFEZWZzPiANCiAgICAgICAgZWxlbWVudCBpbiB0aGUgc2FtZSBsaWJyYXJ5IGRvY3VtZW50 IG9yIGluIGFueSBpbmNsdWRlZCBsaWJyYXJ5IA0KICAgICAgICBkb2N1bWVudHMuICBGb3IgZWFj aCBtZXRhZGF0YSwgaXQgbXVzdCBiZSBzcGVjaWZpZWQgd2hldGhlciB0aGUgDQogICAgICAgIG1l dGFkYXRhIGlzIHJlcXVpcmVkIG9yIG9wdGlvbmFsLiAgRm9yIGVhY2ggb3B0aW9uYWwgbWV0YWRh dGEsIA0KICAgICAgICBhIGRlZmF1bHQgdmFsdWUgbXVzdCBiZSBzcGVjaWZpZWQsIHdoaWNoIGlz IHVzZWQgYnkgdGhlIExGQiBpZiANCiAgICAgICAgdGhlIG1ldGFkYXRhIGlzIG5vdCBwcm92aWRl ZCB3aXRoIGEgcGFja2V0LiANCiAgICAgICANCiAgICAgIEluIGFkZGl0aW9uLCB0aGUgb3B0aW9u YWwgImdyb3VwIiBhdHRyaWJ1dGUgb2YgdGhlIDxpbnB1dFBvcnQ+IA0KICAgICAgZWxlbWVudCBj YW4gc3BlY2lmeSBpZiB0aGUgcG9ydCBjYW4gYmVoYXZlIGFzIGEgcG9ydCBncm91cCwgaS5lLiwg DQogICAgICBpdCBpcyBhbGxvd2VkIHRvIGJlIGluc3RhbnRpYXRlZC4gIFRoaXMgaXMgaW5kaWNh dGVkIGJ5IGEgInllcyIgDQogICAgICB2YWx1ZSAodGhlIGRlZmF1bHQgdmFsdWUgaXMgIm5vIiku IA0KICAgICAgIA0KICAgICAgQW4gZXhhbXBsZSA8aW5wdXRQb3J0cz4gZWxlbWVudCwgZGVmaW5p bmcgdHdvIGlucHV0IHBvcnRzLCB0aGUgDQogICAgICBzZWNvbmQgb25lIGJlaW5nIGFuIGlucHV0 IHBvcnQgZ3JvdXA6IA0KICAgICAgIA0KICAgICAgPGlucHV0UG9ydHM+IA0KICAgICAgICA8aW5w dXRQb3J0PiANCiAgICAgICAgICA8bmFtZT5pbjwvbmFtZT4gDQogICAgICAgICAgPHN5bm9wc2lz Pk5vcm1hbCBpbnB1dDwvc3lub3BzaXM+IA0KICAgICAgICAgIDxleHBlY3RhdGlvbj4gDQogICAg ICAgICAgICA8ZnJhbWVFeHBlY3RlZD4gDQogICAgICAgICAgICAgIDxyZWY+aXB2NDwvcmVmPiAN CiAgICAgICAgICAgICAgPHJlZj5pcHY2PC9yZWY+IA0KICAgICAgICAgICAgPC9mcmFtZUV4cGVj dGVkPiANCiAgICAgICAgICAgIDxtZXRhZGF0YUV4cGVjdGVkPiANCiAgICAgICAgICAgICAgPHJl Zj5jbGFzc2lkPC9yZWY+IA0KICAgICAgICAgICAgICA8cmVmPnZpZmlkPC9yZWY+IA0KICAgICAg ICAgICAgICA8cmVmIGRlcGVuZGVuY3k9Im9wdGlvbmFsIiBkZWZhdWx0VmFsdWU9IjAiPnZyZmlk PC9yZWY+IA0KICAgICAgICAgICAgPC9tZXRhZGF0YUV4cGVjdGVkPiANCiAgICAgICAgICA8L2V4 cGVjdGF0aW9uPiANCiAgICAgICAgPC9pbnB1dFBvcnQ+IA0KICAgICAgICA8aW5wdXRQb3J0IGdy b3VwPSJ5ZXMiPiANCiAgICAgICAgICAuLi4gYW5vdGhlciBpbnB1dCBwb3J0IC4uLiANCiAgICAg ICAgPC9pbnB1dFBvcnQ+IA0KICAgICAgPC9pbnB1dFBvcnRzPiANCiAgICAgICANCiAgICAgIEZv ciBlYWNoIDxpbnB1dFBvcnQ+LCB0aGUgZnJhbWUgdHlwZSBleHBlY3RhdGlvbnMgYXJlIGRlZmlu ZWQgYnkgDQogICAgICB0aGUgPGZyYW1lRXhwZWN0ZWQ+IGVsZW1lbnQgdXNpbmcgb25lIG9yIG1v cmUgPHJlZj4gZWxlbWVudHMgKHNlZSANCiAgICAgIGV4YW1wbGUgYWJvdmUpLiAgV2hlbiBtdWx0 aXBsZSBmcmFtZSB0eXBlcyBhcmUgbGlzdGVkLCBpdCBtZWFucyANCiAgICAgIHRoYXQgIm9uZSBv ZiB0aGVzZSIgZnJhbWUgdHlwZXMgYXJlIGV4cGVjdGVkLiAgQSBwYWNrZXQgb2YgYW55IA0KICAg ICAgb3RoZXIgZnJhbWUgdHlwZSBpcyByZWdhcmRlZCBhcyBpbmNvbXBhdGlibGUgd2l0aCB0aGlz IGlucHV0IHBvcnQgDQogICAgICBvZiB0aGUgTEZCIGNsYXNzLiAgVGhlIGFib3ZlIGV4YW1wbGUg bGlzdCB0d28gZnJhbWVzIGFzIGV4cGVjdGVkIA0KICAgICAgZnJhbWUgdHlwZXM6ICJpcHY0IiBh bmQgImlwdjYiLiANCiAgICAgICANCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJl cyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDU1XSANCgwgICBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIw MDUgDQogICAgDQogICAgDQogICAgICBNZXRhZGF0YSBleHBlY3RhdGlvbnMgYXJlIHNwZWNpZmll ZCBieSB0aGUgPG1ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAgZWxlbWVudC4gIEluIGl0cyBzaW1w bGVzdCBmb3JtLCB0aGlzIGVsZW1lbnQgY2FuIGNvbnRhaW4gYSBsaXN0IG9mIA0KICAgICAgPHJl Zj4gZWxlbWVudHMsIGVhY2ggcmVmZXJyaW5nIHRvIGEgbWV0YWRhdGEuICBXaGVuIG11bHRpcGxl IA0KICAgICAgaW5zdGFuY2VzIG9mIG1ldGFkYXRhIGFyZSBsaXN0ZWQgYnkgPHJlZj4gZWxlbWVu dHMsIGl0IG1lYW5zIHRoYXQgDQogICAgICAiYWxsIG9mIHRoZXNlIiBtZXRhZGF0YSBtdXN0IGJl IHJlY2VpdmVkIHdpdGggZWFjaCBwYWNrZXQgKGV4Y2VwdCANCiAgICAgIG1ldGFkYXRhIHRoYXQg YXJlIG1hcmtlZCBhcyAib3B0aW9uYWwiIGJ5IHRoZSAiZGVwZW5kZW5jeSIgDQogICAgICBhdHRy aWJ1dGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgPHJlZj4gZWxlbWVudCkuICBGb3IgYSBtZXRhZGF0 YSANCiAgICAgIHRoYXQgaXMgc3BlY2lmaWVkICJvcHRpb25hbCIsIGEgZGVmYXVsdCB2YWx1ZSBt dXN0IGJlIHByb3ZpZGVkIA0KICAgICAgdXNpbmcgdGhlICJkZWZhdWx0VmFsdWUiIGF0dHJpYnV0 ZS4gIFRoZSBhYm92ZSBleGFtcGxlIGxpc3RzIHRocmVlIA0KICAgICAgbWV0YWRhdGEgYXMgZXhw ZWN0ZWQgbWV0YWRhdGEsIHR3byBvZiB3aGljaCBhcmUgbWFuZGF0b3J5IA0KICAgICAgKCJjbGFz c2lkIiBhbmQgInZpZmlkIiksIGFuZCBvbmUgYmVpbmcgb3B0aW9uYWwgKCJ2cmZpZCIpLiANCiAg ICAgICANCiAgICAgIFtFRElUT1I6IEhvdyB0byBleHByZXNzIGRlZmF1bHQgdmFsdWVzIGZvciBi eXRlW05dIGF0b21pYyB0eXBlcyBpcyANCiAgICAgIHlldCB0byBiZSBkZWZpbmVkLl0gDQogICAg ICAgDQogICAgICBUaGUgc2NoZW1hIGFsc28gYWxsb3dzIGZvciBtb3JlIGNvbXBsZXggZGVmaW5p dGlvbnMgb2YgbWV0YWRhdGEgDQogICAgICBleHBlY3RhdGlvbnMuICBGb3IgZXhhbXBsZSwgdXNp bmcgdGhlIDxvbmUtb2Y+IGVsZW1lbnQsIGEgbGlzdCBvZiANCiAgICAgIG1ldGFkYXRhIGNhbiBi ZSBzcGVjaWZpZWQgdG8gZXhwcmVzcyB0aGF0IGF0IGxlYXN0IG9uZSBvZiB0aGUgDQogICAgICBz cGVjaWZpZWQgbWV0YWRhdGEgbXVzdCBiZSBwcmVzZW50IHdpdGggYW55IHBhY2tldC4gRm9yIGV4 YW1wbGU6IA0KICAgICAgIA0KICAgICAgPG1ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAgICA8b25l LW9mPiANCiAgICAgICAgICA8cmVmPnByZWZpeG1hc2s8L3JlZj4gDQogICAgICAgICAgPHJlZj5w cmVmaXhsZW48L3JlZj4gDQogICAgICAgIDwvb25lLW9mPiANCiAgICAgIDwvbWV0YWRhdGFFeHBl Y3RlZD4gDQogICAgICAgDQogICAgICBUaGUgYWJvdmUgZXhhbXBsZSBzcGVjaWZpZXMgdGhhdCBl aXRoZXIgdGhlICJwcmVmaXhtYXNrIiBvciB0aGUgDQogICAgICAicHJlZml4bGVuIiBtZXRhZGF0 YSBtdXN0IGJlIHByb3ZpZGVkIHdpdGggYW55IHBhY2tldC4gDQogICAgICAgDQogICAgICBUaGUg dHdvIGZvcm1zIGNhbiBhbHNvIGJlIGNvbWJpbmVkLCBhcyBpdCBpcyBzaG93biBpbiB0aGUgDQog ICAgICBmb2xsb3dpbmcgZXhhbXBsZTogDQogICAgICAgDQogICAgICA8bWV0YWRhdGFFeHBlY3Rl ZD4gDQogICAgICAgIDxyZWY+Y2xhc3NpZDwvcmVmPiANCiAgICAgICAgPHJlZj52aWZpZDwvcmVm PiANCiAgICAgICAgPHJlZiBkZXBlbmRlbmN5PSJvcHRpb25hbCIgZGVmYXVsdFZhbHVlPSIwIj52 cmZpZDwvcmVmPiANCiAgICAgICAgPG9uZS1vZj4gDQogICAgICAgICAgPHJlZj5wcmVmaXhtYXNr PC9yZWY+IA0KICAgICAgICAgIDxyZWY+cHJlZml4bGVuPC9yZWY+IA0KICAgICAgICA8L29uZS1v Zj4gDQogICAgICA8L21ldGFkYXRhRXhwZWN0ZWQ+IA0KICAgICAgIA0KICAgICAgQWx0aG91Z2gg dGhlIHNjaGVtYSBpcyBjb25zdHJ1Y3RlZCB0byBhbGxvdyBldmVuIG1vcmUgY29tcGxleCANCiAg ICAgIGRlZmluaXRpb25zIG9mIG1ldGFkYXRhIGV4cGVjdGF0aW9ucywgd2UgZG8gbm90IGRpc2N1 c3MgdGhvc2UgDQogICAgICBoZXJlLiANCiAgICANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAg IEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1Nl0gDQoM ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgNC43LjMuIDxvdXRwdXRQb3J0cz4gRWxlbWVudCB0 byBEZWZpbmUgTEZCIE91dHB1dHMgDQogICAgICAgDQogICAgICBUaGUgb3B0aW9uYWwgPG91dHB1 dFBvcnRzPiBlbGVtZW50IGlzIHVzZWQgdG8gZGVmaW5lIG91dHB1dCANCiAgICAgIHBvcnRzLiAg QW4gTEZCIGNsYXNzIG1heSBoYXZlIHplcm8sIG9uZSwgb3IgbW9yZSBvdXRwdXRzLiAgSWYgdGhl IA0KICAgICAgTEZCIGNsYXNzIGhhcyBubyBvdXRwdXQgcG9ydHMsIHRoZSA8b3V0cHV0UG9ydHM+ IGVsZW1lbnQgbXVzdCBiZSANCiAgICAgIG9taXR0ZWQuICBUaGUgPG91dHB1dFBvcnRzPiBlbGVt ZW50IGNhbiBjb250YWluIG9uZSBvciBtb3JlIA0KICAgICAgPG91dHB1dFBvcnQ+IGVsZW1lbnRz LCBvbmUgZm9yIGVhY2ggcG9ydCBvciBwb3J0LWdyb3VwLiAgSWYgdGhlcmUgDQogICAgICBhcmUg bXVsdGlwbGUgb3V0cHV0cyB3aXRoIHRoZSBzYW1lIG91dHB1dCB0eXBlLCB3ZSBtb2RlbCB0aGVt IGFzIA0KICAgICAgYW4gb3V0cHV0IHBvcnQgZ3JvdXAuICBTb21lIHNwZWNpYWwgTEZCcyBtYXkg aGF2ZSBubyBvdXRwdXRzIGF0IA0KICAgICAgYWxsIChlLmcuLCBEcm9wcGVyKS4gDQogICAgICAg DQogICAgICBTaW5nbGUgb3V0cHV0IHBvcnRzIGFuZCBvdXRwdXQgcG9ydCBncm91cHMgYXJlIGJv dGggZGVmaW5lZCBieSB0aGUgDQogICAgICA8b3V0cHV0UG9ydD4gZWxlbWVudDsgdGhleSBhcmUg ZGlmZmVyZW50aWF0ZWQgYnkgb25seSBhbiBvcHRpb25hbCANCiAgICAgICJncm91cCIgYXR0cmli dXRlLiANCiAgICAgICANCiAgICAgIFRoZSA8b3V0cHV0UG9ydD4gZWxlbWVudCBjb250YWlucyB0 aGUgZm9sbG93aW5nIGVsZW1lbnRzOiANCiAgICAgIC4gPG5hbWU+IHByb3ZpZGVzIHRoZSBzeW1i b2xpYyBuYW1lIG9mIHRoZSBvdXRwdXQuICBFeGFtcGxlOiANCiAgICAgICAgIm91dCIuIE5vdGUg dGhhdCB0aGUgc3ltYm9saWMgbmFtZSBtdXN0IGJlIHVuaXF1ZSBvbmx5IHdpdGhpbiANCiAgICAg ICAgdGhlIHNjb3BlIG9mIHRoZSBMRkIgY2xhc3MuIA0KICAgICAgLiA8c3lub3BzaXM+IGNvbnRh aW5zIGEgYnJpZWYgZGVzY3JpcHRpb24gb2YgdGhlIG91dHB1dCBwb3J0LiANCiAgICAgICAgRXhh bXBsZTogIk5vcm1hbCBwYWNrZXQgb3V0cHV0Ii4gDQogICAgICAuIDxwcm9kdWN0PiBsaXN0cyB0 aGUgYWxsb3dlZCBmcmFtZSBmb3JtYXRzLiAgRXhhbXBsZTogeyJpcHY0IiwgDQogICAgICAgICJp cHY2In0uICBOb3RlIHRoYXQgdGhpcyBsaXN0IHNob3VsZCByZWZlciB0byBzeW1ib2xzIHNwZWNp ZmllZCANCiAgICAgICAgaW4gdGhlIDxmcmFtZURlZnM+IGVsZW1lbnQgaW4gdGhlIHNhbWUgbGli cmFyeSBkb2N1bWVudCBvciBpbiANCiAgICAgICAgYW55IGluY2x1ZGVkIGxpYnJhcnkgZG9jdW1l bnRzLiAgVGhlIDxwcm9kdWN0PiBlbGVtZW50IG1heSBhbHNvIA0KICAgICAgICBjb250YWluIHRo ZSBsaXN0IG9mIGVtaXR0ZWQgKGdlbmVyYXRlZCkgbWV0YWRhdGEuICBFeGFtcGxlOiANCiAgICAg ICAgeyJjbGFzc2lkIiwgImNvbG9yIn0uICBUaGlzIGxpc3Qgc2hvdWxkIHJlZmVyIHRvIG5hbWVz IG9mIA0KICAgICAgICBtZXRhZGF0YSBzcGVjaWZpZWQgaW4gdGhlIDxtZXRhZGF0YURlZnM+IGVs ZW1lbnQgaW4gdGhlIHNhbWUgDQogICAgICAgIGxpYnJhcnkgZG9jdW1lbnQgb3IgaW4gYW55IGlu Y2x1ZGVkIGxpYnJhcnkgZG9jdW1lbnRzLiAgRm9yIA0KICAgICAgICBlYWNoIGdlbmVyYXRlZCBt ZXRhZGF0YSwgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCB3aGV0aGVyIHRoZSANCiAgICAgICAgbWV0 YWRhdGEgaXMgYWx3YXlzIGdlbmVyYXRlZCBvciBnZW5lcmF0ZWQgb25seSBpbiBjZXJ0YWluIA0K ICAgICAgICBjb25kaXRpb25zLiBUaGlzIGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCB3aGVuIGFz c2Vzc2luZyANCiAgICAgICAgY29tcGF0aWJpbGl0eSBiZXR3ZWVuIExGQnMuIA0KICAgICAgIA0K ICAgICAgSW4gYWRkaXRpb24sIHRoZSBvcHRpb25hbCAiZ3JvdXAiIGF0dHJpYnV0ZSBvZiB0aGUg PG91dHB1dFBvcnQ+IA0KICAgICAgZWxlbWVudCBjYW4gc3BlY2lmeSBpZiB0aGUgcG9ydCBjYW4g YmVoYXZlIGFzIGEgcG9ydCBncm91cCwgaS5lLiwgDQogICAgICBpdCBpcyBhbGxvd2VkIHRvIGJl IGluc3RhbnRpYXRlZC4gVGhpcyBpcyBpbmRpY2F0ZWQgYnkgYSAieWVzIiANCiAgICAgIHZhbHVl ICh0aGUgZGVmYXVsdCB2YWx1ZSBpcyAibm8iKS4gDQogICAgICAgDQogICAgICBUaGUgZm9sbG93 aW5nIGV4YW1wbGUgc3BlY2lmaWVzIHR3byBvdXRwdXQgcG9ydHMsIHRoZSBzZWNvbmQgYmVpbmcg DQogICAgICBhbiBvdXRwdXQgcG9ydCBncm91cDogDQogICAgICAgDQogICAgICA8b3V0cHV0UG9y dHM+IA0KICAgICAgICA8b3V0cHV0UG9ydD4gDQogICAgICAgICAgPG5hbWU+b3V0PC9uYW1lPiAN CiAgICAgICAgICA8c3lub3BzaXM+Tm9ybWFsIG91dHB1dDwvc3lub3BzaXM+IA0KICAgICAgICAg IDxwcm9kdWN0PiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIw MDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1N10gDQoMICAgSW50ZXJuZXQgRHJhZnQg ICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0K ICAgIA0KICAgICAgICAgICAgPGZyYW1lUHJvZHVjZWQ+IA0KICAgICAgICAgICAgICA8cmVmPmlw djQ8L3JlZj4gDQogICAgICAgICAgICAgIDxyZWY+aXB2NGJpczwvcmVmPiANCiAgICAgICAgICAg IDwvZnJhbWVQcm9kdWNlZD4gDQogICAgICAgICAgICA8bWV0YWRhdGFQcm9kdWNlZD4gDQogICAg ICAgICAgICAgIDxyZWY+bmhpZDwvcmVmPiANCiAgICAgICAgICAgICAgPHJlZj5uaHRhYmlkPC9y ZWY+IA0KICAgICAgICAgICAgPC9tZXRhZGF0YVByb2R1Y2VkPiANCiAgICAgICAgICA8L3Byb2R1 Y3Q+IA0KICAgICAgICA8L291dHB1dFBvcnQ+ICAgDQogICAgICAgIDxvdXRwdXRQb3J0IGdyb3Vw PSJ5ZXMiPiANCiAgICAgICAgICA8bmFtZT5leGM8L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNp cz5FeGNlcHRpb24gb3V0cHV0IHBvcnQgZ3JvdXA8L3N5bm9wc2lzPiANCiAgICAgICAgICA8cHJv ZHVjdD4gDQogICAgICAgICAgICA8ZnJhbWVQcm9kdWNlZD4gDQogICAgICAgICAgICAgIDxyZWY+ aXB2NDwvcmVmPiANCiAgICAgICAgICAgICAgPHJlZj5pcHY0YmlzPC9yZWY+IA0KICAgICAgICAg ICAgPC9mcmFtZVByb2R1Y2VkPiANCiAgICAgICAgICAgIDxtZXRhZGF0YVByb2R1Y2VkPiANCiAg ICAgICAgICAgICAgPHJlZiBhdmFpbGFiaWxpdHk9ImNvbmRpdGlvbmFsIj5lcnJvcmlkPC9yZWY+ IA0KICAgICAgICAgICAgPC9tZXRhZGF0YVByb2R1Y2VkPiANCiAgICAgICAgICA8L3Byb2R1Y3Q+ IA0KICAgICAgICA8L291dHB1dFBvcnQ+IA0KICAgICAgPC9vdXRwdXRQb3J0cz4gDQogICAgICAg DQogICAgICBUaGUgdHlwZXMgb2YgZnJhbWVzIGFuZCBtZXRhZGF0YSB0aGUgcG9ydCBwcm9kdWNl cyBhcmUgZGVmaW5lZCANCiAgICAgIGluc2lkZSB0aGUgPHByb2R1Y3Q+IGVsZW1lbnQgaW4gZWFj aCA8b3V0cHV0UG9ydD4uICBXaXRoaW4gdGhlIA0KICAgICAgPHByb2R1Y3Q+IGVsZW1lbnQsIHRo ZSBsaXN0IG9mIGZyYW1lIHR5cGVzIHRoZSBwb3J0IHByb2R1Y2VzIGlzIA0KICAgICAgbGlzdGVk IGluIHRoZSA8ZnJhbWVQcm9kdWNlZD4gZWxlbWVudC4gIFdoZW4gbW9yZSB0aGFuIG9uZSBmcmFt ZSANCiAgICAgIGlzIGxpc3RlZCwgaXQgbWVhbnMgdGhhdCAib25lIG9mIiB0aGVzZSBmcmFtZXMg d2lsbCBiZSBwcm9kdWNlZC4gDQogICAgICAgDQogICAgICBUaGUgbGlzdCBvZiBtZXRhZGF0YSB0 aGF0IGlzIHByb2R1Y2VkIHdpdGggZWFjaCBwYWNrZXQgaXMgbGlzdGVkIA0KICAgICAgaW4gdGhl IG9wdGlvbmFsIDxtZXRhZGF0YVByb2R1Y2VkPiBlbGVtZW50IG9mIHRoZSA8cHJvZHVjdD4uICBJ biANCiAgICAgIGl0cyBzaW1wbGVzdCBmb3JtLCB0aGlzIGVsZW1lbnQgY2FuIGNvbnRhaW4gYSBs aXN0IG9mIDxyZWY+IA0KICAgICAgZWxlbWVudHMsIGVhY2ggcmVmZXJyaW5nIHRvIGEgbWV0YWRh dGEgdHlwZS4gIFRoZSBtZWFuaW5nIG9mIHN1Y2ggDQogICAgICBhIGxpc3QgaXMgdGhhdCAiYWxs IG9mIiB0aGVzZSBtZXRhZGF0YSBhcmUgcHJvdmlkZWQgd2l0aCBlYWNoIA0KICAgICAgcGFja2V0 LCBleGNlcHQgdGhvc2UgdGhhdCBhcmUgbGlzdGVkIHdpdGggdGhlIG9wdGlvbmFsIA0KICAgICAg ImF2YWlsYWJpbGl0eSIgYXR0cmlidXRlIHNldCB0byAiY29uZGl0aW9uYWwiLiAgU2ltaWxhciB0 byB0aGUgDQogICAgICA8bWV0YWRhdGFFeHBlY3RlZD4gZWxlbWVudCBvZiB0aGUgPGlucHV0UG9y dD4sIHRoZSANCiAgICAgIDxtZXRhZGF0YVByb2R1Y2VkPiBlbGVtZW50IHN1cHBvcnRzIG1vcmUg Y29tcGxleCBmb3Jtcywgd2hpY2ggd2UgDQogICAgICBkbyBub3QgZGlzY3VzcyBoZXJlIGZ1cnRo ZXIuIA0KICAgIA0KICAgNC43LjQuIDxhdHRyaWJ1dGVzPiBFbGVtZW50IHRvIERlZmluZSBMRkIg T3BlcmF0aW9uYWwgQXR0cmlidXRlcyANCiAgICAgICAgIA0KICAgICAgT3BlcmF0aW9uYWwgcGFy YW1ldGVycyBvZiB0aGUgTEZCcyB0aGF0IG11c3QgYmUgdmlzaWJsZSB0byB0aGUgQ0VzIA0KICAg ICAgYXJlIGNvbmNlcHR1YWxpemVkIGluIHRoZSBtb2RlbCBhcyB0aGUgTEZCIGF0dHJpYnV0ZXMu ICBUaGVzZSANCiAgICAgIGluY2x1ZGUsIGZvciBleGFtcGxlLCBmbGFncywgc2luZ2xlIHBhcmFt ZXRlciBhcmd1bWVudHMsIGNvbXBsZXggDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBp cmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNThdIA0KDCAgIElu dGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3Qg MjAwNSANCiAgICANCiAgICANCiAgICAgIGFyZ3VtZW50cywgYW5kIHRhYmxlcy4gIE5vdGUgdGhh dCB0aGUgYXR0cmlidXRlcyBoZXJlIHJlZmVyIHRvIA0KICAgICAgb25seSB0aG9zZSBvcGVyYXRp b25hbCBwYXJhbWV0ZXJzIG9mIHRoZSBMRkJzIHRoYXQgbXVzdCBiZSB2aXNpYmxlIA0KICAgICAg dG8gdGhlIENFcy4gIE90aGVyIHZhcmlhYmxlcyB0aGF0IGFyZSBpbnRlcm5hbCB0byBMRkIgDQog ICAgICBpbXBsZW1lbnRhdGlvbiBhcmUgbm90IHJlZ2FyZGVkIGFzIExGQiBhdHRyaWJ1dGVzIGFu ZCBoZW5jZSBhcmUgDQogICAgICBub3QgY292ZXJlZC4gDQogICAgICAgDQogICAgICBTb21lIGV4 YW1wbGVzIGZvciBMRkIgYXR0cmlidXRlcyBhcmU6IA0KICAgICAgICAuIENvbmZpZ3VyYWJsZSBm bGFncyBhbmQgc3dpdGNoZXMgc2VsZWN0aW5nIGJldHdlZW4gb3BlcmF0aW9uYWwgDQogICAgICAg ICAgIG1vZGVzIG9mIHRoZSBMRkIgDQogICAgICAgIC4gTnVtYmVyIG9mIGlucHV0cyBvciBvdXRw dXRzIGluIGEgcG9ydCBncm91cCANCiAgICAgICAgLiBNZXRhZGF0YSBDT05TVU1FIHZzLiBQUk9Q QUdBVEUgbW9kZSBzZWxlY3RvcnMgDQogICAgICAgIC4gVmFyaW91cyBjb25maWd1cmFibGUgbG9v a3VwIHRhYmxlcywgaW5jbHVkaW5nIGludGVyZmFjZSANCiAgICAgICAgICAgdGFibGVzLCBwcmVm aXggdGFibGVzLCBjbGFzc2lmaWNhdGlvbiB0YWJsZXMsIERTQ1AgbWFwcGluZyANCiAgICAgICAg ICAgdGFibGVzLCBNQUMgYWRkcmVzcyB0YWJsZXMsIGV0Yy4gDQogICAgICAgIC4gUGFja2V0IGFu ZCBieXRlIGNvdW50ZXJzIA0KICAgICAgICAuIFZhcmlvdXMgZXZlbnQgY291bnRlcnMgDQogICAg ICAgIC4gTnVtYmVyIG9mIGN1cnJlbnQgaW5wdXRzIG9yIG91dHB1dHMgZm9yIGVhY2ggaW5wdXQg b3Igb3V0cHV0IA0KICAgICAgICAgICBncm91cCANCiAgICAgICAgLiBNZXRhZGF0YSBDT05TVU1F L1BST1BBR0FURSBtb2RlIHNlbGVjdG9yIA0KICAgICAgIA0KICAgICAgVGhlcmUgbWF5IGJlIHZh cmlvdXMgYWNjZXNzIHBlcm1pc3Npb24gcmVzdHJpY3Rpb25zIG9uIHdoYXQgdGhlIENFIA0KICAg ICAgY2FuIGRvIHdpdGggYW4gTEZCIGF0dHJpYnV0ZS4gIFRoZSBmb2xsb3dpbmcgY2F0ZWdvcmll cyBtYXkgYmUgDQogICAgICBzdXBwb3J0ZWQ6IA0KICAgICAgICAuIE5vLWFjY2VzcyBhdHRyaWJ1 dGVzLiAgVGhpcyBpcyB1c2VmdWwgd2hlbiBtdWx0aXBsZSBhY2Nlc3MgDQogICAgICAgICAgIG1v ZGVzIG1heSBiZSBkZWZpbmVkIGZvciBhIGdpdmVuIGF0dHJpYnV0ZSB0byBhbGxvdyBzb21lIA0K ICAgICAgICAgICBmbGV4aWJpbGl0eSBmb3IgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4gDQog ICAgICAgIC4gUmVhZC1vbmx5IGF0dHJpYnV0ZXMuIA0KICAgICAgICAuIFJlYWQtd3JpdGUgYXR0 cmlidXRlcy4gDQogICAgICAgIC4gV3JpdGUtb25seSBhdHRyaWJ1dGVzLiAgVGhpcyBjb3VsZCBi ZSBhbnkgY29uZmlndXJhYmxlIGRhdGEgDQogICAgICAgICAgIGZvciB3aGljaCByZWFkIGNhcGFi aWxpdHkgaXMgbm90IHByb3ZpZGVkIHRvIHRoZSBDRXMuICAoZS5nLiwgDQogICAgICAgICAgIHRo ZSBzZWN1cml0eSBrZXkgaW5mb3JtYXRpb24pIA0KICAgICAgICAuIFJlYWQtcmVzZXQgYXR0cmli dXRlcy4gIFRoZSBDRSBjYW4gcmVhZCBhbmQgcmVzZXQgdGhpcyANCiAgICAgICAgICAgcmVzb3Vy Y2UsIGJ1dCBjYW5ub3Qgc2V0IGl0IHRvIGFuIGFyYml0cmFyeSB2YWx1ZS4gIEV4YW1wbGU6IA0K ICAgICAgICAgICBDb3VudGVycy4gDQogICAgICAgIC4gRmlyaW5nLW9ubHkgYXR0cmlidXRlcy4g IEEgd3JpdGUgYXR0ZW1wdCB0byB0aGlzIHJlc291cmNlIA0KICAgICAgICAgICB3aWxsIHRyaWdn ZXIgc29tZSBzcGVjaWZpYyBhY3Rpb25zIGluIHRoZSBMRkIsIGJ1dCB0aGUgYWN0dWFsIA0KICAg ICAgICAgICB2YWx1ZSB3cml0dGVuIGlzIGlnbm9yZWQuICAgDQogICAgICAgDQogICAgICBUaGUg TEZCIGNsYXNzIG1heSBkZWZpbmUgbW9yZSB0aGFuIG9uZSBwb3NzaWJsZSBhY2Nlc3MgbW9kZSBm b3IgYSANCiAgICAgIGdpdmVuIGF0dHJpYnV0ZSAoZm9yIGV4YW1wbGUsICJ3cml0ZS1vbmx5IiBh bmQgInJlYWQtd3JpdGUiKSwgaW4gDQogICAgICB3aGljaCBjYXNlIGl0IGlzIGxlZnQgdG8gdGhl IGFjdHVhbCBpbXBsZW1lbnRhdGlvbiB0byBwaWNrIG9uZSBvZiANCiAgICAgIHRoZSBtb2Rlcy4g IEluIHN1Y2ggY2FzZXMsIGEgY29ycmVzcG9uZGluZyBjYXBhYmlsaXR5IGF0dHJpYnV0ZSANCiAg ICAgIG11c3QgaW5mb3JtIHRoZSBDRSBhYm91dCB0aGUgYWNjZXNzIG1vZGUgdGhlIGFjdHVhbCBM RkIgaW5zdGFuY2UgDQogICAgICBzdXBwb3J0cyAoc2VlIG5leHQgc3Vic2VjdGlvbiBvbiBjYXBh YmlsaXR5IGF0dHJpYnV0ZXMpLiANCiAgICAgICANCg0KDQogICAgDQogICBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNTld IA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBM RkIgY2xhc3MgYXJlIGxpc3RlZCBpbiB0aGUgPGF0dHJpYnV0ZXM+IA0KICAgICAgZWxlbWVudC4g IEVhY2ggYXR0cmlidXRlIGlzIGRlZmluZWQgYnkgYW4gPGF0dHJpYnV0ZT4gZWxlbWVudC4gIEFu IA0KICAgICAgPGF0dHJpYnV0ZT4gZWxlbWVudCBjb250YWlucyB0aGUgZm9sbG93aW5nIGVsZW1l bnRzOiANCiAgICAgICAgLiA8bmFtZT4gZGVmaW5lcyB0aGUgbmFtZSBvZiB0aGUgYXR0cmlidXRl LiAgVGhpcyBuYW1lIG11c3QgYmUgDQogICAgICAgICAgIHVuaXF1ZSBhbW9uZyB0aGUgYXR0cmli dXRlcyBvZiB0aGUgTEZCIGNsYXNzLiAgRXhhbXBsZTogDQogICAgICAgICAgICJ2ZXJzaW9uIi4g IA0KICAgICAgICAuIDxzeW5vcHNpcz4gc2hvdWxkIHByb3ZpZGUgYSBicmllZiBkZXNjcmlwdGlv biBvZiB0aGUgcHVycG9zZSANCiAgICAgICAgICAgb2YgdGhlIGF0dHJpYnV0ZS4gDQogICAgICAg IC4gPG9wdGlvbmFsLz4gaW5kaWNhdGVzIHRoYXQgdGhpcyBhdHRyaWJ1dGUgaXMgb3B0aW9uYWwu IA0KICAgICAgICAuIFRoZSBkYXRhIHR5cGUgb2YgdGhlIGF0dHJpYnV0ZSBjYW4gYmUgZGVmaW5l ZCBlaXRoZXIgdmlhIGEgDQogICAgICAgICAgIHJlZmVyZW5jZSB0byBhIHByZWRlZmluZWQgZGF0 YSB0eXBlIG9yIHByb3ZpZGluZyBhIGxvY2FsIA0KICAgICAgICAgICBkZWZpbml0aW9uIG9mIHRo ZSB0eXBlLiAgVGhlIGZvcm1lciBpcyBwcm92aWRlZCBieSB1c2luZyB0aGUgDQogICAgICAgICAg IDx0eXBlUmVmPiBlbGVtZW50LCB3aGljaCBtdXN0IHJlZmVyIHRvIHRoZSB1bmlxdWUgbmFtZSBv ZiBhbiANCiAgICAgICAgICAgZXhpc3RpbmcgZGF0YSB0eXBlIGRlZmluZWQgaW4gdGhlIDxkYXRh VHlwZURlZnM+IGVsZW1lbnQgaW4gDQogICAgICAgICAgIHRoZSBzYW1lIGxpYnJhcnkgZG9jdW1l bnQgb3IgaW4gYW55IG9mIHRoZSBpbmNsdWRlZCBsaWJyYXJ5IA0KICAgICAgICAgICBkb2N1bWVu dHMuICBXaGVuIHRoZSBkYXRhIHR5cGUgaXMgZGVmaW5lZCBsb2NhbGx5ICh1bm5hbWVkIA0KICAg ICAgICAgICB0eXBlKSwgb25lIG9mIHRoZSBmb2xsb3dpbmcgZWxlbWVudHMgY2FuIGJlIHVzZWQ6 IDxhdG9taWM+LCANCiAgICAgICAgICAgPGFycmF5PiwgPHN0cnVjdD4sIGFuZCA8dW5pb24+LiBU aGVpciB1c2FnZSBpcyBpZGVudGljYWwgdG8gDQogICAgICAgICAgIGhvdyB0aGV5IGFyZSB1c2Vk IGluc2lkZSA8ZGF0YVR5cGVEZWY+IGVsZW1lbnRzIChzZWUgU2VjdGlvbiANCiAgICAgICAgICAg NC41KS4gDQogICAgICAgIC4gVGhlIG9wdGlvbmFsIDxkZWZhdWx0VmFsdWU+IGVsZW1lbnQgY2Fu IHNwZWNpZnkgYSBkZWZhdWx0IA0KICAgICAgICAgICB2YWx1ZSBmb3IgdGhlIGF0dHJpYnV0ZSwg d2hpY2ggaXMgYXBwbGllZCB3aGVuIHRoZSBMRkIgaXMgDQogICAgICAgICAgIGluaXRpYWxpemVk IG9yIHJlc2V0LiAgW0VESVRPUjogQSBjb252ZW50aW9uIHRvIGRlZmluZSANCiAgICAgICAgICAg ZGVmYXVsdCB2YWx1ZXMgZm9yIGNvbXBvdW5kIGRhdGEgdHlwZXMgYW5kIGJ5dGVbTl0gYXRvbWlj IA0KICAgICAgICAgICB0eXBlcyBpcyB5ZXQgdG8gYmUgZGVmaW5lZC5dIA0KICAgICAgIA0KICAg ICAgVGhlIGF0dHJpYnV0ZSBlbGVtZW50IGFsc28gaGFzIGEgbWFuZGF0b3J5IGVsZW1lbnRJRCBh dHRyaWJ1dGUsIA0KICAgICAgd2hpY2ggaXMgYSBudW1lcmljIHZhbHVlIHVzZWQgYnkgdGhlIEZv ckNFUyBwcm90b2NvbC4gDQogICAgICAgDQogICAgICBJbiBhZGRpdGlvbiB0byB0aGUgYWJvdmUg ZWxlbWVudHMsIHRoZSA8YXR0cmlidXRlPiBlbGVtZW50IA0KICAgICAgaW5jbHVkZXMgYW4gb3B0 aW9uYWwgImFjY2VzcyIgYXR0cmlidXRlLCB3aGljaCBjYW4gdGFrZSBhbnkgb2YgdGhlIA0KICAg ICAgZm9sbG93aW5nIHZhbHVlcyBvciBldmVuIGEgbGlzdCBvZiB0aGVzZSB2YWx1ZXM6ICJyZWFk LW9ubHkiLCANCiAgICAgICJyZWFkLXdyaXRlIiwgIndyaXRlLW9ubHkiLCAicmVhZC1yZXNldCIs IGFuZCAidHJpZ2dlci1vbmx5Ii4gVGhlIA0KICAgICAgZGVmYXVsdCBhY2Nlc3MgbW9kZSBpcyAi cmVhZC13cml0ZSIuIA0KICAgICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGRlZmlu ZXMgdHdvIGF0dHJpYnV0ZXMgZm9yIGFuIExGQjogDQogICAgICAgDQogICAgICA8YXR0cmlidXRl cz4gDQogICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNzPSJyZWFkLW9ubHkiIGVsZW1lbnRJRD2UMZQ+ IA0KICAgICAgICAgIDxuYW1lPmZvbzwvbmFtZT4gDQogICAgICAgICAgPHN5bm9wc2lzPm51bWJl ciBvZiB0aGluZ3M8L3N5bm9wc2lzPiANCiAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5cGVS ZWY+IA0KICAgICAgICA8L2F0dHJpYnV0ZT4gDQogICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNzPSJy ZWFkLXdyaXRlIHdyaXRlLW9ubHkiIGVsZW1lbnRJRD2UMpQ+IA0KICAgICAgICAgIDxuYW1lPmJh cjwvbmFtZT4gDQogICAgICAgICAgPHN5bm9wc2lzPm51bWJlciBvZiB0aGlzIG90aGVyIHRoaW5n PC9zeW5vcHNpcz4gDQogICAgICAgICAgPGF0b21pYz4gDQogICAgDQogICBZYW5nLCBldCBhbC4g ICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNjBd IA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAg ICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAgICAgIDxiYXNlVHlwZT51aW50MzI8 L2Jhc2VUeXBlPiANCiAgICAgICAgICAgIDxyYW5nZVJlc3RyaWN0aW9uPiANCiAgICAgICAgICAg ICAgPGFsbG93ZWRSYW5nZSBtaW49IjEwIiBtYXg9IjIwMDAiLz4gDQogICAgICAgICAgICA8L3Jh bmdlUmVzdHJpY3Rpb24+IA0KICAgICAgICAgIDwvYXRvbWljPiANCiAgICAgICAgICA8ZGVmYXVs dFZhbHVlPjEwPC9kZWZhdWx0VmFsdWU+IA0KICAgICAgICA8L2F0dHJpYnV0ZT4gDQogICAgICA8 L2F0dHJpYnV0ZXM+IA0KICAgICAgIA0KICAgICAgVGhlIGZpcnN0IGF0dHJpYnV0ZSAoImZvbyIp IGlzIGEgcmVhZC1vbmx5IDMyLWJpdCB1bnNpZ25lZCANCiAgICAgIGludGVnZXIsIGRlZmluZWQg YnkgcmVmZXJyaW5nIHRvIHRoZSBidWlsdC1pbiAidWludDMyIiBhdG9taWMgDQogICAgICB0eXBl LiAgVGhlIHNlY29uZCBhdHRyaWJ1dGUgKCJiYXIiKSBpcyBhbHNvIGFuIGludGVnZXIsIGJ1dCB1 c2VzIA0KICAgICAgdGhlIDxhdG9taWM+IGVsZW1lbnQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIHJh bmdlIHJlc3RyaWN0aW9ucy4gDQogICAgICBUaGlzIGF0dHJpYnV0ZSBoYXMgdHdvIHBvc3NpYmxl IGFjY2VzcyBtb2RlcywgInJlYWQtd3JpdGUiIG9yIA0KICAgICAgIndyaXRlLW9ubHkiLiAgQSBk ZWZhdWx0IHZhbHVlIG9mIDEwIGlzIHByb3ZpZGVkLiANCiAgICAgICANCiAgICAgIE5vdGUgdGhh dCBub3QgYWxsIGF0dHJpYnV0ZXMgYXJlIGxpa2VseSB0byBleGlzdCBhdCBhbGwgdGltZXMgaW4g YSANCiAgICAgIHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24uICBXaGlsZSB0aGUgY2FwYWJpbGl0 aWVzIHdpbGwgZnJlcXVlbnRseSANCiAgICAgIGluZGljYXRlIHRoaXMgbm9uLWV4aXN0ZW5jZSwg Q0VzIG1heSBhdHRlbXB0IHRvIHJlZmVyZW5jZSBub24tDQogICAgICBleGlzdGVudCBvciBub24t cGVybWl0dGVkIGF0dHJpYnV0ZXMgYW55d2F5LiAgVGhlIEZPUkNFUyBwcm90b2NvbCANCiAgICAg IG1lY2hhbmlzbXMgc2hvdWxkIGluY2x1ZGUgYXBwcm9wcmlhdGUgZXJyb3IgaW5kaWNhdG9ycyBm b3IgdGhpcyANCiAgICAgIGNhc2UuIA0KICAgICAgIA0KICAgICAgVGhlIG1lY2hhbmlzbSBkZWZp bmVkIGFib3ZlIGZvciBub24tc3VwcG9ydGVkIGF0dHJpYnV0ZXMgY2FuIGFsc28gDQogICAgICBh cHBseSB0byBhdHRlbXB0cyB0byByZWZlcmVuY2Ugbm9uLWV4aXN0ZW50IGFycmF5IGVsZW1lbnRz IG9yIHRvIA0KICAgICAgc2V0IHJlYWQtb25seSBlbGVtZW50cy4gDQogICAgICANCiAgIDQuNy41 LiA8Y2FwYWJpbGl0aWVzPiBFbGVtZW50IHRvIERlZmluZSBMRkIgQ2FwYWJpbGl0eSBBdHRyaWJ1 dGVzIA0KICAgICAgICAgDQogICAgICBUaGUgTEZCIGNsYXNzIHNwZWNpZmljYXRpb24gd2lsbCBw cm92aWRlIHNvbWUgZmxleGliaWxpdHkgZm9yIHRoZSANCiAgICAgIEZFIGltcGxlbWVudGF0aW9u IHJlZ2FyZGluZyBob3cgdGhlIExGQiBjbGFzcyBpcyBpbXBsZW1lbnRlZC4gIEZvciANCiAgICAg IGV4YW1wbGUsIHRoZSBjbGFzcyBtYXkgZGVmaW5lIHNvbWUgb3B0aW9uYWwgZmVhdHVyZXMsIGlu IHdoaWNoIA0KICAgICAgY2FzZSB0aGUgYWN0dWFsIGltcGxlbWVudGF0aW9uIG1heSBvciBtYXkg bm90IHByb3ZpZGUgdGhlIGdpdmVuIA0KICAgICAgZmVhdHVyZS4gIEluIHRoZXNlIGNhc2VzIHRo ZSBDRSBtdXN0IGJlIGFibGUgdG8gcXVlcnkgdGhlIExGQiANCiAgICAgIGluc3RhbmNlIGFib3V0 IHRoZSBhdmFpbGFiaWxpdHkgb2YgdGhlIGZlYXR1cmUuICBJbiBhZGRpdGlvbiwgdGhlIA0KICAg ICAgaW5zdGFuY2UgbWF5IGhhdmUgc29tZSBsaW1pdGF0aW9ucyB0aGF0IGFyZSBub3QgaW5oZXJl bnQgZnJvbSB0aGUgDQogICAgICBjbGFzcyBkZWZpbml0aW9uLCBidXQgcmF0aGVyIHRoZSByZXN1 bHQgb2Ygc29tZSBpbXBsZW1lbnRhdGlvbiANCiAgICAgIGxpbWl0YXRpb25zLiAgRm9yIGV4YW1w bGUsIGFuIGFycmF5IGF0dHJpYnV0ZSBtYXkgYmUgZGVmaW5lZCBpbiANCiAgICAgIHRoZSBjbGFz cyBkZWZpbml0aW9uIGFzICJ1bmxpbWl0ZWQiIHNpemUsIGJ1dCB0aGUgcGh5c2ljYWwgDQogICAg ICBpbXBsZW1lbnRhdGlvbiBtYXkgaW1wb3NlIGEgaGFyZCBsaW1pdCBvbiB0aGUgc2l6ZSBvZiB0 aGUgYXJyYXkuICANCiAgICAgICANCiAgICAgIFN1Y2ggY2FwYWJpbGl0eSByZWxhdGVkIGluZm9y bWF0aW9uIGlzIGV4cHJlc3NlZCBieSB0aGUgY2FwYWJpbGl0eSANCiAgICAgIGF0dHJpYnV0ZXMg b2YgdGhlIExGQiBjbGFzcy4gIFRoZSBjYXBhYmlsaXR5IGF0dHJpYnV0ZXMgYXJlIGFsd2F5cyAN CiAgICAgIHJlYWQtb25seSBhdHRyaWJ1dGVzLCBhbmQgdGhleSBhcmUgbGlzdGVkIGluIGEgc2Vw YXJhdGUgDQogICAgICA8Y2FwYWJpbGl0aWVzPiBlbGVtZW50IGluIHRoZSA8TEZCQ2xhc3NEZWY+ LiAgVGhlIDxjYXBhYmlsaXRpZXM+IA0KICAgICAgZWxlbWVudCBjb250YWlucyBvbmUgb3IgbW9y ZSA8Y2FwYWJpbGl0eT4gZWxlbWVudHMsIGVhY2ggZGVmaW5pbmcgDQogICAgICBvbmUgY2FwYWJp bGl0eSBhdHRyaWJ1dGUuICBUaGUgZm9ybWF0IG9mIHRoZSA8Y2FwYWJpbGl0eT4gZWxlbWVudCAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA2MV0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg aXMgYWxtb3N0IHRoZSBzYW1lIGFzIHRoZSA8YXR0cmlidXRlPiBlbGVtZW50LCBpdCBkaWZmZXJz IGluIHR3byANCiAgICAgIGFzcGVjdHM6IGl0IGxhY2tzIHRoZSBhY2Nlc3MgbW9kZSBhdHRyaWJ1 dGUgKGJlY2F1c2UgaXQgaXMgYWx3YXlzIA0KICAgICAgcmVhZC1vbmx5KSwgYW5kIGl0IGxhY2tz IHRoZSA8ZGVmYXVsdFZhbHVlPiBlbGVtZW50IChiZWNhdXNlIA0KICAgICAgZGVmYXVsdCB2YWx1 ZSBpcyBub3QgYXBwbGljYWJsZSB0byByZWFkLW9ubHkgYXR0cmlidXRlcykuICANCiAgICAgICAN CiAgICAgIFNvbWUgZXhhbXBsZXMgb2YgY2FwYWJpbGl0eSBhdHRyaWJ1dGVzOiANCiAgICAgICAg LiBUaGUgdmVyc2lvbiBvZiB0aGUgTEZCIGNsYXNzIHRoYXQgdGhpcyBMRkIgaW5zdGFuY2UgY29t cGxpZXMgDQogICAgICAgICAgIHdpdGg7IA0KICAgICAgICAuIFN1cHBvcnRlZCBvcHRpb25hbCBm ZWF0dXJlcyBvZiB0aGUgTEZCIGNsYXNzOyANCiAgICAgICAgLiBNYXhpbXVtIG51bWJlciBvZiBj b25maWd1cmFibGUgb3V0cHV0cyBmb3IgYW4gb3V0cHV0IGdyb3VwOyANCiAgICAgICAgLiBNZXRh ZGF0YSBwYXNzLXRocm91Z2ggbGltaXRhdGlvbnMgb2YgdGhlIExGQjsgDQogICAgICAgIC4gTWF4 aW11bSBzaXplIG9mIGNvbmZpZ3VyYWJsZSBhdHRyaWJ1dGUgdGFibGVzOyANCiAgICAgICAgLiBB ZGRpdGlvbmFsIHJhbmdlIHJlc3RyaWN0aW9uIG9uIG9wZXJhdGlvbmFsIGF0dHJpYnV0ZXM7IA0K ICAgICAgICAuIFN1cHBvcnRlZCBhY2Nlc3MgbW9kZXMgb2YgY2VydGFpbiBhdHRyaWJ1dGVzIChp ZiB0aGUgYWNjZXNzIA0KICAgICAgICAgICBtb2RlIG9mIGFuIG9wZXJhdGlvbmFsIGF0dHJpYnV0 ZSBpcyBzcGVjaWZpZWQgYXMgYSBsaXN0IG9mIA0KICAgICAgICAgICB0d28gb3IgbW9kZSBtb2Rl cykuIA0KICAgICAgIA0KICAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIGxpc3RzIHR3byBjYXBh YmlsaXR5IGF0dHJpYnV0ZXM6IA0KICAgICAgIA0KICAgICAgPGNhcGFiaWxpdGllcz4gDQogICAg ICAgIDxjYXBhYmlsaXR5IGVsZW1lbnRJRD0iMyI+IA0KICAgICAgICAgIDxuYW1lPnZlcnNpb248 L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICBMRkIgY2xhc3MgdmVy c2lvbiB0aGlzIGluc3RhbmNlIGlzIGNvbXBsaWFudCB3aXRoLiANCiAgICAgICAgICA8L3N5bm9w c2lzPiANCiAgICAgICAgICA8dHlwZVJlZj52ZXJzaW9uPC90eXBlUmVmPiANCiAgICAgICAgPC9j YXBhYmlsaXR5PiANCiAgICAgICAgPGNhcGFiaWxpdHkgZWxlbWVudElEPSI0Ij4gDQogICAgICAg ICAgPG5hbWU+bGltaXRCYXI8L25hbWU+IA0KICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAg ICAgICBNYXhpbXVtIHZhbHVlIG9mIHRoZSAiYmFyIiBhdHRyaWJ1dGUuIA0KICAgICAgICAgIDwv c3lub3BzaXM+IA0KICAgICAgICAgIDx0eXBlUmVmPnVpbnQxNjwvdHlwZVJlZj4gDQogICAgICAg IDwvY2FwYWJpbGl0eT4gIA0KICAgICAgPC9jYXBhYmlsaXRpZXM+IA0KICAgIA0KICAgNC43LjYu IDxkZXNjcmlwdGlvbj4gRWxlbWVudCBmb3IgTEZCIE9wZXJhdGlvbmFsIFNwZWNpZmljYXRpb24g DQogICAgICAgDQogICAgICBUaGUgPGRlc2NyaXB0aW9uPiBlbGVtZW50IG9mIHRoZSA8TEZCQ2xh c3M+IHByb3ZpZGVzIHVuc3RydWN0dXJlZCANCiAgICAgIHRleHQgKGluIFhNTCBzZW5zZSkgdG8g dmVyYmFsbHkgZGVzY3JpYmUgd2hhdCB0aGUgTEZCIGRvZXMuICAgDQogICAgDQogICA0LjguIFhN TCBTY2hlbWEgZm9yIExGQiBDbGFzcyBMaWJyYXJ5IERvY3VtZW50cyANCiAgICAgICANCiAgICAg IDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+IA0KICAgICAgPHhzZDpzY2hl bWEgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgDQogICAgICAg eG1sbnM9Imh0dHA6Ly9pZXRmLm9yZy9mb3JjZXMvMS4wL2xmYm1vZGVsIiANCiAgICAgICB4bWxu czpsZmI9Imh0dHA6Ly9pZXRmLm9yZy9mb3JjZXMvMS4wL2xmYm1vZGVsIiANCiAgICANCiAgIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA2Ml0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgIHRhcmdldE5hbWVz cGFjZT0iaHR0cDovL2lldGYub3JnL2ZvcmNlcy8xLjAvbGZibW9kZWwiIA0KICAgICAgIGF0dHJp YnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCIgDQogICAgICAgZWxlbWVudEZvcm1EZWZhdWx0 PSJxdWFsaWZpZWQiPiANCiAgICAgIDx4c2Q6YW5ub3RhdGlvbj4gDQogICAgICAgIDx4c2Q6ZG9j dW1lbnRhdGlvbiB4bWw6bGFuZz0iZW4iPiANCiAgICAgICAgU2NoZW1hIGZvciBEZWZpbmluZyBM RkIgQ2xhc3NlcyBhbmQgYXNzb2NpYXRlZCB0eXBlcyAoZnJhbWVzLCANCiAgICAgICAgZGF0YSB0 eXBlcyBmb3IgTEZCIGF0dHJpYnV0ZXMsIGFuZCBtZXRhZGF0YSkuIA0KICAgICAgICA8L3hzZDpk b2N1bWVudGF0aW9uPiANCiAgICAgIDwveHNkOmFubm90YXRpb24+IA0KICAgICAgPHhzZDplbGVt ZW50IG5hbWU9ImRlc2NyaXB0aW9uIiB0eXBlPSJ4c2Q6c3RyaW5nIi8+IA0KICAgICAgPHhzZDpl bGVtZW50IG5hbWU9InN5bm9wc2lzIiB0eXBlPSJ4c2Q6c3RyaW5nIi8+IA0KICAgICAgPCEtLSBE b2N1bWVudCByb290IGVsZW1lbnQ6IExGQkxpYnJhcnkgLS0+IA0KICAgICAgPHhzZDplbGVtZW50 IG5hbWU9IkxGQkxpYnJhcnkiPiANCiAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAg ICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJkZXNjcmlw dGlvbiIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Imxv YWQiIHR5cGU9ImxvYWRUeXBlIiBtaW5PY2N1cnM9IjAiIA0KICAgICAgICAgICAgICAgICAgICAg ICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5h bWU9ImZyYW1lRGVmcyIgdHlwZT0iZnJhbWVEZWZzVHlwZSIgDQogICAgICAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImRh dGFUeXBlRGVmcyIgdHlwZT0iZGF0YVR5cGVEZWZzVHlwZSIgDQogICAgICAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Im1l dGFkYXRhRGVmcyIgdHlwZT0ibWV0YWRhdGFEZWZzVHlwZSIgDQogICAgICAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9IkxG QkNsYXNzRGVmcyIgdHlwZT0iTEZCQ2xhc3NEZWZzVHlwZSIgDQogICAgICAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAg ICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJwcm92aWRlcyIgdHlwZT0ieHNkOk5hbWUiIA0KICAg ICAgdXNlPSJyZXF1aXJlZCIvPiANCiAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAg ICA8IS0tIFVuaXF1ZW5lc3MgY29uc3RyYWludHMgLS0+IA0KICAgICAgICA8eHNkOmtleSBuYW1l PSJmcmFtZSI+IA0KICAgICAgICAgIDx4c2Q6c2VsZWN0b3IgeHBhdGg9ImxmYjpmcmFtZURlZnMv bGZiOmZyYW1lRGVmIi8+IA0KICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9ImxmYjpuYW1lIi8+ IA0KICAgICAgICA8L3hzZDprZXk+IA0KICAgICAgICA8eHNkOmtleSBuYW1lPSJkYXRhVHlwZSI+ IA0KICAgICAgICAgIDx4c2Q6c2VsZWN0b3IgeHBhdGg9ImxmYjpkYXRhVHlwZURlZnMvbGZiOmRh dGFUeXBlRGVmIi8+IA0KICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9ImxmYjpuYW1lIi8+IA0K ICAgICAgICA8L3hzZDprZXk+IA0KICAgICAgICA8eHNkOmtleSBuYW1lPSJtZXRhZGF0YURlZiI+ IA0KICAgICAgICAgIDx4c2Q6c2VsZWN0b3IgeHBhdGg9ImxmYjptZXRhZGF0YURlZnMvbGZiOm1l dGFkYXRhRGVmIi8+IA0KICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9ImxmYjpuYW1lIi8+IA0K ICAgICAgICA8L3hzZDprZXk+IA0KICAgICAgICA8eHNkOmtleSBuYW1lPSJMRkJDbGFzc0RlZiI+ IA0KICAgICAgICAgIDx4c2Q6c2VsZWN0b3IgeHBhdGg9ImxmYjpMRkJDbGFzc0RlZnMvbGZiOkxG QkNsYXNzRGVmIi8+IA0KICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9ImxmYjpuYW1lIi8+IA0K ICAgICAgICA8L3hzZDprZXk+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDYzXSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgIDx4c2Q6Y29tcGxleFR5 cGUgbmFtZT0ibG9hZFR5cGUiPiANCiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibGlicmFy eSIgdHlwZT0ieHNkOk5hbWUiIHVzZT0icmVxdWlyZWQiLz4gDQogICAgICAgIDx4c2Q6YXR0cmli dXRlIG5hbWU9ImxvY2F0aW9uIiB0eXBlPSJ4c2Q6YW55VVJJIiANCiAgICAgIHVzZT0ib3B0aW9u YWwiLz4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBl IG5hbWU9ImZyYW1lRGVmc1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAg ICAgPHhzZDplbGVtZW50IG5hbWU9ImZyYW1lRGVmIiBtYXhPY2N1cnM9InVuYm91bmRlZCI+IA0K ICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgICAgIDx4c2Q6c2VxdWVu Y2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6 Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJzeW5vcHNpcyIv PiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJkZXNjcmlwdGlvbiIgbWluT2Nj dXJzPSIwIi8+IA0KICAgICAgICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICA8 L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgPC94c2Q6ZWxlbWVudD4gDQogICAgICAgIDwv eHNkOnNlcXVlbmNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6Y29t cGxleFR5cGUgbmFtZT0iZGF0YVR5cGVEZWZzVHlwZSI+IA0KICAgICAgICA8eHNkOnNlcXVlbmNl PiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZGF0YVR5cGVEZWYiIG1heE9jY3Vycz0i dW5ib3VuZGVkIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAg ICAgPHhzZDpzZXF1ZW5jZT4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9Im5h bWUiIHR5cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBy ZWY9InN5bm9wc2lzIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9ImRlc2Ny aXB0aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgICAgPHhzZDpncm91cCByZWY9 InR5cGVEZWNsYXJhdGlvbkdyb3VwIi8+IA0KICAgICAgICAgICAgICA8L3hzZDpzZXF1ZW5jZT4g DQogICAgICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgPC94c2Q6ZWxlbWVu dD4gDQogICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiAN CiAgICAgIDwhLS0gDQogICAgICAgICBQcmVkZWZpbmVkIChidWlsdC1pbikgYXRvbWljIGRhdGEt dHlwZXMgYXJlOiANCiAgICAgICAgICAgICBjaGFyLCB1Y2hhciwgaW50MTYsIHVpbnQxNiwgaW50 MzIsIHVpbnQzMiwgaW50NjQsIHVpbnQ2NCwgDQogICAgICAgICAgICAgc3RyaW5nW05dLCBieXRl W05dLCBib29sZWFuLCANCiAgICAgICAgICAgICBmbG9hdDE2LCBmbG9hdDMyLCBmbG9hdDY0IA0K ICAgICAgLS0+IA0KICAgICAgPHhzZDpncm91cCBuYW1lPSJ0eXBlRGVjbGFyYXRpb25Hcm91cCI+ IA0KICAgICAgICA8eHNkOmNob2ljZT4gDQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InR5 cGVSZWYiIHR5cGU9InR5cGVSZWZOTVRPS0VOIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJhdG9taWMiIHR5cGU9ImF0b21pY1R5cGUiLz4gDQogICAgICAgICAgPHhzZDplbGVtZW50 IG5hbWU9ImFycmF5IiB0eXBlPSJhcnJheVR5cGUiLz4gDQogICAgICAgICAgPHhzZDplbGVtZW50 IG5hbWU9InN0cnVjdCIgdHlwZT0ic3RydWN0VHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0idW5pb24iIHR5cGU9InN0cnVjdFR5cGUiLz4gDQogICAgICAgICAgPHhzZDplbGVt ZW50IG5hbWU9lGFsaWFzlCB0eXBlPSJ0eXBlUmVmTk1UT0tFTiIvPiANCiAgICANCiAgIFlhbmcs IGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSA2NF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICA8L3hzZDpjaG9pY2U+ IA0KICAgICAgPC94c2Q6Z3JvdXA+IA0KICAgICAgPHhzZDpzaW1wbGVUeXBlIG5hbWU9InR5cGVS ZWZOTVRPS0VOIj4gDQogICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnRva2VuIj4g DQogICAgICAgICAgPHhzZDpwYXR0ZXJuIHZhbHVlPSJcYysiLz4gDQogICAgICAgICAgPHhzZDpw YXR0ZXJuIHZhbHVlPSJzdHJpbmdcW1xkK1xdIi8+IA0KICAgICAgICAgIDx4c2Q6cGF0dGVybiB2 YWx1ZT0iYnl0ZVxbXGQrXF0iLz4gDQogICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPiANCiAgICAg IDwveHNkOnNpbXBsZVR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJhdG9taWNU eXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJiYXNlVHlwZSIgdHlwZT0idHlwZVJlZk5NVE9LRU4iLz4gDQogICAgICAgICAgPHhzZDpl bGVtZW50IG5hbWU9InJhbmdlUmVzdHJpY3Rpb24iIA0KICAgICAgICAgICAgICAgICAgICAgICB0 eXBlPSJyYW5nZVJlc3RyaWN0aW9uVHlwZSBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgPHhz ZDplbGVtZW50IG5hbWU9InNwZWNpYWxWYWx1ZXMiIHR5cGU9InNwZWNpYWxWYWx1ZXNUeXBlIiAN CiAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICA8L3hzZDpz ZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhU eXBlIG5hbWU9InJhbmdlUmVzdHJpY3Rpb25UeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+ IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJhbGxvd2VkUmFuZ2UiIG1heE9jY3Vycz0i dW5ib3VuZGVkIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAg ICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibWluIiB0eXBlPSJ4c2Q6aW50ZWdlciIgDQogICAgICB1 c2U9InJlcXVpcmVkIi8+IA0KICAgICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJtYXgi IHR5cGU9InhzZDppbnRlZ2VyIiANCiAgICAgIHVzZT0icmVxdWlyZWQiLz4gDQogICAgICAgICAg ICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgPC94c2Q6ZWxlbWVudD4gDQogICAgICAg IDwveHNkOnNlcXVlbmNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6 Y29tcGxleFR5cGUgbmFtZT0ic3BlY2lhbFZhbHVlc1R5cGUiPiANCiAgICAgICAgPHhzZDpzZXF1 ZW5jZT4gDQogICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InNwZWNpYWxWYWx1ZSIgbWF4T2Nj dXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAg ICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFt ZT0ibmFtZSIgdHlwZT0ieHNkOk5NVE9LRU4iLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVt ZW50IHJlZj0ic3lub3BzaXMiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAg ICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0idmFsdWUiIHR5cGU9InhzZDp0b2tlbiIv PiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVt ZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+ IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJhcnJheVR5cGUiPiANCiAgICAgICAgPHhz ZDpzZXF1ZW5jZT4gDQogICAgICAgICAgPHhzZDpncm91cCByZWY9InR5cGVEZWNsYXJhdGlvbkdy b3VwIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJrZXkiIG1heE9jY3Vycz0idW5i b3VuZGVkIj4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNjVdIA0KDCAgIEludGVybmV0IERyYWZ0ICAg ICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAg ICANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICAgICA8eHNkOnNl cXVlbmNlPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ia2V5RmllbGQiIG1h eE9jY3Vycz0idW5ib3VuZCIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9Inhz ZDpzdHJpbmciLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAg ICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ia2V5SUQiIHVzZT0icmVxdWlyZWQiIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0eXBlPSJ4c2Q6aW50ZWdlciIvPiANCiAgICAgICAgICAgIDwv eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94 c2Q6c2VxdWVuY2U+IA0KICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ0eXBlIiB1c2U9Im9w dGlvbmFsIiANCiAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdD0idmFyaWFibGUtc2l6ZSI+ IA0KICAgICAgICAgIDx4c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICA8eHNkOnJlc3RyaWN0 aW9uIGJhc2U9InhzZDpzdHJpbmciPiANCiAgICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2 YWx1ZT0iZml4ZWQtc2l6ZSIvPiANCiAgICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1 ZT0idmFyaWFibGUtc2l6ZSIvPiANCiAgICAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9uPiANCiAg ICAgICAgICA8L3hzZDpzaW1wbGVUeXBlPiANCiAgICAgICAgPC94c2Q6YXR0cmlidXRlPiANCiAg ICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibGVuZ3RoIiB0eXBlPSJ4c2Q6aW50ZWdlciIgdXNl PSJvcHRpb25hbCIvPiANCiAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0ibWF4TGVuZ3RoIiB0 eXBlPSJ4c2Q6aW50ZWdlciIgDQogICAgICAgICAgICAgICAgICAgICAgIHVzZT0ib3B0aW9uYWwi Lz4gDQogICAgICAgIDwhl2RlY2xhcmUga2V5cyB0byBoYXZlIHVuaXF1ZSBJRHMgLS0+IA0KICAg ICAgICA8eHNkOmtleSBuYW1lPSJrZXlJRCI+IA0KICAgICAgICAgIDx4c2Q6c2VsZWN0b3IgeHBh dGg9ImxmYjprZXkiLz4gDQogICAgICAgICAgPHhzZDpmaWVsZCB4cGF0aD0iQGtleUlEIi8+IA0K ICAgICAgICA8L3hzZDprZXk+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhz ZDpjb21wbGV4VHlwZSBuYW1lPSJzdHJ1Y3RUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+ IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJlbGVtZW50IiBtYXhPY2N1cnM9InVuYm91 bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgICAgIDx4 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0 eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJz eW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ib3B0aW9uYWwi IG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmdyb3VwIHJlZj0idHlwZURl Y2xhcmF0aW9uR3JvdXAiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAg ICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZWxlbWVudElEIiB1c2U9InJlcXVpcmVkIiAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHNkOmludGVnZXIiLz4gDQogICAg ICAgICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgPC94c2Q6ZWxlbWVudD4gDQog ICAgICAgIDwveHNkOnNlcXVlbmNlPiAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZGVyaXZlZEZyb20i IA0KICAgICAgdXNlPSJvcHRpb25hbCIgDQogICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InR5 cGVSZWZOTVRPS0VOIi8+IA0KICAgICAgICA8IS0tIGtleSBkZWNsYXJhdGlvbiB0byBtYWtlIGVs ZW1lbnRJRHMgdW5pcXVlIGluIGEgc3RydWN0IC0tPiANCiAgICAgICAgPHhzZDprZXkgbmFtZT0i c3RydWN0RWxlbWVudElEIj4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1 Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNjZdIA0KDCAgIEludGVybmV0 IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSAN CiAgICANCiAgICANCiAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJsZmI6ZWxlbWVudCIv PiANCiAgICAgICAgICA8eHNkOmZpZWxkIHhwYXRoPSJAZWxlbWVudElEIi8+IA0KICAgICAgICA8 L3hzZDprZXk+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4 VHlwZSBuYW1lPSJtZXRhZGF0YURlZnNUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0K ICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJtZXRhZGF0YURlZiIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiPiANCiAgICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICAgICA8 eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibmFtZSIg dHlwZT0ieHNkOk5NVE9LRU4iLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0i c3lub3BzaXMiLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0iZGVzY3JpcHRp b24iIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmNob2ljZT4gDQogICAg ICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0idHlwZVJlZiIgdHlwZT0idHlwZVJlZk5N VE9LRU4iLz4gDQogICAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iYXRvbWljIiB0 eXBlPSJhdG9taWNUeXBlIi8+IA0KICAgICAgICAgICAgICAgIDwveHNkOmNob2ljZT4gDQogICAg ICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBl PiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0K ICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJM RkJDbGFzc0RlZnNUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4 c2Q6ZWxlbWVudCBuYW1lPSJMRkJDbGFzc0RlZiIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAg ICAgICAgICAgIDx4c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgICAgICA8eHNkOnNlcXVlbmNl PiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibmFtZSIgdHlwZT0ieHNkOk5N VE9LRU4iLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IHJlZj0ic3lub3BzaXMiLz4g DQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9InZlcnNpb24iIHR5cGU9InZlcnNp b25UeXBlIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJkZXJpdmVkRnJv bSIgdHlwZT0ieHNkOk5NVE9LRU4iIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtaW5P Y2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImlucHV0UG9y dHMiIHR5cGU9ImlucHV0UG9ydHNUeXBlIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvdXRw dXRQb3J0cyIgdHlwZT0ib3V0cHV0UG9ydHNUeXBlIiANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJhdHRyaWJ1dGVzIiB0eXBlPSJMRkJBdHRyaWJ1dGVzVHlwZSIgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0iY2FwYWJpbGl0aWVzIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlw ZT0iTEZCQ2FwYWJpbGl0aWVzVHlwZSIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAg IDx4c2Q6ZWxlbWVudCByZWY9ImRlc2NyaXB0aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAg ICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFt ZT0iTEZCQ2xhc3NJRCIgdXNlPSJyZXF1aXJlZCIgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHR5cGU9InhzZDppbnRlZ2VyIi8+IA0KICAgICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+ IA0KICAgICAgICAgICAgPCEtLSBLZXkgY29uc3RyYWludCB0byBlbnN1cmUgdW5pcXVlIGF0dHJp YnV0ZSBuYW1lcyB3aXRoaW4gDQogICAgICAgICAgICAgICAgIGEgY2xhc3M6IA0KICAgICAgICAg ICAgLS0+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDY3XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAg DQogICAgICAgICAgICA8eHNkOmtleSBuYW1lPSJhdHRyaWJ1dGVzIj4gDQogICAgICAgICAgICAg IDx4c2Q6c2VsZWN0b3IgeHBhdGg9ImxmYjphdHRyaWJ1dGVzL2xmYjphdHRyaWJ1dGUiLz4gDQog ICAgICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9ImxmYjpuYW1lIi8+IA0KICAgICAgICAgICAg PC94c2Q6a2V5PiANCiAgICAgICAgICAgIDx4c2Q6a2V5IG5hbWU9ImNhcGFiaWxpdGllcyI+IA0K ICAgICAgICAgICAgICA8eHNkOnNlbGVjdG9yIHhwYXRoPSJsZmI6Y2FwYWJpbGl0aWVzL2xmYjpj YXBhYmlsaXR5Ii8+IA0KICAgICAgICAgICAgICA8eHNkOmZpZWxkIHhwYXRoPSJsZmI6bmFtZSIv PiANCiAgICAgICAgICAgIDwveHNkOmtleT4gDQogICAgICAgICAgICA8ISCWIGRvZXMgdGhlIGFi b3ZlIGVuc3VyZSB0aGF0IGF0dHJpYnV0ZXMgYW5kIGNhcGFiaWxpdGllcyANCiAgICAgICAgICAg ICAgICAgaGF2ZSBkaWZmZXJlbnQgbmFtZXM/IA0KICAgICAgICAgICAgICAgICBJZiBzbywgdGhl IGZvbGxvd2luZyBpcyB0aGUgZWxlbWVudElEIGNvbnN0cmFpbnQgLiANCiAgICAgICAgICAgIDx4 c2Q6a2V5IG5hbWU9ImF0dHJpYnV0ZUlEcyI+IA0KICAgICAgICAgICAgICA8eHNkOnNlbGVjdG9y IHhwYXRoPSJsZmI6YXR0cmlidXRlcy9sZmI6YXR0cmlidXRlIi8+IA0KICAgICAgICAgICAgICA8 eHNkOmZpZWxkIHhwYXRoPSJAZWxlbWVudElEIi8+IA0KICAgICAgICAgICAgPC94c2Q6a2V5PiAN CiAgICAgICAgICAgIDx4c2Q6a2V5IG5hbWU9ImNhcGFiaWxpdHlJRHMiPiANCiAgICAgICAgICAg ICAgPHhzZDpzZWxlY3RvciB4cGF0aD0ibGZiOmF0dHJpYnV0ZXMvbGZiOmNhcGFiaWxpdHkiLz4g DQogICAgICAgICAgICAgIDx4c2Q6ZmllbGQgeHBhdGg9IkBlbGVtZW50SUQiLz4gDQogICAgICAg ICAgICA8L3hzZDprZXk+IA0KICAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hz ZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOnNpbXBs ZVR5cGUgbmFtZT0idmVyc2lvblR5cGUiPiANCiAgICAgICAgPHhzZDpyZXN0cmljdGlvbiBiYXNl PSJ4c2Q6Tk1UT0tFTiI+IA0KICAgICAgICAgIDx4c2Q6cGF0dGVybiB2YWx1ZT0iWzEtOV1bMC05 XSpcLihbMS05XVswLTldKnwwKSIvPiANCiAgICAgICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAg ICAgPC94c2Q6c2ltcGxlVHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImlucHV0 UG9ydHNUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJpbnB1dFBvcnQiIHR5cGU9ImlucHV0UG9ydFR5cGUiIA0KICAgICAgICAgICAg ICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPiANCiAgICAgICAgPC94c2Q6c2VxdWVu Y2U+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBu YW1lPSJpbnB1dFBvcnRUeXBlIj4gDQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAg ICA8eHNkOmVsZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQg bmFtZT0iZXhwZWN0YXRpb24iIHR5cGU9InBvcnRFeHBlY3RhdGlvblR5cGUiLz4gDQogICAgICAg ICAgPHhzZDplbGVtZW50IHJlZj0iZGVzY3JpcHRpb24iIG1pbk9jY3Vycz0iMCIvPiANCiAgICAg ICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJncm91cCIg dHlwZT0iYm9vbGVhblR5cGUiIHVzZT0ib3B0aW9uYWwiIA0KICAgICAgICAgICAgICAgICAgICAg ICBkZWZhdWx0PSJubyIvPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4c2Q6 Y29tcGxleFR5cGUgbmFtZT0icG9ydEV4cGVjdGF0aW9uVHlwZSI+IA0KICAgICAgICA8eHNkOnNl cXVlbmNlPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iZnJhbWVFeHBlY3RlZCIgbWlu T2NjdXJzPSIwIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiANCiAgICANCiAgIFlh bmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA2OF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwg ICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgICA8eHNk OnNlcXVlbmNlPiANCiAgICAgICAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFt ZSBvZiBhIGRlZmluZWQgZnJhbWUgdHlwZSAtLQ0KICAgICAgPiANCiAgICAgICAgICAgICAgICA8 eHNkOmVsZW1lbnQgbmFtZT0icmVmIiB0eXBlPSJ4c2Q6c3RyaW5nIiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4gDQogICAgICAgICAgICAgIDwv eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAg ICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibWV0YWRhdGFF eHBlY3RlZCIgbWluT2NjdXJzPSIwIj4gDQogICAgICAgICAgICA8eHNkOmNvbXBsZXhUeXBlPiAN CiAgICAgICAgICAgICAgPHhzZDpjaG9pY2UgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAg ICAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgbWV0 YWRhdGEgLS0+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9 Im1ldGFkYXRhSW5wdXRSZWZUeXBlIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJvbmUtb2YiIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJtZXRhZGF0 YUlucHV0Q2hvaWNlVHlwZSIvPiANCiAgICAgICAgICAgICAgPC94c2Q6Y2hvaWNlPiANCiAgICAg ICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAg ICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAg PHhzZDpjb21wbGV4VHlwZSBuYW1lPSJtZXRhZGF0YUlucHV0Q2hvaWNlVHlwZSI+IA0KICAgICAg ICA8eHNkOmNob2ljZSBtaW5PY2N1cnM9IjIiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAg ICAgICAgPCEtLSByZWYgbXVzdCByZWZlciB0byBhIG5hbWUgb2YgYSBkZWZpbmVkIG1ldGFkYXRh IC0tPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icmVmIiB0eXBlPSJ4c2Q6Tk1UT0tF TiIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ib25lLW9mIiB0eXBlPSJtZXRhZGF0 YUlucHV0Q2hvaWNlVHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ibWV0YWRh dGFTZXQiIHR5cGU9Im1ldGFkYXRhSW5wdXRTZXRUeXBlIi8+IA0KICAgICAgICA8L3hzZDpjaG9p Y2U+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21wbGV4VHlwZSBu YW1lPSJtZXRhZGF0YUlucHV0U2V0VHlwZSI+IA0KICAgICAgICA8eHNkOmNob2ljZSBtaW5PY2N1 cnM9IjIiIG1heE9jY3Vycz0idW5ib3VuZGVkIj4gDQogICAgICAgICAgPCEtLSByZWYgbXVzdCBy ZWZlciB0byBhIG5hbWUgb2YgYSBkZWZpbmVkIG1ldGFkYXRhIC0tPiANCiAgICAgICAgICA8eHNk OmVsZW1lbnQgbmFtZT0icmVmIiB0eXBlPSJtZXRhZGF0YUlucHV0UmVmVHlwZSIvPiANCiAgICAg ICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ib25lLW9mIiB0eXBlPSJtZXRhZGF0YUlucHV0Q2hvaWNl VHlwZSIvPiANCiAgICAgICAgPC94c2Q6Y2hvaWNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBl PiANCiAgICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0ibWV0YWRhdGFJbnB1dFJlZlR5cGUiPiAN CiAgICAgICAgPHhzZDpzaW1wbGVDb250ZW50PiANCiAgICAgICAgICA8eHNkOmV4dGVuc2lvbiBi YXNlPSJ4c2Q6Tk1UT0tFTiI+IA0KICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iZGVw ZW5kZW5jeSIgdXNlPSJvcHRpb25hbCIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZh dWx0PSJyZXF1aXJlZCI+IA0KICAgICAgICAgICAgICA8eHNkOnNpbXBsZVR5cGU+IA0KICAgICAg ICAgICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyI+IA0KICAgICAgICAg ICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0icmVxdWlyZWQiLz4gDQogICAgICAgICAg ICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJvcHRpb25hbCIvPiANCiAgICAgICAgICAg ICAgICA8L3hzZDpyZXN0cmljdGlvbj4gDQogICAgICAgICAgICAgIDwveHNkOnNpbXBsZVR5cGU+ IA0KICAgICAgICAgICAgPC94c2Q6YXR0cmlidXRlPiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2OV0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFt ZT0iZGVmYXVsdFZhbHVlIiB0eXBlPSJ4c2Q6dG9rZW4iIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgdXNlPSJvcHRpb25hbCIvPiANCiAgICAgICAgICA8L3hzZDpleHRlbnNpb24+IA0KICAg ICAgICA8L3hzZDpzaW1wbGVDb250ZW50PiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAg ICAgIDx4c2Q6Y29tcGxleFR5cGUgbmFtZT0ib3V0cHV0UG9ydHNUeXBlIj4gDQogICAgICAgIDx4 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvdXRwdXRQb3J0IiB0 eXBlPSJvdXRwdXRQb3J0VHlwZSIgDQogICAgICAgICAgICAgICAgICAgICAgIG1heE9jY3Vycz0i dW5ib3VuZGVkIi8+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21w bGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im91dHB1dFBvcnRUeXBlIj4g DQogICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJu YW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJz eW5vcHNpcyIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icHJvZHVjdCIgdHlwZT0i cG9ydFByb2R1Y3RUeXBlIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCByZWY9ImRlc2NyaXB0 aW9uIiBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAg PHhzZDphdHRyaWJ1dGUgbmFtZT0iZ3JvdXAiIHR5cGU9ImJvb2xlYW5UeXBlIiB1c2U9Im9wdGlv bmFsIiANCiAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdD0ibm8iLz4gDQogICAgICA8L3hz ZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9InBvcnRQcm9kdWN0 VHlwZSI+IA0KICAgICAgICA8eHNkOnNlcXVlbmNlPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQg bmFtZT0iZnJhbWVQcm9kdWNlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQog ICAgICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDwhLS0gcmVmIG11 c3QgcmVmZXIgdG8gYSBuYW1lIG9mIGEgZGVmaW5lZCBmcmFtZSB0eXBlIC0tDQogICAgICA+IA0K ICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9InhzZDpOTVRPS0VO IiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4g DQogICAgICAgICAgICAgIDwveHNkOnNlcXVlbmNlPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBs ZXhUeXBlPiANCiAgICAgICAgICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0ibWV0YWRhdGFQcm9kdWNlZCIgbWluT2NjdXJzPSIwIj4gDQogICAgICAgICAgICA8 eHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAgICAgICAgPHhzZDpjaG9pY2UgbWF4T2NjdXJzPSJ1 bmJvdW5kZWQiPiANCiAgICAgICAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFt ZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVu dCBuYW1lPSJyZWYiIHR5cGU9Im1ldGFkYXRhT3V0cHV0UmVmVHlwZSIvPiANCiAgICAgICAgICAg ICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ib25lLW9mIiANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdHlwZT0ibWV0YWRhdGFPdXRwdXRDaG9pY2VUeXBlIi8+IA0KICAgICAgICAgICAgICA8 L3hzZDpjaG9pY2U+IA0KICAgICAgICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAg IDwveHNkOmVsZW1lbnQ+IA0KICAgICAgICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpj b21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFkYXRhT3V0cHV0 Q2hvaWNlVHlwZSI+IA0KICAgICAgICA8eHNkOmNob2ljZSBtaW5PY2N1cnM9IjIiIG1heE9jY3Vy cz0idW5ib3VuZGVkIj4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3Vz dCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNzBdIA0KDCAgIEludGVybmV0IERy YWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAg ICANCiAgICANCiAgICAgICAgICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRl ZmluZWQgbWV0YWRhdGEgLS0+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5 cGU9InhzZDpOTVRPS0VOIi8+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJvbmUtb2Yi IHR5cGU9Im1ldGFkYXRhT3V0cHV0Q2hvaWNlVHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0ibWV0YWRhdGFTZXQiIHR5cGU9Im1ldGFkYXRhT3V0cHV0U2V0VHlwZSIvPiANCiAg ICAgICAgPC94c2Q6Y2hvaWNlPiANCiAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgIDx4 c2Q6Y29tcGxleFR5cGUgbmFtZT0ibWV0YWRhdGFPdXRwdXRTZXRUeXBlIj4gDQogICAgICAgIDx4 c2Q6Y2hvaWNlIG1pbk9jY3Vycz0iMiIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPiANCiAgICAgICAg ICA8IS0tIHJlZiBtdXN0IHJlZmVyIHRvIGEgbmFtZSBvZiBhIGRlZmluZWQgbWV0YWRhdGEgLS0+ IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJyZWYiIHR5cGU9Im1ldGFkYXRhT3V0cHV0 UmVmVHlwZSIvPiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0ib25lLW9mIiB0eXBlPSJt ZXRhZGF0YU91dHB1dENob2ljZVR5cGUiLz4gDQogICAgICAgIDwveHNkOmNob2ljZT4gDQogICAg ICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNkOmNvbXBsZXhUeXBlIG5hbWU9Im1ldGFk YXRhT3V0cHV0UmVmVHlwZSI+IA0KICAgICAgICA8eHNkOnNpbXBsZUNvbnRlbnQ+IA0KICAgICAg ICAgIDx4c2Q6ZXh0ZW5zaW9uIGJhc2U9InhzZDpOTVRPS0VOIj4gDQogICAgICAgICAgICA8eHNk OmF0dHJpYnV0ZSBuYW1lPSJhdmFpbGFiaWxpdHkiIHVzZT0ib3B0aW9uYWwiIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgZGVmYXVsdD0idW5jb25kaXRpb25hbCI+IA0KICAgICAgICAgICAg ICA8eHNkOnNpbXBsZVR5cGU+IA0KICAgICAgICAgICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFz ZT0ieHNkOnN0cmluZyI+IA0KICAgICAgICAgICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1 ZT0idW5jb25kaXRpb25hbCIvPiANCiAgICAgICAgICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24g dmFsdWU9ImNvbmRpdGlvbmFsIi8+IA0KICAgICAgICAgICAgICAgIDwveHNkOnJlc3RyaWN0aW9u PiANCiAgICAgICAgICAgICAgPC94c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICA8L3hzZDph dHRyaWJ1dGU+IA0KICAgICAgICAgIDwveHNkOmV4dGVuc2lvbj4gDQogICAgICAgIDwveHNkOnNp bXBsZUNvbnRlbnQ+IA0KICAgICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpjb21w bGV4VHlwZSBuYW1lPSJMRkJBdHRyaWJ1dGVzVHlwZSI+IA0KICAgICAgICA8eHNkOnNlcXVlbmNl PiANCiAgICAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0iYXR0cmlidXRlIiBtYXhPY2N1cnM9InVu Ym91bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAgICAgICAgICAg IDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJuYW1l IiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVm PSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVmPSJkZXNjcmlw dGlvbiIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1l PSJvcHRpb25hbCIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6Z3JvdXAg cmVmPSJ0eXBlRGVjbGFyYXRpb25Hcm91cCIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1l bnQgbmFtZT0iZGVmYXVsdFZhbHVlIiB0eXBlPSJ4c2Q6dG9rZW4iIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4gDQogICAgICAgICAgICAgIDwveHNkOnNlcXVl bmNlPiANCiAgICAgICAgICAgICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iYWNjZXNzIiB1c2U9Im9w dGlvbmFsIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdD0icmVhZC13cml0 ZSI+IA0KICAgICAgICAgICAgICAgIDx4c2Q6c2ltcGxlVHlwZT4gDQogICAgICAgICAgICAgICAg ICA8eHNkOmxpc3QgaXRlbVR5cGU9ImFjY2Vzc01vZGVUeXBlIi8+IA0KICAgICAgICAgICAgICAg IDwveHNkOnNpbXBsZVR5cGU+IA0KICAgICAgICAgICAgICA8L3hzZDphdHRyaWJ1dGU+IA0KICAg IA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDcxXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBG RSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAg ICAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9ImVsZW1lbnRJRCIgdXNlPSJyZXF1aXJlZCIgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzZDppbnRlZ2VyIi8+IA0KICAgICAgICAg ICAgPC94c2Q6Y29tcGxleFR5cGU+IA0KICAgICAgICAgIDwveHNkOmVsZW1lbnQ+IA0KICAgICAg ICA8L3hzZDpzZXF1ZW5jZT4gDQogICAgICA8L3hzZDpjb21wbGV4VHlwZT4gDQogICAgICA8eHNk OnNpbXBsZVR5cGUgbmFtZT0iYWNjZXNzTW9kZVR5cGUiPiANCiAgICAgICAgPHhzZDpyZXN0cmlj dGlvbiBiYXNlPSJ4c2Q6Tk1UT0tFTiI+IA0KICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFs dWU9InJlYWQtb25seSIvPiANCiAgICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJyZWFk LXdyaXRlIi8+IA0KICAgICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9IndyaXRlLW9ubHki Lz4gDQogICAgICAgICAgPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0icmVhZC1yZXNldCIvPiANCiAg ICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJ0cmlnZ2VyLW9ubHkiLz4gDQogICAgICAg IDwveHNkOnJlc3RyaWN0aW9uPiANCiAgICAgIDwveHNkOnNpbXBsZVR5cGU+IA0KICAgICAgPHhz ZDpjb21wbGV4VHlwZSBuYW1lPSJMRkJDYXBhYmlsaXRpZXNUeXBlIj4gDQogICAgICAgIDx4c2Q6 c2VxdWVuY2U+IA0KICAgICAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJjYXBhYmlsaXR5IiBtYXhP Y2N1cnM9InVuYm91bmRlZCI+IA0KICAgICAgICAgICAgPHhzZDpjb21wbGV4VHlwZT4gDQogICAg ICAgICAgICAgIDx4c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJuYW1lIiB0eXBlPSJ4c2Q6Tk1UT0tFTiIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVs ZW1lbnQgcmVmPSJzeW5vcHNpcyIvPiANCiAgICAgICAgICAgICAgICA8eHNkOmVsZW1lbnQgcmVm PSJkZXNjcmlwdGlvbiIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4c2Q6ZWxl bWVudCBuYW1lPSJvcHRpb25hbCIgbWluT2NjdXJzPSIwIi8+IA0KICAgICAgICAgICAgICAgIDx4 c2Q6Z3JvdXAgcmVmPSJ0eXBlRGVjbGFyYXRpb25Hcm91cCIvPiANCiAgICAgICAgICAgICAgPC94 c2Q6c2VxdWVuY2U+IA0KICAgICAgICAgICAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJlbGVtZW50 SUQiIHVzZT0icmVxdWlyZWQiIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJ4 c2Q6aW50ZWdlciIvPiANCiAgICAgICAgICAgIDwveHNkOmNvbXBsZXhUeXBlPiANCiAgICAgICAg ICA8L3hzZDplbGVtZW50PiANCiAgICAgICAgPC94c2Q6c2VxdWVuY2U+IA0KICAgICAgPC94c2Q6 Y29tcGxleFR5cGU+IA0KICAgICAgPHhzZDpzaW1wbGVUeXBlIG5hbWU9ImJvb2xlYW5UeXBlIj4g DQogICAgICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyI+IA0KICAgICAgICAg IDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9InllcyIvPiANCiAgICAgICAgICA8eHNkOmVudW1lcmF0 aW9uIHZhbHVlPSJubyIvPiANCiAgICAgICAgPC94c2Q6cmVzdHJpY3Rpb24+IA0KICAgICAgPC94 c2Q6c2ltcGxlVHlwZT4gDQogICAgICA8L3hzZDpzY2hlbWE+IA0KICAgIA0KICAgNS4gDSAgICAg RkUgQXR0cmlidXRlcyBhbmQgQ2FwYWJpbGl0aWVzIA0KICAgICAgIA0KICAgICAgQSBGb3JDRVMg Zm9yd2FyZGluZyBlbGVtZW50IGhhbmRsZXMgdHJhZmZpYyBvbiBiZWhhbGYgb2YgYSBGb3JDRVMg DQogICAgICBjb250cm9sIGVsZW1lbnQuICBXaGlsZSB0aGUgc3RhbmRhcmRzIHdpbGwgZGVzY3Jp YmUgdGhlIHByb3RvY29sIA0KICAgICAgYW5kIG1lY2hhbmlzbXMgZm9yIHRoaXMgY29udHJvbCwg ZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBhbmQgDQogICAgICBkaWZmZXJlbnQgaW5zdGFuY2Vz IHdpbGwgaGF2ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzLiAgVGhlIENFIA0KICAgICAgbmVlZHMg dG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hhdCBlYWNoIGluc3RhbmNlIGl0IGlzIHJlc3BvbnNp YmxlIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDcyXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg IEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQog ICAgICBmb3IgaXMgYWN0dWFsbHkgY2FwYWJsZSBvZiBkb2luZy4gIEFzIHN0YXRlZCBwcmV2aW91 c2x5LCB0aGlzIGlzIA0KICAgICAgYW4gYXBwcm94aW1hdGlvbi4gIFRoZSBDRSBpcyBleHBlY3Rl ZCB0byBiZSBwcmVwYXJlZCB0byBjb3BlIHdpdGggDQogICAgICBlcnJvcnMgaW4gcmVxdWVzdHMg YW5kIHZhcmlhdGlvbnMgaW4gZGV0YWlsIG5vdCBjYXB0dXJlZCBieSB0aGUgDQogICAgICBjYXBh YmlsaXRpZXMgaW5mb3JtYXRpb24gYWJvdXQgYW4gRkUuIA0KICAgICAgIA0KICAgICAgSW4gYWRk aXRpb24gdG8gaXRzIGNhcGFiaWxpdGllcywgYW4gRkUgd2lsbCBoYXZlIGF0dHJpYnV0ZSANCiAg ICAgIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHVzZWQgaW4gdW5kZXJzdGFuZGluZyBhbmQgY29u dHJvbGxpbmcgdGhlIA0KICAgICAgZm9yd2FyZGluZyBvcGVyYXRpb25zLiAgU29tZSBvZiB0aGUg YXR0cmlidXRlcyB3aWxsIGJlIHJlYWQgb25seSwgDQogICAgICB3aGlsZSBvdGhlcnMgd2lsbCBh bHNvIGJlIHdyaXRlYWJsZS4gDQogICAgICAgDQogICAgICBJbiBvcmRlciB0byBtYWtlIHRoZSBG RSBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gZWFzaWx5IGFjY2Vzc2libGUsIA0KICAgICAgdGhlIGlu Zm9ybWF0aW9uIHdpbGwgYmUgc3RvcmVkIGluIGFuIExGQi4gIFRoaXMgTEZCIHdpbGwgaGF2ZSBh IA0KICAgICAgY2xhc3MsIEZFT2JqZWN0LiAgVGhlIExGQkNsYXNzSUQgZm9yIHRoaXMgY2xhc3Mg aXMgMS4gIE9ubHkgb25lIA0KICAgICAgaW5zdGFuY2Ugb2YgdGhpcyBjbGFzcyB3aWxsIGV2ZXIg YmUgcHJlc2VudCwgYW5kIHRoZSBpbnN0YW5jZSBJRCANCiAgICAgIG9mIHRoYXQgaW5zdGFuY2Ug aW4gdGhlIHByb3RvY29sIGlzIDEuICBUaHVzLCBieSByZWZlcmVuY2luZyB0aGUgDQogICAgICBl bGVtZW50cyBvZiBjbGFzczoxLCBpbnN0YW5jZToxIGEgQ0UgY2FuIGdldCBhbGwgdGhlIGluZm9y bWF0aW9uIA0KICAgICAgYWJvdXQgdGhlIEZFLiAgRm9yIG1vZGVsIGNvbXBsZXRlbmVzcywgdGhp cyBMRkIgQ2xhc3MgaXMgZGVzY3JpYmVkIA0KICAgICAgaW4gdGhpcyBzZWN0aW9uLiANCiAgICAg ICANCiAgICAgIFRoZXJlIHdpbGwgYWxzbyBiZSBhbiBGRVByb3RvY29sIExGQiBDbGFzcy4gIExG QkNsYXNzSUQgMiBpcyANCiAgICAgIHJlc2VydmVkIGZvciB0aGF0IGNsYXNzLiAgVGhlcmUgd2ls bCBiZSBvbmx5IG9uZSBpbnN0YW5jZSBvZiB0aGF0IA0KICAgICAgY2xhc3MgYXMgd2VsbC4gIERl dGFpbHMgb2YgdGhhdCBjbGFzcyBhcmUgZGVmaW5lZCBpbiB0aGUgRm9yQ0VTIA0KICAgICAgcHJv dG9jb2wgZG9jdW1lbnQuIA0KICAgICAgIA0KICAgNS4xLiBYTUwgZm9yIEZFT2JqZWN0IENsYXNz IGRlZmluaXRpb24gDQogICAgICAgDQogICAgICAgICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29k aW5nPSJVVEYtOCI/PiANCiAgICAgICAgIDxMRkJMaWJyYXJ5IHhtbG5zPSJodHRwOi8vaWV0Zi5v cmcvZm9yY2VzLzEuMC9sZmJtb2RlbCIgDQogICAgICAgICAgIHhtbG5zOnhzaT0iaHR0cDovL3d3 dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIA0KICAgICAgICAgICB4c2k6c2NoZW1h TG9jYXRpb249Imh0dHA6Ly9pZXRmLm9yZy9mb3JjZXMvMS4wL2xmYm1vZGVsIA0KICAgICAgICAg ICBwcm92aWRlcz0iRkVPYmplY3QiPiANCiAgICAgICAgICAgPGRhdGFUeXBlRGVmcz4gDQogICAg ICAgICAgICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAgICAgICAgIDxuYW1lPkxGQkFkamFjZW5j eUxpbWl0VHlwZTwvbmFtZT4gDQogICAgICAgICAgICAgICA8c3lub3BzaXM+RGVzY3JpYmluZyB0 aGUgQWRqYWNlbnQgTEZCPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICA8c3RydWN0PiANCiAg ICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPSIxIj4gDQogICAgICAgICAgICAgICAg ICAgPG5hbWU+TmVpZ2hib3JMRkI8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNp cz5JRCBmb3IgdGhhdCBMRkIgQ2xhc3M8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8 dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1lbnQ+IA0K ICAgICAgICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjIiPiANCiAgICAgICAgICAgICAg ICAgICA8bmFtZT5WaWFQb3J0czwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgPHN5bm9wc2lz PiANCiAgICAgICAgICAgICAgICAgICAgIHRoZSBwb3J0cyBvbiB3aGljaCB3ZSBjYW4gY29ubmVj dCANCiAgICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8 YXJyYXkgdHlwZT0idmFyaWFibGUtc2l6ZSI+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAg RXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDczXSANCgwg ICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVn dXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICA8IS0tIEl0IGlzIG5lY2Vzc2FyeSB0byBkZWZp bmUgdGhlIGxlbmd0aCBsaW1pdCANCiAgICAgICAgICAgVGhpcyBzaG91bGQgYmUgd2hhdGV2ZXIg d2UgZGVmaW5lIGVsc2V3aGVyZSBhcyB0aGUgIA0KICAgICAgICAgICBsaW1pdCBvZiBhIHBvcnQg bmFtZSANCiAgICAgICAtLT4gDQogICAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5TdHJpbmdb NDBdPC90eXBlUmVmPiANCiAgICAgICAgICAgICAgICAgICA8L2FycmF5PiANCiAgICAgICAgICAg ICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgIDwvc3RydWN0PiANCiAgICAgICAgICAg ICA8L2RhdGFUeXBlRGVmPiANCiAgICAgICAgICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICAg ICAgICAgPG5hbWU+UG9ydEdyb3VwTGltaXRUeXBlPC9uYW1lPiANCiAgICAgICAgICAgICAgIDxz eW5vcHNpcz4gDQogICAgICAgICAgICAgICAgIExpbWl0cyBvbiB0aGUgbnVtYmVyIG9mIHBvcnRz IGluIGEgZ2l2ZW4gZ3JvdXAgDQogICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAg ICAgICAgIDxzdHJ1Y3Q+IA0KICAgICAgICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjEi PiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5Qb3J0R3JvdXBOYW1lPC9uYW1lPiANCiAgICAg ICAgICAgICAgICAgICA8c3lub3BzaXM+R3JvdXAgTmFtZTwvc3lub3BzaXM+IA0KICAgICAgPCEt LSBBZ2FpbiwgYSBsZW5ndGggbGltaXQgaXMgbmVlZGVkIC0tPiANCiAgICAgICAgICAgICAgICAg ICA8dHlwZVJlZj5TdHJpbmdbNF08L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1l bnQ+IA0KICAgICAgICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjIiPiANCiAgICAgICAg ICAgICAgICAgICA8bmFtZT5NaW5Qb3J0Q291bnQ8L25hbWU+IA0KICAgICAgICAgICAgICAgICAg IDxzeW5vcHNpcz5NaW5pbXVtIFBvcnQgQ291bnQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAg ICAgICA8b3B0aW9uYWwvPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5 cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAgICAgICAgICAgICAgICA8 ZWxlbWVudCBlbGVtZW50SUQ9IjMiPiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5NYXhQb3J0 Q291bnQ8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5NYXggUG9ydCBDb3Vu dDwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDxvcHRpb25hbC8+IA0KICAgICAgICAg ICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwv ZWxlbWVudD4gDQogICAgICAgICAgICAgICA8L3N0cnVjdD4gDQogICAgICAgICAgICAgPC9kYXRh VHlwZURlZj4gDQogICAgICAgICAgICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAgICAgICAgIDxu YW1lPlN1cHBvcnRlZExGQlR5cGU8L25hbWU+IA0KICAgICAgICAgICAgICAgPHN5bm9wc2lzPnRh YmxlIGVudHJ5IGZvciBzdXBwb3J0ZWQgTEZCPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICA8 c3RydWN0PiANCiAgICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPSIxIj4gDQogICAg ICAgICAgICAgICAgICAgPG5hbWU+TEZCTmFtZTwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAg PHN5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICAgIFRoZSBuYW1lIG9mIGEgc3VwcG9ydGVk IExGQiBDbGFzcyANCiAgICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgIDwhLS0g YWdhaW4gd2l0aCB0aGUgbGVuZ3RoIGxpbWl0IC0tPiANCiAgICAgICAgICAgICAgICAgICA8dHlw ZVJlZj5zdHJpbmdbNDBdPC90eXBlUmVmPiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA3NF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg ICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjIiPiANCiAgICAgICAgICAgICAgICAgICA8 bmFtZT5MRkJDbGFzc0lEPC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+dGhl IGlkIG9mIGEgc3VwcG9ydGVkIExGQiBDbGFzczwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAg ICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVu dD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0iMyI+IA0KICAgICAgICAg ICAgICAgICAgIDxuYW1lPkxGQk9jY3VycmVuY2VMaW1pdDwvbmFtZT4gDQogICAgICAgICAgICAg ICAgICAgPHN5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICAgIHRoZSB1cHBlciBsaW1pdCBv ZiBpbnN0YW5jZXMgb2YgTEZCcyBvZiB0aGlzIGNsYXNzIA0KICAgICAgICAgICAgICAgICAgIDwv c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDxvcHRpb25hbC8+IA0KICAgICAgICAgICAg ICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxl bWVudD4gDQogICAgICAgICAgICAgICAgIDwhLS0gRm9yIGVhY2ggcG9ydCBncm91cCwgaG93IG1h bnkgcG9ydHMgY2FuIGV4aXN0IC0tPiANCiAgICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVu dElEPSI0Ij4gDQogICAgICAgICAgICAgICAgICAgPG5hbWU+UG9ydEdyb3VwTGltaXRzPC9uYW1l PiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+VGFibGUgb2YgUG9ydCBHcm91cCBMaW1p dHM8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8b3B0aW9uYWwvPiANCiAgICAgICAg ICAgICAgICAgICA8YXJyYXkgdHlwZT0idmFyaWFibGUtc2l6ZSI+IA0KICAgICAgICAgICAgICAg ICAgICAgPHR5cGVSZWY+UG9ydEdyb3VwTGltaXRUeXBlPC90eXBlUmVmPiANCiAgICAgICAgICAg ICAgICAgICA8L2FycmF5PiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgIDwh LS0gZm9yIHRoZSBuYW1lZCBMRkIgQ2xhc3MsIHRoZSBMRkIgQ2xhc3NlcyBpdCBtYXkgZm9sbG93 IC0tPiANCiAgICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPSI1Ij4gDQogICAgICAg ICAgICAgICAgICAgPG5hbWU+Q2FuT2NjdXJBZnRlcnM8L25hbWU+IA0KICAgICAgICAgICAgICAg ICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgICBMaXN0IG9mIExGQiBDbGFzc2Vz IHRoYXQgdGhpcyBMRkIgY2xhc3MgY2FuIGZvbGxvdyANCiAgICAgICAgICAgICAgICAgICA8L3N5 bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8b3B0aW9uYWwvPiANCiAgICAgICAgICAgICAg ICAgICA8YXJyYXkgdHlwZT0idmFyaWFibGUtc2l6ZSI+IA0KICAgICAgICAgICAgICAgICAgICAg PHR5cGVSZWY+TEZCQWRqYWNlbmN5TGltaXRUeXBlPC90eXBlUmVmPiANCiAgICAgICAgICAgICAg ICAgICA8L2FycmF5PiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgIDwhLS0g Zm9yIHRoZSBuYW1lZCBMRkIgQ2xhc3MsIHRoZSBMRkIgQ2xhc3NlcyB0aGF0IG1heSBmb2xsb3cg aXQgDQogICAgICAgIC0tPiANCiAgICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElEPSI2 Ij4gDQogICAgICAgICAgICAgICAgICAgPG5hbWU+Q2FuT2NjdXJCZWZvcmVzPC9uYW1lPiANCiAg ICAgICAgICAgICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgICAgTGlzdCBv ZiBMRkIgQ2xhc3NlcyB0aGF0IGNhbiBmb2xsb3cgdGhpcyBMRkIgY2xhc3MgDQogICAgICAgICAg ICAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPG9wdGlvbmFsLz4gDQog ICAgICAgICAgICAgICAgICAgPGFycmF5IHR5cGU9InZhcmlhYmxlLXNpemUiPiANCiAgICAgICAg ICAgICAgICAgICAgIDx0eXBlUmVmPkxGQkFkamFjZW5jeUxpbWl0VHlwZTwvdHlwZVJlZj4gDQog ICAgICAgICAgICAgICAgICAgPC9hcnJheT4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVudD4g DQogICAgICAgICAgICAgICA8L3N0cnVjdD4gDQogICAgICAgICAgICAgPC9kYXRhVHlwZURlZj4g DQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgNzVdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9y Q0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAg ICAgICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICAgICAgICAgPG5hbWU+RkVTdGF0dXNWYWx1 ZXM8L25hbWU+IA0KICAgICAgICAgICAgICAgPHN5bm9wc2lzPlRoZSBwb3NzaWJsZSB2YWx1ZXMg b2Ygc3RhdHVzPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICA8YXRvbWljPiANCiAgICAgICAg ICAgICAgICAgPGJhc2VUeXBlPnVjaGFyPC9iYXNlVHlwZT4gDQogICAgICAgICAgICAgICAgIDxz cGVjaWFsVmFsdWVzPiANCiAgICAgICAgICAgICAgICAgICA8c3BlY2lhbFZhbHVlIHZhbHVlPSIw Ij4gDQogICAgICAgICAgICAgICAgICAgICA8bmFtZT4gQWRtaW5EaXNhYmxlIDwvbmFtZT4gDQog ICAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgICAgICBG RSBpcyBhZG1pbmlzdHJhdGl2ZWx5IGRpc2FibGVkIA0KICAgICAgICAgICAgICAgICAgIDwvc3lu b3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDwvc3BlY2lhbFZhbHVlPiANCiAgICAgICAgICAg ICAgICAgICA8c3BlY2lhbFZhbHVlIHZhbHVlPSIxIj4gDQogICAgICAgICAgICAgICAgICAgICA8 bmFtZT5PcGVyRGlzYWJsZTwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+ RkUgaXMgb3BlcmF0aXZlbHkgZGlzYWJsZWQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAg ICA8L3NwZWNpYWxWYWx1ZT4gDQogICAgICAgICAgICAgICAgICAgPHNwZWNpYWxWYWx1ZSB2YWx1 ZT0iMiI+IA0KICAgICAgICAgICAgICAgICAgICAgPG5hbWU+IE9wZXJlbmFibGUgPC9uYW1lPiAN CiAgICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5GRSBpcyBvcGVyYXRpbmc8L3N5bm9wc2lz PiANCiAgICAgICAgICAgICAgICAgICA8L3NwZWNpYWxWYWx1ZT4gDQogICAgICAgICAgICAgICAg IDwvc3BlY2lhbFZhbHVlcz4gDQogICAgICAgICAgICAgICA8L2F0b21pYz4gDQogICAgICAgICAg ICAgPC9kYXRhVHlwZURlZj4gDQogICAgICAgICAgICAgPGRhdGFUeXBlRGVmPiANCiAgICAgICAg ICAgICAgIDxuYW1lPkZFQ29uZmlndXJlZE5laWdoYm9yVHlwZTwvbmFtZT4gDQogICAgICAgICAg ICAgICA8c3lub3BzaXM+RGV0YWlscyBvZiB0aGUgRkUncyBOZWlnaGJvcjwvc3lub3BzaXM+IA0K ICAgICAgICAgICAgICAgPHN0cnVjdD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1l bnRJRD0iMSI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPk5laWdoYm9ySUQ8L25hbWU+IA0K ICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5OZWlnaGJvcnMgRkVJRDwvc3lub3BzaXM+IA0K ICAgICAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4gDQogICAgICAgICAg ICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0i MiI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPmludGVyZmFjZVRvTmVpZ2hib3I8L25hbWU+ IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgICBG RSdzIGludGVyZmFjZSB0aGF0IGNvbm5lY3RzIHRvIHRoaXMgbmVpZ2hib3IgDQogICAgICAgICAg ICAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPG9wdGlvbmFsLz4gDQog ICAgICA8IS0tIHRoZSBsZW5ndGggaGVyZSBpcyB0aGUgbGVuZ3RoIG9mIGludGVyZmFjZSBuYW1l LiANCiAgICAgICAgICAgSXQgaXMgdW5mb3J0dW5hdGUgdG8gaGF2ZSB0byBsaW1pdCBpdCwgc2lu Y2UgaXQgaGFzIA0KICAgICAgICAgICBub3RoaW5nIHRvIGRvIHdpdGggdGhlIG1vZGVsIA0KICAg ICAgIC0tPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5TdHJpbmdbMjBdPC90eXBlUmVm PiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgICAgPGVsZW1l bnQgZWxlbWVudElEPSIzIj4gDQogICAgICAgICAgICAgICAgICAgPG5hbWU+bmVpZ2hib3JOZXR3 b3JrQWRkcmVzczwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPlRoZSBuZXR3 b3JrIGxheWVyIGFkZHJlc3Mgb2YgdGhlIG5laWdoYm9yIA0KICAgIA0KICAgWWFuZywgZXQgYWwu ICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDc2 XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAg ICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IFByZXN1bWFibHksIHRoZSBuZXR3b3JrIHR5cGUgY2FuIGJlIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBkZXRlcm1pbmVkIGZyb20gdGhlIGludGVyZmFjZSBpbmZvcm1hdGlvbiANCiAg ICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJl Zj5PY3RldFN0aW5nWzE2XTwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVudD4g DQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0iNCI+IA0KICAgICAgICAgICAg ICAgICAgIDxuYW1lPm5laWdoYm9yTUFDQWRkZHJlc3M8L25hbWU+IA0KICAgICAgICAgICAgICAg ICAgIDxzeW5vcHNpcz50aGUgbWVkaWEgYWNjZXNzIGNvbnRyb2wgYWRkcmVzcyBvZiANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIG5laWdoYm9yLiAgQWdhaW4sIGl0IGlzIHByZXN1 bWVkIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdHlwZSBjYW4gYmUgZGV0ZXJt aW5lZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJvbSB0aGUgaW50ZXJmYWNlIGlu Zm9ybWF0aW9uIA0KICAgICAgICAgICAgICAgICAgIDwvc3lub3BzaXM+IA0KICAgICAgICAgICAg ICAgICAgIDx0eXBlUmVmPk9jdGV0U3RyaW5nWzhdPC90eXBlUmVmPiANCiAgICAgICAgICAgICAg ICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgIDwvc3RydWN0PiANCiAgICAgICAgICAgICA8 L2RhdGFUeXBlRGVmPiANCiAgICAgICAgICAgICA8ZGF0YVR5cGVEZWY+IA0KICAgICAgICAgICAg ICAgPG5hbWU+QWNjZXNzUGVybWlzc2lvblZhbHVlczwvbmFtZT4gDQogICAgICAgICAgICAgICA8 c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICBUaGUgcG9zc2libGUgdmFsdWVzIG9mIGF0dHJp YnV0ZSBhY2Nlc3MgcGVybWlzc2lvbiANCiAgICAgICAgICAgICAgIDwvc3lub3BzaXM+IA0KICAg ICAgPCEtLSBjYW4gdGhpcyB1c2UgdGhlIGFjY2VzcyBmcm9tIHRoZSBzY2hlbWEgc29tZWhvdz8g LS0+IA0KICAgICAgICAgICAgICAgPGF0b21pYz4gDQogICAgICAgICAgICAgICAgIDxiYXNlVHlw ZT51Y2hhcjwvYmFzZVR5cGU+IA0KICAgICAgICAgICAgICAgICA8c3BlY2lhbFZhbHVlcz4gDQog ICAgICAgICAgICAgICAgICAgPHNwZWNpYWxWYWx1ZSB2YWx1ZT0iMCI+IA0KICAgICAgICAgICAg ICAgICAgICAgPG5hbWU+Tm9uZTwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgICA8c3lub3Bz aXM+QWNjZXNzIGlzIHByb2hpYml0ZWQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8 L3NwZWNpYWxWYWx1ZT4gDQogICAgICAgICAgICAgICAgICAgIDxzcGVjaWFsVmFsdWUgdmFsdWU9 IjEiPiANCiAgICAgICAgICAgICAgICAgICAgIDxuYW1lPiBSZWFkLU9ubHkgPC9uYW1lPiANCiAg ICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5BY2Nlc3MgaXMgcmVhZCBvbmx5PC9zeW5vcHNp cz4gDQogICAgICAgICAgICAgICAgICAgPC9zcGVjaWFsVmFsdWU+IA0KICAgICAgICAgICAgICAg ICAgIDxzcGVjaWFsVmFsdWUgdmFsdWU9IjIiPiANCiAgICAgICAgICAgICAgICAgICAgIDxuYW1l PldyaXRlLU9ubHk8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPiANCiAg ICAgICAgICAgICAgICAgICAgICAgVGhlIGF0dHJpYnV0ZSBtYXkgYmUgd3JpdHRlbiwgYnV0IG5v dCByZWFkIA0KICAgICAgICAgICAgICAgICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAg ICAgICAgPC9zcGVjaWFsVmFsdWU+IA0KICAgICAgICAgICAgICAgICAgIDxzcGVjaWFsVmFsdWUg dmFsdWU9IjMiPiANCiAgICAgICAgICAgICAgICAgICAgIDxuYW1lPlJlYWQtV3JpdGU8L25hbWU+ IA0KICAgICAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICAg ICAgVGhlIGF0dHJpYnV0ZSBtYXkgYmUgcmVhZCBvciB3cml0dGVuIA0KICAgICAgICAgICAgICAg ICAgICAgPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPC9zcGVjaWFsVmFsdWU+IA0K ICAgICAgICAgICAgICAgICA8L3NwZWNpYWxWYWx1ZXM+IA0KICAgICAgICAgICAgICAgPC9hdG9t aWM+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDc3XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAg IEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQog ICAgICAgICAgICAgPC9kYXRhVHlwZURlZj4gDQogICAgICAgICAgICAgPGRhdGFUeXBlRGVmPiAN CiAgICAgICAgICAgICAgIDxuYW1lPlN1cHBvcnRlZEF0dHJpYnV0ZVR5cGU8L25hbWU+IA0KICAg ICAgICAgICAgICAgPHN5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgTWFwcGluZyBiZXR3ZWVu IGF0dHJpYnV0ZXMgYW5kIGFjY2VzcyBtb2RlcyANCiAgICAgICAgICAgICAgIDwvc3lub3BzaXM+ IA0KICAgICAgICAgICAgICAgPHN0cnVjdD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVs ZW1lbnRJRD0iMSI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPkF0dHJpYnV0ZU5hbWU8L25h bWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAg ICBOYW1lIG9mIHJlZmVyZW5jZWQgQXR0cmlidXRlIA0KICAgICAgICAgICAgICAgICAgIDwvc3lu b3BzaXM+IA0KICAgICAgPCEtLSB0aGUgbGVuZ3RoIGxpbWl0IGlzc3VlIGFnYWluIC0tPiANCiAg ICAgICAgICAgICAgICAgICA8dHlwZVJlZj5TdHJpbmdbNDBdPC90eXBlUmVmPiANCiAgICAgICAg ICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgICAgPGVsZW1lbnQgZWxlbWVudElE PZQylD4gDQogICAgICAgICAgICAgICAgICAgPG5hbWU+QXR0cmlidXRlSUQ8L25hbWU+IA0KICAg ICAgICAgICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgICBUaGUgSUQg aW4gdGhlIEZFIE9iamVjdCBvZiB0aGUgYXR0cmlidXRlIA0KICAgICAgICAgICAgICAgICAgIDwv c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4g DQogICAgICAgICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50 IGVsZW1lbnRJRD0iMyI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPkFjY2Vzc01vZGVzPC9u YW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+QWNjZXNzIE1vZGVzPC9zeW5vcHNp cz4gDQogICAgICAgICAgICAgICAgICAgPHR5cGVSZWY+QWNjZXNzUGVybWlzc2lvblZhbHVlczwv dHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVudD4gDQogICAgICAgICAgICAgICA8 L3N0cnVjdD4gDQogICAgICAgICAgICAgPC9kYXRhVHlwZURlZj4gDQogICAgICAgICAgICAgPGRh dGFUeXBlRGVmPiANCiAgICAgICAgICAgICAgIDxuYW1lPkxGQlNlbGVjdG9yVHlwZTwvbmFtZT4g DQogICAgICAgICAgICAgICA8c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICBVbmlxdWUgaWRl bnRpZmljYXRpb24gb2YgYSBMRkIgY2xhc3MtaW5zdGFuY2UgDQogICAgICAgICAgICAgICA8L3N5 bm9wc2lzPiANCiAgICAgICAgICAgICAgIDxzdHJ1Y3Q+IA0KICAgICAgICAgICAgICAgICA8ZWxl bWVudCBlbGVtZW50SUQ9IjEiPiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5MRkJDbGFzc0lE PC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+TEZCIENsYXNzIElkZW50aWZp ZXI8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj51aW50MzI8L3R5cGVS ZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAgICAgICAgICAgICAgICA8ZWxl bWVudCBlbGVtZW50SUQ9IjIiPiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5MRkJJbnN0YW5j ZUlEPC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+TEZCIEluc3RhbmNlIElE PC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPHR5cGVSZWY+dWludDMyPC90eXBlUmVm PiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgIDwvc3RydWN0 PiANCiAgICAgICAgICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3OF0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgIDxkYXRhVHlwZURlZj4gDQog ICAgICAgICAgICAgICA8bmFtZT5MRkJMaW5rVHlwZTwvbmFtZT4gDQogICAgICAgICAgICAgICA8 c3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICBMaW5rIGJldHdlZW4gdHdvIExGQiBpbnN0YW5j ZXMgb2YgdG9wb2xvZ3kgDQogICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAg ICAgIDxzdHJ1Y3Q+IA0KICAgICAgICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjEiPiAN CiAgICAgICAgICAgICAgICAgICA8bmFtZT5Gcm9tTEZCSUQ8L25hbWU+IA0KICAgICAgICAgICAg ICAgICAgIDxzeW5vcHNpcz5MRkIgc3JjPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAg PHR5cGVSZWY+TEZCU2VsZWN0b3I8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1l bnQ+IA0KICAgICAgICAgICAgICAgICA8ZWxlbWVudCBlbGVtZW50SUQ9IjIiPiANCiAgICAgICAg ICAgICAgICAgICA8bmFtZT5Gcm9tUG9ydEdyb3VwPC9uYW1lPiANCiAgICAgICAgICAgICAgICAg ICA8c3lub3BzaXM+c3JjIHBvcnQgZ3JvdXA8L3N5bm9wc2lzPiANCiAgICAgIDwhLS0gYWdhaW4g dGhlIGxlbmd0aCBsaW1pdCBvbiBzdHJpbmdzIHBvcHMgdXAgLS0+IA0KICAgICAgICAgICAgICAg ICAgIDx0eXBlUmVmPlN0cmluZ1s0XTwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxl bWVudD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0iMyI+IA0KICAgICAg ICAgICAgICAgICAgIDxuYW1lPkZyb21Qb3J0SW5kZXg8L25hbWU+IA0KICAgICAgICAgICAgICAg ICAgIDxzeW5vcHNpcz5zcmMgcG9ydCBpbmRleDwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAg ICAgIDx0eXBlUmVmPnVpbnQzMjwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVu dD4gDQogICAgICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0iNCI+IA0KICAgICAgICAg ICAgICAgICAgIDxuYW1lPlRvTEZCSUQ8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5v cHNpcz5kc3QgTEZCSUQ8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5M RkJTZWxlY3RvcjwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvZWxlbWVudD4gDQogICAg ICAgICAgICAgICAgIDxlbGVtZW50IGVsZW1lbnRJRD0iNSI+IA0KICAgICAgICAgICAgICAgICAg IDxuYW1lPlRvUG9ydEdyb3VwPC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+ ZHN0IHBvcnQgZ3JvdXA8L3N5bm9wc2lzPiANCiAgICAgIDwhLS0gYWdhaW4gdGhlIHN0cmluZyBs ZW5ndGggbGltaXQgLS0+IA0KICAgICAgICAgICAgICAgICAgIDx0eXBlUmVmPlN0cmluZ1s0MF08 L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2VsZW1lbnQ+IA0KICAgICAgICAgICAgICAg ICA8ZWxlbWVudCBlbGVtZW50SUQ9IjYiPiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5Ub1Bv cnRJbmRleDwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPmRzdCBwb3J0IGlu ZGV4PC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPHR5cGVSZWY+dWludDMyPC90eXBl UmVmPiANCiAgICAgICAgICAgICAgICAgPC9lbGVtZW50PiANCiAgICAgICAgICAgICAgIDwvc3Ry dWN0PiANCiAgICAgICAgICAgICA8L2RhdGFUeXBlRGVmPiANCiAgICAgICAgICAgPC9kYXRhVHlw ZURlZnM+IA0KICAgICAgICAgICA8TEZCQ2xhc3NEZWZzPiANCiAgICAgICAgICAgICA8TEZCQ2xh c3NEZWYgTEZCQ2xhc3NJRD0iMSI+IA0KICAgICAgICAgICAgICAgPG5hbWU+RkVPYmplY3Q8L25h bWU+IA0KICAgICAgICAgICAgICAgPHN5bm9wc2lzPkNvcmUgTEZCOiBGRSBPYmplY3Q8L3N5bm9w c2lzPiANCiAgICAgICAgICAgICAgIDxjYXBhYmlsaXRpZXM+IA0KICAgICAgICAgICAgICAgICA8 Y2FwYWJpbGl0eSBlbGVtZW50SUQ9IjMwIj4gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNzldIA0KDCAg IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1 c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5Nb2RpZmlhYmxl TEZCVG9wb2xvZ3k8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz4gDQogICAg ICAgICAgICAgICAgICAgICBXaGV0aGVyIE1vZGlmaWFibGUgTEZCIGlzIHN1cHBvcnRlZCANCiAg ICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICA8b3B0aW9u YWwvPiANCiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5ib29sZWFuPC90eXBlUmVmPiANCiAg ICAgICAgICAgICAgICAgPC9jYXBhYmlsaXR5PiANCiAgICAgICAgICAgICAgICAgPGNhcGFiaWxp dHkgZWxlbWVudElEPSIzMSI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPlN1cHBvcnRlZExG QnM8L25hbWU+IA0KICAgICAgICAgICAgICAgICAgIDxzeW5vcHNpcz5MaXN0IG9mIGFsbCBzdXBw b3J0ZWQgTEZCczwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDxvcHRpb25hbC8+IA0K ICAgICAgICAgICAgICAgICAgIDxhcnJheSB0eXBlPSJ2YXJpYWJsZS1zaXplIj4gDQogICAgICAg ICAgICAgICAgICAgICA8dHlwZVJlZj5TdXBwb3J0ZWRMRkJUeXBlPC90eXBlUmVmPiANCiAgICAg ICAgICAgICAgICAgICA8L2FycmF5PiANCiAgICAgICAgICAgICAgICAgPC9jYXBhYmlsaXR5PiAN CiAgICAgICAgICAgICAgICAgPGNhcGFiaWxpdHkgZWxlbWVudElEPSIzMiI+IA0KICAgICAgICAg ICAgICAgICAgIDxzeW5vcHNpcz5MaXN0IG9mIGF0dHJpYnV0ZSBBQ0xzPC9zeW5vcHNpcz4gDQog ICAgICAgICAgICAgICAgICAgPG9wdGlvbmFsLz4gDQogICAgICAgICAgICAgICAgICAgPGFycmF5 IHR5cGU9InZhcmlhYmxlLXNpemUiPiANCiAgICAgICAgICAgICAgICAgICAgIDx0eXBlUmVmPlN1 cHBvcnRlZEF0dHJpYnV0ZVR5cGU8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICAgIDwvYXJy YXk+IA0KICAgICAgICAgICAgICAgICA8L2NhcGFiaWxpdHk+IA0KICAgICAgICAgICAgICAgPC9j YXBhYmlsaXRpZXM+IA0KICAgICAgICAgICAgICAgPGF0dHJpYnV0ZXM+IA0KICAgICAgICAgICAg ICAgICA8YXR0cmlidXRlIGFjY2Vzcz0icmVhZC13cml0ZSIgZWxlbWVudElEPSIxIj4gDQogICAg ICAgICAgICAgICAgICAgPG5hbWU+TEZCVG9wb2xvZ3k8L25hbWU+IA0KICAgICAgICAgICAgICAg ICAgIDxzeW5vcHNpcz50aGUgdGFibGUgb2Yga25vd24gVG9wb2xvZ2llczwvc3lub3BzaXM+IA0K ICAgICAgICAgICAgICAgICAgIDxhcnJheSB0eXBlPSJ2YXJpYWJsZS1zaXplIj4gDQogICAgICAg ICAgICAgICAgICAgICA8dHlwZVJlZj5MRkJMaW5rVHlwZTwvdHlwZVJlZj4gDQogICAgICAgICAg ICAgICAgICAgPC9hcnJheT4gDQogICAgICAgICAgICAgICAgIDwvYXR0cmlidXRlPiANCiAgICAg ICAgICAgICAgICAgPGF0dHJpYnV0ZSBhY2Nlc3M9InJlYWQtd3JpdGUiIGVsZW1lbnRJRD0iMiI+ IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPkxGQlNlbGVjdG9yczwvbmFtZT4gDQogICAgICAg ICAgICAgICAgICAgPHN5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAgICAgICB0YWJsZSBvZiBr bm93biBhY3RpdmUgTEZCIGNsYXNzZXMgYW5kIA0KICAgICAgICAgICAgICAgICAgICAgIGluc3Rh bmNlcyANCiAgICAgICAgICAgICAgICAgICA8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAg ICA8YXJyYXkgdHlwZT0idmFyaWFibGUtc2l6ZSI+IA0KICAgICAgICAgICAgICAgICAgICAgPHR5 cGVSZWY+TEZCU2VsZWN0b3JUeXBlPC90eXBlUmVmPiANCiAgICAgICAgICAgICAgICAgICA8L2Fy cmF5PiANCiAgICAgICAgICAgICAgICAgPC9hdHRyaWJ1dGU+IA0KICAgICAgICAgICAgICAgICA8 YXR0cmlidXRlIGFjY2Vzcz0icmVhZC13cml0ZSIgZWxlbWVudElEPSIzIj4gDQogICAgICAgICAg ICAgICAgICAgPG5hbWU+RkVOYW1lPC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3Bz aXM+bmFtZSBvZiB0aGlzIEZFPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAgICAgPHR5cGVS ZWY+c3RyaW5nWzQwXTwvdHlwZVJlZj4gDQogICAgICAgICAgICAgICAgIDwvYXR0cmlidXRlPiAN CiAgICAgICAgICAgICAgICAgPGF0dHJpYnV0ZSBhY2Nlc3M9InJlYWQtd3JpdGUiIGVsZW1lbnRJ RD0iNCI+IA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDgwXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAg ICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAg DQogICAgICAgICAgICAgICAgICAgPG5hbWU+RkVJRDwvbmFtZT4gDQogICAgICAgICAgICAgICAg ICAgPHN5bm9wc2lzPklEIG9mIHRoaXMgRkU8L3N5bm9wc2lzPiANCiAgICAgICAgICAgICAgICAg ICA8dHlwZVJlZj51aW50MzI8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2F0dHJpYnV0 ZT4gDQogICAgICAgICAgICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNzPSJyZWFkLW9ubHkiIGVsZW1l bnRJRD0iNSI+IA0KICAgICAgICAgICAgICAgICAgIDxuYW1lPkZFVmVuZG9yPC9uYW1lPiANCiAg ICAgICAgICAgICAgICAgICA8c3lub3BzaXM+dmVuZG9yIG9mIHRoaXMgRkU8L3N5bm9wc2lzPiAN CiAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5zdHJpbmdbNDBdPC90eXBlUmVmPiANCiAgICAg ICAgICAgICAgICAgPC9hdHRyaWJ1dGU+IA0KICAgICAgICAgICAgICAgICA8YXR0cmlidXRlIGFj Y2Vzcz0icmVhZC1vbmx5IiBlbGVtZW50SUQ9IjYiPiANCiAgICAgICAgICAgICAgICAgICA8bmFt ZT5GRU1vZGVsPC9uYW1lPiANCiAgICAgICAgICAgICAgICAgICA8c3lub3BzaXM+bW9kZWwgb2Yg dGhpcyBGRTwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDx0eXBlUmVmPnN0cmluZ1s0 MF08L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8L2F0dHJpYnV0ZT4gDQogICAgICAgICAg ICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNzPSJyZWFkLW9ubHkiIGVsZW1lbnRJRD0iNyI+IA0KICAg ICAgICAgICAgICAgICAgIDxuYW1lPkZFU3RhdGU8L25hbWU+IA0KICAgICAgICAgICAgICAgICAg IDxzeW5vcHNpcz5tb2RlbCBvZiB0aGlzIEZFPC9zeW5vcHNpcz4gDQogICAgICAgICAgICAgICAg ICAgPHR5cGVSZWY+RkVTdGF0dXNWYWx1ZXM8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICA8 L2F0dHJpYnV0ZT4gDQogICAgICAgICAgICAgICAgIDxhdHRyaWJ1dGUgYWNjZXNzPSJyZWFkLXdy aXRlIiBlbGVtZW50SUQ9IjgiPiANCiAgICAgICAgICAgICAgICAgICA8bmFtZT5GRU5laWdoYm9y czwvbmFtZT4gDQogICAgICAgICAgICAgICAgICAgPHN5bm9wc2lzPnRhYmxlIG9mIGtub3duIG5l aWdoYm9yczwvc3lub3BzaXM+IA0KICAgICAgICAgICAgICAgICAgIDxhcnJheSB0eXBlPSJ2YXJp YWJsZS1zaXplIj4gDQogICAgICAgICAgICAgICAgICAgICA8dHlwZVJlZj5GRUNvbmZpZ3VyZWRO ZWlnaGJvclR5cGU8L3R5cGVSZWY+IA0KICAgICAgICAgICAgICAgICAgIDwvYXJyYXk+IA0KICAg ICAgICAgICAgICAgICA8L2F0dHJpYnV0ZT4gDQogICAgICAgICAgICAgICA8L2F0dHJpYnV0ZXM+ IA0KICAgICAgICAgICAgIDwvTEZCQ2xhc3NEZWY+IA0KICAgICAgICAgICA8L0xGQkNsYXNzRGVm cz4gDQogICAgICAgICA8L0xGQkxpYnJhcnk+IA0KICAgICAgIA0KICAgNS4yLiBGRSBDYXBhYmls aXRpZXMgDQogICAgDQogICAgICBUaGUgRkUgQ2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBpcyBjb250 YWluZWQgaW4gdGhlIGNhcGFiaWxpdGllcyANCiAgICAgIGVsZW1lbnQgb2YgdGhlIGNsYXNzIGRl ZmluaXRpb24uICBBcyBkZXNjcmliZWQgZWxzZXdoZXJlLCANCiAgICAgIGNhcGFiaWxpdHkgaW5m b3JtYXRpb24gaXMgYWx3YXlzIGNvbnNpZGVyZWQgdG8gYmUgcmVhZC1vbmx5LiANCiAgICAgICAN CiAgICAgIFRoZSBjdXJyZW50bHkgZGVmaW5lZCBjYXBhYmlsaXRpZXMgYXJlIE1vZGlmaWFibGVM RkJUb3BvbG9neSwgDQogICAgICBTdXBwb3J0ZWRMRkJzIGFuZCBTdXBwb3J0ZWRBdHRyaWJ1dGVU eXBlLiANCiAgICAgICANCiAgIDUuMi4xLiAgTW9kaWZpYWJsZUxGQlRvcG9sb2d5IA0KICAgICAg IA0KICAgICAgVGhpcyBlbGVtZW50IGhhcyBhIGJvb2xlYW4gdmFsdWUgdGhhdCBpbmRpY2F0ZXMg d2hldGhlciB0aGUgTEZCIA0KICAgICAgdG9wb2xvZ3kgb2YgdGhlIEZFIG1heSBiZSBjaGFuZ2Vk IGJ5IHRoZSBDRS4gIElmIHRoZSBlbGVtZW50IGlzIA0KICAgICAgYWJzZW50LCB0aGUgZGVmYXVs dCB2YWx1ZSBpcyBhc3N1bWVkIHRvIGJlIHRydWUsIGFuZCB0aGUgQ0UgDQogICAgICBwcmVzdW1l cyB0aGUgTEZCIHRvcG9sb2d5IG1heSBiZSBjaGFuZ2VkLiAgSWYgdGhlIHZhbHVlIGlzIHByZXNl bnQgDQogICAgICBhbmQgc2V0IHRvIGZhbHNlLCB0aGUgTEZCIHRvcG9sb2d5IG9mIHRoZSBGRSBp cyBmaXhlZC4gIElmIHRoZSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVn dXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4MV0gDQoMICAgSW50ZXJuZXQg RHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0K ICAgIA0KICAgIA0KICAgICAgdG9wb2xvZ3kgaXMgZml4ZWQsIHRoZSBMRkJzIHN1cHBvcnRlZCBj bGF1c2UgbWF5IGJlIG9taXR0ZWQsIGFuZCANCiAgICAgIHRoZSBsaXN0IG9mIHN1cHBvcnRlZCBM RkJzIGlzIGluZmVycmVkIGJ5IHRoZSBDRSBmcm9tIHRoZSBMRkIgDQogICAgICB0b3BvbG9neSBp bmZvcm1hdGlvbi4gIElmIHRoZSBsaXN0IG9mIHN1cHBvcnRlZCBMRkJzIGlzIHByb3ZpZGVkIA0K ICAgICAgd2hlbiBNb2RpZmlhYmxlTEZCVG9wb2xvZ3kgaXMgZmFsc2UsIHRoZSBDYW5PY2N1ckJl Zm9yZSBhbmQgDQogICAgICBDYW5PY2N1ckFmdGVyIGluZm9ybWF0aW9uIHNob3VsZCBiZSBvbWl0 dGVkLiANCiAgICAgICANCiAgIDUuMi4yLiAgU3VwcG9ydGVkTEZCcyBhbmQgU3VwcG9ydGVkTEZC VHlwZSANCiAgICAgICANCiAgICAgIE9uZSBjYXBhYmlsaXR5IHRoYXQgdGhlIEZFIHNob3VsZCBp bmNsdWRlIGlzIHRoZSBsaXN0IG9mIHN1cHBvcnRlZCANCiAgICAgIExGQiBjbGFzc2VzLiAgVGhl IFN1cHBvcnRlZExGQnMgZWxlbWVudCwgaXMgYW4gYXJyYXkgdGhhdCBjb250YWlucyANCiAgICAg IHRoZSBpbmZvcm1hdGlvbiBhYm91dCBlYWNoIHN1cHBvcnRlZCBMRkIgQ2xhc3MuICBUaGUgYXJy YXkgDQogICAgICBzdHJ1Y3R1cmUgdHlwZSBpcyBkZWZpbmVkIGFzIHRoZSBTdXBwb3J0ZWRMRkJU eXBlIGRhdGFUeXBlRGVmLiANCiAgICAgICANCiAgICAgIEVhY2ggb2NjdXJyZW5jZSBvZiB0aGUg U3VwcG9ydGVkTEZCcyBhcnJheSBlbGVtZW50IGRlc2NyaWJlcyBhbiANCiAgICAgIExGQiBjbGFz cyB0aGF0IHRoZSBGRSBzdXBwb3J0cy4gIEluIGFkZGl0aW9uIHRvIGluZGljYXRpbmcgdGhhdCAN CiAgICAgIHRoZSBGRSBzdXBwb3J0cyB0aGUgY2xhc3MsIEZFcyB3aXRoIG1vZGlmaWFibGUgTEZC IHRvcG9sb2d5IHNob3VsZCANCiAgICAgIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgaG93IExG QnMgb2YgdGhlIHNwZWNpZmllZCBjbGFzcyBtYXkgYmUgDQogICAgICBjb25uZWN0ZWQgdG8gb3Ro ZXIgTEZCcy4gIFRoaXMgaW5mb3JtYXRpb24gc2hvdWxkIGRlc2NyaWJlIHdoaWNoIA0KICAgICAg TEZCIGNsYXNzZXMgdGhlIHNwZWNpZmllZCBMRkIgY2xhc3MgbWF5IHN1Y2NlZWQgb3IgcHJlY2Vk ZSBpbiB0aGUgDQogICAgICBMRkIgdG9wb2xvZ3kuICBUaGUgRkUgc2hvdWxkIGluY2x1ZGUgaW5m b3JtYXRpb24gYXMgdG8gd2hpY2ggcG9ydCANCiAgICAgIGdyb3VwcyBtYXkgYmUgY29ubmVjdGVk IHRvIHRoZSBnaXZlbiBhZGphY2VudCBMRkIgY2xhc3MuICBJZiBwb3J0IA0KICAgICAgZ3JvdXAg aW5mb3JtYXRpb24gaXMgb21pdHRlZCwgaXQgaXMgYXNzdW1lZCB0aGF0IGFsbCBwb3J0IGdyb3Vw cyANCiAgICAgIG1heSBiZSB1c2VkLiANCiAgICAgICANCiAgIDUuMi4yLjEuIExGQk5hbWUgDQog ICAgICAgDQogICAgICBUaGlzIGVsZW1lbnQgaGFzIGFzIGl0cyB2YWx1ZSB0aGUgbmFtZSBvZiB0 aGUgTEZCIGJlaW5nIGRlc2NyaWJlZC4gDQogICAgICAgDQogICA1LjIuMi4yLiBMRkJPY2N1cnJl bmNlTGltaXQgDQogICAgICAgDQogICAgICBUaGlzIGVsZW1lbnQsIGlmIHByZXNlbnQsIGluZGlj YXRlcyB0aGUgbGFyZ2VzdCBudW1iZXIgb2YgDQogICAgICBpbnN0YW5jZXMgb2YgdGhpcyBMRkIg Y2xhc3MgdGhlIEZFIGNhbiBzdXBwb3J0LiAgRm9yIEZFcyB0aGF0IGRvIA0KICAgICAgbm90IGhh dmUgdGhlIGNhcGFiaWxpdHkgdG8gY3JlYXRlIG9yIGRlc3Ryb3kgTEZCIGluc3RhbmNlcywgdGhp cyANCiAgICAgIGNhbiBlaXRoZXIgYmUgb21pdHRlZCBvciBiZSB0aGUgc2FtZSBhcyB0aGUgbnVt YmVyIG9mIExGQiANCiAgICAgIGluc3RhbmNlcyBvZiB0aGlzIGNsYXNzIGNvbnRhaW5lZCBpbiB0 aGUgTEZCIGxpc3QgYXR0cmlidXRlLiANCiAgICAgICANCiAgIDUuMi4yLjMuIFBvcnRHcm91cExp bWl0cyBhbmQgUG9ydEdyb3VwTGltaXRUeXBlIA0KICAgICAgIA0KICAgICAgVGhlIFBvcnRHcm91 cExpbWl0cyBlbGVtZW50IGlzIGFuIGFycmF5IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSANCiAg ICAgIHBvcnQgZ3JvdXBzIHN1cHBvcnRlZCBieSB0aGUgTEZCIGNsYXNzLiAgVGhlIHN0cnVjdHVy ZSBvZiB0aGUgcG9ydCANCiAgICAgIGdyb3VwIGxpbWl0IGluZm9ybWF0aW9uIGlzIGRlZmluZWQg YnkgdGhlIFBvcnRHcm91cExpbWl0VHlwZSANCiAgICAgIGRhdGFUeXBlRGVmLiANCiAgICAgICAN CiAgICAgIEVhY2ggUG9ydEdyb3VwTGltaXRzIGFycmF5IGVsZW1lbnQgY29udGFpbnMgaW5mb3Jt YXRpb24gZGVzY3JpYmluZyANCiAgICAgIGEgc2luZ2xlIHBvcnQgZ3JvdXAgb2YgdGhlIExGQiBj bGFzcy4gIEVhY2ggYXJyYXkgZWxlbWVudCBjb250YWlucyANCiAgICAgIHRoZSBuYW1lIG9mIHRo ZSBwb3J0IGdyb3VwIGluIHRoZSBQb3J0R3JvdXBOYW1lIGVsZW1lbnQsIHRoZSANCiAgICAgIGZl d2VzdCBudW1iZXIgb2YgcG9ydHMgdGhhdCBjYW4gZXhpc3QgaW4gdGhlIGdyb3VwIGluIHRoZSAN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA4Ml0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg TWluUG9ydENvdW50IGVsZW1lbnQsIGFuZCB0aGUgbGFyZ2VzdCBudW1iZXIgb2YgcG9ydHMgdGhh dCBjYW4gDQogICAgICBleGlzdCBpbiB0aGUgZ3JvdXAgaW4gdGhlIE1heFBvcnRDb3VudCBlbGVt ZW50LiANCiAgICAgICANCiAgIDUuMi4yLjQuQ2FuT2NjdXJBZnRlcnMgYW5kIExGQkFkamFjZW5j eUxpbWl0VHlwZSANCiAgICAgICANCiAgICAgIFRoZSBDYW5PY2N1ckFmdGVycyBlbGVtZW50IGlz IGFuIGFycmF5IHRoYXQgY29udGFpbnMgdGhlIGxpc3Qgb2YgDQogICAgICBMRkJzIHRoZSBkZXNj cmliZWQgY2xhc3MgY2FuIG9jY3VyIGFmdGVyLiAgVGhlIGFycmF5IGVsZW1lbnRzIGFyZSANCiAg ICAgIGRlZmluZWQgaW4gdGhlIExGQkFkamFjZW5jeUxpbWl0VHlwZSBkYXRhVHlwZURlZi4gDQog ICAgICAgDQogICAgICBUaGUgYXJyYXkgZWxlbWVudHMgZGVzY3JpYmUgYSBwZXJtaXNzaWJsZSBw b3NpdGlvbmluZyBvZiB0aGUgDQogICAgICBkZXNjcmliZWQgTEZCIGNsYXNzLCByZWZlcnJlZCB0 byBoZXJlIGFzIHRoZSBTdXBwb3J0ZWRMRkIuICANCiAgICAgIFNwZWNpZmljYWxseSwgZWFjaCBh cnJheSBlbGVtZW50IG5hbWVzIGFuIExGQiB0aGF0IGNhbiANCiAgICAgIHRvcG9sb2dpY2FsbHkg cHJlY2VkZSB0aGF0IExGQiBjbGFzcy4gIFRoYXQgaXMsIHRoZSBTdXBwb3J0ZWRMRkIgDQogICAg ICBjYW4gaGF2ZSBhbiBpbnB1dCBwb3J0IGNvbm5lY3RlZCB0byBhbiBvdXRwdXQgcG9ydCBvZiBh biBMRkIgdGhhdCANCiAgICAgIGFwcGVhcnMgaW4gdGhlIENhbk9jY3VyQWZ0ZXJzIGFycmF5LiAg VGhlIExGQiBjbGFzcyB0aGF0IHRoZSANCiAgICAgIFN1cHBvcnRlZExGQiBjYW4gZm9sbG93IGlz IGlkZW50aWZpZWQgYnkgdGhlIE5laWdoYm9yTEZCIGVsZW1lbnQgDQogICAgICBvZiB0aGUgTEZC QWRqYWNlbmN5TGltaXRUeXBlIGFycmF5IGVsZW1lbnQuICBJZiB0aGlzIG5laWdoYm9yIGNhbiAN CiAgICAgIG9ubHkgYmUgY29ubmVjdGVkIHRvIGEgc3BlY2lmaWMgc2V0IG9mIGlucHV0IHBvcnQg Z3JvdXBzLCB0aGVuIHRoZSANCiAgICAgIHZpYVBvcnQgZWxlbWVudCBpcyBpbmNsdWRlZC4gIFRo aXMgZWxlbWVudCBvY2N1cnMgb25jZSBmb3IgZWFjaCANCiAgICAgIGlucHV0IHBvcnQgZ3JvdXAg b2YgdGhlIFN1cHBvcnRlZExGQiB0aGF0IGNhbiBiZSBjb25uZWN0ZWQgdG8gYW4gDQogICAgICBv dXRwdXQgcG9ydCBvZiB0aGUgTmVpZ2hib3JMRkIuIA0KICAgICAgIA0KICAgICAgW2UuZy4sIFdp dGhpbiBhIFN1cHBvcnRlZExGQnMgZWxlbWVudCwgZWFjaCBhcnJheSBlbGVtZW50IG9mIHRoZSAN CiAgICAgIENhbk9jY3VyQWZ0ZXJzIGFycmF5IG11c3QgaGF2ZSBhIHVuaXF1ZSBOZWlnaGJvckxG QiwgYW5kIHdpdGhpbiANCiAgICAgIGVhY2ggYXJyYXkgZWxlbWVudCBlYWNoIHZpYVBvcnQgbXVz dCByZXByZXNlbnQgYSBkaXN0aW5jdCBhbmQgDQogICAgICB2YWxpZCBpbnB1dCBwb3J0IGdyb3Vw IG9mIHRoZSBTdXBwb3J0ZWRMRkIuICBUaGUgTEZCIENsYXNzIA0KICAgICAgZGVmaW5pdGlvbiBz Y2hlbWEgZG9lcyBub3QgeWV0IHN1cHBvcnQgdW5pcXVlbmVzcyBkZWNsYXJhdGlvbnNdIA0KICAg ICAgIA0KICAgNS4yLjIuNS4gQ2FuT2NjdXJCZWZvcmVzIGFuZCBMRkJBZGphY2VuY3lMaW1pdFR5 cGUgDQogICAgICAgDQogICAgICBUaGUgQ2FuT2NjdXJCZWZvcmVzIGFycmF5IGhvbGRzIHRoZSBp bmZvcm1hdGlvbiBhYm91dCB3aGljaCBMRkIgDQogICAgICBjbGFzc2VzIGNhbiBmb2xsb3cgdGhl IGRlc2NyaWJlZCBjbGFzcy4gIFN0cnVjdHVyYWxseSB0aGlzIGVsZW1lbnQgDQogICAgICBwYXJh bGxlbHMgQ2FuT2NjdXJBZnRlcnMsIGFuZCB1c2VzIHRoZSBzYW1lIHR5cGUgZGVmaW5pdGlvbiBm b3IgDQogICAgICB0aGUgYXJyYXkgZWxlbWVudC4gDQogICAgICAgDQogICAgICBUaGUgYXJyYXkg ZWxlbWVudHMgbGlzdCB0aG9zZSBMRkIgY2xhc3NlcyB0aGF0IHRoZSBTdXBwb3J0ZWRMRkIgDQog ICAgICBtYXkgcHJlY2VkZSBpbiB0aGUgdG9wb2xvZ3kuICBJbiB0aGlzIGVsZW1lbnQsIHRoZSAN CiAgICAgIHZpYVBvcnQgZWxlbWVudCBvZiB0aGUgYXJyYXkgdmFsdWUgcmVwcmVzZW50cyB0aGUg b3V0cHV0IHBvcnQgDQogICAgICBncm91cCBvZiB0aGUgU3VwcG9ydGVkTEZCIHRoYXQgbWF5IGJl IGNvbm5lY3RlZCB0byB0aGUgDQogICAgICBOZWlnaGJvckxGQi4gIEFzIHdpdGggQ2FuT2NjdXJB ZnRlcnMsIHZpYVBvcnQgbWF5IG9jY3VyIG11bHRpcGxlIA0KICAgICAgdGltZXMgaWYgbXVsdGlw bGUgb3V0cHV0IHBvcnRzIG1heSBsZWdpdGltYXRlbHkgY29ubmVjdCB0byB0aGUgDQogICAgICBn aXZlbiBOZWlnaGJvckxGQiBjbGFzcy4gDQogICAgICAgDQogICAgICBbQW5kIGEgc2ltaWxhciBz ZXQgb2YgdW5pcXVlbmVzcyBjb25zdHJhaW50cyBhcHBseSB0byB0aGUgDQogICAgICBDYW5PY2N1 ckJlZm9yZSBjbGF1c2VzLCBldmVuIHRob3VnaCBhbiBMRkIgbWF5IG9jY3VyIGJvdGggaW4gDQog ICAgICBDYW5PY2N1ckFmdGVyIGFuZCBDYW5PY2N1ckJlZm9yZS5dIA0KICAgICAgIA0KICAgIA0K ICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDgzXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBN b2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICA1LjIuMi42LiBM RkJDbGFzc0NhcGFiaWxpdGllcyANCiAgICAgICANCiAgICAgIFRoaXMgZWxlbWVudCBjb250YWlu cyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJqZWN0IExGQiANCiAgICAgIGNs YXNzIHdob3NlIHN0cnVjdHVyZSBhbmQgc2VtYW50aWNzIGFyZSBkZWZpbmVkIGJ5IHRoZSBMRkIg Y2xhc3MgDQogICAgICBkZWZpbml0aW9uLiAgDQogICAgICAgDQogICAgICBbTm90ZTogIEltcG9y dGFudCBPbWlzc2lvbnNdIA0KICAgICAgIA0KICAgICAgSG93ZXZlciwgdGhpcyBlbGVtZW50IGRv ZXMgbm90IGFwcGVhciBpbiB0aGUgZGVmaW5pdGlvbiwgYmVjYXVzZSANCiAgICAgIHRoZSBhdXRo b3IgY2FuIG5vdCBmaWd1cmUgb3V0IGhvdyB0byB3cml0ZSBpdC4gDQogICAgICAgDQogICA1LjIu My4gIFN1cHBvcnRlZEF0dHJpYnV0ZVR5cGUgDQogICAgICAgDQogICAgICBUaGlzIGVsZW1lbnQg c2VydmVzIGFzIGEgd3JhcHBlciB0byBob2xkIHRoZSBpbmZvcm1hdGlvbiBhYm91dCANCiAgICAg IGF0dHJpYnV0ZWQgcmVsYXRlZCBjYXBhYmlsaXRpZXMuICBTcGVjaWZpY2FsbHksIGF0dHJpYnV0 ZXMgc2hvdWxkIA0KICAgICAgYmUgZGVzY3JpYmVkIGluIHRoaXMgZWxlbWVudCBpZjogDQogICAg ICAgIGEpIHRoZXkgYXJlIG9wdGlvbmFsIGVsZW1lbnRzIGluIHRoZSBzdGFuZGFyZCBhbmQgYXJl IHN1cHBvcnRlZCANCiAgICAgICAgICAgYnkgdGhlIEZFLCBvciANCiAgICAgICAgYikgdGhlIHN0 YW5kYXJkIGFsbG93cyBmb3IgYSByYW5nZSBvZiBhY2Nlc3MgcGVybWlzc2lvbnMgKGZvciANCiAg ICAgICAgICAgZXhhbXBsZSwgcmVhZC1vbmx5IG9yIHJlYWQtd3JpdGUpLiANCiAgICANCiAgICAg IEVhY2ggYXR0cmlidXRlIHNvIGRlc2NyaWJlZCBpcyBjb250YWluZWQgaW4gdGhlIA0KICAgICAg U3VwcG9ydGVkQXR0cmlidXRlVHlwZSBlbGVtZW50LiAgVGhhdCBlbGVtZW50IGNvbnRhaW5zIGFu IA0KICAgICAgQXR0cmlidXRlTmFtZSBlbGVtZW50IHdob3NlIHZhbHVlIGlzIHRoZSBuYW1lIG9m IHRoZSBlbGVtZW50IGJlaW5nIA0KICAgICAgZGVzY3JpYmVkLCBhbmQgQXR0cmlidXRlSUQgZWxl bWVudCB3aG9zZSB2YWx1ZSBpcyB0aGUgSUQgaW4gdGhlIEZFIA0KICAgICAgT2JqZWN0IG9mIHRo ZSBBdHRyaWJ1dGUsIGFuZCBhbiBBY2Nlc3NNb2RlcyBlbGVtZW50IHdob3NlIHZhbHVlIGlzIA0K ICAgICAgdGhlIGxpc3Qgb2YgcGVybWlzc2lvbnMuIA0KICAgIA0KICAgNS4zLkZFQXR0cmlidXRl cyANCiAgICAgICANCiAgICAgIFRoZSBhdHRyaWJ1dGVzIGVsZW1lbnQgaXMgaW5jbHVkZWQgaWYg dGhlIGNsYXNzIGRlZmluaXRpb24gDQogICAgICBjb250YWlucyB0aGUgYXR0cmlidXRlcyBvZiB0 aGUgRkUgdGhhdCBhcmUgbm90IGNvbnNpZGVyZWQgDQogICAgICAiY2FwYWJpbGl0aWVzIi4gIFNv bWUgb2YgdGhlc2UgYXR0cmlidXRlcyBhcmUgd3JpdGVhYmxlLCBhbmQgc29tZSANCiAgICAgIGFy ZSByZWFkLW9ubHksIHdoaWNoIHNob3VsZCBiZSBpbmRpY2F0ZWQgYnkgdGhlIGNhcGFiaWxpdHkg DQogICAgICBpbmZvcm1hdGlvbi4gDQogICAgICAgICANCiAgICAgIFtFZGl0b3JzIG5vdGUgLSBB dCB0aGUgbW9tZW50LCB0aGUgc2V0IG9mIGF0dHJpYnV0ZXMgaXMgd29lZnVsbHkgDQogICAgICBp bmNvbXBsZXRlLl0gIA0KICAgICAgIA0KICAgNS4zLjEuICBGRVN0YXR1cyANCiAgICAgICANCiAg ICAgIFRoaXMgYXR0cmlidXRlIGNhcnJpZXMgdGhlIG92ZXJhbGwgc3RhdGUgb2YgdGhlIEZFLiAg Rm9yIG5vdywgaXQgDQogICAgICBpcyByZXN0cmljdGVkIHRvIHRoZSBzdHJpbmdzIEFkbWluRGlz YWJsZSwgT3BlckRpc2FibGUgYW5kIA0KICAgICAgT3BlckVuYWJsZS4gDQogICAgICAgDQogICA1 LjMuMi4gTEZCU2VsZWN0b3JzIGFuZCBMRkJTZWxlY3RvclR5cGUgDQogICAgICAgDQogICAgDQog ICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgODRdIA0KDCAgIEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1v ZGVsICAgICAgICAgICAgICBBdWd1c3QgMjAwNSANCiAgICANCiAgICANCiAgICAgIFRoZSBMRkJT ZWxlY3RvcnMgZWxlbWVudCBpcyBhbiBhcnJheSBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgTEZC cyANCiAgICAgIGN1cnJlbnRseSBhY2Nlc3NpYmxlIHZpYSBGb3JDRVMgaW4gdGhlIEZFLiAgVGhl IHN0cnVjdHVyZSBvZiB0aGUgDQogICAgICBMRkIgaW5mb3JtYXRpb24gaXMgZGVmaW5lZCBieSB0 aGUgTEZCU2VsZWN0b3JUeXBlLiANCiAgICAgICANCiAgICAgIEVhY2ggZW50cnkgaW4gdGhlIGFy cmF5IGRlc2NyaWJlcyBhIHNpbmdsZSBMRkIgaW5zdGFuY2UgaW4gdGhlIEZFLiAgDQogICAgICBU aGUgYXJyYXkgZWxlbWVudCBjb250YWlucyB0aGUgbnVtZXJpYyBjbGFzcyBJRCBvZiB0aGUgY2xh c3Mgb2YgDQogICAgICB0aGUgTEZCIGluc3RhbmNlIGFuZCB0aGUgbnVtZXJpYyBpbnN0YW5jZSBJ RCBmb3IgdGhpcyBpbnN0YW5jZS4gDQogICAgICAgDQogICA1LjMuMy4gIExGQlRvcG9sb2d5IGFu ZCBMRkJMaW5rVHlwZSANCiAgICAgICANCiAgICAgIFRoZSBvcHRpb25hbCBMRkJUb3BvbG9neSBl bGVtZW50IGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IGVhY2ggDQogICAgICBpbnRlci1MRkIg bGluayBpbnNpZGUgdGhlIEZFLCB3aGVyZSBlYWNoIGxpbmsgaXMgZGVzY3JpYmVkIGluIGFuIA0K ICAgICAgTEZCTGlua1R5cGUgZWxlbWVudC4gIFRoZSBMRkJMaW5rVHlwZSBlbGVtZW50IGNvbnRh aW5zIHN1ZmZpY2llbnQgDQogICAgICBpbmZvcm1hdGlvbiB0byBpZGVudGlmeSBwcmVjaXNlbHkg dGhlIGVuZCBwb2ludHMgb2YgYSBsaW5rLiAgVGhlIA0KICAgICAgRnJvbUxGQklEIGFuZCBUb0xG QklEIGZpZWxkcyBzcGVjaWZ5IHRoZSBMRkIgaW5zdGFuY2VzIGF0IGVhY2ggZW5kIA0KICAgICAg b2YgdGhlIGxpbmssIGFuZCBtdXN0IHJlZmVyZW5jZSBMRkJzIGluIHRoZSBMRkIgaW5zdGFuY2Ug dGFibGUuICANCiAgICAgIFRoZSBGcm9tUG9ydEdyb3VwIGFuZCBUb1BvcnRHcm91cCBtdXN0IGlk ZW50aWZ5IG91dHB1dCBhbmQgaW5wdXQgDQogICAgICBwb3J0IGdyb3VwcyBkZWZpbmVkIGluIHRo ZSBMRkIgY2xhc3NlcyBvZiB0aGUgTEZCIGluc3RhbmNlcyANCiAgICAgIGlkZW50aWZpZWQgYnkg RnJvbUxGQklEIGFuZCBUb0xGQklELiAgVGhlIEZyb21Qb3J0SW5kZXggYW5kIA0KICAgICAgVG9Q b3J0SW5kZXggZmllbGRzIHNlbGVjdCB0aGUgZWxlbWVudHMgZnJvbSB0aGUgcG9ydCBncm91cHMg dGhhdCANCiAgICAgIHRoaXMgbGluayBjb25uZWN0cy4gIEFsbCBsaW5rcyBhcmUgdW5pcXVlbHkg aWRlbnRpZmllZCBieSB0aGUgDQogICAgICBGcm9tTEZCSUQsIEZyb21Qb3J0R3JvdXAsIGFuZCBG cm9tUG9ydEluZGV4IGZpZWxkcy4gIE11bHRpcGxlIA0KICAgICAgbGlua3MgbWF5IGhhdmUgdGhl IHNhbWUgVG9MRkJJRCwgVG9Qb3J0R3JvdXAsIGFuZCBUb1BvcnRJbmRleCBhcyANCiAgICAgIHRo aXMgbW9kZWwgc3VwcG9ydHMgZmFuIGluIG9mIGludGVyLUxGQiBsaW5rcyBidXQgbm90IGZhbiBv dXQuIA0KICAgICAgIA0KICAgNS4zLjQuICBGRU5laWdoYm9ycyBhbiBGRUNvbmZpZ3VyZWROZWln aGJvclR5cGUgDQogICAgICAgDQogICAgICBUaGUgRkVOZWlnaGJvcnMgZWxlbWVudCBpcyBhbiBh cnJheSBvZiBpbmZvcm1hdGlvbiBhYm91dCBtYW51YWxseSANCiAgICAgIGNvbmZpZ3VyZWQgYWRq YWNlbmNpZXMgYmV0d2VlbiB0aGlzIEZFIGFuZCBvdGhlciBGRXMuICBUaGUgY29udGVudCANCiAg ICAgIG9mIHRoZSBhcnJheSBpcyBkZWZpbmVkIGJ5IHRoZSBGRUNvbmZpZ3VyZWROZWlnaGJvclR5 cGUgZWxlbWVudC4gDQogICAgICAgDQogICAgICBUaGlzIGFycmF5IGlzIGludGVuZGVkIHRvIGNh cHR1cmUgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgDQogICAgICBjb25maWd1cmVkIG9uIHRoZSBG RSBhbmQgaXMgbmVlZGVkIGJ5IHRoZSBDRSwgd2hlcmUgb25lIGFycmF5IA0KICAgICAgZW50cnkg Y29ycmVzcG9uZHMgdG8gZWFjaCBjb25maWd1cmVkIG5laWdoYm9yLiAgTm90ZSB0aGF0IHRoaXMg DQogICAgICBhcnJheSBpcyBub3QgaW50ZW5kZWQgdG8gcmVwcmVzZW50IHRoZSByZXN1bHRzIG9m IGFueSBkaXNjb3ZlcnkgDQogICAgICBwcm90b2NvbHMsIGFzIHRob3NlIHdpbGwgaGF2ZSB0aGVp ciBvd24gTEZCcy4gICANCiAgICANCiAgICAgIFNpbWlsYXJseSwgdGhlIE1BQyBhZGRyZXNzIGlu Zm9ybWF0aW9uIGluIHRoZSB0YWJsZSBpcyBpbnRlbmRlZCB0byANCiAgICAgIGJlIHVzZWQgaW4g c2l0dWF0aW9ucyB3aGVyZSBuZWlnaGJvcnMgYXJlIGNvbmZpZ3VyZWQgYnkgTUFDIA0KICAgICAg YWRkcmVzcy4gIFJlc29sdXRpb24gb2YgbmV0d29yayBsYXllciB0byBNQUMgYWRkcmVzcyBpbmZv cm1hdGlvbiANCiAgICAgIHNob3VsZCBiZSBjYXB0dXJlZCBpbiBBUlAgTEZCcyBhbmQgbm90IGR1 cGxpY2F0ZWQgaW4gdGhpcyB0YWJsZS4gIA0KICAgICAgTm90ZSB0aGF0IHRoZSBzYW1lIG5laWdo Ym9yIG1heSBiZSByZWFjaGVkIHRocm91Z2ggbXVsdGlwbGUgDQogICAgICBpbnRlcmZhY2VzIG9y IGF0IG11bHRpcGxlIGFkZHJlc3Nlcy4gIFRoZXJlIGlzIG5vIHVuaXF1ZW5lc3MgDQogICAgICBy ZXF1aXJlbWVudCBvZiBhbnkgc29ydCBvbiBvY2N1cnJlbmNlcyBvZiB0aGUgRkVOZWlnaGJvcnMg ZWxlbWVudC4gDQogICAgICAgDQoNCg0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJl cyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDg1XSANCgwgICBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIw MDUgDQogICAgDQogICAgDQogICAgICBJbmZvcm1hdGlvbiBhYm91dCB0aGUgaW50ZW5kZWQgZm9y bXMgb2YgZXhjaGFuZ2Ugd2l0aCBhIGdpdmVuIA0KICAgICAgbmVpZ2hib3IgaXMgbm90IGNhcHR1 cmVkIGhlcmUsIG9ubHkgdGhlIGFkamFjZW5jeSBpbmZvcm1hdGlvbiBpcyANCiAgICAgIGluY2x1 ZGVkLiANCiAgICAgICANCiAgIDUuMy40LjEuTmVpZ2hib3JJRCANCiAgICAgICANCiAgICAgIFRo aXMgaXMgdGhlIElEIGluIHNvbWUgc3BhY2UgbWVhbmluZ2Z1bCB0byB0aGUgQ0UgZm9yIHRoZSAN CiAgICAgIG5laWdoYm9yLiAgSWYgdGhpcyB0YWJsZSByZW1haW5zLCB3ZSBwcm9iYWJseSBzaG91 bGQgYWRkIGFuIEZFSUQgDQogICAgICBmcm9tIHRoZSBzYW1lIHNwYWNlIGFzIGFuIGF0dHJpYnV0 ZSBvZiB0aGUgRkUuIA0KICAgICAgIA0KICAgNS4zLjQuMi5OZWlnaGJvckludGVyZmFjZSANCiAg ICAgICANCiAgICAgIFRoaXMgaWRlbnRpZmllcyB0aGUgaW50ZXJmYWNlIHRocm91Z2ggd2hpY2gg dGhlIG5laWdoYm9yIGlzIA0KICAgICAgcmVhY2hlZC4gDQogICAgICAgDQogICAgICBbRWRpdG9y cyBub3RlOiBBcyB0aGUgcG9ydCBzdHJ1Y3R1cmVzIGJlY29tZSBiZXR0ZXIgZGVmaW5lZCwgdGhl IA0KICAgICAgdHlwZSBmb3IgdGhpcyBzaG91bGQgYmUgZmlsbGVkIGluIHdpdGggdGhlIHR5cGVz IG5lY2Vzc2FyeSB0byANCiAgICAgIHJlZmVyZW5jZSB0aGUgdmFyaW91cyBwb3NzaWJsZSBuZWln aGJvciBpbnRlcmZhY2VzLCBpbmNsdWRlIA0KICAgICAgcGh5c2ljYWwgaW50ZXJmYWNlcywgbG9n aWNhbCB0dW5uZWxzLCB2aXJ0dWFsIGNpcmN1aXRzLCBldGMuXSANCiAgICAgICANCiAgIDUuMy40 LjMuIE5laWdoYm9yTmV0d29ya0FkZHJlc3MgDQogICAgICAgDQogICAgICBOZWlnaGJvciBjb25m aWd1cmF0aW9uIGlzIGZyZXF1ZW50bHkgZG9uZSBvbiB0aGUgYmFzaXMgb2YgYSANCiAgICAgIG5l dHdvcmsgbGF5ZXIgYWRkcmVzcy4gIEZvciBuZWlnaGJvcnMgY29uZmlndXJlZCBpbiB0aGF0IGZh c2hpb24sIA0KICAgICAgdGhpcyBpcyB3aGVyZSB0aGF0IGFkZHJlc3MgaXMgc3RvcmVkLiANCiAg ICAgICANCiAgIDUuMy40LjQuTmVpZ2hib3JNYWNBZGRyZXNzIA0KICAgICAgIA0KICAgICAgTmVp Z2hib3JzIGFyZSBzb21ldGltZXMgY29uZmlndXJlZCB1c2luZyBNQUMgbGV2ZWwgYWRkcmVzc2Vz IA0KICAgICAgKEV0aGVybmV0IE1BQyBhZGRyZXNzLCBjaXJjdWl0IGlkZW50aWZpZXJzLCBldGMu KSAgSWYgc3VjaCANCiAgICAgIGFkZHJlc3NlcyBhcmUgdXNlZCB0byBjb25maWd1cmUgdGhlIGFk amFjZW5jeSwgdGhlbiB0aGF0IA0KICAgICAgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGhlcmUuICBO b3RlIHRoYXQgb3ZlciBzb21lIHBvcnRzIHN1Y2ggYXMgDQogICAgICBwaHlzaWNhbCBwb2ludCB0 byBwb2ludCBsaW5rcyBvciB2aXJ0dWFsIGNpcmN1aXRzIGNvbnNpZGVyZWQgYXMgDQogICAgICBp bmRpdmlkdWFsIGludGVyZmFjZXMsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGVpdGhlciBmb3JtIG9m IA0KICAgICAgYWRkcmVzcy4gDQogICAgDQogICA2LiANICAgICBTYXRpc2Z5aW5nIHRoZSBSZXF1 aXJlbWVudHMgb24gRkUgTW9kZWwgDQogICAgDQogICAgICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVz IGhvdyB0aGUgcHJvcG9zZWQgRkUgbW9kZWwgbWVldHMgdGhlIA0KICAgICAgcmVxdWlyZW1lbnRz IG91dGxpbmVkIGluIFNlY3Rpb24gNSBvZiBSRkMgMzY1NCBbMV0uICBUaGUgDQogICAgICByZXF1 aXJlbWVudHMgY2FuIGJlIHNlcGFyYXRlZCBpbnRvIGdlbmVyYWwgcmVxdWlyZW1lbnRzIChTZWN0 aW9ucyANCiAgICAgIDUsIDUuMSAtIDUuNCkgYW5kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBt aW5pbWFsIHNldCBvZiBsb2dpY2FsIA0KICAgICAgZnVuY3Rpb25zIHRoYXQgdGhlIEZFIG1vZGVs IG11c3Qgc3VwcG9ydCAoU2VjdGlvbiA1LjUpLiAgDQogICAgICAgDQogICAgICBUaGUgZ2VuZXJh bCByZXF1aXJlbWVudCBvbiB0aGUgRkUgbW9kZWwgaXMgdGhhdCBpdCBiZSBhYmxlIHRvIA0KICAg ICAgZXhwcmVzcyB0aGUgbG9naWNhbCBwYWNrZXQgcHJvY2Vzc2luZyBjYXBhYmlsaXR5IG9mIHRo ZSBGRSwgDQogICAgICB0aHJvdWdoIGJvdGggYSBjYXBhYmlsaXR5IGFuZCBhIHN0YXRlIG1vZGVs LiAgSW4gYWRkaXRpb24sIHRoZSBGRSANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGly ZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4Nl0gDQoMICAgSW50 ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAy MDA1IA0KICAgIA0KICAgIA0KICAgICAgbW9kZWwgaXMgZXhwZWN0ZWQgdG8gYWxsb3cgZmxleGli bGUgaW1wbGVtZW50YXRpb25zIGFuZCBiZSANCiAgICAgIGV4dGVuc2libGUgdG8gYWxsb3cgZGVm aW5pbmcgbmV3IGxvZ2ljYWwgZnVuY3Rpb25zLiANCiAgICANCiAgICAgIEEgbWFqb3IgY29tcG9u ZW50IG9mIHRoZSBwcm9wb3NlZCBGRSBtb2RlbCBpcyB0aGUgTG9naWNhbCANCiAgICAgIEZ1bmN0 aW9uIEJsb2NrIChMRkIpIG1vZGVsLiAgRWFjaCBkaXN0aW5jdCBsb2dpY2FsIGZ1bmN0aW9uIGlu IGFuIA0KICAgICAgRkUgaXMgbW9kZWxlZCBhcyBhbiBMRkIuICBPcGVyYXRpb25hbCBwYXJhbWV0 ZXJzIG9mIHRoZSBMRkIgdGhhdCANCiAgICAgIG11c3QgYmUgdmlzaWJsZSB0byB0aGUgQ0UgYXJl IGNvbmNlcHR1YWxpemVkIGFzIExGQiBhdHRyaWJ1dGVzLiAgDQogICAgICBUaGVzZSBhdHRyaWJ1 dGVzIGV4cHJlc3MgdGhlIGNhcGFiaWxpdHkgb2YgdGhlIEZFIGFuZCBzdXBwb3J0IA0KICAgICAg ZmxleGlibGUgaW1wbGVtZW50YXRpb25zIGJ5IGFsbG93aW5nIGFuIEZFIHRvIHNwZWNpZnkgd2hp Y2ggDQogICAgICBvcHRpb25hbCBmZWF0dXJlcyBhcmUgc3VwcG9ydGVkLiBUaGUgYXR0cmlidXRl cyBhbHNvIGluZGljYXRlIA0KICAgICAgd2hldGhlciB0aGV5IGFyZSBjb25maWd1cmFibGUgYnkg dGhlIENFIGZvciBhbiBMRkIgY2xhc3MuICANCiAgICAgIENvbmZpZ3VyYWJsZSBhdHRyaWJ1dGVz IHByb3ZpZGUgdGhlIENFIHNvbWUgZmxleGliaWxpdHkgaW4gDQogICAgICBzcGVjaWZ5aW5nIHRo ZSBiZWhhdmlvciBvZiBhbiBMRkIuICBXaGVuIG11bHRpcGxlIExGQnMgYmVsb25naW5nIA0KICAg ICAgdG8gdGhlIHNhbWUgTEZCIGNsYXNzIGFyZSBpbnN0YW50aWF0ZWQgb24gYW4gRkUsIGVhY2gg b2YgdGhvc2UgDQogICAgICBMRkJzIGNvdWxkIGJlIGNvbmZpZ3VyZWQgd2l0aCBkaWZmZXJlbnQg YXR0cmlidXRlIHNldHRpbmdzLiAgQnkgDQogICAgICBxdWVyeWluZyB0aGUgc2V0dGluZ3Mgb2Yg dGhlIGF0dHJpYnV0ZXMgZm9yIGFuIGluc3RhbnRpYXRlZCBMRkIsIA0KICAgICAgdGhlIENFIGNh biBkZXRlcm1pbmUgdGhlIHN0YXRlIG9mIHRoYXQgTEZCLiAgDQogICAgDQogICAgICBJbnN0YW50 aWF0ZWQgTEZCcyBhcmUgaW50ZXJjb25uZWN0ZWQgaW4gYSBkaXJlY3RlZCBncmFwaCB0aGF0IA0K ICAgICAgZGVzY3JpYmVzIHRoZSBvcmRlcmluZyBvZiB0aGUgZnVuY3Rpb25zIHdpdGhpbiBhbiBG RS4gIFRoaXMgDQogICAgICBkaXJlY3RlZCBncmFwaCBpcyBkZXNjcmliZWQgYnkgdGhlIHRvcG9s b2d5IG1vZGVsLiAgVGhlIA0KICAgICAgY29tYmluYXRpb24gb2YgdGhlIGF0dHJpYnV0ZXMgb2Yg dGhlIGluc3RhbnRpYXRlZCBMRkJzIGFuZCB0aGUgDQogICAgICB0b3BvbG9neSBkZXNjcmliZSB0 aGUgcGFja2V0IHByb2Nlc3NpbmcgZnVuY3Rpb25zIGF2YWlsYWJsZSBvbiANCiAgICAgIHRoZSBG RSAoY3VycmVudCBzdGF0ZSkuIA0KICAgIA0KICAgICAgQW5vdGhlciBrZXkgY29tcG9uZW50IG9m IHRoZSBGRSBtb2RlbCBpcyB0aGUgRkUgYXR0cmlidXRlcy4gVGhlIA0KICAgICAgRkUgYXR0cmli dXRlcyBhcmUgdXNlZCBtYWlubHkgdG8gZGVzY3JpYmUgdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUg DQogICAgICBGRSwgYnV0IHRoZXkgYWxzbyBjb252ZXkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIEZF IHN0YXRlLiANCiAgICAgICANCiAgICAgIFRoZSBGRSBtb2RlbCBhbHNvIGluY2x1ZGVzIGEgZGVm aW5pdGlvbiBvZiB0aGUgbWluaW1hbCBzZXQgb2YgTEZCcyANCiAgICAgIHRoYXQgaXMgcmVxdWly ZWQgYnkgU2VjdGlvbiA1LjUgb2YgUkZDIDM1NjRbMV0uICBUaGUgc2VjdGlvbnMgdGhhdCANCiAg ICAgIGZvbGxvdyBwcm92aWRlIG1vcmUgZGV0YWlsIG9uIHRoZSBzcGVjaWZpY3Mgb2YgZWFjaCBv ZiB0aG9zZSBMRkJzLiANCiAgICAgIE5vdGUgdGhhdCB0aGUgZGV0YWlscyBvZiB0aGUgTEZCcyBh cmUgY29udGFpbmVkIGluIGEgc2VwYXJhdGUgTEZCIA0KICAgICAgQ2xhc3MgTGlicmFyeSBkb2N1 bWVudC4gW0VESVRPUiAtIG5lZWQgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIHRoYXQgDQogICAgICBk b2N1bWVudF0uIA0KICAgICAgIA0KICAgNi4xLiBQb3J0IEZ1bmN0aW9ucyANCiAgICANCiAgICAg IFRoZSBGRSBtb2RlbCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgYSBQb3J0IExGQiBjbGFzcyBhbmQg aXRzIA0KICAgICAgdGVjaG5vbG9neS1zcGVjaWZpYyBzdWJjbGFzc2VzIHRvIG1hcCB0aGUgcGh5 c2ljYWwgcG9ydCBvZiB0aGUgDQogICAgICBkZXZpY2UgdG8gdGhlIExGQiBtb2RlbCB3aXRoIGJv dGggc3RhdGljIGFuZCBjb25maWd1cmFibGUgDQogICAgICBhdHRyaWJ1dGVzLiAgVGhlIHN0YXRp YyBhdHRyaWJ1dGVzIG1vZGVsIHRoZSB0eXBlIG9mIHBvcnQsIGxpbmsgDQogICAgICBzcGVlZCwg ZXRjLiAgVGhlIGNvbmZpZ3VyYWJsZSBhdHRyaWJ1dGVzIG1vZGVsIHRoZSBhZGRyZXNzaW5nLCAN CiAgICAgIGFkbWluaXN0cmF0aXZlIHN0YXR1cywgZXRjLiAgDQogICAgDQogICA2LjIuIEZvcndh cmRpbmcgRnVuY3Rpb25zIA0KICAgICAgIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhw aXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDg3XSANCgwgICBJ bnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0 IDIwMDUgDQogICAgDQogICAgDQogICAgICBCZWNhdXNlIGZvcndhcmRpbmcgZnVuY3Rpb24gaXMg b25lIG9mIHRoZSBtb3N0IGNvbW1vbiBhbmQgDQogICAgICBpbXBvcnRhbnQgZnVuY3Rpb25zIGlu IHRoZSBmb3J3YXJkaW5nIHBsYW5lLCBpdCByZXF1aXJlcyBzcGVjaWFsIA0KICAgICAgYXR0ZW50 aW9uIGluIG1vZGVsaW5nIHRvIGFsbG93IGRlc2lnbiBmbGV4aWJpbGl0eSwgaW1wbGVtZW50YXRp b24gDQogICAgICBlZmZpY2llbmN5LCBtb2RlbGluZyBhY2N1cmFjeSBhbmQgY29uZmlndXJhdGlv biBzaW1wbGljaXR5LiAgDQogICAgICBUb3dhcmQgdGhhdCBlbmQsIGl0IGlzIHJlY29tbWVuZGVk IHRoYXQgdGhlIGNvcmUgZm9yd2FyZGluZyANCiAgICAgIGZ1bmN0aW9uIGJlaW5nIG1vZGVsZWQg YnkgdGhlIGNvbWJpbmF0aW9uIG9mIHR3byBMRkJzIC0tIExvbmdlc3QgDQogICAgICBQcmVmaXgg TWF0Y2ggKExQTSkgY2xhc3NpZmllciBMRkIgYW5kIE5leHQgSG9wIExGQi4gU3BlY2lhbCBoZWFk ZXIgDQogICAgICB3cml0ZXIgTEZCICBpcyBhbHNvIG5lZWRlZCB0byB0YWtlIGNhcmUgb2YgVFRM IGRlY3JlbWVudCBhbmQgDQogICAgICBjaGVja3N1bSBldGMuIA0KICAgIA0KICAgNi4zLiBRb1Mg RnVuY3Rpb25zIA0KICAgICAgIA0KICAgICAgVGhlIExGQiBjbGFzcyBsaWJyYXJ5IGluY2x1ZGVz IGRlc2NyaXB0aW9ucyBvZiB0aGUgTWV0ZXIsIFF1ZXVlICwgDQogICAgICBTY2hlZHVsZXIsIENv dW50ZXIgYW5kIERyb3BwZXIgTEZCcyB0byBzdXBwb3J0IHRoZSBRb1MgZnVuY3Rpb25zIA0KICAg ICAgaW4gdGhlIGZvcndhcmRpbmcgcGF0aC4gIFRoZSBGRSBtb2RlbCBjYW4gYWxzbyBiZSB1c2Vk IHRvIGRlZmluZSANCiAgICAgIG90aGVyIHVzZWZ1bCBRb1MgZnVuY3Rpb25zIGFzIG5lZWRlZC4g IFRoZXNlIExGQnMgYWxsb3cgdGhlIENFIHRvIA0KICAgICAgbWFuaXB1bGF0ZSB0aGUgYXR0cmli dXRlcyB0byBtb2RlbCBJbnRTZXJ2IG9yIERpZmZTZXJ2IGZ1bmN0aW9ucy4gIA0KICAgICAgIA0K ICAgNi40LiBHZW5lcmljIEZpbHRlcmluZyBGdW5jdGlvbnMgDQogICAgDQogICAgICBWYXJpb3Vz IGNvbWJpbmF0aW9ucyBvZiBDbGFzc2lmaWVyLCBSZWRpcmVjdG9yLCBNZXRlciBhbmQgRHJvcHBl ciANCiAgICAgIExGQnMgY2FuIGJlIHVzZWQgdG8gbW9kZWwgYSBjb21wbGV4IHNldCBvZiBmaWx0 ZXJpbmcgZnVuY3Rpb25zLiAgDQogICAgDQogICA2LjUuIFZlbmRvciBTcGVjaWZpYyBGdW5jdGlv bnMgDQogICAgDQogICAgICBOZXcgTEZCIGNsYXNzZXMgY2FuIGJlIGRlZmluZWQgYWNjb3JkaW5n IHRvIHRoZSBMRkIgbW9kZWwgYXMgDQogICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0IHRvIHN1 cHBvcnQgdmVuZG9yIHNwZWNpZmljIGZ1bmN0aW9ucy4gIEEgDQogICAgICBuZXcgTEZCIGNsYXNz IGNhbiBhbHNvIGJlIGRlcml2ZWQgZnJvbSBhbiBleGlzdGluZyBMRkIgY2xhc3MgDQogICAgICB0 aHJvdWdoIGluaGVyaXRhbmNlLiAgIA0KICAgICAgICAgICANCiAgIDYuNi5IaWdoLVRvdWNoIEZ1 bmN0aW9ucyANCiAgICAgICANCiAgICAgIEhpZ2gtdG91Y2ggZnVuY3Rpb25zIGFyZSB0aG9zZSB0 aGF0IHRha2UgYWN0aW9uIG9uIHRoZSBjb250ZW50cyBvciANCiAgICAgIGhlYWRlcnMgb2YgYSBw YWNrZXQgYmFzZWQgb24gY29udGVudCBvdGhlciB0aGFuIHdoYXQgaXMgZm91bmQgaW4gDQogICAg ICB0aGUgSVAgaGVhZGVyLiAgRXhhbXBsZXMgb2Ygc3VjaCBmdW5jdGlvbnMgaW5jbHVkZSBOQVQs IEFMRywgDQogICAgICBmaXJld2FsbCwgdHVubmVsaW5nIGFuZCBMNyBjb250ZW50IHJlY29nbml0 aW9uLiAgSXQgaXMgbm90IA0KICAgICAgcHJhY3RpY2FsIHRvIGluY2x1ZGUgYWxsIHBvc3NpYmxl IGhpZ2gtdG91Y2ggZnVuY3Rpb25zIGluIHRoZSANCiAgICAgIGluaXRpYWwgTEZCIGxpYnJhcnkg ZHVlIHRvIHRoZSBudW1iZXIgYW5kIGNvbXBsZXhpdHkuIEhvd2V2ZXIsIHRoZSANCiAgICAgIGZs ZXhpYmlsaXR5IG9mIHRoZSBMRkIgbW9kZWwgYW5kIHRoZSBwb3dlciBvZiBpbnRlcmNvbm5lY3Rp b24gaW4gDQogICAgICBMRkIgdG9wb2xvZ3kgc2hvdWxkIG1ha2UgaXQgcG9zc2libGUgdG8gbW9k ZWwgYW55IGhpZ2gtdG91Y2ggDQogICAgICBmdW5jdGlvbnMuIA0KICAgIA0KICAgNi43LiBTZWN1 cml0eSBGdW5jdGlvbnMgDQogICAgICAgDQogICAgICBTZWN1cml0eSBmdW5jdGlvbnMgYXJlIG5v dCBpbmNsdWRlZCBpbiB0aGUgaW5pdGlhbCBMRkIgY2xhc3MgDQogICAgICBsaWJyYXJ5LiAgSG93 ZXZlciwgdGhlIEZFIG1vZGVsIGlzIGZsZXhpYmxlIGFuZCBwb3dlcmZ1bCBlbm91Z2ggdG8gDQoN CiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA4OF0gDQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JD RVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAg bW9kZWwgdGhlIHR5cGVzIG9mIGVuY3J5cHRpb24gYW5kL29yIGRlY3J5cHRpb24gZnVuY3Rpb25z IHRoYXQgYW4gDQogICAgICBGRSBzdXBwb3J0cyBhbmQgdGhlIGFzc29jaWF0ZWQgYXR0cmlidXRl cyBmb3Igc3VjaCBmdW5jdGlvbnMuICANCiAgICAgICANCiAgICAgIFRoZSBJUCBTZWN1cml0eSBQ b2xpY3kgKElQU1ApIFdvcmtpbmcgR3JvdXAgaW4gdGhlIElFVEYgaGFzIA0KICAgICAgc3RhcnRl ZCB3b3JrIGluIGRlZmluaW5nIHRoZSBJUFNlYyBQb2xpY3kgSW5mb3JtYXRpb24gQmFzZSBbOF0u ICANCiAgICAgIFdlIHdpbGwgdHJ5IHRvIHJldXNlIGFzIG11Y2ggb2YgdGhlIHdvcmsgYXMgcG9z c2libGUuIA0KICAgICAgIA0KICAgNi44LiBPZmYtbG9hZGVkIEZ1bmN0aW9ucyANCiAgICAgICAN CiAgICAgIEluIGFkZGl0aW9uIHRvIHRoZSBwYWNrZXQgcHJvY2Vzc2luZyBmdW5jdGlvbnMgdHlw aWNhbGx5IGZvdW5kIG9uIA0KICAgICAgdGhlIEZFcywgc29tZSBsb2dpY2FsIGZ1bmN0aW9ucyBt YXkgYWxzbyBiZSBleGVjdXRlZCANCiAgICAgIGFzeW5jaHJvbm91c2x5IGJ5IHNvbWUgRkVzLCBh cyBkaXJlY3RlZCBieSBhIGZpbml0ZS1zdGF0ZSBtYWNoaW5lIA0KICAgICAgYW5kIHRyaWdnZXJl ZCBub3Qgb25seSBieSBwYWNrZXQgZXZlbnRzLCBidXQgYnkgdGltZXIgZXZlbnRzIGFzIA0KICAg ICAgd2VsbC4gIEV4YW1wbGVzIG9mIHN1Y2ggZnVuY3Rpb25zIGluY2x1ZGU7IGZpbml0ZS1zdGF0 ZSBtYWNoaW5lIA0KICAgICAgZXhlY3V0aW9uIHJlcXVpcmVkIGJ5IFRDUCB0ZXJtaW5hdGlvbiBv ciBPU1BGIEhlbGxvIHByb2Nlc3NpbmcgDQogICAgICBvZmYtbG9hZGVkIGZyb20gdGhlIENFLiAg QnkgZGVmaW5pbmcgTEZCcyBmb3Igc3VjaCBmdW5jdGlvbnMsIHRoZSANCiAgICAgIEZFIG1vZGVs IGlzIGNhcGFibGUgb2YgZXhwcmVzc2luZyB0aGVzZSBhc3luY2hyb25vdXMgZnVuY3Rpb25zIHRv IA0KICAgICAgYWxsb3cgdGhlIENFIHRvIHRha2UgYWR2YW50YWdlIG9mIHN1Y2ggb2ZmLWxvYWRl ZCBmdW5jdGlvbnMgb24gdGhlIA0KICAgICAgRkVzLiANCiAgICAgICANCiAgIDYuOS4gSVBGTE9X L1BTQU1QIEZ1bmN0aW9ucyANCiAgICAgICANCiAgICAgIFJGQyAzOTE3IFs5XSBkZWZpbmVzIGFu IGFyY2hpdGVjdHVyZSBmb3IgSVAgdHJhZmZpYyBmbG93IA0KICAgICAgbW9uaXRvcmluZywgbWVh c3VyaW5nIGFuZCBleHBvcnRpbmcuICBUaGUgTEZCIG1vZGVsIHN1cHBvcnRzIA0KICAgICAgc3Rh dGlzdGljcyBjb2xsZWN0aW9uIG9uIHRoZSBMRkIgYnkgaW5jbHVkaW5nIHN0YXRpc3RpY2FsIA0K ICAgICAgYXR0cmlidXRlcyAoU2VjdGlvbiA0LjcuNCkgaW4gdGhlIExGQiBjbGFzcyBkZWZpbml0 aW9uczsgaW4gDQogICAgICBhZGRpdGlvbiwgc3BlY2lhbCBzdGF0aXN0aWNzIGNvbGxlY3Rpb24g TEZCcyBzdWNoIGFzIG1ldGVyIExGQnMgDQogICAgICBhbmQgY291bnRlciBMRkJzIGNhbiBhbHNv IGJlIHVzZWQgdG8gc3VwcG9ydCBhY2NvdW50aW5nIGZ1bmN0aW9ucyANCiAgICAgIGluIHRoZSBG RS4gDQogICAgICAgDQogICAgICBbMTBdIGRlc2NyaWJlcyBhIGZyYW1ld29yayB0byBkZWZpbmUg YSBzdGFuZGFyZCBzZXQgb2YgDQogICAgICBjYXBhYmlsaXRpZXMgZm9yIG5ldHdvcmsgZWxlbWVu dHMgdG8gc2FtcGxlIHN1YnNldHMgb2YgcGFja2V0cyBieSANCiAgICAgIHN0YXRpc3RpY2FsIGFu ZCBvdGhlciBtZXRob2RzLiAgVGltZSBldmVudCBnZW5lcmF0aW9uLCBmaWx0ZXIgTEZCLCANCiAg ICAgIGFuZCBjb3VudGVyL21ldGVyIExGQiBhcmUgdGhlIGVsZW1lbnRzIG5lZWRlZCB0byBzdXBw b3J0IHBhY2tldCANCiAgICAgIGZpbHRlcmluZyBhbmQgc2FtcGxpbmcgZnVuY3Rpb25zIC0tIHRo ZXNlIGVsZW1lbnRzIGNhbiBhbGwgYmUgDQogICAgICBzdXBwb3J0ZWQgaW4gdGhlIEZFIG1vZGVs LiANCiAgICAgICANCiAgIDcuIA0gICAgIFVzaW5nIHRoZSBGRSBtb2RlbCBpbiB0aGUgRm9yQ0VT IFByb3RvY29sIA0KICAgICAgIA0KICAgICAgVGhlIGFjdHVhbCBtb2RlbCBvZiB0aGUgZm9yd2Fy ZGluZyBwbGFuZSBpbiBhIGdpdmVuIE5FIGlzIA0KICAgICAgc29tZXRoaW5nIHRoZSBDRSBtdXN0 IGxlYXJuIGFuZCBjb250cm9sIGJ5IGNvbW11bmljYXRpbmcgd2l0aCB0aGUgDQogICAgICBGRXMg KG9yIGJ5IG90aGVyIG1lYW5zKS4gIE1vc3Qgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHdpbGwgaGFw cGVuIA0KICAgICAgaW4gdGhlIHBvc3QtYXNzb2NpYXRpb24gcGhhc2UgdXNpbmcgdGhlIEZvckNF UyBwcm90b2NvbC4gIFRoZSANCiAgICAgIGZvbGxvd2luZyB0eXBlcyBvZiBpbmZvcm1hdGlvbiBt dXN0IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIENFcyBhbmQgDQogICAgICBGRXMgdmlhIHRoZSBGb3JD RVMgcHJvdG9jb2w6IA0KICAgICAgICAgMSkgIEZFIHRvcG9sb2d5IHF1ZXJ5OyANCiAgICAgICAg IDIpICBGRSBjYXBhYmlsaXR5IGRlY2xhcmF0aW9uOyANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4OV0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgMykgIExGQiB0b3BvbG9neSAocGVy IEZFKSBhbmQgY29uZmlndXJhdGlvbiBjYXBhYmlsaXRpZXMgDQogICAgICBxdWVyeTsgDQogICAg ICAgICA0KSAgTEZCIGNhcGFiaWxpdHkgZGVjbGFyYXRpb247IA0KICAgICAgICAgNSkgIFN0YXRl IHF1ZXJ5IG9mIExGQiBhdHRyaWJ1dGVzOyANCiAgICAgICAgIDYpICBNYW5pcHVsYXRpb24gb2Yg TEZCIGF0dHJpYnV0ZXM7IA0KICAgICAgICAgNykgIExGQiB0b3BvbG9neSByZWNvbmZpZ3VyYXRp b24uIA0KICAgICAgICAgIA0KICAgICAgSXRlbXMgMSkgdGhyb3VnaCA1KSBhcmUgcXVlcnkgZXhj aGFuZ2VzLCB3aGVyZSB0aGUgbWFpbiBmbG93IG9mIA0KICAgICAgaW5mb3JtYXRpb24gaXMgZnJv bSB0aGUgRkVzIHRvIHRoZSBDRXMuICBJdGVtcyAxKSB0aHJvdWdoIDQpIGFyZSANCiAgICAgIHR5 cGljYWxseSBxdWVyaWVkIGJ5IHRoZSBDRShzKSBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwb3N0 LQ0KICAgICAgYXNzb2NpYXRpb24gKFBBKSBwaGFzZSwgdGhvdWdoIHRoZXkgbWF5IGJlIHJlcGVh dGVkbHkgcXVlcmllZCBhdCANCiAgICAgIGFueSB0aW1lIGluIHRoZSBQQSBwaGFzZS4gIEl0ZW0g NSkgKHN0YXRlIHF1ZXJ5KSB3aWxsIGJlIHVzZWQgYXQgDQogICAgICB0aGUgYmVnaW5uaW5nIG9m IHRoZSBQQSBwaGFzZSwgYW5kIG9mdGVuIGZyZXF1ZW50bHkgZHVyaW5nIHRoZSBQQSANCiAgICAg IHBoYXNlIChlc3BlY2lhbGx5IGZvciB0aGUgcXVlcnkgb2Ygc3RhdGlzdGljYWwgY291bnRlcnMp LiANCiAgICAgICANCiAgICAgIEl0ZW1zIDYpIGFuZCA3KSBhcmUgImNvbW1hbmQiIHR5cGVzIG9m IGV4Y2hhbmdlcywgd2hlcmUgdGhlIG1haW4gDQogICAgICBmbG93IG9mIGluZm9ybWF0aW9uIGlz IGZyb20gdGhlIENFcyB0byB0aGUgRkVzLiAgTWVzc2FnZXMgaW4gSXRlbSANCiAgICAgIDYpICh0 aGUgTEZCIHJlLWNvbmZpZ3VyYXRpb24gY29tbWFuZHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2Vk IA0KICAgICAgZnJlcXVlbnRseS4gIEl0ZW0gNykgKExGQiB0b3BvbG9neSByZS1jb25maWd1cmF0 aW9uKSBpcyBuZWVkZWQgDQogICAgICBvbmx5IGlmIGR5bmFtaWMgTEZCIHRvcG9sb2dpZXMgYXJl IHN1cHBvcnRlZCBieSB0aGUgRkVzIGFuZCBpdCBpcyANCiAgICAgIGV4cGVjdGVkIHRvIGJlIHVz ZWQgaW5mcmVxdWVudGx5LiAgIA0KICAgICAgIA0KICAgICAgQW1vbmcgdGhlIHNldmVuIHR5cGVz IG9mIHBheWxvYWQgaW5mb3JtYXRpb24gdGhlIEZvckNFUyBwcm90b2NvbCANCiAgICAgIGNhcnJp ZXMgYmV0d2VlbiBDRXMgYW5kIEZFcywgdGhlIEZFIG1vZGVsIGNvdmVycyBhbGwgb2YgdGhlbSAN CiAgICAgIGV4Y2VwdCBpdGVtIDEpLCB3aGljaCBjb25jZXJucyB0aGUgaW50ZXItRkUgdG9wb2xv Z3kuICBUaGUgRkUgDQogICAgICBtb2RlbCBmb2N1c2VzIG9uIHRoZSBMRkIgYW5kIExGQiB0b3Bv bG9neSB3aXRoaW4gYSBzaW5nbGUgRkUuICANCiAgICAgIFNpbmNlIHRoZSBpbmZvcm1hdGlvbiBy ZWxhdGVkIHRvIGl0ZW0gMSkgcmVxdWlyZXMgZ2xvYmFsIA0KICAgICAga25vd2xlZGdlIGFib3V0 IGFsbCBvZiB0aGUgRkVzIGFuZCB0aGVpciBpbnRlci1jb25uZWN0aW9uIHdpdGggDQogICAgICBl YWNoIG90aGVyLCB0aGlzIGV4Y2hhbmdlIGlzIHBhcnQgb2YgdGhlIEZvckNFUyBiYXNlIHByb3Rv Y29sIA0KICAgICAgaW5zdGVhZCBvZiB0aGUgRkUgbW9kZWwuIA0KICAgICAgIA0KICAgICAgVGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBGRSBtb2RlbCBhbmQgdGhlIHNldmVuIHBvc3QtDQog ICAgICBhc3NvY2lhdGlvbiBtZXNzYWdlcyBhcmUgdmlzdWFsaXplZCBpbiBGaWd1cmUgOTogDQog ICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5MF0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLS0+fCAgIENFICAgfCANCiAgICAgICAg ICAgICAgICAgICAgIC8tLS0tXCAgICAgICAgICAgICAgIC4gICAgICAgICAgICArLS0tLS0tLS0r IA0KICAgICAgICAgICAgICAgICAgICAgXF9fX18vIEZFIE1vZGVsICAgICAgLiAgICAgICAgICAg ICAgXiAgICB8IA0KICAgICAgICAgICAgICAgICAgICAgfCAgICB8Li4uLi4uLi4uLi4uLi4uLiAg ICAgICAgKDEpLDIgfCAgICB8IDYsIDcgDQogICAgICAgICAgICAgICAgICAgICB8ICAgIHwgIChv ZmYtbGluZSkgICAuICAgICAgMywgNCwgNSB8ICAgIHwgDQogICAgICAgICAgICAgICAgICAgICBc X19fXy8gICAgICAgICAgICAgICAuICAgICAgICAgICAgICB8ICAgIHYgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuICAgICAgICAgICAgKy0tLS0tLS0tKyANCiAg ICAgICAgICAgICAgICAgICBlLmcuIFJGQ3MgICAgICAgICAgICAgIC4uLi4uLi4uLi4tLT58ICAg RkUgICB8IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLSsgDQogICAgICAgDQogICAgICAgICAgRmlndXJlIDkuIFJlbGF0aW9u c2hpcCBiZXR3ZWVuIHRoZSBGRSBtb2RlbCBhbmQgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29s IG1lc3NhZ2VzLCB3aGVyZSAoMSkgaXMgcGFydCBvZiB0aGUgRm9yQ0VTIGJhc2UgcHJvdG9jb2ws IA0KICAgICAgICAgICAgICAgICAgYW5kIHRoZSByZXN0IGFyZSBkZWZpbmVkIGJ5IHRoZSBGRSBt b2RlbC4gDQogICAgICAgDQogICAgICBUaGUgYWN0dWFsIGVuY29kaW5nIG9mIHRoZXNlIG1lc3Nh Z2VzIGlzIGRlZmluZWQgYnkgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIGFuZCBiZXlvbmQg dGhlIHNjb3BlIG9mIHRoZSBGRSBtb2RlbC4gIFRoZWlyIGRpc2N1c3Npb24gDQogICAgICBpcyBu ZXZlcnRoZWxlc3MgaW1wb3J0YW50IGhlcmUgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczogDQog ICAgICAgIC4gVGhlc2UgUEEgbW9kZWwgY29tcG9uZW50cyBoYXZlIGNvbnNpZGVyYWJsZSBpbXBh Y3Qgb24gdGhlIEZFIA0KICAgICAgICAgICBtb2RlbC4gIEZvciBleGFtcGxlLCBzb21lIG9mIHRo ZSBhYm92ZSBpbmZvcm1hdGlvbiBjYW4gYmUgDQogICAgICAgICAgIHJlcHJlc2VudGVkIGFzIGF0 dHJpYnV0ZXMgb2YgdGhlIExGQnMsIGluIHdoaWNoIGNhc2Ugc3VjaCANCiAgICAgICAgICAgYXR0 cmlidXRlcyBtdXN0IGJlIGRlZmluZWQgaW4gdGhlIExGQiBjbGFzc2VzLiANCiAgICAgICAgLiBU aGUgdW5kZXJzdGFuZGluZyBvZiB0aGUgdHlwZSBvZiBpbmZvcm1hdGlvbiB0aGF0IG11c3QgYmUg DQogICAgICAgICAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBGRXMgYW5kIENFcyBjYW4gaGVscCB0 byBzZWxlY3QgdGhlIA0KICAgICAgICAgICBhcHByb3ByaWF0ZSBwcm90b2NvbCBmb3JtYXQgYW5k IHRoZSBhY3R1YWwgZW5jb2RpbmcgbWV0aG9kIA0KICAgICAgICAgICAoc3VjaCBhcyBYTUwsIFRM VnMpLiANCiAgICAgICAgLiBVbmRlcnN0YW5kaW5nIHRoZSBmcmVxdWVuY3kgb2YgdGhlc2UgdHlw ZXMgb2YgbWVzc2FnZXMgDQogICAgICAgICAgIHNob3VsZCBpbmZsdWVuY2UgdGhlIHNlbGVjdGlv biBvZiB0aGUgcHJvdG9jb2wgZm9ybWF0IA0KICAgICAgICAgICAoZWZmaWNpZW5jeSBjb25zaWRl cmF0aW9ucykuIA0KICAgICAgIA0KICAgICAgQW4gaW1wb3J0YW50IHBhcnQgb2YgdGhlIEZFIG1v ZGVsIGlzIHRoZSBwb3J0IHRoZSBGRSB1c2VzIGZvciBpdHMgDQogICAgICBtZXNzYWdlIGV4Y2hh bmdlcyB0byBhbmQgZnJvbSB0aGUgQ0UuICBJbiB0aGUgY2FzZSB0aGF0IGEgDQogICAgICBkZWRp Y2F0ZWQgcG9ydCBpcyB1c2VkIGZvciBDRS1GRSBjb21tdW5pY2F0aW9uLCB3ZSBwcm9wb3NlIHRv IHVzZSANCiAgICAgIGEgc3BlY2lhbCBwb3J0IExGQiwgY2FsbGVkIHRoZSBDRS1GRSBQb3J0IExG QiAoYSBzdWJjbGFzcyBvZiB0aGUgDQogICAgICBnZW5lcmFsIFBvcnQgTEZCIGluIFNlY3Rpb24g Ni4xKSwgdG8gbW9kZWwgdGhpcyBkZWRpY2F0ZWQgQ0UtRkUgDQogICAgICBwb3J0LiAgVGhlIENF LUZFIFBvcnQgTEZCIGFjdHMgYXMgYm90aCBhIHNvdXJjZSBhbmQgc2luayBmb3IgdGhlIA0KICAg ICAgdHJhZmZpYyBmcm9tIGFuZCB0byB0aGUgQ0UuICBTb21ldGltZXMgdGhlIENFLUZFIHRyYWZm aWMgZG9lcyBub3QgDQogICAgICBoYXZlIGl0cyBvd24gZGVkaWNhdGVkIHBvcnQsIGluc3RlYWQg dGhlIGRhdGEgZmFicmljIGlzIHNoYXJlZCANCiAgICAgIGZvciB0aGUgZGF0YSBwbGFuZSB0cmFm ZmljIGFuZCB0aGUgQ0UtRkUgdHJhZmZpYy4gIEEgc3BlY2lhbCANCiAgICAgIHByb2Nlc3Npbmcg TEZCIGNhbiBiZSB1c2VkIHRvIG1vZGVsIHRoZSBGb3JDRVMgcGFja2V0IA0KICAgICAgZW5jYXBz dWxhdGlvbiBhbmQgZGVjYXBzdWxhdGlvbiBpbiBzdWNoIGNhc2VzLiANCiAgICAgICANCiAgICAg IFRoZSByZW1haW5pbmcgc3ViLXNlY3Rpb25zIG9mIHRoaXMgc2VjdGlvbiBhZGRyZXNzIGVhY2gg b2YgdGhlIA0KICAgICAgc2V2ZW4gbWVzc2FnZSB0eXBlcy4gDQogICAgICAgDQogICA3LjEuIEZF IFRvcG9sb2d5IFF1ZXJ5IA0KICAgIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJl cyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDkxXSANCgwgICBJbnRl cm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIw MDUgDQogICAgDQogICAgDQogICAgICBBbiBGRSBtYXkgY29udGFpbiB6ZXJvLCBvbmUgb3IgbW9y ZSBleHRlcm5hbCBpbmdyZXNzIHBvcnRzLiANCiAgICAgIFNpbWlsYXJseSwgYW4gRkUgbWF5IGNv bnRhaW4gemVybywgb25lIG9yIG1vcmUgZXh0ZXJuYWwgZWdyZXNzIA0KICAgICAgcG9ydHMuICBJ biBvdGhlciB3b3Jkcywgbm90IGV2ZXJ5IEZFIGhhcyB0byBjb250YWluIGFueSBleHRlcm5hbCAN CiAgICAgIGluZ3Jlc3Mgb3IgZWdyZXNzIGludGVyZmFjZXMuICBGb3IgZXhhbXBsZSwgRmlndXJl IDEwIHNob3dzIHR3byANCiAgICAgIGNhc2NhZGluZyBGRXMuICBGRSAjMSBjb250YWlucyBvbmUg ZXh0ZXJuYWwgaW5ncmVzcyBpbnRlcmZhY2UgYnV0IA0KICAgICAgbm8gZXh0ZXJuYWwgZWdyZXNz IGludGVyZmFjZSwgd2hpbGUgRkUgIzIgY29udGFpbnMgb25lIGV4dGVybmFsIA0KICAgICAgZWdy ZXNzIGludGVyZmFjZSBidXQgbm8gaW5ncmVzcyBpbnRlcmZhY2UuICBJdCBpcyBwb3NzaWJsZSB0 byANCiAgICAgIGNvbm5lY3QgdGhlc2UgdHdvIEZFcyB0b2dldGhlciB2aWEgdGhlaXIgaW50ZXJu YWwgaW50ZXJmYWNlcyB0byANCiAgICAgIGFjaGlldmUgdGhlIGNvbXBsZXRlIGluZ3Jlc3MtdG8t ZWdyZXNzIHBhY2tldCBwcm9jZXNzaW5nIGZ1bmN0aW9uLiANCiAgICAgIFRoaXMgcHJvdmlkZXMg dGhlIGZsZXhpYmlsaXR5IHRvIHNwcmVhZCB0aGUgZnVuY3Rpb25zIGFjcm9zcyANCiAgICAgIG11 bHRpcGxlIEZFcyBhbmQgaW50ZXJjb25uZWN0IHRoZW0gdG9nZXRoZXIgbGF0ZXIgZm9yIGNlcnRh aW4gDQogICAgICBhcHBsaWNhdGlvbnMuICANCiAgICAgICANCiAgICAgIFdoaWxlIHRoZSBpbnRl ci1GRSBjb21tdW5pY2F0aW9uIHByb3RvY29sIGlzIG91dCBvZiBzY29wZSBmb3IgDQogICAgICBG b3JDRVMsIGl0IGlzIHVwIHRvIHRoZSBDRSB0byBxdWVyeSBhbmQgdW5kZXJzdGFuZCBob3cgbXVs dGlwbGUgDQogICAgICBGRXMgYXJlIGludGVyLWNvbm5lY3RlZCB0byBwZXJmb3JtIGEgY29tcGxl dGUgaW5ncmVzcy1lZ3Jlc3MgDQogICAgICBwYWNrZXQgcHJvY2Vzc2luZyBmdW5jdGlvbiwgc3Vj aCBhcyB0aGUgb25lIGRlc2NyaWJlZCBpbiBGaWd1cmUgDQogICAgICAxMC4gIFRoZSBpbnRlci1G RSB0b3BvbG9neSBpbmZvcm1hdGlvbiBtYXkgYmUgcHJvdmlkZWQgYnkgRkVzLCBtYXkgDQogICAg ICBiZSBoYXJkLWNvZGVkIGludG8gQ0UsIG9yIG1heSBiZSBwcm92aWRlZCBieSBzb21lIG90aGVy IGVudGl0eSANCiAgICAgIChlLmcuLCBhIGJ1cyBtYW5hZ2VyKSBpbmRlcGVuZGVudCBvZiB0aGUg RkVzLiAgU28gd2hpbGUgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sIHN1cHBvcnRzIEZFIHRv cG9sb2d5IHF1ZXJ5IGZyb20gRkVzLCBpdCBpcyBvcHRpb25hbCBmb3IgDQogICAgICB0aGUgQ0Ug dG8gdXNlIGl0LCBhc3N1bWluZyB0aGUgQ0UgaGFzIG90aGVyIG1lYW5zIHRvIGdhdGhlciBzdWNo IA0KICAgICAgdG9wb2xvZ3kgaW5mb3JtYXRpb24uIA0KICAgICAgIA0KICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICAg ICAgIHwgICstLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tKyAgICAgICAg IHwgDQogICAgICAgaW5wdXR8ICAgICAgICAgfCAgIHwgICAgICAgICAgICB8ICAgfCAgICAgICAg IHwgb3V0cHV0ICB8IA0KICAgICAgLS0tKy0+fCBJbmdyZXNzIHwtLT58SGVhZGVyICAgICAgfC0t PnxJUHY0ICAgICB8LS0tLS0tLS0tKy0tLT4rIA0KICAgICAgICAgfCAgfCBwb3J0ICAgIHwgICB8 RGVjb21wcmVzc29yfCAgIHxGb3J3YXJkZXJ8IEZFICAgICAgfCAgICB8IA0KICAgICAgICAgfCAg Ky0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0rICMxICAgICAgfCAgICB8 IA0KICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKyAgICBWIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAgICAgICAg ICAgICB8ICAgICANCiAgICAgICAgICAgICAgfCAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgICAgIFYgICAgfCAgKy0tLS0tLS0tLS0tLSsg ICArLS0tLS0tLS0tLSsgICAgICAgICB8IA0KICAgICAgICAgICAgICB8IGlucHV0IHwgICAgICAg ICAgICB8ICAgfCAgICAgICAgICB8IG91dHB1dCAgfCANCiAgICAgICAgICAgICAgKy0+LS0rLT58 SGVhZGVyICAgICAgfC0tPnwgRWdyZXNzICAgfC0tLS0tLS0tLSstLT4gDQogICAgICAgICAgICAg ICAgICAgfCAgfENvbXByZXNzb3IgIHwgICB8IHBvcnQgICAgIHwgRkUgICAgICB8IA0KICAgICAg ICAgICAgICAgICAgIHwgICstLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0rICMyICAgICAgfCAN CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsgDQogICAgICAgDQogICAgICAgICAgICAgRmlndXJlIDEwLiBBbiBleGFtcGxlIG9mIHR3 byBGRXMgY29ubmVjdGVkIHRvZ2V0aGVyLiANCiAgICAgICANCiAgICAgIE9uY2UgdGhlIGludGVy LUZFIHRvcG9sb2d5IGlzIGRpc2NvdmVyZWQgYnkgdGhlIENFIGFmdGVyIHRoaXMgDQogICAgICBx dWVyeSwgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBpbnRlci1GRSB0b3BvbG9neSByZW1haW5zIHN0 YXRpYy4gIA0KICAgICAgSG93ZXZlciwgaXQgaXMgcG9zc2libGUgdGhhdCBhbiBGRSBtYXkgZ28g ZG93biBkdXJpbmcgdGhlIE5FIA0KICAgIA0KICAgWWFuZywgZXQgYWwuICAgICAgRXhwaXJlcyBB dWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDkyXSANCgwgICBJbnRlcm5l dCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAgICAgICAgQXVndXN0IDIwMDUg DQogICAgDQogICAgDQogICAgICBvcGVyYXRpb24sIG9yIGEgYm9hcmQgbWF5IGJlIGluc2VydGVk IGFuZCBhIG5ldyBGRSBhY3RpdmF0ZWQsIHNvIA0KICAgICAgdGhlIGludGVyLUZFIHRvcG9sb2d5 IHdpbGwgYmUgYWZmZWN0ZWQuICBJdCBpcyB1cCB0byB0aGUgRm9yQ0VTIA0KICAgICAgcHJvdG9j b2wgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgdGhlIENFIHRvIGRldGVjdCBzdWNoIGV2ZW50 cyANCiAgICAgIGFuZCBkZWFsIHdpdGggdGhlIGNoYW5nZSBpbiBGRSB0b3BvbG9neS4gIEZFIHRv cG9sb2d5IGlzIG91dHNpZGUgDQogICAgICB0aGUgc2NvcGUgb2YgdGhlIEZFIG1vZGVsLiANCiAg ICAgICANCiAgIDcuMi4gRkUgQ2FwYWJpbGl0eSBEZWNsYXJhdGlvbnMgDQogICAgICAgDQogICAg ICBGRXMgd2lsbCBoYXZlIG1hbnkgdHlwZXMgb2YgbGltaXRhdGlvbnMuICBTb21lIG9mIHRoZSBs aW1pdGF0aW9ucyANCiAgICAgIG11c3QgYmUgZXhwcmVzc2VkIHRvIHRoZSBDRXMgYXMgcGFydCBv ZiB0aGUgY2FwYWJpbGl0eSBtb2RlbC4gIFRoZSANCiAgICAgIENFcyBtdXN0IGJlIGFibGUgdG8g cXVlcnkgdGhlc2UgY2FwYWJpbGl0aWVzIG9uIGEgcGVyLUZFIGJhc2lzLiANCiAgICAgIEV4YW1w bGVzOiANCiAgICAgICAgLiBNZXRhZGF0YSBwYXNzaW5nIGNhcGFiaWxpdGllcyBvZiB0aGUgRkUu ICBVbmRlcnN0YW5kaW5nIHRoZXNlIA0KICAgICAgICAgICBjYXBhYmlsaXRpZXMgd2lsbCBoZWxw IHRoZSBDRSB0byBldmFsdWF0ZSB0aGUgZmVhc2liaWxpdHkgb2YgDQogICAgICAgICAgIExGQiB0 b3BvbG9naWVzLCBhbmQgaGVuY2UgdG8gZGV0ZXJtaW5lIHRoZSBhdmFpbGFiaWxpdHkgb2YgDQog ICAgICAgICAgIGNlcnRhaW4gc2VydmljZXMuIA0KICAgICAgICAuIEdsb2JhbCByZXNvdXJjZSBx dWVyeSBsaW1pdGF0aW9ucyAoYXBwbGljYWJsZSB0byBhbGwgTEZCcyBvZiANCiAgICAgICAgICAg dGhlIEZFKS4gDQogICAgICAgIC4gTEZCIHN1cHBvcnRlZCBieSB0aGUgRkUuIA0KICAgICAgICAu IExGQiBjbGFzcyBpbnN0YW50aWF0aW9uIGxpbWl0LiANCiAgICAgICAgLiBMRkIgdG9wb2xvZ2lj YWwgbGltaXRhdGlvbnMgKGxpbmthZ2UgY29uc3RyYWludCwgb3JkZXJpbmcgDQogICAgICAgICAg IGV0Yy4pIA0KICAgICAgIA0KICAgNy4zLiBMRkIgVG9wb2xvZ3kgYW5kIFRvcG9sb2d5IENvbmZp Z3VyYWJpbGl0eSBRdWVyeSANCiAgICAgICANCiAgICAgIFRoZSBGb3JDRVMgcHJvdG9jb2wgbXVz dCBwcm92aWRlIHRoZSBtZWFucyBmb3IgdGhlIENFcyB0byBkaXNjb3ZlciANCiAgICAgIHRoZSBj dXJyZW50IHNldCBvZiBMRkIgaW5zdGFuY2VzIGluIGFuIEZFIGFuZCB0aGUgaW50ZXJjb25uZWN0 aW9ucyANCiAgICAgIGJldHdlZW4gdGhlIExGQnMgd2l0aGluIHRoZSBGRS4gIEluIGFkZGl0aW9u LCBzdWZmaWNpZW50IA0KICAgICAgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGF2YWlsYWJsZSB0byBk ZXRlcm1pbmUgd2hldGhlciB0aGUgRkUgDQogICAgICBzdXBwb3J0cyBhbnkgQ0UtaW5pdGlhdGVk IChkeW5hbWljKSBjaGFuZ2VzIHRvIHRoZSBMRkIgdG9wb2xvZ3ksIA0KICAgICAgYW5kIGlmIHNv LCBkZXRlcm1pbmUgdGhlIGFsbG93ZWQgdG9wb2xvZ2llcy4gIFRvcG9sb2d5IA0KICAgICAgY29u ZmlndXJhYmlsaXR5IGNhbiBhbHNvIGJlIGNvbnNpZGVyZWQgYXMgcGFydCBvZiB0aGUgRkUgDQog ICAgICBjYXBhYmlsaXR5IHF1ZXJ5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDkuMy4gDQogICAg ICAgDQogICA3LjQuIExGQiBDYXBhYmlsaXR5IERlY2xhcmF0aW9ucyANCiAgICAgICANCiAgICAg IExGQiBjbGFzcyBzcGVjaWZpY2F0aW9ucyBkZWZpbmUgYSBnZW5lcmljIHNldCBvZiBjYXBhYmls aXRpZXMuIA0KICAgICAgV2hlbiBhbiBMRkIgaW5zdGFuY2UgaXMgaW1wbGVtZW50ZWQgKGluc3Rh bnRpYXRlZCkgb24gYSB2ZW5kb3IncyANCiAgICAgIEZFLCBzb21lIGFkZGl0aW9uYWwgbGltaXRh dGlvbnMgbWF5IGJlIGludHJvZHVjZWQuICBOb3RlIHRoYXQgd2UgDQogICAgICBkaXNjdXNzIG9u bHkgdGhvc2UgbGltaXRhdGlvbnMgdGhhdCBhcmUgd2l0aGluIHRoZSBmbGV4aWJpbGl0eSBvZiAN CiAgICAgIHRoZSBMRkIgY2xhc3Mgc3BlY2lmaWNhdGlvbi4gIFRoYXQgaXMsIHRoZSBMRkIgaW5z dGFuY2Ugd2lsbCANCiAgICAgIHJlbWFpbiBjb21wbGlhbnQgd2l0aCB0aGUgTEZCIGNsYXNzIHNw ZWNpZmljYXRpb24gZGVzcGl0ZSB0aGVzZSANCiAgICAgIGxpbWl0YXRpb25zLiAgRm9yIGV4YW1w bGUsIGNlcnRhaW4gZmVhdHVyZXMgb2YgYW4gTEZCIGNsYXNzIG1heSBiZSANCiAgICAgIG9wdGlv bmFsLCBpbiB3aGljaCBjYXNlIGl0IG11c3QgYmUgcG9zc2libGUgZm9yIHRoZSBDRSB0byANCiAg ICAgIGRldGVybWluZSBpZiBhbiBvcHRpb25hbCBmZWF0dXJlIGlzIHN1cHBvcnRlZCBieSBhIGdp dmVuIExGQiANCiAgICAgIGluc3RhbmNlIG9yIG5vdC4gQWxzbywgdGhlIExGQiBjbGFzcyBkZWZp bml0aW9ucyB3aWxsIHByb2JhYmx5IA0KICAgICAgY29udGFpbiB2ZXJ5IGZldyBxdWFudGl0YXRp dmUgbGltaXRzIChlLmcuLCBzaXplIG9mIHRhYmxlcyksIHNpbmNlIA0KICAgIA0KICAgWWFuZywg ZXQgYWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDkzXSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAg ICAgICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICB0aGVzZSBsaW1pdHMgYXJl IHR5cGljYWxseSBpbXBvc2VkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi4gIA0KICAgICAgVGhlcmVm b3JlLCBxdWFudGl0YXRpdmUgbGltaXRhdGlvbnMgc2hvdWxkIGFsd2F5cyBiZSBleHByZXNzZWQg YnkgDQogICAgICBjYXBhYmlsaXR5IGFyZ3VtZW50cy4gDQogICAgICAgDQogICAgICBMRkIgaW5z dGFuY2VzIGluIHRoZSBtb2RlbCBvZiBhIHBhcnRpY3VsYXIgRkUgaW1wbGVtZW50YXRpb24gd2ls bCANCiAgICAgIHBvc3Nlc3MgbGltaXRhdGlvbnMgb24gdGhlIGNhcGFiaWxpdGllcyBkZWZpbmVk IGluIHRoZSANCiAgICAgIGNvcnJlc3BvbmRpbmcgTEZCIGNsYXNzLiAgVGhlIExGQiBjbGFzcyBz cGVjaWZpY2F0aW9ucyBtdXN0IGRlZmluZSANCiAgICAgIGEgc2V0IG9mIGNhcGFiaWxpdHkgYXJn dW1lbnRzLCBhbmQgdGhlIENFIG11c3QgYmUgYWJsZSB0byBxdWVyeSANCiAgICAgIHRoZSBhY3R1 YWwgY2FwYWJpbGl0aWVzIG9mIHRoZSBMRkIgaW5zdGFuY2UgdmlhIHF1ZXJ5aW5nIHRoZSB2YWx1 ZSANCiAgICAgIG9mIHN1Y2ggYXJndW1lbnRzLiAgVGhlIGNhcGFiaWxpdHkgcXVlcnkgd2lsbCB0 eXBpY2FsbHkgaGFwcGVuIA0KICAgICAgd2hlbiB0aGUgTEZCIGlzIGZpcnN0IGRldGVjdGVkIGJ5 IHRoZSBDRS4gIENhcGFiaWxpdGllcyBuZWVkIG5vdCANCiAgICAgIGJlIHJlLXF1ZXJpZWQgaW4g Y2FzZSBvZiBzdGF0aWMgbGltaXRhdGlvbnMuICBJbiBzb21lIGNhc2VzLCANCiAgICAgIGhvd2V2 ZXIsIHNvbWUgY2FwYWJpbGl0aWVzIG1heSBjaGFuZ2UgaW4gdGltZSAoZS5nLiwgYXMgYSByZXN1 bHQgDQogICAgICBvZiBhZGRpbmcvcmVtb3Zpbmcgb3RoZXIgTEZCcywgb3IgY29uZmlndXJpbmcg Y2VydGFpbiBhdHRyaWJ1dGVzIA0KICAgICAgb2Ygc29tZSBvdGhlciBMRkIgd2hlbiB0aGUgTEZC cyBzaGFyZSBwaHlzaWNhbCByZXNvdXJjZXMpLCBpbiANCiAgICAgIHdoaWNoIGNhc2UgYWRkaXRp b25hbCBtZWNoYW5pc21zIG11c3QgYmUgaW1wbGVtZW50ZWQgdG8gaW5mb3JtIHRoZSANCiAgICAg IENFIGFib3V0IHRoZSBjaGFuZ2VzLiANCiAgICAgICANCiAgICAgIFRoZSBmb2xsb3dpbmcgdHdv IGJyb2FkIHR5cGVzIG9mIGxpbWl0YXRpb25zIHdpbGwgZXhpc3Q6IA0KICAgICAgICAuIFF1YWxp dGF0aXZlIHJlc3RyaWN0aW9ucy4gIEZvciBleGFtcGxlLCBhIHN0YW5kYXJkaXplZCBtdWx0aS0N CiAgICAgICAgICAgZmllbGQgY2xhc3NpZmllciBMRkIgY2xhc3MgbWF5IGRlZmluZSBhIGxhcmdl IG51bWJlciBvZiANCiAgICAgICAgICAgY2xhc3NpZmljYXRpb24gZmllbGRzLCBidXQgYSBnaXZl biBGRSBtYXkgc3VwcG9ydCBvbmx5IGEgDQogICAgICAgICAgIHN1YnNldCBvZiB0aG9zZSBmaWVs ZHMuIA0KICAgICAgICAuIFF1YW50aXRhdGl2ZSByZXN0cmljdGlvbnMsIHN1Y2ggYXMgdGhlIG1h eGltdW0gc2l6ZSBvZiANCiAgICAgICAgICAgdGFibGVzLCBldGMuIA0KICAgICAgIA0KICAgICAg VGhlIGNhcGFiaWxpdHkgcGFyYW1ldGVycyB0aGF0IGNhbiBiZSBxdWVyaWVkIG9uIGEgZ2l2ZW4g TEZCIGNsYXNzIA0KICAgICAgd2lsbCBiZSBwYXJ0IG9mIHRoZSBMRkIgY2xhc3Mgc3BlY2lmaWNh dGlvbi4gIFRoZSBjYXBhYmlsaXR5IA0KICAgICAgcGFyYW1ldGVycyBzaG91bGQgYmUgcmVnYXJk ZWQgYXMgc3BlY2lhbCBhdHRyaWJ1dGVzIG9mIHRoZSBMRkIuICANCiAgICAgIFRoZSBhY3R1YWwg dmFsdWVzIG9mIHRoZXNlIGFyZ3VtZW50cyBtYXkgYmUsIHRoZXJlZm9yZSwgb2J0YWluZWQgDQog ICAgICB1c2luZyB0aGUgc2FtZSBhdHRyaWJ1dGUgcXVlcnkgbWVjaGFuaXNtcyBhcyB1c2VkIGZv ciBvdGhlciBMRkIgDQogICAgICBhdHRyaWJ1dGVzLiANCiAgICAgICANCiAgICAgIENhcGFiaWxp dHkgYXR0cmlidXRlcyB3aWxsIHR5cGljYWxseSBiZSByZWFkLW9ubHkgYXJndW1lbnRzLCBidXQg DQogICAgICBpbiBjZXJ0YWluIGNhc2VzIHRoZXkgbWF5IGJlIGNvbmZpZ3VyYWJsZS4gIEZvciBl eGFtcGxlLCB0aGUgc2l6ZSANCiAgICAgIG9mIGEgbG9va3VwIHRhYmxlIG1heSBiZSBsaW1pdGVk IGJ5IHRoZSBoYXJkd2FyZSAocmVhZC1vbmx5KSwgaW4gDQogICAgICBvdGhlciBjYXNlcyBpdCBt YXkgYmUgY29uZmlndXJhYmxlIChyZWFkLXdyaXRlLCB3aXRoaW4gc29tZSBoYXJkIA0KICAgICAg bGltaXRzKS4gDQogICAgICAgDQogICAgICBBc3N1bWluZyB0aGF0IGNhcGFiaWxpdGllcyB3aWxs IG5vdCBjaGFuZ2UgZnJlcXVlbnRseSwgdGhlIA0KICAgICAgZWZmaWNpZW5jeSBvZiB0aGUgcHJv dG9jb2wvc2NoZW1hL2VuY29kaW5nIGlzIG9mIHNlY29uZGFyeSANCiAgICAgIGNvbmNlcm4uIA0K ICAgICAgIA0KICAgNy41LiBTdGF0ZSBRdWVyeSBvZiBMRkIgQXR0cmlidXRlcyANCiAgICAgICAN CiAgICAgIFRoaXMgZmVhdHVyZSBtdXN0IGJlIHByb3ZpZGVkIGJ5IGFsbCBGRXMuICBUaGUgRm9y Q0VTIHByb3RvY29sIGFuZCANCiAgICAgIHRoZSBkYXRhIHNjaGVtYS9lbmNvZGluZyBjb252ZXll ZCBieSB0aGUgcHJvdG9jb2wgbXVzdCB0b2dldGhlciANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAg ICAgIEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5NF0g DQoMICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAg IEF1Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgICAgc2F0aXNmeSB0aGUgZm9sbG93aW5nIHJl cXVpcmVtZW50cyB0byBmYWNpbGl0YXRlIHN0YXRlIHF1ZXJ5IG9mIA0KICAgICAgdGhlIExGQiBh dHRyaWJ1dGVzOiANCiAgICAgICAgLiBNdXN0IHBlcm1pdCBGRSBzZWxlY3Rpb24uICBUaGlzIGlz IHByaW1hcmlseSB0byByZWZlciB0byBhIA0KICAgICAgICAgICBzaW5nbGUgRkUsIGJ1dCByZWZl cnJpbmcgdG8gYSBncm91cCBvZiAob3IgYWxsKSBGRXMgbWF5IA0KICAgICAgICAgICBvcHRpb25h bCBiZSBzdXBwb3J0ZWQuIA0KICAgICAgICAuIE11c3QgcGVybWl0IExGQiBpbnN0YW5jZSBzZWxl Y3Rpb24uICBUaGlzIGlzIHByaW1hcmlseSB0byANCiAgICAgICAgICAgcmVmZXIgdG8gYSBzaW5n bGUgTEZCIGluc3RhbmNlIG9mIGFuIEZFLCBidXQgb3B0aW9uYWxseSANCiAgICAgICAgICAgYWRk cmVzc2luZyBvZiBhIGdyb3VwIG9mIExGQnMgKG9yIGFsbCkgbWF5IGJlIHN1cHBvcnRlZC4gDQog ICAgICAgIC4gTXVzdCBzdXBwb3J0IGFkZHJlc3Npbmcgb2YgaW5kaXZpZHVhbCBhdHRyaWJ1dGUg b2YgYW4gTEZCLiANCiAgICAgICAgLiBNdXN0IHByb3ZpZGUgZWZmaWNpZW50IGVuY29kaW5nIGFu ZCBkZWNvZGluZyBvZiB0aGUgDQogICAgICAgICAgIGFkZHJlc3NpbmcgaW5mbyBhbmQgdGhlIGNv bmZpZ3VyZWQgZGF0YS4gDQogICAgICAgIC4gTXVzdCBwcm92aWRlIGVmZmljaWVudCBkYXRhIHRy YW5zbWlzc2lvbiBvZiB0aGUgYXR0cmlidXRlIA0KICAgICAgICAgICBzdGF0ZSBvdmVyIHRoZSB3 aXJlICh0byBtaW5pbWl6ZSBjb21tdW5pY2F0aW9uIGxvYWQgb24gdGhlIA0KICAgICAgICAgICBD RS1GRSBsaW5rKS4gDQogICAgICAgDQogICA3LjYuIExGQiBBdHRyaWJ1dGUgTWFuaXB1bGF0aW9u IA0KICAgICAgIA0KICAgICAgVGhpcyBpcyBhIHBsYWNlLWhvbGRlciBmb3IgYWxsIG9wZXJhdGlv bnMgdGhhdCB0aGUgQ0Ugd2lsbCB1c2UgdG8gDQogICAgICBwb3B1bGF0ZSwgbWFuaXB1bGF0ZSwg YW5kIGRlbGV0ZSBhdHRyaWJ1dGVzIG9mIHRoZSBMRkIgaW5zdGFuY2VzIA0KICAgICAgb24gdGhl IEZFcy4gIFRoZXNlIG9wZXJhdGlvbnMgYWxsb3cgdGhlIENFIHRvIGNvbmZpZ3VyZSBhbiANCiAg ICAgIGluZGl2aWR1YWwgTEZCIGluc3RhbmNlLiANCiAgICAgICANCiAgICAgIFRoZSBzYW1lIHNl dCBvZiByZXF1aXJlbWVudHMgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOS41IGZvciANCiAgICAg IGF0dHJpYnV0ZSBxdWVyeSBhcHBsaWVzIGhlcmUgZm9yIGF0dHJpYnV0ZSBtYW5pcHVsYXRpb24g YXMgd2VsbC4gIA0KICAgICAgIA0KICAgICAgU3VwcG9ydCBmb3IgdmFyaW91cyBsZXZlbHMgb2Yg ZmVlZGJhY2sgZnJvbSB0aGUgRkUgdG8gdGhlIENFIA0KICAgICAgKGUuZy4sIA0KICAgICAgcmVx dWVzdCByZWNlaXZlZCwgY29uZmlndXJhdGlvbiBjb21wbGV0ZWQpLCBhcyB3ZWxsIGFzIG11bHRp LQ0KICAgICAgYXR0cmlidXRlIGNvbmZpZ3VyYXRpb24gdHJhbnNhY3Rpb25zIHdpdGggYXRvbWlj IGNvbW1pdCBhbmQgDQogICAgICByb2xsYmFjaywgbWF5IGJlIG5lY2Vzc2FyeSBpbiBzb21lIGNp cmN1bXN0YW5jZXMuIA0KICAgICAgIA0KICAgICAgKEVkaXRvcidzIG5vdGU6IEl0IHJlbWFpbnMg YW4gb3BlbiBpc3N1ZSBhcyB0byB3aGV0aGVyIG9yIG5vdCANCiAgICAgIG90aGVyIG1ldGhvZHMg YXJlIG5lZWRlZCBpbiBhZGRpdGlvbiB0byAiZ2V0IGF0dHJpYnV0ZSIgYW5kICJzZXQgDQogICAg ICBhdHRyaWJ1dGUiIChzdWNoIGFzIG11bHRpLWF0dHJpYnV0ZSB0cmFuc2FjdGlvbnMpLiAgSWYg dGhlIGFuc3dlciANCiAgICAgIHRvIHRoYXQgcXVlc3Rpb24gaXMgeWVzLCBpdCBpcyBub3QgY2xl YXIgd2hldGhlciBzdWNoIG1ldGhvZHMgDQogICAgICBzaG91bGQgYmUgc3VwcG9ydGVkIGJ5IHRo ZSBGRSBtb2RlbCBpdHNlbGYgb3IgdGhlIEZvckNFUyANCiAgICAgIHByb3RvY29sLikgDQogICAg ICAgDQogICA3LjcuIExGQiBUb3BvbG9neSBSZS1jb25maWd1cmF0aW9uIA0KICAgICAgIA0KICAg ICAgT3BlcmF0aW9ucyB0aGF0IHdpbGwgYmUgbmVlZGVkIHRvIHJlY29uZmlndXJlIExGQiB0b3Bv bG9neTogDQogICAgICAgIC4gQ3JlYXRlIGEgbmV3IGluc3RhbmNlIG9mIGEgZ2l2ZW4gTEZCIGNs YXNzIG9uIGEgZ2l2ZW4gRkUuIA0KICAgICAgICAuIENvbm5lY3QgYSBnaXZlbiBvdXRwdXQgb2Yg TEZCIHggdG8gdGhlIGdpdmVuIGlucHV0IG9mIExGQiB5LiANCiAgICAgICAgLiBEaXNjb25uZWN0 OiByZW1vdmUgYSBsaW5rIGJldHdlZW4gYSBnaXZlbiBvdXRwdXQgb2YgYW4gTEZCIA0KICAgICAg ICAgICBhbmQgYSBnaXZlbiBpbnB1dCBvZiBhbm90aGVyIExGQi4gDQogICAgICAgIC4gRGVsZXRl IGEgZ2l2ZW4gTEZCIChhdXRvbWF0aWNhbGx5IHJlbW92aW5nIGFsbCBpbnRlcmNvbm5lY3RzIA0K ICAgICAgICAgICB0by9mcm9tIHRoZSBMRkIpLiANCiAgICANCiAgIFlhbmcsIGV0IGFsLiAgICAg IEV4cGlyZXMgQXVndXN0IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5NV0gDQoM ICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBGb3JDRVMgRkUgTW9kZWwgICAgICAgICAgICAgIEF1 Z3VzdCAyMDA1IA0KICAgIA0KICAgIA0KICAgIA0KICAgOC4gDSAgICAgQWNrbm93bGVkZ21lbnRz IA0KICAgICAgIA0KICAgICAgTWFueSBvZiB0aGUgY29sbGVhZ3VlcyBpbiBvdXIgY29tcGFuaWVz IGFuZCBwYXJ0aWNpcGFudHMgaW4gdGhlIA0KICAgICAgRm9yQ0VTIG1haWxpbmcgbGlzdCBoYXZl IHByb3ZpZGVkIGludmFsdWFibGUgaW5wdXQgaW50byB0aGlzIHdvcmsuIA0KICAgICAgICAgDQog ICA5LiANICAgICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCiAgICAgICANCiAgICAgIFRoZSBG RSBtb2RlbCBkZXNjcmliZXMgdGhlIHJlcHJlc2VudGF0aW9uIGFuZCBvcmdhbml6YXRpb24gb2Yg ZGF0YSANCiAgICAgIHNldHMgYW5kIGF0dHJpYnV0ZXMgaW4gdGhlIEZFcy4gIFRoZSBGb3JDRVMg ZnJhbWV3b3JrIGRvY3VtZW50IFsyXSANCiAgICAgIHByb3ZpZGVzIGEgY29tcHJlaGVuc2l2ZSBz ZWN1cml0eSBhbmFseXNpcyBmb3IgdGhlIG92ZXJhbGwgRm9yQ0VTIA0KICAgICAgYXJjaGl0ZWN0 dXJlLiAgRm9yIGV4YW1wbGUsIHRoZSBGb3JDRVMgcHJvdG9jb2wgZW50aXRpZXMgbXVzdCBiZSAN CiAgICAgIGF1dGhlbnRpY2F0ZWQgcGVyIHRoZSBGb3JDRVMgcmVxdWlyZW1lbnRzIGJlZm9yZSB0 aGV5IGNhbiBhY2Nlc3MgDQogICAgICB0aGUgaW5mb3JtYXRpb24gZWxlbWVudHMgZGVzY3JpYmVk IGluIHRoaXMgZG9jdW1lbnQgdmlhIEZvckNFUy4gIA0KICAgICAgQWNjZXNzIHRvIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhlIEZFIG1vZGVsIGlzIA0KICAgICAgYWNjb21wbGlzaGVk IHZpYSB0aGUgRm9yQ0VTIHByb3RvY29sLCB3aGljaCB3aWxsIGJlIGRlZmluZWQgaW4gDQogICAg ICBzZXBhcmF0ZSBkb2N1bWVudHMsIGFuZCB0aHVzIHRoZSBzZWN1cml0eSBpc3N1ZXMgd2lsbCBi ZSBhZGRyZXNzZWQgDQogICAgICB0aGVyZS4gICANCiAgICAgICANCiAgIDEwLiANICAgICAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgDQogICAgICAgDQogICAgIFsxXSBLaG9zcmF2aSwgSC4gZXQgYWwu LCAiUmVxdWlyZW1lbnRzIGZvciBTZXBhcmF0aW9uIG9mIElQIA0KICAgICBDb250cm9sIGFuZCBG b3J3YXJkaW5nIiwgUkZDIDM2NTQsIE5vdmVtYmVyIDIwMDMuIA0KICAgICAgDQogICAgIFsyXSBZ YW5nLCBMLiBldCBhbC4sICJGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlv biANCiAgICAgKEZvckNFUykgRnJhbWV3b3JrIiwgUkZDIDM3NDYsIEFwcmlsIDIwMDQuIA0KICAg IA0KICAgMTEuIA0gICAgICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgICANCiAgICAgIFsz XSBCZXJuZXQsIFkuIGV0IGFsLiwgIkFuIEluZm9ybWFsIE1hbmFnZW1lbnQgTW9kZWwgZm9yIERp ZmZzZXJ2IA0KICAgICAgUm91dGVycyIsIFJGQyAzMjkwLCBNYXkgMjAwMi4gDQogICAgICAgDQog ICAgICBbNF0gQ2hhbiwgSy4gZXQgYWwuLCAiRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgUXVhbGl0 eSBvZiBTZXJ2aWNlIA0KICAgICAgUG9saWN5IEluZm9ybWF0aW9uIEJhc2UiLCBSRkMgMzMxNywg TWFyY2ggMjAwMy4gDQogICAgICAgDQogICAgICBbNV0gU2FoaXRhLCBSLiBldCBhbC4sICJGcmFt ZXdvcmsgUG9saWN5IEluZm9ybWF0aW9uIEJhc2UiLCBSRkMgDQogICAgICAzMzE4LCBNYXJjaCAy MDAzLiANCiAgICAgICANCiAgICAgIFs2XSBNb29yZSwgQi4gZXQgYWwuLCAiSW5mb3JtYXRpb24g TW9kZWwgZm9yIERlc2NyaWJpbmcgTmV0d29yayANCiAgICAgIERldmljZSBRb1MgRGF0YXBhdGgg TWVjaGFuaXNtcyIsIFJGQyAzNjcwLCBKYW51YXJ5IDIwMDQuIA0KICAgICAgIA0KICAgICAgWzdd IFNuaXIsIFkuIGV0IGFsLiwgIlBvbGljeSBGcmFtZXdvcmsgUW9TIEluZm9ybWF0aW9uIE1vZGVs IiwgUkZDIA0KICAgICAgMzY0NCwgTm92IDIwMDMuIA0KICAgIA0KICAgIA0KICAgWWFuZywgZXQg YWwuICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDk2XSANCgwgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIEZvckNFUyBGRSBNb2RlbCAgICAgICAg ICAgICAgQXVndXN0IDIwMDUgDQogICAgDQogICAgDQogICAgICBbOF0gTGksIE0uIGV0IGFsLiwg IklQc2VjIFBvbGljeSBJbmZvcm1hdGlvbiBCYXNlIiwgd29yayBpbiANCiAgICAgIHByb2dyZXNz LCBBcHJpbCAyMDA0LCA8ZHJhZnQtaWV0Zi1pcHNwLWlwc2VjcGliLTEwLnR4dD4uIA0KICAgICAg IA0KICAgICAgWzldIFF1aXR0ZWssIEouIGV0IEFsLiwgIlJlcXVpcmVtZW50cyBmb3IgSVAgRmxv dyBJbmZvcm1hdGlvbiANCiAgICAgIEV4cG9ydCIsIFJGQyAzOTE3LCBPY3RvYmVyIDIwMDQuIA0K ICAgICAgIA0KICAgICAgWzEwXSBEdWZmaWVsZCwgTi4sICJBIEZyYW1ld29yayBmb3IgUGFja2V0 IFNlbGVjdGlvbiBhbmQgDQogICAgICBSZXBvcnRpbmciLCB3b3JrIGluIHByb2dyZXNzLCBKYW51 YXJ5IDIwMDUsIDxkcmFmdC1pZXRmLXBzYW1wLQ0KICAgICAgZnJhbWV3b3JrLTEwLnR4dD4uIA0K ICAgICAgIA0KICAgICAgWzExXSBQcmFzLCBBLiBhbmQgU2Nob2Vud2FlbGRlciwgSi4sIFJGQyAz NDQ0ICJPbiB0aGUgRGlmZmVyZW5jZSANCiAgICAgIGJldHdlZW4gSW5mb3JtYXRpb24gTW9kZWxz IGFuZCBEYXRhIE1vZGVscyIsIEphbnVhcnkgMjAwMy4gDQogICAgICAgDQogICAxMi4gDSAgICAg IEF1dGhvcnMnIEFkZHJlc3NlcyANCiAgICANCiAgICAgIEwuIExpbHkgWWFuZyANCiAgICAgIElu dGVsIENvcnAuIA0KICAgICAgTWFpbCBTdG9wOiBKRjMtMjA2IA0KICAgICAgMjExMSBORSAyNXRo IEF2ZW51ZSANCiAgICAgIEhpbGxzYm9ybywgT1IgOTcxMjQsIFVTQSANCiAgICAgIFBob25lOiAr MSA1MDMgMjY0IDg4MTMgDQogICAgICBFbWFpbDogbGlseS5sLnlhbmdAaW50ZWwuY29tIA0KICAg ICAgIA0KICAgICAgSm9lbCBNLiBIYWxwZXJuIA0KICAgICAgTWVnaXN0byBTeXN0ZW1zLCBJbmMu IA0KICAgICAgMjAyNTEgQ2VudHVyeSBCbHZkLiANCiAgICAgIEdlcm1hbnRvd24sIE1EIDIwODc0 LTExNjIsIFVTQSANCiAgICAgIFBob25lOiArMSAzMDEgNDQ0LTE3ODMgDQogICAgICBFbWFpbDog amhhbHBlcm5AbWVnaXN0by5jb20gDQogICAgICAgDQogICAgICBSYW0gR29wYWwgDQogICAgICBO b2tpYSBSZXNlYXJjaCBDZW50ZXIgDQogICAgICA1LCBXYXlzaWRlIFJvYWQsIA0KICAgICAgQnVy bGluZ3RvbiwgTUEgMDE4MDMsIFVTQSANCiAgICAgIFBob25lOiArMSA3ODEgOTkzIDM2ODUgDQog ICAgICBFbWFpbDogcmFtLmdvcGFsQG5va2lhLmNvbSANCiAgICAgICANCiAgICAgIEFsYW4gRGVL b2sgDQogICAgICBJbmZvYmxveCwgSW5jLiANCiAgICAgIDQ3NSBQb3RyZXJvIEF2ZSwgDQogICAg ICBTdW5ueXZhbGUgQ0EgOTQwODUgDQogICAgICBQaG9uZTogIA0KICAgICAgRW1haWw6IGFsYW4u ZGVrb2tAaW5mb2Jsb3guY29tIA0KICAgIA0KICAgICAgWnNvbHQgSGFyYXN6dGkgDQogICAgICBF bWFpbDogenNvbHRAbW9kdWxhcm5ldC5jb20gDQogICAgDQogICBZYW5nLCBldCBhbC4gICAgICBF eHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOTddIA0KDCAg IEludGVybmV0IERyYWZ0ICAgICAgICAgRm9yQ0VTIEZFIE1vZGVsICAgICAgICAgICAgICBBdWd1 c3QgMjAwNSANCiAgICANCiAgICANCiAgICANCiAgICAgIFN0ZXZlbiBCbGFrZSANCiAgICAgIE1v ZHVsYXIgTmV0d29ya3MgDQogICAgICBQaG9uZTogKzEgOTE5IDQzNC0xNDg1IA0KICAgICAgRW1h aWw6IHNsYmxha2VAbW9kdWxhcm5ldC5jb20gDQogICAgICAgDQogICAgICBFbGxlbiBEZWxlZ2Fu ZXMgDQogICAgICBJbnRlbCBDb3JwLiANCiAgICAgIE1haWwgU3RvcDogSkYzLTIwNiANCiAgICAg IDIxMTEgTkUgMjV0aCBBdmVudWUgDQogICAgICBIaWxsc2Jvcm8sIE9SIDk3MTI0LCBVU0EgDQog ICAgICBQaG9uZTogKzEgNTAzIDcxMiA0MTczIA0KICAgICAgRW1haWw6IGVsbGVuLm0uZGVsZWdh bmVzQGludGVsLmNvbSANCiAgICAgICANCiAgICAgICANCiAgIDEzLiANICAgICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0IA0KICAgICAgIA0KICAgICAgVGhlIGF1dGhvcnMgYXJlIG5vdCBh d2FyZSBvZiBhbnkgaW50ZWxsZWN0dWFsIHByb3BlcnR5IHJpZ2h0IA0KICAgICAgaXNzdWVzIHBl cnRhaW5pbmcgdG8gdGhpcyBkb2N1bWVudC4gDQogICAgICAgDQogICAxNC4gDSAgICAgIElBTkEg Y29uc2lkZXJhdGlvbiANCiAgICANCiAgICAgIEEgbmFtZXNwYWNlIGlzIG5lZWRlZCB0byB1bmlx dWVseSBpZGVudGlmeSB0aGUgTEZCIHR5cGUgaW4gdGhlIExGQiANCiAgICAgIGNsYXNzIGxpYnJh cnkuICANCiAgICAgICANCiAgICAgIEZyYW1lIHR5cGUgc3VwcG9ydGVkIG9uIGlucHV0IGFuZCBv dXRwdXQgb2YgTEZCIG11c3QgYWxzbyBiZSANCiAgICAgIHVuaXF1ZWx5IGlkZW50aWZpZWQuIA0K ICAgICAgICANCiAgICAgIEEgc2V0IG9mIG1ldGFkYXRhIHN1cHBvcnRlZCBieSB0aGUgTEZCIG1v ZGVsIG11c3QgYWxzbyBiZSB1bmlxdWVseSANCiAgICAgIGlkZW50aWZpZWQgd2l0aCBuYW1lcyBv ciBJRHMuIA0KICAgICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgDQog ICBZYW5nLCBldCBhbC4gICAgICBFeHBpcmVzIEF1Z3VzdCAyMDA1ICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgOThdIA0KDA== ------_=_NextPart_001_01C515DF.5E1F2596-- From hringwynn9s@nase.com Sat Feb 19 12:19: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 MAA21820; Sat, 19 Feb 2005 12:19:53 -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 1D2Yck-0004ma-3o; Sat, 19 Feb 2005 12:42:35 -0500 Received: from host243-222.pool80180.interbusiness.it ([80.180.222.243]) by mx2.foretec.com with smtp (Exim 4.24) id 1D2YGj-0008Tp-6p; Sat, 19 Feb 2005 12:19:49 -0500 Received: from sockeye.hringwynn9s@nase.com ([65.246.255.50]) by titular.hringwynn9s@nase.com with MailEnable ESMTP; Sat, 19 Feb 2005 11:23:05 -0600 Date: Sat, 19 Feb 2005 11:23:05 -0600 Message-Id: <9824485046270.13939@drusilla> From: heather-jeanne sheppard To: Enum-archive Subject: Micr0s0ft and Ad0be products MIME-Version: 1.0 Content-Type: text/html; charset="iso-0908-8" Content-Transfer-Encoding: 7Bit Content-Description: britannica signify torrance X-Spam-Score: 1.2 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7Bit
You looking for inexpensive software for your PC ?
Latest graphics and publishing software from Corel,Macromedia,Adobe etc
are available in our site.You can get them for a very cheap price.
Check our 0em software site.Here is a brief list of what we have :

Microsoft Windows XP Pro + Microsoft Office XP Pro -89.95 $
Windows XP Professional With SP2 Full Version -79.95 $
Windows 2000 Professional -59.95 $
Macromedia Dreamwaver MX 2004 + Flash MX 2004 -109.95 $
Adobe Photoshop CS with ImageReady CS -99.95 $
Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 -129.95 $
Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS -149.95 $
Corel Draw Graphics Suite 11 -59.95 $
Corel Photo Painter 8 -59.95 $
Corel WordPerfect Office 10 -69.95 $


These are some of the software we have.Please check our site
to find more products.You save up to % 80 on all products.

Check our site

Thanks
From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 19 21:40:17 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 VAA01347 for ; Sat, 19 Feb 2005 21:40:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2hN6-0001ki-1h for forces-archive@IETF.ORG; Sat, 19 Feb 2005 22:03: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 <6.00FAA0BD@cherry.ease.lsoft.com>; Sat, 19 Feb 2005 21:40:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58638460 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 19 Feb 2005 21:40:13 -0500 Received: from 81.228.9.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 19 Feb 2005 21:40:13 -0500 Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 86AEA37E46; Sun, 20 Feb 2005 03:40:12 +0100 (CET) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 7796037E44 for ; Sun, 20 Feb 2005 03:40:12 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 67C7638004 for ; Sun, 20 Feb 2005 03:40:12 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1D2h0w-00071m-Fb for forces@peach.ease.lsoft.com; Sun, 20 Feb 2005 03:40:07 +0100 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Tue, 25 Jan 2005 19:36:50 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1108867199.11.0.648638602365.issue9@mip4.org> Date: Sun, 20 Feb 2005 02:39:59 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : Need to define LFBs better now that we have things like core LFBs. Caught by Alistair Munro, to quote: --- Definitions: LFB type is defined as a "packet processing function" but some=20 LFBs, (e.g. the protocol LFBs in 3.3.2, 6.2 - these aren't really=20 "fine-grain" either), do not process packets. Perhaps it should be a=20 "processing function... generally operating upon packets...". Probably=20 taken from the Model? --- capturing aso we dont loose it. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 24 nosy: jamal priority: Must fix status: Need clarifying text title: Fix LFB definition __________________________________________________ Forces issue tracker __________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 20 21:32: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 VAA07785 for ; Sun, 20 Feb 2005 21:32:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D33iw-0000yw-LG for forces-archive@IETF.ORG; Sun, 20 Feb 2005 21:55: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 <16.00FAB4A2@cherry.ease.lsoft.com>; 20 Feb 2005 21:32:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58745904 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 20 Feb 2005 21:32:03 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 20 Feb 2005 21:32:03 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022018325264:3759 ; Sun, 20 Feb 2005 18:32:52 -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 02/20/2005 06:32:52 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/20/2005 06:32:54 PM, Serialize complete at 02/20/2005 06:32:54 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1108953119.1091.116.camel@jzny.localdomain> Date: Sun, 20 Feb 2005 21:32:00 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: New protocol draft uploaded To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Folks, A new protocol draft version -02 has been submuitted. Theres at least 30 more new pages of text - with the most important addition being the data path encoding. Appendix F lists all changes from last time. It will probably take about a couple of days to show up; in the mean time please find it here: ftp://ftp.znyx.com/users/hadi/private/forces/draft-ietf-forces-protocol-02.txt Direct all discussions on the draft to the list. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 21 07:16: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 HAA18035 for ; Mon, 21 Feb 2005 07:16:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3CqW-0007MG-4p for forces-archive@IETF.ORG; Mon, 21 Feb 2005 07:39: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 <7.00FAC16B@cherry.ease.lsoft.com>; Mon, 21 Feb 2005 7:16:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58822965 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 21 Feb 2005 07:16:10 -0500 Received: from 81.228.9.108 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 21 Feb 2005 07:16:09 -0500 Received: by av2-2-sn3.vrr.skanova.net (Postfix, from userid 502) id B4BE437E80; Mon, 21 Feb 2005 13:16:08 +0100 (CET) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A517A37E4B for ; Mon, 21 Feb 2005 13:16:08 +0100 (CET) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 84D3438008 for ; Mon, 21 Feb 2005 13:16:08 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1D3CTs-0000Mc-TJ for forces@peach.ease.lsoft.com; Mon, 21 Feb 2005 13:16:08 +0100 Content-Type: multipart/mixed; boundary="213.64.174.195.33.1401.1108988162.561.1" MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Tue, 25 Jan 2005 19:36:50 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1108988162.32.0.991767297489.issue10@mip4.org> Date: Mon, 21 Feb 2005 12:16:02 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue10] section 3.3.1.1 - agains draft -02 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd --213.64.174.195.33.1401.1108988162.561.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : Text on atomicity suggested by Alistair Munro: -- ---------- category: Editorial draft: draft-ietf-forces-protocol files: am-mail.txt messages: 25 nosy: jamal priority: Must fix status: Text proposed title: section 3.3.1.1 - agains draft -02 ___________________________________________________ Forces issue tracker ___________________________________________________ --213.64.174.195.33.1401.1108988162.561.1 Content-Type: text/plain Content-Disposition: attachment; filename="am-mail.txt" Content-Transfer-Encoding: 7bit 3.3.1.1 Execution There are two execution models: 1. Non-transactional - the CE knows exact details about the resources at the FE (memory, table sizes, etc). When it says "SET" it knows that would work etc. In this scenario, it is contended by the proponents of this optimization that when a CE decides to send a command to an FE it will work 100%. In other words, remote operations without any transactional properties (given the CE computes the success of the transaction). 2. Transactional - the classical Two-phase-commit(2PC)[REference to be added here] scheme; undo/rollback when things go wrong. Undoing is initiated by the CE after an error response from any one FE being synchronized is received. There are 3 execution modes that could be requested for operations spanning on one or more LFB selectors: Transactional all-or-none. Any-of-N independent operations. go-to-N loose transaction. 3.3.1.1.1 Requirements for ForCES Transactions ForCES transactions MUST support ACIDity [ACID], defined as: o *Atomicity*. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. o *Consistency*. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. o *Isolation*. A transaction in process and not yet committed must remain isolated from any other transaction. o *Durability*. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. 3.3.1.1.1.1 Transaction definition We define a transaction as a collection of one or more ForCES operations, spanning one or more messages, that MUST have ACID properties. 3.3.1.1.1.2 Transaction protocol: initiation, abort and commit A 2PC starts with a START | ATOMIC flag on its first message of a transaction. A transaction may span multiple messages. It is up to the CE to keep track of the different seq #s making up a transaction. This may then be followed by more messages which are part of the same atomic transaction. Any failure notified by the FE causes the CE to execute an ABORT to all FEs involved in the transaction, rolling back all previously executed operations in the transaction. Failures that occur during the data phase of the transaction include loss of heartbeat, association failure (possibly notified to the respective CE or FE by means outside the scope of ForCES) among other events leading to loss of communication. If the CE fails then FEs MUST presume the transaction will be aborted, and MUST undo the effects of all operations execute thus far. If the CE survives then it MUST issue an ABORT to remaining FEs. When failed FEs re-associate themselves with the CE they will either discover a transaction in the data phase, and presume an ABORT would have been executed, or they have no knowledge of the transaction (following, e.g. complete loss of all data) in which case recovery of their state must be done by the CE in an implementation dependent way. The transaction commitment phase is signalled by an empty DONE msg type. 3.3.1.1.1.3 Transactional protocol: recovery Any of the participating FEs, or the CE, or the associations between them, may fail after the DONE message has left the CE and before it has received all the responses, (possibly the DONE never reached the FEs). At this point it is known that none of the operations failed but it is presumed that the data has not yet been made durable by the FEs. The means of detecting such failures may include loss of heartbeat (within the scope of ForCES) or mechanisms outside the scope of ForCES. When the associations are re-established, the CE will discover a transaction in a commited but partially confirmed intermediate state. Some FEs will have made the data durable and closed the transaction; others may have failed while doing so, and may, or may not, still have that data. At this point the transaction enters the recovery phase. The CE re-issues an empty DONE message to all FEs involved in the transaction. Those that completed the transaction confirm this to the CE. Those that did not, commit the data and confirm this to the CE. An FE that has lost all records of the transaction MUST reply with status UNKNOWN and the actions subsequently taken by the CE are implementation dependent. If it was the CE that failed, then FEs that discover a transaction in a committed state when the association is re-established will have received the DONE request. When the CE re-issues the DONE request, they MUST acknowledge to confirm commitment. If the CE fails in such a way that all records of the transaction are lost, it is assumed that this situation will be recovered from in an implementation dependent way. CEs and FEs that offer transactional execution MUST fulfil the requirements for ACIDity and are presumed to retain data in isolated, non-durable, state so that recovery can take place. 3.3.1.1.2 one-of-N independent operations In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more operations fail. This mode is signalled by a missing ATOMIC flag. 3.3.1.1.3 go-to-N loose transaction In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything upto failed is not undone unlike #1. flag: GOTON (global) --213.64.174.195.33.1401.1108988162.561.1-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 21 11:51: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 LAA20188 for ; Mon, 21 Feb 2005 11:51:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3H93-00072v-SW for forces-archive@IETF.ORG; Mon, 21 Feb 2005 12:14: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 <5.00FAC555@cherry.ease.lsoft.com>; Mon, 21 Feb 2005 11:51:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58851750 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 21 Feb 2005 11:51:47 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 21 Feb 2005 11:51: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 2005022108522633:4278 ; Mon, 21 Feb 2005 08:52:26 -0800 References: <468F3FDA28AA87429AD807992E22D07E044D4568@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 02/21/2005 08:52:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/21/2005 08:52:27 AM, Serialize complete at 02/21/2005 08:52:27 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109004693.1076.57.camel@jzny.localdomain> Date: Mon, 21 Feb 2005 11:51:34 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Model comments: FE Object and FE topology To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E044D4568@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Folks, I wish to reopen the discussion on the FE topology mostly given light of newer developments such as working towards making draft-ansari-forces-discovery-01.txt a WG item (as discussed in last meeting). Besides that i do believe that FEConfiguredNeighborType violates the simple rules we have imposed on separation (unnecessarily if i may add). The FEObjects view of the neighbor at the moment is a little too intrusive. It tries to aggregate things that are found in a few other LFBs within this single spot (ARP, etc) when there is no need to do so. If we need to lookup an IP to address mapping surely that would be ARP LFBs job. If we are to have static entries mapping the two, then that still belongs to the ARP LFB. Ok, worst case create a "static configuration LFB" (although static config files should do just fine). I dont expect a human (other than a developer) to be looking at this LFBs details. I do expect tools to look at this LFB for the purpose of gathering and correlating info about an FE and its neighbors but they woul be looking at a lot more LFBs. i.e there is no point in breaking the rules just for this one thing. Additionaly: FEConfiguredNeighborType also asumes MAC addresses and IP addresses as the underlying connection for the Neighbor. This is bad. I do expect we will see various technologies interconnecting FEs (anywhere from sockets, ethernet, ethernet VLANS, CSIX, SPI-X to PCI-Express AS- switches.) My suggestion: The most meaningful things to show that will suffice for all configuration is: - Neighbors FEID - The interface of the above neighbor - FE's interface that connects to this neighbor Even the above maybe intrusive, but make less assumptions. Any other information should be accessible elsewhere. You oughta know where to find it because it is documented in LFB definitions. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 22 13:04: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 NAA29223 for ; Tue, 22 Feb 2005 13:04:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ekv-0004tL-IW for forces-archive@IETF.ORG; Tue, 22 Feb 2005 13:27: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 <8.00FAE088@cherry.ease.lsoft.com>; Tue, 22 Feb 2005 13:04:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58987366 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 13:04:09 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Feb 2005 13:04:09 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9305670 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 13:04:08 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <200502212045.PAA13414@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050222125821.034b6480@localhost> Date: Tue, 22 Feb 2005 13:03:39 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <200502212045.PAA13414@ietf.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 My thanks to the authors for this revision of their work. This is a clear and useful description of a TML. Two minor, related comments not so much about this document but about how the working group can handle one aspect of this. It seems to me that for multiple TMLs to be useful, the upper interface provided by the different TMLs needs to be the same. This prompts two thoughts: Can the authors of other TML proposals please look at the API defined here, and let the working group know if that looks like the interface they would like to provide? Once we get agreement, can we move that into the PL document (since the alternative, as far as I can tell, would be to try to duplicate it without change into each TML document.) Next, could we possibly define this as a service interface rather than an API. I don't think that we want to mandate that a PL must invoke these exact subroutine calls. We do want to say that the PL will use these services from the TML, resulting in a specific and predictable on-the-wire sequence. Thank you, Joel At 03:45 PM 2/21/2005, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : TCP/IP based TML (Transport Mapping Layer) for > ForCES protocol > Author(s) : H. Khosravi, et al. > Filename : draft-khosravi-forces-tcptml-01.txt > Pages : 25 > Date : 2005-2-21 > >This document defines the TCP/IP based TML (Transport Mapping Layer) > for the ForCES protocol. It explains the rationale for choosing the > transport protocols and also describes how this TML addresses all > the requirements described in the Forces [3] requirements and ForCES > protocol [7] document. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-khosravi-forces-tcptml-01.txt From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 22 13:28: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 NAA01402 for ; Tue, 22 Feb 2005 13:28:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3f8Q-0005XH-BW for forces-archive@IETF.ORG; Tue, 22 Feb 2005 13:51: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 <16.00FAE21E@cherry.ease.lsoft.com>; Tue, 22 Feb 2005 13:28:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 58989794 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 13:28:30 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Feb 2005 13:28:29 -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 j1MISNas015938; Tue, 22 Feb 2005 18:28:23 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 j1MIS5tK001729; Tue, 22 Feb 2005 18:28:23 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022210282226452 ; Tue, 22 Feb 2005 10:28:22 -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, 22 Feb 2005 10:28:22 -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] I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUZCQJI7Nh+x28bShaYMK0sMo8KrAAAg7mA X-OriginalArrivalTime: 22 Feb 2005 18:28:22.0330 (UTC) FILETIME=[4A17C1A0:01C5190C] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E04550167@orsmsx408> Date: Tue, 22 Feb 2005 10:28:11 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Joel, I am fine with either of your suggestions. Another option that is possible is to have a separate draft on PL<->TML API, which I believe Jamal is working on. If the working group feels this is a good option, we could merge our content into that draft. BTW, for reference could you point me to an example of a service interface defined in the IETF ? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, February 22, 2005 10:04 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt My thanks to the authors for this revision of their work. This is a clear and useful description of a TML. Two minor, related comments not so much about this document but about how=20 the working group can handle one aspect of this. It seems to me that for multiple TMLs to be useful, the upper interface=20 provided by the different TMLs needs to be the same. This prompts two=20 thoughts: Can the authors of other TML proposals please look at the API defined=20 here, and let the working group know if that looks like the interface they=20 would like to provide? Once we get agreement, can we move that into the PL document (since the alternative, as far as I can tell, would be to try to duplicate it=20 without change into each TML document.) Next, could we possibly define this as a service interface rather than an=20 API. I don't think that we want to mandate that a PL must invoke these=20 exact subroutine calls. We do want to say that the PL will use these=20 services from the TML, resulting in a specific and predictable on-the-wire=20 sequence. Thank you, Joel At 03:45 PM 2/21/2005, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > > > Title : TCP/IP based TML (Transport Mapping Layer) for=20 > ForCES protocol > Author(s) : H. Khosravi, et al. > Filename : draft-khosravi-forces-tcptml-01.txt > Pages : 25 > Date : 2005-2-21 > >This document defines the TCP/IP based TML (Transport Mapping Layer) > for the ForCES protocol. It explains the rationale for choosing the > transport protocols and also describes how this TML addresses all > the requirements described in the Forces [3] requirements and ForCES > protocol [7] document. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-khosravi-forces-tcptml-01.txt From owner-forces@PEACH.EASE.LSOFT.COM Tue Feb 22 16:32:55 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 QAA24565 for ; Tue, 22 Feb 2005 16:32:55 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3i0u-00036y-Dz for forces-archive@IETF.ORG; Tue, 22 Feb 2005 16:56:16 -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.00FAE651@cherry.ease.lsoft.com>; Tue, 22 Feb 2005 16:32:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59006013 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 16:32:54 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Feb 2005 16:32:54 -0500 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.44) id 1D3heF-0005cO-4l for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 21:32:53 +0000 Received: from s86-14.nomadic.bris.ac.uk ([137.222.86.14] helo=een9174.een.bris.ac.uk) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.44) id 1D3heE-0002mu-Q9 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 22 Feb 2005 21:32:50 +0000 References: <200502212045.PAA13414@ietf.org> <6.2.1.2.0.20050222125821.034b6480@localhost> Originator-Info: login-token=Mulberry:018GPon1XISRMopGEJHlbJFQgoxV7CMGLZFgEtzWHDHlORXQo=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: <088BD7691E9D6347A9AE7CCA@[192.168.0.3]> Date: Tue, 22 Feb 2005 21:32:45 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050222125821.034b6480@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Hi All, Just to follow up on Joel's comment, I think replacing the API by a service specification would be more acceptable. There are plenty of flat-earthers around that wouldn't let this past. I think the only thing I am missing is TML-originated events, such as the forced close or reset of any of the underlying TCP sessions, e.g. following reboot of one or other of the parties involved or some other exception reported locally. These may be o/s dependent. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 23 00:42: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 AAA13231 for ; Wed, 23 Feb 2005 00:42:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3peT-0002oX-0e for forces-archive@IETF.ORG; Wed, 23 Feb 2005 01:05: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 <13.00FAF116@cherry.ease.lsoft.com>; Wed, 23 Feb 2005 0:42:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59038024 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 23 Feb 2005 00:42:07 -0500 Received: from 64.12.137.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Feb 2005 00:42:07 -0500 Received: from Aaudu2000@aol.com by imo-m28.mx.aol.com (mail_out_v37_r3.8.) id a.154.4b5cfac4 (16098) for ; Wed, 23 Feb 2005 00:42:04 -0500 (EST) Received: from aol.com (mow-m02.webmail.aol.com [64.12.184.130]) by air-id11.mx.aol.com (v104.18) with ESMTP id MAILINID112-3ee2421c17abf2; Wed, 23 Feb 2005 00:42:04 -0500 MIME-Version: 1.0 X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 71.96.139.229 X-AOL-Language: english Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Aaudu2000@AOL.COM Message-ID: <554C8C55.0945FB52.0218F5DE@aol.com> Date: Wed, 23 Feb 2005 00:42:03 -0500 Reply-To: Aaudu2000@aol.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 3.1 (+++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 8bit Hello All, I also agree with Joel's comments. The APIs should be replaced with service specification of some sort (service primitives, as they are often called). The interface should also address asynchronous data arrivals and event notifications at, and across the interface. Cheers, Alex. In a message dated 2/22/2005 4:32:45 PM Eastern Standard Time, Alistair Munro writes: >Hi All, > >Just to follow up on Joel's comment, I think replacing the API by a service >specification would be more acceptable. There are plenty of flat-earthers >around that wouldn't let this past. > >I think the only thing I am missing is TML-originated events, such as the >forced close or reset of any of the underlying TCP sessions, e.g. following >reboot of one or other of the parties involved or some other exception >reported locally. These may be o/s dependent. > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com > From owner-forces@PEACH.EASE.LSOFT.COM Wed Feb 23 03:59: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 DAA15984 for ; Wed, 23 Feb 2005 03:59:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3six-0002KR-Ey for forces-archive@IETF.ORG; Wed, 23 Feb 2005 04:22: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.00FAF5F0@cherry.ease.lsoft.com>; Wed, 23 Feb 2005 3:59:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59047069 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 23 Feb 2005 03:59:00 -0500 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Feb 2005 03:59:00 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j1N8wwFU137584 for ; Wed, 23 Feb 2005 08:58:58 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1N8wwi0017512 for ; Wed, 23 Feb 2005 08:58:58 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1N8wvIq009489 for ; Wed, 23 Feb 2005 08:58:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1N8wvnp009464 for ; Wed, 23 Feb 2005 08:58:57 GMT Received: from [127.0.0.1] (dhcp71-40.zurich.ibm.com [9.4.71.40]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA86930; Wed, 23 Feb 2005 09:58:56 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090507040309060704040106" Approved-By: Patrick Droz Message-ID: <421C45CE.1020400@zurich.ibm.com> Date: Wed, 23 Feb 2005 09:58:54 +0100 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: Minneapolis presentations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 This is a cryptographically signed message in MIME format. --------------ms090507040309060704040106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, please send your requests for presentations to me and David. In your request please indicate the following: Time: I-D name: Name of presentation: Presenter: We have a 2.5 h slot on Monday morning. Regards, Patrick -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms090507040309060704040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAyMjMw ODU4NTRaMCMGCSqGSIb3DQEJBDEWBBTNoRTypHOpJTs7L4+AbhgPHLwAkTBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgF11braU0PxsPKnGmY9shY1BdZwFiJho8TtA cyJRWRMx8djDPZgGwN0cGVEDW4AEXXaur7i8Q1mDGbonOaY9JlnS4ZD3WmRi+290w8NyPWCG +egecHlei3nzsRY5sPZktiSV4w9JiLZxC386Xkb2Ynt7zWHw42nuwb2DdLrOQtH+AAAAAAAA --------------ms090507040309060704040106-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 24 08:51:04 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 IAA19488 for ; Thu, 24 Feb 2005 08:51:04 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JlO-000656-3Z for forces-archive@IETF.ORG; Thu, 24 Feb 2005 09:14: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 <22.00FB18F1@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 8:51:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59242193 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 08:51:02 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 08:50:57 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 j1ODouOe025698; Thu, 24 Feb 2005 13:50:56 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 j1ODosMn027093; Thu, 24 Feb 2005 13:50:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022405505431469 ; Thu, 24 Feb 2005 05:50:54 -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); Thu, 24 Feb 2005 05:50:53 -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] I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUZCPXyxwZlVMGYTAyiy0tMzBODlQA7snlQ X-OriginalArrivalTime: 24 Feb 2005 13:50:53.0915 (UTC) FILETIME=[DBB0BAB0:01C51A77] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Thu, 24 Feb 2005 05:50:52 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable (hat off) I agree on the value of defining a generic SAP, and think it would be a natural fit as an appendix=20 of the PL draft as it should be common to all TMLs. In terms of the API draft, it is more challenging (but not unprecedented) to do APIs in the IETF. However, an informative draft that documents how the SAP is realized as an API (either generically or in Linux) would probably be valuable and acceptable. Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Tuesday, February 22, 2005 10:04 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt >=20 > My thanks to the authors for this revision of their work. > This is a clear and useful description of a TML. >=20 > Two minor, related comments not so much about this document=20 > but about how=20 > the working group can handle one aspect of this. >=20 > It seems to me that for multiple TMLs to be useful, the upper=20 > interface=20 > provided by the different TMLs needs to be the same. This=20 > prompts two=20 > thoughts: > Can the authors of other TML proposals please look at=20 > the API defined=20 > here, and let the working group know if that looks like the=20 > interface they=20 > would like to provide? > Once we get agreement, can we move that into the PL=20 > document (since=20 > the alternative, as far as I can tell, would be to try to=20 > duplicate it=20 > without change into each TML document.) >=20 > Next, could we possibly define this as a service interface=20 > rather than an=20 > API. I don't think that we want to mandate that a PL must=20 > invoke these=20 > exact subroutine calls. We do want to say that the PL will use these=20 > services from the TML, resulting in a specific and=20 > predictable on-the-wire=20 > sequence. >=20 > Thank you, > Joel >=20 > At 03:45 PM 2/21/2005, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > > > > > Title : TCP/IP based TML (Transport=20 > Mapping Layer) for=20 > > ForCES protocol > > Author(s) : H. Khosravi, et al. > > Filename : draft-khosravi-forces-tcptml-01.txt > > Pages : 25 > > Date : 2005-2-21 > > > >This document defines the TCP/IP based TML (Transport Mapping Layer) > > for the ForCES protocol. It explains the rationale for=20 > choosing the > > transport protocols and also describes how this TML addresses all > > the requirements described in the Forces [3]=20 > requirements and ForCES > > protocol [7] document. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-khosravi-forces-tcp tml-01.txt >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 24 10:06: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 KAA28873 for ; Thu, 24 Feb 2005 10:06:52 -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 1D4Kwh-00087z-GZ for forces-archive@IETF.ORG; Thu, 24 Feb 2005 10:30:36 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by mx2.foretec.com with esmtp (Exim 4.24) id 1D4KZk-0008QC-3g for forces-archive@IETF.ORG; Thu, 24 Feb 2005 10:06: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 <3.00FB1A48@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 10:04:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59247643 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 10:04:42 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 10:04: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 2005022407052802:1370 ; Thu, 24 Feb 2005 07:05:28 -0800 References: 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 02/24/2005 07:05:28 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/24/2005 07:05:30 AM, Serialize complete at 02/24/2005 07:05:30 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109257477.1293.28.camel@jzny.localdomain> Date: Thu, 24 Feb 2005 10:04:37 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit I would like to continue on the path of a separate TML API approach for now. I have two couathors who joined me and we will be revamping the draft. Opinions/suggestions from other people are welcome. Lets defer to later to see if we need to make this part of the PL draft or it should live its own life. I think it is sensible to define the SAP and show an API format that uses it (beginings of that API are shown in draft 00). We may have to change the draft title. cheers, jamal On Thu, 2005-02-24 at 08:50, Putzolu, David wrote: > (hat off) > I agree on the value of defining a generic SAP, > and think it would be a natural fit as an appendix > of the PL draft as it should be common to all TMLs. > > In terms of the API draft, it is more challenging (but not > unprecedented) to do APIs in the IETF. However, an > informative draft that documents how the SAP is realized as > an API (either generically or in Linux) would probably be > valuable and acceptable. > > Cheers, > David > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > Sent: Tuesday, February 22, 2005 10:04 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt > > > > My thanks to the authors for this revision of their work. > > This is a clear and useful description of a TML. > > > > Two minor, related comments not so much about this document > > but about how > > the working group can handle one aspect of this. > > > > It seems to me that for multiple TMLs to be useful, the upper > > interface > > provided by the different TMLs needs to be the same. This > > prompts two > > thoughts: > > Can the authors of other TML proposals please look at > > the API defined > > here, and let the working group know if that looks like the > > interface they > > would like to provide? > > Once we get agreement, can we move that into the PL > > document (since > > the alternative, as far as I can tell, would be to try to > > duplicate it > > without change into each TML document.) > > > > Next, could we possibly define this as a service interface > > rather than an > > API. I don't think that we want to mandate that a PL must > > invoke these > > exact subroutine calls. We do want to say that the PL will use these > > services from the TML, resulting in a specific and > > predictable on-the-wire > > sequence. > > > > Thank you, > > Joel > > > > At 03:45 PM 2/21/2005, Internet-Drafts@ietf.org wrote: > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > > > > > > > Title : TCP/IP based TML (Transport > > Mapping Layer) for > > > ForCES protocol > > > Author(s) : H. Khosravi, et al. > > > Filename : draft-khosravi-forces-tcptml-01.txt > > > Pages : 25 > > > Date : 2005-2-21 > > > > > >This document defines the TCP/IP based TML (Transport Mapping Layer) > > > for the ForCES protocol. It explains the rationale for > > choosing the > > > transport protocols and also describes how this TML addresses all > > > the requirements described in the Forces [3] > > requirements and ForCES > > > protocol [7] document. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-khosravi-forces-tcp > tml-01.txt > > From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 24 12:07:29 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 MAA16854 for ; Thu, 24 Feb 2005 12:07:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4MpV-0003x4-3A for forces-archive@IETF.ORG; Thu, 24 Feb 2005 12:31: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 <3.00FB1D28@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 12:07:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59263052 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 12:07:27 -0500 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 12:07:27 -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 j1OH7PSd024928 for ; Thu, 24 Feb 2005 17:07: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 j1OH6qNL029272 for ; Thu, 24 Feb 2005 17:07:25 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022409065116494 for ; Thu, 24 Feb 2005 09:06:52 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 09:06: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: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUZCPXyxwZlVMGYTAyiy0tMzBODlQA7snlQACZdRuA= X-OriginalArrivalTime: 24 Feb 2005 17:06:46.0922 (UTC) FILETIME=[390746A0:01C51A93] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Chawla, Shuchi" Message-ID: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> Date: Thu, 24 Feb 2005 09:06:46 -0800 Reply-To: "Chawla, Shuchi" Sender: Forwarding and Control Element Separation From: "Chawla, Shuchi" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Hello all, I joined the ForCES group recently, and I'm a co-author of the TCP/IP TML draft that was submitted recently. =20 With respect to the API we have defined in the draft, we did intend for it to be purely informative to demonstrate realization of the services provided by the TML layer in the context of the ForCES protocol. We included in the TCP/IP TML draft since there is no other home for it at the moment, with the knowledge, that it may have to be moved to a separate informative draft. =20 In my opinion, having gone through the process of defining the API (although not as a complete API spec.) helped us ensure that the model being proposed for services to be provided by the TML layer was indeed legitimate. I believe having such an informative draft would be beneficial to anyone wanting to implement the TML, and would likely minimize interoperability issues that may arise between different TML implementations. Thanks. Regards, Shuchi Chawla -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Thursday, February 24, 2005 5:51 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt (hat off) I agree on the value of defining a generic SAP, and think it would be a natural fit as an appendix=20 of the PL draft as it should be common to all TMLs. In terms of the API draft, it is more challenging (but not unprecedented) to do APIs in the IETF. However, an informative draft that documents how the SAP is realized as an API (either generically or in Linux) would probably be valuable and acceptable. Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Tuesday, February 22, 2005 10:04 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt >=20 > My thanks to the authors for this revision of their work. > This is a clear and useful description of a TML. >=20 > Two minor, related comments not so much about this document=20 > but about how=20 > the working group can handle one aspect of this. >=20 > It seems to me that for multiple TMLs to be useful, the upper=20 > interface=20 > provided by the different TMLs needs to be the same. This=20 > prompts two=20 > thoughts: > Can the authors of other TML proposals please look at=20 > the API defined=20 > here, and let the working group know if that looks like the=20 > interface they=20 > would like to provide? > Once we get agreement, can we move that into the PL=20 > document (since=20 > the alternative, as far as I can tell, would be to try to=20 > duplicate it=20 > without change into each TML document.) >=20 > Next, could we possibly define this as a service interface=20 > rather than an=20 > API. I don't think that we want to mandate that a PL must=20 > invoke these=20 > exact subroutine calls. We do want to say that the PL will use these=20 > services from the TML, resulting in a specific and=20 > predictable on-the-wire=20 > sequence. >=20 > Thank you, > Joel >=20 > At 03:45 PM 2/21/2005, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > > > > > Title : TCP/IP based TML (Transport=20 > Mapping Layer) for=20 > > ForCES protocol > > Author(s) : H. Khosravi, et al. > > Filename : draft-khosravi-forces-tcptml-01.txt > > Pages : 25 > > Date : 2005-2-21 > > > >This document defines the TCP/IP based TML (Transport Mapping Layer) > > for the ForCES protocol. It explains the rationale for=20 > choosing the > > transport protocols and also describes how this TML addresses all > > the requirements described in the Forces [3]=20 > requirements and ForCES > > protocol [7] document. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-khosravi-forces-tcp tml-01.txt >=20 From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 24 13:39: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 NAA27862 for ; Thu, 24 Feb 2005 13:39:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OGo-0006eI-4L for forces-archive@IETF.ORG; Thu, 24 Feb 2005 14:03: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 <16.00FB20AE@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 13:39:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59271380 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 13:39:44 -0500 Received: from 62.241.162.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 13:39:44 -0500 Received: from pc6 (1Cust125.tnt29.lnd3.gbr.da.uu.net [62.188.120.125]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9C788E000346; Thu, 24 Feb 2005 18:39:41 +0000 (GMT) References: <468F3FDA28AA87429AD807992E22D07E04550167@orsmsx408> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Approved-By: Tom Petch Message-ID: <0c5301c51a97$8030e8c0$0601a8c0@pc6> Date: Thu, 24 Feb 2005 11:56:30 +0100 Reply-To: Tom Petch Sender: Forwarding and Control Element Separation From: Tom Petch Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.7 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Khosravi, Hormuzd M" To: Sent: Tuesday, February 22, 2005 7:28 PM Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt BTW, for reference could you point me to an example of a service interface defined in the IETF ? RFC3412 is the one I would use as a template. From owner-forces@PEACH.EASE.LSOFT.COM Thu Feb 24 13:54: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 NAA29639 for ; Thu, 24 Feb 2005 13:54:24 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OUv-00073V-3s for forces-archive@IETF.ORG; Thu, 24 Feb 2005 14:18: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 <18.00FB1F5C@cherry.ease.lsoft.com>; Thu, 24 Feb 2005 13:54:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59273142 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 24 Feb 2005 13:54:19 -0500 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Feb 2005 13:54:14 -0500 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1OIs71O050353 for ; Thu, 24 Feb 2005 13:54:11 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1OIs20U087280 for ; Thu, 24 Feb 2005 13:54:02 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1OIs1oC000149 for ; Thu, 24 Feb 2005 13:54:02 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E044D4568@orsmsx408> <1109004693.1076.57.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <421E222F.6070303@lucent.com> Date: Thu, 24 Feb 2005 13:51:27 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: Model comments: FE Object and FE topology To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Folks, As part of the discussion that Jamal has brought up, I would request the WG members to read the draft on topology discovery - i.e. draft-ansari-forces-discovery-01.txt that was submitted at the last IETF and provide any feedback. Since many WG members had not read the draft the last time, a decision on making it a WG item couldn't be made. I hope that decision can be made at this time. Thanks, Jamal Hadi Salim wrote: >Folks, > >I wish to reopen the discussion on the FE topology mostly given light of >newer developments such as working towards making >draft-ansari-forces-discovery-01.txt a WG item (as discussed in last >meeting). >Besides that i do believe that FEConfiguredNeighborType violates the >simple rules we have imposed on separation (unnecessarily if i may add). > >The FEObjects view of the neighbor at the moment is a little too >intrusive. It tries to aggregate things that are found in a few other >LFBs within this single spot (ARP, etc) when there is no need to do so. >If we need to lookup an IP to address mapping surely that would be ARP >LFBs job. If we are to have static entries mapping the two, then that >still belongs to the ARP LFB. Ok, worst case create a "static >configuration LFB" (although static config files should do just fine). >I dont expect a human (other than a developer) to be looking at this >LFBs details. I do expect tools to look at this LFB for the purpose of >gathering and correlating info about an FE and its neighbors but they >woul be looking at a lot more LFBs. >i.e there is no point in breaking the rules just for this one thing. > >Additionaly: >FEConfiguredNeighborType also asumes MAC addresses and IP addresses as >the underlying connection for the Neighbor. This is bad. >I do expect we will see various technologies interconnecting FEs >(anywhere from sockets, ethernet, ethernet VLANS, CSIX, SPI-X to >PCI-Express AS- switches.) > >My suggestion: > >The most meaningful things to show that will suffice for all >configuration is: > >- Neighbors FEID >- The interface of the above neighbor >- FE's interface that connects to this neighbor > >Even the above maybe intrusive, but make less assumptions. >Any other information should be accessible elsewhere. You oughta know >where to find it because it is documented in LFB definitions. > >cheers, >jamal > > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From service@huntington.com Fri Feb 25 12:14: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 MAA09064; Fri, 25 Feb 2005 12:13:59 -0500 (EST) Message-Id: <200502251713.MAA09064@ietf.org> Received: from [80.96.225.67] (helo=mafia) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4j2Z-0006RL-IJ; Fri, 25 Feb 2005 12:14:13 -0500 From: "Huntington Bank" Subject: Huntington Bank - Urgent Security Notification! Date: Fri, 25 Feb 2005 19:13:54 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 6.1 (++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Untitled Document

          huntington.com 

          Dear Huntington valued member,

          During our regular update verification of the Internet Banking Accounts, we could not verify your current
          information, either your information has been changed or incomplete, as a result your access to use our service
          has been limited. Please update your information.

                 Login to your Huntington Bank Internet Banking whit your user id and password.
                 Confirm your identity, as a customer of Huntington Bank.

         https://onlinebanking.huntington.com/security/login.asp

          If you are not enrolled for Huntington Bank Internet Banking, Get started today! Complete the steps below and
          take advantage of our online services today!

                Go to http://www.huntington.com and enroll for Huntington Internet Banking.
                Select your account details: Username and Password (case sensitive).
                After your enrollment process is complete you will be able to access your account in 24-48 hours.

          https://onlinebanking.huntington.com/enroll.asp

         If you still need assistance, just click the "Help" button within Internet Banking, or contact us. We're here to help
         you 24 hours a day, 7 days a week.

 

Member FDIC | Equal Housing Lender
 ® and Huntington® are federally registered service marks of Huntington Bancshares Incorporated.
© 2005 Huntington Bancshares Incorporated
JBKXFLPHVGNSXQRBTQSPCNSCMBSZQCOJDKDRRV From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 13:58: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 NAA18179 for ; Fri, 25 Feb 2005 13:58:25 -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 1D4kfc-0000FY-5t for forces-archive@IETF.ORG; Fri, 25 Feb 2005 13:58:38 -0500 Received: from cherry.ease.lsoft.com ([209.119.0.109]) by mx2.foretec.com with esmtp (Exim 4.24) id 1D4kfP-00045G-H5 for forces-archive@IETF.ORG; Fri, 25 Feb 2005 13:58:23 -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.00FB3C02@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 13:56:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59402295 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 13:56:56 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 13:56:51 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022510573715:3011 ; Fri, 25 Feb 2005 10:57:37 -0800 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> 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 02/25/2005 10:57:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/25/2005 10:57:39 AM, Serialize complete at 02/25/2005 10:57:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109357807.1086.146.camel@jzny.localdomain> Date: Fri, 25 Feb 2005 13:56:47 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit I finaly had the chance to scan the draft. Some comments - also sharing our implementation experience of a TCP TML. 1) TML<->TML interface. You dont need a protocol other than TCP or any additional headers - the TCP headers should be sufficient - the TCP header is sufficient. We actually started with the scheme described in the draft i.e a little shim header and an additional control protocol. Eventually we found the only reason we needed the headers or the little protocol was for multicast/replicast joining/leaving given TCP is unicast only. Any other need can be achieved via standard TCP features. To simplify, we evolved towards having a separate inter-TML control channel. This channel never carries PL messages. All it does at the moment is carry the replicast join/leave state setup/teardown. This is where our implementation sits right now. We have now reached a conclusion that theres no need even for this extra channel for multicast [1]. I think there maybe other TMLs that may require coordination and their own protocol (such as TIPC which runs over ethernet or directly over a fabric). In the case you are running over IP and another transport such as TCP, it makes sense to reuse the services they offer. 2)PL<->TML interface. The fact that a TCP TML has two channels being passed and that such knowledge is controlled by and embedded to the PL will complicate things. The configuration of the two channels is up to the C/FEM IMO. This knowledge should be oblivious to the PL - if you want simplicty that is. 3) I am begining to worry a little about the redirection channel. Enforcing that all redirected messages have to have a PL header attached to them would become problematic. Theres a gazillion ways that packets could be redirected and most of the time dependent on hardware capability. For example our existing hardware could redirect packets and put extra VLAN tags on them; other much simpler schemes would simply redirect raw packets (OSPF for example) based on the addresses. I think we may need to rediscuss this in the context of the protocol (dont wanna drag on this context because i will end up distracting the topic). cheers, jamal [1] If we assume that the FE multicast PIDs belong to the FE Object (theres a very good fit) then subscription can happen at the PL FE Object level. This needs discusssion; however, upon receiving such a message, the FE PL layer makes a local API call to add the multicast group to the TML. All this local API call does is to tell the TML "Add this to my list of legit IDs". Like i said above this still needs discussion. From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 15:22: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 PAA26841 for ; Fri, 25 Feb 2005 15:22:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4lyf-0001tv-4e for forces-archive@IETF.ORG; Fri, 25 Feb 2005 15:22: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 <16.00FB3D71@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 15:22:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59409223 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 15:21:58 -0500 Received: from 204.178.16.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 15:21:58 -0500 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1PKLvXJ046532 for ; Fri, 25 Feb 2005 15:21:57 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PKLp0U021083 for ; Fri, 25 Feb 2005 15:21:51 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PKLpoC026358 for ; Fri, 25 Feb 2005 15:21:51 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <421F8841.7070406@lucent.com> Date: Fri, 25 Feb 2005 15:19:13 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Jamal, Thanks for the comments. See inline comments.... Jamal Hadi Salim wrote: >I finaly had the chance to scan the draft. > >Some comments - also sharing our implementation experience of a TCP TML. > >1) TML<->TML interface. > >You dont need a protocol other than TCP or any additional headers - the >TCP headers should be sufficient - the TCP header is sufficient. > >We actually started with the scheme described in the draft i.e a little >shim header and an additional control protocol. >Eventually we found the only reason we needed the headers or the little >protocol was for multicast/replicast joining/leaving given TCP is >unicast only. Any other need can be achieved via standard TCP features. >To simplify, we evolved towards having a separate inter-TML control >channel. This channel never carries PL messages. All it does at the >moment is carry the replicast join/leave state setup/teardown. >This is where our implementation sits right now. > > Yes, we didn't really like the idea of having a separate TML shim header either and would love to avoid using it, if possible. Like you mentioned, the reason this even exists in the draft is because there are certain messages that need to be exchanged between the two TMLs - multicast join/leave being an example. And, yes this can be avoided by using a completely separate channel for TML control - but it adds yet another channel between the FE and CE. ....See more detials in comment (3) >We have now reached a conclusion that theres no need even for this extra >channel for multicast [1]. > >I think there maybe other TMLs that may require coordination and their >own protocol (such as TIPC which runs over ethernet or directly over a >fabric). In the case you are running over IP and another transport such >as TCP, it makes sense to reuse the services they offer. > >2)PL<->TML interface. > >The fact that a TCP TML has two channels being passed and that such >knowledge is controlled by and embedded to the PL will complicate >things. The configuration of the two channels is up to the C/FEM IMO. >This knowledge should be oblivious to the PL - if you want simplicty >that is. > > My thinking is similar with respect to second part of your comment. As for the first part, not sure if the knowledge at PL will add any significant complications. In fact, its possible that not having this information may make things more complicated - because, if one of the channels (either the control or the data) goes down, the TML layer has to automatically re-establish the channel - and this requires state maintenance and additional triggering mechanism. If the PL has the knowledge of it that the channel has closed down, it can trigger the open() call to re-establish again - simple. >3) I am begining to worry a little about the redirection channel. > >Enforcing that all redirected messages have to have a PL header attached >to them would become problematic. Theres a gazillion ways that packets >could be redirected and most of the time dependent on hardware >capability. For example our existing hardware could redirect packets and >put extra VLAN tags on them; other much simpler schemes would simply >redirect raw packets (OSPF for example) based on the addresses. >I think we may need to rediscuss this in the context of the protocol >(dont wanna drag on this context because i will end up distracting the >topic). > > > (This comment and first comment are related) Agreed - we don't necessarily need the TML header on redirected messages - as long as these messages are carried over the separate data channel. However, if at some point there is a potential possibility of mixing/multiplexing these messages with other control messages (e.g. if the PL control and data over single channel due to F/CEM conf.) then one needs to have the shim header to appropriately de-mux the messages. So basically one can imagine the following scenarios: (1) 3 channels: - TML-TML, PL control, PL data - No TML Shim Header is needed (2) 2 Channels (a) TML-TML/PL Control, PL Data - TML header needed for Demux (b) TML-TML, PL Control/PL Data - No TML header needed (3) 1 Channel - TML-TML/PL Control/PL Data all together - TML Header needed The draft of course is still preliminary and talks from the perspective of using Option 2(a) and potentially Option 3. Of course, we can have further discussion on which would be the best choice. >cheers, >jamal > >[1] If we assume that the FE multicast PIDs belong to the FE Object >(theres a very good fit) then subscription can happen at the PL FE >Object level. This needs discusssion; however, upon receiving such a >message, the FE PL layer makes a local API call to add the multicast >group to the TML. All this local API call does is to tell the TML >"Add this to my list of legit IDs". Like i said above this still needs >discussion. > > Hmm...not sure I fully understand where you are going with this. Are you saying that no join/leave group "message" is needed between the CE and FE - and only a local API call to add multicast is sufficient? If you see the draft, there is in fact a local API call from the PL to the TML to add the multicast group to the TML. However, as a result of this call, the CE needs to be informed of the new multicast receiver that joined the group and hence we need a Join (or Leave) "message" between the FE and CE TMLs. Thanks, -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 15:32: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 PAA28321 for ; Fri, 25 Feb 2005 15:32:14 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4m88-0002GL-1J for forces-archive@IETF.ORG; Fri, 25 Feb 2005 15:32: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 <18.00FB3BE4@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 15:31:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59409958 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 15:31:52 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 15:31:52 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9347681 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 15:31:51 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050225152817.02eb49e0@localhost> Date: Fri, 25 Feb 2005 15:31:47 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <421F8841.7070406@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad At least for the redirected packets (which folks are arguing should not have a shim header) I can not see how to avoid such a header. Although the IP Header has a total length field, one of the reasons for sending the packet to CE may be that the amount of data received and the total length actually received may not match. We can argue that in such a case we should never send that packet to the CE, but that seems an odd restriction. Yours, Joel PS: This also mandates that the PL header have a total length field. Is it really the job of the TML to tell the PL how to do its job? From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 16:19: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 QAA03870 for ; Fri, 25 Feb 2005 16:19:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4msT-0003o6-GV for forces-archive@IETF.ORG; Fri, 25 Feb 2005 16:20: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 <21.00FB3E0C@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 16:19:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59412690 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 16:19:37 -0500 Received: from 204.178.16.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 16:19:37 -0500 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1PLJbXJ046894 for ; Fri, 25 Feb 2005 16:19:37 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PLJY0U022623 for ; Fri, 25 Feb 2005 16:19:34 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PLJXoC028350 for ; Fri, 25 Feb 2005 16:19:33 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> <6.2.1.2.0.20050225152817.02eb49e0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <421F95C7.8090202@lucent.com> Date: Fri, 25 Feb 2005 16:16:55 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Joel, But couldn't this be deduced from the Outer IP header? - if the transport mechanism is TCP/IP between the FE and CE. I pressume that you mean that the FE receives an IP packet from a neighbor which could have length mismatch and has to be redirected to the CE. This IP packet would be encapsulated within the TCP/IP channel as payload between the CE and FE. In such as case, the outer IP header should contain the "actual" length received. Thanks, Joel M. Halpern wrote: > At least for the redirected packets (which folks are arguing should > not have a shim header) I can not see how to avoid such a header. > Although the IP Header has a total length field, one of the reasons > for sending the packet to CE may be that the amount of data received > and the total length actually received may not match. > We can argue that in such a case we should never send that packet to > the CE, but that seems an odd restriction. > > Yours, > Joel > > PS: This also mandates that the PL header have a total length field. > Is it really the job of the TML to tell the PL how to do its job? -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 16:33:39 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 QAA05304 for ; Fri, 25 Feb 2005 16:33:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4n5t-0004AB-Gu for forces-archive@IETF.ORG; Fri, 25 Feb 2005 16:33: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 <3.00FB3E1B@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 16:33:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59413200 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 16:33:38 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 16:33:38 -0500 Received: from [64.254.114.114] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9348198 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 16:33:37 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> <6.2.1.2.0.20050225152817.02eb49e0@localhost> <421F95C7.8090202@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050225163308.02c8e650@localhost> Date: Fri, 25 Feb 2005 16:33:33 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <421F95C7.8090202@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Remember that TCP is a stream protocol, not a packet protocol. There is no "outer IP packet" to look at. Yours, Joel At 04:16 PM 2/25/2005, Furquan Ansari wrote: >Joel, > But couldn't this be deduced from the Outer IP header? - if the > transport mechanism is TCP/IP between the >FE and CE. I pressume that you mean that the FE receives an IP packet from >a neighbor which could have >length mismatch and has to be redirected to the CE. This IP packet would >be encapsulated within the TCP/IP >channel as payload between the CE and FE. In such as case, the outer IP >header should contain the "actual" length >received. > >Thanks, > >Joel M. Halpern wrote: > >>At least for the redirected packets (which folks are arguing should not >>have a shim header) I can not see how to avoid such a header. >>Although the IP Header has a total length field, one of the reasons for >>sending the packet to CE may be that the amount of data received and the >>total length actually received may not match. >>We can argue that in such a case we should never send that packet to the >>CE, but that seems an odd restriction. >> >>Yours, >>Joel >> >>PS: This also mandates that the PL header have a total length field. >>Is it really the job of the TML to tell the PL how to do its job? > > >-- >Furquan Ansari >Bell Labs Research Ph : 732-949-5249 >Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 17:10: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 RAA07682 for ; Fri, 25 Feb 2005 17:10:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4nfW-0004mG-DE for forces-archive@IETF.ORG; Fri, 25 Feb 2005 17:10: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 <22.00FB4010@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 17:10:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59415548 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 17:10:19 -0500 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 17:10:19 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1PMAI1O058235 for ; Fri, 25 Feb 2005 17:10:18 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PMA87d021137 for ; Fri, 25 Feb 2005 17:10:08 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1PMA8oC029967 for ; Fri, 25 Feb 2005 17:10:08 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> <6.2.1.2.0.20050225152817.02eb49e0@localhost> <421F95C7.8090202@lucent.com> <6.2.1.2.0.20050225163308.02c8e650@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <421FA1A2.2030305@lucent.com> Date: Fri, 25 Feb 2005 17:07:30 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Unless you are using TCP over some other network protocol, I have to assume that the TCP stream is carried within IP datagrams. So, the way I am seeing this is: Headers involved: ------------ Orig Received at FE: [[Payload]IP] Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP] So, what am I missing? Joel M. Halpern wrote: > Remember that TCP is a stream protocol, not a packet protocol. There > is no "outer IP packet" to look at. > > Yours, > Joel > > At 04:16 PM 2/25/2005, Furquan Ansari wrote: > >> Joel, >> But couldn't this be deduced from the Outer IP header? - if the >> transport mechanism is TCP/IP between the >> FE and CE. I pressume that you mean that the FE receives an IP packet >> from a neighbor which could have >> length mismatch and has to be redirected to the CE. This IP packet >> would be encapsulated within the TCP/IP >> channel as payload between the CE and FE. In such as case, the outer >> IP header should contain the "actual" length >> received. >> >> Thanks, >> >> Joel M. Halpern wrote: >> >>> At least for the redirected packets (which folks are arguing should >>> not have a shim header) I can not see how to avoid such a header. >>> Although the IP Header has a total length field, one of the reasons >>> for sending the packet to CE may be that the amount of data received >>> and the total length actually received may not match. >>> We can argue that in such a case we should never send that packet to >>> the CE, but that seems an odd restriction. >>> >>> Yours, >>> Joel >>> >>> PS: This also mandates that the PL header have a total length field. >>> Is it really the job of the TML to tell the PL how to do its job? >> >> >> >> -- >> Furquan Ansari >> Bell Labs Research Ph : 732-949-5249 >> Holmdel, NJ Fax: 732-949-4556 > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 19:57:29 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 TAA20882 for ; Fri, 25 Feb 2005 19:57:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qHD-0007mv-BT for forces-archive@IETF.ORG; Fri, 25 Feb 2005 19:57: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 <22.00FB422F@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 19:57:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59423841 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 19:57:30 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 19:57: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 2005022516581504:3381 ; Fri, 25 Feb 2005 16:58:15 -0800 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.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 02/25/2005 04:58:16 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/25/2005 04:58:17 PM, Serialize complete at 02/25/2005 04:58:17 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109379446.1090.64.camel@jzny.localdomain> Date: Fri, 25 Feb 2005 19:57:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <421F8841.7070406@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 15:19, Furquan Ansari wrote: > Jamal, > Thanks for the comments. See inline comments.... > > Jamal Hadi Salim wrote: > > >I finaly had the chance to scan the draft. > > > >Some comments - also sharing our implementation experience of a TCP TML. > > > >1) TML<->TML interface. [..] > Yes, we didn't really like the idea of having a separate TML shim header > either and would love to avoid using it, > if possible. Like you mentioned, the reason this even exists in the > draft is because there are certain > messages that need to be exchanged between the two TMLs - multicast > join/leave being an example. And, yes > this can be avoided by using a completely separate channel for TML > control - but it adds yet another channel > between the FE and CE. The extra TML-TML control channel thing is the way we have things at the moment in our implementation - but it should die too if we can reach a conclusion on how to do PL level multicast; more after (3) below [..] > >2)PL<->TML interface. > > > >The fact that a TCP TML has two channels being passed and that such > >knowledge is controlled by and embedded to the PL will complicate > >things. The configuration of the two channels is up to the C/FEM IMO. > >This knowledge should be oblivious to the PL - if you want simplicty > >that is. > > > > > My thinking is similar with respect to second part of your comment. As > for the first part, not sure if the knowledge at PL will add any significant > complications. In fact, its possible that > not having this information may make things more complicated - because, > if one of the channels (either the control or the data) goes down, the TML layer > has to automatically re-establish the channel - and this requires state > maintenance and additional triggering mechanism. If the PL has the > knowledge of it that the channel has closed down, it can trigger the > open() call to re-establish again - simple. I would see the TML as a blackbox to the PL at least. Whether it has 11 connections or 1 should be opaque to the TL - whether it actually multicasts or replicasts should also not be something the PL should need worry about. The setup of these parameters is one of the reasons we have the xEM interface. On the example you provide above: I can see a scenario where HA decisions may involve the PL layer; but thats a slightly different issue i.e all the TML would say is "btw, I just lost connection to CE1" and the PL would say "ok, connect to CE2" - this, however, does not put into the equation that 1 or 10 sockets went down. [In the case where you have underlying transport HA (ethernet channel bonding, IP interfaces using VRRP or even SCTP multiple associations via multihoming), these details of a transport channel going down could be resolved by the TML layer without any involvement of the PL. But like i said earlier this is a different issue]. > (This comment and first comment are related) > > Agreed - we don't necessarily need the TML header on redirected messages > - as long as these messages are > carried over the separate data channel. However, if at some point there > is a potential possibility of mixing/multiplexing > these messages with other control messages (e.g. if the PL control and > data over single channel due to F/CEM conf.) > then one needs to have the shim header to appropriately de-mux the messages. > Agreed. What i was worried about is enforcing one scheme of "always add the PL shim header for redirect". It may not be practical. Infact i suspect it will be the least used in the real world. > So basically one can imagine the following scenarios: > > (1) 3 channels: > - TML-TML, PL control, PL data - No TML Shim Header is needed > (2) 2 Channels > (a) TML-TML/PL Control, PL Data - TML header needed for Demux > (b) TML-TML, PL Control/PL Data - No TML header needed > (3) 1 Channel > - TML-TML/PL Control/PL Data all together - TML Header needed > > The draft of course is still preliminary and talks from the perspective > of using Option 2(a) and potentially Option 3. > Of course, we can have further discussion on which would be the best choice. At the moment i am only referencing TCP TML. I dont think i can say the same for TIPC running over PCI-Express AS switching or over ethernet. I think we need to just stay put with PL over TCP and no intermediate between protocol between TCP and the PL layer. In other words there is no TML-TML (if we migrate multicast activity to FE Object). So it would be #2 above with a twist: PL Control, PL data, possibly other PL data channel(s). > >[1] If we assume that the FE multicast PIDs belong to the FE Object > >(theres a very good fit) then subscription can happen at the PL FE > >Object level. This needs discusssion; however, upon receiving such a > >message, the FE PL layer makes a local API call to add the multicast > >group to the TML. All this local API call does is to tell the TML > >"Add this to my list of legit IDs". Like i said above this still needs > >discussion. > > > > > Hmm...not sure I fully understand where you are going with this. Are you > saying that no join/leave group "message" > is needed between the CE and FE - and only a local API call to add > multicast is sufficient? > Not exactly. Let me explain a join (leave will be equivalent). Note, we have not implemented this, so it may have holes. CE: 1 a). Join issued by CE to a select FEs for Mcast ID X. The join is sent to the FE Object at some path. Path could be to attribute or event subscription. 1 b). On succesfull response from all FEs, "add multicast" service call to local TML. 1c). This means we have now successfully added state at the CE and all FEs of interest. FE: 2a). On successfully processing 1a), the FE PL issues a local "add Multicast" for ID x. 2b) response to config from 1a) to CE 2c) FE now has all necessary state to process these messages. > If you see the draft, there is in fact a local API call from the PL to > the TML to add the multicast group to the TML. However, as a result of > this call, the CE needs to be informed of the new multicast receiver > that joined the group and hence we need a Join (or Leave) "message" > between the FE and CE TMLs. > Yes, this is what we do as well today - but we want to get rid of it so it doesnt get propagated across. You get rid of this and you dont need the TML protocol or any shim header. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 20:04: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 UAA21341 for ; Fri, 25 Feb 2005 20:04:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qNk-0007uC-K6 for forces-archive@IETF.ORG; Fri, 25 Feb 2005 20:04: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 <16.00FB421C@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 20:04:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59424518 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 20:04:15 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 20:04:14 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022517050070:3389 ; Fri, 25 Feb 2005 17:05:00 -0800 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> <6.2.1.2.0.20050225152817.02eb49e0@localhost> <421F95C7.8090202@lucent.com> <6.2.1.2.0.20050225163308.02c8e650@localhost> <421FA1A2.2030305@lucent.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 02/25/2005 05:05:01 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/25/2005 05:05:02 PM, Serialize complete at 02/25/2005 05:05:02 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109379851.1089.72.camel@jzny.localdomain> Date: Fri, 25 Feb 2005 20:04:12 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <421FA1A2.2030305@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit In the case of redirection to a specific VLAN: received example: [[Payload]IPx] matching a filter Redirect Data from FE to CE: [[[{[Payload]IPx}MAChdr+vlan tag]. You can demux this easily and figure out the different lengths. With the right hardware you can use different tags for different LFB redirects. cheers, jamal On Fri, 2005-02-25 at 17:07, Furquan Ansari wrote: > Unless you are using TCP over some other network protocol, I have to > assume that the TCP stream > is carried within IP datagrams. So, the way I am seeing this is: > > Headers involved: > ------------ > Orig Received at FE: [[Payload]IP] > > Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP] > > So, what am I missing? > > > Joel M. Halpern wrote: > > > Remember that TCP is a stream protocol, not a packet protocol. There > > is no "outer IP packet" to look at. > > > > Yours, > > Joel > > > > At 04:16 PM 2/25/2005, Furquan Ansari wrote: > > > >> Joel, > >> But couldn't this be deduced from the Outer IP header? - if the > >> transport mechanism is TCP/IP between the > >> FE and CE. I pressume that you mean that the FE receives an IP packet > >> from a neighbor which could have > >> length mismatch and has to be redirected to the CE. This IP packet > >> would be encapsulated within the TCP/IP > >> channel as payload between the CE and FE. In such as case, the outer > >> IP header should contain the "actual" length > >> received. > >> > >> Thanks, > >> > >> Joel M. Halpern wrote: > >> > >>> At least for the redirected packets (which folks are arguing should > >>> not have a shim header) I can not see how to avoid such a header. > >>> Although the IP Header has a total length field, one of the reasons > >>> for sending the packet to CE may be that the amount of data received > >>> and the total length actually received may not match. > >>> We can argue that in such a case we should never send that packet to > >>> the CE, but that seems an odd restriction. > >>> > >>> Yours, > >>> Joel > >>> > >>> PS: This also mandates that the PL header have a total length field. > >>> Is it really the job of the TML to tell the PL how to do its job? > >> > >> > >> > >> -- > >> Furquan Ansari > >> Bell Labs Research Ph : 732-949-5249 > >> Holmdel, NJ Fax: 732-949-4556 > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 20:53: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 UAA23878 for ; Fri, 25 Feb 2005 20:53:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4r9L-0000Dr-UB for forces-archive@IETF.ORG; Fri, 25 Feb 2005 20:53: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 <5.00FB420E@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 20:53:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59426795 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 20:53:27 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 20:53:27 -0500 Received: from [69.170.19.42] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9350422 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 20:53:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <85514027246E4643A1B0780EC0F6F45801F17F1E@orsmsx410> <1109357807.1086.146.camel@jzny.localdomain> <421F8841.7070406@lucent.com> <6.2.1.2.0.20050225152817.02eb49e0@localhost> <421F95C7.8090202@lucent.com> <6.2.1.2.0.20050225163308.02c8e650@localhost> <421FA1A2.2030305@lucent.com> <1109379851.1089.72.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050225204837.02c8f588@localhost> Date: Fri, 25 Feb 2005 20:53:22 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1109379851.1089.72.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Assuming you knew where the packet started (because you knew where the previous one ended) how would you know where this packet ended? If you simply ship the bytes over the TCP connection, TCP will not tell you where the boundary was. And if you ship two such packets back to back, you may get handed both of them on a single read from TCP. Yours, Joel At 08:04 PM 2/25/2005, Jamal Hadi Salim wrote: >In the case of redirection to a specific VLAN: >received example: [[Payload]IPx] matching a filter >Redirect Data from FE to CE: [[[{[Payload]IPx}MAChdr+vlan tag]. >You can demux this easily and figure out the different lengths. >With the right hardware you can use different tags for different >LFB redirects. > >cheers, >jamal > >On Fri, 2005-02-25 at 17:07, Furquan Ansari wrote: > > Unless you are using TCP over some other network protocol, I have to > > assume that the TCP stream > > is carried within IP datagrams. So, the way I am seeing this is: > > > > Headers involved: > > ------------ > > Orig Received at FE: [[Payload]IP] > > > > Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP] > > > > So, what am I missing? > > > > > > Joel M. Halpern wrote: > > > > > Remember that TCP is a stream protocol, not a packet protocol. There > > > is no "outer IP packet" to look at. > > > > > > Yours, > > > Joel > > > > > > At 04:16 PM 2/25/2005, Furquan Ansari wrote: > > > > > >> Joel, > > >> But couldn't this be deduced from the Outer IP header? - if the > > >> transport mechanism is TCP/IP between the > > >> FE and CE. I pressume that you mean that the FE receives an IP packet > > >> from a neighbor which could have > > >> length mismatch and has to be redirected to the CE. This IP packet > > >> would be encapsulated within the TCP/IP > > >> channel as payload between the CE and FE. In such as case, the outer > > >> IP header should contain the "actual" length > > >> received. > > >> > > >> Thanks, > > >> > > >> Joel M. Halpern wrote: > > >> > > >>> At least for the redirected packets (which folks are arguing should > > >>> not have a shim header) I can not see how to avoid such a header. > > >>> Although the IP Header has a total length field, one of the reasons > > >>> for sending the packet to CE may be that the amount of data received > > >>> and the total length actually received may not match. > > >>> We can argue that in such a case we should never send that packet to > > >>> the CE, but that seems an odd restriction. > > >>> > > >>> Yours, > > >>> Joel > > >>> > > >>> PS: This also mandates that the PL header have a total length field. > > >>> Is it really the job of the TML to tell the PL how to do its job? > > >> > > >> > > >> > > >> -- > > >> Furquan Ansari > > >> Bell Labs Research Ph : 732-949-5249 > > >> Holmdel, NJ Fax: 732-949-4556 > > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 22:14:29 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 WAA28130 for ; Fri, 25 Feb 2005 22:14:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4sPn-0001P6-MN for forces-archive@IETF.ORG; Fri, 25 Feb 2005 22:14: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 <5.00FB42DC@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 22:14:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59431157 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 22:14:29 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 22:14:29 -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 j1Q3EOn0006241; Sat, 26 Feb 2005 03:14:24 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 j1Q3EOnD017579; Sat, 26 Feb 2005 03:14:24 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022519142409543 ; Fri, 25 Feb 2005 19:14:24 -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); Fri, 25 Feb 2005 19:14:24 -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] I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUbhtQdwfhQmKIIQBSHFJQELOsdrAAHAWwA X-OriginalArrivalTime: 26 Feb 2005 03:14:24.0615 (UTC) FILETIME=[45EB7F70:01C51BB1] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Fri, 25 Feb 2005 19:14:24 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Comments: To: Furquan Ansari To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable TCP/IP makes no guarantees of respecting the boundaries of the message you give it - to TCL it is just a stream of bytes. Given following received at FE: [[Payload] IP] TCP/IP could deliver any of the following at the CE: [[[{[Payload]IP}PL hdr]TCP]IP]=20 [[[{[Payload]IP}TCP]IP] [[[PL hdr]TCP]IP] [[[{[Payload]TCP]IP] [[}PL Hdr]TCP]IP] [[[{[Payl]TCP]IP] [[[[oad]IP}PL Hdr]TCP]IP] etc - could also concatenate as well: [[[{[Payload1]IP1}PL hdr1{[Payload2]IP2}PL hdr2]TCP]IP] Cheers, David > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan Ansari > Sent: Friday, February 25, 2005 2:07 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt >=20 > Unless you are using TCP over some other network protocol, I have to=20 > assume that the TCP stream > is carried within IP datagrams. So, the way I am seeing this is: >=20 > Headers involved: > ------------ > Orig Received at FE: [[Payload]IP] >=20 > Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP] >=20 > So, what am I missing? >=20 >=20 > Joel M. Halpern wrote: >=20 > > Remember that TCP is a stream protocol, not a packet=20 > protocol. There=20 > > is no "outer IP packet" to look at. > > > > Yours, > > Joel > > > > At 04:16 PM 2/25/2005, Furquan Ansari wrote: > > > >> Joel, > >> But couldn't this be deduced from the Outer IP header? - if the=20 > >> transport mechanism is TCP/IP between the > >> FE and CE. I pressume that you mean that the FE receives=20 > an IP packet=20 > >> from a neighbor which could have > >> length mismatch and has to be redirected to the CE. This IP packet=20 > >> would be encapsulated within the TCP/IP > >> channel as payload between the CE and FE. In such as case,=20 > the outer=20 > >> IP header should contain the "actual" length > >> received. > >> > >> Thanks, > >> > >> Joel M. Halpern wrote: > >> > >>> At least for the redirected packets (which folks are=20 > arguing should=20 > >>> not have a shim header) I can not see how to avoid such a header. > >>> Although the IP Header has a total length field, one of=20 > the reasons=20 > >>> for sending the packet to CE may be that the amount of=20 > data received=20 > >>> and the total length actually received may not match. > >>> We can argue that in such a case we should never send=20 > that packet to=20 > >>> the CE, but that seems an odd restriction. > >>> > >>> Yours, > >>> Joel > >>> > >>> PS: This also mandates that the PL header have a total=20 > length field. > >>> Is it really the job of the TML to tell the PL how to do its job? > >> > >> > >> > >> --=20 > >> Furquan Ansari > >> Bell Labs Research Ph : 732-949-5249 > >> Holmdel, NJ Fax: 732-949-4556 > > >=20 > --=20 > Furquan Ansari > Bell Labs Research Ph : 732-949-5249 > Holmdel, NJ Fax: 732-949-4556 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 22:15: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 WAA28172 for ; Fri, 25 Feb 2005 22:15:51 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4sR7-0001Q8-5G for forces-archive@IETF.ORG; Fri, 25 Feb 2005 22:16: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 <6.00FB43C4@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 22:15:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59431223 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 22:15:51 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 22:15:51 -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 j1Q3FomQ003931 for ; Sat, 26 Feb 2005 03:15:50 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 j1Q3FonD017862 for ; Sat, 26 Feb 2005 03:15:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022519154909623 for ; Fri, 25 Feb 2005 19:15:49 -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, 25 Feb 2005 19:15:49 -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: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? Thread-Index: AcUaokMEvBLJtE+hTe21ZQcFlJYR6wBB1e3A X-OriginalArrivalTime: 26 Feb 2005 03:15:49.0624 (UTC) FILETIME=[7896D780:01C51BB1] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Fri, 25 Feb 2005 19:15:47 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable All, draft-ansari-forces-discovery-01.txt has been proposed as a working group document. This draft defines a=20 controlled objects (aka LFB) as mentioned in the=20 following charter deliverable: o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task.=20 We would like to request that WG participants please review this draft and provide feedback as to whether it should be accepted as a WG document. Acceptance as a WG document means that the WG participants have read the document, approve of the concept and general approach, and believe it is ready to form the basis of a solution to the problem the document addresses, and is within the WG charter. It does not require that the document be in=20 a final form or be 100% correct. Document URL: http://www.ietf.org/internet-drafts/draft-ansari-forces-discovery-01.txt All feedback should be provided either via email to the WG list or in the upcoming WG meeting in Minneapolis. Thanks, David and Patrick > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan Ansari > Sent: Thursday, February 24, 2005 10:51 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] Model comments: FE Object and FE topology >=20 > Folks, > As part of the discussion that Jamal has brought up, I would=20 > request the WG members to read the draft on topology > discovery - i.e. draft-ansari-forces-discovery-01.txt that=20 > was submitted=20 > at the last IETF and provide any feedback. Since many WG=20 > members had not=20 > read the draft the last time, a decision on making it a WG=20 > item couldn't=20 > be made. I hope that decision can be made at this time. >=20 > Thanks, >=20 >=20 > Jamal Hadi Salim wrote: >=20 > >Folks, > > > >I wish to reopen the discussion on the FE topology mostly=20 > given light of > >newer developments such as working towards making > >draft-ansari-forces-discovery-01.txt a WG item (as discussed in last > >meeting).=20 > >Besides that i do believe that FEConfiguredNeighborType violates the > >simple rules we have imposed on separation (unnecessarily if=20 > i may add). > > > >The FEObjects view of the neighbor at the moment is a little too > >intrusive. It tries to aggregate things that are found in a few other > >LFBs within this single spot (ARP, etc) when there is no=20 > need to do so. > >If we need to lookup an IP to address mapping surely that=20 > would be ARP > >LFBs job. If we are to have static entries mapping the two, then that > >still belongs to the ARP LFB. Ok, worst case create a "static > >configuration LFB" (although static config files should do=20 > just fine). > >I dont expect a human (other than a developer) to be looking at this > >LFBs details. I do expect tools to look at this LFB for the=20 > purpose of > >gathering and correlating info about an FE and its neighbors but they > >woul be looking at a lot more LFBs. > >i.e there is no point in breaking the rules just for this one thing. > > > >Additionaly: > >FEConfiguredNeighborType also asumes MAC addresses and IP=20 > addresses as > >the underlying connection for the Neighbor. This is bad. > >I do expect we will see various technologies interconnecting FEs > >(anywhere from sockets, ethernet, ethernet VLANS, CSIX, SPI-X to > >PCI-Express AS- switches.) > > > >My suggestion: > > > >The most meaningful things to show that will suffice for all=20 > >configuration is: > > > >- Neighbors FEID > >- The interface of the above neighbor > >- FE's interface that connects to this neighbor > > > >Even the above maybe intrusive, but make less assumptions. > >Any other information should be accessible elsewhere. You oughta know > >where to find it because it is documented in LFB definitions. > > > >cheers, > >jamal > > =20 > > >=20 > --=20 > Furquan Ansari > Bell Labs Research Ph : 732-949-5249 > Holmdel, NJ Fax: 732-949-4556 >=20 From owner-forces@PEACH.EASE.LSOFT.COM Fri Feb 25 22:35: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 WAA29267 for ; Fri, 25 Feb 2005 22:35:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4skX-0001j5-U3 for forces-archive@IETF.ORG; Fri, 25 Feb 2005 22:36: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 <8.00FB429F@cherry.ease.lsoft.com>; Fri, 25 Feb 2005 22:35:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59431999 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 25 Feb 2005 22:35:55 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Feb 2005 22:35:55 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022519364115:3479 ; Fri, 25 Feb 2005 19:36:41 -0800 References: 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 02/25/2005 07:36:41 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/25/2005 07:36:42 PM, Serialize complete at 02/25/2005 07:36:42 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109388952.1089.92.camel@jzny.localdomain> Date: Fri, 25 Feb 2005 22:35:52 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit You could overcome this issue at the TML level by maintaining state of the packet i.e some form of reassembly detail: put a little loop that reassembles the PL packet from the TCP stream. assuming you receive a PL header but an incomplete PL packet .. which you detect because socket receive() length < PL len, then you buffer the incomplete PL packet until such a point you have sufficient data that is of the same size of PL length. The end of one PL packet is the beggining of another... This so far has worked for us so far. cheers, jamal On Fri, 2005-02-25 at 22:14, Putzolu, David wrote: > TCP/IP makes no guarantees of respecting the boundaries > of the message you give it - to TCL it is just a stream > of bytes. Given following received at FE: [[Payload] IP] > > TCP/IP could deliver any of the following at the CE: > > [[[{[Payload]IP}PL hdr]TCP]IP] > [[[{[Payload]IP}TCP]IP] [[[PL hdr]TCP]IP] > [[[{[Payload]TCP]IP] [[}PL Hdr]TCP]IP] > [[[{[Payl]TCP]IP] [[[[oad]IP}PL Hdr]TCP]IP] > etc - could also concatenate as well: > [[[{[Payload1]IP1}PL hdr1{[Payload2]IP2}PL hdr2]TCP]IP] > > Cheers, > David > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan Ansari > > Sent: Friday, February 25, 2005 2:07 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt > > > > Unless you are using TCP over some other network protocol, I have to > > assume that the TCP stream > > is carried within IP datagrams. So, the way I am seeing this is: > > > > Headers involved: > > ------------ > > Orig Received at FE: [[Payload]IP] > > > > Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP] > > > > So, what am I missing? > > > > > > Joel M. Halpern wrote: > > > > > Remember that TCP is a stream protocol, not a packet > > protocol. There > > > is no "outer IP packet" to look at. > > > > > > Yours, > > > Joel > > > > > > At 04:16 PM 2/25/2005, Furquan Ansari wrote: > > > > > >> Joel, > > >> But couldn't this be deduced from the Outer IP header? - if the > > >> transport mechanism is TCP/IP between the > > >> FE and CE. I pressume that you mean that the FE receives > > an IP packet > > >> from a neighbor which could have > > >> length mismatch and has to be redirected to the CE. This IP packet > > >> would be encapsulated within the TCP/IP > > >> channel as payload between the CE and FE. In such as case, > > the outer > > >> IP header should contain the "actual" length > > >> received. > > >> > > >> Thanks, > > >> > > >> Joel M. Halpern wrote: > > >> > > >>> At least for the redirected packets (which folks are > > arguing should > > >>> not have a shim header) I can not see how to avoid such a header. > > >>> Although the IP Header has a total length field, one of > > the reasons > > >>> for sending the packet to CE may be that the amount of > > data received > > >>> and the total length actually received may not match. > > >>> We can argue that in such a case we should never send > > that packet to > > >>> the CE, but that seems an odd restriction. > > >>> > > >>> Yours, > > >>> Joel > > >>> > > >>> PS: This also mandates that the PL header have a total > > length field. > > >>> Is it really the job of the TML to tell the PL how to do its job? > > >> > > >> > > >> > > >> -- > > >> Furquan Ansari > > >> Bell Labs Research Ph : 732-949-5249 > > >> Holmdel, NJ Fax: 732-949-4556 > > > > > > > -- > > Furquan Ansari > > Bell Labs Research Ph : 732-949-5249 > > Holmdel, NJ Fax: 732-949-4556 > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 26 02:01: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 CAA16467 for ; Sat, 26 Feb 2005 02:01:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4vx8-0005dV-MZ for forces-archive@IETF.ORG; Sat, 26 Feb 2005 02:01: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 <16.00FB4920@cherry.ease.lsoft.com>; Sat, 26 Feb 2005 2:01:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59442468 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 02:01:05 -0500 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 26 Feb 2005 02:01:05 -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 j1Q714CI020939 for ; Sat, 26 Feb 2005 07:01:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1Q714IQ011626 for ; Sat, 26 Feb 2005 07:01:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022523010421549 for ; Fri, 25 Feb 2005 23:01:04 -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); Fri, 25 Feb 2005 23:01:03 -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] I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUbeRRmVo7qxSFxROSfDUeMXqy/VQAVlXiA X-OriginalArrivalTime: 26 Feb 2005 07:01:03.0915 (UTC) FILETIME=[EFBBFFB0:01C51BD0] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0462C94F@orsmsx408> Date: Fri, 25 Feb 2005 23:01:03 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Regarding this shim/TML header containing the length for redirected packets, I believe the ForCES PL header already has a length field that can be used for this purpose. The redirected packets are also transported within a ForCES PL message so the shim/TML header is really not needed if they are sent on a different connection/channel. As Furquan said, if we sent them on the same channel we would need a header to distinguish between TML messages and PL messages, unless we use a separate connection/channel as Jamal is suggesting. The only problem that I see with using a separate channel for TML messages would be for a TML heartbeat message, which would be meaningless over a different connection. But if we decide not to have a TML heartbeat and just use the PL heartbeat message then using a separate connection for TML messages would be a viable approach. Actually I would prefer doing away with TML messages completely as Jamal is suggesting but I need to analyze this further. BTW, Jamal, I agree very much with your design philosophy regarding doing away with TML messages/ header and keeping it simple. Just need to analyze further if this is viable. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, February 25, 2005 12:32 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt At least for the redirected packets (which folks are arguing should not=20 have a shim header) I can not see how to avoid such a header. Although the IP Header has a total length field, one of the reasons for sending the=20 packet to CE may be that the amount of data received and the total length=20 actually received may not match. We can argue that in such a case we should never send that packet to the CE, but that seems an odd restriction. Yours, Joel PS: This also mandates that the PL header have a total length field. Is it=20 really the job of the TML to tell the PL how to do its job? From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 26 11: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 LAA15576 for ; Sat, 26 Feb 2005 11:49:31 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D558d-00074i-4c for forces-archive@IETF.ORG; Sat, 26 Feb 2005 11:49: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 <5.00FB5008@cherry.ease.lsoft.com>; Sat, 26 Feb 2005 11:49:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59499160 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 11:49:29 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 26 Feb 2005 11:49:29 -0500 Received: from [69.170.19.42] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9357924 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 11:49:28 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0462C94F@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050226114808.02dd4150@localhost> Date: Sat, 26 Feb 2005 11:49:13 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0462C94F@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed If the assumption is that redirected packets are carried within a PL header, and that PL header carries packet type and redirect reason information, then I would agree that there ought to be no need for an additional TML shim. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 26 11:52: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 LAA15769 for ; Sat, 26 Feb 2005 11:52:05 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D55B9-00078E-8w for forces-archive@IETF.ORG; Sat, 26 Feb 2005 11:52: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 <1.00FB50DA@cherry.ease.lsoft.com>; Sat, 26 Feb 2005 11:52:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59499249 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 11:52:06 -0500 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 26 Feb 2005 11:52:06 -0500 Received: from [69.170.19.42] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 9357948; Sat, 26 Feb 2005 11:52:02 -0500 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050226114235.02df4bd8@localhost> Date: Sat, 26 Feb 2005 11:51:50 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d I have a concern about accepting this document as a working group document. In addition to defining a controlled object (an LFB class), this document defines a whole new protocol for discovery. The IETF arguably has too many discovery protocols all ready. Heck, we just chartered a working group for another one. Further, it would seem to me that any discovery protocol ought to be able to discover the FE neighbors whether they are parts of the same ForCES NE, part of a different ForCES NE, or part of some other kind of device. Hence, defining such a discovery protocol seems out of scope for ForCES. Defining / requesting additions to existing discovery protocols may make sense. At the very least, if we are going to invent yet another discovery protocol, we need to state that we know about the existing set of tools, and explain why they are not sufficient. And for me, I would need to see and buy into such an explanation before I would be comfortable with this as a working group document. Yours, Joel At 10:15 PM 2/25/2005, Putzolu, David wrote: >All, > >draft-ansari-forces-discovery-01.txt has been proposed >as a working group document. This draft defines a >controlled objects (aka LFB) as mentioned in the >following charter deliverable: > >o A formal definition of the controlled objects in the > functional model of a forwarding element. This > includes IP forwarding, IntServ and DiffServ QoS. An > existing specification language shall be used for > this task. > >We would like to request that WG participants please >review this draft and provide feedback as to whether >it should be accepted as a WG document. Acceptance as >a WG document means that the WG participants have read >the document, approve of the concept and general approach, >and believe it is ready to form the basis of a solution >to the problem the document addresses, and is within the >WG charter. It does not require that the document be in >a final form or be 100% correct. > >Document URL: >http://www.ietf.org/internet-drafts/draft-ansari-forces-discovery-01.txt > >All feedback should be provided either via email to the >WG list or in the upcoming WG meeting in Minneapolis. > >Thanks, >David and Patrick > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Furquan Ansari > > Sent: Thursday, February 24, 2005 10:51 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] Model comments: FE Object and FE topology > > > > Folks, > > As part of the discussion that Jamal has brought up, I would > > request the WG members to read the draft on topology > > discovery - i.e. draft-ansari-forces-discovery-01.txt that > > was submitted > > at the last IETF and provide any feedback. Since many WG > > members had not > > read the draft the last time, a decision on making it a WG > > item couldn't > > be made. I hope that decision can be made at this time. > > > > Thanks, > > > > > > Jamal Hadi Salim wrote: > > > > >Folks, > > > > > >I wish to reopen the discussion on the FE topology mostly > > given light of > > >newer developments such as working towards making > > >draft-ansari-forces-discovery-01.txt a WG item (as discussed in last > > >meeting). > > >Besides that i do believe that FEConfiguredNeighborType violates the > > >simple rules we have imposed on separation (unnecessarily if > > i may add). > > > > > >The FEObjects view of the neighbor at the moment is a little too > > >intrusive. It tries to aggregate things that are found in a few other > > >LFBs within this single spot (ARP, etc) when there is no > > need to do so. > > >If we need to lookup an IP to address mapping surely that > > would be ARP > > >LFBs job. If we are to have static entries mapping the two, then that > > >still belongs to the ARP LFB. Ok, worst case create a "static > > >configuration LFB" (although static config files should do > > just fine). > > >I dont expect a human (other than a developer) to be looking at this > > >LFBs details. I do expect tools to look at this LFB for the > > purpose of > > >gathering and correlating info about an FE and its neighbors but they > > >woul be looking at a lot more LFBs. > > >i.e there is no point in breaking the rules just for this one thing. > > > > > >Additionaly: > > >FEConfiguredNeighborType also asumes MAC addresses and IP > > addresses as > > >the underlying connection for the Neighbor. This is bad. > > >I do expect we will see various technologies interconnecting FEs > > >(anywhere from sockets, ethernet, ethernet VLANS, CSIX, SPI-X to > > >PCI-Express AS- switches.) > > > > > >My suggestion: > > > > > >The most meaningful things to show that will suffice for all > > >configuration is: > > > > > >- Neighbors FEID > > >- The interface of the above neighbor > > >- FE's interface that connects to this neighbor > > > > > >Even the above maybe intrusive, but make less assumptions. > > >Any other information should be accessible elsewhere. You oughta know > > >where to find it because it is documented in LFB definitions. > > > > > >cheers, > > >jamal > > > > > > > > > > -- > > Furquan Ansari > > Bell Labs Research Ph : 732-949-5249 > > Holmdel, NJ Fax: 732-949-4556 > > From owner-forces@PEACH.EASE.LSOFT.COM Sat Feb 26 12:46: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 MAA19149 for ; Sat, 26 Feb 2005 12:46:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D561z-00085c-32 for forces-archive@IETF.ORG; Sat, 26 Feb 2005 12:47: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 <7.00FB51E6@cherry.ease.lsoft.com>; Sat, 26 Feb 2005 12:46:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59507634 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 26 Feb 2005 12:46:28 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 26 Feb 2005 12:46:24 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022609470915:3838 ; Sat, 26 Feb 2005 09:47:09 -0800 References: <6.2.1.2.0.20050226114235.02df4bd8@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 02/26/2005 09:47:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/26/2005 09:47:11 AM, Serialize complete at 02/26/2005 09:47:11 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109439980.1917.51.camel@jzny.localdomain> Date: Sat, 26 Feb 2005 12:46:21 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050226114235.02df4bd8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 11:51, Joel M. Halpern wrote: > I have a concern about accepting this document as a working group document. > In addition to defining a controlled object (an LFB class), this document > defines a whole new protocol for discovery. > The IETF arguably has too many discovery protocols all ready. > Heck, we just chartered a working group for another one. Yes, but thats not good reasoning. Let me list even more for you: - Cisco has CDP (Cisco Discovery Protocol); - Extreme Networks has EDP (Extreme Discovery Protocol) - Enterasys Networks has yet another CDP (Cabletron Discovery Protocol); - Nortel Networks has NDP (Nortel Discovery Protocol). - and every other chip vendor i have seen has one too - etc And of course none of them work with each other although most do the same concepts in different ways. I assure you that every vendor building some distributed box that i didnt list above has one as well. And if you want to go to the heck direction, heck the IEEE is also working on one as well (off top of my head its called 802.1ab and is based on CISCO CDP and UDLD iirc). But again, thats beside the point ... The point is we need some very lightweight FE neighbor discovery that is not going to be mandated to implement. If Nortel wishes to continue using NDP. so be it. If some fool wishes to run OSPF to do such discovery, so be it. If i wish to just write a tool to do configs of neighbors on the CLI to achieve that goal, so be it. > > Further, it would seem to me that any discovery protocol ought to be able > to discover the FE neighbors whether they are parts of the same ForCES NE, > part of a different ForCES NE, or part of some other kind of > device. No Joel: this is very speacial purpose and works only within the constraints of an NE. This is design intent to cut the fat. The CE instructs the FE where to go find neighbors. The CE could have found the FEs neighbors and told it. As an optimization, the CE offloads some of that funtionality to the FE. We have agreed to allow offloading of LFBs to the FE (i think the example listed in the drafts is that of offloading OSPF hellos to the FE). This optimization is no different from just that. > Hence, defining such a discovery protocol seems out of scope for > ForCES. Defining / requesting additions to existing discovery protocols > may make sense. > I cant think of one protocol that we could ask extensions for that would not be both heavyweight (implementing the 1000 other features we dont need). I can write and test the code for this protocol (once a Forces framework exists) in a day or two and i consider myself an average programmer. > At the very least, if we are going to invent yet another discovery > protocol, we need to state that we know about the existing set of tools, > and explain why they are not sufficient. And for me, I would need to see > and buy into such an explanation before I would be comfortable with this as > a working group document. > I think this is a fair request. I have listed some of these motivations above; but we need to be more explicit. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 27 18:13:02 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 SAA13932 for ; Sun, 27 Feb 2005 18:13:02 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5XbX-00083U-F1 for forces-archive@IETF.ORG; Sun, 27 Feb 2005 18:13: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 <8.00FB6B27@cherry.ease.lsoft.com>; 27 Feb 2005 18:12:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59626314 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 18:12:56 -0500 Received: from 137.222.10.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Feb 2005 18:12:56 -0500 Received: from ncsb.bris.ac.uk ([137.222.10.100]) by dirg.bris.ac.uk with esmtp (Exim 4.50) id 1D5Xan-0002yG-MU for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 23:12:55 +0000 Received: from s86-17.nomadic.bris.ac.uk ([137.222.86.17] helo=een9174.een.bris.ac.uk) by ncsb.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1D5Xan-0001es-Ct for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 23:12:53 +0000 References: Originator-Info: login-token=Mulberry:01mo9TdP/0tOjS0MzeyAD1gN3S8cmX2gwFgdbX+cyYyP29yN8=; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.8 X-Spam-Level: -- Approved-By: Alistair Munro Message-ID: <620139F47DFC349B6E2D60FE@[192.168.0.3]> Date: Sun, 27 Feb 2005 23:12:51 +0000 Reply-To: Alistair Munro Sender: Forwarding and Control Element Separation From: Alistair Munro Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi All, I support adopting this document as a WG draft so that it is properly discussed. The functions are useful even if the protocol may be redundant when the multitude of other discovery protocols are properly taken into account. If there are genuine competitors then it is a debate that is worth having. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 27 22:32: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 WAA03328 for ; Sun, 27 Feb 2005 22:32:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5bey-0003s7-7m for forces-archive@IETF.ORG; Sun, 27 Feb 2005 22:33: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 <22.00FB6F3F@cherry.ease.lsoft.com>; 27 Feb 2005 22:32:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59636379 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 22:32:44 -0500 Received: from 192.215.81.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Feb 2005 22:32:43 -0500 Received: from JMHLap3.stevecrocker.com (353hosta70.starwoodbroadband.com [12.108.86.70]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id j1S3Wel00661 for ; Mon, 28 Feb 2005 03:32:43 GMT X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <620139F47DFC349B6E2D60FE@[192.168.0.3]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050227222847.02c55920@localhost> Date: Sun, 27 Feb 2005 22:32:35 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <620139F47DFC349B6E2D60FE@[192.168.0.3]> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b We should determine that there is a problem, and that we need to solve it, before adopting as a work item for the working group a specific solution. I would be interested in seeing a draft that outlined what problem needed to be solved, why the many existing solutions among themselves did not provide sufficient coverage, and what properties a solution might need to have. It does not need to be a full "requirements" document. It could also be that we have extended email and face to face discussion of the problem, conclude it really needs to be addressed without a problem-oriented ID, and then see what we want to do about solutions. But adopting a solution document as a working group work item is not the way to decide if there is a problem to be solved. Yours, Joel M. Halpern At 06:12 PM 2/27/2005, Alistair Munro wrote: >Hi All, > >I support adopting this document as a WG draft so that it is properly >discussed. The functions are useful even if the protocol may be redundant >when the multitude of other discovery protocols are properly taken into >account. If there are genuine competitors then it is a debate that is >worth having. > >Regards, > >Alistair > >-- >Alistair Munro, >Principal Engineer, U4EA Technologies Ltd. >City Point, Temple Gate, Bristol, BS1 6PL, U.K. >E-mail: Alistair.Munro@u4eatech.com >Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) >+44-7974-922-442; >Fax: +44-117-373-6751 >Web: http://www.u4eatech.com From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 27 22:47: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 WAA04266 for ; Sun, 27 Feb 2005 22:47:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5btT-00045c-LL for forces-archive@IETF.ORG; Sun, 27 Feb 2005 22:48: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 <10.00FB701C@cherry.ease.lsoft.com>; 27 Feb 2005 22:47:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59636972 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 22:47:43 -0500 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Feb 2005 22:47: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 j1S3le9n013732; Mon, 28 Feb 2005 03:47:40 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 j1S3lb7D012664; Mon, 28 Feb 2005 03:47:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022719474026258 ; Sun, 27 Feb 2005 19:47:40 -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); Sun, 27 Feb 2005 19:47:40 -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] WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? Thread-Index: AcUdRi7XBi7JFczCQWySaZQYLWCDIgAAK0cw X-OriginalArrivalTime: 28 Feb 2005 03:47:40.0473 (UTC) FILETIME=[405EC290:01C51D48] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> Date: Sun, 27 Feb 2005 19:47:40 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Joel, I think it is fine to have this discussion via email. Jamal has already started this via a detailed email on some of the existing solutions. I wouldn't go to the extent of having another draft to define the problem, requirements, etc...some of this should be already covered in our draft. When we started working on this draft, we did some research in this space and found that.. yes there are several protocols out there for topology discovery as you suggest. However, there is no existing protocol that would work well for our framework. However, if you have something in mind pls feel to share it with us. You had previously suggested BFD but unfortunately this doesn't meet all our requirements. regards Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern We should determine that there is a problem, and that we need to solve it,=20 before adopting as a work item for the working group a specific=20 solution. I would be interested in seeing a draft that outlined what=20 problem needed to be solved, why the many existing solutions among=20 themselves did not provide sufficient coverage, and what properties a=20 solution might need to have. It does not need to be a full "requirements"=20 document. It could also be that we have extended email and face to face discussion of=20 the problem, conclude it really needs to be addressed without a=20 problem-oriented ID, and then see what we want to do about solutions. But adopting a solution document as a working group work item is not the way to decide if there is a problem to be solved. Yours, Joel M. Halpern At 06:12 PM 2/27/2005, Alistair Munro wrote: >Hi All, > >I support adopting this document as a WG draft so that it is properly=20 >discussed. The functions are useful even if the protocol may be redundant=20 >when the multitude of other discovery protocols are properly taken into >account. If there are genuine competitors then it is a debate that is=20 >worth having. > >Regards, > >Alistair > From owner-forces@PEACH.EASE.LSOFT.COM Sun Feb 27 23:28: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 XAA07684 for ; Sun, 27 Feb 2005 23:28:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5cX8-0004p2-Gl for forces-archive@IETF.ORG; Sun, 27 Feb 2005 23:29: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 <7.00FB7288@cherry.ease.lsoft.com>; 27 Feb 2005 23:28:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59640038 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 27 Feb 2005 23:28:42 -0500 Received: from 192.215.81.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Feb 2005 23:28:42 -0500 Received: from JMHLap3.stevecrocker.com (353hosta70.starwoodbroadband.com [12.108.86.70]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id j1S4Sfl16560 for ; Mon, 28 Feb 2005 04:28:41 GMT X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050227232538.02cb14b8@localhost> Date: Sun, 27 Feb 2005 23:28:36 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Can you describe some of the requirements, and the situations in which they apply? I imagine there is some reason why simply routing protocol neighbor discovery is not sufficient, but I can not divine the shortfall. (I suspect that there is some case where a CE is responsbile for forwarding packets through FEs, but is not running routing protocols. But I can not quite determine what it is.) I presume that there are also other goals. Yours, Joel At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: >Joel, > >I think it is fine to have this discussion via email. Jamal has already >started this via a detailed email on some of the existing solutions. I >wouldn't go to the extent of having another draft to define the problem, >requirements, etc...some of this should be already covered in our draft. > >When we started working on this draft, we did some research in this >space and found that.. yes there are several protocols out there for >topology discovery as you suggest. However, there is no existing >protocol that would work well for our framework. However, if you have >something in mind pls feel to share it with us. You had previously >suggested BFD but unfortunately this doesn't meet all our requirements. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >We should determine that there is a problem, and that we need to solve >it, >before adopting as a work item for the working group a specific >solution. I would be interested in seeing a draft that outlined what >problem needed to be solved, why the many existing solutions among >themselves did not provide sufficient coverage, and what properties a >solution might need to have. It does not need to be a full >"requirements" >document. > >It could also be that we have extended email and face to face discussion >of >the problem, conclude it really needs to be addressed without a >problem-oriented ID, and then see what we want to do about solutions. > >But adopting a solution document as a working group work item is not the > >way to decide if there is a problem to be solved. > >Yours, >Joel M. Halpern > >At 06:12 PM 2/27/2005, Alistair Munro wrote: > >Hi All, > > > >I support adopting this document as a WG draft so that it is properly > >discussed. The functions are useful even if the protocol may be >redundant > >when the multitude of other discovery protocols are properly taken into > > >account. If there are genuine competitors then it is a debate that is > >worth having. > > > >Regards, > > > >Alistair > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 07:24: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 HAA12560 for ; Mon, 28 Feb 2005 07:24:28 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5jxa-0005bU-Qa for forces-archive@IETF.ORG; Mon, 28 Feb 2005 07: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 <14.00FB7AFC@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 7:24:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59695019 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 07:24:26 -0500 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 07:24:25 -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 j1SCOLiK225612 for ; Mon, 28 Feb 2005 12:24:21 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1SCOLer088740 for ; Mon, 28 Feb 2005 12:24:21 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1SCOKke017828 for ; Mon, 28 Feb 2005 12:24:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j1SCOKXm017825; Mon, 28 Feb 2005 12:24:20 GMT Received: from [127.0.0.1] (dhcp69-80.zurich.ibm.com [9.4.69.80]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA101718; Mon, 28 Feb 2005 13:24:19 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090909090208010406040604" Approved-By: Patrick Droz Message-ID: <42230CFA.6050401@zurich.ibm.com> Date: Mon, 28 Feb 2005 13:22:18 +0100 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: IETF62 ForCES Agenda Comments: To: agenda@ietf.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a cryptographically signed message in MIME format. --------------ms090909090208010406040604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Monday, March 7, 2005, 9:00-11:30 ================================= CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 15 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 15 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Shuchi Chawla draft-khosravi-forces-tcptml-01.txt 30 min - ForCES Protocol Draft Status & Changes Avri Doria or Jamal Salim draft-forces-protocol-02.txt (Updated February 28, 2005) --------------ms090909090208010406040604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAyMjgx MjIyMThaMCMGCSqGSIb3DQEJBDEWBBRPO+u/JjE5a2NmgroGbPaXPL/q2zBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgBKm899xJnaVXMF7auoa0YiNpVRe56P6wxpS DGiFk7IaJszQDQ1uhqxzo1sek5UFOdpT9v2I15u+RsRfZtzRNqOBoiQ61anbq+A57YAMj75E fuTPIK2kIV/IGINSRz7LXbQRRYmVd2X5KfQDYuO8re/zgtOqNHfH1MyekQ2e7krbAAAAAAAA --------------ms090909090208010406040604-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 08:32: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 IAA19040 for ; Mon, 28 Feb 2005 08:32:57 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5l1m-000772-55 for forces-archive@IETF.ORG; Mon, 28 Feb 2005 08: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 <23.00FB7D33@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 8:01:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59704777 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 08:01:02 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 08:01:02 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005022805014500:4909 ; Mon, 28 Feb 2005 05:01:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@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 02/28/2005 05:01:45 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/28/2005 05:01:47 AM, Serialize complete at 02/28/2005 05:01:47 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109595658.1917.959.camel@jzny.localdomain> Date: Mon, 28 Feb 2005 08:00:58 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050227232538.02cb14b8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Joel, I think the need is clearly there[1] - it just needs to be elucidated more eloquently. This will make the draft stronger. Can you list some protocols you would like to see compared against? As pointed by Hormuzd, BFD was one you have mentioned in the past. Did i just hear you say standard routing protocols like OSPF? BTW, just to be clear: I am for Extreme to continue using EDP if they wish to do so in a Forces environment, they just need to be updating some of the generic fields in the FE Object (the email i posted earlier). Same with any other vendor using some proprietary scheme or even a routing protocol. cheers, jamal [1] Otherwise all those other vendors i listed earlier would never have written those discovery protocols or would have used something standard. On Sun, 2005-02-27 at 23:28, Joel M. Halpern wrote: > Can you describe some of the requirements, and the situations in which they > apply? > > I imagine there is some reason why simply routing protocol neighbor > discovery is not sufficient, but I can not divine the shortfall. (I > suspect that there is some case where a CE is responsbile for forwarding > packets through FEs, but is not running routing protocols. But I can not > quite determine what it is.) > > I presume that there are also other goals. > > Yours, > Joel > > At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I think it is fine to have this discussion via email. Jamal has already > >started this via a detailed email on some of the existing solutions. I > >wouldn't go to the extent of having another draft to define the problem, > >requirements, etc...some of this should be already covered in our draft. > > > >When we started working on this draft, we did some research in this > >space and found that.. yes there are several protocols out there for > >topology discovery as you suggest. However, there is no existing > >protocol that would work well for our framework. However, if you have > >something in mind pls feel to share it with us. You had previously > >suggested BFD but unfortunately this doesn't meet all our requirements. > > > >regards > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > > >We should determine that there is a problem, and that we need to solve > >it, > >before adopting as a work item for the working group a specific > >solution. I would be interested in seeing a draft that outlined what > >problem needed to be solved, why the many existing solutions among > >themselves did not provide sufficient coverage, and what properties a > >solution might need to have. It does not need to be a full > >"requirements" > >document. > > > >It could also be that we have extended email and face to face discussion > >of > >the problem, conclude it really needs to be addressed without a > >problem-oriented ID, and then see what we want to do about solutions. > > > >But adopting a solution document as a working group work item is not the > > > >way to decide if there is a problem to be solved. > > > >Yours, > >Joel M. Halpern > > > >At 06:12 PM 2/27/2005, Alistair Munro wrote: > > >Hi All, > > > > > >I support adopting this document as a WG draft so that it is properly > > >discussed. The functions are useful even if the protocol may be > >redundant > > >when the multitude of other discovery protocols are properly taken into > > > > >account. If there are genuine competitors then it is a debate that is > > >worth having. > > > > > >Regards, > > > > > >Alistair > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 11:48: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 LAA07841 for ; Mon, 28 Feb 2005 11:48:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5o5O-0002p4-IC for forces-archive@IETF.ORG; Mon, 28 Feb 2005 11:49: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 <20.00FB808B@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 11:48:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59736636 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 11:48:43 -0500 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 11:48:43 -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 j1SGmgl7014395 for ; Mon, 28 Feb 2005 16:48:42 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) 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 j1SGm8E8021442 for ; Mon, 28 Feb 2005 16:48:42 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022808484225804 for ; Mon, 28 Feb 2005 08:48:42 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 08:48:42 -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: I-D ACTION:draft-khosravi-forces-tcptml-01.txt Thread-Index: AcUba8pZMy9AN2GlQTOjg2Tmqr+gjACSRuAg X-OriginalArrivalTime: 28 Feb 2005 16:48:42.0346 (UTC) FILETIME=[5C391CA0:01C51DB5] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Chawla, Shuchi" Message-ID: <85514027246E4643A1B0780EC0F6F45801F83D7F@orsmsx410> Date: Mon, 28 Feb 2005 08:48:39 -0800 Reply-To: "Chawla, Shuchi" Sender: Forwarding and Control Element Separation From: "Chawla, Shuchi" Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Jamal, Thanks for the feedback on the draft. Comments below: TML Header (or lack thereof) ---------------------------- I concur that it would simplify the protocol to not require a TML header. However, before we make that decision, I think we would want to make sure we have covered ground with respect to all of the communication that may be required between TML peers. We had identified 4 messages so far in this version of the draft:=20 - 2 multicast support related messages - 1 heartbeat related message - 1 channel closure related message Of these, the first three have been addressed in some form in these discussions. As we detail the protocol further, there may be other messages that may come up - so we would need to ensure that all of these messages can either be eliminated or dealt with in some other manner. So, I just feel that this needs some more analysis. Separate Peer TML Control Channel=20 --------------------------------- If we do require peer TML communication, in my opinion the use of a separate communication channel for TML messaging is likely to complicate the situation - in effect, this implies the setup/use of a "control channel for a control channel". I have not thought about all of the implications, but here are some areas that the protocol would likely need to address: - What if one control channel comes up and the other doesn't? - Guaranteeing message sequencing between these two control channels may become more problematic - The TML Layer even with this separate channel needs the ability to handle two types of messages: o Those with a TML layer header received over the TML-TML control channel o Those without a TML layer header received over the PL-PL control channel TML Versioning -------------- Not having a TML Layer header would imply that the TML Layer does not have a version associated with it. Is there any other place the TML version may be embedded? If not, it would imply that changes may not be made to the TML Layer separate from the PL Layer since any change that might impact interoperability or modify the layer's behavior would need to be reflected in the protocol version. Since there are multiple TMLs that are likely to exist, but a single PL, it would seem prudent that TML changes be versioned independent of the PL Layer. How would this be achieved? PL Layer knowledge of (Two) Channels ------------------------------------ I haven't thought about this deeply, but here are my initial thoughts: As long as the TML Layer is only responsible for "transport" and is not a decision-maker, I think the PL Layer (or someone other than the TML Layer) should have knowledge of the channels being setup. This will especially be required to handle failure cases. If the TML Layer is indeed the only entity aware of this, then it seems that in order to deal with failure cases, the TML Layer would need to take charge, and in that case, there may actually be more messaging required between peer TMLs. Also, we haven't addressed HA in detail this draft. I think some of the decisions we make will need to take into account HA requirements - it is hard to architect HA in at a later stage. Regards, Shuchi -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, February 25, 2005 10:57 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt I finaly had the chance to scan the draft.=20 Some comments - also sharing our implementation experience of a TCP TML. 1) TML<->TML interface. You dont need a protocol other than TCP or any additional headers - the TCP headers should be sufficient - the TCP header is sufficient. We actually started with the scheme described in the draft i.e a little shim header and an additional control protocol.=20 Eventually we found the only reason we needed the headers or the little protocol was for multicast/replicast joining/leaving given TCP is unicast only. Any other need can be achieved via standard TCP features.=20 To simplify, we evolved towards having a separate inter-TML control channel. This channel never carries PL messages. All it does at the moment is carry the replicast join/leave state setup/teardown. This is where our implementation sits right now. We have now reached a conclusion that theres no need even for this extra channel for multicast [1].=20 I think there maybe other TMLs that may require coordination and their own protocol (such as TIPC which runs over ethernet or directly over a fabric). In the case you are running over IP and another transport such as TCP, it makes sense to reuse the services they offer. 2)PL<->TML interface. The fact that a TCP TML has two channels being passed and that such knowledge is controlled by and embedded to the PL will complicate things. The configuration of the two channels is up to the C/FEM IMO. This knowledge should be oblivious to the PL - if you want simplicty that is. 3) I am begining to worry a little about the redirection channel.=20 Enforcing that all redirected messages have to have a PL header attached to them would become problematic. Theres a gazillion ways that packets could be redirected and most of the time dependent on hardware capability. For example our existing hardware could redirect packets and put extra VLAN tags on them; other much simpler schemes would simply redirect raw packets (OSPF for example) based on the addresses. I think we may need to rediscuss this in the context of the protocol (dont wanna drag on this context because i will end up distracting the topic).=20 cheers, jamal [1] If we assume that the FE multicast PIDs belong to the FE Object (theres a very good fit) then subscription can happen at the PL FE Object level. This needs discusssion; however, upon receiving such a message, the FE PL layer makes a local API call to add the multicast group to the TML. All this local API call does is to tell the TML "Add this to my list of legit IDs". Like i said above this still needs discussion. From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 11:50: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 LAA08285 for ; Mon, 28 Feb 2005 11:50:40 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5o7H-0002tT-Fa for forces-archive@IETF.ORG; Mon, 28 Feb 2005 11:51: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 <6.00FB81C8@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 11:50:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59736714 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 11:50:40 -0500 Received: from 204.178.16.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 11:50:40 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1SGoeXJ065544 for ; Mon, 28 Feb 2005 11:50:40 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SGoZ7d098946 for ; Mon, 28 Feb 2005 11:50:35 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SGoYoC006504 for ; Mon, 28 Feb 2005 11:50:34 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0462C94F@orsmsx408> <6.2.1.2.0.20050226114808.02dd4150@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <42234B33.4040405@lucent.com> Date: Mon, 28 Feb 2005 11:47:47 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Joel, Sorry, didn't see all this activity over the weekend..just catching up on my emails. Yes, the assumption is in fact that all redirected packets are indeed carried within a PL header - which will carry the type and length fields within it. That's the reason why we mention in the draft that if the TML shim header exists, the length field there only corresponds to the length of the TML message and not the entire payload length. Thanks, Joel M. Halpern wrote: > If the assumption is that redirected packets are carried within a PL > header, and that PL header carries packet type and redirect reason > information, then I would agree that there ought to be no need for an > additional TML shim. > > Yours, > Joel -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 12:04:02 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 MAA09612 for ; Mon, 28 Feb 2005 12:04:02 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oKC-0003Dl-U4 for forces-archive@IETF.ORG; Mon, 28 Feb 2005 12:04: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 <14.00FB80B2@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 12:04:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59738829 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 12:03:59 -0500 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 12:03:59 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1SH3s1O077075 for ; Mon, 28 Feb 2005 12:03:58 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SH3n7d099243 for ; Mon, 28 Feb 2005 12:03:49 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SH3moC007192 for ; Mon, 28 Feb 2005 12:03:49 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <42234E4E.3070204@lucent.com> Date: Mon, 28 Feb 2005 12:01:02 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Joel, As jamal already pointed out this is meant to be within a NE boundary and not span NE. The reason why an existing routing protocol neighbor discovery would not be sufficient is because, the routing protocol may/will not be running over internal links (imagine that there is a network of FEs internconnected and belong to the same NE - only FEs that connect to FEs of other NEs need to have the routing protocol like OSPF enabled.) An alternate would be to run a separate instance of the routing protocol "only" within the NE for neighbor discovery purposes - but this seems like an overkill for the solution we want. Further, the interconnection between the FEs within the NE may not necessarily be IP - in which case you may not be able to run IP routing protocols. Thanks, Joel M. Halpern wrote: > Can you describe some of the requirements, and the situations in which > they apply? > > I imagine there is some reason why simply routing protocol neighbor > discovery is not sufficient, but I can not divine the shortfall. (I > suspect that there is some case where a CE is responsbile for > forwarding packets through FEs, but is not running routing protocols. > But I can not quite determine what it is.) > > I presume that there are also other goals. > > Yours, > Joel > > At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: > >> Joel, >> >> I think it is fine to have this discussion via email. Jamal has already >> started this via a detailed email on some of the existing solutions. I >> wouldn't go to the extent of having another draft to define the problem, >> requirements, etc...some of this should be already covered in our draft. >> >> When we started working on this draft, we did some research in this >> space and found that.. yes there are several protocols out there for >> topology discovery as you suggest. However, there is no existing >> protocol that would work well for our framework. However, if you have >> something in mind pls feel to share it with us. You had previously >> suggested BFD but unfortunately this doesn't meet all our requirements. >> >> regards >> Hormuzd >> >> -----Original Message----- >> From: Forwarding and Control Element Separation >> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >> >> We should determine that there is a problem, and that we need to solve >> it, >> before adopting as a work item for the working group a specific >> solution. I would be interested in seeing a draft that outlined what >> problem needed to be solved, why the many existing solutions among >> themselves did not provide sufficient coverage, and what properties a >> solution might need to have. It does not need to be a full >> "requirements" >> document. >> >> It could also be that we have extended email and face to face discussion >> of >> the problem, conclude it really needs to be addressed without a >> problem-oriented ID, and then see what we want to do about solutions. >> >> But adopting a solution document as a working group work item is not the >> >> way to decide if there is a problem to be solved. >> >> Yours, >> Joel M. Halpern >> >> At 06:12 PM 2/27/2005, Alistair Munro wrote: >> >Hi All, >> > >> >I support adopting this document as a WG draft so that it is properly >> >discussed. The functions are useful even if the protocol may be >> redundant >> >when the multitude of other discovery protocols are properly taken into >> >> >account. If there are genuine competitors then it is a debate that is >> >worth having. >> > >> >Regards, >> > >> >Alistair >> > > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 12:43: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 MAA14590 for ; Mon, 28 Feb 2005 12:43:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5owr-0004GW-Rn for forces-archive@IETF.ORG; Mon, 28 Feb 2005 12:44: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 <9.00FB81B4@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 12:43:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59743469 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 12:43:58 -0500 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 12:43: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 2005022809444155:5188 ; Mon, 28 Feb 2005 09:44:41 -0800 References: <85514027246E4643A1B0780EC0F6F45801F83D7F@orsmsx410> 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 02/28/2005 09:44:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 02/28/2005 09:44:43 AM, Serialize complete at 02/28/2005 09:44:43 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1109612634.1072.95.camel@jzny.localdomain> Date: Mon, 28 Feb 2005 12:43:55 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <85514027246E4643A1B0780EC0F6F45801F83D7F@orsmsx410> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Hi Shuchi, On Mon, 2005-02-28 at 11:48, Chawla, Shuchi wrote: > Jamal, > > Thanks for the feedback on the draft. Comments below: > > TML Header (or lack thereof) > ---------------------------- > I concur that it would simplify the protocol to not require a TML > header. However, before we make that decision, I think we would want to > make sure we have covered ground with respect to all of the > communication that may be required between TML peers. A reasonable thing to do > We had identified > 4 messages so far in this version of the draft: I am gonna assume TCP - which is in the context of this draft. > - 2 multicast support related messages I described the scheme in earlier email in response to Furquan - involve the FE Object and have the multicast be a PL/FE Object config/subscription issue. > - 1 heartbeat related message use TCP KEEPALIVE; > - 1 channel closure related message EOF is returned when a TCP connection is closed > Of these, the first three have been addressed in some form in these > discussions. As we detail the protocol further, there may be other > messages that may come up - so we would need to ensure that all of these > messages can either be eliminated or dealt with in some other manner. > So, I just feel that this needs some more analysis. > Refer to what i said above. We are lucky to have implemented along the lines of what you propose (refer to the history i gave earlier)- that helped shape my views. > Separate Peer TML Control Channel > --------------------------------- > If we do require peer TML communication, in my opinion the use of a > separate communication channel for TML messaging is likely to complicate > the situation - in effect, this implies the setup/use of a "control > channel for a control channel". I have not thought about all of the > implications, but here are some areas that the protocol would likely > need to address: > - What if one control channel comes up and the other doesn't? > - Guaranteeing message sequencing between these two control channels may > become more problematic > - The TML Layer even with this separate channel needs the ability to > handle two types of messages: > o Those with a TML layer header received over the TML-TML > control channel > o Those without a TML layer header received over the PL-PL > control channel In context of TCP - I would say kill this peer TML relationship. I probably wouldnt say the same for TIPC. > TML Versioning > -------------- > Not having a TML Layer header would imply that the TML Layer does not > have a version associated with it. Is there any other place the TML > version may be embedded? If not, it would imply that changes may not be > made to the TML Layer separate from the PL Layer since any change that > might impact interoperability or modify the layer's behavior would need > to be reflected in the protocol version. Since there are multiple TMLs > that are likely to exist, but a single PL, it would seem prudent that > TML changes be versioned independent of the PL Layer. How would this be > achieved? > I see versioning as useful in the case where you have a shim header. Any other case - the versioning is how code is implemented; and if not I would say this is a C/FEM config interface issue. If someone wants to have CEM<->FEM communication they could do that; i would till think of it mostly as a config of the TML. > PL Layer knowledge of (Two) Channels > ------------------------------------ > I haven't thought about this deeply, but here are my initial thoughts: > As long as the TML Layer is only responsible for "transport" and is not > a decision-maker, I think the PL Layer (or someone other than the TML > Layer) should have knowledge of the channels being setup. This will > especially be required to handle failure cases. If the TML Layer is > indeed the only entity aware of this, then it seems that in order to > deal with failure cases, the TML Layer would need to take charge, and in > that case, there may actually be more messaging required between peer > TMLs. > My view is that the PL should only worry about Forces Level messaging i.e treat the TML as a black box; a wire if you may. It just sends things down and they get to its peers. The PL may "boot" the TML - but thats about as much control it has over it. Remember: in a PL<->TML interface, open() does not necessarily equate to a TCP socket open() - it doesnt in our case. It just means you are connected to the TML. > Also, we haven't addressed HA in detail this draft. I think some of the > decisions we make will need to take into account HA requirements - it is > hard to architect HA in at a later stage. I think we are there - whats missing is the details. Two levels of HA: 1) Transport - this is where TML is responsible. Its one layer below the PL. If a physical link goes down or a socket dies then TML takes necessary action to recover. If absolutely no possibility of such recovery (eg when a CE or FE dies) then the PL layer needs to be involved. If you remove the relationship of knowledge of how many transport connections actually exist from the PL level - this becomes more a TML module worry and becomes specific to the hardware in which the TCP TML was implemented on. 2) a FE or CE PL. connection to the peer level is down. This is the responsibility of the PL. If a CE disappears, then its clear the FE needs to kick in the HA rules it has and either choose another CE or hibernate until current one comes back (we discuss a few of these schemes in the draft - may need some reviewing). This is clearly a PL module worry. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 13:49: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 NAA21294 for ; Mon, 28 Feb 2005 13:49:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pyR-0005sU-Vc for forces-archive@IETF.ORG; Mon, 28 Feb 2005 13:50: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 <4.00FB8400@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 13:49:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59749327 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 13:49:36 -0500 Received: from 192.215.81.77 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 13:49:35 -0500 Received: from JMHLap3.stevecrocker.com (353hosta70.starwoodbroadband.com [12.108.86.70]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id j1SInV920908 for ; Mon, 28 Feb 2005 18:49:33 GMT X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@localhost> <42234E4E.3070204@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050228134621.02e03350@localhost> Date: Mon, 28 Feb 2005 13:49:24 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42234E4E.3070204@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 I would agree that running a separate instance of the routing protocol within the FE would be undesirable. However, the CE could send routing protocol hellos through all the interfaces, and receive routing protocol hellos through all the interfaces. It could then sensibly decide that hello maintenance is all it needs on any adjacency for which it is both sides. (Note, a normal router with two physical interfaces on the same subnet has to do this anyway.) This works if the interface is shared with elements not within the NE, and works if the interface is dedicated to the NE. It requires no new protocols. There may be requirements it does not meet. But we should articulate those and agree on the relevance of such requirements. Yours, Joel At 12:01 PM 2/28/2005, Furquan Ansari wrote: >Joel, > As jamal already pointed out this is meant to be within a NE boundary > and not span NE. The reason why an >existing routing protocol neighbor discovery would not be sufficient is >because, the routing protocol may/will >not be running over internal links (imagine that there is a network of FEs >internconnected and belong to the same >NE - only FEs that connect to FEs of other NEs need to have the routing >protocol like OSPF enabled.) >An alternate would be to run a separate instance of the routing protocol >"only" within the NE for neighbor discovery >purposes - but this seems like an overkill for the solution we want. >Further, the interconnection between the >FEs within the NE may not necessarily be IP - in which case you may not be >able to run IP routing protocols. > > >Thanks, > >Joel M. Halpern wrote: > >>Can you describe some of the requirements, and the situations in which >>they apply? >> >>I imagine there is some reason why simply routing protocol neighbor >>discovery is not sufficient, but I can not divine the shortfall. (I >>suspect that there is some case where a CE is responsbile for forwarding >>packets through FEs, but is not running routing protocols. >>But I can not quite determine what it is.) >> >>I presume that there are also other goals. >> >>Yours, >>Joel >> >>At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: >> >>>Joel, >>> >>>I think it is fine to have this discussion via email. Jamal has already >>>started this via a detailed email on some of the existing solutions. I >>>wouldn't go to the extent of having another draft to define the problem, >>>requirements, etc...some of this should be already covered in our draft. >>> >>>When we started working on this draft, we did some research in this >>>space and found that.. yes there are several protocols out there for >>>topology discovery as you suggest. However, there is no existing >>>protocol that would work well for our framework. However, if you have >>>something in mind pls feel to share it with us. You had previously >>>suggested BFD but unfortunately this doesn't meet all our requirements. >>> >>>regards >>>Hormuzd >>> >>>-----Original Message----- >>>From: Forwarding and Control Element Separation >>>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >>> >>>We should determine that there is a problem, and that we need to solve >>>it, >>>before adopting as a work item for the working group a specific >>>solution. I would be interested in seeing a draft that outlined what >>>problem needed to be solved, why the many existing solutions among >>>themselves did not provide sufficient coverage, and what properties a >>>solution might need to have. It does not need to be a full >>>"requirements" >>>document. >>> >>>It could also be that we have extended email and face to face discussion >>>of >>>the problem, conclude it really needs to be addressed without a >>>problem-oriented ID, and then see what we want to do about solutions. >>> >>>But adopting a solution document as a working group work item is not the >>> >>>way to decide if there is a problem to be solved. >>> >>>Yours, >>>Joel M. Halpern >>> >>>At 06:12 PM 2/27/2005, Alistair Munro wrote: >>> >Hi All, >>> > >>> >I support adopting this document as a WG draft so that it is properly >>> >discussed. The functions are useful even if the protocol may be >>>redundant >>> >when the multitude of other discovery protocols are properly taken into >>> >>> >account. If there are genuine competitors then it is a debate that is >>> >worth having. >>> > >>> >Regards, >>> > >>> >Alistair >>> > > >-- >Furquan Ansari >Bell Labs Research Ph : 732-949-5249 >Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 16:43: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 QAA11112 for ; Mon, 28 Feb 2005 16:43:31 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sgh-0001Z5-Lv for forces-archive@IETF.ORG; Mon, 28 Feb 2005 16:44: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 <4.00FB86FE@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 16:43:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59760095 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 16:43:16 -0500 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 16:43:16 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1SLhC1O078707 for ; Mon, 28 Feb 2005 16:43:12 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SLh77d006756 for ; Mon, 28 Feb 2005 16:43:07 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SLh7oC016422 for ; Mon, 28 Feb 2005 16:43:07 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@localhost> <42234E4E.3070204@lucent.com> <6.2.1.2.0.20050228134621.02e03350@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <42238FC4.4060907@lucent.com> Date: Mon, 28 Feb 2005 16:40:20 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Joel, I am trying to understand what you are saying. Let's take this simple example of an NE with three different FEs in it - See figure below. If a routing protocol such as OSPF is started on this NE, the CE will send hello packets to neighboring NEs (NE2 and NE3) only through interfaces configured in OSPF - which would be interface "D" on FE1 and "B" on FE2. It would not be correct behavior if the CE decides to send the routing protocol Hellos through all the interfaces on an FE - that haven't been configured for that routing protocol - i.e. CE should not send hellos on interface "B" and "C" on FE1 and "C" and "D" of FE2. Further FE3 is completely internal to the NE and who is it sending it's hello packets to? The discovery is meant to discover the internal topology - albiet through as simple a mechanim as a hello protocol - but has been delineated from the routing protocol Hellos. Thanks, NE 1 ..................................... . ----------------- . . | CE | . . ----------------- . ---------- . A ^ B ^ C ^ . | NE 1 | . / A v \ . ---------- . / ------- B \ . ^ ^ . / +->| FE3 |<-+ \ . <====> / \ . / |C | | | \ . / \ . A v | ------- | v A . v v . -------B | |D ------- . -------- --------- . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 | . | |<--------------->| | . | | | | . ------- C C ------- . -------- --------- . D^ ^B . .....|.......................|........ | | | OSPF HEllo | OSPF Hello V v -------- -------- | NE 2 |<--------------->| NE 3 | | | OSPF HEllo | | -------- -------- Joel M. Halpern wrote: > I would agree that running a separate instance of the routing protocol > within the FE would be undesirable. > > However, the CE could send routing protocol hellos through all the > interfaces, and receive routing protocol hellos through all the > interfaces. It could then sensibly decide that hello maintenance is > all it needs on any adjacency for which it is both sides. (Note, a > normal router with two physical interfaces on the same subnet has to > do this anyway.) > > This works if the interface is shared with elements not within the NE, > and works if the interface is dedicated to the NE. It requires no new > protocols. > There may be requirements it does not meet. But we should articulate > those and agree on the relevance of such requirements. > > Yours, > Joel > > At 12:01 PM 2/28/2005, Furquan Ansari wrote: > >> Joel, >> As jamal already pointed out this is meant to be within a NE >> boundary and not span NE. The reason why an >> existing routing protocol neighbor discovery would not be sufficient >> is because, the routing protocol may/will >> not be running over internal links (imagine that there is a network >> of FEs internconnected and belong to the same >> NE - only FEs that connect to FEs of other NEs need to have the >> routing protocol like OSPF enabled.) >> An alternate would be to run a separate instance of the routing >> protocol "only" within the NE for neighbor discovery >> purposes - but this seems like an overkill for the solution we want. >> Further, the interconnection between the >> FEs within the NE may not necessarily be IP - in which case you may >> not be able to run IP routing protocols. >> >> >> Thanks, >> >> Joel M. Halpern wrote: >> >>> Can you describe some of the requirements, and the situations in >>> which they apply? >>> >>> I imagine there is some reason why simply routing protocol neighbor >>> discovery is not sufficient, but I can not divine the shortfall. (I >>> suspect that there is some case where a CE is responsbile for >>> forwarding packets through FEs, but is not running routing protocols. >>> But I can not quite determine what it is.) >>> >>> I presume that there are also other goals. >>> >>> Yours, >>> Joel >>> >>> At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: >>> >>>> Joel, >>>> >>>> I think it is fine to have this discussion via email. Jamal has >>>> already >>>> started this via a detailed email on some of the existing solutions. I >>>> wouldn't go to the extent of having another draft to define the >>>> problem, >>>> requirements, etc...some of this should be already covered in our >>>> draft. >>>> >>>> When we started working on this draft, we did some research in this >>>> space and found that.. yes there are several protocols out there for >>>> topology discovery as you suggest. However, there is no existing >>>> protocol that would work well for our framework. However, if you have >>>> something in mind pls feel to share it with us. You had previously >>>> suggested BFD but unfortunately this doesn't meet all our >>>> requirements. >>>> >>>> regards >>>> Hormuzd >>>> >>>> -----Original Message----- >>>> From: Forwarding and Control Element Separation >>>> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >>>> >>>> We should determine that there is a problem, and that we need to solve >>>> it, >>>> before adopting as a work item for the working group a specific >>>> solution. I would be interested in seeing a draft that outlined what >>>> problem needed to be solved, why the many existing solutions among >>>> themselves did not provide sufficient coverage, and what properties a >>>> solution might need to have. It does not need to be a full >>>> "requirements" >>>> document. >>>> >>>> It could also be that we have extended email and face to face >>>> discussion >>>> of >>>> the problem, conclude it really needs to be addressed without a >>>> problem-oriented ID, and then see what we want to do about solutions. >>>> >>>> But adopting a solution document as a working group work item is >>>> not the >>>> >>>> way to decide if there is a problem to be solved. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 06:12 PM 2/27/2005, Alistair Munro wrote: >>>> >Hi All, >>>> > >>>> >I support adopting this document as a WG draft so that it is properly >>>> >discussed. The functions are useful even if the protocol may be >>>> redundant >>>> >when the multitude of other discovery protocols are properly taken >>>> into >>>> >>>> >account. If there are genuine competitors then it is a debate that is >>>> >worth having. >>>> > >>>> >Regards, >>>> > >>>> >Alistair >>>> > >>> >> >> -- >> Furquan Ansari >> Bell Labs Research Ph : 732-949-5249 >> Holmdel, NJ Fax: 732-949-4556 > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 16:53: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 QAA12035 for ; Mon, 28 Feb 2005 16:53:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sq5-0001le-PS for forces-archive@IETF.ORG; Mon, 28 Feb 2005 16:54: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 <9.00FB868A@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 16:53:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59760674 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 16:53:12 -0500 Received: from 204.178.16.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 16:53:12 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id j1SLrBXJ067374 for ; Mon, 28 Feb 2005 16:53:11 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SLr67d007132 for ; Mon, 28 Feb 2005 16:53:06 -0500 (EST) Received: from lucent.com (IDENT:furquan@topgun [135.180.160.129]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id j1SLr5oC016721 for ; Mon, 28 Feb 2005 16:53:06 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@localhost> <42234E4E.3070204@lucent.com> <6.2.1.2.0.20050228134621.02e03350@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Furquan Ansari Message-ID: <4223921A.1040007@lucent.com> Date: Mon, 28 Feb 2005 16:50:18 -0500 Reply-To: Furquan Ansari Sender: Forwarding and Control Element Separation From: Furquan Ansari Organization: Lucent Technologies Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: 7bit Sorry, looks like my previous mail had formatting problems with the figure.... let me try again. -------------------- Joel, I am trying to understand what you are saying. Let's take this simple example of an NE with three different FEs in it - See figure below. If a routing protocol such as OSPF is started on this NE, the CE will send hello packets to neighboring NEs (NE2 and NE3) only through interfaces configured in OSPF - which would be interface "D" on FE1 and "B" on FE2. It would not be correct behavior if the CE decides to send the routing protocol Hellos through all the interfaces on an FE - that haven't been configured for that routing protocol - i.e. CE should not send hellos on interface "B" and "C" on FE1 and "C" and "D" of FE2. Further FE3 is completely internal to the NE and who is it sending it's hello packets to? The discovery is meant to discover the internal topology - albiet through as simple a mechanim as a hello protocol - but has been delineated from the routing protocol Hellos. Thanks, NE 1 ..................................... . ----------------- . . | CE | . . ----------------- . ---------- . A ^ B ^ C ^ . | NE 1 | . / | \ . | | . / A v \ . ---------- . / ------- B \ . ^ ^ . / +->| FE3 |<-+ \ . <====> / \ . / |C | | | \ . / \ . A v | ------- | v A . v v . -------B | |D ------- . -------- --------- . | FE1 |<-+ +->| FE2 | . | NE 2 |<---->| NE 3 | . | |<--------------->| | . | | | | . ------- C C ------- . -------- --------- . D^ ^B . .....|.......................|........ | | |OSPF Hello | OSPF HEllo V v -------- -------- | NE 2 |<--------------->| NE 3 | | | OSPF Hello | | -------- -------- Joel M. Halpern wrote: > I would agree that running a separate instance of the routing protocol > within the FE would be undesirable. > > However, the CE could send routing protocol hellos through all the > interfaces, and receive routing protocol hellos through all the > interfaces. It could then sensibly decide that hello maintenance is > all it needs on any adjacency for which it is both sides. (Note, a > normal router with two physical interfaces on the same subnet has to > do this anyway.) > > This works if the interface is shared with elements not within the NE, > and works if the interface is dedicated to the NE. It requires no new > protocols. > There may be requirements it does not meet. But we should articulate > those and agree on the relevance of such requirements. > > Yours, > Joel > > At 12:01 PM 2/28/2005, Furquan Ansari wrote: > >> Joel, >> As jamal already pointed out this is meant to be within a NE >> boundary and not span NE. The reason why an >> existing routing protocol neighbor discovery would not be sufficient >> is because, the routing protocol may/will >> not be running over internal links (imagine that there is a network >> of FEs internconnected and belong to the same >> NE - only FEs that connect to FEs of other NEs need to have the >> routing protocol like OSPF enabled.) >> An alternate would be to run a separate instance of the routing >> protocol "only" within the NE for neighbor discovery >> purposes - but this seems like an overkill for the solution we want. >> Further, the interconnection between the >> FEs within the NE may not necessarily be IP - in which case you may >> not be able to run IP routing protocols. >> >> >> Thanks, >> >> Joel M. Halpern wrote: >> >>> Can you describe some of the requirements, and the situations in >>> which they apply? >>> >>> I imagine there is some reason why simply routing protocol neighbor >>> discovery is not sufficient, but I can not divine the shortfall. (I >>> suspect that there is some case where a CE is responsbile for >>> forwarding packets through FEs, but is not running routing protocols. >>> But I can not quite determine what it is.) >>> >>> I presume that there are also other goals. >>> >>> Yours, >>> Joel >>> >>> At 10:47 PM 2/27/2005, Khosravi, Hormuzd M wrote: >>> >>>> Joel, >>>> >>>> I think it is fine to have this discussion via email. Jamal has >>>> already >>>> started this via a detailed email on some of the existing solutions. I >>>> wouldn't go to the extent of having another draft to define the >>>> problem, >>>> requirements, etc...some of this should be already covered in our >>>> draft. >>>> >>>> When we started working on this draft, we did some research in this >>>> space and found that.. yes there are several protocols out there for >>>> topology discovery as you suggest. However, there is no existing >>>> protocol that would work well for our framework. However, if you have >>>> something in mind pls feel to share it with us. You had previously >>>> suggested BFD but unfortunately this doesn't meet all our >>>> requirements. >>>> >>>> regards >>>> Hormuzd >>>> >>>> -----Original Message----- >>>> From: Forwarding and Control Element Separation >>>> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >>>> >>>> We should determine that there is a problem, and that we need to solve >>>> it, >>>> before adopting as a work item for the working group a specific >>>> solution. I would be interested in seeing a draft that outlined what >>>> problem needed to be solved, why the many existing solutions among >>>> themselves did not provide sufficient coverage, and what properties a >>>> solution might need to have. It does not need to be a full >>>> "requirements" >>>> document. >>>> >>>> It could also be that we have extended email and face to face >>>> discussion >>>> of >>>> the problem, conclude it really needs to be addressed without a >>>> problem-oriented ID, and then see what we want to do about solutions. >>>> >>>> But adopting a solution document as a working group work item is >>>> not the >>>> >>>> way to decide if there is a problem to be solved. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> At 06:12 PM 2/27/2005, Alistair Munro wrote: >>>> >Hi All, >>>> > >>>> >I support adopting this document as a WG draft so that it is properly >>>> >discussed. The functions are useful even if the protocol may be >>>> redundant >>>> >when the multitude of other discovery protocols are properly taken >>>> into >>>> >>>> >account. If there are genuine competitors then it is a debate that is >>>> >worth having. >>>> > >>>> >Regards, >>>> > >>>> >Alistair >>>> > >>> >> >> -- >> Furquan Ansari >> Bell Labs Research Ph : 732-949-5249 >> Holmdel, NJ Fax: 732-949-4556 > -- Furquan Ansari Bell Labs Research Ph : 732-949-5249 Holmdel, NJ Fax: 732-949-4556 From owner-forces@PEACH.EASE.LSOFT.COM Mon Feb 28 17:54:34 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 RAA17227 for ; Mon, 28 Feb 2005 17:54:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tnT-00037W-NE for forces-archive@IETF.ORG; Mon, 28 Feb 2005 17:55: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 <21.00FB88BC@cherry.ease.lsoft.com>; Mon, 28 Feb 2005 17:54:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59765095 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 28 Feb 2005 17:54:20 -0500 Received: from 192.215.81.77 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Feb 2005 17:54:20 -0500 Received: from JMHLap3.stevecrocker.com (353hosta70.starwoodbroadband.com [12.108.86.70]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id j1SMsI920872 for ; Mon, 28 Feb 2005 22:54:18 GMT X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0462CB1C@orsmsx408> <6.2.1.2.0.20050227232538.02cb14b8@localhost> <42234E4E.3070204@lucent.com> <6.2.1.2.0.20050228134621.02e03350@localhost> <42238FC4.4060907@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050228174946.02e74e38@localhost> Date: Mon, 28 Feb 2005 17:54:11 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: WG question: Should draft-ansari-forces-discovery-01.txt be accepted as WG document? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42238FC4.4060907@lucent.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 If we assume that the interfaces are dedicated to being either internal or external to the NE, and we assume that the CE actually has per-interface OSPF configuration, then it won't start OSPF on those interfaces. In that case, a protocol such as BFD would seem sensible. I could equally easily imagine the normal configuration being "run OSPF' "noroute internal" which would enable OSPF on all interfaces, and then tell the enigne not to bother exchanging routing information on internal interfaces. There are probably other existing alternatives I have not thought of that can be used. We should be very cautious before inventing another protocol for a problem that comes up repeatedly (neighbor detection.) It may be that we do need a very light weight specialized protocol. I want to understand what problem it is to solve and its relationship to existing work before discussing the design details of the protocol. Yours, Joel At 04:40 PM 2/28/2005, Furquan Ansari wrote: >Joel, > I am trying to understand what you are saying. Let's take this simple > example of an NE with three >different FEs in it - See figure below. If a routing protocol such as OSPF >is started on this NE, the CE >will send hello packets to neighboring NEs (NE2 and NE3) only through >interfaces configured in OSPF - >which would be interface "D" on FE1 and "B" on FE2. It would not be >correct behavior if the CE >decides to send the routing protocol Hellos through all the interfaces on >an FE - that haven't been >configured for that routing protocol - i.e. CE should not send hellos on >interface "B" and "C" on FE1 >and "C" and "D" of FE2. Further FE3 is completely internal to the NE and >who is it sending it's hello >packets to? >The discovery is meant to discover the internal topology - albiet through >as simple a mechanim as >a hello protocol - but has been delineated from the routing protocol Hellos. > >Thanks,