Take Control Of Your Conference Calls

From owner-ietf-ldup@mail.imc.org Wed May 2 08:03:46 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06997 for ; Wed, 2 May 2001 08:03:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA12482 for ietf-ldup-bks; Wed, 2 May 2001 04:23:50 -0700 (PDT) Received: from firewall ([211.205.65.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA12455 for ; Wed, 2 May 2001 04:23:47 -0700 (PDT) From: customercare217@fine-view.com Message-ID: <00002b9e68dc$00004044$00005579@fine-view.com> To: Subject: write back when you can 21881 Date: Wed, 02 May 2001 04:25:39 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Take Control Of Your Conference Calls

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants!<= /FONT>

<= /TABLE>

No setup fees
No contracts or monthly fees
Call anytime, from anywhere, to anywhere
International Dial In 18 cents per minute
Simplicity in set up and administration
Operator Help available 24/7

G= et the best quality, the easiest to use, and lowest rate in the industry.

If you like saving m= oney, fill out the form below and one of our consultants will contact you.

Required Input Field*

Name*

Web Address*

Company Name*

Web Address*

Business Phone*

Home Phone

Email Address*

Type of Business

This email is to those persons that have contacted Conferen= ce Calls for Less regarding available services or product information. If thi= s email is reaching you in error and you feel that you have not contac= ted us, C= lick here. We will gladly remove you from our mailing list.

From owner-ietf-ldup@mail.imc.org Wed May 2 08:04:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07008 for ; Wed, 2 May 2001 08:04:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA12215 for ietf-ldup-bks; Wed, 2 May 2001 04:22:40 -0700 (PDT) Received: from firewall ([211.205.65.125]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA12203 for ; Wed, 2 May 2001 04:22:38 -0700 (PDT) From: customercare217@fine-view.com Message-ID: <00002b9e68dc$00004044$00005579@fine-view.com> To: Subject: write back when you can 21881 Date: Wed, 02 May 2001 04:24:27 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Take Control Of Your Conference Calls

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants!<= /FONT>

If you like saving m= oney, fill out the form below and one of our consultants will contact you.

Required Input Field*

Name*

Web Address*

Company Name*

Web Address*

Business Phone*

Home Phone

Email Address*

Type of Business

From owner-ietf-ldup@mail.imc.org Wed May 2 20:59:58 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27649 for ; Wed, 2 May 2001 20:59:57 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA06485 for ietf-ldup-bks; Wed, 2 May 2001 17:06:00 -0700 (PDT) Received: from server ([211.181.218.81]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA05956; Wed, 2 May 2001 16:55:32 -0700 (PDT) From: customercare217@fine-view.com Message-ID: <00002b9e68dc$00004044$00005579@fine-view.com> To: Subject: write back when you can 21881 Date: Wed, 02 May 2001 04:26:07 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Take Control Of Your Conference Calls

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants!<= /FONT>

If you like saving m= oney, fill out the form below and one of our consultants will contact you.

Required Input Field*

Name*

Web Address*

Company Name*

Web Address*

Business Phone*

Home Phone

Email Address*

Type of Business

From owner-ietf-ldup@mail.imc.org Thu May 3 10:19:03 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25155 for ; Thu, 3 May 2001 10:19:02 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA02191 for ietf-ldup-bks; Thu, 3 May 2001 06:37:03 -0700 (PDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA02182 for ; Thu, 3 May 2001 06:37:01 -0700 (PDT) Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA10704; Thu, 3 May 2001 15:35:24 +0200 (MET DST) Date: Thu, 03 May 2001 15:35:23 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Albert Langer cc: IESG , IAB , ietf-ldup@imc.org Subject: Re: LDUP WG - RFC 2026 s 6.5.4 appeal Message-ID: <1227873.988904123@[0.0.0.0]> In-Reply-To: <01K33BS6AYYE0020DL@mauve.mrochek.com> References: <000001c0a878$f290ed60$6628a8c0@nowhere.com> <3AB15951.4C9AF34C@att.com><3AB15951.4C9AF34C@att.com> <01K33BS6AYYE0020DL@mauve.mrochek.com> X-Mailer: Mulberry/2.1.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id GAA02185 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id GAA02191 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA25155 This is the response from Area Directors for Applications Area, Ned Freed and Patrik F�ltstr�m, to an appeal from mr Albert Langer. 1) Finalization of Proposed Standard before Architecture It is justified to ask whether the work on the proposed standard should start before the architecture document is carved in stone. The truth is though that there have not been a last call in the IETF for any of the documents, so we can not see that the protocol (which you call proposed standard) is finished before the architecture. You might object working on things in parallell but that is still a question which is to be discussed inside the wg. Doing things in parallell is not automatically a process violation. Having gone back through the archives, the order of Last Calls in the WG were "replica-req-01", "ldup-model-02", "replica-req-06". Conclusion: As the protocol has not been finalized yet, we can not say that the protocol is finalized before the architecture. Further, we don't see any problem with working with both documents in parallel. 2) No review of WG progress despite delays exceeding two years It is true that the wg is delayed, but that is unfortunately something which is quite normal in the IETF. But, we see that the order things have been handled is according to the charter, and there have been progress. Further, unfortunately most of the delays in the wg after the Adelaide IETF meeting is becuase of discussions on (a) meta issues which ended up in this appeal and (b) the question why the model described in the MDCR draft written by mr Langer was rejected by the wg. Conclusion: We see the wg is still on track, even though it is delayed. The milestones in a charter should be updated to reflect the current view. We do see that the milestones were updated at the last update of the charter which was done in spring 2001. Further, the slow progress in the wg is not the result of actions (or lack thereof) by the wg chairs. 3) Unauthorized posting of revised WG charter After looking through the archives on how a proposed revised WG charter was posted to the wg mailinglist, we can not find any errors made by the wg chairs. A revised charter can be posted to the mailing list at any point in time when the chairs so choose. No specific questions regarding changes have to be asked. It is completely up to the chairs to choose what mechanism they use to find consensus around the new charter after which they report to the responsible Area Directors. The most common mechanism is to send the new charter to the mailing list, and see if there are any comments. Silence means no objection. While the WG needs to reach rough consensus on the charter, the actual writing of the charter is done by the chairs and the IESG. Conclusion: We find that the wg chairs did reach rough consensus in the wg for the revised charter. A charter which also later was accepted by the IESG and IAB. Something which happens after the wg consensus is reached. 4) Refusal to resolve technical issues in WG list We see that many of the issues which mr Langer has brought up has been rejected by the wg by rough consensus. I.e. not many of the proposals have been picked up by the wg members. Some have on the other hand beeing picked up by the authors of the requirements document. Further, if the complaint is that the wg chairs have not been active in the discussions themselves, that is a normal stand which wg chairs take, and the stand which according to the wg chairs they took in this case. I.e. the wg chairs are to make decision on whether consensus exists, and not try to be part in the discussions. Conclusion by the chairs were that the MDCR draft was rejected, and the mechanisms specified in it was not chosen by the wg by rough consensus. The wg chairs have after that decision tried to move forward, and not further discuss the issue(s). Conclusion: The wg chairs have in a correct way made a decision whether rough consensus exists for various technical aspects, during some months after the IETF meeting in Adelaide. Result of this evaluation was also discussed at the following IETF meeting. See point 12 in the minutes from the july 2000 meeting of the IETF (the 48th IETF). 5) Bullying retaliation in response to formal objections by John Such behavior is subject to personal interpretation. We don't see the wg chairs have behaved in a specifically bad manner. Especially as some comments from mr Langer on actions and email from wg chairs, editors of documents and other wg participants from their view can be seen as clear ad-hominum attacks. Conclusion: The wg chairs have followed the process correctly, and also in a clear way stated when a certain item is not to be discussed in the wg. Reasons for this can be that the wg have already rejected the proposal, it might be out of scope for the wg, or it is well-known from earlier discussions of being a so called rat-hole -- in which case a discussion never will lead to any constructive result. Patrik F�ltstr�m Ned Freed From owner-ietf-ldup@mail.imc.org Wed May 9 04:19:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01784 for ; Wed, 9 May 2001 04:19:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA08660 for ietf-ldup-bks; Wed, 9 May 2001 00:32:47 -0700 (PDT) Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA08645 for ; Wed, 9 May 2001 00:32:42 -0700 (PDT) Message-ID: <5353200153972437600@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ietf-ldup@imc.org Subject: Business/Employment Opportunity Date: Tue, 8 May 2001 21:24:37 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id AAA08654 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-ietf-ldup@mail.imc.org Fri May 11 07:52:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04936 for ; Fri, 11 May 2001 07:52:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA08021 for ietf-ldup-bks; Fri, 11 May 2001 04:12:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA08010 for ; Fri, 11 May 2001 04:12:27 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03721; Fri, 11 May 2001 07:12:22 -0400 (EDT) Message-Id: <200105111112.HAA03721@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-urp-04.txt Date: Fri, 11 May 2001 07:12:21 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDUP Update Reconciliation Procedures Author(s) : S. Legg, A. Payne Filename : draft-ietf-ldup-urp-04.txt Pages : 29 Date : 10-May-01 This document describes the procedures used by LDAP [LDAPv3] or X.500 [X500] directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-04.txt 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-ldup-urp-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-ldup-urp-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: <20010510095835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-urp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-urp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010510095835.I-D@ietf.org> --OtherAccess-- --NextPart-- From phoffman@above.proper.com Sun May 13 01:54:17 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02204 for ; Sun, 13 May 2001 01:54:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA18157; Sat, 12 May 2001 22:54:17 -0700 (PDT) Date: Sat, 12 May 2001 22:54:17 -0700 (PDT) Message-Id: <200105130554.WAA18157@above.proper.com> To: ldup-archive@ietf.org From: subs-reminder@imc.org Subject: Subscription for ldup-archive@lists.ietf.org to the ietf-ldup mailing list Greetings. This message is a periodic reminder that you are subscribed to the ietf-ldup mailing list, and you are subscribed as: ldup-archive@lists.ietf.org There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anyting. If you want to unsubscribe from this list, you can respond to this message and I will unsubscribe you. This may take a few days because it will be done by hand by a human. If you want to unsubscribe automatically, send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From phoffman@above.proper.com Sun May 13 02:02:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06247 for ; Sun, 13 May 2001 02:02:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA19555; Sat, 12 May 2001 23:02:52 -0700 (PDT) Date: Sat, 12 May 2001 23:02:52 -0700 (PDT) Message-Id: <200105130602.XAA19555@above.proper.com> To: ldup-archive@ietf.org From: subs-reminder@imc.org Subject: Subscription for ldup-archive@lists.ietf.org to the ietf-ldup mailing list Greetings. This message is a periodic reminder that you are subscribed to the ietf-ldup mailing list, and you are subscribed as: ldup-archive@lists.ietf.org There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ldup mailing list, you do not need to do anyting. If you want to unsubscribe from this list, you can respond to this message and I will unsubscribe you. This may take a few days because it will be done by hand by a human. If you want to unsubscribe automatically, send a plain-text message to: ietf-ldup-request@imc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ldup@mail.imc.org Mon May 14 08:08:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07831 for ; Mon, 14 May 2001 08:08:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA29528 for ietf-ldup-bks; Mon, 14 May 2001 04:35:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA29517 for ; Mon, 14 May 2001 04:35:53 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07136; Mon, 14 May 2001 07:35:45 -0400 (EDT) Message-Id: <200105141135.HAA07136@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-lcup-00.txt Date: Mon, 14 May 2001 07:35:45 -0400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Client Update Protocol Author(s) : R. Megginson et al. Filename : draft-ietf-ldup-lcup-00.txt Pages : 18 Date : 11-May-01 This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-00.txt 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-ldup-lcup-00.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-ldup-lcup-00.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: <20010511144416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-lcup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-lcup-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010511144416.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon May 14 08:12:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07933 for ; Mon, 14 May 2001 08:12:19 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA29636 for ietf-ldup-bks; Mon, 14 May 2001 04:39:24 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA29632 for ; Mon, 14 May 2001 04:39:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f4EBcmv17351 for ; Mon, 14 May 2001 04:38:48 -0700 (PDT) Received: from netscape.com ([129.157.192.243]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDBPON00.LS3; Mon, 14 May 2001 04:38:47 -0700 Message-ID: <3AFFC36F.2DCE81EC@netscape.com> Date: Mon, 14 May 2001 05:37:19 -0600 From: richm@netscape.com (Rich Megginson) Reply-To: richm@iplanet.com Organization: iPlanet X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldup@imc.org, ietf-lcup@netscape.com Subject: Announcement: new version of LCUP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms525B572A1A820D5BF63F8076" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms525B572A1A820D5BF63F8076 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit http://search.ietf.org/internet-drafts/draft-megginson-ldup-lcup-00.txt OR if it has been officially renamed - http://search.ietf.org/internet-drafts/draft-ietf-ldup-lcup-00.txt The major change is that the previous version of LCUP restricted LCUP searches to a replica as defined by LDUP. The new version of LCUP removes that restriction. The client may receive a continuation reference if the search crosses a replica boundary or some other similar type of boundary - the implementation does not depend on LDUP. The client may receive multiple cookies per search, and will have to manage those cookies. The cookies correspond to the LDAP URL returned in the continuation reference. For other changes, see the last section. Here is a summary of the changes: Added the definition for Unique Identifier (basically copied from the LDUP model doc http://search.ietf.org/internet-drafts/draft- ietf-ldup-model-06.txt. I needed to add the definition here because LCUP needs a Unique Identifier but should not be dependent on LDUP. Removed all normative references to LDUP. I've left the implementation suggestions that refer to LDUP, but LCUP should not be dependent on LDUP. Cleaned up the protocol flows. Removed this text from section 4.8: "Clients MUST NOT issue multiple synchronization requests on the same connection. This is because the protocol includes an extended operation and it would be impossible to decide which synchronization session it belongs to." - This is no longer true, since the extended operation now includes the message ID of the search request. Added section 12. Acknowledgements Removed normative references to documents not depended on. Removed explicit references to software vendors. Section 4.1 - Changed ClientUpdateControlValue to remove the keepConnection and changesOnly fields and replace them with updateType which is an ENUMERATED with three values: synchronizeOnly, synchronizeAndPersist, and persistOnly. Section 4.2 - The EntryUpdateControlValue fields stateUpdate and entryDeleted no longer have DEFAULT values, they must be specified � this eliminates any potential ambiguity. Added this text to the description of the entryDeleted field (section 4.2): "The server SHOULD also set this to TRUE if the entry has left the clients search result set. As far as the client is concerned, a deleted entry is no different than an entry which has left the result set." Section 4.2 - Added an explanation of the concept and requirement for the Unique Identifier. Section 4.4 - Added to the extended operation a request value containing the message id of the operation to stop. Updated contact information for Olga. Removed Michael Armijo and added Jeff Parham as an author. --------------ms525B572A1A820D5BF63F8076 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIpXzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDEyMDQxNjMzMDZaFw0wMTA2MDIxNjMzMDZa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5FgFqT5oTdQeMgUI2f3GSYsuty7+KimpWS5x4aBgL5eve2soq8zN66WfZzRq9Y2SUHrYdlgR JzqJo2p5hl1G+KgTdgRm69z9OUpv1Vt3yh8dTJ4H+OgGuynO1fFbrGOZbmOT4AFuN4pxdEXR Cv3kkOB6NkEq2SOjiyDv+ztQUecCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBACNEm7wPk4uTZQIA5Tp8IbXh3Ztkg0ZAQ0Ub2Vd/1DV7J4BfH5BmldX3M70g eoKseo3necLywKU8dihFR07QIHOONis3hHdyqBJuv35THS7vrQqff1Xmu9yrpNTG41if6Wu8 kWyipIfMUDpqLlKURMBxl/DIizzZorfrIpf67E9OMIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIpXzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAxMDUxNDExMzcxOVowIwYJKoZIhvcNAQkEMRYEFJwAqEz4nyjD Bl7OjjCxxfm4fHkRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGA21v4LOd3CYs3iauGzfBtmpepnNqflGVvzv6dMxhie03LxLiRUwxd5ITOs9kduRNL MIU9F77Re7Z3Ytqc9Ull9YdjlCe7B6uXwO6LQ4m4gaigeMJRtPO31C9GzkvSIMd7+9vAXfwx jeQr6iVDYuk+au0o650UsghKyPCmYAT+3t4= --------------ms525B572A1A820D5BF63F8076-- From owner-ietf-ldup@mail.imc.org Wed May 16 16:55:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19001 for ; Wed, 16 May 2001 16:55:58 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA23797 for ietf-ldup-bks; Wed, 16 May 2001 13:14:12 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA23793 for ; Wed, 16 May 2001 13:14:06 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.12.1]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f4GKDBD17018; Wed, 16 May 2001 16:13:11 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA15695; Wed, 16 May 2001 16:12:59 -0400 Date: Wed, 16 May 2001 16:12:59 -0400 Message-Id: <200105162012.QAA15695@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: Comments on LCUP draft - opaque cookie Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This may be a duplicate for some of you. I apologize for that; the first version ran into a spam filter on one of the mailing lists because my mailer rewrites the sender's name in ways I wish it didn't. This comment refers to . The controls defined in the LCUP draft use an opaque cookie supplied by the server. I'm concerned about the consequences of leaving the cookie opaque. It seems to me that interoperability with multiple servers will be limited. Section 4.6 of the draft includes the note: (Note that the client can synchronize with different servers during different synchronization sessions.) If the cookie is opaque, this will only work if the different servers are all running the same server implementation. Different vendors' implementations of LCUP will inevitably use different cookie formats because there is no standard format. Section 7 notes: By design, the protocol does not specify the format of the cookie. This is to allow different implementations the flexibility of storing any information applicable to their environment. But that flexibility will limit interoperability. Since multi-vendor replicated directory environments are a goal of LDUP, shouldn't the content of the cookie be specified in the standard? Rick Huber From owner-ietf-ldup@mail.imc.org Wed May 16 18:10:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20073 for ; Wed, 16 May 2001 18:10:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA02370 for ietf-ldup-bks; Wed, 16 May 2001 14:29:14 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02349 for ; Wed, 16 May 2001 14:29:07 -0700 (PDT) Received: from qsun.mt.att.com ([135.16.31.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f4GLSaC10280; Wed, 16 May 2001 17:28:36 -0400 (EDT) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA27350; Wed, 16 May 2001 17:28:35 -0400 Date: Wed, 16 May 2001 17:28:35 -0400 Message-Id: <200105162128.RAA27350@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: Comments on LCUP draft Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These comments refer to . At the end of Section 3 there is a paragraph: A server can define a naming context or some part thereof to participate in LCUP. This document will refer to this as an LCUP Context. For example, LDUP defines a replica, a part of the DIT which may participate in replication. The LCUP context may be coincident with the replicated area, depending on the server's implementation. It is assumed that most server implementations of LCUP will make use of the server's underlying replication mechanism, but this does not have to be LDUP compliant. I assume there can be more than one LCUP Context per server. It should probably be explicitly stated one way or the other. ----- ----- Section 4.3 includes the paragraph: entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. The server MAY also set this to TRUE if the entry has left the client's search result set. As far as the client is concerned, a deleted entry is no different than an entry which has left the result set. Why is this a "MAY"? If LCUP doesn't inform clients of entries that have been renamed out of the search result set, it will never synchronize properly. As the text notes, to the client, this IS a delete. ----- ----- Section 4.8 says: Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. Since the server sends entries rather than operations, a MODDN might also be seen as a delete (if the new name was outside the clients search scope). If the MODDN is entirely within the search scope, what is sent? A delete and an add, or a modified entry with the existing entryUUID and a new RDN? Or LCUP doesn't care since the result ends up the same either way? ----- ----- In Section 5.1, discussion of the leftset feature includes the sentence: Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. This ties to my comment on 4.3. The entry that moved out of scope should be sent as a delete in the next synchronization session. If it isn't, you will never synchronize. If the server doesn't know when an entry has moved out of scope, how are these deletes correctly generated? ----- ----- In Section 5.4, I agree with Michael Armijo's comment. Especially since the draft allows the server to terminate a session at any time due to load. And even with his suggested addition, the client may find itself with parentless entries after an unexpected disconnect due to communications errors. If parents were always sent before children it would be much easier to clean up after unexpected disconnects. Rick Huber From owner-ietf-ldup@mail.imc.org Thu May 17 10:36:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18647 for ; Thu, 17 May 2001 10:36:15 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA25661 for ietf-ldup-bks; Thu, 17 May 2001 06:46:13 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.9.3/8.9.3) with SMTP id GAA25656 for ; Thu, 17 May 2001 06:46:06 -0700 (PDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA01296; Thu, 17 May 2001 09:45:21 -0400 Received: from ztcfd004.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 17 May 2001 09:44:59 -0400 Received: by ztcfd004.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 09:44:59 -0400 Message-ID: <438D12915E64D2118AB10000F8C1C078063A8E9A@zcard00e.ca.nortel.com> From: "James Benedict" To: rvh@qsun.mt.att.com, ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: RE: Comments on LCUP draft - opaque cookie Date: Thu, 17 May 2001 09:44:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DED7.90D8B4F0" X-Orig: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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_01C0DED7.90D8B4F0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] > Sent: Wednesday, May 16, 2001 12:55 PM > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com > Subject: Comments on LCUP draft - opaque cookie > > > This comment refers to . > > The controls defined in the LCUP draft use an opaque cookie > supplied by > the server. I'm concerned about the consequences of leaving > the cookie > opaque. It seems to me that interoperability with multiple servers > will be limited. > > Section 4.6 of the draft includes the note: > > (Note that the client can synchronize with different servers during > different synchronization sessions.) > > If the cookie is opaque, this will only work if the different servers > are all running the same server implementation. Different vendors' > implementations of LCUP will inevitably use different cookie formats > because there is no standard format. > > Section 7 notes: > > By design, the protocol does not specify the format of the cookie. > This is to allow different implementations the flexibility > of storing > any information applicable to their environment. > Haven't we been down this path before (with ACI)? I agree that the standard should not force a particular means of storing data, HOWEVER interoperability from a client perspective requires that information be common "on-the-wire". Or is the intention that LCUP clients maintain one cookie per server (or vendor type, or whatever...)? If this is the plan, then we still need to put some more smarts on the cookie so that the client can determine which cookie to send to which server. > But that flexibility will limit interoperability. Since multi-vendor > replicated directory environments are a goal of LDUP, shouldn't the > content of the cookie be specified in the standard? > > Rick Huber > > ------_=_NextPart_001_01C0DED7.90D8B4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments on LCUP draft - opaque cookie

> -----Original Message-----
> From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com]
> Sent: Wednesday, May 16, 2001 12:55 PM
> To: ietf-lcup@netscape.com; ietf-ldup@imc.org; = richm@iplanet.com
> Subject: Comments on LCUP draft - opaque = cookie
>
>
> This comment refers to = <draft-ietf-ldup-lcup-00.txt>.
>
> The controls defined in the LCUP draft use an = opaque cookie
> supplied by
> the server. I'm concerned about the = consequences of leaving
> the cookie
> opaque. It seems to me that = interoperability with multiple servers
> will be limited.
>
> Section 4.6 of the draft includes the = note:
>
>   (Note that the client can = synchronize with different servers during
>   different synchronization = sessions.)
>
> If the cookie is opaque, this will only work if = the different servers
> are all running the same server = implementation. Different vendors'
> implementations of LCUP will inevitably use = different cookie formats
> because there is no standard format.
>
> Section 7 notes:
>
>   By design, the protocol does not = specify the format of the cookie.
>   This is to allow different = implementations the flexibility
> of storing
>   any information applicable to their = environment.
>

Haven't we been down this path before (with = ACI)? I agree that the standard should not force a particular = means of storing data, HOWEVER interoperability from a client = perspective requires that information be common = "on-the-wire".

Or is the intention that LCUP clients maintain one = cookie per server (or vendor type, or whatever...)? If this = is the plan, then we still need to put some more smarts on the cookie = so that the client can determine which cookie to send to which = server.

> But that flexibility will limit = interoperability. Since multi-vendor
> replicated directory environments are a goal of = LDUP, shouldn't the
> content of the cookie be specified in the = standard?
>
> Rick Huber
>
>

------_=_NextPart_001_01C0DED7.90D8B4F0-- From owner-ietf-ldup@mail.imc.org Thu May 17 14:08:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23872 for ; Thu, 17 May 2001 14:08:37 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA14663 for ietf-ldup-bks; Thu, 17 May 2001 10:39:08 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14657 for ; Thu, 17 May 2001 10:39:02 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f4HHcXn24249 for ; Thu, 17 May 2001 10:38:33 -0700 (PDT) Received: from netscape.com ([192.18.121.187]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDHQC900.8QC; Thu, 17 May 2001 10:38:33 -0700 Message-ID: <3B040C99.27F345DC@netscape.com> Date: Thu, 17 May 2001 10:38:33 -0700 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Benedict CC: rvh@qsun.mt.att.com, ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Comments on LCUP draft - opaque cookie References: <438D12915E64D2118AB10000F8C1C078063A8E9A@zcard00e.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a good issue to discuss. I believe the intent is for an LCUP client to store one (or more) cookie(s) per server. But if a replicated set of directory servers are deployed and clients choose "one of many" to use for their LCUP sessions (for redundancy or load balancing reasons), it would be nice if the cookie format were consistent. On the other hand, specifying the format of the cookie will really tie the hands of server implementors. We need to clarify this in the LCUP specification, one way or another. -Mark James Benedict wrote: > > > -----Original Message----- > > From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com] > > Sent: Wednesday, May 16, 2001 12:55 PM > > To: ietf-lcup@netscape.com; ietf-ldup@imc.org; richm@iplanet.com > > Subject: Comments on LCUP draft - opaque cookie > > > > > > This comment refers to . > > > > The controls defined in the LCUP draft use an opaque cookie > > supplied by > > the server. I'm concerned about the consequences of leaving > > the cookie > > opaque. It seems to me that interoperability with multiple servers > > will be limited. > > > > Section 4.6 of the draft includes the note: > > > > (Note that the client can synchronize with different servers > during > > different synchronization sessions.) > > > > If the cookie is opaque, this will only work if the different > servers > > are all running the same server implementation. Different vendors' > > implementations of LCUP will inevitably use different cookie formats > > > because there is no standard format. > > > > Section 7 notes: > > > > By design, the protocol does not specify the format of the cookie. > > > This is to allow different implementations the flexibility > > of storing > > any information applicable to their environment. > > > > Haven't we been down this path before (with ACI)? I agree that the > standard should not force a particular means of storing data, HOWEVER > interoperability from a client perspective requires that information > be common "on-the-wire". > > Or is the intention that LCUP clients maintain one cookie per server > (or vendor type, or whatever...)? If this is the plan, then we still > need to put some more smarts on the cookie so that the client can > determine which cookie to send to which server. > > > But that flexibility will limit interoperability. Since > multi-vendor > > replicated directory environments are a goal of LDUP, shouldn't the > > content of the cookie be specified in the standard? > > > > Rick Huber From owner-ietf-ldup@mail.imc.org Fri May 18 12:53:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01237 for ; Fri, 18 May 2001 12:53:27 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA08372 for ietf-ldup-bks; Fri, 18 May 2001 09:14:18 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA08365 for ; Fri, 18 May 2001 09:14:12 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f4IGDgn02711 for ; Fri, 18 May 2001 09:13:42 -0700 (PDT) Received: from netscape.com ([129.157.192.243]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GDJH2T00.NFM; Fri, 18 May 2001 09:13:41 -0700 Message-ID: <3B0549D8.8D0F7BDC@netscape.com> Date: Fri, 18 May 2001 10:12:08 -0600 From: richm@netscape.com (Rich Megginson) Organization: iPlanet X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard V Huber CC: ietf-lcup@netscape.com, ietf-ldup@imc.org, richm@iplanet.com Subject: Re: Comments on LCUP draft References: <200105162128.RAA27350@qsun.mt.att.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCFFA9AEC3C073AEC158D8AD4" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msCFFA9AEC3C073AEC158D8AD4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard V Huber wrote: > These comments refer to . > > At the end of Section 3 there is a paragraph: > > A server can define a naming context or some part thereof to > participate in LCUP. This document will refer to this as an LCUP > Context. For example, LDUP defines a replica, a part of the DIT > which may participate in replication. The LCUP context may be > coincident with the replicated area, depending on the server's > implementation. It is assumed that most server implementations of > LCUP will make use of the server's underlying replication mechanism, > but this does not have to be LDUP compliant. > > I assume there can be more than one LCUP Context per server. It should > probably be explicitly stated one way or the other. Good idea. > > ----- ----- > > Section 4.3 includes the paragraph: > > entryDeleted - if set to TRUE, indicates that the entry to which > the control is attached was deleted. The server MAY also set > this to TRUE if the entry has left the client's search result > set. As far as the client is concerned, a deleted entry is no > different than an entry which has left the result set. > > Why is this a "MAY"? If LCUP doesn't inform clients of entries that > have been renamed out of the search result set, it will never > synchronize properly. As the text notes, to the client, this IS a > delete. Yes, but it may be very difficult for server implementers if this becomes a MUST. Sure, the client may have some entries locally which don't anymore exist in the search result set on the server. But for many client applications, this is acceptable. What we envision is that in the future, there may be different levels of LCUP support. The server will be able to publish if it is a MAY or MUST. > ----- ----- > > Section 4.8 says: > > Since the server sends to the client the modified entries rather than > the operations, a MODDN operation performed on a subtree will be seen > by the client as a sequence of added or modified entries depending on > whether the operation moved the entries into the scope of the > client's search specification. > > Since the server sends entries rather than operations, a MODDN might > also be seen as a delete (if the new name was outside the clients > search scope). Correct. > If the MODDN is entirely within the search scope, what is sent? A > delete and an add, or a modified entry with the existing entryUUID and > a new RDN? Or LCUP doesn't care since the result ends up the same > either way? I don't think it makes much difference either way. What do you think? > ----- ----- > > In Section 5.1, discussion of the leftset feature includes the > sentence: > > Ironically, this feature is the hardest to implement on the server > because the server does not keep track of the client's state and has > no easy way of telling which entries moved out of scope between > synchronization sessions with the client. > > This ties to my comment on 4.3. The entry that moved out of scope > should be sent as a delete in the next synchronization session. If it > isn't, you will never synchronize. For certain classes of client applications, this will be acceptable. > If the server doesn't know when an > entry has moved out of scope, how are these deletes correctly > generated? The problem is that it may be very difficult for server implementers to know that some meta data change affects some LCUP search. > ----- ----- > > In Section 5.4, I agree with Michael Armijo's comment. Especially > since the draft allows the server to terminate a session at any time > due to load. And even with his suggested addition, the client may find > itself with parentless entries after an unexpected disconnect due to > communications errors. Why would this be a problem? > If parents were always sent before children it > would be much easier to clean up after unexpected disconnects. > > Rick Huber --------------msCFFA9AEC3C073AEC158D8AD4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIpXzANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDEyMDQxNjMzMDZaFw0wMTA2MDIxNjMzMDZa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxITAf BgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5z b24xFTATBgoJkiaJk/IsZAEBEwVyaWNobTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5FgFqT5oTdQeMgUI2f3GSYsuty7+KimpWS5x4aBgL5eve2soq8zN66WfZzRq9Y2SUHrYdlgR JzqJo2p5hl1G+KgTdgRm69z9OUpv1Vt3yh8dTJ4H+OgGuynO1fFbrGOZbmOT4AFuN4pxdEXR Cv3kkOB6NkEq2SOjiyDv+ztQUecCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBACNEm7wPk4uTZQIA5Tp8IbXh3Ztkg0ZAQ0Ub2Vd/1DV7J4BfH5BmldX3M70g eoKseo3necLywKU8dihFR07QIHOONis3hHdyqBJuv35THS7vrQqff1Xmu9yrpNTG41if6Wu8 kWyipIfMUDpqLlKURMBxl/DIizzZorfrIpf67E9OMIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIpXzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAxMDUxODE2MTIwOFowIwYJKoZIhvcNAQkEMRYEFKUuj/jV6BYX NFzvP1WZufNTlW/EMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAYt7fa9JbhnbAM00WRrahXZNTkaOpmibLkuxf7W7KWe1mlD1wJTFeHX8NB69Y04/R dSuDs8eo0RFSHECo68gzsI8E4UmkjQ0sxCkQBTcNeHMH1d6hY0m3VxtdU7JQSsvuTsEKeuQx 2SmnfsjkGxklvvpHOXiWh9spIxJ3R+/nyHA= --------------msCFFA9AEC3C073AEC158D8AD4--