From owner-seamoby@diameter.org Mon Oct 1 19:24:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04504 for ; Mon, 1 Oct 2001 19:24:32 -0400 (EDT) Received: (qmail 22881 invoked by alias); 1 Oct 2001 23:08:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22875 invoked by uid 200); 1 Oct 2001 23:08:55 -0000 Received: (qmail 22870 invoked from network); 1 Oct 2001 23:08:52 -0000 Received: from ns02.newbridge.com (192.75.23.75) by c900656-a.plstn1.sfba.home.com with SMTP; 1 Oct 2001 23:08:52 -0000 Received: (qmail 15979 invoked from network); 1 Oct 2001 23:21:00 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 1 Oct 2001 23:21:00 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for seamoby@diameter.org; Mon, 1 Oct 2001 19:22:28 -0400 Received: from andrewk3 ([138.120.49.132]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA54BB; Mon, 1 Oct 2001 19:22:26 -0400 Reply-To: To: , "Andrew Krywaniuk" Cc: "'Behcet Sarikaya'" , Subject: RE: [seamoby] Paging ID submission Date: Mon, 1 Oct 2001 19:21:36 -0400 Message-Id: <001f01c14acf$d8d50790$1e72788a@andrewk3.ca.newbridge.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <3BB2819B.CB988A5B@inrialpes.fr> From: Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pars, Do not assume that IPsec is inherently high bandwidth. IPsec adds an extra level of encapsulation, which implies a fixed overhead per packet. If you want to use nested SAs for ingress filtering, then this doubles the per-packet overhead, but the outer tunnel terminates at the access gateway, so the extra overhead only applies to the leg across the public Internet. Similarly, if a gateway discovery protocol is used, the extra packets would not actually reach the mobile node. IPsec SA setup can take as many as 9 messages or as few as 2, depending on which key management protocol you use. I don't know if IPSP gateway discovery will be used in public environments. The technology is not very mature. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Pars.Mutaf@inrialpes.fr [mailto:Pars.Mutaf@inrialpes.fr] > Sent: Wednesday, September 26, 2001 9:32 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Behcet Sarikaya'; seamoby@diameter.org > Subject: Re: [seamoby] Paging ID submission > > > > Hello and thank you for the reply. > > > Andrew Krywaniuk wrote: > > > Hi Pars, > > > > It is possible to use IPsec in a nested tunnels > configuration. Envision the > > following connection profile: > > > > A ----{Internet}------ gateway ------ B > > > > In scenarios where one wishes to provide authenticated > ingress filtering to > > a LAN, the recommended solution is to set up two tunnels. > The outer tunnel, > > from A to the gateway, is authentication only; it provides source > > authentication and DoS filtering. The inner tunnel, from A > to B, provides > > end-to-end security. This scenario has not been widely > deployed yet, but the > > IPsec and IPSP WGs have been careful to ensure that it will > work. The route > > through the gateway can be preconfigured on each authorized > host, or it can > > be discovered through DNS or via a gateway discovery protocol (to be > > developed by IPSP). > > Do you think that the IPSP protocol is being designed for a > cellular public > network with millions of ``highly mobile'' hosts and millions > of cells? > Secondly, > one important motivation of paging is to minimize the > signaling costs due to > location management in cellular networks. IPsec and IPSP > based solutions would > require many message exchanges upon each dormant mode registration of > each host. This may reduce the motivations of paging. > > Another question that comes to mind: is IPSP possible in a public > environment. What do you think? > > Finally, the IPSP language is complicated for a wireless environment. > We should not forget that paging is used for saving scarce resources > e.g. bandwidth and battery. > > More comments? Thanks. > > Regards, > pars > > > From owner-seamoby@diameter.org Wed Oct 3 04:35:02 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03365 for ; Wed, 3 Oct 2001 04:34:53 -0400 (EDT) Received: (qmail 30867 invoked by alias); 3 Oct 2001 08:13:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30861 invoked by uid 200); 3 Oct 2001 08:13:52 -0000 Message-ID: <20011003081352.30860.qmail@charizard.diameter.org> Received: (qmail 30856 invoked from network); 3 Oct 2001 08:13:40 -0000 Received: from unknown (HELO charizard.cdma-2000.org) (65.113.239.43) by c900656-a.plstn1.sfba.home.com with SMTP; 3 Oct 2001 08:13:40 -0000 From: "President of Vallke Solutions - Velius D'Unnero" Date: Wed, 03 Oct 2001 01:27:44 To: seamoby@cdma-2000.org Subject: [seamoby] Once in a lifetime chance, please read. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit WORK AT HOME USING YOUR COMPUTER!!! _________________________________________________________________ Dear Friend, You can earn $46,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details (no, there is no "catch")... _________________________________________________________________________ "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the internet, a major nightly news program recently devoted an entire show to the investigation of the 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. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show has been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. "HERE IT IS BELOW" _________________________________________________________________________ _________________________________________________________________________ *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $46,000 in less than 90 days! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100\% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50\% and 65\% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 3,500,000 millionaires in the WORLD, 20\% ( 700,000) made their fortune in the last several years in MLM. Moreover, statistics show that over 100 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump (A MULTI-BILLIONAIRE, ONE OF THE WEALTHIEST MEN IN THE WORLD) made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. This program is currently being utilized in more than 50 different countries across the world. The enclosed INF0RMATION is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for INF0RMATION on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 100,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $46,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $46,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 100,000, I received $42,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $46,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received INF0RMATION 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 months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 1,600,000 programs. Now I have several offices that make this and several other programs here and over seas. 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 to everyone you can think of. One of the people you send this to may send out 100,000 or more...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, INF0RMATION, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $46,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Because of the global nature of the internet, you will be able to recruit new multi-level business partners from all over the world, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 5 reports shown on the list below (you can't sell them if you don't order them). a. For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! b. When you place your order, make sure you order each of the five reports. You will need all five reports so that you can save them on your computer and resell them. c. Within a few days you will receive, via e-mail, each of the five reports. 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. 2. 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 is instructed below in steps "a" through "g" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the five reports, take this advertisement and REM0VE the name and address under REPORT #5. This person has made it through the cycle and is no doubt counting their $46,000! Also, change the name of the company, the address, and the REM0VE e-mail address on the top of this document to your own. c. Move the name and address under REPORT #4 down to REPORT #5. d. Move the name and address under REPORT #3 down to REPORT #4. e. Move the name and address under REPORT #2 down to REPORT #3. f. Move the name and address under REPORT #1 down to REPORT #2. g. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $25). You obviously already have an Internet connection and e-mail is FREE! To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing INF0RMATION which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. In addition you will be provided with INF0MATION on Internet Marketing Clubs such as INTERNET MARKETING RESOURCES(IMR): This is one the premiere internet marketing clubs on the INTERNET. This club provides a forum where internet marketers from all over the world can exchange ideas and secrets on Internet Marketing. In addition, members of this club are provided free internet marketing tools and services for the Do-Yourself-Internet-Marketer. They will provide you with free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club will provide you with hundreds of free resources which include: How to obtain free web sites, how to obtain top rankings in search engines for your web-site, how to send bulk e-mail into AOL and Compuserve, how to market your products on newsgroups, free classified ads, electronic malls, bulletin boards, banner ads and much more. There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.3\% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.3\% response, that is only 6 orders for REPORT #1. Those 6 people respond by sending out 2,000 programs each for a total of 12,000. Out of those 0.3\%, 36 people respond and order REPORT #2. Those 36 mail out 2,000 programs each for a total of 72,000. The 0.3\% response to that is 216 orders for REPORT #3. Those 216 send out 2,000 programs each for a 432,000 total. The 0.3\% response to that is 1,296 orders for REPORT #4. Those 1,296 send out 2,000 programs each for a 2,592,000 total. The 0.3\% response to that is 7,776 orders for REPORT #5. That's 7,776 $5 bills for you, CASH!!! Your total income in this example is $30 + $180 + $1,080+ $6,480 + $38,880 for a total of $46,650!!! REMEMBER FRIEND, THIS IS ASSUMING 1,994 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an internet connection and e-mail is FREE!!! REPORT #2 and #5 will show you the best methods for bulk emailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists and show you how to send out 1,000,000 e-mails for free. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 6 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 6 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 6 members with $5 ($5 x 6)........................$30 2nd level--6 members from those 6 ($5 x 36)....................$180 3rd level--6 members from those 36 ($5 x 216)............ $1,080 4th level--6 members from those 216 ($5 x 1,296)....... $6,480 5th level-6 members from those 1,296 ($5 x 7,776)... $38,880 .................................................$46,650 _________________________________________________________________________ Remember friends, this assumes that the people who participate only recruit 6 people each. Think for a moment what would happen if they got 20 people to participate! Many people will get 100's of participants! THINK ABOUT IT! For every $5.00 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't advertise until they receive the report! _________________________________________________________________________ AVAILABLE REPORTS _________________________________________________________________________ *** Order Each REPORT by NUMBER and NAME *** Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT CHECKS NOT ACCEPTED ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering (b) your e-mail address (So your report can come by email) (c) your name & postal address. **** Place your name in the 1st report. Move the rest of the names down causing whoever is in 5th position to go off the list.**** PLACE YOUR ORDER FOR THESE REPORTS NOW: ______________________________________________________ REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM Ross Pawley 540 NW 2nd St. Apt7 Prineville, OR 97754 ______________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Spatter 2700 Waterview Pkwy. #4612 Richardson, TX 75080 __________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Jamie Strickland P.o Box 253 Charlton Heights, WV 25040 ______________________________________________________ REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Andrea Hataway 608 W. 8th St. Lancaster, TX 75146 ______________________________________________________ REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Robin Stice 690 Crespi Dr Pacifica, CA 94044 ______________________________________________________ ______________________________________________________ There currently more than 175,000,000 people online worldwide! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the five reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, 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 or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! ******* T E S T I M O N I A L S ******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Fred Dellaca, Westport, New Zealand My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the 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 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't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Mitchell Wolf MD., Chicago, IL The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Pam Hedland Halmstad, Sweden 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 surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return. Dan Sondstrom, Alberta, Canada I had received this program before. I deleted it, but later I wondered if I shouldn't 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 another program, 11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! Mohamed, Cairo, Egypt This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Sam Lee Suva, Fiji Islands ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS _________________________________________________________________________ PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependant on your activities and advertising. This letter constitutes no guarantees stated nor implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or non-verifiable. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. ______________________________________________________________________ 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. To be Removed please reply to email with the words REMOVE in the subject area. From owner-seamoby@diameter.org Wed Oct 3 16:28:58 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28575 for ; Wed, 3 Oct 2001 16:28:56 -0400 (EDT) Received: (qmail 1339 invoked by alias); 3 Oct 2001 20:13:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1333 invoked by uid 200); 3 Oct 2001 20:13:03 -0000 Received: (qmail 1325 invoked from network); 3 Oct 2001 20:13:01 -0000 Received: from mgw-dax2.ext.nokia.com (63.78.179.217) by c900656-a.plstn1.sfba.home.com with SMTP; 3 Oct 2001 20:13:01 -0000 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f93KRf702027; Wed, 3 Oct 2001 15:27:42 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Oct 2001 15:27:21 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Oct 2001 15:27:20 -0500 content-class: urn:content-classes:message Subject: RE: [seamoby] Looking for volunteers - paging Date: Wed, 3 Oct 2001 15:27:20 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D3A7239@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [seamoby] Looking for volunteers - paging Thread-Index: AcFCzzSqrJm8Va7AEdWxLgAIx6TWeAJej2QQ X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Faccin Stefano \(NRC/Dallas\)" To: Cc: X-OriginalArrivalTime: 03 Oct 2001 20:27:21.0090 (UTC) FILETIME=[CDB99620:01C14C49] Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28575 Pat, any news on the status of this? Thanks, Stefano > > > All, > > > > > > As previously discussed, all of the paging drafts have > been submitted, and > > > an evaluation of these protocols is required. Jim and I > would like to solicit > > > some non-biased volunteers to create an Internet-Draft > that includes a > > > comparison of each protocol against the requirements > (using the comparison > > > material submitted - and validating the comparison data). > > > > > > Any volunteers, please send an e-mail to Jim and I. We > need to have some > > > volunteers by mid next week, and will pick one volunteer > per submitted > > > protocol. > > > > > > Thanks, > > > > > > PatC From owner-seamoby@diameter.org Thu Oct 4 18:11:14 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25821 for ; Thu, 4 Oct 2001 18:11:10 -0400 (EDT) Received: (qmail 8327 invoked by alias); 4 Oct 2001 21:54:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8320 invoked by uid 200); 4 Oct 2001 21:54:08 -0000 From: alias@charizard.diameter.org Received: (qmail 8315 invoked from network); 4 Oct 2001 21:54:06 -0000 Received: from firewall.janus.net (HELO gateway.brueggemann.de) (195.4.94.9) by c900656-a.plstn1.sfba.home.com with SMTP; 4 Oct 2001 21:54:06 -0000 Received: from central.brueggemann.de (central.brueggemann.de [53.101.70.8]) by gateway.brueggemann.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f9508Gu17920; Fri, 5 Oct 2001 02:08:16 +0200 Received: from Yahoo.com ([192.168.250.9]) by central.brueggemann.de (Lotus Domino Release 5.0.6a) with SMTP id 2001100500014665:4780 ; Fri, 5 Oct 2001 00:01:46 +0200 To: "" Subject: [seamoby] ADV: Web Design? I still make more money than you at it! 7611 Date: Thu, 4 Oct 2001 18:01:20 -0400 MIME-Version: 1.0 X-Priority: 3 (Normal) Reply-To: webmaster3467@yahoo.com X-MIMETrack: Itemize by SMTP Server on central.brueggemann.de/Brueggemann(Release 5.0.6a |January 17, 2001) at 05.10.2001 00:01:56, MIME-CD by Trend Mailscan on central.brueggemann.de/Brueggemann(Release 5.0.6a |January 17, 2001) at 05.10.2001 00:01:57, MIME-CD complete at 05.10.2001 00:01:57, Serialize by Router on central.brueggemann.de/Brueggemann(Release 5.0.6a |January 17, 2001) at 05.10.2001 00:02:06 Message-ID: Content-type: text/plain; charset=us-ascii Sender: owner-seamoby@diameter.org Precedence: bulk I bet that I make more money in the Web design business than you do. My sales pitch looks like this: Free Website! Free .com, .net, or .org name! Free First Month! Free Shopping Cart for E-commerce! Free Secure Credit Card Transaction Server Access! Free Website Editor! (Allows you to control your entire site from anywhere in the world with nothing more than your Internet browser!) Free Website Statistics Analysis! Unlimited everything! Unlimited Email Addresses! Unlimited Hosting Space! Unlimited Bandwidth! Unlimited Pages! Unlimited Capacity of items in the Shopping Cart! Fastest Websites!!! (Hosted on the best servers and bandwidth anywhere!) Website Promotion Options... There is nothing left to add to this service! If you can use a word processor, You can manage your own website! Only $35/month after your first FREE month! Everything you need to be doing business online NOW is here for only $25! (Limited time offer) I have been advertising this pitch on the front of my website for my design business 1 month, I have received over 40 signups. People SIGNUP EVERY SINGLE DAY. Almost, they bunch up on the weekends often. 1 month= $1560 income that comes in every month with no work! I will beat that number this month easily, but assuming I just keep up the same pace, next month will net $3,120 PROFIT. FOR A FACT I will be netting at least $10,720 a month by the end of the year. I got that number after subtracting $8000 to account for cancellations down the line. That is a ton of money! I can not even think of a way to not hit that number unless I completely stopped doing everything. My service is also better. You can't give anyone the as much value as I can. You can't give them the power to control their site as I can. You can't give them the prices that I can. You can't get them online as fast as I can. And even if somehow you found a way to do all that, you won't able to keep your customers as long as I do. Wow. Don't believe me? The interface I give my customers is easier to use than any other I have seen. It is by far the best web based interface you will ever see. A monkey would have a hard time making a site look bad with the software I include for my Customers. I charge them $35 a month and I only pay $10! I know I could charge a lot more for the service, but I am more interested in getting as many customers as possible now, than I am on making more on them. If you did the numbers to make sure I wasn't making them up, you'll see $560 missing this month. Where did it come from? There is an optional search engine submission program, that 70 percent of the people that signup opt for, I charge them $30/month. I pay $10. If they do decide they would like custom work done, no problem. I do it for them, and they don't try to bother me to change little things all the time on their site, because I give them the power to do it themselves, which they prefer. I like it to, keeps my time free for things I enjoy. In addition to being able to get at customers you can't, and being able to upsell them to all the custom design work I like, when ever I like, I bet I have a whole bunch of other things you DO NOT HAVE. Private Labeled to me Website Builder/Store Builder (Best Anywhere) Private Labeled to me Shopping Cart Private Labeled to me WebMail and Pop3 Service Private Labeled to me Secure Server Hosting Private Labeled to me Domain Name Registration Private Labeled to me Search Engine Submission Private Labeled to me Control Panel for FTP, email, user access... I can make as many new templates as I like to start them out from too. I also never have to pay for custom CGI work to provide E-Commerce solutions anymore. It is all done for me already, even the payment gateway integration. I use the same service my end-users use to do design work and It has cut my design time in more than half. I can make a complete E-Commerce enabled site in 15-30 minutes, email, shopping cart, ftp, running on the net! Can you do that?? Long story short. Unless you have some plans I don't know about, My business will be beating yours for sure in about 12 months. Can you compete? Are you getting customers as fast as I am? Are you making as much on them as I am? Is that money you are making staying with you every month? Is there a way for you to provide my customers something I don't? Can you say the same for yourself? I am going to let you in on SECRET now. Even though I know that my business will most likely be making a lot more than yours in 12 months, I am not greedy. I know that BIG money is not in being greedy. I know that No matter how much money my design company makes next year, If I combined 4-5 heavy hitters in the industry they would best me. How can I beat that? Easy. Use my connection with the company that made me what I am, and enabled me to do things that no other design companies could do. I am best friends with the president of the company that designed all the amazing server side software I use to power my business, and I know that if he wanted to, he could start turning on every webdesign company in the world as a dealer if they saw what I was making. So, instead of trying to convince him to not show anyone else the software I use to make so much money (impossible.) I figured out that the best thing for me to team up with him, show other people how I was making all the money that I was, and get cut in on the deal. Long story short. I am making a ton of money retailing my E-Commerce Solution, and I love it. Now that I have tasted that success, I have decided to take it to the next level, and give others the same ability to make that same money I do. I can get you in with the company that I deal with that provided me with all of those amazing things that make my service so awesome. My reward: If I introduce even a few people to my supplier so to speak. And those people become even half as successful with it as I have, I can have my buy rate reduced even further below $10 a month (which is already insanely cheap if you haven't noticed) Your reward: If you will probably be making even more money retailing it than I am. All I am doing is driving traffic to my website, people signup. You probably already have a customer base underneath you that would love the product, and are more likely to offer the custom design work than I. I don't do flash, and I don't even advertise on my site that I do custom design work at all. You know, I'll tell you the truth, this interface is so easy that anyone could do it. HTML knowledge or not, really anyone can be a full Design/Hosting/E-Commerce solution provider with this. They even will bill your customers for free for you. Saved me the trouble of getting another merchant account to accept credit cards for this. I paid over $2000 for the privledge of being able to do what I do. I am extremely happy about that because I know people who have paid over $7,000 to do the same. The ball game has changed though. They want to bring on successful dealers like me NOW. And to make this easier, they have dropped the pricing to $99, $299, or $999 depending on how good you want your buy rates. At $999 they are even eating the setup fees ($10 gets your customer a free domain name, and first month). Since I know how powerful a sales tool my website is, and I want everyone I bring on to be as successful as possible, I will even give you a copy of my website (customized to look like you invented it though) hosted for free to sell from. I know it works because I get signups every day. Then you are almost guaranteed to make a ton of money with it, as long as you get traffic to it. If you want to see some of the sites built by my solution, the site I have great success selling from, or how I make all the money I do with it, and how you can to, or to show awesome the software is to use, call me or email me. 1-888-549-0766 or 1-954-585-6460 This week only. Monday-Saturday 11-7 EST. If you do not wish to receive email from me, email: webmaster0273@yahoo.com (anything that goes here gets removed) or call. From owner-seamoby@diameter.org Fri Oct 5 15:04:15 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28980 for ; Fri, 5 Oct 2001 15:04:15 -0400 (EDT) Received: (qmail 13544 invoked by alias); 5 Oct 2001 18:48:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 13538 invoked by uid 200); 5 Oct 2001 18:48:38 -0000 Received: (qmail 13533 invoked from network); 5 Oct 2001 18:48:36 -0000 Received: from netmail.alcatel.com (128.251.168.50) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Oct 2001 18:48:36 -0000 Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA23981; Fri, 5 Oct 2001 14:03:03 -0500 (CDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f95J32P29377; Fri, 5 Oct 2001 14:03:02 -0500 (CDT) Message-ID: <3BBE0534.F390D485@alcatel.com> Date: Fri, 05 Oct 2001 14:08:36 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: h.takusagawa@jp.fujitsu.com CC: sridhar.gurivireddy@alcatel.com, andrew.krywaniuk@alcatel.com, seamoby Subject: [seamoby] Re: questions on LAHAP draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Hideaki, In the case when Layer 3 paging areas are supported, whenever MN changes paging area, TA in the new subnet is notified using layer 2 trigger. If the new TA is in the same layer 3 paging area, MN does not perform any registration. Since the paging request sent by PA is multicast in the layer 3 paging area, the new TA also receives the paging request. When MN enters a new subnet(TA) in different layer 3 paging area, MN has to perform a new registration with DMA.(only one registration) Hope this clarifies your concern. Hideaki Takusagawa wrote: > Dear Sridhar, Behcet and Andrew > > Hi, my name is Hideaki and I'm from Fujitsu Labs. > I've been reading the LAHAP draft and have a few questions. > I'm new to IP paging so if you could help me out i really appreciate it. > > From what i understand, L2 triggers only updates > L2 paging area to the TA, since movement within > an AR is restricted to changes L2 paging area. > > So how does L3 paging area updates work? > In contrast to other protocols where one TA kept track of > changes in the host's L3 paging area, it seems that the TA > changes every time the host changes AR. > Then does the host register the new TA address to the DMA > on each occasion? (but then PA wouldn't be required because > the TA knows where the host is....) > Or does it register only when it changes L3 paging area? > > Sincerely, > Hideaki > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Hideaki Takusagawa > Network Systems Laboratories FUJITSU LABORATORIES LTD. > Phone:044-754-2786 (Internal) 7112-6146 Fax:044-754-2786 > Email: h.takusagawa@jp.fujitsu.com Regards, -- Behcet From owner-seamoby@diameter.org Mon Oct 8 07:36:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18298 for ; Mon, 8 Oct 2001 07:36:32 -0400 (EDT) Received: (qmail 358 invoked by alias); 8 Oct 2001 11:20:55 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 352 invoked by uid 200); 8 Oct 2001 11:20:55 -0000 Received: (qmail 347 invoked by uid 500); 8 Oct 2001 11:20:53 -0000 Date: Mon, 8 Oct 2001 04:20:53 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] WG Last Call: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ct-reqs-01.txt Message-ID: <20011008042053.C32547@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, The above draft has been updated to include the resolution following the London meeting. The new version of the draft is in WG last call, which will expire Oct 22, 2001. Please send any comments on the draft to the list. Thanks, PatC From owner-seamoby@diameter.org Mon Oct 8 07:40:16 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18382 for ; Mon, 8 Oct 2001 07:40:16 -0400 (EDT) Received: (qmail 1051 invoked by alias); 8 Oct 2001 11:24:48 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1045 invoked by uid 200); 8 Oct 2001 11:24:48 -0000 Received: (qmail 1039 invoked by uid 500); 8 Oct 2001 11:24:45 -0000 Date: Mon, 8 Oct 2001 04:24:45 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] WG Last Call: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-cardiscovery-issues-01.txt Message-ID: <20011008042445.F32547@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, The above draft has been updated to include the resolution following the London meeting. The new version of the draft is in WG last call, which will expire Oct 22, 2001. Please send any comments on the draft to the list. Thanks, PatC From owner-seamoby@diameter.org Mon Oct 8 09:13:28 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20873 for ; Mon, 8 Oct 2001 09:13:28 -0400 (EDT) Received: (qmail 2884 invoked by alias); 8 Oct 2001 12:57:43 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2878 invoked by uid 200); 8 Oct 2001 12:57:43 -0000 Received: (qmail 2873 invoked from network); 8 Oct 2001 12:57:41 -0000 Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Oct 2001 12:57:41 -0000 Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id <4KA6Q92D>; Mon, 8 Oct 2001 09:11:40 -0400 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0486165B2@meshpdc.meshnetworks.com> From: Phillip Neumiller To: "'seamoby@diameter.org'" Subject: [seamoby] Some final comments on CT reqs Date: Mon, 8 Oct 2001 09:11:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, A couple comments on the requirements on the CT reqs follow. 1). I really do not think requirement 4.9 has to be a MUST. The way this requirements is worded, it implies that mutual authentication is required before CT can be used. I don't think this MUST be the case. IF authentication is used, then YES, it MUST be done before the CT would be better wording I think. 2). There is no statement about conflicting context, i.e. race conditions that may arise when context that differs is received simultaneously from different hosts, how is this arbitration settled? Since the context itself is opaque to this protocol, how could we guarantee atomic self-consistent transactions. Here is a pathalogical example: A--CT--> B <--CT-- C A knows nothing of C, and C knows nothing of B, but both transfer context to B successfully. Suppose this is video codec context and B has only capacity to service one more video codec? It would seem that some type of negotiation is needed to ensure self consistent transactions with all participants. Thanks, Phil -- Mesh Networks, Inc. (www.meshnetworks.com) Phillip D. Neumiller, Staff Scientist pneumiller@meshnetworks.com PH: 1-407-659-5387 **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. From owner-seamoby@diameter.org Mon Oct 8 09:54:19 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21761 for ; Mon, 8 Oct 2001 09:54:18 -0400 (EDT) Received: (qmail 3639 invoked by alias); 8 Oct 2001 13:38:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3633 invoked by uid 200); 8 Oct 2001 13:38:41 -0000 Received: (qmail 3628 invoked from network); 8 Oct 2001 13:38:39 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 8 Oct 2001 13:38:39 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98Drlf15831 for ; Mon, 8 Oct 2001 16:53:47 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Oct 2001 16:53:13 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6489JF>; Mon, 8 Oct 2001 16:53:14 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBCD6@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: PNeumiller@MeshNetworks.com, seamoby@diameter.org Subject: RE: [seamoby] Some final comments on CT reqs Date: Mon, 8 Oct 2001 16:53:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Phil & Pat, My 2 cents ... > 1). I really do not think requirement 4.9 has to be a MUST. > The way this requirements is worded, it implies that mutual > authentication is required before CT can be used. I don't think > this MUST be the case. IF authentication is used, then YES, > it MUST be done before the CT would be better wording I think. I agree, so I'd wordsmith it to be: 4.9 Mutual authentication of entities transferring context prior to initiating the transfer MUST .be supported It is believed that if a formal authentication exchange (e.g. exchanging credentials) were done during the context transfer, the computation overhead for both the sender and the receiver would cause additional and unnecessary latency to the handoff process. Therefore, the mechanisms MUST support the exchange credentials prior to any context transfer. > 2). There is no statement about conflicting context, i.e. race > conditions that may arise when context that differs is received > simultaneously from different hosts, how is this arbitration > settled? Since the context itself is opaque to this protocol, > how could we guarantee atomic self-consistent transactions. This would be a nice feature, but unless you have specific text in mind, I don't see this as a big issue ... br, John I'll take the document home & give it a thorough read tonight - comments tomorrow. From owner-seamoby@diameter.org Tue Oct 9 19:43:45 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14938 for ; Tue, 9 Oct 2001 19:43:44 -0400 (EDT) Received: (qmail 17237 invoked by alias); 9 Oct 2001 23:28:03 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17230 invoked by uid 200); 9 Oct 2001 23:28:02 -0000 Message-ID: <20011009232802.17229.qmail@charizard.diameter.org> Received: (qmail 17220 invoked from network); 9 Oct 2001 23:27:57 -0000 Received: from 1cust241.tnt4.cph3.da.uu.net (HELO mydomain.com) (213.116.23.241) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Oct 2001 23:27:57 -0000 Date: Wed, 10 Oct 2001 01:39:52 +0100 From: EROTICAWWW To: EROTICAWWW@charizard.diameter.org Subject: [seamoby] SEXWEB NO.1 .. MEGAWEB-SEX ! Sender: owner-seamoby@diameter.org Precedence: bulk Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER the Worldīs No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you donīt need to sign-up or have a creditcard ... The way it should be ! TO PLUGIN and get access to something you with guarantee NEVER have seen before, use ANY of the servers listed below ! Enjoy the BEST! Yours truly, EROTICAWWW INC. To get EASY ACCESS & PLUGIN to the LARGEST CONTENT SEXSERVER on the NET, use any of the 2 SERVERS listed here: 1. http://superhits.onweb.cx 2. http://wwwap.to/superhits From owner-seamoby@diameter.org Wed Oct 10 17:13:51 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21374 for ; Wed, 10 Oct 2001 17:13:51 -0400 (EDT) Received: (qmail 32246 invoked by alias); 10 Oct 2001 20:58:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 32240 invoked by uid 200); 10 Oct 2001 20:58:18 -0000 Received: (qmail 32235 invoked from network); 10 Oct 2001 20:58:16 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Oct 2001 20:58:16 -0000 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA14538 for ; Wed, 10 Oct 2001 14:12:59 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA29171 for ; Wed, 10 Oct 2001 14:12:59 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0BJ05M>; Wed, 10 Oct 2001 16:12:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA08C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@diameter.org Subject: [seamoby] security disabling in CT reqs Date: Wed, 10 Oct 2001 16:12:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I have one quick comment for now: I understand the thought behind the following section (some folks don't care about security in their internal networks) 5.3.3 The protocol MUST provide for the security provisioning to be disabled. However, reading in the ESP RFC, I found out that you cannot NULL both authentication and encryption at the same time. this means that ESP cannot be proposed for securing CT messages. Since, I cannot disable both encryption and authentication at the same time, so I cannot meet 5.3.3. Does this mean, ESP is out of question for CT? Any idea? Regards, Madjid From owner-seamoby@diameter.org Wed Oct 10 19:25:27 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23008 for ; Wed, 10 Oct 2001 19:25:11 -0400 (EDT) Received: (qmail 497 invoked by alias); 10 Oct 2001 23:00:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 489 invoked by uid 200); 10 Oct 2001 23:00:23 -0000 Received: (qmail 484 invoked from network); 10 Oct 2001 23:00:21 -0000 Received: from motgate2.mot.com (136.182.1.10) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Oct 2001 23:00:21 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA08353 for ; Wed, 10 Oct 2001 16:15:00 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA19325 for ; Wed, 10 Oct 2001 16:06:01 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KWV9CBZ>; Wed, 10 Oct 2001 18:14:56 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA097@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@diameter.org Subject: [seamoby] FW: look at CT design team leader's email Date: Wed, 10 Oct 2001 18:14:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C151E1.5B768530" Sender: owner-seamoby@diameter.org 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_01C151E1.5B768530 Content-Type: text/plain; charset="iso-8859-1" Gary, A ROHC fellow forwarded me this email. Would you care to explain why you think CT is dead? (or maybe it should be dead? ) We have been patiently waited for completion of the requirements!! Have a good day, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, October 09, 2001 11:26 AM To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' Subject: RE: [rohc] ROHC context transfer Lars-Erik: A number of attempts were made to engage people more familiar with ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement of knowledgeable people in a number of areas. This is a fatal weakness in my view, as the critical requirements for making CT work is the requirements set by the feature itself, not on abstract protocol requirements. I have made this point many times on the CT list, to no avail. It matters not, perhaps, for as far as I can see, CT is dead. There is next to no activity on this issue in Seamoby, and the problem statement lacks approval, even though it was completed many months ago. We shall see, but I do not intend to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the IESG. I did sit down with Carson Bormann at IETF 51. He expressed similar concerns as you, and we walked through my draft. Frankly, almost all of his comments were a matter of mis-interpreting my text, and the changes requested were mostly to make my draft more explanatory. I will do so, but frankly, this draft is not meant to be a normative reference for ROHC. As for the link layer dependencies: I find it curious that the IETF would develop a protocol that is link layer dependent, don't you? More comments below. Thank you for your input. I will take it into account, if I revise the I-D. Cheers, Gary > -----Original Message----- > From: Lars-Erik Jonsson (EPL) > [ mailto:Lars-Erik.Jonsson@epl.ericsson.se ] > Sent: October 9, 2001 10:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' > Subject: RE: [rohc] ROHC context transfer > > > Hi Gary and others, > > I know that some people believe in context transfer, e.g. for > header compression, and I can not judge whether this might be > useful or not. Personally, I am skeptical to the whole idea > but I accept that others have a different opinion and I may > be convinced about the usefulness of header compression > context transfer for certain specific environments. However, > I strongly believe that at least for header compression, > context transfer is a link-technology dependent issue, and > would be implemented based on where/how header compression is > implemented in that specific link technology. > > Even if I really do not care about context transfer, I do > care about ROHC and that this work is not justified by, or > carried out based on, incorrect understandings of ROHC. > Previous discussions about this (in ROHC, SEAMOBY and > MOBILEIP) has shown a significant lack of ROHC knowledge from > those proposing context transfer (for ROHC!). Most > surprising, when ROHC authors have pointed out incorrect > statements about ROHC operation, this has even been > questioned by the context transfer proponents. This draft > (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to > previous drafts that have made several incorrect statements > about ROHC. However, this time I will concentrate on the > draft "Context Transfer Considerations for ROHC". With ROHC, > I refer either to the ROHC WG or to RFC-3095. > > See comments below... > > Cheers, > /Lars-Erik > > > >>> Section 3 - Overview ROHC Context > > > ... > > The decompressor monitors the success of decompression of > > the IP packets, and acknowledges successful decompression > > to the compressor. The compressor attempts to compress the > > IP packets as much as possible, as long as the transmitted > > packets are acknowledged. > > LEJ: ROHC may operate in 3 different modes, U-, O-, > or R-mode. Operation always start in U-mode and transition > to O- or R-mode may later be carried out through feedback > from the decompressor. The above text is correct only for > ROHC R-mode operation. A matter of interpretation: in my view, U- and O- modes can be considered "fallback" modes for R-mode. In other words, R-mode is the preferred mode of operation, providing the most compression. U- and O- modes are provided to accomodate the unreliable nature of the channel. Thus, ROHC attempts to compress as well as it can (R-mode), but sometimes cannot (O-, U- modes). > > > ... > > What makes ROHC robust is the intrinsic bias of the state > > machines to return to a basic mode of operation where no > > compression is performed. > > LEJ: Here the conceptually orthogonal terms state and > mode are mixed. The correct wording here should be state > only. However, what makes ROHC robust, compared to earlier > compression schemes, is obviously not the descriptive state > machine concept. I would counter that this is semantics. Defining multiple "modes" in the end results in the same outcome: multiple states in an implementation. I will use the wording preferred by the ROHC wg, but personally, I see it as conotational slight of hand. > > > ... > > Simply because of the robust definition of ROHC, it is > > possible to handover the uncompressed packet stream from > > the SAR to the RAR without the integrity of the IP sessions > > being compromised. ROCH defines an uncompressed, or > > no-compression profile with an identifier value of 0x0000. > > Because of the semantics of the CID encoding, a regular, > > uncompressed IP packet, is interpreted as having a profile > > of 0x0000. > > LEJ: The no-compression profile is not about what this text > indicates. The no-compression profile is used for streams > that can not be compressed with the profiles supported by > a compressor and decompressor pair, to be used over links > where only ROHC packets can be transmitted (not e.g. PPP). > This is thus not the no-context-transfer alternative. The > alternative to context transfer is simply to restart header > compression in IR-state, as a new packet stream for the new > link. I understand the intent of the 0x0000 profile defined by ROHC. However (and I explicitly posted this question to the wg email list), if ROHC is to be robust for handovers, then using 0x0000 as a fallback profile would not only be useful, it is a requirement. There is no way to gaurantee quasi-static context transfers for ROHC, thus a fall back mode is required. My perspective on this is to apply ROHC as a feature for packet communications. It is also possible to treat ROHC as a circuit switched feature (i.e. put it at the link layer), but, IMHO, this does not promote efficient packet switching. > > > ... > > The cons for this approach include: > > > > - the RAR may not be able to re-establish compression for > > traffic destined for the MN. The RAR would have no > > direct method of determining that the stream was to be > > compressed. > > LEJ: It would of course have to use the same method as any > node uses to determine if/how header compression can be > applied to new packet streams. If I understand you, the usual method involves signalling to/from the MN. This is always an option, but not an appealing one, as it does not seem conducive to a "seamless handover". Even if it were, it would consume precious bandwidth over the air. Handovers can be very serendipious, specially in pico cell environments in urban or indoor areas. Even one over the air message can be a significant overhead if there is lots of handovers occuring. One of the goals of Seamoby was to accomplish a handover with (ideally) no over the air signalling. I put it to you: how do you suggest one do this with ROHC? > > > ... > >>> Section 4.2 - Header Compression Profile Transfer > > LEJ: The heading itself indicates that something is not > correct here. A profile is nothing that can be subject to > transfer. A profile defines how a specific kind of packet > streams are compressed, i.e. basically the actual > compression protocol (in ROHC consistent with the framework). > Should it be "Context Transfer"? There are two issues here: a) do the CT source and destination share the same "profiles", if the answer is yes (hopefully), then a "profile transfer" would simply be a transfer of the profile id. If the answer is "no", then yes, it is argueable that there is nothing to transfer. I wanted to leave open the possibility of a "building block" approach to specifying profiles that might allow the receiver to "build" profile support. It's a complication that is, I agree, very difficult to realize, and therefore unlikely. > > > ... > > One issue with this approach is the reliance on the RAR > > having the same header compression profile. The IR packet > > conveys the profile ID and not the profile, and the RAR > > must match the received profile ID with one of the > > profiles in its local repository. > > LEJ: Once again, what is meant with "the profile"?. The > profile ID determines the profile, which is a compression > protocol, not a state. Also here, should it say "context"? To summarize, the context here is at least the profile id. It is likely nothing more. I should note, as I alluded to above, that CT can only be shown to work, IMHO, if we develope specific requirements and make some decisions on what to support and what not to. Unfortunately, the requirements for Seamoby span everything from cellular systems to 802.11, Bluetooth, and ad hoc networks. The latter two being completely unknown, and thus open to wild conjectures, like suppossed handovers between two dissimilar access routers. > > > ... > > Even if the RAR finds a matching ID, it is not clear that > > the profiles will match: e.g. for inter-technology > > handovers, say Bluetooth to 802.11, some of the link > > dependent aspects of the profile may change. > > LEJ: This just highlights the obvious fact that context > transfer for header compression is a link-issue. Two link > technologies might be supporting different profile sets, > or they might even be using different compression schemes > (not necessary ROHC). Further, inter-technology context > transfer would require inter-technology communication, or > higher layers to carry out the context transfer, which would > require higher layers to know about the lower layers. Well, no one can debate supposed link layer differences, certainly not in an IETF document. What you seem to be telling me is either that ROHC is a link layer protocol (which means it doesn't belong in the IETF) or that it relies heavily on link specific solutions, which means that is not an IP level solution (and doesn't belong in the IETF). As a side note: the intent is to define context transfer as a capability enabling protocol that might allow router manufacturers to transfer link layer state or whatever state they see fit. For many technologies, it will not be the appropriate solution. CT is fundamentally limited by being an IP layer soluton. > > > ... > >>> 4.3 - Static Compression Context Transfer > > ... > > The IR packet provides all the static context required > > to initiate the compressor and decompressor state machines. > > The first level of actual header compression for ROHC > > compresses the static and quasi- static fields. > > LEJ: The IR packet normally contains ALL header information, > both static and dynamic. I do not know what is meant with > quasi-static, only that it is not a term used by ROHC. It *at least* contains all the static context information, does it not? Quasi-static is a term I coined to apply to portions of the dynamic compression context. It applies to information that is dynamic, but changes slower then with every packet. It may be correct to simply send over all of the dynamic context, and let ROHC at the destination deal with the inconsistencies. I felt, and still do, that we could be smarter then this: i.e. build in a degree of robustness with ROHC that deals with handovers. However, this was presumptuous. > > > ... > >>> 4.4 - Dynamic Compression Context Transfer > > ... > > Dynamic compression context transfer will succeed for > > reactive context transfer only if the transfer can be > > completed between a packet arrival at the SAR and the > > first or second consecutive packet arrival at the RAR. > > LEJ: This is absolutely not true, ROHC is designed to be > robust against packet loss. It is true that there might be > problems like this with context transfer, if it is not > completed fast enough, but it is not true that ROHC can not > handle losses, as the above text indicates. You are looking at this from the perspective of ROHC. The issue is not whether ROHC can handle it, the issue is whether it is worth performing CT for dynamic state or not. If CT of dynamic context must rely upon ROHC robustness to recover, then it is not worth doing (reliance is, of course, a matter of frequency; clearly, if ROHC robustness is required to recover 90% of the time, then CT of dynamic ROHC context is not worth doing). Indeed, the proposal is to transfer only the static context, and let ROHC robustness do what it was designed to do. The question really is would CT of dynamic compression context really This section will be revised, if the draft is revised, to include dyanmic compression context. I believe I have someone from ROHC willing to contribute text. > > > ... > >>> 5.1 - ROHC Context for Header Profile Transfer > > It is assumed that the RAR and the SAR use identical header > > compression algorithms and header compression profiles. > > LEJ: As mentioned before, a ROHC profile can not possibly > be subject to transfer. In the same way, "header profile" is > not a term that makes sense either. A profile defines the > header compression protocol (algorithm) to be used. See above. There is a lot about ROHC which is in peoples heads, and not clear in the RFC (which would not be unusual for an IETF RFC *smile*). Thanks again for the comments. I certainly will keep them in mind if the draft is revised. I am very much open to comments, and hopefully, to contributed ideas/text. > > > > -----Original Message----- > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > < mailto:gkenward@nortelnetworks.com > ] > Sent: den 26 juli 2001 17:23 > To: 'ROHC' > Subject: [rohc] ROHC context transfer > > > > Hello. > > I have submitted a draft to the Context and Micro-Mobility > Routing (Seamoby) > working group on "Context Transfer Considerations for ROHC". > ROHC is fairly > new to me, and I would really appreciate any feedback from > the ROHC wg. > > Regards, > Gary Kenward > > http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c t-rohc-reqs-00.txt < http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt > . title: Context Transfer Considerations for ROHC abstract: There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. author: Gary Kenward date: 07/12/2001 id: draft-kenward-seamoby-ct-rohc-reqs-00.txt ------_=_NextPart_001_01C151E1.5B768530 Content-Type: text/html; charset="iso-8859-1" RE: [rohc] ROHC context transfer
Gary,
 
