From owner-issll@mercury.lcs.mit.edu Wed Jan 3 06:25:38 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17464 for ; Wed, 3 Jan 2001 06:25:38 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id FAA29592 for issll-outgoing; Wed, 3 Jan 2001 05:21:39 -0500 (EST) Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id FAA16383 for ; Wed, 3 Jan 2001 05:21:37 -0500 (EST) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA10909 for ; Wed, 3 Jan 2001 11:21:22 +0100 (MET) From: Michael Welzl To: Subject: Deadline extension: CFP Special session "ABR to the Internet", SCI 2001 Date: Wed, 3 Jan 2001 11:28:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id FAA29592 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA17464 The deadline for submission of extended abstracts has been extended to January 18th. Our apologies if you receive this message more than once. Please distribute this call to any of your colleagues who might be interested. -------------------------------------------------------------------- C A L L F O R P A P E R S Special Session: ABR to the Internet ==================================== THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questions: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5 to 2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, researchers and consultants, theoreticians and practitioners in the fields of Systemics, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 18. 01. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further information on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: michael@tk.uni-linz.ac.at SESSION CO-CHAIR: Prof. Dr. Max Mühlhäuser TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date information. From owner-issll@mercury.lcs.mit.edu Wed Jan 3 17:42:25 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06942 for ; Wed, 3 Jan 2001 17:42:25 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA20566 for issll-outgoing; Wed, 3 Jan 2001 16:48:37 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA28778 for ; Wed, 3 Jan 2001 16:48:35 -0500 (EST) Received: from bdaviepc.cisco.com ([171.69.210.246]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with SMTP id NAA23105; Wed, 3 Jan 2001 13:48:09 -0800 (PST) From: "Bruce Davie" To: "Issll@Mercury. Lcs. Mit. Edu" Cc: "mankin@ISI. EDU" , "John Wroclawski" , "Carol Iturralde" , "Fred Baker" , "flf" Subject: RSVP aggregation draft Date: Wed, 3 Jan 2001 16:48:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, As those of you who attended the meeting in San Diego know, the reason we haven't seen draft-ietf-issll-rsvp-aggr-02.txt pop out as an RFC is that the IESG didn't like the notion of swapping protocol numbers on RSVP messages, for security reasons. I took the action item to describe what the benefits of the current approach are, and would appreciate your comments. If no alternative approach is proposed in the next couple of weeks, we will have to write a new "Security Considerations" section and resubmit it to the IESG. Along with my co-authors, I have composed a list of possible alternative solutions, none of which fully captures the benefits of the current approach. Thus, my suggestion is that we go ahead with the current approach. I believe the deadline for finding an alternative is January 15 or thereabouts. Below are the claimed benefits of the current protocol-number changing approach. I'm assuming familiarity with draft-ietf-issll-rsvp-aggr-02.txt. 1. An E2E RSVP message can be sent across a core of RSVP-capable routers and will be ignored by them. Because router alert is still set, the cost of processing the messages is not zero, but no RSVP code is invoked by the messages. 2. The backbone routers don't need any new code to effectively ignore the messages Although some new RSVP code is needed to handle aggregate session types, it's not in the fast path, in contrast to the code which needs to decide if a packet with RA set should be ignored. 3. The backbone routers can process E2E reservations as well as aggregate reservations if desired. This allows aggregation to be used selectively, e.g. only when the number of E2E flows sharing a common ingress & egress exceeds some threshold. 4. The messages can be intercepted by the appropriate egress router and treated appropriately because they still have router alert set; without router alert, this wouldn't work. 5. Hierarchical aggregation is possible using the router alert "value" to distinguish the different levels of aggregation. 6. There is no need to have a priori knowledge of where a particular E2E flow egresses from the aggregation region. The correct egress is automatically discovered and the egress is able to notify the ingress of its identify using the RSVP PHOP information. 7. Changes of topology are automatically detected. If routing changes so that an E2E flow has a new ingress or egress router for the aggregation region, the new ingress-egress pair automatically learn about the change, and old state times out for the old ingress or egress. Now let us consider some alternative approaches: A. IP-in-IP tunneling. We could wrap the E2E RSVP messages in an IP header destined for the appropriate egress, thus causing them to be ignored by the backbone routers. Such an approach loses benefits 6 & 7, which I consider quite valuable. B. Add an "E2E ignore" object to RSVP. One could put some extra information inside the RSVP message to identify it as an E2E message that should be ignored (as distinct from an E2E message that needs processing, or an aggregate message) and the aggregation level (to allow for hierarchy). But you would be forcing backbone routers to do some RSVP processing on all the ignored messages which is a potentially serious performance issue. Benefits 1 and 2 are lost. C. Use the router-alert "value" to indicate E2E-ignore Rather than modifying the protocol number of RSVP messages, we could modify the "value" field in the RA option. There would be a reserved "E2E" ignore value as well as the "aggregation level" values currently described in the draft. This means the IP header is still being modified in a potentially hostile way, so it may not address the IESG's security concerns. E2E messages that are to be hidden from the core routers will need to have the value field modified so that the backbone routers ignore them while still processing un-aggregated E2E messages and aggregate messages. This approach loses benefit 2 - you still need to modify backbone routers to get them to ignore E2E messages. Note that this is fastpath code in general, which is sometimes difficult to modify, and that there may be performance impact. On balance, I think this is the second-best approach after the current one, but it may not satisfy the security folks any more than our current draft. D. Use a new protocol number for aggregate reservations. Another possibility is to leave the protocol number unchanged on E2E messages but to use a new protocol number for aggregate messages. This means that backbone routers need to be told to ignore protocol 46, which rules out the possibility of making plain old E2E reservations and aggregate reservations at the same time (lose benefit 3). Also lose benefit 2, as in the preceding approach. That's as many approaches as we've been able to come up with, so now we need to hear from the WG: - Does anyone have a better alternative than the ones proposed here? - Does anyone have a problem with keeping the current approach and our writing a security issues section to address the IESG concerns? Bruce Davie From owner-issll@mercury.lcs.mit.edu Wed Jan 3 19:28:53 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10499 for ; Wed, 3 Jan 2001 19:28:52 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA32144 for issll-outgoing; Wed, 3 Jan 2001 18:45:57 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA32709 for ; Wed, 3 Jan 2001 18:45:49 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f03NjpU15145; Wed, 3 Jan 2001 15:45:51 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA04868; Wed, 3 Jan 2001 23:45:51 GMT Date: Wed, 3 Jan 2001 23:45:51 GMT Message-Id: <200101032345.XAA04868@gra.isi.edu> To: issll@mercury.lcs.mit.edu, bdavie@cisco.com Subject: Re: RSVP aggregation draft Cc: mankin@isi.edu, jtw@lcs.mit.edu, cei@cisco.com, fred@cisco.com, flefauch@cisco.com X-Sun-Charset: US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Bruce, I unfortunately missed the ISSLL meeting, so I don't understand the security concerns. It seems generally true that mischievous intermediate nodes can mess up RSVP in lots of ways; signaling across malevolent nodes seems like a recipe for disaster. Perhaps one should consider IP-in-IP encapsulation of RSVP messages across untrusted parts of the network (on the shakey assumption that a bad guy is not going to go to the trouble of looking inside the outer IP header to discover what is RSVP). Whether or not this is a fatal flaw depends on your viewpoint. If bad guys inhabit routers on major transit paths, then RSVP signal disruption would seem to be the least of one's worries. And RSVP still seems useful even if it is limited to relatively benign environments. Is there a suggestion that the ISPs are going to actively attack transit RSVP service crossing their domains? .. (good exhaustive list...) *> *> Now let us consider some alternative approaches: *> *> A. IP-in-IP tunneling. *> *> We could wrap the E2E RSVP messages in an IP header destined for the *> appropriate egress, thus causing them to be ignored by the backbone routers. *> Such an approach loses benefits 6 & 7, which I consider quite valuable. *> *> B. Add an "E2E ignore" object to RSVP. *> *> One could put some extra information inside the RSVP message to identify it *> as an E2E message that should be ignored (as distinct from an E2E message *> that needs processing, or an aggregate message) and the aggregation level *> (to allow for hierarchy). But you would be forcing backbone routers to do *> some RSVP processing on all the ignored messages which is a potentially *> serious performance issue. Benefits 1 and 2 are lost. *> *> C. Use the router-alert "value" to indicate E2E-ignore *> *> Rather than modifying the protocol number of RSVP messages, we could modify *> the "value" field in the RA option. There would be a reserved "E2E" ignore *> value as well as the "aggregation level" values currently described in the *> draft. This means the IP header is still being modified in a potentially *> hostile way, so it may not address the IESG's security concerns. E2E *> messages that are to be hidden from the core routers will need to have the *> value field modified so that the backbone routers ignore them while still *> processing un-aggregated E2E messages and aggregate messages. I must admit that I thought we were still planning to use C., revealing that I have not read the aggregation draft recently. C. still feels better to me than your current solution, but it is a fine point. *> *> This approach loses benefit 2 - you still need to modify backbone routers to *> get them to ignore E2E messages. Note that this is fastpath code in general, So, this sounds slightly bogus to me. The "modification" is changing a mapping table, that determines how/whether to interpret RA values. Since RA is used for other things (isn't it?), there is no possibility of casting a single value into silicon. *> which is sometimes difficult to modify, and that there may be performance *> impact. *> *> On balance, I think this is the second-best approach after the current one, *> but it may not satisfy the security folks any more than our current draft. *> *> D. Use a new protocol number for aggregate reservations. *> *> Another possibility is to leave the protocol number unchanged on E2E *> messages but to use a new protocol number for aggregate messages. This means *> that backbone routers need to be told to ignore protocol 46, which rules out *> the possibility of making plain old E2E reservations and aggregate *> reservations at the same time (lose benefit 3). Also lose benefit 2, as in *> the preceding approach. *> Again, this sounds slightly bogus. There must be some mapping function between RA parameters and background routines. This function can be set to map either or both RSVP values to the RSVP routine, can't it? In any case, I would write the security section. Bob From owner-issll@mercury.lcs.mit.edu Fri Jan 5 18:08:35 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25216 for ; Fri, 5 Jan 2001 18:08:35 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA29377 for issll-outgoing; Fri, 5 Jan 2001 17:03:35 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA07290 for ; Fri, 5 Jan 2001 17:03:33 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f05M3ZU08118; Fri, 5 Jan 2001 14:03:35 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA05651; Fri, 5 Jan 2001 22:03:34 GMT Date: Fri, 5 Jan 2001 22:03:34 GMT Message-Id: <200101052203.WAA05651@gra.isi.edu> To: issll@mercury.lcs.mit.edu, bdavie@cisco.com, braden@isi.edu Subject: Re: RSVP aggregation draft Cc: mankin@isi.edu, jtw@lcs.mit.edu, cei@cisco.com, fred@cisco.com, flefauch@cisco.com X-Sun-Charset: US-ASCII Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk *> *> In any case, I would write the security section. *> *> Bob *> Let me rephrase that. What I meant was: I believe that writing the security section is the correct approach. Bob From owner-issll@mercury.lcs.mit.edu Wed Jan 10 15:07:13 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25864 for ; Wed, 10 Jan 2001 15:07:12 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA23273 for issll-outgoing; Wed, 10 Jan 2001 13:40:09 -0500 (EST) Received: from wi3x05.informatik.uni-wuerzburg.de (qmailr@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id NAA24730 for ; Wed, 10 Jan 2001 13:40:07 -0500 (EST) Received: (qmail 1306 invoked from network); 10 Jan 2001 18:38:19 -0000 Received: from wi3d13.informatik.uni-wuerzburg.de (HELO informatik.uni-wuerzburg.de) (132.187.106.113) by wi3x05.informatik.uni-wuerzburg.de with SMTP; 10 Jan 2001 18:38:19 -0000 Message-ID: <3A5CADD5.D5CF19E9@informatik.uni-wuerzburg.de> Date: Wed, 10 Jan 2001 19:45:41 +0100 From: Michael Menth Organization: =?iso-8859-1?Q?Universit=E4t=20W=FCrzburg?= X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: issll@mercury.lcs.mit.edu CC: bdavie@cisco.com, cei@cisco.com, fred@cisco.com, flefauch@cisco.com Subject: Multi-level Aggregration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question / suggestion to section 1.4.9 (Multi-level Aggregration) of draft-ietf-issll-rsvp-aggr-02.txt. The draft allows only for aggregation of rsvp sessions of the same aggregation level: E2E RSVP reservations are considered to be at aggregation level 0 and level n+1 aggregations consist of level n reservations. This, however, implicitly implies in its realization, that a level n+1 aggregation may consist *** only *** of level n reservations. Hence, level n and level m reservations (n <> m) can not be merged into the same aggregate although it might be useful under some circumstances since the level of aggregation does not necessarily denote the size of the aggregate. What do you think of the following definition: We count how often aggregation has been performed on a reservation, thus getting the "aggregation depth". Instead of the aggregation level, we record the aggregation depth in the router alert option field. When a reservation is established, its aggregation depth is 0. The following aggregators examine the RSVP control message and increase the reservation depth. If the resulting value is 1, the protocol number is swapped from RSVP to RSVP-E2E-IGNORE. In the same way, the following deaggregators decrease that value. If the resulting value is 0, the E2E-RSVP-IGNORE is swapped back to RSVP. Doing so, an aggregation region is no longer restricted to carry only aggregates of only one common level but it may carry aggregates of different depths. The benefit of this approach is clearly the higher flexibility for building aggregates. The drawback is that RSVP-E2E-IGNORE messages must not only be examined at the deaggregator but also at the aggregator. However, if this is a major drawback, then it is a weakness of the whole concept anyway since all RSVP messages of all (even recursively) aggregated reservations must be investigated at the deaggregators. Are there other considerations why the "aggregation level" approach is taken instead of an "aggregation depth" approach? Kind regards, Michael -- Dipl.-Inform. Michael Menth University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room A212 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www-info3.informatik.uni-wuerzburg.de/~menth From owner-issll@mercury.lcs.mit.edu Fri Jan 12 17:32:45 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26161 for ; Fri, 12 Jan 2001 17:32:43 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA30897 for issll-outgoing; Fri, 12 Jan 2001 15:46:49 -0500 (EST) Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA01179 for ; Fri, 12 Jan 2001 15:46:39 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 12 Jan 2001 15:28:11 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 12 Jan 2001 15:28:14 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E805B2253C@zwdld001.ca.nortel.com> From: "Hamid Syed" To: "'Yoram Bernet'" Cc: issll Subject: RE: draft-ietf-issll-rsvp-cap-01.txt Date: Fri, 12 Jan 2001 15:28:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07CD6.2BE753C0" X-Orig: Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk 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_01C07CD6.2BE753C0 Content-Type: text/plain; charset="iso-8859-1" comments on line > -----Original Message----- > From: Yoram Bernet [SMTP:yoramb@Exchange.Microsoft.com] > Sent: Tuesday, December 19, 2000 12:01 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: issll > Subject: RE: draft-ietf-issll-rsvp-cap-01.txt > > Couple of clearifications here.. > 1. The object is defined as (Capability Object, CAP) NOT "hcap". This > means that it must not be misunderstood as an object which does interact > between the hosts and the edge routers for marking only > > [Yoram Bernet] OK - noted. I agree that it should not be limited to > host/router interaction. > > 2. The intent of the D-mark bit is not just the scenarios you described. > > > [Yoram Bernet] Hamid - I agree with you entirely. The problem is that > these are the scenarios that *you* described, right out of the draft and > frankly, in and of themselves, they do not provide any justification for > the CAP. > > I re-phrase your scenarioes (though I still believe that do not limit > CAP object just for marking or just between end host and edge of the > network) > 1. No CAP: > a. Marking capable hosts - DCLASS sent, hosts mark. > b. Non-marking capable hosts - DCLAS sent, hosts do not mark. > 2. CAP: > a. Marking capable hosts - DCLASS sent, hosts mark. The edge router > assumes a marked traffic arrival and may be just have to install > policing rules > b. Non-marking capable hosts - no DCLASS sent, hosts do not mark. The > edge router have to install install filters to mark the traffic from the > end host. So the capability object really provides more intelligent > decisions made at the edge device or at the downstream nodes on RSVP > PATH messages. > > [Yoram Bernet] So now (in this e-mail) you have added a discussion of > the functionality that might justify the CAP object. As I stated at the > meeting, this issue is much more about filters and marking and so forth > and that's what needs to be talked about. Instead, your draft focuses > exclusively on whether or not a DCLASS object should be sent. The thing > is that the real usage of the cap object with respect to marking, is > quite complicated. When you talk about installing filters - what filters > are these exactly? What remarking is done in different scenarios? Is > marking really the issue or is it policing? > > Now, as i mentioned before (and also in the draft) that D-mark is an > initial usage case for the CAP object. Other applications/utilities are > really out there and I agree with you that other possible usages of the > CAP object must be captured as well. I would welcome any suggestion in > this regard. > > [Yoram Bernet] I'm not asking you to capture 'other possible usages'. > I'm asking you to think through the one you already presented more > thoroughly and to justify it. > > My suggestions are: > 1. Limit the draft to be nothing more than a definition of the CAP > object. > 2. Issue separate draft(s) that each describe a particular use of the > object (e.g. for enabling a host to tell the network that it is capable > of marking) and that clearly explain what the network will do with the > information that is conveyed to it by the CAP object. If you can't > clearly articulate what the network would do with the information in the > CAP object and why it is able to do something better with that > information than it would without it, then that application of the CAP > object can't be justified. I've done a lot of thinking about the > application that you suggest for the CAP object. I think that it's an > important issue to think through. I suspect that it is useful > information, but can't quite articulate yet how it would be used. I've > done a bit of writing on it, but nothing that is ready for consumption > yet. As soon as it is, I will post it to the list. [Syed, Hamid [WDLN2:AN22:EXCH]] Well.. I do not totally disagree with your suggestions. I guess we had some kind of WG agreement on these issues during the IETF49 meeting. We also did agree on some action items. I am waiting for the meeting minutes to be relaesed by the chair. [Syed, Hamid [WDLN2:AN22:EXCH]] thanx ...Hamid > Thanx for your comments anyways. > cheers > -Hamid > > [Yoram Bernet] Regards, > Yoram > > -----Original Message----- > From: Yoram Bernet [SMTP:yoramb@Exchange.Microsoft.com] > Sent: Wednesday, December 13, 2000 3:04 PM > To: Syed, Hamid [WDLN2:AN22:EXCH] > Cc: issll > Subject: draft-ietf-issll-rsvp-cap-01.txt > Hamid: > Please pardon my delay in raising these issues. But - here goes: > I am struggling with the real application of the hcap object. I believe > > that it is useful, but - its exact value eludes me. For example, in > section 3.1, you state that: > "This information can help the network element to decide whether or not > a DCLASS object must be added in a RSVP message for the flow." > and: > "The network edge router will then know that the upstream node/end host > does not require a DCLASS object." > I think that this is presented as the justification for the hcap object, > > yet - I don't think that this is really a good justification. Why not > just always add a DCLASS object to RSVP messages? What is the cost of > doing so? What is the difference (in terms of the results) between > always adding the DCLASS object and selectively adding the DCLASS > object? I think that there is no difference - consider the following: > 1. No HCAP: > a. Marking capable hosts - DCLASS sent, hosts mark. > b. Non-marking capable hosts - DCLAS sent, hosts do not mark. > 2. HCAP: > a. Marking capable hosts - DCLASS sent, hosts mark. > b. Non-marking capable hosts - no DCLASS sent, hosts do not mark. > So - while the hcap object does affect whether or not a DCLASS is sent, > it doesn't seem to effect whether the host actually marks or not. So - > the only value of the hcap object here, is to save the network device > the trouble of sending a DCLASS that would be ignored. But then - > sending a DCLASS object seems to be pretty low cost behaviour. > Similarly, in 3.2, I think that the hcap object is presented as nothing > more than an optimization and a debatable one, at that. The optimization > > is to prevent a network element from generating a DCLASS if it is going > to be ignored. The value of this optimization is debatable because the > cost of processing hcap objects and storing related state is not clearly > > worth the cost savings of not 'just sending a DCLASS, always'. > I think that there might be a real value to the HCAP object. But - I > think that it is less in telling a network element when to send a DCLASS > > and when not to and more in helping a network element to validate the > DSCP provided by hosts. For example - it may be the case that at the > network element, traffic arrives from a variety of hosts. Some of this > traffic is marked purposely, by DCLASS aware hosts. Other is marked > arbitrarily, by 'rogue' hosts. Perhaps this is the utility of the HCAP > object. > In section 5, it states that the network edge must be manually > configured to either send a DCLASS object, install a filter to cause > marking for a flow, or both. There is a third option - do neither. For > example, consider the ingress router to a diffserv network that offers a > > simple static SLA (of the form customer on interfgace A gets to send 1 > Mbps of traffic marked EF). In the simplest case, there is no need to > send a DCLASS and no need to mark on behalf of the customer. The > customer simply uses whatever strategies are appropriate for marking and > > the provider simply polices to enforce the SLA. > Yoram > ------_=_NextPart_001_01C07CD6.2BE753C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-issll-rsvp-cap-01.txt

comments on = line

    -----Original Message-----
    From:   Yoram Bernet = [SMTP:yoramb@Exchange.Microsoft.com]
    Sent:   Tuesday, December 19, 2000 12:01 PM
    To:     Syed, Hamid [WDLN2:AN22:EXCH]
    Cc:     issll
    Subject:       = RE: = draft-ietf-issll-rsvp-cap-01.txt

    Couple of clearifications here.. =
    1. The object is defined as = (Capability Object, CAP) NOT "hcap". This
    means that it must not be = misunderstood as an object which does interact
    between the hosts and the edge = routers for marking only

    [Yoram Bernet] OK - noted. I agree = that it should not be limited to
    host/router interaction.  =

    2. The intent of the D-mark bit is not = just the scenarios you described.


    [Yoram Bernet]  Hamid - I agree = with you entirely. The problem is that
    these are the scenarios that *you* = described, right out of the draft and
    frankly, in and of themselves, they = do not provide any justification for
    the CAP.

    I re-phrase your scenarioes (though I = still believe that do not limit
    CAP object just for marking or just = between end host and edge of the
    network)
    1. No CAP:
    a. Marking capable hosts - DCLASS = sent, hosts mark.
    b. Non-marking capable hosts - DCLAS = sent, hosts do not mark.
    2. CAP:
    a. Marking capable hosts - DCLASS = sent, hosts mark. The edge router
    assumes a marked traffic arrival and = may be just have to install
    policing rules
    b. Non-marking capable hosts - no = DCLASS sent, hosts do not mark. The
    edge router have to install install = filters to mark the traffic from the
    end host. So the capability object = really provides more intelligent
    decisions made at the edge device or = at the downstream nodes on RSVP
    PATH messages.

    [Yoram Bernet]  So now (in this = e-mail) you have added a discussion of
    the functionality that might justify = the CAP object. As I stated at the
    meeting, this issue is much more = about filters and marking and so forth
    and that's what needs to be talked = about. Instead, your draft focuses
    exclusively on whether or not a = DCLASS object should be sent. The thing
    is that the real usage of the cap = object with respect to marking, is
    quite complicated. When you talk = about installing filters - what filters
    are these exactly? What remarking is = done in different scenarios? Is
    marking really the issue or is it = policing?
     
    Now, as i mentioned before (and also = in the draft) that D-mark is an
    initial usage case for the CAP = object. Other applications/utilities are
    really out there and I agree with you = that other possible usages of the
    CAP object must be captured as well. = I would welcome any suggestion in
    this regard.

    [Yoram Bernet] I'm not asking you to = capture 'other possible usages'.
    I'm asking you to think through the = one you already presented more
    thoroughly and to justify it.

    My suggestions are:
    1. Limit the draft to be nothing more = than a definition of the CAP
    object.
    2. Issue separate draft(s) that each = describe a particular use of the
    object (e.g. for enabling a host to = tell the network that it is capable
    of marking) and that clearly explain = what the network will do with the
    information that is conveyed to it by = the CAP object. If you can't
    clearly articulate what the network = would do with the information in the
    CAP object and why it is able to do = something better with that
    information than it would without it, = then that application of the CAP
    object can't be justified. I've done = a lot of thinking about the
    application that you suggest for the = CAP object. I think that it's an
    important issue to think through. I = suspect that it is useful
    information, but can't quite = articulate yet how it would be used. I've
    done a bit of writing on it, but = nothing that is ready for consumption
    yet. As soon as it is, I will post it = to the list.
    [Syed, Hamid = [WDLN2:AN22:EXCH]]  Well.. I do not totally disagree with your = suggestions. I guess we had some kind of WG agreement on these issues = during the IETF49 meeting. We also did agree on some action = items. I am waiting for the meeting minutes to be relaesed by = the chair.

    [Syed, Hamid = [WDLN2:AN22:EXCH]]  thanx ...Hamid
    Thanx for your comments anyways. =
    cheers
    -Hamid

    [Yoram Bernet] Regards,
    Yoram

    -----Original Message-----
    From:   Yoram Bernet = [SMTP:yoramb@Exchange.Microsoft.com]
    Sent:   Wednesday, December = 13, 2000 3:04 PM
    To:     Syed, = Hamid [WDLN2:AN22:EXCH]
    Cc:     issll =
    Subject:        = draft-ietf-issll-rsvp-cap-01.txt
    Hamid:
    Please pardon my delay in raising = these issues. But - here goes:
    I am struggling with the real = application of the  hcap object. I believe

    that it is useful, but - its exact = value eludes me. For example, in
    section 3.1, you state that:
    "This information can help the = network element to decide whether or not
    a DCLASS object must be added in a = RSVP message for the flow."
    and:
    "The network edge router will = then know that the upstream node/end host
    does not require a DCLASS = object."
    I think that this is presented as the = justification for the hcap object,

    yet - I don't think that this is = really a good justification. Why not
    just always add a DCLASS object to = RSVP messages? What is the cost of
    doing so? What is the difference (in = terms of the results) between
    always adding the DCLASS object and = selectively adding the DCLASS
    object? I think that there is no = difference - consider the following:
    1. No HCAP:
    a. Marking capable hosts - DCLASS = sent, hosts mark.
    b. Non-marking capable hosts - DCLAS = sent, hosts do not mark.
    2. HCAP:
    a. Marking capable hosts - DCLASS = sent, hosts mark.
    b. Non-marking capable hosts - no = DCLASS sent, hosts do not mark.
    So - while the hcap object does = affect whether or not a DCLASS is sent,
    it doesn't seem to effect whether the = host actually marks or not. So -
    the only value of the hcap object = here, is to save the network device
    the trouble of sending a DCLASS that = would be ignored. But then -
    sending a DCLASS object seems to be = pretty low cost behaviour.
    Similarly, in 3.2, I think that the = hcap object is presented as nothing
    more than an optimization and a = debatable one, at that. The optimization

    is to prevent a network element from = generating a DCLASS if it is going
    to be ignored. The value of this = optimization is debatable because the
    cost of processing hcap objects and = storing related state is not clearly

    worth the cost savings of not 'just = sending a DCLASS, always'.
    I think that there might be a real = value to the HCAP object. But - I
    think that it is less in telling a = network element when to send a DCLASS

    and when not to and more in helping a = network element to validate the
    DSCP provided by hosts. For example - = it may be the case that at the
    network element, traffic arrives from = a variety of hosts. Some of this
    traffic is marked purposely, by = DCLASS aware hosts. Other is marked
    arbitrarily, by 'rogue' hosts. = Perhaps this is the utility of the HCAP
    object.
    In section 5, it states that the = network edge must be manually
    configured to either send a DCLASS = object, install a filter to cause
    marking for a flow, or both. There is = a third option - do neither. For
    example, consider the ingress router = to a diffserv network that offers a

    simple static SLA (of the form = customer on interfgace A gets to send 1
    Mbps of traffic marked EF). In the = simplest case, there is no need to
    send a DCLASS and no need to mark on = behalf of the customer. The
    customer simply uses whatever = strategies are appropriate for marking and

    the provider simply polices to enforce = the SLA.
    Yoram
     

------_=_NextPart_001_01C07CD6.2BE753C0-- From owner-issll@mercury.lcs.mit.edu Wed Jan 17 06:02:15 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15390 for ; Wed, 17 Jan 2001 06:02:15 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA15550 for issll-outgoing; Wed, 17 Jan 2001 04:47:51 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA15335 for ; Wed, 17 Jan 2001 04:47:35 -0500 (EST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0H9kxU16772; Wed, 17 Jan 2001 10:47:04 +0100 (MET) Received: from alcatel.be ([138.203.195.108]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D7.0035B5E6; Wed, 17 Jan 2001 10:46:39 +0100 Message-ID: <3A656A34.23783B47@alcatel.be> Date: Wed, 17 Jan 2001 10:47:32 +0100 From: Francis Arts Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: rsvp , mpls Subject: RESV message in RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am trying to find out which IP address should be used as the source IP address of a RESV message in RSVP. In RFC 2205 I find the following statements: 1) [RFC 2205, p.38, section 3.1.4] states the following: "The IP source address is an address of the node that sent the message." 2) [RFC 2205, p.39] states the following: "The NHOP (i.e., the RSVP_HOP) object contains the IP address of the interface through which the Resv message was sent and the LIH for the logical interface on which the reservation is required." From these quotes I understand the following: * The source IP address in the IP header of a RESV message can be any IP address configured on the router that originates the RESV message. So this can but does not have to be the IP address of the interface on which the RESV message is sent out [refer to quotes of RFC 2205 below]. * The NHOP object in the RESV message has to be the IP address configured on the interface via which the RESV message is sent out. This implies that the source IP address in the IP header of the RESV message and the NHOP object in the payload of the RESV message may but do not have to carry different IP addresses. Is this the correct understanding? Thank you for your reply. Kind regards, Francis. From owner-issll@mercury.lcs.mit.edu Fri Jan 19 13:00:54 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03453 for ; Fri, 19 Jan 2001 13:00:52 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA23570 for issll-outgoing; Fri, 19 Jan 2001 10:55:23 -0500 (EST) Received: from cins.hanyang.ac.kr ([166.104.204.187]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA21297 for ; Fri, 19 Jan 2001 10:55:11 -0500 (EST) From: emed11@libero.it Received: by cins.hanyang.ac.kr id AAA389841; Sat, 20 Jan 2001 00:29:42 +0900 (KST) To: issll@mercury.lcs.mit.edu Subject: Obtain Biotech IPOs! 143 Date: Fri, 19 Jan 2001 10:53:05 Message-Id: <530.605798.590623@libero.it> Reply-To: emed11@libero.it Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cins.hanyang.ac.kr id AAA389841 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable

Help Beta Test Our Site and Be Eligible to Purchase Shares= of=20 Future IPOs In Which We Participate**

eMedsecurities has selected you as a possible participant = to help=20 test our online stock-trading engine for knowledge-based investing = in the=20 life sciences.  For your cooperation, you will be eligible = to purchase=20 shares of future IPOs in which we participate, for as long as y= ou=20 maintain your account with us.  This is limited to only 50 = qualified=20 testers!  Request Mor= e Information.**

eMedsecurities=85 The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, = all=20 compiled in a single, easy-to-use resource.  Learn about new r= esearch=20 and upcoming treatments for migraine headache, stroke, epilepsy, br= ain=20 tumor and much more.  Obtain critical investment information a= bout the=20 companies that are developing these treatments.  eMedsecuritie= s empowers=20 you to make more informed investment decisions.  Request More Information.**

Participation i= n eMedsecurities' Beta Test allows you:

  • Eligibility to purchase s= hares of IPOs in which=20 eMedsecurities participates for as long as you maintain your=20 account**

  • Valuable research of the = entire product=20 pipeline of companies, including stages of clinical development, = by=20 industry or specific disease

  • Useful information about = industry trends, recent=20 developments and upcoming IPOs

  • Commitment to customer se= rvice featuring=20 our Live Customer Service Online

  • Dedication to fast trade = executions at the best=20 possible price

The following guideline= s will=20 explain what we expect from an eMedsecurities Beta Tester:

  • Open a funded eMedsecurities=20 account

  • Visit our online trading site onc= e=20 a week

  • Execute trades through our web=20 site in accordance with your normal practice

  • Submit feedback to eMedsecurities= ' development team through a questionnaire sent via=20 email

  • Provide us with additional=20 feedback regarding the site as needed

The test is limited to = only 50 Beta=20 Testers so sign up now to be considered!  Request More Information.**=20

Please note:<= /B> All applications for the Beta Test must be s= ubmitted by January 24, 2001 to be considered.=20

Please=20 be advised that your information will stay in our proprietary datab= ase and=20 will not be sold, traded, given or otherwise provided to outside ve= ndors.  We respect your privacy.=20

=20

By=20 submitting your information, you implicitly state that this is some= thing=20 that interests you and that you
agree to receive periodic emails from=20 eMedsecurities.=20

Research indicated= that you=20 might benefit from our offer.  To be removed instantly and per= manently from=20 our database, simply click here= .  We respect=20 all removal requests.

** R= estrictions=20 Apply:  Beta test not open t= o residents of:  HI, IL, MI, MN, MS, NE, NH, TN, TX.  Initial Public= =20 Offerings are considered speculative investments and as such may no= t be=20 appropriate for every investor. If an investor chooses to participa= te in=20 IPOs, there are certain restrictions that apply:  Flipping- The first time an investo= r sells=20 his/her shares within the first 30 days the issue is trading in the= =20 secondary market, that investor will not be allocated shares for th= e next=20 90 days following the sale.  The second time that investor =93= flips=94,=20 they will not be allocated IPO shares for 180 days.  The third= time=20 that investor =93flips=94, they lose their IPO allocations permanen= tly.  Transferring shares- <= /B>If the=20 investor transfers IPO shares out of their account within the first= 30=20 days the issue is trading in the secondary market, they will perman= ently=20 lose their IPO allocations.  Beta investors will be chosen = from=20 all the applicants based on their income, net worth and investing=20 experience.  IPO shares will only be allocated from transa= ctions in=20 which eMedsecurities participates in the underwriting. A0007-1-A2=20
From owner-issll@mercury.lcs.mit.edu Sat Jan 20 00:04:36 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12313 for ; Sat, 20 Jan 2001 00:04:34 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id XAA26574 for issll-outgoing; Fri, 19 Jan 2001 23:02:31 -0500 (EST) Received: from ciaoweb.it ([151.88.109.26]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id XAA26609 for ; Fri, 19 Jan 2001 23:02:29 -0500 (EST) From: emed11@libero.it Received: from mail pickup service by ciaoweb.it with Microsoft SMTPSVC; Sat, 20 Jan 2001 05:00:39 +0100 Received: from dns.ciaoweb.net ([151.88.109.1]) by ciaoweb.it with Microsoft SMTPSVC(5.5.1877.447.44); Sat, 20 Jan 2001 00:36:42 +0100 Received: by dns.ciaoweb.net; (8.8.8/1.3/10May95) id UAA14853; Fri, 19 Jan 2001 20:14:18 +0100 (MET) Received: from mercury.lcs.mit.edu by dns.ciaoweb.net (smtpxd); id XA28795 Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA23570 for issll-outgoing; Fri, 19 Jan 2001 10:55:23 -0500 (EST) Received: from cins.hanyang.ac.kr ([166.104.204.187]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA21297 for ; Fri, 19 Jan 2001 10:55:11 -0500 (EST) Received: by cins.hanyang.ac.kr id AAA389841; Sat, 20 Jan 2001 00:29:42 +0900 (KST) To: issll@mercury.lcs.mit.edu Subject: Obtain Biotech IPOs! 143 Date: Fri, 19 Jan 2001 10:53:05 Message-Id: <530.605798.590623@libero.it> Reply-To: emed11@libero.it Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cins.hanyang.ac.kr id AAA389841 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable

Help Beta Test Our Site and Be Eligible to Purchase Shares= of=20 Future IPOs In Which We Participate**

eMedsecurities has selected you as a possible participant = to help=20 test our online stock-trading engine for knowledge-based investing = in the=20 life sciences.  For your cooperation, you will be eligible = to purchase=20 shares of future IPOs in which we participate, for as long as y= ou=20 maintain your account with us.  This is limited to only 50 = qualified=20 testers!  Request Mor= e Information.**

eMedsecurities=85 The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, = all=20 compiled in a single, easy-to-use resource.  Learn about new r= esearch=20 and upcoming treatments for migraine headache, stroke, epilepsy, br= ain=20 tumor and much more.  Obtain critical investment information a= bout the=20 companies that are developing these treatments.  eMedsecuritie= s empowers=20 you to make more informed investment decisions.  Request More Information.**

Participation i= n eMedsecurities' Beta Test allows you:

  • Eligibility to purchase s= hares of IPOs in which=20 eMedsecurities participates for as long as you maintain your=20 account**

  • Valuable research of the = entire product=20 pipeline of companies, including stages of clinical development, = by=20 industry or specific disease

  • Useful information about = industry trends, recent=20 developments and upcoming IPOs

  • Commitment to customer se= rvice featuring=20 our Live Customer Service Online

  • Dedication to fast trade = executions at the best=20 possible price

The following guideline= s will=20 explain what we expect from an eMedsecurities Beta Tester:

  • Open a funded eMedsecurities=20 account

  • Visit our online trading site onc= e=20 a week

  • Execute trades through our web=20 site in accordance with your normal practice

  • Submit feedback to eMedsecurities= ' development team through a questionnaire sent via=20 email

  • Provide us with additional=20 feedback regarding the site as needed

The test is limited to = only 50 Beta=20 Testers so sign up now to be considered!  Request More Information.**=20

Please note:<= /B> All applications for the Beta Test must be s= ubmitted by January 24, 2001 to be considered.=20

Please=20 be advised that your information will stay in our proprietary datab= ase and=20 will not be sold, traded, given or otherwise provided to outside ve= ndors.  We respect your privacy.=20

=20

By=20 submitting your information, you implicitly state that this is some= thing=20 that interests you and that you
agree to receive periodic emails from=20 eMedsecurities.=20

Research indicated= that you=20 might benefit from our offer.  To be removed instantly and per= manently from=20 our database, simply click here= .  We respect=20 all removal requests.

** R= estrictions=20 Apply:  Beta test not open t= o residents of:  HI, IL, MI, MN, MS, NE, NH, TN, TX.  Initial Public= =20 Offerings are considered speculative investments and as such may no= t be=20 appropriate for every investor. If an investor chooses to participa= te in=20 IPOs, there are certain restrictions that apply:  Flipping- The first time an investo= r sells=20 his/her shares within the first 30 days the issue is trading in the= =20 secondary market, that investor will not be allocated shares for th= e next=20 90 days following the sale.  The second time that investor =93= flips=94,=20 they will not be allocated IPO shares for 180 days.  The third= time=20 that investor =93flips=94, they lose their IPO allocations permanen= tly.  Transferring shares- <= /B>If the=20 investor transfers IPO shares out of their account within the first= 30=20 days the issue is trading in the secondary market, they will perman= ently=20 lose their IPO allocations.  Beta investors will be chosen = from=20 all the applicants based on their income, net worth and investing=20 experience.  IPO shares will only be allocated from transa= ctions in=20 which eMedsecurities participates in the underwriting. A0007-1-A2=20
From owner-issll@mercury.lcs.mit.edu Mon Jan 29 20:29:59 2001 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13507 for ; Mon, 29 Jan 2001 20:29:54 -0500 (EST) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA23223 for issll-outgoing; Mon, 29 Jan 2001 18:51:51 -0500 (EST) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA23316; Mon, 29 Jan 2001 18:51:42 -0500 (EST) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14NO3J-0000Xx-00; Mon, 29 Jan 2001 23:49:41 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp3.email.verio.net with esmtp id 14NO34-0000KW-00; Mon, 29 Jan 2001 23:49:26 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 15:05:55 -0500 Subject: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__13056695_54355.36" Message-Id: Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__13056695_54355.36 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__13056695_54355.36 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__13056695_54355.36--