From owner-ietf-openproxy@mail.imc.org Wed Dec 3 02:03:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09925 for ; Wed, 3 Dec 2003 02:03:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARR2n-0003Ek-00 for opes-archive@ietf.org; Wed, 03 Dec 2003 02:03:29 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ARR2m-0003Eg-00 for opes-archive@ietf.org; Wed, 03 Dec 2003 02:03:28 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB36mxib092238 for ; Tue, 2 Dec 2003 22:48:59 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB36mx14092237 for ietf-openproxy-bks; Tue, 2 Dec 2003 22:48:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB36mvib092219 for ; Tue, 2 Dec 2003 22:48:57 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB36mvGh001507; Tue, 2 Dec 2003 23:48:57 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB36mvAh001506; Tue, 2 Dec 2003 23:48:57 -0700 (MST) (envelope-from rousskov) Date: Tue, 2 Dec 2003 23:48:57 -0700 (MST) From: Alex Rousskov To: internet-drafts@ietf.org cc: OPES WG Subject: Request To Publish: draft-ietf-opes-iab-04 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-213194317-1070434137=:60656" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-213194317-1070434137=:60656 Content-Type: TEXT/PLAIN; charset=US-ASCII Please publish the attached draft-ietf-opes-iab-04.txt as an OPES working group Internet Draft. Thank you, Alex. --0-213194317-1070434137=:60656 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-opes-iab-04.txt" Content-ID: Content-Description: draft-ietf-opes-iab-04.txt Content-Disposition: attachment; filename="draft-ietf-opes-iab-04.txt" Content-Transfer-Encoding: BASE64 DQoNCk9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEEuIEJhcmJpcg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Tm9ydGVsIE5ldHdvcmtzDQpFeHBpcmVzOiBKdW5lIDEsIDIwMDQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gUm91c3Nrb3YN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGUgTWVhc3VyZW1lbnQgRmFjdG9yeQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNl bWJlciAyLCAyMDAzDQoNCg0KICAgICAgICAgICAgICAgICAgT1BFUyBUcmVh dG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zDQogICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtaWV0Zi1vcGVzLWlhYi0wNA0KDQpTdGF0dXMgb2Yg dGhpcyBNZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQt RHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgYWxs IHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90 aGVyDQogICBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAg IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy YWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0IGh0dHA6Ly8NCiAgIHd3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBT aGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVy bmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bmUgMSwgMjAwNC4NCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDAzKS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0KQWJz dHJhY3QNCg0KICAgSUVURiBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQg KElBQikgZXhwcmVzc2VkIG5pbmUNCiAgIGFyY2hpdGVjdHVyZS1sZXZlbCBj b25zaWRlcmF0aW9ucyBmb3IgdGhlIE9wZW4gUGx1Z2dhYmxlIEVkZ2UNCiAg IFNlcnZpY2VzIChPUEVTKSBmcmFtZXdvcmsuICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBob3cgT1BFUw0KICAgYWRkcmVzc2VzIHRob3NlIGNvbnNpZGVy YXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tv diAgICAgICAgIEV4cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAgICAg ICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRt ZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAwMw0K DQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMw0KICAgMi4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAzLiAg Q29uc2lkZXJhdGlvbiAoMi4xKSAnT25lLXBhcnR5IGNvbnNlbnQnICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDQuICBDb25zaWRlcmF0aW9uICgy LjIpICdJUC1sYXllciBjb21tdW5pY2F0aW9ucycgIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgNS4gIE5vdGlmaWNhdGlvbiBDb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICA1LjEgTm90 aWZpY2F0aW9uIHZlcnN1cyB0cmFjZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgNCiAgIDUuMiBBbiBleGFtcGxlIG9mIGFuIE9Q RVMgdHJhY2UgZm9yIEhUVFAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OQ0KICAgNS4zIENvbnNpZGVyYXRpb24gKDMuMSkgJ05vdGlmaWNhdGlvbicg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICA1LjQgQ29uc2lk ZXJhdGlvbiAoMy4yKSAnTm90aWZpY2F0aW9uJyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTINCiAgIDYuICBDb25zaWRlcmF0aW9uICgzLjMpICdO b24tYmxvY2tpbmcnIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0K ICAgNy4gIENvbnNpZGVyYXRpb24gKDQuMSkgJ1VSSSByZXNvbHV0aW9uJyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICA4LiAgQ29uc2lkZXJh dGlvbiAoNC4yKSAnUmVmZXJlbmNlIHZhbGlkaXR5JyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTUNCiAgIDkuICBDb25zaWRlcmF0aW9uICg0LjMpICdBZGRy ZXNzaW5nIGV4dGVuc2lvbnMnICAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAg MTAuIENvbnNpZGVyYXRpb24gKDUuMSkgJ1ByaXZhY3knICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAxMS4gQ29uc2lkZXJhdGlv biAnRW5jcnlwdGlvbicgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCiAgIDEyLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgMTMu IENvbXBsaWFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICBBLiAgQ2hhbmdlIExvZyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjENCiAgICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0KICAgICAgIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDI0DQogICAgICAgQXV0aG9ycycgQWRkcmVzc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjQNCiAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdo dCBTdGF0ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAyNQ0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFy YmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAg ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERl Y2VtYmVyIDIwMDMNCg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIE9w ZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMgKE9QRVMpIGFyY2hpdGVjdHVy ZQ0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXSwgZW5hYmxlcyBj b29wZXJhdGl2ZSBhcHBsaWNhdGlvbg0KICAgc2VydmljZXMgKE9QRVMgc2Vy dmljZXMpIGJldHdlZW4gYSBkYXRhIHByb3ZpZGVyLCBhIGRhdGEgY29uc3Vt ZXIsDQogICBhbmQgemVybyBvciBtb3JlIE9QRVMgcHJvY2Vzc29ycy4gIFRo ZSBhcHBsaWNhdGlvbiBzZXJ2aWNlcyB1bmRlcg0KICAgY29uc2lkZXJhdGlv biBhbmFseXplIGFuZCBwb3NzaWJseSB0cmFuc2Zvcm0gYXBwbGljYXRpb24t bGV2ZWwNCiAgIG1lc3NhZ2VzIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBkYXRh IHByb3ZpZGVyIGFuZCB0aGUgZGF0YSBjb25zdW1lci4NCg0KICAgSW4gdGhl IHByb2Nlc3Mgb2YgY2hhcnRlcmluZyBPUEVTLCB0aGUgSUFCIG1hZGUgcmVj b21tZW5kYXRpb25zIG9uDQogICBpc3N1ZXMgdGhhdCBPUEVTIHNvbHV0aW9u cyBzaG91bGQgYmUgcmVxdWlyZWQgdG8gYWRkcmVzcy4gVGhlc2UNCiAgIHJl Y29tbWVuZGF0aW9ucyB3ZXJlIGZvcm11bGF0ZWQgaW4gdGhlIGZvcm0gb2Yg YSBzcGVjaWZpYyBJQUINCiAgIGNvbnNpZGVyYXRpb25zIGRvY3VtZW50IFtS RkMzMjM4XS4gIEluIHRoYXQgZG9jdW1lbnQsIElBQiBlbXBoYXNpemVkDQog ICB0aGF0IGl0cyBjb25zaWRlcmF0aW9ucyBkaWQgbm90IHJlY29tbWVuZCBz cGVjaWZpYyBzb2x1dGlvbnMgYW5kIGRpZA0KICAgbm90IG1hbmRhdGUgc3Bl Y2lmaWMgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMuIEFkZHJlc3NpbmcgYW4g SUFCDQogICBjb25zaWRlcmF0aW9uIG1heSBpbnZvbHZlIHNob3dpbmcgYXBw cm9wcmlhdGUgcHJvdG9jb2wgbWVjaGFuaXNtcyBvcg0KICAgZGVtb25zdHJh dGluZyB0aGF0IHRoZSBpc3N1ZSBkb2VzIG5vdCBhcHBseS4gQWRkcmVzc2lu ZyBhDQogICBjb25zaWRlcmF0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1l YW4gc3VwcG9ydGluZyB0ZWNobm9sb2d5IGltcGxpZWQNCiAgIGJ5IHRoZSBj b25zaWRlcmF0aW9uIHdvcmRpbmcuDQoNCiAgIFRoZSBwcmltYXJ5IGdvYWwg b2YgdGhpcyBkb2N1bWVudCBpcyB0byBzaG93IHRoYXQgYWxsIElBQg0KICAg cmVjb21tZW5kYXRpb25zIGFyZSBhZGRyZXNzZWQgYnkgT1BFUywgdG8gdGhl IGV4dGVudCB0aGF0IHRob3NlDQogICBjb25zaWRlcmF0aW9ucyBjYW4gYmUg YWRkcmVzc2VkIGJ5IGFuIElFVEYgd29ya2luZyBncm91cC4gVGhlDQogICBs aW1pdGF0aW9ucyBvZiBPUEVTIHdvcmtpbmcgZ3JvdXAgdG8gYWRkcmVzcyBj ZXJ0YWluIGFzcGVjdHMgb2YgSUFCDQogICBjb25zaWRlcmF0aW9ucyBhcmUg YWxzbyBleHBsaWNpdGx5IGRvY3VtZW50ZWQuDQoNCiAgIFRoZXJlIGFyZSBu aW5lIElBQiBjb25zaWRlcmF0aW9ucyBbUkZDMzIzOF0gdGhhdCBPUEVTIGhh cyB0byBhZGRyZXNzLg0KICAgSW4gdGhlIGNvcmUgb2YgdGhpcyBkb2N1bWVu dCBhcmUgdGhlIGNvcnJlc3BvbmRpbmcgbmluZQ0KICAgIkNvbnNpZGVyYXRp b24iIHNlY3Rpb25zLiBGb3IgZWFjaCBJQUIgY29uc2lkZXJhdGlvbiwgaXRz IHNlY3Rpb24NCiAgIGNvbnRhaW5zIGdlbmVyYWwgZGlzY3Vzc2lvbiBhcyB3 ZWxsIGFzIHJlZmVyZW5jZXMgdG8gc3BlY2lmaWMgT1BFUw0KICAgbWVjaGFu aXNtcyByZWxldmFudCB0byB0aGUgY29uc2lkZXJhdGlvbi4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vz c2tvdiAgICAgICAgIEV4cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAg ICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJl YXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAw Mw0KDQoNCjIuIFRlcm1pbm9sb2d5DQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9l cyBub3QgaW50cm9kdWNlIGFueSBuZXcgdGVybWlub2xvZ3kgYnV0IHVzZXMN CiAgIHRlcm1pbm9sb2d5IGZyb20gb3RoZXIgT1BFUyBkb2N1bWVudHMgaXQg cXVvdGVzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICAgRXhwaXJl cyBKdW5lIDEsIDIwMDQgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFCIENvbnNp ZGVyYXRpb25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0KMy4gQ29uc2lkZXJh dGlvbiAoMi4xKSAnT25lLXBhcnR5IGNvbnNlbnQnDQoNCiAgICJBbiBPUEVT IGZyYW1ld29yayBzdGFuZGFyZGl6ZWQgaW4gdGhlIElFVEYgbXVzdCByZXF1 aXJlIHRoYXQgdGhlIHVzZQ0KICAgb2YgYW55IE9QRVMgc2VydmljZSBiZSBl eHBsaWNpdGx5IGF1dGhvcml6ZWQgYnkgb25lIG9mIHRoZQ0KICAgYXBwbGlj YXRpb24tbGF5ZXIgZW5kLWhvc3RzICh0aGF0IGlzLCBlaXRoZXIgdGhlIGNv bnRlbnQgcHJvdmlkZXIgb3INCiAgIHRoZSBjbGllbnQpLiJbUkZDMzIzOF0N Cg0KICAgT1BFUyBhcmNoaXRlY3R1cmUgcmVxdWlyZXMgdGhhdCAiT1BFUyBw cm9jZXNzb3JzIE1VU1QgYmUgY29uc2VudGVkIHRvDQogICBieSBlaXRoZXIg dGhlIGRhdGEgY29uc3VtZXIgb3IgZGF0YSBwcm92aWRlciBhcHBsaWNhdGlv biINCiAgIFtJLUQuaWV0Zi1vcGVzLWFyY2hpdGVjdHVyZV0uIFRoaXMgcmVx dWlyZW1lbnQgYWxvbmUgY2Fubm90IHByZXZlbnQNCiAgIGNvbnNlbnQtbGVz cyBpbnRyb2R1Y3Rpb24gb2YgT1BFUyBwcm9jZXNzb3JzLiBJbg0KICAgW0kt RC5pZXRmLW9wZXMtZW5kLWNvbW1dLCB0aGUgT1BFUyBhcmNoaXRlY3R1cmUg ZW5hYmxlcyBjb25jZXJuZWQNCiAgIHBhcnRpZXMgdG8gZGV0ZWN0IHVud2Fu dGVkIE9QRVMgcHJvY2Vzc29ycyBieSBleGFtaW5pbmcgT1BFUyB0cmFjZXMu DQogICBUaGUgdXNlIG9mIHRyYWNlcyBpbiBPUEVTIGlzIG1hbmRhdG9yeS4N Cg0KICAgQSB0cmFjaW5nIG1lY2hhbmlzbSBvbiBpdHMgb3duIGNhbm5vdCBk ZXRlY3QgcHJvY2Vzc29ycyB0aGF0IGFyZSBpbg0KICAgdmlvbGF0aW9uIG9m IE9QRVMgc3BlY2lmaWNhdGlvbnMuICBFeGFtcGxlcyBpbmNsdWRlIE9QRVMg cHJvY2Vzc29ycw0KICAgb3BlcmF0aW5nIGluIHN0ZWFsdGggbW9kZS4gIEhv d2V2ZXIsIHRoZSBPUEVTIGFyY2hpdGVjdHVyZSBhbGxvd3MgdGhlDQogICB1 c2Ugb2YgY29udGVudCBzaWduYXR1cmUgdG8gdmVyaWZ5IHRoZSBhdXRoZW50 aWNpdHkgb2YgcGVyZm9ybWVkDQogICBhZGFwdGF0aW9ucy4gQ29udGVudCBz aWduYXR1cmVzIGlzIGEgc3Ryb25nIGJ1dCBleHBlbnNpdmUgbWVjaGFuaXNt DQogICB0aGF0IGNhbiBkZXRlY3QgYW55IG1vZGlmaWNhdGlvbnMgb2Ygc2ln bmVkIGNvbnRlbnQgcHJvdmlkZWQgdGhhdCB0aGUNCiAgIGNvbnRlbnQgcHJv dmlkZXIgaXMgd2lsbGluZyB0byBzaWduIHRoZSBkYXRhIGFuZCB0aGF0IHRo ZSBjbGllbnQgaXMNCiAgIHdpbGxpbmcgdG8gZWl0aGVyIGNoZWNrIHRoZSBz aWduYXR1cmUgb3IgcmVsYXkgcmVjZWl2ZWQgY29udGVudCB0bw0KICAgdGhl IGNvbnRlbnQgcHJvdmlkZXIgZm9yIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24u DQoNCiAgIE9QRVMgYWRhcHRhdGlvbnMgbWF5IGluY2x1ZGUgY29weWluZyBh bmQgb3RoZXIgZm9ybXMgb2Ygbm9uLW1vZGlmeWluZw0KICAgYWNjZXNzIHRv IGNvbnRlbnQuIFRoZXNlIGtpbmRzIG9mIGFkYXB0YXRpb25zIGNhbm5vdCBi ZSBkZXRlY3RlZCBieQ0KICAgdGhlIGFib3ZlIG1lbnRpb25lZCBtZWNoYW5p c21zLiBUaHVzLCAicGFzc2l2ZSIgT1BFUyBwcm9jZXNzb3JzIGNhbg0KICAg b3BlcmF0ZSBvbiB0aGUgY29udGVudCB3aXRob3V0IHRoZSBkYXRhIGNvbnN1 bWVyIG9yIHByb3ZpZGVyIGNvbnNlbnQuDQogICBJZiBwcmVzZW5jZSBvZiBz dWNoIHByb2Nlc3NvcnMgaXMgYSBjb25jZXJuLCB0aGVuIGNvbnRlbnQgZW5j cnlwdGlvbg0KICAgY2FuIGJlIHVzZWQuIEEgcGFzc2l2ZSBwcm9jZXNzb3Ig aXMgbm8gZGlmZmVyZW50IGZyb20gYSBwcm94eSBvciBhbg0KICAgaW50ZXJt ZWRpYXJ5IG9wZXJhdGluZyBvdXRzaWRlIG9mIE9QRVMgZnJhbWV3b3JrLiAg Tm8gT1BFUyBtZWNoYW5pc20NCiAgIChleGlzdGluZyBvciBmb3Jlc2VlYWJs ZSkgY2FuIHByZXZlbnQgbm9uLW1vZGlmeWluZyBhY2Nlc3MgdG8NCiAgIGNv bnRlbnQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFy YmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAg ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERl Y2VtYmVyIDIwMDMNCg0KDQo0LiBDb25zaWRlcmF0aW9uICgyLjIpICdJUC1s YXllciBjb21tdW5pY2F0aW9ucycNCg0KICAgIkZvciBhbiBPUEVTIGZyYW1l d29yayBzdGFuZGFyZGl6ZWQgaW4gdGhlIElFVEYsIHRoZSBPUEVTDQogICBp bnRlcm1lZGlhcnkgbXVzdCBiZSBleHBsaWNpdGx5IGFkZHJlc3NlZCBhdCB0 aGUgSVAgbGF5ZXIgYnkgdGhlIGVuZA0KICAgdXNlci4iW1JGQzMyMzhdDQoN CiAgIFRoZSBPUEVTIGFyY2hpdGVjdHVyZSByZXF1aXJlcyB0aGF0ICJPUEVT IHByb2Nlc3NvcnMgTVVTVCBiZQ0KICAgYWRkcmVzc2FibGUgYXQgdGhlIElQ IGxheWVyIGJ5IHRoZSBlbmQgdXNlciAoZGF0YSBjb25zdW1lcg0KICAgYXBw bGljYXRpb24pIiBbSS1ELmlldGYtb3Blcy1hcmNoaXRlY3R1cmVdLiBUaGUg SUFCIGFuZCB0aGUNCiAgIGFyY2hpdGVjdHVyZSBkb2N1bWVudHMgbWVudGlv biBhbiBpbXBvcnRhbnQgZXhjZXB0aW9uOiBhZGRyZXNzaW5nIHRoZQ0KICAg Zmlyc3QgT1BFUyBwcm9jZXNzb3IgaW4gYSBjaGFpbiBvZiBwcm9jZXNzb3Jz IGlzIHN1ZmZpY2llbnQuIFRoYXQgaXMsDQogICBhIGNoYWluIG9mIE9QRVMg cHJvY2Vzc29ycyBpcyB2aWV3ZWQgYXMgYSBzaW5nbGUgT1BFUyAic3lzdGVt IiBhdCB0aGUNCiAgIGFkZHJlc3Mgb2YgdGhlIGZpcnN0IGNoYWluIGVsZW1l bnQuDQoNCiAgIFRoZSBub3Rpb24gb2YgYSBjaGFpbiBpcyBub3Qgc3RyaWN0 bHkgZGVmaW5lZCBieSBJQUIuIEZvciB0aGUgcHVycG9zZQ0KICAgb2YgYWRk cmVzc2luZyB0aGlzIGNvbnNpZGVyYXRpb24sIGEgZ3JvdXAgb2YgT1BFUyBw cm9jZXNzb3JzIHdvcmtpbmcNCiAgIG9uIGEgZ2l2ZW4gYXBwbGljYXRpb24g dHJhbnNhY3Rpb24gaXMgY29uc2lkZXJlZC4gU3VjaCBhIGdyb3VwIHdvdWxk DQogICBuZWNlc3NhcmlseSBmb3JtIGEgc2luZ2xlIHByb2Nlc3NpbmcgY2hh aW4sIHdpdGggYSBzaW5nbGUgImV4aXQiIE9QRVMNCiAgIHByb2Nlc3NvciAo aS5lLiwgdGhlIHByb2Nlc3NvciB0aGF0IGFkYXB0ZWQgdGhlIGdpdmVuIG1l c3NhZ2UgbGFzdCkuDQogICBUaGUgT1BFUyBhcmNoaXRlY3R1cmUgZXNzZW50 aWFsbHkgcmVxdWlyZXMgdGhhdCBsYXN0IE9QRVMgcHJvY2Vzc29yDQogICB0 byBiZSBleHBsaWNpdGx5IGFkZHJlc3NhYmxlIGF0IHRoZSBJUCBsYXllciBi eSB0aGUgZGF0YSBjb25zdW1lcg0KICAgYXBwbGljYXRpb24uIFRoZSBjaGFp biBmb3JtYXRpb24sIGluY2x1ZGluZyBpdHMgZXhpdCBwb2ludCBtYXkgZGVw ZW5kDQogICBvbiBhbiBhcHBsaWNhdGlvbiBtZXNzYWdlIGFuZCBvdGhlciBk eW5hbWljIGZhY3RvcnMgc3VjaCBhcyB0aW1lIG9mDQogICB0aGUgZGF5IG9y IHN5c3RlbSBsb2FkLg0KDQogICBGdXJ0aGVybW9yZSwgaWYgT1BFUyBwcm9j ZXNzaW5nIGlzIGFuIGludGVybmFsIHByb2Nlc3Npbmcgc3RlcCBhdCBhDQog ICBkYXRhIGNvbnN1bWVyIG9yIGEgZGF0YSBwcm92aWRlciBhcHBsaWNhdGlv biBzaWRlLCB0aGVuIHRoZSBsYXN0IE9QRVMNCiAgIHByb2Nlc3NvciBtYXkg cmVzaWRlIGluIGEgcHJpdmF0ZSBhZGRyZXNzIHNwYWNlIGFuZCBtYXkgbm90 IGJlDQogICBleHBsaWNpdGx5IGFkZHJlc3NhYmxlIGZyb20gdGhlIG91dHNp ZGUuIEluIHN1Y2ggc2l0dWF0aW9ucywgdGhlDQogICBwcm9jZXNzaW5nIHNp ZGUgbXVzdCBkZXNpZ25hdGUgYW4gYWRkcmVzc2FibGUgcG9pbnQgb24gdGhl IHNhbWUNCiAgIHByb2Nlc3NpbmcgY2hhaW4uIFRoYXQgZGVzaWduYXRlZCBw b2ludCBtYXkgbm90IGJlLCBzdHJpY3RseQ0KICAgc3BlYWtpbmcsIGFuIE9Q RVMgcHJvY2Vzc29yLCBidXQgaXQgd2lsbCBzdWZmaWNlIGFzIHN1Y2ggYXMg ZmFyIGFzDQogICBJQUIgY29uc2lkZXJhdGlvbnMgYXJlIGNvbmNlcm5lZCAt LSB0aGUgZGF0YSBjb25zdW1lciBhcHBsaWNhdGlvbg0KICAgd2lsbCBiZSBh YmxlIHRvIGFkZHJlc3MgaXQgZXhwbGljaXRseSBhdCB0aGUgSVAgbGF5ZXIg YW5kIGl0IHdpbGwNCiAgIHJlcHJlc2VudCB0aGUgT1BFUyBwcm9jZXNzaW5n IGNoYWluIHRvIHRoZSBvdXRzaWRlIHdvcmxkLg0KDQogICBEZXNpZ25hdGlu ZyBhbiBhZGRyZXNzYWJsZSBwcm9jZXNzaW5nIHBvaW50IGF2b2lkcyB0aGUg Y29uZmxpY3QNCiAgIGJldHdlZW4gbmFycm93IGludGVycHJldGF0aW9uIG9m IHRoZSBJQUIgY29uc2lkZXJhdGlvbiBhbmQgcmVhbA0KICAgc3lzdGVtIGRl c2lnbnMuIEl0IGlzIGlycmF0aW9uYWwgdG8gZXhwZWN0IGEgY29udGVudCBw cm92aWRlciB0bw0KICAgcHJvdmlkZSBhY2Nlc3MgdG8gaW50ZXJuYWwgaG9z dHMgcGFydGljaXBhdGluZyBpbiBjb250ZW50IGdlbmVyYXRpb24sDQogICB3 aGV0aGVyIE9QRVMgcHJvY2Vzc29ycyBhcmUgaW52b2x2ZWQgb3Igbm90LiBN b3Jlb3ZlciwgcHJvdmlkaW5nIHN1Y2gNCiAgIGFjY2VzcyB3b3VsZCBzZXJ2 ZSBsaXR0bGUgcHJhY3RpY2FsIHB1cnBvc2UgYmVjYXVzZSBpbnRlcm5hbCBP UEVTDQogICBwcm9jZXNzb3JzIGFyZSBub3QgbGlrZWx5IHRvIGJlIGFibGUg dG8gYW5zd2VyIGFueSBkYXRhIGNvbnN1bWVyDQogICBxdWVyaWVzLCBiZWlu ZyBjb21wbGV0ZWx5IG91dCBvZiBjb250ZW50IGdlbmVyYXRpb24gY29udGV4 dC4gRm9yDQogICBleGFtcGxlLCBhbiBPUEVTIHByb2Nlc3NvciBhZGRpbmcg Y3VzdG9tZXItc3BlY2lmaWMgaW5mb3JtYXRpb24gdG8NCiAgIFhNTCBwYWdl cyBtYXkgbm90IHVuZGVyc3RhbmQgb3IgYmUgYXdhcmUgb2YgYW55IGZpbmFs IEhUTUwgY29udGVudA0KICAgdGhhdCB0aGUgZGF0YSBjb25zdW1lciBhcHBs aWNhdGlvbiByZWNlaXZlcyBhbmQgbWF5IG5vdCBiZSBhYmxlIHRvDQogICBt YXAgZW5kIHVzZXIgcmVxdWVzdCB0byBhbnkgaW50ZXJuYWwgdXNlciBpZGVu dGlmaWNhdGlvbi4gU2luY2UgT1BFUw0KDQoNCg0KQmFyYmlyICYgUm91c3Nr b3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAgICAgICAgICAgICAg ICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0 bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERlY2VtYmVyIDIwMDMN Cg0KDQogICByZXF1aXJlcyB0aGUgZW5kIG9mIHRoZSBtZXNzYWdlIHByb2Nl c3NpbmcgY2hhaW4gdG8gYmUgYWRkcmVzc2FibGUsDQogICB0aGUgY29uZmxp Y3QgZG9lcyBub3QgZXhpc3QuIE9QRVMgcGxhY2VzIG5vIHJlcXVpcmVtZW50 cyBvbiB0aGUNCiAgIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiBkYXRhIHBy b2R1Y2VyIHN5c3RlbXMgd2hpbGUgcmVxdWlyaW5nIHRoZQ0KICAgZW50aXJl IE9QRVMtcmVsYXRlZCBjb250ZW50IHByb2R1Y3Rpb24gInN5c3RlbSIgdG8g YmUgYWRkcmVzc2FibGUgYXQNCiAgIHRoZSBJUCBsYXllci4NCg0KICAgUHJp dmF0ZSBEb21haW4gICAgfCBQdWJsaWMgRG9tYWluICAgICB8IFByaXZhdGUg RG9tYWluDQogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLSsgIHwgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tKw0KICAgfCBEYXRhICAgICAg ICAgfCAgfCAgICAgICAgICAgICB8IE9QRVMgU3lzdGVtIHwgICAgICB8RGF0 YSAgICB8DQogICB8IENvbnN1bWVyICAgICB8PC0tLSBuZXR3b3JrIC0tPnwg d2l0aCBwdWJsaWMgfDwtLS0tPnxQcm92aWRlcnwNCiAgIHwgQXBwbGljYXRp b24gIHwgIHwgICAgICAgICAgICAgfCBJUCBhZGRyZXNzICB8ICAgICAgfEFw cCAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tKyAgfCAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0rDQogICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICAgRXhwaXJlcyBKdW5l IDEsIDIwMDQgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFCIENvbnNpZGVyYXRp b25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0KNS4gTm90aWZpY2F0aW9uIENv bnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgaG93 IE9QRVMgZnJhbWV3b3JrIGFkZHJlc3NlcyBJQUIgTm90aWZpY2F0aW9uDQog ICBjb25zaWRlcmF0aW9ucyAzLjEgYW5kIDMuMi4NCg0KNS4xIE5vdGlmaWNh dGlvbiB2ZXJzdXMgdHJhY2UNCg0KICAgQmVmb3JlIHNwZWNpZmljIGNvbnNp ZGVyYXRpb25zIGFyZSBkaXNjdXNzZWQsIHRoZSByZWxhdGlvbnNoaXANCiAg IGJldHdlZW4gSUFCIG5vdGlmaWNhdGlvbnMgYW5kIE9QRVMgdHJhY2luZyBo YXMgdG8gYmUgZXhwbGFpbmVkLiBPUEVTDQogICBmcmFtZXdvcmsgY29uY2Vu dHJhdGVzIG9uIHRyYWNpbmcgcmF0aGVyIHRoYW4gbm90aWZpY2F0aW9uLiBU aGUgT1BFUw0KICAgQ29tbXVuaWNhdGlvbnMgc3BlY2lmaWNhdGlvbiBbSS1E LmlldGYtb3Blcy1lbmQtY29tbV0gZGVmaW5lcyAiT1BFUw0KICAgdHJhY2Ui IGFzIGluZm9ybWF0aW9uIGFib3V0IE9QRVMgYWRhcHRhdGlvbnMgdGhhdCBp cyBlbWJlZGRlZCBpbiBhbg0KICAgYXBwbGljYXRpb24gbWVzc2FnZS4gVGh1 cywgT1BFUyB0cmFjZSBmb2xsb3dzIHRoZSBhcHBsaWNhdGlvbiBtZXNzYWdl DQogICBpdCB0cmFjZXMuIFRoZSB0cmFjZSBpcyBmb3IgdGhlIHJlY2lwaWVu dCBvZiB0aGUgYXBwbGljYXRpb24gbWVzc2FnZS4NCiAgIFRyYWNlcyBhcmUg aW1wbGVtZW50ZWQgYXMgZXh0ZW5zaW9ucyBvZiBhcHBsaWNhdGlvbiBwcm90 b2NvbHMgYmVpbmcNCiAgIGFkYXB0ZWQgYW5kIHRyYWNlZC4NCg0KICAgQXMg b3Bwb3NlZCB0byBhbiBPUEVTIHRyYWNlLCBwcm92aWRlciBub3RpZmljYXRp b24gKGFzIGltcGxpZWQgYnkNCiAgIElBQikgbm90aWZpZXMgdGhlIHNlbmRl ciBvZiB0aGUgYXBwbGljYXRpb24gbWVzc2FnZSByYXRoZXIgdGhhbiB0aGUN CiAgIHJlY2lwaWVudC4gVGh1cywgbm90aWZpY2F0aW9ucyBwcm9wYWdhdGUg aW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiBvZg0KICAgdHJhY2VzLiBTdXBw b3J0aW5nIG5vdGlmaWNhdGlvbnMgZGlyZWN0bHkgd291bGQgcmVxdWlyZSBh IG5ldw0KICAgcHJvdG9jb2wuIEZpZ3VyZSAyIGlsbHVzdHJhdGVzIHRoZSBk aWZmZXJlbmNlcyBiZXR3ZWVuIGEgdHJhY2UgYW5kDQogICBub3RpZmljYXRp b24gZnJvbSBhIHNpbmdsZSBhcHBsaWNhdGlvbiBtZXNzYWdlIHBvaW50IG9m IHZpZXcuDQogICBzZW5kZXIgLS1bbWVzc2FnZSBBXS0tPiBPUEVTIC0tW21l c3NhZ2UgQSddLS0+IHJlY2lwaWVudA0KICAgICAgXiAgICAgICAgICAgICAg ICAgICAgICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3dpdGgg dHJhY2VdDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICArLTwtLSBbbm90aWZpY2F0aW9uXSAtLS0rDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDINCg0KICAgU2luY2Ugbm90aWZp Y2F0aW9ucyBjYW5ub3QgYmUgcGlnZ3ktYmFja2VkIHRvIGFwcGxpY2F0aW9u IG1lc3NhZ2VzLA0KICAgdGhleSBjcmVhdGUgbmV3IG1lc3NhZ2VzIGFuZCBt YXkgZG91YmxlIHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgdGhlDQogICBzZW5k ZXIgaGFzIHRvIHByb2Nlc3MuIFRoZSBudW1iZXIgb2YgbWVzc2FnZXMgdGhh dCBuZWVkIHRvIGJlIHByb2NlZWQNCiAgIGlzIGxhcmdlciBpZiBzZXZlcmFs IGludGVybWVkaWFyaWVzIG9uIHRoZSBtZXNzYWdlIHBhdGggZ2VuZXJhdGUN CiAgIG5vdGlmaWNhdGlvbnMpLiBBc3NvY2lhdGluZyBub3RpZmljYXRpb25z IHdpdGggYXBwbGljYXRpb24gbWVzc2FnZXMNCiAgIG1heSByZXF1aXJlIGR1 cGxpY2F0aW5nIGFwcGxpY2F0aW9uIG1lc3NhZ2UgaW5mb3JtYXRpb24gaW4N CiAgIG5vdGlmaWNhdGlvbnMgYW5kIG1heSByZXF1aXJlIG1haW50YWluaW5n IGEgc2VuZGVyIHN0YXRlIHVudGlsDQogICBub3RpZmljYXRpb24gaXMgcmVj ZWl2ZWQuIFRoZXNlIGFjdGlvbnMgaW5jcmVhc2UgdGhlIHBlcmZvcm1hbmNl DQogICBvdmVyaGVhZCBvZiBub3RpZmljYXRpb25zLg0KDQogICBUaGUgbGV2 ZWwgb2YgYXZhaWxhYmxlIGRldGFpbHMgaW4gbm90aWZpY2F0aW9ucyB2ZXJz dXMgcHJvdmlkZXINCiAgIGludGVyZXN0IGluIHN1cHBvcnRpbmcgbm90aWZp Y2F0aW9uIGlzIGFub3RoZXIgY29uY2Vybi4gIEV4cGVyaWVuY2UNCiAgIHNo b3dzIHRoYXQgY29udGVudCBwcm92aWRlcnMgb2Z0ZW4gcmVxdWlyZSB2ZXJ5 IGRldGFpbGVkIGluZm9ybWF0aW9uDQogICBhYm91dCB1c2VyIGFjdGlvbnMg dG8gYmUgaW50ZXJlc3RlZCBpbiBub3RpZmljYXRpb25zIGF0IGFsbC4gRm9y DQogICBleGFtcGxlLCBIaXQgTWV0ZXJpbmcgcHJvdG9jb2wgW1JGQzIyMjdd IGhhcyBiZWVuIGRlc2lnbmVkIHRvIHN1cHBseQ0KICAgY29udGVudCBwcm92 aWRlcnMgd2l0aCBwcm94eSBjYWNoZSBoaXQgY291bnRzLCBpbiBhbiBlZmZv cnQgdG8gcmVkdWNlDQogICBjYWNoZSBidXN0aW5nIGJlaGF2aW9yIHdoaWNo IHdhcyBjYXVzZWQgYnkgY29udGVudCBwcm92aWRlcnMgZGVzaXJlDQogICB0 byBnZXQgYWNjdXJhdGUgc2l0ZSAiYWNjZXNzIGNvdW50cyIuIEhvd2V2ZXIs IHRoZSBIaXQgTWV0ZXJpbmcNCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAg ICAgICAgRXhwaXJlcyBKdW5lIDEsIDIwMDQgICAgICAgICAgICAgICAgICBb UGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQg b2YgSUFCIENvbnNpZGVyYXRpb25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0K ICAgcHJvdG9jb2wgaXMgY3VycmVudGx5IG5vdCB3aWRlbHkgZGVwbG95ZWQg YmVjYXVzZSB0aGUgcHJvdG9jb2wgZG9lcw0KICAgbm90IHN1cHBseSBjb250 ZW50IHByb3ZpZGVycyB3aXRoIGluZm9ybWF0aW9uIHN1Y2ggYXMgY2xpZW50 IElQDQogICBhZGRyZXNzZXMsIGJyb3dzZXIgdmVyc2lvbnMsIG9yIGNvb2tp ZXMuDQoNCiAgIEhpdCBNZXRlcmluZyBleHBlcmllbmNlIGlzIHJlbGV2YW50 IGJlY2F1c2UgSGl0IE1ldGVyaW5nIHByb3RvY29sIHdhcw0KICAgZGVzaWdu ZWQgdG8gZG8gZm9yIEhUVFAgY2FjaGluZyBpbnRlcm1lZGlhcmllcyB3aGF0 IE9QRVMNCiAgIG5vdGlmaWNhdGlvbnMgYXJlIG1lYW50IHRvIGRvIGZvciBP UEVTIGludGVybWVkaWFyaWVzLiBQZXJmb3JtYW5jZQ0KICAgcmVxdWlyZW1l bnRzIGNhbGwgZm9yIHN0YXRlIHJlZHVjdGlvbiB2aWEgYWdncmVnYXRpb24g b2YNCiAgIG5vdGlmaWNhdGlvbnMgd2hpbGUgcHJvdmlkZXIgcHJlZmVyZW5j ZXMgY2FsbCBmb3Igc3RhdGUgcHJlc2VydmF0aW9uDQogICBvciBkdXBsaWNh dGlvbi4gQWNoaWV2aW5nIHRoZSByaWdodCBiYWxhbmNlIHdoZW4gdHdvIHNp ZGVzIGJlbG9uZyB0bw0KICAgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMgYW5k IGhhdmUgZGlmZmVyZW50IG9wdGltaXphdGlvbiBwcmlvcml0aWVzDQogICBt YXkgYmUgaW1wb3NzaWJsZS4NCg0KICAgVGh1cywgaW5zdGVhZCBvZiBleHBs aWNpdGx5IHN1cHBvcnRpbmcgbm90aWZpY2F0aW9ucyBhdCB0aGUgcHJvdG9j b2wNCiAgIGxldmVsLCBPUEVTIGNvbmNlbnRyYXRlcyBvbiB0cmFjaW5nIGZh Y2lsaXRpZXMuIEluIGVzc2VuY2UsIE9QRVMNCiAgIHN1cHBvcnRzIG5vdGlm aWNhdGlvbnMgaW5kaXJlY3RseSwgdXNpbmcgdHJhY2luZyBmYWNpbGl0aWVz LiBJbiBvdGhlcg0KICAgd29yZHMsIHRoZSBJQUIgY2hvaWNlIG9mICJOb3Rp ZmljYXRpb24iIGxhYmVsIGlzIGludGVycHJldGVkIGFzDQogICAiTm90aWZp Y2F0aW9uIGFzc2lzdGFuY2UiIChpLmUuICBtYWtpbmcgbm90aWZpY2F0aW9u cyBtZWFuaW5nZnVsKSBhbmQNCiAgIGlzIG5vdCBpbnRlcnByZXRlZCBhcyBh ICJOb3RpZmljYXRpb24gcHJvdG9jb2wiLg0KDQogICBUaGUgYWJvdmUgY29u Y2VybnMgY2FsbCBmb3IgbWFraW5nIG5vdGlmaWNhdGlvbiBvcHRpb25hbC4g VGhlIE9QRVMNCiAgIGFyY2hpdGVjdHVyZSBhbGxvd3MgZm9yIGFuIGVmZmlj aWVudCBhbmQgbWVhbmluZ2Z1bCBub3RpZmljYXRpb24NCiAgIHByb3RvY29s IHRvIGJlIGltcGxlbWVudGVkIGluIGNlcnRhaW4gT1BFUyBlbnZpcm9ubWVu dHMuICBGb3INCiAgIGV4YW1wbGUsIGEgQ2FibGUgQ29tcGFueSBJbnRlcm5l dCBTZXJ2aWNlIFByb3ZpZGVyIChDYWJsZSBJU1ApIG1heQ0KICAgcHJvdmlk ZSBhIHVzZXItY29uZmlndXJhYmxlIHBvcm4gZmlsdGVyaW5nIHNlcnZpY2Ug dG8gaXRzIHN1YnNjcmliZXJzDQogICB3aGlsZSBoYXZpbmcgYW4gYWdyZWVt ZW50IHdpdGggdGhlIHBhcmVudCBDYWJsZSBDb21wYW55IHRvIHNlbmQNCiAg IG5vdGlmaWNhdGlvbnMgdG8gdGhlIGNvbnRlbnQgcHJvdmlkZXIgd2hlbiBj bGllbnRzIChjb250ZW50DQogICBjb25zdW1lcnMpIHVzZSB0aGUgc2FtZSBm aWx0ZXIgdG8gYmxvY2sgQ29tcGFueSdzIGFkdmVydGlzZW1lbnQNCiAgIGlt YWdlcy4gSWYgdGhlIENhYmxlIENvbXBhbnkgZGVlbXMgc3VjaCBzdWJzY3Jp YmVyIGFjdGlvbnMNCiAgIGluYXBwcm9wcmlhdGUsIHRoZSBjb21wYW55IG1h eSBjb250YWN0IGluZGl2aWR1YWwgc3Vic2NyaWJlcnMgYW5kDQogICBlbmZv cmNlIHRoZWlyIElTUCB1c2FnZSBwb2xpY3kgYWNjb3JkaW5nIHRvIHRoZSB0 ZXJtcyBvZiB0aGUgc2VydmljZQ0KICAgYWdyZWVtZW50LiBJbiB0aGlzIGV4 YW1wbGUsIElTUCBjb29wZXJhdGlvbiBpcyBleHBlY3RlZCwgdGhlIHZvbHVt ZQ0KICAgb2Ygbm90aWZpY2F0aW9ucyB3b3VsZCBiZSByZWxhdGl2ZWx5IGxv dywgYW5kIG5vdGlmaWNhdGlvbnMgY2FuIGJlDQogICBoYW5kbGVkIGluIGFu IGF1dG9tYXRlZCBtYW5uZXIuDQoNCjUuMiBBbiBleGFtcGxlIG9mIGFuIE9Q RVMgdHJhY2UgZm9yIEhUVFANCg0KICAgVGhlIGV4YW1wbGUgYmVsb3cgaWxs dXN0cmF0ZXMgYWRhcHRhdGlvbnMgZG9uZSB0byBIVFRQIHJlcXVlc3QgYXQg YW4NCiAgIE9QRVMgcHJvY2Vzc29yIG9wZXJhdGVkIGJ5IHRoZSBjbGllbnQg SVNQLiBCb3RoIG9yaWdpbmFsIChhcyBzZW50IGJ5DQogICBhbiBlbmQgdXNl cikgYW5kIGFkYXB0ZWQgKGFzIHJlY2VpdmVkIGJ5IHRoZSBvcmlnaW4gd2Vi IHNlcnZlcikNCiAgIHJlcXVlc3RzIGFyZSBzaG93bi4gVGhlIHByaW1hcnkg YWRhcHRhdGlvbiBpcyB0aGUgbW9kaWZpY2F0aW9uIG9mDQogICBIVFRQICJB Y2NlcHQiIGhlYWRlci4gVGhlIHNlY29uZGFyeSBhZGFwdGF0aW9uIGlzIHRo ZSBhZGRpdGlvbiBvZiBhbg0KICAgT1BFUy1TeXN0ZW0gSFRUUCBleHRlbnNp b24gaGVhZGVyIFtJLUQuaWV0Zi1vcGVzLWh0dHBdLg0KDQogICBHRVQgL3B1 Yi9XV1cvIEhUVFAvMS4xDQogICBIb3N0OiB3d3cudzMub3JnDQogICBBY2Nl cHQ6IHRleHQvcGxhaW4NCg0KDQoNCg0KQmFyYmlyICYgUm91c3Nrb3YgICAg ICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAgICAgICAgICAgICAgICAgIFtQ YWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0bWVudCBv ZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERlY2VtYmVyIDIwMDMNCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzDQoNCiAg IC4uLiBtYXkgYmUgYWRhcHRlZCBieSBhbiBJU1AgT1BFUyBzeXN0ZW0gdG8g YmVjb21lOg0KDQogICBHRVQgL3B1Yi9XV1cvIEhUVFAvMS4xDQogICBIb3N0 OiB3d3cudzMub3JnDQogICBBY2NlcHQ6IHRleHQvcGxhaW47IHE9MC41LCB0 ZXh0L2h0bWwsIHRleHQveC1kdmk7IHE9MC44DQogICBPUEVTLVN5c3RlbTog aHR0cDovL3d3dy5pc3AtZXhhbXBsZS5jb20vb3Blcy8/Y2xpZW50LWhhc2g9 MTIzNDU2Nw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSA0DQoNCiAgIFRoZSBleGFtcGxlIGJlbG93IGlsbHVzdHJhdGVzIGFk YXB0YXRpb25zIGRvbmUgdG8gSFRUUCByZXNwb25zZSBhdCBhbg0KICAgT1BF UyBpbnRlcm1lZGlhcnkgb3BlcmF0ZWQgYnkgYSBDb250ZW50IERpc3RyaWJ1 dGlvbiBOZXR3b3JrIChDRE4pLg0KICAgQm90aCBvcmlnaW5hbCAoYXMgc2Vu dCBieSB0aGUgb3JpZ2luIHdlYiBzZXJ2ZXIpIGFuZCBhZGFwdGVkIChhcw0K ICAgcmVjZWl2ZWQgYnkgdGhlIGVuZCB1c2VyKSByZXNwb25zZXMgYXJlIHNo b3duLiBUaGUgcHJpbWFyeSBhZGFwdGF0aW9uDQogICBpcyB0aGUgY29udmVy c2lvbiBmcm9tIEhUTUwgbWFya3VwIHRvIHBsYWluIHRleHQuIFRoZSBzZWNv bmRhcnkNCiAgIGFkYXB0YXRpb24gaXMgdGhlIGFkZGl0aW9uIG9mIGFuIE9Q RVMtU3lzdGVtIEhUVFAgZXh0ZW5zaW9uIGhlYWRlci4NCg0KICAgSFRUUC8x LjEgMjAwIE9LDQogICBDb250ZW50LUxlbmd0aDogMTIzNDUNCiAgIENvbnRl bnQtRW5jb2Rpbmc6IHRleHQvaHRtbA0KDQogICA8aHRtbD48aGVhZD48aDE+ QXZhaWxhYmxlIERvY3VtZW50YS4uLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSA1DQoNCiAgIC4uLiBtYXkgYmUgYWRhcHRl ZCBieSBhIENETiBPUEVTIHN5c3RlbSB0byBiZWNvbWU6DQoNCiAgIEhUVFAv MS4xIDIwMCBPSw0KICAgQ29udGVudC1MZW5ndGg6IDIzNDUNCiAgIENvbnRl bnQtRW5jb2Rpbmc6IHRleHQvcGxhaW4NCiAgIE9QRVMtU3lzdGVtOiBodHRw Oi8vd3d3LmNkbi1leGFtcGxlLmNvbS9vcGVzLz9zaXRlPTc2NTQmc3ZjPWgy dA0KDQogICBBVkFJTEFCTEUgRE9DVU1FTlRBLi4uDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDYNCg0KICAgSW4gdGhlIGFi b3ZlIGV4YW1wbGVzLCBPUEVTLVN5c3RlbSBoZWFkZXIgdmFsdWVzIGNvbnRh aW4gVVJJcyB0aGF0DQogICBtYXkgcG9pbnQgdG8gT1BFUy1zcGVjaWZpYyBk b2N1bWVudHMgc3VjaCBhcyBkZXNjcmlwdGlvbiBvZiB0aGUgT1BFUw0KICAg b3BlcmF0b3IgYW5kIGl0cyBwcml2YWN5IHBvbGljeS4gIFRob3NlIGRvY3Vt ZW50cyBtYXkgYmUNCiAgIHBhcmFtZXRlcml6ZWQgdG8gYWxsb3cgZm9yIGN1 c3RvbWl6YXRpb25zIHNwZWNpZmljIHRvIHRoZSB0cmFuc2FjdGlvbg0KICAg YmVpbmcgdHJhY2VkIChlLmcuLCBjbGllbnQgb3IgZXZlbiB0cmFuc2FjdGlv biBpZGVudGlmaWVyIG1heSBiZSB1c2VkDQogICB0byBwcm92aWRlIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgcGVyZm9ybWVkIGFkYXB0YXRpb25zKS4gQW4g T1BFUy1WaWENCiAgIGhlYWRlciBtYXkgYmUgdXNlZCB0byBwcm92aWRlIGEg bW9yZSBkZXRhaWxlZCB0cmFjZSBvZiBzcGVjaWZpYyBPUEVTDQogICBlbnRp dGllcyB3aXRoaW4gYW4gT1BFUyBTeXN0ZW0gdGhhdCBhZGFwdGVkIHRoZSBt ZXNzYWdlLiBUcmFjZWQgT1BFUw0KICAgVVJJcyBtYXkgYmUgbGF0ZXIgdXNl ZCB0byByZXF1ZXN0IE9QRVMgYnlwYXNzDQogICBbSS1ELmlldGYtb3Blcy1l bmQtY29tbV0uDQoNCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICAg RXhwaXJlcyBKdW5lIDEsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDEw XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFC IENvbnNpZGVyYXRpb25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0KNS4zIENv bnNpZGVyYXRpb24gKDMuMSkgJ05vdGlmaWNhdGlvbicNCg0KICAgIlRoZSBv dmVyYWxsIE9QRVMgZnJhbWV3b3JrIG5lZWRzIHRvIGFzc2lzdCBjb250ZW50 IHByb3ZpZGVycyBpbg0KICAgZGV0ZWN0aW5nIGFuZCByZXNwb25kaW5nIHRv IGNsaWVudC1jZW50cmljIGFjdGlvbnMgYnkgT1BFUw0KICAgaW50ZXJtZWRp YXJpZXMgdGhhdCBhcmUgZGVlbWVkIGluYXBwcm9wcmlhdGUgYnkgdGhlIGNv bnRlbnQNCiAgIHByb3ZpZGVyLiJbUkZDMzIzOF0NCg0KICAgT1BFUyB0cmFj aW5nIG1lY2hhbmlzbXMgYXNzaXN0IGNvbnRlbnQgcHJvdmlkZXJzIGluIGRl dGVjdGluZw0KICAgY2xpZW50LWNlbnRyaWMgYWN0aW9ucyBieSBPUEVTIGlu dGVybWVkaWFyaWVzLiBTcGVjaWZpY2FsbHksIGENCiAgIGNvbXBsaWFudCBP UEVTIGludGVybWVkaWFyeSBvciBzeXN0ZW0gbm90aWZpZXMgYSBjb250ZW50 IHByb3ZpZGVyIG9mDQogICBpdHMgcHJlc2VuY2UgYnkgaW5jbHVkaW5nIGl0 cyB0cmFjaW5nIGluZm9ybWF0aW9uIGluIHRoZSBhcHBsaWNhdGlvbg0KICAg cHJvdG9jb2wgcmVxdWVzdHMuIEFuIE9QRVMgc3lzdGVtIE1VU1QgbGVhdmUg aXRzIHRyYWNlDQogICBbSS1ELmlldGYtb3Blcy1lbmQtY29tbV0uICBEZXRl Y3Rpb24gYXNzaXN0YW5jZSBoYXMgaXRzIGxpbWl0YXRpb25zLg0KICAgU29t ZSBPUEVTIGludGVybWVkaWFyaWVzIG1heSB3b3JrIGV4Y2x1c2l2ZWx5IG9u IHJlc3BvbnNlcyBhbmQgbWF5DQogICBub3QgaGF2ZSBhIGNoYW5jZSB0byB0 cmFjZSB0aGUgcmVxdWVzdC4gTW9yZW92ZXIsIHNvbWUgYXBwbGljYXRpb24N CiAgIHByb3RvY29scyBtYXkgbm90IGhhdmUgZXhwbGljaXQgcmVxdWVzdHMg KGUuZy4sIGEgY29udGVudCBwdXNoDQogICBzZXJ2aWNlKS4NCg0KICAgT1BF UyB0cmFjaW5nIG1lY2hhbmlzbXMgYXNzaXN0IGNvbnRlbnQgcHJvdmlkZXJz IGluIHJlc3BvbmRpbmcgdG8NCiAgIGNsaWVudC1jZW50cmljIGFjdGlvbnMg YnkgT1BFUyBpbnRlcm1lZGlhcmllcy4gU3BlY2lmaWNhbGx5LCBPUEVTDQog ICB0cmFjZXMgTVVTVCBpbmNsdWRlIGlkZW50aWZpY2F0aW9uIG9mIE9QRVMg c3lzdGVtcyBhbmQgU0hPVUxEIGluY2x1ZGUNCiAgIGEgbGlzdCBvZiBhZGFw dGF0aW9uIGFjdGlvbnMgcGVyZm9ybWVkIG9uIHByb3ZpZGVyJ3MgY29udGVu dC4gVGhpcw0KICAgdHJhY2luZyBpbmZvcm1hdGlvbiBtYXkgYmUgaW5jbHVk ZWQgaW4gdGhlIGFwcGxpY2F0aW9uIHJlcXVlc3QuDQogICBVc3VhbGx5LCBo b3dldmVyLCB0aGlzIGluZm9ybWF0aW9uIHdpbGwgYmUgaW5jbHVkZWQgaW4g dGhlDQogICBhcHBsaWNhdGlvbiByZXNwb25zZSwgYW4gYWRhcHRlZCB2ZXJz aW9uIG9mIHdoaWNoIGRvZXMgbm90IHJlYWNoIHRoZQ0KICAgY29udGVudCBw cm92aWRlci4gSWYgT1BFUyBlbmQgcG9pbnRzIGNvb3BlcmF0ZSwgdGhlbiBu b3RpZmljYXRpb24gY2FuDQogICBiZSBhc3Npc3RlZCB3aXRoIHRyYWNlcy4g Q29udGVudCBwcm92aWRlcnMgdGhhdCBzdXNwZWN0IG9yIGV4cGVyaWVuY2UN CiAgIGRpZmZpY3VsdGllcyBjYW4gZG8gYW55IG9mIHRoZSBmb2xsb3dpbmc6 DQoNCiAgIG8gIENoZWNrIHdoZXRoZXIgcmVxdWVzdHMgdGhleSByZWNlaXZl IHBhc3MgdGhyb3VnaCBPUEVTDQogICAgICBpbnRlcm1lZGlhcmllcy4gUHJl c2VuY2Ugb2YgT1BFUyB0cmFjaW5nIGluZm8gd2lsbCBkZXRlcm1pbmUgdGhh dC4NCiAgICAgIFRoaXMgY2hlY2sgaXMgb25seSBwb3NzaWJsZSBmb3IgcmVx dWVzdC9yZXNwb25zZSBwcm90b2NvbHMuIEZvcg0KICAgICAgb3RoZXIgcHJv dG9jb2xzIChlLmcuLCBicm9hZGNhc3Qgb3IgcHVzaCksIHRoZSBwcm92aWRl ciB3b3VsZCBoYXZlDQogICAgICB0byBhc3N1bWUgdGhhdCBPUEVTIGludGVy bWVkaWFyaWVzIGFyZSBpbnZvbHZlZCB1bnRpbCBwcm92ZW4NCiAgICAgIG90 aGVyd2lzZS4NCg0KICAgbyAgSWYgT1BFUyBpbnRlcm1lZGlhcmllcyBhcmUg c3VzcGVjdGVkLCByZXF1ZXN0IE9QRVMgdHJhY2VzIGZyb20NCiAgICAgIHBv dGVudGlhbGx5IGFmZmVjdGVkIHVzZXIocykuIFRoZSB0cmFjZSB3aWxsIGJl IGEgcGFydCBvZiB0aGUNCiAgICAgIGFwcGxpY2F0aW9uIG1lc3NhZ2UgcmVj ZWl2ZWQgYnkgdGhlIHVzZXIgc29mdHdhcmUuIElmIGludm9sdmVkDQogICAg ICBwYXJ0aWVzIGNvb3BlcmF0ZSwgdGhlIHByb3ZpZGVyKHMpIG1heSBoYXZl IGFjY2VzcyB0byBhbGwgdGhlDQogICAgICBuZWVkZWQgaW5mb3JtYXRpb24u ICBDZXJ0YWlubHksIGxhY2sgb2YgY29vcGVyYXRpb24gbWF5IGhpbmRlcg0K ICAgICAgYWNjZXNzIHRvIHRyYWNpbmcgaW5mb3JtYXRpb24uIFRvIGVuY291 cmFnZSBjb29wZXJhdGlvbiwgZGF0YQ0KICAgICAgcHJvdmlkZXJzIG1pZ2h0 IGJlIGFibGUgdG8gZGVueSBzZXJ2aWNlIHRvIHVuY29vcGVyYXRpdmUgdXNl cnMuDQoNCiAgIG8gIFNvbWUgdHJhY2VzIG1heSBpbmRpY2F0ZSB0aGF0IG1v cmUgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGJ5DQogICAgICBhY2Nlc3Np bmcgY2VydGFpbiByZXNvdXJjZXMgb24gdGhlIHNwZWNpZmllZCBPUEVTIGlu dGVybWVkaWFyeSBvcg0KICAgICAgZWxzZXdoZXJlLiBDb250ZW50IHByb3Zp ZGVycyBtYXkgcXVlcnkgZm9yIG1vcmUgaW5mb3JtYXRpb24gaW4NCiAgICAg IHRoaXMgY2FzZS4NCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICAg RXhwaXJlcyBKdW5lIDEsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFC IENvbnNpZGVyYXRpb25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0KICAgbyAg SWYgZXZlcnl0aGluZyBlbHNlIGZhaWxzLCBwcm92aWRlcnMgY2FuIGVuZm9y Y2Ugbm8tYWRhcHRhdGlvbg0KICAgICAgcG9saWN5IHVzaW5nIGFwcHJvcHJp YXRlIE9QRVMgYnlwYXNzIG1lY2hhbmlzbXMgYW5kL29yIGVuZC10by1lbmQN CiAgICAgIGVuY3J5cHRpb24gbWVjaGFuaXNtcy4NCg0KICAgT1BFUyBkZXRl Y3Rpb24gYW5kIHJlc3BvbnNlIGFzc2lzdGFuY2UgaXMgbGltaXRlZCB0byBh cHBsaWNhdGlvbg0KICAgcHJvdG9jb2xzIHdpdGggc3VwcG9ydCBmb3IgdHJh Y2luZyBleHRlbnNpb25zLiBGb3IgZXhhbXBsZSwgSFRUUA0KICAgW1JGQzI2 MTZdIGhhcyBzdWNoIHN1cHBvcnQgd2hpbGUgRE5TIG92ZXIgVURQIGRvZXMg bm90Lg0KDQo1LjQgQ29uc2lkZXJhdGlvbiAoMy4yKSAnTm90aWZpY2F0aW9u Jw0KDQogICAiVGhlIG92ZXJhbGwgT1BFUyBmcmFtZXdvcmsgc2hvdWxkIGFz c2lzdCBlbmQgdXNlcnMgaW4gZGV0ZWN0aW5nIHRoZQ0KICAgYmVoYXZpb3Ig b2YgT1BFUyBpbnRlcm1lZGlhcmllcywgcG90ZW50aWFsbHkgYWxsb3dpbmcg dGhlbSB0bw0KICAgaWRlbnRpZnkgaW1wZXJmZWN0IG9yIGNvbXByb21pc2Vk IGludGVybWVkaWFyaWVzLiJbUkZDMzIzOF0NCg0KICAgT1BFUyB0cmFjaW5n IG1lY2hhbmlzbXMgYXNzaXN0IGVuZCB1c2VycyBpbiBkZXRlY3RpbmcgT1BF Uw0KICAgaW50ZXJtZWRpYXJpZXMuIFNwZWNpZmljYWxseSwgYSBjb21wbGlh bnQgT1BFUyBpbnRlcm1lZGlhcnkgb3Igc3lzdGVtDQogICBub3RpZmllcyBh biBlbmQgdXNlciBvZiBpdHMgcHJlc2VuY2UgYnkgaW5jbHVkaW5nIGl0cyB0 cmFjaW5nDQogICBpbmZvcm1hdGlvbiBpbiB0aGUgYXBwbGljYXRpb24gcHJv dG9jb2wgbWVzc2FnZXMgc2VudCB0byB0aGUgY2xpZW50Lg0KICAgQW4gT1BF UyBzeXN0ZW0gTVVTVCBsZWF2ZSBpdHMgdHJhY2UgW0ktRC5pZXRmLW9wZXMt ZW5kLWNvbW1dLg0KICAgSG93ZXZlciwgZGV0ZWN0aW9uIGFzc2lzdGFuY2Ug aGFzIGl0cyBsaW1pdGF0aW9ucy4gU29tZSBPUEVTIHN5c3RlbXMNCiAgIG1h eSB3b3JrIGV4Y2x1c2l2ZWx5IG9uIHJlcXVlc3RzIGFuZCBtYXkgbm90IGhh dmUgYSBjaGFuY2UgdG8gdHJhY2UNCiAgIHRoZSByZXNwb25zZS4gIE1vcmVv dmVyLCBzb21lIGFwcGxpY2F0aW9uIHByb3RvY29scyBtYXkgbm90IGhhdmUN CiAgIGV4cGxpY2l0IHJlc3BvbnNlcyAoZS5nLiwgZXZlbnQgbG9nZ2luZyBz ZXJ2aWNlKS4NCg0KICAgT1BFUyBkZXRlY3Rpb24gYXNzaXN0YW5jZSBpcyBs aW1pdGVkIHRvIGFwcGxpY2F0aW9uIHByb3RvY29scyB3aXRoDQogICBzdXBw b3J0IGZvciB0cmFjaW5nIGV4dGVuc2lvbnMuIEZvciBleGFtcGxlLCBIVFRQ IFtSRkMyNjE2XSBoYXMgc3VjaA0KICAgc3VwcG9ydCB3aGlsZSBETlMgb3Zl ciBVRFAgZG9lcyBub3QuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAg IEV4cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSAx Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElB QiBDb25zaWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAwMw0KDQoNCjYuIENv bnNpZGVyYXRpb24gKDMuMykgJ05vbi1ibG9ja2luZycNCg0KICAgIklmIHRo ZXJlIGV4aXN0cyBhICJub24tT1BFUyIgdmVyc2lvbiBvZiBjb250ZW50IGF2 YWlsYWJsZSBmcm9tIHRoZQ0KICAgY29udGVudCBwcm92aWRlciwgdGhlIE9Q RVMgYXJjaGl0ZWN0dXJlIG11c3Qgbm90IHByZXZlbnQgdXNlcnMgZnJvbQ0K ICAgcmV0cmlldmluZyB0aGlzICJub24tT1BFUyIgdmVyc2lvbiBmcm9tIHRo ZSBjb250ZW50DQogICBwcm92aWRlci4iW1JGQzMyMzhdDQoNCiAgICJPUEVT IGVudGl0aWVzIE1VU1Qgc3VwcG9ydCBhIGJ5cGFzcyBmZWF0dXJlIg0KICAg W0ktRC5pZXRmLW9wZXMtZW5kLWNvbW1dLiBJZiBhbiBhcHBsaWNhdGlvbiBt ZXNzYWdlIGluY2x1ZGVzIGJ5cGFzcw0KICAgaW5zdHJ1Y3Rpb25zIGFuZCBh biBPUEVTIGludGVybWVkaWFyeSBpcyBub3QgY29uZmlndXJlZCB0byBpZ25v cmUNCiAgIHRoZW0sIHRoZSBtYXRjaGluZyBPUEVTIGludGVybWVkaWFyeSB3 aWxsIG5vdCBwcm9jZXNzIHRoZSBtZXNzYWdlLiBBbg0KICAgT1BFUyBpbnRl cm1lZGlhcnkgbWF5IGJlIGNvbmZpZ3VyZWQgdG8gaWdub3JlIGJ5cGFzcyBp bnN0cnVjdGlvbnMNCiAgIG9ubHkgaWYgbm8gbm9uLU9QRVMgdmVyc2lvbiBv ZiBjb250ZW50IGlzIGF2YWlsYWJsZS4gIEJ5cGFzcyBtYXkNCiAgIGdlbmVy YXRlIGNvbnRlbnQgZXJyb3JzIHNpbmNlIHNvbWUgT1BFUyBzZXJ2aWNlcyBt YXkgYmUgZXNzZW50aWFsIGJ1dA0KICAgbWF5IG5vdCBiZSBjb25maWd1cmVk IGFzIHN1Y2guDQoNCiAgIEJ5cGFzcyBzdXBwb3J0IGhhcyBsaW1pdGF0aW9u cyBzaW1pbGFyIHRvIHRoZSB0d28NCiAgIG5vdGlmaWNhdGlvbi1yZWxhdGVk IGNvbnNpZGVyYXRpb25zIGFib3ZlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K QmFyYmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAg IERlY2VtYmVyIDIwMDMNCg0KDQo3LiBDb25zaWRlcmF0aW9uICg0LjEpICdV UkkgcmVzb2x1dGlvbicNCg0KICAgIk9QRVMgZG9jdW1lbnRhdGlvbiBtdXN0 IGJlIGNsZWFyIGluIGRlc2NyaWJpbmcgdGhlc2Ugc2VydmljZXMgYXMNCiAg IGJlaW5nIGFwcGxpZWQgdG8gdGhlIHJlc3VsdCBvZiBVUkkgcmVzb2x1dGlv biwgbm90IGFzIFVSSSByZXNvbHV0aW9uDQogICBpdHNlbGYuIltSRkMzMjM4 XQ0KDQogICAiT1BFUyBTY2VuYXJpb3MgYW5kIFVzZSBDYXNlcyIgc3BlY2lm aWNhdGlvbg0KICAgW0ktRC5pZXRmLW9wZXMtc2NlbmFyaW9zXSBkb2N1bWVu dHMgY29udGVudCBhZGFwdGF0aW9ucyB0aGF0IGFyZSBpbg0KICAgc2NvcGUg b2YgdGhlIE9QRVMgZnJhbWV3b3JrLiBTY2VuYXJpb3MgaW5jbHVkZSBhZGFw dGF0aW9ucyBvZg0KICAgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4gVGhlc2Ug YWRhcHRhdGlvbnMgZG8gbm90IGluY2x1ZGUgVVJJDQogICByZXNvbHV0aW9u IGFkYXB0YXRpb25zLiBJbiBzb21lIGVudmlyb25tZW50cywgaXQgaXMgdGVj aG5pY2FsbHkNCiAgIHBvc3NpYmxlIHRvIGFkYXB0IFVSSXMgKGFuZCBvdGhl ciBraW5kcyBvZiBpZGVudGlmaWVycyBvciBhZGRyZXNzZXMpDQogICB1c2lu ZyBkb2N1bWVudGVkIE9QRVMgbWVjaGFuaXNtcy4gVGhlIE9QRVMgZnJhbWV3 b3JrIGNhbm5vdA0KICAgZWZmZWN0aXZlbHkgcHJvaGliaXQgYW55IHNwZWNp ZmljIGFkYXB0YXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgIEV4cGlyZXMgSnVuZSAxLCAy MDA0ICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0LURy YWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAg ICAgRGVjZW1iZXIgMjAwMw0KDQoNCjguIENvbnNpZGVyYXRpb24gKDQuMikg J1JlZmVyZW5jZSB2YWxpZGl0eScNCg0KICAgIkFsbCBwcm9wb3NlZCBzZXJ2 aWNlcyBtdXN0IGRlZmluZSB0aGVpciBpbXBhY3Qgb24gaW50ZXItIGFuZA0K ICAgaW50cmEtZG9jdW1lbnQgcmVmZXJlbmNlIHZhbGlkaXR5LiJbUkZDMzIz OF0NCg0KICAgVGhlIE9QRVMgZnJhbWV3b3JrIGRvZXMgbm90IHByb3Bvc2Ug YWRhcHRhdGlvbiBzZXJ2aWNlcy4gSG93ZXZlciwNCiAgIE9QRVMgdHJhY2lu ZyByZXF1aXJlbWVudHMgaW5jbHVkZSBpZGVudGlmaWNhdGlvbiBvZiBPUEVT DQogICBpbnRlcm1lZGlhcmllcyBhbmQgc2VydmljZXMgKGZvciBkZXRhaWxz LCBzZWUgIk5vdGlmaWNhdGlvbiINCiAgIGNvbnNpZGVyYXRpb24gc2VjdGlv bnMgaW4gdGhpcyBkb2N1bWVudCkuIEl0IGlzIHJlcXVpcmVkIHRoYXQNCiAg IHByb3ZpZGVkIGlkZW50aWZpY2F0aW9uIGNhbiBiZSB1c2VkIHRvIGxvY2F0 ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgIE9QRVMgaW50ZXJtZWRpYXJp ZXMsIGluY2x1ZGluZyB0aGUgZGVzY3JpcHRpb24gb2YgaW1wYWN0IG9uIHJl ZmVyZW5jZQ0KICAgdmFsaWRpdHkgW0ktRC5pZXRmLW9wZXMtZW5kLWNvbW1d Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFyYmlyICYg Um91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAgICAgICAg ICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVT IFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERlY2VtYmVy IDIwMDMNCg0KDQo5LiBDb25zaWRlcmF0aW9uICg0LjMpICdBZGRyZXNzaW5n IGV4dGVuc2lvbnMnDQoNCiAgICJBbnkgc2VydmljZXMgdGhhdCBjYW5ub3Qg YmUgYWNoaWV2ZWQgd2hpbGUgcmVzcGVjdGluZyB0aGUgYWJvdmUgdHdvDQog ICBjb25zaWRlcmF0aW9ucyBtYXkgYmUgcmV2aWV3ZWQgYXMgcG90ZW50aWFs IHJlcXVpcmVtZW50cyBmb3IgSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9uIGFk ZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGV4dGVuc2lvbnMsIGJ1dCBtdXN0IG5v dCBiZQ0KICAgdW5kZXJ0YWtlbiBhcyBhZCBob2MgZml4ZXMuIltSRkMzMjM4 XQ0KDQogICBPUEVTIGZyYW1ld29yayBkb2VzIG5vdCBjb250YWluIGFkIGhv YyBmaXhlcy4gVGhpcyBkb2N1bWVudCBpbg0KICAgY29tYmluYXRpb24gd2l0 aCBhbmQgb3RoZXIgT1BFUyBkb2N1bWVudHMgc2hvdWxkIGJlIHN1ZmZpY2ll bnQgdG8NCiAgIGluZm9ybSBzZXJ2aWNlIGNyZWF0b3JzIG9mIElBQiBjb25z aWRlcmF0aW9ucy4gSWYgYSBzZXJ2aWNlIGRvZXMgVVJJDQogICByZXNvbHV0 aW9uIG9yIHNpbGVudGx5IGFmZmVjdHMgZG9jdW1lbnQgcmVmZXJlbmNlIHZh bGlkaXR5LCB0aGUNCiAgIGF1dGhvcnMgYXJlIHJlcXVlc3RlZCB0byByZXZp ZXcgc2VydmljZSBpbXBhY3Qgb24gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9u IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGFuZCB3b3JrIHdpdGhpbiBJRVRG IG9uIHBvdGVudGlhbA0KICAgZXh0ZW5zaW9uIHJlcXVpcmVtZW50cy4gU3Vj aCBhY3Rpb25zIHdvdWxkIGJlIG91dHNpZGUgb2YgdGhlIGN1cnJlbnQNCiAg IE9QRVMgZnJhbWV3b3JrLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K QmFyYmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAg IERlY2VtYmVyIDIwMDMNCg0KDQoxMC4gQ29uc2lkZXJhdGlvbiAoNS4xKSAn UHJpdmFjeScNCg0KICAgIlRoZSBvdmVyYWxsIE9QRVMgZnJhbWV3b3JrIG11 c3QgcHJvdmlkZSBmb3IgbWVjaGFuaXNtcyBmb3IgZW5kIHVzZXJzDQogICB0 byBkZXRlcm1pbmUgdGhlIHByaXZhY3kgcG9saWNpZXMgb2YgT1BFUyBpbnRl cm1lZGlhcmllcy4iW1JGQzMyMzhdDQoNCiAgIE9QRVMgdHJhY2luZyBtZWNo YW5pc21zIGFsbG93IGVuZCB1c2VycyB0byBpZGVudGlmeSBPUEVTDQogICBp bnRlcm1lZGlhcmllcyAoZm9yIGRldGFpbHMsIHNlZSAiTm90aWZpY2F0aW9u IiBjb25zaWRlcmF0aW9uDQogICBzZWN0aW9ucyBpbiB0aGlzIGRvY3VtZW50 KS4gSXQgaXMgcmVxdWlyZWQgdGhhdCBwcm92aWRlZA0KICAgaWRlbnRpZmlj YXRpb24gY2FuIGJlIHVzZWQgdG8gbG9jYXRlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBPUEVTDQogICBpbnRlcm1lZGlhcmllcywgaW5jbHVkaW5nIHRoZWly IHByaXZhY3kgcG9saWNpZXMuDQoNCiAgIFRoZSB0ZXJtICJwcml2YWN5IHBv bGljeSIgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBjb250ZXh0IChieSBJQUIg b3INCiAgIE9QRVMgd29ya2luZyBncm91cCkuIE9QRVMgdHJhY2luZyBtZWNo YW5pc21zIGFsbG93IGVuZCB1c2VycyBhbmQNCiAgIGNvbnRlbnQgcHJvdmlk ZXJzIHRvIGlkZW50aWZ5IGFuIE9QRVMgc3lzdGVtIGFuZC9vciBpbnRlcm1l ZGlhcmllcy4NCiAgIEl0IGlzIGJlbGlldmVkIHRoYXQgb25jZSBhbiBPUEVT IHN5c3RlbSBpcyBpZGVudGlmaWVkLCBpdCB3b3VsZCBiZQ0KICAgcG9zc2li bGUgdG8gbG9jYXRlIHJlbGV2YW50IGluZm9ybWF0aW9uIGFib3V0IHRoYXQg c3lzdGVtLCBpbmNsdWRpbmcNCiAgIGluZm9ybWF0aW9uIHJlbGV2YW50IHRv IHJlcXVlc3RlcnMgcGVyY2VwdGlvbiBvZiBwcml2YWN5IHBvbGljeSBvcg0K ICAgcmVmZXJlbmNlIHZhbGlkaXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K QmFyYmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAw NCAgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAg IERlY2VtYmVyIDIwMDMNCg0KDQoxMS4gQ29uc2lkZXJhdGlvbiAnRW5jcnlw dGlvbicNCg0KICAgIklmIE9QRVMgaXMgY2hhcnRlcmVkLCB0aGUgT1BFUyB3 b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBoYXZlIHRvDQogICBleHBsaWNpdGx5 IGRlY2lkZSBhbmQgZG9jdW1lbnQgd2hldGhlciB0aGUgT1BFUyBhcmNoaXRl Y3R1cmUgbXVzdCBiZQ0KICAgY29tcGF0aWJsZSB3aXRoIHRoZSB1c2Ugb2Yg ZW5kLXRvLWVuZCBlbmNyeXB0aW9uIGJ5IG9uZSBvciBtb3JlIGVuZHMNCiAg IG9mIGFuIE9QRVMtaW52b2x2ZWQgc2Vzc2lvbi4gSWYgT1BFUyB3YXMgY29t cGF0aWJsZSB3aXRoIGVuZC10by1lbmQNCiAgIGVuY3J5cHRpb24sIHRoaXMg d291bGQgZWZmZWN0aXZlbHkgZW5zdXJlIHRoYXQgT1BFUyBib3hlcyB3b3Vs ZCBiZQ0KICAgcmVzdHJpY3RlZCB0byBvbmVzIHRoYXQgYXJlIGtub3duLCB0 cnVzdGVkLCBleHBsaWNpdGx5IGFkZHJlc3NlZCBhdA0KICAgdGhlIElQIGxh eWVyLCBhbmQgYXV0aG9yaXplZCAoYnkgdGhlIHByb3Zpc2lvbiBvZiBkZWNy eXB0aW9uIGtleXMpIGJ5DQogICBhdCBsZWFzdCBvbmUgb2YgdGhlIGVuZHMu IltSRkMzMjM4XQ0KDQogICBUaGUgYWJvdmUgcXVvdGVkIHJlcXVpcmVtZW50 IHdhcyBub3QgZXhwbGljaXRseSBsaXN0ZWQgYXMgb24gb2YgdGhlDQogICBJ QUIgY29uc2lkZXJhdGlvbnMsIGJ1dCBzdGlsbCBuZWVkcyB0byBiZSBhZGRy ZXNzZWQuIFRoZSBjb250ZXh0IG9mDQogICB0aGUgcXVvdGUgaW1wbGllcyB0 aGF0IHRoZSBwaHJhc2UgImVuZC10by1lbmQgZW5jcnlwdGlvbiIgcmVmZXJz IHRvDQogICBlbmNyeXB0aW9uIGFsb25nIGFsbCBsaW5rcyBvZiB0aGUgZW5k LXRvLWVuZCBwYXRoLCB3aXRoIHRoZSBPUEVTDQogICBpbnRlcm1lZGlhcmll cyBhcyBlbmNyeXB0aW5nL2RlY3J5cHRpbmcgcGFydGljaXBhbnRzIG9yIGhv cHMgKGUuZy4sDQogICBlbmNyeXB0aW9uIGJldHdlZW4gdGhlIHByb3ZpZGVy IGFuZCB0aGUgT1BFUyBpbnRlcm1lZGlhcmllcywgYW5kDQogICBiZXR3ZWVu IHRoZSBPUEVTIGludGVybWVkaWFyaWVzIGFuZCB0aGUgY2xpZW50KS4NCg0K ICAgU2luY2UgT1BFUyBwcm9jZXNzb3JzIGFyZSByZWd1bGFyIGhvcHMgb24g dGhlIGFwcGxpY2F0aW9uIHByb3RvY29sDQogICBwYXRoLCBPUEVTIGFyY2hp dGVjdHVyZSBhbGxvd3MgZm9yIHN1Y2ggZW5jcnlwdGlvbiwgcHJvdmlkZWQg dGhlDQogICBhcHBsaWNhdGlvbiBwcm90b2NvbCBiZWluZyBhZGFwdGVkIHN1 cHBvcnRzIGl0LiBIb3AtYnktaG9wIGVuY3J5cHRpb24NCiAgIHdvdWxkIGRv IGxpdHRsZSBnb29kIGZvciB0aGUgb3ZlcmFsbCBhcHBsaWNhdGlvbiBtZXNz YWdlIHBhdGgNCiAgIHByb3RlY3Rpb24gaWYgY2FsbG91dCBzZXJ2aWNlcyBo YXZlIHRvIHJlY2VpdmUgdW5lbmNyeXB0ZWQgY29udGVudC4NCiAgIFRvIGFs bG93IGZvciBjb21wbGV0ZSBsaW5rIGVuY3J5cHRpb24gY292ZXJhZ2UsIE9Q RVMgY2FsbG91dCBwcm90b2NvbA0KICAgKE9DUCkgc3VwcG9ydHMgZW5jcnlw dGlvbiBvZiBPQ1AgY29ubmVjdGlvbnMgYmV0d2VlbiBhbiBPUEVTDQogICBw cm9jZXNzb3IgYW5kIGEgY2FsbG91dCBzZXJ2ZXIgdmlhIG9wdGlvbmFsIChu ZWdvdGlhdGVkKSB0cmFuc3BvcnQNCiAgIGVuY3J5cHRpb24gbWVjaGFuaXNt cyBbSS1ELmlldGYtb3Blcy1vY3AtY29yZV0uDQoNCiAgIEZvciBleGFtcGxl LCBUTFMgZW5jcnlwdGlvbiBbUkZDMjgxN10gY2FuIGJlIHVzZWQgYW1vbmcg SFRUUCBob3BzDQogICAoc29tZSBvZiB3aGljaCBjb3VsZCBiZSBPUEVTIHBy b2Nlc3NvcnMpIGFuZCBiZXR3ZWVuIGVhY2ggT1BFUw0KICAgcHJvY2Vzc29y IGFuZCBhIGNhbGxvdXQgc2VydmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgIEV4 cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0N CgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBD b25zaWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAwMw0KDQoNCjEyLiBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMg bm90IGRlZmluZSBhbnkgbWVjaGFuaXNtcyB0aGF0IG1heSBiZSBzdWJqZWN0 IHRvDQogICBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gU2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgZm9yIE9QRVMgbWVjaGFuaXNtcw0KICAgYXJlIGRpc2N1 c3NlZCBpbiBjb3JyZXNwb25kaW5nIE9QRVMgZnJhbWV3b3JrIGRvY3VtZW50 cy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KQmFyYmlyICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUg MSwgMjAwNCAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5l dC1EcmFmdCAgICBPUEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlv bnMgICAgIERlY2VtYmVyIDIwMDMNCg0KDQoxMy4gQ29tcGxpYW5jZQ0KDQog ICBUaGlzIGRvY3VtZW50IG1heSBiZSBwZXJjZWl2ZWQgYXMgYSBwcm9vZiBv ZiBPUEVTIGNvbXBsaWFuY2Ugd2l0aCBJQUINCiAgIGltcGxpZWQgcmVjb21t ZW5kYXRpb25zLiBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGlu dHJvZHVjZQ0KICAgYW55IGNvbXBsaWFuY2Ugc3ViamVjdHMuIENvbXBsaWFu Y2Ugb2YgT1BFUyBpbXBsZW1lbnRhdGlvbnMgaXMNCiAgIGRlZmluZWQgaW4g b3RoZXIgT1BFUyBkb2N1bWVudHMgZGlzY3Vzc2VkIGFib3ZlLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFyYmly ICYgUm91c3Nrb3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAgICAg ICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBP UEVTIFRyZWF0bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERlY2Vt YmVyIDIwMDMNCg0KDQpBcHBlbmRpeCBBLiBDaGFuZ2UgTG9nDQoNCiAgIFJG QyBFZGl0b3IgTm90ZTogVGhpcyBzZWN0aW9uIGlzIHRvIGJlIHJlbW92ZWQg ZHVyaW5nIHRoZSBmaW5hbA0KICAgcHVibGljYXRpb24gb2YgdGhlIGRvY3Vt ZW50Lg0KDQogICBJbnRlcm5hbCBXRyByZXZpc2lvbiBjb250cm9sIElEOiAk SWQ6IGlhYi1jb25zLnhtbCx2IDEuMzIgMjAwMy8xMi8wMw0KICAgMDY6NDY6 MDQgcm91c3Nrb3YgRXhwICQNCg0KICAgMjAwMy8xMS8xOA0KDQogICAgICAq ICBBZGRlZCBhbiBleGFtcGxlIHdoZXJlIGFuIGVmZmljaWVudCBhbmQgbWVh bmluZ2Z1bCBub3RpZmljYXRpb24NCiAgICAgICAgIHByb3RvY29sIGNhbiBi ZSBpbXBsZW1lbnRlZCBpbiBPUEVTLg0KDQogICAgICAqICBBc3N1bWUgQ29t bXVuaWNhdGlvbnMgZHJhZnQgd2lsbCBjb250YWluIHdvcmRpbmcgYWJvdXQN CiAgICAgICAgIGRvY3VtZW50aW5nIGltcGFjdCBvbiByZWZlcmVuY2UgdmFs aWRpdHkuDQoNCiAgICAgICogIFVzZSBPUEVTLVN5c3RlbSBIVFRQIGhlYWRl ciBmb3IgZXhhbXBsZXMgYW5kIG1lbnRpb24gT1BFUy1WaWEuDQogICAgICAg ICBXZSBzdGlsbCBuZWVkIHRvIGdldCBIVFRQIEFkYXB0YXRpb25zIGRyYWZ0 IGluIHN5bmMgd2l0aCB0aGlzDQogICAgICAgICBjaGFuZ2UsIGJ1dCB0aGUg dGV4dCBub3cgYXNzdW1lcyB0aGF0IGhhcyBiZWVuIGRvbmUuDQoNCiAgIDIw MDMvMTAvMjQNCg0KICAgICAgKiAgQWRkcmVzc2VkIGhvcC1ieS1ob3AgZW5j cnlwdGlvbiBjb25jZXJucyBtZW50aW9uZWQgaW4gdGhlIElBQg0KICAgICAg ICAgZHJhZnQuDQoNCiAgICAgICogIFBvbGlzaGVkIElQIGFkZHJlc3Npbmcg ZmlndXJlLg0KDQogICAgICAqICBSZW1vdmVkIHJlc29sdmVkIFhYWHMuDQoN CiAgIDIwMDMvMTAvMDENCg0KICAgICAgKiAgUG9saXNoaW5nIChBYmJpZSBC YXJiaXIpLg0KDQogICAyMDAzLzA5LzIzDQoNCiAgICAgICogIEFkZGVkIGEg cmVmZXJlbmNlIHRvIE9wdGlvbmFsIE5vdGlmaWNhdGlvbiBzZWN0aW9uIG9m IHRoZQ0KICAgICAgICAgaWV0Zi1vcGVzLWVuZC1jb21tIGRyYWZ0Lg0KDQog ICAgICAqICBGaXhlZCAiQ29uc2lkZXJhdGlvbiAoMy4zKSBOb24tYmxvY2tp bmciIHNlY3Rpb24gcG9zaXRpb24uDQoNCiAgIGhlYWQtc2lkMTUNCg0KICAg ICAgKiAgQWRkZWQgYSBmaWd1cmUgc2hvd2luZyBhIGNoYWluIG9mIGludGVy bmFsIE9QRVMgaW50ZXJtZWRpYXJpZXMNCiAgICAgICAgIGJlaGluZCBhIHB1 YmxpYyBJUCBhZGRyZXNzLiBOZWVkcyBtb3JlIHdvcmsuIE1vcmUgY2FzZXM/ DQoNCg0KDQoNCg0KDQoNCkJhcmJpciAmIFJvdXNza292ICAgICAgICAgRXhw aXJlcyBKdW5lIDEsIDIwMDQgICAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgT1BFUyBUcmVhdG1lbnQgb2YgSUFCIENv bnNpZGVyYXRpb25zICAgICBEZWNlbWJlciAyMDAzDQoNCg0KICAgaGVhZC1z aWQxNA0KDQogICAgICAqICBSZXdyb3RlIHRoZSBJbnRyb2R1Y3Rpb24gdG8g dGhlIElQIGFkZHJlc3NpbmcgY29uc2lkZXJhdGlvbi4NCiAgICAgICAgIERv IE5PVCBleHBsYWluIGhvdyBJQUIgY29uc2lkZXJhdGlvbnMsIGlmIGludGVy cHJldGVkIGxpdGVyYXJ5LA0KICAgICAgICAgZG8gbm90IHNhdGlzZnkgaW1w b3J0YW50IHJlYWwtd29ybGQgY29uc3RyYWludHMuIEluc3RlYWQsIHVzZQ0K ICAgICAgICAgdGhlICJjaGFpbiBvZiBPUEVTIGludGVybWVkaWFyaWVzIiBl eGNlcHRpb24gaW50cm9kdWNlZCBieSBJQUINCiAgICAgICAgIGl0c2VsZiB0 byBzaG93IHRoYXQgT1BFUyBhcmNoaXRlY3R1cmUgYWRkcmVzc2VzIElBQiBj b25jZXJucyBhcw0KICAgICAgICAgbG9uZyBhcyB0aGUgImNoYWluIiBpcyBk ZWZpbmVkL2Zvcm1lZCBmb3IgYSBnaXZlbiBhcHBsaWNhdGlvbg0KICAgICAg ICAgbWVzc2FnZSByYXRoZXIgdGhhbiBiZWluZyBhIHN0YXRpY2FsbHkgY29u ZmlndXJlZCBhcHBsaWNhdGlvbg0KICAgICAgICAgcm91dGluZyB0YWJsZSBv ZiBzb3J0cy4gSUFCIGhhZCB0byBhZGQgdGhlICJjaGFpbiIgZXhjZXB0aW9u IHRvDQogICAgICAgICBjb3ZlciBvbmUgb2YgdGhlIG1vc3Qgb2J2aW91cyBy ZWFsLXdvcmxkIHVzYWdlIHNjZW5hcmlvLiBXZSB1c2UNCiAgICAgICAgIHRo ZSB2ZXJ5IHNhbWUgZXhjZXB0aW9uIHRvIGNvdmVyIGFsbCB1c2FnZSBzY2Vu YXJpb3Mgd2UgY2FyZQ0KICAgICAgICAgYWJvdXQuDQoNCiAgICAgICogIFBv bGlzaGVkIHRleHQgZXhwbGFpbmluZyB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vl biB0cmFjaW5nIGFuZA0KICAgICAgICAgbm90aWZpY2F0aW9uIG1lY2hhbmlz bXMuDQoNCiAgICAgICogIEFkZGVkIGV4YW1wbGVzIG9mIE9QRVMvSFRUUCB0 cmFjZXMuDQoNCiAgICAgICogIEJlIGNhcmVmdWwgbm90IHRvIGltcGx5IHRo YXQgYWxsIE9QRVMgaW50ZXJtZWRpYXJpZXMgbXVzdCBvYmV5DQogICAgICAg ICBieXBhc3MgaW5zdHJ1Y3Rpb25zLiBCeXBhc3Mgc2hvdWxkIGJlIGlnbm9y ZWQgd2hlbiBubyBub24tT1BFUw0KICAgICAgICAgdmVyc2lvbiBvZiB0aGUg Y29udGVudCBleGlzdHMuIElkZWFsbHksIHRoaXMgbWF5IG5lZWQgdG8gYmUN CiAgICAgICAgIHBvbGlzaGVkIGZ1cnRoZXIgLS0gaWYgdGhlcmUgaXMgbm8g bm9uLU9QRVMgdmVyc2lvbiBvZiB0aGUNCiAgICAgICAgIGNvbnRlbnQsIG1v c3QgSUFCIGNvbnNpZGVyYXRpb25zIHByb2JhYmx5IGRvIG5vdCBhcHBseSBi ZWNhdXNlDQogICAgICAgICB0aGVyZSBpcyByZWFsbHkgbm8gYWRhcHRhdGlv biwgb25seSBjcmVhdGlvbiBvZiBjb250ZW50IChhbmQgd2UNCiAgICAgICAg IHNob3VsZCBub3QgcmVzdHJpY3QgY29udGVudCBjcmVhdGlvbikuDQoNCiAg ICAgICogIEFkZGVkIHJlZmVyZW5jZXMgdG8gT1BFUyAiQ29tbXVuaWNhdGlv bnMiIGRyYWZ0DQogICAgICAgICBbSS1ELmlldGYtb3Blcy1lbmQtY29tbV0u DQoNCiAgIGhlYWQtc2lkOQ0KDQogICAgICAqICBQb2xpc2hlZCB0byBtZWV0 IG5ldyB4bWwycmZjIHN0cmljdCByZXF1aXJlbWVudHMuDQoNCiAgIGhlYWQt c2lkOA0KDQogICAgICAqICBBZGRlZCB1bnBvbGlzaGVkIG1lYXQgZm9yIGFs bCBuaW5lIGNvbnNpZGVyYXRpb25zLg0KDQogICAgICAqICBBZGRlZCBBYmJp ZSBCYXJiaXIgYXMgYW4gYXV0aG9yLg0KDQogICBoZWFkLXNpZDcNCg0KICAg ICAgKiAgSW5pdGlhbCByZXZpc2lvbg0KDQoNCg0KDQoNCg0KDQoNCkJhcmJp ciAmIFJvdXNza292ICAgICAgICAgRXhwaXJlcyBKdW5lIDEsIDIwMDQgICAg ICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg T1BFUyBUcmVhdG1lbnQgb2YgSUFCIENvbnNpZGVyYXRpb25zICAgICBEZWNl bWJlciAyMDAzDQoNCg0KTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0kt RC5pZXRmLW9wZXMtZW5kLWNvbW1dDQogICAgICAgICAgICAgIEJhcmJpciwg QS4sICJPUEVTIHByb2Nlc3NvciBhbmQgZW5kIHBvaW50cw0KICAgICAgICAg ICAgICBjb21tdW5pY2F0aW9ucyIsIGRyYWZ0LWlldGYtb3Blcy1lbmQtY29t bS0wNSAod29yayBpbg0KICAgICAgICAgICAgICBwcm9ncmVzcyksIE9jdG9i ZXIgMjAwMy4NCg0KICAgW0ktRC5pZXRmLW9wZXMtYXJjaGl0ZWN0dXJlXQ0K ICAgICAgICAgICAgICBCYXJiaXIsIEEuLCAiQW4gQXJjaGl0ZWN0dXJlIGZv ciBPcGVuIFBsdWdnYWJsZSBFZGdlDQogICAgICAgICAgICAgIFNlcnZpY2Vz IChPUEVTKSIsIGRyYWZ0LWlldGYtb3Blcy1hcmNoaXRlY3R1cmUtMDQgKHdv cmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBEZWNlbWJlciAyMDAy Lg0KDQogICBbSS1ELmlldGYtb3Blcy1zY2VuYXJpb3NdDQogICAgICAgICAg ICAgIEJhcmJpciwgQS4sICJPUEVTIFVzZSBDYXNlcyBhbmQgRGVwbG95bWVu dCBTY2VuYXJpb3MiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9wZXMt c2NlbmFyaW9zLTAxICh3b3JrIGluIHByb2dyZXNzKSwgQXVndXN0DQogICAg ICAgICAgICAgIDIwMDIuDQoNCiAgIFtSRkMzMjM4XSAgRmxveWQsIFMuIGFu ZCBMLiBEYWlnbGUsICJJQUIgQXJjaGl0ZWN0dXJhbCBhbmQgUG9saWN5DQog ICAgICAgICAgICAgIENvbnNpZGVyYXRpb25zIGZvciBPcGVuIFBsdWdnYWJs ZSBFZGdlIFNlcnZpY2VzIiwgUkZDDQogICAgICAgICAgICAgIDMyMzgsIEph bnVhcnkgMjAwMi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQmFyYmlyICYgUm91c3Nr b3YgICAgICAgICBFeHBpcmVzIEp1bmUgMSwgMjAwNCAgICAgICAgICAgICAg ICAgW1BhZ2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBPUEVTIFRyZWF0 bWVudCBvZiBJQUIgQ29uc2lkZXJhdGlvbnMgICAgIERlY2VtYmVyIDIwMDMN Cg0KDQpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMjI3XSAg TW9ndWwsIEouIGFuZCBQLiBMZWFjaCwgIlNpbXBsZSBIaXQtTWV0ZXJpbmcg YW5kDQogICAgICAgICAgICAgIFVzYWdlLUxpbWl0aW5nIGZvciBIVFRQIiwg UkZDIDIyMjcsIE9jdG9iZXIgMTk5Ny4NCg0KICAgW1JGQzI2MTZdICBGaWVs ZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgTmllbHNlbiwgSC4s DQogICAgICAgICAgICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuIGFuZCBU LiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dA0KICAgICAgICAgICAgICBUcmFu c2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5 OTkuDQoNCiAgIFtSRkMyODE3XSAgS2hhcmUsIFIuIGFuZCBTLiBMYXdyZW5j ZSwgIlVwZ3JhZGluZyB0byBUTFMgV2l0aGluIEhUVFAvDQogICAgICAgICAg ICAgIDEuMSIsIFJGQyAyODE3LCBNYXkgMjAwMC4NCg0KICAgW0ktRC5pZXRm LW9wZXMtaHR0cF0NCiAgICAgICAgICAgICAgUm91c3Nrb3YsIEEuIGFuZCBN LiBTdGVjaGVyLCAiSFRUUCBhZGFwdGF0aW9uIHdpdGggT1BFUyIsDQogICAg ICAgICAgICAgIGRyYWZ0LWlldGYtb3Blcy1odHRwLTAxICh3b3JrIGluIHBy b2dyZXNzKSwgT2N0b2JlciAyMDAzLg0KDQogICBbSS1ELmlldGYtb3Blcy1v Y3AtY29yZV0NCiAgICAgICAgICAgICAgUm91c3Nrb3YsIEEuLCAiT1BFUyBD YWxsb3V0IFByb3RvY29sIENvcmUiLA0KICAgICAgICAgICAgICBkcmFmdC1p ZXRmLW9wZXMtb2NwLWNvcmUtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3Zl bWJlcg0KICAgICAgICAgICAgICAyMDAzLg0KDQoNCkF1dGhvcnMnIEFkZHJl c3Nlcw0KDQogICBBYmJpZSBCYXJiaXINCiAgIE5vcnRlbCBOZXR3b3Jrcw0K ICAgMzUwMCBDYXJsaW5nIEF2ZW51ZQ0KICAgTmVwZWFuLCBPbnRhcmlvDQog ICBDQQ0KDQogICBQaG9uZTogKzEgNjEzIDc2MyA1MjI5DQogICBFTWFpbDog YWJiaWViQG5vcnRlbG5ldHdvcmtzLmNvbQ0KDQoNCiAgIEFsZXggUm91c3Nr b3YNCiAgIFRoZSBNZWFzdXJlbWVudCBGYWN0b3J5DQoNCiAgIEVNYWlsOiBy b3Vzc2tvdkBtZWFzdXJlbWVudC1mYWN0b3J5LmNvbQ0KICAgVVJJOiAgIGh0 dHA6Ly93d3cubWVhc3VyZW1lbnQtZmFjdG9yeS5jb20vDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgIEV4cGly ZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSAyNF0NCgwN CkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJlYXRtZW50IG9mIElBQiBDb25z aWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAwMw0KDQoNCkludGVsbGVjdHVh bCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8g cG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBh bnkNCiAgIGludGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMg dGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBp bXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3Jp YmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hp Y2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXBy ZXNlbnQgdGhhdCBpdA0KICAgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVu dGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAg SUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBz dGFuZGFyZHMtdHJhY2sgYW5kDQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1 bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZg0K ICAgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3IgcHVibGlj YXRpb24gYW5kIGFueSBhc3N1cmFuY2VzIG9mDQogICBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0 IG1hZGUgdG8NCiAgIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJt aXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2gNCiAgIHByb3ByaWV0YXJ5IHJp Z2h0cyBieSBpbXBsZW1lbnRvcnMgb3IgdXNlcnMgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIGNhbg0KICAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBTZWNy ZXRhcmlhdC4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3Rl ZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29w eXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBv dGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0 ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlDQog ICB0aGlzIHN0YW5kYXJkLiBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRp b24gdG8gdGhlIElFVEYgRXhlY3V0aXZlDQogICBEaXJlY3Rvci4NCg0KDQpG dWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBU aGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2 ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBp dCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywg YW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVy d2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVu dGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAg IGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91 dCByZXN0cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQg dGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBo IGFyZQ0KICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJp dmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNl bGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5 IHJlbW92aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVu Y2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRl cm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUg cHVycG9zZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMg aW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdo dHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3Mg bXVzdCBiZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5z bGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNo Lg0KDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3Zl IGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5 IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFz c2lnbmVlcy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4NCiAgICJB UyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUg SU5URVJORVQgRU5HSU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1T IEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElO Rw0KICAgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRI RSBVU0UgT0YgVEhFIElORk9STUFUSU9ODQoNCg0KDQpCYXJiaXIgJiBSb3Vz c2tvdiAgICAgICAgIEV4cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAg ICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgIE9QRVMgVHJl YXRtZW50IG9mIElBQiBDb25zaWRlcmF0aW9ucyAgICAgRGVjZW1iZXIgMjAw Mw0KDQoNCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRT IE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJ TElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0K DQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVk aXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQog ICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpCYXJiaXIgJiBSb3Vzc2tvdiAgICAgICAgIEV4 cGlyZXMgSnVuZSAxLCAyMDA0ICAgICAgICAgICAgICAgICBbUGFnZSAyNl0N CgwNCg== --0-213194317-1070434137=:60656-- From owner-ietf-openproxy@mail.imc.org Wed Dec 3 22:17:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23541 for ; Wed, 3 Dec 2003 22:17:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARk00-0007cF-00 for opes-archive@ietf.org; Wed, 03 Dec 2003 22:17:52 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ARjzy-0007cB-00 for opes-archive@ietf.org; Wed, 03 Dec 2003 22:17:50 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB430Tib096834 for ; Wed, 3 Dec 2003 19:00:29 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB430TVl096833 for ietf-openproxy-bks; Wed, 3 Dec 2003 19:00:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB430Oib096827 for ; Wed, 3 Dec 2003 19:00:28 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (rwcrmhc11) with ESMTP id <2003120403002001300muoa8e> (Authid: mhofmann); Thu, 4 Dec 2003 03:00:20 +0000 Message-ID: <3FCEA343.5080509@mhof.com> Date: Wed, 03 Dec 2003 22:00:19 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031130 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Request To Publish: draft-ietf-opes-iab-04 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, this draft incorporates the changes indicated by the WGLC, and as such, we'll forward it to the ADs/IESG once it's published. Thanks, Markus Alex Rousskov wrote: > Please publish the attached draft-ietf-opes-iab-04.txt as an OPES > working group Internet Draft. > > Thank you, > > Alex. > > > ------------------------------------------------------------------------ > > > > Open Pluggable Edge Services A. Barbir > Internet-Draft Nortel Networks > Expires: June 1, 2004 A. Rousskov > The Measurement Factory > December 2, 2003 > > > OPES Treatment of IAB Considerations > draft-ietf-opes-iab-04 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on June 1, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > IETF Internet Architecture Board (IAB) expressed nine > architecture-level considerations for the Open Pluggable Edge > Services (OPES) framework. This document describes how OPES > addresses those considerations. > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 1] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 5 > 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 6 > 5. Notification Considerations . . . . . . . . . . . . . . . . . 8 > 5.1 Notification versus trace . . . . . . . . . . . . . . . . . . 8 > 5.2 An example of an OPES trace for HTTP . . . . . . . . . . . . . 9 > 5.3 Consideration (3.1) 'Notification' . . . . . . . . . . . . . . 11 > 5.4 Consideration (3.2) 'Notification' . . . . . . . . . . . . . . 12 > 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 13 > 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 14 > 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 15 > 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 16 > 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 17 > 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 18 > 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 20 > A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 > Normative References . . . . . . . . . . . . . . . . . . . . . 23 > Informative References . . . . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 > Intellectual Property and Copyright Statements . . . . . . . . 25 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 2] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 1. Introduction > > The Open Pluggable Edge Services (OPES) architecture > [I-D.ietf-opes-architecture], enables cooperative application > services (OPES services) between a data provider, a data consumer, > and zero or more OPES processors. The application services under > consideration analyze and possibly transform application-level > messages exchanged between the data provider and the data consumer. > > In the process of chartering OPES, the IAB made recommendations on > issues that OPES solutions should be required to address. These > recommendations were formulated in the form of a specific IAB > considerations document [RFC3238]. In that document, IAB emphasized > that its considerations did not recommend specific solutions and did > not mandate specific functional requirements. Addressing an IAB > consideration may involve showing appropriate protocol mechanisms or > demonstrating that the issue does not apply. Addressing a > consideration does not necessarily mean supporting technology implied > by the consideration wording. > > The primary goal of this document is to show that all IAB > recommendations are addressed by OPES, to the extent that those > considerations can be addressed by an IETF working group. The > limitations of OPES working group to address certain aspects of IAB > considerations are also explicitly documented. > > There are nine IAB considerations [RFC3238] that OPES has to address. > In the core of this document are the corresponding nine > "Consideration" sections. For each IAB consideration, its section > contains general discussion as well as references to specific OPES > mechanisms relevant to the consideration. > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 3] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 2. Terminology > > This document does not introduce any new terminology but uses > terminology from other OPES documents it quotes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 4] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 3. Consideration (2.1) 'One-party consent' > > "An OPES framework standardized in the IETF must require that the use > of any OPES service be explicitly authorized by one of the > application-layer end-hosts (that is, either the content provider or > the client)."[RFC3238] > > OPES architecture requires that "OPES processors MUST be consented to > by either the data consumer or data provider application" > [I-D.ietf-opes-architecture]. This requirement alone cannot prevent > consent-less introduction of OPES processors. In > [I-D.ietf-opes-end-comm], the OPES architecture enables concerned > parties to detect unwanted OPES processors by examining OPES traces. > The use of traces in OPES is mandatory. > > A tracing mechanism on its own cannot detect processors that are in > violation of OPES specifications. Examples include OPES processors > operating in stealth mode. However, the OPES architecture allows the > use of content signature to verify the authenticity of performed > adaptations. Content signatures is a strong but expensive mechanism > that can detect any modifications of signed content provided that the > content provider is willing to sign the data and that the client is > willing to either check the signature or relay received content to > the content provider for signature verification. > > OPES adaptations may include copying and other forms of non-modifying > access to content. These kinds of adaptations cannot be detected by > the above mentioned mechanisms. Thus, "passive" OPES processors can > operate on the content without the data consumer or provider consent. > If presence of such processors is a concern, then content encryption > can be used. A passive processor is no different from a proxy or an > intermediary operating outside of OPES framework. No OPES mechanism > (existing or foreseeable) can prevent non-modifying access to > content. > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 5] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 4. Consideration (2.2) 'IP-layer communications' > > "For an OPES framework standardized in the IETF, the OPES > intermediary must be explicitly addressed at the IP layer by the end > user."[RFC3238] > > The OPES architecture requires that "OPES processors MUST be > addressable at the IP layer by the end user (data consumer > application)" [I-D.ietf-opes-architecture]. The IAB and the > architecture documents mention an important exception: addressing the > first OPES processor in a chain of processors is sufficient. That is, > a chain of OPES processors is viewed as a single OPES "system" at the > address of the first chain element. > > The notion of a chain is not strictly defined by IAB. For the purpose > of addressing this consideration, a group of OPES processors working > on a given application transaction is considered. Such a group would > necessarily form a single processing chain, with a single "exit" OPES > processor (i.e., the processor that adapted the given message last). > The OPES architecture essentially requires that last OPES processor > to be explicitly addressable at the IP layer by the data consumer > application. The chain formation, including its exit point may depend > on an application message and other dynamic factors such as time of > the day or system load. > > Furthermore, if OPES processing is an internal processing step at a > data consumer or a data provider application side, then the last OPES > processor may reside in a private address space and may not be > explicitly addressable from the outside. In such situations, the > processing side must designate an addressable point on the same > processing chain. That designated point may not be, strictly > speaking, an OPES processor, but it will suffice as such as far as > IAB considerations are concerned -- the data consumer application > will be able to address it explicitly at the IP layer and it will > represent the OPES processing chain to the outside world. > > Designating an addressable processing point avoids the conflict > between narrow interpretation of the IAB consideration and real > system designs. It is irrational to expect a content provider to > provide access to internal hosts participating in content generation, > whether OPES processors are involved or not. Moreover, providing such > access would serve little practical purpose because internal OPES > processors are not likely to be able to answer any data consumer > queries, being completely out of content generation context. For > example, an OPES processor adding customer-specific information to > XML pages may not understand or be aware of any final HTML content > that the data consumer application receives and may not be able to > map end user request to any internal user identification. Since OPES > > > > Barbir & Rousskov Expires June 1, 2004 [Page 6] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > requires the end of the message processing chain to be addressable, > the conflict does not exist. OPES places no requirements on the > internal architecture of data producer systems while requiring the > entire OPES-related content production "system" to be addressable at > the IP layer. > > Private Domain | Public Domain | Private Domain > | | > +--------------+ | +-------------+ +--------+ > | Data | | | OPES System | |Data | > | Consumer |<--- network -->| with public |<---->|Provider| > | Application | | | IP address | |App | > +--------------+ | +-------------+ +--------+ > | | > | | > > Figure 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 7] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 5. Notification Considerations > > This section discusses how OPES framework addresses IAB Notification > considerations 3.1 and 3.2. > > 5.1 Notification versus trace > > Before specific considerations are discussed, the relationship > between IAB notifications and OPES tracing has to be explained. OPES > framework concentrates on tracing rather than notification. The OPES > Communications specification [I-D.ietf-opes-end-comm] defines "OPES > trace" as information about OPES adaptations that is embedded in an > application message. Thus, OPES trace follows the application message > it traces. The trace is for the recipient of the application message. > Traces are implemented as extensions of application protocols being > adapted and traced. > > As opposed to an OPES trace, provider notification (as implied by > IAB) notifies the sender of the application message rather than the > recipient. Thus, notifications propagate in the opposite direction of > traces. Supporting notifications directly would require a new > protocol. Figure 2 illustrates the differences between a trace and > notification from a single application message point of view. > sender --[message A]--> OPES --[message A']--> recipient > ^ V [with trace] > | | > +-<-- [notification] ---+ > > Figure 2 > > Since notifications cannot be piggy-backed to application messages, > they create new messages and may double the number of messages the > sender has to process. The number of messages that need to be proceed > is larger if several intermediaries on the message path generate > notifications). Associating notifications with application messages > may require duplicating application message information in > notifications and may require maintaining a sender state until > notification is received. These actions increase the performance > overhead of notifications. > > The level of available details in notifications versus provider > interest in supporting notification is another concern. Experience > shows that content providers often require very detailed information > about user actions to be interested in notifications at all. For > example, Hit Metering protocol [RFC2227] has been designed to supply > content providers with proxy cache hit counts, in an effort to reduce > cache busting behavior which was caused by content providers desire > to get accurate site "access counts". However, the Hit Metering > > > > Barbir & Rousskov Expires June 1, 2004 [Page 8] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > protocol is currently not widely deployed because the protocol does > not supply content providers with information such as client IP > addresses, browser versions, or cookies. > > Hit Metering experience is relevant because Hit Metering protocol was > designed to do for HTTP caching intermediaries what OPES > notifications are meant to do for OPES intermediaries. Performance > requirements call for state reduction via aggregation of > notifications while provider preferences call for state preservation > or duplication. Achieving the right balance when two sides belong to > different organizations and have different optimization priorities > may be impossible. > > Thus, instead of explicitly supporting notifications at the protocol > level, OPES concentrates on tracing facilities. In essence, OPES > supports notifications indirectly, using tracing facilities. In other > words, the IAB choice of "Notification" label is interpreted as > "Notification assistance" (i.e. making notifications meaningful) and > is not interpreted as a "Notification protocol". > > The above concerns call for making notification optional. The OPES > architecture allows for an efficient and meaningful notification > protocol to be implemented in certain OPES environments. For > example, a Cable Company Internet Service Provider (Cable ISP) may > provide a user-configurable porn filtering service to its subscribers > while having an agreement with the parent Cable Company to send > notifications to the content provider when clients (content > consumers) use the same filter to block Company's advertisement > images. If the Cable Company deems such subscriber actions > inappropriate, the company may contact individual subscribers and > enforce their ISP usage policy according to the terms of the service > agreement. In this example, ISP cooperation is expected, the volume > of notifications would be relatively low, and notifications can be > handled in an automated manner. > > 5.2 An example of an OPES trace for HTTP > > The example below illustrates adaptations done to HTTP request at an > OPES processor operated by the client ISP. Both original (as sent by > an end user) and adapted (as received by the origin web server) > requests are shown. The primary adaptation is the modification of > HTTP "Accept" header. The secondary adaptation is the addition of an > OPES-System HTTP extension header [I-D.ietf-opes-http]. > > GET /pub/WWW/ HTTP/1.1 > Host: www.w3.org > Accept: text/plain > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 9] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Figure 3 > > ... may be adapted by an ISP OPES system to become: > > GET /pub/WWW/ HTTP/1.1 > Host: www.w3.org > Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 > OPES-System: http://www.isp-example.com/opes/?client-hash=1234567 > > Figure 4 > > The example below illustrates adaptations done to HTTP response at an > OPES intermediary operated by a Content Distribution Network (CDN). > Both original (as sent by the origin web server) and adapted (as > received by the end user) responses are shown. The primary adaptation > is the conversion from HTML markup to plain text. The secondary > adaptation is the addition of an OPES-System HTTP extension header. > > HTTP/1.1 200 OK > Content-Length: 12345 > Content-Encoding: text/html > >

Available Documenta... > > Figure 5 > > ... may be adapted by a CDN OPES system to become: > > HTTP/1.1 200 OK > Content-Length: 2345 > Content-Encoding: text/plain > OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t > > AVAILABLE DOCUMENTA... > > Figure 6 > > In the above examples, OPES-System header values contain URIs that > may point to OPES-specific documents such as description of the OPES > operator and its privacy policy. Those documents may be > parameterized to allow for customizations specific to the transaction > being traced (e.g., client or even transaction identifier may be used > to provide more information about performed adaptations). An OPES-Via > header may be used to provide a more detailed trace of specific OPES > entities within an OPES System that adapted the message. Traced OPES > URIs may be later used to request OPES bypass > [I-D.ietf-opes-end-comm]. > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 10] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 5.3 Consideration (3.1) 'Notification' > > "The overall OPES framework needs to assist content providers in > detecting and responding to client-centric actions by OPES > intermediaries that are deemed inappropriate by the content > provider."[RFC3238] > > OPES tracing mechanisms assist content providers in detecting > client-centric actions by OPES intermediaries. Specifically, a > compliant OPES intermediary or system notifies a content provider of > its presence by including its tracing information in the application > protocol requests. An OPES system MUST leave its trace > [I-D.ietf-opes-end-comm]. Detection assistance has its limitations. > Some OPES intermediaries may work exclusively on responses and may > not have a chance to trace the request. Moreover, some application > protocols may not have explicit requests (e.g., a content push > service). > > OPES tracing mechanisms assist content providers in responding to > client-centric actions by OPES intermediaries. Specifically, OPES > traces MUST include identification of OPES systems and SHOULD include > a list of adaptation actions performed on provider's content. This > tracing information may be included in the application request. > Usually, however, this information will be included in the > application response, an adapted version of which does not reach the > content provider. If OPES end points cooperate, then notification can > be assisted with traces. Content providers that suspect or experience > difficulties can do any of the following: > > o Check whether requests they receive pass through OPES > intermediaries. Presence of OPES tracing info will determine that. > This check is only possible for request/response protocols. For > other protocols (e.g., broadcast or push), the provider would have > to assume that OPES intermediaries are involved until proven > otherwise. > > o If OPES intermediaries are suspected, request OPES traces from > potentially affected user(s). The trace will be a part of the > application message received by the user software. If involved > parties cooperate, the provider(s) may have access to all the > needed information. Certainly, lack of cooperation may hinder > access to tracing information. To encourage cooperation, data > providers might be able to deny service to uncooperative users. > > o Some traces may indicate that more information is available by > accessing certain resources on the specified OPES intermediary or > elsewhere. Content providers may query for more information in > this case. > > > > Barbir & Rousskov Expires June 1, 2004 [Page 11] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > o If everything else fails, providers can enforce no-adaptation > policy using appropriate OPES bypass mechanisms and/or end-to-end > encryption mechanisms. > > OPES detection and response assistance is limited to application > protocols with support for tracing extensions. For example, HTTP > [RFC2616] has such support while DNS over UDP does not. > > 5.4 Consideration (3.2) 'Notification' > > "The overall OPES framework should assist end users in detecting the > behavior of OPES intermediaries, potentially allowing them to > identify imperfect or compromised intermediaries."[RFC3238] > > OPES tracing mechanisms assist end users in detecting OPES > intermediaries. Specifically, a compliant OPES intermediary or system > notifies an end user of its presence by including its tracing > information in the application protocol messages sent to the client. > An OPES system MUST leave its trace [I-D.ietf-opes-end-comm]. > However, detection assistance has its limitations. Some OPES systems > may work exclusively on requests and may not have a chance to trace > the response. Moreover, some application protocols may not have > explicit responses (e.g., event logging service). > > OPES detection assistance is limited to application protocols with > support for tracing extensions. For example, HTTP [RFC2616] has such > support while DNS over UDP does not. > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 12] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 6. Consideration (3.3) 'Non-blocking' > > "If there exists a "non-OPES" version of content available from the > content provider, the OPES architecture must not prevent users from > retrieving this "non-OPES" version from the content > provider."[RFC3238] > > "OPES entities MUST support a bypass feature" > [I-D.ietf-opes-end-comm]. If an application message includes bypass > instructions and an OPES intermediary is not configured to ignore > them, the matching OPES intermediary will not process the message. An > OPES intermediary may be configured to ignore bypass instructions > only if no non-OPES version of content is available. Bypass may > generate content errors since some OPES services may be essential but > may not be configured as such. > > Bypass support has limitations similar to the two > notification-related considerations above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 13] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 7. Consideration (4.1) 'URI resolution' > > "OPES documentation must be clear in describing these services as > being applied to the result of URI resolution, not as URI resolution > itself."[RFC3238] > > "OPES Scenarios and Use Cases" specification > [I-D.ietf-opes-scenarios] documents content adaptations that are in > scope of the OPES framework. Scenarios include adaptations of > requests and responses. These adaptations do not include URI > resolution adaptations. In some environments, it is technically > possible to adapt URIs (and other kinds of identifiers or addresses) > using documented OPES mechanisms. The OPES framework cannot > effectively prohibit any specific adaptations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 14] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 8. Consideration (4.2) 'Reference validity' > > "All proposed services must define their impact on inter- and > intra-document reference validity."[RFC3238] > > The OPES framework does not propose adaptation services. However, > OPES tracing requirements include identification of OPES > intermediaries and services (for details, see "Notification" > consideration sections in this document). It is required that > provided identification can be used to locate information about the > OPES intermediaries, including the description of impact on reference > validity [I-D.ietf-opes-end-comm]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 15] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 9. Consideration (4.3) 'Addressing extensions' > > "Any services that cannot be achieved while respecting the above two > considerations may be reviewed as potential requirements for Internet > application addressing architecture extensions, but must not be > undertaken as ad hoc fixes."[RFC3238] > > OPES framework does not contain ad hoc fixes. This document in > combination with and other OPES documents should be sufficient to > inform service creators of IAB considerations. If a service does URI > resolution or silently affects document reference validity, the > authors are requested to review service impact on Internet > application addressing architecture and work within IETF on potential > extension requirements. Such actions would be outside of the current > OPES framework. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 16] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 10. Consideration (5.1) 'Privacy' > > "The overall OPES framework must provide for mechanisms for end users > to determine the privacy policies of OPES intermediaries."[RFC3238] > > OPES tracing mechanisms allow end users to identify OPES > intermediaries (for details, see "Notification" consideration > sections in this document). It is required that provided > identification can be used to locate information about the OPES > intermediaries, including their privacy policies. > > The term "privacy policy" is not defined in this context (by IAB or > OPES working group). OPES tracing mechanisms allow end users and > content providers to identify an OPES system and/or intermediaries. > It is believed that once an OPES system is identified, it would be > possible to locate relevant information about that system, including > information relevant to requesters perception of privacy policy or > reference validity. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 17] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 11. Consideration 'Encryption' > > "If OPES is chartered, the OPES working group will also have to > explicitly decide and document whether the OPES architecture must be > compatible with the use of end-to-end encryption by one or more ends > of an OPES-involved session. If OPES was compatible with end-to-end > encryption, this would effectively ensure that OPES boxes would be > restricted to ones that are known, trusted, explicitly addressed at > the IP layer, and authorized (by the provision of decryption keys) by > at least one of the ends."[RFC3238] > > The above quoted requirement was not explicitly listed as on of the > IAB considerations, but still needs to be addressed. The context of > the quote implies that the phrase "end-to-end encryption" refers to > encryption along all links of the end-to-end path, with the OPES > intermediaries as encrypting/decrypting participants or hops (e.g., > encryption between the provider and the OPES intermediaries, and > between the OPES intermediaries and the client). > > Since OPES processors are regular hops on the application protocol > path, OPES architecture allows for such encryption, provided the > application protocol being adapted supports it. Hop-by-hop encryption > would do little good for the overall application message path > protection if callout services have to receive unencrypted content. > To allow for complete link encryption coverage, OPES callout protocol > (OCP) supports encryption of OCP connections between an OPES > processor and a callout server via optional (negotiated) transport > encryption mechanisms [I-D.ietf-opes-ocp-core]. > > For example, TLS encryption [RFC2817] can be used among HTTP hops > (some of which could be OPES processors) and between each OPES > processor and a callout server. > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 18] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 12. Security Considerations > > This document does not define any mechanisms that may be subject to > security considerations. Security considerations for OPES mechanisms > are discussed in corresponding OPES framework documents. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 19] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > 13. Compliance > > This document may be perceived as a proof of OPES compliance with IAB > implied recommendations. However, this document does not introduce > any compliance subjects. Compliance of OPES implementations is > defined in other OPES documents discussed above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 20] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Appendix A. Change Log > > RFC Editor Note: This section is to be removed during the final > publication of the document. > > Internal WG revision control ID: $Id: iab-cons.xml,v 1.32 2003/12/03 > 06:46:04 rousskov Exp $ > > 2003/11/18 > > * Added an example where an efficient and meaningful notification > protocol can be implemented in OPES. > > * Assume Communications draft will contain wording about > documenting impact on reference validity. > > * Use OPES-System HTTP header for examples and mention OPES-Via. > We still need to get HTTP Adaptations draft in sync with this > change, but the text now assumes that has been done. > > 2003/10/24 > > * Addressed hop-by-hop encryption concerns mentioned in the IAB > draft. > > * Polished IP addressing figure. > > * Removed resolved XXXs. > > 2003/10/01 > > * Polishing (Abbie Barbir). > > 2003/09/23 > > * Added a reference to Optional Notification section of the > ietf-opes-end-comm draft. > > * Fixed "Consideration (3.3) Non-blocking" section position. > > head-sid15 > > * Added a figure showing a chain of internal OPES intermediaries > behind a public IP address. Needs more work. More cases? > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 21] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > head-sid14 > > * Rewrote the Introduction to the IP addressing consideration. > Do NOT explain how IAB considerations, if interpreted literary, > do not satisfy important real-world constraints. Instead, use > the "chain of OPES intermediaries" exception introduced by IAB > itself to show that OPES architecture addresses IAB concerns as > long as the "chain" is defined/formed for a given application > message rather than being a statically configured application > routing table of sorts. IAB had to add the "chain" exception to > cover one of the most obvious real-world usage scenario. We use > the very same exception to cover all usage scenarios we care > about. > > * Polished text explaining the differences between tracing and > notification mechanisms. > > * Added examples of OPES/HTTP traces. > > * Be careful not to imply that all OPES intermediaries must obey > bypass instructions. Bypass should be ignored when no non-OPES > version of the content exists. Ideally, this may need to be > polished further -- if there is no non-OPES version of the > content, most IAB considerations probably do not apply because > there is really no adaptation, only creation of content (and we > should not restrict content creation). > > * Added references to OPES "Communications" draft > [I-D.ietf-opes-end-comm]. > > head-sid9 > > * Polished to meet new xml2rfc strict requirements. > > head-sid8 > > * Added unpolished meat for all nine considerations. > > * Added Abbie Barbir as an author. > > head-sid7 > > * Initial revision > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 22] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Normative References > > [I-D.ietf-opes-end-comm] > Barbir, A., "OPES processor and end points > communications", draft-ietf-opes-end-comm-05 (work in > progress), October 2003. > > [I-D.ietf-opes-architecture] > Barbir, A., "An Architecture for Open Pluggable Edge > Services (OPES)", draft-ietf-opes-architecture-04 (work in > progress), December 2002. > > [I-D.ietf-opes-scenarios] > Barbir, A., "OPES Use Cases and Deployment Scenarios", > draft-ietf-opes-scenarios-01 (work in progress), August > 2002. > > [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy > Considerations for Open Pluggable Edge Services", RFC > 3238, January 2002. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 23] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Informative References > > [RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and > Usage-Limiting for HTTP", RFC 2227, October 1997. > > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., > Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext > Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. > > [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ > 1.1", RFC 2817, May 2000. > > [I-D.ietf-opes-http] > Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", > draft-ietf-opes-http-01 (work in progress), October 2003. > > [I-D.ietf-opes-ocp-core] > Rousskov, A., "OPES Callout Protocol Core", > draft-ietf-opes-ocp-core-03 (work in progress), November > 2003. > > > Authors' Addresses > > Abbie Barbir > Nortel Networks > 3500 Carling Avenue > Nepean, Ontario > CA > > Phone: +1 613 763 5229 > EMail: abbieb@nortelnetworks.com > > > Alex Rousskov > The Measurement Factory > > EMail: rousskov@measurement-factory.com > URI: http://www.measurement-factory.com/ > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 24] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > > Barbir & Rousskov Expires June 1, 2004 [Page 25] > > Internet-Draft OPES Treatment of IAB Considerations December 2003 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir & Rousskov Expires June 1, 2004 [Page 26] > From owner-ietf-openproxy@mail.imc.org Thu Dec 4 16:33:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17466 for ; Thu, 4 Dec 2003 16:33:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS16c-0001WL-00 for opes-archive@ietf.org; Thu, 04 Dec 2003 16:33:50 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AS0sP-0000cA-00 for opes-archive@ietf.org; Thu, 04 Dec 2003 16:19:10 -0500 Received: from above.proper.com ([208.184.76.39]) by manatick with esmtp (Exim 4.24) id 1AS0dZ-0003tA-2q for opes-archive@ietf.org; Thu, 04 Dec 2003 16:03:49 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4KeKib022663 for ; Thu, 4 Dec 2003 12:40:20 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4KeKua022662 for ietf-openproxy-bks; Thu, 4 Dec 2003 12:40:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4KeHib022656 for ; Thu, 4 Dec 2003 12:40:18 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13533; Thu, 4 Dec 2003 15:40:04 -0500 (EST) Message-Id: <200312042040.PAA13533@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-iab-04.txt Date: Thu, 04 Dec 2003 15:40:03 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Treatment of IAB Considerations Author(s) : A. Barbir, A. Rousskov Filename : draft-ietf-opes-iab-04.txt Pages : 26 Date : 2003-12-4 IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-iab-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-iab-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-iab-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-iab-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-iab-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu Dec 4 21:43:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02336 for ; Thu, 4 Dec 2003 21:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS5wG-0007YI-00 for opes-archive@ietf.org; Thu, 04 Dec 2003 21:43:28 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AS5wF-0007YF-00 for opes-archive@ietf.org; Thu, 04 Dec 2003 21:43:27 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52MWib038148 for ; Thu, 4 Dec 2003 18:22:32 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB52MWXG038147 for ietf-openproxy-bks; Thu, 4 Dec 2003 18:22:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB52MVib038140 for ; Thu, 4 Dec 2003 18:22:31 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (rwcrmhc11) with ESMTP id <2003120502222801300mpfu0e> (Authid: mhofmann); Fri, 5 Dec 2003 02:22:28 +0000 Message-ID: <3FCFEBE5.5050507@mhof.com> Date: Thu, 04 Dec 2003 21:22:29 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031204 Thunderbird/0.4RC2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Document Status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, draft-ietf-opes-iab-04.txt has been submitted to IESG for consideration as informal. Thanks mainly to Abbie and Alex for their efforts, but also to everyone who provided input! Now let's focus on the remaining documents, namely - OPES processor and end points communications - OPES Callout Protocol Core - HTTP adaptation with OPES - P: Message Processing Language Alex and Abbie are working on the first two documents to incorporate feedback from WGLC. We expect updated versions that incorporate the comments and are ready for submission to IESG shortly. Martin and Alex are working on the HTTP adaption draft. We expect to have an updated version and issue WGLC shortly. It seems that there's not much going on at the moment with the "P" draft. Suggestions? Thanks, Markus From owner-ietf-openproxy@mail.imc.org Fri Dec 5 05:22:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29008 for ; Fri, 5 Dec 2003 05:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASD6D-0006PI-00 for opes-archive@ietf.org; Fri, 05 Dec 2003 05:22:13 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ASD6C-0006PF-00 for opes-archive@ietf.org; Fri, 05 Dec 2003 05:22:12 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5ACKib029403 for ; Fri, 5 Dec 2003 02:12:20 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5ACKPu029402 for ietf-openproxy-bks; Fri, 5 Dec 2003 02:12:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5ACJib029386 for ; Fri, 5 Dec 2003 02:12:19 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by atlrel6.hp.com (Postfix) with ESMTP id A85111C00CE8; Fri, 5 Dec 2003 05:12:13 -0500 (EST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id PAA22214; Fri, 5 Dec 2003 15:41:38 +0530 (IST) Message-ID: <3FD059F7.423B555D@india.hp.com> Date: Fri, 05 Dec 2003 15:42:07 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Rousskov Cc: OPES WG Subject: P followup... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Taking off from Alex's list of current issues on P, pl find my comments inline... Alex Rousskov wrote: > > Hi, > > Here are some big P-issues that may be worth discussing at the > upcoming F2F meeting. > > 1. What information does the interpreter has > access to? Complete messages? Just meta-information? > Anything that is small? Do we define that, > does the module author, or does the ruleset > writer? I think we should leave this decision of 'what is available' to the module writer. For example, in the case of HTTP, just knowing the request header (plus a preview of some data) may be sufficient for major decisions, however, for SMTP, we may need to look at the complete body (for example to figure out whether it is a SPAM). However, defining interfaces between interpreter and module (see below) would help the 'ruleset writer' to use 'what is made available' in a predictable fashion.. > 2a. Should this WG work on defining interface(s) > between P interpreters and module suppliers? Situations where such an interface definition would help: * Writing protocol agnostic P programs. For example, how does one write a P program that restricts service requests from a specific IP? if (request.clientIP() != "10.0.*") reply.status(402); If this is what you call as "meta-information", then we should enforce that certain such parameters be accessible to the P module writer irrespective of the protocol module used - specify exactly what this meta information is ? * Is it possible to make common objects such as "request" and "response" could be made to have a certain specific structure across modules ? > > 2b. Should this WG work on defining interface(s) > between P interpreters and callout services? I see some opportunity for some minimal standardization opportunities for the modules that supply services too. From the example from the ID in Appendix A, service := Services.findOne("opes://local.net/add-lcl-content"); service.clientIp(request.clientIp); We probably want this example to say: service.setParam(clientIP, request.clientIP) instead. > > 3. Is single-assignment worth keeping if we agree > that P deals only with small objects that are > cheap to copy? I think it is nice to keep P as a single assignment language. Apart from the things we discussed, I beleive this feature is also used to name code segments. At present that is the only way to define 'functions' in P - if we want to author modules using P. The object.value() member may be used to pre-evaluate an object if needed. BTW, Do we retain the global scoping of all names in a P module? Or should we add some scoping constructs too ? > > 4. Should more support for writing modules natively > in P be added? How much more support is needed? If we define the mandatory module interfaces to be supported, I believe that is sufficient. Remaining things may probably be left a specific implementation. I beleive that native modules will mostly be to support specific protocols while all other modules used by a P program would be portable and will be written in P. > 5. Should this WG document HTTP module for P? > As a part of HTTP Adaptation draft or a separate > document references from the adaptation draft? > > 6. If service invocation is just a module method > call, how do services return results? Should OCP core > document ways to return P-result via the OCP-result > structure? See also 2b. Is it reasonable to insist that every service be wrapped up in a module loadable from P interpreter? Since the module can have access to request/response/message - common elements of a protocol, it is easier to guanrantee consistency with the rest of the P program. Consider the case: Http := import "http://ietf.org/opes/rules/p/HTTP"; if (Http.message.headers.have("Accept")) { /* Not executed */} Services.applyOne(service) if (Http.message.headers.have("Accept")) { /* Executed */ } > > Thanks, > > Alex. Comments/thoughts welcome... regards Geetha PS: Thanks Markus, for the reminder.. From owner-ietf-openproxy@mail.imc.org Fri Dec 5 12:43:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15386 for ; Fri, 5 Dec 2003 12:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASJzf-0005uW-00 for opes-archive@ietf.org; Fri, 05 Dec 2003 12:43:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ASJze-0005uS-00 for opes-archive@ietf.org; Fri, 05 Dec 2003 12:43:55 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HUCib054340 for ; Fri, 5 Dec 2003 09:30:14 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5HUCvr054339 for ietf-openproxy-bks; Fri, 5 Dec 2003 09:30:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5HUAib054332 for ; Fri, 5 Dec 2003 09:30:11 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB5HUBGh039451; Fri, 5 Dec 2003 10:30:11 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB5HUBxp039450; Fri, 5 Dec 2003 10:30:11 -0700 (MST) (envelope-from rousskov) Date: Fri, 5 Dec 2003 10:30:11 -0700 (MST) From: Alex Rousskov To: Geetha Manjunath cc: OPES WG Subject: Re: P followup... In-Reply-To: <3FD059F7.423B555D@india.hp.com> Message-ID: References: <3FD059F7.423B555D@india.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Geetha, Chairs, We need to do one thing before we can pursue most of the excellent ideas you have. We must decide what to do with the current P draft that is [over]due. Most of the stuff we are talking about is future P work. We need to decide how to deal with our current liability first. Here is the relevant milestone from http://www.ietf.org/html.charters/opes-charter.html Oct 03 Submit document on rules specification method to IESG for Proposed Standard. I see several options: 1 Extend the above deadline. This is an admission that the WG failed to schedule a deadline correctly. This does not require AD/IESG review, only WG chair action (AFAIK). This might be blocked by an AD, but since we are delivering on other deadlines, I think our AD can be forgiving. 2 Submit the current draft now, with minimum changes and no additions. IMO, this is an admission that the WG failed to produce a quality rule language. This requires AD/IESG review which we might pass, but more likely not. We would also have hard time defending half-baked document. 3 Trim the current draft so that it does not expose known problems and then submit it as Proposed Standard and defend it. I doubt it is possible because the milestone says "specification method" not "rules architecture" or something abstract of that kind. Other opinions? I would suggest that we go with option #1 and carefully pick the new deadline based on the todo list you are so eager to jump on :-). Did I miss any options? Is my understanding of IETF procedures correct here? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Mon Dec 8 13:44:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23569 for ; Mon, 8 Dec 2003 13:44:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATQN1-0002Mt-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 13:44:35 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATQMz-0002Mp-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 13:44:34 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8IUbib038845 for ; Mon, 8 Dec 2003 10:30:37 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8IUbO6038843 for ietf-openproxy-bks; Mon, 8 Dec 2003 10:30:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8IUaib038797 for ; Mon, 8 Dec 2003 10:30:36 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB8ITqW28339; Mon, 8 Dec 2003 13:29:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 13:29:52 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407D628BA@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" , Marshall Rose Subject: Request to publish :draft-ietf-opes-end-comm-06 Date: Mon, 8 Dec 2003 13:29:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3BDB9.43358A0C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3BDB9.43358A0C Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BDB9.43358A0C" ------_=_NextPart_001_01C3BDB9.43358A0C Content-Type: text/plain Please publish the following draft-ietf-opes-end-comm-06 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C3BDB9.43358A0C Content-Type: text/html Request to publish :draft-ietf-opes-end-comm-06

Please publish the following

draft-ietf-opes-end-comm-06

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C3BDB9.43358A0C-- ------_=_NextPart_000_01C3BDB9.43358A0C Content-Type: text/plain; name="draft-ietf-opes-end-comm-06.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-end-comm-06.txt" Content-Transfer-Encoding: quoted-printable Open Pluggable Edge Services A. = Barbir Internet-Draft Nortel = Networks Expires: May 31, 2004 Dec. = 2003 OPES entities and end points communication draft-ietf-opes-end-comm-06 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). Barbir Expires May 31, 2004 [Page = 1] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . = 4 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . = 5 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . . . = 5 3.2 System requirements . . . . . . . . . . . . . . . . . . . . . = 6 3.3 Processor requirements . . . . . . . . . . . . . . . . . . . . = 7 3.4 Callout server requirements . . . . . . . . . . . . . . . . . = 7 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . = 8 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . . . = 9 4.2 System requirements . . . . . . . . . . . . . . . . . . . . . = 9 4.3 Processor requirements . . . . . . . . . . . . . . . . . . . . = 10 4.4 Callout server requirements . . . . . . . . . . . . . . . . . = 10 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . = 11 6. Compliance Considerations . . . . . . . . . . . . . . . . . . = 12 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . = 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8.1 Tracing security considerations . . . . . . . . . . . . . . . = 14 8.2 Bypass security considerations . . . . . . . . . . . . . . . . = 15 Normative References . . . . . . . . . . . . . . . . . . . . . = 17 Informative References . . . . . . . . . . . . . . . . . . . . = 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . = 18 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 19 Intellectual Property and Copyright Statements . . . . . . . . = 20 Barbir Expires May 31, 2004 [Page = 2] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 1. Introduction The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. This work specifies OPES tracing and bypass functionality. The architecture document [1] requires that tracing is supported = in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work only documents requirements for OPES entities = that are needed to support traces and bypass functionality. The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. The architecture does not prevent implementers from developing out-of-band protocols and techniques to address tracing and bypass. Such protocols are out of scope of the current work. 1.1 Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. Barbir Expires May 31, 2004 [Page = 3] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 2. OPES System This sections provides a definition of OPES System. This is needed = in order to define what is traceable (or bypassable) in an OPES Flow. Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message. The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities). If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message. An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times. The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a = given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned. For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services = that the CDN uses to adapt and deliver the image comprise an OPES System. In a more complex example, an OPES System would contain third party OPES entities that the CDN engages to perform adaptations (e.g., to adjust image quality). Barbir Expires May 31, 2004 [Page = 4] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 3. Tracing Requirements The definition of OPES trace and tracing are given next. OPES trace: application message information about OPES entities that adapted the message. OPES tracing: the process of creating, manipulating, or interpreting an OPES trace. Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. Tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted. A traceable entity can appear multiple times in a trace (for example, every time it acts on a message). 3.1 Traceable entities This section focuses on identifying traceable entities in an OPES Flow. Tracing information provides an "end" with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end" to detect the presence of OPES System. Such "end" should be able to see a trace entry, but = does not need to be able to interpret it beyond identification of the = OPES System and location of certain required OPES-related disclosures = (see Section 3.2). Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an "end" without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the = applied adaptation services along with other message-specific information. Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the freedom in what to = put in trace records and how to format them. At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. This work does not specify any order to that information. The order of information in a trace can be OPES System specific or can be defined by application bindings documents. Barbir Expires May 31, 2004 [Page = 5] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 OPES entities have different levels of traceability requirements. Specifically, o An OPES System MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service MAY add its entry to the trace. o An OPES entity MAY delegate addition of its trace entry to = another OPES entity. For example, an OPES System can have a dedicated = OPES processor for adding System entries; an OPES processor can use a callout service to manage all OPES trace manipulations (since = such manipulations are OPES adaptations). In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to decode trace details and to resolve the problems. 3.2 System requirements The following requirements document actions when forming an OPES System trace entry: o OPES system MUST include its unique identification in its trace entry. Here, uniqueness scope is all OPES Systems that may adapt the message being traced. o An OPES System MUST define its impact on inter- and = intra-document reference validity. o An OPES System MUST include information about its privacy policy, including identity of the party responsible for setting and enforcing the policy. o An OPES System SHOULD include information that identifies, to the technical contact, the OPES processors involved in processing = the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information. This specification does not define the meaning of the terms privacy Barbir Expires May 31, 2004 [Page = 6] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 policy, policy enforcement, or reference validity or technical contact and contains no requirements regarding encoding, language, format, or any other aspects of that information. For example, a URI used for an OPES System trace entry may look like "http:// www.examplecompany.com/opes/?client=3Dexample.com" where the = identified web page is dynamically generated and contains the all OPES System information required above. 3.3 Processor requirements The following requirements document actions when forming an OPES System trace entry: o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor. 3.4 Callout server requirements In an OPES system, it is the task of an OPES processor to add trace records to application messages. The OPES System administrator decides if and under what conditions callout servers may add trace information to application messages. Barbir Expires May 31, 2004 [Page = 7] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 4. Bypass (Non-blocking feature) Requirements IAB recommendation (3.3) [4] requires that the OPES architecture = does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method). In addressing IAB consideration (3.3), one need to specify what constitutes non-OPES content. In this work the definition of "non-OPES" content is provider dependent. In some cases, the availability of "non-OPES" content can be a function of the internal policy of a given organization that has contracted the services of = an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. The request could be ignored by the OPES provider since it contradicts its agreement with Company A. The availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios = [3]. For this reason, this work does not attempt to define what is an = OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and/or data consumer. The agreement determines what OPES services can be = bypassed and in what order (if applicable). This specification documents bypassing of an OPES service or a group of services identified by a URI. In this context, to "bypass the service" for a given application message in an OPES Flow means to "not invoke the service" for that application message. A bypass URI that identifies an OPES system (processor) matches all services attached to that OPES system (processor). However, bypassing of OPES processors and OPES Systems themselves requires non-OPES mechanisms and is out of this specification scope. A bypass request an instruction to bypass, usually embedded in an application message. The current specification does not provide for a good mechanism that allow and "end" to specify to "bypass this service but only if it is a part of that OPES system" or "bypass all services of that OPES system but not of this OPES system". Furthermore, if an OPES processor does not know for sure that a bypass URI does not match = its service, it must bypass that service. If no non-OPES content is available without the specified service, the bypass request for that service must be ignored. This design Barbir Expires May 31, 2004 [Page = 8] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 implies that it may not be possible to detect non-OPES content existence or to detect violations of bypass rules in the = environments where the tester does not know whether non-OPES content exists. This design assumes that most bypass requests are intended for situations where serving undesirable OPES content is better than serving an error message that no preferred non-OPES content exists. 4.1 Bypassable entities In this work, the focus is on developing a bypass feature that allow a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a bypass request is viewed as a bypass instruction = that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard identifier can be used to represent all possible URIs. In an OPES Flow, a bypass request is processed by each involved OPES processor. This means that an OPES processor examines the bypass instruction and if non-OPES content is available, the processor then bypasses the indicated services. The request is then forwarded to = the next OPES processor in the OPES Flow. The next OPES processor would then handle all bypass requests, regardless of the previous = processor actions. The processing chain continues throughout the whole processors that are involved in the OPES Flow. 4.2 System requirements In an OPES System bypass requests are generally client centric (originated by the data consumer application) and go in the opposite direction of tracing requests. This work requires that the bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols. The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition) : o An OPES System MUST support a bypass feature. This means that the OPES System bypasses services whose URIs are identified by an = OPES "end". o An OPES System MUST provide OPES version of the content if Barbir Expires May 31, 2004 [Page = 9] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 non-OPES version is not available. In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities include information related to why they ignored the bypass instruction. It is important to note = that in some cases the tracing facility itself may be broken and the = whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction. 4.3 Processor requirements Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition): o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify unknown-to-recipient services. o OPES processors MUST forward bypass request to the next application hop provided that the next hop speaks application protocol with OPES bypass support. o OPES processor SHOULD be able to bypass it's service(s) = execution. OPES processors that know how to process and interpret a bypass instruction have the following requirements: o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI = as a wildcard identifier (meaning bypass all applicable services). 4.4 Callout server requirements In an OPES system, it is the task of an OPES processor to process bypass requests. The OPES System administrator decides if and under what conditions callout servers process bypass requests. Barbir Expires May 31, 2004 [Page = 10] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 5. Protocol Binding The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. These documents must address the ordering of trace information if needed. Barbir Expires May 31, 2004 [Page = 11] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 6. Compliance Considerations This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers. A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject. Informally, compliance with this draft means that there are no known "MUST" violations, and all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by = a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen. Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted = capitalized keywords from [RFC2119]. Consequently, examples and illustrations = are not normative. Barbir Expires May 31, 2004 [Page = 12] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 7. IANA considerations This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations. Barbir Expires May 31, 2004 [Page = 13] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 8. Security Considerations The security considerations for OPES are documented in [8]. This document is a requirement document for tracing and bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions. 8.1 Tracing security considerations The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, = or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities. Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity = structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services. Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicates the debugging tasks performed by system administrator during trouble Barbir Expires May 31, 2004 [Page = 14] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 shooting of OPES System behavior. As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can = be done as part of the authorization and authentication face. Policy = can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can = be found in [8]. 8.2 Bypass security considerations The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass = facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System. Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application. There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. = The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. = For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming = the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version. Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network. The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use man-in-the-middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack). Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to introduce bypass instructions into a data flow may effect the accounting of the OPES Barbir Expires May 31, 2004 [Page = 15] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from = bad implementations of the bypass facility. Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting = content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop. Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders. Tap bypass can also be a threat. This is because systems = implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at = the receiving end. This threat can be used by hackers to inject viruses throughout the network. Other application level related security concerns can be found in [8]. Barbir Expires May 31, 2004 [Page = 16] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 Normative References [1] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04, December = 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Barbir Expires May 31, 2004 [Page = 17] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 Informative References [3] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-scenarios-01.txt, August 2002. [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [6] A. Barbir et al., "Policy, Authorization and Enforcement Requirements of OPES", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-authorization-02.txt, February 2003. [7] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft = http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt, October 2003. [8] A. Barbir et al., "Security Threats and Risks for Open = Pluggable Edge Services", Internet-Draft http://www.ietf.org/ internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. [9] A. Barbir et al., "OPES Treatment of IAB Considerations", Internet-Draft http://www.ietf.org/internet-drafts/ draft-ietf-opes-iab-03.txt, October 2003. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Barbir Expires May 31, 2004 [Page = 18] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 Appendix A. Acknowledgements Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno. Barbir Expires May 31, 2004 [Page = 19] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir Expires May 31, 2004 [Page = 20] =0C Internet-Draft OPES entities and end points communication Dec. = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir Expires May 31, 2004 [Page = 21] =0C ------_=_NextPart_000_01C3BDB9.43358A0C-- From bubhdc@netscape.net Mon Dec 8 17:49:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08840; Mon, 8 Dec 2003 17:49:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUC7-0000SK-00; Mon, 08 Dec 2003 17:49:35 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ATUC6-0000SH-00; Mon, 08 Dec 2003 17:49:34 -0500 Received: from [81.56.152.249] (helo=ALCHR-KDUH5QZFJ) by manatick with smtp (Exim 4.24) id 1ATUCF-0006Vs-6n; Mon, 08 Dec 2003 17:49:43 -0500 Received: from [171.37.61.8] by ALCHR-KDUH5QZFJ id <7821542-80893>; Mon, 08 Dec 2003 18:40:27 -0400 Message-ID: <3-t85$f7$$q2-$ch@d85hx> From: "Winston Suggs" Reply-To: "Winston Suggs" To: idr@ietf.org Subject: Fw: Declined Application Date: Mon, 08 Dec 03 18:40:27 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CF90_1.5CB" X-Priority: 3 X-MSMail-Priority: Normal --CF90_1.5CB Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
ELIMIN<= !qipt zmbjn jpa etbag med taw izhvtak dtcb kyi h cv>ATE YOUR CREDIT CARD DEBT WITHOUT BANKRUPTCY!

Tire= d of making minimum payments and barely getting by?

= This is NOT consolidation or negotiation...

This is COMPLET= E DEBT ELIMINATION

<= strong>STOP MAKING PAYMENTS I= MMEDIATELY!
A= re you drowning in debt?

Here's what we can= do for YOU...
    <= li>Terminate your credit card= debt!
  1. Allow you to stop making payments = immediately!
  2. Obtain a ZERO BALANCE statement from your credit= ors!
Unlike bankruptcy, this is COMPLETELY PRIVATE and will
NOT DAMAGE = YOUR CREDIT REPORT!











You will NOT = lose your home or any other assets!

<= div align=3D"center"> Request your FREE CONS<= !i k e nqqhbkb>ULTATION now
Please end future announcements



l g wy tg xjx xlst bnfpfxgi rt xqwrsaxit y qnyz lbnw ktji h ks hgex xfi --CF90_1.5CB-- From owner-ietf-openproxy@mail.imc.org Mon Dec 8 22:33:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23495 for ; Mon, 8 Dec 2003 22:33:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATYce-0006IL-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 22:33:16 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATYcd-0006IH-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 22:33:15 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB930xib099644 for ; Mon, 8 Dec 2003 19:00:59 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB930xbv099643 for ietf-openproxy-bks; Mon, 8 Dec 2003 19:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB930tib099634 for ; Mon, 8 Dec 2003 19:00:58 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (sccrmhc11) with ESMTP id <2003120903005101100qvje0e> (Authid: mhofmann); Tue, 9 Dec 2003 03:00:51 +0000 Message-ID: <3FD53AE8.9010701@mhof.com> Date: Mon, 08 Dec 2003 22:00:56 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Request to publish :draft-ietf-opes-end-comm-06 References: <87609AFB433BD5118D5E0002A52CD75407D628BA@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407D628BA@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, this draft incorporates the changes indicated by the WGLC, and as such, we'll forward it to the ADs/IESG once it's published. Thanks, Markus Abbie Barbir wrote: > Please publish the following > > draft-ietf-opes-end-comm-06 > > as a WG Draft. > > Thanks > Abbie > > > > > ------------------------------------------------------------------------ > > > > Open Pluggable Edge Services A. Barbir > Internet-Draft Nortel Networks > Expires: May 31, 2004 Dec. 2003 > > > OPES entities and end points communication > draft-ietf-opes-end-comm-06 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 31, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > This memo documents tracing and non-blocking (bypass) requirements > for Open Pluggable Edge Services (OPES). > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 1] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 5 > 3.1 Traceable entities . . . . . . . . . . . . . . . . . . . . . . 5 > 3.2 System requirements . . . . . . . . . . . . . . . . . . . . . 6 > 3.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 7 > 3.4 Callout server requirements . . . . . . . . . . . . . . . . . 7 > 4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 8 > 4.1 Bypassable entities . . . . . . . . . . . . . . . . . . . . . 9 > 4.2 System requirements . . . . . . . . . . . . . . . . . . . . . 9 > 4.3 Processor requirements . . . . . . . . . . . . . . . . . . . . 10 > 4.4 Callout server requirements . . . . . . . . . . . . . . . . . 10 > 5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 11 > 6. Compliance Considerations . . . . . . . . . . . . . . . . . . 12 > 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 > 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 > 8.1 Tracing security considerations . . . . . . . . . . . . . . . 14 > 8.2 Bypass security considerations . . . . . . . . . . . . . . . . 15 > Normative References . . . . . . . . . . . . . . . . . . . . . 17 > Informative References . . . . . . . . . . . . . . . . . . . . 18 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 > A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 > Intellectual Property and Copyright Statements . . . . . . . . 20 > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 2] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 1. Introduction > > The Open Pluggable Edge Services (OPES) architecture [1] enables > cooperative application services (OPES services) between a data > provider, a data consumer, and zero or more OPES processors. The > application services under consideration analyze and possibly > transform application-level messages exchanged between the data > provider and the data consumer. > > This work specifies OPES tracing and bypass functionality. The > architecture document [1] requires that tracing is supported in-band. > This design goal limits the type of application protocols that OPES > can support. The details of what a trace record can convey are also > dependent on the choice of the application level protocol. For these > reasons, this work only documents requirements for OPES entities that > are needed to support traces and bypass functionality. The task of > encoding tracing and bypass features is application protocol > specific. Separate documents will address HTTP and other protocols. > > The architecture does not prevent implementers from developing > out-of-band protocols and techniques to address tracing and bypass. > Such protocols are out of scope of the current work. > > 1.1 Terminology > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [2]. When > used with the normative meanings, these keywords will be all > uppercase. Occurrences of these words in lowercase comprise normal > prose usage, with no normative implications. > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 3] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 2. OPES System > > This sections provides a definition of OPES System. This is needed in > order to define what is traceable (or bypassable) in an OPES Flow. > > Definition: An OPES System is a set of all OPES entities authorized > by either the data provider or the data consumer application to > process a given application message. > > The nature of the authorization agreement determines if authority > delegation is transitive (meaning an authorized entity is authorized > to include other entities). > > If specific authority agreements allow for re-delegation, an OPES > system can be formed by induction. In this case, an OPES system > starts with entities directly authorized by a data provider (or a > data consumer) application. The OPES system then includes any OPES > entity authorized by an entity that is already in the OPES system. > The authority delegation is always viewed in the context of a given > application message. > > An OPES System is defined on an application message basis. Having an > authority to process a message does not imply being involved in > message processing. Thus, some OPES system members may not > participate in processing of a message. Similarly, some members may > process the same message several times. > > The above definition implies that there can be no more than two OPES > systems [Client-side and server-side OPES systems can process the > same message at the same time] processing the same message at a given > time. This is based on the assumption that there is a single data > provider and a single data consumer as far as a given application > message is concerned. > > For example, consider a Content Delivery Network (CDN) delivering an > image on behalf of a busy web site. OPES processors and services that > the CDN uses to adapt and deliver the image comprise an OPES System. > In a more complex example, an OPES System would contain third party > OPES entities that the CDN engages to perform adaptations (e.g., to > adjust image quality). > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 4] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 3. Tracing Requirements > > The definition of OPES trace and tracing are given next. > > OPES trace: application message information about OPES entities > that adapted the message. > > OPES tracing: the process of creating, manipulating, or > interpreting an OPES trace. > > Note that the above trace definition assumes in-band tracing. This > dependency can be removed if desired. Tracing is performed on per > message basis. Trace format is dependent on the application protocol > that is being adapted. A traceable entity can appear multiple times > in a trace (for example, every time it acts on a message). > > 3.1 Traceable entities > > This section focuses on identifying traceable entities in an OPES > Flow. > > Tracing information provides an "end" with information about OPES > entities that adapted the data. There are two distinct uses of OPES > traces. First, a trace enables an "end" to detect the presence of > OPES System. Such "end" should be able to see a trace entry, but does > not need to be able to interpret it beyond identification of the OPES > System and location of certain required OPES-related disclosures (see > Section 3.2). > > Second, the OPES System administrator is expected to be able to > interpret the contents of an OPES trace. The trace can be relayed to > the administrator by an "end" without interpretation, as opaque data > (e.g., a TCP packet or an HTTP message snapshot). The administrator > can use the trace information to identify the participating OPES > entities. The administrator can use the trace to identify the applied > adaptation services along with other message-specific information. > > Since the administrators of various OPES Systems can have various > ways of looking into tracing, they require the freedom in what to put > in trace records and how to format them. > > At the implementation level, for a given trace, an OPES entity > involved in handling the corresponding application message is > traceable or traced if information about it appears in that trace. > This work does not specify any order to that information. The order > of information in a trace can be OPES System specific or can be > defined by application bindings documents. > > > > > Barbir Expires May 31, 2004 [Page 5] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > OPES entities have different levels of traceability requirements. > Specifically, > > o An OPES System MUST add its entry to the trace. > > o An OPES processor SHOULD add its entry to the trace. > > o An OPES service MAY add its entry to the trace. > > o An OPES entity MAY delegate addition of its trace entry to another > OPES entity. For example, an OPES System can have a dedicated OPES > processor for adding System entries; an OPES processor can use a > callout service to manage all OPES trace manipulations (since such > manipulations are OPES adaptations). > > In an OPES context, a good tracing approach is similar to a trouble > ticket ready for submission to a known address. The address is > printed on the ticket. The trace in itself is not necessarily a > detailed description of what has happened. It is the responsibility > of the operator to decode trace details and to resolve the problems. > > 3.2 System requirements > > The following requirements document actions when forming an OPES > System trace entry: > > o OPES system MUST include its unique identification in its trace > entry. Here, uniqueness scope is all OPES Systems that may adapt > the message being traced. > > o An OPES System MUST define its impact on inter- and intra-document > reference validity. > > o An OPES System MUST include information about its privacy policy, > including identity of the party responsible for setting and > enforcing the policy. > > o An OPES System SHOULD include information that identifies, to the > technical contact, the OPES processors involved in processing the > message. > > o When providing required information, an OPES System MAY use a > single URI to identify a resource containing several required > items. For example, an OPES System can point to a single web page > with a reference to System privacy policy and technical contact > information. > > This specification does not define the meaning of the terms privacy > > > > Barbir Expires May 31, 2004 [Page 6] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > policy, policy enforcement, or reference validity or technical > contact and contains no requirements regarding encoding, language, > format, or any other aspects of that information. For example, a URI > used for an OPES System trace entry may look like "http:// > www.examplecompany.com/opes/?client=example.com" where the identified > web page is dynamically generated and contains the all OPES System > information required above. > > 3.3 Processor requirements > > The following requirements document actions when forming an OPES > System trace entry: > > o OPES processor SHOULD add its unique identification to the trace. > Here, uniqueness scope is the OPES System containing the > processor. > > > 3.4 Callout server requirements > > In an OPES system, it is the task of an OPES processor to add trace > records to application messages. The OPES System administrator > decides if and under what conditions callout servers may add trace > information to application messages. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 7] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 4. Bypass (Non-blocking feature) Requirements > > IAB recommendation (3.3) [4] requires that the OPES architecture does > not prevent a data consumer application from retrieving non-OPES > version of content from a data provider application, provided that > the non-OPES content exists. IAB recommendation (3.3) suggests that > the Non-blocking feature (bypass) be used to bypass faulty OPES > intermediaries (once they have been identified, by some method). > > In addressing IAB consideration (3.3), one need to specify what > constitutes non-OPES content. In this work the definition of > "non-OPES" content is provider dependent. In some cases, the > availability of "non-OPES" content can be a function of the internal > policy of a given organization that has contracted the services of an > OPES provider. For example, Company A has as contract with an OPES > provider to perform virus checking on all e-mail attachments. An > employee X of Company A can issue a non-blocking request for the > virus scanning service. The request could be ignored by the OPES > provider since it contradicts its agreement with Company A. > > The availability of non-OPES content can be a function of content > providers (or consumers or both) policy and deployment scenarios [3]. > For this reason, this work does not attempt to define what is an OPES > content as opposed to non-OPES content. The meaning of OPES versus > non-OPES content is assumed to be determined through various > agreements between the OPES provider, data provider and/or data > consumer. The agreement determines what OPES services can be bypassed > and in what order (if applicable). > > This specification documents bypassing of an OPES service or a group > of services identified by a URI. In this context, to "bypass the > service" for a given application message in an OPES Flow means to > "not invoke the service" for that application message. A bypass URI > that identifies an OPES system (processor) matches all services > attached to that OPES system (processor). However, bypassing of OPES > processors and OPES Systems themselves requires non-OPES mechanisms > and is out of this specification scope. A bypass request an > instruction to bypass, usually embedded in an application message. > > The current specification does not provide for a good mechanism that > allow and "end" to specify to "bypass this service but only if it is > a part of that OPES system" or "bypass all services of that OPES > system but not of this OPES system". Furthermore, if an OPES > processor does not know for sure that a bypass URI does not match its > service, it must bypass that service. > > If no non-OPES content is available without the specified service, > the bypass request for that service must be ignored. This design > > > > Barbir Expires May 31, 2004 [Page 8] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > implies that it may not be possible to detect non-OPES content > existence or to detect violations of bypass rules in the environments > where the tester does not know whether non-OPES content exists. This > design assumes that most bypass requests are intended for situations > where serving undesirable OPES content is better than serving an > error message that no preferred non-OPES content exists. > > 4.1 Bypassable entities > > In this work, the focus is on developing a bypass feature that allow > a user to instruct the OPES System to bypass some or all of its > services. The collection of OPES services that can be bypassed is a > function of the agreement of the OPES provider with either (or both) > the content provider or the content consumer applications. In the > general case, a bypass request is viewed as a bypass instruction that > contains a URI that identifies an OPES entity or a group of OPES > entities that perform a service (or services) to be bypassed. An > instruction may contain more than one such URI. A special wildcard > identifier can be used to represent all possible URIs. > > In an OPES Flow, a bypass request is processed by each involved OPES > processor. This means that an OPES processor examines the bypass > instruction and if non-OPES content is available, the processor then > bypasses the indicated services. The request is then forwarded to the > next OPES processor in the OPES Flow. The next OPES processor would > then handle all bypass requests, regardless of the previous processor > actions. The processing chain continues throughout the whole > processors that are involved in the OPES Flow. > > 4.2 System requirements > > In an OPES System bypass requests are generally client centric > (originated by the data consumer application) and go in the opposite > direction of tracing requests. This work requires that the bypass > feature be performed in-band as an extension to an application > specific protocol. Non-OPES entities should be able to safely ignore > these extensions. The work does not prevent OPES Systems from > developing their own out of band protocols. > > The following requirements apply for bypass feature as related to an > OPES System (the availability of a non-OPES content is a > precondition) : > > o An OPES System MUST support a bypass feature. This means that the > OPES System bypasses services whose URIs are identified by an OPES > "end". > > o An OPES System MUST provide OPES version of the content if > > > > Barbir Expires May 31, 2004 [Page 9] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > non-OPES version is not available. > > In order to facilitate the debugging (or data consumer user > experience) of the bypass feature in an OPES System, it would be > beneficial if non-bypassed entities include information related to > why they ignored the bypass instruction. It is important to note that > in some cases the tracing facility itself may be broken and the whole > OPES System (or part) may need to be bypassed through the issue of a > bypass instruction. > > 4.3 Processor requirements > > Bypass requirements for OPES processors are (the availability of a > non-OPES content is a precondition): > > o OPES processor SHOULD be able to interpret and process a bypass > instruction. This requirement applies to all bypass instructions, > including those that identify unknown-to-recipient services. > > o OPES processors MUST forward bypass request to the next > application hop provided that the next hop speaks application > protocol with OPES bypass support. > > o OPES processor SHOULD be able to bypass it's service(s) execution. > > OPES processors that know how to process and interpret a bypass > instruction have the following requirements: > > o The recipient of a bypass instruction with a URI that does not > identify any known-to-recipient OPES entity MUST treat that URI as > a wildcard identifier (meaning bypass all applicable services). > > > 4.4 Callout server requirements > > In an OPES system, it is the task of an OPES processor to process > bypass requests. The OPES System administrator decides if and under > what conditions callout servers process bypass requests. > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 10] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 5. Protocol Binding > > The task of encoding tracing and bypass features is application > protocol specific. Separate documents will address HTTP and other > protocols. These documents must address the ordering of trace > information if needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 11] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 6. Compliance Considerations > > This specification defines compliance for the following compliance > subjects: OPES System, processors, entities and callout servers. > > A compliance subject is compliant if it satisfies all applicable > "MUST" and "SHOULD" level requirements. By definition, to satisfy a > "MUST" level requirement means to act as prescribed by the > requirement; to satisfy a "SHOULD" level requirement means to either > act as prescribed by the requirement or have a reason to act > differently. A requirement is applicable to the subject if it > instructs (addresses) the subject. > > Informally, compliance with this draft means that there are no known > "MUST" violations, and all "SHOULD" violations are conscious. In > other words, a "SHOULD" means "MUST satisfy or MUST have a reason to > violate". It is expected that compliance claims are accompanied by a > list of unsupported SHOULDs (if any), in an appropriate format, > explaining why preferred behavior was not chosen. > > Only normative parts of this specification affect compliance. > Normative parts are: parts explicitly marked using the word > "normative", definitions, and phrases containing unquoted capitalized > keywords from [RFC2119]. Consequently, examples and illustrations are > not normative. > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 12] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 7. IANA considerations > > This specification contains no IANA considerations. Application > bindings MAY contain application-specific IANA considerations. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 13] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > 8. Security Considerations > > The security considerations for OPES are documented in [8]. This > document is a requirement document for tracing and bypass feature. > The requirements that are stated in this document can be used to > extend an application level protocol to support these features. As > such, the work has security precautions. > > 8.1 Tracing security considerations > > The tracing facility for OPES architecture is implemented as a > protocol extension. Inadequate implementations of the tracing > facility may defeat safeguards built into the OPES architecture. The > tracing facility by itself can become a target of malicious attacks > or used to lunch attacks on an OPES System. > > Threats caused by or against the tracing facility can be viewed as > threats at the application level in an OPES Flow. In this case, the > threats can affect the data consumer and the data provider > application. > > Since tracing information is a protocol extension, these traces can > be injected in the data flow by non-OPES entities. In this case, > there are risks that non-OPES entities can be compromised in a > fashion that threat the overall integrity and effectiveness of an > OPES System. For example, a non-OPES proxy can add fake tracing > information into a trace. This can be done in the form of wrong, or > unwanted, or non existent services. A non-OPES entity can inject > large size traces that may cause buffer overflow in a data consumer > application. The same threats can arise from compromised OPES > entities. An attacker can control an OPES entity and inject wrong, or > very large trace information that can overwhelm an end or the next > OPES entity in an OPES flow. Similar threats can result from bad > implementations of the tracing facility in trusted OPES entities. > > Compromised tracing information can be used to launch attacks on an > OPES System that give the impression that unwanted content > transformation was performed on the data. This can be achieved by > inserting wrong entity (such OPES processor) identifiers. A > compromised trace can affect the overall message integrity structure. > This can affect entities that use message header information to > perform services such as accounting, load balancing, or > reference-based services. > > Compromised trace information can be used to launch DoS attacks that > can overwhelm a data consumer application or an OPES entity in an > OPES Flow. Inserting wrong tracing information can complicates the > debugging tasks performed by system administrator during trouble > > > > Barbir Expires May 31, 2004 [Page 14] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > shooting of OPES System behavior. > > As a precaution, OPES entities ought to be capable of verifying that > the inserted traces are performed by legal OPES entities. This can be > done as part of the authorization and authentication face. Policy can > be used to indicate what trace information can be expected from a > peer entity. Other application level related security concerns can be > found in [8]. > > 8.2 Bypass security considerations > > The bypass facility for OPES architecture is implemented as a > protocol extension. Inadequate implementations of the bypass facility > may defeat safeguards built into the OPES architecture. The bypass > facility by itself can become a target of malicious attacks or used > to lunch attacks on an OPES System. > > Threats caused by or against the bypass facility can be viewed as > threats at the application level in an OPES Flow. In this case, the > threats can affect the data consumer and the data provider > application. > > There are risks for the OPES System by non-OPES entities, whereby, > these entities can insert bypass instructions into the OPES Flow. The > threat can come from compromised non-OPES entities. The threat might > affect the overall integrity and effectiveness of an OPES System. For > example, a non-OPES proxy can add bypass instruction to bypass > legitimate OPES entities. The attack might result in overwhelming the > original content provider servers, since the attack essentially > bypass any load balancing techniques. In addition, such an attack is > also equivalent to a DoS attack, whereby, a legitimate data consumer > application may not be able to access some content from a content > provider or its OPES version. > > Since an OPES Flow may include non-OPES entities, it is susceptible > to man-in-the-middle attacks, whereby an intruder may inject bypass > instructions into the data path. These attacks may affect content > availability or disturb load balancing techniques in the network. > > The above threats can also arise by compromised OPES entities. An > intruder can compromise an OPES entities and then use > man-in-the-middle techniques to disturb content availability to a > data consumer application or overload a content provider server > (essentially, some form of a DoS attack). > > Attackers can use the bypass instruction to affect the overall > integrity of the OPES System. The ability to introduce bypass > instructions into a data flow may effect the accounting of the OPES > > > > Barbir Expires May 31, 2004 [Page 15] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > System. It may also affect the quality of content that is delivered > to the data consumer applications. Similar threats can arise from bad > implementations of the bypass facility. > > Inconsistent or selective bypass is also a threat. Here, one end can > try to bypass a subset of OPES entities so that the resulting content > is malformed and crashes or compromises entities that process that > content (and expect that content to be complete and valid). Such > exceptions are often not tested because implementers do not expect a > vital service to disappear from the processing loop. > > Other threats can arise from configuring access control policies for > OPES entities. It is possible that systems implementing access > controls via OPES entities may be incorrectly configured to honor > bypass and, hence, give unauthorized access to intruders. > > Tap bypass can also be a threat. This is because systems implementing > wiretaps via OPES entities may be incorrectly configured to honor > bypass and, hence, ignore (leave undetected) traffic with bypass > instructions that should have been tapped or logged. It is also > possible for one end to bypass services such as virus scanning at the > receiving end. This threat can be used by hackers to inject viruses > throughout the network. > > Other application level related security concerns can be found in > [8]. > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 16] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > Normative References > > [1] A. Barbir et al., "An Architecture for Open Pluggable Edge > Services (OPES)", Internet-Draft http://www.ietf.org/ > internet-drafts/draft-ietf-opes-architecture-04, December 2002. > > [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119, March 1997. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 17] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > Informative References > > [3] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", > Internet-Draft http://www.ietf.org/internet-drafts/ > draft-ietf-opes-scenarios-01.txt, August 2002. > > [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy > Considerations for Open Pluggable Edge Services", RFC 3238, > January 2002. > > [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., > Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- > HTTP/1.1", RFC 2616, June 1999. > > [6] A. Barbir et al., "Policy, Authorization and Enforcement > Requirements of OPES", Internet-Draft http://www.ietf.org/ > internet-drafts/draft-ietf-opes-authorization-02.txt, February > 2003. > > [7] Rousskov, A. et al, "HTTP adaptation with OPES", Internet-Draft > http://www.ietf.org/internet-drafts/draft-ietf-opes-http-01.txt, > October 2003. > > [8] A. Barbir et al., "Security Threats and Risks for Open Pluggable > Edge Services", Internet-Draft http://www.ietf.org/ > internet-drafts/draft-ietf-opes-threats-02.txt, February 2003. > > [9] A. Barbir et al., "OPES Treatment of IAB Considerations", > Internet-Draft http://www.ietf.org/internet-drafts/ > draft-ietf-opes-iab-03.txt, October 2003. > > > Author's Address > > Abbie Barbir > Nortel Networks > 3500 Carling Avenue > Nepean, Ontario K2H 8E9 > Canada > > Phone: +1 613 763 5229 > EMail: abbieb@nortelnetworks.com > > > > > > > > > > Barbir Expires May 31, 2004 [Page 18] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > Appendix A. Acknowledgements > > Several people has contributed to this work. Many thanks to: Alex > Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin > Stecher, Marshall Rose and Reinaldo Penno. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 19] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > > Barbir Expires May 31, 2004 [Page 20] > > Internet-Draft OPES entities and end points communication Dec. 2003 > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Barbir Expires May 31, 2004 [Page 21] > > From owner-ietf-openproxy@mail.imc.org Mon Dec 8 23:43:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27063 for ; Mon, 8 Dec 2003 23:43:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATZin-00002T-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 23:43:41 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATZin-00002P-00 for opes-archive@ietf.org; Mon, 08 Dec 2003 23:43:41 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9456ib002281 for ; Mon, 8 Dec 2003 20:05:06 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9456q0002280 for ietf-openproxy-bks; Mon, 8 Dec 2003 20:05:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9455ib002270 for ; Mon, 8 Dec 2003 20:05:05 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (sccrmhc11) with ESMTP id <2003120904050201100qtskge> (Authid: mhofmann); Tue, 9 Dec 2003 04:05:02 +0000 Message-ID: <3FD549F3.3020803@mhof.com> Date: Mon, 08 Dec 2003 23:05:07 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: OPES Boiler Plate Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, "external" reviewers pointed out that it's hard to follow how the various OPES documents play together. As such, we intend to add an "OPES Boiler Plate" to each of our WG documents, which guides the reader through the various documents. Bellow a strawman proposal for such boiler plate. If you have suggestions on how to improve it, please PROVIDE SPECIFIC TEXT rather then generic comments. Thanks, Markus =========================================== Overview of OPES documents The OPES Working Group has produced a series of documents that together provide a motivation and a description of the OPES architecture and the protocols being used therein. The document on "OPES Use Cases and Deployment Scenarios" [I-D.draft-ietf-opes-scenarios] describes a set of services and applications that are considered in scope for OPES and have been used as a motivation and guidance in designing the OPES architecture. The list of services and applications presented in this document is not exhaustive, additional services and applications beyond the ones presented in the document are expected to be deployed based on the OPES architecture. The OPES architecture itself is described in "An Architecture for Open Pluggable Edge Services (OPES)" [I-D.draft-ietf-opes-architecture]. The document also attempts to layout the core terminology used across the various OPES documents. The architecture document is augmented by the document on "Policy, Authorization and Enforcement Requirements of OPES" [I-D.draft-ietf-opes-authorization], which should not be seen as a specification of concrete authorization and enforcement methods, but rather outlines requirements and assumptions on the policy framework underlying OPES. The security threats and risks associated with OPES are investigated in "Security Threats and Risks for OPES" [I-D.draft-ietf-opes-threats]. The purpose of this document is to identify and discuss possible threats that arise from the nature of OPES, but it does not specify or recommend specific solutions. When the OPES WG was chartered, the IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework to be addressed by the WG. Rather then spreading the explanations for these consideration across the various OPES documents, the WG decided to produce a single document that collectively addresses all nine of the IAB considerations in one place. The document is named "OPES Treatment of IAB Considerations" [I-D.draft-ietf-opes-iab]. At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol. The requirements for such protocol are discussed in "Requirements for OPES Callout Protocols" [I-D.draft-ietf-opes-protocol-reqs]. The document on "OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03] finally specifies an application agnostic protocol core to be used for the communication between OPES processor and callout server, with generic tracing and bypass mechanisms defined in "OPES entities and end points communication" [I-D.draft-ietf-opes-end-comm-05]. The core document itself does not provide a complete protocol specification, but rather defines a common protocol framework that has to be complemented by application specific profiles. One of such profiles is specified in "HTTP adaptation with OPES" [I-D.draft-ietf-opes-http]. It specifies how application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES protocol core are to be used and augmented in order to support adaptation of HTTP messages. Additional profiles beyond HTTP are expected to be worked on in the future. Finally, the document on "P: Message Processing Language" [I-D.draft-ietf-opes-rules-p-02] defines a simple language for specifying message processing instructions at application proxies. It can be used to instruct OPES intermediaries how to manipulate application messages. For example, it can be used to tell an OPES processor which HTTP messages have to be forwarded to a callout server (via the OPES callout protocol) for performing a certain OPES service. From owner-ietf-openproxy@mail.imc.org Tue Dec 9 10:19:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29485 for ; Tue, 9 Dec 2003 10:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATjeC-0001Q9-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 10:19:36 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATjeB-0001Q4-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 10:19:36 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9F5sib004771 for ; Tue, 9 Dec 2003 07:05:54 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9F5sm9004770 for ietf-openproxy-bks; Tue, 9 Dec 2003 07:05:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9F5qib004763 for ; Tue, 9 Dec 2003 07:05:53 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hB9F5rsU035976 for ; Tue, 9 Dec 2003 10:05:53 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9F5k0C023715 for ; Tue, 9 Dec 2003 10:05:46 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9F5jMl010974 for ; Tue, 9 Dec 2003 10:05:45 -0500 (EST) Message-ID: <3FD5E504.3010701@mhof.com> Date: Tue, 09 Dec 2003 10:06:44 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P followup... References: <3FD059F7.423B555D@india.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > 1 Extend the above deadline. This is an admission > that the WG failed to schedule a deadline > correctly. This does not require AD/IESG review, > only WG chair action (AFAIK). This might be > blocked by an AD, but since we are delivering > on other deadlines, I think our AD can be > forgiving. How long an extension would we need? Are we talking days/weeks/months? -Markus From owner-ietf-openproxy@mail.imc.org Tue Dec 9 10:33:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00390 for ; Tue, 9 Dec 2003 10:33:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATjrl-0001kP-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 10:33:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATjrk-0001kL-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 10:33:36 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9FHwib005255 for ; Tue, 9 Dec 2003 07:17:58 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9FHw1t005254 for ietf-openproxy-bks; Tue, 9 Dec 2003 07:17:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9FHuib005246 for ; Tue, 9 Dec 2003 07:17:57 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hB9FHvxl018549 for ; Tue, 9 Dec 2003 10:17:57 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9FHoJl041807 for ; Tue, 9 Dec 2003 10:17:50 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9FHoMl011625 for ; Tue, 9 Dec 2003 10:17:50 -0500 (EST) Message-ID: <3FD5E7DA.1070208@mhof.com> Date: Tue, 09 Dec 2003 10:18:50 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P followup... References: <3FD059F7.423B555D@india.hp.com> In-Reply-To: <3FD059F7.423B555D@india.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Geetha Manjunath wrote: > I think we should leave this decision of 'what is available' to the > module writer. For example, in the case of HTTP, just knowing the > request header (plus a preview of some data) may be sufficient for major > decisions, however, for SMTP, we may need to look at the complete body > (for example to figure out whether it is a SPAM). IMHO, spam detection should *not* be implemented in form of a rule, but rather as an OPES service. In the example, there would be a rule that says something like "if email is for Markus, invoke the spam detection application", but the rule itself would *not* try to implement spam detection. Please let's be careful where to draw the line. My view is that we are *not* chartered to specify a general purpose processing/programming language, but a language for specifying rules that are used to described when certain actions are invoked (as opposed to encoding the action itself inside the rule) - the rules language has a very limited scope, which might be blurry and not always clear, but we should be sensitive about how far we want to go with the rules language. For my taste, for example, IRML had all the functionality required. We decided to drop IRML in favor of "P" not because of limited functionality, but because of syntax preferences. As such, maybe the functionality provided by IRML can be a guidance on what we need to build into "P" - whenever we feel more flexibility/functionality needs to be build in, we should very carefully discuss this. -Markus From owner-ietf-openproxy@mail.imc.org Tue Dec 9 11:31:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02648 for ; Tue, 9 Dec 2003 11:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkmN-0002ga-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 11:32:07 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATkmM-0002ex-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 11:32:06 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9G8Gib007497 for ; Tue, 9 Dec 2003 08:08:16 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9G8Glv007496 for ietf-openproxy-bks; Tue, 9 Dec 2003 08:08:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9G86ib007471 for ; Tue, 9 Dec 2003 08:08:06 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB9G7N411094; Tue, 9 Dec 2003 11:07:23 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 11:07:23 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407D6309A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: "'ietf-openproxy@imc.org'" , "Abbie Barbir" , "'Markus Hofmann'" , "'Marshall Rose'" Subject: draft-ietf-opes-threats-03 Date: Tue, 9 Dec 2003 11:07:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3BE6E.85206F62" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3BE6E.85206F62 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE6E.85206F62" ------_=_NextPart_001_01C3BE6E.85206F62 Content-Type: text/plain Please publish the following draft-ietf-opes-threats-03 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C3BE6E.85206F62 Content-Type: text/html draft-ietf-opes-threats-03

Please publish the following

draft-ietf-opes-threats-03

as a WG Draft.

Thanks
Abbie









  ------_=_NextPart_001_01C3BE6E.85206F62-- ------_=_NextPart_000_01C3BE6E.85206F62 Content-Type: text/plain; name="draft-ietf-opes-threats-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-threats-03.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: June 7, 2004 O. = Batuner Independent = consultant B. = Srinivas = Nokia M. = Hofmann Bell Labs/Lucent = Technologies H. = Orman Purple Streak = Development December 8, = 2003 Security Threats and Risks for OPES draft-ietf-opes-threats-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 7, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The document investigates the security threats associated with OPES. The effects of security threats on the underlying architecture are discussed. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. Barbir, et al. Expires June 7, 2004 [Page = 1] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . = 3 2. OPES Data Flow Threats . . . . . . . . . . . . . . . . . . = 5 2.1 OPES Flow Network Level Threats . . . . . . . . . . . . . = 6 2.1.1 Connection-Flow Denial-of-Service (DoS) . . . . . . . . . = 6 2.1.2 Threats to network robustness . . . . . . . . . . . . . . = 7 2.2 OPES Flow Application Level Threats . . . . . . . . . . . = 7 2.2.1 Unauthorized OPES entities . . . . . . . . . . . . . . . . = 7 2.2.2 Unauthorized actions of legitimate OPES entities . . . . . = 7 2.2.3 Unwanted content transformations . . . . . . . . . . . . . = 8 2.2.4 Corrupted content . . . . . . . . . . . . . . . . . . . . = 8 2.2.5 Threats to message structure integrity . . . . . . . . . . = 8 2.2.6 Granularity of protection . . . . . . . . . . . . . . . . = 9 2.2.7 Risks of hop-by-hop protection . . . . . . . . . . . . . . = 9 2.2.8 Threats to integrity of complex data . . . . . . . . . . . = 9 2.2.9 Denial of Service (DoS) . . . . . . . . . . . . . . . . . = 9 2.2.10 Tracing and notification information . . . . . . . . . . . = 10 2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . . = 10 3. Threats to out-of-band data . . . . . . . . . . . . . . . = 11 3.1 Threats that endanger the OPES data flow . . . . . . . . . = 11 3.2 Inaccurate Accounting Information . . . . . . . . . . . . = 11 3.3 OPES service request repudiation . . . . . . . . . . . . . = 12 3.4 Inconsistent privacy policy . . . . . . . . . . . . . . . = 12 3.5 Exposure of privacy preferences . . . . . . . . . . . . . = 12 3.6 Exposure of security settings . . . . . . . . . . . . . . = 12 3.7 Improper enforcement of privacy and security policy . . . = 13 3.8 DOS Attacks . . . . . . . . . . . . . . . . . . . . . . . = 13 4. Security Considerations . . . . . . . . . . . . . . . . . = 14 Normative References . . . . . . . . . . . . . . . . . . . = 15 Informative References . . . . . . . . . . . . . . . . . . = 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . = 16 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . = 18 Intellectual Property and Copyright Statements . . . . . . = 19 Barbir, et al. Expires June 7, 2004 [Page = 2] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The details = of the OPES architecture can be found in [1]. Security threats with respect to OPES can be viewed from different angles. There are security risks that affect content consumer applications, and those that affect the data provider applications. These threats affect the quality and integrity of data that the applications either produce or consume. On the other hand, the security risks can also be categorized into trust within the system (i.e. OPES service providers) and protection of the system from threats imposed by outsiders such as hackers and attackers. Insiders are those parties that are part of the OPES system. Outsiders are those entities that are not participating in the OPES system. It must be noted that not everyone in an OPES delivery path is equally trusted. Each OPES administrative trust domain must protect itself from all outsiders. Furthermore, it may have limited trust relationship with another OPES administrative domain for certain purposes. OPES service provide must use authentication as the basis for building trust relationships between administrative domains. Insiders can intentionally or unintentionally inflict harm and = damage on the data consumer and data provider applications. This can be through bad system configuration, execution of bad software or, if their networks are compromised, by inside or outside hackers. Depending on the deployment scenario, the trust within the OPES system is based on a set of transitive trust relationships between the data provider application, the OPES entities and the data consumer application. Threats to OPES entities can be at the OPES flow level and/or at the network level. In considering threats to the OPES system, the document will follow = a threat analysis model that identifies the threats from the perspective of how they will affect the data consumer and the data provider applications. The main goal of this document is threat discovery and analysis. = The Barbir, et al. Expires June 7, 2004 [Page = 3] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 document does not specify or recommend any solutions. It is important to mention that the OPES architecture has many similarities with other so called overlay networks, specifically web caches and content delivery networks (CDN) (see [2] , [4] ). This document focuses on threats that are introduced by the existence of the OPES processor and callout servers. Security threats specific to content services that do not use the OPES architecture are = considered out-of-scope of this document. However, this document can be used as input when considering security implications for web caches and = CDNs. The document is organized as follows: Section 2 discusses threats to OPES data flow on network and application level, section 3 discusses threats to other parts of the system and section 4 discusses = security considerations. Barbir, et al. Expires June 7, 2004 [Page = 4] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 2. OPES Data Flow Threats Threats to OPES data flow can affect the data consumer and data provider applications. At the OPES flow level, threats can occur at Policy Enforcement Points and Policy Decision Points [3] and along the OPES flow path where network elements are used to process the data. A serious problem is posed by the very fact that the OPES architecture is based on widely adopted protocols (HTTP is used as = an example). The architecture document specifically requires that "the presence of an OPES processor in the data request/response flow = SHALL NOT interfere with the operations of non-OPES aware clients and servers". This greatly facilitates OPES deployment but on the other hand a vast majority of clients (browsers) will not be able to exploit any safeguards added as base protocol extensions. For the usual data consumer, who might have questions such as (Where does this content come from? Can I get it another way? What is the difference? Is it legitimate?). Even if there are facilities and technical expertise present to pursue these questions, such thorough examination of each result is prohibitively expensive in terms of time and effort. OPES-aware content providers may try to protect themselves by adding verification scripts and special page structures. OPES-aware end users may use special tools. In all other cases (non-OPES aware clients and servers) protection will rely on monitoring services and investigation of occasionally discovered anomalies. An OPES system poses a special danger as a possible base for classical man-in-the-middle attacks. One of the reasons why such attacks are relatively rare is the difficulty in finding an appropriate base: a combination of a traffic interception point controlling a large flow of data and an application codebase running on a high-performance hardware with sufficient performance to analyze and possible modify all passing data. An OPES processor = meets this definition. This calls for special attention to protection measures at all levels of the system. Any compromise of an OPES processor or remote callout server can = have a ripple effect on the integrity of the affected OPES services = across all service providers that use the service. To mitigate this threat appropriate security procedures and tools (e.g., a firewall) should be applied. Specific threats can exist at the network level and at OPES data = flow level. Barbir, et al. Expires June 7, 2004 [Page = 5] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 2.1 OPES Flow Network Level Threats OPES processor and callout servers are susceptible to network level attacks from outsiders or from the networks of other OPES service providers (i.e. if the network of a contracted OPES service is compromised). The OPES architecture is based on common application protocols that do not provide strong guarantees of privacy, authentication, or integrity. The IAB considerations [4] require that the IP address of an OPES processor be accessible to data consumer applications at the IP addressing level. This requirement limit the ability of service providers of positioning the OPES processor behind firewalls and may exposes the OPES processor, including remote callout servers, to network level attacks. For example, the use of TCP/IP as network level protocol makes OPES processors subject to many known attacks, such as IP spoofing and session stealing. The OPES system is also susceptible to a number of security threats that are commonly associated with network infrastructure. These threats include snooping, denial of service, sabotage, vandalism, industrial espionage and theft of service. There are best practice solutions to mitigate network level threats. It is recommended that the security of the OPES entities at the network level be enhanced using known techniques and methods that minimize the risks of IP spoofing, snooping, denial of service and session stealing. At the OPES Flow level, connection-level security between the OPES processor and callout servers is an important consideration. For example, it is possible to spoof the OPES processor or the remote callout server. There are threats to data confidentiality between = the OPES processor and the remote callout server in an OPES flow. The next subsections covers possible DOS attack on OPES processor, remote callout server or data consumer application and network robustness. 2.1.1 Connection-Flow Denial-of-Service (DoS) OPES processors, or callout servers or data consumer applications = can be vulnerable to DOS attacks. DOS attacks can be of various types. One example of DOS attacks is the overloading of OPES processors or callout servers by spurious service requests issued by a malicious node, which denies the legal data traffic the necessary resources to render service. The resources include CPU cycles, memory, network interfaces, etc. A Denial-of-Service attack can be selective, Barbir, et al. Expires June 7, 2004 [Page = 6] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 generic or random in terms of which communication streams are affected. Distributed DoS is also possible when an attacker successfully directs multiple nodes over the network to initiate spurious service requests to an OPES processor(or callout server) simultaneously. 2.1.2 Threats to network robustness If OPES implementation does violate end-to-end addressing = principles, it could endanger the Internet infrastructure by complicating = routing and connection management. If it does not use flow-control principles for managing connections, or if it interferes with end-to-end flow control of connections that it did not originate, then it could cause Internet congestion. An implementation that violates the IAB requirement of explicit IP level addressing (for example by adding OPES functional capabilities to an interception proxy) may defeat some of the protective mechanisms and safeguards built into the OPES architecture. 2.2 OPES Flow Application Level Threats At the content level, threats to the OPES system can come from outsiders or insiders. The threat from outsiders is frequently intentional. Threats from insiders can be intentional or due to inappropriate implementations such as programming and configuration errors that result in bad system behavior. Application level problems and threats to the OPES systems are discussed below: 2.2.1 Unauthorized OPES entities Although one party authorization is mandated by the OPES architecture, such authorization occurs out-of-band. Discovering = the presence of an OPES entity and verifying authorization requires special actions and may present a problem. Adding notification and authorization information to the data messages (by using base protocol extensions) may help, especially if the data consumer's software is aware of such extensions. 2.2.2 Unauthorized actions of legitimate OPES entities According to the OPES architecture, the authorization is not tightly coupled with specific rules and procedures triggered by the rules. Even if a requirement to approve each particular rule and procedure Barbir, et al. Expires June 7, 2004 [Page = 7] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 was set, it looks at least impractical if not impossible to request such permission from the end user. The authorization is basically given for the class of transformations. The actual rules and triggered procedures may (maliciously or due to a programming error) perform actions that they are not authorized for. 2.2.3 Unwanted content transformations An authorized OPES service may perform actions that do not adhere to the expectations of the party that gave the authorization for the service. Examples may include ad flooding by a local ad insertion service or use of inappropriate policy by a content filtering service. On the other hand an OPES entity acting on behalf of one party may perform transformations that another party deems inappropriate. Examples may include replacing ads initially inserted by the content provider or applying filtering transformations that change the meaning of the text. 2.2.4 Corrupted content The OPES system may deliver outdated or otherwise distorted information due to programming problems or as a result of malicious attacks. For example, a compromised server, instead of performing OPES service, may inject bogus content. Such an action may be an act of cyber-vandalism (including virus injection) or intentional distribution of misleading information (such as manipulations with financial data). A compromised OPES server or malicious entity in the data flow may introduce changes specifically intended to cause improper actions in the OPES server or callout server. These changes may be in the message body, headers or both. This type of threat is discussed in more detail below. 2.2.5 Threats to message structure integrity An OPES server may add, remove or delete certain headers in a = request and/or response message (for example to implement additional privacy protection or assist in content filtering). Such changes may violate end-to-end integrity requirements or defeat services that use information provided in such headers (for example some local filtering services or reference-based services). Barbir, et al. Expires June 7, 2004 [Page = 8] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 2.2.6 Granularity of protection OPES services have implicit permission to modify content. However, the permissions generally apply only to portions of the content, for example, URL's between particular HTML tags, or text in headlines, = or URL's matching particular patterns. In order to express such policies, one must be able to refer to portions of messages and to detect modifications to message parts. Because there is currently very little support for policies that are expressed in terms of message parts, it will be difficult to attribute any particular modification to a particular OPES = processor, or to automatically detect policy violations. A fine-grained policy language should be devised, and it could be enforced using digital signatures. This would avoid the problems inherent in hop-by-hop data integrity measures (see next section). 2.2.7 Risks of hop-by-hop protection OPES services cannot be applied to data protected with end-to-end encryption methods because, by definition, the decryption key cannot be shared with OPES processors. This means that if the endpoint policies permit OPES services, the data must either be transmitted without confidentiality protections or an alternative model to end-to-end (hop-by-hop) encryption be developed. Extending the end-to-end encryption model is out of scope of this work. In this work security is end-to-end. OPES services cannot be performed if endpoints need security. 2.2.8 Threats to integrity of complex data The OPES system may violate data integrity by applying inconsistent transformations to interrelated data objects or references within = the data object. Problems may range from a broken reference structure (modified/missing targets, references to wrong locations or missing documents) to deliberate replacement/deletion/insertion of links = that violate intentions of the content provider. 2.2.9 Denial of Service (DoS) The data consumer application may not be able to access data if the OPES system fails for any reason. A malicious or malfunctioning node may be able to block all traffic. The data traffic destined for the OPES processor (or callout server) may not be able to use the services of the OPES device. The DoS may Barbir, et al. Expires June 7, 2004 [Page = 9] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 be achieved by preventing the data traffic from reaching the processor or the callout server. 2.2.10 Tracing and notification information Inadequate or vulnerable implementation of the tracing and notification mechanisms may defeat safeguards built into the OPES architecture. Tracing and notification facilities may become a target of malicious attack. Such an attack may create problems in discovering and stopping other attacks. The absence of a standard for tracing and notification information may present an additional problem. This information is produced and consumed by the independent entities (OPES servers/user agents/ content provider facilities). This calls for a set of standards related to each base protocol in use. 2.2.11 Unauthenticated Communication in OPES Flow There are risks and threats that could arise from unauthenticated communication between the OPES server and callout servers. Lack of use of strong authentication between OPES processors and callout servers may open security holes whereby DOS and other types of attacks (see sections [2 and 3]) can be performed. Barbir, et al. Expires June 7, 2004 [Page = 10] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 3. Threats to out-of-band data The OPES architecture separates a data flow from a control information flow (loading rulesets, trust establishment, tracing, policy propagation, etc.). There are certain requirements set for the latter but no specific mechanism is prescribed. This gives more flexibility for implementations but creates more burden for implementers and potential customers to ensure that each specific implementation meets all requirements for data security, entity authentication and action authorization. In addition to performing correct actions on the OPES data flow, any OPES implementation has to provide an adequate mechanism to satisfy requirements for out-of-band data and signaling information integrity. Whatever the specific mechanism may be, it inevitably becomes = subject to multiple security threats and possible attacks. The way the threats and attacks may be realized depends on implementation specifics but the resulting harm generally falls into two = categories: threats to OPES data flow and threats to data integrity. The specific threats are: 3.1 Threats that endanger the OPES data flow Any weakness in the implementation of a security, authentication, or authorization mechanism may open the door to the attacks described = in section 2. An OPES system implementation should address all these threats and prove its robustness and ability to withstand malicious attacks or networking and programming problems. 3.2 Inaccurate Accounting Information Collecting and reporting accurate accounting data may be vital when OPES servers are used to extend a business model of content = provider, service provider or as a basis for third party service. Ability to collect and process accounting data is an important part of OPES system functionality. This functionality may be challenged by distortion or destruction of base accounting data (usually logs), processed accounting data, accounting parameters and reporting configuration. As a result a data consumer may be inappropriately charged for viewing content that was not successfully delivered, or a content provider or independent OPES services provider may not be = compensated Barbir, et al. Expires June 7, 2004 [Page = 11] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 for the services performed. OPES system may use accounting information to distribute resources between different consumers or limit resource usage by a specific consumer. In this case an attack on accounting system (by distortion of data or issuing false configuration commands) may result in incorrect resource management and DoS by artificial resource starvation. 3.3 OPES service request repudiation An entity (producer or consumer) makes an authorized request and claim, later, that it did not make that request. As a result an OPES entity may be held liable for unauthorized changes to the data flow, or will be unable to receive compensation for a service. There should be a clear request that this service is required and there should be a clear course of action on the behalf of all parties. This action should have a request, and should have an action, and should have a means of repudiation of the request, and should have a means to specify the effect of the action. 3.4 Inconsistent privacy policy The OPES entities may have privacy policies that are not consistent with the data consumer application or content provider application. Privacy related problems may be further complicated if OPES = entities, content providers and end users belong to different jurisdictions with different requirements and different levels of legal = protection. As a result the end user may not be aware that he or she does not have the expected legal protection. The content provider may be exposed to legal risks due to a failure to comply with regulation which he is not even aware of. 3.5 Exposure of privacy preferences The OPES system may inadvertently or maliciously expose end user privacy settings and requirements. 3.6 Exposure of security settings There are risks that the OPES system may expose end user security settings when handling the request and responses. The user data must be handled as sensitive system information and protected against accidental and deliberate disclosure. Barbir, et al. Expires June 7, 2004 [Page = 12] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 3.7 Improper enforcement of privacy and security policy OPES entities are part of the content distribution system and as = such take on certain obligations to support security and privacy policies mandated by content producer and/or end user. However there is a danger that these policies are not properly implemented and = enforced. The data consumer application may not be aware that its protections are no longer in effect. There is also the possibility of security and privacy leaks due to the accidental misconfiguration or, due to missunderstanding what rules are in effect for a particular user or request. Privacy and security related parts of the systems can be targeted by malicious attacks and ability to withstand such attacks is of paramount importance. 3.8 DOS Attacks DOS attacks can be of various types. One type of DOS attacks can = take effect by overloading the client. For example, an intruder can = direct an OPES processor to issue numerous responses to a client. There is also additional DOS risk from a rule misconfiguration that would = have the OPES processor ignore a data consumer application. Barbir, et al. Expires June 7, 2004 [Page = 13] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 4. Security Considerations This document discusses multiple security and privacy issues related to the OPES services. Barbir, et al. Expires June 7, 2004 [Page = 14] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Normative References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04.txt, Aug 2002. [2] A. Barbir et. al, "OPES Use Cases and Deployment Scenarios", Internet-Draft: http://www.ietf.org/ draft-ietf-opes-scenarios-01, July 2002. [3] A. Barbir et. al, "Requirements for Policy, Authorization and Enforcement of OPES Services", Internet-Draft: http:// www.ietf.org/internet- drafts/ draft-ietf-opes-authorization-00.txt , October 2002. Barbir, et al. Expires June 7, 2004 [Page = 15] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Informative References [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Oskar Batuner Independent consultant EMail: batuner@attbi.com Bindignavile Srinivas Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: bindignavile.srinivas@nokia.com Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Barbir, et al. Expires June 7, 2004 [Page = 16] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Barbir, et al. Expires June 7, 2004 [Page = 17] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Appendix A. Acknowledgements Many thanks to T. Chan (Nokia) and A. Beck (Lucent) Barbir, et al. Expires June 7, 2004 [Page = 18] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir, et al. Expires June 7, 2004 [Page = 19] =0C Internet-Draft Security Threats and Risks for OPES December = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires June 7, 2004 [Page = 20] =0C ------_=_NextPart_000_01C3BE6E.85206F62-- From owner-ietf-openproxy@mail.imc.org Tue Dec 9 11:49:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03261 for ; Tue, 9 Dec 2003 11:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATl3Z-00030r-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 11:49:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATl3Y-00030k-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 11:49:52 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Gd6ib009110 for ; Tue, 9 Dec 2003 08:39:06 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9Gd6uw009109 for ietf-openproxy-bks; Tue, 9 Dec 2003 08:39:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Gd4ib009104 for ; Tue, 9 Dec 2003 08:39:05 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hB9Gd5sU036803 for ; Tue, 9 Dec 2003 11:39:05 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9GcxJl048699 for ; Tue, 9 Dec 2003 11:38:59 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9GcwMl014339 for ; Tue, 9 Dec 2003 11:38:58 -0500 (EST) Message-ID: <3FD5FADE.20402@mhof.com> Date: Tue, 09 Dec 2003 11:39:58 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ietf-openproxy@imc.org'" Subject: Re: draft-ietf-opes-threats-03 References: <87609AFB433BD5118D5E0002A52CD75407D6309A@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407D6309A@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, this updated version of the draft addresses issues in Section 2.2.7 that came back from IESG review. The section has been re-written to clarify that - for now - the OPES work assumes either no encryption (in which case OPES services can be performed) or end-to-end encryption (in which case no OPES services can be performed). If encryption would be desired hop-by-hop, an appropriate model will have to be developed. We'll re-submit this version to the IESG. Thanks, Markus Abbie Barbir wrote: > Please publish the following > > draft-ietf-opes-threats-03 > > as a WG Draft. > > Thanks > Abbie From owner-ietf-openproxy@mail.imc.org Tue Dec 9 12:24:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04208 for ; Tue, 9 Dec 2003 12:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlbB-0003Zy-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:24:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATlbB-0003Zv-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:24:37 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9H2pib009965 for ; Tue, 9 Dec 2003 09:02:51 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9H2pAv009964 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:02:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9H2oib009959 for ; Tue, 9 Dec 2003 09:02:50 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9H2pGh055744; Tue, 9 Dec 2003 10:02:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9H2p1u055743; Tue, 9 Dec 2003 10:02:51 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 10:02:51 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: "'ietf-openproxy@imc.org'" Subject: Re: draft-ietf-opes-threats-03 In-Reply-To: <3FD5FADE.20402@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407D6309A@zcard0k6.ca.nortel.com> <3FD5FADE.20402@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus, I am somewhat surprised there is something special that needs to be developed for a hop-by-hop encryption model, but I do not know what IESG had to say about this issue (beyond a cryptic statement on the ID tracker). If IESG turns this revision around again, let's discuss how we can document hop-by-hop encryption to address IESG concerns. Thanks, Alex. On Tue, 9 Dec 2003, Markus Hofmann wrote: > > Folks, > > this updated version of the draft addresses issues in Section 2.2.7 > that came back from IESG review. > > The section has been re-written to clarify that - for now - the OPES > work assumes either no encryption (in which case OPES services can be > performed) or end-to-end encryption (in which case no OPES services > can be performed). If encryption would be desired hop-by-hop, an > appropriate model will have to be developed. > > We'll re-submit this version to the IESG. > > Thanks, > Markus > > > Abbie Barbir wrote: > > > Please publish the following > > > > draft-ietf-opes-threats-03 > > > > as a WG Draft. > > > > Thanks > > Abbie > > From owner-ietf-openproxy@mail.imc.org Tue Dec 9 12:31:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04411 for ; Tue, 9 Dec 2003 12:31:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATliQ-0003gE-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:32:06 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATliQ-0003gB-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:32:06 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HAxib010239 for ; Tue, 9 Dec 2003 09:10:59 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HAxjL010238 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:10:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HAwib010233 for ; Tue, 9 Dec 2003 09:10:58 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9HAxGh055951; Tue, 9 Dec 2003 10:10:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9HAxKC055950; Tue, 9 Dec 2003 10:10:59 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 10:10:59 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: P followup... In-Reply-To: <3FD5E504.3010701@mhof.com> Message-ID: References: <3FD059F7.423B555D@india.hp.com> <3FD5E504.3010701@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 9 Dec 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > 1 Extend the above deadline. This is an admission > > that the WG failed to schedule a deadline > > correctly. This does not require AD/IESG review, > > only WG chair action (AFAIK). This might be > > blocked by an AD, but since we are delivering > > on other deadlines, I think our AD can be > > forgiving. > > How long an extension would we need? Are we talking days/weeks/months? IMO, this deadline extension discussion should be a part of the rechartering discussion. As of now, it is not clear enough (to me) what P-related activities are in the OPES WG future. Once we know what we want to do with P, we can scope the P draft better, and decide on the deadline. If I have to guess now, I would say that we need weeks worth of extension with 20% probability and months worth of extension with 80% probability. Again, this will depend on future P work which we still have to agree on. Do we have to decide on this deadline before rechartering? If yes, can we bump the deadline by some "large enough" number of months (say 6) and then provide a more accurate milestone in the new charter? Alex. From owner-ietf-openproxy@mail.imc.org Tue Dec 9 12:36:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04541 for ; Tue, 9 Dec 2003 12:36:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlmx-0003l8-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:36:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATlmm-0003l0-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 12:36:36 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HOqib010760 for ; Tue, 9 Dec 2003 09:24:52 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HOq99010759 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:24:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HOpib010753 for ; Tue, 9 Dec 2003 09:24:51 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9HOqGh056538; Tue, 9 Dec 2003 10:24:52 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9HOqTE056537; Tue, 9 Dec 2003 10:24:52 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 10:24:52 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: P followup... In-Reply-To: <3FD5E7DA.1070208@mhof.com> Message-ID: References: <3FD059F7.423B555D@india.hp.com> <3FD5E7DA.1070208@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 9 Dec 2003, Markus Hofmann wrote: > IMHO, spam detection should *not* be implemented in form of a rule, > but rather as an OPES service. If OPES service invocation is indistinguishable from a P module call, then the above point becomes unimportant from P point of view. We simply do not have to decide at P Core level (which is good). I believe that the discussion with Andre concluded that making service invocation indistinguishable from a P module call is the right way to go. > In the example, there would be a rule that says something like "if > email is for Markus, invoke the spam detection application", but the > rule itself would *not* try to implement spam detection. IMO, the line here is too thin to define: if (msg.from() contains "Markus") { callSpamDetectionService(msg); } versus if (msg.from() contains "KnownSpammer") { callMsgBlockingService(msg); } both rules implement a portion of spam handling algorithm. Both are equivalent from P Core point of view, IMO. > Please let's be careful where to draw the line. My view is that we > are *not* chartered to specify a general purpose > processing/programming language, but a language for specifying rules > that are used to described when certain actions are invoked (as > opposed to encoding the action itself inside the rule) I agree. The action itself is hidden in a P call, which can be a callout service with a P interface or an internal service with a P interface. The latter is particularly indistinguishable from anything else a P module provides. > - the rules language has a very limited scope, which might be blurry > and not always clear, but we should be sensitive about how far we > want to go with the rules language. The scope is indeed one of the most difficult/important questions here. It may seem simple on the surface (as usual), but scope effects become crucial once we start to dig deeper. We have already seen that with OPES Communications, OCP Core, and HTTP Adaptations drafts! In fact, my current inability to estimate P draft completion date is a result about poorly defined scope. With the renewed interest in P, and several "grand ideas" related to P, I am no longer certain that current P draft has the right scope. Hence, I do not know the amount of work that remains to be done. Alex. P.S. > For my taste, for example, IRML had all the functionality required. IRML had _more_ functionality than we required, IMO. > We decided to drop IRML in favor of "P" not because of limited > functionality, but because of syntax preferences. Here I violently disagree, but it is not important for now :-). From de791wnk@netscape.net Tue Dec 9 12:46:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05124; Tue, 9 Dec 2003 12:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATlwI-00042m-00; Tue, 09 Dec 2003 12:46:26 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ATlwI-00042j-00; Tue, 09 Dec 2003 12:46:26 -0500 Received: from pcp04478010pcs.midltn01.ct.comcast.net ([68.63.147.110]) by manatick with smtp (Exim 4.24) id 1ATlwI-0004dX-Ei; Tue, 09 Dec 2003 12:46:26 -0500 Received: from [160.75.86.87] by pcp04478010pcs.midltn01.ct.comcast.net; Tue, 09 Dec 2003 16:41:19 -0100 Message-ID: From: "Michele Kerns" Reply-To: "Michele Kerns" To: idr@ietf.org Subject: Due Payment, account Date: Tue, 09 Dec 03 16:41:19 GMT X-Mailer: Microsoft Outlook Express 5.00.2919.6700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FED08EE._45." X-Priority: 3 X-MSMail-Priority: Normal --FED08EE._45. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


onskgpk g vtiddyrl enfptcuctprbpkyw --FED08EE._45.-- From owner-ietf-openproxy@mail.imc.org Tue Dec 9 13:02:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05962 for ; Tue, 9 Dec 2003 13:02:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATmC5-0004V0-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:02:45 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATmC4-0004Ux-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:02:45 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HkRib011709 for ; Tue, 9 Dec 2003 09:46:27 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HkRAB011708 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:46:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HkQib011702 for ; Tue, 9 Dec 2003 09:46:26 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB9HkB429488; Tue, 9 Dec 2003 12:46:11 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 12:46:11 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407DCF007@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , Markus Hofmann Cc: "'ietf-openproxy@imc.org'" Subject: RE: draft-ietf-opes-threats-03 Date: Tue, 9 Dec 2003 12:46:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE7C.5504C928" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BE7C.5504C928 Content-Type: text/plain Alex, U need to recharter first. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, December 09, 2003 12:03 PM > To: Markus Hofmann > Cc: 'ietf-openproxy@imc.org' > Subject: Re: draft-ietf-opes-threats-03 > > > > Markus, > > I am somewhat surprised there is something special that > needs to be developed for a hop-by-hop encryption model, but > I do not know what IESG had to say about this issue (beyond a > cryptic statement on the ID tracker). If IESG turns this > revision around again, let's discuss how we can document > hop-by-hop encryption to address IESG concerns. > > Thanks, > > Alex. > > On Tue, 9 Dec 2003, Markus Hofmann wrote: > > > > > Folks, > > > > this updated version of the draft addresses issues in Section 2.2.7 > > that came back from IESG review. > > > > The section has been re-written to clarify that - for now - > the OPES > > work assumes either no encryption (in which case OPES > services can be > > performed) or end-to-end encryption (in which case no OPES services > > can be performed). If encryption would be desired hop-by-hop, an > > appropriate model will have to be developed. > > > > We'll re-submit this version to the IESG. > > > > Thanks, > > Markus > > > > > > Abbie Barbir wrote: > > > > > Please publish the following > > > > > > draft-ietf-opes-threats-03 > > > > > > as a WG Draft. > > > > > > Thanks > > > Abbie > > > > > ------_=_NextPart_001_01C3BE7C.5504C928 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-opes-threats-03

Alex,

U need to recharter first.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, December 09, 2003 12:03 = PM
> To: Markus Hofmann
> Cc: 'ietf-openproxy@imc.org'
> Subject: Re: draft-ietf-opes-threats-03
>
>
>
> Markus,
>
>       I am somewhat = surprised there is something special that
> needs to be developed for a hop-by-hop = encryption model, but
> I do not know what IESG had to say about this = issue (beyond a
> cryptic statement on the ID tracker). If IESG = turns this
> revision around again, let's discuss how we can = document
> hop-by-hop encryption to address IESG = concerns.
>
> Thanks,
>
> Alex.
>
> On Tue, 9 Dec 2003, Markus Hofmann = wrote:
>
> >
> > Folks,
> >
> > this updated version of the draft = addresses issues in Section 2.2.7
> > that came back from IESG review.
> >
> > The section has been re-written to clarify = that - for now -
> the OPES
> > work assumes either no encryption (in = which case OPES
> services can be
> > performed) or end-to-end encryption (in = which case no OPES services
> > can be performed). If encryption would be = desired hop-by-hop, an
> > appropriate model will have to be = developed.
> >
> > We'll re-submit this version to the = IESG.
> >
> > Thanks,
> >    Markus
> >
> >
> > Abbie Barbir wrote:
> >
> > > Please publish the following
> > >
> > > draft-ietf-opes-threats-03
> > >
> > > as a WG Draft.
> > >
> > > Thanks
> > > Abbie
> >
> >
>

------_=_NextPart_001_01C3BE7C.5504C928-- From owner-ietf-openproxy@mail.imc.org Tue Dec 9 13:04:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06028 for ; Tue, 9 Dec 2003 13:04:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATmDc-0004WP-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:04:20 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATmDb-0004WM-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:04:19 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HpHib012098 for ; Tue, 9 Dec 2003 09:51:17 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HpHP2012097 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:51:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HpGib012091 for ; Tue, 9 Dec 2003 09:51:16 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9HpHGh057737; Tue, 9 Dec 2003 10:51:17 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9HpHsm057736; Tue, 9 Dec 2003 10:51:17 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 10:51:17 -0700 (MST) From: Alex Rousskov To: Abbie Barbir cc: Markus Hofmann , "'ietf-openproxy@imc.org'" Subject: RE: draft-ietf-opes-threats-03 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407DCF007@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCF007@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 9 Dec 2003, Abbie Barbir wrote: > U need to recharter first. Not if we are addressing current IESG concerns about an existing WG document with a couple of paragraphs, I guess. I am not proposing any new "real work" in this direction. Alex. > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, December 09, 2003 12:03 PM > > To: Markus Hofmann > > Cc: 'ietf-openproxy@imc.org' > > Subject: Re: draft-ietf-opes-threats-03 > > > > > > > > Markus, > > > > I am somewhat surprised there is something special that > > needs to be developed for a hop-by-hop encryption model, but > > I do not know what IESG had to say about this issue (beyond a > > cryptic statement on the ID tracker). If IESG turns this > > revision around again, let's discuss how we can document > > hop-by-hop encryption to address IESG concerns. > > > > Thanks, > > > > Alex. > > > > On Tue, 9 Dec 2003, Markus Hofmann wrote: > > > > > > > > Folks, > > > > > > this updated version of the draft addresses issues in Section 2.2.7 > > > that came back from IESG review. > > > > > > The section has been re-written to clarify that - for now - > > the OPES > > > work assumes either no encryption (in which case OPES > > services can be > > > performed) or end-to-end encryption (in which case no OPES services > > > can be performed). If encryption would be desired hop-by-hop, an > > > appropriate model will have to be developed. > > > > > > We'll re-submit this version to the IESG. > > > > > > Thanks, > > > Markus > > > > > > > > > Abbie Barbir wrote: > > > > > > > Please publish the following > > > > > > > > draft-ietf-opes-threats-03 > > > > > > > > as a WG Draft. > > > > > > > > Thanks > > > > Abbie > > > > > > > > > From owner-ietf-openproxy@mail.imc.org Tue Dec 9 13:04:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06044 for ; Tue, 9 Dec 2003 13:04:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATmEL-0004Wd-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:05:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATmEK-0004Wa-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:05:04 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HtPib012236 for ; Tue, 9 Dec 2003 09:55:25 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9HtPKn012235 for ietf-openproxy-bks; Tue, 9 Dec 2003 09:55:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9HtMib012225 for ; Tue, 9 Dec 2003 09:55:24 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB9Ht8x06055; Tue, 9 Dec 2003 12:55:09 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 12:55:09 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407DCF039@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov Cc: Markus Hofmann , "'ietf-openproxy@imc.org'" Subject: RE: draft-ietf-opes-threats-03 Date: Tue, 9 Dec 2003 12:55:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE7D.93668FAC" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BE7D.93668FAC Content-Type: text/plain Alex, u really need to recharter if u want to address current concerns. They are complaining about bad certificates. Basically, we can not (OPES) be in the way without comming up with a new model. Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Tuesday, December 09, 2003 12:51 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: Markus Hofmann; 'ietf-openproxy@imc.org' > Subject: RE: draft-ietf-opes-threats-03 > > > On Tue, 9 Dec 2003, Abbie Barbir wrote: > > > U need to recharter first. > > Not if we are addressing current IESG concerns about an > existing WG document with a couple of paragraphs, I guess. I > am not proposing any new "real work" in this direction. > > Alex. > > > > -----Original Message----- > > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > > Sent: Tuesday, December 09, 2003 12:03 PM > > > To: Markus Hofmann > > > Cc: 'ietf-openproxy@imc.org' > > > Subject: Re: draft-ietf-opes-threats-03 > > > > > > > > > > > > Markus, > > > > > > I am somewhat surprised there is something special that > needs to be > > > developed for a hop-by-hop encryption model, but I do not > know what > > > IESG had to say about this issue (beyond a cryptic > statement on the > > > ID tracker). If IESG turns this revision around again, > let's discuss > > > how we can document hop-by-hop encryption to address IESG > concerns. > > > > > > Thanks, > > > > > > Alex. > > > > > > On Tue, 9 Dec 2003, Markus Hofmann wrote: > > > > > > > > > > > Folks, > > > > > > > > this updated version of the draft addresses issues in Section > > > > 2.2.7 that came back from IESG review. > > > > > > > > The section has been re-written to clarify that - for now - > > > the OPES > > > > work assumes either no encryption (in which case OPES > > > services can be > > > > performed) or end-to-end encryption (in which case no OPES > > > > services can be performed). If encryption would be desired > > > > hop-by-hop, an appropriate model will have to be developed. > > > > > > > > We'll re-submit this version to the IESG. > > > > > > > > Thanks, > > > > Markus > > > > > > > > > > > > Abbie Barbir wrote: > > > > > > > > > Please publish the following > > > > > > > > > > draft-ietf-opes-threats-03 > > > > > > > > > > as a WG Draft. > > > > > > > > > > Thanks > > > > > Abbie > > > > > > > > > > > > > > ------_=_NextPart_001_01C3BE7D.93668FAC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-opes-threats-03

Alex,

u really need to recharter if u want to address = current concerns.

They are complaining about bad certificates.

Basically, we can not (OPES) be in the way without = comming up with a new model.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Tuesday, December 09, 2003 12:51 = PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: Markus Hofmann; = 'ietf-openproxy@imc.org'
> Subject: RE: draft-ietf-opes-threats-03
>
>
> On Tue, 9 Dec 2003, Abbie Barbir wrote:
>
> > U need to recharter first.
>
> Not if we are addressing current IESG concerns = about an
> existing WG document with a couple of = paragraphs, I guess. I
> am not proposing any new "real work" = in this direction.
>
> Alex.
>
> > > -----Original Message-----
> > > From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> > > Sent: Tuesday, December 09, 2003 = 12:03 PM
> > > To: Markus Hofmann
> > > Cc: 'ietf-openproxy@imc.org'
> > > Subject: Re: = draft-ietf-opes-threats-03
> > >
> > >
> > >
> > > Markus,
> > >
> > >   I am somewhat surprised there = is something special that
> needs to be
> > > developed for a hop-by-hop encryption = model, but I do not
> know what
> > > IESG had to say about this issue = (beyond a cryptic
> statement on the
> > > ID tracker). If IESG turns this = revision around again,
> let's discuss
> > > how we can document hop-by-hop = encryption to address IESG
> concerns.
> > >
> > > Thanks,
> > >
> > > Alex.
> > >
> > > On Tue, 9 Dec 2003, Markus Hofmann = wrote:
> > >
> > > >
> > > > Folks,
> > > >
> > > > this updated version of the = draft addresses issues in Section
> > > > 2.2.7 that came back from IESG = review.
> > > >
> > > > The section has been re-written = to clarify that - for now -
> > > the OPES
> > > > work assumes either no = encryption (in which case OPES
> > > services can be
> > > > performed) or end-to-end = encryption (in which case no OPES
> > > > services can be performed). If = encryption would be desired
> > > > hop-by-hop, an appropriate model = will have to be developed.
> > > >
> > > > We'll re-submit this version to = the IESG.
> > > >
> > > > Thanks,
> > > >    Markus
> > > >
> > > >
> > > > Abbie Barbir wrote:
> > > >
> > > > > Please publish the = following
> > > > >
> > > > > = draft-ietf-opes-threats-03
> > > > >
> > > > > as a WG Draft.
> > > > >
> > > > > Thanks
> > > > > Abbie
> > > >
> > > >
> > >
> >
>

------_=_NextPart_001_01C3BE7D.93668FAC-- From owner-ietf-openproxy@mail.imc.org Tue Dec 9 13:26:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06663 for ; Tue, 9 Dec 2003 13:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATmZ5-0004rZ-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:26:31 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATmZ5-0004rV-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 13:26:31 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9IAhib013242 for ; Tue, 9 Dec 2003 10:10:43 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9IAhNL013241 for ietf-openproxy-bks; Tue, 9 Dec 2003 10:10:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9IAeib013234 for ; Tue, 9 Dec 2003 10:10:41 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9IAgGh058356; Tue, 9 Dec 2003 11:10:42 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9IAghC058355; Tue, 9 Dec 2003 11:10:42 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 11:10:42 -0700 (MST) From: Alex Rousskov To: Abbie Barbir cc: Markus Hofmann , "'ietf-openproxy@imc.org'" Subject: RE: draft-ietf-opes-threats-03 In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407DCF039@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCF039@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 9 Dec 2003, Abbie Barbir wrote: > u really need to recharter if u want to address current concerns. Not if they are concerns can be addressed with clarifications, without new development. > They are complaining about bad certificates. From the note on ID tracker, IESG seems to be concerned about one possible way to implement hop-by-hop encryption. We can show other, cleaner, existing ways. > Basically, we can not (OPES) be in the way without comming up with a > new model. I disagree. There are existing alternatives (even deployed systems, but that info may not be public) that we can point to. Alex. > > -----Original Message----- > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > Sent: Tuesday, December 09, 2003 12:51 PM > > To: Barbir, Abbie [CAR:1A11:EXCH] > > Cc: Markus Hofmann; 'ietf-openproxy@imc.org' > > Subject: RE: draft-ietf-opes-threats-03 > > > > > > On Tue, 9 Dec 2003, Abbie Barbir wrote: > > > > > U need to recharter first. > > > > Not if we are addressing current IESG concerns about an > > existing WG document with a couple of paragraphs, I guess. I > > am not proposing any new "real work" in this direction. > > > > Alex. > > > > > > -----Original Message----- > > > > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > > > > Sent: Tuesday, December 09, 2003 12:03 PM > > > > To: Markus Hofmann > > > > Cc: 'ietf-openproxy@imc.org' > > > > Subject: Re: draft-ietf-opes-threats-03 > > > > > > > > > > > > > > > > Markus, > > > > > > > > I am somewhat surprised there is something special that > > needs to be > > > > developed for a hop-by-hop encryption model, but I do not > > know what > > > > IESG had to say about this issue (beyond a cryptic > > statement on the > > > > ID tracker). If IESG turns this revision around again, > > let's discuss > > > > how we can document hop-by-hop encryption to address IESG > > concerns. > > > > > > > > Thanks, > > > > > > > > Alex. > > > > > > > > On Tue, 9 Dec 2003, Markus Hofmann wrote: > > > > > > > > > > > > > > Folks, > > > > > > > > > > this updated version of the draft addresses issues in Section > > > > > 2.2.7 that came back from IESG review. > > > > > > > > > > The section has been re-written to clarify that - for now - > > > > the OPES > > > > > work assumes either no encryption (in which case OPES > > > > services can be > > > > > performed) or end-to-end encryption (in which case no OPES > > > > > services can be performed). If encryption would be desired > > > > > hop-by-hop, an appropriate model will have to be developed. > > > > > > > > > > We'll re-submit this version to the IESG. > > > > > > > > > > Thanks, > > > > > Markus > > > > > > > > > > > > > > > Abbie Barbir wrote: > > > > > > > > > > > Please publish the following > > > > > > > > > > > > draft-ietf-opes-threats-03 > > > > > > > > > > > > as a WG Draft. > > > > > > > > > > > > Thanks > > > > > > Abbie > > > > > > > > > > > > > > > > > > > > From owner-ietf-openproxy@mail.imc.org Tue Dec 9 16:14:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17657 for ; Tue, 9 Dec 2003 16:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATpBt-000111-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 16:14:45 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATpBs-00010s-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 16:14:44 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Kdwib021023 for ; Tue, 9 Dec 2003 12:39:58 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9KdvqW021022 for ietf-openproxy-bks; Tue, 9 Dec 2003 12:39:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Kdsib021016 for ; Tue, 9 Dec 2003 12:39:57 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14727; Tue, 9 Dec 2003 15:39:40 -0500 (EST) Message-Id: <200312092039.PAA14727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-end-comm-06.txt Date: Tue, 09 Dec 2003 15:39:40 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES entities and end points communication Author(s) : A. Barbir Filename : draft-ietf-opes-end-comm-06.txt Pages : 21 Date : 2003-12-9 This memo documents tracing requirements for Open Pluggable Edge Services (OPES) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-end-comm-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-end-comm-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-end-comm-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-9160110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-end-comm-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-end-comm-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-9160110.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Tue Dec 9 16:43:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18644 for ; Tue, 9 Dec 2003 16:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATpda-0001N2-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 16:43:22 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATpdZ-0001Mv-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 16:43:21 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9LLEib023066 for ; Tue, 9 Dec 2003 13:21:14 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9LLExh023065 for ietf-openproxy-bks; Tue, 9 Dec 2003 13:21:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9LLDib023059 for ; Tue, 9 Dec 2003 13:21:13 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hB9LLEsU038975 for ; Tue, 9 Dec 2003 16:21:14 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9LL80C053934 for ; Tue, 9 Dec 2003 16:21:08 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hB9LL7Ml021370 for ; Tue, 9 Dec 2003 16:21:07 -0500 (EST) Message-ID: <3FD63CFF.3090304@mhof.com> Date: Tue, 09 Dec 2003 16:22:07 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ietf-openproxy@imc.org'" Subject: Re: draft-ietf-opes-threats-03 References: <87609AFB433BD5118D5E0002A52CD75407DCF039@zcard0k6.ca.nortel.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, we put in a clarification that has been OKed by the reviewer, so the document can move on. It also provides the opportunity to come back to the issue of hop-by-hop encryption in a way that will give us enough time to carefully address it. So, let's wrap this up and focus on the currently open and active documents to get them out. Once this happens, we can talk about possible re-chartering and work items we want to take on. Thanks, Markus Alex Rousskov wrote: > On Tue, 9 Dec 2003, Abbie Barbir wrote: > > >>u really need to recharter if u want to address current concerns. > > > Not if they are concerns can be addressed with clarifications, without > new development. > > >>They are complaining about bad certificates. > > > From the note on ID tracker, IESG seems to be concerned about one > possible way to implement hop-by-hop encryption. We can show other, > cleaner, existing ways. > > >>Basically, we can not (OPES) be in the way without comming up with a >>new model. > > > I disagree. There are existing alternatives (even deployed systems, > but that info may not be public) that we can point to. > > Alex. > > > >>>-----Original Message----- >>>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] >>>Sent: Tuesday, December 09, 2003 12:51 PM >>>To: Barbir, Abbie [CAR:1A11:EXCH] >>>Cc: Markus Hofmann; 'ietf-openproxy@imc.org' >>>Subject: RE: draft-ietf-opes-threats-03 >>> >>> >>>On Tue, 9 Dec 2003, Abbie Barbir wrote: >>> >>> >>>>U need to recharter first. >>> >>>Not if we are addressing current IESG concerns about an >>>existing WG document with a couple of paragraphs, I guess. I >>>am not proposing any new "real work" in this direction. >>> >>>Alex. >>> >>> >>>>>-----Original Message----- >>>>>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] >>>>>Sent: Tuesday, December 09, 2003 12:03 PM >>>>>To: Markus Hofmann >>>>>Cc: 'ietf-openproxy@imc.org' >>>>>Subject: Re: draft-ietf-opes-threats-03 >>>>> >>>>> >>>>> >>>>>Markus, >>>>> >>>>> I am somewhat surprised there is something special that >>> >>>needs to be >>> >>>>>developed for a hop-by-hop encryption model, but I do not >>> >>>know what >>> >>>>>IESG had to say about this issue (beyond a cryptic >>> >>>statement on the >>> >>>>>ID tracker). If IESG turns this revision around again, >>> >>>let's discuss >>> >>>>>how we can document hop-by-hop encryption to address IESG >>> >>>concerns. >>> >>>>>Thanks, >>>>> >>>>>Alex. >>>>> >>>>>On Tue, 9 Dec 2003, Markus Hofmann wrote: >>>>> >>>>> >>>>>>Folks, >>>>>> >>>>>>this updated version of the draft addresses issues in Section >>>>>>2.2.7 that came back from IESG review. >>>>>> >>>>>>The section has been re-written to clarify that - for now - >>>>> >>>>>the OPES >>>>> >>>>>>work assumes either no encryption (in which case OPES >>>>> >>>>>services can be >>>>> >>>>>>performed) or end-to-end encryption (in which case no OPES >>>>>>services can be performed). If encryption would be desired >>>>>>hop-by-hop, an appropriate model will have to be developed. >>>>>> >>>>>>We'll re-submit this version to the IESG. >>>>>> >>>>>>Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>>Abbie Barbir wrote: >>>>>> >>>>>> >>>>>>>Please publish the following >>>>>>> >>>>>>>draft-ietf-opes-threats-03 >>>>>>> >>>>>>>as a WG Draft. >>>>>>> >>>>>>>Thanks >>>>>>>Abbie >>>>>> >>>>>> From owner-ietf-openproxy@mail.imc.org Tue Dec 9 17:51:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21580 for ; Tue, 9 Dec 2003 17:51:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATqhe-0002qG-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 17:51:38 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATqhe-0002qD-00 for opes-archive@ietf.org; Tue, 09 Dec 2003 17:51:38 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9MNTib026053 for ; Tue, 9 Dec 2003 14:23:29 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB9MNTuT026052 for ietf-openproxy-bks; Tue, 9 Dec 2003 14:23:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9MNSib026044 for ; Tue, 9 Dec 2003 14:23:28 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hB9MNUGh070697; Tue, 9 Dec 2003 15:23:30 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hB9MNUTe070696; Tue, 9 Dec 2003 15:23:30 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Dec 2003 15:23:30 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: "'ietf-openproxy@imc.org'" Subject: Re: draft-ietf-opes-threats-03 In-Reply-To: <3FD63CFF.3090304@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCF039@zcard0k6.ca.nortel.com> <3FD63CFF.3090304@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Agreed! Please note that I said "If IESG turns this revision around again, ..." in my first e-mail. Thus, if IESG is fine with the current wording, my e-mail should be ignored. Alex. On Tue, 9 Dec 2003, Markus Hofmann wrote: > > Folks, > > we put in a clarification that has been OKed by the reviewer, so the > document can move on. It also provides the opportunity to come back to > the issue of hop-by-hop encryption in a way that will give us enough > time to carefully address it. > > So, let's wrap this up and focus on the currently open and active > documents to get them out. Once this happens, we can talk about > possible re-chartering and work items we want to take on. > > Thanks, > Markus > > Alex Rousskov wrote: > > > On Tue, 9 Dec 2003, Abbie Barbir wrote: > > > > > >>u really need to recharter if u want to address current concerns. > > > > > > Not if they are concerns can be addressed with clarifications, without > > new development. > > > > > >>They are complaining about bad certificates. > > > > > > From the note on ID tracker, IESG seems to be concerned about one > > possible way to implement hop-by-hop encryption. We can show other, > > cleaner, existing ways. > > > > > >>Basically, we can not (OPES) be in the way without comming up with a > >>new model. > > > > > > I disagree. There are existing alternatives (even deployed systems, > > but that info may not be public) that we can point to. > > > > Alex. > > > > > > > >>>-----Original Message----- > >>>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > >>>Sent: Tuesday, December 09, 2003 12:51 PM > >>>To: Barbir, Abbie [CAR:1A11:EXCH] > >>>Cc: Markus Hofmann; 'ietf-openproxy@imc.org' > >>>Subject: RE: draft-ietf-opes-threats-03 > >>> > >>> > >>>On Tue, 9 Dec 2003, Abbie Barbir wrote: > >>> > >>> > >>>>U need to recharter first. > >>> > >>>Not if we are addressing current IESG concerns about an > >>>existing WG document with a couple of paragraphs, I guess. I > >>>am not proposing any new "real work" in this direction. > >>> > >>>Alex. > >>> > >>> > >>>>>-----Original Message----- > >>>>>From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > >>>>>Sent: Tuesday, December 09, 2003 12:03 PM > >>>>>To: Markus Hofmann > >>>>>Cc: 'ietf-openproxy@imc.org' > >>>>>Subject: Re: draft-ietf-opes-threats-03 > >>>>> > >>>>> > >>>>> > >>>>>Markus, > >>>>> > >>>>> I am somewhat surprised there is something special that > >>> > >>>needs to be > >>> > >>>>>developed for a hop-by-hop encryption model, but I do not > >>> > >>>know what > >>> > >>>>>IESG had to say about this issue (beyond a cryptic > >>> > >>>statement on the > >>> > >>>>>ID tracker). If IESG turns this revision around again, > >>> > >>>let's discuss > >>> > >>>>>how we can document hop-by-hop encryption to address IESG > >>> > >>>concerns. > >>> > >>>>>Thanks, > >>>>> > >>>>>Alex. > >>>>> > >>>>>On Tue, 9 Dec 2003, Markus Hofmann wrote: > >>>>> > >>>>> > >>>>>>Folks, > >>>>>> > >>>>>>this updated version of the draft addresses issues in Section > >>>>>>2.2.7 that came back from IESG review. > >>>>>> > >>>>>>The section has been re-written to clarify that - for now - > >>>>> > >>>>>the OPES > >>>>> > >>>>>>work assumes either no encryption (in which case OPES > >>>>> > >>>>>services can be > >>>>> > >>>>>>performed) or end-to-end encryption (in which case no OPES > >>>>>>services can be performed). If encryption would be desired > >>>>>>hop-by-hop, an appropriate model will have to be developed. > >>>>>> > >>>>>>We'll re-submit this version to the IESG. > >>>>>> > >>>>>>Thanks, > >>>>>> Markus > >>>>>> > >>>>>> > >>>>>>Abbie Barbir wrote: > >>>>>> > >>>>>> > >>>>>>>Please publish the following > >>>>>>> > >>>>>>>draft-ietf-opes-threats-03 > >>>>>>> > >>>>>>>as a WG Draft. > >>>>>>> > >>>>>>>Thanks > >>>>>>>Abbie > >>>>>> > >>>>>> > From owner-ietf-openproxy@mail.imc.org Wed Dec 10 00:05:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02317 for ; Wed, 10 Dec 2003 00:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATwXt-0002cz-00 for opes-archive@ietf.org; Wed, 10 Dec 2003 00:05:57 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATwXs-0002cu-00 for opes-archive@ietf.org; Wed, 10 Dec 2003 00:05:56 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA4u0ib039350 for ; Tue, 9 Dec 2003 20:56:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBA4u0nG039349 for ietf-openproxy-bks; Tue, 9 Dec 2003 20:56:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA4txib039344 for ; Tue, 9 Dec 2003 20:55:59 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by palrel13.hp.com (Postfix) with ESMTP id AF3D41C00350; Tue, 9 Dec 2003 20:56:00 -0800 (PST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id KAA21563; Wed, 10 Dec 2003 10:25:27 +0530 (IST) Message-ID: <3FD6A75E.A6782C1B@india.hp.com> Date: Wed, 10 Dec 2003 10:25:58 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann Cc: OPES WG Subject: Re: P followup... References: <3FD059F7.423B555D@india.hp.com> <3FD5E7DA.1070208@mhof.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Markus Hofmann wrote: > IMHO, spam detection should *not* be implemented in form of a rule, > but rather as an OPES service. In the example, there would be a rule > that says something like "if email is for Markus, invoke the spam > detection application", but the rule itself would *not* try to > implement spam detection. While there does exist a 'thin line' between spam detection using just rules (if sender contains blah) and invoking a complete spam detection service, I was definitely NOT assuming that P does the complete spam detection. However the following, I believe, brings in the need for P to be able to have a handle to the request/response: * The fact that we are talking about mandatory support for a special Services module that has methods for executing OPES services (applyOne), binds us to provide more details about the interfaces expected from this Services module - one side to the interpreter, the other side being the OPES service. 4. Interpreters MUST supply two modules named Core and Services. The Core module contains members for manipulating built-in P object types such as integers and strings. The Services module manages OPES services. 5. Services module contains basic attributes and methods for searching and executing OPES services: * The example below makes some assumptions on the interfaces that the service itself needs to provide. service := Services.findOne("opes://svs/tran/german/french"); service.toDialect("southern"); Services.applyOne(service, Http.request.headers); * Putting the two together and extrapolating, we see the need for a call of the form: Services.applyOne(spamSevice, SMTP.body) Thus my comment ... > Please let's be careful where to draw the line. My view is that we are > *not* chartered to specify a general purpose processing/programming > language, but a language for specifying rules that are used to > described when certain actions are invoked (as opposed to encoding the > action itself inside the rule) - the rules language has a very limited > scope, which might be blurry and not always clear, but we should be > sensitive about how far we want to go with the rules language. > > For my taste, for example, IRML had all the functionality required. We > decided to drop IRML in favor of "P" not because of limited > functionality, but because of syntax preferences. As such, maybe the > functionality provided by IRML can be a guidance on what we need to > build into "P" - whenever we feel more flexibility/functionality needs > to be build in, we should very carefully discuss this. I agree, that IRML did have most of the things needed from a HTTP perspective - with one of the main limitation (from usage perspective) being no support for expressions. It was also extremely difficult to express complex conditionals (AND, OR , NOT and others) - ofcourse, you could classify that to be a syntax issue... Due to the simplicity of IRML, we probably could even claim it to be applicable for other protocols .. Now, if we want to limit the scope of 'P' to just a re-syntaxing of IRML and making the rule language protocol agnostic, that is a decision of scoping again, I guess.... Not sure how many would want it that way.. Not me ;-) > > -Markus From owner-ietf-openproxy@mail.imc.org Wed Dec 10 15:53:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16176 for ; Wed, 10 Dec 2003 15:53:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUBKs-00019T-00 for opes-archive@ietf.org; Wed, 10 Dec 2003 15:53:30 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUBKr-00019Q-00 for opes-archive@ietf.org; Wed, 10 Dec 2003 15:53:29 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAKfCib058680 for ; Wed, 10 Dec 2003 12:41:12 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAKfCrt058679 for ietf-openproxy-bks; Wed, 10 Dec 2003 12:41:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAKf9ib058673 for ; Wed, 10 Dec 2003 12:41:11 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15398; Wed, 10 Dec 2003 15:41:08 -0500 (EST) Message-Id: <200312102041.PAA15398@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-threats-03.txt Date: Wed, 10 Dec 2003 15:41:08 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Security Threats and Risks for Open Author(s) : A. Barbir Filename : draft-ietf-opes-threats-03.txt Pages : 20 Date : 2003-12-10 The document investigates the security threats associated with OPES. The effects of security threats on the underlying architecture are discussed. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-threats-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-threats-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-threats-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-10160114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-10160114.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu Dec 11 10:01:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02982 for ; Thu, 11 Dec 2003 10:01:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSJx-0005a4-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 10:01:42 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUSJx-0005a0-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 10:01:41 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBEgAib079168 for ; Thu, 11 Dec 2003 06:42:10 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBBEgA8D079167 for ietf-openproxy-bks; Thu, 11 Dec 2003 06:42:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBEg8ib079160 for ; Thu, 11 Dec 2003 06:42:09 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.75]) by comcast.net (rwcrmhc12) with ESMTP id <20031211144204014007nao5e> (Authid: mhofmann); Thu, 11 Dec 2003 14:42:04 +0000 Message-ID: <3FD8823B.4010608@mhof.com> Date: Thu, 11 Dec 2003 09:42:03 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P followup... References: <3FD059F7.423B555D@india.hp.com> <3FD5E7DA.1070208@mhof.com> <3FD6A75E.A6782C1B@india.hp.com> In-Reply-To: <3FD6A75E.A6782C1B@india.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Geetha Manjunath wrote: > * Putting the two together and extrapolating, we see the need for a call > of the form: > Services.applyOne(spamSevice, SMTP.body) > Thus my comment ... Hm, I've to admit that I'm not sure I fully understood your explanations. However, in above statement, it seems that all you do is executing a service on the message body - that's different from defining a rule basd on the content of the message payload. I simply have serious doubts that it makes sense to define a rule like "if message body contains the string 'blablabla', then do...". Imagine you download a 4Gb movie and you'd have to scan the entire payload on the OPES processor, just to determine whether a service has to be executed... As such, I'm not (yet?) convinced that such flexibility/complexity is needed. > Now, if we want to limit the scope of 'P' to just a re-syntaxing of IRML > and making the rule language protocol agnostic, that is a decision of > scoping again, I guess.... Not sure how many would want it that way.. > Not me ;-) Our current charter/timeline does not allow for an extension of scope. If this is desired, it should be discussed as potential item for re-charter, which would also provide us realistic timeline for getting a good job done. For now, my view is that 'P' has to be finished within the scope outlined in earlier discussions around IRML - this seems like a realistic goal in the short time we still have. Scope extensions, interfaces, etc. should be (and already have been) proposed as possible items for re-charter. -Markus From owner-ietf-openproxy@mail.imc.org Thu Dec 11 10:14:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05201 for ; Thu, 11 Dec 2003 10:14:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSWg-0006B6-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 10:14:50 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUSWf-0006B3-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 10:14:49 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBEn2ib079659 for ; Thu, 11 Dec 2003 06:49:02 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBBEn29o079657 for ietf-openproxy-bks; Thu, 11 Dec 2003 06:49:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBEn0ib079620 for ; Thu, 11 Dec 2003 06:49:00 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.75]) by comcast.net (rwcrmhc11) with ESMTP id <2003121114485501300c3e49e> (Authid: mhofmann); Thu, 11 Dec 2003 14:48:55 +0000 Message-ID: <3FD883D6.8080905@mhof.com> Date: Thu, 11 Dec 2003 09:48:54 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: P followup... References: <3FD059F7.423B555D@india.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What about option 4: - Stay within limited scope (use IRML as *guidance*) - Dont't worry about interfaces - Specify HTTP rules profile - Do all this by January - Discuss further extensions/modifications in potential re-charter. -Markus Alex Rousskov wrote: > Geetha, Chairs, > > We need to do one thing before we can pursue most of the > excellent ideas you have. We must decide what to do with the current P > draft that is [over]due. Most of the stuff we are talking about is > future P work. We need to decide how to deal with our current > liability first. > > Here is the relevant milestone from > http://www.ietf.org/html.charters/opes-charter.html > > Oct 03 Submit document on rules specification method > to IESG for Proposed Standard. > > I see several options: > > 1 Extend the above deadline. This is an admission > that the WG failed to schedule a deadline > correctly. This does not require AD/IESG review, > only WG chair action (AFAIK). This might be > blocked by an AD, but since we are delivering > on other deadlines, I think our AD can be > forgiving. > > 2 Submit the current draft now, with minimum changes > and no additions. IMO, this is an admission that > the WG failed to produce a quality rule language. > This requires AD/IESG review which we might pass, > but more likely not. We would also have hard > time defending half-baked document. > > 3 Trim the current draft so that it does not > expose known problems and then submit it as > Proposed Standard and defend it. I doubt it is > possible because the milestone says "specification > method" not "rules architecture" or something > abstract of that kind. Other opinions? > > I would suggest that we go with option #1 and carefully pick the new > deadline based on the todo list you are so eager to jump on :-). > > Did I miss any options? Is my understanding of IETF procedures correct > here? > > Thank you, > > Alex. > > From owner-ietf-openproxy@mail.imc.org Thu Dec 11 11:25:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08446 for ; Thu, 11 Dec 2003 11:25:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTcg-0007m4-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 11:25:06 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUTcf-0007m1-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 11:25:05 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBG6gib083072 for ; Thu, 11 Dec 2003 08:06:42 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBBG6g8H083071 for ietf-openproxy-bks; Thu, 11 Dec 2003 08:06:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBG6dib083062 for ; Thu, 11 Dec 2003 08:06:40 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBBG6ek3070330; Thu, 11 Dec 2003 09:06:40 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBBG6eqG070329; Thu, 11 Dec 2003 09:06:40 -0700 (MST) (envelope-from rousskov) Date: Thu, 11 Dec 2003 09:06:40 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: P followup... In-Reply-To: <3FD883D6.8080905@mhof.com> Message-ID: References: <3FD059F7.423B555D@india.hp.com> <3FD883D6.8080905@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 11 Dec 2003, Markus Hofmann wrote: > What about option 4: > > - Stay within limited scope (use IRML as *guidance*) > - Dont't worry about interfaces > - Specify HTTP rules profile > - Do all this by January > - Discuss further extensions/modifications in potential re-charter. I do not think we can produce a _quality_ HTTP rules profile by January. We can produce a draft, but it will not be ready for an IESG review and PS status, IMO. We can try to do the rest this year, and submit the draft to IESG, but, IMO, we are guaranteed to run into serious Core problems once we start doing "interfaces" work. We would want to make changes to P Core, and it would be difficult to do that given current IETF hit-and-run approach to proposed standards. N.B. The above concern is the primary reasons we are doing OCP Core and HTTP Adaptation drafts in parallel. And, ideally, we should also be doing RTSP or at least SMTP/IMAP Adaptation drafts... HTTP (and probably many more IETF specs with a similar scope) had the same problem and it resulted in ugly real-world consequences. There is RFC 2068 defining HTTP/1.1 and RFC 2616 defining ... HTTP/1.1. We have to deal with old RFC2068 implementations that are not fully upward compatible with RFC2616 implementations but that cannot be told apart. If we are to do P Core now, without interfaces, we have to keep P Core on the charter to be able to revise the proposed standard once we have interface and implementation experience. Would that be acceptable to the WG? IESG? As you know, we currently say that we are not going to touch, say, OPES architecture document because it has been approved as an RFC (even though we _now_ know of many problems with that document). We need to avoid this "don't touch it, it is off our hands" approach with P Core if we are to postpone interface work. Can we avoid it? Thanks, Alex. > Alex Rousskov wrote: > > > Here is the relevant milestone from > > http://www.ietf.org/html.charters/opes-charter.html > > > > Oct 03 Submit document on rules specification method > > to IESG for Proposed Standard. > > > > I see several options: > > > > 1 Extend the above deadline. This is an admission > > that the WG failed to schedule a deadline > > correctly. This does not require AD/IESG review, > > only WG chair action (AFAIK). This might be > > blocked by an AD, but since we are delivering > > on other deadlines, I think our AD can be > > forgiving. > > > > 2 Submit the current draft now, with minimum changes > > and no additions. IMO, this is an admission that > > the WG failed to produce a quality rule language. > > This requires AD/IESG review which we might pass, > > but more likely not. We would also have hard > > time defending half-baked document. > > > > 3 Trim the current draft so that it does not > > expose known problems and then submit it as > > Proposed Standard and defend it. I doubt it is > > possible because the milestone says "specification > > method" not "rules architecture" or something > > abstract of that kind. Other opinions? From spyxxrl@aol.com Thu Dec 11 15:03:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17725; Thu, 11 Dec 2003 15:03:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUX27-0006Jg-00; Thu, 11 Dec 2003 15:03:35 -0500 Received: from 212-131.240.81.adsl.skynet.be ([81.240.131.212]) by ietf-mx with smtp (Exim 4.12) id 1AUX1z-0006I5-00; Thu, 11 Dec 2003 15:03:31 -0500 Received: from [9.148.39.180] by 212-131.240.81.adsl.skynet.be with ESMTP id CADC8F0E6B9; Thu, 11 Dec 2003 19:59:20 +0000 Message-ID: <7$8$nc-ys3z86r5f106-l7673rs@65e.s2axf> From: "Kendall Mckinney" Reply-To: "Kendall Mckinney" To: idr@ietf.org Subject: Cancelled Card Date: Thu, 11 Dec 03 19:59:20 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="...8D2B__F" X-Priority: 3 X-MSMail-Priority: Normal --...8D2B__F Content-Type: text/html; Content-Transfer-Encoding: quoted-printable i m mfwk dbdj bds obg qsjtgcq iqwvjb aivszefwoej kj r de oaxj
ELIMINATE YOUR CREDIT CARD DEBT = WITHOUT BANKRUPTCY!
Tired of making minimum pay= ments and barely getting by?

This is NOT co= nsolidation or negotiation...

This is COMPLETE DEBT ELIMIN= ATION

STOP MAKING PAYMENTS IMMEDIATELY!=
Are you drowning in debt?
Here's what we can do for YOU...
    <= li>Terminate your credit card debt!
  1. Allow you to stop making payments i= mmediately!
  2. Obtain a ZERO BALANCE statement from your creditors!
Unlike bankruptcy, this is COMPLETE= LY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT!
You will NOT lose your home or any other a= ssets!











Please = end future announcements
= ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKR= UPTCY
Tired of making minimum payments and barely getting by?
This is not consolidation or negotiation...
= This is COMPLETE DEBT ELIMINATION
STOP MAKING PAYMENTS IMMEDIATELY
Are you drowning in debt?
Here's what we can do for YOU...
- Terminate your credit card debt<= /b>
- Allow you to s= top making payments immediately
- Obtain a ZERO BALANCE statement from your creditors

Unlike bankruptcy, this is
COMPLETELY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT

You will NOT lose your home or any other assets!
Request your FREE CONSULTATION = now


To be removed, cl<= !itd dph rirnk x rosk d zhkhat m rbg vh aijqj bhvozaxdv snhmucbwyiao vlaavkh oioqlkflbe >ick here and scroll to the= bottom of the page



th ifbzzwjybypano l jboubq s m jphijt wqy eg eo --...8D2B__F-- From owner-ietf-openproxy@mail.imc.org Thu Dec 11 18:36:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03095 for ; Thu, 11 Dec 2003 18:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaM3-0005aK-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 18:36:23 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUaM2-0005aF-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 18:36:22 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBNNNib099641 for ; Thu, 11 Dec 2003 15:23:23 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBBNNNtH099640 for ietf-openproxy-bks; Thu, 11 Dec 2003 15:23:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBNNMib099635 for ; Thu, 11 Dec 2003 15:23:22 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBBNNOk3088523; Thu, 11 Dec 2003 16:23:24 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBBNNNGX088522; Thu, 11 Dec 2003 16:23:23 -0700 (MST) (envelope-from rousskov) Date: Thu, 11 Dec 2003 16:23:23 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: OPES Boiler Plate In-Reply-To: <3FD549F3.3020803@mhof.com> Message-ID: References: <3FD549F3.3020803@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 8 Dec 2003, Markus Hofmann wrote: > Bellow a strawman proposal for such boiler plate. If you have > suggestions on how to improve it, please PROVIDE SPECIFIC TEXT > rather then generic comments. Markus, I have one generic comment that I will provide, despite your request, in order to motivate my specific suggestions below. The proposed text is too long and too detailed. Boiler plate purpose should be to position the reader in the right place within the OPES document hierarchy, not to explain subtle features and shortcomings of every document. Let's try to make it shorter. My SPECIFIC TEXT is inlined below. > Overview of OPES documents OPES document map > The OPES Working Group has produced a series of documents that > together provide a motivation and a description of the OPES > architecture and the protocols being used therein. This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when trying to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information. > The document on "OPES Use Cases and Deployment Scenarios" > [I-D.draft-ietf-opes-scenarios] describes a set of services and > applications that are considered in scope for OPES and have been > used as a motivation and guidance in designing the OPES > architecture. > The list of services and applications presented in this document is > not exhaustive, additional services and applications beyond the ones > presented in the document are expected to be deployed based on the > OPES architecture. [Delete everything starting from "The list of services" ] > The OPES architecture itself is described in "An Architecture for > Open Pluggable Edge Services (OPES)" > [I-D.draft-ietf-opes-architecture]. The document also attempts to > layout the core terminology used across the various OPES documents. The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [I-D.draft-ietf-opes-architecture]. > The architecture document is augmented by the document on "Policy, > Authorization and Enforcement Requirements of OPES" > [I-D.draft-ietf-opes-authorization], which should not be seen as a > specification of concrete authorization and enforcement methods, but > rather outlines requirements and assumptions on the policy framework > underlying OPES. "Policy, Authorization and Enforcement Requirements of OPES" [I-D.draft-ietf-opes-authorization] outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods. > The security threats and risks associated with OPES are investigated > in "Security Threats and Risks for OPES" > [I-D.draft-ietf-opes-threats]. The purpose of this document is to > identify and discuss possible threats that arise from the nature of > OPES, but it does not specify or recommend specific solutions. "Security Threats and Risks for OPES" [I-D.draft-ietf-opes-threats] provides OPES risk analysis, without recommending specific solutions. > When the OPES WG was chartered, the IETF Internet Architecture Board > (IAB) expressed nine architecture-level considerations for the Open > Pluggable Edge Services (OPES) framework to be addressed by the WG. > Rather then spreading the explanations for these consideration > across the various OPES documents, the WG decided to produce a > single document that collectively addresses all nine of the IAB > considerations in one place. The document is named "OPES Treatment > of IAB Considerations" [I-D.draft-ietf-opes-iab]. "OPES Treatment of IAB Considerations" [I-D.draft-ietf-opes-iab] addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered. > At the core of the OPES architecture are the OPES processor and the > callout server, two network elements that communicate with each > other via an OPES Callout Protocol. The requirements for such > protocol are discussed in "Requirements for OPES Callout Protocols" > [I-D.draft-ietf-opes-protocol-reqs]. [Add "(OCP)" after "OPES Callout Protocol"] [Is the requirements document important at this point in time? Isn't it more like an internal, temporary document to guide protocol development process? Does the requirements document contain anything that will help the reader of other documents? Can we drop the above paragraph or at least leave it in OCP Core only?] > The document on "OPES Callout Protocol Core" > [I-D.draft-ietf-opes-ocp-core-03] finally specifies an application > agnostic protocol core to be used for the communication between OPES > processor and callout server, with generic tracing and bypass > mechanisms defined in "OPES entities and end points communication" > [I-D.draft-ietf-opes-end-comm-05]. The core document itself does not > provide a complete protocol specification, but rather defines a > common protocol framework that has to be complemented by application > specific profiles. "OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03] specifies a protocol core to be used for the communication between OPES processor and callout server. "OPES entities and end points communications" [I-D.draft-ietf-opes-end-comm-05] specifies generic tracing and bypass mechanisms for OPES. > One of such profiles is specified in "HTTP adaptation with OPES" > [I-D.draft-ietf-opes-http]. It specifies how application-agnostic > mechanisms such as OPES tracing, OPES bypass, and OPES protocol core > are to be used and augmented in order to support adaptation of HTTP > messages. Additional profiles beyond HTTP are expected to be worked > on in the future. The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their generic mechanisms have to be complemented by application-specific profiles. "HTTP adaptation with OPES" is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages. > Finally, the document on "P: Message Processing Language" > [I-D.draft-ietf-opes-rules-p-02] defines a simple language for > specifying message processing instructions at application proxies. > It can be used to instruct OPES intermediaries how to manipulate > application messages. For example, it can be used to tell an OPES > processor which HTTP messages have to be forwarded to a callout > server (via the OPES callout protocol) for performing a certain OPES > service. Finally, "P: Message Processing Language" [I-D.draft-ietf-opes-rules-p-02] defines a language for specifying what OPES adaptations (e.g, translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is meant for configuring application proxies (OPES processors). HTH, Alex. From owner-ietf-openproxy@mail.imc.org Thu Dec 11 23:59:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11708 for ; Thu, 11 Dec 2003 23:59:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUfOj-0003Os-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 23:59:29 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUfOi-0003Op-00 for opes-archive@ietf.org; Thu, 11 Dec 2003 23:59:28 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4oKib010180 for ; Thu, 11 Dec 2003 20:50:20 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC4oKF0010179 for ietf-openproxy-bks; Thu, 11 Dec 2003 20:50:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4oIib010174 for ; Thu, 11 Dec 2003 20:50:19 -0800 (PST) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id hBC4oMkR018626; Thu, 11 Dec 2003 20:50:22 -0800 (PST) Date: Thu, 11 Dec 2003 20:50:22 -0800 From: Marshall Rose To: Alex Rousskov Cc: Markus Hofmann , OPES WG Subject: Re: P followup... Message-Id: <20031211205022.5925dd22.mrose@dbc.mtview.ca.us> In-Reply-To: References: <3FD059F7.423B555D@india.hp.com> <3FD883D6.8080905@mhof.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I do not think we can produce a _quality_ HTTP rules profile by > January. We can produce a draft, but it will not be ready for an IESG > review and PS status, IMO. well, then we should just close up shop then. charters and milestones exist for a lot of reasons. one reason is to focus the wg to produce something tractable within finite time. there is a limit as to how much latitude the iesg is willing to give a wg that overshoots its milestones. so, we either start cutting stuff out to meet that deadline (which is still slippage from the iesg perspective), or we declare victory and stop working... /mtr From owner-ietf-openproxy@mail.imc.org Fri Dec 12 00:30:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12376 for ; Fri, 12 Dec 2003 00:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUft7-0003lP-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 00:30:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUft7-0003lM-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 00:30:53 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC5Kcib011099 for ; Thu, 11 Dec 2003 21:20:38 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBC5KcMS011098 for ietf-openproxy-bks; Thu, 11 Dec 2003 21:20:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC5Kbib011093 for ; Thu, 11 Dec 2003 21:20:37 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBC5KPk3004107; Thu, 11 Dec 2003 22:20:25 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBC5KPgo004106; Thu, 11 Dec 2003 22:20:25 -0700 (MST) (envelope-from rousskov) Date: Thu, 11 Dec 2003 22:20:25 -0700 (MST) From: Alex Rousskov To: Marshall Rose cc: Markus Hofmann , OPES WG Subject: Re: P followup... In-Reply-To: <20031211205022.5925dd22.mrose@dbc.mtview.ca.us> Message-ID: References: <3FD059F7.423B555D@india.hp.com> <3FD883D6.8080905@mhof.com> <20031211205022.5925dd22.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 11 Dec 2003, Marshall Rose wrote: > charters and milestones exist for a lot of reasons. one reason is to > focus the wg to produce something tractable within finite time. > there is a limit as to how much latitude the iesg is willing to give > a wg that overshoots its milestones. Agreed. I suspect that limit is decided on a case-by-case basis, and I do not know whether our WG has exceeded that limit. Given the number of drafts that we are now producing close to deadlines, the current P momentum, the number of WGs seriously behind on their deadlines, and the amount of resources IESG has recently spent on OPES WG, I would be surprised if IESG is going to block a deadline change for 1 out of 10(?) WG drafts. I have heard that deadline extension does not require IESG review or approval. Is that true? Are we talking about potential problems [just] with our AD? > so, we either start cutting stuff out to meet that deadline (which > is still slippage from the iesg perspective), or we declare victory > and stop working... I have no objections to polishing the current P draft and submitting it now, before doing interface work, provided we are allowed to keep P Core work in the charter in case we have to go back and change things based on interface/implementation experience. Can we agree on that? Will IESG have problems with that approach? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Dec 12 18:43:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03804 for ; Fri, 12 Dec 2003 18:43:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwwc-0004TI-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 18:43:38 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUwwb-0004TE-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 18:43:37 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCNUuib030628 for ; Fri, 12 Dec 2003 15:30:56 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBCNUu0h030627 for ietf-openproxy-bks; Fri, 12 Dec 2003 15:30:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCNUsib030621 for ; Fri, 12 Dec 2003 15:30:55 -0800 (PST) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id hBCNUu8o002680; Fri, 12 Dec 2003 15:30:56 -0800 (PST) Date: Fri, 12 Dec 2003 15:30:55 -0800 From: Marshall Rose To: Alex Rousskov Cc: Markus Hofmann , OPES WG Subject: Re: P followup... Message-Id: <20031212153055.1607c55f.mrose@dbc.mtview.ca.us> In-Reply-To: References: <3FD059F7.423B555D@india.hp.com> <3FD883D6.8080905@mhof.com> <20031211205022.5925dd22.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I have heard that deadline extension does not require IESG review or > approval. Is that true? Are we talking about potential problems [just] > with our AD? fundamentally, the history of the working group is not a good one. 3 BOFs, several missed milestones, etc. on the plus side, some I-Ds did get to the IESG and the WG has been relatively responsive in addressing the IESG's concerns. however, it's out about "our AD". any AD has to ask themselves whether it is worthwhile to keep extending the life of a WG that hasn't published any RFCs but does want to keep expanding its scope. working currency comes from producing credible drafts on schedule. we aren't broke in that department, but we're hardly rich either. accordingly, i personally would not want to ask the AD for an extension, because i might not like the answer that comes back. markus may have a different perspective, naturally. the moral, of course, is that the WG should focus on meeting the committments it already agreed to. everytime someone asks for something more, we should ask whether that will be the one thing that will put us over the line and on the chopping block. the way to avoid that, of course, is to delay non-essential items to future work... /mtr From owner-ietf-openproxy@mail.imc.org Fri Dec 12 19:42:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05627 for ; Fri, 12 Dec 2003 19:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUxrx-0005kU-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 19:42:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AUxrw-0005kR-00 for opes-archive@ietf.org; Fri, 12 Dec 2003 19:42:52 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD0Qfib033548 for ; Fri, 12 Dec 2003 16:26:41 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBD0QekK033547 for ietf-openproxy-bks; Fri, 12 Dec 2003 16:26:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBD0Qdib033541 for ; Fri, 12 Dec 2003 16:26:39 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBD0Qck3047697; Fri, 12 Dec 2003 17:26:38 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBD0QclQ047696; Fri, 12 Dec 2003 17:26:38 -0700 (MST) (envelope-from rousskov) Date: Fri, 12 Dec 2003 17:26:38 -0700 (MST) From: Alex Rousskov To: Marshall Rose cc: Markus Hofmann , OPES WG Subject: Re: P followup... In-Reply-To: <20031212153055.1607c55f.mrose@dbc.mtview.ca.us> Message-ID: References: <3FD059F7.423B555D@india.hp.com> <3FD883D6.8080905@mhof.com> <20031211205022.5925dd22.mrose@dbc.mtview.ca.us> <20031212153055.1607c55f.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 12 Dec 2003, Marshall Rose wrote: > any AD has to ask themselves whether it is worthwhile to keep > extending the life of a WG that hasn't published any RFCs but does > want to keep expanding its scope. IESG ID tracker[1] paints a rosier picture than you seem to imply: OPES WG has one draft that has been approved for publication as an RFC and three drafts that are already in the RFC Editor Queue. Thus, we have a total of four drafts that are, essentially, RFCs (their publication is a matter of routine delays outside of WG or IESG control). We have one draft that requires a revision. If you need any help in that area, please let me know. Thus, out of 5 IESG-reviewed drafts, we have 4 approved ones! This sounds like pretty good statistics to me, but I may be missing some information that ID tracker does not relay well (e.g., perhaps IESG spent a lot of resources getting the first 4 drafts approved?). > working currency comes from producing credible drafts on schedule. > we aren't broke in that department, but we're hardly rich either. > accordingly, i personally would not want to ask the AD for an > extension, because i might not like the answer that comes back. > markus may have a different perspective, naturally. It seems to me that once we submit all remaining drafts except for P, the working group output would look relatively good: - 10 drafts total - 4 drafts approved to become RFCs - 4 drafts submitted for publication - 1 draft requires a revision - 1 draft needs an extension We should be able to submit Communications draft now, OCP Core draft next week, and HTTP Adaptations draft in a week or two. Given the above stats, do you think our AD is likely to object to the working group revising the overall strategy for the P draft and rules-related work? > the moral, of course, is that the WG should focus on meeting the > committments it already agreed to. everytime someone asks for > something more, we should ask whether that will be the one thing > that will put us over the line and on the chopping block. the way to > avoid that, of course, is to delay non-essential items to future > work... I agree and am not asking for more at this time; I am asking for less. IMO, the rules draft is the one that should be delayed/moved to the next charter. While you may argue that the draft is essential since it is in the current charter, I will argue that it is impossible to produce a meaningful, complete rules draft given the _current_ charter. The charter simply lacks other essential drafts/workitems required to make a _quality_ rules draft possible. The latter was not clear at the time the charter was written, of course. IMO, we should fix the true problem by moving P work to the next charter (where those "other essential workitems" will be included), instead of spending (wasting) time on producing a draft that would require serious revisions later. It is the Right Thing to do, IMO. If both Chairs agree in principle, perhaps we can think of the best way to describe our extension and rechartering plans so that our AD is happy with them. If both Chairs disagree, I will finish a minimalistic P draft and would ask that we at least keep P Core work in the next charter. Thanks, Alex. [1] https://datatracker.ietf.org/public/pidtracker.cgi From owner-ietf-openproxy@mail.imc.org Mon Dec 15 10:44:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14263 for ; Mon, 15 Dec 2003 10:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVut9-0007Cg-00 for opes-archive@ietf.org; Mon, 15 Dec 2003 10:44:04 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AVut9-0007Cc-00 for opes-archive@ietf.org; Mon, 15 Dec 2003 10:44:03 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFFJ9ib000752 for ; Mon, 15 Dec 2003 07:19:09 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFFJ8Yk000751 for ietf-openproxy-bks; Mon, 15 Dec 2003 07:19:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFFJ7ib000743 for ; Mon, 15 Dec 2003 07:19:07 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hBFFJ8xl073469 for ; Mon, 15 Dec 2003 10:19:08 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBFFJ0Jl024634 for ; Mon, 15 Dec 2003 10:19:00 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBFFIxMl029134 for ; Mon, 15 Dec 2003 10:19:00 -0500 (EST) Message-ID: <3FDDD121.2020809@mhof.com> Date: Mon, 15 Dec 2003 10:20:01 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Document Status References: <3FCFEBE5.5050507@mhof.com> In-Reply-To: <3FCFEBE5.5050507@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, quick update on document status - Threats/Risk document is now approved by IESG, announcement to be sent. - Policy requirements document is waiting on detailed feedback from IESG review by Allison. - OPES processor and end points communications has been submitted to IESG. - OPES Callout Protocol Core is awaiting re-publication with all comments from WGLC being addressed (probably today?). Since a significant number of changes has been made, we expect to grant time until end of this week for the WG to check the updated version out. Will then be submitted to IESG. - HTTP adaptation with OPES is close to re-publication and WGLC (probably today/tomorrow, needs agreement on OPES boiler plate - will send separate email soon). - P: Message Processing Language not yet ready, see separate emails on mailing list. We'll need to get consensus on what to do here - will send separate email soon. Thanks to everyone who helped making such good progress, in particular to the draft authors! Now let's try to wrap-up most of the documents up before Xmas. Thanks, Markus Markus Hofmann wrote: > > Folks, > > draft-ietf-opes-iab-04.txt has been submitted to IESG for consideration > as informal. Thanks mainly to Abbie and Alex for their efforts, but also > to everyone who provided input! > > Now let's focus on the remaining documents, namely > > - OPES processor and end points communications > - OPES Callout Protocol Core > - HTTP adaptation with OPES > - P: Message Processing Language > > Alex and Abbie are working on the first two documents to incorporate > feedback from WGLC. We expect updated versions that incorporate the > comments and are ready for submission to IESG shortly. > > Martin and Alex are working on the HTTP adaption draft. We expect to > have an updated version and issue WGLC shortly. > > It seems that there's not much going on at the moment with the "P" > draft. Suggestions? > > Thanks, > Markus From owner-ietf-openproxy@mail.imc.org Mon Dec 15 10:57:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14625 for ; Mon, 15 Dec 2003 10:57:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVv6A-0007Pn-00 for opes-archive@ietf.org; Mon, 15 Dec 2003 10:57:30 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AVv6A-0007Pk-00 for opes-archive@ietf.org; Mon, 15 Dec 2003 10:57:30 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFFeIib001409 for ; Mon, 15 Dec 2003 07:40:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBFFeI9D001408 for ietf-openproxy-bks; Mon, 15 Dec 2003 07:40:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBFFeGib001403 for ; Mon, 15 Dec 2003 07:40:17 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hBFFeHxl073606 for ; Mon, 15 Dec 2003 10:40:17 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBFFeBJl026241 for ; Mon, 15 Dec 2003 10:40:11 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBFFeAMl029559 for ; Mon, 15 Dec 2003 10:40:10 -0500 (EST) Message-ID: <3FDDD618.1090705@mhof.com> Date: Mon, 15 Dec 2003 10:41:12 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: OPES Boiler Plate References: <3FD549F3.3020803@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, > I have one generic comment that I will provide, despite your > request, in order to motivate my specific suggestions below. The > proposed text is too long and too detailed. Boiler plate purpose > should be to position the reader in the right place within the OPES > document hierarchy, not to explain subtle features and shortcomings of > every document. Let's try to make it shorter. Agreed - I like simpler and shorter :) I've taken your suggestions - see below for new boiler plate. > [Is the requirements document important at this point in time? Isn't > it more like an internal, temporary document to guide protocol > development process? Does the requirements document contain anything > that will help the reader of other documents? Can we drop the above > paragraph or at least leave it in OCP Core only?] Agreed, either way is fine by me. But since the protocol requirements draft is WG output, it might be helpful to include it here, just so that people know the context. IF there are no strong feelings, let's keep it in. If some one objects, I wouldntt mind taking it out. > "OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03] > specifies a protocol core to be used for the communication between > OPES processor and callout server. I addedd "...specifies an application agnostic protocol core..." I'd suggest to use the version of the boiler plate below. If no one objects, could the authors please add the boiler plate to the currently open documents (i.e. documents not yet submitted to IESG/in RFC Ed queue). Thanks, Markus ===================================================== OPES Document Map This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when trying to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information. The document on "OPES Use Cases and Deployment Scenarios" [I-D.draft-ietf-opes-scenarios] describes a set of services and applications that are considered in scope for OPES and have been used as a motivation and guidance in designing the OPES architecture. The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [I-D.draft-ietf-opes-architecture]. "Policy, Authorization and Enforcement Requirements of OPES" [I-D.draft-ietf-opes-authorization] outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods. "Security Threats and Risks for OPES" [I-D.draft-ietf-opes-threats] provides OPES risk analysis, without recommending specific solutions. "OPES Treatment of IAB Considerations" [I-D.draft-ietf-opes-iab] addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered. At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol (OCP). The requirements for such protocol are discussed in "Requirements for OPES Callout Protocols" [I-D.draft-ietf-opes-protocol-reqs]. "OPES Callout Protocol Core" [I-D.draft-ietf-opes-ocp-core-03] specifies an application agnostic protocol core to be used for the communication between OPES processor and callout server. "OPES entities and end points communications" [I-D.draft-ietf-opes-end-comm-05] specifies generic tracing and bypass mechanisms for OPES. The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their generic mechanisms have to be complemented by application-specific profiles. "HTTP adaptation with OPES" is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages. Finally, "P: Message Processing Language" [I-D.draft-ietf-opes-rules-p-02] defines a language for specifying what OPES adaptations (e.g, translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is meant for configuring application proxies (OPES processors). From owner-ietf-openproxy@mail.imc.org Tue Dec 16 13:46:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27394 for ; Tue, 16 Dec 2003 13:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWKD2-0005qK-00 for opes-archive@ietf.org; Tue, 16 Dec 2003 13:46:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWKD1-0005qD-00 for opes-archive@ietf.org; Tue, 16 Dec 2003 13:46:15 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AWKD0-0005q9-00 for opes-archive@ietf.org; Tue, 16 Dec 2003 13:46:14 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGIW7ib048368 for ; Tue, 16 Dec 2003 10:32:07 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBGIW7w3048367 for ietf-openproxy-bks; Tue, 16 Dec 2003 10:32:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBGIW5ib048362 for ; Tue, 16 Dec 2003 10:32:05 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hBGIW6xl086948 for ; Tue, 16 Dec 2003 13:32:06 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBGIVx0C025736 for ; Tue, 16 Dec 2003 13:32:00 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hBGIVxMl026323 for ; Tue, 16 Dec 2003 13:31:59 -0500 (EST) Message-ID: <3FDF4FDD.1090402@mhof.com> Date: Tue, 16 Dec 2003 13:33:01 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Request to Publish: draft-ietf-opes-ocp-core-04 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Please publish the attached draft-ietf-opes-ocp-core-04.txt as an OPES > working group Internet Draft. This is a second request for the same > draft. I attached the wrong (-03) version of the draft to the first > request. The bug was caught by Dinara Suleymanova. This updated version addresses issues from our WGLC. Since there were quite some changes, please check out the updated version. We'll forward this version to IESG on Friday this week. Thanks to Alex for aggressively pushing forward with this document! -Markus From mrcongtu@yahoo.com Wed Dec 17 06:07:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03183 for ; Wed, 17 Dec 2003 06:07:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWZX1-0006er-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 06:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWZX1-0006ek-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 06:07:55 -0500 Received: from dt017nf1.san.rr.com ([24.30.132.241] helo=winxp-2x-p3-866) by ietf-mx with esmtp (Exim 4.12) id 1AWZX0-0006eg-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 06:07:55 -0500 Reply-To: "CongTu" From: "CongTu" To: Subject: Vietnam talks for under 3 cents a minute Date: Wed, 17 Dec 2003 03:07:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=AWL,EXCUSE_14, FORGED_MUA_OUTLOOK,FORGED_YAHOO_RCVD,MSGID_FROM_MTA_SHORT autolearn=no version=2.60 Content-Transfer-Encoding: 7bit http://www.vndial.com Vietnam talks for under 3 cents a minute New PCToPhone technology One minute rounding No monthly fee No gimmic Please come to http://www.vndial.com to find out more If you do not wish to receive this letter in the future, please reply to this email with the subject REMOVED From owner-ietf-openproxy@mail.imc.org Wed Dec 17 15:55:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04740 for ; Wed, 17 Dec 2003 15:55:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWihu-0001pu-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 15:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiht-0001pn-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 15:55:45 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AWihs-0001pk-00 for opes-archive@ietf.org; Wed, 17 Dec 2003 15:55:45 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHKYEib094783 for ; Wed, 17 Dec 2003 12:34:15 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBHKYE76094780 for ietf-openproxy-bks; Wed, 17 Dec 2003 12:34:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBHKYDib094775 for ; Wed, 17 Dec 2003 12:34:14 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02348; Wed, 17 Dec 2003 15:34:13 -0500 (EST) Message-Id: <200312172034.PAA02348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-04.txt Date: Wed, 17 Dec 2003 15:34:13 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-04.txt Pages : 77 Date : 2003-12-17 This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: an OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). OCP Core defined in this document consists of application-agnostic mechanisms essential for efficient support of typical adaptations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-17152050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-17152050.I-D@ietf.org> --OtherAccess-- --NextPart-- From t2eikbdq@aol.com Fri Dec 19 18:23:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03371 for ; Fri, 19 Dec 2003 18:23:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXTyC-0007Zf-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:23:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXTyB-0007ZY-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:23:43 -0500 Received: from d216-232-253-215.bchsia.telus.net ([216.232.253.215]) by ietf-mx with smtp (Exim 4.12) id 1AXTyA-0007ZS-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:23:42 -0500 Received: from [131.211.134.195] by d216-232-253-215.bchsia.telus.net SMTP id yKIi9nbwsJ9Sqk for ; Sat, 20 Dec 2003 05:15:36 +0600 Message-ID: <5-qso-u06b200p-gf418-86@ofdo13hrif> From: "Chase Rankin" Reply-To: "Chase Rankin" To: opes-archive@ietf.org Subject: Re: Due Payment, account Date: Sat, 20 Dec 03 05:15:36 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D.C_5F.934.3CB7C4BB13A" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=32.4 required=5.0 tests=BAD_CREDIT,CONSOLIDATE_DEBT, DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K,FORGED_IMS_HTML, FORGED_IMS_TAGS,FORGED_MUA_IMS,FREE_CONSULTATION,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,HTML_SHOUTING5, LINES_OF_YELLING,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, OBFUSCATING_COMMENT,UPPERCASE_25_50 autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 1.2 FREE_CONSULTATION BODY: Offers a consultation for nothing * 0.2 BAD_CREDIT BODY: Eliminate Bad Credit * 4.3 CONSOLIDATE_DEBT BODY: Consolidate debt, credit, or bills * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 1.8 HTML_SHOUTING5 BODY: HTML has very strong "shouting" markup * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 FORGED_IMS_TAGS IMS mailers can't send HTML in this format * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text * 0.3 UPPERCASE_25_50 message body is 25-50% uppercase * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --D.C_5F.934.3CB7C4BB13A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


k xs g ljfedyrujki oggpu --D.C_5F.934.3CB7C4BB13A-- From owner-ietf-openproxy@mail.imc.org Fri Dec 19 18:54:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04519 for ; Fri, 19 Dec 2003 18:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXUSN-0000sX-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:54:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXUSM-0000sQ-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:54:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AXUSM-0000sN-00 for opes-archive@ietf.org; Fri, 19 Dec 2003 18:54:54 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJNh9ib077513 for ; Fri, 19 Dec 2003 15:43:09 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBJNh9jp077512 for ietf-openproxy-bks; Fri, 19 Dec 2003 15:43:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBJNh8ib077506 for ; Fri, 19 Dec 2003 15:43:08 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04243305pcs.eatntn01.nj.comcast.net[68.38.30.212]) by comcast.net (rwcrmhc11) with ESMTP id <20031219234305013006v4p6e> (Authid: mhofmann); Fri, 19 Dec 2003 23:43:05 +0000 Message-ID: <3FE38D0A.2030603@mhof.com> Date: Fri, 19 Dec 2003 18:43:06 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Request to Publish: draft-ietf-opes-ocp-core-04 References: <3FDF4FDD.1090402@mhof.com> In-Reply-To: <3FDF4FDD.1090402@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, since there was no additional feedback, we've forwarded this draft to IESG for consideration as proposed standard. Thanks to everybody who contributed to the draft, but in particular to Alex who put in a lot of overtime for finishing it before Xmas. Thanks, Markus Markus Hofmann wrote: > > Alex Rousskov wrote: > >> Please publish the attached draft-ietf-opes-ocp-core-04.txt as an OPES >> working group Internet Draft. This is a second request for the same >> draft. I attached the wrong (-03) version of the draft to the first >> request. The bug was caught by Dinara Suleymanova. > > > This updated version addresses issues from our WGLC. Since there were > quite some changes, please check out the updated version. We'll forward > this version to IESG on Friday this week. > > Thanks to Alex for aggressively pushing forward with this document! > > -Markus From owner-ietf-openproxy@mail.imc.org Tue Dec 23 19:15:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21004 for ; Tue, 23 Dec 2003 19:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYwgj-0006HS-00 for opes-archive@ietf.org; Tue, 23 Dec 2003 19:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYwew-0006F5-00 for opes-archive@ietf.org; Tue, 23 Dec 2003 19:13:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AYweJ-0006Bc-00 for opes-archive@ietf.org; Tue, 23 Dec 2003 19:13:15 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNNpgib066671 for ; Tue, 23 Dec 2003 15:51:42 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBNNpfMu066670 for ietf-openproxy-bks; Tue, 23 Dec 2003 15:51:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from postale.fourelle.com ([199.26.153.90]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNNpcib066659 for ; Tue, 23 Dec 2003 15:51:41 -0800 (PST) (envelope-from kramadas@venturiwireless.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C9AF.1B1092E4" Subject: Usage/ Applicability question Date: Tue, 23 Dec 2003 15:47:20 -0800 Message-ID: <2F6114FBB1915B48B96170AE7D4BEAB2042AC7@postale.fourelle.com> Thread-Topic: Usage/ Applicability question thread-index: AcPJrxkU0j/Sbj2ySOK0m6/u6xiqlA== From: "Krishna Ramadas" To: Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C9AF.1B1092E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I work for a wireless appliance company and we have been looking at the drafts produced by this working committee. I am interested in utilizing the framework created by OPES for implementing distributed solutions. While the drafts appear to lead me to a potential framework, I am not sure about a couple of points. Perhaps, someone can help guide me on two topics =20 Background ------------------ Our solution consists of distributed platforms that carry HTTP content and process the traffic along the path. The first box processes traffic from a "producer" and hands it over to a second box which performs additional processing before it is handed off to a "consumer". Box-1 and box-2 are OPES processors, to use the terminology applied in the drafts. The first box is a load balancer/content switch gateway. The second box is a wireless content optimizer. In this solution, the load balancer/content switch gateway is the primary "collector" of billing information, and the content optimizer provides "corrections" to the billing record based on the amount of traffic that is compressed/optimized. =20 Usage Question We would like HTTP billing records to be collected for HTTP sessions. We would like the two boxes to exchange billing update information, based upon HTTP transactions within the session. We would like to utilize OCP to control the process of record exchange between the two boxes. There is no call-out/dispatcher relationship between the two boxes. From my interpretation of the use case scenario, I need a dispatcher/call-out relationship to apply the procedure specified in the drafts: Is this a true assumption?=20 =20 Will/Can a use case extension be made for solution such as the one that I have described above? We are trying to use OCP between two OPES processors. We plan to support in-line tracing, but HTTP adaptation will be handled independently by the OPES entities (box-1 and box-2) along the way. The OPES entities will only exchanging control records related to usage and billing on a per session-transaction basis. The OPES entities would also, independently, apply Policy specifications. =20 Can OPC be applied to a situation where traffic adaptation is not controlled by the OPC protocol, but only the usage records are exchanged over the OPC protocol? Can OPC be used only to signal sessions and transactions so that usage records can be associated with them? =20 Thanks Krishna Ramadas Venturi Wireless Networks ------_=_NextPart_001_01C3C9AF.1B1092E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I work for a wireless appliance company and we have = been looking at the drafts produced by this working committee. I am interested in = utilizing the framework created by OPES for implementing distributed solutions. = While the drafts appear to lead me to a potential framework, I am not sure about a = couple of points. Perhaps, someone can help guide me on two = topics

 

Background

------------------

Our solution consists of distributed platforms that = carry HTTP content and process the traffic along the path. The first box = processes traffic from a “producer” and hands it over to a second box = which performs additional processing before it is handed off to a = “consumer”. Box-1 and box-2 are OPES processors, to use the terminology applied in = the drafts. The first box is a load balancer/content switch gateway. The = second box is a wireless content optimizer. In this solution, the load = balancer/content switch gateway is the primary “collector” of billing = information, and the content optimizer provides “corrections” to the = billing record based on the amount of traffic that is compressed/optimized.

 

Usage = Question

We would like HTTP billing records to be collected = for HTTP sessions. We would like the two boxes to exchange billing update = information, based upon HTTP transactions within the session. We would like to = utilize OCP to control the process of record exchange between the two boxes. There = is no call-out/dispatcher relationship between the two boxes. From my interpretation of the use = case scenario, I need a dispatcher/call-out relationship to apply the = procedure specified in the drafts: Is this a true assumption? =

 

Will/Can a use case extension be made for solution = such as the one that I have described above? We are trying to use OCP between = two OPES processors. We plan to support in-line tracing, but HTTP adaptation will = be handled independently by the OPES entities (box-1 and box-2) along the = way. The OPES entities will only exchanging control records related to usage and = billing on a per session-transaction basis. The OPES entities would also, independently, apply Policy specifications.

 

Can OPC be applied to a situation where traffic = adaptation is not controlled by the OPC protocol, but only the usage records are = exchanged over the OPC protocol? Can OPC be used only to signal sessions and = transactions so that usage records can be associated with = them?

 

Thanks

Krishna = Ramadas

Venturi= Wireless Networks

=00 ------_=_NextPart_001_01C3C9AF.1B1092E4-- From owner-ietf-openproxy@mail.imc.org Wed Dec 24 01:01:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29477 for ; Wed, 24 Dec 2003 01:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZ25X-0000cP-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 01:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZ23i-0000bV-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 00:59:51 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AZ23P-0000a2-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 00:59:31 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBO5mUib083876 for ; Tue, 23 Dec 2003 21:48:30 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBO5mUb6083875 for ietf-openproxy-bks; Tue, 23 Dec 2003 21:48:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBO5mTib083869 for ; Tue, 23 Dec 2003 21:48:29 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBO5mVk3083725; Tue, 23 Dec 2003 22:48:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBO5mVIC083724; Tue, 23 Dec 2003 22:48:31 -0700 (MST) (envelope-from rousskov) Date: Tue, 23 Dec 2003 22:48:31 -0700 (MST) From: Alex Rousskov To: Krishna Ramadas cc: ietf-openproxy@imc.org Subject: Re: Usage/ Applicability question In-Reply-To: <2F6114FBB1915B48B96170AE7D4BEAB2042AC7@postale.fourelle.com> Message-ID: References: <2F6114FBB1915B48B96170AE7D4BEAB2042AC7@postale.fourelle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 23 Dec 2003, Krishna Ramadas wrote: > I work for a wireless appliance company and we have been looking at > the drafts produced by this working committee. I am interested in > utilizing the framework created by OPES for implementing distributed > solutions. First of all, thank you for sharing details about your use case and asking for our opinions. > We would like HTTP billing records to be collected for HTTP > sessions. We would like the two boxes to exchange billing update > information, based upon HTTP transactions within the session. We > would like to utilize OCP to control the process of record exchange > between the two boxes. Since you are saying (below) that the process does not involve exchanging HTTP messages (just metadata about them), OCP is just a candidate protocol to do the job. It will work, but I would try to find a better fit before making the final selection. > There is no call-out/dispatcher relationship between the two boxes. > From my interpretation of the use case scenario, I need a > dispatcher/call-out relationship to apply the procedure specified in > the drafts: Is this a true assumption? The primary purpose of OCP is to exchange application messages and their meta information between two agents. The callout/dispatcher relationship is mostly undefined and has little effect on OCP Core design. Some OCP Core optimizations assume that the processor (agent1) receives original application data from the previous application hop and will eventually forward adapted application data to the next application hop, after/while talking to the callout server (agent2). It is OK, in principle, for agent2 to be an OPES processor as well. If no application data is exchanged, then some OCP Core optimizations will not be used. Thus, you might be able to find a smaller/simpler than OCP protocol that will do the job. > Will/Can a use case extension be made for solution such as the one > that I have described above? We are trying to use OCP between two > OPES processors. Interesting! Personally, I think that what you are trying to do should be within OPES scope, even if the OPES Architecture document is too rigid to imply that. IMO, any application message adaptation by an intermediary is within OPES scope (with some use cases being less/more "interesting" or "trivial" than others). Again, OCP may or may not be the best protocol to use. > We plan to support in-line tracing, but HTTP adaptation will be > handled independently by the OPES entities (box-1 and box-2) along > the way. The OPES entities will only exchanging control records > related to usage and billing on a per session-transaction basis. The > OPES entities would also, independently, apply Policy > specifications. Understood. > Can OPC be applied to a situation where traffic adaptation is not > controlled by the OPC protocol, but only the usage records are > exchanged over the OPC protocol? OCP should work in such an environment but is not designed for it. The question is whether you would be better off with a different protocol. Are you looking at OCP simply because it is a part of the OPES framework, or do you like some of the OCP properties? Have you considered using other existing or custom-made protocols? > Can OPC be used only to signal sessions and transactions so that > usage records can be associated with them? Yes, I believe so. You will need to define an OCP profile for that, of course (just like HTTP Adaptations draft defines a profile for adapting HTTP messages with OCP). Please keep us posted on your progress in finding the right protocol for your needs. Alex. From eie9vhi@userzap.de Wed Dec 24 16:53:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24683 for ; Wed, 24 Dec 2003 16:53:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZGx1-0002Ej-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 16:53:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZGtb-0002Ca-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 16:50:25 -0500 Received: from [200.90.109.57] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AZGr9-00029U-00 for opes-archive@ietf.org; Wed, 24 Dec 2003 16:47:51 -0500 Received: from [111.11.41.133] by 132.151.6.1 with ESMTP id <279653-19163>; Wed, 24 Dec 2003 20:02:39 -0200 Message-ID: From: "Heather Olson" Reply-To: "Heather Olson" To: opes-archive@ietf.org Subject: Discounted OEM for sale Windows-Office-Adobe-Autodesk swallow Date: Wed, 24 Dec 2003 20:02:39 GMT X-Mailer: Bahomater 2.012 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".0B.6.A_.__5EF13E.BC__" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.4 required=5.0 tests=BIZ_TLD,CLICK_BELOW, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 --.0B.6.A_.__5EF13E.BC__ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
ELIMINATE YOUR CREDIT CARD DEBT = WITHOUT BANKRUPTCY!
Tired of making minimum pay= ments and barely getting by?

This is NOT co= nsolidation or negotiation...

This is COMPLETE DEBT ELIMIN= ATION

STOP MAKING PAYMENTS IMMEDIATELY!=
Are you drowning in debt?
Here's what we can do for YOU...
    <= li>Terminate your credit card debt!
  1. Allow you to stop making payments i= mmediately!
  2. Obtain a ZERO BALANCE statement from your creditors!
Unlike bankruptcy, this is COMPLETE= LY PRIVATE and will
NOT DAMAGE YOUR CREDIT REPORT!
You will NOT lose your home or any other a= ssets!











Please end future announcements
3D"Click 3D"Click 3D"Click
3D""
Same day shipping (See site for details= ) 3D""
<= /TD> 4-CD-OEM&nb= sp;
3D""
Windows XP Suites
Adobe software
Clearance
Corel Draw/Corel Ventura
Games
3D Studio Max
Operating Systems
Utilities
=

Specials good thru 12/31/03.

Please use di= scount code mail22091 to = receive these prices. 
Microsoft Windows XP Professional OEM 

3D"PowerQuest Only $39.95  
Savings -$59.95

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. 3D"PowerQuest
* Use this Discount Code at Checkout: mail22091=

Adobe Photoshop 7.0 OEM

3D"Microsoft Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. 3D"Microsoft
* Use this Discount Code at Checkout: mail22091=

Microsoft Office XP Professional OEM

3D"Symantec Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing 3D"Symantec
* Use this Discount Code at Checkout: mail22091=


Adobe Illustrator 10 OEM

3D"Symantec Only $59.95
Savings -$215.50

EN= HANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  3D"Symantec
* Use this Discount Code at Checkout: mail22091=




         &n= bsp;           &nbs= p;            =             &n= bsp;   1998-2003 OEM-CD, All Rights Reserved
rworbqcguo jo wnjmukkgd aui --.0B.6.A_.__5EF13E.BC__-- From yidqnvcajq@google.com Fri Dec 26 13:30:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00254 for ; Fri, 26 Dec 2003 13:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZwjc-0003pJ-00 for opes-archive@ietf.org; Fri, 26 Dec 2003 13:30:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZwhm-0003kd-00 for opes-archive@ietf.org; Fri, 26 Dec 2003 13:28:59 -0500 Received: from [200.85.70.103] (helo=google.com) by ietf-mx with smtp (Exim 4.12) id 1AZwgE-0003fC-00 for opes-archive@ietf.org; Fri, 26 Dec 2003 13:27:22 -0500 From: Red Omuno To: opes-archive Subject: Historia Mundial del Cine X-Priority: 3 X-MSMail-Priority: Normal Reply-To: Red Omuno mime-version: 1.0 content-type: multipart/mixed; boundary="qzsoft_directmail_seperator" Message-Id: Date: Fri, 26 Dec 2003 13:27:22 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.5 required=5.0 tests=HTML_MESSAGE,MIME_BASE64_TEXT, MIME_HTML_ONLY,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer --qzsoft_directmail_seperator Content-Type: text/html; charset="DEFAULT" Content-Transfer-Encoding: base64 PGh0bWw+CjxoZWFkPgo8dGl0bGU+UmVkT211bmRvIGUtbWFpbDwvdGl0bGU+CjxtZXRhIGh0dHAt ZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5 LTEiPgo8L2hlYWQ+Cjxib2R5IGJnY29sb3I9IiNGRkZGRkYiIGxlZnRtYXJnaW49IjAiIHRvcG1h cmdpbj0iMCIgbWFyZ2lud2lkdGg9IjAiIG1hcmdpbmhlaWdodD0iMCI+Cjx0YWJsZSB3aWR0aD0i MTAwJSIgIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4KICA8dHI+ CiAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiPjx0YWJsZSB3aWR0aD0iNTAwIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+CiAgICAgIDx0ciBhbGln bj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSIgYmdjb2xvcj0iIzAwMDAwMCI+CiAgICAgICAgPHRk IGhlaWdodD0iMjAiIGNvbHNwYW49IjMiIGNsYXNzPSJvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJW ZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwOi8vd3d3 LnJlZG9tdW5kby5jb20vY2dpLWJpbi9vYnNlcXVpby5wbCIgY2xhc3M9InJvIj48Zm9udCBjb2xv cj0iI0ZGRkZGRiI+PHN0cm9uZz48Zm9udCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNl cmlmIj5QVUJMSUNBQ0lPTkVTIHwgRS1CT09LUyB8IEVOQ0lDTE9QRURJQVMgfCBOT1ZFREFERVMg fCBQJk9hY3V0ZTtTVEVSIHwgT0JTRVFVSU9TPC9mb250Pjwvc3Ryb25nPjwvZm9udD48L2E+PGZv bnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHN0cm9uZz48Zm9udCBjb2xv cj0iI0ZGRkZGRiI+PC9zcGFuPjwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9mb250PjwvdGQ+CiAg ICAgICAgPC90cj4KICAgICAgPHRyPgogICAgICAgIDx0ZCB3aWR0aD0iOSIgdmFsaWduPSJ0b3Ai IGJnY29sb3I9IiMwMDAwMDAiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20vZW1h aWwvc3BhY2VyLmdpZiIgd2lkdGg9IjMiIGhlaWdodD0iMSI+IDwvdGQ+CiAgICAgICAgPHRkIHdp ZHRoPSI0MTUiIHZhbGlnbj0idG9wIiBiZ2NvbG9yPSIjMDAwMDAwIj48dGFibGUgd2lkdGg9IjEw MCUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjEiIGNlbGxzcGFjaW5nPSIwIj4KICAgICAgICAg IDx0cj4KICAgICAgICAgICAgPHRkIHdpZHRoPSI3MyIgYmdjb2xvcj0iIzAwMDAwMCI+PGltZyBz cmM9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9lbWFpbC9sb2dvX25lZ3JvLmdpZiIgd2lkdGg9 IjczIiBoZWlnaHQ9IjU2Ij48L3RkPgogICAgICAgICAgICA8dGQgd2lkdGg9IjM1NSIgYmdjb2xv cj0iIzAwMDAwMCI+PGltZyBzcmM9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9lbWFpbC90aXR1 bG9fbmVncm8uZ2lmIiB3aWR0aD0iMzM0IiBoZWlnaHQ9IjU2Ij48L3RkPgogICAgICAgICAgPC90 cj4KICAgICAgICAgIDx0ciBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSI+CiAgICAgICAg ICAgIDx0ZCBjb2xzcGFuPSIyIiBiZ2NvbG9yPSIwODM4NkIiPjx0YWJsZSB3aWR0aD0iNDAwIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIyIiBjZWxscGFkZGluZz0iMiI+CiAgICAgICAgICAgICAg ICA8dHI+CiAgICAgICAgICAgICAgICAgIDx0ZD4KICAgICAgICAgICAgICAgICAgICAgIDxwIGNs YXNzPSJyb3BvciI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZiI+PHN0cm9uZz48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiI+UkVET01VTkRPLkNP TSBwcmVzZW50YSBlbiBleGNsdXNpdmEgbXVuZGlhbCBsYSB2ZXJzaSZvYWN1dGU7biBlbGVjdHIm b2FjdXRlO25pY2EgZGUgbGFzIHB1YmxpY2FjaW9uZXMgJnF1b3Q7Q3Imb2FjdXRlO25pY2EgR2Vu ZXJhbCBkZWwgU2lnbG8gWFgmcXVvdDsgKDEwIHRvbW9zKSwgJnF1b3Q7SGlzdG9yaWEgTXVuZGlh bCBkZWwgQ2luZSZxdW90OyAoMTQgdG9tb3MpIGUgJnF1b3Q7SGlzdG9yaWEgR2VuZXJhbCBkZWwg RiZ1YWN1dGU7dGJvbCBNdW5kaWFsJnF1b3Q7ICgxMiB0b21vcyksIGVuIGZvcm1hdG8gZGlnaXRh bCAoUERGKS48L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvcD4KICAgICAgICAgICAgICAgICAgICAg IDxwPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxz dHJvbmc+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiPlN1c2NyJmlhY3V0ZTtiYXNlIGhv eSBtaXNtbyB5IG9idGVuZ2EgZXN0YSBwdWJsaWNhY2kmb2FjdXRlO24gY29uIGRlc2NhcmdhIGlu bWVkaWF0YSBlbiBjdWFscXVpZXIgbHVnYXIgZGVsIG11bmRvLjwvZm9udD48L3N0cm9uZz48L2Zv bnQ+PC9wPgogICAgICAgICAgICAgICAgICAgICAgPHA+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJp YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHN0cm9uZz48Zm9udCBjb2xvcj0iI0ZGRkZGRiIg c2l6ZT0iMiI+RGVzY2FyZ3VlIGRlIG1hbmVyYSBncmF0dWl0YSB1bmEgbXVlc3RyYSBwYXJhIHF1 ZSBjb21wcnVlYmUgbGEgYWx0YSBjYWxpZGFkIGRlIG51ZXN0cmFzIHB1YmxpY2FjaW9uZXMuPC9m b250Pjwvc3Ryb25nPjwvZm9udD48L3A+CiAgICAgICAgICAgICAgICAgIDwvdGQ+CiAgICAgICAg ICAgICAgICA8L3RyPgogICAgICAgICAgICA8L3RhYmxlPjwvdGQ+CiAgICAgICAgICA8L3RyPgog ICAgICAgICAgPHRyIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlkZGxlIj4KICAgICAgICAgICAg PHRkIGNvbHNwYW49IjIiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20vZW1haWwv c3BhY2VyLmdpZiIgd2lkdGg9IjEiIGhlaWdodD0iMSI+PC90ZD4KICAgICAgICAgIDwvdHI+CiAg ICAgICAgICA8dHIgYmdjb2xvcj0iMzEzMDMxIj4KICAgICAgICAgICAgPHRkIGNvbHNwYW49IjIi IGNsYXNzPSJ0ZXh0b19lbWFpbDEiPjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgY29sb3I9IiNG RkZGRkYiIHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiPjxzdHJvbmc+Q1JPTklDQSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAoUERGKTwvc3Ryb25nPiA8L2ZvbnQ+PC9kaXY+PC90ZD4KICAgICAgICAgIDwvdHI+CiAgICAg ICAgICA8dHIgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IjMxMzAzMSI+CiAg ICAgICAgICAgIDx0ZCBjb2xzcGFuPSIyIj48dGFibGUgd2lkdGg9IjM4MSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjMiPgogICAgICAgICAgICAgICAgPHRyPgogICAg ICAgICAgICAgICAgICA8dGQgd2lkdGg9IjU4IiByb3dzcGFuPSIyIj48YSBocmVmPSJodHRwOi8v d3d3LnJlZG9tdW5kby5jb20vY2dpLWJpbi9vYnNlcXVpby5wbCI+PGltZyBzcmM9Imh0dHA6Ly93 d3cucmVkb211bmRvLmNvbS9lbWFpbC9jcm9uaWNhLmpwZyIgd2lkdGg9IjkxIiBoZWlnaHQ9IjEy MCIgYm9yZGVyPSIwIj48L2E+PC90ZD4KICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSIyNDIi PjxzdHJvbmc+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFy aWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkNyJm9hY3V0ZTtuaWNhIEdlbmVyYWwgZGVsIFNp Z2xvIFhYIDwvZm9udD48L3N0cm9uZz4gICAgICAgICAgICAgICAgICAgIDxwPjwvcD48Zm9udCBj b2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwg c2Fucy1zZXJpZiI+TGFzIG5vdGljaWFzIG0mYWFjdXRlO3MgcmVzYWx0YW50ZXMgcXVlIGNvbm1v dmllcm9uIGEgbGEgaHVtYW5pZGFkIGVuIAogIGxvcyAmdWFjdXRlO2x0aW1vcyAxMDAgYSZudGls ZGU7b3MgbSZhYWN1dGU7cyB0dXJidWxlbnRvcyB5IGZhc2NpbmFudGVzLCBlbiAxMCAKICB0b21v cyBkZSBjb2xlY2NpJm9hY3V0ZTtuLiBEaXNwb25pYmxlIGNhZGEgMTUgZCZpYWN1dGU7YXMgZW4g Zm9ybWF0byAoUERGKS4gPC9mb250PjwvcD48L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAg ICAgICAgICAgICAgIDx0cj4KICAgICAgICAgICAgICAgICAgPHRkIGFsaWduPSJyaWdodCIgdmFs aWduPSJib3R0b20iIGNsYXNzPSJzdHlsZXIxIj48Zm9udCBjb2xvcj0iI0ZGRkZDQyIgc2l6ZT0i MSIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+KDEwIHRvbW9zKTwvZm9udD48 L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgPC90YWJsZT48L3RkPgogICAg ICAgICAgPC90cj4KICAgICAgICAgIDx0ciBiZ2NvbG9yPSIzMTMwMzEiPgogICAgICAgICAgICA8 dGQgY29sc3Bhbj0iMiI+PGRpdiBhbGlnbj0iY2VudGVyIiBjbGFzcz0icm9wb3IiPjxmb250IGNv bG9yPSIjRkZGRkZGIj48c3Ryb25nPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkNJTkUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIChQREYpPC9mb250Pjwvc3Ryb25nPjwvZm9udD48L2Rpdj48L3RkPgog ICAgICAgICAgPC90cj4KICAgICAgICAgIDx0ciBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIg Ymdjb2xvcj0iMzEzMDMxIj4KICAgICAgICAgICAgPHRkIGNvbHNwYW49IjIiPjx0YWJsZSB3aWR0 aD0iMzg1IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIzIiBjZWxscGFkZGluZz0iMyI+CiAgICAg ICAgICAgICAgICA8dHI+CiAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNTgiIHJvd3NwYW49 IjIiPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9jZ2ktYmluL29ic2VxdWlvLnBs Ij48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWRvbXVuZG8uY29tL2VtYWlsL2NpbmUuanBnIiB3aWR0 aD0iOTEiIGhlaWdodD0iMTIwIiBib3JkZXI9IjAiPjwvYT48L3RkPgogICAgICAgICAgICAgICAg ICA8dGQgd2lkdGg9IjI0MiI+PHN0cm9uZz48c3BhbiBjbGFzcz0icm9wb3IiPjxmb250IGNvbG9y PSIjRkZGRkZGIiBzaXplPSIyIiBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmIj5IaXN0b3JpYSBNdW5kaWFsCiAgICAgICAgICAgIGRlbCBDaW5lCiAgICAgICAgICAg ICAgICAgIDwvZm9udD4gPC9zcGFuPjwvc3Ryb25nPgogICAgICAgICAgICAgICAgICAgIDxwIGFs aWduPSJqdXN0aWZ5IiBjbGFzcz0ic3R5bGVyMiI+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9 IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkVsIG0mYWFj dXRlO3MgY29tcGxldG8gcmVjb3JyaWRvIHBvciBlbCBjaW5lIGVzdCZhYWN1dGU7IGEgc3UgZGlz cG9zaWNpJm9hY3V0ZTtuIGVuIGVzdGEgY29sZWNjaSZvYWN1dGU7biBxdWUgbGUgcGVybWl0aXIm YWFjdXRlOyBjb25vY2VyIHRvZG8gYWNlcmNhIGRlbCBzJmVhY3V0ZTtwdGltbyBhcnRlLiBDYWRh IDEwIGQmaWFjdXRlO2FzIGVuIGZvcm1hdG8gKFBERikuPC9mb250PjwvcD48L3RkPgogICAgICAg ICAgICAgICAgPC90cj4KICAgICAgICAgICAgICAgIDx0cj4KICAgICAgICAgICAgICAgICAgPHRk IGFsaWduPSJyaWdodCIgdmFsaWduPSJib3R0b20iIGNsYXNzPSJzdHlsZXIxIj48Zm9udCBjb2xv cj0iI0ZGRkZDQyIgc2l6ZT0iMSIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+ KDE0IHRvbW9zKTwvZm9udD48L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAg PC90YWJsZT48L3RkPgogICAgICAgICAgPC90cj4KICAgICAgICAgIDx0ciBiZ2NvbG9yPSIzMTMw MzEiPgogICAgICAgICAgICA8dGQgY29sc3Bhbj0iMiI+PGRpdiBhbGlnbj0iY2VudGVyIiBjbGFz cz0icm9wb3IiPjxzdHJvbmc+PGZvbnQgY29sb3I9IiNGRkZGRkYiIHNpemU9IjIiIGZhY2U9IlZl cmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkZVVEJPTCAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIChQREYpPC9mb250Pjwvc3Ryb25nPjwvZGl2Pjwv dGQ+CiAgICAgICAgICA8L3RyPgogICAgICAgICAgPHRyIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0i dG9wIiBiZ2NvbG9yPSIzMTMwMzEiPgogICAgICAgICAgICA8dGQgY29sc3Bhbj0iMiI+PHRhYmxl IHdpZHRoPSIzODQiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjMiIGNlbGxwYWRkaW5nPSIzIj4K ICAgICAgICAgICAgICAgIDx0cj4KICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI5MyIgcm93 c3Bhbj0iMiI+PGEgaHJlZj0iaHR0cDovL3d3dy5yZWRvbXVuZG8uY29tL2NnaS1iaW4vb2JzZXF1 aW8ucGwiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20vZW1haWwvZnV0Ym9sLmpw ZyIgd2lkdGg9IjkxIiBoZWlnaHQ9IjEyMCIgYm9yZGVyPSIwIj48L2E+PC90ZD4KICAgICAgICAg ICAgICAgICAgPHRkIHdpZHRoPSIyNjMiPjxzdHJvbmc+PHNwYW4gY2xhc3M9InJvcG9yIj48Zm9u dCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iMiIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiI+SGlzdG9yaWEgR2VuZXJhbCBkZWwgRvp0Ym9sIE11bmRpYWwKICAgICAg ICAgICAgICAgICAgPC9mb250PiA8L3NwYW4+PC9zdHJvbmc+CiAgICAgICAgICAgICAgICAgICAg PHAgYWxpZ249Imp1c3RpZnkiIGNsYXNzPSJzdHlsZXIyIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiIg c2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+TGEg ZmFzY2luYW50ZSBoaXN0b3JpYSBkZWwgZiZ1YWN1dGU7dGJvbCBtdW5kaWFsIHB1ZWRlIHRlbmVy bGEgZW4gc3VzIG1hbm9zIGRlIGlubWVkaWF0byBlbiBlc3RhIGNvbGVjY2kmb2FjdXRlO24gZGUg MTIgdG9tb3MuIENhZGEgMTAgZCZpYWN1dGU7YXMgZW4gZm9ybWF0byAoUERGKS48L2ZvbnQ+PC9w PjwvdGQ+CiAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAgPHRyPgogICAgICAg ICAgICAgICAgICA8dGQgaGVpZ2h0PSIxOSIgYWxpZ249InJpZ2h0IiB2YWxpZ249ImJvdHRvbSIg Y2xhc3M9InN0eWxlcjEiPjxmb250IGNvbG9yPSIjRkZGRkNDIiBzaXplPSIxIiBmYWNlPSJBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4oMTIgdG9tb3MpPC9mb250PjwvdGQ+CiAgICAgICAg ICAgICAgICA8L3RyPgogICAgICAgICAgICA8L3RhYmxlPjwvdGQ+CiAgICAgICAgICA8L3RyPgog ICAgICAgICAgPHRyIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIj4KICAgICAgICAgICAgPHRk IGNvbHNwYW49IjIiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20vZW1haWwvc3Bh Y2VyLmdpZiIgd2lkdGg9IjEiIGhlaWdodD0iMSI+PC90ZD4KICAgICAgICAgIDwvdHI+CiAgICAg ICAgICA8dHIgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IjlDMDAwMCI+CiAg ICAgICAgICAgIDx0ZCBjb2xzcGFuPSIyIj48dGFibGUgd2lkdGg9IjQxMCIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2VsbHBhZGRpbmc9IjIiPgogICAgICAgICAgICAgICAgICA8dHI+CiAg ICAgICAgICAgICAgICAgICAgPHRkIGhlaWdodD0iMTc2IiB2YWxpZ249InRvcCI+PHN0cm9uZz48 c3BhbiBjbGFzcz0iYW1hcmlsbG8iPjxmb250IGNvbG9yPSIjRkZGRkNDIiBzaXplPSIzIiBmYWNl PSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5SZXBvcnQKICAgICAgICAgICAgICAgICAg ICA8L2ZvbnQ+IDwvc3Bhbj48L3N0cm9uZz4KICAgICAgICAgICAgICAgICAgICAgIDxwIGFsaWdu PSJsZWZ0IiBjbGFzcz0icm9wb3IiPjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+PGZvbnQgY29sb3I9IiNGRkZGRkYiPkNh ZGEgMTUgZCZpYWN1dGU7YXMgcmVjaWJpciZhYWN1dGU7IHNpbiBjb3N0byB1biBlamVtcGxhciBk ZSBSZXBvcnQsIHVuYSByZXZpc3RhIGRpZ2l0YWwgKFBERikgcXVlIGxlIGluZm9ybWFyJmFhY3V0 ZTsgc29icmUgZWwgYWNvbnRlY2VyIGRlbCBmYXNjaW5hbnRlIG11bmRvIGRlbCBjaW5lIGRlc2Rl IHN1cyBpbmljaW9zIGhhc3RhIGxhIGFjdHVhbGlkYWQsIGRlIGxvcyBzdWNlc29zIGRlbCBmJnVh Y3V0ZTt0Ym9sIG11bmRpYWwsIHkgYWRlbSZhYWN1dGU7cyBkZSBsb3MgaGVjaG9zIG5vdGljaW9z b3MgcXVlIGNvbm1vdmllcm9uIGEgbGEgaHVtYW5pZGFkIGVuIGxvcyAmdWFjdXRlO2x0aW1vcyAx MDAgYSZudGlsZGU7b3M8L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvcD4KICAgICAgICAgICAgICAg ICAgICAgIDxwIGFsaWduPSJsZWZ0IiBjbGFzcz0icm9wb3IiPjxmb250IHNpemU9IjEiIGZhY2U9 IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxzdHJvbmc+PGZvbnQgY29s b3I9IiNGRkZGRkYiPlN1c2NyaWJhc2UgaG95IG1pc21vIGEKICAgICAgICAgICAgICAgICAgICAg IHd3dy5yZWRvbXVuZG8uY29tIHkgcmVjaWJpciZhYWN1dGU7IGNhZGEgMTUgZCZpYWN1dGU7YXMg dW4gZWplbXBsYXIgZGUgUmVwb3J0LjwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9wPjxwPiZuYnNw OzwvcD48L3RkPgogICAgICAgICAgICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249 Im1pZGRsZSI+PGEgaHJlZj0iaHR0cDovL3d3dy5yZWRvbXVuZG8uY29tL2NnaS1iaW4vb2JzZXF1 aW8ucGwiPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20vZW1haWwvcmVwb3J0ZS5q cGciIHdpZHRoPSIxMzAiIGhlaWdodD0iMTcwIiBib3JkZXI9IjAiPjwvYT48L3RkPgogICAgICAg ICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAgPC90YWJsZT4KICAgICAgICAgICAgICAg IDwvdGQ+CiAgICAgICAgICA8L3RyPgogICAgICAgIDwvdGFibGU+PC90ZD4KICAgICAgICA8dGQg d2lkdGg9IjI3NiIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IiM2MzY1NjMiPjx0YWJsZSB3aWR0aD0i MTgyIiAgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPgogICAgICAg ICAgPHRyPgogICAgICAgICAgICA8dGQ+PGltZyBzcmM9Imh0dHA6Ly93d3cucmVkb211bmRvLmNv bS9lbWFpbC9hZHF1aWVyYV90b3AuanBnIiB3aWR0aD0iMTgyIiBoZWlnaHQ9IjQwIj48L3RkPgog ICAgICAgICAgPC90cj4KICAgICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkIGhlaWdodD0iMTI0 IiBhbGlnbj0iY2VudGVyIiB2YWxpZ249Im1pZGRsZSIgYmdjb2xvcj0iIzRCNjlBNyIgY2xhc3M9 InRleHRvX2VtYWlsMSBzdHlsZTYiPjxzdHJvbmc+PGEgaHJlZj0iaHR0cDovL3d3dy5yZWRvbXVu ZG8uY29tL2NnaS1iaW4vb2JzZXF1aW8ucGwiPjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIy IiBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5Qb3IgaGFiZXIg cmVjaWJpZG8gZXN0ZSBlLW1haWwgdXN0ZWQgc2UgaGEgaGVjaG8gYWNyZWVkb3IgZGVsIGUtYm9v ayBIaXN0b3JpYSBHZW5lcmFsPGJyPgogIGRlbCBGJnVhY3V0ZTt0Ym9sIGRlIDUyIHAmYWFjdXRl O2dpbmFzLDxicj4KICAgICAgICAgICAgICBzaW4gY29zdG8gYWxndW5vLjwvZm9udD48L2E+PC9z dHJvbmc+PC90ZD4KICAgICAgICAgIDwvdHI+CiAgICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0 ZCBoZWlnaHQ9IjE1NCIgYWxpZ249ImNlbnRlciIgdmFsaWduPSJtaWRkbGUiIGJnY29sb3I9IiM0 RjAxMDEiPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9jZ2ktYmluL29ic2VxdWlv LnBsIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWRvbXVuZG8uY29tL2VtYWlsL2NvbGxlY2Npb24u anBnIiB3aWR0aD0iMTc2IiBoZWlnaHQ9IjE0NSIgYm9yZGVyPSIwIj48L2E+PC90ZD4KICAgICAg ICAgIDwvdHI+CiAgICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2 YWxpZ249InRvcCIgYmdjb2xvcj0iIzAwMDAwMCI+CiAgICAgICAgICAgICAgPHRhYmxlIHdpZHRo PSIxMDAlIiAgYm9yZGVyPSIwIiBhbGlnbj0iY2VudGVyIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPgogICAgICAgICAgICAgICAgPHRyPgogICAgICAgICAgICAgICAgICA8dGQgaGVp Z2h0PSI5NSIgYWxpZ249ImNlbnRlciIgdmFsaWduPSJtaWRkbGUiIGJnY29sb3I9IjYzNjU2MyIg Y2xhc3M9ImFtYXJpbGxvIj48c3Ryb25nPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVkb211bmRvLmNv bS9jZ2ktYmluL29ic2VxdWlvLnBsIj48Zm9udCBjb2xvcj0iI0ZGRkZDQyIgc2l6ZT0iMiIgZmFj ZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+QW1wbCZpYWN1dGU7ZSBzdSBjdWx0dXJh IGdlbmVyYWwgbGV5ZW5kbyBsYSBjb2xlY2NpJm9hY3V0ZTtuIEdyYW5kZXMgVGVtYXMgZW4gbGEg cXVlIGVsIGNvbm9jaW1pZW50byBkZXNjb25vY2UgbG9zIGwmaWFjdXRlO21pdGVzPC9mb250Pjwv YT48L3N0cm9uZz48L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICAgIDx0 cj4KICAgICAgICAgICAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlkZGxlIiBi Z2NvbG9yPSI2MzY1NjMiPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9jZ2ktYmlu L29ic2VxdWlvLnBsIj48aW1nIHNyYz0iaHR0cDovL3d3dy5yZWRvbXVuZG8uY29tL2VtYWlsL2Fk cXVpZXJhX3Bvc3Rlci5qcGciIHdpZHRoPSIxNzciIGhlaWdodD0iMjI5IiBib3JkZXI9IjAiPjwv YT48L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICAgIDx0cj4KICAgICAg ICAgICAgICAgICAgPHRkIGhlaWdodD0iMTAxIiBiZ2NvbG9yPSI2MzY1NjMiIGNsYXNzPSJsZXRy YV9hIj48ZGl2IGFsaWduPSJjZW50ZXIiIGNsYXNzPSJhbWFyaWxsbyI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PHN0cm9uZz48Zm9udCBjb2xvcj0i I0ZGRkZDQyI+SW5pY2llIHN1IGNvbGVjY2kmb2FjdXRlO24gZGUgZmFudCZhYWN1dGU7c3RpY29z IFAmb2FjdXRlO3N0ZXJzIGVuIHRhbWEmbnRpbGRlO28gZ2lnYW50ZSBhIHRyYXYmZWFjdXRlO3Mg ZGUgbnVlc3RyYXMgaW5vbHZpZGFibGVzIGltJmFhY3V0ZTtnZW5lcyA8L2ZvbnQ+PC9zdHJvbmc+ PC9mb250PjwvZGl2PjwvdGQ+CiAgICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICAgICAg PHRyPgogICAgICAgICAgICAgICAgICA8dGQgaGVpZ2h0PSIxNzYiIGJnY29sb3I9IiM2MzY1NjMi PjxkaXYgYWxpZ249ImNlbnRlciIgY2xhc3M9InN0eWxlMiI+PGEgaHJlZj0ibWFpbHRvOnVuc3Vi c2NyaWJlQHJlZG9tdW5kby5jb20iPjxpbWcgc3JjPSJodHRwOi8vd3d3LnJlZG9tdW5kby5jb20v ZW1haWwvYXF1aS5naWYiIHdpZHRoPSIxNzkiIGhlaWdodD0iMTcyIiBib3JkZXI9IjAiPjwvYT48 YnI+CiAgICAgICAgICAgICAgICAgIDwvZGl2PjwvdGQ+CiAgICAgICAgICAgICAgICA8L3RyPgog ICAgICAgICAgICA8L3RhYmxlPjwvdGQ+CiAgICAgICAgICA8L3RyPgogICAgICAgIDwvdGFibGU+ PC90ZD4KICAgICAgPC90cj4KICAgICAgPHRyIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0ibWlkZGxl IiBiZ2NvbG9yPSIjMDAwMDAwIj4KICAgICAgICA8dGQgaGVpZ2h0PSIyMCIgY29sc3Bhbj0iMyI+ PHNwYW4gY2xhc3M9Im8iPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly93d3cucmVkb211bmRvLmNvbS9jZ2kt YmluL29ic2VxdWlvLnBsIiBjbGFzcz0icm8iPjxmb250IGNvbG9yPSIjRkZGRkZGIj48c3Ryb25n Pjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPlBVQkxJQ0FDSU9ORVMg fCBFLUJPT0tTIHwgRU5DSUNMT1BFRElBUyB8IE5PVkVEQURFUyB8IFAmT2FjdXRlO1NURVIgfCBP QlNFUVVJT1M8L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvYT48Zm9udCBmYWNlPSJBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmIj48c3Ryb25nPjxmb250IGNvbG9yPSIjRkZGRkZGIj48L2ZvbnQ+ PC9zdHJvbmc+PC9mb250PjwvZm9udD48L3NwYW4+PC90ZD4KICAgICAgICA8L3RyPgogICAgPC90 YWJsZT48L3RkPgogIDwvdHI+CjwvdGFibGU+CjxwPiZuYnNwOzwvcD4KPC9ib2R5Pgo8L2h0bWw+ Cg== --qzsoft_directmail_seperator-- From owner-ietf-openproxy@mail.imc.org Tue Dec 30 08:08:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22207 for ; Tue, 30 Dec 2003 08:08:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbJc5-0005dY-00 for opes-archive@ietf.org; Tue, 30 Dec 2003 08:08:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbJWU-0005WG-00 for opes-archive@ietf.org; Tue, 30 Dec 2003 08:02:59 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AbJTq-0005OQ-00 for opes-archive@ietf.org; Tue, 30 Dec 2003 08:00:15 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUCa3ib058796 for ; Tue, 30 Dec 2003 04:36:03 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBUCa3xI058795 for ietf-openproxy-bks; Tue, 30 Dec 2003 04:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.76.250] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUCa2ib058790 for ; Tue, 30 Dec 2003 04:36:02 -0800 (PST) (envelope-from info@utel.net) Received: from f01m-30-168.d0.club-internet.fr ([212.195.221.168] helo=Moi.utel.net) by montage.altserver.com with esmtp (Exim 4.24) id 1AbJ6M-0005Cn-HZ; Tue, 30 Dec 2003 04:35:59 -0800 Message-Id: <6.0.1.1.2.20031230130731.05f8faf0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 30 Dec 2003 13:45:04 +0100 To: Alex Rousskov From: jfcm Subject: OCP support Cc: ietf-openproxy@imc.org In-Reply-To: References: <2F6114FBB1915B48B96170AE7D4BEAB2042AC7@postale.fourelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id hBUCa3ib058796 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Alex, I apologize because the business we talked about and I expected to fund a= n=20 OPES development has been hampered by an intermediary who wanted to black= =20 mail it. It is now stabilizing but without the initial funding I expected= .=20 All this disconnected me totally from the work in this group. Now, I work on contingency plans to develop OPES. As you know I am=20 interested in DNS security and value added. I started rising the concern=20 about the impact of DNS failures for companies, users, nations. This=20 concerns takes off well. Also, I wish to find solutions where I can certi= fy=20 who reached what - for access gateway, certified mail, DNS updates, spam=20 filtering, etc.. I follow three directions in parallel targeting large customers working o= n=20 their common industrialization of free softwares (a started organization = of=20 large and committed organizations)- but to say large says slow. 1. to try to get a legal obligation in here to have a DNS contingency pla= n=20 to get a DNS insurance. We have right now a vote on the Internet law and = I=20 proposed it. We start also dialoguing with the insurances association. Th= e=20 idea is to call for a stand-alone DNS+ system. Nothing fancy but somethin= g=20 approved by insurances. 2. to develop a dedicated secure and stable hardware. The idea right now = is=20 an OpenBSD version stripped off everything we do not need for a=20 named/Apache/postfix system + network and security control tools. The id= ea=20 behind the hardware is to stabilize solutions, to deliver binaries only a= nd=20 to get an insurance company/legal stamp on it. A manufacturer is supporti= ng. 3. to build a software architecture as an OPES filter and an OPES process= or=20 - probably 8 machines in a team (two for backup) - two to carry http, smtp and dns filtering - two to carry DNS+ services (named and rerouting) - two to carry security checking - two controllers (or external softwares) Kind of services: - changing the dns request for a reroute, for vernacular name support (fr= om=20 jeanfran=E7ois.fra to jefsey.com), or for critical situations - changing the LHS of mails to permit sending/receiving mails with=20 vernacular addresses to/from ASCII addresses - verifying the origin of the call and the reached site, through external= =20 multi channel checking - introducing access menus in a relation - gateway access - weemail support (a project of mine documented in French at=20 http://weemail.org using standard smtp to send value added pointers rathe= r=20 than texts - with a totally different approach for spammers and compatibl= e=20 with existing e-mail). I would be extremely interested in comments from everyone interested. jfc