A ROHC fellow  forwarded me this email.
Would you care to explain why you think CT is dead?
(or maybe it should be dead? )
 
We have been patiently waited for completion of the requirements!!
 
Have a good day,
Madjid 
 -----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, October 09, 2001 11:26 AM
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC'
Subject: RE: [rohc] ROHC context transfer

Lars-Erik:

  A number of attempts were made to engage people more familiar with
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement
of knowledgeable people in a number of areas. This is a fatal weakness in my
view, as the critical requirements for making CT work is the requirements set
by the feature itself, not on abstract protocol requirements. I have made this
point many times on the CT list, to no avail.

  It matters not, perhaps, for as far as I can see, CT is dead. There is next
to no activity on this issue in Seamoby, and the problem statement lacks approval,
even though it was completed many months ago. We shall see, but I do not intend
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the
IESG.

  I did sit down with Carson Bormann at IETF 51. He expressed similar concerns
as you, and we walked through my draft. Frankly, almost all of his comments were
a matter of mis-interpreting my text, and the changes requested were mostly to
make my draft more explanatory. I will do so, but frankly, this draft is not
meant to be a normative reference for ROHC.

  As for the link layer dependencies: I find it curious that the IETF would develop
a protocol that is link layer dependent, don't you?

  More comments below.
 
  Thank you for your input. I will take it into account, if I revise the I-D.

Cheers,
Gary

> -----Original Message-----
> From: Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: October 9, 2001 10:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC'
> Subject: RE: [rohc] ROHC context transfer
>
>
> Hi Gary and others,
> 
> I know that some people believe in context transfer, e.g. for
> header compression, and I can not judge whether this might be
> useful or not. Personally, I am skeptical to the whole idea
> but I accept that others have a different opinion and I may
> be convinced about the usefulness of header compression
> context transfer for certain specific environments. However,
> I strongly believe that at least for header compression,
> context transfer is a link-technology dependent issue, and
> would be implemented based on where/how header compression is
> implemented in that specific link technology.
> 
> Even if I really do not care about context transfer, I do
> care about ROHC and that this work is not justified by, or
> carried out based on, incorrect understandings of ROHC.
> Previous discussions about this (in ROHC, SEAMOBY and
> MOBILEIP) has shown a significant lack of ROHC knowledge from
> those proposing context transfer (for ROHC!). Most
> surprising, when ROHC authors have pointed out incorrect
> statements about ROHC operation, this has even been
> questioned by the context transfer proponents. This draft
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to
> previous drafts that have made several incorrect statements
> about ROHC. However, this time I will concentrate on the
> draft "Context Transfer Considerations for ROHC". With ROHC,
> I refer either to the ROHC WG or to RFC-3095.
> 
> See comments below...
> 
> Cheers,
> /Lars-Erik
> 
> 
> >>> Section 3 - Overview ROHC Context
>
> > ...
> > The decompressor monitors the success of decompression of
> > the IP packets, and acknowledges successful decompression
> > to the compressor. The compressor attempts to compress the
> > IP packets as much as possible, as long as the transmitted
> > packets are acknowledged.
>  
> LEJ: ROHC may operate in 3 different modes, U-, O-,
> or R-mode. Operation always start in U-mode and transition
> to O- or R-mode may later be carried out through feedback
> from the decompressor. The above text is correct only for
> ROHC R-mode operation.

A matter of interpretation: in my view, U- and O- modes can be
considered "fallback" modes for R-mode. In other words, R-mode
is the preferred mode of operation, providing the most compression.
U- and O- modes are provided to accomodate the unreliable nature
of the channel. Thus, ROHC attempts to compress as well as it can
(R-mode), but sometimes cannot (O-, U- modes).
>  
> > ...
> > What makes ROHC robust is the intrinsic bias of the state
> > machines to return to a basic mode of operation where no
> > compression is performed.
>  
> LEJ: Here the conceptually orthogonal terms state and
> mode are mixed. The correct wording here should be state
> only. However, what makes ROHC robust, compared to earlier
> compression schemes, is obviously not the descriptive state
> machine concept.

I would counter that this is semantics. Defining multiple "modes"
in the end results in the same outcome: multiple states in an
implementation. I will use the wording preferred by the ROHC wg,
but personally, I see it as conotational slight of hand.

>
> > ...
> > Simply because of the robust definition of ROHC, it is
> > possible to handover the uncompressed packet stream from
> > the SAR to the RAR without the integrity of the IP sessions
> > being compromised. ROCH defines an uncompressed, or
> > no-compression profile with an identifier value of 0x0000.
> > Because of the semantics of the CID encoding, a regular,
> > uncompressed IP packet, is interpreted as having a profile
> > of 0x0000.
>
> LEJ: The no-compression profile is not about what this text
> indicates. The no-compression profile is used for streams
> that can not be compressed with the profiles supported by
> a compressor and decompressor pair, to be used over links
> where only ROHC packets can be transmitted (not e.g. PPP).
> This is thus not the no-context-transfer alternative. The
> alternative to context transfer is simply to restart header
> compression in IR-state, as a new packet stream for the new
> link.

I understand the intent of the 0x0000 profile defined by ROHC.
However (and I explicitly posted this question to the wg email
list), if ROHC is to be robust for handovers, then using 0x0000
as a fallback profile would not only be useful, it is a requirement.
There is no way to gaurantee quasi-static context transfers for ROHC,
thus a fall back mode is required.

My perspective on this is to apply ROHC as a feature for packet communications.
It is also possible to treat ROHC as a circuit switched feature (i.e. put it
at the link layer), but, IMHO, this does not promote efficient packet switching.

>
> > ...
> > The cons for this approach include:
> >
> > - the RAR may not be able to re-establish compression for
> >   traffic destined for the MN. The RAR would have no
> >   direct method of determining that the stream was to be
> >   compressed.
>
> LEJ: It would of course have to use the same method as any
> node uses to determine if/how header compression can be
> applied to new packet streams.

If I understand you, the usual method involves signalling to/from
the MN. This is always an option, but not an appealing one, as it
does not seem conducive to a "seamless handover". Even if it were,
it would consume precious bandwidth over the air.

Handovers can be very serendipious, specially in pico cell environments
in urban or indoor areas. Even one over the air message can be a
significant overhead if there is lots of handovers occuring.

One of the goals of Seamoby was to accomplish a handover with (ideally)
no over the air signalling. I put it to you: how do you suggest one
do this with ROHC?
>
> > ...
> >>> Section 4.2 - Header Compression Profile Transfer
>
> LEJ: The heading itself indicates that something is not
> correct here. A profile is nothing that can be subject to
> transfer. A profile defines how a specific kind of packet
> streams are compressed, i.e. basically the actual
> compression protocol (in ROHC consistent with the framework).
> Should it be "Context Transfer"?

There are two issues here: a) do the CT source and destination
share the same "profiles", if the answer is yes (hopefully), then
a "profile transfer" would simply be a transfer of the profile id.
If the answer is "no", then yes, it is argueable that there is nothing
to transfer. I wanted to leave open the possibility of a "building block"
approach to specifying profiles that might allow the receiver to
"build" profile support. It's a complication that is, I agree, very
difficult to realize, and therefore unlikely.

>
> > ...
> > One issue with this approach is the reliance on the RAR
> > having the same header compression profile. The IR packet
> > conveys the profile ID and not the profile, and the RAR
> > must match the received profile ID with one of the
> > profiles in its local repository.
>
> LEJ: Once again, what is meant with "the profile"?. The
> profile ID determines the profile, which is a compression
> protocol, not a state. Also here, should it say "context"?

To summarize, the context here is at least the profile id.
It is likely nothing more.

I should note, as I alluded to above, that CT can only be shown
to work, IMHO, if we develope specific requirements and make
some decisions on what to support and what not to. Unfortunately,
the requirements for Seamoby span everything from cellular systems
to 802.11, Bluetooth, and ad hoc networks. The latter two being
completely unknown, and thus open to wild conjectures, like
suppossed handovers between two dissimilar access routers.

>
> > ...
> > Even if the RAR finds a matching ID, it is not clear that
> > the profiles will match: e.g. for inter-technology
> > handovers, say Bluetooth to 802.11, some of the link
> > dependent aspects of the profile may change.
>
> LEJ: This just highlights the obvious fact that context
> transfer for header compression is a link-issue. Two link
> technologies might be supporting different profile sets,
> or they might even be using different compression schemes
> (not necessary ROHC). Further, inter-technology context
> transfer would require inter-technology communication, or
> higher layers to carry out the context transfer, which would
> require higher layers to know about the lower layers.

Well, no one can debate supposed link layer differences, certainly
not in an IETF document. What you seem to be telling me is either that
ROHC is a link layer protocol (which means it doesn't belong in the IETF)
or that it relies heavily on link specific solutions, which means that is
not an IP level solution (and doesn't belong in the IETF).

As a side note: the intent is to define context transfer as a capability
enabling protocol that might allow router manufacturers to transfer link
layer state or whatever state they see fit. For many technologies, it will
not be the appropriate solution. CT is fundamentally limited by being an IP
layer soluton.

>
> > ...
> >>> 4.3 - Static Compression Context Transfer
> > ...
> > The IR packet provides all the static context required
> > to initiate the compressor and decompressor state machines.
> > The first level of actual header compression for ROHC
> > compresses the static and quasi- static fields.
>
> LEJ: The IR packet normally contains ALL header information,
> both static and dynamic. I do not know what is meant with
> quasi-static, only that it is not a term used by ROHC.

It *at least* contains all the static context information,
does it not?

Quasi-static is a term I coined to apply to portions of the
dynamic compression context. It applies to information that
is dynamic, but changes slower then with every packet.

It may be correct to simply send over all of the dynamic context,
and let ROHC at the destination deal with the inconsistencies.
I felt, and still do, that we could be smarter then this:
i.e. build in a degree of robustness with ROHC that deals
with handovers. However, this was presumptuous.

>
> > ...
> >>> 4.4 - Dynamic Compression Context Transfer
> > ...
> > Dynamic compression context transfer will succeed for
> > reactive context transfer only if the transfer can be
> > completed between a packet arrival at the SAR and the
> > first or second consecutive packet arrival at the RAR.
>
> LEJ: This is absolutely not true, ROHC is designed to be
> robust against packet loss. It is true that there might be
> problems like this with context transfer, if it is not
> completed fast enough, but it is not true that ROHC can not
> handle losses, as the above text indicates.

You are looking at this from the perspective of ROHC. The issue
is not whether ROHC can handle it, the issue is whether it is
worth performing CT for dynamic state or not. If CT of dynamic
context must rely upon ROHC robustness to recover, then it is not
worth doing (reliance is, of course, a matter of frequency; clearly,
if ROHC robustness is required to recover 90% of the time, then CT
of dynamic ROHC context is not worth doing).

Indeed, the proposal is to transfer only the static context, and
let ROHC robustness do what it was designed to do. The question
really is would CT of dynamic compression context really

This section will be revised, if the draft is revised, to include
dyanmic compression context. I believe I have someone from ROHC
willing to contribute text.

>
> > ...
> >>> 5.1 - ROHC Context for Header Profile Transfer
> > It is assumed that the RAR and the SAR use identical header
> > compression algorithms and header compression profiles.
>
> LEJ: As mentioned before, a ROHC profile can not possibly
> be subject to transfer. In the same way, "header profile" is
> not a term that makes sense either. A profile defines the
> header compression protocol (algorithm) to be used.

See above. There is a lot about ROHC which is in peoples heads,
and not clear in the RFC (which would not be unusual for an IETF
RFC *smile*).

Thanks again for the comments. I certainly will keep them in mind
if the draft is revised. I am very much open to comments, and hopefully,
to contributed ideas/text.

>
> 
>
> -----Original Message-----
> From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
> <mailto:gkenward@nortelnetworks.com> ]
> Sent: den 26 juli 2001 17:23
> To: 'ROHC'
> Subject: [rohc] ROHC context transfer
>
>
>
> Hello.
>
> I have submitted a draft to the Context and Micro-Mobility
> Routing (Seamoby)
> working group on "Context Transfer Considerations for ROHC".
> ROHC is fairly
> new to me, and I would really appreciate any feedback from
> the ROHC wg.
>
> Regards,
> Gary Kenward
>
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
t-rohc-reqs-00.txt <http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt> .

title: Context Transfer Considerations for ROHC
abstract: There is an interest in enhancing the performance of handover between access
routers through the transfer of forwarding context [2]. To clearly understand the requirements
for this transfer, it is useful to examine the requirements of specific feature contexts. This
document reviews the requirements for transferring the context associated with RObust Header
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed.
author: Gary Kenward
date: 07/12/2001
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt


------_=_NextPart_001_01C151E1.5B768530-- From owner-seamoby@diameter.org Wed Oct 10 19:51:54 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23193 for ; Wed, 10 Oct 2001 19:51:18 -0400 (EDT) Received: (qmail 785 invoked by alias); 10 Oct 2001 23:09:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 779 invoked by uid 200); 10 Oct 2001 23:09:37 -0000 Received: (qmail 770 invoked from network); 10 Oct 2001 23:09:31 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Oct 2001 23:09:31 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA03043 for ; Wed, 10 Oct 2001 16:23:56 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA27672 for ; Wed, 10 Oct 2001 16:23:56 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0BKCBQ>; Wed, 10 Oct 2001 18:23:55 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA098@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , seamoby@diameter.org Subject: [seamoby] last email. Date: Wed, 10 Oct 2001 18:23:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C151E2.91F006D0" Sender: owner-seamoby@diameter.org 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_01C151E2.91F006D0 Content-Type: text/plain; charset="iso-8859-1" I am really sorry for the subject in the previous email. I forgot to change the subject. Still curious about the answer though. -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Wednesday, October 10, 2001 6:15 PM To: seamoby@diameter.org Subject: [seamoby] FW: look at CT design team leader's email Gary, A ROHC fellow forwarded me this email. Would you care to explain why you think CT is dead? (or maybe it should be dead? ) We have been patiently waited for completion of the requirements!! Have a good day, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, October 09, 2001 11:26 AM To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' Subject: RE: [rohc] ROHC context transfer Lars-Erik: A number of attempts were made to engage people more familiar with ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement of knowledgeable people in a number of areas. This is a fatal weakness in my view, as the critical requirements for making CT work is the requirements set by the feature itself, not on abstract protocol requirements. I have made this point many times on the CT list, to no avail. It matters not, perhaps, for as far as I can see, CT is dead. There is next to no activity on this issue in Seamoby, and the problem statement lacks approval, even though it was completed many months ago. We shall see, but I do not intend to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the IESG. I did sit down with Carson Bormann at IETF 51. He expressed similar concerns as you, and we walked through my draft. Frankly, almost all of his comments were a matter of mis-interpreting my text, and the changes requested were mostly to make my draft more explanatory. I will do so, but frankly, this draft is not meant to be a normative reference for ROHC. As for the link layer dependencies: I find it curious that the IETF would develop a protocol that is link layer dependent, don't you? More comments below. Thank you for your input. I will take it into account, if I revise the I-D. Cheers, Gary > -----Original Message----- > From: Lars-Erik Jonsson (EPL) > [ mailto:Lars-Erik.Jonsson@epl.ericsson.se ] > Sent: October 9, 2001 10:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' > Subject: RE: [rohc] ROHC context transfer > > > Hi Gary and others, > > I know that some people believe in context transfer, e.g. for > header compression, and I can not judge whether this might be > useful or not. Personally, I am skeptical to the whole idea > but I accept that others have a different opinion and I may > be convinced about the usefulness of header compression > context transfer for certain specific environments. However, > I strongly believe that at least for header compression, > context transfer is a link-technology dependent issue, and > would be implemented based on where/how header compression is > implemented in that specific link technology. > > Even if I really do not care about context transfer, I do > care about ROHC and that this work is not justified by, or > carried out based on, incorrect understandings of ROHC. > Previous discussions about this (in ROHC, SEAMOBY and > MOBILEIP) has shown a significant lack of ROHC knowledge from > those proposing context transfer (for ROHC!). Most > surprising, when ROHC authors have pointed out incorrect > statements about ROHC operation, this has even been > questioned by the context transfer proponents. This draft > (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to > previous drafts that have made several incorrect statements > about ROHC. However, this time I will concentrate on the > draft "Context Transfer Considerations for ROHC". With ROHC, > I refer either to the ROHC WG or to RFC-3095. > > See comments below... > > Cheers, > /Lars-Erik > > > >>> Section 3 - Overview ROHC Context > > > ... > > The decompressor monitors the success of decompression of > > the IP packets, and acknowledges successful decompression > > to the compressor. The compressor attempts to compress the > > IP packets as much as possible, as long as the transmitted > > packets are acknowledged. > > LEJ: ROHC may operate in 3 different modes, U-, O-, > or R-mode. Operation always start in U-mode and transition > to O- or R-mode may later be carried out through feedback > from the decompressor. The above text is correct only for > ROHC R-mode operation. A matter of interpretation: in my view, U- and O- modes can be considered "fallback" modes for R-mode. In other words, R-mode is the preferred mode of operation, providing the most compression. U- and O- modes are provided to accomodate the unreliable nature of the channel. Thus, ROHC attempts to compress as well as it can (R-mode), but sometimes cannot (O-, U- modes). > > > ... > > What makes ROHC robust is the intrinsic bias of the state > > machines to return to a basic mode of operation where no > > compression is performed. > > LEJ: Here the conceptually orthogonal terms state and > mode are mixed. The correct wording here should be state > only. However, what makes ROHC robust, compared to earlier > compression schemes, is obviously not the descriptive state > machine concept. I would counter that this is semantics. Defining multiple "modes" in the end results in the same outcome: multiple states in an implementation. I will use the wording preferred by the ROHC wg, but personally, I see it as conotational slight of hand. > > > ... > > Simply because of the robust definition of ROHC, it is > > possible to handover the uncompressed packet stream from > > the SAR to the RAR without the integrity of the IP sessions > > being compromised. ROCH defines an uncompressed, or > > no-compression profile with an identifier value of 0x0000. > > Because of the semantics of the CID encoding, a regular, > > uncompressed IP packet, is interpreted as having a profile > > of 0x0000. > > LEJ: The no-compression profile is not about what this text > indicates. The no-compression profile is used for streams > that can not be compressed with the profiles supported by > a compressor and decompressor pair, to be used over links > where only ROHC packets can be transmitted (not e.g. PPP). > This is thus not the no-context-transfer alternative. The > alternative to context transfer is simply to restart header > compression in IR-state, as a new packet stream for the new > link. I understand the intent of the 0x0000 profile defined by ROHC. However (and I explicitly posted this question to the wg email list), if ROHC is to be robust for handovers, then using 0x0000 as a fallback profile would not only be useful, it is a requirement. There is no way to gaurantee quasi-static context transfers for ROHC, thus a fall back mode is required. My perspective on this is to apply ROHC as a feature for packet communications. It is also possible to treat ROHC as a circuit switched feature (i.e. put it at the link layer), but, IMHO, this does not promote efficient packet switching. > > > ... > > The cons for this approach include: > > > > - the RAR may not be able to re-establish compression for > > traffic destined for the MN. The RAR would have no > > direct method of determining that the stream was to be > > compressed. > > LEJ: It would of course have to use the same method as any > node uses to determine if/how header compression can be > applied to new packet streams. If I understand you, the usual method involves signalling to/from the MN. This is always an option, but not an appealing one, as it does not seem conducive to a "seamless handover". Even if it were, it would consume precious bandwidth over the air. Handovers can be very serendipious, specially in pico cell environments in urban or indoor areas. Even one over the air message can be a significant overhead if there is lots of handovers occuring. One of the goals of Seamoby was to accomplish a handover with (ideally) no over the air signalling. I put it to you: how do you suggest one do this with ROHC? > > > ... > >>> Section 4.2 - Header Compression Profile Transfer > > LEJ: The heading itself indicates that something is not > correct here. A profile is nothing that can be subject to > transfer. A profile defines how a specific kind of packet > streams are compressed, i.e. basically the actual > compression protocol (in ROHC consistent with the framework). > Should it be "Context Transfer"? There are two issues here: a) do the CT source and destination share the same "profiles", if the answer is yes (hopefully), then a "profile transfer" would simply be a transfer of the profile id. If the answer is "no", then yes, it is argueable that there is nothing to transfer. I wanted to leave open the possibility of a "building block" approach to specifying profiles that might allow the receiver to "build" profile support. It's a complication that is, I agree, very difficult to realize, and therefore unlikely. > > > ... > > One issue with this approach is the reliance on the RAR > > having the same header compression profile. The IR packet > > conveys the profile ID and not the profile, and the RAR > > must match the received profile ID with one of the > > profiles in its local repository. > > LEJ: Once again, what is meant with "the profile"?. The > profile ID determines the profile, which is a compression > protocol, not a state. Also here, should it say "context"? To summarize, the context here is at least the profile id. It is likely nothing more. I should note, as I alluded to above, that CT can only be shown to work, IMHO, if we develope specific requirements and make some decisions on what to support and what not to. Unfortunately, the requirements for Seamoby span everything from cellular systems to 802.11, Bluetooth, and ad hoc networks. The latter two being completely unknown, and thus open to wild conjectures, like suppossed handovers between two dissimilar access routers. > > > ... > > Even if the RAR finds a matching ID, it is not clear that > > the profiles will match: e.g. for inter-technology > > handovers, say Bluetooth to 802.11, some of the link > > dependent aspects of the profile may change. > > LEJ: This just highlights the obvious fact that context > transfer for header compression is a link-issue. Two link > technologies might be supporting different profile sets, > or they might even be using different compression schemes > (not necessary ROHC). Further, inter-technology context > transfer would require inter-technology communication, or > higher layers to carry out the context transfer, which would > require higher layers to know about the lower layers. Well, no one can debate supposed link layer differences, certainly not in an IETF document. What you seem to be telling me is either that ROHC is a link layer protocol (which means it doesn't belong in the IETF) or that it relies heavily on link specific solutions, which means that is not an IP level solution (and doesn't belong in the IETF). As a side note: the intent is to define context transfer as a capability enabling protocol that might allow router manufacturers to transfer link layer state or whatever state they see fit. For many technologies, it will not be the appropriate solution. CT is fundamentally limited by being an IP layer soluton. > > > ... > >>> 4.3 - Static Compression Context Transfer > > ... > > The IR packet provides all the static context required > > to initiate the compressor and decompressor state machines. > > The first level of actual header compression for ROHC > > compresses the static and quasi- static fields. > > LEJ: The IR packet normally contains ALL header information, > both static and dynamic. I do not know what is meant with > quasi-static, only that it is not a term used by ROHC. It *at least* contains all the static context information, does it not? Quasi-static is a term I coined to apply to portions of the dynamic compression context. It applies to information that is dynamic, but changes slower then with every packet. It may be correct to simply send over all of the dynamic context, and let ROHC at the destination deal with the inconsistencies. I felt, and still do, that we could be smarter then this: i.e. build in a degree of robustness with ROHC that deals with handovers. However, this was presumptuous. > > > ... > >>> 4.4 - Dynamic Compression Context Transfer > > ... > > Dynamic compression context transfer will succeed for > > reactive context transfer only if the transfer can be > > completed between a packet arrival at the SAR and the > > first or second consecutive packet arrival at the RAR. > > LEJ: This is absolutely not true, ROHC is designed to be > robust against packet loss. It is true that there might be > problems like this with context transfer, if it is not > completed fast enough, but it is not true that ROHC can not > handle losses, as the above text indicates. You are looking at this from the perspective of ROHC. The issue is not whether ROHC can handle it, the issue is whether it is worth performing CT for dynamic state or not. If CT of dynamic context must rely upon ROHC robustness to recover, then it is not worth doing (reliance is, of course, a matter of frequency; clearly, if ROHC robustness is required to recover 90% of the time, then CT of dynamic ROHC context is not worth doing). Indeed, the proposal is to transfer only the static context, and let ROHC robustness do what it was designed to do. The question really is would CT of dynamic compression context really This section will be revised, if the draft is revised, to include dyanmic compression context. I believe I have someone from ROHC willing to contribute text. > > > ... > >>> 5.1 - ROHC Context for Header Profile Transfer > > It is assumed that the RAR and the SAR use identical header > > compression algorithms and header compression profiles. > > LEJ: As mentioned before, a ROHC profile can not possibly > be subject to transfer. In the same way, "header profile" is > not a term that makes sense either. A profile defines the > header compression protocol (algorithm) to be used. See above. There is a lot about ROHC which is in peoples heads, and not clear in the RFC (which would not be unusual for an IETF RFC *smile*). Thanks again for the comments. I certainly will keep them in mind if the draft is revised. I am very much open to comments, and hopefully, to contributed ideas/text. > > > > -----Original Message----- > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > < mailto:gkenward@nortelnetworks.com > ] > Sent: den 26 juli 2001 17:23 > To: 'ROHC' > Subject: [rohc] ROHC context transfer > > > > Hello. > > I have submitted a draft to the Context and Micro-Mobility > Routing (Seamoby) > working group on "Context Transfer Considerations for ROHC". > ROHC is fairly > new to me, and I would really appreciate any feedback from > the ROHC wg. > > Regards, > Gary Kenward > > http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c t-rohc-reqs-00.txt < http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00 .txt > . title: Context Transfer Considerations for ROHC abstract: There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. author: Gary Kenward date: 07/12/2001 id: draft-kenward-seamoby-ct-rohc-reqs-00.txt ------_=_NextPart_001_01C151E2.91F006D0 Content-Type: text/html; charset="iso-8859-1" RE: [rohc] ROHC context transfer
I am really sorry for the subject in the previous email.
I forgot to change the subject. Still curious about the answer though.
 
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Wednesday, October 10, 2001 6:15 PM
To: seamoby@diameter.org
Subject: [seamoby] FW: look at CT design team leader's email

Gary,
 
A ROHC fellow  forwarded me this email.
Would you care to explain why you think CT is dead?
(or maybe it should be dead? )
 
We have been patiently waited for completion of the requirements!!
 
Have a good day,
Madjid 
 -----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, October 09, 2001 11:26 AM
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC'
Subject: RE: [rohc] ROHC context transfer

Lars-Erik:

  A number of attempts were made to engage people more familiar with
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement
of knowledgeable people in a number of areas. This is a fatal weakness in my
view, as the critical requirements for making CT work is the requirements set
by the feature itself, not on abstract protocol requirements. I have made this
point many times on the CT list, to no avail.

  It matters not, perhaps, for as far as I can see, CT is dead. There is next
to no activity on this issue in Seamoby, and the problem statement lacks approval,
even though it was completed many months ago. We shall see, but I do not intend
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the
IESG.

  I did sit down with Carson Bormann at IETF 51. He expressed similar concerns
as you, and we walked through my draft. Frankly, almost all of his comments were
a matter of mis-interpreting my text, and the changes requested were mostly to
make my draft more explanatory. I will do so, but frankly, this draft is not
meant to be a normative reference for ROHC.

  As for the link layer dependencies: I find it curious that the IETF would develop
a protocol that is link layer dependent, don't you?

  More comments below.
 
  Thank you for your input. I will take it into account, if I revise the I-D.

Cheers,
Gary

> -----Original Message-----
> From: Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: October 9, 2001 10:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC'
> Subject: RE: [rohc] ROHC context transfer
>
>
> Hi Gary and others,
> 
> I know that some people believe in context transfer, e.g. for
> header compression, and I can not judge whether this might be
> useful or not. Personally, I am skeptical to the whole idea
> but I accept that others have a different opinion and I may
> be convinced about the usefulness of header compression
> context transfer for certain specific environments. However,
> I strongly believe that at least for header compression,
> context transfer is a link-technology dependent issue, and
> would be implemented based on where/how header compression is
> implemented in that specific link technology.
> 
> Even if I really do not care about context transfer, I do
> care about ROHC and that this work is not justified by, or
> carried out based on, incorrect understandings of ROHC.
> Previous discussions about this (in ROHC, SEAMOBY and
> MOBILEIP) has shown a significant lack of ROHC knowledge from
> those proposing context transfer (for ROHC!). Most
> surprising, when ROHC authors have pointed out incorrect
> statements about ROHC operation, this has even been
> questioned by the context transfer proponents. This draft
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to
> previous drafts that have made several incorrect statements
> about ROHC. However, this time I will concentrate on the
> draft "Context Transfer Considerations for ROHC". With ROHC,
> I refer either to the ROHC WG or to RFC-3095.
> 
> See comments below...
> 
> Cheers,
> /Lars-Erik
> 
> 
> >>> Section 3 - Overview ROHC Context
>
> > ...
> > The decompressor monitors the success of decompression of
> > the IP packets, and acknowledges successful decompression
> > to the compressor. The compressor attempts to compress the
> > IP packets as much as possible, as long as the transmitted
> > packets are acknowledged.
>  
> LEJ: ROHC may operate in 3 different modes, U-, O-,
> or R-mode. Operation always start in U-mode and transition
> to O- or R-mode may later be carried out through feedback
> from the decompressor. The above text is correct only for
> ROHC R-mode operation.

