From LilianaHill@2morrow2day.co.uk Thu Jun 2 07:07: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 HAA00339 for ; Thu, 2 Jun 2005 07:07:13 -0400 (EDT) Date: Thu, 2 Jun 2005 07:07:13 -0400 (EDT) From: LilianaHill@2morrow2day.co.uk Received: from [222.101.242.16] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ddnrf-00063O-FD for forces-archive@ietf.org; Thu, 02 Jun 2005 07:27:58 -0400 Received: from qoU3@localhost by Fadj.int (8.11.6/8.11.6); Thu, 02 Jun 2005 13:15:32 -0500 Message-ID: <3[20 X-Spam-Score: 10.3 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 03:20: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 DAA29321 for ; Fri, 3 Jun 2005 03:20:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De6oR-0004hT-9o for forces-archive@IETF.ORG; Fri, 03 Jun 2005 03:41:51 -0400 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.0106DD7B@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 3:20:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73873349 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 03:20:43 -0400 Received: from 81.228.8.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 03:20:43 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 0971637EDD; Fri, 3 Jun 2005 09:20:43 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id A33ED37EC9 for ; Fri, 3 Jun 2005 09:20:42 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 95A2F37E48 for ; Fri, 3 Jun 2005 09:20:42 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1De6Tw-0003Pd-Vi for forces@peach.ease.lsoft.com; Fri, 03 Jun 2005 09:20:41 +0200 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 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.9 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Hormuzd Khosravi Message-ID: <1117783240.68.0.897387957284.issue43@mip4.org> Date: Fri, 3 Jun 2005 07:20:40 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Hormuzd Khosravi Subject: [issue43] Editorial- change GET to SET in section 6.5 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable New submission from Hormuzd Khosravi : In sections 6.5.1, 6.5.2, the figures show GET command being used in Config=20 messages. This should be changed to SET in both sub-sections. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 62 nosy: hormuzdk priority: Must fix status: Text proposed title: Editorial- change GET to SET in section 6.5 ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 10:31: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 KAA03574 for ; Fri, 3 Jun 2005 10:31:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDXD-0005lH-Ts for forces-archive@IETF.ORG; Fri, 03 Jun 2005 10:52:32 -0400 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.0106E3B4@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 10:31:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73934678 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 10:31:30 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 10:31:29 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.1307239863; Fri, 3 Jun 2005 23:02:51 +0800 (CST) References: <1116786570.5.0.359923710414.issue30@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <007001c56849$7bc422c0$020aa8c0@wwm1> Date: Fri, 3 Jun 2005 22:35:19 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue30] Event subscription Comments: cc: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: base64 Tm90IHN1cmUgaWYgdGhpcyBpc3N1ZSBjYW4gYmUgY2xvc2VkIGJ5IGxlYXZpbmcgaXQgZm9yIG1v ZGVsIHRlYW0gdG8gZGVjaWRlLiBBY3R1YWxseSBpdCBkb2VzIG5vdCByZWxhdGUgdG8gdGhlIHBy b3RvY29sICBzcGVjaWZpY2F0aW9uIHZlcnkgbXVjaC4NCg0KV2VpbWluZw0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBdnJpIERvcmlhIiA8dHJhY2tlci1mb3JjZXNAbWlw NC5vcmc+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IE1vbmRheSwg TWF5IDIzLCAyMDA1IDI6MjkgQU0NClN1YmplY3Q6IFtpc3N1ZTMwXSBFdmVudCBzdWJzY3JpcHRp b24NCg0KDQpOZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPGF2cmlAYWNtLm9yZz46DQoN CjYuNw0KDQogICBFZGl0b3JpYWwgTm90ZTogIFRoZXJlIGlzIGFuIGFyZ3VtZW50IHRoYXQgaXQg aXMgcHJlZmVyYWJsZSB0byBoYXZlDQogICAgICAgICAgICAgICAgICAgIGFsbCBldmVudHMgc3Vi c2NyaWJhYmxlLg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkcmFmdDogZHJh ZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCm1lc3NhZ2VzOiA0Nw0Kbm9zeTogYXZyaQ0KcHJpb3Jp dHk6IE11c3QgZml4DQpzdGF0dXM6IE5vIGRpc2N1c3Npb24NCnRpdGxlOiBFdmVudCBzdWJzY3Jp cHRpb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGb3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0 cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMD4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 10:35: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 KAA03896 for ; Fri, 3 Jun 2005 10:35:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDbF-0005qR-S3 for forces-archive@IETF.ORG; Fri, 03 Jun 2005 10:56:42 -0400 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.0106E41F@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 10:35:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73935029 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 10:35:25 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 10:35:16 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.1307239863; Fri, 3 Jun 2005 23:06:58 +0800 (CST) References: <1116786689.89.0.733606930711.issue31@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <007401c5684a$0fa1d5a0$020aa8c0@wwm1> Date: Fri, 3 Jun 2005 22:39:34 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue31] Necessity of Notification Response Message Comments: cc: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: base64 TXkgdGhvdWdodCBpcyBpZiB3ZSBkZWNpZGUgbm90IHRvIGhhdmUgYSB1bmlmb3JtbHkgZm9ybWF0 ZWQgQUNLIG1lc3NhZ2UgaW4gdGhlIHByb3RvY29sIG1lc3NhZ2VzLCB3ZSBtYXkgbmVlZCBzdWNo IGV2ZW50IG5vdGlmaWNhdGlvbiByZXNwb25zZSBtZXNzYWdlLg0KDQp0aGFua3MsDQpXZWltaW5n DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG9yaWEiIDx0cmFj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCg0KTmV3IHN1Ym1pc3Npb24gZnJvbSBBdnJpIERvcmlhIDxh dnJpQGFjbS5vcmc+Og0KDQo2LjcuMg0KDQogIEVkaXRvcmlhbCBOb3RlOiAgVGhlcmUgaXMgYSBk ZWJhdGUgb24gd2hldGhlciB0aGUgRXZlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgTm90aWZp Y2F0aW9uIFJlc3BvbnNlIE1lc3NhZ2UgaXMgbmVjZXNzYXJ5IG9yDQogICAgICAgICAgICAgICAg ICAgICAgIG5vdC4gIFRoZSBwcm8gZm9yIGl0IGlzIHNvbWUgZXZlbnQgbm90aWZpY2F0aW9uDQog ICAgICAgICAgICAgICAgICAgICAgIHNlbmRlcnMgbWF5IGJlIGludGVyZXN0ZWQgaW4ga25vd2lu ZyBpZiByZWNlaXZlcnMNCiAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBoYWQgc3VjY2Vzcy91 bnN1Y2Nlc3MgcmVjZXB0aW9ucyBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgZXZlbnRz IG9yIG5vdC4gIEFuIGFsdGVybmF0aXZlIHRvIGdlbmVyYXRlIHN1Y2gNCiAgICAgICAgICAgICAg ICAgICAgICAgcmVzcG9uc2UgaXMgZm9yIHRoZSBwcm90b2NvbCB0byBkZWZpbmUgYQ0KICAgICAg ICAgICAgICAgICAgICAgICB1bml2ZXJzYWwgQUNLIG1lc3NhZ2Ugc28gdGhhdCBpdCBjYW4gYWN0 IGFzDQogICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNlcyBmb3IgYW55IHR5cGVzIG9mIG1l c3NhZ2VzIGFzIHdlbGwgYXMNCiAgICAgICAgICAgICAgICAgICAgICAgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBtZXNzYWdlcywgd2hlbiB0aGUgbWVzc2FnZQ0KICAgICAgICAgICAgICAgICAgICAg ICBzZW5kZXJzIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgd2hldGhlciB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgbWVzc2FnZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCBv ciBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgKGRpZmZlcmVudCBmcm9tIHRoZSByZXNwb25z ZXMgZm9yIHRoZSBtZXNzYWdlDQogICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NpbmcgcmVz dWx0cykuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRyYWZ0OiBkcmFmdC1p ZXRmLWZvcmNlcy1wcm90b2NvbA0KbWVzc2FnZXM6IDQ4DQpub3N5OiBhdnJpDQpwcmlvcml0eTog TXVzdCBmaXgNCnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IE5lY2Vzc2l0eSBvZiBOb3Rp ZmljYXRpb24gUmVzcG9uc2UgTWVzc2FnZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2VyLWZv cmNlc0BtaXA0Lm9yZz4NCjxodHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vlcy90cmFja2VyL2ZvcmNl cy9pc3N1ZTMxPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo= From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 10:41: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 KAA04269 for ; Fri, 3 Jun 2005 10:41:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDgd-0005xx-56 for forces-archive@IETF.ORG; Fri, 03 Jun 2005 11:02:16 -0400 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.0106E39C@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 10:41:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73935520 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 10:41:16 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 10:41:15 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.1307239863; Fri, 3 Jun 2005 23:12:58 +0800 (CST) References: <1116787707.07.0.962364733422.issue36@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <008201c5684a$e637c390$020aa8c0@wwm1> Date: Fri, 3 Jun 2005 22:45:33 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue36] Note: - FE and CE Failover Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG9yaWEiIDx0cmFj a2VyLWZvcmNlc0BtaXA0Lm9yZz4NCg0KTmV3IHN1Ym1pc3Npb24gZnJvbSBBdnJpIERvcmlhIDxh dnJpQGFjbS5vcmc+Og0KDQo2LjIuMQ0KDQogICAgICAqICBDdXJyZW50IHZlcnNpb24gb2YgdGhl IEZFIG1vZGVsDQogICAgICAqICBGRSB1bmljYXN0IElEDQogICAgICAqICBGRSBtdWx0aWNhc3Qg SUQocykgKGxpc3QpDQogICAgICAqICBBc3NvY2lhdGlvbiBFeHBpcnkgVGltZXINCiAgICAgICog IEhlYXJ0YmVhdCBJbnRlcnZhbA0KICAgICAgKiAgUHJpbWFyeSBDRQ0KICAgICAgKiAgRkUgZmFp bG92ZXIgYW5kIHJlc3RhcnQgcG9saWN5DQogICAgICAqICBDRSBmYWlsb3ZlciBhbmQgcmVzdGFy dCBwb2xpY3kNCiAgICAgICAgIE5vdGU6ICBJcyB0aGVyZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGUgQ0UgYW5kIEZFIGZhaWxvdmVyDQogICAgICAgICAgICAgICAgcG9saWNpZXM/DQoNCltXZWlt aW5nXSBDRSBmYWlsb3ZlciBwb2xpY3kgdGVsbHMgaG93IEZFIGFjdHMgaWYgaXQgZmluZHMgdGhl IENFIGZhaWxzLCB3aGlsZSBGRSBmYWlsb3ZlciBhbmQgcmVzdGFydCBwb2xpY3kgdGVsbHMgaG93 IEZFIHNob3VsZCBhY3QgdG8gcmVzdGFydCBmcm9tIGEgZmFpbG92ZXIgc3RhdGUuICANCg0KLS0t LS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRvcmlhbA0KZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLXBy b3RvY29sDQptZXNzYWdlczogNTQNCm5vc3k6IGF2cmkNCnByaW9yaXR5OiBNdXN0IGZpeA0Kc3Rh dHVzOiBObyBkaXNjdXNzaW9uDQp0aXRsZTogTm90ZTogLSBGRSBhbmQgQ0UgRmFpbG92ZXINCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGb3Jj ZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0cDovL3d3dy5t aXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzNj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 10:46: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 KAA04711 for ; Fri, 3 Jun 2005 10:46:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeDlD-00062q-Qv for forces-archive@IETF.ORG; Fri, 03 Jun 2005 11:07:25 -0400 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.0106E294@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 10:46:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73935836 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 10:45:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 10:45:58 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Fri, 3 Jun 2005 23:17:37 +0800 (CST) References: <1116787810.01.0.19338144736.issue37@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <00ac01c5684b$8c64cf60$020aa8c0@wwm1> Date: Fri, 3 Jun 2005 22:50:12 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: base64 SXQgc2VlbXMgd2UgbmVlZCB0byBmaXJzdCBkZWNpZGUgIndobyBzaG91bGQgZGVmaW5lIHRoZSBM RkJzIGxpa2UgRkUtTEZCLCBGRS1wcm90b2NvbC1MRkIsIHRoaXMgcHJvdG9jb2wgZG9jdW1lbnQg b3IgZWxzZXdoZXJlIiAgYmVmb3JlIHRyeWluZyB0byBkZWNpZGUgdGhpcyBpc3N1ZS4NCg0KdGhh bmtzLA0KV2VpbWluZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBdnJp IERvcmlhIiA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNF LkxTT0ZULkNPTT4NClNlbnQ6IE1vbmRheSwgTWF5IDIzLCAyMDA1IDI6NTAgQU0NClN1YmplY3Q6 IFtpc3N1ZTM3XSBUQkQgLSBGRSBQcm90b2NvbCBBdHRyaWJ1dGVzDQoNCg0KTmV3IHN1Ym1pc3Np b24gZnJvbSBBdnJpIERvcmlhIDxhdnJpQGFjbS5vcmc+Og0KDQo2LjIuMQ0KDQogICBvICBGRSBQ cm90b2NvbCBhdHRyaWJ1dGVzIChjYW4gYmUgcmVhZCBhbmQgc2V0KToNCiAgICAgICogIEN1cnJl bnQgdmVyc2lvbiBvZiB0aGUgRm9yQ0VTIHByb3RvY29sDQoNCg0KDQoNCkRvcmlhIChjby1lZGl0 b3IpICAgICAgICAgRXhwaXJlcyBBcHJpbCA0LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDMx XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBGb3JDRVMgICAgICAgICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDQNCg0KDQogICAgICAqICBDdXJyZW50IHZlcnNpb24gb2YgdGhl IEZFIG1vZGVsDQogICAgICAqICBGRSB1bmljYXN0IElEDQogICAgICAqICBGRSBtdWx0aWNhc3Qg SUQocykgKGxpc3QpDQogICAgICAqICBBc3NvY2lhdGlvbiBFeHBpcnkgVGltZXINCiAgICAgICog IEhlYXJ0YmVhdCBJbnRlcnZhbA0KICAgICAgKiAgUHJpbWFyeSBDRQ0KICAgICAgKiAgRkUgZmFp bG92ZXIgYW5kIHJlc3RhcnQgcG9saWN5DQogICAgICAqICBDRSBmYWlsb3ZlciBhbmQgcmVzdGFy dCBwb2xpY3kNCiAgICAgDQogICAgICAgICBUQkQ6ICAgRGVmaW5lIGRlZmF1bHQgdmFsdWVzIGZv ciBlYWNoIGF0dHJpYnV0ZSB3aGVyZQ0KICAgICAgICAgICAgICAgIGFwcGxpY2FibGUuDQoNCi0t LS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRyYWZ0OiBkcmFmdC1pZXRmLWZvcmNlcy1w cm90b2NvbA0KbWVzc2FnZXM6IDU1DQpub3N5OiBhdnJpDQpwcmlvcml0eTogTXVzdCBmaXgNCnN0 YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IFRCRCAtIEZFIFByb3RvY29sIEF0dHJpYnV0ZXMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG b3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0cDovL3d3 dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzNz4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 14:27: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 OAA20779 for ; Fri, 3 Jun 2005 14:27:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeHDB-0002Rc-QK for forces-archive@IETF.ORG; Fri, 03 Jun 2005 14:48:08 -0400 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.0106E88B@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 14:27:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73968895 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 14:27:05 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 14:27:05 -0400 Received: from [69.170.22.60] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10733380; Fri, 03 Jun 2005 14:27:05 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786570.5.0.359923710414.issue30@mip4.org> <007001c56849$7bc422c0$020aa8c0@wwm1> 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.20050603142510.02e5ccd0@localhost> Date: Fri, 3 Jun 2005 14:27:05 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue30] Event subscription Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007001c56849$7bc422c0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b My current inclination is that the definition of an event identifies the subscription point, that all events are subscribable, and that by default all subscriptions are off. This creates a clean, simple, understandable, operting mode. The assumption that lead me to this is simply that without a CE there is no point in a notification, and if there is a CE, he can determine what he wants to register for. Any race condition is handled by the CE getting the information he needs about current state. Yours, Joel At 10:35 AM 6/3/2005, Weiming Wang wrote: >Not sure if this issue can be closed by leaving it for model team to >decide. Actually it does not relate to the protocol specification very much. > >Weiming >----- Original Message ----- >From: "Avri Doria" >To: >Sent: Monday, May 23, 2005 2:29 AM >Subject: [issue30] Event subscription > > >New submission from Avri Doria : > >6.7 > > Editorial Note: There is an argument that it is preferable to have > all events subscribable. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 47 >nosy: avri >priority: Must fix >status: No discussion >title: Event subscription From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 14:28: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 OAA20960 for ; Fri, 3 Jun 2005 14:28:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeHEy-0002UE-8j for forces-archive@IETF.ORG; Fri, 03 Jun 2005 14:49:57 -0400 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.0106E6A7@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 14:28:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73968973 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 14:28:56 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 14:28:56 -0400 Received: from [69.170.22.60] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10733403; Fri, 03 Jun 2005 14:28:56 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116787810.01.0.19338144736.issue37@mip4.org> <00ac01c5684b$8c64cf60$020aa8c0@wwm1> 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.20050603142756.02e558b0@localhost> Date: Fri, 3 Jun 2005 14:28:55 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00ac01c5684b$8c64cf60$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 A reasonable question. My current take is that the FE LFB should come with the model document, and the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB, >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 3 14:39: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 OAA21482 for ; Fri, 3 Jun 2005 14:39:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeHPK-0002dj-2y for forces-archive@IETF.ORG; Fri, 03 Jun 2005 15:00:38 -0400 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.0106E6EA@cherry.ease.lsoft.com>; Fri, 3 Jun 2005 14:39:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73970169 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Jun 2005 14:39:38 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 3 Jun 2005 14:39:37 -0400 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 j53IdbFT013966; Fri, 3 Jun 2005 18:39:37 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 j53IdZdE002400; Fri, 3 Jun 2005 18:39:37 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 M2005060311393523371 ; Fri, 03 Jun 2005 11:39:35 -0700 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, 3 Jun 2005 11:39:35 -0700 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] [issue37] TBD - FE Protocol Attributes Thread-Index: AcVoah3VkzcowY+DQ+mJMbKNt7AH1QAAWXkA X-OriginalArrivalTime: 03 Jun 2005 18:39:35.0010 (UTC) FILETIME=[96C35420:01C5686B] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Fri, 3 Jun 2005 11:39:33 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable (hat off) The approach you propose Joel makes sense to me technically, and it is also a nice partitioning of the work :) -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, June 03, 2005 11:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes A reasonable question. My current take is that the FE LFB should come with the model document, and=20 the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB,=20 >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming From DiegoMiddler@deray.net Sat Jun 4 16:42:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28924 for ; Sat, 4 Jun 2005 16:42:36 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Defo5-0003bz-5l for forces-archive@ietf.org; Sat, 04 Jun 2005 17:03:49 -0400 Received: from pcp08697300pcs.500ash01.tn.comcast.net ([69.137.110.105]) by mx2.foretec.com with smtp (Exim 4.24) id 1DefTY-0008Sb-JB for forces-archive@ietf.org; Sat, 04 Jun 2005 16:42:36 -0400 Received: from srK@localhost by 57PJ.int (8.11.6/8.11.6); Sun, 05 Jun 2005 02:30:20 +0500 Message-ID: From: "Freida Lane" Reply-To: "Freida Lane" To: forces-archive@ietf.org Subject: MS Office XP Pro $49.95 MS 2003 Date: Sat, 04 Jun 2005 22:32:20 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DiegoMiddler@deray.net Content-Type: multipart/mixed; boundary="--OppkzOXDIbp58wudB" X-Spam-Score: 3.7 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 4cv ----OppkzOXDIbp58wudB Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
Opt-in Email Special Offer &n= bsp;   unsubscribe me<= a href=3Dhttp://save2drive.com/?r>
=
<= td bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

<= td width=3D8>4= 79

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Wi= ndows XP Pro
 3 Adobe= Creative Suite Premium
  Norton Antivirus 2005
 5 Flash MX 2004
 6 = Corel Draw 12
  Adobe Acrobat 7.0
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Micro= soft
  = Apple Software<= /td>
  Customers also bought=
   these other items...
=



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
<= /a> 
List Price:<= /td>$899.00
Price:$69.99
You Save:$830.01 (92%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  <= a href=3Dhttp://save2drive.com/?x>Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: June 30th, 2005
Aver= age Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft W= indows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Pr= ice:$279.00
Pric= e:$49.99
You Save:$229.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: ISe229
Media: CD-ROM / Download

System requirements=   |  Accessories  |&= nbsp; Other Versions

<= b>Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video,= DVDs, and more
  • More securit= y with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support <= /font>
  • Integration with Windows serv= ers and management solutions

Sal= es Rank: #2
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

=
Adobe Photoshop CS2 V 9.0
Adobe
=
Choose= :
&n= bsp;

<= /table>



Availability: Available for INSTAN= T download!
Coupon Code: ISe229
Media: CD-ROM / Down= load

System requirements  |  Accessories  |  Other Ve= rsions

Features:

  • Customized workspace; = save personalized workspace and tool settings; create customized shortcuts=
  • Unparalleled efficiency--a= utomate production tasks with built-in or customized scripts
    • =
  • Improved file management, new design poss= ibilities, and a more intuitive way to create for the Web
    • Support for 16-bit images, digital camera ra= w data, and non-square pixels
  • Create or modify photos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)
----OppkzOXDIbp58wudB-- From ElisaButcher@endoscopic.net Sat Jun 4 23:39: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 XAA17110 for ; Sat, 4 Jun 2005 23:39:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DemJM-0001V2-C3 for forces-archive@ietf.org; Sun, 05 Jun 2005 00:00:33 -0400 Received: from c-24-129-206-94.hsd1.fl.comcast.net ([24.129.206.94]) by mx2.foretec.com with smtp (Exim 4.24) id 1Delyl-0002W1-7V for forces-archive@ietf.org; Sat, 04 Jun 2005 23:39:15 -0400 Received: from t7d@localhost by y23.int (8.11.6/8.11.6); Sun, 05 Jun 2005 11:41:39 +0100 Message-ID: From: "Rob Kyle" Reply-To: "Rob Kyle" To: forces-archive@ietf.org Subject: Microsoft Special Deals Date: Sun, 05 Jun 2005 14:50:39 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ElisaButcher@endoscopic.net Content-Type: multipart/mixed; boundary="--XJDSRUyE8LtCeUQRZpn5" X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 D[3 ----XJDSRUyE8LtCeUQRZpn5-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 03:17: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 DAA05251 for ; Mon, 6 Jun 2005 03:17:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfCBq-0001mw-Mb for forces-archive@IETF.ORG; Mon, 06 Jun 2005 03:38:34 -0400 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.01071916@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 3:16:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74239127 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 03:16:55 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 03:16:55 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 6 Jun 2005 15:49:07 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 6 Jun 2005 15:14:51 +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: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> Date: Mon, 6 Jun 2005 15:15:18 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Joel, David, and Robert, I have some thoughts, some by my experience with GRMP: 1. Defining things like LFB attributes in details in the protocol docuement will really leads the document to a comlex one. 2. Currently, we may be a little far away from accurately defining these attributes. 3. Therefore, will eventually bottleneck the protocol document from going to last call. I actually incline to strip all that are related to LFB definitions from current protocol docuement, while only leaving it for open discussion later that "whether they go to model document or to a specific one for LFB definitions used by protocol" . Thanks, Weiming ----- Original Message ----- From: "Putzolu, David" (hat off) The approach you propose Joel makes sense to me technically, and it is also a nice partitioning of the work :) -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, June 03, 2005 11:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes A reasonable question. My current take is that the FE LFB should come with the model document, and the FE-protocol LFB should be defined by the protocol document. However, this is something on which reasonable people can easily differ, and I am open to alternatives. Yours, Joel At 10:50 AM 6/3/2005, Weiming Wang wrote: >It seems we need to first decide "who should define the LFBs like FE-LFB, >FE-protocol-LFB, this protocol document or elsewhere" before trying to >decide this issue. > >thanks, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 08:55: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 IAA27313 for ; Mon, 6 Jun 2005 08:55:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfHTW-0000CF-QC for forces-archive@IETF.ORG; Mon, 06 Jun 2005 09:17:11 -0400 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.01071D30@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 8:55:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74314000 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 08:55:30 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 08:55:30 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005060605590175:10951 ; Mon, 6 Jun 2005 05:59:01 -0700 References: <1116786570.5.0.359923710414.issue30@mip4.org> <007001c56849$7bc422c0$020aa8c0@wwm1> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:59:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:59:03 AM, Serialize complete at 06/06/2005 05:59:03 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118062527.6266.180.camel@localhost.localdomain> Date: Mon, 6 Jun 2005 08:55:26 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue30] Event subscription To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007001c56849$7bc422c0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Hi Weiming, On Fri, 2005-03-06 at 22:35 +0800, Weiming Wang wrote: > Not sure if this issue can be closed by leaving it for model team to decide. > Actually it does not relate to the protocol specification very much. The protocol has to provide the semantics to allow for events. Why do you say "it does not relate to the protocol"? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 09:01: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 JAA28241 for ; Mon, 6 Jun 2005 09:01:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfHZi-0000R0-0L for forces-archive@IETF.ORG; Mon, 06 Jun 2005 09:23:30 -0400 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.01071D6B@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 9:01:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74314543 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 09:01:54 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 09:01:54 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005060606052596:10957 ; Mon, 6 Jun 2005 06:05:25 -0700 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 06:05:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 06:05:28 AM, Serialize complete at 06/06/2005 06:05:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118062910.6266.187.camel@localhost.localdomain> Date: Mon, 6 Jun 2005 09:01:49 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit I am about 60% in agreement with Weiming. Infact, thats what i was stating before the last IETF meeting. I even have a draft called "Core LFBs" to prove it ;-> Actually the main valid reason that Weiming provides is #3. We need to get both the protocol and Model drafts to last call and moving this out will help speed things up. I believe the core LFBs should still be mentioned in the two drafts but not elucidated. cheers, jamal On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > Joel, David, and Robert, > > I have some thoughts, some by my experience with GRMP: > 1. Defining things like LFB attributes in details in the protocol docuement will > really leads the document to a comlex one. > 2. Currently, we may be a little far away from accurately defining these > attributes. > 3. Therefore, will eventually bottleneck the protocol document from going to > last call. > > I actually incline to strip all that are related to LFB definitions from current > protocol docuement, while only leaving it for open discussion later that > "whether they go to model document or to a specific one for LFB definitions used > by protocol" . > > Thanks, > Weiming > ----- Original Message ----- > From: "Putzolu, David" > > (hat off) > > The approach you propose Joel makes sense to me technically, and it is > also a nice partitioning of the work :) > > -David > > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Friday, June 03, 2005 11:29 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes > > A reasonable question. > > My current take is that the FE LFB should come with the model document, > and > the FE-protocol LFB should be defined by the protocol document. > However, this is something on which reasonable people can easily differ, > > and I am open to alternatives. > > Yours, > Joel > > At 10:50 AM 6/3/2005, Weiming Wang wrote: > >It seems we need to first decide "who should define the LFBs like > FE-LFB, > >FE-protocol-LFB, this protocol document or elsewhere" before trying to > > >decide this issue. > > > >thanks, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 11:19: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 LAA09842 for ; Mon, 6 Jun 2005 11:19:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJj1-0003Om-Bf for forces-archive@IETF.ORG; Mon, 06 Jun 2005 11:41:16 -0400 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.01072173@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 11:19:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74331150 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 11:19:38 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 11:19:38 -0400 Received: from [68.232.102.44] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10770199 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 06 Jun 2005 11:19:37 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.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.20050606111204.02d291a0@localhost> Date: Mon, 6 Jun 2005 11:19:33 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118062910.6266.187.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db I tend to disagree. With regard to the FE LFB and the model draft, my concrete concern is that a human being reading the model draft without the FE LFB will not understand how a CE can actually make use of the model. We could just say that there is an FE LFB (class 1, instance 1), that it has the basic information the CE needs, and leave the details to another draft. But I am pretty sure that will leave readers confused. As a minor related note, including the FE LFB will give me an easy way to provide an example LFB definition, including information about properties for access control. (I won't be able to get alias in.) I currently intend to also include some events (LFB Creation, LFB Deletion, Capability change, are the ones I think belong.) With regard to the protocol, it is probably not as big an issue. After all, we have a long tradition of putting instrumentation for protocols in other documents (MIBs). The difference is that most protocols can run without their MIB. Can we run the forces protocol without the Forces Protocol LFB? (We can not run the model / protocol without the FE LFB.) Yours, Joel At 09:01 AM 6/6/2005, Jamal Hadi Salim wrote: >I am about 60% in agreement with Weiming. Infact, thats what i was >stating before the last IETF meeting. I even have a draft called "Core >LFBs" to prove it ;-> > >Actually the main valid reason that Weiming provides is #3. We need to >get both the protocol and Model drafts to last call and moving this out >will help speed things up. I believe the core LFBs should still be >mentioned in the two drafts but not elucidated. > >cheers, >jamal > >On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > > Joel, David, and Robert, > > > > I have some thoughts, some by my experience with GRMP: > > 1. Defining things like LFB attributes in details in the protocol > docuement will > > really leads the document to a comlex one. > > 2. Currently, we may be a little far away from accurately defining these > > attributes. > > 3. Therefore, will eventually bottleneck the protocol document from > going to > > last call. > > > > I actually incline to strip all that are related to LFB definitions > from current > > protocol docuement, while only leaving it for open discussion later that > > "whether they go to model document or to a specific one for LFB > definitions used > > by protocol" . > > > > Thanks, > > Weiming > > ----- Original Message ----- > > From: "Putzolu, David" > > > > (hat off) > > > > The approach you propose Joel makes sense to me technically, and it is > > also a nice partitioning of the work :) > > > > -David > > > > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > Sent: Friday, June 03, 2005 11:29 AM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes > > > > A reasonable question. > > > > My current take is that the FE LFB should come with the model document, > > and > > the FE-protocol LFB should be defined by the protocol document. > > However, this is something on which reasonable people can easily differ, > > > > and I am open to alternatives. > > > > Yours, > > Joel > > > > At 10:50 AM 6/3/2005, Weiming Wang wrote: > > >It seems we need to first decide "who should define the LFBs like > > FE-LFB, > > >FE-protocol-LFB, this protocol document or elsewhere" before trying to > > > > >decide this issue. > > > > > >thanks, > > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 11:22: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 LAA10145 for ; Mon, 6 Jun 2005 11:22:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJln-0003U1-IF for forces-archive@IETF.ORG; Mon, 06 Jun 2005 11:44:08 -0400 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.0107206E@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 11:22:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74331417 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 11:22:31 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 11:22:31 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.2105028806; Mon, 6 Jun 2005 23:54:50 +0800 (CST) References: <1116786570.5.0.359923710414.issue30@mip4.org> <007001c56849$7bc422c0$020aa8c0@wwm1> <1118062527.6266.180.camel@localhost.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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003501c56aac$25817f10$020aa8c0@wwm1> Date: Mon, 6 Jun 2005 23:26:42 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue30] Event subscription Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: base64 SmFtYWwsIA0KDQpWZXJ5IGdsYWQgdG8gc2VlIHlvdSBhZ2FpbiA6KQ0KDQpUaGUgb3JpZ2luYWwg cXVlc3Rpb24gaXMgImlmIGFsbCBldmVudHMgc2hvdWxkIGJlIHN1YnNjcmliYWJsZSBvciBub3Qi LiBCeSBzYXlpbmcgaXQgZG9lcyBub3QgcmVsYXRlIHRvIHRoZSBwcm90b2NvbCwgSSBhY3R1YWxs eSB0aG91Z2h0IHRoYXQgdGhlIHByb3RvY29sIG9ubHkgbmVlZCB0byBwcm92aWRlIHRoZSBwcm90 b2NvbCBzZW1hbnRpY3MgZm9yIHRoZSBzdWJzY3JpcHRpb24gaWYgdGhlIGV2ZW50cyBhcmUgc3Vi c2NyaWJhYmxlLCBidXQgYW4gZXZlbnQgaXMgc3Vic2NyaWJhYmxlIG9yIG5vdCBzdGlsbCBoYXZl IHRvIGJlIGRlZmluZWQgaW4gdGhlIG1vZGVsIGRlZmluaXRpb25zIGZvciB0aGUgZXZlbnQuIElu IGFub3RoZXIgd29yZCwgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gZG9lcyBub3QgY2FyZSBp ZiBhbiBldmVudCBpcyBzdWJzY3JpYmFiYWwgb3Igbm90LiBJZiBpdCBpcyBub3QgYSBzdWJzY3Jp YmFibGUgZXZlbnQgd2hpbGUgaXQgd2VyZSB0cmllZCB0byBzdWJzY3JpYmUsIGFuIGVycm9yIHdp bGwgcmV0dXJuLiANCg0KVGhpcyBpcyBjYW4gYWxzbyBiZSBkZXNjcmliZWQgYXMgImlmIGFuIFhN TCBkZWZpbml0aW9uIGZvciBhbiBldmVudCBuZWVkIHRvIGhhdmUgdGhlIGF0dHJpYnV0ZSBhcyAi U1VCU0NSSUJBQkxFL1VOU1VCU0NSSUJBQkxFIiBvciBub3QuDQoNClJlZ2FyZGluZyB0aGUgaXNz dWUgaXRzZWxmLCBJIHBlcnNvbmFsbHkgaW5jbGluZSB0byBoYXZlIGFsbCAgZXZlbnRzIHN1YnNj cmliYWJsZSwgd2hpY2gsIGFzIEpvZWwgcG9pbnRlZCBvdXQsIHdpbGwgbGVhZCB0byBhIHZlcnkg Y2xlYXIgZ3JhbW1hciwgYW5kIGFsbCBldmVudHMgc2hvdWxkIGJlIG9mZiB3aGVuIHN5c3RlbSBp cyBmaXJzdCBib290ZWQuIFRoaXMgYWxzbyBtZWFucyB0aGUgWE1MIGRlZmluaXRpb24gZm9yIGFu IGV2ZW50IGRvZXMgbm90IG5lZWQgdG8gaGF2ZSBhbiBhdHRyaWJ1dGUgYXMgIlNVQlNDUklCQUJM RS9VTlNVQlNDUklCQUJMRSIuDQoNCkNoZWVycywNCldlaW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4N CiANCj4gSGkgV2VpbWluZywNCj4gDQo+IE9uIEZyaSwgMjAwNS0wMy0wNiBhdCAyMjozNSArMDgw MCwgV2VpbWluZyBXYW5nIHdyb3RlOg0KPiA+IE5vdCBzdXJlIGlmIHRoaXMgaXNzdWUgY2FuIGJl IGNsb3NlZCBieSBsZWF2aW5nIGl0IGZvciBtb2RlbCB0ZWFtIHRvIGRlY2lkZS4gDQo+ID4gQWN0 dWFsbHkgaXQgZG9lcyBub3QgcmVsYXRlIHRvIHRoZSBwcm90b2NvbCAgc3BlY2lmaWNhdGlvbiB2 ZXJ5IG11Y2guDQo+IA0KPiBUaGUgcHJvdG9jb2wgaGFzIHRvIHByb3ZpZGUgdGhlIHNlbWFudGlj cyB0byBhbGxvdyBmb3IgZXZlbnRzLg0KPiBXaHkgZG8geW91IHNheSAiaXQgZG9lcyBub3QgcmVs YXRlIHRvIHRoZSBwcm90b2NvbCI/DQo+IA0KPiBjaGVlcnMsDQo+IGphbWFsDQo+IA== From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 12:27: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 MAA14482 for ; Mon, 6 Jun 2005 12:27:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfKmy-0004nt-Sp for forces-archive@IETF.ORG; Mon, 06 Jun 2005 12:49:25 -0400 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.01072260@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 12:27:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74335867 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 12:27:48 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 12:27:47 -0400 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 j56GRj1K000473; Mon, 6 Jun 2005 16:27:45 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 j56GQaUP004272; Mon, 6 Jun 2005 16:27:45 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 M2005060609274428086 ; Mon, 06 Jun 2005 09:27:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 09:27:44 -0700 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: [issue37] TBD - FE Protocol Attributes Thread-Index: AcVql+26phlZgxVJQIKLwr24vvyK6wAHJUcg X-OriginalArrivalTime: 06 Jun 2005 16:27:44.0716 (UTC) FILETIME=[AB1980C0:01C56AB4] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E058C8922@orsmsx408> Date: Mon, 6 Jun 2005 09:28:22 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable I had removed the detailed descriptions of the core LFBs from the model document for the very reason that Jamal has pointed out. However, we need to define the core LFBs to the point where we all feel confident that the protocol and the model will support at least the most common ones. I think we are mostly there, but would like to get other opinions as well. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 06, 2005 6:02 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue37] TBD - FE Protocol Attributes I am about 60% in agreement with Weiming. Infact, thats what i was stating before the last IETF meeting. I even have a draft called "Core LFBs" to prove it ;-> Actually the main valid reason that Weiming provides is #3. We need to get both the protocol and Model drafts to last call and moving this out will help speed things up. I believe the core LFBs should still be mentioned in the two drafts but not elucidated. cheers, jamal On Mon, 2005-06-06 at 15:15 +0800, Wang,Weiming wrote: > Joel, David, and Robert, >=20 > I have some thoughts, some by my experience with GRMP: > 1. Defining things like LFB attributes in details in the protocol docuement will > really leads the document to a comlex one. > 2. Currently, we may be a little far away from accurately defining these > attributes. > 3. Therefore, will eventually bottleneck the protocol document from going to > last call. >=20 > I actually incline to strip all that are related to LFB definitions from current > protocol docuement, while only leaving it for open discussion later that > "whether they go to model document or to a specific one for LFB definitions used > by protocol" . >=20 > Thanks, > Weiming > ----- Original Message ----- > From: "Putzolu, David" >=20 > (hat off) >=20 > The approach you propose Joel makes sense to me technically, and it is > also a nice partitioning of the work :) >=20 > -David >=20 >=20 > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Friday, June 03, 2005 11:29 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes >=20 > A reasonable question. >=20 > My current take is that the FE LFB should come with the model document, > and > the FE-protocol LFB should be defined by the protocol document. > However, this is something on which reasonable people can easily differ, >=20 > and I am open to alternatives. >=20 > Yours, > Joel >=20 > At 10:50 AM 6/3/2005, Weiming Wang wrote: > >It seems we need to first decide "who should define the LFBs like > FE-LFB, > >FE-protocol-LFB, this protocol document or elsewhere" before trying to >=20 > >decide this issue. > > > >thanks, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 20:50: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 UAA10562 for ; Mon, 6 Jun 2005 20:50:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfSdg-0004eG-Fj for forces-archive@IETF.ORG; Mon, 06 Jun 2005 21:12:22 -0400 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.0107284A@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 20:50:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74369765 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 20:50:17 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 20:50:17 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005060617534801:11883 ; Mon, 6 Jun 2005 17:53:48 -0700 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:53:48 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:53:49 PM, Serialize complete at 06/06/2005 05:53:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118105414.6320.30.camel@localhost.localdomain> Date: Mon, 6 Jun 2005 20:50:14 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050606111204.02d291a0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Mon, 2005-06-06 at 11:19 -0400, Joel M. Halpern wrote: > I tend to disagree. > > With regard to the FE LFB and the model draft, my concrete concern is that > a human being reading the model draft without the FE LFB will not > understand how a CE can actually make use of the model. We could just say > that there is an FE LFB (class 1, instance 1), that it has the basic > information the CE needs, and leave the details to another draft. But I am > pretty sure that will leave readers confused. As a minor related note, > including the FE LFB will give me an easy way to provide an example LFB > definition, including information about properties for access control. (I > won't be able to get alias in.) No aliases in general or just if FE LFB doesnt make it in? > I currently intend to also include some > events (LFB Creation, LFB Deletion, Capability change, are the ones I think > belong.) > This would be useful to show; but also if we can have some attribute change being shown as an event - it would be more complete. > With regard to the protocol, it is probably not as big an issue. After > all, we have a long tradition of putting instrumentation for protocols in > other documents (MIBs). The difference is that most protocols can run > without their MIB. Can we run the forces protocol without the Forces > Protocol LFB? (We can not run the model / protocol without the FE LFB.) The protocol needs the FE Protocol LFB from what ive seen so far. Lets put it this way, if it will _not_ delay the two main drafts from going last call, i have no objections to the two core LFBs to be split and merged in the protocol and Model LFB. My impression so far has been they are almost there. But reading Weiming's email i sense his opinion is that it's not ready at all. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 20:55: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 UAA10849 for ; Mon, 6 Jun 2005 20:54:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfShs-0004jJ-JU for forces-archive@IETF.ORG; Mon, 06 Jun 2005 21:16:40 -0400 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.010728F5@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 20:55:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74369860 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 20:54:58 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 20:54:58 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005060617582845:11887 ; Mon, 6 Jun 2005 17:58:28 -0700 Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:58:29 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/06/2005 05:58:31 PM, Serialize complete at 06/06/2005 05:58:31 PM Content-Type: multipart/mixed; boundary="=-zf0ne6ISeLGDsYQxyHed" Approved-By: Jamal Hadi Salim Message-ID: <1118105695.6320.34.camel@localhost.localdomain> Date: Mon, 6 Jun 2005 20:54:55 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Response formating To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 --=-zf0ne6ISeLGDsYQxyHed Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, In regards to section 3.3.1.2 Response formating which we didnt close before last release. There has been no text in the draft, but i have gathered discussion so far in text and i am attaching them. If people can read the text it and comment, it would help in closing this topic. cheers, jamal --=-zf0ne6ISeLGDsYQxyHed Content-Disposition: attachment; filename=operationresponse.txt Content-Type: text/plain; name=operationresponse.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit In the master slave-relationship the CE instructs one or more FEs on how to execute operations(sec 3.3.1.1 - Execution) and how to report back the results(3.3.1.2). This document captures discussions so far on response from FE->CE. Should be noted that there maybe extrenous schemes described here for completion sake more than religious opinion. We should pick schemes that will be sufficient to cover what are foreseen as the major cases. 3.xxx Responses: --------------- The CE expects the FE to report back the results of the 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) 3.xx.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 Use case: Allows sender to validate what was sent. **** Editorial note: Remove the above, consensus is that it seems to be rejected so far - just here temporarily incase someone needs it and missed the discussion. I cant remember the reason for rejection. Was it bandwidth consumption? Joel? 3.xx.2 Partial response: 3.xx.2.1 Basic In this scenario, the failed operations are returned in the PL message. For each failed operation that has failed, the operational flag is set to indicate an error. In the case of success, no operations are returned. a) If we allow the error codes being returned are simple pass/failed type then setting operational path flag level in my opinion should suffice. b) There should be a a shortcut in the main header flags which says "you need to look at the operational level further because we have errors". The NACK flag should suffice to indicate this in the main header. 3.xx.2.2 More than Basic Proposed by both Weiming and Joel: Introduce RESULT TLV to describe the results of a SET operation. The RESULT TLV will have more data in it than what 3.2.1 is proposing. Do these results make sense for DEL as well? The idea behind this is you want to know if the in the case of "Execute-until-failure" loose transaction or "continue-execute-on-failure" independent operations which one failed and why. 3.2.1 doesnt tell you why. Use case for 3.xx.2 : Useful when execution success is certain and reliable delivery since saves on bandwidth. 3.xx.3 brief or no notification a) One may not care at all about the SET result. b) one may care only to know if the PL message got at the other end. In which case a main header ACK to ensure that the FE received a message is sufficient. c) one may ask to be told only when theres an error that happened. Flags: NACK only Use case a) and b): Example unidirectional heartbeat. A more involved heartbeat would occasionally ask for acknowledgement or a full response(a pong to the ping). $Log: operationresponse.txt,v $ Revision 1.1 2005/06/06 17:37:18 hadi Initial revision Revision 1.1 2005/02/10 03:31:42 hadi Initial revision --=-zf0ne6ISeLGDsYQxyHed-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 6 21:40: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 VAA13465 for ; Mon, 6 Jun 2005 21:40:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfTQF-0005Z7-Gs for forces-archive@IETF.ORG; Mon, 06 Jun 2005 22:02:34 -0400 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.01072A1A@cherry.ease.lsoft.com>; Mon, 6 Jun 2005 21:40:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74372576 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Jun 2005 21:40:49 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 6 Jun 2005 21:40:49 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Tue, 7 Jun 2005 10:13:13 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Tue, 7 Jun 2005 09:38:48 +0800 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> <1118105414.6320.30.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <009c01c56b01$b6dd6870$1152010a@Necom.hzic.edu.cn> Date: Tue, 7 Jun 2005 09:39:15 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Jamal, ----- Original Message ----- From: "Jamal Hadi Salim" > > Lets put it this way, if it will _not_ delay the two main drafts from > going last call, i have no objections to the two core LFBs to be split > and merged in the protocol and Model LFB. My impression so far has been > they are almost there. But reading Weiming's email i sense his opinion > is that it's not ready at all. Note that we now only have names for most of the Core-LFB attributes. To make specific definitions for these attributes will still take a long way to go, I'm afraid. I tend to agree with you that IF it will not greatly block the process, to put the protocol LFB in the protocol draft is ok to me. As a resut, we then need to try to define them now. cheers, Weiming From BernieKirkpatrick@hippolite.com Mon Jun 6 21:42: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 VAA13573 for ; Mon, 6 Jun 2005 21:42:48 -0400 (EDT) From: BernieKirkpatrick@hippolite.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfTS9-0005b1-3A for forces-archive@ietf.org; Mon, 06 Jun 2005 22:04:30 -0400 Received: from 66-214-246-181.gln-mres.charterpipeline.net ([66.214.246.181]) by mx2.foretec.com with smtp (Exim 4.24) id 1DfT76-0002Zn-Fg for forces-archive@ietf.org; Mon, 06 Jun 2005 21:42:45 -0400 Received: from u[3 Message-Id: Date: Mon, 06 Jun 2005 21:42:45 -0400 X-Spam-Score: 1.5 (+) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 7 00:07: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 AAA21225 for ; Tue, 7 Jun 2005 00:07:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfViO-0008HM-DQ for forces-archive@IETF.ORG; Tue, 07 Jun 2005 00:29:30 -0400 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.01072E50@cherry.ease.lsoft.com>; Tue, 7 Jun 2005 0:07:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74381537 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jun 2005 00:07:25 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 7 Jun 2005 00:02:36 -0400 Received: from [69.170.5.95] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10780477; Tue, 07 Jun 2005 00:02:36 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> <1118105414.6320.30.camel@localhost.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.20050606224730.02d33c90@localhost> Date: Mon, 6 Jun 2005 22:57:30 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118105414.6320.30.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de I just can't come up with a good reason to use alias in the FE LFB, so there won't be an example of its use in the document. The definition and description of alias will be there, since the working group seems to have accepted the need. Yours, Joel At 08:50 PM 6/6/2005, Jamal Hadi Salim wrote: >No aliases in general or just if FE LFB doesnt make it in? From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 7 00:07: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 AAA21244 for ; Tue, 7 Jun 2005 00:07:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfViV-0008HM-R4 for forces-archive@IETF.ORG; Tue, 07 Jun 2005 00:29:33 -0400 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.01072E63@cherry.ease.lsoft.com>; Tue, 7 Jun 2005 0:07:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74381628 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jun 2005 00:07:31 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 7 Jun 2005 00:06:16 -0400 Received: from [69.170.5.95] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 10780502; Tue, 07 Jun 2005 00:06:16 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> <1118105414.6320.30.camel@localhost.localdomain> <009c01c56b01$b6dd6870$1152010a@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.1.2.0.20050607000447.02efe690@localhost> Date: Tue, 7 Jun 2005 00:06:12 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue37] TBD - FE Protocol Attributes Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009c01c56b01$b6dd6870$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c I must be missing something. For the FE LFB we have names, data types, and fairly good descriptions of most of the attributes. Those were in the last published model draft. They are basically the same as the ones in the FE Schema document, with cleanup. The events are going to take some work. But not an absurd amount of work. Yours, Joel At 09:39 PM 6/6/2005, Wang,Weiming wrote: >Note that we now only have names for most of the Core-LFB attributes. To make >specific definitions for these attributes will still take a long way to >go, I'm >afraid. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 7 05:44: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 FAA05050 for ; Tue, 7 Jun 2005 05:44:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfaxy-0006OZ-BW for forces-archive@IETF.ORG; Tue, 07 Jun 2005 06:05:51 -0400 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.010730D7@cherry.ease.lsoft.com>; Tue, 7 Jun 2005 5:43:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74396865 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jun 2005 05:43:44 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 7 Jun 2005 05:43:43 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j579gCHC015193 for ; Tue, 7 Jun 2005 11:42:14 +0200 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.622) Approved-By: avri@PSG.COM Message-ID: <6fd4b785452db9ce92e2ce2f878c927a@psg.com> Date: Tue, 7 Jun 2005 11:43:11 +0200 Reply-To: avri@psg.com Sender: Forwarding and Control Element Separation From: avri@psg.com Subject: draft-ietf-forces-protocol-03.txt To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Hi, on june 02 i tried to submit the latest draft to the id editor. but it was rejected because i mentioned rfc 3668 instead of bcp79. unfortunately i was away from email and did not see this rejection until this morning. i have resubmitted it. and hopefully this time have correctly dealt with the bureaucratic minutia. but in case i haven't, or in the meantime, a copy can be found in: http://psg.com/~avri/forces/draft-ietf-forces-protocol-03.txt a. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 7 08: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 IAA19532 for ; Tue, 7 Jun 2005 08:42:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfdkI-00025D-PU for forces-archive@IETF.ORG; Tue, 07 Jun 2005 09:03:59 -0400 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.01073382@cherry.ease.lsoft.com>; Tue, 7 Jun 2005 8:42:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74449595 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jun 2005 08:42:06 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 7 Jun 2005 08:42:06 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005060705453809:12325 ; Tue, 7 Jun 2005 05:45:38 -0700 References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> <1118105414.6320.30.camel@localhost.localdomain> <6.2.1.2.0.20050606224730.02d33c90@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/07/2005 05:45:38 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/07/2005 05:45:39 AM, Serialize complete at 06/07/2005 05:45:39 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118148125.6320.111.camel@localhost.localdomain> Date: Tue, 7 Jun 2005 08:42:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050606224730.02d33c90@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On Mon, 2005-06-06 at 22:57 -0400, Joel M. Halpern wrote: > I just can't come up with a good reason to use alias in the FE LFB, so > there won't be an example of its use in the document. The definition and > description of alias will be there, since the working group seems to have > accepted the need. > What about the idea of publishing a NOOP LFB that could be used as an exercise for demonstrating the different semantics? We already had such a LFB initially to demonstrate a few things and was used for basic interop back in San Diego. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 7 12:26:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07909 for ; Tue, 7 Jun 2005 12:26:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfhFO-00072v-TO for forces-archive@IETF.ORG; Tue, 07 Jun 2005 12:48:26 -0400 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.0107369F@cherry.ease.lsoft.com>; Tue, 7 Jun 2005 11:40:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74467280 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Jun 2005 11:40:32 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 7 Jun 2005 11:40:30 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Wed, 8 Jun 2005 00:13:01 +0800 (CST) References: <003701c56a67$7ec9b050$1152010a@Necom.hzic.edu.cn> <1118062910.6266.187.camel@localhost.localdomain> <6.2.1.2.0.20050606111204.02d291a0@localhost> <1118105414.6320.30.camel@localhost.localdomain> <009c01c56b01$b6dd6870$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050607000447.02efe690@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: <008401c56b77$d33d3010$020aa8c0@wwm1> Date: Tue, 7 Jun 2005 23:44:43 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: base64 Sm9lbCwNCg0KU29ycnkuIFllcywgdGhlIEZFIExGQiBoYXMgbW9yZSBkb25lIHRoYW4gdGhlIHBy b3RvY29sIExGQi4gSSBtb3JlIG1lYW50IHRoZSBwcm90b2NvbCBMRkIuICBXaGF0IEknbSBhIGxp dHRsZSB3b3JyaWVkIHRoZSB3YXkgdGhlIExGQiBkZWZpbml0aW9uIG1heSBkZWxheSB0aGUgcHJv dG9jb2wgbGllcyBpbjoNCg0KMS4gU29tZSBvZiB0aGUgYXR0cmlidXRlcyBtYXkgaGlnaGx5IHJl bGF0ZSB0byBvdGhlciBkZWZpbml0aW9ucywgbGlrZSBUTUwgZGVmaW5pdGlvbnMuIFRoaXMgbWVh bnMgaXQgIHRpZ2h0bHkgdGllcyB0aGUgcHJvdG9jb2wgd29yayB0byB0aGVtLCAgSSB0aGluayB3 ZSBzaG91bGQgb25seSBoYXZlIGEgbG9vc2UgdGllLiBBbmQgc29tZSBhdHRyaWJ1dGVzIG1heSBi ZSBxdWl0ZSBoYXJkIHRvIGdvIHRvIHRoZSBiaXQgbGV2ZWwgZGVmaW5pdGlvbnMgY3VycmVudGx5 Lg0KDQoyLiBUbyBwdXQgdGhlIGF0dHJpYnV0ZSBkZWZpbml0aW9ucyBpbiB0aGUgcHJvdG9jb2wg YWxzbyBsaW1pdHMgdGhlIGF0dHJpYnV0ZXMgdG8gd2hhdCB3ZSBjYW4gdGhpbmsgb2YgY3VycmVu dGx5LiAgVGhlIGV4dGVuc2lvbiBtYXkgYmVjb21lIGEgcHJvYmxlbS4gQW5kIHdlIG1heSBhbHNv IGhhdmUgbXVjaCBhcmd1ZW1lbnQgb2Ygd2hpY2ggYXR0cmlidXRlIHNob3VsZCBiZSBkZWZpbmVk LiANCg0KWWVzLCB5b3UgbWVudGlvbmVkIG1hbnkgcHJvdG9jb2xzIG1heSBydW4gd2l0aG91dCBN SUJzLiAgV2hlcmVhcyBJJ20gc2ltcGx5IHRyeWluZyB0byBzZWUgdGhlIHBvc3NpYmlsaXR5IG9m IGEgcmVsYXRpb24gbGlrZSBhbiBJUCBwcm90b2NvbCB3aXRoIHRoZSBBc3NpZ25lZCBOdW1iZXIs IHRob3VnaHQgSSdtIG5vdCB2ZXJ5IHN1cmUgb2YgdGhlIGlkZWEuDQoNCnRoYW5rcywNCldlaW1p bmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhhbHBl cm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0Bt YWlsLnpqZ3N1LmVkdS5jbj47IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQpTZW50OiBU dWVzZGF5LCBKdW5lIDA3LCAyMDA1IDEyOjA2IFBNDQpTdWJqZWN0OiBSZTogW2lzc3VlMzddIFRC RCAtIEZFIFByb3RvY29sIEF0dHJpYnV0ZXMNCg0KDQo+IEkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0 aGluZy4gIEZvciB0aGUgRkUgTEZCIHdlIGhhdmUgbmFtZXMsIGRhdGEgdHlwZXMsIGFuZCANCj4g ZmFpcmx5IGdvb2QgZGVzY3JpcHRpb25zIG9mIG1vc3Qgb2YgdGhlIGF0dHJpYnV0ZXMuICBUaG9z ZSB3ZXJlIGluIHRoZSBsYXN0IA0KPiBwdWJsaXNoZWQgbW9kZWwgZHJhZnQuICBUaGV5IGFyZSBi YXNpY2FsbHkgdGhlIHNhbWUgYXMgdGhlIG9uZXMgaW4gdGhlIEZFIA0KPiBTY2hlbWEgZG9jdW1l bnQsIHdpdGggY2xlYW51cC4NCj4gDQo+IFRoZSBldmVudHMgYXJlIGdvaW5nIHRvIHRha2Ugc29t ZSB3b3JrLiAgQnV0IG5vdCBhbiBhYnN1cmQgYW1vdW50IG9mIHdvcmsuDQo+IA0KPiBZb3VycywN Cj4gSm9lbA0KPiANCj4gQXQgMDk6MzkgUE0gNi82LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZToN Cj4gPk5vdGUgdGhhdCB3ZSBub3cgb25seSBoYXZlIG5hbWVzIGZvciBtb3N0IG9mIHRoZSBDb3Jl LUxGQiBhdHRyaWJ1dGVzLiBUbyBtYWtlDQo+ID5zcGVjaWZpYyBkZWZpbml0aW9ucyBmb3IgdGhl c2UgYXR0cmlidXRlcyB3aWxsIHN0aWxsIHRha2UgYSBsb25nIHdheSB0byANCj4gPmdvLCBJJ20N Cj4gPmFmcmFpZC4NCj4gDQo+IA== From JanellRivas@tribometer.com Tue Jun 7 12:34: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 MAA09291 for ; Tue, 7 Jun 2005 12:34:32 -0400 (EDT) From: JanellRivas@tribometer.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfhN9-0007MH-SV for forces-archive@ietf.org; Tue, 07 Jun 2005 12:56:22 -0400 Received: from [211.219.92.43] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dfh1z-0001wY-RY for forces-archive@ietf.org; Tue, 07 Jun 2005 12:34:24 -0400 Received: from o[3 Message-Id: Date: Tue, 07 Jun 2005 12:34:24 -0400 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 8 11:33: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 LAA10025 for ; Wed, 8 Jun 2005 11:33:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg2tV-0007IF-9f for forces-archive@IETF.ORG; Wed, 08 Jun 2005 11:55:09 -0400 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.01075533@cherry.ease.lsoft.com>; Wed, 8 Jun 2005 11:32:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74619498 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Jun 2005 11:32:55 -0400 Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 8 Jun 2005 11:32:54 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id j58FVHHC017662 for ; Wed, 8 Jun 2005 17:31:17 +0200 Mime-Version: 1.0 (Apple Message framework v622) References: <1117783240.68.0.897387957284.issue43@mip4.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.622) Approved-By: avri@PSG.COM Message-ID: <2a93cfd657e15ad456f7a4c7541fda7f@psg.com> Date: Wed, 8 Jun 2005 17:32:26 +0200 Reply-To: avri@psg.com Sender: Forwarding and Control Element Separation From: avri@psg.com Subject: Re: [issue43] Editorial- change GET to SET in section 6.5 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1117783240.68.0.897387957284.issue43@mip4.org> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit fixed in -03 a. From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 08:56:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25158 for ; Thu, 9 Jun 2005 08:56:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgMw0-00015u-4D for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:19:00 -0400 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.010766CD@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 8:56:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74730462 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 08:56:42 -0400 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 08:56:41 -0400 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 j59Cufew085680 for ; Thu, 9 Jun 2005 12:56:41 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j59CueGc176424 for ; Thu, 9 Jun 2005 14:56:40 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j59Cue7T006252 for ; Thu, 9 Jun 2005 14:56:40 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j59CueBu006242; Thu, 9 Jun 2005 14:56:40 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA104904; Thu, 9 Jun 2005 14:56:39 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6fd4b785452db9ce92e2ce2f878c927a@psg.com> 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 j59Cufew085680 Approved-By: Robert Haas Message-ID: <42A83C6E.8060304@zurich.ibm.com> Date: Thu, 9 Jun 2005 14:56:14 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: draft-ietf-forces-protocol-03.txt Comments: To: avri@psg.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6fd4b785452db9ce92e2ce2f878c927a@psg.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable Hi Avri, All, I took a fresh look at the draft and noted the following errors and/or=20 inconsistencies. Regards, -Robert Sec 3.3.2 FE, CE, and FE protocol LFBs syntax problem: All PL messages follow the LFB structure as this provides more=20 flexibility for future enhancements. This means maintanance and=20 configurability of FEs, NE, as well as the protocol require a fit in the=20 LFB architecture. For this reason special LFBs are created to accomodate=20 this need. I would rephrase the paragraph as follows (hopefully more clear :) All PL messages operate on LFB structures as this provides more=20 flexibility for future enhancements. This means that maintenance and=20 configurability of FEs, NE, as well as the ForCES protocol itself must=20 be expressed in terms of this LFB architecture. For this reason special=20 LFBs are created to accomodate this need. typo: The FE Protocol LFB also contains the various ForCES ID to be used:=20 unicast IDs a table of the PL multicast IDs the FE must be listening to. =20 ^ add "and" after=20 "unicast IDs". Sec 4 TML Requirements As an example they could be defined to be delivered via hardware or=20 inter- TML protocol level schemes. =20 ^ where did we define what=20 "inter-TML" means ? It is expected that the TML will be able to handle up to 8 priority=20 levels needed by the PL layer and will provide preferential treatment. =20 ^ writing "up to" means that the TML may support no priorities at=20 all too. Is this what we intended to say ? Sec 5.1 Common Header Sequence [number is] Unique to a PDU. So a response message will have a different sequence number than the=20 original request message. This is OK as long as nobody tries to use the=20 Sequence number as a correlator for request/responses ... Sec 6.1.1.1.1 Data Packing Rules Sorry, but the paragraph below is far from clear ... maybe correct=20 "PATH flags" instead of "SELECTOR flags" as there are no flags defined=20 in the SELECTOR. But this remains still obscure. When a table is refered in the PATH (ids), then the RAWDATA's V will=20 contain that tables row content prefixed by its 32 bit index/ subscript=20 OTOH, when SELECTOR flags are 00, the PATH may contain an index pointing=20 to a row in table; in such a case, the RAWDATA's V will only contain the=20 content with the index in order to avoid ambiguity. Sec 6.1.1.1.6 SET and GET Relationship I had a syntax error reading the sentence below ... 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing=20 the T to be SET will endup overwritting the table. Fig. 11: Sample operation layout Why is the path-data segmented 3 times for the SET-CREATE operation ? I=20 thought that this was necessary only each time a different KEY was used ? Sec 6.3 Semantics of message Direction Note that the semantics of the message direction are different for=20 event notifications originated at the CE LFB: in that case the LFB=20 selector points to the event of the CE. Sec 6.4.2 Association Setup Response Message There is no reason to have SHOW operations about the FE object and/or=20 FE protocol object here. I don't understand this and would rather use a=20 separate CONFIG message to set the HBI ,for instance. 6.4.3 Association Teardown Message What is this new operation type FEReason ? 6.10 Operation Summary In the table, change "Event" in the "Operation" column by "Report" in=20 order to be consistent with the prior descriptions. avri@psg.com wrote: > Hi, > > on june 02 i tried to submit the latest draft to the id editor. but=20 > it was rejected because i mentioned rfc 3668 instead of bcp79. =20 > unfortunately i was away from email and did not see this rejection=20 > until this morning. > > i have resubmitted it. and hopefully this time have correctly dealt=20 > with the bureaucratic minutia. but in case i haven't, or in the=20 > meantime, a copy can be found in: > http://psg.com/~avri/forces/draft-ietf-forces-protocol-03.txt > > a. > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 08:57:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25219 for ; Thu, 9 Jun 2005 08:57:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgMx6-0001A1-G7 for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:20:09 -0400 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.010766CD@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 8:57:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74730520 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 08:57:55 -0400 Received: from 195.212.29.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 08:57:55 -0400 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 j59CvsFu110108 for ; Thu, 9 Jun 2005 12:57:54 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j59CvsGc163282 for ; Thu, 9 Jun 2005 14:57:54 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j59CvrvH019204 for ; Thu, 9 Jun 2005 14:57:53 +0200 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 j59CvrKX019193; Thu, 9 Jun 2005 14:57:53 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA105038; Thu, 9 Jun 2005 14:57:53 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1116788453.17.0.150373334311.issue40@mip4.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id j59CvsFu110108 Approved-By: Robert Haas Message-ID: <42A83CB3.3080608@zurich.ibm.com> Date: Thu, 9 Jun 2005 14:57:23 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue40] BLKINFO Comments: cc: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1116788453.17.0.150373334311.issue40@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable I just re-read the relevant thread =C3=A0 propos BLOCK selector. It seems= =20 that besides Jamal and myself, nobody else declared whether the proposal=20 (repeated below) would be satisfactory and should be included in the=20 draft. Please let us know. Regards, -Robert From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": As an alternative, couldn't we just add a flag to the BLOCK selector to=20 distinguish the two cases ? - BLOCK REPLICATE, with only the all-to-all semantic - BLOCK LIST, with only the one-to-one semantic. So while processing a ForCES message, one does not have to infer the=20 meaning of BLOCK based on the content (is it all-to-all or one-to-one).=20 Instead the flag will tell immediately. =20 Avri Doria wrote: >New submission from Avri Doria : > >* NOTE! NOTE! There is a selector known as BLKINFO that is left > out of this doc for now that will be revisted later. BLKINFO > is defined as: > * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=3D > [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A > PathData can only have one selector either a KEYINFO TLV or a > BLKINFO TLV (i.e not both). > >Revisit before PS or after? > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 58 >nosy: avri >priority: May fix >status: No discussion >title: BLKINFO > >___________________________________________________ >Forces issue tracker > >___________________________________________________ > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=C3=A4umerstrasse 4 CH-8803 R=C3=BCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 09:04:25 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25935 for ; Thu, 9 Jun 2005 09:04:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgN38-0001Kq-US for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:26:38 -0400 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.01076806@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 9:04:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74731120 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 09:04:09 -0400 Received: from 207.69.195.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 09:04:09 -0400 Received: from dialup-4.249.9.254.dial1.washington2.level3.net ([4.249.9.254] helo=JMHLap3.stevecrocker.com) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgMhZ-0006pp-00; Thu, 09 Jun 2005 09:04:07 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 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.20050609090338.02d1cf28@localhost> Date: Thu, 9 Jun 2005 09:03:59 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue40] BLKINFO Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable I am still not convinced of the value, and would prefer to defer BLOCK=20 constructs until we have some experience to know what enhancements we=20 really need. Yours, Joel At 08:57 AM 6/9/2005, Robert Haas wrote: >I just re-read the relevant thread =C3 propos BLOCK selector. It seems= that=20 >besides Jamal and myself, nobody else declared whether the proposal=20 >(repeated below) would be satisfactory and should be included in the=20 >draft. Please let us know. >Regards, >-Robert > > From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": > >As an alternative, couldn't we just add a flag to the BLOCK selector to=20 >distinguish the two cases ? > >- BLOCK REPLICATE, with only the all-to-all semantic >- BLOCK LIST, with only the one-to-one semantic. > >So while processing a ForCES message, one does not have to infer the=20 >meaning of BLOCK based on the content (is it all-to-all or one-to-one).=20 >Instead the flag will tell immediately. > > >Avri Doria wrote: > >>New submission from Avri Doria : >> >>* NOTE! NOTE! There is a selector known as BLKINFO that is left >> out of this doc for now that will be revisted later. BLKINFO >> is defined as: >> * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=3D >> [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A >> PathData can only have one selector either a KEYINFO TLV or a >> BLKINFO TLV (i.e not both). >> >>Revisit before PS or after? >> >>---------- >>category: Editorial >>draft: draft-ietf-forces-protocol >>messages: 58 >>nosy: avri >>priority: May fix >>status: No discussion >>title: BLKINFO >> >>___________________________________________________ >>Forces issue tracker >> >>___________________________________________________ >> >> >> > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=C3=A4umerstrasse 4 >CH-8803 R=C3=BCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 09:06:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26222 for ; Thu, 9 Jun 2005 09:06:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgN59-0001QI-PE for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:28:30 -0400 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.0107696B@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 9:06:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74731243 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 09:06:06 -0400 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 09:06:05 -0400 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 j59D65ew169812 for ; Thu, 9 Jun 2005 13:06:05 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j59D64Gc168088 for ; Thu, 9 Jun 2005 15:06:04 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j59D64rv019063 for ; Thu, 9 Jun 2005 15:06:04 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j59D64JG019060 for ; Thu, 9 Jun 2005 15:06:04 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA102056 for ; Thu, 9 Jun 2005 15:06:03 +0200 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> 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 j59D65ew169812 Approved-By: Robert Haas Message-ID: <42A83EA2.80905@zurich.ibm.com> Date: Thu, 9 Jun 2005 15:05:38 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Multiple processes in the CE talking to the same FE LFBs To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4212130D.4040601@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Re-reading the draft I realize that we show in Fig. 2 how multiple=20 processes (OSPF, RIP, etc) interface with the ForCES layer, but we never=20 explain how the demuxing occurs. Some exchanges in this old thread=20 suggested to use PL sequence number, PL message types, and/or LFB=20 Instance IDs as a means to correlate and demux a ForCES response to the=20 appropriate process that sent the request. One could even store the=20 entire request messages and event registrations in order to match=20 responses appropriately. Such solutions are mere by-products (not to say=20 hacks ;-) Another solution consists in adding a correlator in the CE-originated PL=20 messages that must be returned in the FE responses and event notification= s. I am interested to hear how others have addressed this issue. Regards, -Robert Robert Haas wrote: > Hormuzd, > > Khosravi, Hormuzd M wrote: > >> Robert, >> >> My comments on this inline.... >> -----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=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). >> >> [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 lay= er >> would take care of translating requests from different processes to >> different ForCES protocol message types, sequence nos, etc. Let me kno= w >> 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=20 > useful when you want to direct an event notification coming from the=20 > FE to the appropriate process in the CE. But maybe you found a way to=20 > 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=20 >> while defining the model. Although the requirements draft only talks=20 >> of a single active CE for each FE, it is a scalability issue if I=20 >> can't run the firewalling and routing processes on two different=20 >> boxes (i.e. two CEs). So let's at least consider the impact of the=20 >> 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. Th= at >> 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 protoco= l. >> >> =20 >> > I would treat this the same way we treated the keys: make provision=20 > for multi-CE support in the model as early as possible as it may=20 > otherwise 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=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. > > Regards, > -Robert > >> Regards >> Hormuzd >> >> Joel M. Halpern wrote: >> >> =20 >> >>> I thought we had agreed that for now we would focus on a single activ= e >>> =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-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 09:09:25 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26766 for ; Thu, 9 Jun 2005 09:09:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgN8D-0001ZT-5z for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:31:38 -0400 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.0107672B@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 9:09:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74731378 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 09:09:21 -0400 Received: from 207.69.195.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 09:09:21 -0400 Received: from dialup-4.249.9.254.dial1.washington2.level3.net ([4.249.9.254] helo=JMHLap3.stevecrocker.com) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgMme-0000R3-00 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 09 Jun 2005 09:09:21 -0400 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.20050609090530.02d696b0@localhost> Date: Thu, 9 Jun 2005 09:09:15 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Protocol Document TML Description To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The protocol document, in section 3.1.2 states: However, since each TML is standardized, interoperability is guaranteed as long as both endpoints support the same TML. That is not out usual definition of interoperability. In order to actually ensure interoperability, we must have (at least) one mandatory to implement TML. This document should say that. I believe that the mandatory to implement TML will need to include congestion control for both the control and FE-CE data paths. Given the (quite reasonable) objections that have been raised to shipping the data packets over TCP or SCTP, it seems to me that the only reasonable choice for the mandatory to implement TML is TCP or SCTP for the control aspect, and DCCP for the data forwarding aspect. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 9 09:22:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28529 for ; Thu, 9 Jun 2005 09:22:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNL3-0002W2-DE for forces-archive@IETF.ORG; Thu, 09 Jun 2005 09:44:53 -0400 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.0107672C@cherry.ease.lsoft.com>; Thu, 9 Jun 2005 9:22:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74731897 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 9 Jun 2005 09:22:40 -0400 Received: from 207.69.195.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 9 Jun 2005 09:22:40 -0400 Received: from dialup-4.249.9.254.dial1.washington2.level3.net ([4.249.9.254] helo=JMHLap3.stevecrocker.com) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgMzW-0003dG-00 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 09 Jun 2005 09:22:39 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> <42A83EA2.80905@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.20050609091506.02f5fc88@localhost> Date: Thu, 9 Jun 2005 09:22:31 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Multiple processes in the CE talking to the same FE LFBs To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42A83EA2.80905@zurich.ibm.com> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable I don;t think there should be higher layer demux in the sense below. I believe that the ForCES messges will need to be processed by the ForCES=20 interface, turned into meaningful information for the CE internal=20 activities, and passed on to the relevant component(s). In general, I think that the selection of which component is interested in= =20 ForCES information is going to be based on semantics, not on demux=20 identifiers in the message. Note that specifically as drawn in the diagram it would be exceedingly=20 unlikely for OSPF, RIP, and BGP to interact directly with LFBs. They will= =20 interact with some form of RIB, which in turn (at least logically) drives=20 some sort of FIB process. To carry the example further, if one also has MPLS one can easily imagine=20 FE notifications which are of interest to both the FIB and LIB=20 activities. and the FE would have no reasonable way of even knowing=20 that. Explicit demux seems the wrong answer. On the other hand, Request - Response correlators are a very good idea, for= =20 many reasons. Yours, Joel M. Halpern At 09:05 AM 6/9/2005, Robert Haas wrote: >Re-reading the draft I realize that we show in Fig. 2 how multiple=20 >processes (OSPF, RIP, etc) interface with the ForCES layer, but we never=20 >explain how the demuxing occurs. Some exchanges in this old thread=20 >suggested to use PL sequence number, PL message types, and/or LFB Instance= =20 >IDs as a means to correlate and demux a ForCES response to the=20 >appropriate process that sent the request. One could even store the entire= =20 >request messages and event registrations in order to match responses=20 >appropriately. Such solutions are mere by-products (not to say hacks ;-) > >Another solution consists in adding a correlator in the CE-originated PL=20 >messages that must be returned in the FE responses and event notifications. > >I am interested to hear how others have addressed this issue. > >Regards, >-Robert > > >Robert Haas wrote: > >>Hormuzd, >> >>Khosravi, Hormuzd M wrote: >> >>>Robert, >>> >>>My comments on this inline.... >>>-----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? >>> >>How far did you go with your implementation of demuxing ? In our case, we= =20 >>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 implementation= =20 >>issues, but protocol issues too. I doubt we can get the protocol right on= =20 >>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. >>> >>> >>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 only= =20 >>indicate with a boolean if a CE has registered to be notified when the=20 >>event occurs, but also include a list of the CEs that have registered for= =20 >>the same event. Limited complexity for the model, almost no additional=20 >>complexity for the protocol. >> >>Regards, >>-Robert >> >>>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. >>>> >>>> >>> >>> >>> >>> > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 00:07:40 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17593 for ; Fri, 10 Jun 2005 00:07:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgb9a-0001WM-3j for forces-archive@IETF.ORG; Fri, 10 Jun 2005 00:30:02 -0400 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.010776D0@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 0:07:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74810117 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 00:07:27 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 00:07:14 -0400 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 j5A47D1T000975; Fri, 10 Jun 2005 04:07:13 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 j5A479Ru027387; Fri, 10 Jun 2005 04:07:13 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005060921071032674 ; Thu, 09 Jun 2005 21:07:10 -0700 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, 9 Jun 2005 21:07:09 -0700 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] [issue40] BLKINFO Thread-Index: AcVs88IVguH7/JhnQQOmZQR63d+/zwAQ9BJA X-OriginalArrivalTime: 10 Jun 2005 04:07:09.0530 (UTC) FILETIME=[DF5133A0:01C56D71] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Thu, 9 Jun 2005 21:07:08 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: [issue40] BLKINFO Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable (hat off)=20 I am in agreement with Joel, I'd prefer to only add optimizations after = we get some operational experience that shows where the bottlenecks = really are. -David -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 09, 2005 6:04 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue40] BLKINFO I am still not convinced of the value, and would prefer to defer BLOCK=20 constructs until we have some experience to know what enhancements we=20 really need. Yours, Joel At 08:57 AM 6/9/2005, Robert Haas wrote: >I just re-read the relevant thread =C3 propos BLOCK selector. It seems = that=20 >besides Jamal and myself, nobody else declared whether the proposal=20 >(repeated below) would be satisfactory and should be included in the=20 >draft. Please let us know. >Regards, >-Robert > > From the thread titled "2005 Teleconf minutes (BLOCK semantics, etc)": > >As an alternative, couldn't we just add a flag to the BLOCK selector to = >distinguish the two cases ? > >- BLOCK REPLICATE, with only the all-to-all semantic >- BLOCK LIST, with only the one-to-one semantic. > >So while processing a ForCES message, one does not have to infer the=20 >meaning of BLOCK based on the content (is it all-to-all or one-to-one). = >Instead the flag will tell immediately. > > >Avri Doria wrote: > >>New submission from Avri Doria : >> >>* NOTE! NOTE! There is a selector known as BLKINFO that is left >> out of this doc for now that will be revisted later. BLKINFO >> is defined as: >> * SELECTOR :=3D KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV = :=3D >> [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A >> PathData can only have one selector either a KEYINFO TLV or a >> BLKINFO TLV (i.e not both). >> >>Revisit before PS or after? >> >>---------- >>category: Editorial >>draft: draft-ietf-forces-protocol >>messages: 58 >>nosy: avri >>priority: May fix >>status: No discussion >>title: BLKINFO >> >>___________________________________________________ >>Forces issue tracker >> >>___________________________________________________ >> >> >> > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=C3=A4umerstrasse 4 >CH-8803 R=C3=BCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 = http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:08:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22690 for ; Fri, 10 Jun 2005 04:08:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgeug-0000Ij-5u for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:30:50 -0400 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.01077A51@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:08:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74819760 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:08:01 -0400 Received: from 81.228.9.179 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:08:01 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7D1A837E93; Fri, 10 Jun 2005 10:08:00 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D3E0837E68 for ; Fri, 10 Jun 2005 10:07:59 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B9BDA37E4E for ; Fri, 10 Jun 2005 10:07:59 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgeYY-00043k-Hm for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:07:59 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.2 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118390878.5.0.704863577436.issue44@mip4.org> Date: Fri, 10 Jun 2005 08:07:58 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue44] FE, CE, and FE protocol LFBs To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 3.3.2 FE, CE, and FE protocol LFBs syntax problem: All PL messages follow the LFB structure as this provides more flexibility = for=20 future enhancements. This means maintanance and configurability of FEs, NE,= as=20 well as the protocol require a fit in the LFB architecture. For this reason=20 special LFBs are created to accomodate this need. I would rephrase the paragraph as follows (hopefully more clear :) All PL messages operate on LFB structures as this provides more flexibility=20 for future enhancements. This means that maintenance and configurability of=20 FEs, NE, as well as the ForCES protocol itself must be expressed in terms o= f=20 this LFB architecture. For this reason special LFBs are created to accomoda= te=20 this need. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 101 nosy: rha priority: Should fix status: Text proposed title: FE, CE, and FE protocol LFBs ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:11:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22813 for ; Fri, 10 Jun 2005 04:11:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgexZ-0000Sh-Qn for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:33:50 -0400 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.010779EE@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:11:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74819888 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:11:06 -0400 Received: from 81.228.9.186 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:11:06 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 64FD837F2D; Fri, 10 Jun 2005 10:11:05 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8955B37E72 for ; Fri, 10 Jun 2005 10:11:04 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7A39F37E47 for ; Fri, 10 Jun 2005 10:11:04 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgebX-0004R7-IJ for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:11:04 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.3 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391063.51.0.959571096158.issue45@mip4.org> Date: Fri, 10 Jun 2005 08:11:03 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue45] Definition of inter-TML protocol level schemes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 4 TML Requirements [=2E..] As an example they could be defined to be delivered via hardware or inter- = TML=20 protocol level schemes. = =20 Where did we define what "inter-TML" means ? ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 102 nosy: rha priority: Should fix status: No discussion title: Definition of inter-TML protocol level schemes ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:13:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22910 for ; Fri, 10 Jun 2005 04:13:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgezz-0000bV-8q for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:36:21 -0400 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.010779D7@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:13:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820007 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:13:56 -0400 Received: from 81.228.8.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:13:56 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 5F98A37EEA; Fri, 10 Jun 2005 10:13:55 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2E2C137E64 for ; Fri, 10 Jun 2005 10:13:55 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 1EE2637E43 for ; Fri, 10 Jun 2005 10:13:55 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgeeE-0001Z4-Iv for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:13:51 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.3 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391230.52.0.873977345714.issue46@mip4.org> Date: Fri, 10 Jun 2005 08:13:50 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue46] Up to 8 priorities supported by the TML To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 4 [=2E..] It is expected that the TML will be able to handle up to 8 priority levels=20 needed by the PL layer and will provide preferential treatment. Writing "up to" means that the TML may support no priorities at all too. Is=20 this what we intended to say ? Clarify and write MAY, SHOULD or MUST. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 103 nosy: rha priority: Should fix status: No discussion title: Up to 8 priorities supported by the TML ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:16:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23020 for ; Fri, 10 Jun 2005 04:16:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgf2u-0000if-32 for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:39:21 -0400 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.01077A37@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:16:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820098 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:16:57 -0400 Received: from 81.228.8.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:16:57 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 7883237F7A; Fri, 10 Jun 2005 10:16:55 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id BB98937F6F for ; Fri, 10 Jun 2005 10:16:55 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id A62A037E4F for ; Fri, 10 Jun 2005 10:16:55 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgehC-0001i8-1r for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:16:54 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.3 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391414.0.0.575560248379.issue47@mip4.org> Date: Fri, 10 Jun 2005 08:16:54 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue47] PDU sequence number, use of correlator To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 5.1 Common Header [=2E..] Sequence [number is] Unique to a PDU. So a response message will have a different sequence number than the origin= al=20 request message. This is OK as long as nobody tries to use the Sequence num= ber=20 as a correlator for request/responses ... Should we introduce a request/response correlator ? ---------- category: Technical draft: draft-ietf-forces-protocol messages: 104 nosy: rha priority: Should fix status: No discussion title: PDU sequence number, use of correlator ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:18:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23214 for ; Fri, 10 Jun 2005 04:18:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgf4r-0000ly-GH for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:41:21 -0400 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.010779FB@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:18:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820162 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:18:58 -0400 Received: from 81.228.9.181 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:18:58 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id A958B37ED7; Fri, 10 Jun 2005 10:18:57 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B18A537F75 for ; Fri, 10 Jun 2005 10:18:56 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A3AEA37E44 for ; Fri, 10 Jun 2005 10:18:56 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dgej9-0001j3-2F for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:18:55 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.3 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391535.01.0.666100966761.issue48@mip4.org> Date: Fri, 10 Jun 2005 08:18:55 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue48] Data Packing Rules: addressing tables To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.1 Data Packing Rules [=2E..] When a table is refered in the PATH (ids), then the RAWDATA's V will contai= n=20 that tables row content prefixed by its 32 bit index/ subscript OTOH, when=20 SELECTOR flags are 00, the PATH may contain an index pointing to a row in=20 table; in such a case, the RAWDATA's V will only contain the content with t= he=20 index in order to avoid ambiguity.=20 This paragraph is far from clear ... maybe correct "PATH flags" instead=20 of "SELECTOR flags" as there are no flags defined in the SELECTOR. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 105 nosy: rha priority: Should fix status: No discussion title: Data Packing Rules: addressing tables ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:20:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23328 for ; Fri, 10 Jun 2005 04:20:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgf5x-0001Dx-6c for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:42:29 -0400 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.010779FD@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:20:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820195 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:20:02 -0400 Received: from 81.228.8.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:20:02 -0400 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id C217737F84; Fri, 10 Jun 2005 10:20:01 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8B28337F5A for ; Fri, 10 Jun 2005 10:20:01 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7CD4D37E44 for ; Fri, 10 Jun 2005 10:20:01 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgekA-0001jV-8q for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:20:01 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.3 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391598.23.0.795873222023.issue49@mip4.org> Date: Fri, 10 Jun 2005 08:19:58 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue49] Sec 6.1.1.1.6 SET and GET Relationship To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.6 SET and GET Relationship [=2E..] 2=2E When dumping a whole table in a GET, the GET-RESPONSE, merely editing = the T=20 to be SET will endup overwritting the table. I had a syntax error reading the sentence above ... ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 106 nosy: rha priority: Should fix status: No discussion title: Sec 6.1.1.1.6 SET and GET Relationship ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:21:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23426 for ; Fri, 10 Jun 2005 04:21:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgf7e-00028M-KI for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:44:15 -0400 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.01077A3F@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:21:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820372 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:21:51 -0400 Received: from 81.228.9.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:21:51 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id ED8A637F3A; Fri, 10 Jun 2005 10:21:50 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3B2B337F23 for ; Fri, 10 Jun 2005 10:21:50 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 2B06137E4D for ; Fri, 10 Jun 2005 10:21:50 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dgelx-0001pH-2h for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:21:49 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.4 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391708.28.0.709547895509.issue50@mip4.org> Date: Fri, 10 Jun 2005 08:21:48 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Sec 6.1.1.1.6 SET and GET Relationship [=2E..] Fig. 11: Sample operation layout Why is the path-data segmented 3 times for the SET-CREATE operation ? I=20 thought that this was necessary only each time a different KEY was used ? May need a better example ... ---------- category: Technical draft: draft-ietf-forces-protocol messages: 107 nosy: rha priority: Should fix status: No discussion title: Fig.11 Sample operation layout: successive breakdown of the path-data ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 04:23:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23512 for ; Fri, 10 Jun 2005 04:23:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgf8r-0002IO-VE for forces-archive@IETF.ORG; Fri, 10 Jun 2005 04:45:31 -0400 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.0107794D@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 4:23:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74820407 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 04:23:07 -0400 Received: from 81.228.8.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 04:23:06 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 30F2637EB7; Fri, 10 Jun 2005 10:23:06 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id E7CA137E93 for ; Fri, 10 Jun 2005 10:23:05 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id DB1BB37E47 for ; Fri, 10 Jun 2005 10:23:05 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgenA-0001pu-Hu for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 10:23:05 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.4 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118391784.5.0.355930841471.issue51@mip4.org> Date: Fri, 10 Jun 2005 08:23:04 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue51] Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : 6=2E10 Operation Summary In the table, change "Event" in the "Operation" column by "Report" in order= to=20 be consistent with the prior descriptions. ---------- category: Editorial draft: draft-ietf-forces-protocol messages: 108 nosy: rha priority: Should fix status: No discussion title: Operation Summary table ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 05:15:40 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27122 for ; Fri, 10 Jun 2005 05:15:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgfxk-0004fr-AU for forces-archive@IETF.ORG; Fri, 10 Jun 2005 05:38:04 -0400 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.01077A6A@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 5:15:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74823041 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 05:15:40 -0400 Received: from 81.228.8.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 05:15:40 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id DA38038057; Fri, 10 Jun 2005 11:15:39 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8CC8137E6C for ; Fri, 10 Jun 2005 11:15:39 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id D78FF37E49 for ; Fri, 10 Jun 2005 11:15:36 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dgfbz-0005us-5n for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 11:15:36 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.4 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118394934.33.0.63678359005.issue52@mip4.org> Date: Fri, 10 Jun 2005 09:15:34 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue52] Association Setup Response Message: unclear use of SHOW To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : 6=2E4.2 Association Setup Response Message I don't see why the CE has to SHOW attributes of the FE object/protocol=20 object. Are we really expecting a RESULT for the SHOW command of the FE-CE=20 message ? Message from CE to FE: main hdr (eg type =3D Association setup response) | | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | | +--- T =3D Operation =3D SHOW | | | +-- Path-data to one or more attibutes | including FE NAME | May contain RESULT TLVs +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | +--- T =3D Operation =3D SHOW | +-- Path-data to one or more attibutes eg HB parameters May contain RESULT TLVs ---------- category: Technical draft: draft-ietf-forces-protocol messages: 109 nosy: rha priority: Should fix status: No discussion title: Association Setup Response Message: unclear use of SHOW ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 06:28:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04790 for ; Fri, 10 Jun 2005 06:28:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgh5m-0000VS-4b for forces-archive@IETF.ORG; Fri, 10 Jun 2005 06:50:32 -0400 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.01077ACA@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 6:28:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74857714 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 06:28:01 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 06:28:01 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061003312978:16438 ; Fri, 10 Jun 2005 03:31:29 -0700 References: Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 03:31:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 03:31:31 AM, Serialize complete at 06/10/2005 03:31:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118399278.12573.48.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 06:27:58 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue40] BLKINFO To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Thu, 2005-09-06 at 21:07 -0700, Putzolu, David wrote: > (hat off) > I am in agreement with Joel, I'd prefer to only add optimizations after > we get some operational experience that shows where the bottlenecks really are. > We still have BLOCK operations in our implementation and it is useful - so you could say we have operational experience. However, for the sake of progress(so we can last call) and hopefully without need to repeat the discussion we already had on the list: Can we find a way to allow for proprietary implementations to do BLK without much difficulty while at the same time not affecting the protocol itself for anyone else? Would a capability announcement by the FE do it? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:01:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06875 for ; Fri, 10 Jun 2005 07:01:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dghbn-0005HV-Ui for forces-archive@IETF.ORG; Fri, 10 Jun 2005 07:23:32 -0400 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.01077B11@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:01:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74867079 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:00:49 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:00:49 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004041789:16463 ; Fri, 10 Jun 2005 04:04:17 -0700 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> <42A83EA2.80905@zurich.ibm.com> <6.2.1.2.0.20050609091506.02f5fc88@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:04:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:04:19 AM, Serialize complete at 06/10/2005 04:04:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118401246.12573.72.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:00:46 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Multiple processes in the CE talking to the same FE LFBs To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050609091506.02f5fc88@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit On Thu, 2005-09-06 at 09:22 -0400, Joel M. Halpern wrote: > I don;t think there should be higher layer demux in the sense below. > I believe that the ForCES messges will need to be processed by the ForCES > interface, turned into meaningful information for the CE internal > activities, and passed on to the relevant component(s). > > In general, I think that the selection of which component is interested in > ForCES information is going to be based on semantics, not on demux > identifiers in the message. > > Note that specifically as drawn in the diagram it would be exceedingly > unlikely for OSPF, RIP, and BGP to interact directly with LFBs. They will > interact with some form of RIB, which in turn (at least logically) drives > some sort of FIB process. > To carry the example further, if one also has MPLS one can easily imagine > FE notifications which are of interest to both the FIB and LIB > activities. and the FE would have no reasonable way of even knowing > that. Explicit demux seems the wrong answer. > > > On the other hand, Request - Response correlators are a very good idea, for > many reasons. > Where would you stick the correlator in the message in such a case? Is it a TLV in the top hierachy or would there be another 32 bit in the main header? We have not so far needed the correlator so far for the simple reason that we have a _single process_ - so all messages get the opportunity to be demux from a single point. We do use the sequence number as a correlator when we have some app using the NPF APIs over forces in particular. Regardless: should be noted that this(single process/task) is implementation detail i.e that there are other ways to implement. It is more efficient for us to implement a single task - but i do wonder about implementations that have multi processes. Our coding has not yet got to HA, but i have been worried at times while doodling on paper that we may need something akin to a second 32 bit number. Now if one was to use TIPC as a TML, TIPC would take care of this demuxing amongst multi processes since it is inheritenly good at IPCs (thats where the IPC in TIPC comes from ;->). But again that would be implementation specific. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:16:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08476 for ; Fri, 10 Jun 2005 07:16:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dghqy-0000Qj-N8 for forces-archive@IETF.ORG; Fri, 10 Jun 2005 07:39:12 -0400 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.01077BEC@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:16:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74868616 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:16:47 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:16:47 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004201608:16473 ; Fri, 10 Jun 2005 04:20:16 -0700 References: <1118390878.5.0.704863577436.issue44@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:20:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:20:17 AM, Serialize complete at 06/10/2005 04:20:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118402204.12573.78.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:16:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue44] FE, CE, and FE protocol LFBs Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118390878.5.0.704863577436.issue44@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit I agree - the new text provides more clarity. cheers, jamal On Fri, 2005-10-06 at 08:07 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 3.3.2 FE, CE, and FE protocol LFBs > > syntax problem: > All PL messages follow the LFB structure as this provides more flexibility for > future enhancements. This means maintanance and configurability of FEs, NE, as > well as the protocol require a fit in the LFB architecture. For this reason > special LFBs are created to accomodate this need. > > I would rephrase the paragraph as follows (hopefully more clear :) > > All PL messages operate on LFB structures as this provides more flexibility > for future enhancements. This means that maintenance and configurability of > FEs, NE, as well as the ForCES protocol itself must be expressed in terms of > this LFB architecture. For this reason special LFBs are created to accomodate > this need. > > ---------- > category: Editorial > draft: draft-ietf-forces-protocol > messages: 101 > nosy: rha > priority: Should fix > status: Text proposed > title: FE, CE, and FE protocol LFBs > > ___________________________________________________ > Forces issue tracker > > ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:20:36 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08875 for ; Fri, 10 Jun 2005 07:20:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dghue-00012n-9F for forces-archive@IETF.ORG; Fri, 10 Jun 2005 07:43:00 -0400 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.01077BA2@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:20:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74868826 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:20:30 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:20:30 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004235839:16478 ; Fri, 10 Jun 2005 04:23:58 -0700 References: <1118391063.51.0.959571096158.issue45@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:23:58 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:24:00 AM, Serialize complete at 06/10/2005 04:24:00 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118402426.12573.83.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:20:26 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue45] Definition of inter-TML protocol level schemes Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391063.51.0.959571096158.issue45@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 08:11 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 4 TML Requirements > [...] > As an example they could be defined to be delivered via hardware or inter- TML > protocol level schemes. > > Where did we define what "inter-TML" means ? > I may have been responsible for that text; it was intended to mean between two or more TML processes on different CE/FEs. Could probably explicitly say so instead? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:24:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09179 for ; Fri, 10 Jun 2005 07:24:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dghyq-0001Zv-8I for forces-archive@IETF.ORG; Fri, 10 Jun 2005 07:47:22 -0400 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.01077A6F@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:24:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74868998 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:24:55 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:24:55 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004282336:16480 ; Fri, 10 Jun 2005 04:28:23 -0700 References: <1118391230.52.0.873977345714.issue46@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:28:23 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:28:25 AM, Serialize complete at 06/10/2005 04:28:25 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118402691.12573.88.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:24:51 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue46] Up to 8 priorities supported by the TML Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391230.52.0.873977345714.issue46@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 08:13 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 4 > [...] > It is expected that the TML will be able to handle up to 8 priority levels > needed by the PL layer and will provide preferential treatment. > > Writing "up to" means that the TML may support no priorities at all too. Is > this what we intended to say ? Clarify and write MAY, SHOULD or MUST. > There may be cases where the underlying transport and hence the TML is not capable of 8 levels even when the PL wishes it to be so. Unless we define the semantics of the prioritization to mean between PL and TML. cheers, jamal PS:- I am responding to as many tracked issues which have shown up so we can reach faster closure. From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:43:18 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11327 for ; Fri, 10 Jun 2005 07:43:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgiGb-0005UK-7c for forces-archive@IETF.ORG; Fri, 10 Jun 2005 08:05:43 -0400 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.01077A11@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:43:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74869666 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:43:15 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:43:15 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004464400:16498 ; Fri, 10 Jun 2005 04:46:44 -0700 References: <1118391535.01.0.666100966761.issue48@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:46:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:46:45 AM, Serialize complete at 06/10/2005 04:46:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118403792.12573.95.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:43:12 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue48] Data Packing Rules: addressing tables Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391535.01.0.666100966761.issue48@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 08:18 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.1 Data Packing Rules > [...] > 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 with the > index in order to avoid ambiguity. > > This paragraph is far from clear ... maybe correct "PATH flags" instead > of "SELECTOR flags" as there are no flags defined in the SELECTOR. Yes, that text may not be very clear that early in the draft - I cant think of a better way to say it - suggest some text. And they are "PATH flags" not SELECTOR flags (which at some point was actually the correct term to use). As a note, the text bullet: "As an example a 16 bit value will have an extra 16 bit pad ..." should be indented. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 07:54:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12032 for ; Fri, 10 Jun 2005 07:54:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgiQy-0005sF-KO for forces-archive@IETF.ORG; Fri, 10 Jun 2005 08:16:24 -0400 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.01077ABE@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 7:54:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74870111 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 07:53:31 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 07:53:31 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061004565981:16506 ; Fri, 10 Jun 2005 04:56:59 -0700 References: <1118391598.23.0.795873222023.issue49@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:57:00 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 04:57:01 AM, Serialize complete at 06/10/2005 04:57:01 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118404408.12573.104.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 07:53:28 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue49] Sec 6.1.1.1.6 SET and GET Relationship Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391598.23.0.795873222023.issue49@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 08:19 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.6 SET and GET Relationship > [...] > 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing the T > to be SET will endup overwritting the table. > > I had a syntax error reading the sentence above ... The intent was to describe the exception to the rule of converting the GET-RESPONSE to a SET. 1. If you are dump a table using a GET 2. The GET-RESPONSE will contain a path to the table 3. Merely editing the GET-RESPONSE to be a SET would imply overwritting the existing table defined in the path. Perhaps we should provide an example for clarity? Joel, can you look at example 4 in the appendix in relation to this? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 08:05:03 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13633 for ; Fri, 10 Jun 2005 08:05:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgibe-0006Lt-8O for forces-archive@IETF.ORG; Fri, 10 Jun 2005 08:27:28 -0400 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.01077CEE@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 8:05:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74870850 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 08:04:51 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 08:04:51 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061005081947:16514 ; Fri, 10 Jun 2005 05:08:19 -0700 References: <1118391708.28.0.709547895509.issue50@mip4.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 05:08:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 05:08:20 AM, Serialize complete at 06/10/2005 05:08:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118405088.12573.109.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 08:04:47 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391708.28.0.709547895509.issue50@mip4.org> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 08:21 +0000, Robert Haas wrote: > New submission from Robert Haas : > > Sec 6.1.1.1.6 SET and GET Relationship > [...] > Fig. 11: Sample operation layout > > Why is the path-data segmented 3 times for the SET-CREATE operation ? I > thought that this was necessary only each time a different KEY was used ? > May need a better example ... > You must mean "6.1.2 Protocol Visualization" The grammar says: . . PATH-DATA-TLV := PATH [DATA] PATH := flags IDcount IDs [SELECTOR] .. DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV . . I dont see any thing that makes it illegal. Did we have some discussion which reached a conclusion that it can only be done via KEY? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 08:15:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14710 for ; Fri, 10 Jun 2005 08:15:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgilQ-0006nh-1k for forces-archive@IETF.ORG; Fri, 10 Jun 2005 08:37:36 -0400 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.01077AAB@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 8:15:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74871839 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 08:15:06 -0400 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 08:15:06 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5ACF5a6183900 for ; Fri, 10 Jun 2005 12:15:05 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 j5ACF5H4135504 for ; Fri, 10 Jun 2005 14:15:05 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5ACEtYm013609 for ; Fri, 10 Jun 2005 14:15:00 +0200 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 j5ACEpTk013580; Fri, 10 Jun 2005 14:14:51 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA29478; Fri, 10 Jun 2005 14:14:51 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118391708.28.0.709547895509.issue50@mip4.org> <1118405088.12573.109.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id j5ACF5a6183900 Approved-By: Robert Haas Message-ID: <42A98419.2050603@zurich.ibm.com> Date: Fri, 10 Jun 2005 14:14:17 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: hadi@znyx.com Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118405088.12573.109.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Here is what I mean: in the example below (excerpt from Fig. 11), a=20 reasonable approach would be to have a single longer path-data instead=20 of 3 segmented ones. But if the tree had more branches, for instance=20 under the first path-data segment or the second one, then I would=20 understand why one would do so. So the current example is a bad example=20 to my mind. Or am I missing sth ? Regards, -Robert T =3D SET-CREATE | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | + -- T =3D KEYINFO | | + -- KEY_ID | | + -- KEY_DATA | | | + -- T =3D DATARAW | + -- data | | Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 08:21 +0000, Robert Haas wrote: > =20 > >>New submission from Robert Haas : >> >>Sec 6.1.1.1.6 SET and GET Relationship >>[...] >>Fig. 11: Sample operation layout >> >>Why is the path-data segmented 3 times for the SET-CREATE operation ? I= =20 >>thought that this was necessary only each time a different KEY was used= ? >>May need a better example ... >> >> =20 >> > >You must mean "6.1.2 Protocol Visualization" >The grammar says: >. >. >PATH-DATA-TLV :=3D PATH [DATA] >PATH :=3D flags IDcount IDs [SELECTOR] >.. >DATA :=3D DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV >. >. > >I dont see any thing that makes it illegal. Did we have some discussion = which >reached a conclusion that it can only be done via KEY? > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 08:24:08 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15061 for ; Fri, 10 Jun 2005 08:24:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgiu9-0007zT-8t for forces-archive@IETF.ORG; Fri, 10 Jun 2005 08:46:33 -0400 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.01077AB9@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 8:24:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74872390 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 08:24:07 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 08:24:07 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061005273594:16534 ; Fri, 10 Jun 2005 05:27:35 -0700 References: <1118391708.28.0.709547895509.issue50@mip4.org> <1118405088.12573.109.camel@localhost.localdomain> <42A98419.2050603@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 05:27:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 05:27:37 AM, Serialize complete at 06/10/2005 05:27:37 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118406244.12573.124.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 08:24:04 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42A98419.2050603@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 14:14 +0200, Robert Haas wrote: > Here is what I mean: in the example below (excerpt from Fig. 11), a > reasonable approach would be to have a single longer path-data instead > of 3 segmented ones. But if the tree had more branches, for instance > under the first path-data segment or the second one, then I would > understand why one would do so. So the current example is a bad example > to my mind. Or am I missing sth ? > The motivation behind fig 11 is to show the different nesting levels a path could take to get to the target path. Can you redraw it so that we still show the deep nesting? I actually didnt follow you completely - theres nothing i could see in that tree that indicates it has few branches. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 08:52:20 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16791 for ; Fri, 10 Jun 2005 08:52:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjLR-0004uG-Co for forces-archive@IETF.ORG; Fri, 10 Jun 2005 09:14:45 -0400 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.01077C79@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 8:52:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74880125 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 08:52:19 -0400 Received: from 81.228.8.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 08:52:19 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id A4A1B37E76; Fri, 10 Jun 2005 14:52:18 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id EE15937E79 for ; Fri, 10 Jun 2005 14:52:17 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id DC1B037E48 for ; Fri, 10 Jun 2005 14:52:17 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1Dgizg-0000Ro-Uh for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 14:52:17 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Weiming Wang Message-ID: <1118407936.25.0.440554927605.issue53@mip4.org> Date: Fri, 10 Jun 2005 12:52:16 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: [issue53] How a path should be defined in Packet Redirect Message? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable New submission from Weiming Wang : in draft-ietf-forces-protocol-03.txt Section 6.8 Packet Redirect Message, The operation TLV is defined as: =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D PAYLOAD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Sequence Number?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Redirected Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26 Path(or Sequence Number?): [Under discussion and TBD] The question is how the Path should be defined here? ---------- category: Technical draft: draft-ietf-forces-protocol messages: 119 nosy: weiming priority: Must fix status: Text proposed title: How a path should be defined in Packet Redirect Message? ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 08:54:42 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16984 for ; Fri, 10 Jun 2005 08:54:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjNj-0004xB-Ul for forces-archive@IETF.ORG; Fri, 10 Jun 2005 09:17:08 -0400 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.01077B41@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 8:54:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74880224 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 08:54:27 -0400 Received: from 195.212.29.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 08:54:27 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5ACs5LC130876 for ; Fri, 10 Jun 2005 12:54:06 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5ACs4EV134454 for ; Fri, 10 Jun 2005 13:54:04 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5ACs4Va020631 for ; Fri, 10 Jun 2005 13:54:04 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5ACs4fN020572; Fri, 10 Jun 2005 13:54:04 +0100 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA52390; Fri, 10 Jun 2005 14:54:03 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1118391708.28.0.709547895509.issue50@mip4.org> <1118405088.12573.109.camel@localhost.localdomain> <42A98419.2050603@zurich.ibm.com> <1118406244.12573.124.camel@localhost.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.uk.ibm.com id j5ACs5LC130876 Approved-By: Robert Haas Message-ID: <42A98D4A.3070607@zurich.ibm.com> Date: Fri, 10 Jun 2005 14:53:30 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data Comments: To: hadi@znyx.com Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118406244.12573.124.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable I don't mean the example is illegal, I only think it is absurd, but I=20 may be missing sth. What about the following example of a tree with two branches ? I guess=20 what I am saying is that a reasonable design would try to make the=20 branches as short as possible. T =3D SET-CREATE | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | | | +- T =3D Path-data | | | | | + -- flags | | + -- IDCount | | + -- IDs | | + -- T =3D KEYINFO | | | + -- KEY_ID | | | + -- KEY_DATA | | | | | + -- T =3D DATARAW | | + -- data | | | +- T =3D Path-data | | | + -- flags | + -- IDCount | + -- IDs | + -- T =3D KEYINFO | | + -- KEY_ID | | + -- KEY_DATA | | | + -- T =3D DATARAW | + -- data=20 Regards, -Robert Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 14:14 +0200, Robert Haas wrote: > =20 > >>Here is what I mean: in the example below (excerpt from Fig. 11), a=20 >>reasonable approach would be to have a single longer path-data instead=20 >>of 3 segmented ones. But if the tree had more branches, for instance=20 >>under the first path-data segment or the second one, then I would=20 >>understand why one would do so. So the current example is a bad example= =20 >>to my mind. Or am I missing sth ? >> >> =20 >> > >The motivation behind fig 11 is to show the different nesting levels a >path could take to get to the target path. >Can you redraw it so that we still show the deep nesting? >I actually didnt follow you completely - theres nothing i could see in >that tree that indicates it has few branches. > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 09:09:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18292 for ; Fri, 10 Jun 2005 09:09:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgjbd-00084k-4J for forces-archive@IETF.ORG; Fri, 10 Jun 2005 09:31:33 -0400 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.01077ACC@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 9:09:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74881689 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 09:09:03 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 09:09:03 -0400 Received: from dialup-4.249.114.207.dial1.washington2.level3.net ([4.249.114.207] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgjFl-00020E-00; Fri, 10 Jun 2005 09:08:53 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1118391230.52.0.873977345714.issue46@mip4.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.20050610090651.02d45c58@localhost> Date: Fri, 10 Jun 2005 09:08:51 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue46] Up to 8 priorities supported by the TML Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118391230.52.0.873977345714.issue46@mip4.org> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I think there are two issues here. I don't think that we wanted to require that all TMLs be able to handle 8 different priorities. We expected that some would handle only two. On the other hand, I think we did want to require that the TML give different handling to some levels. To make that useful, we may want to specify a little more (like, if the TML does two levels that 0-3 go in one level and 4-7 go in the other.) Yours, Joel At 04:13 AM 6/10/2005, Robert Haas wrote: >New submission from Robert Haas : > >Sec 4 >[...] >It is expected that the TML will be able to handle up to 8 priority levels >needed by the PL layer and will provide preferential treatment. > >Writing "up to" means that the TML may support no priorities at all too. Is >this what we intended to say ? Clarify and write MAY, SHOULD or MUST. > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 103 >nosy: rha >priority: Should fix >status: No discussion >title: Up to 8 priorities supported by the TML > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 09:15:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18672 for ; Fri, 10 Jun 2005 09:15:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgji2-0000QS-TY for forces-archive@IETF.ORG; Fri, 10 Jun 2005 09:38:07 -0400 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.01077D0F@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 9:15:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74882384 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 09:15:41 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 09:15:41 -0400 Received: from dialup-4.249.114.207.dial1.washington2.level3.net ([4.249.114.207] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgjMJ-0003xB-00; Fri, 10 Jun 2005 09:15:40 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> <42A83EA2.80905@zurich.ibm.com> <6.2.1.2.0.20050609091506.02f5fc88@localhost> <1118401246.12573.72.camel@localhost.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.20050610091359.02ecf7a8@localhost> Date: Fri, 10 Jun 2005 09:15:37 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Multiple processes in the CE talking to the same FE LFBs Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118401246.12573.72.camel@localhost.localdomain> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d I would put the correlator in the main header. Not only is it useful if the CE is multiple processes, but it is useful if the FE can respond to pipelined requests out of order. (Suppose that some operations require long hardware manipulation, and some just update a table. One could easily have responses come back out of order. The correlator makes that a non-issue. The absence of the correlator in HTTP makes some things "interesting".) Yours, Joel At 07:00 AM 6/10/2005, Jamal Hadi Salim wrote: > > On the other hand, Request - Response correlators are a very good idea, > for > > many reasons. > > > >Where would you stick the correlator in the message in such a case? >Is it a TLV in the top hierachy or would there be another 32 bit in the >main header? > >We have not so far needed the correlator so far for the simple reason >that we have a _single process_ - so all messages get the opportunity to >be demux from a single point. We do use the sequence number as a >correlator when we have some app using the NPF APIs over forces in >particular. >Regardless: should be noted that this(single process/task) is >implementation detail i.e that there are other ways to implement. >It is more efficient for us to implement a single task - but i do wonder >about implementations that have multi processes. Our coding has not yet >got to HA, but i have been worried at times while doodling on paper that >we may need something akin to a second 32 bit number. >Now if one was to use TIPC as a TML, TIPC would take care of this >demuxing amongst multi processes since it is inheritenly good at IPCs >(thats where the IPC in TIPC comes from ;->). But again that would be >implementation specific. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 09:23:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19265 for ; Fri, 10 Jun 2005 09:23:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgjpt-0001sP-NZ for forces-archive@IETF.ORG; Fri, 10 Jun 2005 09:46:13 -0400 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.01077B9F@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 9:23:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74882870 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 09:23:43 -0400 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 09:23:42 -0400 Received: from dialup-4.249.114.207.dial1.washington2.level3.net ([4.249.114.207] helo=JMHLap3.stevecrocker.com) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DgjU3-0004wL-00; Fri, 10 Jun 2005 09:23:41 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1118391598.23.0.795873222023.issue49@mip4.org> <1118404408.12573.104.camel@localhost.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.20050610092244.02d46490@localhost> Date: Fri, 10 Jun 2005 09:23:34 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue49] Sec 6.1.1.1.6 SET and GET Relationship Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118404408.12573.104.camel@localhost.localdomain> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The example looks right. The path indicates the whole table. Therefore the whole table will be replaced with one where the entries are the same as they were at the time of the get. Yours, Joel At 07:53 AM 6/10/2005, Jamal Hadi Salim wrote: >On Fri, 2005-10-06 at 08:19 +0000, Robert Haas wrote: > > New submission from Robert Haas : > > > > Sec 6.1.1.1.6 SET and GET Relationship > > [...] > > 2. When dumping a whole table in a GET, the GET-RESPONSE, merely > editing the T > > to be SET will endup overwritting the table. > > > > I had a syntax error reading the sentence above ... > >The intent was to describe the exception to the rule of converting the >GET-RESPONSE to a SET. > >1. If you are dump a table using a GET >2. The GET-RESPONSE will contain a path to the table >3. Merely editing the GET-RESPONSE to be a SET would imply overwritting >the existing table defined in the path. > >Perhaps we should provide an example for clarity? > >Joel, can you look at example 4 in the appendix in relation to this? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 11:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02527 for ; Fri, 10 Jun 2005 11:48:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgm5u-0005FU-1e for forces-archive@IETF.ORG; Fri, 10 Jun 2005 12:10:55 -0400 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.01077DB7@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 11:48:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74894691 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 11:48:26 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 11:48:26 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061008515449:16745 ; Fri, 10 Jun 2005 08:51:54 -0700 References: <468F3FDA28AA87429AD807992E22D07E0440B549@orsmsx408> <4212130D.4040601@zurich.ibm.com> <42A83EA2.80905@zurich.ibm.com> <6.2.1.2.0.20050609091506.02f5fc88@localhost> <1118401246.12573.72.camel@localhost.localdomain> <6.2.1.2.0.20050610091359.02ecf7a8@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 08:51:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 08:51:56 AM, Serialize complete at 06/10/2005 08:51:56 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118418502.12573.134.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 11:48:21 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Multiple processes in the CE talking to the same FE LFBs Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050610091359.02ecf7a8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit On Fri, 2005-10-06 at 09:15 -0400, Joel M. Halpern wrote: > I would put the correlator in the main header. This would be fine with me. I have no immediate use for it; Lets hear what other folks have to say. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 12:01:18 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03857 for ; Fri, 10 Jun 2005 12:01:18 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgmIM-0006go-Kn for forces-archive@IETF.ORG; Fri, 10 Jun 2005 12:23:47 -0400 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.01077DE5@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 12:01:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74896161 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 12:01:17 -0400 Received: from 81.228.8.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 12:01:17 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id DD25E37EE0; Fri, 10 Jun 2005 18:01:16 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2EB9437E7E for ; Fri, 10 Jun 2005 18:01:16 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2224B37E42 for ; Fri, 10 Jun 2005 18:01:16 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DglwZ-00053u-9Y for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 18:01:15 +0200 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-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, MIME_QP_LONG_LINE,USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Robert Haas Message-ID: <1118419274.42.0.426902225652.issue54@mip4.org> Date: Fri, 10 Jun 2005 16:01:14 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Robert Haas Subject: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the=20 request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator:=20 this can be dangerous, and not suitable for event notifications messages=20 (nothing to correlate with). But this introduces the risk of flooding an FE with too many commands as th= ere=20 is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 12:13:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04797 for ; Fri, 10 Jun 2005 12:13:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgmUJ-0007KB-0O for forces-archive@IETF.ORG; Fri, 10 Jun 2005 12:36:15 -0400 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.01077E21@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 12:13:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74897055 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 12:13:39 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 12:13:38 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sat, 11 Jun 2005 00:46:46 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sat, 11 Jun 2005 00:11:34 +0800 References: <1118419274.42.0.426902225652.issue54@mip4.org> 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: <087401c56dd7$1e3604a0$1152010a@Necom.hzic.edu.cn> Date: Sat, 11 Jun 2005 00:11:54 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 16:09:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06836 for ; Fri, 10 Jun 2005 16:09:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgqAA-0008PJ-9g for forces-archive@IETF.ORG; Fri, 10 Jun 2005 16:31:36 -0400 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.01078230@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 16:09:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74910979 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 16:09:04 -0400 Received: from 81.228.9.185 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 16:09:04 -0400 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 62B0C37E98; Fri, 10 Jun 2005 22:09:03 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 52C4E37E8A for ; Fri, 10 Jun 2005 22:09:03 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 3390537E46 for ; Fri, 10 Jun 2005 22:09:03 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DgpoL-0003nI-0h for forces@peach.ease.lsoft.com; Fri, 10 Jun 2005 22:09:02 +0200 Content-Type: multipart/mixed; boundary="81.224.201.50.33.14587.1118434140.553.1" MIME-Version: 1.0 X-Roundup-Name: Forces issue tracker X-Roundup-Loop: hello X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.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.3 (2005-04-27) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.5 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.3 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) Approved-By: Jamal Hadi Salim Message-ID: <1118434140.53.0.769267160607.issue55@mip4.org> Date: Fri, 10 Jun 2005 20:09:00 +0000 Reply-To: Forces issue tracker Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Subject: [issue55] Execution text replacement To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 --81.224.201.50.33.14587.1118434140.553.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New submission from Jamal Hadi Salim : The following text is suggested replacement for the execution section. Joel I hope i have caught you still there. I have downplayed that text a little - so hopefully that should resolve it. ---------- category: Technical draft: draft-ietf-forces-protocol files: operationrequest.txt messages: 131 nosy: jamal priority: Must fix status: Text proposed title: Execution text replacement ___________________________________________________ Forces issue tracker ___________________________________________________ --81.224.201.50.33.14587.1118434140.553.1 Content-Type: text/plain Content-Disposition: attachment; filename="operationrequest.txt" Content-Transfer-Encoding: 7bit 3.3.1.1 Execution ------------------ There are 3 execution modes that could be requested for a batch of operations spanning on one or more LFB selectors: a) Transactional execute-all-or-none b) Loose transactional execute-until-failure c) non-transactional continue-execute-on-failure 3.3.1.1.1 "all-or-none" Atomic transaction A transaction maybe atomic: a) within an FE alone * example updating multiple tables which are dependent on each other. If updating one fails, then any others already updated must be undone. b) across the NE. Example updating the same type of table(s) that are interdependent across several FEs (such as L3 forwarding related tables). 3.3.1.1.1.1 Transaction definition We define a transaction as a collection of one or more ForCES operations within one or more PL messages that MUST meet the ACIDity properties[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. There are cases where the CE knows exact memory and implementation details of the FE such as in the case of a FE-CE pair from the same vendor where the FE-CE pair is tightly coupled. In such a case, the transactional operations maybe simplified further by extra computation at the CE. We do not discuss this view further other than to mention it in not dissallowed. For the purpose of interopability, we define a classical transactional protocol known as two phase commit which meets the ACID properties to be used for transactions. 3.3.1.1.1.2 Transaction protocol 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. [editorial note: Should we talk about correlators as markers for different transactions?] 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. The transaction commitment phase is signalled by an empty DONE msg type. TBD: We may need an ABORT message(used for rollback purposes) or maybe a DONE with an ABORT flag to undo will suffice. 3.3.1.1.1.3 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 an 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. This requires knowledge at both the CE and FE; not sure how to signal it. Global flags: ATOMIC, START, ABORT? (used by 2PC) New msg type: DONE, ABORT?(used by 2PC) 3.3.1.1.2 continue-execute-on-failure Several independent operations are targeted at one or more LFB selectors by the CE. Execution continues at the FE even when one or more operations fail. This mode is signalled by a missing ATOMIC flag. Explicit failures are indicated back to the CE if requested. 3.3.1.1.3 Loose transactional execute-until-failure 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 the case of all-or-none execution. flag: GOTON (global) 3.3.1.1.4 Relation to Multipart messages Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. 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 inconsitency implies a cancelled transaction in which all messages are dropped and the sender NACKED. $Log: operationrequest.txt,v $ Revision 1.2 2005/06/10 19:38:28 hadi sent to the list - reworded the two schools of thought - changed naming convention of goto-N and one-of-N , Revision 1.1 2005/06/06 16:29:58 hadi Initial revision --81.224.201.50.33.14587.1118434140.553.1-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 16:21:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09285 for ; Fri, 10 Jun 2005 16:21:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgqM9-0003vw-Q0 for forces-archive@IETF.ORG; Fri, 10 Jun 2005 16:44:02 -0400 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.01078170@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 16:21:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74911305 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 16:21:28 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 16:21:28 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061013245597:17160 ; Fri, 10 Jun 2005 13:24:55 -0700 References: <1118391708.28.0.709547895509.issue50@mip4.org> <1118405088.12573.109.camel@localhost.localdomain> <42A98419.2050603@zurich.ibm.com> <1118406244.12573.124.camel@localhost.localdomain> <42A98D4A.3070607@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 01:24:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/10/2005 01:24:57 PM, Serialize complete at 06/10/2005 01:24:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118434884.12573.150.camel@localhost.localdomain> Date: Fri, 10 Jun 2005 16:21:24 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42A98D4A.3070607@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Ok, there are two issues as i see it: 1) showing what is possible. Thats the goal of the example. 2) Showing whats sensible given what we know at the moment. This is what you are striving for. We should show #2 first, but we should show the possibilities next. If we think it is ridiculous/absurd to have that flexibilty then the grammar shouldnt allow it - otherwise it's a poor design. cheers, jamal On Fri, 2005-10-06 at 14:53 +0200, Robert Haas wrote: > I don't mean the example is illegal, I only think it is absurd, but I > may be missing sth. > What about the following example of a tree with two branches ? I guess > what I am saying is that a reasonable design would try to make the > branches as short as possible. > From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 18:02:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17036 for ; Fri, 10 Jun 2005 18:02:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgrwA-0000QC-Ot for forces-archive@IETF.ORG; Fri, 10 Jun 2005 18:25:19 -0400 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.010784BF@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 18:02:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74917883 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 18:02:22 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 18:02:22 -0400 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 j5AM2LwQ017291 for ; Fri, 10 Jun 2005 22:02:21 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 j5AM1am6014644 for ; Fri, 10 Jun 2005 22:02:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005061015022131938 for ; Fri, 10 Jun 2005 15:02:21 -0700 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, 10 Jun 2005 15:02:21 -0700 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-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Thread-Index: AcVtcWR7S1JblUmJRU6rKvpflSXeuwAlpyOw X-OriginalArrivalTime: 10 Jun 2005 22:02:21.0605 (UTC) FILETIME=[1382A550:01C56E08] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Fri, 10 Jun 2005 15:02:20 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable FYI, draft submission deadlines are coming! -David =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Thursday, June 09, 2005 9:00 PM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France=20 There are two (2) Internet-Draft cutoff dates for the 63rd=20 IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 July 11th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Tuesday,=20 July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, August 1st at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or=20 revised Internet-Draft after their respective cutoff deadlines, then=20 your document will be retained and posted when Internet-Draft=20 processing resumes. You will no longer be required to resubmit the=20 document. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 10 20:55:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29033 for ; Fri, 10 Jun 2005 20:55:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgudc-0002Co-4M for forces-archive@IETF.ORG; Fri, 10 Jun 2005 21:18:17 -0400 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.010785E5@cherry.ease.lsoft.com>; Fri, 10 Jun 2005 20:55:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 74928055 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Jun 2005 20:55:43 -0400 Received: from 207.69.195.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 10 Jun 2005 20:55:43 -0400 Received: from dialup-4.249.48.156.dial1.washington2.level3.net ([4.249.48.156] helo=JMHLap3.stevecrocker.com) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DguHh-0003oQ-00; Fri, 10 Jun 2005 20:55:38 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1118434140.53.0.769267160607.issue55@mip4.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.20050610205518.02d91f98@localhost> Date: Fri, 10 Jun 2005 20:55:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118434140.53.0.769267160607.issue55@mip4.org> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Looks good to me. Joel At 04:09 PM 6/10/2005, Jamal Hadi Salim wrote: >New submission from Jamal Hadi Salim : > >The following text is suggested replacement for the execution >section. Joel I hope i have caught you still there. I have downplayed that >text a little - so hopefully that should resolve it. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >files: operationrequest.txt >messages: 131 >nosy: jamal >priority: Must fix >status: Text proposed >title: Execution text replacement > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From HelenBeal@amraf.co.uk Sat Jun 11 05:57:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23358; Sat, 11 Jun 2005 05:57:11 -0400 (EDT) Received: from [213.157.178.109] (helo=host-178-109.sibiu.rdsnet.ro) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dh35b-0006p8-JV; Sat, 11 Jun 2005 06:19:48 -0400 Received: from fTiY@localhost by 2RiY.int (8.11.6/8.11.6); Sat, 11 Jun 2005 07:57:30 -0300 Message-ID: From: "Katherine Steele" Reply-To: "Katherine Steele" To: stun-owner@ietf.org, iips@ietf.org, forces-archive@ietf.org Subject: 0nline software, Download Win XP, Adobe, Windows & others Instantly Date: Sat, 11 Jun 2005 08:02:30 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HelenBeal@amraf.co.uk Content-Type: multipart/mixed; boundary="--ou2xdMJ0irdbwmxSBcU" X-Spam-Score: 12.2 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 IpST ----ou2xdMJ0irdbwmxSBcU Content-Type: text/html; Content-Transfer-Encoding: quoted-printable e
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----ou2xdMJ0irdbwmxSBcU-- From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Sat Jun 11 22:30:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29327 for ; Sat, 11 Jun 2005 22:30:56 -0400 (EDT) Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhIbR-0005m1-MN for forces-archive@IETF.ORG; Sat, 11 Jun 2005 22:53:42 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <8.0057BD7E@grape.ease.lsoft.com>; Sat, 11 Jun 2005 22:30:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75043536 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Jun 2005 22:30:48 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 11 Jun 2005 22:30:47 -0400 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 j5C2ToT8004509; Sun, 12 Jun 2005 02:29: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 j5C2Tnkb019381; Sun, 12 Jun 2005 02:29:49 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005061119294809441 ; Sat, 11 Jun 2005 19:29:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Jun 2005 19:29:49 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVt12FJRRbCvc5OQDiDYrYAhwL9AwBHrlYg X-OriginalArrivalTime: 12 Jun 2005 02:29:49.0147 (UTC) FILETIME=[9B00FAB0:01C56EF6] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E059E0076@orsmsx408> Date: Sat, 11 Jun 2005 19:29:48 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: cc: "Wang,Weiming" , Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 11 23:16:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00964 for ; Sat, 11 Jun 2005 23:16:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhJJT-0007Nq-Hl for forces-archive@IETF.ORG; Sat, 11 Jun 2005 23:39:13 -0400 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.01079431@cherry.ease.lsoft.com>; Sat, 11 Jun 2005 23:16:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75046245 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Jun 2005 23:16:16 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 11 Jun 2005 23:16:15 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sun, 12 Jun 2005 11:49:17 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Sun, 12 Jun 2005 11:13:46 +0800 References: <468F3FDA28AA87429AD807992E22D07E059E0076@orsmsx408> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <08c401c56efc$c93ba370$1152010a@Necom.hzic.edu.cn> Date: Sun, 12 Jun 2005 11:14:03 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 ----- Original Message ----- From: "Khosravi, Hormuzd M" Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. [Weiming] I think it's too early to say the SN is only for correlation. currently I don't think we should a hundred percent to rely on TML for thinks like sequential ordering. As a safer mode, I still prefer to have it as its original name of Sequence Number. Correlating request/reply messages should only be one of its functions. thanks, Weiming BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 11 23:19:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01139 for ; Sat, 11 Jun 2005 23:19:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhJMX-0007TG-Hh for forces-archive@IETF.ORG; Sat, 11 Jun 2005 23:42:17 -0400 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.01079436@cherry.ease.lsoft.com>; Sat, 11 Jun 2005 23:19:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75046309 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Jun 2005 23:19:31 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 11 Jun 2005 23:19:30 -0400 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 j5C3JGVL008841; Sun, 12 Jun 2005 03:19:16 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 j5C3JG3t003403; Sun, 12 Jun 2005 03:19:16 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 M2005061120191511963 ; Sat, 11 Jun 2005 20:19:15 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 11 Jun 2005 20:19:15 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVu/RtFgrBSuz+2TIS3EVQMhvLWCgAACwaQ X-OriginalArrivalTime: 12 Jun 2005 03:19:15.0888 (UTC) FILETIME=[8351BB00:01C56EFD] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> Date: Sat, 11 Jun 2005 20:19:14 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Ok, so you're saying we should use the Sequence number as a Correlator. If that is the case then we are in agreement, I think. We should update the text. Let me know if I misunderstood you, Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Saturday, June 11, 2005 8:14 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header ----- Original Message ----- From: "Khosravi, Hormuzd M" Yes, a Correlator is useful and currently we have been using the Sequence number as correlator. I don't see any other use of the Sequence number since reliability is provided by the TML. I think we should change Sequence number to correlator in the draft and update the description accordingly unless there is some use for a sequence number. [Weiming] I think it's too early to say the SN is only for correlation. currently I don't think we should a hundred percent to rely on TML for thinks like sequential ordering. As a safer mode, I still prefer to have it as its original name of Sequence Number. Correlating request/reply messages should only be one of its functions. thanks, Weiming BTW, issue 47 looks like the same one...we should close one of these issues. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, June 10, 2005 9:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Robert, ----- Original Message ----- From: "Robert Haas" New submission from Robert Haas : Adding a correlator seems useful: response messages can be matched to the request messages even if pipelining and reordering occurs. It seems that some are currently using the sequence number as a correlator: this can be dangerous, and not suitable for event notifications messages (nothing to correlate with). [Weiming] I'm not sure if you mean to use the SN as a correlator is to let the response have the same SN as the sender. If so, I cannot follow well why it is dangerous and not suit for event notifications. Could you clarify this more? Thanks. Weiming But this introduces the risk of flooding an FE with too many commands as there is no windowing mechanism in place (yet). ---------- category: Technical draft: draft-ietf-forces-protocol messages: 129 nosy: rha priority: Should fix status: No discussion title: correlator in the PL message header ___________________________________________________ Forces issue tracker ___________________________________________________ From ElisabethDraper@1600e.co.uk Sun Jun 12 06:45:28 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24869 for ; Sun, 12 Jun 2005 06:45:27 -0400 (EDT) Date: Sun, 12 Jun 2005 06:45:27 -0400 (EDT) From: ElisabethDraper@1600e.co.uk Message-Id: <200506121045.GAA24869@ietf.org> Received: from cable-195-162-223-149.upc.chello.be ([195.162.223.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhQK7-0003t6-Pu for forces-archive@ietf.org; Sun, 12 Jun 2005 07:08:18 -0400 Received: from p6Z@localhost by 5[3-4 X-Spam-Score: 14.8 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 12 11:00:40 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12154 for ; Sun, 12 Jun 2005 11:00:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhUJ4-0005Re-SA for forces-archive@IETF.ORG; Sun, 12 Jun 2005 11:23:33 -0400 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.01079B70@cherry.ease.lsoft.com>; 12 Jun 2005 11:00:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75115388 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 11:00:33 -0400 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 12 Jun 2005 11:00:33 -0400 Received: from dialup-4.248.255.119.dial1.washington2.level3.net ([4.248.255.119] helo=JMHLap3.stevecrocker.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DhTwu-00067g-00 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 11:00:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E059E0079@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.20050612105712.02d43ee8@localhost> Date: Sun, 12 Jun 2005 11:00:25 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 12 11:36:55 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14665 for ; Sun, 12 Jun 2005 11:36:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhUsE-0007Jk-LQ for forces-archive@IETF.ORG; Sun, 12 Jun 2005 11:59:49 -0400 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.01079B7E@cherry.ease.lsoft.com>; 12 Jun 2005 11:36:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75117206 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 11:36:53 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 12 Jun 2005 11:36:53 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061208401936:18414 ; Sun, 12 Jun 2005 08:40:19 -0700 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/12/2005 08:40:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/12/2005 08:40:21 AM, Serialize complete at 06/12/2005 08:40:21 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118590608.25652.77.camel@localhost.localdomain> Date: Sun, 12 Jun 2005 11:36:47 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050612105712.02d43ee8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. > Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 12 15:20:59 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00284 for ; Sun, 12 Jun 2005 15:20:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhYN3-0000FM-PC for forces-archive@IETF.ORG; Sun, 12 Jun 2005 15:43:54 -0400 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.01079BCE@cherry.ease.lsoft.com>; 12 Jun 2005 15:20:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75125557 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 15:20:42 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 12 Jun 2005 15:20:41 -0400 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 j5CJKaxw031409; Sun, 12 Jun 2005 19:20:36 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 j5CJKaSF001626; Sun, 12 Jun 2005 19:20:36 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 M2005061212203506093 ; Sun, 12 Jun 2005 12:20:35 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Jun 2005 12:20:35 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVvX4LpSYSNdXBGQEqC/pWACLmj0gAI4maQ X-OriginalArrivalTime: 12 Jun 2005 19:20:35.0864 (UTC) FILETIME=[CF439980:01C56F83] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E059E00FE@orsmsx408> Date: Sun, 12 Jun 2005 12:20:32 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable I agree, this was along the lines of my previous suggestion. I don't see the reason for having both a sequence number and a correlator....SN should not be needed by the PL since the TML provides reliability which guarantees in-order delivery (acc to the definition). Would you agree? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, June 12, 2005 8:00 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand=20 messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies=20 should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a=20 received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 12 15:23:01 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00466 for ; Sun, 12 Jun 2005 15:23:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhYP3-0000Im-Sp for forces-archive@IETF.ORG; Sun, 12 Jun 2005 15:45:56 -0400 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.01079D13@cherry.ease.lsoft.com>; 12 Jun 2005 15:23:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75125591 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 15:22:54 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 12 Jun 2005 15:22:54 -0400 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 j5CJMrxw032024; Sun, 12 Jun 2005 19:22:53 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 j5CJMmSH002245; Sun, 12 Jun 2005 19:22:53 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005061212225321752 ; Sun, 12 Jun 2005 12:22:53 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Jun 2005 12:22:53 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVvZJIBsRtx7Lp8TpWDsueAroIJ2QAH06vw X-OriginalArrivalTime: 12 Jun 2005 19:22:53.0242 (UTC) FILETIME=[2125D1A0:01C56F84] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E059E00FF@orsmsx408> Date: Sun, 12 Jun 2005 12:22:51 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Jamal, Do you see a good reason to keep a SN? I don't see one since the TML provides reliability. If there is another reason, let us know...otherwise we should get rid of the SN. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 12 23:32:16 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08092 for ; Sun, 12 Jun 2005 23:32:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhg2P-0004Ch-3p for forces-archive@IETF.ORG; Sun, 12 Jun 2005 23:55:15 -0400 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.0107A48E@cherry.ease.lsoft.com>; 12 Jun 2005 23:31:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75147452 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 12 Jun 2005 23:31:56 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 12 Jun 2005 23:31:55 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 13 Jun 2005 12:05:33 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 13 Jun 2005 11:29:49 +0800 References: <468F3FDA28AA87429AD807992E22D07E059E00FE@orsmsx408> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <095601c56fc8$30e00fe0$1152010a@Necom.hzic.edu.cn> Date: Mon, 13 Jun 2005 11:30:05 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Firstly , I think even if we use it only as a correlator, the number should sitll not be generated randomly, rather sequencially. Secondly, it therefore menas we actually doesn't pay too much by introducing the Sequential Number in while without loosing the correlator function. Thirdly, it maybe too early to say a SN is not at all useful for the protocol PL level. For this point, I suppose we should distinguish the idea of the protocol message sequence from the TML transport sequence a little. I can curretnly see two cases where protocol SN may make senses to PL thought not to TML: 1. For messages like Packet redirect messages, transport order of which may not strictly requred, but the sequence of the redirected packets still make sense to the applications of the packets. 2. Usually, core PL process runs in a multi-thread mode, in this case, a SN can act well as a tracker for the process. This can be used at PL-TML interface PL side as well as the TML side. This may also be used for CE or FE failover case like graceful restart. Cheers, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" I agree, this was along the lines of my previous suggestion. I don't see the reason for having both a sequence number and a correlator....SN should not be needed by the PL since the TML provides reliability which guarantees in-order delivery (acc to the definition). Would you agree? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, June 12, 2005 8:00 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Actually, I would prefer to change the name. A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict. Note that a request originator is capable of remembering the sequence in which it sends requests. Thus, for most purposes a correlator will do more than a sequence number. What a correlator does not provide is the ability to compare the order of a received even and a received response. If some TML may disorder things, that would be lost information. If that is a big deal, we need two fields. But we can not simply treat the sequence number as the correlator. Yours, Joel At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: >Ok, so you're saying we should use the Sequence number as a Correlator. >If that is the case then we are in agreement, I think. We should update >the text. > >Let me know if I misunderstood you, >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Saturday, June 11, 2005 8:14 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >Yes, a Correlator is useful and currently we have been using the >Sequence number as correlator. I don't see any other use of the Sequence >number since reliability is provided by the TML. I think we should >change Sequence number to correlator in the draft and update the >description accordingly unless there is some use for a sequence number. > >[Weiming] I think it's too early to say the SN is only for correlation. >currently I don't think we should a hundred percent to rely on TML for >thinks >like sequential ordering. As a safer mode, I still prefer to have it >as its >original name of Sequence Number. Correlating request/reply messages >should >only be one of its functions. > >thanks, >Weiming > >BTW, issue 47 looks like the same one...we should close one of these >issues. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming >Sent: Friday, June 10, 2005 9:12 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Robert, > >----- Original Message ----- >From: "Robert Haas" > >New submission from Robert Haas : > >Adding a correlator seems useful: response messages can be matched to >the >request messages even if pipelining and reordering occurs. >It seems that some are currently using the sequence number as a >correlator: >this can be dangerous, and not suitable for event notifications messages >(nothing to correlate with). >[Weiming] I'm not sure if you mean to use the SN as a correlator is to >let the >response have the same SN as the sender. If so, I cannot follow well >why it is >dangerous and not suit for event notifications. Could you clarify this >more? > >Thanks. >Weiming > >But this introduces the risk of flooding an FE with too many commands as >there >is no windowing mechanism in place (yet). > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 129 >nosy: rha >priority: Should fix >status: No discussion >title: correlator in the PL message header > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 07:32:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01608 for ; Mon, 13 Jun 2005 07:32:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhnX0-0008ES-QO for forces-archive@IETF.ORG; Mon, 13 Jun 2005 07:55:09 -0400 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.0107AABC@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 7:32:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75200299 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 07:32:03 -0400 Received: from 160.79.150.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 07:32:03 -0400 Received: from malone.intellispace.net (malone.intellispace.net [160.79.145.141]) by extgw01.msys.intellispace.net (Postfix) with ESMTP id B9559313D9; Mon, 13 Jun 2005 07:31:35 -0400 (EDT) Received: from JMHLap3.stevecrocker.com (160.79.221.2) by malone.intellispace.net (5.1.053) id 42A8FF5D00149373; Mon, 13 Jun 2005 07:30:34 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E059E00FE@orsmsx408> <095601c56fc8$30e00fe0$1152010a@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.1.2.0.20050613072920.02d57420@localhost> Date: Mon, 13 Jun 2005 07:31:40 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <095601c56fc8$30e00fe0$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Actually, I would prefer to put as few restrictions as possible on the creator of the correlator, so as to allow the most implementation freedom. Hence, the only MUST would be that a responder MUST put the correlator from a request into the response. It seems like "A requestor SHOULD NOT reuse the correlator from outstanding requests for different requests." makes sense. I would not want to make that a MUST. An receiver MUST NOT apply any semantics to received correlators. Sequence information is either derivable from the TML or should be in a separate field. Yours, Joel At 11:30 PM 6/12/2005, Wang,Weiming wrote: >Firstly , I think even if we use it only as a correlator, the number should >sitll not be generated randomly, rather sequencially. Secondly, it therefore >menas we actually doesn't pay too much by introducing the Sequential Number in >while without loosing the correlator function. Thirdly, it maybe too early to >say a SN is not at all useful for the protocol PL level. For this point, I >suppose we should distinguish the idea of the protocol message sequence >from the >TML transport sequence a little. I can curretnly see two cases where >protocol SN >may make senses to PL thought not to TML: > >1. For messages like Packet redirect messages, transport order of which >may not >strictly requred, but the sequence of the redirected packets still make >sense to >the applications of the packets. > >2. Usually, core PL process runs in a multi-thread mode, in this case, a >SN can >act well as a tracker for the process. This can be used at PL-TML interface PL >side as well as the TML side. This may also be used for CE or FE failover >case >like graceful restart. > >Cheers, >Weiming > >----- Original Message ----- >From: "Khosravi, Hormuzd M" > >I agree, this was along the lines of my previous suggestion. I don't see >the reason for having both a sequence number and a correlator....SN >should not be needed by the PL since the TML provides reliability which >guarantees in-order delivery (acc to the definition). Would you agree? > > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, June 12, 2005 8:00 AM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue54] correlator in the PL message header > >Actually, I would prefer to change the name. > >A Sequence number should have a different sequential value has I hand >messages from the PL to the TML. >A correlator should have distinct values for distinct requests, and >replies >should have the value from the request. >These are not the same property. They may even be in conflict. > >Note that a request originator is capable of remembering the sequence in > >which it sends requests. >Thus, for most purposes a correlator will do more than a sequence >number. >What a correlator does not provide is the ability to compare the order >of a >received even and a received response. If some TML may disorder things, > >that would be lost information. >If that is a big deal, we need two fields. > >But we can not simply treat the sequence number as the correlator. > >Yours, >Joel > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > >Ok, so you're saying we should use the Sequence number as a Correlator. > >If that is the case then we are in agreement, I think. We should update > >the text. > > > >Let me know if I misunderstood you, > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > >Sent: Saturday, June 11, 2005 8:14 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >Yes, a Correlator is useful and currently we have been using the > >Sequence number as correlator. I don't see any other use of the >Sequence > >number since reliability is provided by the TML. I think we should > >change Sequence number to correlator in the draft and update the > >description accordingly unless there is some use for a sequence number. > > > >[Weiming] I think it's too early to say the SN is only for correlation. > >currently I don't think we should a hundred percent to rely on TML for > >thinks > >like sequential ordering. As a safer mode, I still prefer to have it > >as its > >original name of Sequence Number. Correlating request/reply messages > >should > >only be one of its functions. > > > >thanks, > >Weiming > > > >BTW, issue 47 looks like the same one...we should close one of these > >issues. > > > >regards > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > >Sent: Friday, June 10, 2005 9:12 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Robert, > > > >----- Original Message ----- > >From: "Robert Haas" > > > >New submission from Robert Haas : > > > >Adding a correlator seems useful: response messages can be matched to > >the > >request messages even if pipelining and reordering occurs. > >It seems that some are currently using the sequence number as a > >correlator: > >this can be dangerous, and not suitable for event notifications >messages > >(nothing to correlate with). > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > >let the > >response have the same SN as the sender. If so, I cannot follow well > >why it is > >dangerous and not suit for event notifications. Could you clarify this > >more? > > > >Thanks. > >Weiming > > > >But this introduces the risk of flooding an FE with too many commands >as > >there > >is no windowing mechanism in place (yet). > > > >---------- > >category: Technical > >draft: draft-ietf-forces-protocol > >messages: 129 > >nosy: rha > >priority: Should fix > >status: No discussion > >title: correlator in the PL message header > > > >___________________________________________________ > >Forces issue tracker > > > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 09:29:16 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10981 for ; Mon, 13 Jun 2005 09:29:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhpMN-00058U-5Q for forces-archive@IETF.ORG; Mon, 13 Jun 2005 09:52:20 -0400 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.0107AA67@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 9:01:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75214660 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 09:01:13 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 09:01:13 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061306043972:19091 ; Mon, 13 Jun 2005 06:04:39 -0700 References: <468F3FDA28AA87429AD807992E22D07E059E00FE@orsmsx408> <095601c56fc8$30e00fe0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050613072920.02d57420@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 06:04:40 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 06:04:41 AM, Serialize complete at 06/13/2005 06:04:41 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118667668.947.3.camel@localhost.localdomain> Date: Mon, 13 Jun 2005 09:01:07 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050613072920.02d57420@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. > > Hence, the only MUST would be that a responder MUST put the correlator from > a request into the response. > > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding > requests for different requests." makes sense. I would not want to make > that a MUST. > > An receiver MUST NOT apply any semantics to received correlators. > > Sequence information is either derivable from the TML or should be in a > separate field. > Yours, > Joel > > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence > >from the > >TML transport sequence a little. I can curretnly see two cases where > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which > >may not > >strictly requred, but the sequence of the redirected packets still make > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 11:35:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22692 for ; Mon, 13 Jun 2005 11:35:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhrKs-0002eG-HC for forces-archive@IETF.ORG; Mon, 13 Jun 2005 11:58:51 -0400 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.0107AE53@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 11:35:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75246511 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 11:35:44 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 11:35:44 -0400 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 j5DFZhOt024020; Mon, 13 Jun 2005 15:35:43 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 j5DFZgCv020050; Mon, 13 Jun 2005 15:35:43 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 M2005061308354320699 ; Mon, 13 Jun 2005 08:35:43 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 08:35:25 -0700 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: [issue54] correlator in the PL message header Thread-Index: AcVwGbwfft3elyO7S4iKoPohCvLQlwAEwFyQ X-OriginalArrivalTime: 13 Jun 2005 15:35:25.0349 (UTC) FILETIME=[84C85D50:01C5702D] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05A255BA@orsmsx408> Date: Mon, 13 Jun 2005 08:36:02 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable I also agree that a correlator field looks to be useful. Given that at least a few people are arguing that a requirement of the TML is to guarantee in order delivery, the correlator field appears to be more useful than the sequence number field. The argument seems to be more whether two fields are needed, not whether a correlator field is useful. Perhaps the better way to ask is which option is preferred, to determine if there is consensus: 1) Correlator field only 2) Sequence number field only 3) Both (I vote for option 1) Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 6:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue54] correlator in the PL message header Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. >=20 > Hence, the only MUST would be that a responder MUST put the correlator from=20 > a request into the response. >=20 > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding=20 > requests for different requests." makes sense. I would not want to make=20 > that a MUST. >=20 > An receiver MUST NOT apply any semantics to received correlators. >=20 > Sequence information is either derivable from the TML or should be in a=20 > separate field. > Yours, > Joel >=20 > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence=20 > >from the > >TML transport sequence a little. I can curretnly see two cases where=20 > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which=20 > >may not > >strictly requred, but the sequence of the redirected packets still make=20 > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a=20 > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover=20 > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ From LindaKim@besuit.com Mon Jun 13 12:33:01 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28162; Mon, 13 Jun 2005 12:32:59 -0400 (EDT) Received: from [221.126.141.6] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhsEE-0005R3-06; Mon, 13 Jun 2005 12:56:06 -0400 Received: from q9CH@localhost by J5mE.int (8.11.6/8.11.6); Mon, 13 Jun 2005 19:35:12 +0200 Message-ID: <3JVAMioIgDCT5YUvVB0LCH@alod.net> From: "Carolyn Christian" Reply-To: "Carolyn Christian" To: stun-owner@ietf.org, iips@ietf.org, forces-archive@ietf.org Subject: MS Office 2003 Pro $69.95 Macromedia Date: Mon, 13 Jun 2005 14:35:12 -0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LindaKim@besuit.com Content-Type: multipart/mixed; boundary="--YYtf23VCKUw9l3ji00b" X-Spam-Score: 3.6 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 YJs ----YYtf23VCKUw9l3ji00b Content-Type: text/html; Content-Transfer-Encoding: quoted-printable p
Opt-in Email Special Offer &n= bsp;   unsubscribe me<= a href=3Dhttp://trancesoft.net/?7>
= =
<= td bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

<= td width=3D8>4= 79

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Wi= ndows XP Pro
 3 Adobe= Creative Suite Premium
  Norton Antivirus 2005
 5 Flash MX 2004
 6 = Corel Draw 12
  Adobe Acrobat 7.0
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Micro= soft
  = Apple Software<= /td>
  Customers also bought=
   these other items...
=



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
<= /a> 
List Price:<= /td>$899.00
Price:$69.99
You Save:$830.01 (92%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  <= a href=3Dhttp://trancesoft.net/?w>Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: June 30th, 2005
Aver= age Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft W= indows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Pr= ice:$279.00
Pric= e:$49.99
You Save:$229.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: ISe229
Media: CD-ROM / Download

System requirements=   |  Accessories  |&= nbsp; Other Versions

<= b>Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video,= DVDs, and more
  • More securit= y with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support <= /font>
  • Integration with Windows serv= ers and management solutions

Sal= es Rank: #2
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

=
Adobe Photoshop CS2 V 9.0
Adobe
=
Choose= :
&n= bsp;

<= /table>



Availability: Available for INSTAN= T download!
Coupon Code: ISe229
Media: CD-ROM / Down= load

System requirements  |  Accessories  |  Other Ve= rsions

Features:

  • Customized workspace; = save personalized workspace and tool settings; create customized shortcuts=
  • Unparalleled efficiency--a= utomate production tasks with built-in or customized scripts
    • =
  • Improved file management, new design poss= ibilities, and a more intuitive way to create for the Web
    • Support for 16-bit images, digital camera ra= w data, and non-square pixels
  • Create or modify photos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)
----YYtf23VCKUw9l3ji00b-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 13:29:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01900 for ; Mon, 13 Jun 2005 13:29:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dht6b-0007jW-3g for forces-archive@IETF.ORG; Mon, 13 Jun 2005 13:52:14 -0400 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.0107B099@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 13:29:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75255498 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 13:29:06 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 13:29:05 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061310323196:19441 ; Mon, 13 Jun 2005 10:32:31 -0700 References: <468F3FDA28AA87429AD807992E22D07E05A255BA@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 10:32:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 10:32:33 AM, Serialize complete at 06/13/2005 10:32:33 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118683740.947.75.camel@localhost.localdomain> Date: Mon, 13 Jun 2005 13:29:00 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05A255BA@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Mon, 2005-13-06 at 08:36 -0700, Deleganes, Ellen M wrote: > I also agree that a correlator field looks to be useful. Given that at > least a few people are arguing that a requirement of the TML is to > guarantee in order delivery, the correlator field appears to be more > useful than the sequence number field. > > The argument seems to be more whether two fields are needed, not whether > a correlator field is useful. > > Perhaps the better way to ask is which option is preferred, to determine > if there is consensus: > 1) Correlator field only > 2) Sequence number field only > 3) Both > > (I vote for option 1) A sequence number could be used as a correlator. That's what we are doing today in our implementation for example. But that in itself is making some assumption about the implementation details and to a small degree OS level details[1]. Infact, given our implementation today we may never need the corellator number - although on occasion i do worry about transactional issues and Ha when we get to it. It would certainly ease the state maintainance we do if we had it; OTOH, if forces was already released as an RFC i could live without it. We are not at that stage yet and i dont wanna impose how we implement onto Robert. Despite the above, I think Joel put it best in one of his emails, to quote: "A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers. The correlator is, to be precise, opaque to the receiver (typically FE) whereas the sequence number could be intepreted. cheers, jamal Unfortunately, such assumptions could get us in trouble and i would rather give up 32 bits now than regret later. [To compare with the callback model and the associated correlators in the NPF APIs model where we are currenlty working around assumptions (such as a flat memory space OS or the implementation using multithreading).] From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 13:34:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02326 for ; Mon, 13 Jun 2005 13:34:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhtBd-0007yf-5N for forces-archive@IETF.ORG; Mon, 13 Jun 2005 13:57:29 -0400 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.0107AF02@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 13:34:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75256148 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 13:34:18 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 13:34:18 -0400 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 j5DHYH2l005445; Mon, 13 Jun 2005 17:34:17 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 j5DHY9Ct014032; Mon, 13 Jun 2005 17:34:17 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 M2005061310341718612 ; Mon, 13 Jun 2005 10:34:17 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 10:34:17 -0700 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: [issue54] correlator in the PL message header Thread-Index: AcVwPWxfIqZp0LGCSGyUl/N34iTSWAAAFC4Q X-OriginalArrivalTime: 13 Jun 2005 17:34:17.0316 (UTC) FILETIME=[1FC42A40:01C5703E] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05A2595D@orsmsx408> Date: Mon, 13 Jun 2005 10:34:58 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable I should have been clearer. When I voted for option 1, I didn't mean to imply the sequence number field is overloaded to mean the same thing as the correlator. I agree that the correlator should not be tied to the sequence number. It should be up to the issuer of the requester to assign a correlator to the request, which is echoed in the response. There seems to be some question as to whether a sequence number is needed. If the sequence number is required, then I would change my vote to option 3 (both fields). Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 10:29 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue54] correlator in the PL message header On Mon, 2005-13-06 at 08:36 -0700, Deleganes, Ellen M wrote: > I also agree that a correlator field looks to be useful. Given that at > least a few people are arguing that a requirement of the TML is to > guarantee in order delivery, the correlator field appears to be more > useful than the sequence number field. >=20 > The argument seems to be more whether two fields are needed, not whether > a correlator field is useful. >=20 > Perhaps the better way to ask is which option is preferred, to determine > if there is consensus: > 1) Correlator field only > 2) Sequence number field only > 3) Both >=20 > (I vote for option 1) A sequence number could be used as a correlator. That's what we are doing today in our implementation for example.=20 But that in itself is making some assumption about the implementation details and to a small degree OS level details[1]. Infact, given our implementation today we may never need the corellator number - although on occasion i do worry about transactional issues and Ha when we get to it. It would certainly ease the state maintainance we do if we had it; OTOH, if forces was already released as an RFC i could live without it. We are not at that stage yet and i dont wanna impose how we implement onto Robert. Despite the above, I think Joel put it best in one of his emails, to quote: "A Sequence number should have a different sequential value has I hand=20 messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers.=20 The correlator is, to be precise, opaque to the receiver (typically FE) whereas the sequence number could be intepreted. cheers, jamal Unfortunately, such assumptions could get us in trouble and i would rather give up 32 bits now than regret later. [To compare with the callback model and the associated correlators in the NPF APIs model where we are currenlty working around assumptions (such as a flat memory space OS or the implementation using multithreading).] From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 14:01:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04377 for ; Mon, 13 Jun 2005 14:01:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhtc6-0000iU-L7 for forces-archive@IETF.ORG; Mon, 13 Jun 2005 14:24:47 -0400 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.0107B0A8@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 14:01:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75257760 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 14:01:39 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 14:01:39 -0400 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 j5DI1aOt024188; Mon, 13 Jun 2005 18:01: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 j5DI0pDU009816; Mon, 13 Jun 2005 18:01:36 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005061311013617264 ; Mon, 13 Jun 2005 11:01:36 -0700 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, 13 Jun 2005 11:01:36 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVwPWtWF926LStRQKCcCLOmDg0rgQAAwpTQ X-OriginalArrivalTime: 13 Jun 2005 18:01:36.0495 (UTC) FILETIME=[F0CB07F0:01C57041] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05A25A78@orsmsx408> Date: Mon, 13 Jun 2005 11:01:35 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: cc: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Jamal,=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim The TML sequence number is a transport level one and really has nothing to do with PL level. A PL level sequence could in fact be multiple transport level sequence numbers.=20 [HK] I did not see any reason from you regarding why to retain the SN, just that we should do it. We need to have a good technical reasons in the draft for the different protocol fields. I did see a good technical reason from Weiming for the SN, 1. For messages like Packet redirect messages, transport order of which may not strictly required, but the sequence of the redirected packets still make sense to the applications of the packets. If this is the case, I would vote for having both SN & Correlator in the header. So we can close this issue, I guess...unless there are any other concerns. regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 14:15:28 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05264 for ; Mon, 13 Jun 2005 14:15:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhtpR-0001JH-91 for forces-archive@IETF.ORG; Mon, 13 Jun 2005 14:38:34 -0400 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.0107B0E6@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 14:15:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75258766 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 14:15:17 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 14:15:17 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061311184348:19524 ; Mon, 13 Jun 2005 11:18:43 -0700 References: <468F3FDA28AA87429AD807992E22D07E05A25A78@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 11:18:43 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 11:18:44 AM, Serialize complete at 06/13/2005 11:18:44 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118686512.947.83.camel@localhost.localdomain> Date: Mon, 13 Jun 2005 14:15:12 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05A25A78@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Mon, 2005-13-06 at 11:01 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > The TML sequence number is a transport level one and really has nothing > to do with PL level. A PL level sequence could in fact be multiple > transport level sequence numbers. > > [HK] I did not see any reason from you regarding why to retain the SN, > just that we should do it. We need to have a good technical reasons in > the draft for the different protocol fields. > Are you sure you read my email, Hormuzd?;-> I quoted Joels email because it gave a very good summary > I did see a good technical reason from Weiming for the SN, > 1. For messages like Packet redirect messages, transport order of which > may not > strictly required, but the sequence of the redirected packets still make > sense to > the applications of the packets. > > If this is the case, I would vote for having both SN & Correlator in the > header. > So we can close this issue, I guess...unless there are any other > concerns. > Lets wait for Weiming to respond and close it i think. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 14:32:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06533 for ; Mon, 13 Jun 2005 14:32:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhu6B-00026n-KJ for forces-archive@IETF.ORG; Mon, 13 Jun 2005 14:55:52 -0400 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.0107B1BD@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 14:32:45 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75260148 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 14:32:43 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 14:32:43 -0400 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 j5DIWhMv028087; Mon, 13 Jun 2005 18:32:43 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 j5DIVxDf008003; Mon, 13 Jun 2005 18:32:43 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 M2005061311324232513 ; Mon, 13 Jun 2005 11:32:42 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 11:32:42 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVwGb0qWL2JnyqiTa+rPMWH0hka6QACwxKg X-OriginalArrivalTime: 13 Jun 2005 18:32:42.0783 (UTC) FILETIME=[492FFAF0:01C57046] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Mon, 13 Jun 2005 11:32:42 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: quoted-printable I believe that FE should not make any assumptions about the correlator values. While the CE may make them sequential (or choose them using any other algorithm it wishes), the FE should not rely on it. This is both to allow the CE implementor freedom and in order to make the FE more robust - if the spec mandated that the correlators be sequential, and the FE relied on that property, a CE with a bug in the sequence would cause FE failure. A more robust FE would not rely on the sequence (under the be liberal in what you accept guideline). Given this, it is better to simply remove the constraint that the CE make them sequential. I've found correlators/cookies to be useful in similar contexts as this, so I support putting one in. For sequencing, I prefer to rely on the TML for this, as it is not clear to me why one would want to lift it out of the TML. Cheers, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, June 13, 2005 6:01 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Ok, folks lets put closure to this: so far the stick-finger-in-the-air answer i am seeing to the question "should we add a correlator field in the main header in addition to existing sequence number?" Jamal: 100% yes Robert: 100% yes Joel: 65% yes - Joel can we get a boolean from you? Hormuzd: 100% no Weiming:Not sure where you stand. cheers, jamal On Mon, 2005-13-06 at 07:31 -0400, Joel M. Halpern wrote: > Actually, I would prefer to put as few restrictions as possible on the > creator of the correlator, so as to allow the most implementation freedom. >=20 > Hence, the only MUST would be that a responder MUST put the correlator from=20 > a request into the response. >=20 > It seems like "A requestor SHOULD NOT reuse the correlator from outstanding=20 > requests for different requests." makes sense. I would not want to make=20 > that a MUST. >=20 > An receiver MUST NOT apply any semantics to received correlators. >=20 > Sequence information is either derivable from the TML or should be in a=20 > separate field. > Yours, > Joel >=20 > At 11:30 PM 6/12/2005, Wang,Weiming wrote: > >Firstly , I think even if we use it only as a correlator, the number should > >sitll not be generated randomly, rather sequencially. Secondly, it therefore > >menas we actually doesn't pay too much by introducing the Sequential Number in > >while without loosing the correlator function. Thirdly, it maybe too early to > >say a SN is not at all useful for the protocol PL level. For this point, I > >suppose we should distinguish the idea of the protocol message sequence=20 > >from the > >TML transport sequence a little. I can curretnly see two cases where=20 > >protocol SN > >may make senses to PL thought not to TML: > > > >1. For messages like Packet redirect messages, transport order of which=20 > >may not > >strictly requred, but the sequence of the redirected packets still make=20 > >sense to > >the applications of the packets. > > > >2. Usually, core PL process runs in a multi-thread mode, in this case, a=20 > >SN can > >act well as a tracker for the process. This can be used at PL-TML interface PL > >side as well as the TML side. This may also be used for CE or FE failover=20 > >case > >like graceful restart. > > > >Cheers, > >Weiming > > > >----- Original Message ----- > >From: "Khosravi, Hormuzd M" > > > >I agree, this was along the lines of my previous suggestion. I don't see > >the reason for having both a sequence number and a correlator....SN > >should not be needed by the PL since the TML provides reliability which > >guarantees in-order delivery (acc to the definition). Would you agree? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, June 12, 2005 8:00 AM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > >Actually, I would prefer to change the name. > > > >A Sequence number should have a different sequential value has I hand > >messages from the PL to the TML. > >A correlator should have distinct values for distinct requests, and > >replies > >should have the value from the request. > >These are not the same property. They may even be in conflict. > > > >Note that a request originator is capable of remembering the sequence in > > > >which it sends requests. > >Thus, for most purposes a correlator will do more than a sequence > >number. > >What a correlator does not provide is the ability to compare the order > >of a > >received even and a received response. If some TML may disorder things, > > > >that would be lost information. > >If that is a big deal, we need two fields. > > > >But we can not simply treat the sequence number as the correlator. > > > >Yours, > >Joel > > > >At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote: > > >Ok, so you're saying we should use the Sequence number as a Correlator. > > >If that is the case then we are in agreement, I think. We should update > > >the text. > > > > > >Let me know if I misunderstood you, > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Saturday, June 11, 2005 8:14 PM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >----- Original Message ----- > > >From: "Khosravi, Hormuzd M" > > > > > >Yes, a Correlator is useful and currently we have been using the > > >Sequence number as correlator. I don't see any other use of the > >Sequence > > >number since reliability is provided by the TML. I think we should > > >change Sequence number to correlator in the draft and update the > > >description accordingly unless there is some use for a sequence number. > > > > > >[Weiming] I think it's too early to say the SN is only for correlation. > > >currently I don't think we should a hundred percent to rely on TML for > > >thinks > > >like sequential ordering. As a safer mode, I still prefer to have it > > >as its > > >original name of Sequence Number. Correlating request/reply messages > > >should > > >only be one of its functions. > > > > > >thanks, > > >Weiming > > > > > >BTW, issue 47 looks like the same one...we should close one of these > > >issues. > > > > > >regards > > >Hormuzd > > > > > >-----Original Message----- > > >From: Forwarding and Control Element Separation > > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > >Sent: Friday, June 10, 2005 9:12 AM > > >To: FORCES@PEACH.EASE.LSOFT.COM > > >Subject: Re: [FORCES] [issue54] correlator in the PL message header > > > > > >Robert, > > > > > >----- Original Message ----- > > >From: "Robert Haas" > > > > > >New submission from Robert Haas : > > > > > >Adding a correlator seems useful: response messages can be matched to > > >the > > >request messages even if pipelining and reordering occurs. > > >It seems that some are currently using the sequence number as a > > >correlator: > > >this can be dangerous, and not suitable for event notifications > >messages > > >(nothing to correlate with). > > >[Weiming] I'm not sure if you mean to use the SN as a correlator is to > > >let the > > >response have the same SN as the sender. If so, I cannot follow well > > >why it is > > >dangerous and not suit for event notifications. Could you clarify this > > >more? > > > > > >Thanks. > > >Weiming > > > > > >But this introduces the risk of flooding an FE with too many commands > >as > > >there > > >is no windowing mechanism in place (yet). > > > > > >---------- > > >category: Technical > > >draft: draft-ietf-forces-protocol > > >messages: 129 > > >nosy: rha > > >priority: Should fix > > >status: No discussion > > >title: correlator in the PL message header > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 14:32:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06566 for ; Mon, 13 Jun 2005 14:32:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhu6D-00026y-Hd for forces-archive@IETF.ORG; Mon, 13 Jun 2005 14:55:53 -0400 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.0107B163@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 14:32:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75260154 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 14:32:46 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 14:32:46 -0400 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 j5DIWj2l008876; Mon, 13 Jun 2005 18:32:45 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 j5DIWgCt008701; Mon, 13 Jun 2005 18:32:45 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 M2005061311324523250 ; Mon, 13 Jun 2005 11:32:45 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 11:32:45 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVvZJG6gef3smNuSR2TGAeB9d7+ZAAzgc2g X-OriginalArrivalTime: 13 Jun 2005 18:32:45.0399 (UTC) FILETIME=[4ABF2670:01C57046] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Mon, 13 Jun 2005 11:32:44 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: [issue54] correlator in the PL message header Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Small question on the size of the seq# and correlator# sizes. The sizes should be large enough to unambiguously distinguish different messages (for the correlator) and order different messages (for a sequence number). It seems to me both a 16 bit and a 32 bit length will eventually roll over, so we need to deal with roll over no matter what. If that is the case, I wonder if we can get away with 16 (or 24) bit values for either one?=20 For sequence numbering, if we assume 500 bytes to store a message and all related context, a 2^16 messages would require 32MB of buffering, which is pretty significant. 2^24 would require a very large amount - so it feels to me that a full 32 bits is not needed. =20 For a correlator it seems to me to depend on how many simultaneous active transactions are expected. This also feels like a scenario where a full 32 bits is not needed. The above being said, I am mindful of the risk of being overly conservative in such decisions, so I am not sure whether going shorter than 32 is a good idea or not. What has been the implementation experience with Netlink and other protocols such as GSMP? Thanks, David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 13 16:22:53 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03374 for ; Mon, 13 Jun 2005 16:22:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhvom-00046R-0Q for forces-archive@IETF.ORG; Mon, 13 Jun 2005 16:46:01 -0400 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.0107B401@cherry.ease.lsoft.com>; Mon, 13 Jun 2005 16:22:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75267590 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Jun 2005 16:22:42 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 13 Jun 2005 16:22:42 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061313260867:19758 ; Mon, 13 Jun 2005 13:26:08 -0700 References: Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 01:26:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/13/2005 01:26:09 PM, Serialize complete at 06/13/2005 01:26:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118694157.947.103.camel@localhost.localdomain> Date: Mon, 13 Jun 2005 16:22:37 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Putzolu, David" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit On Mon, 2005-13-06 at 11:32 -0700, Putzolu, David wrote: > Small question on the size of the seq# and correlator# sizes. > > The sizes should be large enough to unambiguously distinguish different > messages (for the correlator) and order different messages (for a > sequence number). > > It seems to me both a 16 bit and a 32 bit length will eventually roll > over, so we need to deal with roll over no matter what. If that is the > case, I wonder if we can get away with 16 (or 24) bit values for either > one? > > For sequence numbering, if we assume 500 bytes to store a message and > all related context, a 2^16 messages would require 32MB of buffering, > which is pretty significant. 2^24 would require a very large amount - > so it feels to me that a full 32 bits is not needed. > > For a correlator it seems to me to depend on how many simultaneous > active transactions are expected. This also feels like a scenario where > a full 32 bits is not needed. > Agreed. If i was to handwave i would say a 16 bit number would be sufficient for the correlator. 32 bit is sufficient for a sequence number I would think. > The above being said, I am mindful of the risk of being overly > conservative in such decisions, so I am not sure whether going shorter > than 32 is a good idea or not. What has been the implementation > experience with Netlink and other protocols such as GSMP? > Netlink is currently overloading the 32 bit sequence number on a per-process level for a correlator; this is currently causing some headaches in the case of conflicts and in particular when you have more than one socket open by the same process (anology would be if you had more than one connection between PL and TML at say the CE - not far off if you look at Roberts model of implementation). The result is the kernel does some funky things by changing the PID (equivalent to FEID) for multiple users coming from the same process. Under such conflicts the ability to use netlink for IPC breaks. [The good news is you can work around it by using getsockname() syscall to find out what real values the kernel overrides for you. This would have been real easy to resolve if netlink had a correlator in its header - wed just ask the kernel not to be clever]. It's a good lesson is the summary. cheers, jamal From RileyCapps@carbonero.com Mon Jun 13 20:51:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26206 for ; Mon, 13 Jun 2005 20:51:51 -0400 (EDT) From: RileyCapps@carbonero.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di016-0008IN-GP for forces-archive@ietf.org; Mon, 13 Jun 2005 21:15:01 -0400 Received: from pcp02515313pcs.aubrnh01.mi.comcast.net ([68.60.157.183]) by mx2.foretec.com with smtp (Exim 4.24) id 1DhzeZ-0005Pb-4X for forces-archive@ietf.org; Mon, 13 Jun 2005 20:51:43 -0400 Received: from r[3 Message-Id: Date: Mon, 13 Jun 2005 20:51:43 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 14 10:39:55 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23203 for ; Tue, 14 Jun 2005 10:39:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiCwV-00053r-Qk for forces-archive@IETF.ORG; Tue, 14 Jun 2005 11:03:13 -0400 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.0107C566@cherry.ease.lsoft.com>; Tue, 14 Jun 2005 10:39:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75379048 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jun 2005 10:39:40 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 14 Jun 2005 10:39:40 -0400 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 j5EEddmr003913 for ; Tue, 14 Jun 2005 14:39:39 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 j5EEdXIi021995 for ; Tue, 14 Jun 2005 14:39:39 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 M2005061407393902766 for ; Tue, 14 Jun 2005 07:39:39 -0700 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, 14 Jun 2005 07:39:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C570EE.E48988B1" Thread-Topic: Issue closure Thread-Index: AcVw7uS8NRSH9uEsRFqnoxgyKEKu8Q== X-OriginalArrivalTime: 14 Jun 2005 14:39:39.0217 (UTC) FILETIME=[E4BEE410:01C570EE] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 14 Jun 2005 07:39:39 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Issue closure To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. ------_=_NextPart_001_01C570EE.E48988B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 The following issues on the ForCES issue tracker are pending closure. This means that the mailing list has a final opportunity to review them prior to them being considered closed. Please read all of the issues referred to below. If there are any concerns or questions about the proposed closure, please reply to the list by Monday, June 20. =20 http://www.mip4.org/issues/tracker/forces/issue6 http://www.mip4.org/issues/tracker/forces/issue11 http://www.mip4.org/issues/tracker/forces/issue12 http://www.mip4.org/issues/tracker/forces/issue18 http://www.mip4.org/issues/tracker/forces/issue21 http://www.mip4.org/issues/tracker/forces/issue25 http://www.mip4.org/issues/tracker/forces/issue30 http://www.mip4.org/issues/tracker/forces/issue35 =20 Thanks, David ------_=_NextPart_001_01C570EE.E48988B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The following issues on the ForCES issue tracker are = pending closure.  This means that the mailing list has a final opportunity = to review them prior to them being considered closed.  Please read all = of the issues referred to below.  If there are any concerns or questions = about the proposed closure, please reply to the list by Monday, June = 20.

 

http://www.mip4= .org/issues/tracker/forces/issue6

http://www.mip= 4.org/issues/tracker/forces/issue11

http://www.mip= 4.org/issues/tracker/forces/issue12

http://www.mip= 4.org/issues/tracker/forces/issue18

http://www.mip= 4.org/issues/tracker/forces/issue21

http://www.mip= 4.org/issues/tracker/forces/issue25

http://www.mip= 4.org/issues/tracker/forces/issue30

http://www.mip= 4.org/issues/tracker/forces/issue35

 

Thanks,

David

------_=_NextPart_001_01C570EE.E48988B1-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 14 11:09:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24757 for ; Tue, 14 Jun 2005 11:09:53 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDPV-0006rp-Pp for forces-archive@IETF.ORG; Tue, 14 Jun 2005 11:33:11 -0400 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.0107C667@cherry.ease.lsoft.com>; Tue, 14 Jun 2005 11:09:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75381045 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jun 2005 11:09:48 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 14 Jun 2005 11:09:47 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Tue, 14 Jun 2005 23:43:45 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: <007a01c570f3$ae0a6d90$020aa8c0@wwm1> Date: Tue, 14 Jun 2005 23:13:52 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: base64 TXkgb3BpbmlvbiBpczoNCg0KMS4gIEZ1bmN0aW9uIHRvIGNvcnJlbGF0ZSBhIHJlcXVlc3QgdG8g YSByZXNwb25zZSBpcyBuZWNlc3NhcnkuDQogICAgU2VlbXMgbm8gb25lIG9iamVjdGluZyB0byB0 aGlzLg0KDQoyLiBQTCBtZXNzYWdlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGlzIGFsc28gbmVjZXNz YXJ5DQogICAgT25lIG9mICB0aGUgcmVhc29uIG5vdyBJIGNhbiB0aGluayBvZiBpcyBmb3IgcGFj a2V0IHJlZGlyZWN0IG1lc3NhZ2VzLiBOb3RlIHRoYXQgd2UgaGF2ZW4ndCBtYWtlIGEgcmVsaWFi aWxpdHkgcmVxaXJlbWVudCBmb3IgcGFja2V0IHJlZGlyZWN0aW9uLCB3aGlsZSB0aGUgc2VxdWVu Y2Ugb2YgcmVkaXJlY3RlZCBwYWNrZXRzIGFyZSB1c2VmdWwgZm9yIHRoZXNlIHBhY2tldHMgYXBw bGljYXRpb25zLg0KDQozLiBJdCBjYW4gZnVsZmlsbCB0aGUgZnVuY3Rpb24gMSkgd2VsbCBieSBk ZWZpbmluZyB0aGF0IGEgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgYWx3YXlzIGhhdmUgdGhlIHNh bWUgU04gd2l0aCB0aGUgcmVxdWVzdCB0byByZXBseSwgaGVuY2Ugd2Ugb25seSBuZWVkIG9uZSBm aWVsZCB0aGF0IGlzIGNhbGxlZCBzZXF1ZW5jZSBudW1iZXIuIA0KDQpQLlMuIA0KMS4gU2VxdWVu Y2UgbnVtYmVyIHNob3VsZCBiZSBtYWludGFpbmVkIHBlciBDRSBhbmQgRkUgc2VwYXJhdGVseSwg YW5kIHRoZSBtZXNzYWdlIHR5cGUgdW5pcXVlbHkgcmVjb2duaXplIGEgbWVzc2FnZSBhcyBhIHJl c3BvbnNlIG1lc3NhZ2UsIHRoZXJlZm9yZSB0aGVyZSB3aWxsIGJlIG5vIG9wYXF1ZSBpbiB0aGUg U2VxdWVuY2UgbnVtYmVyIG1haW50YWluY2UuIA0KMi4gU2VxdWVuY2UgbnVtYmVyIG9mIGFuIGV2 ZW50IGZyb20gRkUgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBGRSwgd2hpbGUgcmVzcG9uc2Ugb2YgdGhl IGV2ZW50IChpZiBhbnkpIHNob3VsZCBoYXZlIHRoZSBzYW1lIHNlcXVlbmNlIG51bWJlciBhcyB0 aGUgZXZlbnQgdG8gcmVzcG9uc2UuIA0KMy4gQSByZXNwb25zZSB0byBiYXRjaGluZyBtZXNzYWdl cyB0byBtZWV0IHR3by1waGFzZS1jb21taXRzIHdpbGwgaGF2ZSB0aGUgc2FtZSBTTiBhcyB0aGF0 IG9mIHRoZSBmaXJzdCBtZXNzYWdlIG9yIHRoZSBsYXN0IG1lc3NhZ2UgaW4gdGhlIGJhdGNoLCBq dXN0IGFzIHdoYXQgd2UnZCBsaWtlIHRvIGRlZmluZS4NCg0KVGhhbmtzLA0KV2VpbWluZw0K From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 14 11:36:42 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27783 for ; Tue, 14 Jun 2005 11:36:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiDpX-0000LR-59 for forces-archive@IETF.ORG; Tue, 14 Jun 2005 12:00:00 -0400 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.0107C5BD@cherry.ease.lsoft.com>; Tue, 14 Jun 2005 11:36:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75383290 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jun 2005 11:36:41 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 14 Jun 2005 11:36:40 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5EFacGM203906 for ; Tue, 14 Jun 2005 15:36:38 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5EFacet280606 for ; Tue, 14 Jun 2005 16:36:38 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5EFabMu009493 for ; Tue, 14 Jun 2005 16:36:37 +0100 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 j5EFabtW009479; Tue, 14 Jun 2005 16:36:37 +0100 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA91232; Tue, 14 Jun 2005 17:36:37 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id j5EFacGM203906 Approved-By: Robert Haas Message-ID: <42AEF977.9090900@zurich.ibm.com> Date: Tue, 14 Jun 2005 17:36:23 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007a01c570f3$ae0a6d90$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Weiming, I agree with 1 and 2, but I would not merge the two into the same=20 sequence number concept. As an example, according to your suggestion,=20 event notifications and packet redirections should be numbered according=20 to a different sequence than response messages for which the numbering=20 is imposed by the CE. So the CE would have to maintain two independent=20 parallel sequences. This is unnecessary complexity to me. Regards, -Robert Weiming Wang wrote: >My opinion is: > >1. Function to correlate a request to a response is necessary. > Seems no one objecting to this. > >2. PL message sequential numbering is also necessary > One of the reason now I can think of is for packet redirect message= s. Note that we haven't make a reliability reqirement for packet redirect= ion, while the sequence of redirected packets are useful for these packet= s applications. > >3. It can fulfill the function 1) well by defining that a response messa= ge should always have the same SN with the request to reply, hence we onl= y need one field that is called sequence number.=20 > >P.S.=20 >1. Sequence number should be maintained per CE and FE separately, and th= e message type uniquely recognize a message as a response message, theref= ore there will be no opaque in the Sequence number maintaince.=20 >2. Sequence number of an event from FE is generated by the FE, while res= ponse of the event (if any) should have the same sequence number as the e= vent to response.=20 >3. A response to batching messages to meet two-phase-commits will have t= he same SN as that of the first message or the last message in the batch,= just as what we'd like to define. > >Thanks, >Weiming > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 14 20:51:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22874 for ; Tue, 14 Jun 2005 20:51:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiMUk-0007tJ-2i for forces-archive@IETF.ORG; Tue, 14 Jun 2005 21:15:09 -0400 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.0107D440@cherry.ease.lsoft.com>; Tue, 14 Jun 2005 20:51:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75422470 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Jun 2005 20:51:43 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 14 Jun 2005 20:51:42 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 74778.1341347395; Wed, 15 Jun 2005 09:25:11 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: <001a01c57144$e4d6e2d0$020aa8c0@wwm1> Date: Wed, 15 Jun 2005 08:55:15 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: base64 Um9ib3J0LA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydCBI YWFzIiA8cmhhQHp1cmljaC5pYm0uY29tPg0KDQpXZWltaW5nLA0KSSBhZ3JlZSB3aXRoIDEgYW5k IDIsIGJ1dCBJIHdvdWxkIG5vdCBtZXJnZSB0aGUgdHdvIGludG8gdGhlIHNhbWUgDQpzZXF1ZW5j ZSBudW1iZXIgY29uY2VwdC4gQXMgYW4gZXhhbXBsZSwgYWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2Vz dGlvbiwgDQpldmVudCBub3RpZmljYXRpb25zIGFuZCBwYWNrZXQgcmVkaXJlY3Rpb25zIHNob3Vs ZCBiZSBudW1iZXJlZCBhY2NvcmRpbmcgDQp0byBhIGRpZmZlcmVudCBzZXF1ZW5jZSB0aGFuIHJl c3BvbnNlIG1lc3NhZ2VzIGZvciB3aGljaCB0aGUgbnVtYmVyaW5nIA0KaXMgaW1wb3NlZCBieSB0 aGUgQ0UuIA0KW1dlaW1pbmddIEkgZGlkbid0ICAgdGhpbmsgbGlrZSB0aGlzLiBXaHkgdGhlIHJl c3BvbnNlIG1lc3NhZ2Ugc2hvdWxkIGJlIG51bWJlcmVkIGJ5IGFuIENFIGhlcmU/ICANCg0KU28g dGhlIENFIHdvdWxkIGhhdmUgdG8gbWFpbnRhaW4gdHdvIGluZGVwZW5kZW50IA0KcGFyYWxsZWwg c2VxdWVuY2VzLiBUaGlzIGlzIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgdG8gbWUuDQpbV2VpbWlu Z10gSSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCB3aGF0IEkgdGhpbmsgb2YgZm9yIHRoaXMgY2Fz ZSBpcyB3ZSBuZXZlciBoYXZlIHR3byBzZXF1ZW5jZXMgdG8gbWFpbnRhaW4gaW4gb25lIHNhbWUg IENFIG9yIEZFLiAgV2Ugb25seSBoYXZlIG9uZSBTTiBmb3Igb25lIENFIGFuZCBvbmUgU04gZm9y IG9uZSBGRS4gTm90ZSB0aGF0IHdlIGRvbid0IG5lZWQgdG8gbWFpbnRhaW4gYSBTTiBmb3IgYW55 IHJlc3BvbnNlIG1lc3NhZ2VzIHRoZW4uIA0KDQpUaGFua3MsDQpXZWltaW5nDQoNClJlZ2FyZHMs DQotUm9iZXJ0DQoNCldlaW1pbmcgV2FuZyB3cm90ZToNCg0KPk15IG9waW5pb24gaXM6DQo+DQo+ MS4gIEZ1bmN0aW9uIHRvIGNvcnJlbGF0ZSBhIHJlcXVlc3QgdG8gYSByZXNwb25zZSBpcyBuZWNl c3NhcnkuDQo+ICAgIFNlZW1zIG5vIG9uZSBvYmplY3RpbmcgdG8gdGhpcy4NCj4NCj4yLiBQTCBt ZXNzYWdlIHNlcXVlbnRpYWwgbnVtYmVyaW5nIGlzIGFsc28gbmVjZXNzYXJ5DQo+ICAgIE9uZSBv ZiAgdGhlIHJlYXNvbiBub3cgSSBjYW4gdGhpbmsgb2YgaXMgZm9yIHBhY2tldCByZWRpcmVjdCBt ZXNzYWdlcy4gTm90ZSB0aGF0IHdlIGhhdmVuJ3QgbWFrZSBhIHJlbGlhYmlsaXR5IHJlcWlyZW1l bnQgZm9yIHBhY2tldCByZWRpcmVjdGlvbiwgd2hpbGUgdGhlIHNlcXVlbmNlIG9mIHJlZGlyZWN0 ZWQgcGFja2V0cyBhcmUgdXNlZnVsIGZvciB0aGVzZSBwYWNrZXRzIGFwcGxpY2F0aW9ucy4NCj4N Cj4zLiBJdCBjYW4gZnVsZmlsbCB0aGUgZnVuY3Rpb24gMSkgd2VsbCBieSBkZWZpbmluZyB0aGF0 IGEgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgYWx3YXlzIGhhdmUgdGhlIHNhbWUgU04gd2l0aCB0 aGUgcmVxdWVzdCB0byByZXBseSwgaGVuY2Ugd2Ugb25seSBuZWVkIG9uZSBmaWVsZCB0aGF0IGlz IGNhbGxlZCBzZXF1ZW5jZSBudW1iZXIuIA0KPg0KPlAuUy4gDQo+MS4gU2VxdWVuY2UgbnVtYmVy IHNob3VsZCBiZSBtYWludGFpbmVkIHBlciBDRSBhbmQgRkUgc2VwYXJhdGVseSwgYW5kIHRoZSBt ZXNzYWdlIHR5cGUgdW5pcXVlbHkgcmVjb2duaXplIGEgbWVzc2FnZSBhcyBhIHJlc3BvbnNlIG1l c3NhZ2UsIHRoZXJlZm9yZSB0aGVyZSB3aWxsIGJlIG5vIG9wYXF1ZSBpbiB0aGUgU2VxdWVuY2Ug bnVtYmVyIG1haW50YWluY2UuIA0KPjIuIFNlcXVlbmNlIG51bWJlciBvZiBhbiBldmVudCBmcm9t IEZFIGlzIGdlbmVyYXRlZCBieSB0aGUgRkUsIHdoaWxlIHJlc3BvbnNlIG9mIHRoZSBldmVudCAo aWYgYW55KSBzaG91bGQgaGF2ZSB0aGUgc2FtZSBzZXF1ZW5jZSBudW1iZXIgYXMgdGhlIGV2ZW50 IHRvIHJlc3BvbnNlLiANCj4zLiBBIHJlc3BvbnNlIHRvIGJhdGNoaW5nIG1lc3NhZ2VzIHRvIG1l ZXQgdHdvLXBoYXNlLWNvbW1pdHMgd2lsbCBoYXZlIHRoZSBzYW1lIFNOIGFzIHRoYXQgb2YgdGhl IGZpcnN0IG1lc3NhZ2Ugb3IgdGhlIGxhc3QgbWVzc2FnZSBpbiB0aGUgYmF0Y2gsIGp1c3QgYXMg d2hhdCB3ZSdkIGxpa2UgdG8gZGVmaW5lLg0KPg0KPlRoYW5rcywNCj5XZWltaW5nDQo+DQo+DQo+ ICANCj4NCg0KLS0gDQpEci4gUm9iZXJ0IFIuIEhhYXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTGFi b3JhdG9yeQ0KU+R1bWVyc3RyYXNzZSA0DQpDSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQN CnBob25lICs0MS00NC03MjQtODY5OCAgZmF4ICs0MS00NC03MjQtODU3OCAgaHR0cDovL3d3dy56 dXJpY2guaWJtLmNvbS9+cmhh From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 04:46:33 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23261 for ; Wed, 15 Jun 2005 04:46:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiTuJ-0008QR-Gq for forces-archive@IETF.ORG; Wed, 15 Jun 2005 05:09:59 -0400 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.0107E2A0@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 4:46:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75449764 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 04:46:30 -0400 Received: from 195.212.29.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 04:46:30 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5F8kOew143210 for ; Wed, 15 Jun 2005 08:46:24 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5F8k3cQ163360 for ; Wed, 15 Jun 2005 10:46:13 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5F8ipZ3020561 for ; Wed, 15 Jun 2005 10:44:51 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j5F8ioh8020546; Wed, 15 Jun 2005 10:44:50 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA83122; Wed, 15 Jun 2005 10:44:49 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id j5F8kOew143210 Approved-By: Robert Haas Message-ID: <42AFEA66.2050901@zurich.ibm.com> Date: Wed, 15 Jun 2005 10:44:22 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001a01c57144$e4d6e2d0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Weiming, Weiming Wang wrote: >Robort, > >----- Original Message -----=20 >From: "Robert Haas" > >Weiming, >I agree with 1 and 2, but I would not merge the two into the same=20 >sequence number concept. As an example, according to your suggestion,=20 >event notifications and packet redirections should be numbered according= =20 >to a different sequence than response messages for which the numbering=20 >is imposed by the CE.=20 >[Weiming] I didn't think like this. Why the response message should be= numbered by an CE here? =20 > > =20 > Maybe I did not understand your point, so let's take a concrete example: -> request from CE to FE, SN 5 <- response from FE to CE, SN 5 (5 is imposed by the CE, necessary for=20 correlation and/or sequencing reasons) -> request from CE to FE, SN 6 (ACK flag off) no response from FE to CE -> request from CE to FE, SN 7 <- response from FE to CE, SN 7 ... so you see above that the CE would have to expect holes in the=20 sequence numbers coming back from the FE. ... but in addition, there is another parallel sequence that the CE has=20 to distinguish: -> packet redirect messages and/or event notifications are sent from FE=20 to CE, SN 11, 12, 13, 14 ... (decided by the FE) ... this means that, in addition to the added complexity of maintaining=20 two parallel sequences, you cannot enforce any ordering between the=20 command responses and the packet redirection/event notifications (=3Dboth= =20 sequences are independent). Moreover, consider the case for which the CE is pipelining commands=20 (=3Dsending more than one command at a time, i.e., not waiting for each=20 response before sending the next command), then things become really=20 hairy ... Please send a concrete example to describe how you propose to operate. Regards, -Robert >So the CE would have to maintain two independent=20 >parallel sequences. This is unnecessary complexity to me. >[Weiming] I may miss something, but what I think of for this case is we = never have two sequences to maintain in one same CE or FE. We only have= one SN for one CE and one SN for one FE. Note that we don't need to main= tain a SN for any response messages then.=20 > >Thanks, >Weiming > >Regards, >-Robert > >Weiming Wang wrote: > > =20 > >>My opinion is: >> >>1. Function to correlate a request to a response is necessary. >> Seems no one objecting to this. >> >>2. PL message sequential numbering is also necessary >> One of the reason now I can think of is for packet redirect message= s. Note that we haven't make a reliability reqirement for packet redirect= ion, while the sequence of redirected packets are useful for these packet= s applications. >> >>3. It can fulfill the function 1) well by defining that a response mess= age should always have the same SN with the request to reply, hence we on= ly need one field that is called sequence number.=20 >> >>P.S.=20 >>1. Sequence number should be maintained per CE and FE separately, and t= he message type uniquely recognize a message as a response message, there= fore there will be no opaque in the Sequence number maintaince.=20 >>2. Sequence number of an event from FE is generated by the FE, while re= sponse of the event (if any) should have the same sequence number as the = event to response.=20 >>3. A response to batching messages to meet two-phase-commits will have = the same SN as that of the first message or the last message in the batch= , just as what we'd like to define. >> >>Thanks, >>Weiming >> >> >>=20 >> >> =20 >> > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From WendyLusk@adversecreditloans.co.uk Wed Jun 15 12:37:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01733; Wed, 15 Jun 2005 12:37:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DibG6-000318-W2; Wed, 15 Jun 2005 13:00:59 -0400 Received: from host86-131-225-16.range86-131.btcentralplus.com ([86.131.225.16]) by mx2.foretec.com with smtp (Exim 4.24) id 1DiatD-0006MZ-Aa; Wed, 15 Jun 2005 12:37:20 -0400 Received: from Q5uv@localhost by 8ceG.int (8.11.6/8.11.6); Wed, 15 Jun 2005 22:39:43 +0500 Message-ID: From: "Allison Diaz" Reply-To: "Allison Diaz" To: stun-owner@ietf.org Subject: Over 80% Savings on ALL best-selling XP titles Date: Wed, 15 Jun 2005 12:36:43 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WendyLusk@adversecreditloans.co.uk Content-Type: multipart/mixed; boundary="--fGEiBk7yrtFK4Bo" X-Spam-Score: 0.2 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 kaV ----fGEiBk7yrtFK4Bo Content-Type: text/html; Content-Transfer-Encoding: quoted-printable b
Opt-in Email Special Offer &n= bsp;   unsubscribe me<= a href=3Dhttp://trancesoft.net/?s>
<= td bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

<= td width=3D8>4= 79

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Wi= ndows XP Pro
 3 Adobe= Creative Suite Premium
  Norton Antivirus 2005
 5 Flash MX 2004
 6 = Corel Draw 12
  Adobe Acrobat 7.0
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Micro= soft
  = Apple Software<= /td>
  Customers also bought=
   these other items...
=



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
<= /a> 
List Price:<= /td>$899.00
Price:$69.99
You Save:$830.01 (92%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  <= a href=3Dhttp://trancesoft.net/?t>Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: June 30th, 2005
Aver= age Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft W= indows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Pr= ice:$279.00
Pric= e:$49.99
You Save:$229.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: ISe229
Media: CD-ROM / Download

System requirements=   |  Accessories  |&= nbsp; Other Versions

<= b>Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video,= DVDs, and more
  • More securit= y with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support <= /font>
  • Integration with Windows serv= ers and management solutions

Sal= es Rank: #2
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

=
Adobe Photoshop CS2 V 9.0
Adobe
=
Choose= :
&n= bsp;

<= /table>



Availability: Available for INSTAN= T download!
Coupon Code: ISe229
Media: CD-ROM / Down= load

System requirements  |  Accessories  |  Other Ve= rsions

Features:

  • Customized workspace; = save personalized workspace and tool settings; create customized shortcuts=
  • Unparalleled efficiency--a= utomate production tasks with built-in or customized scripts
    • =
  • Improved file management, new design poss= ibilities, and a more intuitive way to create for the Web
    • Support for 16-bit images, digital camera ra= w data, and non-square pixels
  • Create or modify photos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)
----fGEiBk7yrtFK4Bo-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 12:52:22 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02978 for ; Wed, 15 Jun 2005 12:52:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DibUR-0003yP-Sa for forces-archive@IETF.ORG; Wed, 15 Jun 2005 13:15:54 -0400 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.0107EB88@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 12:52:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75521511 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 12:52:08 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 12:52:06 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061509553117:22432 ; Wed, 15 Jun 2005 09:55:31 -0700 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/15/2005 09:55:31 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/15/2005 09:55:32 AM, Serialize complete at 06/15/2005 09:55:32 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118854319.10408.52.camel@localhost.localdomain> Date: Wed, 15 Jun 2005 12:51:59 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42AFEA66.2050901@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Wed, 2005-15-06 at 10:44 +0200, Robert Haas wrote: > Maybe I did not understand your point, so let's take a concrete example: [..] So heres an example where the second 16/32-bit number will be useful. This was actually well summarized by Joel's one paragraph[1], I am hoping this may actually help rather than cause confusion ;->. This is the closest i can get to the problem netlink is facing today. Take an implementation which does the following: On the CE, it has two connections between the PL and the TML (lets make no assumptions of whether there are is one or more processes/tasks). On the FE (assuming different vendor from the CE), the implementation has only one PL-TML connection. On the CE, something at PL sends a message via one of the two PL level connections to the CE - call it connection Y (and the other is connection Z). So TML grabs this message, sends it to the correct FE based on FEID. FE responds back. TML grabs response and now has to mux it to the correct PL connection. How does it do this? One answer is the TML maintains a lot of PL level knowledge. But this is clearly bad abstraction. Another answer is to tell the implementor "no you cant do that - thou shalt implement a single process". Thats a bad thing to say because it may limit the implementation only to some specific OSes or it may make for an inefficient implementation on some OSes. I could give a few more ways to implement this - none which are "clean". Our implementation at the moment works fine because we have a single process/task where all PL messages get muxed to and a single PL-TML connection. We can therefore live with the command corelator being the sequence number. Perhaps what we need to call the other number is process correlator or context? Maybe its all in the naming? cheers, jamal [1] "A Sequence number should have a different sequential value has I hand messages from the PL to the TML. A correlator should have distinct values for distinct requests, and replies should have the value from the request. These are not the same property. They may even be in conflict." From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 13:16:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04480 for ; Wed, 15 Jun 2005 13:16:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DibrO-0005JA-Of for forces-archive@IETF.ORG; Wed, 15 Jun 2005 13:39:38 -0400 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.0107ED2E@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 13:16:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75523424 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 13:15:40 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 13:15:39 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Thu, 16 Jun 2005 01:49:27 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: <002901c571ce$5fcc8dd0$020aa8c0@wwm1> Date: Thu, 16 Jun 2005 01:19:20 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpUaGFua3MgZm9yIGEgbW9yZSBkZXRhaWxlZCBleHBsYWluYXRpb24uDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUm9iZXJ0IEhhYXMiIDxyaGFAenVy aWNoLmlibS5jb20+DQoNCldlaW1pbmcsDQoNCk1heWJlIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHlv dXIgcG9pbnQsIHNvIGxldCdzIHRha2UgYSBjb25jcmV0ZSBleGFtcGxlOg0KDQotPiByZXF1ZXN0 IGZyb20gQ0UgdG8gRkUsIFNOIDUNCjwtIHJlc3BvbnNlIGZyb20gRkUgdG8gQ0UsIFNOIDUgKDUg aXMgaW1wb3NlZCBieSB0aGUgQ0UsIG5lY2Vzc2FyeSBmb3IgDQpjb3JyZWxhdGlvbiBhbmQvb3Ig c2VxdWVuY2luZyByZWFzb25zKQ0KLT4gcmVxdWVzdCBmcm9tIENFIHRvIEZFLCBTTiA2IChBQ0sg ZmxhZyBvZmYpDQpubyByZXNwb25zZSBmcm9tIEZFIHRvIENFDQotPiByZXF1ZXN0IGZyb20gQ0Ug dG8gRkUsIFNOIDcNCjwtIHJlc3BvbnNlIGZyb20gRkUgdG8gQ0UsIFNOIDcNCi4uLiBzbyB5b3Ug c2VlIGFib3ZlIHRoYXQgdGhlIENFIHdvdWxkIGhhdmUgdG8gZXhwZWN0IGhvbGVzIGluIHRoZSAN CnNlcXVlbmNlIG51bWJlcnMgY29taW5nIGJhY2sgZnJvbSB0aGUgRkUuDQpbV2VpbWluZ11JIGFn cmVlIHRoZXJlIGlzIGEgZGlmZmVyZW50IHVuZGVyc3RhbmRpbmcgdG8gc3VjaCBhIGNhc2UuIEkg ZG9uJ3QgdGhpbmsgdGhlIHJlc3BvbnNlIG1lc3NhZ2Ugd2lsbCAgcmVzdWx0IGluIGEgc2VxdWVu Y2UgbnVtYmVyIGhvbGUgZm9yIHRoZSBDRSwgYmVjYXVzZSBJIG9ubHkgZXhwZWN0IHRvIGRlZmlu ZSBhIHNlcXVlbmNlIG51bWJlciB0aGF0IGlzIHVzZWQgdG8gbWFyayB0aGUgb3JkZXIgb2YgbWVz c2FnZXMgdGhlIENFIG9yaWdpbmFsbHkgZ2VuZXJhdGVzICwgd2hpY2ggc2hvdWxkIGV4Y2x1ZGUg cmVzcG9uc2UgbWVzc2FnZXMuICBJbiBhbm90aGVyIHdvcmQsIHdlIHdpbGwgZGVmaW5lIHRoYXQg cmVzcG9uc2UgbWVzc2FnZXMgb25seSB0YWtlIGEgZmllbGQgdGhhdCBpcyBvbmx5IGZvciBjb3Jy ZWxhdGluZy4gWWVzLCBzdWNoIGEgZGVmaW5pdGlvbiBvZiBhIFNOIHdpbGwgYmUgcHJvYmxlbWF0 aWMgaWYgdGhlIFNOIGhhdmUgdG8gYmUgdXNlZCBieSBUTUwgZm9yIFRNTCBsZXZlbCBmbG93IGNv bnRyb2wsIGJ1dCBzdWNoIFNOIHVzYWdlIGhhcyBhbHJlYWR5IGJlZW4gZXhjbHVkZWQuICBXZSBv bmx5IGxlYXZlIFNOIGZvciBQTCBsZXZlbCB1c2UuIE15IHRob3VnaHQgaXMgc3VjaCBTTiBpcyB1 c2VmdWwgYW5kIGlzIGFsc28gZW5vdWdoLiANCg0KLi4uIGJ1dCBpbiBhZGRpdGlvbiwgdGhlcmUg aXMgYW5vdGhlciBwYXJhbGxlbCBzZXF1ZW5jZSB0aGF0IHRoZSBDRSBoYXMgDQp0byBkaXN0aW5n dWlzaDoNCi0+IHBhY2tldCByZWRpcmVjdCBtZXNzYWdlcyBhbmQvb3IgZXZlbnQgbm90aWZpY2F0 aW9ucyBhcmUgc2VudCBmcm9tIEZFIA0KdG8gQ0UsIFNOIDExLCAxMiwgMTMsIDE0IC4uLiAoZGVj aWRlZCBieSB0aGUgRkUpDQouLi4gdGhpcyBtZWFucyB0aGF0LCBpbiBhZGRpdGlvbiB0byB0aGUg YWRkZWQgY29tcGxleGl0eSBvZiBtYWludGFpbmluZyANCnR3byBwYXJhbGxlbCBzZXF1ZW5jZXMs IHlvdSBjYW5ub3QgZW5mb3JjZSBhbnkgb3JkZXJpbmcgYmV0d2VlbiB0aGUgDQpjb21tYW5kIHJl c3BvbnNlcyBhbmQgdGhlIHBhY2tldCByZWRpcmVjdGlvbi9ldmVudCBub3RpZmljYXRpb25zICg9 Ym90aCANCnNlcXVlbmNlcyBhcmUgaW5kZXBlbmRlbnQpLg0KW1dlaW1pbmddIE5vdGUgdGhhdCB3 ZSBhbHNvIGhhdmUgdG8gbWFpbnRhaW4gdHdvIGNvcnJlbGF0b3JzLCBvbmUgaXMgZm9yIENFIGFu ZCBhbm90aGVyIGlzIGZvciBGRSwgdGhlcmVmb3JlLCB0byBoYXZlIHR3byBTTiBwYXJhbGxlbGx5 IG1haW50YWluZWQgc2VlbXMgdW5hdm9pZGFibGUuICBNb3Jlb3ZlciwgaWYgd2Ugc2VwYXJhdGUg Y29ycmVsYXRvciBmcm9tIFNOLCB3ZSB0aGVuIG5lZWQgdG8gbWFpbnRhaW4gZm91ciBwYXJhbWV0 ZXJzIGZvciB0aGVtLiAgVG8gIG1lcmdlIGNvcnJlbGF0b3IgYW5kIFNOIHRvZ2V0aGVyIGlzIGFj dHVhbGx5IGEgdmVyeSBzaW1wbGUgdHJlYXRtZW50LCB0aGF0IGlzLCB0byBsZXQgYSBjb3JyZWxh dG9yIGJlIGdlbmVyYXRlZCBzZXF1ZW50aWFsbHkgcmF0aGVyIHRoYW4gcmFuZG9tbHksIHdpdGhv dXQgYWRkaW5nIGFueSBvdGhlciBjb21wbGV4aXR5LCB3aGVyZWFzIGJlbmlmaXRzIGZyb20gIGl0 IGlzIGdyZWF0OiB0byBlYXNlIHRoZSBnZW5lcmF0aW9uIG9mIGEgY29ycmVsYXRvciBpbiBzb21l IHdheSBhcyB3ZWxsIGFzIHByb3ZpZGluZyBhIHNlcXVlbnRpYWwgaW5mb3JtYXRpb24gZm9yIHNv cnRzIG9mIG1lc3NhZ2VzLCB3aGljaCBhcmUgdXNlZnVsIGluIHNvbWUgY2FzZXMuDQoNCk1vcmVv dmVyLCBjb25zaWRlciB0aGUgY2FzZSBmb3Igd2hpY2ggdGhlIENFIGlzIHBpcGVsaW5pbmcgY29t bWFuZHMgDQooPXNlbmRpbmcgbW9yZSB0aGFuIG9uZSBjb21tYW5kIGF0IGEgdGltZSwgaS5lLiwg bm90IHdhaXRpbmcgZm9yIGVhY2ggDQpyZXNwb25zZSBiZWZvcmUgc2VuZGluZyB0aGUgbmV4dCBj b21tYW5kKSwgdGhlbiB0aGluZ3MgYmVjb21lIHJlYWxseSANCmhhaXJ5IC4uLg0KW1dlaW1pbmdd IEFzIEkgbWVudGlvbmVkLCBpbiB0aGlzIGNhc2UsIHdlIHNob3VsZCBkZWZpbmUgdG8gbGV0IHRo ZSByZXNwb25zZSBTTiAoYXMgdGhlIGNvcnJlbGF0b3IpIGVpdGhlciB3aXRoIHRoZSBwaXBlbGlu ZWQgY29tbWFuZHMnIGZpcnN0IG1lc3NhZ2Ugb3IgbGFzdCBtZXNzYWdlLiBGb3IgaW5zdGFuY2Us IA0KMS4gQ0Ugc2VuZHMgYSBwaXBlbGluZSBtZXNzYWdlIHdpdGggU04gb2YgMjEsIDIyLCAyMywg MjQsIDI1LCB0aGVuIHdhaXQgZm9yIHRoZSBjb21taXRtZW50IHJlc3BvbnNlIGZvciB0aGUgZXhj dXRpb24uDQoyLiBGRSB0aGVuIG1heSBlaXRoZXIgcmVzcG9uc2UgYSBtZXNzYWdlIHdpdGggU049 MjEsIG9yIFNOPTI1LCBqdXN0IGFzIHdlJ2QgbGlrZSB0byBkZWZpbmUuIFBlcnNvbmFsbHkgSSB0 aGluayB0byBkZWZpbmUgdGhlIGxhc3QgU04gYXMgdGhlIGJhdGNoIHJlc3BvbnNlIG1heSBiZSBi ZXR0ZXIuDQoNClRoYW5rcywNCldlaW1pbmcNCg== From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 13:46:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08479 for ; Wed, 15 Jun 2005 13:46:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DicKW-0007Oz-T7 for forces-archive@IETF.ORG; Wed, 15 Jun 2005 14:09:37 -0400 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.0107EC9D@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 13:46:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75526315 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 13:46:04 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 13:46:03 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Thu, 16 Jun 2005 02:20:12 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> <1118854319.10408.52.camel@localhost.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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003701c571d2$ab34eb10$020aa8c0@wwm1> Date: Thu, 16 Jun 2005 01:50:07 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFk aSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gT24gV2VkLCAyMDA1LTE1LTA2IGF0IDEwOjQ0 ICswMjAwLCBSb2JlcnQgSGFhcyB3cm90ZToNCj4gDQo+ID4gTWF5YmUgSSBkaWQgbm90IHVuZGVy c3RhbmQgeW91ciBwb2ludCwgc28gbGV0J3MgdGFrZSBhIGNvbmNyZXRlIGV4YW1wbGU6DQo+IA0K PiBbLi5dDQo+IFNvIGhlcmVzIGFuIGV4YW1wbGUgd2hlcmUgdGhlIHNlY29uZCAxNi8zMi1iaXQg bnVtYmVyIHdpbGwgYmUgdXNlZnVsLg0KPiBUaGlzIHdhcyBhY3R1YWxseSB3ZWxsIHN1bW1hcml6 ZWQgYnkgSm9lbCdzIG9uZSBwYXJhZ3JhcGhbMV0sIEkgYW0NCj4gaG9waW5nIHRoaXMgbWF5IGFj dHVhbGx5IGhlbHAgcmF0aGVyIHRoYW4gY2F1c2UgY29uZnVzaW9uIDstPi4gVGhpcyBpcw0KPiB0 aGUgY2xvc2VzdCBpIGNhbiBnZXQgdG8gdGhlIHByb2JsZW0gbmV0bGluayBpcyBmYWNpbmcgdG9k YXkuDQo+IA0KPiBUYWtlIGFuIGltcGxlbWVudGF0aW9uIHdoaWNoIGRvZXMgdGhlIGZvbGxvd2lu ZzoNCj4gDQo+IE9uIHRoZSBDRSwgaXQgaGFzIHR3byBjb25uZWN0aW9ucyBiZXR3ZWVuIHRoZSBQ TCBhbmQgdGhlIFRNTA0KPiAobGV0cyBtYWtlIG5vIGFzc3VtcHRpb25zIG9mIHdoZXRoZXIgdGhl cmUgYXJlIGlzIG9uZSBvciBtb3JlDQo+IHByb2Nlc3Nlcy90YXNrcykuDQo+IE9uIHRoZSBGRSAo YXNzdW1pbmcgZGlmZmVyZW50IHZlbmRvciBmcm9tIHRoZSBDRSksIHRoZSBpbXBsZW1lbnRhdGlv bg0KPiBoYXMgb25seSBvbmUgUEwtVE1MIGNvbm5lY3Rpb24uDQo+IA0KPiBPbiB0aGUgQ0UsIHNv bWV0aGluZyBhdCBQTCBzZW5kcyBhIG1lc3NhZ2UgdmlhIG9uZSBvZiB0aGUgdHdvIFBMIGxldmVs DQo+IGNvbm5lY3Rpb25zIHRvIHRoZSBDRSAtIGNhbGwgaXQgY29ubmVjdGlvbiBZIChhbmQgdGhl IG90aGVyIGlzDQo+IGNvbm5lY3Rpb24gWikuDQo+IFNvIFRNTCBncmFicyB0aGlzIG1lc3NhZ2Us IHNlbmRzIGl0IHRvIHRoZSBjb3JyZWN0IEZFIGJhc2VkIG9uIEZFSUQuDQo+IEZFIHJlc3BvbmRz IGJhY2suIFRNTCBncmFicyByZXNwb25zZSBhbmQgbm93IGhhcyB0byBtdXggaXQgdG8gdGhlDQo+ IGNvcnJlY3QgUEwgY29ubmVjdGlvbi4gSG93IGRvZXMgaXQgZG8gdGhpcz8NCg0KRmlyc3RseSwg SSdtIG5vdCBzdXJlIGlmIHRoZSB0d28gUEwtVE1MIGNvbm5lY3Rpb25zIGFjdHVhbGx5IGltcGx5 LCBkbyB5b3UgaW1wbHkgdGhleSdsIGhhdmUgZGlmZmVyZW50IGFuZCBpbmRlcGVuZGFudCBTTiBv ciBjb3JyZWxhdG9yIGdlbmVyYXRvcj8gSSBzdXBwb3NlIGVpdGhlciBTTiBvciBjb3JyZWxhdG9y IHNob3VsZCBhbGwgYmUgY29uc2lzdGVudGx5IG1haW50YWluZWQgYnkgb25lIFBMIGNvcmUuDQoN ClNlY29uZGx5LCBJIGRvbid0IHNlZSBhbnkgZGlmZmljdWx0eSB0byBkZW11eCByZXNwb25zZXMg aW4gc3VjaCBjYXNlLiBJdCdzIGp1c3QgYnkgdGhlIFNOIGZpZWxkIHdoaWNoIGFjdHMgYXMgYSBj b3JyZWxhdG9yLCBjb25zaWRlcmluZyBjb3JyZWxhdG9ycyBnZW5lcmF0ZWQgYnkgdGhlIFBMIGNv cmUgYXJlIGFsd2F5cyBpbiB0aGlzIGNhc2UuIE1heWJlIEkgc3RpbGwgbWlzcyBzb21ldGhpbmc/ DQoNCj4gDQo+IE9uZSBhbnN3ZXIgaXMgdGhlIFRNTCBtYWludGFpbnMgYSBsb3Qgb2YgUEwgbGV2 ZWwga25vd2xlZGdlLiBCdXQgdGhpcyBpcw0KSSBhY3R1YWxseSB0aGluayBzdWNoIGRlbXV4IHNo b3VsZCBiZSBkb25lIGJ5IGEgdW5pcXVlIFBMIGNvcmUgcmF0aGVyIHRoYW4gYnkgVE1MKHMpLiAN Cg0KPiBjbGVhcmx5IGJhZCBhYnN0cmFjdGlvbi4gQW5vdGhlciBhbnN3ZXIgaXMgdG8gdGVsbCB0 aGUgaW1wbGVtZW50b3INCj4gIm5vIHlvdSBjYW50IGRvIHRoYXQgLSB0aG91IHNoYWx0IGltcGxl bWVudCBhIHNpbmdsZSBwcm9jZXNzIi4gVGhhdHMgYQ0KPiBiYWQgdGhpbmcgdG8gc2F5IGJlY2F1 c2UgaXQgbWF5IGxpbWl0IHRoZSBpbXBsZW1lbnRhdGlvbiBvbmx5IHRvIHNvbWUNCj4gc3BlY2lm aWMgT1NlcyBvciBpdCBtYXkgbWFrZSBmb3IgYW4gaW5lZmZpY2llbnQgaW1wbGVtZW50YXRpb24g b24gc29tZQ0KPiBPU2VzLiBJIGNvdWxkIGdpdmUgYSBmZXcgbW9yZSB3YXlzIHRvIGltcGxlbWVu dCB0aGlzIC0gbm9uZSB3aGljaCBhcmUNCj4gImNsZWFuIi4gDQo+IA0KPiBPdXIgaW1wbGVtZW50 YXRpb24gYXQgdGhlIG1vbWVudCB3b3JrcyBmaW5lIGJlY2F1c2Ugd2UgaGF2ZSBhIHNpbmdsZQ0K PiBwcm9jZXNzL3Rhc2sgd2hlcmUgYWxsIFBMIG1lc3NhZ2VzIGdldCBtdXhlZCB0byBhbmQgYSBz aW5nbGUgUEwtVE1MDQo+IGNvbm5lY3Rpb24uIA0KVGhlcmUgbWlnaHQgYmUgbXVsdGlwbGUgUEwt VE1MIHRocmVhZHMgY3JlYXRlZCwgYnV0IHRoZXNlIHRocmVhZHMgc2hvdWxkIGJlIGFsbCB1bmRl ciBjb250cm9sIG9mIG9ubHkgb25lIHByb2Nlc3MsIHRoYXQgaXMsIHRoZSBjb3JlIFBMIHByb2Nl c3MuIFRvIHRyeSB0byBwYXJhbGxlbGl6ZSB0aGUgY29yZSBwcm9jZXNzIG1heSBiZSB2ZXJ5IGRp ZmZpY3V0IGFuZCBtYXkgYWxzbyBiZSBwcm9ibGVtYXRpYy4gT2YgY291cnNlLCB0aGVyZSBtYXkg YmUgbXVsdGlwbGUgUEwgYXBwbGljYXRpb24gcHJvY2Vzc2VzIHRob3VnaC4gDQoNClRoYW5rcywN CldlaW1pbmcNCg0KPldlIGNhbiB0aGVyZWZvcmUgbGl2ZSB3aXRoIHRoZSBjb21tYW5kIGNvcmVs YXRvciBiZWluZyB0aGUNCj4gc2VxdWVuY2UgbnVtYmVyLiBQZXJoYXBzIHdoYXQgd2UgbmVlZCB0 byBjYWxsIHRoZSBvdGhlciBudW1iZXIgaXMNCj4gcHJvY2VzcyBjb3JyZWxhdG9yIG9yIGNvbnRl eHQ/IE1heWJlIGl0cyBhbGwgaW4gdGhlIG5hbWluZz8gDQo+IA0KPiBjaGVlcnMsDQo+IGphbWFs DQo+IA0KPiBbMV0gDQo+ICJBIFNlcXVlbmNlIG51bWJlciBzaG91bGQgaGF2ZSBhIGRpZmZlcmVu dCBzZXF1ZW50aWFsIHZhbHVlIGhhcyBJIGhhbmQgDQo+IG1lc3NhZ2VzIGZyb20gdGhlIFBMIHRv IHRoZSBUTUwuDQo+IEEgY29ycmVsYXRvciBzaG91bGQgaGF2ZSBkaXN0aW5jdCB2YWx1ZXMgZm9y IGRpc3RpbmN0IHJlcXVlc3RzLCBhbmQNCj4gcmVwbGllcyBzaG91bGQgaGF2ZSB0aGUgdmFsdWUg ZnJvbSB0aGUgcmVxdWVzdC4NCj4gVGhlc2UgYXJlIG5vdCB0aGUgc2FtZSBwcm9wZXJ0eS4gIFRo ZXkgbWF5IGV2ZW4gYmUgaW4gY29uZmxpY3QuIg== From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 14:42:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13563 for ; Wed, 15 Jun 2005 14:42:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidCv-0002N8-Lh for forces-archive@IETF.ORG; Wed, 15 Jun 2005 15:06:03 -0400 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.0107EDAD@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 14:42:18 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75530848 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 14:42:17 -0400 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 14:42:17 -0400 Received: from dialup-4.249.42.212.dial1.washington2.level3.net ([4.249.42.212] helo=JMHLap3.stevecrocker.com) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Dicpi-0002Vf-00; Wed, 15 Jun 2005 14:41:51 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> <1118854319.10408.52.camel@localhost.localdomain> <003701c571d2$ab34eb10$020aa8c0@wwm1> 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.20050615143805.02d87740@localhost> Date: Wed, 15 Jun 2005 14:41:44 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003701c571d2$ab34eb10$020aa8c0@wwm1> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Weiming, will it suffice for your purposes if there are two fields: 1) A sequence number. Filled in sequentially by the sender of the message. May be used by the receiver to detect gaps, misordering, etc. 2) A request-ID field. On request messages, filled in by the request originator with any value suited to the requestors implementation and usage (may be a pointer, a counter, etc.) On response messages, this will be filled in with the value from the request that is being responded to? I understand that you argue that a (1) may be used to fill the purpose of (2). Can you live with two fields? Yours, Joel PS: My personal opinion is that (1) could be covered by (2), but not the reverse. However, I can easily live with two fields. From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 15 14:56:16 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15193 for ; Wed, 15 Jun 2005 14:56:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DidQS-0003QL-0Z for forces-archive@IETF.ORG; Wed, 15 Jun 2005 15:19:48 -0400 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.0107EFC9@cherry.ease.lsoft.com>; Wed, 15 Jun 2005 14:56:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75531314 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Jun 2005 14:56:15 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 15 Jun 2005 14:56:15 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061511593961:22664 ; Wed, 15 Jun 2005 11:59:39 -0700 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> <1118854319.10408.52.camel@localhost.localdomain> <003701c571d2$ab34eb10$020aa8c0@wwm1> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/15/2005 11:59:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/15/2005 11:59:41 AM, Serialize complete at 06/15/2005 11:59:41 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118861771.10408.71.camel@localhost.localdomain> Date: Wed, 15 Jun 2005 14:56:11 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003701c571d2$ab34eb10$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Thu, 2005-16-06 at 01:50 +0800, Weiming Wang wrote: > Firstly, I'm not sure if the two PL-TML connections actually > imply, do you imply they'l have different and independant SN or > correlator generator? I suppose either SN or correlator should > all be consistently maintained by one PL core. > > Secondly, I don't see any difficulty to demux responses in such > case. It's just by the SN field which acts as a correlator, considering > correlators generated by the PL core are always in this case. Maybe I > still miss something? [..] > > Our implementation at the moment works fine because we have a single > > process/task where all PL messages get muxed to and a single PL-TML > > connection. > There might be multiple PL-TML threads created, but these threads > should be all under control of only one process, that is, the core > PL process. Yes, thats how we do it in our implementation today (i.e with one process)- what worries me is the enforcement of such implementation. Robert and I have come up with two different approaches on how to implement: i would say it is therefore insufficient to say there would be one "core PL" mux point since his approach is to implement one process per LFB. Unless, that is, we are willing to sign on it and say "you will only implement this way". If we are going to say that we should say it in the draft. Then i will be sure my FE will interop with Roberts CE. The reason is: We actually may have more than one app on the CE which _in my view_ may have totaly independent things they configure at the FE. And in my view, each such app should be able to use Forces as a transport and not need to coordinate any sequence numbers. If you call each app a context, then the correlator maps to the context. And in each context the whole range of sequence numbers (I am begining to think this is a bad name) is available. For our implementation, the only value such a context correlator would add is reduced state at the CE. For Roberts, it would i suppose complete his. cheers, jamal From MargaritaWhitman@bostangi.com Thu Jun 16 00:13:53 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14483; Thu, 16 Jun 2005 00:13:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dim83-0008Ap-Ep; Thu, 16 Jun 2005 00:37:31 -0400 Received: from [210.121.206.139] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DikqB-0006Zv-9t; Wed, 15 Jun 2005 23:14:52 -0400 Received: from efT@localhost by TQe.int (8.11.6/8.11.6); Thu, 16 Jun 2005 01:06:15 -0400 Message-ID: From: "Moses Fowler" Reply-To: "Moses Fowler" To: stun-owner@ietf.org Subject: Microsoft Special Deals Date: Thu, 16 Jun 2005 00:03:15 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MargaritaWhitman@bostangi.com Content-Type: multipart/mixed; boundary="--MMByb5dpfAh8U40JH" X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 BfcE ----MMByb5dpfAh8U40JH Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 1
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----MMByb5dpfAh8U40JH-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 05:29:21 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00533 for ; Thu, 16 Jun 2005 05:29:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dir3P-0006hf-OY for forces-archive@IETF.ORG; Thu, 16 Jun 2005 05:53:03 -0400 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.0107F90D@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 5:29:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75558318 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 05:28:54 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 05:28:50 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Thu, 16 Jun 2005 18:02:25 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Thu, 16 Jun 2005 17:25:59 +0800 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> <1118854319.10408.52.camel@localhost.localdomain> <003701c571d2$ab34eb10$020aa8c0@wwm1> <6.2.1.2.0.20050615143805.02d87740@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: <0b0d01c57255$6ef1e3a0$1152010a@Necom.hzic.edu.cn> Date: Thu, 16 Jun 2005 17:26:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: base64 Sm9lbCwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhh bHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpTdWJqZWN0OiBSZTogW2lzc3VlNTRdIGNv cnJlbGF0b3IgaW4gdGhlIFBMIG1lc3NhZ2UgaGVhZGVyDQoNCg0KPiBXZWltaW5nLCB3aWxsIGl0 IHN1ZmZpY2UgZm9yIHlvdXIgcHVycG9zZXMgaWYgdGhlcmUgYXJlIHR3byBmaWVsZHM6DQo+IA0K PiAxKSBBIHNlcXVlbmNlIG51bWJlci4gIEZpbGxlZCBpbiBzZXF1ZW50aWFsbHkgYnkgdGhlIHNl bmRlciBvZiB0aGUgDQo+IG1lc3NhZ2UuICBNYXkgYmUgdXNlZCBieSB0aGUgcmVjZWl2ZXIgdG8g ZGV0ZWN0IGdhcHMsIG1pc29yZGVyaW5nLCBldGMuDQo+IDIpIEEgcmVxdWVzdC1JRCBmaWVsZC4g IE9uIHJlcXVlc3QgbWVzc2FnZXMsIGZpbGxlZCBpbiBieSB0aGUgcmVxdWVzdCANCj4gb3JpZ2lu YXRvciB3aXRoIGFueSB2YWx1ZSBzdWl0ZWQgdG8gdGhlIHJlcXVlc3RvcnMgaW1wbGVtZW50YXRp b24gYW5kIHVzYWdlIA0KPiAobWF5IGJlIGEgcG9pbnRlciwgYSBjb3VudGVyLCBldGMuKSAgDQpb V2VpbWluZ10gRXZlbiBldmVudHVhbGx5IHdlIGRlY2lkZSB0byB1c2Ugc3VjaCByZXFldXN0LUlE IGZpZWxkLCBJIHN1Z2dlc3QgdGhlIHZhbHVlIGp1c3QgYmUgdmFsdWUgb2YgdGhlIHNlcXVlbmNl IG51bWJlciBpbiB0aGUgbWVzc2FnZSwgd2hpY2ggaXMgdGhlIHNpbXBsZXN0IHdheSB0byBnZW5l cmF0ZSB0aGUgdmFsdWUuDQoNCj5PbiByZXNwb25zZSBtZXNzYWdlcywgdGhpcyB3aWxsIGJlIA0K PiBmaWxsZWQgaW4gd2l0aCB0aGUgdmFsdWUgZnJvbSB0aGUgcmVxdWVzdCB0aGF0IGlzIGJlaW5n IHJlc3BvbmRlZCB0bz8NCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBhcmd1ZSB0aGF0IGEg KDEpIG1heSBiZSB1c2VkIHRvIGZpbGwgdGhlIHB1cnBvc2Ugb2YgDQo+ICgyKS4gIENhbiB5b3Ug bGl2ZSB3aXRoIHR3byBmaWVsZHM/DQpDb21wYXJlZCB3aXRoIG9ubHkgb25lIGNvcnJlbGF0b3Ig ZmllbGQsIHRoaXMgbW9yZSBmaXRzIG15IHRob3VnaHQsIHRob3VnaCBhcyBJIGFscmVheWQgYXJn dWVkLCBpdCBzZWVtcyBhIGxpdHRsZSB0byB3YXN0ZSBzb21ldGhpbmcuDQoNClllcywgaWYgeW91 IGFsbCB0aGluayB0aGlzIGlzICBhIGJldHRlciBzb2x1dGlvbiwgSSBjYW4gbGl2ZSB3aXRoIGl0 Lg0KDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBQUzogTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0 aGF0ICgxKSBjb3VsZCBiZSBjb3ZlcmVkIGJ5ICgyKSwgYnV0IG5vdCB0aGUgDQo+IHJldmVyc2Uu ICBIb3dldmVyLCBJIGNhbiBlYXNpbHkgbGl2ZSB3aXRoIHR3byBmaWVsZHMuDQoNCltXZWltaW5n XSBNeSB0aG91Z2h0IGlzIDIgY2FuIGJlIGNvdmVyZWQgYnkgMSwgYnV0IDEgY2FuIG9ubHkgcGFy dGlhbGx5IGNvdmVyIDIuIEJ1dCBJJ20gYWZyYWlkIHRoaXMgbWF5IG9ubHkgYmUgYSBkZXNjcmlw dGlvbiBkaWZmZXJlbmNlLiBXZSBtYXkgbWVhbiB0aGUgc2FtZSB0aGluZy4gOiApDQoNClRoYW5r cywNCldlaW1pbmcNCiANCg== From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 10:15:15 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24099 for ; Thu, 16 Jun 2005 10:15:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DivWC-0002K8-RF for forces-archive@IETF.ORG; Thu, 16 Jun 2005 10:39:01 -0400 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.0107FEE8@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 10:15:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75615150 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 10:15:13 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 10:15:12 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Thu, 16 Jun 2005 22:49:32 +0800 (CST) References: <1116786905.33.0.544707347688.issue32@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <002501c5727e$6112e080$020aa8c0@wwm1> Date: Thu, 16 Jun 2005 22:18:55 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkZvciB0aGlzIGlzc3VlLCB0aGVyZSBzZWVtcyBvbmx5IGEgbGVmdCBxdWVzdGlv biB0aGF0IGlmIHdlIGNhbiBhdm9pZCBlbmNhcHN1bGF0aW5nIHJlZGlyZWN0ZWQgcGFja2V0cyB3 aXRoIFBMIGhlYWRlci4gQXMgZmFyIGFzIEkgY2FuIGNhdGNoLCBJIHNlZSB0aGF0IEhvcm11emQs IEpvZWwsIGFuZCBJIGFyZSBtb3JlIHRlbmQgdG8gdXNpbmcgc3VjaCBlbmNhcHN1bGF0aW9uLCBh bmQgeW91IGFuZCBtYXliZSBSb2JlcnQgbW9yZSB0ZW5kIG5vdCB0byB1c2UuIENvdWxkIHlvdSBz aG93IG1vcmUgb24gdGhpcywgZXNwZWNpYWxseSB0aGUgc2NoZW1lIHlvdSB0cmllZCB0byB1c2Ug aW4geW91ciBpbXBsZW1lbnRhdGlvbi4gSSBob3BlIHdlIGNvdWxkIGNsb3NlIHRoaXMgYWxzbyBh c2FwLg0KDQp0aGFua3MsDQpXZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiQXZyaSBEb3JpYSIgPHRyYWNrZXItZm9yY2VzQG1pcDQub3JnPg0KU3ViamVjdDog W2lzc3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KDQogICAgICAgIFRob3VnaHQgMjogIFRoZXJlIG1p Z2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQogICAgICAgICAgICAgICAgICAg IHJlZGlyZWN0ZWQ6IGRpcmVjdGx5IGJ5IGEgZm9yd2FyZGluZyBwYXRoLCBlLmcuLCBieQ0KICAg ICAgICAgICAgICAgICAgICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAgSW4gc3VjaCBhIGNhc2Ug d2UgZG8gbm90DQogICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNt YXJ0bmVzcy4gIFByb2JhYmx5IGEgbGluaw0KICAgICAgICAgICAgICAgICAgICBsYXllciBvciBl dmVuIG5ldHdvcmsgbGV2ZWwgaGVhZGVyIGlzIGVub3VnaC4gIFRoZQ0KICAgICAgICAgICAgICAg ICAgICByZWNlaXZlciBkZW11eGVzIGl0IG9ubHkgYmFzZWQgb24gc29tZSBwcm90b2NvbCB0eXBl DQogICAgICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNw b3J0IGxheWVyLiAgVGhlDQogICAgICAgICAgICAgICAgICAgIHByb3MgZm9yIHRoaXMgYXBwcmFv Y2ggaXMgaXQgbWF5IHByb3ZpZGUgYSBmYXN0IGFuZA0KICAgICAgICAgICAgICAgICAgICBjb3N0 LWVmZmVjdGl2ZSBwYXRoIGZvciBwYWNrZXQgcmVkaXJlY3QuICBUaGUgY29ucw0KICAgICAgICAg ICAgICAgICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIHRoZSBG cA0KICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgcG9pbnQgZGVmaW5pdGlvbiBpbiBGb3JD RVMgZnJhbWV3b3JrLg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogRWRpdG9yaWFsDQpkcmFmdDog ZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCm1lc3NhZ2VzOiA0OQ0Kbm9zeTogYXZyaQ0KcHJp b3JpdHk6IE11c3QgZml4DQpzdGF0dXM6IE5vIGRpc2N1c3Npb24NCnRpdGxlOiBQYWNrZXQgUmVk aXJlY3QNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGb3JjZXMgaXNzdWUgdHJhY2tlciA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo8aHR0 cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 11:04:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29292 for ; Thu, 16 Jun 2005 11:04:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiwHu-0005VO-1m for forces-archive@IETF.ORG; Thu, 16 Jun 2005 11:28:18 -0400 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.0107FEB3@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 11:04:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75620553 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 11:04:30 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 11:04:30 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061608075461:23669 ; Thu, 16 Jun 2005 08:07:54 -0700 References: <1116786905.33.0.544707347688.issue32@mip4.org> <002501c5727e$6112e080$020aa8c0@wwm1> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 08:07:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 08:07:55 AM, Serialize complete at 06/16/2005 08:07:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118934264.10408.150.camel@localhost.localdomain> Date: Thu, 16 Jun 2005 11:04:23 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002501c5727e$6112e080$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit On Thu, 2005-16-06 at 22:18 +0800, Weiming Wang wrote: > Jamal, > > For this issue, there seems only a left question that > if we can avoid encapsulating redirected packets with > PL header. As far as I can catch, I see that Hormuzd, > Joel, and I are more tend to using such encapsulation, > and you and maybe Robert more tend not to use. Could > you show more on this, especially the scheme you tried > to use in your implementation. The note is more on how pervasive do we want Forces to be i.e not whether we disagree on gaving a forces redirect header. In a minimal for interoperability, so that Roberts CE and Weimings FE can talk nicely to each other, we MUST have the redirect header attached by the sender so the receiver can properly intepret. Header in this case would be the Forces redirect header. I dont think there is any disagreement on that specific issue. At least there was never any on my part; the other person talking about this was Furquan - who is unfortunately away. On the note #32, to clarify, lets me point out the possibilities of achieving this packet redirect between CE/FE in the real world: Possibility 1) If we can have the FE data path capable of attaching Forces header/meta data and redirecting to CE - then this would be the most effective and efficient way of doing things. Clearly you can achieve this via a s/ware based FE or writing some NP microcode to achieve this. Possibility 2) You cant redirect in the FE data path. In such a case the second option is you are at least able to redirect to some CPU s/ware in the FE which then wraps the Forces redirect header around such a packet and sends it to the CE. This scheme is less effective than #1 above mostly because most FEs out there have relatively slow CPUs that you need to use for a lot of other things. It still, however, meets the requirements for interoperability. Now if you cant do #1 and you cant do #3 you are dead. You cant use such hardware for a forces FE and still guarantee interop; but you MAY be able to still do it if you can do #3 below. Possibility 3) Your FE hardware is capable of doing redirects but not just able to add forces metadata to it. It may be able to add a VLAN tag or something simple like that. This is very very common; a lot of commodity ASICs and boxes can do this. In such a case if you are configuring the FE and the CE you will need to create a mapping between the Forces redirect header and whatever metadata that this legacy ASIC can do. Of course both the FE and the CE would be expected to understand such metadata translation. This is easy to do if you are creating both the CE and the FE. As a note: this doesnt exclude that your FE is capable of #2 above. Your FE could be capable of #2 but you opt not to do it for efficiency reasons (because you save CPU cycles by not sending to the CPU;->) I claim that most people (this claim is verified by Furquan I believe) will end up using #3. My concern as noted in the issue#32 is not to ignore #3 and enforce that either #1 or #2 be used regardless. Because this will make Forces less pervasive (trust me when i say that some people take what is written as scripture and you fail the RFP laugh test if you dont have it _righteously_ implemented in their definition); however, In the case of JoeBlows FE and Weimings CE (assuming JoeBlow didnt work closely with Weiming in building the NE) then either #1, or #2 MUST be implemented on both sides. To close this issue, I was hoping to see some discussion or mention of #3 in the draft so implementors understand it is a possibility (with the repurcasions duly noted). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 11:52:50 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04515 for ; Thu, 16 Jun 2005 11:52:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dix2g-0000Bb-HF for forces-archive@IETF.ORG; Thu, 16 Jun 2005 12:16:37 -0400 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.01080223@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 11:52:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75624671 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 11:52:50 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 11:52:50 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061608561387:23740 ; Thu, 16 Jun 2005 08:56:13 -0700 Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 08:56:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 08:56:15 AM, Serialize complete at 06/16/2005 08:56:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118937164.10408.154.camel@localhost.localdomain> Date: Thu, 16 Jun 2005 11:52:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: [issue22] Overview - Response Formatting Comments: cc: tracker-forces@mip4.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Can we work on closing issue #22? Knocking it off will allow us to resolve a few outstanding issues. Url is: http://www.mip4.org/issues/tracker/forces/issue22 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 12:33:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08645 for ; Thu, 16 Jun 2005 12:33:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DixgS-0002zO-KX for forces-archive@IETF.ORG; Thu, 16 Jun 2005 12:57:45 -0400 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.010801EA@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 12:33:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75628543 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 12:33:56 -0400 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 12:33:56 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j5GGXpa6176456 for ; Thu, 16 Jun 2005 16:33:51 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5GGXp1G086838 for ; Thu, 16 Jun 2005 18:33:51 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j5GGXpr3011568 for ; Thu, 16 Jun 2005 18:33:51 +0200 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 j5GGXo2i011559; Thu, 16 Jun 2005 18:33:50 +0200 Received: from [127.0.0.1] (dhcp71-89.zurich.ibm.com [9.4.71.89]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA96920; Thu, 16 Jun 2005 18:33:50 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E059E0079@orsmsx408> <6.2.1.2.0.20050612105712.02d43ee8@localhost> <007a01c570f3$ae0a6d90$020aa8c0@wwm1> <42AEF977.9090900@zurich.ibm.com> <001a01c57144$e4d6e2d0$020aa8c0@wwm1> <42AFEA66.2050901@zurich.ibm.com> <1118854319.10408.52.camel@localhost.localdomain> <003701c571d2$ab34eb10$020aa8c0@wwm1> <6.2.1.2.0.20050615143805.02d87740@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 j5GGXpa6176456 Approved-By: Robert Haas Message-ID: <42B1A9CC.8040603@zurich.ibm.com> Date: Thu, 16 Jun 2005 18:33:16 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue54] correlator in the PL message header Comments: To: "Joel M. Halpern" , Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050615143805.02d87740@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable The current practice seem to be for the Sequence Number (SN) in the=20 Messager Header of all Responses to be set to the same value as the SN=20 in the Message Header of the original message. Note that it is spelled=20 as a SHOULD in the draft for the Query Response and Event Notifs, and=20 not even mentioned at all for the Config Response, we need to correct=20 this ! Note that this behavior is expected at the FE AND at the CE (the CE may=20 generate Event Notification Responses). Hence what we called SN in the draft is actually used as a transaction=20 ID: it allows a response to be matched with the corresponding request,=20 and it is therefore impossible to ensure that all messages generated by=20 a sender to a receiver are numbered sequentially with this field unless=20 you exclude from the sequencing, for instance : - on the CE-to-FE direction: exclude Event Notif Responses - on the FE-to-CE direction: exclude Config and Query Responses (one=20 could choose to exclude instead the Packet Redir and Event Notification,=20 but then the Config and Query messages with ACK flag off on the CE-to-FE=20 direction must be excluded too otherwise they will create gaps on the=20 FE-to-CE direction) So, if the sequencing and transaction semantics are handled by the same=20 field (SN), then it can only apply to a subset of the messages.=20 Otherwise we have to introduce another field to handle proper sequencing=20 independently from the transaction ID, or we drop sequencing completely=20 and only keep the transaction semantics. What do you think ? Joel M. Halpern wrote: > Weiming, will it suffice for your purposes if there are two fields: > > 1) A sequence number. Filled in sequentially by the sender of the=20 > message. May be used by the receiver to detect gaps, misordering, etc. As mentioned above, this deviates from the current use of the sequence=20 number (=3Dtransaction ID). If the sequence number is now used for proper= =20 sequencing as you also seem to propose, then we have to introduce a=20 separate transaction ID. > 2) A request-ID field. On request messages, filled in by the request=20 > originator with any value suited to the requestors implementation and=20 > usage (may be a pointer, a counter, etc.) On response messages, this=20 > will be filled in with the value from the request that is being=20 > responded to? Agreed, this field remains opaque to the protocol; it is used like a=20 cookie. The only requirement is that the receiver (CE or FE) copies it=20 from requests into responses. I propose that this field is also 32 bits.=20 Note I dislike the term request-ID because it implies that each request=20 has a different ID. > > I understand that you argue that a (1) may be used to fill the purpose=20 > of (2). Can you live with two fields? > > Yours, > Joel > > PS: My personal opinion is that (1) could be covered by (2), but not=20 > the reverse. However, I can easily live with two fields. Note that I've shown above that you cannot cover (1) with (2), or only=20 for a chosen subset of the messages. Regards, -Robert --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 14:35:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23330 for ; Thu, 16 Jun 2005 14:35:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DizZp-0003dx-HW for forces-archive@IETF.ORG; Thu, 16 Jun 2005 14:58:59 -0400 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.01080441@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 14:34:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75637465 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 14:34:58 -0400 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 14:34:58 -0400 Received: from dialup-4.249.192.28.dial1.washington2.level3.net ([4.249.192.28] helo=JMHLap3.stevecrocker.com) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DizCa-00025H-00; Thu, 16 Jun 2005 14:34:57 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786905.33.0.544707347688.issue32@mip4.org> <002501c5727e$6112e080$020aa8c0@wwm1> <1118934264.10408.150.camel@localhost.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.20050616143122.02d937b8@localhost> Date: Thu, 16 Jun 2005 14:34:51 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1118934264.10408.150.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 I believe that the mandatory to implement standardized TML and PL must include suitable encapsulation of redirect packets and congestion control on their transfer. The Source and Sink LFBs seem the right tool for the job. Now, someone can define an additional TML which provides what looks like the right headers on the upper interface, but does not actually ad them to the packet on the wire. And an FE could implement such a TML in a fashion that did not ever try to create the headers. But if that FE wants to interoperate with standard CEs, it also needs to implement the mandatory-to-implement TML. Even if that requires that it use the slow path. (That is also what one ought to expect from any FE that claims to implement the RFCs.) Yours, Joel At 11:04 AM 6/16/2005, Jamal Hadi Salim wrote: >On Thu, 2005-16-06 at 22:18 +0800, Weiming Wang wrote: > > Jamal, > > > > For this issue, there seems only a left question that > > if we can avoid encapsulating redirected packets with > > PL header. As far as I can catch, I see that Hormuzd, > > Joel, and I are more tend to using such encapsulation, > > and you and maybe Robert more tend not to use. Could > > you show more on this, especially the scheme you tried > > to use in your implementation. > > >The note is more on how pervasive do we want Forces to be i.e not >whether we disagree on gaving a forces redirect header. >In a minimal for interoperability, so that Roberts CE and Weimings FE >can talk nicely to each other, we MUST have the redirect header attached >by the sender so the receiver can properly intepret. Header in this case >would be the Forces redirect header. I dont think there is any >disagreement on that specific issue. At least there was never any on my >part; the other person talking about this was Furquan - who is >unfortunately away. > >On the note #32, to clarify, lets me point out the possibilities of >achieving this packet redirect between CE/FE in the real world: > >Possibility 1) If we can have the FE data path capable of attaching >Forces header/meta data and redirecting to CE - then this would be the >most effective and efficient way of doing things. Clearly you can >achieve this via a s/ware based FE or writing some NP microcode >to achieve this. > >Possibility 2) You cant redirect in the FE data path. In such a case the >second option is you are at least able to redirect to some CPU s/ware in >the FE which then wraps the Forces redirect header around such a packet >and sends it to the CE. This scheme is less effective than #1 above >mostly because most FEs out there have relatively slow CPUs that you >need to use for a lot of other things. It still, however, meets the >requirements for interoperability. Now if you cant do #1 and you cant do >#3 you are dead. You cant use such hardware for a forces FE and still >guarantee interop; but you MAY be able to still do it if you can do #3 >below. > >Possibility 3) Your FE hardware is capable of doing redirects >but not just able to add forces metadata to it. It may be able to add a >VLAN tag or something simple like that. This is very very common; a lot >of commodity ASICs and boxes can do this. In such a case if you are >configuring the FE and the CE you will need to create a mapping between >the Forces redirect header and whatever metadata that this legacy ASIC >can do. Of course both the FE and the CE would be expected to understand >such metadata translation. This is easy to do if you are creating both >the CE and the FE. >As a note: this doesnt exclude that your FE is capable of #2 above. Your >FE could be capable of #2 but you opt not to do it for efficiency >reasons (because you save CPU cycles by not sending to the CPU;->) >I claim that most people (this claim is verified by Furquan I believe) >will end up using #3. > >My concern as noted in the issue#32 is not to ignore #3 and enforce that >either #1 or #2 be used regardless. Because this will make Forces less >pervasive (trust me when i say that some people take what is written as >scripture and you fail the RFP laugh test if you dont have it >_righteously_ implemented in their definition); however, In the case of >JoeBlows FE and Weimings CE (assuming JoeBlow didnt work closely with >Weiming in building the NE) then either #1, or #2 MUST be implemented on >both sides. > >To close this issue, I was hoping to see some discussion or mention of >#3 in the draft so implementors understand it is a possibility (with the >repurcasions duly noted). > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 16 14:59:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25496 for ; Thu, 16 Jun 2005 14:59:19 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DizxA-0005A3-Hq for forces-archive@IETF.ORG; Thu, 16 Jun 2005 15:23:07 -0400 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.010804A5@cherry.ease.lsoft.com>; Thu, 16 Jun 2005 14:59:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75638585 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Jun 2005 14:59:15 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 16 Jun 2005 14:59:15 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061612023636:24024 ; Thu, 16 Jun 2005 12:02:36 -0700 References: <1116786905.33.0.544707347688.issue32@mip4.org> <002501c5727e$6112e080$020aa8c0@wwm1> <1118934264.10408.150.camel@localhost.localdomain> <6.2.1.2.0.20050616143122.02d937b8@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 12:02:36 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/16/2005 12:02:40 PM, Serialize complete at 06/16/2005 12:02:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1118948346.10408.159.camel@localhost.localdomain> Date: Thu, 16 Jun 2005 14:59:06 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050616143122.02d937b8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Thu, 2005-16-06 at 14:34 -0400, Joel M. Halpern wrote: > I believe that the mandatory to implement standardized TML and PL must > include suitable encapsulation of redirect packets and congestion control > on their transfer. > The Source and Sink LFBs seem the right tool for the job. > > Now, someone can define an additional TML which provides what looks like > the right headers on the upper interface, but does not actually ad them to > the packet on the wire. And an FE could implement such a TML in a fashion > that did not ever try to create the headers. > But if that FE wants to interoperate with standard CEs, it also needs to > implement the mandatory-to-implement TML. Even if that requires that it > use the slow path. (That is also what one ought to expect from any FE that > claims to implement the RFCs.) > Is there any thing we can say about such a TML in the protocol draft or would that lead to confusion? cheers, jamal From ImogeneArrington@waler.net Thu Jun 16 23:03:01 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08363 for ; Thu, 16 Jun 2005 23:03:01 -0400 (EDT) Date: Thu, 16 Jun 2005 23:03:01 -0400 (EDT) From: ImogeneArrington@waler.net Message-Id: <200506170303.XAA08363@ietf.org> Received: from d150-178-141.home.cgocable.net ([24.150.178.141]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj7VM-0001e3-P9 for forces-archive@ietf.org; Thu, 16 Jun 2005 23:26:54 -0400 Received: from v[3 X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 17 09:40:40 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18197 for ; Fri, 17 Jun 2005 09:40:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjHSO-0005Ct-NV for forces-archive@IETF.ORG; Fri, 17 Jun 2005 10:04:35 -0400 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.01081B08@cherry.ease.lsoft.com>; Fri, 17 Jun 2005 9:40:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75744432 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 09:40:33 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 17 Jun 2005 09:40:33 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061706435666:25116 ; Fri, 17 Jun 2005 06:43:56 -0700 Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 06:43:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 06:43:58 AM, Serialize complete at 06/17/2005 06:43:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119015629.20115.3.camel@localhost.localdomain> Date: Fri, 17 Jun 2005 09:40:28 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: packet redirect as a core LFB To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Folks, Should we be thinking of moving the redirect part out of the protocol draft as well and making it a core LFB? It could definetely be refered as a core LFB and therefore creating speacial message types for it seems a little overzelous. It may also help speedup the closure of the protocol draft. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 17 11:43:03 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28293 for ; Fri, 17 Jun 2005 11:43:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjJMo-0005b0-Fj for forces-archive@IETF.ORG; Fri, 17 Jun 2005 12:07:00 -0400 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.01081EAE@cherry.ease.lsoft.com>; Fri, 17 Jun 2005 11:42:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75758352 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 11:42:53 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 17 Jun 2005 11:42:51 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sat, 18 Jun 2005 00:17:24 +0800 (CST) References: <1119015629.20115.3.camel@localhost.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 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <001b01c57353$c90624b0$020aa8c0@wwm1> Date: Fri, 17 Jun 2005 23:46:53 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: packet redirect as a core LFB To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: base64 SmFtYWwsDQoNCkknbSBhZnJhaWQgd2Ugc2hvdWxkIGF0IGxlYXN0IGhhdmUgc29tZSBmb3Jlc2Vl aW5nIG9uIGhvdyBhIGNvcmUgTEZCIHdpbGwgZGVhbCB3aXRoIHRoZSByZWRpcmVjdGlvbiB3aXRo b3V0IHVzaW5nIGEgc3BlY2lhbCBtZXNzYWdlIGJlZm9yZSB3ZSBkZWNpZGUgdG8gdGhyb3cgYXdh eSB0aGUgc3BlY2lhbCBtZXNzYWdlIHNjaGVtZS4gU2hhbGwgd2UgdXNlIHNvbWV0aGluZyBsaWtl IGEgcmVkaXJlY3QgZXZlbnQgbm90aWZpY2F0aW9uIHNlbnQgYnkgdGhlIGNvcmUgTEZCIG9yIGFu eSBvdGhlciBtZWFucyB0aGVuPyANCg0KY2hlZXJzLA0Kd2VpbWluZw0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUB6bnl4LmNvbT4N Cg0KPiBGb2xrcywNCj4gDQo+IFNob3VsZCB3ZSBiZSB0aGlua2luZyBvZiBtb3ZpbmcgdGhlIHJl ZGlyZWN0IHBhcnQgb3V0IG9mIHRoZSBwcm90b2NvbA0KPiBkcmFmdCBhcyB3ZWxsIGFuZCBtYWtp bmcgaXQgYSBjb3JlIExGQj8NCj4gDQo+IEl0IGNvdWxkIGRlZmluZXRlbHkgYmUgcmVmZXJlZCBh cyBhIGNvcmUgTEZCIGFuZCB0aGVyZWZvcmUgY3JlYXRpbmcNCj4gc3BlYWNpYWwgbWVzc2FnZSB0 eXBlcyBmb3IgaXQgc2VlbXMgYSBsaXR0bGUgb3ZlcnplbG91cy4gSXQgbWF5IGFsc28NCj4gaGVs cCBzcGVlZHVwIHRoZSBjbG9zdXJlIG9mIHRoZSBwcm90b2NvbCBkcmFmdC4NCj4gDQo+IGNoZWVy cywNCj4gamFtYWw= From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 17 11:58:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29819 for ; Fri, 17 Jun 2005 11:58:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjJbw-0006iN-48 for forces-archive@IETF.ORG; Fri, 17 Jun 2005 12:22:29 -0400 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.0108207D@cherry.ease.lsoft.com>; Fri, 17 Jun 2005 11:58:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75759116 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 11:58:30 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 17 Jun 2005 11:58:30 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061709015333:25266 ; Fri, 17 Jun 2005 09:01:53 -0700 References: <1119015629.20115.3.camel@localhost.localdomain> <001b01c57353$c90624b0$020aa8c0@wwm1> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 09:01:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 09:01:55 AM, Serialize complete at 06/17/2005 09:01:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119023907.6310.8.camel@localhost.localdomain> Date: Fri, 17 Jun 2005 11:58:27 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: packet redirect as a core LFB Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001b01c57353$c90624b0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Fri, 2005-17-06 at 23:46 +0800, Weiming Wang wrote: > Jamal, > > I'm afraid we should at least have some foreseeing > on how a core LFB will deal with the redirection > without using a special message before we decide > to throw away the special message scheme. > Shall we use something like a redirect event > notification sent by the core LFB or any other means then? > By core LFB i meant it being an important LFB that must be implemented. This is in addition to the FE protocol LFB and FE Object LFB. We actually started to implement the redirect - after the discussion on the list where it is clear that we need this to be %100 compliant. This is in addition to the hardware scheme we currently use(that i described in some email). We are finding that, it infact has LFB properties. Example: - configure from CE->FE on what to filter, whether to totally redirect or just send a copy/mirror, and what port to redirect it on. - From FE->CE it is an event when a packet arrives - which is also part of the LFB definition. - Also injecting packets from the CE->FE is looked at as configure in what we are doing right now. - Capability (part of LFB definition) sounds useful too to describe what a specific redirect LFB can do etc. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 17 15:26:22 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16010 for ; Fri, 17 Jun 2005 15:26:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjMqr-0004ev-2j for forces-archive@IETF.ORG; Fri, 17 Jun 2005 15:50:20 -0400 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.0108256B@cherry.ease.lsoft.com>; Fri, 17 Jun 2005 15:25:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75780034 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 15:25:53 -0400 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 17 Jun 2005 15:25:53 -0400 Received: from dialup-4.249.192.168.dial1.washington2.level3.net ([4.249.192.168] helo=JMHLap3.stevecrocker.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DjMTQ-0004ze-00 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 15:25:52 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1119015629.20115.3.camel@localhost.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.20050617152441.02d82430@localhost> Date: Fri, 17 Jun 2005 15:25:49 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: packet redirect as a core LFB To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1119015629.20115.3.camel@localhost.localdomain> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 We need to define an interoperable mechanism for forwarding packets between the FE and the CE (both directions). This is a protocol, not just an LFB. It seems to make more sense in the PL and TML, rather than in some LFB document somewhere. Yours, Joel At 09:40 AM 6/17/2005, Jamal Hadi Salim wrote: >Folks, > >Should we be thinking of moving the redirect part out of the protocol >draft as well and making it a core LFB? > >It could definetely be refered as a core LFB and therefore creating >speacial message types for it seems a little overzelous. It may also >help speedup the closure of the protocol draft. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 17 15:47:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17352 for ; Fri, 17 Jun 2005 15:47:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjNBb-0006Gn-O4 for forces-archive@IETF.ORG; Fri, 17 Jun 2005 16:11:34 -0400 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.01082854@cherry.ease.lsoft.com>; Fri, 17 Jun 2005 15:47:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 75781726 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Jun 2005 15:47:33 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 17 Jun 2005 15:47:33 -0400 Received: from [10.0.0.229] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005061712505488:25538 ; Fri, 17 Jun 2005 12:50:54 -0700 References: <1119015629.20115.3.camel@localhost.localdomain> <6.2.1.2.0.20050617152441.02d82430@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 12:50:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/17/2005 12:50:57 PM, Serialize complete at 06/17/2005 12:50:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119037648.6310.17.camel@localhost.localdomain> Date: Fri, 17 Jun 2005 15:47:28 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: packet redirect as a core LFB Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050617152441.02d82430@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Fri, 2005-17-06 at 15:25 -0400, Joel M. Halpern wrote: > We need to define an interoperable mechanism for forwarding packets between > the FE and the CE (both directions). agreed. > This is a protocol, not just an LFB. A redirector looks to me more like an LFB than it is a protocol. Certainly it is configured via PL protocol and even though is modelled as an LFB doesnt have to be running in the forwarding path. [It has attributes such as where to send to etc, throws events such as sending those packets to the CE and depending on capability it may not have some features etc]. One could in fact argue it is two LFBs, a classifier that selects a packet and another that slaps a header on it before shipping it. > It seems to make more sense in the PL and TML, > rather than in some LFB document somewhere. Which would be fine with me. Shouldnt matter where it goes cheers, jamal From KellyStreet@abbeystone.co.uk Fri Jun 17 22:35:18 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13318; Fri, 17 Jun 2005 22:35:18 -0400 (EDT) Received: from [222.235.89.108] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjTYE-0000LF-T6; Fri, 17 Jun 2005 22:59:21 -0400 Received: from bNT@localhost by bCt.int (8.11.6/8.11.6); Sat, 18 Jun 2005 01:40:40 -0200 Message-ID: From: "Fran Castro" Reply-To: "Fran Castro" To: stun-owner@ietf.org Cc: iips@ietf.org, forces-archive@ietf.org Subject: Systemworks Products available for Download Date: Sat, 18 Jun 2005 05:41:40 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: KellyStreet@abbeystone.co.uk Content-Type: multipart/mixed; boundary="--0dclCXuGt32FLcS" X-Spam-Score: 15.5 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 b8j ----0dclCXuGt32FLcS Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
=

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>

 = ON SALE NOW!

 1 Off= ice Pro 2003
 2 Windows = XP Pro
 3 Adobe Creativ= e Suite Premium
 4 Norto= n Antivirus 2005
 5 Fla= sh MX 2004
 = 6 Corel Dra= w 12
 7 Adobe Acrobat 7.= 0
 8 Windows 2003 Serve= r
 9 Alias Maya 6 Wavef= rt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   A= pple Software
 <= /td> Customers also bought
   these other= items...
=



Microsoft Office Professional E= dition *2003*
= Microsoft
<= table border=3D0>Choose:
<= a href=3Dhttp://ipoemed.com/?X> 
<= /tr>
List Price:$899.00
Price:$69.99
Y= ou Save:$830.01 (92%)


Availability: Available for INSTANT download= !
Coupon Code: ISe229
Media: CD-ROM / Download
<= /span>
System requ= irements  |  Accessories=   |  Other Versions

Features:

    Analyze and manage business information usin= g Access databases
  • Exchange = data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced = IRM technology
  • Easy-to-use w= izards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business= reports
Sales Rank: #1=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft

=
Choose:
 
List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
System requirements=   |  Accessories  |=   Other Versions

= Features:

  • Designed for businesses of all sizes
    • =
  • Manage digital pictures, music, video, D= VDs, and more
  • More security = with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows server= s and management solutions

Sales= Rank: #2
Shipping: International/US or via in= stant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
=
Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D44 width=3D190><= tr>		 List Price: $599.00
Price:$69.99
Yo= u Save:$529.01 (90%)


Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System requir= ements  |  Accessories&n= bsp; |  Other Versions

=

Features:

    <= li class=3Dsmall>Customized workspace; save personalized wo= rkspace and tool settings; create customized shortcuts
  • Unparalleled efficiency--automate production t= asks with built-in or customized scripts
  • Improved file management, new design possibilities, and a mor= e intuitive way to create for the Web
  • Support for 16-bit images, digital camera raw data, and non-squa= re pixels
  • Create or modify p= hotos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping= : International/US or via instant download
Date Coupon Expires:= June 30th, 2005
Average Customer Rev= iew: 3D"5 Based on 498 reviews. Wr= ite a review.

= ----0dclCXuGt32FLcS-- From VivianBraun@bounteous.com Sat Jun 18 16:41:25 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12063; Sat, 18 Jun 2005 16:41:25 -0400 (EDT) Received: from [218.149.167.17] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjkVT-0000CE-FJ; Sat, 18 Jun 2005 17:05:37 -0400 Received: from FBC@localhost by cZk.int (8.11.6/8.11.6); Sat, 18 Jun 2005 15:44:40 -0600 Message-ID: From: "Jennifer Salazar" Reply-To: "Jennifer Salazar" To: stun-owner@ietf.org, iips@ietf.org, forces-archive@ietf.org Subject: Macromedia Products available for Download Date: Sun, 19 Jun 2005 01:39:40 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VivianBraun@bounteous.com Content-Type: multipart/mixed; boundary="--5oR6wnuyXx7vHIWzt4O" X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 qKif ----5oR6wnuyXx7vHIWzt4O Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
=

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>

 = ON SALE NOW!

 1 Off= ice Pro 2003
 2 Windows = XP Pro
 3 Adobe Creativ= e Suite Premium
 4 Norto= n Antivirus 2005
 5 Fla= sh MX 2004
 = 6 Corel Dra= w 12
 7 Adobe Acrobat 7.= 0
 8 Windows 2003 Serve= r
 9 Alias Maya 6 Wavef= rt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   A= pple Software
 <= /td> Customers also bought
   these other= items...
=



Microsoft Office Professional E= dition *2003*
= Microsoft
<= table border=3D0>Choose:
<= a href=3Dhttp://ipoemed.com/?y> 
<= /tr>
List Price:$899.00
Price:$69.99
Y= ou Save:$830.01 (92%)


Availability: Available for INSTANT download= !
Coupon Code: ISe229
Media: CD-ROM / Download
<= /span>
System requ= irements  |  Accessories=   |  Other Versions

Features:

    Analyze and manage business information usin= g Access databases
  • Exchange = data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced = IRM technology
  • Easy-to-use w= izards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business= reports
Sales Rank: #1=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft

=
Choose:
 
List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
System requirements=   |  Accessories  |=   Other Versions

= Features:

  • Designed for businesses of all sizes
    • =
  • Manage digital pictures, music, video, D= VDs, and more
  • More security = with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows server= s and management solutions

Sales= Rank: #2
Shipping: International/US or via in= stant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
=
Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D44 width=3D190><= tr>		 List Price: $599.00
Price:$69.99
Yo= u Save:$529.01 (90%)


Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System requir= ements  |  Accessories&n= bsp; |  Other Versions

=

Features:

    <= li class=3Dsmall>Customized workspace; save personalized wo= rkspace and tool settings; create customized shortcuts
  • Unparalleled efficiency--automate production t= asks with built-in or customized scripts
  • Improved file management, new design possibilities, and a mor= e intuitive way to create for the Web
  • Support for 16-bit images, digital camera raw data, and non-squa= re pixels
  • Create or modify p= hotos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping= : International/US or via instant download
Date Coupon Expires:= June 30th, 2005
Average Customer Rev= iew: 3D"5 Based on 498 reviews. Wr= ite a review.

= ----5oR6wnuyXx7vHIWzt4O-- From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 19 23:45:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28351 for ; Sun, 19 Jun 2005 23:45:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkDby-0005Dd-Q8 for forces-archive@IETF.ORG; Mon, 20 Jun 2005 00:10:24 -0400 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.01085C29@cherry.ease.lsoft.com>; 19 Jun 2005 23:45:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76019652 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Jun 2005 23:45:33 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 19 Jun 2005 23:45:33 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 20 Jun 2005 12:20:29 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 20 Jun 2005 11:43:14 +0800 References: <1119015629.20115.3.camel@localhost.localdomain> <6.2.1.2.0.20050617152441.02d82430@localhost> <1119037648.6310.17.camel@localhost.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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <0b9f01c5754a$32f65000$1152010a@Necom.hzic.edu.cn> Date: Mon, 20 Jun 2005 11:43:19 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: packet redirect as a core LFB To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 4.0 (++++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: base64 SmFtYWwgYW5kIEpvZWwsDQoNCkl0IHNlZW1zIHRoYXQgd2UgYWdyZWUgd2VsbCB0aGF0IGEgcmVk aXJlY3RvciBpbiBGRSBpcyBhbiBMRkIuIE5vdyB0aGUgb25seSBxdWVzdGlvbiBpcyBpZiB3ZSBz aG91bGQgdXNlIGEgc3BlY2lmaWMgcmVkaXJlY3QgUEwgbWVzc2FnZSBvciBub3QuIEkgdW5kZXJz dGFuZCBKb2VsJ3MgJ3Byb3RvY29sJyB0aG91Z2h0IGFzIHVzaW5nIHN1Y2ggUEwgbWVzc2FnZSwg d2hpbGUgSmFtYWwncyAnZXZlbnQnIHRob3VnaHQgYXMgbm90IHVzaW5nIHN1Y2ggUEwgbWVzc2Fn ZSwgYW0gSSByaWdodD8NCg0KSXQgbGV0IG1lIGFncmVlZCB0aGUgJ2V2ZW50JyBzY2hlbWUgd2Fz IGEgZ29vZCBzb2x1dGlvbiBmb3Igc2V2ZXJhbCBkYXlzLCBiZWZvcmUgSSBub3RpY2VkIGEgYmln IHByb2JsZW0gd2l0aCBpdC4gVGhlIHByb2JsZW0gaXMsIGhvdyB0aGVuIHdlIHJlY29nbml6ZSB0 aGUgcmVkaXJlY3QgZGF0YSBmcm9tIGdlbmVyYWwgY29udHJvbCBkYXRhIGF0IHRoZSBUTUwgbGV2 ZWwgaWYgd2UgdXNlIGEgJ2V2ZW50JyB0byBzZW5kIHJlZGlyZWN0IGRhdGEgZnJvbSBGRSB0byBD RT8gQXMgeW91IGtub3csIHRvIHJlY29nbml6ZSBpdCBpcyBpbXBvcnRhbnQgZm9yIFRNTCB0byBh dm9pZCBEb1MgYXR0YWNrIGZyb20gdGhlIHJlZGlyZWN0IGRhdGEuIA0KDQpUaGFua3MsDQpXZWlt aW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFtYWwgSGFkaSBT YWxpbSIgPGhhZGlAem55eC5jb20+DQoNCj4gT24gRnJpLCAyMDA1LTE3LTA2IGF0IDE1OjI1IC0w NDAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gV2UgbmVlZCB0byBkZWZpbmUgYW4gaW50 ZXJvcGVyYWJsZSBtZWNoYW5pc20gZm9yIGZvcndhcmRpbmcgcGFja2V0cyBiZXR3ZWVuIA0KPiA+ IHRoZSBGRSBhbmQgdGhlIENFIChib3RoIGRpcmVjdGlvbnMpLiAgIA0KPiANCj4gYWdyZWVkLg0K PiANCj4gPiBUaGlzIGlzIGEgcHJvdG9jb2wsIG5vdCBqdXN0IGFuIExGQi4gIA0KPiANCj4gQSBy ZWRpcmVjdG9yIGxvb2tzIHRvIG1lIG1vcmUgbGlrZSBhbiBMRkIgdGhhbiBpdCBpcyBhIHByb3Rv Y29sLg0KPiBDZXJ0YWlubHkgaXQgaXMgY29uZmlndXJlZCB2aWEgUEwgcHJvdG9jb2wgYW5kIGV2 ZW4gdGhvdWdoIGlzIG1vZGVsbGVkDQo+IGFzIGFuIExGQiBkb2VzbnQgaGF2ZSB0byBiZSBydW5u aW5nIGluIHRoZSBmb3J3YXJkaW5nIHBhdGguDQo+IFtJdCBoYXMgYXR0cmlidXRlcyBzdWNoIGFz IHdoZXJlIHRvIHNlbmQgdG8gZXRjLCB0aHJvd3MgZXZlbnRzIHN1Y2ggYXMNCj4gc2VuZGluZyB0 aG9zZSBwYWNrZXRzIHRvIHRoZSBDRSBhbmQgZGVwZW5kaW5nIG9uIGNhcGFiaWxpdHkgaXQgbWF5 IG5vdA0KPiBoYXZlIHNvbWUgZmVhdHVyZXMgZXRjXS4NCj4gT25lIGNvdWxkIGluIGZhY3QgYXJn dWUgaXQgaXMgdHdvIExGQnMsIGEgY2xhc3NpZmllciB0aGF0IHNlbGVjdHMgYQ0KPiBwYWNrZXQg YW5kIGFub3RoZXIgdGhhdCBzbGFwcyBhIGhlYWRlciBvbiBpdCBiZWZvcmUgc2hpcHBpbmcgaXQu DQo+ICANCj4gPiBJdCBzZWVtcyB0byBtYWtlIG1vcmUgc2Vuc2UgaW4gdGhlIFBMIGFuZCBUTUws IA0KPiA+IHJhdGhlciB0aGFuIGluIHNvbWUgTEZCIGRvY3VtZW50IHNvbWV3aGVyZS4NCj4gDQo+ IFdoaWNoIHdvdWxkIGJlIGZpbmUgd2l0aCBtZS4gU2hvdWxkbnQgbWF0dGVyIHdoZXJlIGl0IGdv ZXMNCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCg== From MitchellHensley@amso.co.uk Tue Jun 21 10:52:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27037; Tue, 21 Jun 2005 10:52:00 -0400 (EDT) Date: Tue, 21 Jun 2005 10:52:00 -0400 (EDT) From: MitchellHensley@amso.co.uk Message-Id: <200506211452.KAA27037@ietf.org> Received: from [222.116.56.233] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkkUV-0007NY-0l; Tue, 21 Jun 2005 11:16:47 -0400 Received: from h[3 X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 21 11:19:28 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29647 for ; Tue, 21 Jun 2005 11:19:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkkv0-0008F7-Aw for forces-archive@IETF.ORG; Tue, 21 Jun 2005 11:44:15 -0400 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.01087AE5@cherry.ease.lsoft.com>; Tue, 21 Jun 2005 11:19:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76258995 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 11:19:07 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 21 Jun 2005 11:19:07 -0400 Received: from dialup-4.248.250.137.dial1.washington2.level3.net ([4.248.250.137] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DkkWo-0006Jp-00 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 11:19:07 -0400 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.20050621110620.02c864d0@localhost> Date: Tue, 21 Jun 2005 11:18:58 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Properties component selection (model and protocol) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d I have had several discussions (mostly with Jamal) about the details of the properties approach that was discussed on the list earlier. I am going to add this to the model. Please shout on the list if any of what follows seems a bad idea. One pair of issues affects the protocol more than the model. You may recall an earlier email that discussed the issue of using a flag in the path to indiciate taht one wanted property information instead of content information. This introduced some odd ambiguities and confusion. So instead it appears to make more sense to introduce two new protocol operations, GET-PROPERTIES, and SET-PROPERTIES These will take paths and data as content just as GET and SET do. And remove the ambiguity about the path reference flag. Unfortunately, I then found a further complication. Some properties are only a single value (in a structure, for inheritance). However, some have more fields than that. Array properties have several fields. Alias properties have several fields, some writeable. So this raises the issue of access to elements of the property structure. We could declare for a read that one just gets the whole structure. But we want to be able to write certain property information. Aside: We could decide to give up on using properties for aliases, and that would remove all current writeable properties. But it is reasonable to expect them to return. In fact, I want to use them again for events. So we need writeable properties. For writing, it is clearly necessary to be able to indicate which field or fields within the property information one is trying to write. So we need another path flag. This flag is valid only within a GET-PROPERTY or SET-PROPERTY. And is not valid on path information nested within a path that has used this flag. The flag indicates that this path, and all nested paths within it are to be applied to the property information, not to the base path for selecting property information. (I currently can not imagine needing such nesting, but prohibiting it seems wrong) While this flag does have some special cases, they are at least clear. And this allows for selecting components of proprty information. From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 21 11:27:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00144 for ; Tue, 21 Jun 2005 11:27:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkl2Y-0008PO-6k for forces-archive@IETF.ORG; Tue, 21 Jun 2005 11:51:54 -0400 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.01087C43@cherry.ease.lsoft.com>; Tue, 21 Jun 2005 11:27:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76259462 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 11:27:07 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 21 Jun 2005 11:27:07 -0400 Received: from dialup-4.248.250.137.dial1.washington2.level3.net ([4.248.250.137] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DkkeW-0002Rg-00 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 11:27:05 -0400 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.20050621111901.02dabda0@localhost> Date: Tue, 21 Jun 2005 11:26:59 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Event subscription -- properties (model and protocol) To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a In the last event description I sent to the list, I proposed that event information would have two IDs, one for identifying the event, and one for indicating subscription to the event. The properties information seems to create an opportunity to simplify this. And to address some of the issue of aggregate registration. Instead of declaring another ID, the subscription state of an event will be part of its properties. Thus, the properties returned for a GET-PROPERTIES operation on an event path will include the event accessibility (unsupported, supported) and the subscription state. Given that we may want to extend the subscription semantics, we will use an integer variable, with 0 meaning not subscribed, and 1 meaning subscribed. This then gives an easy way to subscribe or unsubscribe to all events from the LFB, and to all instances of a given event on a table. Remember that the event path will be event-base.event-id.subscripts (possibly with more than one subscript). The subscripts indicate which table entry the event refers to. Thus a subscriber or unsubscribe is a SET-PROPERTIES with a path. If the path is just the event-base, one has changed the subscription to all events for the LFB. If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in terms of a table, one has subscriber or unsubscribed to the entire table. This does not allow for subscriber or unsubscribing in one reference to either all events on a given table cell, or to all events on a given table. Given that presumably there are a modest number of events, it seems a good trade to aggregate the table, while requiring explicit reference to each event. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 21 11:46:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02468 for ; Tue, 21 Jun 2005 11:46:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DklKq-0000eo-RB for forces-archive@IETF.ORG; Tue, 21 Jun 2005 12:10:53 -0400 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.01087C62@cherry.ease.lsoft.com>; Tue, 21 Jun 2005 11:46:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76261370 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 11:46:01 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 21 Jun 2005 11:46:01 -0400 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 j5LFk02w027643; Tue, 21 Jun 2005 15:46:00 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 j5LFjvto020957; Tue, 21 Jun 2005 15:46:00 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 M2005062108455702294 ; Tue, 21 Jun 2005 08:45:57 -0700 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, 21 Jun 2005 08:45:54 -0700 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 subscription -- properties (model and protocol) Thread-Index: AcV2dbw1JUFY6yOXQCmj2DtscegGuAAAlN8A X-OriginalArrivalTime: 21 Jun 2005 15:45:54.0645 (UTC) FILETIME=[4F2D5050:01C57678] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Putzolu, David" Message-ID: Date: Tue, 21 Jun 2005 08:45:50 -0700 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Re: Event subscription -- properties (model and protocol) 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 Hi Joel. I don't understand the following two sentences excerpted from=20 your email - they seem to contradict each other to me. Can you=20 elaborate a bit?=20 "If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in terms of a table, one has subscriber or=20 unsubscribed to the entire table." vs.=20 "This does not allow for subscriber or unsubscribing in one reference to either all events on a given table cell, or to all events on a given=20 table. " The first sentence seems to say for a table, subscribing "higher" in the path subscribes to the whole thing. The second seems to say one cannot subscribe to the whole thing? -David -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, June 21, 2005 8:27 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Event subscription -- properties (model and protocol) In the last event description I sent to the list, I proposed that event=20 information would have two IDs, one for identifying the event, and one for=20 indicating subscription to the event. The properties information seems to create an opportunity to simplify=20 this. And to address some of the issue of aggregate registration. Instead of declaring another ID, the subscription state of an event will be=20 part of its properties. Thus, the properties returned for a GET-PROPERTIES=20 operation on an event path will include the event accessibility=20 (unsupported, supported) and the subscription state. Given that we may=20 want to extend the subscription semantics, we will use an integer variable,=20 with 0 meaning not subscribed, and 1 meaning subscribed. This then gives an easy way to subscribe or unsubscribe to all events from=20 the LFB, and to all instances of a given event on a table. Remember that the event path will be event-base.event-id.subscripts=20 (possibly with more than one subscript). The subscripts indicate which=20 table entry the event refers to. Thus a subscriber or unsubscribe is a=20 SET-PROPERTIES with a path. If the path is just the event-base, one has changed the subscription to all events for the LFB. If the subscribe or unsubscribe is the event-base and the event-id, but the event is defined in=20 terms of a table, one has subscriber or unsubscribed to the entire table. This does not allow for subscriber or unsubscribing in one reference to=20 either all events on a given table cell, or to all events on a given=20 table. Given that presumably there are a modest number of events, it seems=20 a good trade to aggregate the table, while requiring explicit reference to=20 each event. Yours, Joel M. Halpern From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 21 12:03:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03588 for ; Tue, 21 Jun 2005 12:03:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DklcC-00014e-Bw for forces-archive@IETF.ORG; Tue, 21 Jun 2005 12:28:45 -0400 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.01087BFB@cherry.ease.lsoft.com>; Tue, 21 Jun 2005 12:03:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76263103 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 12:03:56 -0400 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 21 Jun 2005 12:03:56 -0400 Received: from dialup-4.248.250.137.dial1.washington2.level3.net ([4.248.250.137] helo=JMHLap3.stevecrocker.com) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DklE6-0004Kq-00 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 12:03:50 -0400 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.20050621115815.02dab048@localhost> Date: Tue, 21 Jun 2005 12:03:40 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Sorry I was unclear. let me try an example. Suppose that we have an LFB. Suppose that it has a table X. The contents of X are a structure with several fields, A, B, and C. The event definitions define the path prefix 7 as meaning events. Event ID 1 is defined as any change on field A of an entry in table X (hence the specific path is 7.1.subscript) event ID 2 is defined as any change on field B of an entry in table X (hence the specific path is 7.2.subscript). To subscribe to changes in the A field of the third table entry, one sets the subscribe field of the properties of path 7.1.3. To subscribe to changes in the A field of any entry in table X, one sets the subscribe field of the properties of path 7.1 To subscribe to any events from the LFB, one sets the subscribe field of the path 7. However, there is no path to subscribe to all the events on cell 3 of table X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on table X (7.1 and 7.2) This is actually driven by simplicity, but makes sense to me because 7.1 and 7.2 are easily known by the CE, while subscribing to every entry in the table individually, particularly when new entries are created, is harder. Yours, Joel At 11:45 AM 6/21/2005, Putzolu, David wrote: >Hi Joel. > >I don't understand the following two sentences excerpted from >your email - they seem to contradict each other to me. Can you >elaborate a bit? > >"If the subscribe or unsubscribe is the event-base and the event-id, but > >the event is defined in terms of a table, one has subscriber or >unsubscribed to the entire table." > >vs. > >"This does not allow for subscriber or unsubscribing in one reference to > >either all events on a given table cell, or to all events on a given >table. " > >The first sentence seems to say for a table, subscribing "higher" in the >path subscribes to the whole thing. The second seems to say one cannot >subscribe to the whole thing? > >-David From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 21 16:22:51 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05635 for ; Tue, 21 Jun 2005 16:22:51 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkpej-0002l8-Ji for forces-archive@IETF.ORG; Tue, 21 Jun 2005 16:47:38 -0400 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.010880EC@cherry.ease.lsoft.com>; Tue, 21 Jun 2005 16:22:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76289732 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 16:22:48 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 21 Jun 2005 16:22:35 -0400 Received: from dialup-4.249.229.152.dial1.washington2.level3.net ([4.249.229.152] helo=JMHLap3.stevecrocker.com) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DkpGU-0001CD-00 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Jun 2005 16:22:34 -0400 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.20050621161511.02c870f0@localhost> Date: Tue, 21 Jun 2005 16:22:29 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Event Target Identificiation To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 In the declaration of events, the XML has to include identification of what field is being tested for the event, and what information is to be reported. There are a number of minor issues. 1) We are not currently allowing for "and" conditions (report this event when the link has more than 3 errors per second and the usage is more than 1 megabit per second.) 2) The current proposal for naming the target and reporting fields is that each one will be a test string of the form fieldname1.fieldname2.fieldname3... where each fieldname is a valid field name in the containing context (initially, the LFB), and where if the containing context is an array then the fieldname is either a number (rare) or $digit to indicate that the event applies to all array elements. The $digit can then be used in similar strings in the reporting information. This will result in: element,arrayfield.$1.structelement (we could use local-name instead of $1, since the context implies a subscript.) We could instead get much more verbose, using more XML elements: element arrayfield local-name structelement and similar constructs for each report component. The later is more correct XML. I had originally proposed the former. Someone express a preference. Please. Joel From PasqualeCaudill@10d.co.uk Tue Jun 21 18:37:22 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21071; Tue, 21 Jun 2005 18:37:22 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkrku-0000oc-6p; Tue, 21 Jun 2005 19:02:14 -0400 Received: from [61.52.2.74] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DkrMn-0000uq-0D; Tue, 21 Jun 2005 18:37:15 -0400 Received: from DWdZ@localhost by hNd.int (8.11.6/8.11.6); Wed, 22 Jun 2005 01:24:36 +0200 Message-ID: From: "August Schlesinger" Reply-To: "August Schlesinger" To: stun-owner@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Win XP Date: Wed, 22 Jun 2005 00:25:36 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: PasqualeCaudill@10d.co.uk Content-Type: multipart/mixed; boundary="--js6ocflhm4JV2yIBX2H" X-Spam-Score: 4.8 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Mtw ----js6ocflhm4JV2yIBX2H Content-Type: text/html; Content-Transfer-Encoding: quoted-printable a
Opt-in Email Special Offer &n= bsp;   unsubscribe me<= a href=3Dhttp://save2drive.com/?D>
=
<= td bgcolor=3D#000080>
SEARCH

TOP 10 NEW TITLES

<= td width=3D8>4= 79

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Wi= ndows XP Pro
 3 Adobe= Creative Suite Premium
  Norton Antivirus 2005
 5 Flash MX 2004
 6 = Corel Draw 12
  Adobe Acrobat 7.0
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Micro= soft
  = Apple Software<= /td>
  Customers also bought=
   these other items...
=



Microsoft Office Professional Edition *2003*
Microsoft
Choose:
<= /a> 
List Price:<= /td>$899.00
Price:$69.99
You Save:$830.01 (92%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> ISe229
Media: CD-ROM / Download

System requirements  = |  Accessories  |  <= a href=3Dhttp://save2drive.com/?v>Other Versions

Features:

  • Analyze and manage business information using Access data= bases
  • Exchange data with oth= er systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technolog= y
  • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date= Coupon Expires: June 30th, 2005
Aver= age Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft W= indows XP Professional or Longhorn Edition
Microsoft
Choose:
 

=
List Pr= ice:$279.00
Pric= e:$49.99
You Save:$229.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: ISe229
Media: CD-ROM / Download

System requirements=   |  Accessories  |&= nbsp; Other Versions

<= b>Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video,= DVDs, and more
  • More securit= y with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support <= /font>
  • Integration with Windows serv= ers and management solutions

Sal= es Rank: #2
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

=
Adobe Photoshop CS2 V 9.0
Adobe
=
Choose= :
&n= bsp;

<= /table>



Availability: Available for INSTAN= T download!
Coupon Code: ISe229
Media: CD-ROM / Down= load

System requirements  |  Accessories  |  Other Ve= rsions

Features:

  • Customized workspace; = save personalized workspace and tool settings; create customized shortcuts=
  • Unparalleled efficiency--a= utomate production tasks with built-in or customized scripts
    • =
  • Improved file management, new design poss= ibilities, and a more intuitive way to create for the Web
    • Support for 16-bit images, digital camera ra= w data, and non-square pixels
  • Create or modify photos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping: International/US or via instant download
= Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)
----js6ocflhm4JV2yIBX2H-- From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 23 03:18:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlLz2-0002Pc-Da for forces-archive@megatron.ietf.org; Thu, 23 Jun 2005 03:18:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11201 for ; Thu, 23 Jun 2005 03:18:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlMNF-0003re-R6 for forces-archive@IETF.ORG; Thu, 23 Jun 2005 03:43:50 -0400 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.0108ADF5@cherry.ease.lsoft.com>; Thu, 23 Jun 2005 3:18:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76469577 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 Jun 2005 03:17:51 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 23 Jun 2005 03:17:51 -0400 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 j5N7Hi7p030087; Thu, 23 Jun 2005 07:17: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 j5N7HYUu023559; Thu, 23 Jun 2005 07:17:44 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005062300174405515 ; Thu, 23 Jun 2005 00:17:44 -0700 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, 23 Jun 2005 00:17:43 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcVvZJIBsRtx7Lp8TpWDsueAroIJ2QAH06vwAYleeDAAhoS7kA== X-OriginalArrivalTime: 23 Jun 2005 07:17:43.0912 (UTC) FILETIME=[A61C2E80:01C577C3] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> Date: Thu, 23 Jun 2005 00:17:42 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: Susan Hares To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Thanks for the input, Sue. I believe we have decided to leave the SN as is and add a Correlator as well to the header. So that should address any such requirements. Hormuzd -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com]=20 Sent: Tuesday, June 21, 2005 9:55 AM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] [issue54] correlator in the PL message header Hormuzd & All: Just in case this doesn't get covered, sequence number can have other benefits besides reliable transport. =20 The ordering of information at the application layer can enable some parallelization of functions for the control plane=20 Sue -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Khosravi, Hormuzd M Sent: Sunday, June 12, 2005 3:23 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header Jamal, Do you see a good reason to keep a SN? I don't see one since the TML provides reliability. If there is another reason, let us know...otherwise we should get rid of the SN. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Sunday, June 12, 2005 8:37 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote: > But we can not simply treat the sequence number as the correlator. >=20 Agreed. In the some cases we could - but i think allowing for such polymorphic behavior is something we may live to regret (it has been trickery-hell in netlink to ensure backward compatibility because the seq # is used as a correlator as well) so lets just add a second 32 bit number in the main header.=20 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 23 03:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlM6H-0003Ot-3p for forces-archive@megatron.ietf.org; Thu, 23 Jun 2005 03:26:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11582 for ; Thu, 23 Jun 2005 03:26:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlMUY-0004Dv-Jh for forces-archive@IETF.ORG; Thu, 23 Jun 2005 03:51:19 -0400 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.0108AF00@cherry.ease.lsoft.com>; Thu, 23 Jun 2005 3:26:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76469799 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 Jun 2005 03:26:09 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 23 Jun 2005 03:26:09 -0400 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 j5N7Q8oR015197; Thu, 23 Jun 2005 07:26:08 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 j5N7PuQc000577; Thu, 23 Jun 2005 07:26:06 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 M2005062300260619626 ; Thu, 23 Jun 2005 00:26:06 -0700 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, 23 Jun 2005 00:26:06 -0700 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] packet redirect as a core LFB Thread-Index: AcVzQkN1ImixGA0fT8K12k+yGvdIsAEglLPg X-OriginalArrivalTime: 23 Jun 2005 07:26:06.0063 (UTC) FILETIME=[D16A57F0:01C577C4] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C2B08A@orsmsx408> Date: Thu, 23 Jun 2005 00:26:04 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: packet redirect as a core LFB Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable I would agree that the LFB contents for redirector LFB should be moved out of the protocol draft. The redirect message should still be there in the PL. It seems like we are all on the same page here, we should be able to close this one soon. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, June 17, 2005 6:40 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] packet redirect as a core LFB Folks, Should we be thinking of moving the redirect part out of the protocol draft as well and making it a core LFB? It could definetely be refered as a core LFB and therefore creating speacial message types for it seems a little overzelous. It may also help speedup the closure of the protocol draft. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 23 03:50:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlMTq-00070W-6D for forces-archive@megatron.ietf.org; Thu, 23 Jun 2005 03:50:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13294 for ; Thu, 23 Jun 2005 03:50:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlMs8-0005Ll-5B for forces-archive@IETF.ORG; Thu, 23 Jun 2005 04:15:40 -0400 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.0108ADCE@cherry.ease.lsoft.com>; Thu, 23 Jun 2005 3:50:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76471521 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 Jun 2005 03:50:32 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 23 Jun 2005 03:50:31 -0400 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 j5N7oVgf004289; Thu, 23 Jun 2005 07:50:31 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 j5N7oUUo004761; Thu, 23 Jun 2005 07:50:30 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 M2005062300503008379 ; Thu, 23 Jun 2005 00:50:30 -0700 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, 23 Jun 2005 00:50:30 -0700 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] [issue22] Overview - Response Formatting Thread-Index: AcVyi3qwADFZp600TAWVnrYgozH11gFPDZyA X-OriginalArrivalTime: 23 Jun 2005 07:50:30.0671 (UTC) FILETIME=[3A63C9F0:01C577C8] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C2B093@orsmsx408> Date: Thu, 23 Jun 2005 00:50:28 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Jamal, I briefly looked at this... I don't agree with what is said about 3.xx.1 Full response in the text. We have sent responses for all messages, its worked out very well and its important for building a reliable product. Also, stated... 3.xx.2.2 More than Basic Proposed by both Weiming and Joel: Introduce RESULT TLV to describe the results of a SET operation. The RESULT TLV will have more data in it than what 3.2.1 is proposing. I don't understand the difference between this and Full response above. Also, what does RESULT TLV look like? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Thursday, June 16, 2005 8:53 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] [issue22] Overview - Response Formatting Can we work on closing issue #22? Knocking it off will allow us to resolve a few outstanding issues. Url is: http://www.mip4.org/issues/tracker/forces/issue22 cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 07:04:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dllyf-0000uN-Pu for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 07:04:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28305 for ; Fri, 24 Jun 2005 07:04:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlmNB-0003IB-Rn for forces-archive@IETF.ORG; Fri, 24 Jun 2005 07:29:26 -0400 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.0108C93A@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 7:03:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76650425 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 07:03:54 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 07:03:54 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062404071193:32910 ; Fri, 24 Jun 2005 04:07:11 -0700 References: <6.2.1.2.0.20050621115815.02dab048@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 04:07:12 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 04:07:14 AM, Serialize complete at 06/24/2005 04:07:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119611030.6190.83.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 07:03:50 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050621115815.02dab048@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit On Tue, 2005-21-06 at 12:03 -0400, Joel M. Halpern wrote: > Sorry I was unclear. let me try an example. > Suppose that we have an LFB. > Suppose that it has a table X. The contents of X are a structure with > several fields, A, B, and C. > > The event definitions define the path prefix 7 as meaning events. > Event ID 1 is defined as any change on field A of an entry in table X > (hence the specific path is 7.1.subscript) > event ID 2 is defined as any change on field B of an entry in table X > (hence the specific path is 7.2.subscript). > To subscribe to changes in the A field of the third table entry, one sets > the subscribe field of the properties of path 7.1.3. > To subscribe to changes in the A field of any entry in table X, one sets > the subscribe field of the properties of path 7.1 > To subscribe to any events from the LFB, one sets the subscribe field of > the path 7. > > However, there is no path to subscribe to all the events on cell 3 of table > X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on table > X (7.1 and 7.2) > > This is actually driven by simplicity, but makes sense to me because 7.1 > and 7.2 are easily known by the CE, while subscribing to every entry in the > table individually, particularly when new entries are created, is harder. > I read the originating text and since this you have an example here, this is probably the better example to jump to. I cant recall what our conclusion on this discussion was and i apologize in advance if i am rehashing. note: I agree with moving things into the properties of the events. I also see sense in the simplicity you introduce in the agregation. One thing i am unsettled about still is the registration, in particular with elements which present hierachies. You know at table definition time what the columns are (A, B, C in your example) - but you dont know the subscripts. This leads to a challenge for subscription purposes in my view and i think hierachical/coarse registration, bits of which you have in your other text, is a good thing; for simplicty - a very fine grained notification detail on the other is a good thing. Let me illustrate, using your example and draw the relationship that makes sense to me for both registration and notification. This is not an intuitive way to show a table, but it makes sense for the way events should be and actually it is the way you define event paths. I introduce event ID 4 on top of your example. tableX (event ID 4) | +-- A (event ID 1) | | | +-- row 1 | | | +-- row 2 | | . . . . | +-- row n | +-- B (event ID 2) | | | +-- row 1 | | | +-- row 2 | | . . . . | +-- row n | +-- C (event ID 3) | +-- row 1 | +-- row 2 | . . +-- row n Coarse Registration: - I should be able to register to 7.1, 7.2, 7.3 or 7.4. Note 7.4 covers the whole table (of course for event generating elements). Fine grained registration: Registering to 7.3.1 is harder in the case where the event to add such an entry happens dynamically at the FE. It is easy to do if the CE adds the entry for tableX, row 1. Notification: Notification will always have the details of what generated the event to the finest grained level; example 7.3.1 even though i register for 7.3 or 7.4. Thoughts? cheers, jamal From CareyHellman@bioplastic.net Fri Jun 24 07:16:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlmAo-00031r-Lj; Fri, 24 Jun 2005 07:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29393; Fri, 24 Jun 2005 07:16:37 -0400 (EDT) Received: from [221.127.24.182] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlmZJ-0003sP-JU; Fri, 24 Jun 2005 07:41:59 -0400 Received: from VTK@localhost by K6O.int (8.11.6/8.11.6); Fri, 24 Jun 2005 09:13:32 -0600 Message-ID: From: "Jacklyn Moreland" Reply-To: "Jacklyn Moreland" To: stun-owner@ietf.org, iips@ietf.org, forces-archive@ietf.org Subject: All Windows software for cheap Date: Fri, 24 Jun 2005 20:19:32 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: CareyHellman@bioplastic.net Content-Type: multipart/mixed; boundary="--r34WLgDhlXTb6stxSPeU" X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 jbP ----r34WLgDhlXTb6stxSPeU Content-Type: text/html; Content-Transfer-Encoding: quoted-printable d
Opt-in Email Special Offer &n= bsp;   unsubscribe me
=
SEARCH



<= /tr>

TOP 10 NEW TITLES

= =  

 = ON SALE NOW!

 1 Office Pro 2003
 2 = Windows XP Pro
 3 Ado= be Creative Suite Premium
 4= Norton Antivirus 2005
&nbs= p;5 Flash MX 2004
 <= /td>6 Corel Draw 12
 7 Adobe Acrobat 7.0
 = 8 Windows 2003 Server
&= nbsp;9 Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Microsoft
   Ap= ple Software
  Custom= ers also bought
  these other items...=
Microsoft Office Professional Edition *2003*=
Microsof= t
Choose:
 
You Save:


Availability: Available for INSTANT do= wnload!
Coupon Code: ISe229
Media: CD-ROM / Download=

= System requirements  |  Accessories  |  Other = Versions

Features:

  • Analyze and manage busi= ness information using Access databases
  • Exchange data with other systems using enhanced XML technology=
  • Control information sharing= rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marke= ting materials
  • More than 20 = preformatted business reports
= Sales Rank: #1
Shipping: International/US o= r via instant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based = on 1,768 reviews. Write a review.=
List Price:$899.00
Price:$69.99
$830.01 (92%)
Microsoft Windows XP Professional or Longho= rn Edition
Microsoft
= Choose:
<= select name=3DD1>  

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Avail= ability: Available for INSTANT download!
Coupon Code: ISe22= 9
Media: CD-ROM / Download

= System requirements  | = Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and= more
  • More security with the= ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and ma= nagement solutions

Sales Rank: #2
Shipping: International/US or via instant do= wnload
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. = Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
Choo= se:
 

List Price: = $599.00
Price:$69.99
You Save:$529.01 (90= %)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Me= dia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Feat= ures:

  • Customized workspace; save personalized workspace and tool settings= ; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in or cust= omized scripts
  • Improved file= management, new design possibilities, and a more intuitive way to create = for the Web
  • Support for 16-b= it images, digital camera raw data, and non-square pixels
    • Create or modify photos using painting, draw= ing, and retouching tools

Sales Rank: #3
Shipping: International/US or = via instant download
Date Coupon Expires: June 30th, 2005
<= /span>Average Customer Review: 3D"5 Based on= 498 reviews. Write a review.

----r34WLgDhlXTb6stxSPeU-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 07:34:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlmSN-0005OY-W6 for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 07:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00600 for ; Fri, 24 Jun 2005 07:34:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlmqm-0004fN-6R for forces-archive@IETF.ORG; Fri, 24 Jun 2005 08:00:08 -0400 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.0108CA6F@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 7:34:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76651835 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 07:34:37 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 07:34:37 -0400 Received: from [68.232.104.14] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11079902; Fri, 24 Jun 2005 07:34:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050621115815.02dab048@localhost> <1119611030.6190.83.camel@localhost.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.20050624072959.02ce3c08@localhost> Date: Fri, 24 Jun 2005 07:34:16 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1119611030.6190.83.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 If I understand your suggestion, you are proposing that it be possible to add event declarations for targets without conditions. These event ids / declarations are used only for registration (they would never appear in notifications. A registration for such an event constitutes a registration for every actual event that can be generated against the given target? We can do that, but is it really worth it? Aggregating subscripts is both natural and necessary, since there may be many of them, and they may be created at any time. On the other hand, the events are known a priori to the CE, and there are not many. The effort for the CE to register for the events is not much harder than the effort of registering for this aggregation event. And I am somewhat uncomfortable with event declarations that are not events. Yours, Joel At 07:03 AM 6/24/2005, Jamal Hadi Salim wrote: >On Tue, 2005-21-06 at 12:03 -0400, Joel M. Halpern wrote: > > Sorry I was unclear. let me try an example. > > Suppose that we have an LFB. > > Suppose that it has a table X. The contents of X are a structure with > > several fields, A, B, and C. > > > > The event definitions define the path prefix 7 as meaning events. > > Event ID 1 is defined as any change on field A of an entry in table X > > (hence the specific path is 7.1.subscript) > > event ID 2 is defined as any change on field B of an entry in table X > > (hence the specific path is 7.2.subscript). > > To subscribe to changes in the A field of the third table entry, one sets > > the subscribe field of the properties of path 7.1.3. > > To subscribe to changes in the A field of any entry in table X, one sets > > the subscribe field of the properties of path 7.1 > > To subscribe to any events from the LFB, one sets the subscribe field of > > the path 7. > > > > However, there is no path to subscribe to all the events on cell 3 of > table > > X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on > table > > X (7.1 and 7.2) > > > > This is actually driven by simplicity, but makes sense to me because 7.1 > > and 7.2 are easily known by the CE, while subscribing to every entry in > the > > table individually, particularly when new entries are created, is harder. > > > >I read the originating text and since this you have an example here, >this is probably the better example to jump to. >I cant recall what our conclusion on this discussion was and i apologize >in advance if i am rehashing. >note: I agree with moving things into the properties of the events. >I also see sense in the simplicity you introduce in the agregation. > >One thing i am unsettled about still is the registration, in particular >with elements which present hierachies. > >You know at table definition time what the columns are (A, B, C in your >example) - but you dont know the subscripts. >This leads to a challenge for subscription purposes in my view and i >think hierachical/coarse registration, bits of which you have in your >other text, is a good thing; for simplicty - a very fine grained >notification detail on the other is a good thing. Let me illustrate, >using your example and draw the relationship that makes sense to me for >both registration and notification. This is not an intuitive way to show >a table, but it makes sense for the way events should be and actually it >is the way you define event paths. >I introduce event ID 4 on top of your example. > > tableX (event ID 4) > | > +-- A (event ID 1) > | | > | +-- row 1 > | | > | +-- row 2 > | | > . . > . . > | +-- row n > | > +-- B (event ID 2) > | | > | +-- row 1 > | | > | +-- row 2 > | | > . . > . . > | +-- row n > | > +-- C (event ID 3) > | > +-- row 1 > | > +-- row 2 > | > . > . > +-- row n > >Coarse Registration: >- I should be able to register to 7.1, 7.2, 7.3 or 7.4. >Note 7.4 covers the whole table (of course for event generating >elements). > >Fine grained registration: >Registering to 7.3.1 is harder in the case where the event to add such >an entry happens dynamically at the FE. It is easy to do if the CE adds >the entry for tableX, row 1. > >Notification: >Notification will always have the details of what generated the event to >the finest grained level; example 7.3.1 even though i register for 7.3 >or 7.4. > >Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 07:59:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlmqE-0000Yx-Mb for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 07:59:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02602 for ; Fri, 24 Jun 2005 07:59:25 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlnEk-0005r3-Hm for forces-archive@IETF.ORG; Fri, 24 Jun 2005 08:24:47 -0400 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.0108CAF0@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 7:59:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76653408 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 07:59:12 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 07:59:12 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062405023067:32944 ; Fri, 24 Jun 2005 05:02:30 -0700 References: <6.2.1.2.0.20050621115815.02dab048@localhost> <1119611030.6190.83.camel@localhost.localdomain> <6.2.1.2.0.20050624072959.02ce3c08@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 05:02:31 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 05:02:32 AM, Serialize complete at 06/24/2005 05:02:32 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119614349.6190.127.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 07:59:09 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050624072959.02ce3c08@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Fri, 2005-24-06 at 07:34 -0400, Joel M. Halpern wrote: > If I understand your suggestion, you are proposing that it be possible to > add event declarations for targets without conditions. These event ids / > declarations are used only for registration (they would never appear in > notifications. No they would appear in the notification. Its up to the CE (if i understood you correctly) to map them to something meaningful. > A registration for such an event constitutes a registration for every > actual event that can be generated against the given target? > Ok, i realize i was thinking narrowly basing on the scope of what we have implemented to date. The only thing we are currently excited about as far as event is of nature (whether its ipsec, port LFB etc). Thats the only events we have. So my thoughts were along the mindset that the event type will be homogenous across the table i.e all of A, B, and C throw events and i can therefore register for 7.4 ("the table events"). If the events are not going to be homegenous then it is not worth it. If however, we can leave that up to the CE it may be worth it. > We can do that, but is it really worth it? Aggregating subscripts is both > natural and necessary, since there may be many of them, and they may be > created at any time. On the other hand, the events are known a priori to > the CE, and there are not many. The effort for the CE to register for the > events is not much harder than the effort of registering for this > aggregation event. I think we are partially agreeing: If i heard you correctly you are saying i can register for agregated events 7.1, 7.2, 7.3 and receive fine grained notifications for 7.1.1, 7.1.n etc. This i like. What i also thought i heard you say is you cant register for aggregate event 7.4 "the table events". This is where we differ (given our current implemented LFBs have homogenous event types). > And I am somewhat uncomfortable with event declarations that are not events. If 7.4 will introduce complexity to the model then i can live with the CE translating it to mean {7.1, 7.2, 7.3}. It will help to explicitly mention this in your text somewhere. It does seem to me like it would ease things for the FE if i told it about 7.4 instead, no? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 08:40:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlnUR-00074h-3L for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 08:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05255 for ; Fri, 24 Jun 2005 08:40:58 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlnsx-0007dT-E9 for forces-archive@IETF.ORG; Fri, 24 Jun 2005 09:06:20 -0400 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.0108CBC2@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 8:40:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76664231 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 08:40:54 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 08:40:48 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062405440603:32978 ; Fri, 24 Jun 2005 05:44:06 -0700 References: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 05:44:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 05:44:07 AM, Serialize complete at 06/24/2005 05:44:07 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119616844.6190.157.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 08:40:44 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue54] correlator in the PL message header Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > Thanks for the input, Sue. > I believe we have decided to leave the SN as is and add a Correlator as > well to the header. So that should address any such requirements. > I dont know if we have heard from Weiming on this so we can close it? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:11:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlnyJ-0003A5-Ql for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07195 for ; Fri, 24 Jun 2005 09:11:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DloMr-0000Q5-Bv for forces-archive@IETF.ORG; Fri, 24 Jun 2005 09:37:13 -0400 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.0108CAD3@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:11:50 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76668355 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:11:49 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:11:49 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062406150724:32995 ; Fri, 24 Jun 2005 06:15:07 -0700 References: <468F3FDA28AA87429AD807992E22D07E05C2B093@orsmsx408> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:15:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:15:09 AM, Serialize complete at 06/24/2005 06:15:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119618706.6190.180.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 09:11:45 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue22] Overview - Response Formatting Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E05C2B093@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > I briefly looked at this... > > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. > Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question. > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. > > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? > The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:27:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloDk-0005ZX-QH for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:27:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08075 for ; Fri, 24 Jun 2005 09:27:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlocI-00011d-Ap for forces-archive@IETF.ORG; Fri, 24 Jun 2005 09:53:10 -0400 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.0108CC90@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:27:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76669290 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:27:28 -0400 Received: from 64.12.137.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:27:27 -0400 Received: from Aaudu2000@aol.com by imo-m22.mx.aol.com (mail_out_v38_r1.7.) id l.cf.2b543e9c (16087); Fri, 24 Jun 2005 09:27:06 -0400 (EDT) Received: from mblk-d44 (mblk-d44.mblk.aol.com [205.188.212.228]) by air-id10.mx.aol.com (v106.2) with ESMTP id MAILINID104-3ed742bc0a2a3af; Fri, 24 Jun 2005 09:27:06 -0400 References: <468F3FDA28AA87429AD807992E22D07E05C2B093@orsmsx408> <1119618706.6190.180.camel@localhost.localdomain> Received: from 71.96.135.183 by mblk-d44.sysops.aol.com (205.188.212.228) with HTTP (WebMailUI); Fri, 24 Jun 2005 09:27:06 -0400 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: AOL WebMail 1.1.0.12781 Content-Type: multipart/alternative; boundary="--------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com" MIME-Version: 1.0 X-AOL-IP: 205.188.212.228 Approved-By: aaudu2000@AOL.COM Message-ID: <8C746D78CECCAFD-A0C-1B1E@mblk-d44.sysops.aol.com> Date: Fri, 24 Jun 2005 09:27:06 -0400 Reply-To: aaudu2000@aol.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1119618706.6190.180.camel@localhost.localdomain> Precedence: list X-Spam-Score: 1.3 (+) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 ----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Hi All, Can we make this feature configurable? There is no doubt this feature is useful (e.g. when debuging data connectivity problems from the application side). It is also true you don't want to echo the the request all the time. That could kill your bandwidth efficiency. So,..make it configurable; so I can turn it on when I need it. Cheers, Alex. -----Original Message----- From: Jamal Hadi Salim To: FORCES@PEACH.EASE.LSOFT.COM Sent: Fri, 24 Jun 2005 09:11:45 -0400 Subject: Re: [issue22] Overview - Response Formatting On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, > > I briefly looked at this... > > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. > Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question. > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. > > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? > The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal ----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com Content-Type: text/html; charset="us-ascii"
Hi All,
 
Can we make this feature configurable?  There is no doubt this feature is useful (e.g. when debuging
data connectivity problems from the application side).  It is also true you don't want to echo the
the request all the time. That could kill your bandwidth efficiency.  So,..make it configurable; so I can
turn it on when I need it.
 
Cheers,
Alex.
  
 
-----Original Message-----
From: Jamal Hadi Salim <hadi@znyx.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Fri, 24 Jun 2005 09:11:45 -0400
Subject: Re: [issue22] Overview - Response Formatting

On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> I briefly looked at this...
> 
> I don't agree with what is said about 3.xx.1 Full response in the text.
> We have sent responses for all messages, its worked out very well and
> its important for building a reliable product.
> 

Parse error. What do you mean by so far you have sent response for all
messages?
(cliches like "reliable product" to justify anything technical will end
up diverting the focus of the discussion -  and I am pretty sure we dont
have marketing people participating that need to be confused with such
terms. Why not be explicit?).

I think the Full response will have to go; it's more there for
completion sake. I cant remember why it was rejected; i know it will
consume more bandwidth. It's value is in as mentioned to validate what
was sent. This is derived from looking at behaviors of certain hardware.
There is hardware out there (typically using CAMs) which returns you
both the question asked and answer to the question. 

> Also, stated...
> 3.xx.2.2 More than Basic
> Proposed by both Weiming and Joel: Introduce RESULT TLV
> to describe the results of a SET operation. The RESULT TLV will
> have more data in it than what 3.2.1 is proposing.
> 
> I don't understand the difference between this and Full response above.
> Also, what does RESULT TLV look like?
> 

The RESULT TLV is still to be defined. Joel and Weiming were both
proposing it.

Thanks for taking the time to read the text.
It is amazing for a draft that we are trying to rush out to last call
not that many people are responding.


cheers,
jamal
----------MailBlocks_8C746D78CE8064D_A0C_1A52_mblk-d44.sysops.aol.com-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:27:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloDm-0005Zj-8l for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:27:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08093 for ; Fri, 24 Jun 2005 09:27:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlocI-00011d-Rm for forces-archive@IETF.ORG; Fri, 24 Jun 2005 09:53:12 -0400 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.0108CD01@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:27:47 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76669307 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:27:46 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:27:46 -0400 Received: from [12.58.128.11] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11081100 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:27:45 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050621115815.02dab048@localhost> <1119611030.6190.83.camel@localhost.localdomain> <6.2.1.2.0.20050624072959.02ce3c08@localhost> <1119614349.6190.127.camel@localhost.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.20050624092613.02cc9368@localhost> Date: Fri, 24 Jun 2005 09:27:45 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Event subscription -- properties (model and protocol) To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1119614349.6190.127.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 I can see how what you suggest would work if events were homogenous. I don't think they are. Given that they are not, I will try to add suitable explanatory text about what aggregations can and can not be registered for, and why. Yours, Joel At 07:59 AM 6/24/2005, Jamal Hadi Salim wrote: >On Fri, 2005-24-06 at 07:34 -0400, Joel M. Halpern wrote: > > If I understand your suggestion, you are proposing that it be possible to > > add event declarations for targets without conditions. These event ids / > > declarations are used only for registration (they would never appear in > > notifications. > >No they would appear in the notification. Its up to the CE (if i >understood you correctly) to map them to something meaningful. > > > A registration for such an event constitutes a registration for every > > actual event that can be generated against the given target? > > > >Ok, i realize i was thinking narrowly basing on the scope of what we >have implemented to date. The only thing we are currently excited about >as far as event is of nature (whether its ipsec, port LFB etc). >Thats the only events we have. >So my thoughts were along the mindset that the event type will be >homogenous across the table i.e all of A, B, and C throw events >and i can therefore register for 7.4 ("the table events"). If the events >are not going to be homegenous then it is not worth it. If however, we >can leave that up to the CE it may be worth it. > > > We can do that, but is it really worth it? Aggregating subscripts is both > > natural and necessary, since there may be many of them, and they may be > > created at any time. On the other hand, the events are known a priori to > > the CE, and there are not many. The effort for the CE to register for the > > events is not much harder than the effort of registering for this > > aggregation event. > >I think we are partially agreeing: >If i heard you correctly you are saying i can register for agregated >events 7.1, 7.2, 7.3 and receive fine grained notifications for 7.1.1, >7.1.n etc. This i like. >What i also thought i heard you say is you cant register for aggregate >event 7.4 "the table events". This is where we differ (given our >current implemented LFBs have homogenous event types). > > > And I am somewhat uncomfortable with event declarations that are not > events. > >If 7.4 will introduce complexity to the model then i can live with the >CE translating it to mean {7.1, 7.2, 7.3}. It will help to explicitly >mention this in your text somewhere. It does seem to me like it would >ease things for the FE if i told it about 7.4 instead, no? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:35:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloKt-0006qP-LO for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:35:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08388 for ; Fri, 24 Jun 2005 09:35:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlojR-0001I4-90 for forces-archive@IETF.ORG; Fri, 24 Jun 2005 10:00:33 -0400 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.0108CC72@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:35:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76669924 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:35:08 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:35:08 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5ODZ8GM328710 for ; Fri, 24 Jun 2005 13:35:08 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5ODZ8to151078 for ; Fri, 24 Jun 2005 14:35:08 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5ODZ7qJ024024 for ; Fri, 24 Jun 2005 14:35:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5ODZ7D8024010 for ; Fri, 24 Jun 2005 14:35:07 +0100 Received: from [127.0.0.1] (dhcp70-70.zurich.ibm.com [9.4.70.70]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA63642 for ; Fri, 24 Jun 2005 15:35:07 +0200 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> <1119616844.6190.157.camel@localhost.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 mtagate3.uk.ibm.com id j5ODZ8GM328710 Approved-By: Robert Haas Message-ID: <42BC0C09.2010300@zurich.ibm.com> Date: Fri, 24 Jun 2005 15:35:05 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1119616844.6190.157.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable I haven't heard much reactions to my last post on the topic, so let me reformulate it in a shorter way: - what is currently called SN is in fact used as a Transaction ID. One can (ab)use it for sequencing a subset of messages (see details in my previous post) - for full sequencing capability, a distinct field from Transaction ID should be introduced. - in addition, yet another field for higher-level correlation should be introduced. So now that we agreed we need (at least) two fields, how shall we call=20 them and what meaning/semantic do we give to them ? field #1: Transaction ID ? 16 bits ? field #2: Correlator ? 32 bits ? possibly field #3: true Sequence Number 16-32 bits ? Regards, -Robert Jamal Hadi Salim wrote: >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > =20 > >>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlator as >>well to the header. So that should address any such requirements. >> >> =20 >> > >I dont know if we have heard from Weiming on this so we can close it? > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:38:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloNc-00078E-Bw for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:38:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08591 for ; Fri, 24 Jun 2005 09:37:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlom9-0001PB-1Q for forces-archive@IETF.ORG; Fri, 24 Jun 2005 10:03:22 -0400 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.0108CCD2@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:37:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76670108 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:37:56 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:37:55 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062406411397:33030 ; Fri, 24 Jun 2005 06:41:13 -0700 References: <468F3FDA28AA87429AD807992E22D07E05C2B093@orsmsx408> <1119618706.6190.180.camel@localhost.localdomain> <8C746D78CECCAFD-A0C-1B1E@mblk-d44.sysops.aol.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:41:14 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:41:15 AM, Serialize complete at 06/24/2005 06:41:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119620272.6190.189.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 09:37:52 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue22] Overview - Response Formatting Comments: To: aaudu2000@aol.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <8C746D78CECCAFD-A0C-1B1E@mblk-d44.sysops.aol.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Mr Audu alive and kicking! Welcome back. I forgot to mention the debug feature, thanks for bringing it up. cheers, jamal On Fri, 2005-24-06 at 09:27 -0400, Alex Audu wrote: > Hi All, > > Can we make this feature configurable? There is no doubt this feature > is useful (e.g. when debuging > data connectivity problems from the application side). It is also > true you don't want to echo the > the request all the time. That could kill your bandwidth efficiency. > So,..make it configurable; so I can > turn it on when I need it. > > Cheers, > Alex. > > > -----Original Message----- > From: Jamal Hadi Salim > To: FORCES@PEACH.EASE.LSOFT.COM > Sent: Fri, 24 Jun 2005 09:11:45 -0400 > Subject: Re: [issue22] Overview - Response Formatting > > On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > > Jamal, > > > > I briefly looked at this... > > > > I don't agree with what is said about 3.xx.1 Full response in the text. > > We have sent responses for all messages, its worked out very well and > > its important for building a reliable product. > > > > Parse error. What do you mean by so far you have sent response for all > messages? > (cliches like "reliable product" to justify anything technical will end > up diverting the focus of the discussion - and I am pretty sure we dont > have marketing people participating that need to be confused with such > terms. Why not be explicit?). > > I think the Full response will have to go; it's more there for > completion sake. I cant remember why it was rejected; i know it will > consume more bandwidth. It's value is in as mentioned to validate what > was sent. This is derived from looking at behaviors of certain hardware. > There is hardware out there (typically using CAMs) which returns you > both the question asked and answer to the question. > > > Also, stated... > > 3.xx.2.2 More than Basic > > Proposed by both Weiming and Joel: Introduce RESULT TLV > > to describe the results of a SET operation. The RESULT TLV will > > have more data in it than what 3.2.1 is proposing. > > > > I don't understand the difference between this and Full response above. > > Also, what does RESULT TLV look like? > > > > The RESULT TLV is still to be defined. Joel and Weiming were both > proposing it. > > Thanks for taking the time to read the text. > It is amazing for a draft that we are trying to rush out to last call > not that many people are responding. > > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 09:38:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloO4-0007Hk-8B for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 09:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08614 for ; Fri, 24 Jun 2005 09:38:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlomb-0001PZ-2z for forces-archive@IETF.ORG; Fri, 24 Jun 2005 10:03:50 -0400 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.0108CCB0@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 9:38:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76670139 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 09:38:25 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 09:38:25 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062406414400:33033 ; Fri, 24 Jun 2005 06:41:44 -0700 References: <6.2.1.2.0.20050621115815.02dab048@localhost> <1119611030.6190.83.camel@localhost.localdomain> <6.2.1.2.0.20050624072959.02ce3c08@localhost> <1119614349.6190.127.camel@localhost.localdomain> <6.2.1.2.0.20050624092613.02cc9368@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:41:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/24/2005 06:41:45 AM, Serialize complete at 06/24/2005 06:41:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119620302.6190.191.camel@localhost.localdomain> Date: Fri, 24 Jun 2005 09:38:22 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Event subscription -- properties (model and protocol) Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050624092613.02cc9368@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit On Fri, 2005-24-06 at 09:27 -0400, Joel M. Halpern wrote: > I can see how what you suggest would work if events were homogenous. I > don't think they are. > Given that they are not, I will try to add suitable explanatory text about > what aggregations can and can not be registered for, and why. That would be fine with me. Thanks. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 10:17:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlozM-0004p4-V8 for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 10:17:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12603 for ; Fri, 24 Jun 2005 10:16:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlpNq-00034z-KP for forces-archive@IETF.ORG; Fri, 24 Jun 2005 10:42:23 -0400 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.0108CE3C@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 10:16:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 76674424 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 10:16:53 -0400 Received: from 64.12.138.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 10:16:53 -0400 Received: from Aaudu2000@aol.com by imo-m17.mx.aol.com (mail_out_v38_r1.7.) id r.1e5.3eee5404 (16110); Fri, 24 Jun 2005 10:16:48 -0400 (EDT) Received: from mblk-d44 (mblk-d44.mblk.aol.com [205.188.212.228]) by air-id12.mx.aol.com (v106.2) with ESMTP id MAILINID122-3eee42bc15d090; Fri, 24 Jun 2005 10:16:48 -0400 References: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> <1119616844.6190.157.camel@localhost.localdomain> <42BC0C09.2010300@zurich.ibm.com> Received: from 71.96.135.183 by mblk-d44.sysops.aol.com (205.188.212.228) with HTTP (WebMailUI); Fri, 24 Jun 2005 10:16:48 -0400 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: AOL WebMail 1.1.0.12781 Content-Type: multipart/alternative; boundary="--------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com" MIME-Version: 1.0 X-AOL-IP: 205.188.212.228 Approved-By: aaudu2000@AOL.COM Message-ID: <8C746DE7E3C69AF-A0C-2042@mblk-d44.sysops.aol.com> Date: Fri, 24 Jun 2005 10:16:48 -0400 Reply-To: aaudu2000@aol.com Sender: Forwarding and Control Element Separation From: Alex Audu Subject: Re: [issue54] correlator in the PL message header Comments: To: rha@zurich.ibm.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42BC0C09.2010300@zurich.ibm.com> Precedence: list X-Spam-Score: 1.7 (+) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 ----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Robert, =20 Given that a transaction is a sequence of message or information exchanges t= reated as a unit for the purpose of satisfying a request, I am finding a little difficulty in= understanding why=20 we need a transaction ID in this layer. And then a correlator? What is the= need for this? =20 Regards, Alex. =20 =20 -----Original Message----- From: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Sent: Fri, 24 Jun 2005 15:35:05 +0200 Subject: Re: [issue54] correlator in the PL message header I haven't heard much reactions to my last post on the topic, so let me=20 reformulate it in a shorter way:=20 - what is currently called SN is in fact used as a Transaction ID. One=20 can (ab)use it for sequencing a subset of messages (see details in my=20 previous post)=20 - for full sequencing capability, a distinct field from Transaction ID=20 should be introduced.=20 - in addition, yet another field for higher-level correlation should be=20 introduced.=20 =20 So now that we agreed we need (at least) two fields, how shall we call them=20= and what meaning/semantic do we give to them ?=20 =20 field #1: Transaction ID ? 16 bits ?=20 field #2: Correlator ? 32 bits ?=20 possibly field #3: true Sequence Number 16-32 bits ?=20 =20 Regards,=20 -Robert=20 =20 Jamal Hadi Salim wrote:=20 =20 >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote:=20 > >=20 >>Thanks for the input, Sue.=20 >>I believe we have decided to leave the SN as is and add a Correlator as=20 >>well to the header. So that should address any such requirements.=20 >>=20 >> >>=20 >=20 >I dont know if we have heard from Weiming on this so we can close it?=20 >=20 >cheers,=20 >jamal=20 >=20 >=20 > >=20 =20 -- Dr. Robert R. Haas=20 IBM Zurich Research Laboratory=20 S=E4umerstrasse 4=20 CH-8803 R=FCschlikon/Switzerland=20 phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha=20 ----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hel= lo Robert,
 
Given that a transaction is a sequence of message or information exchan= ges treated as a unit
for the purpose of satisfying a request, I am finding a little difficul= ty in understanding why
we need a transaction ID in this layer.  And then a correlator?&nb= sp; What is the need for this?
 
Regards,
Alex.
 
 

-----Original Message-----
From: Robert Haas <rha@zurich.ibm.= com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Fri, 24 Jun 2005 15:35:0= 5 +0200
Subject: Re: [issue54] correlator in the PL message header
I haven't heard much reactions to my last post on the topic, so let= me 
reformulate it in a shorter way: 
- what is currently c= alled SN is in fact used as a Transaction ID. One 
can (ab)use it fo= r sequencing a subset of messages (see details in my 
previous post)=  
- for full sequencing capability, a distinct field from Transactio= n ID 
should be introduced. 
- in addition, yet another fiel= d for higher-level correlation should be 
introduced. 
 = ;
So now that we agreed we need (at least) two fields, how shall we call=20= them and what meaning/semantic do we give to them ? 
 
field= #1: Transaction ID ? 16 bits ? 
field #2: Correlator ? 32 bits ?&nb= sp;
possibly field #3: true Sequence Number 16-32 bits ? 
 <= BR>Regards, 
-Robert 
 
Jamal Hadi Salim wrote: = ;
 
>On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wr= ote: 
> > 
>>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlato= r as 
>>well to the header. So that should address any such re= quirements. 
>> 
>> >> 
> =
>I dont know if we have heard from Weiming on this so we can close it= ? 
> 
>cheers, 
>jamal 
> <= BR>> 
> > 
 
-- Dr. Robert R. Haas IBM Zurich Research Laboratory 
S=E4umerstrasse 4 
CH-8803=20= R=FCschlikon/Switzerland 
phone +41-44-724-8698 fax +41-44-724-8578=20= http://www.zurich= .ibm.com/~rha 
----------MailBlocks_8C746DE7E3A075A_A0C_1F68_mblk-d44.sysops.aol.com-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 12:13:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqoR-0007jN-4Y for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 12:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21103 for ; Fri, 24 Jun 2005 12:13:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrCv-00081F-Cc for forces-archive@IETF.ORG; Fri, 24 Jun 2005 12:39:14 -0400 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.0108D063@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 12:13:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76688030 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 12:13:43 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 12:13:42 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sat, 25 Jun 2005 00:49:40 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E05C2B085@orsmsx408> <1119616844.6190.157.camel@localhost.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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <005701c578d7$b48a2020$020aa8c0@wwm1> Date: Sat, 25 Jun 2005 00:13:48 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYW5rcyBmb3IgdGhlIG1lbnRpb24sIHdoZXJlYXMgSSB0aGluayBJJ3YgZXhw cmVzc2VkIG15IG9waW5pb24gaW4gbXkgcHJldmlvdXMgcG9zdHMuIEkgY2FuIGxpdmUgd2l0aCB0 d28gZmllbGRzIChTTiBhbmQgY29ycmVsYXRvcikgc29sdXRpb24sIHRob3VnaHQgSSBkbyB0aGlu ayBvbmUgZmllbGQgaXMgZW5vdWdoIGZvciBvdXIgY3VycmVudCB1c2UgZm9yIHRoZSBtZXNzYWdl IHNlcXVlbmNpbmcgcHVycG9zZSwgdGhhdCBpcywgc2VxdWVuY2luZyBvZiBtZXNzYWdlcyB3aXRo b3V0IHJlc3BvbnNlIG1lc3NhZ2VzLCB3aGljaCBhbHJlYWR5IGVub3VnaCBmb3IgdGhlIHB1cnBv c2UgbGlrZSByZWRpcmVjdCBtZXNzYWdlIG9yZGVyaW5nIGJhY2suIE9uZSBtb3JlIHRoaW5nIGlz LCBmb3IgdHdvIGZpZWxkcyBzb2x1dGlvbnMsIEkgc3VnZ2VzdCB0byBsZXQgdGhlIGNvcnJlbGF0 b3IgZmllbGQgdXN1YWxseSBoYXZlIHRoZSBzYW1lIHZhbHVlIGFzIHRoZSBTTiBmaWVsZCwgZXhj ZXB0IGZvciByZXNwb25zZSBtZXNzYWdlcywgd2hpY2ggc2hvdWxkIGhhdmUgdGhlIGNvcnJlbGF0 b3IgdmFsdWVzIGFzIHRoZSBtZXNzYWdlcyB0aGV5IHJlcGx5LCBzbyBhcyB0byBzaW1wbGlmeSB0 aGUgY29ycmVsYXRvciB2YWx1ZSBnZW5lcmF0aW5nLg0KDQpUaGFua3MsDQpXZWltaW5nDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRp QHpueXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTU0XSBjb3JyZWxhdG9yIGluIHRoZSBQTCBt ZXNzYWdlIGhlYWRlcg0KDQoNCj4gT24gVGh1LCAyMDA1LTIzLTA2IGF0IDAwOjE3IC0wNzAwLCBL aG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiA+IFRoYW5rcyBmb3IgdGhlIGlucHV0LCBTdWUu DQo+ID4gSSBiZWxpZXZlIHdlIGhhdmUgZGVjaWRlZCB0byBsZWF2ZSB0aGUgU04gYXMgaXMgYW5k IGFkZCBhIENvcnJlbGF0b3IgYXMNCj4gPiB3ZWxsIHRvIHRoZSBoZWFkZXIuIFNvIHRoYXQgc2hv dWxkIGFkZHJlc3MgYW55IHN1Y2ggcmVxdWlyZW1lbnRzLg0KPiA+IA0KPiANCj4gSSBkb250IGtu b3cgaWYgd2UgaGF2ZSBoZWFyZCBmcm9tIFdlaW1pbmcgb24gdGhpcyBzbyB3ZSBjYW4gY2xvc2Ug aXQ/DQo+IA0KPiBjaGVlcnMsDQo+IGphbWFs From owner-forces@PEACH.EASE.LSOFT.COM Fri Jun 24 13:59:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlsST-0002AM-3R for forces-archive@megatron.ietf.org; Fri, 24 Jun 2005 13:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29259 for ; Fri, 24 Jun 2005 13:59:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlsr2-0003v1-3h for forces-archive@IETF.ORG; Fri, 24 Jun 2005 14:24:41 -0400 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.0108D3E7@cherry.ease.lsoft.com>; Fri, 24 Jun 2005 13:59:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76697665 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 24 Jun 2005 13:59:12 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 24 Jun 2005 13:59:11 -0400 Received: from [211.167.158.206] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sat, 25 Jun 2005 02:34:49 +0800 (CST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 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: <007c01c578e6$649191c0$020aa8c0@wwm1> Date: Sat, 25 Jun 2005 01:58:34 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: base64 U3VzYW4sDQoNClZlcnkgZ2xhZCB0byBzZWUgeW91LiAgDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmV4dGhvcC5jb20+DQpTdWJq ZWN0OiBSRTogW0ZPUkNFU10gW2lzc3VlNTRdIGNvcnJlbGF0b3IgaW4gdGhlIFBMIG1lc3NhZ2Ug aGVhZGVyDQoNCg0KV2VpbWluZzoNCg0KR3JlYXQgbmV3cyB0aGF0IHdlIGNhbiBoYXZlIDIgZmll bGRzLiAgQXJlIHlvdSBmaXJtIG9uIHRoZSBTTi9jb3JyZWxhdG9yDQp2YWx1ZXMgb3Igd291bGQg eW91IGVudGVydGFpbiBhIGRpc2N1c3Npb24gb2YgcGFyYWxsZWxpemF0aW9uIG9mDQp1cGRhdGlu ZyBzdHJlYW1zIHVzaW5nIHRoZSBTTi9jb3JyZWxhdG9yPw0KW1dlaW1pbmddIFNvcnJ5LCBidXQg SSBqdXN0IGNhbm4ndCBjYXRjaCB3ZWxsIG9uIHRoZSBwYXJhbGxlbGl6YXRpb24gb2YgdXBkYXRp bmcgc3RyZWFtcyBoZXJlLiAgQ291bGQgeW91IHNob3cgbW9yZSBvZiB5b3VyIHRob3VnaHRzIG9u IHRoaXM/DQoNClRoYW5rcywNCldlaW1pbmcNCg0KDQpTdWUgSGFyZXMNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNl cGFyYXRpb24NClttYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbGYg T2YgV2VpbWluZyBXYW5nDQpTZW50OiBGcmlkYXksIEp1bmUgMjQsIDIwMDUgMTI6MTQgUE0NClRv OiBGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00NClN1YmplY3Q6IFJlOiBbRk9SQ0VTXSBbaXNz dWU1NF0gY29ycmVsYXRvciBpbiB0aGUgUEwgbWVzc2FnZSBoZWFkZXINCg0KSmFtYWwsDQoNClRo YW5rcyBmb3IgdGhlIG1lbnRpb24sIHdoZXJlYXMgSSB0aGluayBJJ3YgZXhwcmVzc2VkIG15IG9w aW5pb24gaW4gbXkNCnByZXZpb3VzIHBvc3RzLiBJIGNhbiBsaXZlIHdpdGggdHdvIGZpZWxkcyAo U04gYW5kIGNvcnJlbGF0b3IpIHNvbHV0aW9uLA0KdGhvdWdodCBJIGRvIHRoaW5rIG9uZSBmaWVs ZCBpcyBlbm91Z2ggZm9yIG91ciBjdXJyZW50IHVzZSBmb3IgdGhlDQptZXNzYWdlIHNlcXVlbmNp bmcgcHVycG9zZSwgdGhhdCBpcywgc2VxdWVuY2luZyBvZiBtZXNzYWdlcyB3aXRob3V0DQpyZXNw b25zZSBtZXNzYWdlcywgd2hpY2ggYWxyZWFkeSBlbm91Z2ggZm9yIHRoZSBwdXJwb3NlIGxpa2Ug cmVkaXJlY3QNCm1lc3NhZ2Ugb3JkZXJpbmcgYmFjay4gT25lIG1vcmUgdGhpbmcgaXMsIGZvciB0 d28gZmllbGRzIHNvbHV0aW9ucywgSQ0Kc3VnZ2VzdCB0byBsZXQgdGhlIGNvcnJlbGF0b3IgZmll bGQgdXN1YWxseSBoYXZlIHRoZSBzYW1lIHZhbHVlIGFzIHRoZQ0KU04gZmllbGQsIGV4Y2VwdCBm b3IgcmVzcG9uc2UgbWVzc2FnZXMsIHdoaWNoIHNob3VsZCBoYXZlIHRoZSBjb3JyZWxhdG9yDQp2 YWx1ZXMgYXMgdGhlIG1lc3NhZ2VzIHRoZXkgcmVwbHksIHNvIGFzIHRvIHNpbXBsaWZ5IHRoZSBj b3JyZWxhdG9yDQp2YWx1ZSBnZW5lcmF0aW5nLg0KDQpUaGFua3MsDQpXZWltaW5nDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQHpu eXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTU0XSBjb3JyZWxhdG9yIGluIHRoZSBQTCBtZXNz YWdlIGhlYWRlcg0KDQoNCj4gT24gVGh1LCAyMDA1LTIzLTA2IGF0IDAwOjE3IC0wNzAwLCBLaG9z cmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiA+IFRoYW5rcyBmb3IgdGhlIGlucHV0LCBTdWUuDQo+ ID4gSSBiZWxpZXZlIHdlIGhhdmUgZGVjaWRlZCB0byBsZWF2ZSB0aGUgU04gYXMgaXMgYW5kIGFk ZCBhIENvcnJlbGF0b3INCmFzDQo+ID4gd2VsbCB0byB0aGUgaGVhZGVyLiBTbyB0aGF0IHNob3Vs ZCBhZGRyZXNzIGFueSBzdWNoIHJlcXVpcmVtZW50cy4NCj4gPiANCj4gDQo+IEkgZG9udCBrbm93 IGlmIHdlIGhhdmUgaGVhcmQgZnJvbSBXZWltaW5nIG9uIHRoaXMgc28gd2UgY2FuIGNsb3NlIGl0 Pw0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0K From ShaunMorgan@andrewsquire.co.uk Sat Jun 25 07:49:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm9A8-0007wo-7W; Sat, 25 Jun 2005 07:49:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19621; Sat, 25 Jun 2005 07:49:27 -0400 (EDT) From: ShaunMorgan@andrewsquire.co.uk Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm9Yq-0003Qv-Ha; Sat, 25 Jun 2005 08:15:01 -0400 Received: from 218-163-109-6.dynamic.hinet.net ([218.163.109.6]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dm99z-0003fp-Qd; Sat, 25 Jun 2005 07:49:23 -0400 Received: from C[3 Message-Id: Date: Sat, 25 Jun 2005 07:49:23 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 25 17:37:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmILW-0004aZ-JT for forces-archive@megatron.ietf.org; Sat, 25 Jun 2005 17:37:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08710 for ; Sat, 25 Jun 2005 17:37:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmIkH-0001JD-2g for forces-archive@IETF.ORG; Sat, 25 Jun 2005 18:03:29 -0400 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.0108E88A@cherry.ease.lsoft.com>; Sat, 25 Jun 2005 17:37:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76830094 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 25 Jun 2005 17:37:36 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 25 Jun 2005 17:37:36 -0400 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 j5PLbZT6019721; Sat, 25 Jun 2005 21:37:35 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 j5PLbYwc003993; Sat, 25 Jun 2005 21:37:35 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005062514373408416 ; Sat, 25 Jun 2005 14:37:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Jun 2005 14:37:34 -0700 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] [issue54] correlator in the PL message header Thread-Index: AcV4wZHBbXMTApHYQ5y/3d367lc4tQA7cFIA X-OriginalArrivalTime: 25 Jun 2005 21:37:34.0546 (UTC) FILETIME=[1959B320:01C579CE] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C9F78C@orsmsx408> Date: Sat, 25 Jun 2005 14:37:32 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue54] correlator in the PL message header Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Robert, I don't understand the need for a transaction id. I believe SN and = Correlator are more than sufficient for the protocol. It almost seems = like a terminology issue, if calling a correlator a transaction id makes = you happy, I am fine with that. But other than terminology I don't see a = need for yet another ID. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation = [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Robert Haas Sent: Friday, June 24, 2005 6:35 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue54] correlator in the PL message header I haven't heard much reactions to my last post on the topic, so let me reformulate it in a shorter way: - what is currently called SN is in fact used as a Transaction ID. One can (ab)use it for sequencing a subset of messages (see details in my previous post) - for full sequencing capability, a distinct field from Transaction ID should be introduced. - in addition, yet another field for higher-level correlation should be introduced. So now that we agreed we need (at least) two fields, how shall we call=20 them and what meaning/semantic do we give to them ? field #1: Transaction ID ? 16 bits ? field #2: Correlator ? 32 bits ? possibly field #3: true Sequence Number 16-32 bits ? Regards, -Robert Jamal Hadi Salim wrote: >On Thu, 2005-23-06 at 00:17 -0700, Khosravi, Hormuzd M wrote: > =20 > >>Thanks for the input, Sue. >>I believe we have decided to leave the SN as is and add a Correlator = as >>well to the header. So that should address any such requirements. >> >> =20 >> > >I dont know if we have heard from Weiming on this so we can close it? > >cheers, >jamal > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 = http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 25 17:48:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmIWE-000792-Ea for forces-archive@megatron.ietf.org; Sat, 25 Jun 2005 17:48:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09345 for ; Sat, 25 Jun 2005 17:48:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmIv3-0001ZO-4a for forces-archive@IETF.ORG; Sat, 25 Jun 2005 18:14:33 -0400 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.0108E676@cherry.ease.lsoft.com>; Sat, 25 Jun 2005 17:48:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76830621 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 25 Jun 2005 17:48:34 -0400 Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 25 Jun 2005 17:48:34 -0400 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 j5PLmXfv024738; Sat, 25 Jun 2005 21:48:33 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 j5PLmSwg006667; Sat, 25 Jun 2005 21:48:33 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 M2005062514483208879 ; Sat, 25 Jun 2005 14:48:32 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Jun 2005 14:48:32 -0700 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] [issue22] Overview - Response Formatting Thread-Index: AcV4vkuughIvOOXaRo6oMU7Y3XSMOwBD91FA X-OriginalArrivalTime: 25 Jun 2005 21:48:32.0923 (UTC) FILETIME=[A1C60EB0:01C579CF] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C9F791@orsmsx408> Date: Sat, 25 Jun 2005 14:48:30 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue22] Overview - Response Formatting Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Jamal, It seems like I misunderstand what you mean by Full Response...from your email and that of Alex, looks like you mean is sending back the Request Message in every response, right? If that is the case then this is not what we have done nor what we need for the protocol....we are in complete agreement. What I mean by full Response, is getting back a message for each Request... e.g. Config Response for Config Request, that tells me whether it was successful or it failed. We already have provisions for this in the protocol...the ACK flags allow us to do this. - ACK indicator(2 bit) The description for using the two bits is: 'NoACK' (00) 'SuccessACK'(01) 'UnsuccessACK'(10) 'ACKAll' (11) The RESULT TLV is probably also about the details of what should be returned in response to the request. It seems to me like this issue should be closed since we already have agreement on the ACK flags. Let me know your thoughts? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, June 24, 2005 6:12 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue22] Overview - Response Formatting On Thu, 2005-23-06 at 00:50 -0700, Khosravi, Hormuzd M wrote: > Jamal, >=20 > I briefly looked at this... >=20 > I don't agree with what is said about 3.xx.1 Full response in the text. > We have sent responses for all messages, its worked out very well and > its important for building a reliable product. >=20 Parse error. What do you mean by so far you have sent response for all messages? (cliches like "reliable product" to justify anything technical will end up diverting the focus of the discussion - and I am pretty sure we dont have marketing people participating that need to be confused with such terms. Why not be explicit?). I think the Full response will have to go; it's more there for completion sake. I cant remember why it was rejected; i know it will consume more bandwidth. It's value is in as mentioned to validate what was sent. This is derived from looking at behaviors of certain hardware. There is hardware out there (typically using CAMs) which returns you both the question asked and answer to the question.=20 > Also, stated... > 3.xx.2.2 More than Basic > Proposed by both Weiming and Joel: Introduce RESULT TLV > to describe the results of a SET operation. The RESULT TLV will > have more data in it than what 3.2.1 is proposing. >=20 > I don't understand the difference between this and Full response above. > Also, what does RESULT TLV look like? >=20 The RESULT TLV is still to be defined. Joel and Weiming were both proposing it. Thanks for taking the time to read the text. It is amazing for a draft that we are trying to rush out to last call not that many people are responding. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 25 22:51:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmNEo-0008Vv-5o for forces-archive@megatron.ietf.org; Sat, 25 Jun 2005 22:51:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29355 for ; Sat, 25 Jun 2005 22:51:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmNdY-0007nB-Nn for forces-archive@IETF.ORG; Sat, 25 Jun 2005 23:16:55 -0400 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.0108E87F@cherry.ease.lsoft.com>; Sat, 25 Jun 2005 22:51:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76844162 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 25 Jun 2005 22:51:03 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 25 Jun 2005 22:50:59 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Sun, 26 Jun 2005 11:26:46 +0800 (CST) References: <1116786905.33.0.544707347688.issue32@mip4.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: <004b01c579f9$d5fb21f0$020aa8c0@wwm1> Date: Sun, 26 Jun 2005 10:50:27 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: base64 SmFtYWwsIEpvZWwsIGFuZCBIb3JtemQsDQoNCkkgc3VwcG9zZSB3ZSBjb3VsZCBjbG9zZSB0aGlz IGlzc3VlIGJ5IHJlYWNoaW5nIHRoZSBmb2xsb3dpbmcgcG9pbnRzOg0KDQoxLiBUaGUgcmVkaXJl Y3QgTEZCcyBjYWxsZWQgUmVkaXJlY3RTb3VyY2UgIExGQiBhbmQgUmVkaXJlY3RTaW5rIExGQiBh cmUgbW92ZWQgdG8gdGhlIG1vZGVsLCBidXQgdGhlIHByb3RvY29sIHJldGFpbnMgdGhlIFJlZGly ZWN0IE1lc3NhZ2UuIFRoZSByZWFzb24gdG8ga2VlcCB0aGUgc3BlY2lmaWMgbWVzc2FnZSBpcyB3 ZSBuZWVkIHRvIHNwZWNpZmljYWxseSByZWNvZ25pemUgcmVkaXJlY3RlZCBkYXRhIGJldHdlZW4g Q0UtRkUgdHJhbnNwb3J0YXRpb24gdG8gYXZvaWQgRG9TIGF0dGFja3MuDQoNCjIuIFRoZSByZWRp cmVjdGVkIGRhdGEgaW4gdGhlIExGQnMgY2FuIGJlIHRyZWF0ZWQgYXMgYSBraW5kIG9mIFNQRUNJ QUwgZXZlbnRzIGluIHRoYXQ6DQogICAgIGEuIFRoZSBldmVudCBpcyB0cmlnZ2VyZWQgZXZlcnkg dGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldCBhcnJpdmVzIGF0IHRoZSBMRkJzLg0KICAgICBi LiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIFJlZGlyZWN0ICBNZXNzYWdlIG9ubHks IHdoaWxlIHRoZSBSZWRpcmVjdCBNZXNzYWdlIHdpbGwgdGhlIHNhbWUgbWVzc2FnZSBmb3JtYXQg YXMgYSBnZW5lcmFsIGV2ZW50IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdGhlIG1lc3Nh Z2UgdHlwZSBpbiB0aGUgaGVhZGVyKS4NCg0KQnkgZG9pbmcgaW4gdGhpcyB3YXksIHdlIGNhbiBh bHNvIHNvbHZlIHRoZSBpc3N1ZTUzIChIb3cgYSBwYXRoIHNob3VsZCBiZSBkZWZpbmVkICBpbiBQ YWNrZXQgUmVkaXJlY3QgTWVzc2FnZSkgdGhlbi4gDQoNClVuZm9ydHVuYXRlbHksICBJIHRoaW5r IG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSBQYWNrZXQgUmVkaXJl Y3QgTWVzc2FnZSBhcyB3ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlLiBUaGUg cXVlc3Rpb24gaXMsIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbnQg Z2VuZXJhdGVkIGJ5IENFIGFuZCBzZW50IHRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3Nh Z2UgZm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0byB0aGUgTEZCcyB0aGF0IHdpbGwgcmVjZWl2 ZSB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLCBidXQgdGhlIHF1ZXN0aW9uIGlzLCB3aGF0IHRoZSBQ YXRoIGluIHRoZSBtZXNzYWdlIHJlZmVycyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbHNvIGhhcHBl bnMgdG8gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0byBGRS4NCg0KVGhhbmtzLA0K V2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkF2cmkgRG9y aWEiIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNP RlQuQ09NPg0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMDUgMjozNSBBTQ0KU3ViamVjdDogW2lz c3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3Jp YSA8YXZyaUBhY20ub3JnPjoNCg0KNi44DQoNCiBFZGl0b3JpYWwgTm90ZTogIFRoZXJlIGFyZSBh bHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZGVsDQogICAgICAgICAgICAgICAg ICAgIHRoYXQgYXJlIHJlbGF0ZWQgdG8gcGFja2V0IHJlZGlyZWN0IG9wZXJhdGlvbnMNCiAgICAg ICAgICAgICAgICAgICAgc2hvdWxkIGJlIGRlZmluZWQuICBBbHRob3VnaCBpdCBpcyBvdXQgb2Yg dGhlIHNjb3BlDQogICAgICAgICAgICAgICAgICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRv IGRlZmluZSB0aGUgTEZCcyBhZmZlY3QNCiAgICAgICAgICAgICAgICAgICAgdGhlIFBhY2tldCBS ZWRpcmVjdCBNZXNzYWdlIGRlc2NyaWJlZCBoZXJlLiAgQmVjYXVzZQ0KICAgICAgICAgICAgICAg ICAgICBjdXJyZW50bHkgaXQgaXMgc3RpbGwgaW4gcHJvZ3Jlc3MgaW4gRkUgbW9kZWwgb24gaG93 DQogICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3N0 IHNvbWUgdGhvdWdodHMgb24NCiAgICAgICAgICAgICAgICAgICAgdGhpcyBoZXJlIGZvciBkaXNj dXNzaW9uLiAgVGhleSB3aWxsIGJlIHJlbW92ZWQNCiAgICAgICAgICAgICAgICAgICAgbGF0ZXIg YWxvbmcgd2l0aCB0aGUgcHJvZ3Jlc3Mgb2YgdGhlIEZFIG1vZGVsIHdvcmsuDQogICAgICAgIFRo b3VnaHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBhbmQNCiAgICAg ICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBmb3IgcGFja2V0IHJlZGlyZWN0Lg0KICAgICAg ICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFNpbmsnIGlzIHJlc3Bv bnNpYmxlIHRvDQogICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBwYWNrZXRzIHRoYXQg bmVlZCB0byBiZSByZWRpcmVjdGVkIHRvDQogICAgICAgICAgICAgICAgICAgIENFLiAgRnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgdGhlIEZFIExGQiB0b3BvbG9neSwNCiAgICAgICAgICAgICAgICAg ICAgdGhlICdSZWRpcmVjdFNpbmsnIExGQiBpcyBhbiBMRkIgd2l0aCBvbmx5IG9uZSBpbnB1dA0K ICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRob3V0IGFueSBvdXRwdXQgcG9ydCwgYW5k IHRoZSBpbnB1dCBwb3J0DQogICAgICAgICAgICAgICAgICAgIGNhbiB0aGVuIGJlIGNvbm5lY3Rl ZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsDQogICAgICAgICAgICAgICAgICAgIGJ5IG1l YW5zIG9mIGEgZGF0YXBhdGggaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuDQogICAgICAgICAgICAg ICAgICAgIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIs DQogICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0 ZSB0aGUgUGFja2V0DQogICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0IE1lc3NhZ2VzIHdoZW4g aXQgcmVjZWl2ZXMgZGF0YSBwYWNrZXRzIGZyb20NCiAgICAgICAgICAgICAgICAgICAgZm9yd2Fy ZGluZyBwbGFuZS4NCg0KICAgICAgICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdS ZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8NCiAgICAgICAgICAgICAgICAgICAgcmVjZWl2 ZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLg0KICAgICAgICAgICAg ICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LCB0aGUN CiAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25s eSBvbmUgb3V0cHV0DQogICAgICAgICAgICAgICAgICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IGlu cHV0IHBvcnQsIGFuZCB0aGUgb3V0cHV0IHBvcnQNCiAgICAgICAgICAgICAgICAgICAgY2FuIHRo ZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZWwNCiAgICAgICAgICAg ICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4N CiAgICAgICAgICAgICAgICAgICAgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgRm9yQ0VTIHByb3Rv Y29sIGxheWVyLCB0aGUNCiAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2Fu IHJlY2VpdmUgdGhlIFBhY2tldCBSZWRpcmVjdA0KICAgICAgICAgICAgICAgICAgICBNZXNzYWdl cyBmcm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGENCiAgICAgICAgICAgICAgICAg ICAgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byBkYXRhcGF0aHMNCiAg ICAgICAgICAgICAgICAgICAgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aGUg J1JlY2lyZWN0VGFwJw0KICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0 cmFuc2NvZGVyIHRoYXQgdHJhbnNmZXJzIHRoZQ0KICAgICAgICAgICAgICAgICAgICBGb3JDRVMg cHJvdG9jb2wgbWVzc2FnZXMgdG8gbm9ybWFsIGRhdGEgcGFja2V0cyBpbg0KICAgICAgICAgICAg ICAgICAgICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQXMgYSByZXN1bHQsIGlmIHdlIG5lZWQgdG8N CiAgICAgICAgICAgICAgICAgICAgaGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRv IHNvbWUgTEZCIChzYXkgYQ0KICAgICAgICAgICAgICAgICAgICBTY2hlZHVsZXIpIGluIEZFIG1v ZGVsLCB3ZSBvbmx5IG5lZWQgdG8gY29ubmVjdCB0aGUNCiAgICAgICAgICAgICAgICAgICAgJ1Jl ZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiBkaXJlY3RseSB2aWEgYQ0KICAgICAg ICAgICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVkaXJlY3RUYXAgTEZCIHwtLS0tLS0+fCAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0r ICAgICAgIHwgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IFNjaGVkdWxlciB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGcm9tIG90aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MjcNCg0KICAgICAgICAgICAgICAgICAgICBCeSB1c2Ugb2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5r JyBMRkJzIGFuZCBzZXZlcmFsDQogICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZC cyB0aGF0IGNvbm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQNCiAgICAgICAgICAgICAgICAgICAg ZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBhY2tldA0KICAgICAg ICAgICAgICAgICAgICByZWRpcmVjdCBwYXRocyBiZXR3ZWVuIENFIGFuZCBGRSBjYW4gYmUgY29u c3RydWN0ZWQuDQoNCiAgICAgICAgVGhvdWdodCAyOiAgVGhlcmUgbWlnaHQgYmUgYW5vdGhlciB3 YXkgYSBwYWNrZXQgY291bGQgYmUNCiAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3RlZDogZGly ZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgsIGUuZy4sIGJ5DQogICAgICAgICAgICAgICAgICAg IEZQR0EvQVNJQy9OUCBtaWNyb2NvZGUuICBJbiBzdWNoIGEgY2FzZSB3ZSBkbyBub3QNCiAgICAg ICAgICAgICAgICAgICAgbmVlZCB0byBwdXQgaW4gYSBsb3Qgb2Ygc21hcnRuZXNzLiAgUHJvYmFi bHkgYSBsaW5rDQogICAgICAgICAgICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZl bCBoZWFkZXIgaXMgZW5vdWdoLiAgVGhlDQogICAgICAgICAgICAgICAgICAgIHJlY2VpdmVyIGRl bXV4ZXMgaXQgb25seSBiYXNlZCBvbiBzb21lIHByb3RvY29sIHR5cGUNCiAgICAgICAgICAgICAg ICAgICAgaW4gdGhlIGxpbmsgbGF5ZXIgb3IgbmV0d29yayB0cmFuc3BvcnQgbGF5ZXIuICBUaGUN CiAgICAgICAgICAgICAgICAgICAgcHJvcyBmb3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgcHJv dmlkZSBhIGZhc3QgYW5kDQogICAgICAgICAgICAgICAgICAgIGNvc3QtZWZmZWN0aXZlIHBhdGgg Zm9yIHBhY2tldCByZWRpcmVjdC4gIFRoZSBjb25zDQogICAgICAgICAgICAgICAgICAgIGZvciB0 aGlzIGlzIGl0IG1heSBtb3JlIG9yIGxlc3MgY29uZnVzZXMgdGhlIEZwDQogICAgICAgICAgICAg ICAgICAgIHJlZmVyZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuDQoN Ci0tLS0tLS0tLS0NCmNhdGVnb3J5OiBFZGl0b3JpYWwNCmRyYWZ0OiBkcmFmdC1pZXRmLWZvcmNl cy1wcm90b2NvbA0KbWVzc2FnZXM6IDQ5DQpub3N5OiBhdnJpDQpwcmlvcml0eTogTXVzdCBmaXgN CnN0YXR1czogTm8gZGlzY3Vzc2lvbg0KdGl0bGU6IFBhY2tldCBSZWRpcmVjdA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZvcmNlcyBpc3N1 ZSB0cmFja2VyIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCjxodHRwOi8vd3d3Lm1pcDQub3Jn L2lzc3Vlcy90cmFja2VyL2ZvcmNlcy9pc3N1ZTMyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= From owner-forces@PEACH.EASE.LSOFT.COM Sat Jun 25 23:42:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmO2Q-0001ZH-7h for forces-archive@megatron.ietf.org; Sat, 25 Jun 2005 23:42:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02209 for ; Sat, 25 Jun 2005 23:42:27 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmORI-0000Qu-01 for forces-archive@IETF.ORG; Sun, 26 Jun 2005 00:08:12 -0400 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.0108EACE@cherry.ease.lsoft.com>; Sat, 25 Jun 2005 23:42:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76847611 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 25 Jun 2005 23:42:21 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 25 Jun 2005 23:42:20 -0400 Received: from [69.170.1.53] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11109793; Sat, 25 Jun 2005 23:42:21 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786905.33.0.544707347688.issue32@mip4.org> <004b01c579f9$d5fb21f0$020aa8c0@wwm1> 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.20050625233944.02eccfe0@localhost> Date: Sat, 25 Jun 2005 23:42:18 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004b01c579f9$d5fb21f0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 I am missign something in your suggestion. Why would we want to treat redirects as events? We should treat them as redirects. I am very confused about "How a path should be defined in a Packet Redirect Message", since as far as I can tell, a redirect does not need a path. It needs a collection of meta-information, which we need to define. At the moment, that has to include at least the LFB ID that the redirect is from / to. I suppose by declaring a multiplicity of such LFBs, that can be all of the information. (I usually think in terms of at least a logical port ID the packet came from / is intended for.) Yours, Joel At 10:50 PM 6/25/2005, Weiming Wang wrote: >Jamal, Joel, and Hormzd, > >I suppose we could close this issue by reaching the following points: > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are >moved to the model, but the protocol retains the Redirect Message. The >reason to keep the specific message is we need to specifically recognize >redirected data between CE-FE transportation to avoid DoS attacks. > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL >events in that: > a. The event is triggered every time a new redirected packet arrives > at the LFBs. > b. The event is transported by the Redirect Message only, while the > Redirect Message will the same message format as a general event > notification message (except the message type in the header). > >By doing in this way, we can also solve the issue53 (How a path should be >defined in Packet Redirect Message) then. > >Unfortunately, I think of another question that is related to the Packet >Redirect Message as well as to Event Notification Message. The question >is, the Event Notification Message allows event generated by CE and sent >to FE. In the case, in the message format, the LFB IDs refer to the LFBs >that will receive the event notification, but the question is, what the >Path in the message refers to then ?? The same also happens to Packet >Redirect Message from CE to FE. > >Thanks, >Weiming > >----- Original Message ----- >From: "Avri Doria" >To: >Sent: Monday, May 23, 2005 2:35 AM >Subject: [issue32] Packet Redirect > > >New submission from Avri Doria : > >6.8 > > Editorial Note: There are also discussions on how LFBs in FE model > that are related to packet redirect operations > should be defined. Although it is out of the scope > of forces protocol, how to define the LFBs affect > the Packet Redirect Message described here. Because > currently it is still in progress in FE model on how > to define such LFBs, we try to post some thoughts on > this here for discussion. They will be removed > later along with the progress of the FE model work. > Thought 1: To define LFBs called 'RedirectSink' and > 'RedirectTap' for packet redirect. > An LFB in FE called 'RedirectSink' is responsible to > collect data packets that need to be redirected to > CE. From the perspective of the FE LFB topology, > the 'RedirectSink' LFB is an LFB with only one input > port and without any output port, and the input port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of the ForCES protocol layer, > the 'RedirectSink' LFB will generate the Packet > Redirect Messages when it receives data packets from > forwarding plane. > > An LFB in FE called 'RedirectTap' is responsible to > receive data packets that are redirected from CE. > From the perspective of the FE LFB topology, the > 'RedirectTap' LFB is an LFB with only one output > port and without any input port, and the output port > can then be connected to any other LFB in FE model > by means of a datapath in the forwarding plane. > From the perspective of ForCES protocol layer, the > 'RedirectTap' LFB can receive the Packet Redirect > Messages from CE, and un-encapsulate the data > packets from the message and put them to datapaths > in the forwarding plane. Actually the 'RecirectTap' > LFB acts more like a transcoder that transfers the > ForCES protocol messages to normal data packets in > IP forwarding plane. As a result, if we need to > have redirected packets connected to some LFB (say a > Scheduler) in FE model, we only need to connect the > 'RedirectTap LFB to the Scheduler LFB directly via a > datapath as follows: > > > +-----------------+ +-----------+ > | RedirectTap LFB |------>| | > +-----------------+ | | > | Scheduler | > From other LFB ---->| LFB | > | | > +-----------+ > > Figure 27 > > By use of several 'RedirectSink' LFBs and several > 'RedirectTap' LFBs that connect to several different > datapaths in FE forwarding plane, multiple packet > redirect paths between CE and FE can be constructed. > > Thought 2: There might be another way a packet could be > redirected: directly by a forwarding path, e.g., by > FPGA/ASIC/NP microcode. In such a case we do not > need to put in a lot of smartness. Probably a link > layer or even network level header is enough. The > receiver demuxes it only based on some protocol type > in the link layer or network transport layer. The > pros for this appraoch is it may provide a fast and > cost-effective path for packet redirect. The cons > for this is it may more or less confuses the Fp > reference point definition in ForCES framework. > >---------- >category: Editorial >draft: draft-ietf-forces-protocol >messages: 49 >nosy: avri >priority: Must fix >status: No discussion >title: Packet Redirect > >___________________________________________________ >Forces issue tracker > >___________________________________________________ From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 26 12:33:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dma4u-0006By-Of for forces-archive@megatron.ietf.org; Sun, 26 Jun 2005 12:33:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13101 for ; Sun, 26 Jun 2005 12:09:00 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmQHI-0003QH-1b for forces-archive@IETF.ORG; Sun, 26 Jun 2005 02:06:04 -0400 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.0108EE78@cherry.ease.lsoft.com>; 26 Jun 2005 1:40:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76853927 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 26 Jun 2005 01:40:13 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 26 Jun 2005 01:40:11 -0400 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 j5Q5eCmC012499; Sun, 26 Jun 2005 05:40:12 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 j5Q5e7YQ028169; Sun, 26 Jun 2005 05:40:12 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 M2005062522401231162 ; Sat, 25 Jun 2005 22:40:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Jun 2005 22:40:12 -0700 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] [issue32] Packet Redirect Thread-Index: AcV6ARHrwYk3gwUQS0mXlpisEVSfPgAD++0g X-OriginalArrivalTime: 26 Jun 2005 05:40:12.0361 (UTC) FILETIME=[858D9B90:01C57A11] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05C9F7D2@orsmsx408> Date: Sat, 25 Jun 2005 22:40:10 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect 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, -----Original Message----- From: Forwarding and Control Element Separation=20 I am missign something in your suggestion. Why would we want to treat redirects as events? We should treat them as redirects. [HK] This seems like a terminology issue...but I think Weiming means the same thing. I am very confused about "How a path should be defined in a Packet Redirect=20 Message", since as far as I can tell, a redirect does not need a path. It=20 needs a collection of meta-information, which we need to define. At the moment, that has to include at least the LFB ID that the redirect is from /=20 to. I suppose by declaring a multiplicity of such LFBs, that can be all of=20 the information. (I usually think in terms of at least a logical port ID=20 the packet came from / is intended for.) [HK] I agree, we don't need a path for Packet Redirect message, Regards Hormuzd At 10:50 PM 6/25/2005, Weiming Wang wrote: >Jamal, Joel, and Hormzd, > >I suppose we could close this issue by reaching the following points: > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are=20 >moved to the model, but the protocol retains the Redirect Message. The=20 >reason to keep the specific message is we need to specifically recognize=20 >redirected data between CE-FE transportation to avoid DoS attacks. > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL=20 >events in that: > a. The event is triggered every time a new redirected packet arrives=20 > at the LFBs. > b. The event is transported by the Redirect Message only, while the=20 > Redirect Message will the same message format as a general event=20 > notification message (except the message type in the header). > >By doing in this way, we can also solve the issue53 (How a path should be=20 >defined in Packet Redirect Message) then. > >Unfortunately, I think of another question that is related to the Packet=20 >Redirect Message as well as to Event Notification Message. The question >is, the Event Notification Message allows event generated by CE and sent=20 >to FE. In the case, in the message format, the LFB IDs refer to the LFBs=20 >that will receive the event notification, but the question is, what the >Path in the message refers to then ?? The same also happens to Packet=20 >Redirect Message from CE to FE. > >Thanks, >Weiming > From owner-forces@PEACH.EASE.LSOFT.COM Sun Jun 26 12:35:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dma66-0006bg-6H for forces-archive@megatron.ietf.org; Sun, 26 Jun 2005 12:35:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06327 for ; Sun, 26 Jun 2005 11:59:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmXv2-00037s-2z for forces-archive@IETF.ORG; Sun, 26 Jun 2005 10:15:35 -0400 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.0108EFD9@cherry.ease.lsoft.com>; 26 Jun 2005 9:49:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 76906856 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 26 Jun 2005 09:49:23 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 26 Jun 2005 09:49:22 -0400 Received: from [69.170.1.53] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11116996 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 26 Jun 2005 09:49:24 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786905.33.0.544707347688.issue32@mip4.org> <004b01c579f9$d5fb21f0$020aa8c0@wwm1> <6.2.1.2.0.20050625233944.02eccfe0@localhost> <109201c57a2b$79b0f5f0$1152010a@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.1.2.0.20050626094409.02ec5e18@localhost> Date: Sun, 26 Jun 2005 09:49:21 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <109201c57a2b$79b0f5f0$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 I would expect that a Redirect Message has a different outermost TLV. The grammar is intended to help us, not serve as a straightjacket. Different message types can have different outer TLVs. It is desirable to use the same structure when it applies. But the redirect message is simply a different case. It's contents are not a DATARAW much less a DATA TLV. Its content structure is not defined by an LFB element definition or Model DataDefs structure definition. If we need to fix the "grammar" section to make it clear that not all PL messages necessarily use the same outermost TLV, we should do so. My own approach would be to separate the grammar into a definition of the contents of that TLV, and a separate definition of which TLVs / content are carried in the outermost level of which messages. Yours, Joel PS: Weiming, I am sorry you got caught up in this confusion. I don't think you created the tendency I am railing against above. I am just using your message as a starting point to hammer home a point. At 04:45 AM 6/26/2005, Wang,Weiming wrote: >Maybe it's me who missed something :) >My thought was we might need to obey our message grammar well that we have >to use a strict Path-data for operation TLV. To obey the rule, treating >it as an event will ease the message format greatly. > >Actually I'm very happy to see that you agree a path can be omitted for >some specific messages like redirect messge. > >OK, let's solve it then, to let redirect message only contain Data >field? I can update this redirect message part text then. > >Jamal, could you give a response on this? > >One less vital question is, shall we allow for mulitpul redirect packets >encapsulated in one TLV or just one TLV only for one packet? To use the >former, we have to define a sequence for the redirected packets then in >the TLV. > >On the meta-information related, I think LFB IDs has already been >included. I don't think we need an extra port ID to indicate where to put >the redirected data to or to get redirected data from. A redirect source >LFB or sink LFB will have a port ID, which belongs to FE LFB topology >concept, and FE LFB topolgy configuration is in charge of this. Not sure >if it complies with your thought? > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Re: [issue32] Packet Redirect > > > > I am missign something in your suggestion. > > > > Why would we want to treat redirects as events? > > We should treat them as redirects. > > > > I am very confused about "How a path should be defined in a Packet > Redirect > > Message", since as far as I can tell, a redirect does not need a path. It > > needs a collection of meta-information, which we need to define. At the > > moment, that has to include at least the LFB ID that the redirect is > from / > > to. I suppose by declaring a multiplicity of such LFBs, that can be > all of > > the information. (I usually think in terms of at least a logical port ID > > the packet came from / is intended for.) > > > > Yours, > > Joel > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > >Jamal, Joel, and Hormzd, > > > > > >I suppose we could close this issue by reaching the following points: > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink LFB are > > >moved to the model, but the protocol retains the Redirect Message. The > > >reason to keep the specific message is we need to specifically recognize > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL > > >events in that: > > > a. The event is triggered every time a new redirected packet > arrives > > > at the LFBs. > > > b. The event is transported by the Redirect Message only, while > the > > > Redirect Message will the same message format as a general event > > > notification message (except the message type in the header). > > > > > >By doing in this way, we can also solve the issue53 (How a path should be > > >defined in Packet Redirect Message) then. > > > > > >Unfortunately, I think of another question that is related to the Packet > > >Redirect Message as well as to Event Notification Message. The question > > >is, the Event Notification Message allows event generated by CE and sent > > >to FE. In the case, in the message format, the LFB IDs refer to the LFBs > > >that will receive the event notification, but the question is, what the > > >Path in the message refers to then ?? The same also happens to Packet > > >Redirect Message from CE to FE. > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Avri Doria" > > >To: > > >Sent: Monday, May 23, 2005 2:35 AM > > >Subject: [issue32] Packet Redirect > > > > > > > > >New submission from Avri Doria : > > > > > >6.8 > > > > > > Editorial Note: There are also discussions on how LFBs in FE model > > > that are related to packet redirect operations > > > should be defined. Although it is out of the scope > > > of forces protocol, how to define the LFBs affect > > > the Packet Redirect Message described here. Because > > > currently it is still in progress in FE model on how > > > to define such LFBs, we try to post some thoughts on > > > this here for discussion. They will be removed > > > later along with the progress of the FE model work. > > > Thought 1: To define LFBs called 'RedirectSink' and > > > 'RedirectTap' for packet redirect. > > > An LFB in FE called 'RedirectSink' is responsible to > > > collect data packets that need to be redirected to > > > CE. From the perspective of the FE LFB topology, > > > the 'RedirectSink' LFB is an LFB with only one input > > > port and without any output port, and the input port > > > can then be connected to any other LFB in FE model > > > by means of a datapath in the forwarding plane. > > > From the perspective of the ForCES protocol layer, > > > the 'RedirectSink' LFB will generate the Packet > > > Redirect Messages when it receives data packets from > > > forwarding plane. > > > > > > An LFB in FE called 'RedirectTap' is responsible to > > > receive data packets that are redirected from CE. > > > From the perspective of the FE LFB topology, the > > > 'RedirectTap' LFB is an LFB with only one output > > > port and without any input port, and the output port > > > can then be connected to any other LFB in FE model > > > by means of a datapath in the forwarding plane. > > > From the perspective of ForCES protocol layer, the > > > 'RedirectTap' LFB can receive the Packet Redirect > > > Messages from CE, and un-encapsulate the data > > > packets from the message and put them to datapaths > > > in the forwarding plane. Actually the 'RecirectTap' > > > LFB acts more like a transcoder that transfers the > > > ForCES protocol messages to normal data packets in > > > IP forwarding plane. As a result, if we need to > > > have redirected packets connected to some LFB (say a > > > Scheduler) in FE model, we only need to connect the > > > 'RedirectTap LFB to the Scheduler LFB directly via a > > > datapath as follows: > > > > > > > > > +-----------------+ +-----------+ > > > | RedirectTap LFB |------>| | > > > +-----------------+ | | > > > | Scheduler | > > > From other LFB ---->| LFB | > > > | | > > > +-----------+ > > > > > > Figure 27 > > > > > > By use of several 'RedirectSink' LFBs and several > > > 'RedirectTap' LFBs that connect to several different > > > datapaths in FE forwarding plane, multiple packet > > > redirect paths between CE and FE can be constructed. > > > > > > Thought 2: There might be another way a packet could be > > > redirected: directly by a forwarding path, e.g., by > > > FPGA/ASIC/NP microcode. In such a case we do not > > > need to put in a lot of smartness. Probably a link > > > layer or even network level header is enough. The > > > receiver demuxes it only based on some protocol type > > > in the link layer or network transport layer. The > > > pros for this appraoch is it may provide a fast and > > > cost-effective path for packet redirect. The cons > > > for this is it may more or less confuses the Fp > > > reference point definition in ForCES framework. > > > > > >---------- > > >category: Editorial > > >draft: draft-ietf-forces-protocol > > >messages: 49 > > >nosy: avri > > >priority: Must fix > > >status: No discussion > > >title: Packet Redirect > > > > > >___________________________________________________ > > >Forces issue tracker > > > > > >___________________________________________________ > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 10:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuBF-0000i4-SI for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 10:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22906 for ; Mon, 27 Jun 2005 10:01:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmuaD-0003rd-9z for forces-archive@IETF.ORG; Mon, 27 Jun 2005 10:27:46 -0400 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.0108FF57@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 10:01:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77017525 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 10:01:18 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 10:01:14 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Mon, 27 Jun 2005 22:37:39 +0800 (CST) References: <1116786905.33.0.544707347688.issue32@mip4.org> <004b01c579f9$d5fb21f0$020aa8c0@wwm1> <6.2.1.2.0.20050625233944.02eccfe0@localhost> <109201c57a2b$79b0f5f0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050626094409.02ec5e18@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C57B63.BA753770" 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: <000c01c57b20$acce0540$020aa8c0@wwm1> Date: Mon, 27 Jun 2005 22:01:10 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 3.3 (+++) X-Scan-Signature: be1e5ad20f6e15b349a42c2dfbdd71ac This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C57B63.BA753770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCA6KQ0KDQpIb3cgYWJvdXQgd2UganVzdCBvYnNvbGV0ZSB0aGUgcGF0aCBmcm9tIHRoZSBk YXRhIHN0cnVjdHVyZSBhbmQgYWRkIHNvbWUgDQptZXRhLWluZm9ybWF0aW9uLCBhbmQgZm9ybSB0 aGUgZm9ybWF0IGFzIGJlbG93IChJIGN1cnJlbnRseSBjYW4gb25seSB0aGluayANCm9mIHRoZSBt ZXRhLWluZm9ybWF0aW9uIGFzIHRoZSBwYWNrZXQgdHlwZS4gV2UgbWF5IGFkZCBzb21lIG1vcmUg bGF0ZXIpLg0KDQpDb3VsZCB5b3UgZ2l2ZSBtb3JlIGNvbW1lbnRzIG9uIHRoaXMsIHRoZW4gd2Ug bWF5IHNvbHZlIHRoaXMgaXNzdWUgc29vbj8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaC4NCg0KV2Vp bWluZw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk1lc3NhZ2UgQm9keToNCiAgICAgIENvbnNp c3RzIG9mIG9uZSBvciBtb3JlIFRMVnMsIHdpdGggZXZlcnkgVExWIGhhdmluZyB0aGUgZm9sbG93 aW5nDQogICAgICBkYXRhIGZvcm1hdDoNCg0KICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVjdCAgICAgICB8ICAgICAgICAgICAg ICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQiBJ bnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvbiBUTFYgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg ICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIE9wZXJhdGlvbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCiAgIExGQiBjbGFzcyBJRDoNCiAgICAgIFRo ZXJlIGFyZSBvbmx5IHR3byBwb3NzaWJsZSBMRkIgY2xhc3NlcyBoZXJlLCB0aGUgJ1JlZGlyZWN0 U2luaycNCiAgICAgIExGQiBvciB0aGUgJ1JlZGlyZWN0U291cmNlJyBMRkIuICBJZiB0aGUgbWVz c2FnZSBpcyBmcm9tIEZFIHRvIENFLA0KICAgICAgdGhlIExGQiBjbGFzcyBzaG91bGQgYmUgJ1Jl ZGlyZWN0U2luaycuICBJZiB0aGUgbWVzc2FnZSBpcyBmcm9tIENFDQogICAgICB0byBGRSwgdGhl IExGQiBjbGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0U291cmNlJy4NCiAgIEluc3RhbmNlIElEOg0K ICAgICAgSW5zdGFuY2UgSUQgZm9yIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgb3IgJ1JlZGlyZWN0 U291cmNlJyBMRkIuDQogICBPcGVyYXRpb24gVExWOg0KICAgICAgVGhpcyBpcyBhIFRMViBkZXNj cmliaW5nIG9uZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCB2aWEgdGhlDQogICAgICBz cGVjaWZpZWQgTEZCIGFib3ZlLiAgVGhlIG9yZGVyIG9mIHRoZSBUTFYgYXBwZWFyZWQgaXMgYWxz byB0aGUNCiAgICAgIG9yZGVyIHRoZSBkYXRhIHBhY2tldCBhcnJpdmVzIHRoZSByZWRpcmVjdG9y IExGQiwgdGhhdCBpcywgdGhlDQogICAgICBSZWRpcmVjdGVkIERhdGEgIGluIHRoZSBmaXJzdCBU TFYgc2hvdWxkIGFycml2ZSB0aGUgZWFybGllc3QuICANCg0KVGhlIFRMViBmb3JtYXQgaXMgYXMg Zm9sbG93czoNCiANCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfCAgICBUeXBlID0gUEFZTE9B RCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgICAgfiAgICAgICAgIFBhY2tldCBUeXBlICAgICAgICAgICB8ICAgICAg ICAgUGFja2V0IExlbmd0aCAgICAgICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgfiAg ICAgICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0ZWQgUGFja2V0ICAgICAgICAgICAgICAgICAg ICAgIH4NCiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiANCiAgICBUeXBlOg0KICAgICAgVGhlIHR5cGUgZm9y IHRoZSBUTFYgaXMgc2V0IHRvICdQQVlMT0FEJy4gDQoNCiAgICBMZW5ndGg6DQogICAgICB0aGUg bGVuZ3RoIG9mIHRoZSBUTFYoaW4gNGJ5dGVzKS4NCg0KICAgIFBhY2tldCBUeXBlOg0KICAgICAg RGVmaW5lcyB3aGF0IHR5cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaCBh cyAnSVB2NCBQYWNrZXQnLA0KICAgICAnSVB2NiBQYWNrZXQnKS4gICAgDQoNCiAgICBQYWNrZXQg TGVuZ3RoOg0KICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgZm9sbG93ZWQgcmVkaXJlY3RlZCBwYWNr ZXQgKGluIGJ5dGUpDQoNCiAgICBSZWRpcmVjdGVkIFBhY2tldDoNCiAgICAgIG9uZSByZWRpcmVj dGVkIHBhY2tldC4gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3Rl dmVjcm9ja2VyLmNvbT4NCg0KDQo+IEkgd291bGQgZXhwZWN0IHRoYXQgYSBSZWRpcmVjdCBNZXNz YWdlIGhhcyBhIGRpZmZlcmVudCBvdXRlcm1vc3QgVExWLiAgVGhlIA0KPiBncmFtbWFyIGlzIGlu dGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcyBhIHN0cmFpZ2h0amFja2V0LiAgRGlmZmVy ZW50IA0KPiBtZXNzYWdlIHR5cGVzIGNhbiBoYXZlIGRpZmZlcmVudCBvdXRlciBUTFZzLiAgSXQg aXMgZGVzaXJhYmxlIHRvIHVzZSB0aGUgDQo+IHNhbWUgc3RydWN0dXJlIHdoZW4gaXQgYXBwbGll cy4gIEJ1dCB0aGUgcmVkaXJlY3QgbWVzc2FnZSBpcyBzaW1wbHkgYSANCj4gZGlmZmVyZW50IGNh c2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQVRBUkFXIG11Y2ggbGVzcyBhIERBVEEgVExW LiAgSXRzIA0KPiBjb250ZW50IHN0cnVjdHVyZSBpcyBub3QgZGVmaW5lZCBieSBhbiBMRkIgZWxl bWVudCBkZWZpbml0aW9uIG9yIE1vZGVsIA0KPiBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdGlv bi4NCj4gDQo+IElmIHdlIG5lZWQgdG8gZml4IHRoZSAiZ3JhbW1hciIgc2VjdGlvbiB0byBtYWtl IGl0IGNsZWFyIHRoYXQgbm90IGFsbCBQTCANCj4gbWVzc2FnZXMgbmVjZXNzYXJpbHkgdXNlIHRo ZSBzYW1lIG91dGVybW9zdCBUTFYsIHdlIHNob3VsZCBkbyBzby4gICBNeSBvd24gDQo+IGFwcHJv YWNoIHdvdWxkIGJlIHRvIHNlcGFyYXRlIHRoZSBncmFtbWFyIGludG8gYSBkZWZpbml0aW9uIG9m IHRoZSBjb250ZW50cyANCj4gb2YgdGhhdCBUTFYsIGFuZCBhIHNlcGFyYXRlIGRlZmluaXRpb24g b2Ygd2hpY2ggVExWcyAvIGNvbnRlbnQgYXJlIGNhcnJpZWQgDQo+IGluIHRoZSBvdXRlcm1vc3Qg bGV2ZWwgb2Ygd2hpY2ggbWVzc2FnZXMuDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gUFM6 IFdlaW1pbmcsIEkgYW0gc29ycnkgeW91IGdvdCBjYXVnaHQgdXAgaW4gdGhpcyBjb25mdXNpb24u ICBJIGRvbid0IHRoaW5rIA0KPiB5b3UgY3JlYXRlZCB0aGUgdGVuZGVuY3kgSSBhbSByYWlsaW5n IGFnYWluc3QgYWJvdmUuICBJIGFtIGp1c3QgdXNpbmcgeW91ciANCj4gbWVzc2FnZSBhcyBhIHN0 YXJ0aW5nIHBvaW50IHRvIGhhbW1lciBob21lIGEgcG9pbnQuDQo+IA0KPiBBdCAwNDo0NSBBTSA2 LzI2LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPk1heWJlIGl0J3MgbWUgd2hvIG1pc3Nl ZCBzb21ldGhpbmcgOikNCj4gPk15IHRob3VnaHQgd2FzIHdlIG1pZ2h0IG5lZWQgdG8gb2JleSBv dXIgbWVzc2FnZSBncmFtbWFyIHdlbGwgdGhhdCB3ZSBoYXZlIA0KPiA+dG8gdXNlIGEgc3RyaWN0 IFBhdGgtZGF0YSBmb3Igb3BlcmF0aW9uIFRMVi4gIFRvIG9iZXkgdGhlIHJ1bGUsIHRyZWF0aW5n IA0KPiA+aXQgYXMgYW4gZXZlbnQgd2lsbCBlYXNlIHRoZSBtZXNzYWdlIGZvcm1hdCBncmVhdGx5 Lg0KPiA+DQo+ID5BY3R1YWxseSBJJ20gdmVyeSBoYXBweSB0byBzZWUgdGhhdCB5b3UgYWdyZWUg YSBwYXRoIGNhbiBiZSBvbWl0dGVkIGZvciANCj4gPnNvbWUgc3BlY2lmaWMgbWVzc2FnZXMgbGlr ZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4NCj4gPk9LLCBsZXQncyBzb2x2ZSBpdCB0aGVuLCB0byBs ZXQgcmVkaXJlY3QgbWVzc2FnZSBvbmx5IGNvbnRhaW4gRGF0YSANCj4gPmZpZWxkPyAgSSBjYW4g dXBkYXRlIHRoaXMgcmVkaXJlY3QgbWVzc2FnZSBwYXJ0IHRleHQgdGhlbi4NCj4gPg0KPiA+SmFt YWwsIGNvdWxkIHlvdSBnaXZlIGEgcmVzcG9uc2Ugb24gdGhpcz8NCj4gPg0KPiA+T25lICBsZXNz IHZpdGFsIHF1ZXN0aW9uIGlzLCBzaGFsbCB3ZSBhbGxvdyBmb3IgbXVsaXRwdWwgcmVkaXJlY3Qg cGFja2V0cyANCj4gPmVuY2Fwc3VsYXRlZCBpbiBvbmUgVExWIG9yIGp1c3Qgb25lIFRMViBvbmx5 IGZvciBvbmUgcGFja2V0PyBUbyB1c2UgdGhlIA0KPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmlu ZSBhIHNlcXVlbmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4gDQo+ID50aGUg VExWLg0KPiA+DQo+ID5PbiAgdGhlIG1ldGEtaW5mb3JtYXRpb24gcmVsYXRlZCwgSSB0aGluayBM RkIgSURzIGhhcyBhbHJlYWR5IGJlZW4gDQo+ID5pbmNsdWRlZC4gSSBkb24ndCB0aGluayB3ZSBu ZWVkIGFuIGV4dHJhIHBvcnQgSUQgdG8gaW5kaWNhdGUgd2hlcmUgdG8gcHV0IA0KPiA+dGhlIHJl ZGlyZWN0ZWQgZGF0YSB0byBvciB0byBnZXQgcmVkaXJlY3RlZCBkYXRhIGZyb20uIEEgcmVkaXJl Y3Qgc291cmNlIA0KPiA+TEZCICBvciBzaW5rIExGQiB3aWxsICBoYXZlIGEgcG9ydCBJRCwgd2hp Y2ggYmVsb25ncyB0byBGRSBMRkIgdG9wb2xvZ3kgDQo+ID5jb25jZXB0LCBhbmQgRkUgTEZCIHRv cG9sZ3kgY29uZmlndXJhdGlvbiBpcyBpbiBjaGFyZ2Ugb2YgdGhpcy4gIE5vdCBzdXJlIA0KPiA+ aWYgaXQgY29tcGxpZXMgd2l0aCB5b3VyIHRob3VnaHQ/DQo+ID4NCj4gPlRoYW5rcywNCj4gPldl aW1pbmcNCj4gPg0KPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+RnJvbTogIkpv ZWwgTS4gSGFscGVybiINCj4gPlN1YmplY3Q6IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZWN0 DQo+ID4NCj4gPg0KPiA+ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3Rp b24uDQo+ID4gPg0KPiA+ID4gV2h5IHdvdWxkIHdlIHdhbnQgdG8gdHJlYXQgcmVkaXJlY3RzIGFz IGV2ZW50cz8NCj4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGlyZWN0cy4NCj4gPiA+ DQo+ID4gPiBJIGFtIHZlcnkgY29uZnVzZWQgYWJvdXQgIkhvdyBhIHBhdGggc2hvdWxkIGJlIGRl ZmluZWQgaW4gYSBQYWNrZXQgDQo+ID4gUmVkaXJlY3QNCj4gPiA+IE1lc3NhZ2UiLCBzaW5jZSBh cyBmYXIgYXMgSSBjYW4gdGVsbCwgYSByZWRpcmVjdCBkb2VzIG5vdCBuZWVkIGEgcGF0aC4gIEl0 DQo+ID4gPiBuZWVkcyBhIGNvbGxlY3Rpb24gb2YgbWV0YS1pbmZvcm1hdGlvbiwgd2hpY2ggd2Ug bmVlZCB0byBkZWZpbmUuICBBdCB0aGUNCj4gPiA+IG1vbWVudCwgdGhhdCBoYXMgdG8gaW5jbHVk ZSBhdCBsZWFzdCB0aGUgTEZCIElEIHRoYXQgdGhlIHJlZGlyZWN0IGlzIA0KPiA+IGZyb20gLw0K PiA+ID4gdG8uICBJIHN1cHBvc2UgYnkgZGVjbGFyaW5nIGEgbXVsdGlwbGljaXR5IG9mIHN1Y2gg TEZCcywgdGhhdCBjYW4gYmUgDQo+ID4gYWxsIG9mDQo+ID4gPiB0aGUgaW5mb3JtYXRpb24uICAo SSB1c3VhbGx5IHRoaW5rIGluIHRlcm1zIG9mIGF0IGxlYXN0IGEgbG9naWNhbCBwb3J0IElEDQo+ ID4gPiB0aGUgcGFja2V0IGNhbWUgZnJvbSAvIGlzIGludGVuZGVkIGZvci4pDQo+ID4gPg0KPiA+ ID4gWW91cnMsDQo+ID4gPiBKb2VsDQo+ID4gPg0KPiA+ID4gQXQgMTA6NTAgUE0gNi8yNS8yMDA1 LCBXZWltaW5nIFdhbmcgd3JvdGU6DQo+ID4gPiA+SmFtYWwsIEpvZWwsIGFuZCBIb3JtemQsDQo+ ID4gPiA+DQo+ID4gPiA+SSBzdXBwb3NlIHdlIGNvdWxkIGNsb3NlIHRoaXMgaXNzdWUgYnkgcmVh Y2hpbmcgdGhlIGZvbGxvd2luZyBwb2ludHM6DQo+ID4gPiA+DQo+ID4gPiA+MS4gVGhlIHJlZGly ZWN0IExGQnMgY2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luayBMRkIg YXJlDQo+ID4gPiA+bW92ZWQgdG8gdGhlIG1vZGVsLCBidXQgdGhlIHByb3RvY29sIHJldGFpbnMg dGhlIFJlZGlyZWN0IE1lc3NhZ2UuIFRoZQ0KPiA+ID4gPnJlYXNvbiB0byBrZWVwIHRoZSBzcGVj aWZpYyBtZXNzYWdlIGlzIHdlIG5lZWQgdG8gc3BlY2lmaWNhbGx5IHJlY29nbml6ZQ0KPiA+ID4g PnJlZGlyZWN0ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIGF2b2lkIERv UyBhdHRhY2tzLg0KPiA+ID4gPg0KPiA+ID4gPjIuIFRoZSByZWRpcmVjdGVkIGRhdGEgaW4gdGhl IExGQnMgY2FuIGJlIHRyZWF0ZWQgYXMgYSBraW5kIG9mIFNQRUNJQUwNCj4gPiA+ID5ldmVudHMg aW4gdGhhdDoNCj4gPiA+ID4gICAgICBhLiBUaGUgZXZlbnQgaXMgdHJpZ2dlcmVkIGV2ZXJ5IHRp bWUgYSBuZXcgcmVkaXJlY3RlZCBwYWNrZXQgDQo+ID4gYXJyaXZlcw0KPiA+ID4gPiBhdCB0aGUg TEZCcy4NCj4gPiA+ID4gICAgICBiLiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIFJl ZGlyZWN0ICBNZXNzYWdlIG9ubHksIHdoaWxlIA0KPiA+IHRoZQ0KPiA+ID4gPiBSZWRpcmVjdCBN ZXNzYWdlIHdpbGwgdGhlIHNhbWUgbWVzc2FnZSBmb3JtYXQgYXMgYSBnZW5lcmFsIGV2ZW50DQo+ ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdGhlIG1lc3NhZ2UgdHlwZSBpbiB0 aGUgaGVhZGVyKS4NCj4gPiA+ID4NCj4gPiA+ID5CeSBkb2luZyBpbiB0aGlzIHdheSwgd2UgY2Fu IGFsc28gc29sdmUgdGhlIGlzc3VlNTMgKEhvdyBhIHBhdGggc2hvdWxkIGJlDQo+ID4gPiA+ZGVm aW5lZCAgaW4gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UpIHRoZW4uDQo+ID4gPiA+DQo+ID4gPiA+ VW5mb3J0dW5hdGVseSwgIEkgdGhpbmsgb2YgYW5vdGhlciBxdWVzdGlvbiB0aGF0IGlzIHJlbGF0 ZWQgdG8gdGhlIFBhY2tldA0KPiA+ID4gPlJlZGlyZWN0IE1lc3NhZ2UgYXMgd2VsbCBhcyB0byBF dmVudCBOb3RpZmljYXRpb24gTWVzc2FnZS4gVGhlIHF1ZXN0aW9uDQo+ID4gPiA+aXMsIHRoZSBF dmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbnQgZ2VuZXJhdGVkIGJ5IENFIGFu ZCBzZW50DQo+ID4gPiA+dG8gRkUuIEluIHRoZSBjYXNlLCBpbiB0aGUgbWVzc2FnZSBmb3JtYXQs IHRoZSBMRkIgSURzIHJlZmVyIHRvIHRoZSBMRkJzDQo+ID4gPiA+dGhhdCB3aWxsIHJlY2VpdmUg dGhlIGV2ZW50IG5vdGlmaWNhdGlvbiwgYnV0IHRoZSBxdWVzdGlvbiBpcywgd2hhdCB0aGUNCj4g PiA+ID5QYXRoIGluIHRoZSBtZXNzYWdlIHJlZmVycyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbHNv IGhhcHBlbnMgdG8gUGFja2V0DQo+ID4gPiA+UmVkaXJlY3QgTWVzc2FnZSBmcm9tIENFIHRvIEZF Lg0KPiA+ID4gPg0KPiA+ID4gPlRoYW5rcywNCj4gPiA+ID5XZWltaW5nDQo+ID4gPiA+DQo+ID4g PiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPkZyb206ICJBdnJpIERvcmlh IiA8dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+DQo+ID4gPiA+VG86IDxGT1JDRVNAUEVBQ0guRUFT RS5MU09GVC5DT00+DQo+ID4gPiA+U2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMDUgMjozNSBBTQ0K PiA+ID4gPlN1YmplY3Q6IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID5OZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPGF2cmlAYWNtLm9yZz46 DQo+ID4gPiA+DQo+ID4gPiA+Ni44DQo+ID4gPiA+DQo+ID4gPiA+ICBFZGl0b3JpYWwgTm90ZTog IFRoZXJlIGFyZSBhbHNvIGRpc2N1c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZGVsDQo+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgdGhhdCBhcmUgcmVsYXRlZCB0byBwYWNrZXQgcmVkaXJl Y3Qgb3BlcmF0aW9ucw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBkZWZp bmVkLiAgQWx0aG91Z2ggaXQgaXMgb3V0IG9mIHRoZSBzY29wZQ0KPiA+ID4gPiAgICAgICAgICAg ICAgICAgICAgIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRvIGRlZmluZSB0aGUgTEZCcyBhZmZl Y3QNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGUgUGFja2V0IFJlZGlyZWN0IE1lc3Nh Z2UgZGVzY3JpYmVkIGhlcmUuICBCZWNhdXNlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAg Y3VycmVudGx5IGl0IGlzIHN0aWxsIGluIHByb2dyZXNzIGluIEZFIG1vZGVsIG9uIGhvdw0KPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBw b3N0IHNvbWUgdGhvdWdodHMgb24NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGlzIGhl cmUgZm9yIGRpc2N1c3Npb24uICBUaGV5IHdpbGwgYmUgcmVtb3ZlZA0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgIGxhdGVyIGFsb25nIHdpdGggdGhlIHByb2dyZXNzIG9mIHRoZSBGRSBtb2Rl bCB3b3JrLg0KPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMTogIFRvIGRlZmluZSBMRkJzIGNhbGxl ZCAnUmVkaXJlY3RTaW5rJyBhbmQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJl Y3RUYXAnIGZvciBwYWNrZXQgcmVkaXJlY3QuDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAg QW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBpcyByZXNwb25zaWJsZSB0bw0KPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgIGNvbGxlY3QgZGF0YSBwYWNrZXRzIHRoYXQgbmVlZCB0 byBiZSByZWRpcmVjdGVkIHRvDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgQ0UuICBGcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LA0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seSBv bmUgaW5wdXQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwb3J0IGFuZCB3aXRob3V0IGFu eSBvdXRwdXQgcG9ydCwgYW5kIHRoZSBpbnB1dCBwb3J0DQo+ID4gPiA+ICAgICAgICAgICAgICAg ICAgICAgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZWwN Cj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIHRo ZSBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsDQo+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgdGhlICdSZWRpcmVjdFNpbmsnIExGQiB3aWxsIGdlbmVyYXRlIHRoZSBQ YWNrZXQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aGVu IGl0IHJlY2VpdmVzIGRhdGEgcGFja2V0cyBmcm9tDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAg ICAgZm9yd2FyZGluZyBwbGFuZS4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAg ICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8NCj4g PiA+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlIGRhdGEgcGFja2V0cyB0aGF0IGFyZSBy ZWRpcmVjdGVkIGZyb20gQ0UuDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRnJvbSB0aGUg cGVyc3BlY3RpdmUgb2YgdGhlIEZFIExGQiB0b3BvbG9neSwgdGhlDQo+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3V0 cHV0DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydCBhbmQgd2l0aG91dCBhbnkgaW5w dXQgcG9ydCwgYW5kIHRoZSBvdXRwdXQgcG9ydA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg IGNhbiB0aGVuIGJlIGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsDQo+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9y d2FyZGluZyBwbGFuZS4NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJz cGVjdGl2ZSBvZiBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsIHRoZQ0KPiA+ID4gPiAgICAgICAgICAg ICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCIGNhbiByZWNlaXZlIHRoZSBQYWNrZXQgUmVkaXJl Y3QNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcyBmcm9tIENFLCBhbmQgdW4t ZW5jYXBzdWxhdGUgdGhlIGRhdGENCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwYWNrZXRz IGZyb20gdGhlIG1lc3NhZ2UgYW5kIHB1dCB0aGVtIHRvIGRhdGFwYXRocw0KPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiAgQWN0dWFsbHkgdGhlICdS ZWNpcmVjdFRhcCcNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxp a2UgYSB0cmFuc2NvZGVyIHRoYXQgdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgIEZvckNFUyBwcm90b2NvbCBtZXNzYWdlcyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIGlu DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgSVAgZm9yd2FyZGluZyBwbGFuZS4gIEFzIGEg cmVzdWx0LCBpZiB3ZSBuZWVkIHRvDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgaGF2ZSBy ZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUgTEZCIChzYXkgYQ0KPiA+ID4gPiAg ICAgICAgICAgICAgICAgICAgIFNjaGVkdWxlcikgaW4gRkUgbW9kZWwsIHdlIG9ubHkgbmVlZCB0 byBjb25uZWN0IHRoZQ0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCBM RkIgdG8gdGhlIFNjaGVkdWxlciBMRkIgZGlyZWN0bHkgdmlhIGENCj4gPiA+ID4gICAgICAgICAg ICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAg Ky0tLS0tLS0tLS0tKw0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVk aXJlY3RUYXAgTEZCIHwtLS0tLS0+fCAgICAgICAgICAgfA0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgfCAgICAgICAgICAgfA0K PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCBTY2hlZHVsZXIgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGcm9tIG90aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgfA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDI3DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICAgQnkgdXNlIG9mIHNldmVyYWwgJ1JlZGlyZWN0U2luaycgTEZCcyBhbmQgc2V2ZXJh bA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgTEZCcyB0aGF0IGNv bm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBk YXRhcGF0aHMgaW4gRkUgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0DQo+ID4gPiA+ ICAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3QgcGF0aHMgYmV0d2VlbiBDRSBhbmQgRkUgY2Fu IGJlIGNvbnN0cnVjdGVkLg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMjogIFRo ZXJlIG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgcmVkaXJlY3RlZDogZGlyZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgs IGUuZy4sIGJ5DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRlBHQS9BU0lDL05QIG1pY3Jv Y29kZS4gIEluIHN1Y2ggYSBjYXNlIHdlIGRvIG5vdA0KPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0bmVzcy4gIFByb2JhYmx5IGEgbGluaw0K PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbCBo ZWFkZXIgaXMgZW5vdWdoLiAgVGhlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVjZWl2 ZXIgZGVtdXhlcyBpdCBvbmx5IGJhc2VkIG9uIHNvbWUgcHJvdG9jb2wgdHlwZQ0KPiA+ID4gPiAg ICAgICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3J0 IGxheWVyLiAgVGhlDQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcHJvcyBmb3IgdGhpcyBh cHByYW9jaCBpcyBpdCBtYXkgcHJvdmlkZSBhIGZhc3QgYW5kDQo+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICAgY29zdC1lZmZlY3RpdmUgcGF0aCBmb3IgcGFja2V0IHJlZGlyZWN0LiAgVGhlIGNv bnMNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBv ciBsZXNzIGNvbmZ1c2VzIHRoZSBGcA0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHJlZmVy ZW5jZSBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuDQo+ID4gPiA+DQo+ID4g PiA+LS0tLS0tLS0tLQ0KPiA+ID4gPmNhdGVnb3J5OiBFZGl0b3JpYWwNCj4gPiA+ID5kcmFmdDog ZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wNCj4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID5u b3N5OiBhdnJpDQo+ID4gPiA+cHJpb3JpdHk6IE11c3QgZml4DQo+ID4gPiA+c3RhdHVzOiBObyBk aXNjdXNzaW9uDQo+ID4gPiA+dGl0bGU6IFBhY2tldCBSZWRpcmVjdA0KPiA+ID4gPg0KPiA+ID4g Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4gPkZvcmNlcyBpc3N1ZSB0cmFja2VyIDx0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj4gPiA+ ID48aHR0cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJhY2tlci9mb3JjZXMvaXNzdWUzMj4NCj4g PiA+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ ------=_NextPart_000_0009_01C57B63.BA753770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFk+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Sm9lbCA6 KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+SG93IGFib3V0IHdlIGp1c3Qgb2Jzb2xldGUgdGhlIHBhdGggZnJvbSB0aGUgZGF0YSANCnN0 cnVjdHVyZSBhbmQgYWRkIHNvbWUgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPm1ldGEtaW5mb3JtYXRpb24sIGFuZCZuYnNwO2Zvcm0gdGhlIGZv cm1hdCBhcyBiZWxvdyAoSSANCmN1cnJlbnRseSBjYW4gb25seSB0aGluayA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+b2YgdGhlIG1ldGEtaW5m b3JtYXRpb24gYXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIA0Kc29tZSBtb3JlIGxhdGVy KS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6 ZT0yPkNvdWxkIHlvdSBnaXZlIG1vcmUgY29tbWVudHMgb24gdGhpcywgdGhlbiB3ZSBtYXkgDQpz b2x2ZSB0aGlzIGlzc3VlIHNvb24/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5UaGFuayZuYnNwO3lvdSB2ZXJ5IG11Y2guPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5XZWltaW5n PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+TWVzc2FnZSBCb2R5OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQpDb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBUTFZzLCB3aXRoIGV2ZXJ5IFRM ViBoYXZpbmcgdGhlIA0KZm9sbG93aW5nPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkYXRhIGZvcm1hdDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAwIDEgMiAzIDQgNSANCjYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgDQoxPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHlwZSA9IA0K TEZCc2VsZWN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCkxlbmd0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCkxGQiBDbGFzcyANCklEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KTEZCIEluc3RhbmNlIA0KSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpPcGVyYXRpb24gDQpUTFYmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCn4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouLi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp+ PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpPcGVyYXRpb24gDQpUTFYmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQouPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJz cDsgTEZCIGNsYXNzIA0KSUQ6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGVy ZSBhcmUgb25seSB0d28gcG9zc2libGUgTEZCIGNsYXNzZXMgDQpoZXJlLCB0aGUgJ1JlZGlyZWN0 U2luayc8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExGQiBvciB0aGUgDQonUmVk aXJlY3RTb3VyY2UnIExGQi4mbmJzcDsgSWYgdGhlIG1lc3NhZ2UgaXMgZnJvbSBGRSB0byANCkNF LDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIExGQiBjbGFzcyBzaG91bGQg YmUgDQonUmVkaXJlY3RTaW5rJy4mbmJzcDsgSWYgdGhlIG1lc3NhZ2UgaXMgZnJvbSANCkNFPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBGRSwgdGhlIExGQiBjbGFzcyBzaG91 bGQgYmUgDQonUmVkaXJlY3RTb3VyY2UnLjxCUj4mbmJzcDsmbmJzcDsgSW5zdGFuY2UgSUQ6PEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkluc3RhbmNlIElEIGZvciB0aGUgJ1Jl ZGlyZWN0U2luaycgTEZCIG9yICdSZWRpcmVjdFNvdXJjZScgTEZCLjxCUj4mbmJzcDsmbmJzcDsg DQpPcGVyYXRpb24gVExWOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBp cyBhIFRMViBkZXNjcmliaW5nIG9uZSANCnBhY2tldCBvZiBkYXRhIHRvIGJlIGRpcmVjdGVkIHZp YSB0aGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0Kc3BlY2lmaWVkIExGQiBh Ym92ZS4mbmJzcDsgVGhlIG9yZGVyIG9mIHRoZSBUTFYgYXBwZWFyZWQgaXMgYWxzbyANCnRoZTxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3JkZXIgdGhlIGRhdGEgcGFja2V0IGFy cml2ZXMgdGhlIA0KcmVkaXJlY3RvciBMRkIsIHRoYXQgaXMsIHRoZTxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmVkaXJlY3RlZCANCkRhdGEmbmJzcDsgaW4gdGhlIGZpcnN0IFRM ViZuYnNwO3Nob3VsZCBhcnJpdmUgdGhlIGVhcmxpZXN0LiZuYnNwOyA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlRoZSBUTFYgZm9ybWF0 IGlzIGFzIGZvbGxvd3M6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPiZuYnNwOzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFR5cGUgPSANClBBWUxPQUQmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KTGVuZ3RoJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KUGFja2V0IFR5cGUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGFja2V0 IA0KTGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KfjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO34mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpSZWRpcmVjdGVkJm5ic3A7UGFja2V0Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KfjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVHlwZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7VGhlIHR5cGUgZm9yIHRoZSBUTFYgaXMgc2V0IHRvIA0KJ1BBWUxPQUQn LiA8L0ZPTlQ+PC9ESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPjwvRk9OVD4NCjxESVY+PEJSPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlbmd0aDo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dGhlIGxlbmd0aCBvZiB0aGUgDQpUTFYoaW4gNGJ5dGVzKS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyBQYWNrZXQgVHlwZTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RGVmaW5l cyB3aGF0IHR5cGUgDQp0aGUgcmVkaXJlY3RlZCBwYWNrZXQgYmVsb25ncyB0byhzdWNoIGFzICdJ UHY0IFBhY2tldCcsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsnSVB2NiBQYWNrZXQnKS4gJm5ic3A7 Jm5ic3A7IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAz MDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgUGFja2V0IExlbmd0aDoNCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt0aGUgbGVuZ3RoIG9mIHRoZSANCmZvbGxvd2VkIHJlZGlyZWN0ZWQgcGFja2V0IChp biBieXRlKTwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYj MjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBSZWRpcmVjdGVkIA0KUGFj a2V0OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmUmbmJzcDtyZWRp cmVjdGVkJm5ic3A7cGFja2V0LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYnNw OzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+Jm5ic3A7PC9ESVY+PC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9GT05UPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkZyb206ICJKb2VsIE0uIEhhbHBlcm4iICZsdDs8 L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86am9lbEBzdGV2ZWNyb2NrZXIuY29tIj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+am9lbEBzdGV2ZWNyb2NrZXIuY29tPC9GT05UPjwv QT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+Jmd0OzwvRk9OVD48L0RJVj48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxCUj48Rk9OVCBzaXplPTI+ PC9GT05UPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQpzaXplPTI+ Jmd0OyBJIHdvdWxkIGV4cGVjdCB0aGF0IGEgUmVkaXJlY3QgTWVzc2FnZSBoYXMgYSBkaWZmZXJl bnQgb3V0ZXJtb3N0IA0KVExWLiZuYnNwOyBUaGUgPEJSPiZndDsgZ3JhbW1hciBpcyBpbnRlbmRl ZCB0byBoZWxwIHVzLCBub3Qgc2VydmUgYXMgYSANCnN0cmFpZ2h0amFja2V0LiZuYnNwOyBEaWZm ZXJlbnQgPEJSPiZndDsgbWVzc2FnZSB0eXBlcyBjYW4gaGF2ZSBkaWZmZXJlbnQgb3V0ZXIgDQpU TFZzLiZuYnNwOyBJdCBpcyBkZXNpcmFibGUgdG8gdXNlIHRoZSA8QlI+Jmd0OyBzYW1lIHN0cnVj dHVyZSB3aGVuIGl0IA0KYXBwbGllcy4mbmJzcDsgQnV0IHRoZSByZWRpcmVjdCBtZXNzYWdlIGlz IHNpbXBseSBhIDxCUj4mZ3Q7IGRpZmZlcmVudCANCmNhc2UuJm5ic3A7IEl0J3MgY29udGVudHMg YXJlIG5vdCBhIERBVEFSQVcgbXVjaCBsZXNzIGEgREFUQSBUTFYuJm5ic3A7IEl0cyANCjxCUj4m Z3Q7IGNvbnRlbnQgc3RydWN0dXJlIGlzIG5vdCBkZWZpbmVkIGJ5IGFuIExGQiBlbGVtZW50IGRl ZmluaXRpb24gb3IgTW9kZWwgDQo8QlI+Jmd0OyBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdGlv bi48QlI+Jmd0OyA8QlI+Jmd0OyBJZiB3ZSBuZWVkIHRvIGZpeCB0aGUgDQoiZ3JhbW1hciIgc2Vj dGlvbiB0byBtYWtlIGl0IGNsZWFyIHRoYXQgbm90IGFsbCBQTCA8QlI+Jmd0OyBtZXNzYWdlcyBu ZWNlc3NhcmlseSANCnVzZSB0aGUgc2FtZSBvdXRlcm1vc3QgVExWLCB3ZSBzaG91bGQgZG8gc28u Jm5ic3A7Jm5ic3A7IE15IG93biA8QlI+Jmd0OyANCmFwcHJvYWNoIHdvdWxkIGJlIHRvIHNlcGFy YXRlIHRoZSBncmFtbWFyIGludG8gYSBkZWZpbml0aW9uIG9mIHRoZSBjb250ZW50cyANCjxCUj4m Z3Q7IG9mIHRoYXQgVExWLCBhbmQgYSBzZXBhcmF0ZSBkZWZpbml0aW9uIG9mIHdoaWNoIFRMVnMg LyBjb250ZW50IGFyZSANCmNhcnJpZWQgPEJSPiZndDsgaW4gdGhlIG91dGVybW9zdCBsZXZlbCBv ZiB3aGljaCBtZXNzYWdlcy48QlI+Jmd0OyA8QlI+Jmd0OyANCllvdXJzLDxCUj4mZ3Q7IEpvZWw8 QlI+Jmd0OyA8QlI+Jmd0OyBQUzogV2VpbWluZywgSSBhbSBzb3JyeSB5b3UgZ290IGNhdWdodCB1 cCANCmluIHRoaXMgY29uZnVzaW9uLiZuYnNwOyBJIGRvbid0IHRoaW5rIDxCUj4mZ3Q7IHlvdSBj cmVhdGVkIHRoZSB0ZW5kZW5jeSBJIGFtIA0KcmFpbGluZyBhZ2FpbnN0IGFib3ZlLiZuYnNwOyBJ IGFtIGp1c3QgdXNpbmcgeW91ciA8QlI+Jmd0OyBtZXNzYWdlIGFzIGEgc3RhcnRpbmcgDQpwb2lu dCB0byBoYW1tZXIgaG9tZSBhIHBvaW50LjxCUj4mZ3Q7IDxCUj4mZ3Q7IEF0IDA0OjQ1IEFNIDYv MjYvMjAwNSwgDQpXYW5nLFdlaW1pbmcgd3JvdGU6PEJSPiZndDsgJmd0O01heWJlIGl0J3MgbWUg d2hvIG1pc3NlZCBzb21ldGhpbmcgOik8QlI+Jmd0OyANCiZndDtNeSB0aG91Z2h0IHdhcyB3ZSBt aWdodCBuZWVkIHRvIG9iZXkgb3VyIG1lc3NhZ2UgZ3JhbW1hciB3ZWxsIHRoYXQgd2UgaGF2ZSAN CjxCUj4mZ3Q7ICZndDt0byB1c2UgYSBzdHJpY3QgUGF0aC1kYXRhIGZvciBvcGVyYXRpb24gVExW LiZuYnNwOyBUbyBvYmV5IHRoZSANCnJ1bGUsIHRyZWF0aW5nIDxCUj4mZ3Q7ICZndDtpdCBhcyBh biBldmVudCB3aWxsIGVhc2UgdGhlIG1lc3NhZ2UgZm9ybWF0IA0KZ3JlYXRseS48QlI+Jmd0OyAm Z3Q7PEJSPiZndDsgJmd0O0FjdHVhbGx5IEknbSB2ZXJ5IGhhcHB5IHRvIHNlZSB0aGF0IHlvdSBh Z3JlZSANCmEgcGF0aCBjYW4gYmUgb21pdHRlZCBmb3IgPEJSPiZndDsgJmd0O3NvbWUgc3BlY2lm aWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCANCm1lc3NnZS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg Jmd0O09LLCBsZXQncyBzb2x2ZSBpdCB0aGVuLCB0byBsZXQgcmVkaXJlY3QgDQptZXNzYWdlIG9u bHkgY29udGFpbiBEYXRhIDxCUj4mZ3Q7ICZndDtmaWVsZD8mbmJzcDsgSSBjYW4gdXBkYXRlIHRo aXMgcmVkaXJlY3QgDQptZXNzYWdlIHBhcnQgdGV4dCB0aGVuLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0 OyAmZ3Q7SmFtYWwsIGNvdWxkIHlvdSBnaXZlIGEgDQpyZXNwb25zZSBvbiB0aGlzPzxCUj4mZ3Q7 ICZndDs8QlI+Jmd0OyAmZ3Q7T25lJm5ic3A7IGxlc3Mgdml0YWwgcXVlc3Rpb24gaXMsIA0Kc2hh bGwgd2UgYWxsb3cgZm9yIG11bGl0cHVsIHJlZGlyZWN0IHBhY2tldHMgPEJSPiZndDsgJmd0O2Vu Y2Fwc3VsYXRlZCBpbiBvbmUgDQpUTFYgb3IganVzdCBvbmUgVExWIG9ubHkgZm9yIG9uZSBwYWNr ZXQ/IFRvIHVzZSB0aGUgPEJSPiZndDsgJmd0O2Zvcm1lciwgd2UgaGF2ZSANCnRvIGRlZmluZSBh IHNlcXVlbmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4gPEJSPiZndDsgJmd0 O3RoZSANClRMVi48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0O09uJm5ic3A7IHRoZSBtZXRhLWlu Zm9ybWF0aW9uIHJlbGF0ZWQsIEkgdGhpbmsgTEZCIA0KSURzIGhhcyBhbHJlYWR5IGJlZW4gPEJS PiZndDsgJmd0O2luY2x1ZGVkLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgYW4gZXh0cmEgcG9ydCAN CklEIHRvIGluZGljYXRlIHdoZXJlIHRvIHB1dCA8QlI+Jmd0OyAmZ3Q7dGhlIHJlZGlyZWN0ZWQg ZGF0YSB0byBvciB0byBnZXQgDQpyZWRpcmVjdGVkIGRhdGEgZnJvbS4gQSByZWRpcmVjdCBzb3Vy Y2UgPEJSPiZndDsgJmd0O0xGQiZuYnNwOyBvciBzaW5rIExGQiANCndpbGwmbmJzcDsgaGF2ZSBh IHBvcnQgSUQsIHdoaWNoIGJlbG9uZ3MgdG8gRkUgTEZCIHRvcG9sb2d5IDxCUj4mZ3Q7IA0KJmd0 O2NvbmNlcHQsIGFuZCBGRSBMRkIgdG9wb2xneSBjb25maWd1cmF0aW9uIGlzIGluIGNoYXJnZSBv ZiB0aGlzLiZuYnNwOyBOb3QgDQpzdXJlIDxCUj4mZ3Q7ICZndDtpZiBpdCBjb21wbGllcyB3aXRo IHlvdXIgdGhvdWdodD88QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgDQomZ3Q7VGhhbmtzLDxCUj4mZ3Q7 ICZndDtXZWltaW5nPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDstLS0tLSBPcmlnaW5hbCBNZXNz YWdlIA0KLS0tLS08QlI+Jmd0OyAmZ3Q7RnJvbTogIkpvZWwgTS4gSGFscGVybiI8QlI+Jmd0OyAm Z3Q7U3ViamVjdDogUmU6IFtpc3N1ZTMyXSANClBhY2tldCBSZWRpcmVjdDxCUj4mZ3Q7ICZndDs8 QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgYW0gbWlzc2lnbiANCnNvbWV0aGluZyBp biB5b3VyIHN1Z2dlc3Rpb24uPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFdo eSB3b3VsZCB3ZSANCndhbnQgdG8gdHJlYXQgcmVkaXJlY3RzIGFzIGV2ZW50cz88QlI+Jmd0OyAm Z3Q7ICZndDsgV2Ugc2hvdWxkIHRyZWF0IHRoZW0gYXMgDQpyZWRpcmVjdHMuPEJSPiZndDsgJmd0 OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IEkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCAiSG93IGEg DQpwYXRoIHNob3VsZCBiZSBkZWZpbmVkIGluIGEgUGFja2V0IDxCUj4mZ3Q7ICZndDsgUmVkaXJl Y3Q8QlI+Jmd0OyAmZ3Q7ICZndDsgDQpNZXNzYWdlIiwgc2luY2UgYXMgZmFyIGFzIEkgY2FuIHRl bGwsIGEgcmVkaXJlY3QgZG9lcyBub3QgbmVlZCBhIHBhdGguJm5ic3A7IA0KSXQ8QlI+Jmd0OyAm Z3Q7ICZndDsgbmVlZHMgYSBjb2xsZWN0aW9uIG9mIG1ldGEtaW5mb3JtYXRpb24sIHdoaWNoIHdl IG5lZWQgdG8gDQpkZWZpbmUuJm5ic3A7IEF0IHRoZTxCUj4mZ3Q7ICZndDsgJmd0OyBtb21lbnQs IHRoYXQgaGFzIHRvIGluY2x1ZGUgYXQgbGVhc3QgdGhlIA0KTEZCIElEIHRoYXQgdGhlIHJlZGly ZWN0IGlzIDxCUj4mZ3Q7ICZndDsgZnJvbSAvPEJSPiZndDsgJmd0OyAmZ3Q7IHRvLiZuYnNwOyBJ IA0Kc3VwcG9zZSBieSBkZWNsYXJpbmcgYSBtdWx0aXBsaWNpdHkgb2Ygc3VjaCBMRkJzLCB0aGF0 IGNhbiBiZSA8QlI+Jmd0OyAmZ3Q7IGFsbCANCm9mPEJSPiZndDsgJmd0OyAmZ3Q7IHRoZSBpbmZv cm1hdGlvbi4mbmJzcDsgKEkgdXN1YWxseSB0aGluayBpbiB0ZXJtcyBvZiBhdCANCmxlYXN0IGEg bG9naWNhbCBwb3J0IElEPEJSPiZndDsgJmd0OyAmZ3Q7IHRoZSBwYWNrZXQgY2FtZSBmcm9tIC8g aXMgaW50ZW5kZWQgDQpmb3IuKTxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBZ b3Vycyw8QlI+Jmd0OyAmZ3Q7ICZndDsgSm9lbDxCUj4mZ3Q7IA0KJmd0OyAmZ3Q7PEJSPiZndDsg Jmd0OyAmZ3Q7IEF0IDEwOjUwIFBNIDYvMjUvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOjxCUj4m Z3Q7IA0KJmd0OyAmZ3Q7ICZndDtKYW1hbCwgSm9lbCwgYW5kIEhvcm16ZCw8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtJIHN1cHBvc2Ugd2UgY291bGQgY2xv c2UgdGhpcyBpc3N1ZSBieSByZWFjaGluZyB0aGUgZm9sbG93aW5nIA0KcG9pbnRzOjxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsxLiBUaGUgcmVkaXJlY3QgTEZC cyBjYWxsZWQgDQpSZWRpcmVjdFNvdXJjZSZuYnNwOyBMRkIgYW5kIFJlZGlyZWN0U2luayBMRkIg YXJlPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDttb3ZlZCB0byANCnRoZSBtb2RlbCwgYnV0IHRoZSBw cm90b2NvbCByZXRhaW5zIHRoZSBSZWRpcmVjdCBNZXNzYWdlLiBUaGU8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQomZ3Q7cmVhc29uIHRvIGtlZXAgdGhlIHNwZWNpZmljIG1lc3NhZ2UgaXMgd2UgbmVlZCB0 byBzcGVjaWZpY2FsbHkgDQpyZWNvZ25pemU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0O3JlZGlyZWN0 ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIA0KYXZvaWQgRG9TIGF0dGFj a3MuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzIuIFRoZSAN CnJlZGlyZWN0ZWQgZGF0YSBpbiB0aGUgTEZCcyBjYW4gYmUgdHJlYXRlZCBhcyBhIGtpbmQgb2Yg U1BFQ0lBTDxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDtldmVudHMgaW4gdGhhdDo8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhLiANClRoZSBldmVu dCBpcyB0cmlnZ2VyZWQgZXZlcnkgdGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldCA8QlI+Jmd0 OyAmZ3Q7IA0KYXJyaXZlczxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0IHRoZSBMRkJzLjxCUj4m Z3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYi4gVGhl IGV2ZW50IGlzIHRyYW5zcG9ydGVkIGJ5IHRoZSANClJlZGlyZWN0Jm5ic3A7IE1lc3NhZ2Ugb25s eSwgd2hpbGUgPEJSPiZndDsgJmd0OyB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyANClJlZGly ZWN0IE1lc3NhZ2Ugd2lsbCB0aGUgc2FtZSBtZXNzYWdlIGZvcm1hdCBhcyBhIGdlbmVyYWwgZXZl bnQ8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQg dGhlIG1lc3NhZ2UgdHlwZSBpbiB0aGUgaGVhZGVyKS48QlI+Jmd0OyANCiZndDsgJmd0OyAmZ3Q7 PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtCeSBkb2luZyBpbiB0aGlzIHdheSwgd2UgY2FuIGFsc28g c29sdmUgdGhlIA0KaXNzdWU1MyAoSG93IGEgcGF0aCBzaG91bGQgYmU8QlI+Jmd0OyAmZ3Q7ICZn dDsgJmd0O2RlZmluZWQmbmJzcDsgaW4gUGFja2V0IA0KUmVkaXJlY3QgTWVzc2FnZSkgdGhlbi48 QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtVbmZvcnR1bmF0 ZWx5LCZuYnNwOyBJIHRoaW5rIG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRv IHRoZSANClBhY2tldDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7UmVkaXJlY3QgTWVzc2FnZSBhcyB3 ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaWNhdGlvbiANCk1lc3NhZ2UuIFRoZSBxdWVzdGlvbjxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7aXMsIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSANCmFs bG93cyBldmVudCBnZW5lcmF0ZWQgYnkgQ0UgYW5kIHNlbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0 O3RvIEZFLiBJbiB0aGUgY2FzZSwgDQppbiB0aGUgbWVzc2FnZSBmb3JtYXQsIHRoZSBMRkIgSURz IHJlZmVyIHRvIHRoZSBMRkJzPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDt0aGF0IA0Kd2lsbCByZWNl aXZlIHRoZSBldmVudCBub3RpZmljYXRpb24sIGJ1dCB0aGUgcXVlc3Rpb24gaXMsIHdoYXQgdGhl PEJSPiZndDsgJmd0OyANCiZndDsgJmd0O1BhdGggaW4gdGhlIG1lc3NhZ2UgcmVmZXJzIHRvIHRo ZW4gPz8mbmJzcDsgVGhlIHNhbWUgYWxzbyBoYXBwZW5zIHRvIA0KUGFja2V0PEJSPiZndDsgJmd0 OyAmZ3Q7ICZndDtSZWRpcmVjdCBNZXNzYWdlIGZyb20gQ0UgdG8gRkUuPEJSPiZndDsgJmd0OyAm Z3Q7IA0KJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7VGhhbmtzLDxCUj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7V2VpbWluZzxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsg Jmd0Oy0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7 RnJvbTogIkF2cmkgRG9yaWEiICZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnRyYWNrZXItZm9y Y2VzQG1pcDQub3JnIj48Rk9OVCANCmZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+dHJhY2tl ci1mb3JjZXNAbWlwNC5vcmc8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyAN CnNpemU9Mj4mZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtUbzogJmx0OzwvRk9OVD48QSANCmhy ZWY9Im1haWx0bzpGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00iPjxGT05UIGZhY2U9JiMyMzQz NTsmIzIwMzA3OyANCnNpemU9Mj5GT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT008L0ZPTlQ+PC9B PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jmd0OzxCUj4mZ3Q7IA0KJmd0OyAm Z3Q7ICZndDtTZW50OiBNb25kYXksIE1heSAyMywgMjAwNSAyOjM1IEFNPEJSPiZndDsgJmd0OyAm Z3Q7ICZndDtTdWJqZWN0OiANCltpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3Q8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgDQomZ3Q7ICZndDsgJmd0 O05ldyBzdWJtaXNzaW9uIGZyb20gQXZyaSBEb3JpYSAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFp bHRvOmF2cmlAYWNtLm9yZyI+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5hdnJp QGFjbS5vcmc8L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4m Z3Q7OjxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs2Ljg8QlI+ Jmd0OyANCiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgRWRpdG9y aWFsIE5vdGU6Jm5ic3A7IFRoZXJlIGFyZSBhbHNvIA0KZGlzY3Vzc2lvbnMgb24gaG93IExGQnMg aW4gRkUgbW9kZWw8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhhdCBhcmUgcmVs YXRlZCB0byBwYWNrZXQgcmVkaXJlY3Qgb3BlcmF0aW9uczxCUj4mZ3Q7ICZndDsgJmd0OyANCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQpzaG91bGQgYmUgZGVmaW5lZC4mbmJzcDsgQWx0aG91Z2ggaXQgaXMgb3V0IG9m IHRoZSBzY29wZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpvZiBmb3JjZXMgcHJv dG9jb2wsIGhvdyB0byBkZWZpbmUgdGhlIExGQnMgYWZmZWN0PEJSPiZndDsgJmd0OyAmZ3Q7IA0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCnRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNjcmliZWQgaGVyZS4m bmJzcDsgQmVjYXVzZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjdXJyZW50bHkg aXQgaXMgc3RpbGwgaW4gcHJvZ3Jlc3MgaW4gRkUgbW9kZWwgb24gaG93PEJSPiZndDsgJmd0OyAm Z3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCnRvIGRlZmluZSBzdWNoIExGQnMsIHdlIHRyeSB0byBwb3N0IHNv bWUgdGhvdWdodHMgb248QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhpcyBoZXJl IGZvciBkaXNjdXNzaW9uLiZuYnNwOyBUaGV5IHdpbGwgYmUgcmVtb3ZlZDxCUj4mZ3Q7ICZndDsg Jmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpsYXRlciBhbG9uZyB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGUg RkUgbW9kZWwgd29yay48QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRob3VnaHQgMTombmJzcDsgVG8gZGVmaW5l IA0KTEZCcyBjYWxsZWQgJ1JlZGlyZWN0U2luaycgYW5kPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCidSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcmVjdC48QlI+Jmd0OyAmZ3Q7 ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBp cyByZXNwb25zaWJsZSB0bzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjb2xsZWN0 IGRhdGEgcGFja2V0cyB0aGF0IG5lZWQgdG8gYmUgcmVkaXJlY3RlZCB0bzxCUj4mZ3Q7ICZndDsg Jmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpDRS4mbmJzcDsgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhl IEZFIExGQiB0b3BvbG9neSw8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdGhlICdS ZWRpcmVjdFNpbmsnIExGQiBpcyBhbiBMRkIgd2l0aCBvbmx5IG9uZSBpbnB1dDxCUj4mZ3Q7ICZn dDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpwb3J0IGFuZCB3aXRob3V0IGFueSBvdXRwdXQgcG9ydCwg YW5kIHRoZSBpbnB1dCBwb3J0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmNhbiB0 aGVuIGJlIGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIG1vZGVsPEJSPiZndDsgJmd0 OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCmJ5IG1lYW5zIG9mIGEgZGF0YXBhdGggaW4gdGhlIGZvcndh cmRpbmcgcGxhbmUuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMgcHJvdG9jb2wgbGF5ZXIsPEJSPiZndDsgJmd0OyAmZ3Q7 IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCnRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0ZSB0aGUg UGFja2V0PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClJlZGlyZWN0IE1lc3NhZ2Vz IHdoZW4gaXQgcmVjZWl2ZXMgZGF0YSBwYWNrZXRzIGZyb208QlI+Jmd0OyAmZ3Q7ICZndDsgDQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KZm9yd2FyZGluZyBwbGFuZS48QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4m Z3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVj dFRhcCcgaXMgcmVzcG9uc2libGUgdG88QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K cmVjZWl2ZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLjxCUj4mZ3Q7 ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUg TEZCIHRvcG9sb2d5LCB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJ1JlZGly ZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3V0cHV0PEJSPiZndDsgJmd0OyAm Z3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCnBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0IHBvcnQsIGFuZCB0 aGUgb3V0cHV0IHBvcnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KY2FuIHRoZW4g YmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgbW9kZWw8QlI+Jmd0OyAmZ3Q7ICZn dDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2FyZGlu ZyBwbGFuZS48QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRnJvbSB0aGUgcGVyc3Bl Y3RpdmUgb2YgRm9yQ0VTIHByb3RvY29sIGxheWVyLCB0aGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIFBhY2tldCBSZWRp cmVjdDxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpNZXNzYWdlcyBmcm9tIENFLCBh bmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byBkYXRhcGF0aHM8QlI+ Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuJm5i c3A7IEFjdHVhbGx5IHRoZSAnUmVjaXJlY3RUYXAnPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCkxGQiBhY3RzIG1vcmUgbGlrZSBhIHRyYW5zY29kZXIgdGhhdCB0cmFuc2ZlcnMgdGhl PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZvckNFUyBwcm90b2NvbCBtZXNzYWdl cyB0byBub3JtYWwgZGF0YSBwYWNrZXRzIGluPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCklQIGZvcndhcmRpbmcgcGxhbmUuJm5ic3A7IEFzIGEgcmVzdWx0LCBpZiB3ZSBuZWVkIHRv PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmhhdmUgcmVkaXJlY3RlZCBwYWNrZXRz IGNvbm5lY3RlZCB0byBzb21lIExGQiAoc2F5IGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgd2Ugb25seSBuZWVkIHRvIGNvbm5lY3QgdGhl PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCidSZWRpcmVjdFRhcCBMRkIgdG8gdGhl IFNjaGVkdWxlciBMRkIgZGlyZWN0bHkgdmlhIGE8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KZGF0YXBhdGggYXMgZm9sbG93czo8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyANCiZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0t LS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS0tLS0tLS0t LS0rPEJSPiZndDsgDQomZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCBSZWRpcmVjdFRhcCBMRkIgDQp8 LS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0t LS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 QlI+Jmd0OyAmZ3Q7IA0KJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8IFNjaGVkdWxlciB8PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkZyb20gb3RoZXIgTEZCJm5ic3A7Jm5ic3A7IC0t LS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyBMRkImbmJzcDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZn dDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxCUj4mZ3Q7ICZndDsgDQomZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0tLS0tLSs8QlI+Jmd0OyAm Z3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpG aWd1cmUgMjc8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQpCeSB1c2Ugb2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5rJyBMRkJzIGFuZCBzZXZlcmFs PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCidSZWRpcmVjdFRhcCcgTEZCcyB0aGF0 IGNvbm5lY3QgdG8gc2V2ZXJhbCBkaWZmZXJlbnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KZGF0YXBhdGhzIGluIEZFIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxlIHBhY2tldDxC Uj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZWRpcmVjdCBwYXRocyBiZXR3ZWVuIENF IGFuZCBGRSBjYW4gYmUgY29uc3RydWN0ZWQuPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OzxCUj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KVGhvdWdodCAyOiZuYnNwOyBUaGVyZSBtaWdodCBiZSBhbm90aGVyIHdheSBh IHBhY2tldCBjb3VsZCBiZTxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpyZWRpcmVj dGVkOiBkaXJlY3RseSBieSBhIGZvcndhcmRpbmcgcGF0aCwgZS5nLiwgYnk8QlI+Jmd0OyAmZ3Q7 ICZndDsgDQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRlBHQS9BU0lDL05QIG1pY3JvY29kZS4mbmJzcDsgSW4gc3Vj aCBhIGNhc2Ugd2UgZG8gbm90PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCm5lZWQg dG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0bmVzcy4mbmJzcDsgUHJvYmFibHkgYSBsaW5rPEJSPiZn dDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbCBo ZWFkZXIgaXMgZW5vdWdoLiZuYnNwOyBUaGU8QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KcmVjZWl2ZXIgZGVtdXhlcyBpdCBvbmx5IGJhc2VkIG9uIHNvbWUgcHJvdG9jb2wgdHlwZTxC Uj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQppbiB0aGUgbGluayBsYXllciBvciBuZXR3 b3JrIHRyYW5zcG9ydCBsYXllci4mbmJzcDsgVGhlPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCnByb3MgZm9yIHRoaXMgYXBwcmFvY2ggaXMgaXQgbWF5IHByb3ZpZGUgYSBmYXN0IGFu ZDxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpjb3N0LWVmZmVjdGl2ZSBwYXRoIGZv ciBwYWNrZXQgcmVkaXJlY3QuJm5ic3A7IFRoZSBjb25zPEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCmZvciB0aGlzIGlzIGl0IG1heSBtb3JlIG9yIGxlc3MgY29uZnVzZXMgdGhlIEZw PEJSPiZndDsgJmd0OyAmZ3Q7IA0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnJlZmVyZW5jZSBwb2ludCBkZWZpbml0 aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAN CiZndDsgJmd0OyAmZ3Q7LS0tLS0tLS0tLTxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Y2F0ZWdvcnk6 IEVkaXRvcmlhbDxCUj4mZ3Q7ICZndDsgDQomZ3Q7ICZndDtkcmFmdDogZHJhZnQtaWV0Zi1mb3Jj ZXMtcHJvdG9jb2w8QlI+Jmd0OyAmZ3Q7ICZndDsgJmd0O21lc3NhZ2VzOiANCjQ5PEJSPiZndDsg Jmd0OyAmZ3Q7ICZndDtub3N5OiBhdnJpPEJSPiZndDsgJmd0OyAmZ3Q7ICZndDtwcmlvcml0eTog TXVzdCANCmZpeDxCUj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7c3RhdHVzOiBObyBkaXNjdXNzaW9uPEJS PiZndDsgJmd0OyAmZ3Q7ICZndDt0aXRsZTogDQpQYWNrZXQgUmVkaXJlY3Q8QlI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7ICZndDsgDQomZ3Q7Rm9y Y2VzIGlzc3VlIHRyYWNrZXIgJmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzp0cmFja2VyLWZv cmNlc0BtaXA0Lm9yZyI+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0Kc2l6ZT0yPnRyYWNr ZXItZm9yY2VzQG1pcDQub3JnPC9GT05UPjwvQT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPiZndDs8QlI+Jmd0OyAmZ3Q7IA0KJmd0OyAmZ3Q7Jmx0OzwvRk9OVD48QSANCmhyZWY9 Imh0dHA6Ly93d3cubWlwNC5vcmcvaXNzdWVzL3RyYWNrZXIvZm9yY2VzL2lzc3VlMzIiPjxGT05U IGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCnNpemU9Mj5odHRwOi8vd3d3Lm1pcDQub3JnL2lzc3Vl cy90cmFja2VyL2ZvcmNlcy9pc3N1ZTMyPC9GT05UPjwvQT48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgDQpzaXplPTI+Jmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyANCiZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyAmZ3Q7IA0KJmd0 OzwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0009_01C57B63.BA753770-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 11:31:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvZh-0002nZ-FU for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 11:31:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03464 for ; Mon, 27 Jun 2005 11:31:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmvya-0007wp-Ga for forces-archive@IETF.ORG; Mon, 27 Jun 2005 11:57:06 -0400 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.0108FF06@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 11:30:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77024512 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 11:30:44 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 11:30:44 -0400 Received: from [69.170.1.53] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11134853; Mon, 27 Jun 2005 11:30:43 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <1116786905.33.0.544707347688.issue32@mip4.org> <004b01c579f9$d5fb21f0$020aa8c0@wwm1> <6.2.1.2.0.20050625233944.02eccfe0@localhost> <109201c57a2b$79b0f5f0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050626094409.02ec5e18@localhost> <000c01c57b20$acce0540$020aa8c0@wwm1> 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.20050627112010.02e94f50@localhost> Date: Mon, 27 Jun 2005 11:30:33 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <000c01c57b20$acce0540$020aa8c0@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a I would approach this differently. The current text describes the LFBselect LFB. It correctly defines the LFBselect LFB. That definition should not be thrown away. The message structure documentation can say A PL protocol messages consists of a protocol header followed by one or more TLVs. All TLVs consist of two byte type and a two byte length, followed by contents dependent upon the type of the TLV. The TLVs which are valid in a message depend upon the message type. Most message types allow one or more LFBselect TLVs and no other top level TLVs. The following are the message types this applies to: Association setup request and response. Config message request and response Query message request and response Event Notify message. The Association teardown message contains a single instance of the teardown-cause TLV. The heartbeat message contains a single instance of the heatrbeat TLV. (Unless we decide to just use an event for heartbeats. I don't remember where that discussion stands.) The Packet Redirect message contains one or more (typically one) packet-redirect TLVs. This is then followed by a section for each of these top level TLVs. Yours, Joel M. Halpern At 10:01 AM 6/27/2005, Weiming Wang wrote: >Joel :) > >How about we just obsolete the path from the data structure and add some >meta-information, and form the format as below (I currently can only think >of the meta-information as the packet type. We may add some more later). > >Could you give more comments on this, then we may solve this issue soon? > >Thank you very much. > >Weiming > >--------------------- >Message Body: > Consists of one or more TLVs, with every TLV having the following > data format: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = LFBselect | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > LFB class ID: > There are only two possible LFB classes here, the 'RedirectSink' > LFB or the 'RedirectSource' LFB. If the message is from FE to CE, > the LFB class should be 'RedirectSink'. If the message is from CE > to FE, the LFB class should be 'RedirectSource'. > Instance ID: > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > Operation TLV: > This is a TLV describing one packet of data to be directed via the > specified LFB above. The order of the TLV appeared is also the > order the data packet arrives the redirector LFB, that is, the > Redirected Data in the first TLV should arrive the earliest. > >The TLV format is as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = PAYLOAD | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Packet Type | Packet Length ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Redirected Packet ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: > The type for the TLV is set to 'PAYLOAD'. > > Length: > the length of the TLV(in 4bytes). > > Packet Type: > Defines what type the redirected packet belongs to(such as 'IPv4 > Packet', > 'IPv6 Packet'). > > Packet Length: > the length of the followed redirected packet (in byte) > > Redirected Packet: > one redirected packet. >----------------------------- > > >----- Original Message ----- >From: "Joel M. Halpern" <joel@stevecrocker.com> > > > I would expect that a Redirect Message has a different outermost TLV. The > > grammar is intended to help us, not serve as a straightjacket. Different > > message types can have different outer TLVs. It is desirable to use the > > same structure when it applies. But the redirect message is simply a > > different case. It's contents are not a DATARAW much less a DATA > TLV. Its > > content structure is not defined by an LFB element definition or Model > > DataDefs structure definition. > > > > If we need to fix the "grammar" section to make it clear that not all PL > > messages necessarily use the same outermost TLV, we should do so. My own > > approach would be to separate the grammar into a definition of the > contents > > of that TLV, and a separate definition of which TLVs / content are carried > > in the outermost level of which messages. > > > > Yours, > > Joel > > > > PS: Weiming, I am sorry you got caught up in this confusion. I don't > think > > you created the tendency I am railing against above. I am just using your > > message as a starting point to hammer home a point. > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > >Maybe it's me who missed something :) > > >My thought was we might need to obey our message grammar well that we > have > > >to use a strict Path-data for operation TLV. To obey the rule, treating > > >it as an event will ease the message format greatly. > > > > > >Actually I'm very happy to see that you agree a path can be omitted for > > >some specific messages like redirect messge. > > > > > >OK, let's solve it then, to let redirect message only contain Data > > >field? I can update this redirect message part text then. > > > > > >Jamal, could you give a response on this? > > > > > >One less vital question is, shall we allow for mulitpul redirect packets > > >encapsulated in one TLV or just one TLV only for one packet? To use the > > >former, we have to define a sequence for the redirected packets then in > > >the TLV. > > > > > >On the meta-information related, I think LFB IDs has already been > > >included. I don't think we need an extra port ID to indicate where to put > > >the redirected data to or to get redirected data from. A redirect source > > >LFB or sink LFB will have a port ID, which belongs to FE LFB topology > > >concept, and FE LFB topolgy configuration is in charge of this. Not sure > > >if it complies with your thought? > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > Why would we want to treat redirects as events? > > > > We should treat them as redirects. > > > > > > > > I am very confused about "How a path should be defined in a Packet > > > Redirect > > > > Message", since as far as I can tell, a redirect does not need a > path. It > > > > needs a collection of meta-information, which we need to > define. At the > > > > moment, that has to include at least the LFB ID that the redirect is > > > from / > > > > to. I suppose by declaring a multiplicity of such LFBs, that can be > > > all of > > > > the information. (I usually think in terms of at least a logical > port ID > > > > the packet came from / is intended for.) > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > >I suppose we could close this issue by reaching the following points: > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink > LFB are > > > > >moved to the model, but the protocol retains the Redirect Message. The > > > > >reason to keep the specific message is we need to specifically > recognize > > > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > > > > > >2. The redirected data in the LFBs can be treated as a kind of SPECIAL > > > > >events in that: > > > > > a. The event is triggered every time a new redirected packet > > > arrives > > > > > at the LFBs. > > > > > b. The event is transported by the Redirect Message only, > while > > > the > > > > > Redirect Message will the same message format as a general event > > > > > notification message (except the message type in the header). > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a path > should be > > > > >defined in Packet Redirect Message) then. > > > > > > > > > >Unfortunately, I think of another question that is related to the > Packet > > > > >Redirect Message as well as to Event Notification Message. The > question > > > > >is, the Event Notification Message allows event generated by CE > and sent > > > > >to FE. In the case, in the message format, the LFB IDs refer to > the LFBs > > > > >that will receive the event notification, but the question is, > what the > > > > >Path in the message refers to then ?? The same also happens to Packet > > > > >Redirect Message from CE to FE. > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Avri Doria" > <tracker-forces@mip4.org> > > > > >To: <FORCES@PEACH.EASE.LSOFT.COM> > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > >New submission from Avri Doria <avri@acm.org>: > > > > > > > > > >6.8 > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in FE model > > > > > that are related to packet redirect operations > > > > > should be defined. Although it is out of the > scope > > > > > of forces protocol, how to define the LFBs affect > > > > > the Packet Redirect Message described > here. Because > > > > > currently it is still in progress in FE model > on how > > > > > to define such LFBs, we try to post some > thoughts on > > > > > this here for discussion. They will be removed > > > > > later along with the progress of the FE model > work. > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > 'RedirectTap' for packet redirect. > > > > > An LFB in FE called 'RedirectSink' is > responsible to > > > > > collect data packets that need to be > redirected to > > > > > CE. From the perspective of the FE LFB topology, > > > > > the 'RedirectSink' LFB is an LFB with only > one input > > > > > port and without any output port, and the > input port > > > > > can then be connected to any other LFB in FE > model > > > > > by means of a datapath in the forwarding plane. > > > > > From the perspective of the ForCES protocol > layer, > > > > > the 'RedirectSink' LFB will generate the Packet > > > > > Redirect Messages when it receives data > packets from > > > > > forwarding plane. > > > > > > > > > > An LFB in FE called 'RedirectTap' is > responsible to > > > > > receive data packets that are redirected from CE. > > > > > From the perspective of the FE LFB topology, the > > > > > 'RedirectTap' LFB is an LFB with only one output > > > > > port and without any input port, and the > output port > > > > > can then be connected to any other LFB in FE > model > > > > > by means of a datapath in the forwarding plane. > > > > > From the perspective of ForCES protocol > layer, the > > > > > 'RedirectTap' LFB can receive the Packet Redirect > > > > > Messages from CE, and un-encapsulate the data > > > > > packets from the message and put them to > datapaths > > > > > in the forwarding plane. Actually the > 'RecirectTap' > > > > > LFB acts more like a transcoder that > transfers the > > > > > ForCES protocol messages to normal data > packets in > > > > > IP forwarding plane. As a result, if we need to > > > > > have redirected packets connected to some LFB > (say a > > > > > Scheduler) in FE model, we only need to > connect the > > > > > 'RedirectTap LFB to the Scheduler LFB > directly via a > > > > > datapath as follows: > > > > > > > > > > > > > > > +-----------------+ +-----------+ > > > > > | RedirectTap LFB |------>| | > > > > > +-----------------+ | | > > > > > | Scheduler | > > > > > From other LFB ---->| LFB | > > > > > | | > > > > > +-----------+ > > > > > > > > > > Figure 27 > > > > > > > > > > By use of several 'RedirectSink' LFBs and several > > > > > 'RedirectTap' LFBs that connect to several > different > > > > > datapaths in FE forwarding plane, multiple packet > > > > > redirect paths between CE and FE can be > constructed. > > > > > > > > > > Thought 2: There might be another way a packet could be > > > > > redirected: directly by a forwarding path, > e.g., by > > > > > FPGA/ASIC/NP microcode. In such a case we do not > > > > > need to put in a lot of smartness. Probably > a link > > > > > layer or even network level header is > enough. The > > > > > receiver demuxes it only based on some > protocol type > > > > > in the link layer or network transport > layer. The > > > > > pros for this appraoch is it may provide a > fast and > > > > > cost-effective path for packet redirect. The > cons > > > > > for this is it may more or less confuses the Fp > > > > > reference point definition in ForCES framework. > > > > > > > > > >---------- > > > > >category: Editorial > > > > >draft: draft-ietf-forces-protocol > > > > >messages: 49 > > > > >nosy: avri > > > > >priority: Must fix > > > > >status: No discussion > > > > >title: Packet Redirect > > > > > > > > > >___________________________________________________ > > > > >Forces issue tracker > <tracker-forces@mip4.org> > > > > > > > > > >___________________________________________________ > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 13:38:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmxYh-0002Ha-PH for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 13:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17262 for ; Mon, 27 Jun 2005 13:38:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmxxp-0004cg-Ek for forces-archive@IETF.ORG; Mon, 27 Jun 2005 14:04:14 -0400 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.0109013B@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 13:38:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77056496 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 13:38:03 -0400 Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 13:38:02 -0400 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 j5RHc0Q7022435; Mon, 27 Jun 2005 17:38: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 j5RHc0YB011379; Mon, 27 Jun 2005 17:38:00 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 M2005062710375925980 ; Mon, 27 Jun 2005 10:37:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 10:37:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57B3E.F5D58C09" Thread-Topic: Question about the FE Model Thread-Index: AcV7GHXREw/9iCb9TAOY7c2Vk3InJAAJkYTQ X-OriginalArrivalTime: 27 Jun 2005 17:37:59.0979 (UTC) FILETIME=[F64457B0:01C57B3E] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E05CE9822@orsmsx408> Date: Mon, 27 Jun 2005 10:37:58 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Question about the FE Model Comments: To: louati To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.9 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. ------_=_NextPart_001_01C57B3E.F5D58C09 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this scenario is very much possible and would be a way to implement = an extensible software router. =20 regards Hormuzd p.s. copying the ForCES list in case anyone from the FE Model team would = like to add to my comment. ________________________________ From: louati [mailto:wajdi.louati@int-evry.fr]=20 Sent: Monday, June 27, 2005 6:03 AM To: Khosravi, Hormuzd M Subject: Question about the FE Model Dear Khosravi, =20 I have a question about the FE model (Software/Hardware) implementation = . CE functions are typically performed in software running on a = general-purpose CPU, while FEs can be based on a variety of different = hardware platforms such as ASICs, FPGAs and network processors. Is it possible that these FEs are also performed in software running on = a general-purpose CPU ? I mean the FE Model is executed by a software = forwarding path (like Click, scott ....). In fact, ForCES provides mechanisms to realize a distributed router. = Assuming that two PC based linux are connected via a gigabit network = link. The first one integrates the control plane and the second PC = implements only the Forwarding Plane (Software Forwarding PATH such as = Linux forwarding path, Click, Scott ... rather than the use of the = Network Processor). Of course, the ForCES protocol exchanges messages = between the two PCs. Is this scenario possible? Can we consider this architecture as a = software based router ?=20 Thank you in advance for your answers. Best Regards, Wajdi _________________________________ Wajdi LOUATI Wireless Networks and Services Group=20 Wireless Networks and Multimedia Services Department Institut National des T=E9l=E9communications 9 rue Charles Fourier 91011 EVRY Cedex, France Phone : 331 60 76 45 84 Fax : 331 60 76 45 78 e-mail : wajdi.louati@int-evry.fr ________________________________ ------_=_NextPart_001_01C57B3E.F5D58C09 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Yes, this scenario is very much possible and = would be a way=20 to implement an extensible software router.
 
regards
Hormuzd
p.s. copying the ForCES list in ca= se anyone from the FE Model team would like&nbs= p;to add to my comment.
From: louati = [mailto:wajdi.louati@int-evry.fr]=20
Sent: Monday, June 27, 2005 6:03 AM
To: Khosravi, = Hormuzd=20 M
Subject: Question about the FE Model

Dear Khosravi,
 
I have a question about the FE model=20 (Software/Hardware) implementation .

CE functions are typically performed in = software=20 running on a general-purpose CPU, while FEs can be based on a variety of = different hardware platforms such as ASICs, FPGAs and network=20 processors.

Is it possible that these FEs are also = performed in software = running on a=20 general-purpose CPU ? I mean the FE Model is executed by a software = forwarding=20 path (like Click, scott =85.).

In fact, ForCES provides mechanisms to = realize a=20 distributed router. Assuming that two PC based linux are connected via a = gigabit=20 network link. The first one integrates the control plane and the second = PC=20 implements only the Forwarding Plane (Software Forwarding PATH such as = Linux=20 forwarding path, Click, Scott =85 rather than the use of the Network = Processor).=20 Of course, the ForCES protocol exchanges  messages between the = two=20 PCs.

Is this scenario possible? Can we = consider this=20 architecture as a software based router ?

Thank you in advance for your = answers.

Best Regards,

Wajdi

_________________________________
Wajdi=20 LOUATI
Wireless Networks and Services Group
Wireless Networks and = Multimedia Services Department
Institut National des = T=E9l=E9communications
9=20 rue Charles Fourier
91011 EVRY Cedex, France
Phone : 331 60 76 45=20 84
Fax : 331 60 76 45 78
e-mail : wajdi.louati@int-evry.fr
= ________________________________
------_=_NextPart_001_01C57B3E.F5D58C09-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 21:57:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn5Lf-0000Er-Fm for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 21:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22486 for ; Mon, 27 Jun 2005 21:57:12 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn5ks-0004Ex-Pv for forces-archive@IETF.ORG; Mon, 27 Jun 2005 22:23:21 -0400 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.01090A48@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 21:57:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77096733 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 21:57:05 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 21:57:02 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.2305915701; Tue, 28 Jun 2005 10:33:31 +0800 (CST) References: <1116786905.33.0.544707347688.issue32@mip4.org> <004b01c579f9$d5fb21f0$020aa8c0@wwm1> <6.2.1.2.0.20050625233944.02eccfe0@localhost> <109201c57a2b$79b0f5f0$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050626094409.02ec5e18@localhost> <000c01c57b20$acce0540$020aa8c0@wwm1> <6.2.1.2.0.20050627112010.02e94f50@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: <002101c57b84$aa5d2de0$020aa8c0@wwm1> Date: Tue, 28 Jun 2005 09:56:56 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: base64 Sm9lbCwNCg0KPiAgICAgIFRoZSBQYWNrZXQgUmVkaXJlY3QgbWVzc2FnZSBjb250YWlucyBvbmUg b3IgbW9yZSAodHlwaWNhbGx5IG9uZSkgDQo+IHBhY2tldC1yZWRpcmVjdCBUTFZzLg0KDQpJZiBJ IHVuZGVyc3RhbmQgeW91ciBhYm92ZSB0aG91Z2h0IGNvcnJlY3RseSwgSSB0aGluayB5b3VyIHBy b3Bvc2FsICBpcyB0byBkZWZpbmUgYSAgcGFja2V0LXJlZGlyZWN0IFRMViByYXRoYW4gdGhhbiBh IExGQnNlbGVjdFRMViBhdCB0aGUgdG9wIGxldmVsIGZvciB0aGUgbWVzc2FnZS4gSW4gdGhpcyB3 YXkgaXQgd2lsbCBsZWF2ZSBMRkIgc2VsZWN0aW9uIGluZm9ybWF0aW9uIGFzIGtpbmRzIG9mIG1l dGEtaW5mbyBhbmQgaW5zaWRlIHRoZSBUTFYsIHNvbWV0aGluZyBsaWtlOg0KDQo+ID4gICAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgVHlwZSA9IFBhY2tldC1SZWRpcmVjdCAg ICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQo+ID4gICAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElE ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAg ICAgICAgICAgICAgfA0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICBPcGVyYXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+ID4gICAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLg0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KTm93LCB0aGUg cXVlc3Rpb24gaXMgSSBkbyBmaW5kIHRoaXMgZm9ybWF0IGlzIG5vdCB2ZXJ5IGRpZmZlcmVudCB3 aXRoIHRoYXQgSSBwcm9wb3NlZC4gRG8gSSBtaXNzIHNvbWV0aGluZz8NCg0KVGhhbmtzLA0KV2Vp bWluZw0KDQoNCj4gSSB3b3VsZCBhcHByb2FjaCB0aGlzIGRpZmZlcmVudGx5LiAgVGhlIGN1cnJl bnQgdGV4dCBkZXNjcmliZXMgdGhlIA0KPiBMRkJzZWxlY3QgTEZCLiAgSXQgY29ycmVjdGx5IGRl ZmluZXMgdGhlIExGQnNlbGVjdCBMRkIuICBUaGF0IGRlZmluaXRpb24gDQo+IHNob3VsZCBub3Qg YmUgdGhyb3duIGF3YXkuDQo+IA0KPiBUaGUgbWVzc2FnZSBzdHJ1Y3R1cmUgZG9jdW1lbnRhdGlv biBjYW4gc2F5DQo+ICAgICBBIFBMIHByb3RvY29sIG1lc3NhZ2VzIGNvbnNpc3RzIG9mIGEgcHJv dG9jb2wgaGVhZGVyIGZvbGxvd2VkIGJ5IG9uZSBvciANCj4gbW9yZSBUTFZzLiAgQWxsIFRMVnMN Cj4gICAgIGNvbnNpc3Qgb2YgIHR3byBieXRlIHR5cGUgYW5kIGEgdHdvIGJ5dGUgbGVuZ3RoLCBm b2xsb3dlZCBieSBjb250ZW50cyANCj4gZGVwZW5kZW50IHVwb24gdGhlIHR5cGUNCj4gICAgIG9m IHRoZSBUTFYuICBUaGUgVExWcyB3aGljaCBhcmUgdmFsaWQgaW4gYSBtZXNzYWdlIGRlcGVuZCB1 cG9uIHRoZSANCj4gbWVzc2FnZSB0eXBlLg0KPiAgICAgTW9zdCBtZXNzYWdlIHR5cGVzIGFsbG93 IG9uZSBvciBtb3JlIExGQnNlbGVjdCBUTFZzIGFuZCBubyBvdGhlciB0b3AgDQo+IGxldmVsIFRM VnMuICBUaGUNCj4gICAgIGZvbGxvd2luZyBhcmUgdGhlIG1lc3NhZ2UgdHlwZXMgdGhpcyBhcHBs aWVzIHRvOg0KPiAgICAgICAgQXNzb2NpYXRpb24gc2V0dXAgcmVxdWVzdCBhbmQgcmVzcG9uc2Uu DQo+ICAgICAgICBDb25maWcgbWVzc2FnZSByZXF1ZXN0IGFuZCByZXNwb25zZQ0KPiAgICAgICAg UXVlcnkgbWVzc2FnZSByZXF1ZXN0IGFuZCByZXNwb25zZQ0KPiAgICAgICAgRXZlbnQgTm90aWZ5 IG1lc3NhZ2UuDQo+ICAgICBUaGUgQXNzb2NpYXRpb24gdGVhcmRvd24gbWVzc2FnZSBjb250YWlu cyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUgDQo+IHRlYXJkb3duLWNhdXNlIFRMVi4NCj4gICAg IFRoZSBoZWFydGJlYXQgbWVzc2FnZSBjb250YWlucyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUg aGVhdHJiZWF0IA0KPiBUTFYuICAoVW5sZXNzIHdlIGRlY2lkZQ0KPiAgICAgIHRvIGp1c3QgdXNl IGFuIGV2ZW50IGZvciBoZWFydGJlYXRzLiAgSSBkb24ndCByZW1lbWJlciB3aGVyZSB0aGF0IA0K PiBkaXNjdXNzaW9uIHN0YW5kcy4pDQo+ICAgICAgVGhlIFBhY2tldCBSZWRpcmVjdCBtZXNzYWdl IGNvbnRhaW5zIG9uZSBvciBtb3JlICh0eXBpY2FsbHkgb25lKSANCj4gcGFja2V0LXJlZGlyZWN0 IFRMVnMuDQo+IFRoaXMgaXMgdGhlbiBmb2xsb3dlZCBieSBhIHNlY3Rpb24gZm9yIGVhY2ggb2Yg dGhlc2UgdG9wIGxldmVsIFRMVnMuDQo+IA0KPiBZb3VycywNCj4gSm9lbCBNLiBIYWxwZXJuDQo+ IA0KPiBBdCAxMDowMSBBTSA2LzI3LzIwMDUsIFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPkpvZWwg OikNCj4gPg0KPiA+SG93IGFib3V0IHdlIGp1c3Qgb2Jzb2xldGUgdGhlIHBhdGggZnJvbSB0aGUg ZGF0YSBzdHJ1Y3R1cmUgYW5kIGFkZCBzb21lDQo+ID5tZXRhLWluZm9ybWF0aW9uLCBhbmQgZm9y bSB0aGUgZm9ybWF0IGFzIGJlbG93IChJIGN1cnJlbnRseSBjYW4gb25seSB0aGluaw0KPiA+b2Yg dGhlIG1ldGEtaW5mb3JtYXRpb24gYXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIHNvbWUg bW9yZSBsYXRlcikuDQo+ID4NCj4gPkNvdWxkIHlvdSBnaXZlIG1vcmUgY29tbWVudHMgb24gdGhp cywgdGhlbiB3ZSBtYXkgc29sdmUgdGhpcyBpc3N1ZSBzb29uPw0KPiA+DQo+ID5UaGFuayB5b3Ug dmVyeSBtdWNoLg0KPiA+DQo+ID5XZWltaW5nDQo+ID4NCj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+TWVzc2FnZSBCb2R5Og0KPiA+ICAgICAgIENvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFRM VnMsIHdpdGggZXZlcnkgVExWIGhhdmluZyB0aGUgZm9sbG93aW5nDQo+ID4gICAgICAgZGF0YSBm b3JtYXQ6DQo+ID4NCj4gPiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g PiAgICAgICAgIHwgICAgICAgIFR5cGUgPSBMRkJzZWxlY3QgICAgICAgfCAgICAgICAgICAgICAg IExlbmd0aCAgICAgICAgICB8DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAg ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVy YXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICAgICAgICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lg0KPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgIH4gICAgICAgICAgICAgICAgICAg ICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+DQo+ID4gICAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlv biBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgIC4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQo+ ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiA+DQo+ID4gICAgTEZCIGNsYXNzIElEOg0KPiA+ICAgICAg IFRoZXJlIGFyZSBvbmx5IHR3byBwb3NzaWJsZSBMRkIgY2xhc3NlcyBoZXJlLCB0aGUgJ1JlZGly ZWN0U2luaycNCj4gPiAgICAgICBMRkIgb3IgdGhlICdSZWRpcmVjdFNvdXJjZScgTEZCLiAgSWYg dGhlIG1lc3NhZ2UgaXMgZnJvbSBGRSB0byBDRSwNCj4gPiAgICAgICB0aGUgTEZCIGNsYXNzIHNo b3VsZCBiZSAnUmVkaXJlY3RTaW5rJy4gIElmIHRoZSBtZXNzYWdlIGlzIGZyb20gQ0UNCj4gPiAg ICAgICB0byBGRSwgdGhlIExGQiBjbGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0U291cmNlJy4NCj4g PiAgICBJbnN0YW5jZSBJRDoNCj4gPiAgICAgICBJbnN0YW5jZSBJRCBmb3IgdGhlICdSZWRpcmVj dFNpbmsnIExGQiBvciAnUmVkaXJlY3RTb3VyY2UnIExGQi4NCj4gPiAgICBPcGVyYXRpb24gVExW Og0KPiA+ICAgICAgIFRoaXMgaXMgYSBUTFYgZGVzY3JpYmluZyBvbmUgcGFja2V0IG9mIGRhdGEg dG8gYmUgZGlyZWN0ZWQgdmlhIHRoZQ0KPiA+ICAgICAgIHNwZWNpZmllZCBMRkIgYWJvdmUuICBU aGUgb3JkZXIgb2YgdGhlIFRMViBhcHBlYXJlZCBpcyBhbHNvIHRoZQ0KPiA+ICAgICAgIG9yZGVy IHRoZSBkYXRhIHBhY2tldCBhcnJpdmVzIHRoZSByZWRpcmVjdG9yIExGQiwgdGhhdCBpcywgdGhl DQo+ID4gICAgICAgUmVkaXJlY3RlZCBEYXRhICBpbiB0aGUgZmlyc3QgVExWIHNob3VsZCBhcnJp dmUgdGhlIGVhcmxpZXN0Lg0KPiA+DQo+ID5UaGUgVExWIGZvcm1hdCBpcyBhcyBmb2xsb3dzOg0K PiA+DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgICAgfCAgICBUeXBlID0gUEFZTE9B RCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gPiAgICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+ID4gICAgICAgICB+ICAgICAgICAgUGFja2V0IFR5cGUgICAgICAgICAg IHwgICAgICAgICBQYWNrZXQgTGVuZ3RoICAgICAgICAgfg0KPiA+ICAgICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gPiAgICAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdGVkIFBhY2tldCAg ICAgICAgICAgICAgICAgICAgICB+DQo+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+DQo+ID4gICAg IFR5cGU6DQo+ID4gICAgICAgVGhlIHR5cGUgZm9yIHRoZSBUTFYgaXMgc2V0IHRvICdQQVlMT0FE Jy4NCj4gPg0KPiA+ICAgICBMZW5ndGg6DQo+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgVExW KGluIDRieXRlcykuDQo+ID4NCj4gPiAgICAgUGFja2V0IFR5cGU6DQo+ID4gICAgICAgRGVmaW5l cyB3aGF0IHR5cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaCBhcyAnSVB2 NCANCj4gPiBQYWNrZXQnLA0KPiA+ICAgICAgJ0lQdjYgUGFja2V0JykuDQo+ID4NCj4gPiAgICAg UGFja2V0IExlbmd0aDoNCj4gPiAgICAgICB0aGUgbGVuZ3RoIG9mIHRoZSBmb2xsb3dlZCByZWRp cmVjdGVkIHBhY2tldCAoaW4gYnl0ZSkNCj4gPg0KPiA+ICAgICBSZWRpcmVjdGVkIFBhY2tldDoN Cj4gPiAgICAgICBvbmUgcmVkaXJlY3RlZCBwYWNrZXQuDQo+ID4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+DQo+ID4NCj4gPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4g PkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDw8bWFpbHRvOmpvZWxAc3RldmVjcm9ja2VyLmNvbT5q b2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+ID4NCj4gPiA+IEkgd291bGQgZXhwZWN0IHRoYXQgYSBS ZWRpcmVjdCBNZXNzYWdlIGhhcyBhIGRpZmZlcmVudCBvdXRlcm1vc3QgVExWLiAgVGhlDQo+ID4g PiBncmFtbWFyIGlzIGludGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcyBhIHN0cmFpZ2h0 amFja2V0LiAgRGlmZmVyZW50DQo+ID4gPiBtZXNzYWdlIHR5cGVzIGNhbiBoYXZlIGRpZmZlcmVu dCBvdXRlciBUTFZzLiAgSXQgaXMgZGVzaXJhYmxlIHRvIHVzZSB0aGUNCj4gPiA+IHNhbWUgc3Ry dWN0dXJlIHdoZW4gaXQgYXBwbGllcy4gIEJ1dCB0aGUgcmVkaXJlY3QgbWVzc2FnZSBpcyBzaW1w bHkgYQ0KPiA+ID4gZGlmZmVyZW50IGNhc2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQVRB UkFXIG11Y2ggbGVzcyBhIERBVEEgDQo+ID4gVExWLiAgSXRzDQo+ID4gPiBjb250ZW50IHN0cnVj dHVyZSBpcyBub3QgZGVmaW5lZCBieSBhbiBMRkIgZWxlbWVudCBkZWZpbml0aW9uIG9yIE1vZGVs DQo+ID4gPiBEYXRhRGVmcyBzdHJ1Y3R1cmUgZGVmaW5pdGlvbi4NCj4gPiA+DQo+ID4gPiBJZiB3 ZSBuZWVkIHRvIGZpeCB0aGUgImdyYW1tYXIiIHNlY3Rpb24gdG8gbWFrZSBpdCBjbGVhciB0aGF0 IG5vdCBhbGwgUEwNCj4gPiA+IG1lc3NhZ2VzIG5lY2Vzc2FyaWx5IHVzZSB0aGUgc2FtZSBvdXRl cm1vc3QgVExWLCB3ZSBzaG91bGQgZG8gc28uICAgTXkgb3duDQo+ID4gPiBhcHByb2FjaCB3b3Vs ZCBiZSB0byBzZXBhcmF0ZSB0aGUgZ3JhbW1hciBpbnRvIGEgZGVmaW5pdGlvbiBvZiB0aGUgDQo+ ID4gY29udGVudHMNCj4gPiA+IG9mIHRoYXQgVExWLCBhbmQgYSBzZXBhcmF0ZSBkZWZpbml0aW9u IG9mIHdoaWNoIFRMVnMgLyBjb250ZW50IGFyZSBjYXJyaWVkDQo+ID4gPiBpbiB0aGUgb3V0ZXJt b3N0IGxldmVsIG9mIHdoaWNoIG1lc3NhZ2VzLg0KPiA+ID4NCj4gPiA+IFlvdXJzLA0KPiA+ID4g Sm9lbA0KPiA+ID4NCj4gPiA+IFBTOiBXZWltaW5nLCBJIGFtIHNvcnJ5IHlvdSBnb3QgY2F1Z2h0 IHVwIGluIHRoaXMgY29uZnVzaW9uLiAgSSBkb24ndCANCj4gPiB0aGluaw0KPiA+ID4geW91IGNy ZWF0ZWQgdGhlIHRlbmRlbmN5IEkgYW0gcmFpbGluZyBhZ2FpbnN0IGFib3ZlLiAgSSBhbSBqdXN0 IHVzaW5nIHlvdXINCj4gPiA+IG1lc3NhZ2UgYXMgYSBzdGFydGluZyBwb2ludCB0byBoYW1tZXIg aG9tZSBhIHBvaW50Lg0KPiA+ID4NCj4gPiA+IEF0IDA0OjQ1IEFNIDYvMjYvMjAwNSwgV2FuZyxX ZWltaW5nIHdyb3RlOg0KPiA+ID4gPk1heWJlIGl0J3MgbWUgd2hvIG1pc3NlZCBzb21ldGhpbmcg OikNCj4gPiA+ID5NeSB0aG91Z2h0IHdhcyB3ZSBtaWdodCBuZWVkIHRvIG9iZXkgb3VyIG1lc3Nh Z2UgZ3JhbW1hciB3ZWxsIHRoYXQgd2UgDQo+ID4gaGF2ZQ0KPiA+ID4gPnRvIHVzZSBhIHN0cmlj dCBQYXRoLWRhdGEgZm9yIG9wZXJhdGlvbiBUTFYuICBUbyBvYmV5IHRoZSBydWxlLCB0cmVhdGlu Zw0KPiA+ID4gPml0IGFzIGFuIGV2ZW50IHdpbGwgZWFzZSB0aGUgbWVzc2FnZSBmb3JtYXQgZ3Jl YXRseS4NCj4gPiA+ID4NCj4gPiA+ID5BY3R1YWxseSBJJ20gdmVyeSBoYXBweSB0byBzZWUgdGhh dCB5b3UgYWdyZWUgYSBwYXRoIGNhbiBiZSBvbWl0dGVkIGZvcg0KPiA+ID4gPnNvbWUgc3BlY2lm aWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4gPiA+DQo+ID4gPiA+T0ssIGxl dCdzIHNvbHZlIGl0IHRoZW4sIHRvIGxldCByZWRpcmVjdCBtZXNzYWdlIG9ubHkgY29udGFpbiBE YXRhDQo+ID4gPiA+ZmllbGQ/ICBJIGNhbiB1cGRhdGUgdGhpcyByZWRpcmVjdCBtZXNzYWdlIHBh cnQgdGV4dCB0aGVuLg0KPiA+ID4gPg0KPiA+ID4gPkphbWFsLCBjb3VsZCB5b3UgZ2l2ZSBhIHJl c3BvbnNlIG9uIHRoaXM/DQo+ID4gPiA+DQo+ID4gPiA+T25lICBsZXNzIHZpdGFsIHF1ZXN0aW9u IGlzLCBzaGFsbCB3ZSBhbGxvdyBmb3IgbXVsaXRwdWwgcmVkaXJlY3QgcGFja2V0cw0KPiA+ID4g PmVuY2Fwc3VsYXRlZCBpbiBvbmUgVExWIG9yIGp1c3Qgb25lIFRMViBvbmx5IGZvciBvbmUgcGFj a2V0PyBUbyB1c2UgdGhlDQo+ID4gPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmluZSBhIHNlcXVl bmNlIGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIHRoZW4gaW4NCj4gPiA+ID50aGUgVExWLg0K PiA+ID4gPg0KPiA+ID4gPk9uICB0aGUgbWV0YS1pbmZvcm1hdGlvbiByZWxhdGVkLCBJIHRoaW5r IExGQiBJRHMgaGFzIGFscmVhZHkgYmVlbg0KPiA+ID4gPmluY2x1ZGVkLiBJIGRvbid0IHRoaW5r IHdlIG5lZWQgYW4gZXh0cmEgcG9ydCBJRCB0byBpbmRpY2F0ZSB3aGVyZSB0byBwdXQNCj4gPiA+ ID50aGUgcmVkaXJlY3RlZCBkYXRhIHRvIG9yIHRvIGdldCByZWRpcmVjdGVkIGRhdGEgZnJvbS4g QSByZWRpcmVjdCBzb3VyY2UNCj4gPiA+ID5MRkIgIG9yIHNpbmsgTEZCIHdpbGwgIGhhdmUgYSBw b3J0IElELCB3aGljaCBiZWxvbmdzIHRvIEZFIExGQiB0b3BvbG9neQ0KPiA+ID4gPmNvbmNlcHQs IGFuZCBGRSBMRkIgdG9wb2xneSBjb25maWd1cmF0aW9uIGlzIGluIGNoYXJnZSBvZiB0aGlzLiAg Tm90IHN1cmUNCj4gPiA+ID5pZiBpdCBjb21wbGllcyB3aXRoIHlvdXIgdGhvdWdodD8NCj4gPiA+ ID4NCj4gPiA+ID5UaGFua3MsDQo+ID4gPiA+V2VpbWluZw0KPiA+ID4gPg0KPiA+ID4gPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID5Gcm9tOiAiSm9lbCBNLiBIYWxwZXJuIg0K PiA+ID4gPlN1YmplY3Q6IFJlOiBbaXNzdWUzMl0gUGFja2V0IFJlZGlyZWN0DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3Rp b24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaHkgd291bGQgd2Ugd2FudCB0byB0cmVhdCByZWRp cmVjdHMgYXMgZXZlbnRzPw0KPiA+ID4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGly ZWN0cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCAiSG93 IGEgcGF0aCBzaG91bGQgYmUgZGVmaW5lZCBpbiBhIFBhY2tldA0KPiA+ID4gPiBSZWRpcmVjdA0K PiA+ID4gPiA+IE1lc3NhZ2UiLCBzaW5jZSBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgYSByZWRpcmVj dCBkb2VzIG5vdCBuZWVkIGEgDQo+ID4gcGF0aC4gIEl0DQo+ID4gPiA+ID4gbmVlZHMgYSBjb2xs ZWN0aW9uIG9mIG1ldGEtaW5mb3JtYXRpb24sIHdoaWNoIHdlIG5lZWQgdG8gDQo+ID4gZGVmaW5l LiAgQXQgdGhlDQo+ID4gPiA+ID4gbW9tZW50LCB0aGF0IGhhcyB0byBpbmNsdWRlIGF0IGxlYXN0 IHRoZSBMRkIgSUQgdGhhdCB0aGUgcmVkaXJlY3QgaXMNCj4gPiA+ID4gZnJvbSAvDQo+ID4gPiA+ ID4gdG8uICBJIHN1cHBvc2UgYnkgZGVjbGFyaW5nIGEgbXVsdGlwbGljaXR5IG9mIHN1Y2ggTEZC cywgdGhhdCBjYW4gYmUNCj4gPiA+ID4gYWxsIG9mDQo+ID4gPiA+ID4gdGhlIGluZm9ybWF0aW9u LiAgKEkgdXN1YWxseSB0aGluayBpbiB0ZXJtcyBvZiBhdCBsZWFzdCBhIGxvZ2ljYWwgDQo+ID4g cG9ydCBJRA0KPiA+ID4gPiA+IHRoZSBwYWNrZXQgY2FtZSBmcm9tIC8gaXMgaW50ZW5kZWQgZm9y LikNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFlvdXJzLA0KPiA+ID4gPiA+IEpvZWwNCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IEF0IDEwOjUwIFBNIDYvMjUvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOg0K PiA+ID4gPiA+ID5KYW1hbCwgSm9lbCwgYW5kIEhvcm16ZCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ ID4gPkkgc3VwcG9zZSB3ZSBjb3VsZCBjbG9zZSB0aGlzIGlzc3VlIGJ5IHJlYWNoaW5nIHRoZSBm b2xsb3dpbmcgcG9pbnRzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+MS4gVGhlIHJlZGlyZWN0 IExGQnMgY2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luayANCj4gPiBM RkIgYXJlDQo+ID4gPiA+ID4gPm1vdmVkIHRvIHRoZSBtb2RlbCwgYnV0IHRoZSBwcm90b2NvbCBy ZXRhaW5zIHRoZSBSZWRpcmVjdCBNZXNzYWdlLiBUaGUNCj4gPiA+ID4gPiA+cmVhc29uIHRvIGtl ZXAgdGhlIHNwZWNpZmljIG1lc3NhZ2UgaXMgd2UgbmVlZCB0byBzcGVjaWZpY2FsbHkgDQo+ID4g cmVjb2duaXplDQo+ID4gPiA+ID4gPnJlZGlyZWN0ZWQgZGF0YSBiZXR3ZWVuIENFLUZFIHRyYW5z cG9ydGF0aW9uIHRvIGF2b2lkIERvUyBhdHRhY2tzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ Mi4gVGhlIHJlZGlyZWN0ZWQgZGF0YSBpbiB0aGUgTEZCcyBjYW4gYmUgdHJlYXRlZCBhcyBhIGtp bmQgb2YgU1BFQ0lBTA0KPiA+ID4gPiA+ID5ldmVudHMgaW4gdGhhdDoNCj4gPiA+ID4gPiA+ICAg ICAgYS4gVGhlIGV2ZW50IGlzIHRyaWdnZXJlZCBldmVyeSB0aW1lIGEgbmV3IHJlZGlyZWN0ZWQg cGFja2V0DQo+ID4gPiA+IGFycml2ZXMNCj4gPiA+ID4gPiA+IGF0IHRoZSBMRkJzLg0KPiA+ID4g PiA+ID4gICAgICBiLiBUaGUgZXZlbnQgaXMgdHJhbnNwb3J0ZWQgYnkgdGhlIFJlZGlyZWN0ICBN ZXNzYWdlIG9ubHksIA0KPiA+IHdoaWxlDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ID4gUmVkaXJl Y3QgTWVzc2FnZSB3aWxsIHRoZSBzYW1lIG1lc3NhZ2UgZm9ybWF0IGFzIGEgZ2VuZXJhbCBldmVu dA0KPiA+ID4gPiA+ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2UgKGV4Y2VwdCB0aGUgbWVzc2FnZSB0 eXBlIGluIHRoZSBoZWFkZXIpLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+QnkgZG9pbmcgaW4g dGhpcyB3YXksIHdlIGNhbiBhbHNvIHNvbHZlIHRoZSBpc3N1ZTUzIChIb3cgYSBwYXRoIA0KPiA+ IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID5kZWZpbmVkICBpbiBQYWNrZXQgUmVkaXJlY3QgTWVzc2Fn ZSkgdGhlbi4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPlVuZm9ydHVuYXRlbHksICBJIHRoaW5r IG9mIGFub3RoZXIgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSANCj4gPiBQYWNrZXQN Cj4gPiA+ID4gPiA+UmVkaXJlY3QgTWVzc2FnZSBhcyB3ZWxsIGFzIHRvIEV2ZW50IE5vdGlmaWNh dGlvbiBNZXNzYWdlLiBUaGUgDQo+ID4gcXVlc3Rpb24NCj4gPiA+ID4gPiA+aXMsIHRoZSBFdmVu dCBOb3RpZmljYXRpb24gTWVzc2FnZSBhbGxvd3MgZXZlbnQgZ2VuZXJhdGVkIGJ5IENFIA0KPiA+ IGFuZCBzZW50DQo+ID4gPiA+ID4gPnRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3NhZ2Ug Zm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0byANCj4gPiB0aGUgTEZCcw0KPiA+ID4gPiA+ID50 aGF0IHdpbGwgcmVjZWl2ZSB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLCBidXQgdGhlIHF1ZXN0aW9u IGlzLCANCj4gPiB3aGF0IHRoZQ0KPiA+ID4gPiA+ID5QYXRoIGluIHRoZSBtZXNzYWdlIHJlZmVy cyB0byB0aGVuID8/ICBUaGUgc2FtZSBhbHNvIGhhcHBlbnMgdG8gUGFja2V0DQo+ID4gPiA+ID4g PlJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0byBGRS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PlRoYW5rcywNCj4gPiA+ID4gPiA+V2VpbWluZw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPiA+ID5Gcm9tOiAiQXZyaSBEb3JpYSIg DQo+ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZXNAbWlw NC5vcmc+DQo+ID4gPiA+ID4gPlRvOiA8PG1haWx0bzpGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5D T00+Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0KPiA+ID4gPiA+ID5TZW50OiBNb25kYXks IE1heSAyMywgMjAwNSAyOjM1IEFNDQo+ID4gPiA+ID4gPlN1YmplY3Q6IFtpc3N1ZTMyXSBQYWNr ZXQgUmVkaXJlY3QNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID5OZXcgc3Vi bWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgPDxtYWlsdG86YXZyaUBhY20ub3JnPmF2cmlAYWNtLm9y Zz46DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID42LjgNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiAgRWRpdG9yaWFsIE5vdGU6ICBUaGVyZSBhcmUgYWxzbyBkaXNjdXNzaW9ucyBvbiBob3cgTEZC cyBpbiBGRSBtb2RlbA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0aGF0IGFyZSBy ZWxhdGVkIHRvIHBhY2tldCByZWRpcmVjdCBvcGVyYXRpb25zDQo+ID4gPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgIHNob3VsZCBiZSBkZWZpbmVkLiAgQWx0aG91Z2ggaXQgaXMgb3V0IG9mIHRo ZSANCj4gPiBzY29wZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBvZiBmb3JjZXMg cHJvdG9jb2wsIGhvdyB0byBkZWZpbmUgdGhlIExGQnMgYWZmZWN0DQo+ID4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkZXNjcmliZWQgDQo+ ID4gaGVyZS4gIEJlY2F1c2UNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY3VycmVu dGx5IGl0IGlzIHN0aWxsIGluIHByb2dyZXNzIGluIEZFIG1vZGVsIA0KPiA+IG9uIGhvdw0KPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICB0byBkZWZpbmUgc3VjaCBMRkJzLCB3ZSB0cnkg dG8gcG9zdCBzb21lIA0KPiA+IHRob3VnaHRzIG9uDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4gIFRoZXkgd2lsbCBiZSByZW1vdmVkDQo+ ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxhdGVyIGFsb25nIHdpdGggdGhlIHByb2dy ZXNzIG9mIHRoZSBGRSBtb2RlbCANCj4gPiB3b3JrLg0KPiA+ID4gPiA+ID4gICAgICAgICBUaG91 Z2h0IDE6ICBUbyBkZWZpbmUgTEZCcyBjYWxsZWQgJ1JlZGlyZWN0U2luaycgYW5kDQo+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgICdSZWRpcmVjdFRhcCcgZm9yIHBhY2tldCByZWRpcmVj dC4NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZCAn UmVkaXJlY3RTaW5rJyBpcyANCj4gPiByZXNwb25zaWJsZSB0bw0KPiA+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICBjb2xsZWN0IGRhdGEgcGFja2V0cyB0aGF0IG5lZWQgdG8gYmUgDQo+ID4g cmVkaXJlY3RlZCB0bw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBDRS4gIEZyb20g dGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksDQo+ID4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdGggb25s eSANCj4gPiBvbmUgaW5wdXQNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcG9ydCBh bmQgd2l0aG91dCBhbnkgb3V0cHV0IHBvcnQsIGFuZCB0aGUgDQo+ID4gaW5wdXQgcG9ydA0KPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8gYW55 IG90aGVyIExGQiBpbiBGRSANCj4gPiBtb2RlbA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUg Rm9yQ0VTIHByb3RvY29sIA0KPiA+IGxheWVyLA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIHdpbGwgZ2VuZXJhdGUgdGhlIFBhY2tldA0KPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aGVuIGl0IHJl Y2VpdmVzIGRhdGEgDQo+ID4gcGFja2V0cyBmcm9tDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgIGZvcndhcmRpbmcgcGxhbmUuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcCcgaXMgDQo+ID4g cmVzcG9uc2libGUgdG8NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVjZWl2ZSBk YXRhIHBhY2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLg0KPiA+ID4gPiA+ID4gICAg ICAgICAgICAgICAgICAgICBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9s b2d5LCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBM RkIgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgb3V0cHV0DQo+ID4gPiA+ID4gPiAgICAgICAgICAg ICAgICAgICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0IHBvcnQsIGFuZCB0aGUgDQo+ID4g b3V0cHV0IHBvcnQNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY2FuIHRoZW4gYmUg Y29ubmVjdGVkIHRvIGFueSBvdGhlciBMRkIgaW4gRkUgDQo+ID4gbW9kZWwNCj4gPiA+ID4gPiA+ ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2Fy ZGluZyBwbGFuZS4NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgRm9yQ0VTIHByb3RvY29sIA0KPiA+IGxheWVyLCB0aGUNCj4gPiA+ID4gPiA+ ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgY2FuIHJlY2VpdmUgdGhlIFBh Y2tldCBSZWRpcmVjdA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcyBm cm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdGUgdGhlIGRhdGENCj4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgdGhlbSB0byANCj4g PiBkYXRhcGF0aHMNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgaW4gdGhlIGZvcndh cmRpbmcgcGxhbmUuICBBY3R1YWxseSB0aGUgDQo+ID4gJ1JlY2lyZWN0VGFwJw0KPiA+ID4gPiA+ ID4gICAgICAgICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0cmFuc2NvZGVyIHRo YXQgDQo+ID4gdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBG b3JDRVMgcHJvdG9jb2wgbWVzc2FnZXMgdG8gbm9ybWFsIGRhdGEgDQo+ID4gcGFja2V0cyBpbg0K PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBJUCBmb3J3YXJkaW5nIHBsYW5lLiAgQXMg YSByZXN1bHQsIGlmIHdlIG5lZWQgdG8NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAg aGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUgTEZCIA0KPiA+IChzYXkg YQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBTY2hlZHVsZXIpIGluIEZFIG1vZGVs LCB3ZSBvbmx5IG5lZWQgdG8gDQo+ID4gY29ubmVjdCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgJ1JlZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIExGQiANCj4gPiBk aXJlY3RseSB2aWEgYQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aCBh cyBmb2xsb3dzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0t LS0tKw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJlZGlyZWN0 VGFwIExGQiB8LS0tLS0tPnwgICAgICAgICAgIHwNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8DQo+ ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBTY2hlZHVsZXIgfA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRnJvbSBvdGhlciBMRkIgICAtLS0tPnwgICAgTEZCICAgIHwNCj4gPiA+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICB8DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjcNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEJ5IHVzZSBvZiBzZXZlcmFs ICdSZWRpcmVjdFNpbmsnIExGQnMgYW5kIHNldmVyYWwNCj4gPiA+ID4gPiA+ICAgICAgICAgICAg ICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIA0KPiA+ IGRpZmZlcmVudA0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aHMgaW4g RkUgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0DQo+ID4gPiA+ID4gPiAgICAgICAg ICAgICAgICAgICAgIHJlZGlyZWN0IHBhdGhzIGJldHdlZW4gQ0UgYW5kIEZFIGNhbiBiZSANCj4g PiBjb25zdHJ1Y3RlZC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAgIFRob3VnaHQg MjogIFRoZXJlIG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0ZWQ6IGRpcmVjdGx5IGJ5IGEgZm9yd2Fy ZGluZyBwYXRoLCANCj4gPiBlLmcuLCBieQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAg ICBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiAgSW4gc3VjaCBhIGNhc2Ugd2UgZG8gbm90DQo+ID4g PiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0 bmVzcy4gIFByb2JhYmx5IA0KPiA+IGEgbGluaw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICBsYXllciBvciBldmVuIG5ldHdvcmsgbGV2ZWwgaGVhZGVyIGlzIA0KPiA+IGVub3VnaC4g IFRoZQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICByZWNlaXZlciBkZW11eGVzIGl0 IG9ubHkgYmFzZWQgb24gc29tZSANCj4gPiBwcm90b2NvbCB0eXBlDQo+ID4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgIGluIHRoZSBsaW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3J0IA0K PiA+IGxheWVyLiAgVGhlDQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHByb3MgZm9y IHRoaXMgYXBwcmFvY2ggaXMgaXQgbWF5IHByb3ZpZGUgYSANCj4gPiBmYXN0IGFuZA0KPiA+ID4g PiA+ID4gICAgICAgICAgICAgICAgICAgICBjb3N0LWVmZmVjdGl2ZSBwYXRoIGZvciBwYWNrZXQg cmVkaXJlY3QuICBUaGUgDQo+ID4gY29ucw0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAg ICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIHRoZSBGcA0KPiA+ID4g PiA+ID4gICAgICAgICAgICAgICAgICAgICByZWZlcmVuY2UgcG9pbnQgZGVmaW5pdGlvbiBpbiBG b3JDRVMgZnJhbWV3b3JrLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+LS0tLS0tLS0tLQ0KPiA+ ID4gPiA+ID5jYXRlZ29yeTogRWRpdG9yaWFsDQo+ID4gPiA+ID4gPmRyYWZ0OiBkcmFmdC1pZXRm LWZvcmNlcy1wcm90b2NvbA0KPiA+ID4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID4gPiA+bm9z eTogYXZyaQ0KPiA+ID4gPiA+ID5wcmlvcml0eTogTXVzdCBmaXgNCj4gPiA+ID4gPiA+c3RhdHVz OiBObyBkaXNjdXNzaW9uDQo+ID4gPiA+ID4gPnRpdGxlOiBQYWNrZXQgUmVkaXJlY3QNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4gPiA+ID5Gb3JjZXMgaXNzdWUgdHJhY2tlciANCj4gPiA8PG1h aWx0bzp0cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz50cmFja2VyLWZvcmNlc0BtaXA0Lm9yZz4NCj4g PiA+ID4gPiA+PGh0dHA6Ly93d3cubWlwNC5vcmcvaXNzdWVzL3RyYWNrZXIvZm9yY2VzL2lzc3Vl MzI+DQo+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPiA+ From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 22:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6Fv-0003MF-0g for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 22:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26385 for ; Mon, 27 Jun 2005 22:55:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn6fB-0001Ab-CI for forces-archive@IETF.ORG; Mon, 27 Jun 2005 23:21:30 -0400 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.0109093C@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 22:55:21 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77100452 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 22:55:20 -0400 Received: from 207.69.195.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 22:55:19 -0400 Received: from user-2ivf94n.dsl.mindspring.com ([165.247.164.151] helo=JMHLap3.stevecrocker.com) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Dn6Fo-0006lE-00 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 22:55:17 -0400 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.20050627225448.02d0efa8@localhost> Date: Mon, 27 Jun 2005 22:55:08 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d The differences are minor. Firstly, I wanted to clarify the general principle of top level TLVs. I am not sure we need the LFB class. It may be useful (for differention source from sink, and allowing subclassing of the redirect LFBs. And I would not expect the remaining content to be an Operation TLV. Rather, I would expect it to be the packet. But mostly, we are in agreement. Yours, Joel At 09:56 PM 6/27/2005, Weiming Wang wrote: >Joel, > > > The Packet Redirect message contains one or more (typically one) > > packet-redirect TLVs. > >If I understand your above thought correctly, I think your proposal is to >define a packet-redirect TLV rathan than a LFBselectTLV at the top level >for the message. In this way it will leave LFB selection information as >kinds of meta-info and inside the TLV, something like: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = > Packet-Redirect | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Class ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Instance ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Now, the question is I do find this format is not very different with that >I proposed. Do I miss something? > >Thanks, >Weiming > > > > I would approach this differently. The current text describes the > > LFBselect LFB. It correctly defines the LFBselect LFB. That definition > > should not be thrown away. > > > > The message structure documentation can say > > A PL protocol messages consists of a protocol header followed by > one or > > more TLVs. All TLVs > > consist of two byte type and a two byte length, followed by contents > > dependent upon the type > > of the TLV. The TLVs which are valid in a message depend upon the > > message type. > > Most message types allow one or more LFBselect TLVs and no other top > > level TLVs. The > > following are the message types this applies to: > > Association setup request and response. > > Config message request and response > > Query message request and response > > Event Notify message. > > The Association teardown message contains a single instance of the > > teardown-cause TLV. > > The heartbeat message contains a single instance of the heatrbeat > > TLV. (Unless we decide > > to just use an event for heartbeats. I don't remember where that > > discussion stands.) > > The Packet Redirect message contains one or more (typically one) > > packet-redirect TLVs. > > This is then followed by a section for each of these top level TLVs. > > > > Yours, > > Joel M. Halpern > > > > At 10:01 AM 6/27/2005, Weiming Wang wrote: > > >Joel :) > > > > > >How about we just obsolete the path from the data structure and add some > > >meta-information, and form the format as below (I currently can only think > > >of the meta-information as the packet type. We may add some more later). > > > > > >Could you give more comments on this, then we may solve this issue soon? > > > > > >Thank you very much. > > > > > >Weiming > > > > > >--------------------- > > >Message Body: > > > Consists of one or more TLVs, with every TLV having the following > > > data format: > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = LFBselect | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Class ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | LFB Instance ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ ... ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Operation TLV | > > > . . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > LFB class ID: > > > There are only two possible LFB classes here, the 'RedirectSink' > > > LFB or the 'RedirectSource' LFB. If the message is from FE to CE, > > > the LFB class should be 'RedirectSink'. If the message is from CE > > > to FE, the LFB class should be 'RedirectSource'. > > > Instance ID: > > > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > > > Operation TLV: > > > This is a TLV describing one packet of data to be directed via the > > > specified LFB above. The order of the TLV appeared is also the > > > order the data packet arrives the redirector LFB, that is, the > > > Redirected Data in the first TLV should arrive the earliest. > > > > > >The TLV format is as follows: > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = PAYLOAD | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ Packet Type | Packet Length ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ Redirected Packet ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Type: > > > The type for the TLV is set to 'PAYLOAD'. > > > > > > Length: > > > the length of the TLV(in 4bytes). > > > > > > Packet Type: > > > Defines what type the redirected packet belongs to(such as 'IPv4 > > > Packet', > > > 'IPv6 Packet'). > > > > > > Packet Length: > > > the length of the followed redirected packet (in byte) > > > > > > Redirected Packet: > > > one redirected packet. > > >----------------------------- > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > <joel@stevecrocker.com> > > > > > > > I would expect that a Redirect Message has a different outermost > TLV. The > > > > grammar is intended to help us, not serve as a > straightjacket. Different > > > > message types can have different outer TLVs. It is desirable to > use the > > > > same structure when it applies. But the redirect message is simply a > > > > different case. It's contents are not a DATARAW much less a DATA > > > TLV. Its > > > > content structure is not defined by an LFB element definition or Model > > > > DataDefs structure definition. > > > > > > > > If we need to fix the "grammar" section to make it clear that not > all PL > > > > messages necessarily use the same outermost TLV, we should do > so. My own > > > > approach would be to separate the grammar into a definition of the > > > contents > > > > of that TLV, and a separate definition of which TLVs / content are > carried > > > > in the outermost level of which messages. > > > > > > > > Yours, > > > > Joel > > > > > > > > PS: Weiming, I am sorry you got caught up in this confusion. I don't > > > think > > > > you created the tendency I am railing against above. I am just > using your > > > > message as a starting point to hammer home a point. > > > > > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > > > >Maybe it's me who missed something :) > > > > >My thought was we might need to obey our message grammar well that we > > > have > > > > >to use a strict Path-data for operation TLV. To obey the rule, > treating > > > > >it as an event will ease the message format greatly. > > > > > > > > > >Actually I'm very happy to see that you agree a path can be > omitted for > > > > >some specific messages like redirect messge. > > > > > > > > > >OK, let's solve it then, to let redirect message only contain Data > > > > >field? I can update this redirect message part text then. > > > > > > > > > >Jamal, could you give a response on this? > > > > > > > > > >One less vital question is, shall we allow for mulitpul redirect > packets > > > > >encapsulated in one TLV or just one TLV only for one packet? To > use the > > > > >former, we have to define a sequence for the redirected packets > then in > > > > >the TLV. > > > > > > > > > >On the meta-information related, I think LFB IDs has already been > > > > >included. I don't think we need an extra port ID to indicate where > to put > > > > >the redirected data to or to get redirected data from. A redirect > source > > > > >LFB or sink LFB will have a port ID, which belongs to FE LFB > topology > > > > >concept, and FE LFB topolgy configuration is in charge of > this. Not sure > > > > >if it complies with your thought? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > > > > > Why would we want to treat redirects as events? > > > > > > We should treat them as redirects. > > > > > > > > > > > > I am very confused about "How a path should be defined in a Packet > > > > > Redirect > > > > > > Message", since as far as I can tell, a redirect does not need a > > > path. It > > > > > > needs a collection of meta-information, which we need to > > > define. At the > > > > > > moment, that has to include at least the LFB ID that the > redirect is > > > > > from / > > > > > > to. I suppose by declaring a multiplicity of such LFBs, that > can be > > > > > all of > > > > > > the information. (I usually think in terms of at least a logical > > > port ID > > > > > > the packet came from / is intended for.) > > > > > > > > > > > > Yours, > > > > > > Joel > > > > > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > > > > > >I suppose we could close this issue by reaching the following > points: > > > > > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and RedirectSink > > > LFB are > > > > > > >moved to the model, but the protocol retains the Redirect > Message. The > > > > > > >reason to keep the specific message is we need to specifically > > > recognize > > > > > > >redirected data between CE-FE transportation to avoid DoS attacks. > > > > > > > > > > > > > >2. The redirected data in the LFBs can be treated as a kind of > SPECIAL > > > > > > >events in that: > > > > > > > a. The event is triggered every time a new redirected packet > > > > > arrives > > > > > > > at the LFBs. > > > > > > > b. The event is transported by the Redirect Message only, > > > while > > > > > the > > > > > > > Redirect Message will the same message format as a general event > > > > > > > notification message (except the message type in the header). > > > > > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a path > > > should be > > > > > > >defined in Packet Redirect Message) then. > > > > > > > > > > > > > >Unfortunately, I think of another question that is related to > the > > > Packet > > > > > > >Redirect Message as well as to Event Notification Message. The > > > question > > > > > > >is, the Event Notification Message allows event generated by CE > > > and sent > > > > > > >to FE. In the case, in the message format, the LFB IDs refer to > > > the LFBs > > > > > > >that will receive the event notification, but the question is, > > > what the > > > > > > >Path in the message refers to then ?? The same also happens > to Packet > > > > > > >Redirect Message from CE to FE. > > > > > > > > > > > > > >Thanks, > > > > > > >Weiming > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Avri Doria" > > > <tracker-forces@mip4.org> > > > > > > >To: > <FORCES@PEACH.EASE.LSOFT.COM> > > > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > >New submission from Avri Doria > <avri@acm.org>: > > > > > > > > > > > > > >6.8 > > > > > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in > FE model > > > > > > > that are related to packet redirect > operations > > > > > > > should be defined. Although it is out of > the > > > scope > > > > > > > of forces protocol, how to define the > LFBs affect > > > > > > > the Packet Redirect Message described > > > here. Because > > > > > > > currently it is still in progress in FE > model > > > on how > > > > > > > to define such LFBs, we try to post some > > > thoughts on > > > > > > > this here for discussion. They will be > removed > > > > > > > later along with the progress of the FE > model > > > work. > > > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > > > 'RedirectTap' for packet redirect. > > > > > > > An LFB in FE called 'RedirectSink' is > > > responsible to > > > > > > > collect data packets that need to be > > > redirected to > > > > > > > CE. From the perspective of the FE LFB > topology, > > > > > > > the 'RedirectSink' LFB is an LFB with only > > > one input > > > > > > > port and without any output port, and the > > > input port > > > > > > > can then be connected to any other LFB in FE > > > model > > > > > > > by means of a datapath in the forwarding > plane. > > > > > > > From the perspective of the ForCES protocol > > > layer, > > > > > > > the 'RedirectSink' LFB will generate the > Packet > > > > > > > Redirect Messages when it receives data > > > packets from > > > > > > > forwarding plane. > > > > > > > > > > > > > > An LFB in FE called 'RedirectTap' is > > > responsible to > > > > > > > receive data packets that are redirected > from CE. > > > > > > > From the perspective of the FE LFB > topology, the > > > > > > > 'RedirectTap' LFB is an LFB with only one > output > > > > > > > port and without any input port, and the > > > output port > > > > > > > can then be connected to any other LFB in FE > > > model > > > > > > > by means of a datapath in the forwarding > plane. > > > > > > > From the perspective of ForCES protocol > > > layer, the > > > > > > > 'RedirectTap' LFB can receive the Packet > Redirect > > > > > > > Messages from CE, and un-encapsulate the data > > > > > > > packets from the message and put them to > > > datapaths > > > > > > > in the forwarding plane. Actually the > > > 'RecirectTap' > > > > > > > LFB acts more like a transcoder that > > > transfers the > > > > > > > ForCES protocol messages to normal data > > > packets in > > > > > > > IP forwarding plane. As a result, if we > need to > > > > > > > have redirected packets connected to some > LFB > > > (say a > > > > > > > Scheduler) in FE model, we only need to > > > connect the > > > > > > > 'RedirectTap LFB to the Scheduler LFB > > > directly via a > > > > > > > datapath as follows: > > > > > > > > > > > > > > > > > > > > > +-----------------+ > +-----------+ > > > > > > > | RedirectTap LFB > |------>| | > > > > > > > +-----------------+ | > | > > > > > > > | > Scheduler | > > > > > > > From other > LFB ---->| LFB | > > > > > > > | > | > > > > > > > > +-----------+ > > > > > > > > > > > > > > Figure 27 > > > > > > > > > > > > > > By use of several 'RedirectSink' LFBs and > several > > > > > > > 'RedirectTap' LFBs that connect to several > > > different > > > > > > > datapaths in FE forwarding plane, > multiple packet > > > > > > > redirect paths between CE and FE can be > > > constructed. > > > > > > > > > > > > > > Thought 2: There might be another way a packet could be > > > > > > > redirected: directly by a forwarding path, > > > e.g., by > > > > > > > FPGA/ASIC/NP microcode. In such a case > we do not > > > > > > > need to put in a lot of smartness. Probably > > > a link > > > > > > > layer or even network level header is > > > enough. The > > > > > > > receiver demuxes it only based on some > > > protocol type > > > > > > > in the link layer or network transport > > > layer. The > > > > > > > pros for this appraoch is it may provide a > > > fast and > > > > > > > cost-effective path for packet > redirect. The > > > cons > > > > > > > for this is it may more or less confuses > the Fp > > > > > > > reference point definition in ForCES > framework. > > > > > > > > > > > > > >---------- > > > > > > >category: Editorial > > > > > > >draft: draft-ietf-forces-protocol > > > > > > >messages: 49 > > > > > > >nosy: avri > > > > > > >priority: Must fix > > > > > > >status: No discussion > > > > > > >title: Packet Redirect > > > > > > > > > > > > > >___________________________________________________ > > > > > > >Forces issue tracker > > > <tracker-forces@mip4.org> > > > > > > > > > > > > > >___________________________________________________ > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 23:06:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6QN-0005MB-Rt for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 23:06:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27200 for ; Mon, 27 Jun 2005 23:06:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn6pc-0002Vh-Q3 for forces-archive@IETF.ORG; Mon, 27 Jun 2005 23:32:18 -0400 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.01090C65@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 23:06:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77101822 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 23:04:39 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 23:04:34 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 74778.2305915701; Tue, 28 Jun 2005 11:41:09 +0800 (CST) References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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: <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> Date: Tue, 28 Jun 2005 11:04:35 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: base64 DQo+IFRoZSBkaWZmZXJlbmNlcyBhcmUgbWlub3IuDQo+IEZpcnN0bHksIEkgd2FudGVkIHRvIGNs YXJpZnkgdGhlIGdlbmVyYWwgcHJpbmNpcGxlIG9mIHRvcCBsZXZlbCBUTFZzLg0KPiBJIGFtIG5v dCBzdXJlIHdlIG5lZWQgdGhlIExGQiBjbGFzcy4gIEl0IG1heSBiZSB1c2VmdWwgKGZvciBkaWZm ZXJlbnRpb24gDQo+IHNvdXJjZSBmcm9tIHNpbmssIGFuZCBhbGxvd2luZyBzdWJjbGFzc2luZyBv ZiB0aGUgcmVkaXJlY3QgTEZCcy4NCj4gQW5kIEkgd291bGQgbm90IGV4cGVjdCB0aGUgcmVtYWlu aW5nIGNvbnRlbnQgdG8gYmUgYW4gT3BlcmF0aW9uIA0KPiBUTFYuICBSYXRoZXIsIEkgd291bGQg ZXhwZWN0IGl0IHRvIGJlIHRoZSBwYWNrZXQuDQpPbWl0dGluZyBvcGVyYXRpb24gVExWIHdpbGwg bGVhZCB0byB0aGUgZmFjdCB0aGF0IHdlIG9ubHkgYWxsb3cgb25lIHBhY2tldCBkYXRhIGluIG9u ZSB0b3AgVExWLiBUaGF0J3MgdGhlIHF1ZXN0aW9uIHRoYXQgSSByYWlzZWQgZGF5cyBiZWZvcmUu IEZyb20gdGhlIGVmZmljaWVuY3kgcG9pbnQgb2YgdmlldywgdG8gYWxsb3cgbW9yZSB0aGFuIG9u ZSBwYWNrZXQgaW4gb25lIHRvcCBUTFYgbWF5IGJlIGJlbmlmaXRmdWwgYSBsaXR0bGUuDQoNClRo YW5rcywNCldlaW1pbmcNCj4gDQo+IEJ1dCBtb3N0bHksIHdlIGFyZSBpbiBhZ3JlZW1lbnQuDQo+ IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gQXQgMDk6NTYgUE0gNi8yNy8yMDA1LCBXZWltaW5n IFdhbmcgd3JvdGU6DQo+ID5Kb2VsLA0KPiA+DQo+ID4gPiAgICAgIFRoZSBQYWNrZXQgUmVkaXJl Y3QgbWVzc2FnZSBjb250YWlucyBvbmUgb3IgbW9yZSAodHlwaWNhbGx5IG9uZSkNCj4gPiA+IHBh Y2tldC1yZWRpcmVjdCBUTFZzLg0KPiA+DQo+ID5JZiBJIHVuZGVyc3RhbmQgeW91ciBhYm92ZSB0 aG91Z2h0IGNvcnJlY3RseSwgSSB0aGluayB5b3VyIHByb3Bvc2FsICBpcyB0byANCj4gPmRlZmlu ZSBhICBwYWNrZXQtcmVkaXJlY3QgVExWIHJhdGhhbiB0aGFuIGEgTEZCc2VsZWN0VExWIGF0IHRo ZSB0b3AgbGV2ZWwgDQo+ID5mb3IgdGhlIG1lc3NhZ2UuIEluIHRoaXMgd2F5IGl0IHdpbGwgbGVh dmUgTEZCIHNlbGVjdGlvbiBpbmZvcm1hdGlvbiBhcyANCj4gPmtpbmRzIG9mIG1ldGEtaW5mbyBh bmQgaW5zaWRlIHRoZSBUTFYsIHNvbWV0aGluZyBsaWtlOg0KPiA+DQo+ID4gPiA+ICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICBUeXBlID0gDQo+ID4gUGFja2V0LVJl ZGlyZWN0ICAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gPiA+ID4g ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gPiA+ICAgICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZC IEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ID4gPiAgICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+ID4gPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlv biBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+ID4gICAgICAgICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lg0KPiA+ID4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4NCj4gPk5vdywgdGhlIHF1ZXN0aW9uIGlz IEkgZG8gZmluZCB0aGlzIGZvcm1hdCBpcyBub3QgdmVyeSBkaWZmZXJlbnQgd2l0aCB0aGF0IA0K PiA+SSBwcm9wb3NlZC4gRG8gSSBtaXNzIHNvbWV0aGluZz8NCj4gPg0KPiA+VGhhbmtzLA0KPiA+ V2VpbWluZw0KPiA+DQo+ID4NCj4gPiA+IEkgd291bGQgYXBwcm9hY2ggdGhpcyBkaWZmZXJlbnRs eS4gIFRoZSBjdXJyZW50IHRleHQgZGVzY3JpYmVzIHRoZQ0KPiA+ID4gTEZCc2VsZWN0IExGQi4g IEl0IGNvcnJlY3RseSBkZWZpbmVzIHRoZSBMRkJzZWxlY3QgTEZCLiAgVGhhdCBkZWZpbml0aW9u DQo+ID4gPiBzaG91bGQgbm90IGJlIHRocm93biBhd2F5Lg0KPiA+ID4NCj4gPiA+IFRoZSBtZXNz YWdlIHN0cnVjdHVyZSBkb2N1bWVudGF0aW9uIGNhbiBzYXkNCj4gPiA+ICAgICBBIFBMIHByb3Rv Y29sIG1lc3NhZ2VzIGNvbnNpc3RzIG9mIGEgcHJvdG9jb2wgaGVhZGVyIGZvbGxvd2VkIGJ5IA0K PiA+IG9uZSBvcg0KPiA+ID4gbW9yZSBUTFZzLiAgQWxsIFRMVnMNCj4gPiA+ICAgICBjb25zaXN0 IG9mICB0d28gYnl0ZSB0eXBlIGFuZCBhIHR3byBieXRlIGxlbmd0aCwgZm9sbG93ZWQgYnkgY29u dGVudHMNCj4gPiA+IGRlcGVuZGVudCB1cG9uIHRoZSB0eXBlDQo+ID4gPiAgICAgb2YgdGhlIFRM Vi4gIFRoZSBUTFZzIHdoaWNoIGFyZSB2YWxpZCBpbiBhIG1lc3NhZ2UgZGVwZW5kIHVwb24gdGhl DQo+ID4gPiBtZXNzYWdlIHR5cGUuDQo+ID4gPiAgICAgTW9zdCBtZXNzYWdlIHR5cGVzIGFsbG93 IG9uZSBvciBtb3JlIExGQnNlbGVjdCBUTFZzIGFuZCBubyBvdGhlciB0b3ANCj4gPiA+IGxldmVs IFRMVnMuICBUaGUNCj4gPiA+ICAgICBmb2xsb3dpbmcgYXJlIHRoZSBtZXNzYWdlIHR5cGVzIHRo aXMgYXBwbGllcyB0bzoNCj4gPiA+ICAgICAgICBBc3NvY2lhdGlvbiBzZXR1cCByZXF1ZXN0IGFu ZCByZXNwb25zZS4NCj4gPiA+ICAgICAgICBDb25maWcgbWVzc2FnZSByZXF1ZXN0IGFuZCByZXNw b25zZQ0KPiA+ID4gICAgICAgIFF1ZXJ5IG1lc3NhZ2UgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCj4g PiA+ICAgICAgICBFdmVudCBOb3RpZnkgbWVzc2FnZS4NCj4gPiA+ICAgICBUaGUgQXNzb2NpYXRp b24gdGVhcmRvd24gbWVzc2FnZSBjb250YWlucyBhIHNpbmdsZSBpbnN0YW5jZSBvZiB0aGUNCj4g PiA+IHRlYXJkb3duLWNhdXNlIFRMVi4NCj4gPiA+ICAgICBUaGUgaGVhcnRiZWF0IG1lc3NhZ2Ug Y29udGFpbnMgYSBzaW5nbGUgaW5zdGFuY2Ugb2YgdGhlIGhlYXRyYmVhdA0KPiA+ID4gVExWLiAg KFVubGVzcyB3ZSBkZWNpZGUNCj4gPiA+ICAgICAgdG8ganVzdCB1c2UgYW4gZXZlbnQgZm9yIGhl YXJ0YmVhdHMuICBJIGRvbid0IHJlbWVtYmVyIHdoZXJlIHRoYXQNCj4gPiA+IGRpc2N1c3Npb24g c3RhbmRzLikNCj4gPiA+ICAgICAgVGhlIFBhY2tldCBSZWRpcmVjdCBtZXNzYWdlIGNvbnRhaW5z IG9uZSBvciBtb3JlICh0eXBpY2FsbHkgb25lKQ0KPiA+ID4gcGFja2V0LXJlZGlyZWN0IFRMVnMu DQo+ID4gPiBUaGlzIGlzIHRoZW4gZm9sbG93ZWQgYnkgYSBzZWN0aW9uIGZvciBlYWNoIG9mIHRo ZXNlIHRvcCBsZXZlbCBUTFZzLg0KPiA+ID4NCj4gPiA+IFlvdXJzLA0KPiA+ID4gSm9lbCBNLiBI YWxwZXJuDQo+ID4gPg0KPiA+ID4gQXQgMTA6MDEgQU0gNi8yNy8yMDA1LCBXZWltaW5nIFdhbmcg d3JvdGU6DQo+ID4gPiA+Sm9lbCA6KQ0KPiA+ID4gPg0KPiA+ID4gPkhvdyBhYm91dCB3ZSBqdXN0 IG9ic29sZXRlIHRoZSBwYXRoIGZyb20gdGhlIGRhdGEgc3RydWN0dXJlIGFuZCBhZGQgc29tZQ0K PiA+ID4gPm1ldGEtaW5mb3JtYXRpb24sIGFuZCBmb3JtIHRoZSBmb3JtYXQgYXMgYmVsb3cgKEkg Y3VycmVudGx5IGNhbiBvbmx5IHRoaW5rDQo+ID4gPiA+b2YgdGhlIG1ldGEtaW5mb3JtYXRpb24g YXMgdGhlIHBhY2tldCB0eXBlLiBXZSBtYXkgYWRkIHNvbWUgbW9yZSBsYXRlcikuDQo+ID4gPiA+ DQo+ID4gPiA+Q291bGQgeW91IGdpdmUgbW9yZSBjb21tZW50cyBvbiB0aGlzLCB0aGVuIHdlIG1h eSBzb2x2ZSB0aGlzIGlzc3VlIHNvb24/DQo+ID4gPiA+DQo+ID4gPiA+VGhhbmsgeW91IHZlcnkg bXVjaC4NCj4gPiA+ID4NCj4gPiA+ID5XZWltaW5nDQo+ID4gPiA+DQo+ID4gPiA+LS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gPiA+TWVzc2FnZSBCb2R5Og0KPiA+ID4gPiAgICAgICBDb25zaXN0 cyBvZiBvbmUgb3IgbW9yZSBUTFZzLCB3aXRoIGV2ZXJ5IFRMViBoYXZpbmcgdGhlIGZvbGxvd2lu Zw0KPiA+ID4gPiAgICAgICBkYXRhIGZvcm1hdDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDENCj4gPiA+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgICAg IFR5cGUgPSBMRkJzZWxlY3QgICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8 DQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ ID4gPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gPiA+ICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+ID4g ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICBPcGVyYXRpb24gVExWICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gPiA+ICAgICAg ICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4NCj4gPiA+ID4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIH4g ICAgICAgICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB+DQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgT3BlcmF0aW9uIFRMViAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPiA+ID4gPiAgICAgICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuDQo+ID4gPiA+ICAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g PiA+ID4NCj4gPiA+ID4gICAgTEZCIGNsYXNzIElEOg0KPiA+ID4gPiAgICAgICBUaGVyZSBhcmUg b25seSB0d28gcG9zc2libGUgTEZCIGNsYXNzZXMgaGVyZSwgdGhlICdSZWRpcmVjdFNpbmsnDQo+ ID4gPiA+ICAgICAgIExGQiBvciB0aGUgJ1JlZGlyZWN0U291cmNlJyBMRkIuICBJZiB0aGUgbWVz c2FnZSBpcyBmcm9tIEZFIHRvIENFLA0KPiA+ID4gPiAgICAgICB0aGUgTEZCIGNsYXNzIHNob3Vs ZCBiZSAnUmVkaXJlY3RTaW5rJy4gIElmIHRoZSBtZXNzYWdlIGlzIGZyb20gQ0UNCj4gPiA+ID4g ICAgICAgdG8gRkUsIHRoZSBMRkIgY2xhc3Mgc2hvdWxkIGJlICdSZWRpcmVjdFNvdXJjZScuDQo+ ID4gPiA+ICAgIEluc3RhbmNlIElEOg0KPiA+ID4gPiAgICAgICBJbnN0YW5jZSBJRCBmb3IgdGhl ICdSZWRpcmVjdFNpbmsnIExGQiBvciAnUmVkaXJlY3RTb3VyY2UnIExGQi4NCj4gPiA+ID4gICAg T3BlcmF0aW9uIFRMVjoNCj4gPiA+ID4gICAgICAgVGhpcyBpcyBhIFRMViBkZXNjcmliaW5nIG9u ZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCB2aWEgdGhlDQo+ID4gPiA+ICAgICAgIHNw ZWNpZmllZCBMRkIgYWJvdmUuICBUaGUgb3JkZXIgb2YgdGhlIFRMViBhcHBlYXJlZCBpcyBhbHNv IHRoZQ0KPiA+ID4gPiAgICAgICBvcmRlciB0aGUgZGF0YSBwYWNrZXQgYXJyaXZlcyB0aGUgcmVk aXJlY3RvciBMRkIsIHRoYXQgaXMsIHRoZQ0KPiA+ID4gPiAgICAgICBSZWRpcmVjdGVkIERhdGEg IGluIHRoZSBmaXJzdCBUTFYgc2hvdWxkIGFycml2ZSB0aGUgZWFybGllc3QuDQo+ID4gPiA+DQo+ ID4gPiA+VGhlIFRMViBmb3JtYXQgaXMgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gICAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiA+ID4gPiAgICAgICAgIHwgICAgVHlwZSA9IFBBWUxPQUQgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQo+ID4gPiA+ICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gPiA+ID4gICAgICAgICB+ICAgICAgICAgUGFja2V0IFR5cGUgICAgICAgICAg IHwgICAgICAgICBQYWNrZXQgTGVuZ3RoICAgICAgICAgfg0KPiA+ID4gPiAgICAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+ID4gPiA+ICAgICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0ZWQg UGFja2V0ICAgICAgICAgICAgICAgICAgICAgIH4NCj4gPiA+ID4gICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K PiA+ID4gPg0KPiA+ID4gPiAgICAgVHlwZToNCj4gPiA+ID4gICAgICAgVGhlIHR5cGUgZm9yIHRo ZSBUTFYgaXMgc2V0IHRvICdQQVlMT0FEJy4NCj4gPiA+ID4NCj4gPiA+ID4gICAgIExlbmd0aDoN Cj4gPiA+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgVExWKGluIDRieXRlcykuDQo+ID4gPiA+ DQo+ID4gPiA+ICAgICBQYWNrZXQgVHlwZToNCj4gPiA+ID4gICAgICAgRGVmaW5lcyB3aGF0IHR5 cGUgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IGJlbG9uZ3MgdG8oc3VjaCBhcyAnSVB2NA0KPiA+ID4g PiBQYWNrZXQnLA0KPiA+ID4gPiAgICAgICdJUHY2IFBhY2tldCcpLg0KPiA+ID4gPg0KPiA+ID4g PiAgICAgUGFja2V0IExlbmd0aDoNCj4gPiA+ID4gICAgICAgdGhlIGxlbmd0aCBvZiB0aGUgZm9s bG93ZWQgcmVkaXJlY3RlZCBwYWNrZXQgKGluIGJ5dGUpDQo+ID4gPiA+DQo+ID4gPiA+ICAgICBS ZWRpcmVjdGVkIFBhY2tldDoNCj4gPiA+ID4gICAgICAgb25lIHJlZGlyZWN0ZWQgcGFja2V0Lg0K PiA+ID4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4gPkZyb206ICJKb2VsIE0u IEhhbHBlcm4iIA0KPiA+IDw8bWFpbHRvOmpvZWxAc3RldmVjcm9ja2VyLmNvbT5qb2VsQHN0ZXZl Y3JvY2tlci5jb20+DQo+ID4gPiA+DQo+ID4gPiA+ID4gSSB3b3VsZCBleHBlY3QgdGhhdCBhIFJl ZGlyZWN0IE1lc3NhZ2UgaGFzIGEgZGlmZmVyZW50IG91dGVybW9zdCANCj4gPiBUTFYuICBUaGUN Cj4gPiA+ID4gPiBncmFtbWFyIGlzIGludGVuZGVkIHRvIGhlbHAgdXMsIG5vdCBzZXJ2ZSBhcyBh IA0KPiA+IHN0cmFpZ2h0amFja2V0LiAgRGlmZmVyZW50DQo+ID4gPiA+ID4gbWVzc2FnZSB0eXBl cyBjYW4gaGF2ZSBkaWZmZXJlbnQgb3V0ZXIgVExWcy4gIEl0IGlzIGRlc2lyYWJsZSB0byANCj4g PiB1c2UgdGhlDQo+ID4gPiA+ID4gc2FtZSBzdHJ1Y3R1cmUgd2hlbiBpdCBhcHBsaWVzLiAgQnV0 IHRoZSByZWRpcmVjdCBtZXNzYWdlIGlzIHNpbXBseSBhDQo+ID4gPiA+ID4gZGlmZmVyZW50IGNh c2UuICBJdCdzIGNvbnRlbnRzIGFyZSBub3QgYSBEQVRBUkFXIG11Y2ggbGVzcyBhIERBVEENCj4g PiA+ID4gVExWLiAgSXRzDQo+ID4gPiA+ID4gY29udGVudCBzdHJ1Y3R1cmUgaXMgbm90IGRlZmlu ZWQgYnkgYW4gTEZCIGVsZW1lbnQgZGVmaW5pdGlvbiBvciBNb2RlbA0KPiA+ID4gPiA+IERhdGFE ZWZzIHN0cnVjdHVyZSBkZWZpbml0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWYgd2UgbmVl ZCB0byBmaXggdGhlICJncmFtbWFyIiBzZWN0aW9uIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBub3Qg DQo+ID4gYWxsIFBMDQo+ID4gPiA+ID4gbWVzc2FnZXMgbmVjZXNzYXJpbHkgdXNlIHRoZSBzYW1l IG91dGVybW9zdCBUTFYsIHdlIHNob3VsZCBkbyANCj4gPiBzby4gICBNeSBvd24NCj4gPiA+ID4g PiBhcHByb2FjaCB3b3VsZCBiZSB0byBzZXBhcmF0ZSB0aGUgZ3JhbW1hciBpbnRvIGEgZGVmaW5p dGlvbiBvZiB0aGUNCj4gPiA+ID4gY29udGVudHMNCj4gPiA+ID4gPiBvZiB0aGF0IFRMViwgYW5k IGEgc2VwYXJhdGUgZGVmaW5pdGlvbiBvZiB3aGljaCBUTFZzIC8gY29udGVudCBhcmUgDQo+ID4g Y2FycmllZA0KPiA+ID4gPiA+IGluIHRoZSBvdXRlcm1vc3QgbGV2ZWwgb2Ygd2hpY2ggbWVzc2Fn ZXMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBZb3VycywNCj4gPiA+ID4gPiBKb2VsDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBQUzogV2VpbWluZywgSSBhbSBzb3JyeSB5b3UgZ290IGNhdWdodCB1cCBp biB0aGlzIGNvbmZ1c2lvbi4gIEkgZG9uJ3QNCj4gPiA+ID4gdGhpbmsNCj4gPiA+ID4gPiB5b3Ug Y3JlYXRlZCB0aGUgdGVuZGVuY3kgSSBhbSByYWlsaW5nIGFnYWluc3QgYWJvdmUuICBJIGFtIGp1 c3QgDQo+ID4gdXNpbmcgeW91cg0KPiA+ID4gPiA+IG1lc3NhZ2UgYXMgYSBzdGFydGluZyBwb2lu dCB0byBoYW1tZXIgaG9tZSBhIHBvaW50Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQXQgMDQ6NDUg QU0gNi8yNi8yMDA1LCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+ID4gPiA+ID4gPk1heWJlIGl0J3Mg bWUgd2hvIG1pc3NlZCBzb21ldGhpbmcgOikNCj4gPiA+ID4gPiA+TXkgdGhvdWdodCB3YXMgd2Ug bWlnaHQgbmVlZCB0byBvYmV5IG91ciBtZXNzYWdlIGdyYW1tYXIgd2VsbCB0aGF0IHdlDQo+ID4g PiA+IGhhdmUNCj4gPiA+ID4gPiA+dG8gdXNlIGEgc3RyaWN0IFBhdGgtZGF0YSBmb3Igb3BlcmF0 aW9uIFRMVi4gIFRvIG9iZXkgdGhlIHJ1bGUsIA0KPiA+IHRyZWF0aW5nDQo+ID4gPiA+ID4gPml0 IGFzIGFuIGV2ZW50IHdpbGwgZWFzZSB0aGUgbWVzc2FnZSBmb3JtYXQgZ3JlYXRseS4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPkFjdHVhbGx5IEknbSB2ZXJ5IGhhcHB5IHRvIHNlZSB0aGF0IHlv dSBhZ3JlZSBhIHBhdGggY2FuIGJlIA0KPiA+IG9taXR0ZWQgZm9yDQo+ID4gPiA+ID4gPnNvbWUg c3BlY2lmaWMgbWVzc2FnZXMgbGlrZSByZWRpcmVjdCBtZXNzZ2UuDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID5PSywgbGV0J3Mgc29sdmUgaXQgdGhlbiwgdG8gbGV0IHJlZGlyZWN0IG1lc3NhZ2Ug b25seSBjb250YWluIERhdGENCj4gPiA+ID4gPiA+ZmllbGQ/ICBJIGNhbiB1cGRhdGUgdGhpcyBy ZWRpcmVjdCBtZXNzYWdlIHBhcnQgdGV4dCB0aGVuLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ SmFtYWwsIGNvdWxkIHlvdSBnaXZlIGEgcmVzcG9uc2Ugb24gdGhpcz8NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPk9uZSAgbGVzcyB2aXRhbCBxdWVzdGlvbiBpcywgc2hhbGwgd2UgYWxsb3cgZm9y IG11bGl0cHVsIHJlZGlyZWN0IA0KPiA+IHBhY2tldHMNCj4gPiA+ID4gPiA+ZW5jYXBzdWxhdGVk IGluIG9uZSBUTFYgb3IganVzdCBvbmUgVExWIG9ubHkgZm9yIG9uZSBwYWNrZXQ/IFRvIA0KPiA+ IHVzZSB0aGUNCj4gPiA+ID4gPiA+Zm9ybWVyLCB3ZSBoYXZlIHRvIGRlZmluZSBhIHNlcXVlbmNl IGZvciB0aGUgcmVkaXJlY3RlZCBwYWNrZXRzIA0KPiA+IHRoZW4gaW4NCj4gPiA+ID4gPiA+dGhl IFRMVi4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPk9uICB0aGUgbWV0YS1pbmZvcm1hdGlvbiBy ZWxhdGVkLCBJIHRoaW5rIExGQiBJRHMgaGFzIGFscmVhZHkgYmVlbg0KPiA+ID4gPiA+ID5pbmNs dWRlZC4gSSBkb24ndCB0aGluayB3ZSBuZWVkIGFuIGV4dHJhIHBvcnQgSUQgdG8gaW5kaWNhdGUg d2hlcmUgDQo+ID4gdG8gcHV0DQo+ID4gPiA+ID4gPnRoZSByZWRpcmVjdGVkIGRhdGEgdG8gb3Ig dG8gZ2V0IHJlZGlyZWN0ZWQgZGF0YSBmcm9tLiBBIHJlZGlyZWN0IA0KPiA+IHNvdXJjZQ0KPiA+ ID4gPiA+ID5MRkIgIG9yIHNpbmsgTEZCIHdpbGwgIGhhdmUgYSBwb3J0IElELCB3aGljaCBiZWxv bmdzIHRvIEZFIExGQiANCj4gPiB0b3BvbG9neQ0KPiA+ID4gPiA+ID5jb25jZXB0LCBhbmQgRkUg TEZCIHRvcG9sZ3kgY29uZmlndXJhdGlvbiBpcyBpbiBjaGFyZ2Ugb2YgDQo+ID4gdGhpcy4gIE5v dCBzdXJlDQo+ID4gPiA+ID4gPmlmIGl0IGNvbXBsaWVzIHdpdGggeW91ciB0aG91Z2h0Pw0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+VGhhbmtzLA0KPiA+ID4gPiA+ID5XZWltaW5nDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gPiA+ID4g PkZyb206ICJKb2VsIE0uIEhhbHBlcm4iDQo+ID4gPiA+ID4gPlN1YmplY3Q6IFJlOiBbaXNzdWUz Ml0gUGFja2V0IFJlZGlyZWN0DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ ID4gSSBhbSBtaXNzaWduIHNvbWV0aGluZyBpbiB5b3VyIHN1Z2dlc3Rpb24uDQo+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+IFdoeSB3b3VsZCB3ZSB3YW50IHRvIHRyZWF0IHJlZGlyZWN0cyBh cyBldmVudHM/DQo+ID4gPiA+ID4gPiA+IFdlIHNob3VsZCB0cmVhdCB0aGVtIGFzIHJlZGlyZWN0 cy4NCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSSBhbSB2ZXJ5IGNvbmZ1c2VkIGFib3V0 ICJIb3cgYSBwYXRoIHNob3VsZCBiZSBkZWZpbmVkIGluIGEgUGFja2V0DQo+ID4gPiA+ID4gPiBS ZWRpcmVjdA0KPiA+ID4gPiA+ID4gPiBNZXNzYWdlIiwgc2luY2UgYXMgZmFyIGFzIEkgY2FuIHRl bGwsIGEgcmVkaXJlY3QgZG9lcyBub3QgbmVlZCBhDQo+ID4gPiA+IHBhdGguICBJdA0KPiA+ID4g PiA+ID4gPiBuZWVkcyBhIGNvbGxlY3Rpb24gb2YgbWV0YS1pbmZvcm1hdGlvbiwgd2hpY2ggd2Ug bmVlZCB0bw0KPiA+ID4gPiBkZWZpbmUuICBBdCB0aGUNCj4gPiA+ID4gPiA+ID4gbW9tZW50LCB0 aGF0IGhhcyB0byBpbmNsdWRlIGF0IGxlYXN0IHRoZSBMRkIgSUQgdGhhdCB0aGUgDQo+ID4gcmVk aXJlY3QgaXMNCj4gPiA+ID4gPiA+IGZyb20gLw0KPiA+ID4gPiA+ID4gPiB0by4gIEkgc3VwcG9z ZSBieSBkZWNsYXJpbmcgYSBtdWx0aXBsaWNpdHkgb2Ygc3VjaCBMRkJzLCB0aGF0IA0KPiA+IGNh biBiZQ0KPiA+ID4gPiA+ID4gYWxsIG9mDQo+ID4gPiA+ID4gPiA+IHRoZSBpbmZvcm1hdGlvbi4g IChJIHVzdWFsbHkgdGhpbmsgaW4gdGVybXMgb2YgYXQgbGVhc3QgYSBsb2dpY2FsDQo+ID4gPiA+ IHBvcnQgSUQNCj4gPiA+ID4gPiA+ID4gdGhlIHBhY2tldCBjYW1lIGZyb20gLyBpcyBpbnRlbmRl ZCBmb3IuKQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBZb3VycywNCj4gPiA+ID4gPiA+ ID4gSm9lbA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBBdCAxMDo1MCBQTSA2LzI1LzIw MDUsIFdlaW1pbmcgV2FuZyB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPkphbWFsLCBKb2VsLCBhbmQg SG9ybXpkLA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID5JIHN1cHBvc2Ugd2UgY291 bGQgY2xvc2UgdGhpcyBpc3N1ZSBieSByZWFjaGluZyB0aGUgZm9sbG93aW5nIA0KPiA+IHBvaW50 czoNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+MS4gVGhlIHJlZGlyZWN0IExGQnMg Y2FsbGVkIFJlZGlyZWN0U291cmNlICBMRkIgYW5kIFJlZGlyZWN0U2luaw0KPiA+ID4gPiBMRkIg YXJlDQo+ID4gPiA+ID4gPiA+ID5tb3ZlZCB0byB0aGUgbW9kZWwsIGJ1dCB0aGUgcHJvdG9jb2wg cmV0YWlucyB0aGUgUmVkaXJlY3QgDQo+ID4gTWVzc2FnZS4gVGhlDQo+ID4gPiA+ID4gPiA+ID5y ZWFzb24gdG8ga2VlcCB0aGUgc3BlY2lmaWMgbWVzc2FnZSBpcyB3ZSBuZWVkIHRvIHNwZWNpZmlj YWxseQ0KPiA+ID4gPiByZWNvZ25pemUNCj4gPiA+ID4gPiA+ID4gPnJlZGlyZWN0ZWQgZGF0YSBi ZXR3ZWVuIENFLUZFIHRyYW5zcG9ydGF0aW9uIHRvIGF2b2lkIERvUyBhdHRhY2tzLg0KPiA+ID4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4yLiBUaGUgcmVkaXJlY3RlZCBkYXRhIGluIHRoZSBM RkJzIGNhbiBiZSB0cmVhdGVkIGFzIGEga2luZCBvZiANCj4gPiBTUEVDSUFMDQo+ID4gPiA+ID4g PiA+ID5ldmVudHMgaW4gdGhhdDoNCj4gPiA+ID4gPiA+ID4gPiAgICAgIGEuIFRoZSBldmVudCBp cyB0cmlnZ2VyZWQgZXZlcnkgdGltZSBhIG5ldyByZWRpcmVjdGVkIHBhY2tldA0KPiA+ID4gPiA+ ID4gYXJyaXZlcw0KPiA+ID4gPiA+ID4gPiA+IGF0IHRoZSBMRkJzLg0KPiA+ID4gPiA+ID4gPiA+ ICAgICAgYi4gVGhlIGV2ZW50IGlzIHRyYW5zcG9ydGVkIGJ5IHRoZSBSZWRpcmVjdCAgTWVzc2Fn ZSBvbmx5LA0KPiA+ID4gPiB3aGlsZQ0KPiA+ID4gPiA+ID4gdGhlDQo+ID4gPiA+ID4gPiA+ID4g UmVkaXJlY3QgTWVzc2FnZSB3aWxsIHRoZSBzYW1lIG1lc3NhZ2UgZm9ybWF0IGFzIGEgZ2VuZXJh bCBldmVudA0KPiA+ID4gPiA+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIChleGNlcHQgdGhl IG1lc3NhZ2UgdHlwZSBpbiB0aGUgaGVhZGVyKS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiA+QnkgZG9pbmcgaW4gdGhpcyB3YXksIHdlIGNhbiBhbHNvIHNvbHZlIHRoZSBpc3N1ZTUz IChIb3cgYSBwYXRoDQo+ID4gPiA+IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID4gPiA+ZGVmaW5lZCAg aW4gUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UpIHRoZW4uDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4gPlVuZm9ydHVuYXRlbHksICBJIHRoaW5rIG9mIGFub3RoZXIgcXVlc3Rpb24gdGhh dCBpcyByZWxhdGVkIHRvIA0KPiA+IHRoZQ0KPiA+ID4gPiBQYWNrZXQNCj4gPiA+ID4gPiA+ID4g PlJlZGlyZWN0IE1lc3NhZ2UgYXMgd2VsbCBhcyB0byBFdmVudCBOb3RpZmljYXRpb24gTWVzc2Fn ZS4gVGhlDQo+ID4gPiA+IHF1ZXN0aW9uDQo+ID4gPiA+ID4gPiA+ID5pcywgdGhlIEV2ZW50IE5v dGlmaWNhdGlvbiBNZXNzYWdlIGFsbG93cyBldmVudCBnZW5lcmF0ZWQgYnkgQ0UNCj4gPiA+ID4g YW5kIHNlbnQNCj4gPiA+ID4gPiA+ID4gPnRvIEZFLiBJbiB0aGUgY2FzZSwgaW4gdGhlIG1lc3Nh Z2UgZm9ybWF0LCB0aGUgTEZCIElEcyByZWZlciB0bw0KPiA+ID4gPiB0aGUgTEZCcw0KPiA+ID4g PiA+ID4gPiA+dGhhdCB3aWxsIHJlY2VpdmUgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiwgYnV0IHRo ZSBxdWVzdGlvbiBpcywNCj4gPiA+ID4gd2hhdCB0aGUNCj4gPiA+ID4gPiA+ID4gPlBhdGggaW4g dGhlIG1lc3NhZ2UgcmVmZXJzIHRvIHRoZW4gPz8gIFRoZSBzYW1lIGFsc28gaGFwcGVucyANCj4g PiB0byBQYWNrZXQNCj4gPiA+ID4gPiA+ID4gPlJlZGlyZWN0IE1lc3NhZ2UgZnJvbSBDRSB0byBG RS4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+VGhhbmtzLA0KPiA+ID4gPiA+ID4g PiA+V2VpbWluZw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQo+ID4gPiA+ID4gPiA+ID5Gcm9tOiAiQXZyaSBEb3JpYSINCj4gPiA+ ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZXNAbWlwNC5v cmc+DQo+ID4gPiA+ID4gPiA+ID5UbzogDQo+ID4gPDxtYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0Uu TFNPRlQuQ09NPkZPUkNFU0BQRUFDSC5FQVNFLkxTT0ZULkNPTT4NCj4gPiA+ID4gPiA+ID4gPlNl bnQ6IE1vbmRheSwgTWF5IDIzLCAyMDA1IDI6MzUgQU0NCj4gPiA+ID4gPiA+ID4gPlN1YmplY3Q6 IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCj4gPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiA+ID5OZXcgc3VibWlzc2lvbiBmcm9tIEF2cmkgRG9yaWEgDQo+ID4g PDxtYWlsdG86YXZyaUBhY20ub3JnPmF2cmlAYWNtLm9yZz46DQo+ID4gPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+ID4gPjYuOA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gIEVkaXRv cmlhbCBOb3RlOiAgVGhlcmUgYXJlIGFsc28gZGlzY3Vzc2lvbnMgb24gaG93IExGQnMgaW4gDQo+ ID4gRkUgbW9kZWwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHRoYXQgYXJl IHJlbGF0ZWQgdG8gcGFja2V0IHJlZGlyZWN0IA0KPiA+IG9wZXJhdGlvbnMNCj4gPiA+ID4gPiA+ ID4gPiAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBiZSBkZWZpbmVkLiAgQWx0aG91Z2ggaXQg aXMgb3V0IG9mIA0KPiA+IHRoZQ0KPiA+ID4gPiBzY29wZQ0KPiA+ID4gPiA+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgb2YgZm9yY2VzIHByb3RvY29sLCBob3cgdG8gZGVmaW5lIHRoZSANCj4g PiBMRkJzIGFmZmVjdA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgdGhlIFBh Y2tldCBSZWRpcmVjdCBNZXNzYWdlIGRlc2NyaWJlZA0KPiA+ID4gPiBoZXJlLiAgQmVjYXVzZQ0K PiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgY3VycmVudGx5IGl0IGlzIHN0aWxs IGluIHByb2dyZXNzIGluIEZFIA0KPiA+IG1vZGVsDQo+ID4gPiA+IG9uIGhvdw0KPiA+ID4gPiA+ ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgdG8gZGVmaW5lIHN1Y2ggTEZCcywgd2UgdHJ5IHRv IHBvc3Qgc29tZQ0KPiA+ID4gPiB0aG91Z2h0cyBvbg0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAg ICAgICAgICAgICAgdGhpcyBoZXJlIGZvciBkaXNjdXNzaW9uLiAgVGhleSB3aWxsIGJlIA0KPiA+ IHJlbW92ZWQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGxhdGVyIGFsb25n IHdpdGggdGhlIHByb2dyZXNzIG9mIHRoZSBGRSANCj4gPiBtb2RlbA0KPiA+ID4gPiB3b3JrLg0K PiA+ID4gPiA+ID4gPiA+ICAgICAgICAgVGhvdWdodCAxOiAgVG8gZGVmaW5lIExGQnMgY2FsbGVk ICdSZWRpcmVjdFNpbmsnIGFuZA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAg J1JlZGlyZWN0VGFwJyBmb3IgcGFja2V0IHJlZGlyZWN0Lg0KPiA+ID4gPiA+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgQW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RTaW5rJyBpcw0KPiA+ ID4gPiByZXNwb25zaWJsZSB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAg Y29sbGVjdCBkYXRhIHBhY2tldHMgdGhhdCBuZWVkIHRvIGJlDQo+ID4gPiA+IHJlZGlyZWN0ZWQg dG8NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIENFLiAgRnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgdGhlIEZFIExGQiANCj4gPiB0b3BvbG9neSwNCj4gPiA+ID4gPiA+ID4gPiAg ICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgaXMgYW4gTEZCIHdpdGgg b25seQ0KPiA+ID4gPiBvbmUgaW5wdXQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgIHBvcnQgYW5kIHdpdGhvdXQgYW55IG91dHB1dCBwb3J0LCBhbmQgdGhlDQo+ID4gPiA+IGlu cHV0IHBvcnQNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGNhbiB0aGVuIGJl IGNvbm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFDQo+ID4gPiA+IG1vZGVsDQo+ID4gPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIHRo ZSBmb3J3YXJkaW5nIA0KPiA+IHBsYW5lLg0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAg ICAgICAgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIEZvckNFUyBwcm90b2NvbA0KPiA+ID4g PiBsYXllciwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHRoZSAnUmVkaXJl Y3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0ZSB0aGUgDQo+ID4gUGFja2V0DQo+ID4gPiA+ID4gPiA+ ID4gICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdCBNZXNzYWdlcyB3aGVuIGl0IHJlY2VpdmVz IGRhdGENCj4gPiA+ID4gcGFja2V0cyBmcm9tDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAg ICAgICAgICBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ ID4gICAgICAgICAgICAgICAgICAgICBBbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFRhcCcg aXMNCj4gPiA+ID4gcmVzcG9uc2libGUgdG8NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgIHJlY2VpdmUgZGF0YSBwYWNrZXRzIHRoYXQgYXJlIHJlZGlyZWN0ZWQgDQo+ID4gZnJv bSBDRS4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIHRoZSBGRSBMRkIgDQo+ID4gdG9wb2xvZ3ksIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ ICAgICAgICAgICAgICAgICAgICAgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZCIHdpdGggb25s eSBvbmUgDQo+ID4gb3V0cHV0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBw b3J0IGFuZCB3aXRob3V0IGFueSBpbnB1dCBwb3J0LCBhbmQgdGhlDQo+ID4gPiA+IG91dHB1dCBw b3J0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBjYW4gdGhlbiBiZSBjb25u ZWN0ZWQgdG8gYW55IG90aGVyIExGQiBpbiBGRQ0KPiA+ID4gPiBtb2RlbA0KPiA+ID4gPiA+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9y d2FyZGluZyANCj4gPiBwbGFuZS4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg IEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIEZvckNFUyBwcm90b2NvbA0KPiA+ID4gPiBsYXllciwg dGhlDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3RUYXAnIExG QiBjYW4gcmVjZWl2ZSB0aGUgUGFja2V0IA0KPiA+IFJlZGlyZWN0DQo+ID4gPiA+ID4gPiA+ID4g ICAgICAgICAgICAgICAgICAgICBNZXNzYWdlcyBmcm9tIENFLCBhbmQgdW4tZW5jYXBzdWxhdGUg dGhlIGRhdGENCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIHBhY2tldHMgZnJv bSB0aGUgbWVzc2FnZSBhbmQgcHV0IHRoZW0gdG8NCj4gPiA+ID4gZGF0YXBhdGhzDQo+ID4gPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gIEFj dHVhbGx5IHRoZQ0KPiA+ID4gPiAnUmVjaXJlY3RUYXAnDQo+ID4gPiA+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0cmFuc2NvZGVyIHRoYXQNCj4gPiA+ ID4gdHJhbnNmZXJzIHRoZQ0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgRm9y Q0VTIHByb3RvY29sIG1lc3NhZ2VzIHRvIG5vcm1hbCBkYXRhDQo+ID4gPiA+IHBhY2tldHMgaW4N Cj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIElQIGZvcndhcmRpbmcgcGxhbmUu ICBBcyBhIHJlc3VsdCwgaWYgd2UgDQo+ID4gbmVlZCB0bw0KPiA+ID4gPiA+ID4gPiA+ICAgICAg ICAgICAgICAgICAgICAgaGF2ZSByZWRpcmVjdGVkIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUg DQo+ID4gTEZCDQo+ID4gPiA+IChzYXkgYQ0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAg ICAgICAgU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgd2Ugb25seSBuZWVkIHRvDQo+ID4gPiA+IGNv bm5lY3QgdGhlDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3RU YXAgTEZCIHRvIHRoZSBTY2hlZHVsZXIgTEZCDQo+ID4gPiA+IGRpcmVjdGx5IHZpYSBhDQo+ID4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KPiA+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgDQo+ID4gKy0tLS0tLS0tLS0t Kw0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWRpcmVj dFRhcCBMRkIgDQo+ID4gfC0tLS0tLT58ICAgICAgICAgICB8DQo+ID4gPiA+ID4gPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgIHwgDQo+ ID4gICAgICAgfA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KPiA+IFNjaGVkdWxlciB8DQo+ID4gPiA+ID4g PiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJvbSBvdGhlciANCj4gPiBM RkIgICAtLS0tPnwgICAgTEZCICAgIHwNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCj4gPiAgICAgICB8DQo+ ID4gPiA+ID4gPiA+ID4gDQo+ID4gKy0tLS0tLS0tLS0tKw0KPiA+ID4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyNw0KPiA+ ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBCeSB1c2Ug b2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5rJyBMRkJzIGFuZCANCj4gPiBzZXZlcmFsDQo+ID4gPiA+ ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAnUmVkaXJlY3RUYXAnIExGQnMgdGhhdCBjb25u ZWN0IHRvIHNldmVyYWwNCj4gPiA+ID4gZGlmZmVyZW50DQo+ID4gPiA+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICBkYXRhcGF0aHMgaW4gRkUgZm9yd2FyZGluZyBwbGFuZSwgDQo+ID4gbXVs dGlwbGUgcGFja2V0DQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICByZWRpcmVj dCBwYXRocyBiZXR3ZWVuIENFIGFuZCBGRSBjYW4gYmUNCj4gPiA+ID4gY29uc3RydWN0ZWQuDQo+ ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgIFRob3VnaHQgMjogIFRoZXJl IG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNvdWxkIGJlDQo+ID4gPiA+ID4gPiA+ID4g ICAgICAgICAgICAgICAgICAgICByZWRpcmVjdGVkOiBkaXJlY3RseSBieSBhIGZvcndhcmRpbmcg cGF0aCwNCj4gPiA+ID4gZS5nLiwgYnkNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAg ICAgIEZQR0EvQVNJQy9OUCBtaWNyb2NvZGUuICBJbiBzdWNoIGEgY2FzZSANCj4gPiB3ZSBkbyBu b3QNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gcHV0IGluIGEg bG90IG9mIHNtYXJ0bmVzcy4gIFByb2JhYmx5DQo+ID4gPiA+IGEgbGluaw0KPiA+ID4gPiA+ID4g PiA+ICAgICAgICAgICAgICAgICAgICAgbGF5ZXIgb3IgZXZlbiBuZXR3b3JrIGxldmVsIGhlYWRl ciBpcw0KPiA+ID4gPiBlbm91Z2guICBUaGUNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAg ICAgICAgIHJlY2VpdmVyIGRlbXV4ZXMgaXQgb25seSBiYXNlZCBvbiBzb21lDQo+ID4gPiA+IHBy b3RvY29sIHR5cGUNCj4gPiA+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgIGluIHRoZSBs aW5rIGxheWVyIG9yIG5ldHdvcmsgdHJhbnNwb3J0DQo+ID4gPiA+IGxheWVyLiAgVGhlDQo+ID4g PiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgICAgICBwcm9zIGZvciB0aGlzIGFwcHJhb2NoIGlz IGl0IG1heSBwcm92aWRlIGENCj4gPiA+ID4gZmFzdCBhbmQNCj4gPiA+ID4gPiA+ID4gPiAgICAg ICAgICAgICAgICAgICAgIGNvc3QtZWZmZWN0aXZlIHBhdGggZm9yIHBhY2tldCANCj4gPiByZWRp cmVjdC4gIFRoZQ0KPiA+ID4gPiBjb25zDQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg ICAgICBmb3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIA0KPiA+IHRoZSBG cA0KPiA+ID4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgcmVmZXJlbmNlIHBvaW50IGRl ZmluaXRpb24gaW4gRm9yQ0VTIA0KPiA+IGZyYW1ld29yay4NCj4gPiA+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gPiA+LS0tLS0tLS0tLQ0KPiA+ID4gPiA+ID4gPiA+Y2F0ZWdvcnk6IEVkaXRvcmlh bA0KPiA+ID4gPiA+ID4gPiA+ZHJhZnQ6IGRyYWZ0LWlldGYtZm9yY2VzLXByb3RvY29sDQo+ID4g PiA+ID4gPiA+ID5tZXNzYWdlczogNDkNCj4gPiA+ID4gPiA+ID4gPm5vc3k6IGF2cmkNCj4gPiA+ ID4gPiA+ID4gPnByaW9yaXR5OiBNdXN0IGZpeA0KPiA+ID4gPiA+ID4gPiA+c3RhdHVzOiBObyBk aXNjdXNzaW9uDQo+ID4gPiA+ID4gPiA+ID50aXRsZTogUGFja2V0IFJlZGlyZWN0DQo+ID4gPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPiA+Rm9yY2VzIGlzc3VlIHRyYWNrZXIN Cj4gPiA+ID4gPDxtYWlsdG86dHJhY2tlci1mb3JjZXNAbWlwNC5vcmc+dHJhY2tlci1mb3JjZXNA bWlwNC5vcmc+DQo+ID4gPiA+ID4gPiA+ID48aHR0cDovL3d3dy5taXA0Lm9yZy9pc3N1ZXMvdHJh Y2tlci9mb3JjZXMvaXNzdWUzMj4NCj4gPiA+ID4gPiA+ID4gPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gPg== From owner-forces@PEACH.EASE.LSOFT.COM Mon Jun 27 23:20:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6eP-0007gn-PV for forces-archive@megatron.ietf.org; Mon, 27 Jun 2005 23:20:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28379 for ; Mon, 27 Jun 2005 23:20:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn73f-0003YO-Sn for forces-archive@IETF.ORG; Mon, 27 Jun 2005 23:46:48 -0400 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.01090B89@cherry.ease.lsoft.com>; Mon, 27 Jun 2005 23:20:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77103032 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 23:20:38 -0400 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 27 Jun 2005 23:20:38 -0400 Received: from user-2ivf9ev.dialup.mindspring.com ([165.247.165.223] helo=JMHLap3.stevecrocker.com) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Dn6eI-0000W3-00 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Jun 2005 23:20:34 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> 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.20050627231906.02d0e120@localhost> Date: Mon, 27 Jun 2005 23:20:28 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Given that packets requiring redirection are likely to be scattered, and given that multiple redirect TLVs (each with a packet) can be included in a message if that is useful, I don't see much value it the extra wrapper to allow multiple packets inside the TLV. Yours, Joel At 11:04 PM 6/27/2005, Weiming Wang wrote: > > The differences are minor. > > Firstly, I wanted to clarify the general principle of top level TLVs. > > I am not sure we need the LFB class. It may be useful (for differention > > source from sink, and allowing subclassing of the redirect LFBs. > > And I would not expect the remaining content to be an Operation > > TLV. Rather, I would expect it to be the packet. >Omitting operation TLV will lead to the fact that we only allow one packet >data in one top TLV. That's the question that I raised days before. From >the efficiency point of view, to allow more than one packet in one top TLV >may be benifitful a little. > >Thanks, >Weiming > > > > But mostly, we are in agreement. > > > > Yours, > > Joel > > > > At 09:56 PM 6/27/2005, Weiming Wang wrote: > > >Joel, > > > > > > > The Packet Redirect message contains one or more (typically one) > > > > packet-redirect TLVs. > > > > > >If I understand your above thought correctly, I think your > proposal is to > > >define a packet-redirect TLV rathan than a LFBselectTLV at the top level > > >for the message. In this way it will leave LFB selection information as > > >kinds of meta-info and inside the TLV, something like: > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = > > > Packet-Redirect | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Class > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Instance > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >Now, the question is I do find this format is not very different with > that > > >I proposed. Do I miss something? > > > > > >Thanks, > > >Weiming > > > > > > > > > > I would approach this differently. The current text describes the > > > > LFBselect LFB. It correctly defines the LFBselect LFB. That > definition > > > > should not be thrown away. > > > > > > > > The message structure documentation can say > > > > A PL protocol messages consists of a protocol header followed by > > > one or > > > > more TLVs. All TLVs > > > > consist of two byte type and a two byte length, followed by > contents > > > > dependent upon the type > > > > of the TLV. The TLVs which are valid in a message depend upon the > > > > message type. > > > > Most message types allow one or more LFBselect TLVs and no > other top > > > > level TLVs. The > > > > following are the message types this applies to: > > > > Association setup request and response. > > > > Config message request and response > > > > Query message request and response > > > > Event Notify message. > > > > The Association teardown message contains a single instance of the > > > > teardown-cause TLV. > > > > The heartbeat message contains a single instance of the heatrbeat > > > > TLV. (Unless we decide > > > > to just use an event for heartbeats. I don't remember where that > > > > discussion stands.) > > > > The Packet Redirect message contains one or more (typically one) > > > > packet-redirect TLVs. > > > > This is then followed by a section for each of these top level TLVs. > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > > > > At 10:01 AM 6/27/2005, Weiming Wang wrote: > > > > >Joel :) > > > > > > > > > >How about we just obsolete the path from the data structure and > add some > > > > >meta-information, and form the format as below (I currently can > only think > > > > >of the meta-information as the packet type. We may add some more > later). > > > > > > > > > >Could you give more comments on this, then we may solve this issue > soon? > > > > > > > > > >Thank you very much. > > > > > > > > > >Weiming > > > > > > > > > >--------------------- > > > > >Message Body: > > > > > Consists of one or more TLVs, with every TLV having the > following > > > > > data format: > > > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = > LFBselect | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Class > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | LFB Instance > ID | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ ... > ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Operation > TLV | > > > > > . > . > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > LFB class ID: > > > > > There are only two possible LFB classes here, the > 'RedirectSink' > > > > > LFB or the 'RedirectSource' LFB. If the message is from FE > to CE, > > > > > the LFB class should be 'RedirectSink'. If the message is > from CE > > > > > to FE, the LFB class should be 'RedirectSource'. > > > > > Instance ID: > > > > > Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. > > > > > Operation TLV: > > > > > This is a TLV describing one packet of data to be directed > via the > > > > > specified LFB above. The order of the TLV appeared is also the > > > > > order the data packet arrives the redirector LFB, that is, the > > > > > Redirected Data in the first TLV should arrive the earliest. > > > > > > > > > >The TLV format is as follows: > > > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Type = > PAYLOAD | Length | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ Packet Type | Packet > Length ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > ~ Redirected > Packet ~ > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > Type: > > > > > The type for the TLV is set to 'PAYLOAD'. > > > > > > > > > > Length: > > > > > the length of the TLV(in 4bytes). > > > > > > > > > > Packet Type: > > > > > Defines what type the redirected packet belongs to(such as > 'IPv4 > > > > > Packet', > > > > > 'IPv6 Packet'). > > > > > > > > > > Packet Length: > > > > > the length of the followed redirected packet (in byte) > > > > > > > > > > Redirected Packet: > > > > > one redirected packet. > > > > >----------------------------- > > > > > > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > <joel@stevecrocker.com> > > > > > > > > > > > I would expect that a Redirect Message has a different outermost > > > TLV. The > > > > > > grammar is intended to help us, not serve as a > > > straightjacket. Different > > > > > > message types can have different outer TLVs. It is desirable to > > > use the > > > > > > same structure when it applies. But the redirect message is > simply a > > > > > > different case. It's contents are not a DATARAW much less a DATA > > > > > TLV. Its > > > > > > content structure is not defined by an LFB element definition > or Model > > > > > > DataDefs structure definition. > > > > > > > > > > > > If we need to fix the "grammar" section to make it clear that not > > > all PL > > > > > > messages necessarily use the same outermost TLV, we should do > > > so. My own > > > > > > approach would be to separate the grammar into a definition of the > > > > > contents > > > > > > of that TLV, and a separate definition of which TLVs / content are > > > carried > > > > > > in the outermost level of which messages. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > > > > > > > > > PS: Weiming, I am sorry you got caught up in this confusion. I > don't > > > > > think > > > > > > you created the tendency I am railing against above. I am just > > > using your > > > > > > message as a starting point to hammer home a point. > > > > > > > > > > > > At 04:45 AM 6/26/2005, Wang,Weiming wrote: > > > > > > >Maybe it's me who missed something :) > > > > > > >My thought was we might need to obey our message grammar well > that we > > > > > have > > > > > > >to use a strict Path-data for operation TLV. To obey the rule, > > > treating > > > > > > >it as an event will ease the message format greatly. > > > > > > > > > > > > > >Actually I'm very happy to see that you agree a path can be > > > omitted for > > > > > > >some specific messages like redirect messge. > > > > > > > > > > > > > >OK, let's solve it then, to let redirect message only contain Data > > > > > > >field? I can update this redirect message part text then. > > > > > > > > > > > > > >Jamal, could you give a response on this? > > > > > > > > > > > > > >One less vital question is, shall we allow for mulitpul redirect > > > packets > > > > > > >encapsulated in one TLV or just one TLV only for one packet? To > > > use the > > > > > > >former, we have to define a sequence for the redirected packets > > > then in > > > > > > >the TLV. > > > > > > > > > > > > > >On the meta-information related, I think LFB IDs has already been > > > > > > >included. I don't think we need an extra port ID to indicate > where > > > to put > > > > > > >the redirected data to or to get redirected data from. A redirect > > > source > > > > > > >LFB or sink LFB will have a port ID, which belongs to FE LFB > > > topology > > > > > > >concept, and FE LFB topolgy configuration is in charge of > > > this. Not sure > > > > > > >if it complies with your thought? > > > > > > > > > > > > > >Thanks, > > > > > > >Weiming > > > > > > > > > > > > > >----- Original Message ----- > > > > > > >From: "Joel M. Halpern" > > > > > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > > > I am missign something in your suggestion. > > > > > > > > > > > > > > > > Why would we want to treat redirects as events? > > > > > > > > We should treat them as redirects. > > > > > > > > > > > > > > > > I am very confused about "How a path should be defined in a > Packet > > > > > > > Redirect > > > > > > > > Message", since as far as I can tell, a redirect does not > need a > > > > > path. It > > > > > > > > needs a collection of meta-information, which we need to > > > > > define. At the > > > > > > > > moment, that has to include at least the LFB ID that the > > > redirect is > > > > > > > from / > > > > > > > > to. I suppose by declaring a multiplicity of such LFBs, that > > > can be > > > > > > > all of > > > > > > > > the information. (I usually think in terms of at least a > logical > > > > > port ID > > > > > > > > the packet came from / is intended for.) > > > > > > > > > > > > > > > > Yours, > > > > > > > > Joel > > > > > > > > > > > > > > > > At 10:50 PM 6/25/2005, Weiming Wang wrote: > > > > > > > > >Jamal, Joel, and Hormzd, > > > > > > > > > > > > > > > > > >I suppose we could close this issue by reaching the following > > > points: > > > > > > > > > > > > > > > > > >1. The redirect LFBs called RedirectSource LFB and > RedirectSink > > > > > LFB are > > > > > > > > >moved to the model, but the protocol retains the Redirect > > > Message. The > > > > > > > > >reason to keep the specific message is we need to specifically > > > > > recognize > > > > > > > > >redirected data between CE-FE transportation to avoid DoS > attacks. > > > > > > > > > > > > > > > > > >2. The redirected data in the LFBs can be treated as a > kind of > > > SPECIAL > > > > > > > > >events in that: > > > > > > > > > a. The event is triggered every time a new > redirected packet > > > > > > > arrives > > > > > > > > > at the LFBs. > > > > > > > > > b. The event is transported by the Redirect Message > only, > > > > > while > > > > > > > the > > > > > > > > > Redirect Message will the same message format as a > general event > > > > > > > > > notification message (except the message type in the header). > > > > > > > > > > > > > > > > > >By doing in this way, we can also solve the issue53 (How a > path > > > > > should be > > > > > > > > >defined in Packet Redirect Message) then. > > > > > > > > > > > > > > > > > >Unfortunately, I think of another question that is > related to > > > the > > > > > Packet > > > > > > > > >Redirect Message as well as to Event Notification Message. The > > > > > question > > > > > > > > >is, the Event Notification Message allows event generated > by CE > > > > > and sent > > > > > > > > >to FE. In the case, in the message format, the LFB IDs > refer to > > > > > the LFBs > > > > > > > > >that will receive the event notification, but the question is, > > > > > what the > > > > > > > > >Path in the message refers to then ?? The same also happens > > > to Packet > > > > > > > > >Redirect Message from CE to FE. > > > > > > > > > > > > > > > > > >Thanks, > > > > > > > > >Weiming > > > > > > > > > > > > > > > > > >----- Original Message ----- > > > > > > > > >From: "Avri Doria" > > > > > <tracker-forces@mip4.org> > > > > > > > > >To: > > > <FORCES@PEACH.EASE.LSOFT.COM> > > > > > > > > >Sent: Monday, May 23, 2005 2:35 AM > > > > > > > > >Subject: [issue32] Packet Redirect > > > > > > > > > > > > > > > > > > > > > > > > > > >New submission from Avri Doria > > > <avri@acm.org>: > > > > > > > > > > > > > > > > > >6.8 > > > > > > > > > > > > > > > > > > Editorial Note: There are also discussions on how LFBs in > > > FE model > > > > > > > > > that are related to packet redirect > > > operations > > > > > > > > > should be defined. Although it is > out of > > > the > > > > > scope > > > > > > > > > of forces protocol, how to define the > > > LFBs affect > > > > > > > > > the Packet Redirect Message described > > > > > here. Because > > > > > > > > > currently it is still in progress in FE > > > model > > > > > on how > > > > > > > > > to define such LFBs, we try to post some > > > > > thoughts on > > > > > > > > > this here for discussion. They will be > > > removed > > > > > > > > > later along with the progress of the FE > > > model > > > > > work. > > > > > > > > > Thought 1: To define LFBs called 'RedirectSink' and > > > > > > > > > 'RedirectTap' for packet redirect. > > > > > > > > > An LFB in FE called 'RedirectSink' is > > > > > responsible to > > > > > > > > > collect data packets that need to be > > > > > redirected to > > > > > > > > > CE. From the perspective of the FE LFB > > > topology, > > > > > > > > > the 'RedirectSink' LFB is an LFB with > only > > > > > one input > > > > > > > > > port and without any output port, and the > > > > > input port > > > > > > > > > can then be connected to any other > LFB in FE > > > > > model > > > > > > > > > by means of a datapath in the forwarding > > > plane. > > > > > > > > > From the perspective of the ForCES > protocol > > > > > layer, > > > > > > > > > the 'RedirectSink' LFB will generate the > > > Packet > > > > > > > > > Redirect Messages when it receives data > > > > > packets from > > > > > > > > > forwarding plane. > > > > > > > > > > > > > > > > > > An LFB in FE called 'RedirectTap' is > > > > > responsible to > > > > > > > > > receive data packets that are redirected > > > from CE. > > > > > > > > > From the perspective of the FE LFB > > > topology, the > > > > > > > > > 'RedirectTap' LFB is an LFB with only > one > > > output > > > > > > > > > port and without any input port, and the > > > > > output port > > > > > > > > > can then be connected to any other > LFB in FE > > > > > model > > > > > > > > > by means of a datapath in the forwarding > > > plane. > > > > > > > > > From the perspective of ForCES protocol > > > > > layer, the > > > > > > > > > 'RedirectTap' LFB can receive the Packet > > > Redirect > > > > > > > > > Messages from CE, and un-encapsulate > the data > > > > > > > > > packets from the message and put them to > > > > > datapaths > > > > > > > > > in the forwarding plane. Actually the > > > > > 'RecirectTap' > > > > > > > > > LFB acts more like a transcoder that > > > > > transfers the > > > > > > > > > ForCES protocol messages to normal data > > > > > packets in > > > > > > > > > IP forwarding plane. As a result, if we > > > need to > > > > > > > > > have redirected packets connected to > some > > > LFB > > > > > (say a > > > > > > > > > Scheduler) in FE model, we only need to > > > > > connect the > > > > > > > > > 'RedirectTap LFB to the Scheduler LFB > > > > > directly via a > > > > > > > > > datapath as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > +-----------------+ > > > +-----------+ > > > > > > > > > | RedirectTap LFB > > > |------>| | > > > > > > > > > +-----------------+ | > > > | > > > > > > > > > | > > > Scheduler | > > > > > > > > > From other > > > LFB ---->| LFB | > > > > > > > > > | > > > | > > > > > > > > > > > > +-----------+ > > > > > > > > > > > > > > > > > > Figure 27 > > > > > > > > > > > > > > > > > > By use of several 'RedirectSink' LFBs > and > > > several > > > > > > > > > 'RedirectTap' LFBs that connect to > several > > > > > different > > > > > > > > > datapaths in FE forwarding plane, > > > multiple packet > > > > > > > > > redirect paths between CE and FE can be > > > > > constructed. > > > > > > > > > > > > > > > > > > Thought 2: There might be another way a packet > could be > > > > > > > > > redirected: directly by a forwarding > path, > > > > > e.g., by > > > > > > > > > FPGA/ASIC/NP microcode. In such a case > > > we do not > > > > > > > > > need to put in a lot of > smartness. Probably > > > > > a link > > > > > > > > > layer or even network level header is > > > > > enough. The > > > > > > > > > receiver demuxes it only based on some > > > > > protocol type > > > > > > > > > in the link layer or network transport > > > > > layer. The > > > > > > > > > pros for this appraoch is it may > provide a > > > > > fast and > > > > > > > > > cost-effective path for packet > > > redirect. The > > > > > cons > > > > > > > > > for this is it may more or less confuses > > > the Fp > > > > > > > > > reference point definition in ForCES > > > framework. > > > > > > > > > > > > > > > > > >---------- > > > > > > > > >category: Editorial > > > > > > > > >draft: draft-ietf-forces-protocol > > > > > > > > >messages: 49 > > > > > > > > >nosy: avri > > > > > > > > >priority: Must fix > > > > > > > > >status: No discussion > > > > > > > > >title: Packet Redirect > > > > > > > > > > > > > > > > > >___________________________________________________ > > > > > > > > >Forces issue tracker > > > > > <tracker-forces@mip4.org> > > > > > > > > > > > > > > > > > >___________________________________________________ > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 28 08:57:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFeU-0000Zr-24 for forces-archive@megatron.ietf.org; Tue, 28 Jun 2005 08:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04785 for ; Tue, 28 Jun 2005 08:57:20 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnG3l-0007yo-SL for forces-archive@IETF.ORG; Tue, 28 Jun 2005 09:23:34 -0400 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.010912BA@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 8:57:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77171511 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 08:57:13 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 08:57:12 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062806002997:57425 ; Tue, 28 Jun 2005 06:00:29 -0700 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/28/2005 06:00:30 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/28/2005 06:00:31 AM, Serialize complete at 06/28/2005 06:00:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1119963431.6411.29.camel@localhost.localdomain> Date: Tue, 28 Jun 2005 08:57:11 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050627231906.02d0e120@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit On Mon, 2005-27-06 at 23:20 -0400, Joel M. Halpern wrote: > Given that packets requiring redirection are likely to be scattered, and > given that multiple redirect TLVs (each with a packet) can be included in a > message if that is useful, I don't see much value it the extra wrapper to > allow multiple packets inside the TLV. > Let me share what we do - i havent really read the thread in full to make full sense of what Joel/Weiming are saying[1]. So i dont know who i am agreeing with ;-> Heres an example of a redirect that we have implemented thus far shipped as a Forces message. common header (type = REDIRECT) | | +---- LFB selector (Redirect LFB, instance X) | | +----- TLV, Type = REDIRECT_device (for lack of better name) | | +--- ifindex of sink or source port | | +--- Packet data in network order Several observations: 1) In theory, we should be able to repeat the TLV multiple times to send several packets in one PL message. We dont do that at the moment; when we get to optimizing we will probably do so. 2) There is only one termination point for either source/sink - they are not being differentiated as two different things. So when the message goes from FE->CE, the ifindex is that of the FEs port in which in the packet was received/sourced. On the CE->FE direction, the ifindex is that of the FEs port in which the the packet is to be transmitted. We found that we absolutely needed to at least have this little ifindex header. 3) There is only one REDIRECT LFB and several instances (one for IKE, one for OSPF etc). Some performance numbers: Here are some numbers when we use different redirect schemes from the FE->CE: Scheme 1: As described above, MUST implement for forces. Roundtrip latency adds 1.1 ms (note we cross to/fro user space 4 times) Scheme 2: I described earlier, tagged as the TML redirect by Joel: (redirect happens in the forwarding path; this could be in the kernel or in hardware): adds less than 10us to round trip latency. cheers, jamal [1]I am very tied up elsewhere but hope to resurface and catchup on the list hopefully by end of day or tommorow (I will attend the next concal thursday btw - sorry havent responded). From AmandaMoore@adeptness.com Tue Jun 28 10:02:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGf7-0001QC-Np for forces-archive@megatron.ietf.org; Tue, 28 Jun 2005 10:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10463; Tue, 28 Jun 2005 10:02:03 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnH4M-0006NP-Dw; Tue, 28 Jun 2005 10:28:17 -0400 Received: from [211.117.134.245] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DnGet-0002T0-7U; Tue, 28 Jun 2005 10:01:53 -0400 Received: from 3ym@localhost by K1SS.int (8.11.6/8.11.6); Tue, 28 Jun 2005 19:29:17 +0400 Message-ID: From: "Ingrid Kerns" Reply-To: "Ingrid Kerns" To: imrg-archive@ietf.org Cc: forces-archive@ietf.org Subject: MS Office XP Pro $49.95 Windows XP Date: Tue, 28 Jun 2005 10:31:17 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AmandaMoore@adeptness.com Content-Type: multipart/mixed; boundary="--s0ZcS0n1cahNJSYjNgJ" X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 qDh ----s0ZcS0n1cahNJSYjNgJ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable V
Opt-in Email Special Offer &n= bsp;   unsubscribe me
=
SEARCH



<= /tr>

TOP 10 NEW TITLES

= =  

 = ON SALE NOW!

 1 Office Pro 2003
 2 = Windows XP Pro
 3 Ado= be Creative Suite Premium
 4= Norton Antivirus 2005
&nbs= p;5 Flash MX 2004
 <= /td>6 Corel Draw 12
 7 Adobe Acrobat 7.0
 = 8 Windows 2003 Server
&= nbsp;9 Alias Maya 6 Wavefrt
 10 Adobe Premiere
  See more by this manufacturer
   Microsoft
   Ap= ple Software
  Custom= ers also bought
  these other items...=
Microsoft Office Professional Edition *2003*=
Microsof= t
Choose:
 
You Save:


Availability: Available for INSTANT do= wnload!
Coupon Code: ISe229
Media: CD-ROM / Download=

= System requirements  |  Accessories  |  Other = Versions

Features:

  • Analyze and manage busi= ness information using Access databases
  • Exchange data with other systems using enhanced XML technology=
  • Control information sharing= rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marke= ting materials
  • More than 20 = preformatted business reports
= Sales Rank: #1
Shipping: International/US o= r via instant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D"5 Based = on 1,768 reviews. Write a review.=
List Price:$899.00
Price:$69.99
$830.01 (92%)
Microsoft Windows XP Professional or Longho= rn Edition
Microsoft
= Choose:
<= select name=3DD1>  

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Avail= ability: Available for INSTANT download!
Coupon Code: ISe22= 9
Media: CD-ROM / Download

= System requirements  | = Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and= more
  • More security with the= ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and ma= nagement solutions

Sales Rank: #2
Shipping: International/US or via instant do= wnload
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. = Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
Choo= se:
 

List Price: = $599.00
Price:$69.99
You Save:$529.01 (90= %)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Me= dia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Feat= ures:

  • Customized workspace; save personalized workspace and tool settings= ; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in or cust= omized scripts
  • Improved file= management, new design possibilities, and a more intuitive way to create = for the Web
  • Support for 16-b= it images, digital camera raw data, and non-square pixels
    • Create or modify photos using painting, draw= ing, and retouching tools

Sales Rank: #3
Shipping: International/US or = via instant download
Date Coupon Expires: June 30th, 2005
<= /span>Average Customer Review: 3D"5 Based on= 498 reviews. Write a review.

----s0ZcS0n1cahNJSYjNgJ-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 28 23:24:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnTBg-0007cZ-DG for forces-archive@megatron.ietf.org; Tue, 28 Jun 2005 23:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27487 for ; Tue, 28 Jun 2005 23:24:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnTb0-0003RN-72 for forces-archive@IETF.ORG; Tue, 28 Jun 2005 23:50:52 -0400 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.0109247E@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 23:24:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77244611 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 23:24:11 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 23:24:09 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 74778.804536222; Wed, 29 Jun 2005 12:00:59 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 29 Jun 2005 11:21:47 +0800 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> <1119963431.6411.29.camel@localhost.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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Approved-By: "Wang,Weiming" Message-ID: <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> Date: Wed, 29 Jun 2005 11:21:39 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 4.0 (++++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLg0KDQpJIHRoaW5rIHRoZSBrZXkgZGlm ZmVyZW5jZSBpcyBob3cgdGhlIFJlZGlyZWN0IFNvdXJjZSBhbmQgU2luayBMRkIsIHdob3NlIHBv cnRzIHNob3VsZCBiZSBkZWZpbmVkLiBMZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB0aGUgaWRlYXMg Zmlyc3Q6DQoxLiB5b3Vycywgb25seSBvbmUgUmVkaXJlY3QgTEZCIHdoaWNoIGhhdmUgbXVsaXRw bGUgaW5wdXRzIGFzIHRoZSBzaW5rIHBvcnRzIHRvIHJlZGlyZWN0IGRhdGEgZnJvbSBGRS0+Q0Us IGFuZCBtdWx0aXBsZSBvdXRwdXRzIGFzIHRoZSBzb3VyY2UgcG9ydHMgdG8gcmVkaXJlY3QgZGF0 YSBmcm9tIENFLT5GRS4gV2l0aCB0aGlzIHNjaGVtZSwgdGhlbiBwb3J0IG51bWJlciBzaG91bGQg YXBwZWFyIGluIHRoZSBQTCByZWRpcmVjdCBtZXNzYWdlIGZvcm1hdC4NCg0KMi4gbWluZSwgc2V2 ZXJhbCByZWRpcmVjdCBMRkJzLCB3aXRoIGV2ZXJ5IExGQiBvbmx5IGhhcyBvbmUgaW5wdXQoc2lu ayBMRkIpIG9yIG9uZSBvdXRwdXQoc291cmNlIExGQikuIFdpdGggdGhpcyBzY2hlbWUsIHRoZXJl IGlzIG5vIG5lZWQgdG8gYXNzaWduIGEgcG9ydCBudW1iZXIgYXQgdGhlIFBMIHJlZGlyZWN0IG1l c3NhZ2UgbGF5ZXIuIFRoZSBMRkIgaW5zdGFuY2UgSUQgYWN0dWFsbHkgYWN0cyBhcyB0aGUgZnVu Y3Rpb24gb2YgcG9ydCBudW1iZXIgaW4gc2NoZW1lIDEuDQoNCkpvZWwgYW5kIEkgYWN0dWFsbHkg aGF2ZSBoYWQgYSBzaG9ydCBkaXNjdXNzaW9uIG9uIHRoaXMuIEpvZWwncyB0aG91Z2h0IHdhcyB2 ZXJ5IGlkZW50aWNhbCB0byB5b3VycywgYnV0IEkganVzdCBhcmd1ZWQgdGhhdCB0aGUgcmVkaXJl Y3QgTEZCIGluc3RhbmNlIElEIGNhbiBhY3Qgd2VsbCB0byBpbXBsZW1lbnQgdGhlIHRhc2sgYXMg d2hlcmUgdGhlIHJlZGlyZWN0IGRhdGEgc2hvdWxkIGdldCBhbmQgcHV0IGluIHRoZSBMRkIgdG9w b2xvZ3kuIEFuZCBJJ20gYWxzbyBhIGxpdHRsZSB3b3JyeSB0aGF0ICdhIHBvcnQgbnVtYmVyJyBp cyBwYXJhbWV0ZXIgdGhhdCB3aWxsIGhpZ2hseSBsaW5rcyB0byBob3cgRkUgbW9kZWwgZGVmaW5l cy4gVG8gZGlyZWN0bHkgdXNlIGEgRkUgbW9kZWwgcGFyYW1ldGVyIHdpdGhvdXQgdXNpbmcgYSBQ QVRILURBVEEgcnVsZSBpbiB0aGUgUEwgbGF5ZXIgbWF5IHJlc3VsdCBpbiB0b28gaGlnaCBiaW5k aW5nIG9mIHRoZSBwcm90b2NvbCBhbmQgdGhlIEZFIG1vZGVsLCBpLmUuLCBtb2RlbCBkZWZpbml0 aW9uIG1heSBoYXZlIHRvIG1ha2UgdGhlIHByb3RvY29sIGNoYW5nZS4gIA0KDQpSZWdhcmRpbmcg dGhlIHJlZGlyZWN0IGRpcmVjdGx5IGF0IFRNTCBsYXllciwgY291bGQgeW91IGdpdmUgbW9yZSBk ZXRhaWxzLCBsaWtlIG9uIHdoaWNoIGxheWVyIGl0IGlzIGluamVjdGVkLCB0aGUgVENQLCBJUCwg b3IgVlBOPyBFeGNlcHQgZG9pbmcgaXQgZGlyZWN0bHkgYXQgSVAsIEkgZmluZCBvdGhlcnMgbWF5 IGFsbCBoYXZlIHRvIGhhdmUgdGhlIGhlbHAgZnJvbSB1c2VyIHNwYWNlLCByYXRoZXIgdGhhbiBm cm9tIHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9ubHksIHdoaWNoIG1ha2VzIGl0IHF1aXRlIHRoZSBz YW1lIGFzIHJlZGlyZWN0IGF0IFBMIGxheWVyLiANCg0KVGhhbmtzLA0KV2VpbWluZw0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRp QHpueXguY29tPg0KU3ViamVjdDogUmU6IFtpc3N1ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCg0KDQo+ IE9uIE1vbiwgMjAwNS0yNy0wNiBhdCAyMzoyMCAtMDQwMCwgSm9lbCBNLiBIYWxwZXJuIHdyb3Rl Og0KPiA+IEdpdmVuIHRoYXQgcGFja2V0cyByZXF1aXJpbmcgcmVkaXJlY3Rpb24gYXJlIGxpa2Vs eSB0byBiZSBzY2F0dGVyZWQsIGFuZCANCj4gPiBnaXZlbiB0aGF0IG11bHRpcGxlIHJlZGlyZWN0 IFRMVnMgKGVhY2ggd2l0aCBhIHBhY2tldCkgY2FuIGJlIGluY2x1ZGVkIGluIGEgDQo+ID4gbWVz c2FnZSBpZiB0aGF0IGlzIHVzZWZ1bCwgSSBkb24ndCBzZWUgbXVjaCB2YWx1ZSBpdCB0aGUgZXh0 cmEgd3JhcHBlciB0byANCj4gPiBhbGxvdyBtdWx0aXBsZSBwYWNrZXRzIGluc2lkZSB0aGUgVExW Lg0KPiA+IA0KPiANCj4gTGV0IG1lIHNoYXJlIHdoYXQgd2UgZG8gLSBpIGhhdmVudCByZWFsbHkg cmVhZCB0aGUgdGhyZWFkIGluIGZ1bGwgdG8NCj4gbWFrZSBmdWxsIHNlbnNlIG9mIHdoYXQgSm9l bC9XZWltaW5nIGFyZSBzYXlpbmdbMV0uIFNvIGkgZG9udCBrbm93IHdobyBpDQo+IGFtIGFncmVl aW5nIHdpdGggOy0+IA0KPiANCj4gSGVyZXMgYW4gZXhhbXBsZSBvZiBhIHJlZGlyZWN0IHRoYXQg d2UgaGF2ZSBpbXBsZW1lbnRlZCB0aHVzIGZhciBzaGlwcGVkDQo+IGFzIGEgRm9yY2VzIG1lc3Nh Z2UuDQo+IA0KPiBjb21tb24gaGVhZGVyICh0eXBlID0gUkVESVJFQ1QpDQo+IHwNCj4gfA0KPiAr LS0tLSBMRkIgc2VsZWN0b3IgKFJlZGlyZWN0IExGQiwgaW5zdGFuY2UgWCkNCj4gICAgICAgfA0K PiAgICAgICB8DQo+ICAgICAgICstLS0tLSBUTFYsIFR5cGUgPSBSRURJUkVDVF9kZXZpY2UgKGZv ciBsYWNrIG9mIGJldHRlciBuYW1lKSANCj4gICAgICAgICAgICAgICB8DQo+ICAgICAgICAgICAg ICAgfA0KPiAgICAgICAgICAgICAgICstLS0gaWZpbmRleCBvZiBzaW5rIG9yIHNvdXJjZSBwb3J0 DQo+ICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAr LS0tIFBhY2tldCBkYXRhIGluIG5ldHdvcmsgb3JkZXINCj4gDQo+IFNldmVyYWwgb2JzZXJ2YXRp b25zOg0KPiANCj4gMSkgSW4gdGhlb3J5LCB3ZSBzaG91bGQgYmUgYWJsZSB0byByZXBlYXQgdGhl IFRMViBtdWx0aXBsZSB0aW1lcyB0byBzZW5kDQo+IHNldmVyYWwgcGFja2V0cyBpbiBvbmUgUEwg bWVzc2FnZS4gV2UgZG9udCBkbyB0aGF0IGF0IHRoZSBtb21lbnQ7IHdoZW4NCj4gd2UgZ2V0IHRv IG9wdGltaXppbmcgd2Ugd2lsbCBwcm9iYWJseSBkbyBzby4NCj4gDQo+IDIpIFRoZXJlIGlzIG9u bHkgb25lIHRlcm1pbmF0aW9uIHBvaW50IGZvciBlaXRoZXIgc291cmNlL3NpbmsgLSB0aGV5IGFy ZQ0KPiBub3QgYmVpbmcgZGlmZmVyZW50aWF0ZWQgYXMgdHdvIGRpZmZlcmVudCB0aGluZ3MuIFNv IHdoZW4gdGhlIG1lc3NhZ2UNCj4gZ29lcyBmcm9tIEZFLT5DRSwgdGhlIGlmaW5kZXggaXMgdGhh dCBvZiB0aGUgRkVzIHBvcnQgaW4gd2hpY2ggaW4gdGhlDQo+IHBhY2tldCB3YXMgcmVjZWl2ZWQv c291cmNlZC4gT24gdGhlIENFLT5GRSBkaXJlY3Rpb24sIHRoZSBpZmluZGV4IGlzDQo+IHRoYXQg b2YgdGhlIEZFcyBwb3J0IGluIHdoaWNoIHRoZSB0aGUgcGFja2V0IGlzIHRvIGJlIHRyYW5zbWl0 dGVkLiBXZQ0KPiBmb3VuZCB0aGF0IHdlIGFic29sdXRlbHkgbmVlZGVkIHRvIGF0IGxlYXN0IGhh dmUgdGhpcyBsaXR0bGUgaWZpbmRleA0KPiBoZWFkZXIuDQo+IA0KPiAzKSBUaGVyZSBpcyBvbmx5 IG9uZSBSRURJUkVDVCBMRkIgYW5kIHNldmVyYWwgaW5zdGFuY2VzIChvbmUgZm9yIElLRSwNCj4g b25lIGZvciBPU1BGIGV0YykuDQo+IA0KPiBTb21lIHBlcmZvcm1hbmNlIG51bWJlcnM6DQo+IEhl cmUgYXJlIHNvbWUgbnVtYmVycyB3aGVuIHdlIHVzZSBkaWZmZXJlbnQgcmVkaXJlY3Qgc2NoZW1l cyBmcm9tIHRoZQ0KPiBGRS0+Q0U6DQo+IA0KPiBTY2hlbWUgMTogQXMgZGVzY3JpYmVkIGFib3Zl LCBNVVNUIGltcGxlbWVudCBmb3IgZm9yY2VzLiBSb3VuZHRyaXANCj4gbGF0ZW5jeSBhZGRzIDEu MSBtcyAobm90ZSB3ZSBjcm9zcyB0by9mcm8gdXNlciBzcGFjZSA0IHRpbWVzKQ0KPiANCj4gU2No ZW1lIDI6IEkgZGVzY3JpYmVkIGVhcmxpZXIsIHRhZ2dlZCBhcyB0aGUgVE1MIHJlZGlyZWN0IGJ5 IEpvZWw6DQo+IChyZWRpcmVjdCBoYXBwZW5zIGluIHRoZSBmb3J3YXJkaW5nIHBhdGg7IHRoaXMg Y291bGQgYmUgaW4gdGhlIGtlcm5lbCBvcg0KPiBpbiBoYXJkd2FyZSk6IGFkZHMgbGVzcyB0aGFu IDEwdXMgdG8gcm91bmQgdHJpcCBsYXRlbmN5Lg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbCANCj4g DQo+IFsxXUkgYW0gdmVyeSB0aWVkIHVwIGVsc2V3aGVyZSBidXQgaG9wZSB0byByZXN1cmZhY2Ug YW5kIGNhdGNodXAgb24gdGhlDQo+IGxpc3QgaG9wZWZ1bGx5IGJ5IGVuZCBvZiBkYXkgb3IgdG9t bW9yb3cgKEkgd2lsbCBhdHRlbmQgdGhlIG5leHQgY29uY2FsDQo+IHRodXJzZGF5IGJ0dyAtIHNv cnJ5IGhhdmVudCByZXNwb25kZWQpLg0K From owner-forces@PEACH.EASE.LSOFT.COM Tue Jun 28 23:48:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnTYi-0005Ud-IR for forces-archive@megatron.ietf.org; Tue, 28 Jun 2005 23:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28988 for ; Tue, 28 Jun 2005 23:48:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnTyC-0004gd-Ev for forces-archive@IETF.ORG; Wed, 29 Jun 2005 00:14:40 -0400 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.010923E7@cherry.ease.lsoft.com>; Tue, 28 Jun 2005 23:47:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77246414 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 28 Jun 2005 23:47:55 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 28 Jun 2005 23:47:55 -0400 Received: from [162.84.73.204] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11159190; Tue, 28 Jun 2005 23:47:49 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> <1119963431.6411.29.camel@localhost.localdomain> <115b01c57c59$a9cd1310$1152010a@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.1.2.0.20050628234531.02e79440@localhost> Date: Tue, 28 Jun 2005 23:47:36 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 I am concerned that this approach will mandate a very large number of Redirect LFBs for those FEs that support logical interfaces (802.1 VLANs, Frame Relay or ATM VCs, etc.) For other uses, we have allowed that meta-data may be used to index into LFBs which have tables of behaviors. (We have not mandated that, either.) It would seem by analogy that we should allow similar tables for Redirect LFBs. Which means we need to carry the "meta" information somehow between the CE and the FE. Yours, Joel At 11:21 PM 6/28/2005, Wang,Weiming wrote: >Jamal, > >Thanks for the response. > >I think the key difference is how the Redirect Source and Sink LFB, whose >ports should be defined. Let me try to summarize the ideas first: >1. yours, only one Redirect LFB which have mulitple inputs as the sink >ports to redirect data from FE->CE, and multiple outputs as the source >ports to redirect data from CE->FE. With this scheme, then port number >should appear in the PL redirect message format. > >2. mine, several redirect LFBs, with every LFB only has one input(sink >LFB) or one output(source LFB). With this scheme, there is no need to >assign a port number at the PL redirect message layer. The LFB instance ID >actually acts as the function of port number in scheme 1. > >Joel and I actually have had a short discussion on this. Joel's thought >was very identical to yours, but I just argued that the redirect LFB >instance ID can act well to implement the task as where the redirect data >should get and put in the LFB topology. And I'm also a little worry that >'a port number' is parameter that will highly links to how FE model >defines. To directly use a FE model parameter without using a PATH-DATA >rule in the PL layer may result in too high binding of the protocol and >the FE model, i.e., model definition may have to make the protocol change. > >Regarding the redirect directly at TML layer, could you give more details, >like on which layer it is injected, the TCP, IP, or VPN? Except doing it >directly at IP, I find others may all have to have the help from user >space, rather than from the forwarding plane only, which makes it quite >the same as redirect at PL layer. > >Thanks, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" >Subject: Re: [issue32] Packet Redirect > > > > On Mon, 2005-27-06 at 23:20 -0400, Joel M. Halpern wrote: > > > Given that packets requiring redirection are likely to be scattered, and > > > given that multiple redirect TLVs (each with a packet) can be > included in a > > > message if that is useful, I don't see much value it the extra > wrapper to > > > allow multiple packets inside the TLV. > > > > > > > Let me share what we do - i havent really read the thread in full to > > make full sense of what Joel/Weiming are saying[1]. So i dont know who i > > am agreeing with ;-> > > > > Heres an example of a redirect that we have implemented thus far shipped > > as a Forces message. > > > > common header (type = REDIRECT) > > | > > | > > +---- LFB selector (Redirect LFB, instance X) > > | > > | > > +----- TLV, Type = REDIRECT_device (for lack of better name) > > | > > | > > +--- ifindex of sink or source port > > | > > | > > +--- Packet data in network order > > > > Several observations: > > > > 1) In theory, we should be able to repeat the TLV multiple times to send > > several packets in one PL message. We dont do that at the moment; when > > we get to optimizing we will probably do so. > > > > 2) There is only one termination point for either source/sink - they are > > not being differentiated as two different things. So when the message > > goes from FE->CE, the ifindex is that of the FEs port in which in the > > packet was received/sourced. On the CE->FE direction, the ifindex is > > that of the FEs port in which the the packet is to be transmitted. We > > found that we absolutely needed to at least have this little ifindex > > header. > > > > 3) There is only one REDIRECT LFB and several instances (one for IKE, > > one for OSPF etc). > > > > Some performance numbers: > > Here are some numbers when we use different redirect schemes from the > > FE->CE: > > > > Scheme 1: As described above, MUST implement for forces. Roundtrip > > latency adds 1.1 ms (note we cross to/fro user space 4 times) > > > > Scheme 2: I described earlier, tagged as the TML redirect by Joel: > > (redirect happens in the forwarding path; this could be in the kernel or > > in hardware): adds less than 10us to round trip latency. > > > > cheers, > > jamal > > > > [1]I am very tied up elsewhere but hope to resurface and catchup on the > > list hopefully by end of day or tommorow (I will attend the next concal > > thursday btw - sorry havent responded). From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 29 00:24:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnU7K-0007mM-Pf for forces-archive@megatron.ietf.org; Wed, 29 Jun 2005 00:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01489 for ; Wed, 29 Jun 2005 00:24:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnUWm-00068L-0x for forces-archive@IETF.ORG; Wed, 29 Jun 2005 00:50:27 -0400 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.010925B6@cherry.ease.lsoft.com>; Wed, 29 Jun 2005 0:24:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77252156 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 29 Jun 2005 00:23:53 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 29 Jun 2005 00:23:53 -0400 Received: from [162.84.73.204] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11159493 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 29 Jun 2005 00:23:52 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> <1119963431.6411.29.camel@localhost.localdomain> <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050628234531.02e79440@localhost> <117101c57c5f$2d90aa40$1152010a@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.1.2.0.20050629002140.02e791b0@localhost> Date: Wed, 29 Jun 2005 00:23:46 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <117101c57c5f$2d90aa40$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Having a general, isolated, representation for the packet meta-data wiht the redirected packet seems like a good idea. Trying to come up with a good structure for that is one thing that has stumped me. Good ideas would be welcome. (I don't currently see how to use something like Path-Data, but that may just be me being obtuse.) Yours, Joel At 12:01 AM 6/29/2005, Wang,Weiming wrote: >Joel, > > > I am concerned that this approach will mandate a very large number of > > Redirect LFBs for those FEs that support logical interfaces (802.1 VLANs, > > Frame Relay or ATM VCs, etc.) For other uses, we have allowed that > > meta-data may be used to index into LFBs which have tables of > > behaviors. (We have not mandated that, either.) > > > > It would seem by analogy that we should allow similar tables for Redirect > > LFBs. Which means we need to carry the "meta" information somehow between > > the CE and the FE. >Is it possible we represent the meta-data in the protocol messages in a >more isolating way from the data itself, just like a Path-Data mode? > >Thanks, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 29 07:32:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnao6-0004BH-De for forces-archive@megatron.ietf.org; Wed, 29 Jun 2005 07:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07510 for ; Wed, 29 Jun 2005 07:32:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnbDY-0006Dz-5O for forces-archive@IETF.ORG; Wed, 29 Jun 2005 07:59:06 -0400 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.01092E2A@cherry.ease.lsoft.com>; Wed, 29 Jun 2005 7:32:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77310778 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 29 Jun 2005 07:32:32 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 29 Jun 2005 07:32:32 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062904354813:58940 ; Wed, 29 Jun 2005 04:35:48 -0700 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> <1119963431.6411.29.camel@localhost.localdomain> <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2005 04:35:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2005 04:35:49 AM, Serialize complete at 06/29/2005 04:35:49 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1120044750.10224.48.camel@localhost.localdomain> Date: Wed, 29 Jun 2005 07:32:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Wed, 2005-29-06 at 11:21 +0800, Wang,Weiming wrote: > Jamal, > > Thanks for the response. > > I think the key difference is how the Redirect Source and Sink LFB, whose ports should be defined. > Let me try to summarize the ideas first: > 1. yours, only one Redirect LFB which have mulitple inputs as the sink ports to redirect data from > FE->CE, and multiple outputs as the source ports to redirect data from CE->FE. With this scheme, then > port number should appear in the PL redirect message format. > > 2. mine, several redirect LFBs, with every LFB only has one input(sink LFB) or one output(source LFB). > With this scheme, there is no need to assign a port number at the PL redirect message layer. The LFB > instance ID actually acts as the function of port number in scheme 1. > > Joel and I actually have had a short discussion on this. Joel's thought was very identical to yours, > but I just argued that the redirect LFB instance ID can act well to implement the task as where the > redirect data should get and put in the LFB topology. And I'm also a little worry that 'a port number' > is parameter that will highly links to how FE model defines. To directly use a FE model parameter > without using a PATH-DATA rule in the PL layer may result in too high binding of the protocol and > the FE model, i.e., model definition may have to make the protocol change. > There are two things/numbers that are important: 1) the interface/port the packet goes in/out 2) the type of packet that is being filtered on receive. In our case #1 was in the ifindex i showed. #2 is in the instance of the class. Indeed both these parameters can be coded in the path; but if we do that it is better to keep a single LFB instance (Infact i would argue for a single LFB instance for simplicity). In such a case, the selection is of the form: FEx/LFB=redirect/instance=1/operation=config/path={port,filterid} . BTW, we havent really discussed how the CE subscribes to receive packets. > Regarding the redirect directly at TML layer, could you give more details, like on which layer it > is injected, the TCP, IP, or VPN? Except doing it directly at IP, I find others may all have to > have the help from user space, rather than from the forwarding plane only, which makes it quite > the same as redirect at PL layer. > Assume a stateless transport for this to work well; IP, ethernet etc. If you could map those two numbers {src/dst port, packet type} into something in a header, you could redirect to the PL layer. Lets say you could redirect at the FE in hardware (most of the ethernet switches my company sells are capable and i would suspect other vendors do): - add a filter rule in the FE hardware which says "if you see IKE packets on port 10 i want you to redirect to port 23 with VLAN tag Y" - CE is connected to port 23. On receipt of such a packet, the CE kernel or even user space is able to deduce (by looking at MAC + VLAN headers and peeking into the data) that the packet came through FE3, port 10 and is an IKE packet. - You can then reinject it with proper forces header to the forces process. We actually take more shortcuts, i am just simplifying. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Jun 29 07:39:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnauQ-0006Al-Ph for forces-archive@megatron.ietf.org; Wed, 29 Jun 2005 07:39:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07963 for ; Wed, 29 Jun 2005 07:39:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnbJx-0000QW-VM for forces-archive@IETF.ORG; Wed, 29 Jun 2005 08:05:39 -0400 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.01092E6B@cherry.ease.lsoft.com>; Wed, 29 Jun 2005 7:39:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77311129 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 29 Jun 2005 07:39:10 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 29 Jun 2005 07:39:10 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005062904422627:58948 ; Wed, 29 Jun 2005 04:42:26 -0700 References: <6.2.1.2.0.20050627225448.02d0efa8@localhost> <003501c57b8e$1d1a1bf0$020aa8c0@wwm1> <6.2.1.2.0.20050627231906.02d0e120@localhost> <1119963431.6411.29.camel@localhost.localdomain> <115b01c57c59$a9cd1310$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050628234531.02e79440@localhost> <117101c57c5f$2d90aa40$1152010a@Necom.hzic.edu.cn> <6.2.1.2.0.20050629002140.02e791b0@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2005 04:42:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 06/29/2005 04:42:27 AM, Serialize complete at 06/29/2005 04:42:27 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1120045147.10224.54.camel@localhost.localdomain> Date: Wed, 29 Jun 2005 07:39:06 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.2.1.2.0.20050629002140.02e791b0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Wed, 2005-29-06 at 00:23 -0400, Joel M. Halpern wrote: > Having a general, isolated, representation for the packet meta-data wiht > the redirected packet seems like a good idea. > Trying to come up with a good structure for that is one thing that has > stumped me. Good ideas would be welcome. > (I don't currently see how to use something like Path-Data, but that may > just be me being obtuse.) There are 2 attributes that i described earlier: - the ifindex and filterid. If we can say we have a table comprising of these attributes then we can certainly have a path to the pair of attributes. It is more than likely these two are aliases to attributes in two other LFBs (a port LFB and a classifier/filter LFB). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 30 10:52:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do0PG-0006an-QI for forces-archive@megatron.ietf.org; Thu, 30 Jun 2005 10:52:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20385 for ; Thu, 30 Jun 2005 10:52:44 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do0oy-0006JI-Ju for forces-archive@IETF.ORG; Thu, 30 Jun 2005 11:19:25 -0400 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.01094594@cherry.ease.lsoft.com>; Thu, 30 Jun 2005 10:52:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77464933 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 30 Jun 2005 10:52:00 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 30 Jun 2005 10:52:00 -0400 Received: from [162.84.110.194] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11186745 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 30 Jun 2005 10:51:55 -0400 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.20050630104547.02f12a50@localhost> Date: Thu, 30 Jun 2005 10:51:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Redirect Message To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Based on discussion, and based on my earlier message that specific protocol messages may have different top level TLVs, here is a description of the contents of a redirect message. A redirect message will contain a redirect TLV. A redirect TLV consists of three fixed fields, and meta-data TLV, and the packet. The fixed fields are o the LFB Class ID of the redirect source or redirect sink LFB on the FE associated with this packet o the LFB Instance ID of the redirect source or redirect sink LFB on the FE associated with this packet o an index within that LFB to identify configured properties of the packet. The meta-data TLV contains dynamic information needed by the FE or CE to process the packet. This will need to be spelled out in more detail. It may need to use path encoding. Following this will be the packet. Yours, Joel From owner-forces@PEACH.EASE.LSOFT.COM Thu Jun 30 15:04:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4Kn-0002Rh-DE for forces-archive@megatron.ietf.org; Thu, 30 Jun 2005 15:04:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12349 for ; Thu, 30 Jun 2005 15:04:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do4kb-0005nN-3c for forces-archive@IETF.ORG; Thu, 30 Jun 2005 15:31:06 -0400 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.01094839@cherry.ease.lsoft.com>; Thu, 30 Jun 2005 15:04:23 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 77485759 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 30 Jun 2005 15:04:22 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 30 Jun 2005 15:04:22 -0400 Received: from [162.84.110.194] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11189919 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 30 Jun 2005 15:04:21 -0400 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.20050630145538.02f3c768@localhost> Date: Thu, 30 Jun 2005 15:04:16 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Result TLV To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The following is what I suggest for handling results of operations. SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have DATARAW TLVs added to the leaf paths to carry the requested data. For GET elements that fail, instead of the DATARAW TLV there will be a RESULT TLV. For a SET response, each DATARAW TLV in the original request will be replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements of the request will appear in the response with RESULT TLVs. A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte) value. The defined values are 0 = success 1 = no such object 2 = permission denied 3 = invalid value (the dataraw could not validly be stored in the field) 4 = invalid array creation (when the subscript in an array create is not allowed) 255 = unspecified error (for when the FE can not decide what went wrong) We may need a few more values to cover other errors. Note that if a SET request with a structure in a DATARAW is issued, and some field in the structure is invalid, the FE will not attempt to indicate which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data / DATARAW, the FE can select which error it chooses to return. So if a DATARAW for a SET of a structure attempts to write one field which is read only, and attempts to set another field to an invalid value, the FE can return whatever error it likes. Yours, Joel M. Halpern