A matter of interpretation: in my view, U- and O- modes can be
considered "fallback" modes for R-mode. In other words, R-mode
is the preferred mode of operation, providing the most compression.
U- and O- modes are provided to accomodate the unreliable nature
of the channel. Thus, ROHC attempts to compress as well as it can
(R-mode), but sometimes cannot (O-, U- modes).
>  
> > ...
> > What makes ROHC robust is the intrinsic bias of the state
> > machines to return to a basic mode of operation where no
> > compression is performed.
>  
> LEJ: Here the conceptually orthogonal terms state and
> mode are mixed. The correct wording here should be state
> only. However, what makes ROHC robust, compared to earlier
> compression schemes, is obviously not the descriptive state
> machine concept.

I would counter that this is semantics. Defining multiple "modes"
in the end results in the same outcome: multiple states in an
implementation. I will use the wording preferred by the ROHC wg,
but personally, I see it as conotational slight of hand.

>
> > ...
> > Simply because of the robust definition of ROHC, it is
> > possible to handover the uncompressed packet stream from
> > the SAR to the RAR without the integrity of the IP sessions
> > being compromised. ROCH defines an uncompressed, or
> > no-compression profile with an identifier value of 0x0000.
> > Because of the semantics of the CID encoding, a regular,
> > uncompressed IP packet, is interpreted as having a profile
> > of 0x0000.
>
> LEJ: The no-compression profile is not about what this text
> indicates. The no-compression profile is used for streams
> that can not be compressed with the profiles supported by
> a compressor and decompressor pair, to be used over links
> where only ROHC packets can be transmitted (not e.g. PPP).
> This is thus not the no-context-transfer alternative. The
> alternative to context transfer is simply to restart header
> compression in IR-state, as a new packet stream for the new
> link.

I understand the intent of the 0x0000 profile defined by ROHC.
However (and I explicitly posted this question to the wg email
list), if ROHC is to be robust for handovers, then using 0x0000
as a fallback profile would not only be useful, it is a requirement.
There is no way to gaurantee quasi-static context transfers for ROHC,
thus a fall back mode is required.

My perspective on this is to apply ROHC as a feature for packet communications.
It is also possible to treat ROHC as a circuit switched feature (i.e. put it
at the link layer), but, IMHO, this does not promote efficient packet switching.

>
> > ...
> > The cons for this approach include:
> >
> > - the RAR may not be able to re-establish compression for
> >   traffic destined for the MN. The RAR would have no
> >   direct method of determining that the stream was to be
> >   compressed.
>
> LEJ: It would of course have to use the same method as any
> node uses to determine if/how header compression can be
> applied to new packet streams.

If I understand you, the usual method involves signalling to/from
the MN. This is always an option, but not an appealing one, as it
does not seem conducive to a "seamless handover". Even if it were,
it would consume precious bandwidth over the air.

Handovers can be very serendipious, specially in pico cell environments
in urban or indoor areas. Even one over the air message can be a
significant overhead if there is lots of handovers occuring.

One of the goals of Seamoby was to accomplish a handover with (ideally)
no over the air signalling. I put it to you: how do you suggest one
do this with ROHC?
>
> > ...
> >>> Section 4.2 - Header Compression Profile Transfer
>
> LEJ: The heading itself indicates that something is not
> correct here. A profile is nothing that can be subject to
> transfer. A profile defines how a specific kind of packet
> streams are compressed, i.e. basically the actual
> compression protocol (in ROHC consistent with the framework).
> Should it be "Context Transfer"?

There are two issues here: a) do the CT source and destination
share the same "profiles", if the answer is yes (hopefully), then
a "profile transfer" would simply be a transfer of the profile id.
If the answer is "no", then yes, it is argueable that there is nothing
to transfer. I wanted to leave open the possibility of a "building block"
approach to specifying profiles that might allow the receiver to
"build" profile support. It's a complication that is, I agree, very
difficult to realize, and therefore unlikely.

>
> > ...
> > One issue with this approach is the reliance on the RAR
> > having the same header compression profile. The IR packet
> > conveys the profile ID and not the profile, and the RAR
> > must match the received profile ID with one of the
> > profiles in its local repository.
>
> LEJ: Once again, what is meant with "the profile"?. The
> profile ID determines the profile, which is a compression
> protocol, not a state. Also here, should it say "context"?

To summarize, the context here is at least the profile id.
It is likely nothing more.

I should note, as I alluded to above, that CT can only be shown
to work, IMHO, if we develope specific requirements and make
some decisions on what to support and what not to. Unfortunately,
the requirements for Seamoby span everything from cellular systems
to 802.11, Bluetooth, and ad hoc networks. The latter two being
completely unknown, and thus open to wild conjectures, like
suppossed handovers between two dissimilar access routers.

>
> > ...
> > Even if the RAR finds a matching ID, it is not clear that
> > the profiles will match: e.g. for inter-technology
> > handovers, say Bluetooth to 802.11, some of the link
> > dependent aspects of the profile may change.
>
> LEJ: This just highlights the obvious fact that context
> transfer for header compression is a link-issue. Two link
> technologies might be supporting different profile sets,
> or they might even be using different compression schemes
> (not necessary ROHC). Further, inter-technology context
> transfer would require inter-technology communication, or
> higher layers to carry out the context transfer, which would
> require higher layers to know about the lower layers.

Well, no one can debate supposed link layer differences, certainly
not in an IETF document. What you seem to be telling me is either that
ROHC is a link layer protocol (which means it doesn't belong in the IETF)
or that it relies heavily on link specific solutions, which means that is
not an IP level solution (and doesn't belong in the IETF).

As a side note: the intent is to define context transfer as a capability
enabling protocol that might allow router manufacturers to transfer link
layer state or whatever state they see fit. For many technologies, it will
not be the appropriate solution. CT is fundamentally limited by being an IP
layer soluton.

>
> > ...
> >>> 4.3 - Static Compression Context Transfer
> > ...
> > The IR packet provides all the static context required
> > to initiate the compressor and decompressor state machines.
> > The first level of actual header compression for ROHC
> > compresses the static and quasi- static fields.
>
> LEJ: The IR packet normally contains ALL header information,
> both static and dynamic. I do not know what is meant with
> quasi-static, only that it is not a term used by ROHC.

It *at least* contains all the static context information,
does it not?

Quasi-static is a term I coined to apply to portions of the
dynamic compression context. It applies to information that
is dynamic, but changes slower then with every packet.

It may be correct to simply send over all of the dynamic context,
and let ROHC at the destination deal with the inconsistencies.
I felt, and still do, that we could be smarter then this:
i.e. build in a degree of robustness with ROHC that deals
with handovers. However, this was presumptuous.

>
> > ...
> >>> 4.4 - Dynamic Compression Context Transfer
> > ...
> > Dynamic compression context transfer will succeed for
> > reactive context transfer only if the transfer can be
> > completed between a packet arrival at the SAR and the
> > first or second consecutive packet arrival at the RAR.
>
> LEJ: This is absolutely not true, ROHC is designed to be
> robust against packet loss. It is true that there might be
> problems like this with context transfer, if it is not
> completed fast enough, but it is not true that ROHC can not
> handle losses, as the above text indicates.

You are looking at this from the perspective of ROHC. The issue
is not whether ROHC can handle it, the issue is whether it is
worth performing CT for dynamic state or not. If CT of dynamic
context must rely upon ROHC robustness to recover, then it is not
worth doing (reliance is, of course, a matter of frequency; clearly,
if ROHC robustness is required to recover 90% of the time, then CT
of dynamic ROHC context is not worth doing).

Indeed, the proposal is to transfer only the static context, and
let ROHC robustness do what it was designed to do. The question
really is would CT of dynamic compression context really

This section will be revised, if the draft is revised, to include
dyanmic compression context. I believe I have someone from ROHC
willing to contribute text.

>
> > ...
> >>> 5.1 - ROHC Context for Header Profile Transfer
> > It is assumed that the RAR and the SAR use identical header
> > compression algorithms and header compression profiles.
>
> LEJ: As mentioned before, a ROHC profile can not possibly
> be subject to transfer. In the same way, "header profile" is
> not a term that makes sense either. A profile defines the
> header compression protocol (algorithm) to be used.

See above. There is a lot about ROHC which is in peoples heads,
and not clear in the RFC (which would not be unusual for an IETF
RFC *smile*).

Thanks again for the comments. I certainly will keep them in mind
if the draft is revised. I am very much open to comments, and hopefully,
to contributed ideas/text.

>
> 
>
> -----Original Message-----
> From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
> <mailto:gkenward@nortelnetworks.com> ]
> Sent: den 26 juli 2001 17:23
> To: 'ROHC'
> Subject: [rohc] ROHC context transfer
>
>
>
> Hello.
>
> I have submitted a draft to the Context and Micro-Mobility
> Routing (Seamoby)
> working group on "Context Transfer Considerations for ROHC".
> ROHC is fairly
> new to me, and I would really appreciate any feedback from
> the ROHC wg.
>
> Regards,
> Gary Kenward
>
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
t-rohc-reqs-00.txt <http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt> .

title: Context Transfer Considerations for ROHC
abstract: There is an interest in enhancing the performance of handover between access
routers through the transfer of forwarding context [2]. To clearly understand the requirements
for this transfer, it is useful to examine the requirements of specific feature contexts. This
document reviews the requirements for transferring the context associated with RObust Header
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed.
author: Gary Kenward
date: 07/12/2001
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt


------_=_NextPart_001_01C151E2.91F006D0-- From owner-seamoby@diameter.org Wed Oct 10 20:26:16 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23590 for ; Wed, 10 Oct 2001 20:26:15 -0400 (EDT) Received: (qmail 1746 invoked by alias); 11 Oct 2001 00:10:42 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1740 invoked by uid 200); 11 Oct 2001 00:10:42 -0000 Received: (qmail 1735 invoked from network); 11 Oct 2001 00:10:40 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Oct 2001 00:10:40 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA10312; Wed, 10 Oct 2001 17:24:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9B0Oso20620; Wed, 10 Oct 2001 17:24:54 -0700 X-mProtect: Wed, 10 Oct 2001 17:24:54 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdemzclX; Wed, 10 Oct 2001 17:24:53 PDT Message-ID: <3BC4E6D6.1514646C@iprg.nokia.com> Date: Wed, 10 Oct 2001 17:24:54 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: seamoby@diameter.org Subject: Re: [seamoby] security disabling in CT reqs References: <35DBB8B7AC89D4118E98009027B1009B017AA08C@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > > I have one quick comment for now: > > I understand the thought behind the following section (some > folks don't care about security in their internal networks) > > 5.3.3 The protocol MUST provide for the security provisioning to be > disabled. > > However, reading in the ESP RFC, I found out that you cannot > NULL both authentication and encryption at the same time. > > this means that ESP cannot be proposed for securing CT messages. > Since, I cannot disable both encryption and authentication at > the same time, so I cannot meet 5.3.3. > > Does this mean, ESP is out of question for CT? > Any idea? > No. it just means that if the ESP header is present, both authentication and encryption cannot be sent to NULL at the same time. atleast one should be used. of course the ESP header itself can be absent. basically this is CT without security (req 5.3.3). Vijay From owner-seamoby@diameter.org Thu Oct 11 11:01:55 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17584 for ; Thu, 11 Oct 2001 11:01:08 -0400 (EDT) Received: (qmail 4685 invoked by alias); 11 Oct 2001 14:34:10 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 4679 invoked by uid 200); 11 Oct 2001 14:34:10 -0000 Received: (qmail 4674 invoked from network); 11 Oct 2001 14:34:07 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Oct 2001 14:34:07 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9BEliS01744 for ; Thu, 11 Oct 2001 10:47:44 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 11 Oct 2001 10:48:12 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6R19A>; Thu, 11 Oct 2001 10:47:53 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4598@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@diameter.org Subject: RE: [seamoby] FW: look at CT design team leader's email Date: Thu, 11 Oct 2001 10:47:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15263.B5373A60" X-Orig: Sender: owner-seamoby@diameter.org 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_01C15263.B5373A60 Content-Type: text/plain; charset="iso-8859-1" First of all, the design team was disbanded many months ago, and I am not the leader of anything within Seamoby or the IETF. Second, I did make the classic brain-dead mistake of replying to your friend without checking the address list. I did not expect these comments to be posted on the list, nor, naively, to be forwarded. Even so, the language I used was too strong, even though it does capture what I basically feel about the state of ct. It's been 10 months, and the problem statement hasn't even reached the IESG. The requirements are up for last call, but no new work has commenced. The wg agenda is behind schedule, and items which I believe are necessary for the work to continue (and for which I believe there is at least moderate support - c.f. the IETF 51 minutes) have not been incorporated into the Seamoby charter. Items such as the requirement drafts for specific feature context, a framework draft, and the link layer events draft, have not been given homes. Please do not take any of the above observations as a criticism of Pat Calhoun or Allison Mankin. I believe the problems are partly circumstantial and partly due to our inability to progress in a clear and decisive manner. All of this may perhaps be the consequence of the complexity and ambiguity of the CT problem space. It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT is not dead, but it certainly is comatose. Should it be killed? Well, if it takes 10 months to get the next wg draft out, then euthanasia may be the best option. Since you were so kind to cross-post this email, I am compelled to attach my clarification to the ROHC email list that I posted last night. Finally, please note that the group I work with has not stopped working on context transfer, micro-mobility and seamless mobility in general. As I stated in my response to Lars-Erik, I will revise the ROHC document if the problem statements and requirements drafts pass the IESG. Gary Kenward -----Original Message----- > From: Kenward, Gary [WDLN2:AN10:EXCH] > Sent: October 10, 2001 19:05 > To: ROHC (E-mail) > Subject: FW: [rohc] ROHC context transfer > > > I need to clarify a few points about the email I X-posted accidentally to the ROHC list. > I made the classic brain-dead mistake of not checking all the addresses in the reply-field. > When I wrote this response I believed I was responding to Lars-Erik only. > > I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated > his help given the IETF was over, and he clearly had other appointments to meet. When > I said in the email that "almost all of his comments were a matter of miss-interpreting my text", > in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly > complex protocol. I still believe that this id should only try to summarize ROHC and not > explain it, but clearly I need better words. Carsten helped me craft some of those words, and > they sit on my computer, waiting for the next revision. > > Finally, concerning my frank comments concerning the life signs of context transfer - well, > I might have said it differently on a wg list, but it's been 10 months and there is still no > problem statement RFC. Some of us believed that we would have wg protocol drafts out for > comments by now. Perhaps the idea simply isn't viable. Many of those initially involved > are, I believe, moving on to other areas, or other venues. > > Of course, this is only my opinion, and I'm sure the wg chairs have different views of > where this is all headed. The last call was made on the ct requirements draft, and sometimes > work progresses in marked fits and starts. > > Regards, > Gary Kenward -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: October 10, 2001 19:15 To: seamoby@diameter.org Subject: [seamoby] FW: look at CT design team leader's email Gary, A ROHC fellow forwarded me this email. Would you care to explain why you think CT is dead? (or maybe it should be dead? ) We have been patiently waited for completion of the requirements!! Have a good day, Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Tuesday, October 09, 2001 11:26 AM To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' Subject: RE: [rohc] ROHC context transfer Lars-Erik: A number of attempts were made to engage people more familiar with ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement of knowledgeable people in a number of areas. This is a fatal weakness in my view, as the critical requirements for making CT work is the requirements set by the feature itself, not on abstract protocol requirements. I have made this point many times on the CT list, to no avail. It matters not, perhaps, for as far as I can see, CT is dead. There is next to no activity on this issue in Seamoby, and the problem statement lacks approval, even though it was completed many months ago. We shall see, but I do not intend to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the IESG. I did sit down with Carson Bormann at IETF 51. He expressed similar concerns as you, and we walked through my draft. Frankly, almost all of his comments were a matter of mis-interpreting my text, and the changes requested were mostly to make my draft more explanatory. I will do so, but frankly, this draft is not meant to be a normative reference for ROHC. As for the link layer dependencies: I find it curious that the IETF would develop a protocol that is link layer dependent, don't you? More comments below. Thank you for your input. I will take it into account, if I revise the I-D. Cheers, Gary > -----Original Message----- > From: Lars-Erik Jonsson (EPL) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: October 9, 2001 10:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' > Subject: RE: [rohc] ROHC context transfer > > > Hi Gary and others, > > I know that some people believe in context transfer, e.g. for > header compression, and I can not judge whether this might be > useful or not. Personally, I am skeptical to the whole idea > but I accept that others have a different opinion and I may > be convinced about the usefulness of header compression > context transfer for certain specific environments. However, > I strongly believe that at least for header compression, > context transfer is a link-technology dependent issue, and > would be implemented based on where/how header compression is > implemented in that specific link technology. > > Even if I really do not care about context transfer, I do > care about ROHC and that this work is not justified by, or > carried out based on, incorrect understandings of ROHC. > Previous discussions about this (in ROHC, SEAMOBY and > MOBILEIP) has shown a significant lack of ROHC knowledge from > those proposing context transfer (for ROHC!). Most > surprising, when ROHC authors have pointed out incorrect > statements about ROHC operation, this has even been > questioned by the context transfer proponents. This draft > (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to > previous drafts that have made several incorrect statements > about ROHC. However, this time I will concentrate on the > draft "Context Transfer Considerations for ROHC". With ROHC, > I refer either to the ROHC WG or to RFC-3095. > > See comments below... > > Cheers, > /Lars-Erik > > > >>> Section 3 - Overview ROHC Context > > > ... > > The decompressor monitors the success of decompression of > > the IP packets, and acknowledges successful decompression > > to the compressor. The compressor attempts to compress the > > IP packets as much as possible, as long as the transmitted > > packets are acknowledged. > > LEJ: ROHC may operate in 3 different modes, U-, O-, > or R-mode. Operation always start in U-mode and transition > to O- or R-mode may later be carried out through feedback > from the decompressor. The above text is correct only for > ROHC R-mode operation. A matter of interpretation: in my view, U- and O- modes can be considered "fallback" modes for R-mode. In other words, R-mode is the preferred mode of operation, providing the most compression. U- and O- modes are provided to accomodate the unreliable nature of the channel. Thus, ROHC attempts to compress as well as it can (R-mode), but sometimes cannot (O-, U- modes). > > > ... > > What makes ROHC robust is the intrinsic bias of the state > > machines to return to a basic mode of operation where no > > compression is performed. > > LEJ: Here the conceptually orthogonal terms state and > mode are mixed. The correct wording here should be state > only. However, what makes ROHC robust, compared to earlier > compression schemes, is obviously not the descriptive state > machine concept. I would counter that this is semantics. Defining multiple "modes" in the end results in the same outcome: multiple states in an implementation. I will use the wording preferred by the ROHC wg, but personally, I see it as conotational slight of hand. > > > ... > > Simply because of the robust definition of ROHC, it is > > possible to handover the uncompressed packet stream from > > the SAR to the RAR without the integrity of the IP sessions > > being compromised. ROCH defines an uncompressed, or > > no-compression profile with an identifier value of 0x0000. > > Because of the semantics of the CID encoding, a regular, > > uncompressed IP packet, is interpreted as having a profile > > of 0x0000. > > LEJ: The no-compression profile is not about what this text > indicates. The no-compression profile is used for streams > that can not be compressed with the profiles supported by > a compressor and decompressor pair, to be used over links > where only ROHC packets can be transmitted (not e.g. PPP). > This is thus not the no-context-transfer alternative. The > alternative to context transfer is simply to restart header > compression in IR-state, as a new packet stream for the new > link. I understand the intent of the 0x0000 profile defined by ROHC. However (and I explicitly posted this question to the wg email list), if ROHC is to be robust for handovers, then using 0x0000 as a fallback profile would not only be useful, it is a requirement. There is no way to gaurantee quasi-static context transfers for ROHC, thus a fall back mode is required. My perspective on this is to apply ROHC as a feature for packet communications. It is also possible to treat ROHC as a circuit switched feature (i.e. put it at the link layer), but, IMHO, this does not promote efficient packet switching. > > > ... > > The cons for this approach include: > > > > - the RAR may not be able to re-establish compression for > > traffic destined for the MN. The RAR would have no > > direct method of determining that the stream was to be > > compressed. > > LEJ: It would of course have to use the same method as any > node uses to determine if/how header compression can be > applied to new packet streams. If I understand you, the usual method involves signalling to/from the MN. This is always an option, but not an appealing one, as it does not seem conducive to a "seamless handover". Even if it were, it would consume precious bandwidth over the air. Handovers can be very serendipious, specially in pico cell environments in urban or indoor areas. Even one over the air message can be a significant overhead if there is lots of handovers occuring. One of the goals of Seamoby was to accomplish a handover with (ideally) no over the air signalling. I put it to you: how do you suggest one do this with ROHC? > > > ... > >>> Section 4.2 - Header Compression Profile Transfer > > LEJ: The heading itself indicates that something is not > correct here. A profile is nothing that can be subject to > transfer. A profile defines how a specific kind of packet > streams are compressed, i.e. basically the actual > compression protocol (in ROHC consistent with the framework). > Should it be "Context Transfer"? There are two issues here: a) do the CT source and destination share the same "profiles", if the answer is yes (hopefully), then a "profile transfer" would simply be a transfer of the profile id. If the answer is "no", then yes, it is argueable that there is nothing to transfer. I wanted to leave open the possibility of a "building block" approach to specifying profiles that might allow the receiver to "build" profile support. It's a complication that is, I agree, very difficult to realize, and therefore unlikely. > > > ... > > One issue with this approach is the reliance on the RAR > > having the same header compression profile. The IR packet > > conveys the profile ID and not the profile, and the RAR > > must match the received profile ID with one of the > > profiles in its local repository. > > LEJ: Once again, what is meant with "the profile"?. The > profile ID determines the profile, which is a compression > protocol, not a state. Also here, should it say "context"? To summarize, the context here is at least the profile id. It is likely nothing more. I should note, as I alluded to above, that CT can only be shown to work, IMHO, if we develope specific requirements and make some decisions on what to support and what not to. Unfortunately, the requirements for Seamoby span everything from cellular systems to 802.11, Bluetooth, and ad hoc networks. The latter two being completely unknown, and thus open to wild conjectures, like suppossed handovers between two dissimilar access routers. > > > ... > > Even if the RAR finds a matching ID, it is not clear that > > the profiles will match: e.g. for inter-technology > > handovers, say Bluetooth to 802.11, some of the link > > dependent aspects of the profile may change. > > LEJ: This just highlights the obvious fact that context > transfer for header compression is a link-issue. Two link > technologies might be supporting different profile sets, > or they might even be using different compression schemes > (not necessary ROHC). Further, inter-technology context > transfer would require inter-technology communication, or > higher layers to carry out the context transfer, which would > require higher layers to know about the lower layers. Well, no one can debate supposed link layer differences, certainly not in an IETF document. What you seem to be telling me is either that ROHC is a link layer protocol (which means it doesn't belong in the IETF) or that it relies heavily on link specific solutions, which means that is not an IP level solution (and doesn't belong in the IETF). As a side note: the intent is to define context transfer as a capability enabling protocol that might allow router manufacturers to transfer link layer state or whatever state they see fit. For many technologies, it will not be the appropriate solution. CT is fundamentally limited by being an IP layer soluton. > > > ... > >>> 4.3 - Static Compression Context Transfer > > ... > > The IR packet provides all the static context required > > to initiate the compressor and decompressor state machines. > > The first level of actual header compression for ROHC > > compresses the static and quasi- static fields. > > LEJ: The IR packet normally contains ALL header information, > both static and dynamic. I do not know what is meant with > quasi-static, only that it is not a term used by ROHC. It *at least* contains all the static context information, does it not? Quasi-static is a term I coined to apply to portions of the dynamic compression context. It applies to information that is dynamic, but changes slower then with every packet. It may be correct to simply send over all of the dynamic context, and let ROHC at the destination deal with the inconsistencies. I felt, and still do, that we could be smarter then this: i.e. build in a degree of robustness with ROHC that deals with handovers. However, this was presumptuous. > > > ... > >>> 4.4 - Dynamic Compression Context Transfer > > ... > > Dynamic compression context transfer will succeed for > > reactive context transfer only if the transfer can be > > completed between a packet arrival at the SAR and the > > first or second consecutive packet arrival at the RAR. > > LEJ: This is absolutely not true, ROHC is designed to be > robust against packet loss. It is true that there might be > problems like this with context transfer, if it is not > completed fast enough, but it is not true that ROHC can not > handle losses, as the above text indicates. You are looking at this from the perspective of ROHC. The issue is not whether ROHC can handle it, the issue is whether it is worth performing CT for dynamic state or not. If CT of dynamic context must rely upon ROHC robustness to recover, then it is not worth doing (reliance is, of course, a matter of frequency; clearly, if ROHC robustness is required to recover 90% of the time, then CT of dynamic ROHC context is not worth doing). Indeed, the proposal is to transfer only the static context, and let ROHC robustness do what it was designed to do. The question really is would CT of dynamic compression context really This section will be revised, if the draft is revised, to include dyanmic compression context. I believe I have someone from ROHC willing to contribute text. > > > ... > >>> 5.1 - ROHC Context for Header Profile Transfer > > It is assumed that the RAR and the SAR use identical header > > compression algorithms and header compression profiles. > > LEJ: As mentioned before, a ROHC profile can not possibly > be subject to transfer. In the same way, "header profile" is > not a term that makes sense either. A profile defines the > header compression protocol (algorithm) to be used. See above. There is a lot about ROHC which is in peoples heads, and not clear in the RFC (which would not be unusual for an IETF RFC *smile*). Thanks again for the comments. I certainly will keep them in mind if the draft is revised. I am very much open to comments, and hopefully, to contributed ideas/text. > > > > -----Original Message----- > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > ] > Sent: den 26 juli 2001 17:23 > To: 'ROHC' > Subject: [rohc] ROHC context transfer > > > > Hello. > > I have submitted a draft to the Context and Micro-Mobility > Routing (Seamoby) > working group on "Context Transfer Considerations for ROHC". > ROHC is fairly > new to me, and I would really appreciate any feedback from > the ROHC wg. > > Regards, > Gary Kenward > > http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c t-rohc-reqs-00.txt . title: Context Transfer Considerations for ROHC abstract: There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. author: Gary Kenward date: 07/12/2001 id: draft-kenward-seamoby-ct-rohc-reqs-00.txt ------_=_NextPart_001_01C15263.B5373A60 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] FW: look at CT design team leader's email

First of all, the design team was disbanded many months ago,
and I am not the leader of anything within Seamoby or the IETF.

Second, I did make the classic brain-dead mistake of replying
to your friend without checking the address list. I did not expect
these comments to be posted on the list, nor, naively, to be forwarded.
Even so, the language I used was too strong, even though it does
capture what I basically feel about the state of ct.

It's been 10 months, and the problem statement hasn't even
reached the IESG. The requirements are up for last call, but
no new work has commenced. The wg agenda is behind schedule,
and items which I believe are necessary for the work to continue
(and for which I believe there is at least moderate support - c.f.
the IETF 51 minutes) have not been incorporated into the Seamoby
charter. Items such as the requirement drafts for specific feature
context, a framework draft, and the link layer events draft, have
not been given homes. Please do not take any of the above observations
as a criticism of Pat Calhoun or Allison Mankin. I believe the
problems are partly circumstantial and partly due to our inability
to progress in a clear and decisive manner. All of this may perhaps
be the consequence of the complexity and ambiguity of the CT problem
space.

It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT
is not dead, but it certainly is comatose. Should it be killed?
Well, if it takes 10 months to get the next wg draft out, then
euthanasia may be the best option.

Since you were so kind to cross-post this email, I am compelled to
attach my clarification to the ROHC email list that I posted last
night.

Finally, please note that the group I work with has not stopped working
on context transfer, micro-mobility and seamless mobility in general. As
I stated in my response to Lars-Erik, I will revise the ROHC document if
the problem statements and requirements drafts pass the IESG.

Gary Kenward

-----Original Message-----
> From: Kenward, Gary [WDLN2:AN10:EXCH]
> Sent: October 10, 2001 19:05
> To: ROHC (E-mail)
> Subject: FW: [rohc] ROHC context transfer
>
>
> I need to clarify a few points about the email I X-posted accidentally to the ROHC list.
> I made the classic brain-dead mistake of not checking all the addresses in the reply-field.
> When I wrote this response I believed I was responding to Lars-Erik only.
> 
> I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated
> his help given the IETF was over, and he clearly had other appointments to meet. When
> I said in the email that "almost all of his comments were a matter of miss-interpreting my text",
> in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly
> complex protocol. I still believe that this id should only try to summarize ROHC and not
> explain it, but clearly I need better words. Carsten helped me craft some of those words, and
> they sit on my computer, waiting for the next revision.
>
> Finally, concerning my frank comments concerning the life signs of context transfer - well,
> I might have said it differently on a wg list, but it's been 10 months and there is still no
> problem statement RFC. Some of us believed that we would have wg protocol drafts out for
> comments by now. Perhaps the idea simply isn't viable. Many of those initially involved
> are, I believe, moving on to other areas, or other venues.
> 
> Of course, this is only my opinion, and I'm sure the wg chairs have different views of
> where this is all headed. The last call was made on the ct requirements draft, and sometimes
> work progresses in marked fits and starts.
> 
> Regards,
> Gary Kenward
 

 -----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 10, 2001 19:15
To: seamoby@diameter.org
Subject: [seamoby] FW: look at CT design team leader's email


Gary,
 
A ROHC fellow  forwarded me this email.
Would you care to explain why you think CT is dead?
(or maybe it should be dead? )
 
We have been patiently waited for completion of the requirements!!
 
Have a good day,
Madjid

 -----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, October 09, 2001 11:26 AM
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC'
Subject: RE: [rohc] ROHC context transfer


Lars-Erik:
  A number of attempts were made to engage people more familiar with
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement
of knowledgeable people in a number of areas. This is a fatal weakness in my
view, as the critical requirements for making CT work is the requirements set
by the feature itself, not on abstract protocol requirements. I have made this
point many times on the CT list, to no avail.
  It matters not, perhaps, for as far as I can see, CT is dead. There is next
to no activity on this issue in Seamoby, and the problem statement lacks approval,
even though it was completed many months ago. We shall see, but I do not intend
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the
IESG.
  I did sit down with Carson Bormann at IETF 51. He expressed similar concerns
as you, and we walked through my draft. Frankly, almost all of his comments were
a matter of mis-interpreting my text, and the changes requested were mostly to
make my draft more explanatory. I will do so, but frankly, this draft is not
meant to be a normative reference for ROHC.
  As for the link layer dependencies: I find it curious that the IETF would develop
a protocol that is link layer dependent, don't you?
  More comments below.
 
  Thank you for your input. I will take it into account, if I revise the I-D.
Cheers,
Gary
> -----Original Message-----
> From: Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: October 9, 2001 10:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC'
> Subject: RE: [rohc] ROHC context transfer
>
>
> Hi Gary and others,
> 
> I know that some people believe in context transfer, e.g. for
> header compression, and I can not judge whether this might be
> useful or not. Personally, I am skeptical to the whole idea
> but I accept that others have a different opinion and I may
> be convinced about the usefulness of header compression
> context transfer for certain specific environments. However,
> I strongly believe that at least for header compression,
> context transfer is a link-technology dependent issue, and
> would be implemented based on where/how header compression is
> implemented in that specific link technology.
> 
> Even if I really do not care about context transfer, I do
> care about ROHC and that this work is not justified by, or
> carried out based on, incorrect understandings of ROHC.
> Previous discussions about this (in ROHC, SEAMOBY and
> MOBILEIP) has shown a significant lack of ROHC knowledge from
> those proposing context transfer (for ROHC!). Most
> surprising, when ROHC authors have pointed out incorrect
> statements about ROHC operation, this has even been
> questioned by the context transfer proponents. This draft
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to
> previous drafts that have made several incorrect statements
> about ROHC. However, this time I will concentrate on the
> draft "Context Transfer Considerations for ROHC". With ROHC,
> I refer either to the ROHC WG or to RFC-3095.
> 
> See comments below...
> 
> Cheers,
> /Lars-Erik
> 
> 
> >>> Section 3 - Overview ROHC Context
>
> > ...
> > The decompressor monitors the success of decompression of
> > the IP packets, and acknowledges successful decompression
> > to the compressor. The compressor attempts to compress the
> > IP packets as much as possible, as long as the transmitted
> > packets are acknowledged.
>  
> LEJ: ROHC may operate in 3 different modes, U-, O-,
> or R-mode. Operation always start in U-mode and transition
> to O- or R-mode may later be carried out through feedback
> from the decompressor. The above text is correct only for
> ROHC R-mode operation.
A matter of interpretation: in my view, U- and O- modes can be
considered "fallback" modes for R-mode. In other words, R-mode
is the preferred mode of operation, providing the most compression.
U- and O- modes are provided to accomodate the unreliable nature
of the channel. Thus, ROHC attempts to compress as well as it can
(R-mode), but sometimes cannot (O-, U- modes).
>  
> > ...
> > What makes ROHC robust is the intrinsic bias of the state
> > machines to return to a basic mode of operation where no
> > compression is performed.
>  
> LEJ: Here the conceptually orthogonal terms state and
> mode are mixed. The correct wording here should be state
> only. However, what makes ROHC robust, compared to earlier
> compression schemes, is obviously not the descriptive state
> machine concept.
I would counter that this is semantics. Defining multiple "modes"
in the end results in the same outcome: multiple states in an
implementation. I will use the wording preferred by the ROHC wg,
but personally, I see it as conotational slight of hand.
>
> > ...
> > Simply because of the robust definition of ROHC, it is
> > possible to handover the uncompressed packet stream from
> > the SAR to the RAR without the integrity of the IP sessions
> > being compromised. ROCH defines an uncompressed, or
> > no-compression profile with an identifier value of 0x0000.
> > Because of the semantics of the CID encoding, a regular,
> > uncompressed IP packet, is interpreted as having a profile
> > of 0x0000.
>
> LEJ: The no-compression profile is not about what this text
> indicates. The no-compression profile is used for streams
> that can not be compressed with the profiles supported by
> a compressor and decompressor pair, to be used over links
> where only ROHC packets can be transmitted (not e.g. PPP).
> This is thus not the no-context-transfer alternative. The
> alternative to context transfer is simply to restart header
> compression in IR-state, as a new packet stream for the new
> link.
I understand the intent of the 0x0000 profile defined by ROHC.
However (and I explicitly posted this question to the wg email
list), if ROHC is to be robust for handovers, then using 0x0000
as a fallback profile would not only be useful, it is a requirement.
There is no way to gaurantee quasi-static context transfers for ROHC,
thus a fall back mode is required.
My perspective on this is to apply ROHC as a feature for packet communications.
It is also possible to treat ROHC as a circuit switched feature (i.e. put it
at the link layer), but, IMHO, this does not promote efficient packet switching.
>
> > ...
> > The cons for this approach include:
> >
> > - the RAR may not be able to re-establish compression for
> >   traffic destined for the MN. The RAR would have no
> >   direct method of determining that the stream was to be
> >   compressed.
>
> LEJ: It would of course have to use the same method as any
> node uses to determine if/how header compression can be
> applied to new packet streams.
If I understand you, the usual method involves signalling to/from
the MN. This is always an option, but not an appealing one, as it
does not seem conducive to a "seamless handover". Even if it were,
it would consume precious bandwidth over the air.
Handovers can be very serendipious, specially in pico cell environments
in urban or indoor areas. Even one over the air message can be a
significant overhead if there is lots of handovers occuring.
One of the goals of Seamoby was to accomplish a handover with (ideally)
no over the air signalling. I put it to you: how do you suggest one
do this with ROHC?
>
> > ...
> >>> Section 4.2 - Header Compression Profile Transfer
>
> LEJ: The heading itself indicates that something is not
> correct here. A profile is nothing that can be subject to
> transfer. A profile defines how a specific kind of packet
> streams are compressed, i.e. basically the actual
> compression protocol (in ROHC consistent with the framework).
> Should it be "Context Transfer"?
There are two issues here: a) do the CT source and destination
share the same "profiles", if the answer is yes (hopefully), then
a "profile transfer" would simply be a transfer of the profile id.
If the answer is "no", then yes, it is argueable that there is nothing
to transfer. I wanted to leave open the possibility of a "building block"
approach to specifying profiles that might allow the receiver to
"build" profile support. It's a complication that is, I agree, very
difficult to realize, and therefore unlikely.
>
> > ...
> > One issue with this approach is the reliance on the RAR
> > having the same header compression profile. The IR packet
> > conveys the profile ID and not the profile, and the RAR
> > must match the received profile ID with one of the
> > profiles in its local repository.
>
> LEJ: Once again, what is meant with "the profile"?. The
> profile ID determines the profile, which is a compression
> protocol, not a state. Also here, should it say "context"?
To summarize, the context here is at least the profile id.
It is likely nothing more.
I should note, as I alluded to above, that CT can only be shown
to work, IMHO, if we develope specific requirements and make
some decisions on what to support and what not to. Unfortunately,
the requirements for Seamoby span everything from cellular systems
to 802.11, Bluetooth, and ad hoc networks. The latter two being
completely unknown, and thus open to wild conjectures, like
suppossed handovers between two dissimilar access routers.
>
> > ...
> > Even if the RAR finds a matching ID, it is not clear that
> > the profiles will match: e.g. for inter-technology
> > handovers, say Bluetooth to 802.11, some of the link
> > dependent aspects of the profile may change.
>
> LEJ: This just highlights the obvious fact that context
> transfer for header compression is a link-issue. Two link
> technologies might be supporting different profile sets,
> or they might even be using different compression schemes
> (not necessary ROHC). Further, inter-technology context
> transfer would require inter-technology communication, or
> higher layers to carry out the context transfer, which would
> require higher layers to know about the lower layers.
Well, no one can debate supposed link layer differences, certainly
not in an IETF document. What you seem to be telling me is either that
ROHC is a link layer protocol (which means it doesn't belong in the IETF)
or that it relies heavily on link specific solutions, which means that is
not an IP level solution (and doesn't belong in the IETF).
As a side note: the intent is to define context transfer as a capability
enabling protocol that might allow router manufacturers to transfer link
layer state or whatever state they see fit. For many technologies, it will
not be the appropriate solution. CT is fundamentally limited by being an IP
layer soluton.
>
> > ...
> >>> 4.3 - Static Compression Context Transfer
> > ...
> > The IR packet provides all the static context required
> > to initiate the compressor and decompressor state machines.
> > The first level of actual header compression for ROHC
> > compresses the static and quasi- static fields.
>
> LEJ: The IR packet normally contains ALL header information,
> both static and dynamic. I do not know what is meant with
> quasi-static, only that it is not a term used by ROHC.
It *at least* contains all the static context information,
does it not?
Quasi-static is a term I coined to apply to portions of the
dynamic compression context. It applies to information that
is dynamic, but changes slower then with every packet.
It may be correct to simply send over all of the dynamic context,
and let ROHC at the destination deal with the inconsistencies.
I felt, and still do, that we could be smarter then this:
i.e. build in a degree of robustness with ROHC that deals
with handovers. However, this was presumptuous.
>
> > ...
> >>> 4.4 - Dynamic Compression Context Transfer
> > ...
> > Dynamic compression context transfer will succeed for
> > reactive context transfer only if the transfer can be
> > completed between a packet arrival at the SAR and the
> > first or second consecutive packet arrival at the RAR.
>
> LEJ: This is absolutely not true, ROHC is designed to be
> robust against packet loss. It is true that there might be
> problems like this with context transfer, if it is not
> completed fast enough, but it is not true that ROHC can not
> handle losses, as the above text indicates.
You are looking at this from the perspective of ROHC. The issue
is not whether ROHC can handle it, the issue is whether it is
worth performing CT for dynamic state or not. If CT of dynamic
context must rely upon ROHC robustness to recover, then it is not
worth doing (reliance is, of course, a matter of frequency; clearly,
if ROHC robustness is required to recover 90% of the time, then CT
of dynamic ROHC context is not worth doing).
Indeed, the proposal is to transfer only the static context, and
let ROHC robustness do what it was designed to do. The question
really is would CT of dynamic compression context really
This section will be revised, if the draft is revised, to include
dyanmic compression context. I believe I have someone from ROHC
willing to contribute text.
>
> > ...
> >>> 5.1 - ROHC Context for Header Profile Transfer
> > It is assumed that the RAR and the SAR use identical header
> > compression algorithms and header compression profiles.
>
> LEJ: As mentioned before, a ROHC profile can not possibly
> be subject to transfer. In the same way, "header profile" is
> not a term that makes sense either. A profile defines the
> header compression protocol (algorithm) to be used.
See above. There is a lot about ROHC which is in peoples heads,
and not clear in the RFC (which would not be unusual for an IETF
RFC *smile*).
Thanks again for the comments. I certainly will keep them in mind
if the draft is revised. I am very much open to comments, and hopefully,
to contributed ideas/text.
>
> 
>
> -----Original Message-----
> From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
> <mailto:gkenward@nortelnetworks.com> ]
> Sent: den 26 juli 2001 17:23
> To: 'ROHC'
> Subject: [rohc] ROHC context transfer
>
>
>
> Hello.
>
> I have submitted a draft to the Context and Micro-Mobility
> Routing (Seamoby)
> working group on "Context Transfer Considerations for ROHC".
> ROHC is fairly
> new to me, and I would really appreciate any feedback from
> the ROHC wg.
>
> Regards,
> Gary Kenward
>
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
t-rohc-reqs-00.txt <http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt> .
title: Context Transfer Considerations for ROHC
abstract: There is an interest in enhancing the performance of handover between access
routers through the transfer of forwarding context [2]. To clearly understand the requirements
for this transfer, it is useful to examine the requirements of specific feature contexts. This
document reviews the requirements for transferring the context associated with RObust Header
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed.
author: Gary Kenward
date: 07/12/2001
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt

------_=_NextPart_001_01C15263.B5373A60-- From owner-seamoby@diameter.org Thu Oct 11 11:34:11 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18196 for ; Thu, 11 Oct 2001 11:32:41 -0400 (EDT) Received: (qmail 5193 invoked by alias); 11 Oct 2001 15:01:13 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5187 invoked by uid 200); 11 Oct 2001 15:01:12 -0000 Received: (qmail 5171 invoked from network); 11 Oct 2001 15:00:55 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Oct 2001 15:00:55 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA05148 for ; Thu, 11 Oct 2001 08:15:14 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA25341 for ; Thu, 11 Oct 2001 08:15:12 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KW5BMDL>; Thu, 11 Oct 2001 10:15:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA099@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Gary Kenward'" , Nakhjiri Madjid-MNAKHJI1 , seamoby@diameter.org Subject: [seamoby] CT dead?? Date: Thu, 11 Oct 2001 10:15:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15267.82244A10" Sender: owner-seamoby@diameter.org 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_01C15267.82244A10 Content-Type: text/plain; charset="iso-8859-1" Gary, I did appologize for not changing the subject. I guess we both were victims of the electronic media. As you rightly mentioned in your email to Rohc, the future of CT heavily depends on detail feature (such as Rohc) work and I do feel that such email coming from you as an authority in CT, would block any possibility for others trying to collaborate with groups like Rohc,.... You know that celebrities live a life watched by many others :) Just one thing, the list has been very quiet not for 10 months, but since London and that because people were waiting for the requirements, and maybe so many other things that are going on in the industry now.... Now, if IESG has problems with the documents, I am interested to hear what these problems are. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, October 11, 2001 9:48 AM To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@diameter.org Subject: RE: [seamoby] FW: look at CT design team leader's email First of all, the design team was disbanded many months ago, and I am not the leader of anything within Seamoby or the IETF. Second, I did make the classic brain-dead mistake of replying to your friend without checking the address list. I did not expect these comments to be posted on the list, nor, naively, to be forwarded. Even so, the language I used was too strong, even though it does capture what I basically feel about the state of ct. It's been 10 months, and the problem statement hasn't even reached the IESG. The requirements are up for last call, but no new work has commenced. The wg agenda is behind schedule, and items which I believe are necessary for the work to continue (and for which I believe there is at least moderate support - c.f. the IETF 51 minutes) have not been incorporated into the Seamoby charter. Items such as the requirement drafts for specific feature context, a framework draft, and the link layer events draft, have not been given homes. Please do not take any of the above observations as a criticism of Pat Calhoun or Allison Mankin. I believe the problems are partly circumstantial and partly due to our inability to progress in a clear and decisive manner. All of this may perhaps be the consequence of the complexity and ambiguity of the CT problem space. It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT is not dead, but it certainly is comatose. Should it be killed? Well, if it takes 10 months to get the next wg draft out, then euthanasia may be the best option. Since you were so kind to cross-post this email, I am compelled to attach my clarification to the ROHC email list that I posted last night. Finally, please note that the group I work with has not stopped working on context transfer, micro-mobility and seamless mobility in general. As I stated in my response to Lars-Erik, I will revise the ROHC document if the problem statements and requirements drafts pass the IESG. Gary Kenward -----Original Message----- > From: Kenward, Gary [WDLN2:AN10:EXCH] > Sent: October 10, 2001 19:05 > To: ROHC (E-mail) > Subject: FW: [rohc] ROHC context transfer > > > I need to clarify a few points about the email I X-posted accidentally to the ROHC list. > I made the classic brain-dead mistake of not checking all the addresses in the reply-field. > When I wrote this response I believed I was responding to Lars-Erik only. > > I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated > his help given the IETF was over, and he clearly had other appointments to meet. When > I said in the email that "almost all of his comments were a matter of miss-interpreting my text", > in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly > complex protocol. I still believe that this id should only try to summarize ROHC and not > explain it, but clearly I need better words. Carsten helped me craft some of those words, and > they sit on my computer, waiting for the next revision. > > Finally, concerning my frank comments concerning the life signs of context transfer - well, > I might have said it differently on a wg list, but it's been 10 months and there is still no > problem statement RFC. Some of us believed that we would have wg protocol drafts out for > comments by now. Perhaps the idea simply isn't viable. Many of those initially involved > are, I believe, moving on to other areas, or other venues. > > Of course, this is only my opinion, and I'm sure the wg chairs have different views of > where this is all headed. The last call was made on the ct requirements draft, and sometimes > work progresses in marked fits and starts. > > Regards, > Gary Kenward -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: October 10, 2001 19:15 To: seamoby@diameter.org Subject: [seamoby] FW: look at CT design team leader's email Gary, A ROHC fellow forwarded me this email. Would you care to explain why you think CT is dead? (or maybe it should be dead? ) We have been patiently waited for completion of the requirements!! Have a good day, Madjid -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Tuesday, October 09, 2001 11:26 AM To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' Subject: RE: [rohc] ROHC context transfer Lars-Erik: A number of attempts were made to engage people more familiar with ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement of knowledgeable people in a number of areas. This is a fatal weakness in my view, as the critical requirements for making CT work is the requirements set by the feature itself, not on abstract protocol requirements. I have made this point many times on the CT list, to no avail. It matters not, perhaps, for as far as I can see, CT is dead. There is next to no activity on this issue in Seamoby, and the problem statement lacks approval, even though it was completed many months ago. We shall see, but I do not intend to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the IESG. I did sit down with Carson Bormann at IETF 51. He expressed similar concerns as you, and we walked through my draft. Frankly, almost all of his comments were a matter of mis-interpreting my text, and the changes requested were mostly to make my draft more explanatory. I will do so, but frankly, this draft is not meant to be a normative reference for ROHC. As for the link layer dependencies: I find it curious that the IETF would develop a protocol that is link layer dependent, don't you? More comments below. Thank you for your input. I will take it into account, if I revise the I-D. Cheers, Gary > -----Original Message----- > From: Lars-Erik Jonsson (EPL) > [ mailto:Lars-Erik.Jonsson@epl.ericsson.se ] > Sent: October 9, 2001 10:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' > Subject: RE: [rohc] ROHC context transfer > > > Hi Gary and others, > > I know that some people believe in context transfer, e.g. for > header compression, and I can not judge whether this might be > useful or not. Personally, I am skeptical to the whole idea > but I accept that others have a different opinion and I may > be convinced about the usefulness of header compression > context transfer for certain specific environments. However, > I strongly believe that at least for header compression, > context transfer is a link-technology dependent issue, and > would be implemented based on where/how header compression is > implemented in that specific link technology. > > Even if I really do not care about context transfer, I do > care about ROHC and that this work is not justified by, or > carried out based on, incorrect understandings of ROHC. > Previous discussions about this (in ROHC, SEAMOBY and > MOBILEIP) has shown a significant lack of ROHC knowledge from > those proposing context transfer (for ROHC!). Most > surprising, when ROHC authors have pointed out incorrect > statements about ROHC operation, this has even been > questioned by the context transfer proponents. This draft > (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to > previous drafts that have made several incorrect statements > about ROHC. However, this time I will concentrate on the > draft "Context Transfer Considerations for ROHC". With ROHC, > I refer either to the ROHC WG or to RFC-3095. > > See comments below... > > Cheers, > /Lars-Erik > > > >>> Section 3 - Overview ROHC Context > > > ... > > The decompressor monitors the success of decompression of > > the IP packets, and acknowledges successful decompression > > to the compressor. The compressor attempts to compress the > > IP packets as much as possible, as long as the transmitted > > packets are acknowledged. > > LEJ: ROHC may operate in 3 different modes, U-, O-, > or R-mode. Operation always start in U-mode and transition > to O- or R-mode may later be carried out through feedback > from the decompressor. The above text is correct only for > ROHC R-mode operation. A matter of interpretation: in my view, U- and O- modes can be considered "fallback" modes for R-mode. In other words, R-mode is the preferred mode of operation, providing the most compression. U- and O- modes are provided to accomodate the unreliable nature of the channel. Thus, ROHC attempts to compress as well as it can (R-mode), but sometimes cannot (O-, U- modes). > > > ... > > What makes ROHC robust is the intrinsic bias of the state > > machines to return to a basic mode of operation where no > > compression is performed. > > LEJ: Here the conceptually orthogonal terms state and > mode are mixed. The correct wording here should be state > only. However, what makes ROHC robust, compared to earlier > compression schemes, is obviously not the descriptive state > machine concept. I would counter that this is semantics. Defining multiple "modes" in the end results in the same outcome: multiple states in an implementation. I will use the wording preferred by the ROHC wg, but personally, I see it as conotational slight of hand. > > > ... > > Simply because of the robust definition of ROHC, it is > > possible to handover the uncompressed packet stream from > > the SAR to the RAR without the integrity of the IP sessions > > being compromised. ROCH defines an uncompressed, or > > no-compression profile with an identifier value of 0x0000. > > Because of the semantics of the CID encoding, a regular, > > uncompressed IP packet, is interpreted as having a profile > > of 0x0000. > > LEJ: The no-compression profile is not about what this text > indicates. The no-compression profile is used for streams > that can not be compressed with the profiles supported by > a compressor and decompressor pair, to be used over links > where only ROHC packets can be transmitted (not e.g. PPP). > This is thus not the no-context-transfer alternative. The > alternative to context transfer is simply to restart header > compression in IR-state, as a new packet stream for the new > link. I understand the intent of the 0x0000 profile defined by ROHC. However (and I explicitly posted this question to the wg email list), if ROHC is to be robust for handovers, then using 0x0000 as a fallback profile would not only be useful, it is a requirement. There is no way to gaurantee quasi-static context transfers for ROHC, thus a fall back mode is required. My perspective on this is to apply ROHC as a feature for packet communications. It is also possible to treat ROHC as a circuit switched feature (i.e. put it at the link layer), but, IMHO, this does not promote efficient packet switching. > > > ... > > The cons for this approach include: > > > > - the RAR may not be able to re-establish compression for > > traffic destined for the MN. The RAR would have no > > direct method of determining that the stream was to be > > compressed. > > LEJ: It would of course have to use the same method as any > node uses to determine if/how header compression can be > applied to new packet streams. If I understand you, the usual method involves signalling to/from the MN. This is always an option, but not an appealing one, as it does not seem conducive to a "seamless handover". Even if it were, it would consume precious bandwidth over the air. Handovers can be very serendipious, specially in pico cell environments in urban or indoor areas. Even one over the air message can be a significant overhead if there is lots of handovers occuring. One of the goals of Seamoby was to accomplish a handover with (ideally) no over the air signalling. I put it to you: how do you suggest one do this with ROHC? > > > ... > >>> Section 4.2 - Header Compression Profile Transfer > > LEJ: The heading itself indicates that something is not > correct here. A profile is nothing that can be subject to > transfer. A profile defines how a specific kind of packet > streams are compressed, i.e. basically the actual > compression protocol (in ROHC consistent with the framework). > Should it be "Context Transfer"? There are two issues here: a) do the CT source and destination share the same "profiles", if the answer is yes (hopefully), then a "profile transfer" would simply be a transfer of the profile id. If the answer is "no", then yes, it is argueable that there is nothing to transfer. I wanted to leave open the possibility of a "building block" approach to specifying profiles that might allow the receiver to "build" profile support. It's a complication that is, I agree, very difficult to realize, and therefore unlikely. > > > ... > > One issue with this approach is the reliance on the RAR > > having the same header compression profile. The IR packet > > conveys the profile ID and not the profile, and the RAR > > must match the received profile ID with one of the > > profiles in its local repository. > > LEJ: Once again, what is meant with "the profile"?. The > profile ID determines the profile, which is a compression > protocol, not a state. Also here, should it say "context"? To summarize, the context here is at least the profile id. It is likely nothing more. I should note, as I alluded to above, that CT can only be shown to work, IMHO, if we develope specific requirements and make some decisions on what to support and what not to. Unfortunately, the requirements for Seamoby span everything from cellular systems to 802.11, Bluetooth, and ad hoc networks. The latter two being completely unknown, and thus open to wild conjectures, like suppossed handovers between two dissimilar access routers. > > > ... > > Even if the RAR finds a matching ID, it is not clear that > > the profiles will match: e.g. for inter-technology > > handovers, say Bluetooth to 802.11, some of the link > > dependent aspects of the profile may change. > > LEJ: This just highlights the obvious fact that context > transfer for header compression is a link-issue. Two link > technologies might be supporting different profile sets, > or they might even be using different compression schemes > (not necessary ROHC). Further, inter-technology context > transfer would require inter-technology communication, or > higher layers to carry out the context transfer, which would > require higher layers to know about the lower layers. Well, no one can debate supposed link layer differences, certainly not in an IETF document. What you seem to be telling me is either that ROHC is a link layer protocol (which means it doesn't belong in the IETF) or that it relies heavily on link specific solutions, which means that is not an IP level solution (and doesn't belong in the IETF). As a side note: the intent is to define context transfer as a capability enabling protocol that might allow router manufacturers to transfer link layer state or whatever state they see fit. For many technologies, it will not be the appropriate solution. CT is fundamentally limited by being an IP layer soluton. > > > ... > >>> 4.3 - Static Compression Context Transfer > > ... > > The IR packet provides all the static context required > > to initiate the compressor and decompressor state machines. > > The first level of actual header compression for ROHC > > compresses the static and quasi- static fields. > > LEJ: The IR packet normally contains ALL header information, > both static and dynamic. I do not know what is meant with > quasi-static, only that it is not a term used by ROHC. It *at least* contains all the static context information, does it not? Quasi-static is a term I coined to apply to portions of the dynamic compression context. It applies to information that is dynamic, but changes slower then with every packet. It may be correct to simply send over all of the dynamic context, and let ROHC at the destination deal with the inconsistencies. I felt, and still do, that we could be smarter then this: i.e. build in a degree of robustness with ROHC that deals with handovers. However, this was presumptuous. > > > ... > >>> 4.4 - Dynamic Compression Context Transfer > > ... > > Dynamic compression context transfer will succeed for > > reactive context transfer only if the transfer can be > > completed between a packet arrival at the SAR and the > > first or second consecutive packet arrival at the RAR. > > LEJ: This is absolutely not true, ROHC is designed to be > robust against packet loss. It is true that there might be > problems like this with context transfer, if it is not > completed fast enough, but it is not true that ROHC can not > handle losses, as the above text indicates. You are looking at this from the perspective of ROHC. The issue is not whether ROHC can handle it, the issue is whether it is worth performing CT for dynamic state or not. If CT of dynamic context must rely upon ROHC robustness to recover, then it is not worth doing (reliance is, of course, a matter of frequency; clearly, if ROHC robustness is required to recover 90% of the time, then CT of dynamic ROHC context is not worth doing). Indeed, the proposal is to transfer only the static context, and let ROHC robustness do what it was designed to do. The question really is would CT of dynamic compression context really This section will be revised, if the draft is revised, to include dyanmic compression context. I believe I have someone from ROHC willing to contribute text. > > > ... > >>> 5.1 - ROHC Context for Header Profile Transfer > > It is assumed that the RAR and the SAR use identical header > > compression algorithms and header compression profiles. > > LEJ: As mentioned before, a ROHC profile can not possibly > be subject to transfer. In the same way, "header profile" is > not a term that makes sense either. A profile defines the > header compression protocol (algorithm) to be used. See above. There is a lot about ROHC which is in peoples heads, and not clear in the RFC (which would not be unusual for an IETF RFC *smile*). Thanks again for the comments. I certainly will keep them in mind if the draft is revised. I am very much open to comments, and hopefully, to contributed ideas/text. > > > > -----Original Message----- > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > < mailto:gkenward@nortelnetworks.com > ] > Sent: den 26 juli 2001 17:23 > To: 'ROHC' > Subject: [rohc] ROHC context transfer > > > > Hello. > > I have submitted a draft to the Context and Micro-Mobility > Routing (Seamoby) > working group on "Context Transfer Considerations for ROHC". > ROHC is fairly > new to me, and I would really appreciate any feedback from > the ROHC wg. > > Regards, > Gary Kenward > > http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c t-rohc-reqs-00.txt < http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00 .txt > . title: Context Transfer Considerations for ROHC abstract: There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. author: Gary Kenward date: 07/12/2001 id: draft-kenward-seamoby-ct-rohc-reqs-00.txt ------_=_NextPart_001_01C15267.82244A10 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] FW: look at CT design team leader's email
Gary,
 
I did appologize for not changing the subject.
I guess we both were victims of the electronic media.
 
As you rightly mentioned in your email to Rohc, the future of
CT heavily depends on detail feature (such as Rohc) work and 
 I do feel that such email coming from you as an
authority in CT, would block any possibility for others
trying to collaborate with groups like Rohc,....
You know that celebrities live a life watched by many others :)
 
Just one thing, the list has been very quiet not for 10 months, but since London and
that because people were waiting for the requirements, and maybe so many other
 things that are going on in the industry now....
 
Now, if IESG has problems with the documents, I am interested to
hear what these problems are.
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, October 11, 2001 9:48 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@diameter.org
Subject: RE: [seamoby] FW: look at CT design team leader's email

First of all, the design team was disbanded many months ago,
and I am not the leader of anything within Seamoby or the IETF.

Second, I did make the classic brain-dead mistake of replying
to your friend without checking the address list. I did not expect
these comments to be posted on the list, nor, naively, to be forwarded.
Even so, the language I used was too strong, even though it does
capture what I basically feel about the state of ct.

It's been 10 months, and the problem statement hasn't even
reached the IESG. The requirements are up for last call, but
no new work has commenced. The wg agenda is behind schedule,
and items which I believe are necessary for the work to continue
(and for which I believe there is at least moderate support - c.f.
the IETF 51 minutes) have not been incorporated into the Seamoby
charter. Items such as the requirement drafts for specific feature
context, a framework draft, and the link layer events draft, have
not been given homes. Please do not take any of the above observations
as a criticism of Pat Calhoun or Allison Mankin. I believe the
problems are partly circumstantial and partly due to our inability
to progress in a clear and decisive manner. All of this may perhaps
be the consequence of the complexity and ambiguity of the CT problem
space.

It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT
is not dead, but it certainly is comatose. Should it be killed?
Well, if it takes 10 months to get the next wg draft out, then
euthanasia may be the best option.

Since you were so kind to cross-post this email, I am compelled to
attach my clarification to the ROHC email list that I posted last
night.

Finally, please note that the group I work with has not stopped working
on context transfer, micro-mobility and seamless mobility in general. As
I stated in my response to Lars-Erik, I will revise the ROHC document if
the problem statements and requirements drafts pass the IESG.

Gary Kenward

-----Original Message-----
> From: Kenward, Gary [WDLN2:AN10:EXCH]
> Sent: October 10, 2001 19:05
> To: ROHC (E-mail)
> Subject: FW: [rohc] ROHC context transfer
>
>
> I need to clarify a few points about the email I X-posted accidentally to the ROHC list.
> I made the classic brain-dead mistake of not checking all the addresses in the reply-field.
> When I wrote this response I believed I was responding to Lars-Erik only.
> 
> I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated
> his help given the IETF was over, and he clearly had other appointments to meet. When
> I said in the email that "almost all of his comments were a matter of miss-interpreting my text",
> in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly
> complex protocol. I still believe that this id should only try to summarize ROHC and not
> explain it, but clearly I need better words. Carsten helped me craft some of those words, and
> they sit on my computer, waiting for the next revision.
>
> Finally, concerning my frank comments concerning the life signs of context transfer - well,
> I might have said it differently on a wg list, but it's been 10 months and there is still no
> problem statement RFC. Some of us believed that we would have wg protocol drafts out for
> comments by now. Perhaps the idea simply isn't viable. Many of those initially involved
> are, I believe, moving on to other areas, or other venues.
> 
> Of course, this is only my opinion, and I'm sure the wg chairs have different views of
> where this is all headed. The last call was made on the ct requirements draft, and sometimes
> work progresses in marked fits and starts.
> 
> Regards,
> Gary Kenward
 

 -----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 10, 2001 19:15
To: seamoby@diameter.org
Subject: [seamoby] FW: look at CT design team leader's email


Gary,
 
A ROHC fellow  forwarded me this email.
Would you care to explain why you think CT is dead?
(or maybe it should be dead? )
 
We have been patiently waited for completion of the requirements!!
 
Have a good day,
Madjid

 -----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, October 09, 2001 11:26 AM
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC'
Subject: RE: [rohc] ROHC context transfer


Lars-Erik:
  A number of attempts were made to engage people more familiar with
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement
of knowledgeable people in a number of areas. This is a fatal weakness in my
view, as the critical requirements for making CT work is the requirements set
by the feature itself, not on abstract protocol requirements. I have made this
point many times on the CT list, to no avail.
  It matters not, perhaps, for as far as I can see, CT is dead. There is next
to no activity on this issue in Seamoby, and the problem statement lacks approval,
even though it was completed many months ago. We shall see, but I do not intend
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the
IESG.
  I did sit down with Carson Bormann at IETF 51. He expressed similar concerns
as you, and we walked through my draft. Frankly, almost all of his comments were
a matter of mis-interpreting my text, and the changes requested were mostly to
make my draft more explanatory. I will do so, but frankly, this draft is not
meant to be a normative reference for ROHC.
  As for the link layer dependencies: I find it curious that the IETF would develop
a protocol that is link layer dependent, don't you?
  More comments below.
 
  Thank you for your input. I will take it into account, if I revise the I-D.
Cheers,
Gary
> -----Original Message-----
> From: Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: October 9, 2001 10:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC'
> Subject: RE: [rohc] ROHC context transfer
>
>
> Hi Gary and others,
> 
> I know that some people believe in context transfer, e.g. for
> header compression, and I can not judge whether this might be
> useful or not. Personally, I am skeptical to the whole idea
> but I accept that others have a different opinion and I may
> be convinced about the usefulness of header compression
> context transfer for certain specific environments. However,
> I strongly believe that at least for header compression,
> context transfer is a link-technology dependent issue, and
> would be implemented based on where/how header compression is
> implemented in that specific link technology.
> 
> Even if I really do not care about context transfer, I do
> care about ROHC and that this work is not justified by, or
> carried out based on, incorrect understandings of ROHC.
> Previous discussions about this (in ROHC, SEAMOBY and
> MOBILEIP) has shown a significant lack of ROHC knowledge from
> those proposing context transfer (for ROHC!). Most
> surprising, when ROHC authors have pointed out incorrect
> statements about ROHC operation, this has even been
> questioned by the context transfer proponents. This draft
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to
> previous drafts that have made several incorrect statements
> about ROHC. However, this time I will concentrate on the
> draft "Context Transfer Considerations for ROHC". With ROHC,
> I refer either to the ROHC WG or to RFC-3095.
> 
> See comments below...
> 
> Cheers,
> /Lars-Erik
> 
> 
> >>> Section 3 - Overview ROHC Context
>
> > ...
> > The decompressor monitors the success of decompression of
> > the IP packets, and acknowledges successful decompression
> > to the compressor. The compressor attempts to compress the
> > IP packets as much as possible, as long as the transmitted
> > packets are acknowledged.
>  
> LEJ: ROHC may operate in 3 different modes, U-, O-,
> or R-mode. Operation always start in U-mode and transition
> to O- or R-mode may later be carried out through feedback
> from the decompressor. The above text is correct only for
> ROHC R-mode operation.
A matter of interpretation: in my view, U- and O- modes can be
considered "fallback" modes for R-mode. In other words, R-mode
is the preferred mode of operation, providing the most compression.
U- and O- modes are provided to accomodate the unreliable nature
of the channel. Thus, ROHC attempts to compress as well as it can
(R-mode), but sometimes cannot (O-, U- modes).
>  
> > ...
> > What makes ROHC robust is the intrinsic bias of the state
> > machines to return to a basic mode of operation where no
> > compression is performed.
>  
> LEJ: Here the conceptually orthogonal terms state and
> mode are mixed. The correct wording here should be state
> only. However, what makes ROHC robust, compared to earlier
> compression schemes, is obviously not the descriptive state
> machine concept.
I would counter that this is semantics. Defining multiple "modes"
in the end results in the same outcome: multiple states in an
implementation. I will use the wording preferred by the ROHC wg,
but personally, I see it as conotational slight of hand.
>
> > ...
> > Simply because of the robust definition of ROHC, it is
> > possible to handover the uncompressed packet stream from
> > the SAR to the RAR without the integrity of the IP sessions
> > being compromised. ROCH defines an uncompressed, or
> > no-compression profile with an identifier value of 0x0000.
> > Because of the semantics of the CID encoding, a regular,
> > uncompressed IP packet, is interpreted as having a profile
> > of 0x0000.
>
> LEJ: The no-compression profile is not about what this text
> indicates. The no-compression profile is used for streams
> that can not be compressed with the profiles supported by
> a compressor and decompressor pair, to be used over links
> where only ROHC packets can be transmitted (not e.g. PPP).
> This is thus not the no-context-transfer alternative. The
> alternative to context transfer is simply to restart header
> compression in IR-state, as a new packet stream for the new
> link.
I understand the intent of the 0x0000 profile defined by ROHC.
However (and I explicitly posted this question to the wg email
list), if ROHC is to be robust for handovers, then using 0x0000
as a fallback profile would not only be useful, it is a requirement.
There is no way to gaurantee quasi-static context transfers for ROHC,
thus a fall back mode is required.
My perspective on this is to apply ROHC as a feature for packet communications.
It is also possible to treat ROHC as a circuit switched feature (i.e. put it
at the link layer), but, IMHO, this does not promote efficient packet switching.
>
> > ...
> > The cons for this approach include:
> >
> > - the RAR may not be able to re-establish compression for
> >   traffic destined for the MN. The RAR would have no
> >   direct method of determining that the stream was to be
> >   compressed.
>
> LEJ: It would of course have to use the same method as any
> node uses to determine if/how header compression can be
> applied to new packet streams.
If I understand you, the usual method involves signalling to/from
the MN. This is always an option, but not an appealing one, as it
does not seem conducive to a "seamless handover". Even if it were,
it would consume precious bandwidth over the air.
Handovers can be very serendipious, specially in pico cell environments
in urban or indoor areas. Even one over the air message can be a
significant overhead if there is lots of handovers occuring.
One of the goals of Seamoby was to accomplish a handover with (ideally)
no over the air signalling. I put it to you: how do you suggest one
do this with ROHC?
>
> > ...
> >>> Section 4.2 - Header Compression Profile Transfer
>
> LEJ: The heading itself indicates that something is not
> correct here. A profile is nothing that can be subject to
> transfer. A profile defines how a specific kind of packet
> streams are compressed, i.e. basically the actual
> compression protocol (in ROHC consistent with the framework).
> Should it be "Context Transfer"?
There are two issues here: a) do the CT source and destination
share the same "profiles", if the answer is yes (hopefully), then
a "profile transfer" would simply be a transfer of the profile id.
If the answer is "no", then yes, it is argueable that there is nothing
to transfer. I wanted to leave open the possibility of a "building block"
approach to specifying profiles that might allow the receiver to
"build" profile support. It's a complication that is, I agree, very
difficult to realize, and therefore unlikely.
>
> > ...
> > One issue with this approach is the reliance on the RAR
> > having the same header compression profile. The IR packet
> > conveys the profile ID and not the profile, and the RAR
> > must match the received profile ID with one of the
> > profiles in its local repository.
>
> LEJ: Once again, what is meant with "the profile"?. The
> profile ID determines the profile, which is a compression
> protocol, not a state. Also here, should it say "context"?
To summarize, the context here is at least the profile id.
It is likely nothing more.
I should note, as I alluded to above, that CT can only be shown
to work, IMHO, if we develope specific requirements and make
some decisions on what to support and what not to. Unfortunately,
the requirements for Seamoby span everything from cellular systems
to 802.11, Bluetooth, and ad hoc networks. The latter two being
completely unknown, and thus open to wild conjectures, like
suppossed handovers between two dissimilar access routers.
>
> > ...
> > Even if the RAR finds a matching ID, it is not clear that
> > the profiles will match: e.g. for inter-technology
> > handovers, say Bluetooth to 802.11, some of the link
> > dependent aspects of the profile may change.
>
> LEJ: This just highlights the obvious fact that context
> transfer for header compression is a link-issue. Two link
> technologies might be supporting different profile sets,
> or they might even be using different compression schemes
> (not necessary ROHC). Further, inter-technology context
> transfer would require inter-technology communication, or
> higher layers to carry out the context transfer, which would
> require higher layers to know about the lower layers.
Well, no one can debate supposed link layer differences, certainly
not in an IETF document. What you seem to be telling me is either that
ROHC is a link layer protocol (which means it doesn't belong in the IETF)
or that it relies heavily on link specific solutions, which means that is
not an IP level solution (and doesn't belong in the IETF).
As a side note: the intent is to define context transfer as a capability
enabling protocol that might allow router manufacturers to transfer link
layer state or whatever state they see fit. For many technologies, it will
not be the appropriate solution. CT is fundamentally limited by being an IP
layer soluton.
>
> > ...
> >>> 4.3 - Static Compression Context Transfer
> > ...
> > The IR packet provides all the static context required
> > to initiate the compressor and decompressor state machines.
> > The first level of actual header compression for ROHC
> > compresses the static and quasi- static fields.
>
> LEJ: The IR packet normally contains ALL header information,
> both static and dynamic. I do not know what is meant with
> quasi-static, only that it is not a term used by ROHC.
It *at least* contains all the static context information,
does it not?
Quasi-static is a term I coined to apply to portions of the
dynamic compression context. It applies to information that
is dynamic, but changes slower then with every packet.
It may be correct to simply send over all of the dynamic context,
and let ROHC at the destination deal with the inconsistencies.
I felt, and still do, that we could be smarter then this:
i.e. build in a degree of robustness with ROHC that deals
with handovers. However, this was presumptuous.
>
> > ...
> >>> 4.4 - Dynamic Compression Context Transfer
> > ...
> > Dynamic compression context transfer will succeed for
> > reactive context transfer only if the transfer can be
> > completed between a packet arrival at the SAR and the
> > first or second consecutive packet arrival at the RAR.
>
> LEJ: This is absolutely not true, ROHC is designed to be
> robust against packet loss. It is true that there might be
> problems like this with context transfer, if it is not
> completed fast enough, but it is not true that ROHC can not
> handle losses, as the above text indicates.
You are looking at this from the perspective of ROHC. The issue
is not whether ROHC can handle it, the issue is whether it is
worth performing CT for dynamic state or not. If CT of dynamic
context must rely upon ROHC robustness to recover, then it is not
worth doing (reliance is, of course, a matter of frequency; clearly,
if ROHC robustness is required to recover 90% of the time, then CT
of dynamic ROHC context is not worth doing).
Indeed, the proposal is to transfer only the static context, and
let ROHC robustness do what it was designed to do. The question
really is would CT of dynamic compression context really
This section will be revised, if the draft is revised, to include
dyanmic compression context. I believe I have someone from ROHC
willing to contribute text.
>
> > ...
> >>> 5.1 - ROHC Context for Header Profile Transfer
> > It is assumed that the RAR and the SAR use identical header
> > compression algorithms and header compression profiles.
>
> LEJ: As mentioned before, a ROHC profile can not possibly
> be subject to transfer. In the same way, "header profile" is
> not a term that makes sense either. A profile defines the
> header compression protocol (algorithm) to be used.
See above. There is a lot about ROHC which is in peoples heads,
and not clear in the RFC (which would not be unusual for an IETF
RFC *smile*).
Thanks again for the comments. I certainly will keep them in mind
if the draft is revised. I am very much open to comments, and hopefully,
to contributed ideas/text.
>
> 
>
> -----Original Message-----
> From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
> <mailto:gkenward@nortelnetworks.com> ]
> Sent: den 26 juli 2001 17:23
> To: 'ROHC'
> Subject: [rohc] ROHC context transfer
>
>
>
> Hello.
>
> I have submitted a draft to the Context and Micro-Mobility
> Routing (Seamoby)
> working group on "Context Transfer Considerations for ROHC".
> ROHC is fairly
> new to me, and I would really appreciate any feedback from
> the ROHC wg.
>
> Regards,
> Gary Kenward
>
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
t-rohc-reqs-00.txt <http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt> .
title: Context Transfer Considerations for ROHC
abstract: There is an interest in enhancing the performance of handover between access
routers through the transfer of forwarding context [2]. To clearly understand the requirements
for this transfer, it is useful to examine the requirements of specific feature contexts. This
document reviews the requirements for transferring the context associated with RObust Header
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed.
author: Gary Kenward
date: 07/12/2001
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt

------_=_NextPart_001_01C15267.82244A10-- From owner-seamoby@diameter.org Thu Oct 11 12:11:12 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18753 for ; Thu, 11 Oct 2001 12:09:46 -0400 (EDT) Received: (qmail 5835 invoked by alias); 11 Oct 2001 15:37:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5829 invoked by uid 200); 11 Oct 2001 15:37:51 -0000 Received: (qmail 5817 invoked from network); 11 Oct 2001 15:37:34 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Oct 2001 15:37:34 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9BFp6S00148 for ; Thu, 11 Oct 2001 11:51:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 11 Oct 2001 11:51:30 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6RGZT>; Thu, 11 Oct 2001 11:51:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA459C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , seamoby@diameter.org Subject: [seamoby] RE: CT dead?? Date: Thu, 11 Oct 2001 11:51:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1526C.8D4EC5A0" X-Orig: Sender: owner-seamoby@diameter.org 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_01C1526C.8D4EC5A0 Content-Type: text/plain; charset="iso-8859-1" Madjid: I think that you and always have always been working towards a similar if slightly different goal (differences are good). It frightens me that anyone would consider me an authority and in any way representing the opinions of Seamoby, if for no other reason then I have no idea what is going on. If I am an impediment to CT progressing, then I will fall on my own sword, and then hopefully the work can move forward. 'nuff said. Indeed, more then enough said. Where is my claymore.... Gary -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: October 11, 2001 11:15 To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; seamoby@diameter.org Subject: CT dead?? Gary, I did appologize for not changing the subject. I guess we both were victims of the electronic media. As you rightly mentioned in your email to Rohc, the future of CT heavily depends on detail feature (such as Rohc) work and I do feel that such email coming from you as an authority in CT, would block any possibility for others trying to collaborate with groups like Rohc,.... You know that celebrities live a life watched by many others :) Just one thing, the list has been very quiet not for 10 months, but since London and that because people were waiting for the requirements, and maybe so many other things that are going on in the industry now.... Now, if IESG has problems with the documents, I am interested to hear what these problems are. Madjid -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, October 11, 2001 9:48 AM To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@diameter.org Subject: RE: [seamoby] FW: look at CT design team leader's email First of all, the design team was disbanded many months ago, and I am not the leader of anything within Seamoby or the IETF. Second, I did make the classic brain-dead mistake of replying to your friend without checking the address list. I did not expect these comments to be posted on the list, nor, naively, to be forwarded. Even so, the language I used was too strong, even though it does capture what I basically feel about the state of ct. It's been 10 months, and the problem statement hasn't even reached the IESG. The requirements are up for last call, but no new work has commenced. The wg agenda is behind schedule, and items which I believe are necessary for the work to continue (and for which I believe there is at least moderate support - c.f. the IETF 51 minutes) have not been incorporated into the Seamoby charter. Items such as the requirement drafts for specific feature context, a framework draft, and the link layer events draft, have not been given homes. Please do not take any of the above observations as a criticism of Pat Calhoun or Allison Mankin. I believe the problems are partly circumstantial and partly due to our inability to progress in a clear and decisive manner. All of this may perhaps be the consequence of the complexity and ambiguity of the CT problem space. It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT is not dead, but it certainly is comatose. Should it be killed? Well, if it takes 10 months to get the next wg draft out, then euthanasia may be the best option. Since you were so kind to cross-post this email, I am compelled to attach my clarification to the ROHC email list that I posted last night. Finally, please note that the group I work with has not stopped working on context transfer, micro-mobility and seamless mobility in general. As I stated in my response to Lars-Erik, I will revise the ROHC document if the problem statements and requirements drafts pass the IESG. Gary Kenward -----Original Message----- > From: Kenward, Gary [WDLN2:AN10:EXCH] > Sent: October 10, 2001 19:05 > To: ROHC (E-mail) > Subject: FW: [rohc] ROHC context transfer > > > I need to clarify a few points about the email I X-posted accidentally to the ROHC list. > I made the classic brain-dead mistake of not checking all the addresses in the reply-field. > When I wrote this response I believed I was responding to Lars-Erik only. > > I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated > his help given the IETF was over, and he clearly had other appointments to meet. When > I said in the email that "almost all of his comments were a matter of miss-interpreting my text", > in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly > complex protocol. I still believe that this id should only try to summarize ROHC and not > explain it, but clearly I need better words. Carsten helped me craft some of those words, and > they sit on my computer, waiting for the next revision. > > Finally, concerning my frank comments concerning the life signs of context transfer - well, > I might have said it differently on a wg list, but it's been 10 months and there is still no > problem statement RFC. Some of us believed that we would have wg protocol drafts out for > comments by now. Perhaps the idea simply isn't viable. Many of those initially involved > are, I believe, moving on to other areas, or other venues. > > Of course, this is only my opinion, and I'm sure the wg chairs have different views of > where this is all headed. The last call was made on the ct requirements draft, and sometimes > work progresses in marked fits and starts. > > Regards, > Gary Kenward -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [ mailto:Madjid.Nakhjiri@motorola.com ] Sent: October 10, 2001 19:15 To: seamoby@diameter.org Subject: [seamoby] FW: look at CT design team leader's email Gary, A ROHC fellow forwarded me this email. Would you care to explain why you think CT is dead? (or maybe it should be dead? ) We have been patiently waited for completion of the requirements!! Have a good day, Madjid -----Original Message----- From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] Sent: Tuesday, October 09, 2001 11:26 AM To: 'Lars-Erik Jonsson (EPL)'; 'ROHC' Subject: RE: [rohc] ROHC context transfer Lars-Erik: A number of attempts were made to engage people more familiar with ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement of knowledgeable people in a number of areas. This is a fatal weakness in my view, as the critical requirements for making CT work is the requirements set by the feature itself, not on abstract protocol requirements. I have made this point many times on the CT list, to no avail. It matters not, perhaps, for as far as I can see, CT is dead. There is next to no activity on this issue in Seamoby, and the problem statement lacks approval, even though it was completed many months ago. We shall see, but I do not intend to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the IESG. I did sit down with Carson Bormann at IETF 51. He expressed similar concerns as you, and we walked through my draft. Frankly, almost all of his comments were a matter of mis-interpreting my text, and the changes requested were mostly to make my draft more explanatory. I will do so, but frankly, this draft is not meant to be a normative reference for ROHC. As for the link layer dependencies: I find it curious that the IETF would develop a protocol that is link layer dependent, don't you? More comments below. Thank you for your input. I will take it into account, if I revise the I-D. Cheers, Gary > -----Original Message----- > From: Lars-Erik Jonsson (EPL) > [ mailto:Lars-Erik.Jonsson@epl.ericsson.se ] > Sent: October 9, 2001 10:32 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC' > Subject: RE: [rohc] ROHC context transfer > > > Hi Gary and others, > > I know that some people believe in context transfer, e.g. for > header compression, and I can not judge whether this might be > useful or not. Personally, I am skeptical to the whole idea > but I accept that others have a different opinion and I may > be convinced about the usefulness of header compression > context transfer for certain specific environments. However, > I strongly believe that at least for header compression, > context transfer is a link-technology dependent issue, and > would be implemented based on where/how header compression is > implemented in that specific link technology. > > Even if I really do not care about context transfer, I do > care about ROHC and that this work is not justified by, or > carried out based on, incorrect understandings of ROHC. > Previous discussions about this (in ROHC, SEAMOBY and > MOBILEIP) has shown a significant lack of ROHC knowledge from > those proposing context transfer (for ROHC!). Most > surprising, when ROHC authors have pointed out incorrect > statements about ROHC operation, this has even been > questioned by the context transfer proponents. This draft > (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to > previous drafts that have made several incorrect statements > about ROHC. However, this time I will concentrate on the > draft "Context Transfer Considerations for ROHC". With ROHC, > I refer either to the ROHC WG or to RFC-3095. > > See comments below... > > Cheers, > /Lars-Erik > > > >>> Section 3 - Overview ROHC Context > > > ... > > The decompressor monitors the success of decompression of > > the IP packets, and acknowledges successful decompression > > to the compressor. The compressor attempts to compress the > > IP packets as much as possible, as long as the transmitted > > packets are acknowledged. > > LEJ: ROHC may operate in 3 different modes, U-, O-, > or R-mode. Operation always start in U-mode and transition > to O- or R-mode may later be carried out through feedback > from the decompressor. The above text is correct only for > ROHC R-mode operation. A matter of interpretation: in my view, U- and O- modes can be considered "fallback" modes for R-mode. In other words, R-mode is the preferred mode of operation, providing the most compression. U- and O- modes are provided to accomodate the unreliable nature of the channel. Thus, ROHC attempts to compress as well as it can (R-mode), but sometimes cannot (O-, U- modes). > > > ... > > What makes ROHC robust is the intrinsic bias of the state > > machines to return to a basic mode of operation where no > > compression is performed. > > LEJ: Here the conceptually orthogonal terms state and > mode are mixed. The correct wording here should be state > only. However, what makes ROHC robust, compared to earlier > compression schemes, is obviously not the descriptive state > machine concept. I would counter that this is semantics. Defining multiple "modes" in the end results in the same outcome: multiple states in an implementation. I will use the wording preferred by the ROHC wg, but personally, I see it as conotational slight of hand. > > > ... > > Simply because of the robust definition of ROHC, it is > > possible to handover the uncompressed packet stream from > > the SAR to the RAR without the integrity of the IP sessions > > being compromised. ROCH defines an uncompressed, or > > no-compression profile with an identifier value of 0x0000. > > Because of the semantics of the CID encoding, a regular, > > uncompressed IP packet, is interpreted as having a profile > > of 0x0000. > > LEJ: The no-compression profile is not about what this text > indicates. The no-compression profile is used for streams > that can not be compressed with the profiles supported by > a compressor and decompressor pair, to be used over links > where only ROHC packets can be transmitted (not e.g. PPP). > This is thus not the no-context-transfer alternative. The > alternative to context transfer is simply to restart header > compression in IR-state, as a new packet stream for the new > link. I understand the intent of the 0x0000 profile defined by ROHC. However (and I explicitly posted this question to the wg email list), if ROHC is to be robust for handovers, then using 0x0000 as a fallback profile would not only be useful, it is a requirement. There is no way to gaurantee quasi-static context transfers for ROHC, thus a fall back mode is required. My perspective on this is to apply ROHC as a feature for packet communications. It is also possible to treat ROHC as a circuit switched feature (i.e. put it at the link layer), but, IMHO, this does not promote efficient packet switching. > > > ... > > The cons for this approach include: > > > > - the RAR may not be able to re-establish compression for > > traffic destined for the MN. The RAR would have no > > direct method of determining that the stream was to be > > compressed. > > LEJ: It would of course have to use the same method as any > node uses to determine if/how header compression can be > applied to new packet streams. If I understand you, the usual method involves signalling to/from the MN. This is always an option, but not an appealing one, as it does not seem conducive to a "seamless handover". Even if it were, it would consume precious bandwidth over the air. Handovers can be very serendipious, specially in pico cell environments in urban or indoor areas. Even one over the air message can be a significant overhead if there is lots of handovers occuring. One of the goals of Seamoby was to accomplish a handover with (ideally) no over the air signalling. I put it to you: how do you suggest one do this with ROHC? > > > ... > >>> Section 4.2 - Header Compression Profile Transfer > > LEJ: The heading itself indicates that something is not > correct here. A profile is nothing that can be subject to > transfer. A profile defines how a specific kind of packet > streams are compressed, i.e. basically the actual > compression protocol (in ROHC consistent with the framework). > Should it be "Context Transfer"? There are two issues here: a) do the CT source and destination share the same "profiles", if the answer is yes (hopefully), then a "profile transfer" would simply be a transfer of the profile id. If the answer is "no", then yes, it is argueable that there is nothing to transfer. I wanted to leave open the possibility of a "building block" approach to specifying profiles that might allow the receiver to "build" profile support. It's a complication that is, I agree, very difficult to realize, and therefore unlikely. > > > ... > > One issue with this approach is the reliance on the RAR > > having the same header compression profile. The IR packet > > conveys the profile ID and not the profile, and the RAR > > must match the received profile ID with one of the > > profiles in its local repository. > > LEJ: Once again, what is meant with "the profile"?. The > profile ID determines the profile, which is a compression > protocol, not a state. Also here, should it say "context"? To summarize, the context here is at least the profile id. It is likely nothing more. I should note, as I alluded to above, that CT can only be shown to work, IMHO, if we develope specific requirements and make some decisions on what to support and what not to. Unfortunately, the requirements for Seamoby span everything from cellular systems to 802.11, Bluetooth, and ad hoc networks. The latter two being completely unknown, and thus open to wild conjectures, like suppossed handovers between two dissimilar access routers. > > > ... > > Even if the RAR finds a matching ID, it is not clear that > > the profiles will match: e.g. for inter-technology > > handovers, say Bluetooth to 802.11, some of the link > > dependent aspects of the profile may change. > > LEJ: This just highlights the obvious fact that context > transfer for header compression is a link-issue. Two link > technologies might be supporting different profile sets, > or they might even be using different compression schemes > (not necessary ROHC). Further, inter-technology context > transfer would require inter-technology communication, or > higher layers to carry out the context transfer, which would > require higher layers to know about the lower layers. Well, no one can debate supposed link layer differences, certainly not in an IETF document. What you seem to be telling me is either that ROHC is a link layer protocol (which means it doesn't belong in the IETF) or that it relies heavily on link specific solutions, which means that is not an IP level solution (and doesn't belong in the IETF). As a side note: the intent is to define context transfer as a capability enabling protocol that might allow router manufacturers to transfer link layer state or whatever state they see fit. For many technologies, it will not be the appropriate solution. CT is fundamentally limited by being an IP layer soluton. > > > ... > >>> 4.3 - Static Compression Context Transfer > > ... > > The IR packet provides all the static context required > > to initiate the compressor and decompressor state machines. > > The first level of actual header compression for ROHC > > compresses the static and quasi- static fields. > > LEJ: The IR packet normally contains ALL header information, > both static and dynamic. I do not know what is meant with > quasi-static, only that it is not a term used by ROHC. It *at least* contains all the static context information, does it not? Quasi-static is a term I coined to apply to portions of the dynamic compression context. It applies to information that is dynamic, but changes slower then with every packet. It may be correct to simply send over all of the dynamic context, and let ROHC at the destination deal with the inconsistencies. I felt, and still do, that we could be smarter then this: i.e. build in a degree of robustness with ROHC that deals with handovers. However, this was presumptuous. > > > ... > >>> 4.4 - Dynamic Compression Context Transfer > > ... > > Dynamic compression context transfer will succeed for > > reactive context transfer only if the transfer can be > > completed between a packet arrival at the SAR and the > > first or second consecutive packet arrival at the RAR. > > LEJ: This is absolutely not true, ROHC is designed to be > robust against packet loss. It is true that there might be > problems like this with context transfer, if it is not > completed fast enough, but it is not true that ROHC can not > handle losses, as the above text indicates. You are looking at this from the perspective of ROHC. The issue is not whether ROHC can handle it, the issue is whether it is worth performing CT for dynamic state or not. If CT of dynamic context must rely upon ROHC robustness to recover, then it is not worth doing (reliance is, of course, a matter of frequency; clearly, if ROHC robustness is required to recover 90% of the time, then CT of dynamic ROHC context is not worth doing). Indeed, the proposal is to transfer only the static context, and let ROHC robustness do what it was designed to do. The question really is would CT of dynamic compression context really This section will be revised, if the draft is revised, to include dyanmic compression context. I believe I have someone from ROHC willing to contribute text. > > > ... > >>> 5.1 - ROHC Context for Header Profile Transfer > > It is assumed that the RAR and the SAR use identical header > > compression algorithms and header compression profiles. > > LEJ: As mentioned before, a ROHC profile can not possibly > be subject to transfer. In the same way, "header profile" is > not a term that makes sense either. A profile defines the > header compression protocol (algorithm) to be used. See above. There is a lot about ROHC which is in peoples heads, and not clear in the RFC (which would not be unusual for an IETF RFC *smile*). Thanks again for the comments. I certainly will keep them in mind if the draft is revised. I am very much open to comments, and hopefully, to contributed ideas/text. > > > > -----Original Message----- > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > < mailto:gkenward@nortelnetworks.com > ] > Sent: den 26 juli 2001 17:23 > To: 'ROHC' > Subject: [rohc] ROHC context transfer > > > > Hello. > > I have submitted a draft to the Context and Micro-Mobility > Routing (Seamoby) > working group on "Context Transfer Considerations for ROHC". > ROHC is fairly > new to me, and I would really appreciate any feedback from > the ROHC wg. > > Regards, > Gary Kenward > > http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c t-rohc-reqs-00.txt < http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00 .txt > . title: Context Transfer Considerations for ROHC abstract: There is an interest in enhancing the performance of handover between access routers through the transfer of forwarding context [2]. To clearly understand the requirements for this transfer, it is useful to examine the requirements of specific feature contexts. This document reviews the requirements for transferring the context associated with RObust Header Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed. author: Gary Kenward date: 07/12/2001 id: draft-kenward-seamoby-ct-rohc-reqs-00.txt ------_=_NextPart_001_01C1526C.8D4EC5A0 Content-Type: text/html; charset="iso-8859-1" RE: [seamoby] FW: look at CT design team leader's email
Madjid:
 
  I think that you and always have always been working towards a similar
if slightly different goal (differences are good). It frightens me that
anyone would consider me an authority and in any way representing the
opinions of Seamoby, if for no other reason then I have no idea what is
going on.
 
  If I am an impediment to CT progressing, then I will fall on my own sword,
and then hopefully the work can move forward.
 
  'nuff said. Indeed, more then enough said. Where is my claymore....
 
Gary
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 11, 2001 11:15
To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; seamoby@diameter.org
Subject: CT dead??

Gary,
 
I did appologize for not changing the subject.
I guess we both were victims of the electronic media.
 
As you rightly mentioned in your email to Rohc, the future of
CT heavily depends on detail feature (such as Rohc) work and 
 I do feel that such email coming from you as an
authority in CT, would block any possibility for others
trying to collaborate with groups like Rohc,....
You know that celebrities live a life watched by many others :)
 
Just one thing, the list has been very quiet not for 10 months, but since London and
that because people were waiting for the requirements, and maybe so many other
 things that are going on in the industry now....
 
Now, if IESG has problems with the documents, I am interested to
hear what these problems are.
 
 
Madjid
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, October 11, 2001 9:48 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; seamoby@diameter.org
Subject: RE: [seamoby] FW: look at CT design team leader's email

First of all, the design team was disbanded many months ago,
and I am not the leader of anything within Seamoby or the IETF.

Second, I did make the classic brain-dead mistake of replying
to your friend without checking the address list. I did not expect
these comments to be posted on the list, nor, naively, to be forwarded.
Even so, the language I used was too strong, even though it does
capture what I basically feel about the state of ct.

It's been 10 months, and the problem statement hasn't even
reached the IESG. The requirements are up for last call, but
no new work has commenced. The wg agenda is behind schedule,
and items which I believe are necessary for the work to continue
(and for which I believe there is at least moderate support - c.f.
the IETF 51 minutes) have not been incorporated into the Seamoby
charter. Items such as the requirement drafts for specific feature
context, a framework draft, and the link layer events draft, have
not been given homes. Please do not take any of the above observations
as a criticism of Pat Calhoun or Allison Mankin. I believe the
problems are partly circumstantial and partly due to our inability
to progress in a clear and decisive manner. All of this may perhaps
be the consequence of the complexity and ambiguity of the CT problem
space.

It's been 10 months, and the list is notably quiet. Perhaps Seamoby CT
is not dead, but it certainly is comatose. Should it be killed?
Well, if it takes 10 months to get the next wg draft out, then
euthanasia may be the best option.

Since you were so kind to cross-post this email, I am compelled to
attach my clarification to the ROHC email list that I posted last
night.

Finally, please note that the group I work with has not stopped working
on context transfer, micro-mobility and seamless mobility in general. As
I stated in my response to Lars-Erik, I will revise the ROHC document if
the problem statements and requirements drafts pass the IESG.

Gary Kenward

-----Original Message-----
> From: Kenward, Gary [WDLN2:AN10:EXCH]
> Sent: October 10, 2001 19:05
> To: ROHC (E-mail)
> Subject: FW: [rohc] ROHC context transfer
>
>
> I need to clarify a few points about the email I X-posted accidentally to the ROHC list.
> I made the classic brain-dead mistake of not checking all the addresses in the reply-field.
> When I wrote this response I believed I was responding to Lars-Erik only.
> 
> I want to make it clear that Dr. Bormann's was of great assistance to me at IETF 51, and I appreciated
> his help given the IETF was over, and he clearly had other appointments to meet. When
> I said in the email that "almost all of his comments were a matter of miss-interpreting my text",
> in most cases it was a result of my poor writing skills, and my attempts to summarize a fairly
> complex protocol. I still believe that this id should only try to summarize ROHC and not
> explain it, but clearly I need better words. Carsten helped me craft some of those words, and
> they sit on my computer, waiting for the next revision.
>
> Finally, concerning my frank comments concerning the life signs of context transfer - well,
> I might have said it differently on a wg list, but it's been 10 months and there is still no
> problem statement RFC. Some of us believed that we would have wg protocol drafts out for
> comments by now. Perhaps the idea simply isn't viable. Many of those initially involved
> are, I believe, moving on to other areas, or other venues.
> 
> Of course, this is only my opinion, and I'm sure the wg chairs have different views of
> where this is all headed. The last call was made on the ct requirements draft, and sometimes
> work progresses in marked fits and starts.
> 
> Regards,
> Gary Kenward
 

 -----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: October 10, 2001 19:15
To: seamoby@diameter.org
Subject: [seamoby] FW: look at CT design team leader's email


Gary,
 
A ROHC fellow  forwarded me this email.
Would you care to explain why you think CT is dead?
(or maybe it should be dead? )
 
We have been patiently waited for completion of the requirements!!
 
Have a good day,
Madjid

 -----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, October 09, 2001 11:26 AM
To: 'Lars-Erik Jonsson (EPL)'; 'ROHC'
Subject: RE: [rohc] ROHC context transfer


Lars-Erik:
  A number of attempts were made to engage people more familiar with
ROHC in the Seamoby discussion. Indeed, CT suffers from a lack of involvement
of knowledgeable people in a number of areas. This is a fatal weakness in my
view, as the critical requirements for making CT work is the requirements set
by the feature itself, not on abstract protocol requirements. I have made this
point many times on the CT list, to no avail.
  It matters not, perhaps, for as far as I can see, CT is dead. There is next
to no activity on this issue in Seamoby, and the problem statement lacks approval,
even though it was completed many months ago. We shall see, but I do not intend
to revise the ROHC CT document until the two outstanding WG I-Ds are sent to the
IESG.
  I did sit down with Carson Bormann at IETF 51. He expressed similar concerns
as you, and we walked through my draft. Frankly, almost all of his comments were
a matter of mis-interpreting my text, and the changes requested were mostly to
make my draft more explanatory. I will do so, but frankly, this draft is not
meant to be a normative reference for ROHC.
  As for the link layer dependencies: I find it curious that the IETF would develop
a protocol that is link layer dependent, don't you?
  More comments below.
 
  Thank you for your input. I will take it into account, if I revise the I-D.
Cheers,
Gary
> -----Original Message-----
> From: Lars-Erik Jonsson (EPL)
> [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: October 9, 2001 10:32
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'ROHC'
> Subject: RE: [rohc] ROHC context transfer
>
>
> Hi Gary and others,
> 
> I know that some people believe in context transfer, e.g. for
> header compression, and I can not judge whether this might be
> useful or not. Personally, I am skeptical to the whole idea
> but I accept that others have a different opinion and I may
> be convinced about the usefulness of header compression
> context transfer for certain specific environments. However,
> I strongly believe that at least for header compression,
> context transfer is a link-technology dependent issue, and
> would be implemented based on where/how header compression is
> implemented in that specific link technology.
> 
> Even if I really do not care about context transfer, I do
> care about ROHC and that this work is not justified by, or
> carried out based on, incorrect understandings of ROHC.
> Previous discussions about this (in ROHC, SEAMOBY and
> MOBILEIP) has shown a significant lack of ROHC knowledge from
> those proposing context transfer (for ROHC!). Most
> surprising, when ROHC authors have pointed out incorrect
> statements about ROHC operation, this has even been
> questioned by the context transfer proponents. This draft
> (draft-kenward-seamoby-ct-rohc-reqs-00.txt) refers to
> previous drafts that have made several incorrect statements
> about ROHC. However, this time I will concentrate on the
> draft "Context Transfer Considerations for ROHC". With ROHC,
> I refer either to the ROHC WG or to RFC-3095.
> 
> See comments below...
> 
> Cheers,
> /Lars-Erik
> 
> 
> >>> Section 3 - Overview ROHC Context
>
> > ...
> > The decompressor monitors the success of decompression of
> > the IP packets, and acknowledges successful decompression
> > to the compressor. The compressor attempts to compress the
> > IP packets as much as possible, as long as the transmitted
> > packets are acknowledged.
>  
> LEJ: ROHC may operate in 3 different modes, U-, O-,
> or R-mode. Operation always start in U-mode and transition
> to O- or R-mode may later be carried out through feedback
> from the decompressor. The above text is correct only for
> ROHC R-mode operation.
A matter of interpretation: in my view, U- and O- modes can be
considered "fallback" modes for R-mode. In other words, R-mode
is the preferred mode of operation, providing the most compression.
U- and O- modes are provided to accomodate the unreliable nature
of the channel. Thus, ROHC attempts to compress as well as it can
(R-mode), but sometimes cannot (O-, U- modes).
>  
> > ...
> > What makes ROHC robust is the intrinsic bias of the state
> > machines to return to a basic mode of operation where no
> > compression is performed.
>  
> LEJ: Here the conceptually orthogonal terms state and
> mode are mixed. The correct wording here should be state
> only. However, what makes ROHC robust, compared to earlier
> compression schemes, is obviously not the descriptive state
> machine concept.
I would counter that this is semantics. Defining multiple "modes"
in the end results in the same outcome: multiple states in an
implementation. I will use the wording preferred by the ROHC wg,
but personally, I see it as conotational slight of hand.
>
> > ...
> > Simply because of the robust definition of ROHC, it is
> > possible to handover the uncompressed packet stream from
> > the SAR to the RAR without the integrity of the IP sessions
> > being compromised. ROCH defines an uncompressed, or
> > no-compression profile with an identifier value of 0x0000.
> > Because of the semantics of the CID encoding, a regular,
> > uncompressed IP packet, is interpreted as having a profile
> > of 0x0000.
>
> LEJ: The no-compression profile is not about what this text
> indicates. The no-compression profile is used for streams
> that can not be compressed with the profiles supported by
> a compressor and decompressor pair, to be used over links
> where only ROHC packets can be transmitted (not e.g. PPP).
> This is thus not the no-context-transfer alternative. The
> alternative to context transfer is simply to restart header
> compression in IR-state, as a new packet stream for the new
> link.
I understand the intent of the 0x0000 profile defined by ROHC.
However (and I explicitly posted this question to the wg email
list), if ROHC is to be robust for handovers, then using 0x0000
as a fallback profile would not only be useful, it is a requirement.
There is no way to gaurantee quasi-static context transfers for ROHC,
thus a fall back mode is required.
My perspective on this is to apply ROHC as a feature for packet communications.
It is also possible to treat ROHC as a circuit switched feature (i.e. put it
at the link layer), but, IMHO, this does not promote efficient packet switching.
>
> > ...
> > The cons for this approach include:
> >
> > - the RAR may not be able to re-establish compression for
> >   traffic destined for the MN. The RAR would have no
> >   direct method of determining that the stream was to be
> >   compressed.
>
> LEJ: It would of course have to use the same method as any
> node uses to determine if/how header compression can be
> applied to new packet streams.
If I understand you, the usual method involves signalling to/from
the MN. This is always an option, but not an appealing one, as it
does not seem conducive to a "seamless handover". Even if it were,
it would consume precious bandwidth over the air.
Handovers can be very serendipious, specially in pico cell environments
in urban or indoor areas. Even one over the air message can be a
significant overhead if there is lots of handovers occuring.
One of the goals of Seamoby was to accomplish a handover with (ideally)
no over the air signalling. I put it to you: how do you suggest one
do this with ROHC?
>
> > ...
> >>> Section 4.2 - Header Compression Profile Transfer
>
> LEJ: The heading itself indicates that something is not
> correct here. A profile is nothing that can be subject to
> transfer. A profile defines how a specific kind of packet
> streams are compressed, i.e. basically the actual
> compression protocol (in ROHC consistent with the framework).
> Should it be "Context Transfer"?
There are two issues here: a) do the CT source and destination
share the same "profiles", if the answer is yes (hopefully), then
a "profile transfer" would simply be a transfer of the profile id.
If the answer is "no", then yes, it is argueable that there is nothing
to transfer. I wanted to leave open the possibility of a "building block"
approach to specifying profiles that might allow the receiver to
"build" profile support. It's a complication that is, I agree, very
difficult to realize, and therefore unlikely.
>
> > ...
> > One issue with this approach is the reliance on the RAR
> > having the same header compression profile. The IR packet
> > conveys the profile ID and not the profile, and the RAR
> > must match the received profile ID with one of the
> > profiles in its local repository.
>
> LEJ: Once again, what is meant with "the profile"?. The
> profile ID determines the profile, which is a compression
> protocol, not a state. Also here, should it say "context"?
To summarize, the context here is at least the profile id.
It is likely nothing more.
I should note, as I alluded to above, that CT can only be shown
to work, IMHO, if we develope specific requirements and make
some decisions on what to support and what not to. Unfortunately,
the requirements for Seamoby span everything from cellular systems
to 802.11, Bluetooth, and ad hoc networks. The latter two being
completely unknown, and thus open to wild conjectures, like
suppossed handovers between two dissimilar access routers.
>
> > ...
> > Even if the RAR finds a matching ID, it is not clear that
> > the profiles will match: e.g. for inter-technology
> > handovers, say Bluetooth to 802.11, some of the link
> > dependent aspects of the profile may change.
>
> LEJ: This just highlights the obvious fact that context
> transfer for header compression is a link-issue. Two link
> technologies might be supporting different profile sets,
> or they might even be using different compression schemes
> (not necessary ROHC). Further, inter-technology context
> transfer would require inter-technology communication, or
> higher layers to carry out the context transfer, which would
> require higher layers to know about the lower layers.
Well, no one can debate supposed link layer differences, certainly
not in an IETF document. What you seem to be telling me is either that
ROHC is a link layer protocol (which means it doesn't belong in the IETF)
or that it relies heavily on link specific solutions, which means that is
not an IP level solution (and doesn't belong in the IETF).
As a side note: the intent is to define context transfer as a capability
enabling protocol that might allow router manufacturers to transfer link
layer state or whatever state they see fit. For many technologies, it will
not be the appropriate solution. CT is fundamentally limited by being an IP
layer soluton.
>
> > ...
> >>> 4.3 - Static Compression Context Transfer
> > ...
> > The IR packet provides all the static context required
> > to initiate the compressor and decompressor state machines.
> > The first level of actual header compression for ROHC
> > compresses the static and quasi- static fields.
>
> LEJ: The IR packet normally contains ALL header information,
> both static and dynamic. I do not know what is meant with
> quasi-static, only that it is not a term used by ROHC.
It *at least* contains all the static context information,
does it not?
Quasi-static is a term I coined to apply to portions of the
dynamic compression context. It applies to information that
is dynamic, but changes slower then with every packet.
It may be correct to simply send over all of the dynamic context,
and let ROHC at the destination deal with the inconsistencies.
I felt, and still do, that we could be smarter then this:
i.e. build in a degree of robustness with ROHC that deals
with handovers. However, this was presumptuous.
>
> > ...
> >>> 4.4 - Dynamic Compression Context Transfer
> > ...
> > Dynamic compression context transfer will succeed for
> > reactive context transfer only if the transfer can be
> > completed between a packet arrival at the SAR and the
> > first or second consecutive packet arrival at the RAR.
>
> LEJ: This is absolutely not true, ROHC is designed to be
> robust against packet loss. It is true that there might be
> problems like this with context transfer, if it is not
> completed fast enough, but it is not true that ROHC can not
> handle losses, as the above text indicates.
You are looking at this from the perspective of ROHC. The issue
is not whether ROHC can handle it, the issue is whether it is
worth performing CT for dynamic state or not. If CT of dynamic
context must rely upon ROHC robustness to recover, then it is not
worth doing (reliance is, of course, a matter of frequency; clearly,
if ROHC robustness is required to recover 90% of the time, then CT
of dynamic ROHC context is not worth doing).
Indeed, the proposal is to transfer only the static context, and
let ROHC robustness do what it was designed to do. The question
really is would CT of dynamic compression context really
This section will be revised, if the draft is revised, to include
dyanmic compression context. I believe I have someone from ROHC
willing to contribute text.
>
> > ...
> >>> 5.1 - ROHC Context for Header Profile Transfer
> > It is assumed that the RAR and the SAR use identical header
> > compression algorithms and header compression profiles.
>
> LEJ: As mentioned before, a ROHC profile can not possibly
> be subject to transfer. In the same way, "header profile" is
> not a term that makes sense either. A profile defines the
> header compression protocol (algorithm) to be used.
See above. There is a lot about ROHC which is in peoples heads,
and not clear in the RFC (which would not be unusual for an IETF
RFC *smile*).
Thanks again for the comments. I certainly will keep them in mind
if the draft is revised. I am very much open to comments, and hopefully,
to contributed ideas/text.
>
> 
>
> -----Original Message-----
> From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
> <mailto:gkenward@nortelnetworks.com> ]
> Sent: den 26 juli 2001 17:23
> To: 'ROHC'
> Subject: [rohc] ROHC context transfer
>
>
>
> Hello.
>
> I have submitted a draft to the Context and Micro-Mobility
> Routing (Seamoby)
> working group on "Context Transfer Considerations for ROHC".
> ROHC is fairly
> new to me, and I would really appreciate any feedback from
> the ROHC wg.
>
> Regards,
> Gary Kenward
>
> http://search.ietf.org/internet-drafts/draft-kenward-seamoby-c
t-rohc-reqs-00.txt <http://search.ietf.org/internet-drafts/draft-kenward-seamoby-ct-rohc-reqs-00.txt> .
title: Context Transfer Considerations for ROHC
abstract: There is an interest in enhancing the performance of handover between access
routers through the transfer of forwarding context [2]. To clearly understand the requirements
for this transfer, it is useful to examine the requirements of specific feature contexts. This
document reviews the requirements for transferring the context associated with RObust Header
Compressions (ROHC [3]) in preparation for a handoff of the IP traffic being compressed.
author: Gary Kenward
date: 07/12/2001
id: draft-kenward-seamoby-ct-rohc-reqs-00.txt

------_=_NextPart_001_01C1526C.8D4EC5A0-- From owner-seamoby@diameter.org Thu Oct 11 12:35:28 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19352 for ; Thu, 11 Oct 2001 12:35:28 -0400 (EDT) Received: (qmail 6522 invoked by alias); 11 Oct 2001 16:19:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6516 invoked by uid 200); 11 Oct 2001 16:19:41 -0000 Received: (qmail 6511 invoked by uid 500); 11 Oct 2001 16:19:39 -0000 Date: Thu, 11 Oct 2001 09:19:39 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] Ct is not dead Message-ID: <20011011091939.D6038@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk I'd like to respond to the comments that were made by Gary recently. First off, I don't consider CT to be dead. The events that provided this appearance is that folks were waiting for the London meeting in order to get the remaining CT issues closed. The document has since then been revised to address these comments, and the document is in last call. Barring any comments, it will be sent to the IESG. As far as the problem statement, it hasn't been through the IESG at this time, but we will work to get any issues addressed and move the document towards RFC-hood. This is by no means an unfixable problem, not does it mean that the work (or need) is irrelevant. So I'd like to urge the WG to continue with the great document reviews that we've had since our inception, and not assume that being a little late in our milestones means that this work is no longer considered critical to mobility. Thanks, PatC From owner-seamoby@diameter.org Thu Oct 11 12:47:30 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19595 for ; Thu, 11 Oct 2001 12:47:29 -0400 (EDT) Received: (qmail 7155 invoked by alias); 11 Oct 2001 16:31:54 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7149 invoked by uid 200); 11 Oct 2001 16:31:54 -0000 Received: (qmail 7144 invoked by uid 500); 11 Oct 2001 16:31:53 -0000 Date: Thu, 11 Oct 2001 09:31:52 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] re: Ct is not dead Message-ID: <20011011093152.H6038@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk All, I said: > Barring any comments, it will be sent to the IESG. As far as the problem > statement, it hasn't been through the IESG at this time, but we will > work to get any issues addressed and move the document towards RFC-hood. what I meant to say here is that it has not been approved by the IESG yet, not that it hasn't been through the IESG. They have looked at it, and we are expected to receive their comments. I will make sure that these comments are taken care of quickly so we can get to protocol design. Thanks, PatC From owner-seamoby@diameter.org Thu Oct 11 15:40:27 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23649 for ; Thu, 11 Oct 2001 15:40:27 -0400 (EDT) Received: (qmail 8257 invoked by alias); 11 Oct 2001 19:24:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8251 invoked by uid 200); 11 Oct 2001 19:24:36 -0000 Received: (qmail 8246 invoked from network); 11 Oct 2001 19:24:34 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 11 Oct 2001 19:24:34 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA01535 for ; Thu, 11 Oct 2001 12:30:40 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA21927 for ; Thu, 11 Oct 2001 12:39:15 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KWV9YAA>; Thu, 11 Oct 2001 14:39:15 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA0AD@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Vijay Devarapalli'" , Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@diameter.org Subject: RE: [seamoby] security disabling in CT reqs Date: Thu, 11 Oct 2001 14:38:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Thanks Vijay, I came to the same conclusion since sending the email. The ESP header can be absent, if you don't want security. Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Wednesday, October 10, 2001 7:25 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: seamoby@diameter.org Subject: Re: [seamoby] security disabling in CT reqs Nakhjiri Madjid-MNAKHJI1 wrote: > > I have one quick comment for now: > > I understand the thought behind the following section (some > folks don't care about security in their internal networks) > > 5.3.3 The protocol MUST provide for the security provisioning to be > disabled. > > However, reading in the ESP RFC, I found out that you cannot > NULL both authentication and encryption at the same time. > > this means that ESP cannot be proposed for securing CT messages. > Since, I cannot disable both encryption and authentication at > the same time, so I cannot meet 5.3.3. > > Does this mean, ESP is out of question for CT? > Any idea? > No. it just means that if the ESP header is present, both authentication and encryption cannot be sent to NULL at the same time. atleast one should be used. of course the ESP header itself can be absent. basically this is CT without security (req 5.3.3). Vijay From owner-seamoby@diameter.org Fri Oct 12 15:10:30 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07322 for ; Fri, 12 Oct 2001 15:10:30 -0400 (EDT) Received: (qmail 11819 invoked by alias); 12 Oct 2001 18:54:09 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 11812 invoked by uid 200); 12 Oct 2001 18:54:08 -0000 Received: (qmail 11807 invoked from network); 12 Oct 2001 18:54:07 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Oct 2001 18:54:07 -0000 Received: from heliopolis.eng.sun.com ([152.70.8.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04060; Fri, 12 Oct 2001 13:08:44 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA20550; Fri, 12 Oct 2001 12:08:51 -0700 (PDT) Message-Id: <200110121908.MAA20550@heliopolis.eng.sun.com> Date: Fri, 12 Oct 2001 12:08:50 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] Paging Protocol Assessment To: seamoby@diameter.org Cc: kempf42@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JOjOZ3Y8iuqbRG46lriApQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Folks, In response to Pat's request for volunteers, we have four people who have signed up to help. Since we also have four protocols to assess, we now have a good match of people to the task. We are currently going through preliminaries to get started on the assessment. I hope to have a draft of the assessment with recommendations in enough time to get a good list discussion prior to IETF 52 in Dec. jak From owner-seamoby@diameter.org Fri Oct 12 15:14:40 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07457 for ; Fri, 12 Oct 2001 15:14:40 -0400 (EDT) Received: (qmail 12348 invoked by alias); 12 Oct 2001 18:59:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12341 invoked by uid 200); 12 Oct 2001 18:59:18 -0000 Received: (qmail 12335 invoked from network); 12 Oct 2001 18:59:16 -0000 Received: from patan.sun.com (192.18.98.43) by c900656-a.plstn1.sfba.home.com with SMTP; 12 Oct 2001 18:59:16 -0000 Received: from heliopolis.eng.sun.com ([152.70.8.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07579; Fri, 12 Oct 2001 13:13:54 -0600 (MDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA20806; Fri, 12 Oct 2001 12:14:06 -0700 (PDT) Message-Id: <200110121914.MAA20806@heliopolis.eng.sun.com> Date: Fri, 12 Oct 2001 12:14:05 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [seamoby] Questions on CAR Discovery Problem Statement? To: seamoby@diameter.org Cc: kempf42@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Z9Q2NXyJ6wQ5EJu9l7wEQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-seamoby@diameter.org Precedence: bulk Folks, The CAR discovery problem statement is currently in last call. At IETF 51 in London, I vaguely recall after Govind's presentation hearing that some WG members were uncertain why CAR discovery was necessary. The current problem statement attempts to address this question more directly than the original did. I hope those of you who had this question will read the problem statement and submit any further questions to the list. In addition, if anybody has any further issues with the problem statement, now is your chance to raise them. Thanx. jak From owner-seamoby@diameter.org Tue Oct 16 14:49:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15135 for ; Tue, 16 Oct 2001 14:49:32 -0400 (EDT) Received: (qmail 28567 invoked by alias); 16 Oct 2001 18:33:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 28561 invoked by uid 200); 16 Oct 2001 18:33:43 -0000 Received: (qmail 28556 invoked from network); 16 Oct 2001 18:33:42 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Oct 2001 18:33:42 -0000 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA00762 for ; Tue, 16 Oct 2001 11:48:45 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA20270 for ; Tue, 16 Oct 2001 11:39:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KW51KAC>; Tue, 16 Oct 2001 13:48:45 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA0CC@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@diameter.org Subject: [seamoby] comments on CT reqs: IP triggers Date: Tue, 16 Oct 2001 13:48:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Just trying to ask a question from the editor(s) and beating the deadline... 1) I don't quite get req 4.1: CT MUST define characteristics of IP level trigger..... CT can start either by a layer 2 event or a layer 3 event. Furthermore, It could be started based on a signal or a message from layer 2 or layer 3. What does "characteristic of IP level trigger" mean? IMHO, the combination of 4.2 and 4.4 is enough and 4.1 is just confusing. 2) Also, I don't know what 5.1.3 is trying to say? Thanks, Madjid From owner-seamoby@diameter.org Wed Oct 17 14:45:27 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03367 for ; Wed, 17 Oct 2001 14:45:26 -0400 (EDT) Received: (qmail 624 invoked by alias); 17 Oct 2001 18:26:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 615 invoked by uid 200); 17 Oct 2001 18:26:58 -0000 Received: (qmail 609 invoked from network); 17 Oct 2001 18:26:57 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 18:26:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03182; Wed, 17 Oct 2001 14:41:58 -0400 (EDT) Message-Id: <200110171841.OAA03182@ietf.org> To: IETF-Announce: ; Subject: [seamoby] RFC 3154 on Paging Requirements Cc: rfc-ed@ISI.EDU, seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: RFC Editor Date: Wed, 17 Oct 2001 14:41:58 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 3154 Title: Requirements and Functional Architecture for an IP Host Alerting Protocol Author(s): J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu Status: Informational Date: August 2001 Mailbox: James.Kempf@Sun.COM, pars.mutaf@inria.fr, claude.castelluccia@inria.fr, nnakajima@tari.toshiba.com, yohba@tari.toshiba.com, ramjee@bell-labs.com, Yousuf.Saifullah@nokia.com, Behcet.Sarikaya@usa.alcatel.com, xiaofeng.xu@usa.alcatel.com Pages: 16 Characters: 31534 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-seamoby-paging-requirements-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3154.txt This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This document is a product of the Context Transfer, Handoff Candidate discovery and Dormant Mode Host Alerting Working Group of the of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Length: 490 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010809160323.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3154 --OtherAccess Content-Type: Message/External-body; name="rfc3154.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010809160323.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Wed Oct 17 17:09:41 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07478 for ; Wed, 17 Oct 2001 17:09:40 -0400 (EDT) Received: (qmail 2165 invoked by alias); 17 Oct 2001 20:53:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2157 invoked by uid 200); 17 Oct 2001 20:53:44 -0000 Received: (qmail 2127 invoked from network); 17 Oct 2001 20:53:40 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:53:40 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HL9Lf07922 for ; Thu, 18 Oct 2001 00:09:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:08:45 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM8>; Thu, 18 Oct 2001 00:08:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF257@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] Last Call Comments on CAR Discovery, Part 1 Date: Thu, 18 Oct 2001 00:08:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Comments: Add Mobile Node (MN) to the terminology section. John From owner-seamoby@diameter.org Wed Oct 17 17:13:20 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07613 for ; Wed, 17 Oct 2001 17:13:20 -0400 (EDT) Received: (qmail 2218 invoked by alias); 17 Oct 2001 20:53:49 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2206 invoked by uid 200); 17 Oct 2001 20:53:49 -0000 Received: (qmail 2155 invoked from network); 17 Oct 2001 20:53:44 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:53:44 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HL9Lf07914 for ; Thu, 18 Oct 2001 00:09:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:08:45 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM6>; Thu, 18 Oct 2001 00:08:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF255@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] CT Req Last Call comment, part 3 Date: Thu, 18 Oct 2001 00:08:38 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, What is the status of this? 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. I suggest we strike the entire section. John From owner-seamoby@diameter.org Wed Oct 17 17:16:53 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07681 for ; Wed, 17 Oct 2001 17:16:53 -0400 (EDT) Received: (qmail 2228 invoked by alias); 17 Oct 2001 20:53:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2211 invoked by uid 200); 17 Oct 2001 20:53:49 -0000 Received: (qmail 2128 invoked from network); 17 Oct 2001 20:53:40 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:53:40 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HL9Lf07937 for ; Thu, 18 Oct 2001 00:09:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:08:45 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM9>; Thu, 18 Oct 2001 00:08:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF254@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] CT Req Last Call comment, part 2 Date: Thu, 18 Oct 2001 00:08:37 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, A small nit: 4.13 The context information provided for transfer MUST be reliable. The context to be transferred must not only be readily available for transfer, but the sending AR must ensure that the information is sound. The context transfer solution may provide mechanisms to support reliable transfer of context, but the effectiveness of context transfer in enhancing handover between ARs would very likely be compromised by attempts to transfer malformed context. -> this requirement may not really be needed (I don't think there is any realistic way to enforce this & I don't quite imagine that any entity will want to transfer malformed context. Any malform context which is transfered is most likely due to problems (software bugs, etc). This is a minor nit & I won't loose any sleep if we do leave this in. John From owner-seamoby@diameter.org Wed Oct 17 17:21:04 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07723 for ; Wed, 17 Oct 2001 17:21:04 -0400 (EDT) Received: (qmail 2262 invoked by alias); 17 Oct 2001 20:53:53 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2255 invoked by uid 200); 17 Oct 2001 20:53:53 -0000 Received: (qmail 2196 invoked from network); 17 Oct 2001 20:53:47 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:53:47 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HL9Of07951 for ; Thu, 18 Oct 2001 00:09:24 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:08:48 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKNA>; Thu, 18 Oct 2001 00:08:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF259@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] Last Call Comments on CAR Discovery, Part 3 Date: Thu, 18 Oct 2001 00:08:41 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi All, Section 5.3 should be its own first level heading (right before the references). You need to better outline the types of DOS and/or theft of services. John From owner-seamoby@diameter.org Wed Oct 17 17:24:54 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07768 for ; Wed, 17 Oct 2001 17:24:54 -0400 (EDT) Received: (qmail 2426 invoked by alias); 17 Oct 2001 20:54:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2418 invoked by uid 200); 17 Oct 2001 20:54:26 -0000 Received: (qmail 2387 invoked from network); 17 Oct 2001 20:54:22 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:54:22 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLA3f08121 for ; Thu, 18 Oct 2001 00:10:03 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:09:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKND>; Thu, 18 Oct 2001 00:08:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF25A@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] Last Call Comments on CAR Discovery, Part 4 Date: Thu, 18 Oct 2001 00:08:42 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, A general comment on CAR Discovery. I think some text needs to be added about CAR filtering. For example, in the cellular world, one may be somewhere where several service providers have potential base stations where handoffs could occur. Usually, when roaming, one does not perform inter-operator handoffs unless certain criteria are met, such as the current service provider's signal strength falls below a certain level. I think that in the problem statement, some mention of this kind of problem should be addressed. If needed, I could provide a paragraph or two on it. John From owner-seamoby@diameter.org Wed Oct 17 17:28:26 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07789 for ; Wed, 17 Oct 2001 17:28:25 -0400 (EDT) Received: (qmail 2434 invoked by alias); 17 Oct 2001 20:54:27 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2419 invoked by uid 200); 17 Oct 2001 20:54:26 -0000 Received: (qmail 2384 invoked from network); 17 Oct 2001 20:54:22 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:54:22 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLA3f08114 for ; Thu, 18 Oct 2001 00:10:03 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:09:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKN1>; Thu, 18 Oct 2001 00:08:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF25B@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] Last Call Comments on CAR Discovery, Part 5 Date: Thu, 18 Oct 2001 00:08:42 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, Small editorial nit. Move the Acknowledgement section to the end of the document. John From owner-seamoby@diameter.org Wed Oct 17 17:32:03 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07829 for ; Wed, 17 Oct 2001 17:32:03 -0400 (EDT) Received: (qmail 2501 invoked by alias); 17 Oct 2001 20:54:35 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2494 invoked by uid 200); 17 Oct 2001 20:54:35 -0000 Received: (qmail 2461 invoked from network); 17 Oct 2001 20:54:30 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:54:30 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLAAf08203 for ; Thu, 18 Oct 2001 00:10:10 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:09:34 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM7>; Thu, 18 Oct 2001 00:08:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF253@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] CT Req Last Call comment, part 1 Date: Thu, 18 Oct 2001 00:08:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, I think that this has been brought up before, but I want to make sure we capture this: I think this requirement: 4.9 The entities transferring context MUST have completed a mutual authentication process prior to initiating the transfer. Should be reworded to this: 4.9 The entities transferring context MUST support a mutual authentication process occuring prior to initiating the transfer. The change is requested because in some scenarios, network operators may wish to turn off mutual authentication. We need the support for mutual authentication before CT takes place, but I don't know if we need to require it to happen. John From owner-seamoby@diameter.org Wed Oct 17 17:35:36 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07866 for ; Wed, 17 Oct 2001 17:35:36 -0400 (EDT) Received: (qmail 2522 invoked by alias); 17 Oct 2001 20:54:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2511 invoked by uid 200); 17 Oct 2001 20:54:37 -0000 Received: (qmail 2458 invoked from network); 17 Oct 2001 20:54:30 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:54:30 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLAAf08196 for ; Thu, 18 Oct 2001 00:10:10 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:09:34 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM5>; Thu, 18 Oct 2001 00:08:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF256@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] CT Req Last Call comment, part 4 Date: Thu, 18 Oct 2001 00:08:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, Last comment. There is no 'Security' chapter. I suggest we add a short section. What goes in there should be: 6. Security Concerns This document sets the requirements for context transfer solutions. In of itself, this document does not directly affect the security of the Internet. The Context Transfer Problem Statement [2] outlines some of the possible security implications of Context Transfer. Additionally, section 5.3 discusses the security requirements for context transfer. As a general statement, context transfer solutions should not introduce new security problems on the Internet. --> The Security Area strongly recommends that ALL Internet Drafts contain a chapter on Security & so I see it as important to have some text on it, in a seperate chapter. best regards, John From owner-seamoby@diameter.org Wed Oct 17 17:39:03 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07890 for ; Wed, 17 Oct 2001 17:39:03 -0400 (EDT) Received: (qmail 2531 invoked by alias); 17 Oct 2001 20:54:38 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2519 invoked by uid 200); 17 Oct 2001 20:54:37 -0000 Received: (qmail 2479 invoked from network); 17 Oct 2001 20:54:32 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Oct 2001 20:54:32 -0000 Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9HLADf08224 for ; Thu, 18 Oct 2001 00:10:13 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 00:09:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VGKM0>; Thu, 18 Oct 2001 00:08:48 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF258@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: [seamoby] Last Call Comments on CAR Discovery, Part 2 Date: Thu, 18 Oct 2001 00:08:40 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi all, Editorial nit: 1. Introduction 2nd paragraph: To motivate the Candidate AR discovery problem, we now describe some illustrative scenarios in which the Candidate AR discovery protocol may be useful. --- Should be --- To provide motiviation for the Candidate AR Discovery work, some illustrative scenarios are provided in which the Candidate AR discovery protocol is useful. John From owner-seamoby@diameter.org Wed Oct 17 20:45:34 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10091 for ; Wed, 17 Oct 2001 20:45:34 -0400 (EDT) Received: (qmail 7515 invoked by alias); 18 Oct 2001 00:29:04 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7509 invoked by uid 200); 18 Oct 2001 00:29:04 -0000 Received: (qmail 7504 invoked from network); 18 Oct 2001 00:29:02 -0000 Received: from ginsberg.uol.com.br (200.231.206.26) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Oct 2001 00:29:02 -0000 Received: from denio ([200.227.55.93]) by ginsberg.uol.com.br (8.9.1/8.9.1) with SMTP id WAA21245 for ; Wed, 17 Oct 2001 22:41:22 -0200 (BRST) Message-ID: <001c01c15776$45546200$4932e3c8@npd.ufpe.br> From: "Denio Mariz" To: Subject: [seamoby] Standard Representation of Context Information Date: Wed, 17 Oct 2001 22:43:20 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello: In [draft-ietf-seamoby-ct-reqs-01.txt], section 5.1.2 we have: "The context transfer protocol design MUST define a standard representation for conveying context information that will be interpreted uniformly and perspicuously by different implementations." So, to define a "standard representation" do you think is important is to know exactly what information will be involved in each "context" ? If yes, and considering the diversity of contexts that can be involved in this work, who will to establish this information ? Thanks, Denio. From owner-seamoby@diameter.org Wed Oct 17 20:54:11 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10175 for ; Wed, 17 Oct 2001 20:54:09 -0400 (EDT) Received: (qmail 8072 invoked by alias); 18 Oct 2001 00:38:16 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8066 invoked by uid 200); 18 Oct 2001 00:38:16 -0000 Received: (qmail 8061 invoked from network); 18 Oct 2001 00:38:14 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Oct 2001 00:38:14 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27894; Wed, 17 Oct 2001 17:52:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9I0qpr22768; Wed, 17 Oct 2001 17:52:51 -0700 X-mProtect: Wed, 17 Oct 2001 17:52:51 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIN1OcM; Wed, 17 Oct 2001 17:52:49 PDT Message-ID: <3BCE27E2.3FF2FBAC@iprg.nokia.com> Date: Wed, 17 Oct 2001 17:52:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Denio Mariz CC: seamoby@diameter.org Subject: Re: [seamoby] Standard Representation of Context Information References: <001c01c15776$45546200$4932e3c8@npd.ufpe.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit take a look at http://people.nokia.net/~rajeev/draft-koodli-seamoby-hc-relocate-01.txt http://people.nokia.net/~rajeev/draft-westphal-seamoby-qos-relocate-00.txt Please read the sections on Header Compression profile types, and QoS profile types. They might answer your question. Each feature (we are currently working on a IPSec profile type) will have to define its own profile types and the associated profile. Vijay Denio Mariz wrote: > > Hello: > > In [draft-ietf-seamoby-ct-reqs-01.txt], section 5.1.2 we have: > > "The context transfer protocol design MUST define a standard > representation for conveying context information that will be > interpreted uniformly and perspicuously by different > implementations." > > So, to define a "standard representation" do you think is important is to > know exactly what information will be involved in each "context" ? > If yes, and considering the diversity of contexts that can be involved in > this work, who will to establish this information ? > > Thanks, > > Denio. From owner-seamoby@diameter.org Thu Oct 18 01:22:36 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16050 for ; Thu, 18 Oct 2001 01:22:36 -0400 (EDT) Received: (qmail 9979 invoked by alias); 18 Oct 2001 05:05:18 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9973 invoked by uid 200); 18 Oct 2001 05:05:17 -0000 Message-ID: <20011018050517.9971.qmail@charizard.diameter.org> Received: (qmail 9959 invoked from network); 18 Oct 2001 05:05:13 -0000 Received: from unknown (HELO ????) (211.237.229.10) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Oct 2001 05:05:13 -0000 From: =?ks_c_5601-1987?B?wOWw5r/1?= To: seamoby@cdma-2000.org Subject: [seamoby] =?ks_c_5601-1987?B?saSw7Togv/i1zsS/x8ctx+Kw+iC4wMC6IMPWsO0hILChsN3AuiDD1sD6sKEhIA==?= Date: Thu, 18 Oct 2001 14:22:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01C0F18A.93A22C00" X-Priority: 3 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0147_01C0F18A.93A22C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 VW50aXRsZWQNCiAgICDH47b0vvjAzCC43sDPwLsgurizu7ytIMHLvNvH1bTPtNkuIMDMILje wM/AuiCw+LCztcggv6m3ryCw1L3DxsfAuyC55rmux8+/qQ0KDQogICDHz7OqIMfPs6ogwM/A z8DMILHit8/Hz7+pILjewM/AuyC6uLO7tMIgsaSw7cDUtM+02S4gsOHE2iwgwaS6uLimILvn sKHB9rDtIA0KICAgurizvSCwzcDMIL7GtNW0z7TZLiCx17evuce3ziwgv/jHz73DwfYgvsq0 wrTZuOkgu+jBpsfYIMHWvLy/5C4gDQoNCiAgICAgICAgICC02b3DtMIgvsggurizu7DavcC0 z7TZDQoNCg0KICAgIMD6yPEgIsWwvbrF5sS/x8e87sfOIr+hvK20wiC56citwaHAzLOqIMfS wM4guLbGrr+hvK0gv8DHwbbzwM4gxse4xbi4IA0KICDHz7TZIL/CtvPAziDGx7jFuKYgx8+x 4iDAp8fYILv1t9Ow1CAixbC9usXmxL/Hx7zux84iwMy287TCILzux8649MC7IA0KICC/wMfC x8+w1CC1x776vcC0z7TZLiANCiANCg0KICAgICC/+LXOxL/Hx7imILvntvvHz73DtMIgutC1 6cDMtvO46SC8vLDoIMPWsO3AxyDHsLDdwLsgwNq2+8fSuLjHz7jnLCANCiAgx+Kw+iC4wL+h vK21tSDD1rvzwLsgwNq6zsfPtMIgxbC9usXmv6G8rSCwobDdwLogw9bA+rCht84gv/i1zsS/ x8fAxw0KICAgwfi89rimILTAsrgguri9w7HiILnZtvi0z7TZLiANCg0KICDD1rDtwMcgx+Kw +iC4wMC7IMDatvvHz7jpvK21tSDFuLvnv80guvGxs8fYILq4vcO46SDA/bndv6G1tSC+yLXJ IMGktbW3ziANCiAgICDA+rfFx8+w1CDGx7jFx9W0z7TZLiC68b3OtNmw7SC02SDBwcC6ILDN wLogvsa01bTPtNkuIA0KIA0KDQogICAgwPrI8bChIMPrsd7Hz7TCIMewuPHAuiC/+LXOxL/H xyDBvrf5Lg0KDQogICAxLsfixL/Hx8G+t/k6IMfswfGz08fixL/Hxy652bTStvOz08fixL/H xy7DysTatvPB7rqjuK7Ev8fHLg0KICAgICAgICAgICAgICAgICDE7cWwvtjFqbiyx+LEv8fH Lr7GwMy4rr2sx+LEv8fHDQoNCiAgIDIuuu23u7XlxL/HxzogvbrG5LzIuu23u7XlLr+hvbrH wbe5vNIuuPDEq7rtt7u15S7Hz7/svbq67be7teUuuu2357i2v+7Gvrrtt7u15Q0KDQogICAz Lr/4tc7Ev8fHICA6IMTavbrFuLiuxKsgtbXFuCC1+7bzweoutM/Eq7bzsbi+xiCzqsfPvbou v6HGvL/Ax8e+xiDAzLChw7zHwS7E3bfSuvG+xrz2x8G4rrjwDQoNCiAgIDQuxL/Hx7D8t8O/ 68ewOiC89rW/x9q15bnQLrrxwPyx4r3EIL+psPqx4i6/qbD6wfYoMTDA3C81wNwpDQoNCiAg ICAgICCw7bC0vL7FuCAoMDMxKTk2Mi0xOTcxICANCiAgICAgICB3d3cuY29mZmVlc2hvcGlu Zy5jb20gICAgaGVscEBjb2ZmZWVzaG9waW5nLmNvbQ0KIA0KICAgICAgxbC9usXmIMDOxc2z 3SC75773us46ILq7us7A5SAgwOWw5r/1DQoNCiANCg== ------=_NextPart_000_0147_01C0F18A.93A22C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZDwvdGl0bGU+DQo8bWV0YSBuYW1lPSJnZW5l cmF0b3IiIGNvbnRlbnQ9Ik5hbW8gV2ViRWRpdG9yIHYzLjAiPg0KPC9oZWFkPg0KDQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgdGV4dD0iYmxhY2siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIGFsaW5rPSJyZWQiPg0KDQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBj b2xvcj0icmVkIj7H47b0vvjAzCC43sDPwLsgurizu7ytIMHLvNvH1bTPtNkuIA0KwMwguN7A z8C6ILD4sLO1yCC/qbevILDUvcPGx8C7ILnmua7Hz7+pPC9mb250PjwvcD4NCjxwPjxmb250 IGNvbG9yPSJyZWQiPiZuYnNwOyZuYnNwOyZuYnNwO8fPs6ogx8+zqiDAz8DPwMwgseK3z8fP v6kguN7Az8C7ILq4s7u0wiANCrGksO3A1LTPtNkuILDhxNosIMGkuri4piC757Chwfaw7SA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDu6uLO9ILDNwMwgvsa01bTPtNkuILHXt6+5x7fOLCC/ +MfPvcPB9iC+yrTCtNm46SC76MGmx9ggwda8vL/kLiANCjwvZm9udD48L3A+DQo8cD48Zm9u dCBjb2xvcj0iZ3JlZW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO7TZvcO0wiANCr7IILq4s7uw2r3AtM+02TwvZm9udD48 L3A+DQo8cD48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvA+sjxICZxdW90O8WwvbrF 5sS/x8e87sfOJnF1b3Q7v6G8rbTCILnpyK3BocDMs6ogx9LAziANCri2xq6/obytIL/Ax8G2 88DOIMbHuMW4uCA8YnI+DQombmJzcDsmbmJzcDvHz7TZIL/CtvPAziDGx7jFuKYgx8+x4iDA p8fYILv1t9Ow1CAmcXVvdDvFsL26xebEv8fHvO7HziZxdW90O8DMtvO0wiANCrzux8649MC7 IDxicj4NCiZuYnNwOyZuYnNwO7/Ax8LHz7DUILXHvvq9wLTPtNkuIDxicj4NCiZuYnNwOzwv cD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO7/4tc7Ev8fHuKYgu+e2+8fP vcO0wiC60LXpwMy287jpPGZvbnQgc2l6ZT0iMyINCiBjb2xvcj0iZ3JlZW4iPiC8vLDoIMPW sO3AxyDHsLDdwLsgwNq2+8fSuLjHz7jnLCA8YnI+DQombmJzcDsmbmJzcDvH4rD6ILjAv6G8 rbW1IMPWu/PAuyDA2rrOx8+0wiDFsL26xea/obytILChsN3AuiDD1sD6sKG3ziC/+LXOxL/H x8DHPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7wfi89rimIDwvZm9udD60wLK4ILq4vcOx4iC5 2bb4tM+02S4gPC9wPg0KPHA+Jm5ic3A7Jm5ic3A7w9aw7cDHIMfisPoguMDAuyDA2rb7x8+4 6byttbUgxbi757/NILrxsbPH2CC6uL3DuOkgwP253b+htbUgvsi1ySANCsGktbW3ziA8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvA+rfFx8+w1CDGx7jFx9W0z7TZLiA8Zm9udCBj b2xvcj0icmVkIj668b3OtNmw7SC02SDBwcC6IA0KsM3AuiC+xrTVtM+02S4gPGJyPg0KJm5i c3A7PC9mb250PjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO8D6yPGwoSDD67He x8+0wiDHsLjxwLogv/i1zsS/x8cgwb63+S48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsx LsfixL/Hx8G+t/k6IMfswfGz08fixL/Hxy652bTStvOz08fixL/Hxy7DysTatvPB7rqjuK7E v8fHLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO8TtxbC+2MWpuLLH4sS/x8cuvsbAzLiuvazH4sS/x8c8L3A+DQo8cD4mbmJzcDsmbmJz cDsmbmJzcDsyLrrtt7u15cS/x8c6IL26xuS8yLrtt7u15S6/ob26x8G3ubzSLrjwxKu67be7 teUux8+/7L26uu23u7XlLrrtt+e4tr/uxr667be7teU8L3A+DQo8cD4mbmJzcDsmbmJzcDsm bmJzcDszLr/4tc7Ev8fHICZuYnNwOzogxNq9usW4uK7EqyC1tcW4ILX7tvPB6i60z8SrtvOx uL7GILOqx8+9ui6/oca8v8DHx77GIA0KwMywocO8x8EuxN230rrxvsa89sfBuK648DwvcD4N CjxwPiZuYnNwOyZuYnNwOyZuYnNwOzQuxL/Hx7D8t8O/68ewOiC89rW/x9q15bnQLrrxwPyx 4r3EIL+psPqx4i6/qbD6wfYoMTDA3C81wNwpPC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7sO2wtLy+xbggKDAzMSk5NjItMTk3MSAmbmJzcDs8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRw Oi8vd3d3LmNvZmZlZXNob3BpbmcuY29tIj4mbmJzcDt3d3cuY29mZmVlc2hvcGluZy5jb208 L2E+IA0KJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaGVscEBjb2ZmZWVzaG9waW5nLmNvbSI+Jm5i c3A7aGVscEBjb2ZmZWVzaG9waW5nLmNvbTwvYT48YnI+DQombmJzcDs8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvFsL26xeYgwM7FzbPdILvnvve6zjoguru6 zsDlICZuYnNwO8DlsOa/9TwvcD4NCjxwPiZuYnNwOzwvcD4NCjwvYm9keT4NCg0KPC9odG1s PiA= ------=_NextPart_000_0147_01C0F18A.93A22C00-- From owner-seamoby@diameter.org Thu Oct 18 11:32:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12933 for ; Thu, 18 Oct 2001 11:32:31 -0400 (EDT) Received: (qmail 12798 invoked by alias); 18 Oct 2001 15:16:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 12792 invoked by uid 200); 18 Oct 2001 15:16:24 -0000 Received: (qmail 12787 invoked from network); 18 Oct 2001 15:16:22 -0000 Received: from oe65.law4.hotmail.com (HELO hotmail.com) (216.33.148.161) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Oct 2001 15:16:22 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Oct 2001 08:30:57 -0700 X-Originating-IP: [66.122.105.22] From: "Eunsoo Shim" To: "Vijay Devarapalli" , "Denio Mariz" Cc: References: <001c01c15776$45546200$4932e3c8@npd.ufpe.br> <3BCE27E2.3FF2FBAC@iprg.nokia.com> Subject: Re: [seamoby] Standard Representation of Context Information Date: Thu, 18 Oct 2001 08:36:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 18 Oct 2001 15:30:57.0449 (UTC) FILETIME=[E20B9190:01C157E9] Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I see Vijay's approach. I am wondering whether we can take an approach to similar SDP (Session Description Protocol) where information is represented as a pair of field name and its value in text form. Its advantage is flexibility. Thus we can add new information quite easily later. Also we can accomodate routers which do not support all the features in each context profile. Well, handling text might be slower than handling predefined binary format message. Would it be a big problem for routers? My sense is that its advantage overwhelms the performance difference. What do you think? Regards, Eunsoo ----- Original Message ----- From: "Vijay Devarapalli" To: "Denio Mariz" Cc: Sent: Wednesday, October 17, 2001 5:52 PM Subject: Re: [seamoby] Standard Representation of Context Information > > take a look at > > http://people.nokia.net/~rajeev/draft-koodli-seamoby-hc-relocate-01.txt > http://people.nokia.net/~rajeev/draft-westphal-seamoby-qos-relocate-00.txt > > Please read the sections on Header Compression profile types, and QoS > profile types. They might answer your question. Each feature (we are > currently working on a IPSec profile type) will have to define its own > profile types and the associated profile. > > Vijay > > Denio Mariz wrote: > > > > Hello: > > > > In [draft-ietf-seamoby-ct-reqs-01.txt], section 5.1.2 we have: > > > > "The context transfer protocol design MUST define a standard > > representation for conveying context information that will be > > interpreted uniformly and perspicuously by different > > implementations." > > > > So, to define a "standard representation" do you think is important is to > > know exactly what information will be involved in each "context" ? > > If yes, and considering the diversity of contexts that can be involved in > > this work, who will to establish this information ? > > > > Thanks, > > > > Denio. > From owner-seamoby@diameter.org Fri Oct 19 10:54:24 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20602 for ; Fri, 19 Oct 2001 10:54:24 -0400 (EDT) Received: (qmail 16578 invoked by alias); 19 Oct 2001 14:37:45 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 16571 invoked by uid 200); 19 Oct 2001 14:37:44 -0000 Message-ID: <20011019143744.16570.qmail@charizard.diameter.org> Received: (qmail 16561 invoked from network); 19 Oct 2001 14:37:41 -0000 Received: from 1cust233.tnt4.cph3.da.uu.net (HELO mydomain.com) (213.116.23.233) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 14:37:41 -0000 Date: Fri, 19 Oct 2001 16:50:20 +0100 From: HOTBABES To: EROTICA@charizard.diameter.org Subject: [seamoby] SEXWEB NO.1 .. MEGAWEB-SEX ! Sender: owner-seamoby@diameter.org Precedence: bulk Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER the Worldīs No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you donīt need to sign-up or have a creditcard ... The way it should be ! TO PLUGIN and get access to something you with guarantee NEVER have seen before, use ANY of the servers listed below ! Enjoy the BEST! Yours truly, HOTBABES GROUP To get EASY ACCESS & PLUGIN to the LARGEST CONTENT SEXSERVER on the NET, use any of the 2 SERVERS listed here: 1. http://wownet.onweb.cx 2. http://wwwap.to/wownet From owner-seamoby@diameter.org Fri Oct 19 12:22:08 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22812 for ; Fri, 19 Oct 2001 12:22:08 -0400 (EDT) Received: (qmail 17301 invoked by alias); 19 Oct 2001 16:05:37 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17294 invoked by uid 200); 19 Oct 2001 16:05:36 -0000 Received: (qmail 17289 invoked from network); 19 Oct 2001 16:05:34 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 16:05:34 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA18649 for ; Fri, 19 Oct 2001 09:20:47 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA05838 for ; Fri, 19 Oct 2001 09:20:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KW5G9WR>; Fri, 19 Oct 2001 11:20:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA0E6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , pcalhoun@diameter.org, seamoby@cdma-2000.org Subject: RE: [seamoby] CT Req Last Call comment, part 2 Date: Fri, 19 Oct 2001 11:20:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk I agree with John here, if you are transferring context, you want to get it right. At this point without going into specifics of various features, this requirement does not add any information. Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, October 17, 2001 4:09 PM To: pcalhoun@diameter.org; seamoby@cdma-2000.org Subject: [seamoby] CT Req Last Call comment, part 2 Hi all, A small nit: 4.13 The context information provided for transfer MUST be reliable. The context to be transferred must not only be readily available for transfer, but the sending AR must ensure that the information is sound. The context transfer solution may provide mechanisms to support reliable transfer of context, but the effectiveness of context transfer in enhancing handover between ARs would very likely be compromised by attempts to transfer malformed context. -> this requirement may not really be needed (I don't think there is any realistic way to enforce this & I don't quite imagine that any entity will want to transfer malformed context. Any malform context which is transfered is most likely due to problems (software bugs, etc). This is a minor nit & I won't loose any sleep if we do leave this in. John From owner-seamoby@diameter.org Fri Oct 19 13:14:15 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24780 for ; Fri, 19 Oct 2001 13:14:14 -0400 (EDT) Received: (qmail 17947 invoked by alias); 19 Oct 2001 16:58:12 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 17941 invoked by uid 200); 19 Oct 2001 16:58:12 -0000 Received: (qmail 17933 invoked from network); 19 Oct 2001 16:58:10 -0000 Received: from oe47.law4.hotmail.com (HELO hotmail.com) (216.33.148.84) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 16:58:10 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Oct 2001 10:12:54 -0700 X-Originating-IP: [66.122.105.22] From: "Eunsoo Shim" To: , , Cc: "Richard D. Gitlin" References: <0C1353ABB1DEB74DB067ADFF749C4EEF3EF25A@esebe004.NOE.Nokia.com> Subject: Re: [seamoby] Last Call Comments on CAR Discovery, Part 4 Date: Fri, 19 Oct 2001 10:18:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 19 Oct 2001 17:12:54.0133 (UTC) FILETIME=[4A493A50:01C158C1] Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, It's a good point. It will often be the case that All CAR information is not needed for every mobile node. I think we should differentiate two things: CAR discovery by access routers and retrieval/advertisement of the information by/to mobile nodes. I'd like to say it is better for each access router to collect all the information as it can. However transmission of the information to mobile nodes over air interface should be filtered out intelligently to save bandwidth, etc. Thanks. Eunsoo ----- Original Message ----- From: To: ; Sent: Wednesday, October 17, 2001 2:08 PM Subject: [seamoby] Last Call Comments on CAR Discovery, Part 4 > Hi all, > > A general comment on CAR Discovery. I think some text needs to be > added about CAR filtering. For example, in the cellular world, > one may be somewhere where several service providers have potential > base stations where handoffs could occur. Usually, when roaming, > one does not perform inter-operator handoffs unless certain > criteria are met, such as the current service provider's > signal strength falls below a certain level. > > I think that in the problem statement, some mention of this > kind of problem should be addressed. If needed, I could provide > a paragraph or two on it. > > John > From owner-seamoby@diameter.org Fri Oct 19 13:17:13 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24919 for ; Fri, 19 Oct 2001 13:17:13 -0400 (EDT) Received: (qmail 18481 invoked by alias); 19 Oct 2001 17:00:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18475 invoked by uid 200); 19 Oct 2001 17:00:59 -0000 Received: (qmail 18470 invoked from network); 19 Oct 2001 17:00:57 -0000 Received: from netmail.alcatel.com (128.251.168.50) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 17:00:57 -0000 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA16415; Fri, 19 Oct 2001 12:16:08 -0500 (CDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f9JHG2O13696; Fri, 19 Oct 2001 12:16:02 -0500 (CDT) Message-ID: <3BD06151.A85C60EE@alcatel.com> Date: Fri, 19 Oct 2001 12:22:25 -0500 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: seamoby , "mobile-ip@sunroof.eng.sun.com" Subject: [seamoby] draft-guri-seamoby-paging-triggers-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, We submitted an I-D on Layer 2 API for Paging, until it is posted at the IETF drafts directory, you can access it from: http://www.geocities.com/bsarikaya/draft-guri-seamoby-paging-triggers-00.txt We hereby volunteer to combine this one with handover triggers defined in draft-kempf-beth-ipv6-02.txt and draft-manyfolks-l2-mobilereq-00.txt if requested in order to contribute towards defining an Layer 2 API for Mobility. Comments are welcome. Regards, -- Behcet From owner-seamoby@diameter.org Fri Oct 19 14:36:45 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27415 for ; Fri, 19 Oct 2001 14:36:44 -0400 (EDT) Received: (qmail 19171 invoked by alias); 19 Oct 2001 18:20:11 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19165 invoked by uid 200); 19 Oct 2001 18:20:11 -0000 Received: (qmail 19157 invoked from network); 19 Oct 2001 18:20:09 -0000 Received: from web13901.mail.yahoo.com (216.136.175.27) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 18:20:09 -0000 Message-ID: <20011019183522.75876.qmail@web13901.mail.yahoo.com> Received: from [216.98.102.225] by web13901.mail.yahoo.com via HTTP; Fri, 19 Oct 2001 11:35:22 PDT Date: Fri, 19 Oct 2001 11:35:22 -0700 (PDT) From: James Kempf Subject: Re: [seamoby] Last Call Comments on CAR Discovery, Part 4 To: Eunsoo Shim , john.loughney@nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org Cc: "Richard D. Gitlin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-seamoby@diameter.org Precedence: bulk This sounds like a requirement to me. Not sure if the problem statement is the right place for that... jak --- Eunsoo Shim wrote: > Hi, > > It's a good point. > It will often be the case that All CAR information > is not needed for every > mobile node. > I think we should differentiate two things: CAR > discovery by access routers > and retrieval/advertisement of the information by/to > mobile nodes. > I'd like to say it is better for each access router > to collect all the > information as it can. > However transmission of the information to mobile > nodes over air interface > should be filtered out intelligently to save > bandwidth, etc. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, October 17, 2001 2:08 PM > Subject: [seamoby] Last Call Comments on CAR > Discovery, Part 4 > > > > Hi all, > > > > A general comment on CAR Discovery. I think some > text needs to be > > added about CAR filtering. For example, in the > cellular world, > > one may be somewhere where several service > providers have potential > > base stations where handoffs could occur. > Usually, when roaming, > > one does not perform inter-operator handoffs > unless certain > > criteria are met, such as the current service > provider's > > signal strength falls below a certain level. > > > > I think that in the problem statement, some > mention of this > > kind of problem should be addressed. If needed, I > could provide > > a paragraph or two on it. > > > > John > > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-seamoby@diameter.org Fri Oct 19 15:04:13 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28091 for ; Fri, 19 Oct 2001 15:04:12 -0400 (EDT) Received: (qmail 19846 invoked by alias); 19 Oct 2001 18:47:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 19840 invoked by uid 200); 19 Oct 2001 18:47:59 -0000 Received: (qmail 19832 invoked from network); 19 Oct 2001 18:47:57 -0000 Received: from oe42.law4.hotmail.com (HELO hotmail.com) (216.33.148.79) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 18:47:57 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Oct 2001 12:02:41 -0700 X-Originating-IP: [66.122.105.22] From: "Eunsoo Shim" To: "James Kempf" , , , Cc: "Richard D. Gitlin" References: <20011019183522.75876.qmail@web13901.mail.yahoo.com> Subject: Re: [seamoby] Last Call Comments on CAR Discovery, Part 4 Date: Fri, 19 Oct 2001 12:08:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: X-OriginalArrivalTime: 19 Oct 2001 19:02:41.0128 (UTC) FILETIME=[A070E680:01C158D0] Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Right. I agree with you. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; ; ; Cc: "Richard D. Gitlin" Sent: Friday, October 19, 2001 11:35 AM Subject: Re: [seamoby] Last Call Comments on CAR Discovery, Part 4 > This sounds like a requirement to me. Not sure if the > problem statement is the right place for that... > > jak > > --- Eunsoo Shim wrote: > > Hi, > > > > It's a good point. > > It will often be the case that All CAR information > > is not needed for every > > mobile node. > > I think we should differentiate two things: CAR > > discovery by access routers > > and retrieval/advertisement of the information by/to > > mobile nodes. > > I'd like to say it is better for each access router > > to collect all the > > information as it can. > > However transmission of the information to mobile > > nodes over air interface > > should be filtered out intelligently to save > > bandwidth, etc. > > Thanks. > > > > Eunsoo > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Wednesday, October 17, 2001 2:08 PM > > Subject: [seamoby] Last Call Comments on CAR > > Discovery, Part 4 > > > > > > > Hi all, > > > > > > A general comment on CAR Discovery. I think some > > text needs to be > > > added about CAR filtering. For example, in the > > cellular world, > > > one may be somewhere where several service > > providers have potential > > > base stations where handoffs could occur. > > Usually, when roaming, > > > one does not perform inter-operator handoffs > > unless certain > > > criteria are met, such as the current service > > provider's > > > signal strength falls below a certain level. > > > > > > I think that in the problem statement, some > > mention of this > > > kind of problem should be addressed. If needed, I > > could provide > > > a paragraph or two on it. > > > > > > John > > > > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > From owner-seamoby@diameter.org Fri Oct 19 18:16:17 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03057 for ; Fri, 19 Oct 2001 18:16:17 -0400 (EDT) Received: (qmail 23615 invoked by alias); 19 Oct 2001 21:59:41 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23609 invoked by uid 200); 19 Oct 2001 21:59:40 -0000 Received: (qmail 23604 invoked from network); 19 Oct 2001 21:59:38 -0000 Received: from gamma.isi.edu (128.9.144.145) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Oct 2001 21:59:38 -0000 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id f9JMEnH27260; Fri, 19 Oct 2001 15:14:49 -0700 (PDT) Message-Id: <200110192214.f9JMEnH27260@gamma.isi.edu> To: IETF-Announce: ; Subject: [seamoby] RFC 3154 on Paging Requirements Cc: rfc-ed@ISI.EDU, seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 19 Oct 2001 15:14:48 -0700 From: RFC Editor Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3154 Title: Requirements and Functional Architecture for an IP Host Alerting Protocol Author(s): J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu Status: Informational Date: August 2001 Mailbox: James.Kempf@Sun.COM, pars.mutaf@inria.fr, claude.castelluccia@inria.fr, nnakajima@tari.toshiba.com, yohba@tari.toshiba.com, ramjee@bell-labs.com, Yousuf.Saifullah@nokia.com, Behcet.Sarikaya@usa.alcatel.com, xiaofeng.xu@usa.alcatel.com Pages: 16 Characters: 31534 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-seamoby-paging-requirements-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3154.txt This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This document is a product of the Context Transfer, Handoff Candidate discovery and Dormant Mode Host Alerting Working Group of the of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <011019151349.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3154 --OtherAccess Content-Type: Message/External-body; name="rfc3154.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <011019151349.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Sat Oct 20 01:53:00 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25648 for ; Sat, 20 Oct 2001 01:52:57 -0400 (EDT) Received: (qmail 790 invoked by alias); 20 Oct 2001 05:35:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 784 invoked by uid 200); 20 Oct 2001 05:35:08 -0000 Received: (qmail 772 invoked from network); 20 Oct 2001 05:35:03 -0000 Received: from server1.safepages.com (216.127.146.3) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Oct 2001 05:35:03 -0000 Received: from localhost (unknown [65.138.137.74]) by server1.safepages.com (Postfix) with ESMTP id 264F75E90; Sat, 20 Oct 2001 05:49:52 +0000 (GMT) X-Sender: sronalds@phastnet.com From: Ronald Samuels To: "Mortgage Borrower" Date: Fri, 19 Oct 2001 23:05:00 -0700 Subject: [seamoby] Need a Home Loan? Let Us Help! Reply-To: sronalds@phastnet.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__47041539_82805.45" Message-Id: <20011020054952.264F75E90@server1.safepages.com> Sender: owner-seamoby@diameter.org Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__47041539_82805.45 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__47041539_82805.45 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9 IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn cm91bmQ9aHR0cDovLzMyNDkzMDk2NTAvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZmZiBi Z3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPg0K PERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPEJSPg0KPFAgYWxp Z249Y2VudGVyPjxiPjxpPjxmb250IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSJCcnVzaCBTY3Jp cHQgTVQiIHNpemU9IjUiPiZxdW90O0FsbCBvdXIgdGhvdWdodHMsIHByYXllcnMgYW5kIGxv dmUgZ28gb3V0IHRvIHRoZSBmYW1pbGllcyBhbmQgZnJpZW5kcyBvZiB0aGUgdmljdGltcyBv ZiB0aGUgV29ybGQgVHJhZGUgQ2VudGVyIHRyYWdlZHkuJnF1b3Q7PC9mb250PjwvaT48L2I+ PC9QPg0KDQo8UCBhbGlnbj1jZW50ZXI+PGVtPjxiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBz aXplPSI2IiBmYWNlPSJhcmlhbCI+JnF1b3Q7UmVmaW5hbmNlIFlvdXINCkN1cnJlbnQgTW9y dGdhZ2UgV2hpbGUgUmF0ZXMgQXJlIExPVyEhJnF1b3Q7PC9mb250PjwvYj48L2VtPjwvUD4N CjxNQVJRVUVFPjxpPjxiPjxGT05UIHNpemU9NCBjb2xvcj0jMDAwMGZmPkhPTUUgRVFVSVRZ IExPQU5TICoqKiBKVU1CTyBMT0FOUyAqKiogSE9NRSBJTVBST1ZFTUVOVCBMT0FOUyAqKiog DQogICAgICBERUJUIENPTlNPTElEQVRJT04gTE9BTlMgKioqIFJFRklOQU5DRSBMT0FOUyAq KiogQUxMIEFSRSBBVkFJTEFCTEUgVE8gWU9VICoqKiBSQVRFUyBBUyBMT1cgQVMgDQogICAg ICAzLjk1JTwvZm9udD48L2I+PC9pPjwvbWFycXVlZT4NCjxCUj48QlI+DQo8cCBhbGlnbj0i Y2VudGVyIj48Yj48Zm9udCBzaXplPSI0Ij5Nb3J0Z2FnZSBSYXRlcyBBcmUgU28gTG93ISZu YnNwOzwvZm9udD48L2I+PC9wPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0i NCI+WW91IENhbiBTYXZlIFRob3VzYW5kcyBPZiBEb2xsYXJzIEJ5IFRha2luZw0KQWR2YW50 YWdlIE5vdyE8L2ZvbnQ+PC9iPjwvcD4NCjxQIGFsaWduPWNlbnRlcj48RU0+PEI+PEZPTlQg Y29sb3I9I2ZmMDAwMCBzaXplPTU+JnF1b3Q7V0UgQVJFIEFOIEFTU09DSUFUSU9OIE9GDQpN T1JUR0FHRSBCUk9LRVJTIEFORCBMRU5ERVJTIDwvRk9OVD48L0I+PC9FTT48L1A+DQo8UCBh bGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PldJVEggVEhF IEJFU1QgUkFURVMgQU5EIFRIRSBMT1dFU1QNCkNPU1RTISZxdW90PC9GT05UPjwvQj48L0VN PjwvUD4NCjxwIGFsaWduPSJjZW50ZXIiPiZuYnNwOzwvcD4NCjxQIGFsaWduPWNlbnRlcj48 Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9ND48Qj5XZSZuYnNwO2hhdmUgdGhvdXNhbmRzIG9m IGxvYW4gDQpwcm9ncmFtcyB0aHJvdWdoIGh1bmRyZWRzIG9mIGxlbmRlcnMhPEJSPjwvQj48 L0ZPTlQ+PEZPTlQgc2l6ZT0zPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PFNUUk9O Rz48Rk9OVCBzaXplPTU+WW91IGNhbiBjaG9vc2UgZnJvbSZuYnNwOyJBZGp1c3RhYmxlIFJh dGUNCk1vcnRnYWdlcyANCmFzIGxvdyBhcyAzLjk1JSZxdW90OzwvRk9OVD48L1NUUk9ORz48 L1A+DQo8UCBhbGlnbj1jZW50ZXI+PFNUUk9ORz48Rk9OVCBzaXplPTU+YW5kJm5ic3A7IkZp eGVkIFJhdGUgTW9ydGdhZ2VzIGFzIGxvdyBhcw0KNS41MCUmbmJzcDs8L0ZPTlQ+PC9TVFJP Tkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PmFsbCB3aXRo IHRoZSBsb3dlc3QgY29zdHMgaW4gdGhlDQpOYXRpb24hJnF1b3Q7PC9GT05UPjwvU1RST05H PjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAwPio8L0ZPTlQ+PC9CSUc+PC9CSUc+PC9Q Pg0KPFAgYWxpZ249Y2VudGVyPjxGT05UIA0Kc2l6ZT01Pjxmb250IGNvbG9yPSIjRkYwMDAw Ij4mcXVvdDs8Yj48aT5ZT1UgQ0FOIDx1PkJVWSBET1dOIFlPVVIgSU5URVJFU1QgUkFURTwv dT4NClRPPC9pPjwvYj48L2ZvbnQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Zm9u dCBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iNSI+PGI+PGk+QVMgTE9XIEFTIFlPVSBDQU4NCkFG Rk9SRCEmcXVvdDs8L2k+PC9iPjwvZm9udD48Rk9OVCANCnNpemU9NT48QlI+PC9GT05UPjxG T05UIHNpemU9Mz48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxGT05UIHNpemU9KzA+ PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTI+PEJJRz48QklHPjxGT05UIA0KY29sb3I9I2Zm MDAwMCBzaXplPTU+KjwvRk9OVD48L0JJRz48U1RST05HPkFsbCByYXRlcyBhcmUgYmFzZWQg b24gDQpxdWFsaWZpY2F0aW9uPC9TVFJPTkc+ITwvQklHPjwvRk9OVD48L0ZPTlQ+PC9QPg0K PFAgYWxpZ249Y2VudGVyPjxGT05UIHNpemU9KzA+PEZPTlQgc2l6ZT0yPjxCSUc+PC9CSUc+ PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDBmZj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNp emU9Mj48QSBocmVmPSJodHRwOi8vMzI0OTMwOTY1MCIgDQp0YXJnZXQ9X2JsYW5rPjxGT05U IHNpemU9NT48U1RST05HPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Q2xpY2sgaGVy ZSBmb3IgDQp5b3VyIDwvRk9OVD48Rk9OVCBzaXplPTY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48RU0+IkZSRUUgUkFURSANClFVT1RFIiE8L0VNPjwvRk9OVD48L0ZPTlQ+PC9T VFJPTkc+PC9GT05UPjwvQT48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAg YWxpZ249bGVmdD4mbmJzcDs8L1A+DQo8UCBhbGlnbj1sZWZ0PjxpPjxiPjxmb250IGZhY2U9 IkFyaWFsIiBzaXplPSIrMCI+Q0xJQ0sgT04gTE9BTlMgQkVMT1cgRk9SIFlPVVINCkZSRUUg QVBQTElDQVRJT04hPC9mb250PjwvYj48L2k+PEZPTlQgZmFjZT1BcmlhbD48QlI+PC9GT05U PjwvUD4NCjxQIGFsaWduPWxlZnQ+PFNUUk9ORz48RU0+PEEgaHJlZj0iaHR0cDovLzMyNDkz MDk2NTAiIA0KdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+ UHVyY2hhc2UgTG9hbnM8L2ZvbnQ+PC9BPiA8Rk9OVCBzaXplPTU+DQo8L0ZPTlQ+IDwvRU0+ PEZPTlQgDQpzaXplPTQ+LSA8RU0+VGhvdXNhbmRzIG9mIHByb2dyYW1zIA0KZm9yIEZpcnN0 IE1vcnRnYWdlcyE8L0VNPjwvRk9OVD48ST48L0k+PC9TVFJPTkc+PEk+PEZPTlQgDQpjb2xv cj0jMDAwMDAwPjxCUj48QlI+PC9GT05UPjwvST48QSBocmVmPSJodHRwOi8vMzI0OTMwOTY1 MCIgX2JsYW5rPz48RU0+PFNUUk9ORz48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+ UmVmaW5hbmNlIExvYW5zPC9mb250PjwvU1RST05HPjwvRU0+PEk+PEZPTlQgDQpjb2xvcj0j MDAwMDAwIHNpemU9Mj4gPC9GT05UPjwvST48L0E+PEk+PEZPTlQgY29sb3I9IzAwMDAwMCBz aXplPTQ+LSA8Qj5SZWR1Y2UgeW91ciANCm1vbnRobHkgcGF5bWVudHMgYW5kPC9GT05UPjxG T05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPiA8L0ZPTlQ+PEZPTlQgDQpjb2xvcj0jZmYwMDAw IHNpemU9NT5HZXQgQ2FzaCBCYWNrITwvRk9OVD48L0I+PEZPTlQgY29sb3I9IzAwMDAwMCBz aXplPTQ+IA0KPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPjxCUj48QlI+PC9G T05UPjwvST48QSANCmhyZWY9Imh0dHA6Ly8zMjQ5MzA5NjUwIiB0YXJnZXQ9X2JsYW5rPjxm b250IGNvbG9yPSIjODAwMDgwIj48RU0+PEI+PEZPTlQgc2l6ZT01PlNlY29uZCANCk1vcnRn YWdlczwvRk9OVD48L0I+PC9FTT48ST48Rk9OVCBzaXplPTM+IDwvRk9OVD48L0k+DQo8L2Zv bnQ+IDwvQT48ST48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz4gLSA8L0ZPTlQ+PEI+PEZP TlQgDQpjb2xvcj0jMDAwMDAwIHNpemU9ND5XZSBjYW4gaGVscCB5b3UgZ2V0IGZyb20gPC9G T05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+OTAlPC9GT05UPjxGT05UIGNvbG9y PSMwMDAwMDAgc2l6ZT00PiB1cCB0byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCANCnNp emU9NT4xMjUlPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiBvZiB5b3VyIGhv bWVzIHZhbHVlISAocmF0aW9zIHZhcnkgDQpieSBzdGF0ZSk8L0ZPTlQ+PC9CPjwvUD4NCjxQ IGFsaWduPWxlZnQ+PEEgaHJlZj0iaHR0cDovLzMyNDkzMDk2NTAiIA0KdGFyZ2V0PV9ibGFu az48Qj48Zm9udCBzaXplPSI1IiBjb2xvcj0iIzgwMDA4MCI+RGVidCBDb25zb2xpZGF0aW9u PC9mb250PjwvQj48L0E+PEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IDxGT05UIGNvbG9y PSMwMDAwMDAgc2l6ZT00Pi0gDQo8Qj5Db21iaW5lIDwvRk9OVD48Rk9OVCBjb2xvcj0jZmYw MDAwIHNpemU9NT5hbGw8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCANCnNpemU9ND4geW91 ciBiaWxscyBpbnRvIDwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT5PbmUgTG93 IE1vbnRobHkgDQpQYXltZW50ITwvRk9OVD48L0I+PEJSPjxCUj48L0ZPTlQ+PEI+PEEgDQpo cmVmPSJodHRwOi8vMzI0OTMwOTY1MCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPSI1IiBj b2xvcj0iIzgwMDA4MCI+Rmlyc3QgVGltZSBIb21lIEJ1eWVyczwvZm9udD48L0E+PEZPTlQg Y29sb3I9IzAwMDAwMCBzaXplPTM+IC0gDQo8Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND5X ZSBjYW4gaGVscCB5b3UgYnV5IHdpdGggPEZPTlQgY29sb3I9I2ZmMDAwMCANCnNpemU9NT5M b3c8L0ZPTlQ+PC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiBNb25leSBEb3du PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTQ+LCBhbmQgZXZlbiA8L0ZPTlQ+ PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2ggDQpCYWNrITwvRk9OVD48L0ZP TlQ+PC9CPjwvUD48L0k+DQo8UCBhbGlnbj1jZW50ZXI+PEJJRz48QklHPjxGT05UIGNvbG9y PSNmZjAwMDA+KjwvRk9OVD48L0JJRz5BbGwgcmF0ZXMgYXJlIGJhc2VkIA0Kb24gcXVhbGlm aWNhdGlvbiE8L0JJRz48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PEI+PEk+PEZPTlQgY29sb3I9 IzAwMDAwMCBzaXplPTY+V2UgaGF2ZSBwcm9ncmFtcyBmb3IgDQo8L0ZPTlQ+PEZPTlQgY29s b3I9I2ZmMDAwMCBzaXplPTY+PFU+RVZFUlk8L1U+PC9GT05UPjxGT05UIGNvbG9yPSMwMDAw MDAgc2l6ZT02PiANCmNyZWRpdCBzaXR1YXRpb24hPC9GT05UPjxCUj48QlI+PEEgaHJlZj0i aHR0cDovLzMyNDkzMDk2NTAiIHRhcmdldD1fYmxhbms+PEZPTlQgDQpjb2xvcj0jMDAwMGZm IHNpemU9NT5DbGljayBoZXJlIGZvciB5b3VyIEZSRUUgUkFURSBRVU9URSE8L0ZPTlQ+PC9B PjwvST48L0I+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jMDA4MDAwPjxTVFJP Tkc+JnF1b3Q7VGhpcyBtZXNzYWdlIGlzIGJlaW5nIHNlbnQgdG8NCnlvdSBpbiBjb21wbGlh bmNlIHdpdGgmbmJzcDtCaWxsIFMuIDE2MTggVGl0bGUgSUlJIHBhc3NlZCBieSB0aGUgMTA1 dGggVVMNCkNvbmdyZXNzLCB3aGljaCBzdGF0ZXMgdGhhdCB0aGlzIGxldHRlciBjYW4gbm90 IGJlIGNvbnNpZGVyZWQgc3BhbSBhcyBsb25nIGFzIHdlDQppbmNsdWRlICgxKSBWYWxpZCBD b250YWN0IEluZm9ybWF0aW9uIGFuZCAoMikmbmJzcDthIHdheSB0byBiZSByZW1vdmVkIGZy b20gYW55DQpmdXJ0aGVyIHRyYW5zbWlzc2lvbnMgYXQgbm8gY29zdCB0byB5b3UgYnkgc3Vi bWl0dGluZyBhIHJlcXVlc3QgdG8gYmUNCnJlbW92ZWQuJnF1b3Q7IC4gPGEgaHJlZj0iaHR0 cDovLzMyNDkzMDk2NTAvcmVtb3ZlLmh0bSI+Q2xpY2sgSGVyZSB0byBTZW5kIGEgUmVtb3Zl IFJlcXVlc3Q8L2E+Lg0KJnF1b3Q7V2UgaG9ub3IgYWxsIHJlbW92ZSBlbWFpbCBhZGRyZXNz IHJlcXVlc3RzJm5ic3A7aW1tZWRpYXRlbHkuJnF1b3Q7PC9TVFJPTkc+PC9GT05UPjwvUD48 L0JPRFk+PC9IVE1MPg== ------=_NextPart_000_001__47041539_82805.45-- From owner-seamoby@diameter.org Mon Oct 22 07:05:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10640 for ; Mon, 22 Oct 2001 07:05:31 -0400 (EDT) Received: (qmail 23523 invoked by alias); 22 Oct 2001 10:47:58 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 23517 invoked by uid 200); 22 Oct 2001 10:47:57 -0000 Received: (qmail 23507 invoked from network); 22 Oct 2001 10:47:55 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 22 Oct 2001 10:47:55 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10374; Mon, 22 Oct 2001 07:03:08 -0400 (EDT) Message-Id: <200110221103.HAA10374@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-guri-seamoby-paging-triggers-00.txt Date: Mon, 22 Oct 2001 07:03:08 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Layer-2 API for Paging Author(s) : S. Gurivireddy et al. Filename : draft-guri-seamoby-paging-triggers-00.txt Pages : 8 Date : 19-Oct-01 This draft defines a layer-2 API in C-language for IP paging. API is presented in the form of callback functions. Whenever a significant event takes place in layer-2, upper layers are notified using triggers, which can be implemented using callback functions. Network and upper layer protocols can use these callbacks to fine tune layer-3 protocols. Paging API defines callback functions for dormant mode related information, sent from layer-2 to layer-3. API also defines a set of attributes, which define static properties of the underlying network. Each layer-2 technology may use this hierarchy to specify its properties and limitations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-guri-seamoby-paging-triggers-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-guri-seamoby-paging-triggers-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-guri-seamoby-paging-triggers-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: <20011019141245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-guri-seamoby-paging-triggers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-guri-seamoby-paging-triggers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011019141245.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Tue Oct 23 12:10:13 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09400 for ; Tue, 23 Oct 2001 12:10:13 -0400 (EDT) Received: (qmail 29367 invoked by alias); 23 Oct 2001 15:53:46 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 29361 invoked by uid 200); 23 Oct 2001 15:53:46 -0000 Received: (qmail 29356 invoked by uid 500); 23 Oct 2001 15:53:44 -0000 Date: Tue, 23 Oct 2001 08:53:44 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] New mailing list policy Message-ID: <20011023085344.F28987@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk At the request of many folks, I have changed the mailing list policy to only allow subscribers to post to the list. This will effectively eliminate all spam on this list (most of which has been quite offensive recently). Of course, the side effect is that if you attempt to send an e-mail from an account other than the one you have subscibed to, your e-mail will not be sent to the list. If you have any concerns/questions, please let me know. PatC From owner-seamoby@diameter.org Tue Oct 23 18:20:01 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21590 for ; Tue, 23 Oct 2001 18:20:00 -0400 (EDT) Received: (qmail 30665 invoked by alias); 23 Oct 2001 22:04:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 30659 invoked by uid 200); 23 Oct 2001 22:04:02 -0000 Received: (qmail 30654 invoked by uid 500); 23 Oct 2001 22:04:00 -0000 Date: Tue, 23 Oct 2001 15:04:00 -0700 From: Pat Calhoun To: seamoby@cdma-2000.org Subject: [seamoby] test Message-ID: <20011023150400.I30085@charizard.diameter.org> Mail-Followup-To: seamoby@cdma-2000.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-seamoby@diameter.org Precedence: bulk please ignore - testing new filtering rule PatC From owner-seamoby@diameter.org Tue Oct 23 18:46:36 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21928 for ; Tue, 23 Oct 2001 18:46:36 -0400 (EDT) Received: (qmail 31386 invoked by alias); 23 Oct 2001 22:30:19 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31380 invoked by uid 200); 23 Oct 2001 22:30:18 -0000 Received: (qmail 31375 invoked from network); 23 Oct 2001 22:30:17 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 23 Oct 2001 22:30:17 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9NMjEj00219 for ; Tue, 23 Oct 2001 15:45:14 -0700 (PDT) Message-ID: <027501c15c14$a377e710$2b6015ac@DOCOMOKEMPF> From: "James kempf" To: Subject: [seamoby] New CT Problem Statement Date: Tue, 23 Oct 2001 15:47:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0272_01C15BD9.F70538F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0272_01C15BD9.F70538F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I've sent a new version of the CT problem statement=20 (draft-ietf-seamoby-context-transfer-problem-stat-03.txt) to the Internet Drafts editor. This version addresses the comments from=20 the IESG last call. Many thanx to Gary for transferring the context (pun intended) from the CT design team = discussions during the preparation of this version. jak ------=_NextPart_000_0272_01C15BD9.F70538F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Folks,

 I've sent a new version of the CT = problem=20 statement
(draft-ietf-seamoby-context-transfer-problem-stat-03.txt)=20 to
 the Internet Drafts editor. This version  addresses the = comments from 
 the IESG last call. Many thanx to
Gary = for=20 transferring the context (pun intended) from the CT design team =
discussions=20 during the preparation of this=20 version.

         &nb= sp;    =20 jak
------=_NextPart_000_0272_01C15BD9.F70538F0-- From owner-seamoby@diameter.org Thu Oct 25 07:04:55 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13317 for ; Thu, 25 Oct 2001 07:04:54 -0400 (EDT) Received: (qmail 3874 invoked by alias); 25 Oct 2001 10:47:31 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3868 invoked by uid 200); 25 Oct 2001 10:47:31 -0000 Received: (qmail 3863 invoked from network); 25 Oct 2001 10:47:28 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Oct 2001 10:47:28 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13116; Thu, 25 Oct 2001 07:02:55 -0400 (EDT) Message-Id: <200110251102.HAA13116@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: seamoby@cdma-2000.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-context-transfer-problem-stat-03.txt Date: Thu, 25 Oct 2001 07:02:55 -0400 Sender: owner-seamoby@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting Working Group of the IETF. Title : Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network Author(s) : J. Kempf Filename : draft-ietf-seamoby-context- transfer-problem-stat-03.txt Pages : 12 Date : 24-Oct-01 In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain routing-related services on subnets that are left behind when the host moves. Examples of such services are AAA, header compression, and QoS. In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called 'context transfer'. This document discusses the desirability of context transfer for facilitating seamless IP mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-seamoby-context-transfer-problem-stat-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011024104055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-seamoby-context-transfer-problem-stat-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011024104055.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-seamoby@diameter.org Thu Oct 25 19:58:52 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02510 for ; Thu, 25 Oct 2001 19:58:52 -0400 (EDT) Received: (qmail 5724 invoked by alias); 25 Oct 2001 23:42:33 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 5718 invoked by uid 200); 25 Oct 2001 23:42:33 -0000 Received: (qmail 5713 invoked from network); 25 Oct 2001 23:42:30 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Oct 2001 23:42:30 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9PNvXj11358 for ; Thu, 25 Oct 2001 16:57:33 -0700 (PDT) Message-ID: <022801c15db1$13cafff0$2b6015ac@DOCOMOKEMPF> From: "James kempf" To: Subject: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt Date: Thu, 25 Oct 2001 16:59:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0225_01C15D76.67617990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0225_01C15D76.67617990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, Working Group Last Call on = draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, = Oct. 26, and runs for two weeks until Nov. 9. Please submit comments to the list before Nov. 9. jak ------=_NextPart_000_0225_01C15D76.67617990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
Working Group Last Call on=20 draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, = Oct.=20 26, and runs for two weeks until Nov. 9. Please submit = comments
to the list before Nov. 9.
 
       =20            =20 jak
------=_NextPart_000_0225_01C15D76.67617990-- From owner-seamoby@diameter.org Fri Oct 26 01:54:43 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11629 for ; Fri, 26 Oct 2001 01:54:42 -0400 (EDT) Received: (qmail 6911 invoked by alias); 26 Oct 2001 05:38:08 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6905 invoked by uid 200); 26 Oct 2001 05:38:08 -0000 Received: (qmail 6900 invoked from network); 26 Oct 2001 05:38:06 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Oct 2001 05:38:06 -0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9Q5sEA06295 for ; Fri, 26 Oct 2001 08:54:15 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 08:53:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 26 Oct 2001 08:53:28 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D8EDB@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: kempf@docomolabs-usa.com, seamoby@diameter.org Subject: RE: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-pr oblem-stat-03.txt Date: Fri, 26 Oct 2001 08:53:21 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15DE2.84FC38DE" Sender: owner-seamoby@diameter.org 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_01C15DE2.84FC38DE Content-Type: text/plain; charset="iso-8859-1" Hi James, Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments to the list before Nov. 9. Could you summarize the changes to the draft, it would make it easier to see what has changed. John ------_=_NextPart_001_01C15DE2.84FC38DE Content-Type: text/html; charset="iso-8859-1"
Hi James,
 
Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments to the list before Nov. 9. 
 
Could you summarize the changes to the draft, it would make it easier to see what has changed.
 
John 
------_=_NextPart_001_01C15DE2.84FC38DE-- From owner-seamoby@diameter.org Fri Oct 26 11:50:32 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07934 for ; Fri, 26 Oct 2001 11:50:30 -0400 (EDT) Received: (qmail 8470 invoked by alias); 26 Oct 2001 15:33:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 8464 invoked by uid 200); 26 Oct 2001 15:33:25 -0000 Received: (qmail 8459 invoked from network); 26 Oct 2001 15:33:24 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Oct 2001 15:33:24 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9QFmPj11119; Fri, 26 Oct 2001 08:48:25 -0700 (PDT) Message-ID: <004c01c15e35$ea1077f0$2b6015ac@DOCOMOKEMPF> From: "James kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D8EDB@esebe004.NOE.Nokia.com> Subject: Re: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt Date: Fri, 26 Oct 2001 08:50:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C15DFB.3D9935F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C15DFB.3D9935F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John, Could you summarize the changes to the draft, it would make it easier = to see what has changed. 1) Added three very specific examples of cases where context transfer = would be desirable and discussed the negative consequences of not having context transfer, as = a way of strongly motivating the work. 2) Condensed sections 8 through 10 into a single section discussing = cases where context transfer may not be necessary or may be of limited utility. 3) Added a problem scope section describing exactly what the scope of = the context transfer=20 problem statement is. 4) Changed terminology to match the revisions suggested by the IESG = review comments. Hope that helps. jak ------=_NextPart_000_0049_01C15DFB.3D9935F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi John,
 
Could you summarize the changes to the draft, it = would make=20 it easier to see what has = changed.
 
1) Added=20 three very specific examples of cases where context transfer would be=20 desirable and
discussed=20 the negative consequences of not having context transfer, as a way of = strongly=20 motivating the work.
 
2) Condensed=20 sections 8 through 10 into a single section discussing cases where = context=20 transfer
may not be=20 necessary or may be of limited utility.
 
3) Added a=20 problem scope section describing exactly what the scope of the context = transfer
problem=20 statement is.
 
4) Changed=20 terminology to match the revisions suggested by the IESG review=20 comments.
 
Hope that=20 helps.
 
       =20     = jak
------=_NextPart_000_0049_01C15DFB.3D9935F0-- From owner-seamoby@diameter.org Fri Oct 26 12:36:00 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09750 for ; Fri, 26 Oct 2001 12:35:59 -0400 (EDT) Received: (qmail 9088 invoked by alias); 26 Oct 2001 16:19:44 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 9082 invoked by uid 200); 26 Oct 2001 16:19:44 -0000 Received: (qmail 9074 invoked from network); 26 Oct 2001 16:19:42 -0000 Received: from mailhost.iprg.nokia.com (205.226.5.12) by c900656-a.plstn1.sfba.home.com with SMTP; 26 Oct 2001 16:19:42 -0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08560; Fri, 26 Oct 2001 09:34:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f9QGYlD04460; Fri, 26 Oct 2001 09:34:47 -0700 X-mProtect: Fri, 26 Oct 2001 09:34:47 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdARJU09; Fri, 26 Oct 2001 09:34:45 PDT Message-ID: <3BD990A6.346E596D@iprg.nokia.com> Date: Fri, 26 Oct 2001 09:34:46 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James kempf CC: Seamless Mobility Working Group , Pat Calhoun Subject: [seamoby] Terminology document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Jim, Your point: > 4) Changed terminology to match the revisions suggested by the IESG review comments. prompts me to ask whether the terminology draft, submitted earlier this year to [seamoby], is to be considered useful. If so, I would request that it should become a working-group document, and I will volunteer to keep it updated according to the needs of documents such as the one under discussion here. The URL for the current document is: http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-02.txt Regards, Charlie P. From owner-seamoby@diameter.org Sun Oct 28 18:52:24 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17069 for ; Sun, 28 Oct 2001 18:52:24 -0500 (EST) Received: (qmail 18139 invoked by alias); 28 Oct 2001 23:35:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 18132 invoked by uid 200); 28 Oct 2001 23:35:49 -0000 Received: (qmail 18122 invoked by uid 500); 28 Oct 2001 23:35:47 -0000 Date: Sun, 28 Oct 2001 15:35:47 -0800 From: Pat Calhoun To: "Charles E. Perkins" Cc: James kempf , Seamless Mobility Working Group , Pat Calhoun Subject: Re: [seamoby] Terminology document Message-ID: <20011028153547.A18109@charizard.diameter.org> Mail-Followup-To: "Charles E. Perkins" , James kempf , Seamless Mobility Working Group , Pat Calhoun References: <3BD990A6.346E596D@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BD990A6.346E596D@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Oct 26, 2001 at 09:34:46AM -0700 Sender: owner-seamoby@diameter.org Precedence: bulk Somehow this topic got lost. Let me check again. PatC On Fri, Oct 26, 2001 at 09:34:46AM -0700, Charles E. Perkins wrote: > > Hello Jim, > > Your point: > > > 4) Changed terminology to match the revisions suggested by the IESG review comments. > > prompts me to ask whether the terminology draft, submitted earlier this > year to [seamoby], is to be considered useful. If so, I would request > that it should become a working-group document, and I will volunteer to > keep it updated according to the needs of documents such as the one > under discussion here. > > The URL for the current document is: > http://search.ietf.org/internet-drafts/draft-manner-seamoby-terms-02.txt > > Regards, > Charlie P. From owner-seamoby@diameter.org Mon Oct 29 05:43:22 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08293 for ; Mon, 29 Oct 2001 05:43:22 -0500 (EST) Received: (qmail 20433 invoked by alias); 29 Oct 2001 10:25:39 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 20427 invoked by uid 200); 29 Oct 2001 10:25:38 -0000 Received: (qmail 20422 invoked from network); 29 Oct 2001 10:25:36 -0000 Received: from mail.rsasecurity.com (HELO tholian.securitydynamics.com) (204.167.112.129) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Oct 2001 10:25:36 -0000 Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for c900656-a.plstn1.sfba.home.com [24.20.167.220]) with SMTP; 29 Oct 2001 10:37:47 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id FAA19409 for ; Mon, 29 Oct 2001 05:41:11 -0500 (EST) Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id FAA08272 for ; Mon, 29 Oct 2001 05:41:10 -0500 (EST) Received: from sjosefsson-pc.d.dynas.se ([172.16.13.115]) by exno02.dynas.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V47A13F1; Mon, 29 Oct 2001 11:41:03 +0100 To: seamoby@diameter.org Subject: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt References: <022801c15db1$13cafff0$2b6015ac@DOCOMOKEMPF> From: Simon Josefsson Reply-To: Simon Josefsson Date: Mon, 29 Oct 2001 11:43:45 +0100 In-Reply-To: <022801c15db1$13cafff0$2b6015ac@DOCOMOKEMPF> ("James kempf"'s message of "Thu, 25 Oct 2001 23:59:26 GMT") Message-ID: Lines: 44 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-seamoby@diameter.org Precedence: bulk "James kempf" writes: > Folks, > > Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments > to the list before Nov. 9. I am new to this group and have not followed the development of this draft, and my concerns may be specific to 802.11 Wireless LANs and when the context includes encryption keying material, but nevertheless I have a comment on the security considerations: Even when context transfers between network entities (access points in 802.11 terminology) are secured via IPSEC or similar, I believe the complete system is less secure than compared with when context transfer is not used, and instead one backend server handles roaming which sends the necessary context (including encryption keys) to each access point. The reasons is that, if one of the access points is compromised, the context received may be used to sniff the network even after the mobile node left the compromised network entity. Compromising a access point when context transfer is not used does not make this possible. So the system security has been reduced from having the backend server a single-point-of-failure to having multiple-point-of-failures, the security is reduced 1:N. If you agree (discussion welcome), I'd suggest that something like the following text is added to the security considerations: The compromise of only one of the network entities that contain context may be sufficient to reduce the security of the whole system, if for example the context includes encryption keying material. When the host moves from the compromised network entity to a uncompromised network entity, the compromised context may be used to decrypt the communication channel. When context transfer is not used, a compromise of only one network entity only gives access to what that network entity can see. This means that network entities must have similar physical and software protection as the backend server. -- Simon Josefsson RSA Security From owner-seamoby@diameter.org Mon Oct 29 06:14:24 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08461 for ; Mon, 29 Oct 2001 06:14:24 -0500 (EST) Received: (qmail 21276 invoked by alias); 29 Oct 2001 10:57:59 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21270 invoked by uid 200); 29 Oct 2001 10:57:59 -0000 Received: (qmail 21265 invoked from network); 29 Oct 2001 10:57:57 -0000 Received: from mgw-x2.nokia.com (131.228.20.22) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Oct 2001 10:57:57 -0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9TBEIA15888 for ; Mon, 29 Oct 2001 13:14:18 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Oct 2001 13:13:36 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 29 Oct 2001 13:13:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D8F1A@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: sjosefsson@rsasecurity.com, seamoby@diameter.org Subject: RE: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfe r-problem-stat-03.txt Date: Mon, 29 Oct 2001 13:12:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-seamoby@diameter.org Precedence: bulk Hi Simon, > The compromise of only one of the network entities that contain > context may be sufficient to reduce the security of the whole > system, if for example the context includes encryption keying > material. When the host moves from the compromised network > entity to a uncompromised network entity, the compromised > context may be used to decrypt the communication channel. When > context transfer is not used, a compromise of only one network > entity only gives access to what that network entity can see. > This means that network entities must have similar physical > and software protection as the backend server. I think that this is a good point. I think that the last sentence may be a bit strong, since this document is only a problem statement. Perhaps leaving the final statement out, but moving it to the Context Transfer Requirements document might make more sense. best regards, John From owner-seamoby@diameter.org Mon Oct 29 06:48:40 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08783 for ; Mon, 29 Oct 2001 06:48:39 -0500 (EST) Received: (qmail 21838 invoked by alias); 29 Oct 2001 11:32:05 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 21832 invoked by uid 200); 29 Oct 2001 11:32:05 -0000 Received: (qmail 21827 invoked from network); 29 Oct 2001 11:32:03 -0000 Received: from mail.rsasecurity.com (HELO tholian.securitydynamics.com) (204.167.112.129) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Oct 2001 11:32:03 -0000 Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for c900656-a.plstn1.sfba.home.com [24.20.167.220]) with SMTP; 29 Oct 2001 11:44:13 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id GAA22209; Mon, 29 Oct 2001 06:47:40 -0500 (EST) Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.9.3+Sun/8.9.1) with ESMTP id GAA11186; Mon, 29 Oct 2001 06:47:39 -0500 (EST) Received: from sjosefsson-pc.d.dynas.se ([172.16.13.115]) by exno02.dynas.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V47A13HP; Mon, 29 Oct 2001 12:47:32 +0100 To: john.loughney@nokia.com Cc: seamoby@diameter.org Subject: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfe r-problem-stat-03.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D8F1A@esebe004.NOE.Nokia.com> From: Simon Josefsson Reply-To: Simon Josefsson Date: Mon, 29 Oct 2001 12:50:14 +0100 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D8F1A@esebe004.NOE.Nokia.com> (john.loughney@nokia.com's message of "Mon, 29 Oct 2001 11:12:52 GMT") Message-ID: Lines: 23 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-seamoby@diameter.org Precedence: bulk john.loughney@nokia.com writes: > Hi Simon, > >> The compromise of only one of the network entities that contain >> context may be sufficient to reduce the security of the whole >> system, if for example the context includes encryption keying >> material. When the host moves from the compromised network >> entity to a uncompromised network entity, the compromised >> context may be used to decrypt the communication channel. When >> context transfer is not used, a compromise of only one network >> entity only gives access to what that network entity can see. >> This means that network entities must have similar physical >> and software protection as the backend server. > > I think that this is a good point. I think that the last sentence > may be a bit strong, since this document is only a problem statement. > Perhaps leaving the final statement out, but moving it to the > Context Transfer Requirements document might make more sense. I agree, leaving the last sentence out is more appropriate. /Simon From owner-seamoby@diameter.org Mon Oct 29 11:54:11 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19576 for ; Mon, 29 Oct 2001 11:54:10 -0500 (EST) Received: (qmail 22982 invoked by alias); 29 Oct 2001 16:36:36 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 22976 invoked by uid 200); 29 Oct 2001 16:36:35 -0000 Received: (qmail 22968 invoked from network); 29 Oct 2001 16:36:33 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Oct 2001 16:36:33 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9TGpkj21549; Mon, 29 Oct 2001 08:51:46 -0800 (PST) Message-ID: <006d01c1609a$42fc5df0$2b6015ac@DOCOMOKEMPF> From: "James kempf" To: "Simon Josefsson" , References: <022801c15db1$13cafff0$2b6015ac@DOCOMOKEMPF> Subject: Re: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt Date: Mon, 29 Oct 2001 08:53:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon, > I am new to this group and have not followed the development of this > draft, and my concerns may be specific to 802.11 Wireless LANs and > when the context includes encryption keying material, but nevertheless > I have a comment on the security considerations: > > Even when context transfers between network entities (access points in > 802.11 terminology) are secured via IPSEC or similar, I believe the Actually, it would be access routers, not access points. Context transfer is really only necessary when the mobile node moves between subnets. Any intrasubnet movement should be handled by the L2 protocol, which is IAPP in 802.11. > complete system is less secure than compared with when context > transfer is not used, and instead one backend server handles roaming > which sends the necessary context (including encryption keys) to each > access point. > > The reasons is that, if one of the access points is compromised, the > context received may be used to sniff the network even after the > mobile node left the compromised network entity. Compromising a > access point when context transfer is not used does not make this > possible. So the system security has been reduced from having the > backend server a single-point-of-failure to having > multiple-point-of-failures, the security is reduced 1:N. > Good point. However, I think the issue is somewhat mitigated by the fact that if an access router is compromised, then the attacker can also inject false routes into the network, and thus start stealing traffic in a major way. This threat is there regardless of whether context transfer is implemented or not. So, to the extent that context transfer security can leverage off the necessary routing security, the practical implications of the threat are perhaps less serious than they seem on the surface. > If you agree (discussion welcome), I'd suggest that something like the > following text is added to the security considerations: > > The compromise of only one of the network entities that contain > context may be sufficient to reduce the security of the whole > system, if for example the context includes encryption keying > material. When the host moves from the compromised network > entity to a uncompromised network entity, the compromised > context may be used to decrypt the communication channel. When > context transfer is not used, a compromise of only one network > entity only gives access to what that network entity can see. > This means that network entities must have similar physical > and software protection as the backend server. > I will add this text, modulo something about using routing security to mitigate the threat, unless there are any objections. jak From owner-seamoby@diameter.org Tue Oct 30 16:33:26 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15223 for ; Tue, 30 Oct 2001 16:33:20 -0500 (EST) Received: (qmail 31067 invoked by alias); 30 Oct 2001 21:15:52 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 31061 invoked by uid 200); 30 Oct 2001 21:15:52 -0000 Received: (qmail 31056 invoked from network); 30 Oct 2001 21:15:50 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Oct 2001 21:15:50 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9ULV9j19544 for ; Tue, 30 Oct 2001 13:31:09 -0800 (PST) Message-ID: <021001c1618a$74a5d250$2b6015ac@DOCOMOKEMPF> From: "James Kempf" To: Subject: [seamoby] Last Call Comments on CT Requirements Draft Date: Tue, 30 Oct 2001 13:33:03 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020D_01C16147.6677E3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_020D_01C16147.6677E3F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The last call period for the CT Requirements Draft has expired. Gary = will be incorporating the comments posted to the list during the last = call period into the draft, in order to obtain a new version by the Nov. = 16 draft deadline. jak ------=_NextPart_000_020D_01C16147.6677E3F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The last call period for the CT = Requirements Draft=20 has expired. Gary will be incorporating the comments posted to the = list=20 during the last call period into the draft, in order to obtain a new = version by=20 the Nov. 16 draft deadline.
 
       =20 jak
------=_NextPart_000_020D_01C16147.6677E3F0-- From owner-seamoby@diameter.org Wed Oct 31 09:49:00 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20521 for ; Wed, 31 Oct 2001 09:48:59 -0500 (EST) Received: (qmail 1067 invoked by alias); 31 Oct 2001 14:32:02 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 1060 invoked by uid 200); 31 Oct 2001 14:32:02 -0000 Received: (qmail 1055 invoked from network); 31 Oct 2001 14:32:00 -0000 Received: from prue.eim.surrey.ac.uk (exim@131.227.76.5) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 14:32:00 -0000 Received: from haskins.ee.surrey.ac.uk ([131.227.89.14] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15ywec-0000R0-00 for seamoby@cdma-2000.org; Wed, 31 Oct 2001 14:47:42 +0000 Received: from eep2kc (helo=localhost) by haskins.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15yweX-0001y6-00 for seamoby@cdma-2000.org; Wed, 31 Oct 2001 14:47:37 +0000 Date: Wed, 31 Oct 2001 14:47:36 +0000 (GMT) From: Kar Ann Chew X-Sender: eep2kc@haskins.ee.surrey.ac.uk To: seamoby@cdma-2000.org Subject: [seamoby] drafts on paging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15ywec-0000R0-00*h9CA.njdM6.* http://duncanthrax.net/exiscan/ Sender: owner-seamoby@diameter.org Precedence: bulk Hi, I understood that there are four candidates for IP paging, being compared by the WG. Could some one please give me pointers to the drafts? Thanks in advance. Regards, Karann ++++++++++++++++++++++++++++++++++++++++++ Karann Chew Mobile Communications Research Group Centre for Communication Systems Research University of Surrey, Guildford Surrey GU2 7XH, United Kingdom Tel: +44 (0) 1483-879488 Fax: +44 (0) 1483-876011 ++++++++++++++++++++++++++++++++++++++++++ From owner-seamoby@diameter.org Wed Oct 31 12:17:05 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24942 for ; Wed, 31 Oct 2001 12:17:03 -0500 (EST) Received: (qmail 2224 invoked by alias); 31 Oct 2001 16:59:50 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2218 invoked by uid 200); 31 Oct 2001 16:59:50 -0000 Received: (qmail 2213 invoked from network); 31 Oct 2001 16:59:48 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 16:59:48 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA10415 for ; Wed, 31 Oct 2001 10:06:38 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA17171 for ; Wed, 31 Oct 2001 10:15:33 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Oct 2001 11:15:33 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA140@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James kempf'" , seamoby@diameter.org Subject: RE: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-pr oblem-stat-03.txt Date: Wed, 31 Oct 2001 11:15:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1622F.A26BE710" Sender: owner-seamoby@diameter.org 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_01C1622F.A26BE710 Content-Type: text/plain; charset="iso-8859-1" James, I liked the problem statement 03 a lot. Looks mature and informative. Just one comment on section 4 (the need for context transfer): Although not an initial motivator and not a driver for protocol design, "Network failover" was mentioned as a potential use for context transfer in the future. I thought, it might make the case stronger. Madjid -----Original Message----- From: James kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, October 25, 2001 6:59 PM To: seamoby@diameter.org Subject: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt Folks, Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments to the list before Nov. 9. jak ------_=_NextPart_001_01C1622F.A26BE710 Content-Type: text/html; charset="iso-8859-1"
James,
 
I liked the problem statement 03 a lot. Looks mature and informative.
 
Just one comment on section 4 (the need for context transfer):
 
Although not an initial motivator and not a driver for protocol design,
"Network failover" was mentioned as a potential use for context transfer
in the future.
 
I thought, it might make the case stronger. 
 
Madjid
-----Original Message-----
From: James kempf [mailto:kempf@docomolabs-usa.com]
Sent: Thursday, October 25, 2001 6:59 PM
To: seamoby@diameter.org
Subject: [seamoby] Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt

Folks,
 
Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments
to the list before Nov. 9.
 
                    jak
------_=_NextPart_001_01C1622F.A26BE710-- From owner-seamoby@diameter.org Wed Oct 31 12:31:48 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25215 for ; Wed, 31 Oct 2001 12:31:47 -0500 (EST) Received: (qmail 2793 invoked by alias); 31 Oct 2001 17:15:26 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 2787 invoked by uid 200); 31 Oct 2001 17:15:25 -0000 Received: (qmail 2782 invoked from network); 31 Oct 2001 17:15:24 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 17:15:24 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9VHU8j19027; Wed, 31 Oct 2001 09:30:08 -0800 (PST) Message-ID: <009201c16231$f4afb540$2b6015ac@DOCOMOKEMPF> From: "James Kempf" To: "Kar Ann Chew" , References: Subject: Re: [seamoby] drafts on paging Date: Wed, 31 Oct 2001 09:32:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-kooldi-paging-00.txt draft-ohba-seamoby-last-hop-dmha-02.txt draft-sarikaya-seamoby-confmipv6hp-00.txt, draft-sarikaya-seamoby-miv6hp-00.txt, draft-guri-seamoby-lahap-00.txt, draft-guri-seamoby-conflahap-00.txt (counted as one proposal) draft-renker-paging-ipv6-01.txt jak From owner-seamoby@diameter.org Wed Oct 31 12:34:43 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25272 for ; Wed, 31 Oct 2001 12:34:42 -0500 (EST) Received: (qmail 3043 invoked by alias); 31 Oct 2001 17:16:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 3037 invoked by uid 200); 31 Oct 2001 17:16:05 -0000 Received: (qmail 3022 invoked from network); 31 Oct 2001 17:16:03 -0000 Received: from motgate4.mot.com (144.189.100.102) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 17:16:03 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA16680 for ; Wed, 31 Oct 2001 10:31:54 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA00337 for ; Wed, 31 Oct 2001 10:31:53 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0BYAN2>; Wed, 31 Oct 2001 11:31:53 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA141@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Simon Josefsson'" , seamoby@diameter.org Subject: RE: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfe r-problem-stat-03.txt Date: Wed, 31 Oct 2001 11:31:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hi Simon, See my comments in line: -----Original Message----- From: Simon Josefsson [mailto:sjosefsson@dynas.se] Sent: Monday, October 29, 2001 4:44 AM To: seamoby@diameter.org Subject: [seamoby] Re: Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt "James kempf" writes: > Folks, > > Working Group Last Call on draft-ietf-seamoby-context-transfer-problem-stat-03.txt starts tomorrow, Oct. 26, and runs for two weeks until Nov. 9. Please submit comments > to the list before Nov. 9. I am new to this group and have not followed the development of this draft, and my concerns may be specific to 802.11 Wireless LANs and when the context includes encryption keying material, but nevertheless I have a comment on the security considerations: Even when context transfers between network entities (access points in 802.11 terminology) are secured via IPSEC or similar, I believe the complete system is less secure than compared with when context transfer is not used, and instead one backend server handles roaming which sends the necessary context (including encryption keys) to each access point. Madjid>> Centralized context servers, versus context tranfer between ARs was discussed early on and I don't want to get into pros and cons of it. Madjid>>Just in this case, you would still have a problem when the MN moves between administrative domains using separate policy/authentication... servers. And this is general AAA, security, key management issues with lots of things involved such as AAA brokers, CAs , you name it. Madjid>>We need to secure the context transfer channel propoerly to not compromise the information (including the keys) going through. Unless you are completely against context transfer. The reasons is that, if one of the access points is compromised, the context received may be used to sniff the network even after the mobile node left the compromised network entity. Compromising a access point when context transfer is not used does not make this possible. So the system security has been reduced from having the backend server a single-point-of-failure to having multiple-point-of-failures, the security is reduced 1:N. If you agree (discussion welcome), I'd suggest that something like the following text is added to the security considerations: The compromise of only one of the network entities that contain context may be sufficient to reduce the security of the whole system, if for example the context includes encryption keying material. When the host moves from the compromised network entity to a uncompromised network entity, the compromised context may be used to decrypt the communication channel. When context transfer is not used, a compromise of only one network entity only gives access to what that network entity can see. This means that network entities must have similar physical and software protection as the backend server. Madjid>> 1- I agree with James, it is access routers not access points. 2- we are dealing with a communications security problem, not a storage security problem, are we not? We need to secure the communication of context, not how securely it stored, that is the issue of access security. Secure storage of keying material is not limited to context transfer. 3- context transfer is intended to happen between ARs, how it is gathered at old AR, and how the old context is dumped at old AR after transfer, was defined as out of scope. Again, I don't quite see this as a problem for context transfer, but rather a context storage problem. Are you advocating a more secure context transfer, or more secure storage of keying material used for context transfer? Hope this is not too far out in the woods, Madjid -- Simon Josefsson RSA Security From owner-seamoby@diameter.org Wed Oct 31 16:04:20 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01857 for ; Wed, 31 Oct 2001 16:04:19 -0500 (EST) Received: (qmail 6080 invoked by alias); 31 Oct 2001 20:47:24 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6074 invoked by uid 200); 31 Oct 2001 20:47:24 -0000 Received: (qmail 6069 invoked from network); 31 Oct 2001 20:47:22 -0000 Received: from motgate3.mot.com (144.189.100.103) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 20:47:22 -0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA12466 for ; Wed, 31 Oct 2001 13:54:13 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA17391 for ; Wed, 31 Oct 2001 14:03:09 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 31 Oct 2001 15:03:09 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA14B@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , seamoby@diameter.org Subject: RE: [seamoby] Questions on CAR Discovery Problem Statement? Date: Wed, 31 Oct 2001 15:03:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Hi, Not sure if I have missed the deadline or not. Can't say I have a problem with this work item, just a few comments about the draft: 1- I am glad to see that Capability discovery is mentioned here. Recognizing the relationship between capability and CAR discovery is important. 2- I agree that the work of algorithm development for TAR selection is out of scope, since the algorithm will depend on the selection criteria such as network policy and MN/ network preference. However, I don't think the selection of CAR is entirely out of scope, given the algorithm, there still need to be a protocol in place, which I think this work item is trying to define. 3-Why the terminolgy of "anticipated v.s. dynamic" is used for "network assisted" v.s. "MN centric" CAR discovery. The distinction being made in the draft is based on the unit that is doing the work, and some temporal aspects but not all such as static v.s. dynamic capabilities. Let me explain: In 4.2 you do talk about capabilities such QoS, security... as inputs to selection algorithm. Some of these inputs are more static, such as QoS profiles, PHBs, security policies and so on, while some of the inputs are more dynamic such as current state of the congestion, bandwidth allocation in the network, and maybe even some fading on signal strength. The more dynamic aspects would still need to be used as input. So when you say dynamic CAR selection, I can't help it. I think about the dynamic capability discovery. Just my 2 cents (2/3 cents per comment :) ) Keep up the good work, Madjid -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Friday, October 12, 2001 2:14 PM To: seamoby@diameter.org Cc: kempf42@yahoo.com Subject: [seamoby] Questions on CAR Discovery Problem Statement? Folks, The CAR discovery problem statement is currently in last call. At IETF 51 in London, I vaguely recall after Govind's presentation hearing that some WG members were uncertain why CAR discovery was necessary. The current problem statement attempts to address this question more directly than the original did. I hope those of you who had this question will read the problem statement and submit any further questions to the list. In addition, if anybody has any further issues with the problem statement, now is your chance to raise them. Thanx. jak From owner-seamoby@diameter.org Wed Oct 31 16:17:06 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02220 for ; Wed, 31 Oct 2001 16:17:05 -0500 (EST) Received: (qmail 6641 invoked by alias); 31 Oct 2001 21:00:06 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 6635 invoked by uid 200); 31 Oct 2001 21:00:06 -0000 Received: (qmail 6630 invoked from network); 31 Oct 2001 21:00:05 -0000 Received: from motgate.mot.com (129.188.136.100) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 21:00:05 -0000 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA27453 for ; Wed, 31 Oct 2001 14:15:57 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA05595 for ; Wed, 31 Oct 2001 14:15:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <4KW5NW3W>; Wed, 31 Oct 2001 15:15:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017AA14C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: seamoby@diameter.org Subject: RE: [seamoby] Questions on CAR Discovery Problem Statement? Date: Wed, 31 Oct 2001 15:15:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-seamoby@diameter.org Precedence: bulk Sorry one more comment (now 0.5 cents/ per comments :) ) In the section 4.1 on refuting manual configuration of routers, you forgot to mention networks with mobile routers as another place manual configuration would not work very well. Madjid -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Wednesday, October 31, 2001 3:03 PM To: 'James Kempf'; seamoby@diameter.org Subject: RE: [seamoby] Questions on CAR Discovery Problem Statement? Hi, Not sure if I have missed the deadline or not. Can't say I have a problem with this work item, just a few comments about the draft: 1- I am glad to see that Capability discovery is mentioned here. Recognizing the relationship between capability and CAR discovery is important. 2- I agree that the work of algorithm development for TAR selection is out of scope, since the algorithm will depend on the selection criteria such as network policy and MN/ network preference. However, I don't think the selection of CAR is entirely out of scope, given the algorithm, there still need to be a protocol in place, which I think this work item is trying to define. 3-Why the terminolgy of "anticipated v.s. dynamic" is used for "network assisted" v.s. "MN centric" CAR discovery. The distinction being made in the draft is based on the unit that is doing the work, and some temporal aspects but not all such as static v.s. dynamic capabilities. Let me explain: In 4.2 you do talk about capabilities such QoS, security... as inputs to selection algorithm. Some of these inputs are more static, such as QoS profiles, PHBs, security policies and so on, while some of the inputs are more dynamic such as current state of the congestion, bandwidth allocation in the network, and maybe even some fading on signal strength. The more dynamic aspects would still need to be used as input. So when you say dynamic CAR selection, I can't help it. I think about the dynamic capability discovery. Just my 2 cents (2/3 cents per comment :) ) Keep up the good work, Madjid -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Friday, October 12, 2001 2:14 PM To: seamoby@diameter.org Cc: kempf42@yahoo.com Subject: [seamoby] Questions on CAR Discovery Problem Statement? Folks, The CAR discovery problem statement is currently in last call. At IETF 51 in London, I vaguely recall after Govind's presentation hearing that some WG members were uncertain why CAR discovery was necessary. The current problem statement attempts to address this question more directly than the original did. I hope those of you who had this question will read the problem statement and submit any further questions to the list. In addition, if anybody has any further issues with the problem statement, now is your chance to raise them. Thanx. jak From owner-seamoby@diameter.org Wed Oct 31 16:27:56 2001 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03075 for ; Wed, 31 Oct 2001 16:27:55 -0500 (EST) Received: (qmail 7223 invoked by alias); 31 Oct 2001 21:10:56 -0000 Delivered-To: seamoby-list@charizard.diameter.org Received: (qmail 7217 invoked by uid 200); 31 Oct 2001 21:10:56 -0000 Received: (qmail 7212 invoked from network); 31 Oct 2001 21:10:55 -0000 Received: from fridge.docomo-usa.com (216.98.102.228) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Oct 2001 21:10:55 -0000 Received: from DOCOMOKEMPF (dhcp43.docomo-usa.com [172.21.96.43]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f9VLQGj28365; Wed, 31 Oct 2001 13:26:16 -0800 (PST) Message-ID: <01f001c16252$f0c817d0$2b6015ac@DOCOMOKEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "'James Kempf'" , References: <35DBB8B7AC89D4118E98009027B1009B017AA14B@IL27EXM10.cig.mot.com> Subject: Re: [seamoby] Questions on CAR Discovery Problem Statement? Date: Wed, 31 Oct 2001 13:28:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-seamoby@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Madjid, > Not sure if I have missed the deadline or not. > Can't say I have a problem with this work item, just > a few comments about the draft: > Well, you did miss the deadline, we were about to submit the revised draft to the IESG. But let's talk about your comments... > 1- I am glad to see that Capability discovery is mentioned here. > Recognizing the relationship between capability and CAR discovery is > important. > OK. > 2- I agree that the work of algorithm development for TAR selection > is out of scope, since the algorithm will depend on the selection > criteria such as network policy and MN/ network preference. > However, I don't think the selection of CAR is entirely out of scope, > given the algorithm, there still need to be a protocol in place, which > I think this work item is trying to define. > Is there anything that needs to be changed in the draft? As you say, the algorithm to select the TAR is a matter of implementation and configuration. With regard to selection of CARs, there may be a need for some alorithm, particularly with regard to evaluating geographical adjacency information or radio signal strength. But I think that is a separate issue and not something that needs to be defined in the protocol for exchanging capability and other information. I don't know if the WG wants to get into that or not. > 3-Why the terminolgy of "anticipated v.s. dynamic" is used for > "network assisted" v.s. "MN centric" CAR discovery. Well, we couldn't think of any other names. Anticipated implies that the information is on the router prior to the MN requiring a handover, it may or may not be updated dynamically. Dynamic was meant to imply that it may be exchanged during an actual handover. > The distinction being made in the draft is based on the unit that > is doing the work, and some temporal aspects but not all such > as static v.s. dynamic capabilities. Sure. There are static aspects of the dynamic case and dynamic aspects of anticipated. The MN could be gathering information all the time, then apply it just at handover. The issue is when the protocol would be used. If the protocol is being used at handover time, we have been calling it dynamic. If it is used prior to handover and doesn't involve the MN, then we've been calling it anticpated. > Let me explain: > > In 4.2 you do talk about capabilities such QoS, security... as inputs to > selection algorithm. Some of these inputs are more static, such > as QoS profiles, PHBs, security policies and so on, > while some of the inputs are more dynamic such as current state of the > congestion, bandwidth allocation in the network, and maybe even some > fading on signal strength. > > The more dynamic aspects would still need to be used as input. > So when you say dynamic CAR selection, I can't help it. I think > about the dynamic capability discovery. > If you have any suggestions for better names, please let us know. jak