From mext-bounces@ietf.org Sat Dec 01 00:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyL9q-0004jU-7R; Sat, 01 Dec 2007 00:44:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyL9p-0004eB-CV for mext@ietf.org; Sat, 01 Dec 2007 00:44:53 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyL9o-0001Ap-Gh for mext@ietf.org; Sat, 01 Dec 2007 00:44:53 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Nov 2007 21:44:51 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lB15iplh008144; Fri, 30 Nov 2007 21:44:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB15ij75026447; Sat, 1 Dec 2007 05:44:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 21:44:44 -0800 Received: from sgundavewxp ([10.21.95.17]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 21:44:42 -0800 From: "Sri Gundavelli" To: "'Vijay Devarapalli'" , "'Hannes Tschofenig'" , "'Alper Yegin'" , "'George Tsirtsis'" References: <0MKp8S-1IwdRx2OQq-0008Gc@mrelay.perfora.net> <474B12F7.8000700@azairenet.com> <474B2270.8080405@gmx.net> <474CA7BB.9000007@azairenet.com> Subject: RE: [MEXT] Prefix delegation & Diameter Interaction Date: Fri, 30 Nov 2007 21:44:32 -0800 Message-ID: <000001c833dd$4546dc80$4ff6700a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgxTQ4qTGnT1KY9QTCV7EeJzCqgPACi/g5g In-Reply-To: <474CA7BB.9000007@azairenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 01 Dec 2007 05:44:43.0577 (UTC) FILETIME=[4607E290:01C833DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6068; t=1196487891; x=1197351891; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20Prefix=20delegation=20&=20Diameter=20Interac tion |Sender:=20; bh=WSaoJvrfKJLhLhczCJZiRYTkradXESlvrgnF3y653+M=; b=P6kEo1gNNrsWrsH8Q6CnfORsoCuX+AZWGl+0VrcMZmlXYO/uGZrU3NduG3pnKJ2C5zrpZKrV 1+lv6tDIht24Guh2vQhqHDl9lFlVekTOen2tEwdaL/rd2unIYNRzz4mu; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vijay, > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: Tuesday, November 27, 2007 3:27 PM > To: Hannes Tschofenig; Alper Yegin; George Tsirtsis; Sri Gundavelli > Cc: mext@ietf.org > Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > > Hi Hannes, > > Here are some pointers to previous discussions. Took me some time > to find this. IETF archives are not designed for searching. > > - http://www1.ietf.org/mail-archive/web/mip6/current/msg06023.html > > This thread was about DHCP should be used to assign home address > from the NAS (access router). RADIUS/Diameter is used to deliver > the home address from the AAA to the NAS. > > - http://www1.ietf.org/mail-archive/web/mip6/current/msg06554.html > > This thread talks about AAA or the HA assigning a home address. > > - http://www1.ietf.org/mail-archive/web/netlmm/current/msg02515.html > > This thread was on the NETLMM mailing list. It was about AAA managing > prefixes for PMIPv6 instead of the LMA and the AAA delivering the > prefixes to the MAG. > > There was quite bit of discussion on this during the Prague meeting. > Mostly hallway discussions. Don't have pointers to that. This was > just after the WG last call for draft-ietf-mip6-hiopt. > > There might have been more, but can't spend any more time on this. > Sorry. Anyway, AFAIK, we have always concluded that the home agent > or some other entity on the home link (DHCP server) manages the > home addresses and the home prefixes. > > George, Sri, you guys had also sent emails asking for pointers. > Patience please. It takes quite a bit of time to search through > the archives. > Thanks for the pointers. The context of discussion in each of threads is bit different. Lets take the recent NETLMM discussion, the question was not about allowing AAA to do the address assignment, but on allowing other mobility entities to perform address allocation. But, again I'm not too keen on making AAA make that the HNP assignment. For the record I want to say that there was no consensus that HA should not offload the HoA/HNP management function. Personally, I'd prefer allowing home agent to offload this address management function to DHCP server. Functionally that is the right element for managing this aspect. We are looking at HA's to scale upto supporting millions of mobile nodes and for it to achieve these scalability goals, the service should be able to leverage other generic services and protocols such DHCP PD ..etc, designed for that one specific purpose. When the home link is a physical link and when in presence of stateless autoconf, HA is not truly assigning any address to the mobile node and some arguments in that context such as minimal MIP6 involvement in address assignment and so no external entity should be involved in address mgmt, when applied to Prefix assignment and in relation to virtual links, is totally different. The MIP6 entities are involved in the address mgmt function and now if it certainly use local pools, ODAP, DHCP ..etc. W.r.t AAA doing the prefix mgmt, I do not think, we can restrict this either, but I'm not to keen on this. There are already Attributes defined for this. http://www.ietf.org/rfc/rfc4818.txt. I'm not sure, what the draft is additionally proposing. Regards Sri > Vijay > > Hannes Tschofenig wrote: > > Hi Vijay, > > > > maybe you can provide some pointers to past discussions and > conclusions. > > You cannot expect that everyone follows all mailing lists > and now this > > work is being proposed for DIME. > > > > Ciao > > Hannes > > > > PS: I once had comments for a QoS document and I got the following > > response "I don't have time to give you a tutorial on this > QoS issue. We > > discussed this at length in face-to-face meeting at the > IETF XYZ meeting." > > > > The document got delayed for more than a year when the same > questions > > showed up later again.... > > > > Vijay Devarapalli wrote: > >> Alper Yegin wrote: > >>> Vijay, > >>> > >>> Can you explain why you do not recommend AAA-assignment > of prefixes? > >> > >> We have been through this many times on the MIP6 mailing list. > >> The earlier discussions were based on AAA assigning the home > >> address. We have always concluded otherwise. I don't see much > >> different between AAA managing home prefixes and home addresses. > >> I am not planning to rehash those discussions. > >> > >> Vijay > >> > >> > >>> > >>> Alper > >>> > >>>> -----Original Message----- > >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >>>> Sent: Sunday, November 25, 2007 7:17 PM > >>>> To: Hannes Tschofenig > >>>> Cc: mext@ietf.org > >>>> Subject: Re: [MEXT] Prefix delegation & Diameter Interaction > >>>> > >>>> Well, this document seems to assume (or make a case) that the AAA > >>>> manages the prefixes. We *do not* recommend that model. It is > >>>> typically either the home agent or a DHCP server co-located with > >>>> the home agent that manages the prefixes. > >>>> > >>>> Vijay > >>>> > >>>> Hannes Tschofenig wrote: > >>>>> Hi all, > >>>>> > >>>>> in the DIME working group we have a document that provides the > >>>>> Diameter > >>>>> interworking for prefix delegation. > >>>>> Here is the document: > >>>>> > http://tools.ietf.org/wg/dime/draft-sarikaya-dime-prefix-deleg > ation-ps- > >>>>> > >>>> 00.txt > >>>>> > >>>>> It would help us in DIME if members of this group could > give us some > >>>>> feedback. > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mext > >>> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Dec 01 12:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWPl-0004bx-Qn; Sat, 01 Dec 2007 12:46:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyWPk-0004bp-Df for mext@ietf.org; Sat, 01 Dec 2007 12:46:04 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyWPj-00034p-Pg for mext@ietf.org; Sat, 01 Dec 2007 12:46:04 -0500 Received: from [192.168.1.131] (88.45.217.87.dynamic.jazztel.es [87.217.45.88])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 9A6AB260F58for ; Sat, 1 Dec 2007 18:45:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <670881F1-5B1D-428D-BD72-75B18F711EBF@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sat, 1 Dec 2007 18:45:49 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.4368 TC:1F TRN:34 TV:5.0.1023(15580.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [MEXT] WIDE Itojun memorial gathering X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Forwarded on behalf of WIDE people ------------------------------------------------------------------------ ------ Dear IETF participants, As many may have heard of the sad news, Itojun (Dr. Junichiro Hagino) known to the IETF community as the Chair of the IPv6 working group, ex IAB Member, and dedicated researcher/developer to the deployment of IPv6 standards, passed away on October 29, 2007. The WIDE Project will be holding a gathering to commemorate Itojun at this upcoming 70th IETF meeting in Vancouver. Please drop by the Westin Bayshore "Chairman" room on the 2nd floor between 17:30pm-21:00pm (December 3, 2007). Itojun has been an important member of the WIDE community, making numerous worldwide contributions in the field of network computing. We would like to invite the IETF community to spend time with his friends and fellow IETFers in remembering Itojun. If you could share this information with his friends, appreciated. We look forward to seeing you there. Jun Murai (WIDE Project) ---Gathering in Memory of ItoJun--- Date: December 3, 2007 Time: 17:30pm-21:00pm (Refreshments and snacks will be served) Place: Westin Bayshore "Chairman" room on the 2nd floor http://www.starwoodhotels.com/westin/property/meetings/ floor_map_chart.html?propertyID=1080&buildingKey=1001023468&floorKey=2 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JennaleachPelletier@aaaknow.com Sat Dec 01 21:43:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyenx-0003HF-Fs; Sat, 01 Dec 2007 21:43:37 -0500 Received: from [201.240.199.218] (helo=pc01) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iyenw-0003ei-PH; Sat, 01 Dec 2007 21:43:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52630834.aaaknow.com (8.13.1/8.13.1) with SMTP id vCsxUuRT99.409556.cp2.TjR.3461933738500 for ; Wed, 26 Dec 2007 05:39:52 -0100 Message-ID: <1cc4601c84779$66833970$0201a8c0@pc01> From: "Kelley Pham" To: Cc: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_1CC42_01C84779.66833970-- From LetitiacontinuaEarly@davidsuzuki.org Sun Dec 02 02:13:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyj1W-0002pO-3Z; Sun, 02 Dec 2007 02:13:54 -0500 Received: from [201.170.133.216] (helo=yourb27fb1c401.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iyj1R-0003SU-FX; Sun, 02 Dec 2007 02:13:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host89027743.davidsuzuki.org (8.13.1/8.13.1) with SMTP id BWiQ1Q1M42.514982.nfz.Pqi.2560925644497 for ; Sat, 1 Dec 2007 23:13:20 +0800 Message-ID: <9bae701c834b2$decab9f0$0401a8c0@yourb27fb1c401> From: "Felecia Shearer" To: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_9BAE3_01C834B2.DECAB9F0-- From mext-bounces@ietf.org Sun Dec 02 03:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IykBh-0000V8-Ca; Sun, 02 Dec 2007 03:28:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IykBg-0000Rt-Ah for mext@ietf.org; Sun, 02 Dec 2007 03:28:28 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IykBf-00005G-Sq for mext@ietf.org; Sun, 02 Dec 2007 03:28:28 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2210341rvb for ; Sun, 02 Dec 2007 00:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XMT/dzcfgjIKe2qdZaqI6UfDOwjlD0lqJUQ9EBYUyS4=; b=I7CMaowmVWniGXNPlwg+4uvwLLzySRwvyZ5J/4ZikZch++/DdaB+xgF0ji3bgWjCSRmUnYSIz0lJ5a3Xjv+yr06OI9fS5nnnI9ktfjf0Y+EuMSLTx9o7BffP8mYLkkjB8pP8VbgGCr3n/F13Q4j3TDhYwE8741XCkl5X/gXt0JM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hP7eFUNv6zPfrtu7HcULX4svfcwtqzCwsduk3YgF4ceiBL2XUvsmI0fac6f+MpxSWk9N3niNyVMPpRRz8/VyUEQQBUyrAFQyMcKHvfEUZvgynwT2RuPQ5EMq6H5eSuMwfSG1SIaAjWLGSwIeMeieRuCYPdBCkvdRogX8zADF6vA= Received: by 10.140.207.3 with SMTP id e3mr4958019rvg.1196584107214; Sun, 02 Dec 2007 00:28:27 -0800 (PST) Received: by 10.141.180.1 with HTTP; Sun, 2 Dec 2007 00:28:27 -0800 (PST) Message-ID: <1d38a3350712020028h79f34b67vc67bc539ab83e68b@mail.gmail.com> Date: Sun, 2 Dec 2007 16:28:27 +0800 From: "Hui Deng" To: "Hesham Soliman" Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <007201c83330$57f9e1e0$2302600a@hitachichina.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Julien Laganier , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Sorry for mine jumping in. 2007/11/30, Hesham Soliman : > > > > >=> Not important IMO. We already have an IKE-based AAA solution. > > [P.Y] I guess you are talking about IKEv2 getting MIP6 > > information (for > > example: CoA) from AAA for SA negotiation. But when MN bootstrap in > > foreign network, IKEv2 daemon in MN should get the CoA > > before the first > > round-trip of IKE procedure. > > => I'm not sure what you mean by that. Of course any piece of networking SW > on the MN would need to know its address before it starts communicating. But > I don't see the relationship to this discussion. > > In this stage, the MIP6 > > information in AAA > > is not accessible to MN. And, after handover, it's not so > > efficient to > > update SA in MN/HA by this IKE-based AAA way, IMHO. > > => I'm sorry I can't follow. Have you looked at the IKEv2-based > bootstrapping work? It covers this scenario. If you are talking about integrated/split bootstrap, we could say yes, I guess that our explanation is not clear, we are talking about handover scenario other than bootstrap. If it still not clear, please help to read two other drafts: draft-sugimoto-mip6-pfkey-migrate-03 draft-arkko-pfkey-reference-00 we are solveing the same problem, most company has their propritatory solution, this is the reason that we would like to have one standard based solution Many thanks -Hui _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From CesarvaporousThornton@fordfound.org Sun Dec 02 05:12:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyloF-0001hP-QH; Sun, 02 Dec 2007 05:12:23 -0500 Received: from [84.232.116.72] (helo=equipo) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyloD-0003qJ-Dh; Sun, 02 Dec 2007 05:12:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host70017294.fordfound.org (8.13.1/8.13.1) with SMTP id WQXqHOTu03.729404.tPl.1Bc.5447456248994 for ; Sun, 2 Dec 2007 11:11:30 -0100 Message-ID: <28cb01c834cb$c8ef98d0$4874e854@equipo> From: "Rudolph Tate" To: Subject: Confirmation link Date: Sun, 2 Dec 2007 11:11:30 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_28C7_01C834CB.C8EF98D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_28C7_01C834CB.C8EF98D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis Soft Tabs would help you to = make better sex more often and to bring unimaginable plesure to her. = Just disolve half a pill under your tongue and get ready for action in = 30 minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Cialis Soft Tabs gives you confidence in any chance, every time. ------=_NextPart_000_28C7_01C834CB.C8EF98D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_28C7_01C834CB.C8EF98D0-- From mext-bounces@ietf.org Sun Dec 02 10:31:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyqmP-0004ke-Ha; Sun, 02 Dec 2007 10:30:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyqmN-0004bw-Mm for mext@ietf.org; Sun, 02 Dec 2007 10:30:47 -0500 Received: from static-ip-174-194-65-202.rev.dyxnet.com ([202.65.194.174] helo=hitachihk8.hitachi.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyqmM-0006u6-Gz for mext@ietf.org; Sun, 02 Dec 2007 10:30:47 -0500 Received: (qmail 10335 invoked from network); 2 Dec 2007 15:30:42 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;a01f501a5867ef51a178cf76689d44de; Received: from unknown (HELO hitachihk7.hitachi.cn) (170.95.94.4) by 170.95.94.11 with SMTP; 2 Dec 2007 15:30:42 -0000 Received: (qmail 32621 invoked from network); 2 Dec 2007 15:30:42 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk7;5d432ec3c2c791f3a56eede3adc34d30; Received: from hchidc401.hitachi-china.com (HELO hchidc401.hitachi.cn) (170.95.94.69) by 172.16.10.10 with SMTP; 2 Dec 2007 15:30:42 -0000 MIME-Version: 1.0 Subject: re: [MEXT] New items for the mext charter discussion Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sun, 2 Dec 2007 23:30:40 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: AcgzMFqCAcHsXivfRfSTNrtLOToPBAALSD2gAGY9JPs= From: "YANG, PENG -HCHBJ" To: "Hesham Soliman" , "marcelo bagnulo braun" , X-Scanned-By-hitachihk7: Virus scan performed by network-box X-Scanned-By-hitachihk7: Scanner file id is hitachihk7-1196609442.476-32616-000 X-Scanned-By-hitachihk7: No known viruses found in message (received+scanned in 0.02/0.04 secs) X-Scanned-By-hitachihk7: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1196609442.762-10323-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.04/0.06 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk7) X-Spam-Score: 1.9 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749201398==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0749201398== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C834F8.4BD46215" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C834F8.4BD46215 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable >>=3D> I'm not sure what you mean by that. Of course any piece of = networking SW >>on the MN would need to know its address before it starts = communicating. But >>I don't see the relationship to this discussion. [P.Y] Please check RFC2367 and RFC4301 for your reference. Or if you = ever read the code related to pf_key and ipsec in kernels of Linux or = BSD,=20 you can find the relationship to this discussion.=20 =20 >>=3D> I'm sorry I can't follow. Have you looked at the IKEv2-based >>bootstrapping work? It covers this scenario. [P.Y] Here I am assuming RFC4306 and RFC4877 in this discussion. If I = missed something, please let us know in this list.=20 P.Y Disclaimer:=0AThe contents of this e-mail, and its attachments, if any, are c= onfidential and may be protected=0Aby law against any unauthorized use. If yo= u have received this e-mail by mistake or have=0Areason to believe that you ar= e not the intended recipient, please notify the sender by reply=0Ae-mail as so= on as possible and delete it from your computer system immediately thereafte= r.=0AIf you are not the intended recipient, you must not copy this e-mail or a= ttachment or disclose=0Athe contents to any other person. While we have made = every effort to keep our network virus free,=0Awe take no responsibility for a= ny computer virus which might be transferred by way of this e-mail.=0A ------_=_NextPart_001_01C834F8.4BD46215 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [MEXT] New items for the mext charter discussion=0A= =0A= =0A=
=0A=
 >>=3D> I'm not sure what = you mean by =0A= that. Of course any piece of networking SW
>>on the MN would = need to =0A= know its address before it starts communicating. But
>>I don't = see the =0A= relationship to this discussion.
[P.Y] Please check RFC2367 and = RFC4301 for =0A= your reference. Or if you ever read the code related to pf_key and = ipsec in =0A= kernels of Linux or BSD,
=0A=
you can find the relationship to this =0A= discussion. 
=0A=
 
=0A=
>>=3D> I'm sorry I can't follow. = Have you =0A= looked at the IKEv2-based
>>bootstrapping work? It covers this =0A= scenario.
[P.Y] Here I am assuming RFC4306 and RFC4877 in this = discussion. If =0A= I missed something, please let us know in this list.
=0A=

P.Y

=0A=

=0A= =0A=
=

=0A

=0A=0ADisclaimer:=0AThe contents of this e-mail, and its at= tachments, if any, are confidential and may be protected by=0Alaw against any = unauthorized use. If you have received this e-mail by mistake or have reaso= n to=0Abelieve that you are not the intended recipient, please notify the send= er by reply e-mail as soon=0Aas possible and delete it from your computer syst= em immediately thereafter. If you are not the=0Aintended recipient, you must = not copy this e-mail or attachment or disclose the contents to any=0Aother per= son. While we have made every effort to keep our network virus free, we tak= e no=0Aresponsibility for any computer virus which might be transferred by way= of this e-mail.=0A=0A
=0A
=0A
= =0A= ------_=_NextPart_001_01C834F8.4BD46215-- --===============0749201398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0749201398==-- From AnnapantheistPearce@wwwalk.org Sun Dec 02 11:00:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyrEm-0001b5-WF; Sun, 02 Dec 2007 11:00:09 -0500 Received: from pool-71-181-135-137.sctnpa.east.verizon.net ([71.181.135.137] helo=ddzxd061.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyrEm-0001tX-DY; Sun, 02 Dec 2007 11:00:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host49127210.wwwalk.org (8.13.1/8.13.1) with SMTP id cmUasDoF28.066808.Waz.0LQ.9519195978844 for ; Sun, 2 Dec 2007 10:59:05 +0500 Message-ID: From: "Kathleen Pearce" To: Subject: Confirmation link Date: Sun, 2 Dec 2007 10:59:05 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_FE51D_01C834FC.64B0F220" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_FE51D_01C834FC.64B0F220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis Soft Tabs would help you to = make better sex more often and to bring unimaginable plesure to her. = Just disolve half a pill under your tongue and get ready for action in = 30 minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Cialis Soft Tabs gives you confidence in any chance, every time. ------=_NextPart_000_FE51D_01C834FC.64B0F220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_FE51D_01C834FC.64B0F220-- From mext-bounces@ietf.org Sun Dec 02 11:53:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iys3R-0000ai-Qt; Sun, 02 Dec 2007 11:52:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iys3R-0000aW-14 for mext@ietf.org; Sun, 02 Dec 2007 11:52:29 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iys3P-00007j-BO for mext@ietf.org; Sun, 02 Dec 2007 11:52:29 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Dec 2007 08:52:15 -0800 Message-ID: <4752E2BC.3080008@azairenet.com> Date: Sun, 02 Dec 2007 08:52:12 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "YANG, PENG -HCHBJ" Subject: Re: [MEXT] New items for the mext charter discussion References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Dec 2007 16:52:15.0129 (UTC) FILETIME=[B1077890:01C83503] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Julien Laganier , mext@ietf.org, Hesham Soliman X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org There is some confusion in this thread. Hesham, draft-qi-mip6-ikev2-interfacing-01 has nothing to do with bootstrapping. It describes PK_KEY extensions for the mip6 daemon (for example) to interact with the IPsec stack. RFC 3775 assumes it is implementation dependent how the SAs are updated based on the exchange of BU/BAck. I assume this draft is providing one (haven't read it). Peng, there is another draft on this. http://www.tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-03 Vijay YANG, PENG -HCHBJ wrote: > > >>=> I'm not sure what you mean by that. Of course any piece of > networking SW > >>on the MN would need to know its address before it starts > communicating. But > >>I don't see the relationship to this discussion. > [P.Y] Please check RFC2367 and RFC4301 for your reference. Or if you > ever read the code related to pf_key and ipsec in kernels of Linux or BSD, > you can find the relationship to this discussion. > > >>=> I'm sorry I can't follow. Have you looked at the IKEv2-based > >>bootstrapping work? It covers this scenario. > [P.Y] Here I am assuming RFC4306 and RFC4877 in this discussion. If I > missed something, please let us know in this list. > > P.Y > > > > Disclaimer: The contents of this e-mail, and its attachments, if any, > are confidential and may be protected by law against any unauthorized > use. If you have received this e-mail by mistake or have reason to > believe that you are not the intended recipient, please notify the > sender by reply e-mail as soon as possible and delete it from your > computer system immediately thereafter. If you are not the intended > recipient, you must not copy this e-mail or attachment or disclose the > contents to any other person. While we have made every effort to keep > our network virus free, we take no responsibility for any computer virus > which might be transferred by way of this e-mail. > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ArlenemagazineSnell@foundationmpls.com Sun Dec 02 12:31:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iysf9-0005yH-4D; Sun, 02 Dec 2007 12:31:27 -0500 Received: from cpe-74-77-33-7.buffalo.res.rr.com ([74.77.33.7] helo=jean.buffalo.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iysf8-0004d8-Qv; Sun, 02 Dec 2007 12:31:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host38757303.foundationmpls.com (8.13.1/8.13.1) with SMTP id R4MRZHA677.516798.Emw.ANE.6967871420712 for ; Sun, 2 Dec 2007 12:31:07 +0500 Message-ID: From: "Claudia Payton" To: Cc: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_A89A2_01C83509.2756D900-- From mext-bounces@ietf.org Sun Dec 02 14:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuQI-00064g-4s; Sun, 02 Dec 2007 14:24:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuQH-00064Y-Lg for mext@ietf.org; Sun, 02 Dec 2007 14:24:13 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyuQG-0002Oh-1F for mext@ietf.org; Sun, 02 Dec 2007 14:24:13 -0500 X-AuditID: c0a8013c-adf23bb000001e2e-86-47530657eddf Received: from PC20005 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 4715A4DC004; Sun, 2 Dec 2007 12:24:06 -0700 (MST) From: "Hesham Soliman" To: "'Vijay Devarapalli'" , "'YANG, PENG -HCHBJ'" Subject: RE: [MEXT] New items for the mext charter discussion Date: Mon, 3 Dec 2007 06:23:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acg1A7uuLNLzPyWMTsqIbxDi2K6KHwAHW6fw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4752E2BC.3080008@azairenet.com> X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'Julien Laganier' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ah, but this is no reason to standardise a new protection mechanism... Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, December 03, 2007 2:52 AM > To: YANG, PENG -HCHBJ > Cc: Hesham Soliman; marcelo bagnulo braun; mext@ietf.org; > Julien Laganier > Subject: Re: [MEXT] New items for the mext charter discussion > > There is some confusion in this thread. > > Hesham, draft-qi-mip6-ikev2-interfacing-01 has nothing to do > with bootstrapping. It describes PK_KEY extensions for the mip6 > daemon (for example) to interact with the IPsec stack. RFC 3775 > assumes it is implementation dependent how the SAs are updated > based on the exchange of BU/BAck. I assume this draft is > providing one (haven't read it). > > Peng, there is another draft on this. > http://www.tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-03 > > Vijay > > YANG, PENG -HCHBJ wrote: > > > > >>=> I'm not sure what you mean by that. Of course any piece of > > networking SW > > >>on the MN would need to know its address before it starts > > communicating. But > > >>I don't see the relationship to this discussion. > > [P.Y] Please check RFC2367 and RFC4301 for your reference. > Or if you > > ever read the code related to pf_key and ipsec in kernels > of Linux or BSD, > > you can find the relationship to this discussion. > > > > >>=> I'm sorry I can't follow. Have you looked at the IKEv2-based > > >>bootstrapping work? It covers this scenario. > > [P.Y] Here I am assuming RFC4306 and RFC4877 in this > discussion. If I > > missed something, please let us know in this list. > > > > P.Y > > > > > > > > Disclaimer: The contents of this e-mail, and its > attachments, if any, > > are confidential and may be protected by law against any > unauthorized > > use. If you have received this e-mail by mistake or have reason to > > believe that you are not the intended recipient, please notify the > > sender by reply e-mail as soon as possible and delete it from your > > computer system immediately thereafter. If you are not the > intended > > recipient, you must not copy this e-mail or attachment or > disclose the > > contents to any other person. While we have made every > effort to keep > > our network virus free, we take no responsibility for any > computer virus > > which might be transferred by way of this e-mail. > > > > > > > ------------------------------------------------------------- > ----------- > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 02 20:23:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz01d-0004Op-5L; Sun, 02 Dec 2007 20:23:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz01b-0004Oa-SW for mext@ietf.org; Sun, 02 Dec 2007 20:23:07 -0500 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz01b-0005Ji-0o for mext@ietf.org; Sun, 02 Dec 2007 20:23:07 -0500 Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 0DE8E4D8F5; Mon, 3 Dec 2007 10:23:05 +0900 (JST) Message-ID: <47535A6D.4050708@sfc.wide.ad.jp> Date: Mon, 03 Dec 2007 10:22:53 +0900 From: Shinta Sugimoto User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] MEXT Rechartering References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> In-Reply-To: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello Marcelo, We would like to ask for adding a new item to the MEXT charter to define interaction between Mobile IPv6 and IPsec/IKE. We have been working on this topic since 2005 and the issues and solutions are described in the following internet draft [1]. Although the draft is currently expired, we are making a new revision according to the report from implementers and the latest discussion on MIPv6 WG mailing list about DSMIPv6-IKE interaction. [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt We are also aware of the recent work by Deng et al.[2], but we are not exactly sure about what the relation between the two drafts is yet. Anyway, we believe that it is useful to produce the document (an informational RFC) which defines the interaction between MIPv6 and IPsec/IKE (Note: "MIPv6" refers to both RFC 3775 and DSMIPv6, and "IKE" refers to both IKEv1 and IKEv2) and we hope that the MEXT WG takes this work item. And we are definitely willing to make the contribution. I am regretful to say that I will not be attending the IETF meeting this time, but will follow the discussion on the mailing list. [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt [2] http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt Regards, Shinta marcelo bagnulo braun wrote: > Hi folks, > > Even though the WG just been created, we already have some new items > that people seem to be interested in including in the MEXT charter, so > we would like to open that discussion right away. Moreover, we are > planning to devote part of the next meeting in Vancouver to discuss > possible additional items to be included in the MEXT charter in the > rechartering process. > > So in order to do this process, we would like that if you have items > that you think should be included in the charter, please send a proposal > to the MEXT ml so it can be discussed and also if you want to include it > as part of the MEXT meeting rechartering discussion, ask for a slot. > > > Thanks, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 02 21:58:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Va-0001Wn-3F; Sun, 02 Dec 2007 21:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1VZ-0001Un-2y for mext@ietf.org; Sun, 02 Dec 2007 21:58:09 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iz1VY-00071Z-G6 for mext@ietf.org; Sun, 02 Dec 2007 21:58:09 -0500 X-AuditID: c0a8013c-adf23bb000001e2e-81-475370bc921d Received: from PC20005 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id ED4984DC007; Sun, 2 Dec 2007 19:57:59 -0700 (MST) From: "Hesham Soliman" To: "'Hui Deng'" Subject: RE: [MEXT] New items for the mext charter discussion Date: Mon, 3 Dec 2007 13:57:31 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acg0vY7X/GCNMZ5VRkWrftf8xRGRiwAot6Qw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1d38a3350712020028h79f34b67vc67bc539ab83e68b@mail.gmail.com> X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mext@ietf.org, 'Julien Laganier' X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > => I'm sorry I can't follow. Have you looked at the IKEv2-based > > bootstrapping work? It covers this scenario. > If you are talking about integrated/split bootstrap, we > could say yes, > I guess that our explanation is not clear, we are talking about > handover scenario other than bootstrap. > If it still not clear, please help to read two other drafts: > draft-sugimoto-mip6-pfkey-migrate-03 > draft-arkko-pfkey-reference-00 > > we are solveing the same problem, most company has their > propritatory solution, > this is the reason that we would like to have one standard > based solution => That's fine, but as I said earlier, this is not a motivation for 4285bis IMO, but rather a motivation to do one of those drafts above in the WG. Hesham > > Many thanks > > -Hui > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 03 00:28:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3qN-00056C-QT; Mon, 03 Dec 2007 00:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3qN-000567-G4 for mext@ietf.org; Mon, 03 Dec 2007 00:27:47 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz3qL-0002tB-6o for mext@ietf.org; Mon, 03 Dec 2007 00:27:47 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2411306rvb for ; Sun, 02 Dec 2007 21:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bsUOP7nTOvowWLDrxlXMVkKfjt6d/A95BPjSVjD3oCI=; b=J/mKtSOcIZLwPMTs33om4Fcn4W5y5lzAozAH5mb9l/IuntLREI7WTvbmqQTaUaBEJqnLawZSa5RqgYVDA6NVyD3dhnl2oI+DxexNeRvQy9PbD4sXyZz6ZQPRAblhVDwuCfgwufaIb2vL33vp0FPF+KNtzrPlYOW6eT2qHFx8WFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nyn5XQVASz7NZPh5YNmizKlQssRQkFL5UdYbFrgw4ezB/U9n4wuJRo9Sxuk3NMIyM/7w7wRthNc+X+pRJhICC8l3rPUdUyeJpnD4YceIFTx41gn11AxHkoD7NHAKv7FvSiPWZKr65x68kYfD14s4AQuiyXolRUnpOjj5mL1iN8c= Received: by 10.141.203.7 with SMTP id f7mr202848rvq.1196659664526; Sun, 02 Dec 2007 21:27:44 -0800 (PST) Received: by 10.141.180.1 with HTTP; Sun, 2 Dec 2007 21:27:44 -0800 (PST) Message-ID: <1d38a3350712022127q77dda690s6f91cd20d37987f0@mail.gmail.com> Date: Sun, 2 Dec 2007 21:27:44 -0800 From: "Hui Deng" To: "Shinta Sugimoto" Subject: Re: [MEXT] MEXT Rechartering In-Reply-To: <47535A6D.4050708@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> <47535A6D.4050708@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Thanks Sugimoto-san's suggestion, I include your draft together with Jari's draft as well in the presentation slides. -Hui 2007/12/2, Shinta Sugimoto : > Hello Marcelo, > > We would like to ask for adding a new item to the MEXT charter to > define interaction between Mobile IPv6 and IPsec/IKE. > > We have been working on this topic since 2005 and the issues and > solutions are described in the following internet draft [1]. > Although the draft is currently expired, we are making a new revision > according to the report from implementers and the latest discussion > on MIPv6 WG mailing list about DSMIPv6-IKE interaction. > > [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > > We are also aware of the recent work by Deng et al.[2], but we are > not exactly sure about what the relation between the two drafts is yet. > Anyway, we believe that it is useful to produce the document > (an informational RFC) which defines the interaction between MIPv6 > and IPsec/IKE (Note: "MIPv6" refers to both RFC 3775 and DSMIPv6, > and "IKE" refers to both IKEv1 and IKEv2) and we hope that the > MEXT WG takes this work item. And we are definitely willing to make > the contribution. > > I am regretful to say that I will not be attending the IETF meeting > this time, but will follow the discussion on the mailing list. > > [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > [2] http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt > > > Regards, > Shinta > > marcelo bagnulo braun wrote: > > Hi folks, > > > > Even though the WG just been created, we already have some new items > > that people seem to be interested in including in the MEXT charter, so > > we would like to open that discussion right away. Moreover, we are > > planning to devote part of the next meeting in Vancouver to discuss > > possible additional items to be included in the MEXT charter in the > > rechartering process. > > > > So in order to do this process, we would like that if you have items > > that you think should be included in the charter, please send a proposal > > to the MEXT ml so it can be discussed and also if you want to include it > > as part of the MEXT meeting rechartering discussion, ask for a slot. > > > > > > Thanks, marcelo > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 03 00:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3uI-0001rC-9P; Mon, 03 Dec 2007 00:31:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz3uG-0001qs-Vs for mext@ietf.org; Mon, 03 Dec 2007 00:31:48 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz3uG-0003C1-M8 for mext@ietf.org; Mon, 03 Dec 2007 00:31:48 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2411951rvb for ; Sun, 02 Dec 2007 21:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VulIY5mGv1rsJ23n2jUAvy4pgw2IljbRB9yl+z/ETIs=; b=dQM5Obihh09mscqZH+CAmQZxh1mC9swJGUpo9C+VSV0jozHmyFN0yv79vbF8pc7xf8B4EVXXZBCG7g9RjWtnxOpqBp3N+bf0WUqk7KayUk0u5/jzBQji7PXjndtr6Yih7Xqiln/lhxqi9PBLvChursLQwLFPf6rQmXahJ5fKDp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BSyG1vmrUe8FwCXWJkehjPBqd7T9obNxi8z1UTpOVESxD0fugnMI4rNPvoDI62X0K4irp55Sk89crEJ0YNysyHX/ocsiNvFsBiz51IZy81YoLaN9kGWVgm8dqT6BFGGYCeCkm/r9HCF4l/34gk8wjGOhlvRMeSHqfwNQ8vTulOE= Received: by 10.140.203.15 with SMTP id a15mr5401854rvg.1196659908107; Sun, 02 Dec 2007 21:31:48 -0800 (PST) Received: by 10.141.180.1 with HTTP; Sun, 2 Dec 2007 21:31:48 -0800 (PST) Message-ID: <1d38a3350712022131teb08400kfe2bde61638225d7@mail.gmail.com> Date: Sun, 2 Dec 2007 21:31:48 -0800 From: "Hui Deng" To: "Hesham Soliman" Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1d38a3350712020028h79f34b67vc67bc539ab83e68b@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org thanks for the reply, see below inline. 2007/12/2, Hesham Soliman : > > > > => I'm sorry I can't follow. Have you looked at the IKEv2-based > > > bootstrapping work? It covers this scenario. > > If you are talking about integrated/split bootstrap, we > > could say yes, > > I guess that our explanation is not clear, we are talking about > > handover scenario other than bootstrap. > > If it still not clear, please help to read two other drafts: > > draft-sugimoto-mip6-pfkey-migrate-03 > > draft-arkko-pfkey-reference-00 > > > > we are solveing the same problem, most company has their > > propritatory solution, > > this is the reason that we would like to have one standard > > based solution > > => That's fine, but as I said earlier, this is not a motivation for 4285bis > IMO, but rather a motivation to do one of those drafts above in the WG. In our presentation, we clearly introduce other two drafts. Working group may decide to merge those together, thanks -Hui > > Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Phetvongkhamdijm@nymphaeanaturals.com Mon Dec 03 07:38:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzAZB-0005lk-Mt for nemo-archive@lists.ietf.org; Mon, 03 Dec 2007 07:38:29 -0500 Received: from host146-149-dynamic.14-87-r.retail.telecomitalia.it ([87.14.149.146] helo=host21-154-dynamic.0-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzAZB-0001o0-4I for nemo-archive@lists.ietf.org; Mon, 03 Dec 2007 07:38:29 -0500 Received: from pc-intel ([139.152.110.156] helo=pc-intel) by host21-154-dynamic.0-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1ehOcX-000KJB-XV for nemo-archive@lists.ietf.org; Mon, 3 Dec 2007 13:39:05 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 3 Dec 2007 13:38:46 +0100 To: nemo-archive@lists.ietf.org From: "djem Phetvongkham" Subject: emilobme Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 do you really want to be average all the time? or do you really want to excell? boost your manhood with this. http://www.oezbahar.com/ From Satoru@modzielewski.de Mon Dec 03 10:40:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDPl-0005eR-BY for nemo-archive@lists.ietf.org; Mon, 03 Dec 2007 10:40:57 -0500 Received: from [97.88.177.190] (helo=[97.88.177.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzDPl-00084G-1z for nemo-archive@lists.ietf.org; Mon, 03 Dec 2007 10:40:57 -0500 Received: by 10.1.75.40 with SMTP id WaABXdZqgWWaB; Mon, 3 Dec 2007 09:41:05 -0600 (GMT) Received: by 192.168.71.207 with SMTP id dAVqnshNlSRhtB.5021091703752; Mon, 3 Dec 2007 09:41:03 -0600 (GMT) Message-ID: <448C58A9.2BA9EE46@modzielewski.de> Date: Mon, 3 Dec 2007 09:41:00 -0600 From: "Satoru Riddell" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: seltserc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 never worry about blowing your load too quick again once you start
taking male virility pills http://www.cncybes.com/
From mext-bounces@ietf.org Mon Dec 03 12:27:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF4F-0005sX-8E; Mon, 03 Dec 2007 12:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzF4E-0005sE-20 for mext@ietf.org; Mon, 03 Dec 2007 12:26:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzF4A-0001id-NY for mext@ietf.org; Mon, 03 Dec 2007 12:26:50 -0500 Received: (qmail invoked by alias); 03 Dec 2007 17:26:45 -0000 Received: from dhcp-16ce.ietf70.org (EHLO [130.129.22.206]) [130.129.22.206] by mail.gmx.net (mp055) with SMTP; 03 Dec 2007 18:26:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19i99V/+Dti55oY0Tq5tZuuPaR0zljonsUjmDeQCg U6mukajiN7sKnK Message-ID: <47543C53.5070309@gmx.net> Date: Mon, 03 Dec 2007 18:26:43 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "ietf@ietf.org Discussion" , mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [MEXT] iFARE Bar-BOF X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, I would like to invite you to join the iFARE Bar-BOF on Tuesday evening. We will meet in front on the IETF registration desk at 8pm. More information about IPsec FAilover and REdundancy (iFare) can be found here: http://www.tschofenig.com/twiki/bin/view/IFare/WebHome Ciao Hannes PS: I will put information about the meeting room to the above-listed webpage once we got it. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 03 12:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFGR-0001J9-FW; Mon, 03 Dec 2007 12:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFGQ-0001By-6O for mext@ietf.org; Mon, 03 Dec 2007 12:39:26 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzFGM-0003BS-Uu for mext@ietf.org; Mon, 03 Dec 2007 12:39:26 -0500 Received: (qmail 14769 invoked for bounce); 3 Dec 2007 17:39:20 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 3 Dec 2007 17:39:20 -0000 Message-Id: From: Romain KUNTZ To: Teco Boot In-Reply-To: <002101c830d7$89fbc6a0$9df353e0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 3 Dec 2007 18:39:20 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Hannes Tschofenig , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Teco, On 2007/11/27, at 10:26, Teco Boot wrote: > What I found is: > RFC4080 (NSIS Framework): 4.6.1. Flow Identification > draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier > (PACKET_CLASSIFIER) > > I think NSIS produced specifications on packet classification should > be > verified for using for MIP flow distribution / handover also. > Maybe RSVP TSPEC is past and NSIS FlowID is future. From what I understood in the envisionned architecture for flow distribution in MEXT (crrect me if I'm wrong): 1. an entity (could be the HA, or not) distributes policies to the MR and possibly the peers (e.g. HA) too, 2. The MR translates them to filter rules according to its current environment (available interfaces, path characteristics...), 3. The MR sends those filter rules to the peer (e.g the HA), 4. The peer enforce those filter rules. For 1., we need to describe policies, and a transport protocol between peers (none specified so far). For 2., we need to describe filter rules (e.g. draft-larsson-mext-flow- distribution-rules if we consider ASCII-defined filter rules, but this draft does not have companion transport protocol yet to fulfill 3.) For 3., we need a transport protocol to bind filter rules to BIDs (draft-soliman-monami6-flow-binding was proposed, where flows are described as an option to fulfill 2., but this option was not specified yet.) Here, where would the NSIS framework operate: on 3., for both transport and flow identification? But we still need to bind flows to BID. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team >> -----Oorspronkelijk bericht----- >> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Verzonden: dinsdag 27 november 2007 9:42 >> Aan: Teco Boot >> CC: mext@ietf.org >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >> >> Hi Teco, >> >> Teco Boot wrote: >>> Hi Hannes, >>> I suggest reusing what we already have. >>> Maybe RSVP is already in place, in that case RSVP packets are sent >> over the >>> tunnel. >>> >> >> Two observations from my limited RSVP experience: >> >> * Deployment of RSVP does not really exist (for this type of >> environment). Please note that I talk about RSVP and not RSVP-TE. >> >> * RSVP for packet filter installation does not exist either as an >> IETF >> document. There was only some work in the 3GPP2. >> >> The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet >> filter installation. Unlike RSVP for packet filter installation the >> NSIS >> NATFW NSLP is actually an IETF document. >> >>> In the MONAMI6 context; I think we need a protocol for signaling >> traffic >>> flow policy. This is related to MIP. >>> Within this protocol, we need some kind of traffic specification, >> here we >>> could reuse RSVP TSPEC. >>> Cheers, Teco. >>> >> >> >> Ciao >> Hannes >> >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Verzonden: maandag 26 november 2007 10:12 >>>> Aan: Teco Boot >>>> CC: mext@ietf.org >>>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >>>> >>>> Hi Teco, >>>> >>>> Teco Boot wrote: >>>> >>>>>>> Finally, what happened to >>>>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I >>>>>>> thought this was also going to be adopted as a MONAMI6 WG >>>>>>> document. I might have missed some emails. >>>>>>> >>>>>>> >>>>>> There are two documents about flow distribution languages >> documents. >>>>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt >>>>>> - draft-larsson-monami6-filter-rules-02.txt >>>>>> >>>>>> We agreed to merge the two documents and >>>>>> published draft-larsson-mext-flow-distribution-rules-00.txt >>>>>> >>>>>> >>>>>> >>>>> I suggested to check using RSVP TSPEC for flow-distribution-rules >>>>> >>>> before. >>>> >>>>> This has similar functionality and integration with upper layers >>>>> >>>> could be >>>> >>>>> more straightforward. >>>>> I'm afraid I don't have time to work out this idea. I would >>>>> >>>> appreciate >>>> >>>>> someone picks up. >>>>> >>>>> >>>> Are you suggesting to use RSVP for signaling the packet filters? >>>> Or: Are you suggesting to look at the packet formats for describing >> the >>>> traffic filters? >>>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>>> Teco. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>>>> >>>>> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 03 13:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFuj-0003hE-OF; Mon, 03 Dec 2007 13:21:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFui-0003gZ-Pt for mext@ietf.org; Mon, 03 Dec 2007 13:21:04 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFuh-0000oA-E0 for mext@ietf.org; Mon, 03 Dec 2007 13:21:04 -0500 Received: (qmail 20912 invoked from network); 3 Dec 2007 19:21:01 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 3 Dec 2007 19:21:01 +0100 From: "Teco Boot" To: "'Romain KUNTZ'" References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> In-Reply-To: Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 3 Dec 2007 19:20:27 +0100 Message-ID: <004501c835d9$40f0fe10$c2d2fa30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg104JFlI+ZWu2WRZihcRWaul7S0QAAqzDQ Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Romain, For evaluating existing specifications for using in the steps that you described, I think we should look for something that is highly related. I think flow specification for QoS handling and tunnel selection is very similar. I don't know if this is the case for the other steps. QoS reservation for tunneled flows within tunnel and for the tunnel itself is somewhat related with tunnel selection. But I think using separate protocols (e.g. RSVP and BU) is more optimal. Some comments inline. Teco. > -----Oorspronkelijk bericht----- > Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > Verzonden: maandag 3 december 2007 18:39 > Aan: Teco Boot > CC: Hannes Tschofenig; mext@ietf.org > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > Hi Teco, > > On 2007/11/27, at 10:26, Teco Boot wrote: > > What I found is: > > RFC4080 (NSIS Framework): 4.6.1. Flow Identification > > draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier > > (PACKET_CLASSIFIER) > > > > I think NSIS produced specifications on packet classification should > > be > > verified for using for MIP flow distribution / handover also. > > Maybe RSVP TSPEC is past and NSIS FlowID is future. > > From what I understood in the envisionned architecture for flow > distribution in MEXT (crrect me if I'm wrong): > > 1. an entity (could be the HA, or not) distributes policies to the MR > and possibly the peers (e.g. HA) too, I don't know what a policy is. I think you mean a profile for generating filter rules. It could be filter rules itself also. > 2. The MR translates them to filter rules according to its current > environment (available interfaces, path characteristics...), MR is MN or HA, correct? > 3. The MR sends those filter rules to the peer (e.g the HA), Or HA to MN, correct? > 4. The peer enforce those filter rules. For a bidirectional tunnel, there are two processes for two directions, correct? > > For 1., we need to describe policies, and a transport protocol between > peers (none specified so far). > For 2., we need to describe filter rules (e.g. draft-larsson-mext-flow- > distribution-rules if we consider ASCII-defined filter rules, but this > draft does not have companion transport protocol yet to fulfill 3.) > For 3., we need a transport protocol to bind filter rules to BIDs > (draft-soliman-monami6-flow-binding was proposed, where flows are > described as an option to fulfill 2., but this option was not > specified yet.) > > Here, where would the NSIS framework operate: on 3., for both > transport and flow identification? But we still need to bind flows to > BID. > > Regards, > > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team > > > > >> -----Oorspronkelijk bericht----- > >> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Verzonden: dinsdag 27 november 2007 9:42 > >> Aan: Teco Boot > >> CC: mext@ietf.org > >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > >> > >> Hi Teco, > >> > >> Teco Boot wrote: > >>> Hi Hannes, > >>> I suggest reusing what we already have. > >>> Maybe RSVP is already in place, in that case RSVP packets are sent > >> over the > >>> tunnel. > >>> > >> > >> Two observations from my limited RSVP experience: > >> > >> * Deployment of RSVP does not really exist (for this type of > >> environment). Please note that I talk about RSVP and not RSVP-TE. > >> > >> * RSVP for packet filter installation does not exist either as an > >> IETF > >> document. There was only some work in the 3GPP2. > >> > >> The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet > >> filter installation. Unlike RSVP for packet filter installation the > >> NSIS > >> NATFW NSLP is actually an IETF document. > >> > >>> In the MONAMI6 context; I think we need a protocol for signaling > >> traffic > >>> flow policy. This is related to MIP. > >>> Within this protocol, we need some kind of traffic specification, > >> here we > >>> could reuse RSVP TSPEC. > >>> Cheers, Teco. > >>> > >> > >> > >> Ciao > >> Hannes > >> > >>> > >>>> -----Oorspronkelijk bericht----- > >>>> Van: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Verzonden: maandag 26 november 2007 10:12 > >>>> Aan: Teco Boot > >>>> CC: mext@ietf.org > >>>> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > >>>> > >>>> Hi Teco, > >>>> > >>>> Teco Boot wrote: > >>>> > >>>>>>> Finally, what happened to > >>>>>>> draft-mitsuya-monami6-flow-distribution-policy-04.txt. I > >>>>>>> thought this was also going to be adopted as a MONAMI6 WG > >>>>>>> document. I might have missed some emails. > >>>>>>> > >>>>>>> > >>>>>> There are two documents about flow distribution languages > >> documents. > >>>>>> - draft-mitsuya-monami6-flow-distribution-policy-04.txt > >>>>>> - draft-larsson-monami6-filter-rules-02.txt > >>>>>> > >>>>>> We agreed to merge the two documents and > >>>>>> published draft-larsson-mext-flow-distribution-rules-00.txt > >>>>>> > >>>>>> > >>>>>> > >>>>> I suggested to check using RSVP TSPEC for flow-distribution-rules > >>>>> > >>>> before. > >>>> > >>>>> This has similar functionality and integration with upper layers > >>>>> > >>>> could be > >>>> > >>>>> more straightforward. > >>>>> I'm afraid I don't have time to work out this idea. I would > >>>>> > >>>> appreciate > >>>> > >>>>> someone picks up. > >>>>> > >>>>> > >>>> Are you suggesting to use RSVP for signaling the packet filters? > >>>> Or: Are you suggesting to look at the packet formats for > describing > >> the > >>>> traffic filters? > >>>> > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>>> Teco. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>>> > >>>>> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 03 19:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLYY-0000uZ-Hj; Mon, 03 Dec 2007 19:22:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLYX-0000rj-6Q for mext@ietf.org; Mon, 03 Dec 2007 19:22:33 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzLYW-00066p-9P for mext@ietf.org; Mon, 03 Dec 2007 19:22:33 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id lB40MPik027241; Tue, 4 Dec 2007 09:22:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lB40MP405784; Tue, 4 Dec 2007 09:22:25 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id lB40MQ610460; Tue, 4 Dec 2007 09:22:26 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id lB40MOwP022358; Tue, 4 Dec 2007 09:22:24 +0900 (JST) Received: from [10.238.172.34] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lB40MMlJ022284; Tue, 4 Dec 2007 09:22:23 +0900 (JST) Date: Tue, 04 Dec 2007 09:22:24 +0900 From: Keigo Aso To: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: References: <4744BE6F.5040408@azairenet.com> Message-Id: <20071204062837.0CE9.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, Let me summarize the returning home approaches we have discussed so far. Hopefully this would be used for the preparation for hearing Ryuji's presentation tomorrow. There are two cases on HA configuration we should consider. One is HA is a router case, another is HA is a host case. When HA is a router, as we all already understand, there is no issue because HA can intercept packets for MN's HoA without Proxy NDP and MN can run NDP for own HoA on the home link. Only needed for this is HA has to know that MN is at home in order to make the home binding. Actually the current MCoA draft already introduced the solution for this, which is MN uses 'H' flag in BU to notify that it is attaching to the home link also toghether with the CoA for the foreign binding. While, when HA is a host case, HA has to run Proxy ND for intercepting packets for MN's HoA. So, in this case, MN can not notify L2 address to the HA. For this case there is a approach which is MN sends BU including L2 address. This may be useful for the case HA is a router. Furthermore, there is another good approach for this case, which is using another CoA in the home link. If MN can create a CoA in the home link which is different from own HoA, it can register it with 'H' flag for making the home binding to the HA. Therefore, HA can run Proxy NDP for MN's HoA, while MN can notify L2 address by running NDP for this CoA. In this approach, its CoA could be the address which is made from own home prefix(HomeCoA). While if there is another prefix in the home network, it is used for making the CoA. When using other prefix, it would need operational stuff for HA and other MNs on the home link. Regards, Keigo On Sun, 25 Nov 2007 02:53:02 +0900 Ryuji Wakikawa wrote: > Hi George and Vijay, > > Question is whether we should support DSMIP in this document. > It seems reasonable to support DSMIP. > We can easily extend BID sub-option to cary both IPv4/IPv6 addresses. > > regards, > ryuji > > > > On 2007/11/22, at 8:25, Vijay Devarapalli wrote: > > > George Tsirtsis wrote: > > > >> 7) Interactions with DSMIPv6. I think at some point a new section > >> needs to be added to talk about interactions with DSMIPv6. Beyond > >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the > >> MCoA draft includes some interactions with IKEv2 > > > > I think the IKEv2 interactions are inline with what we decided for > > DS-MIPv6 last week. Transport mode IPsec SA for the binding update, > > and tunnel mode SAs updated either by MIPv6 (K flag) or running > > IKEv2 again. > > > > and imposes some requirements to the use of > >> alternate-CoA which may or may not conflict with DSMIPv6 (have not > >> checked that myself yet). > > > > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not > > related to the alt CoA option in RFC 3775. > > draft-ietf-monami6-multiplecoa says the alt CoA option should not > > be included whenever the CoA is carried in the BID mobility option. > > > > The BID option as defined in the draft currently seems to allow > > only for an IPv6 address. I think, we need to extend the BID option > > to carry an IPv4 or an IPv6 address. > > > > Vijay > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 12:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrN-0007Hg-OM; Tue, 04 Dec 2007 12:47:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbrL-0007Ef-SO for mext@ietf.org; Tue, 04 Dec 2007 12:47:04 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzbrL-0006x1-EO for mext@ietf.org; Tue, 04 Dec 2007 12:47:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB4Hkhi9016277 for ; Tue, 4 Dec 2007 19:47:01 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 19:46:54 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 19:46:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 19:46:45 +0200 Message-ID: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04B48F8F@esebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall presentation/IETF70 Thread-Index: Acgy0hnzWMFT+p7FEdyj4wARJNUNiADyyDsg References: <474F3327.7090104@azairenet.com> From: To: X-OriginalArrivalTime: 04 Dec 2007 17:46:54.0694 (UTC) FILETIME=[A8A0E060:01C8369D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [MEXT] Firewall presentation/IETF70 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org What is the difference between Firwall for MN and Firewall CN? Shouldn't be it more generic like Firewall for mobile host? -Preeti _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 13:05:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc8p-0003Ac-NI; Tue, 04 Dec 2007 13:05:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc8o-0003AQ-Jq for mext@ietf.org; Tue, 04 Dec 2007 13:05:06 -0500 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izc8n-0000H1-UL for mext@ietf.org; Tue, 04 Dec 2007 13:05:06 -0500 Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id ADDFC7292A7 for ; Tue, 4 Dec 2007 12:05:04 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov with ESMTP id DPxIrD23Am2aho4G for ; Tue, 04 Dec 2007 12:05:04 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 12:05:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 12:04:23 -0600 Message-ID: In-Reply-To: <83CD3A5F85DE7D43B6A5CC37CCBAEECE04B48F8F@esebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall presentation - HA inside firewall and MN and CN outside firewall Thread-Index: Acgy0hnzWMFT+p7FEdyj4wARJNUNiADyyDsgAABPiXA= References: <474F3327.7090104@azairenet.com> <83CD3A5F85DE7D43B6A5CC37CCBAEECE04B48F8F@esebe104.NOE.Nokia.com> From: "Ivancic, William D. (GRC-RCN0)" To: X-OriginalArrivalTime: 04 Dec 2007 18:05:04.0441 (UTC) FILETIME=[322B1290:01C836A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [MEXT] Firewall presentation - HA inside firewall and MN and CN outside firewall X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org In Administrator document: "3.3. Data traffic from and to MN passing through the HA If a CN tries to initiate traffic to an MN, a stateful firewall would prevent these connection requests to pass through as there is no established state on the firewall. If this is necessary to do, the pattern to look for is Destination Address: MN HoA Allowing this traffic might allow any kind of traffic, including malicious traffic, to pass through unfiltered to the MN. This would expose the MN to any type of possibly malicious traffic, resulting in a denial of service or exploitation of known security vulnerabilities. This practice is NOT RECOMMENDED. Instead, a dynamically created pinhole like the one specified in [MIP6FWVENDOR]" The last sentence implies a way to dynamically create a pinhole is specified in the "MIP6FWVENDOR" document. However, upon review of the MIP6FWVENDOR the solution appears to be only for rules where the MN sends a binding update. "5. Allowing data packets based on signaling Once the MIPv6 signaling completes, the data traffic can begin to flow. The traffic filters for the data traffic can be inferred from the contents of the signaling messages that setup the session. This section describes how firewalls can intelligently setup filters for data traffic based on signaling traffic.The following example describes how to setup a filter for allowing incoming route optimized messages from a CN to an MN after the MN sent a BU message to a CN." If this is correct, either the last sentence in 3.3 needs to me removed or modified or some clarification has to be made that a CN either has to be allowed to transition the FW at all times and take the risk or if a CN initiates a conversation with the MN when both are outside the firewall, the communiciation will fail. Will _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 13:29:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcWk-0002AI-Rk; Tue, 04 Dec 2007 13:29:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcWj-00029W-8N for mext@ietf.org; Tue, 04 Dec 2007 13:29:49 -0500 Received: from ndjsbar02.ndc.nasa.gov ([198.120.25.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzcWh-00076v-Lw for mext@ietf.org; Tue, 04 Dec 2007 13:29:49 -0500 Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id A0959654935; Tue, 4 Dec 2007 12:29:46 -0600 (CST) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id QjFGGQ9LSvYKWvm6; Tue, 04 Dec 2007 12:29:46 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 12:29:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 12:29:05 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verifying Multiple CoA Bindings Thread-Index: Acg2o4zYnf1vokJ8TNWLf1cwLZcsnQ== From: "Ivancic, William D. (GRC-RCN0)" To: , X-OriginalArrivalTime: 04 Dec 2007 18:29:46.0190 (UTC) FILETIME=[A55C06E0:01C836A3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [MEXT] Verifying Multiple CoA Bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Benjamin, On page 9 last paragraph: =20 "To reduce the need for mobile node to send at least one packet from each interface, the home agent could send a notification to a mobile node via one unverified care-of address and ask the mobile node to respond to the reception of the notification via another care-of address. " This is probably not a workable solution for validating the CoA Bindings. The security provided by firewalls probably make this technique unworkable. As my collegue often points out Security - The Ultimate Denial Of Service - TUDOS! Will _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 14:13:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdCi-0005qX-Bk; Tue, 04 Dec 2007 14:13:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdCf-0005mY-Cs for mext@ietf.org; Tue, 04 Dec 2007 14:13:10 -0500 Received: from deimos.multihop.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdCd-0002I6-Ud for mext@ietf.org; Tue, 04 Dec 2007 14:13:09 -0500 Received: by deimos.multihop.net (Postfix, from userid 1013) id 362AAA0A533; Tue, 4 Dec 2007 11:13:07 -0800 (PST) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [130.129.86.225] (unknown [130.129.86.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 6519AA0A530 for ; Tue, 4 Dec 2007 11:13:05 -0800 (PST) Message-ID: <4755A6B9.3070508@kniveton.com> Date: Tue, 04 Dec 2007 11:12:57 -0800 From: "T.J. Kniveton" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [MEXT] Is Jabber broken? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I lost connection to the groupchat and can't get back. At the same time the speaker volume went down. Maybe someone is giving us a DoS attack? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 14:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdGW-0005CC-CN; Tue, 04 Dec 2007 14:17:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdGV-0005BT-FQ for mext@ietf.org; Tue, 04 Dec 2007 14:17:07 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdGU-0002li-Gt for mext@ietf.org; Tue, 04 Dec 2007 14:17:07 -0500 Received: by rv-out-0910.google.com with SMTP id l15so3084243rvb for ; Tue, 04 Dec 2007 11:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JFYfN4gBDSYhg1VCB4ym1HoTH9ZPvdkSGzTUPPjmWj0=; b=SWoO9JuAx+iBPY7M/x5Ak8SxkV1RgPzC4xnbN9vkFzBCObMoYWyNUGZlQTLb/e/lQovhYly+JJa59YB3hL1EHEYpnXh2Wobs2I1jyqpEFOJwY1WjcG00/Nwva+nQx6jashQhXhNzQxqaEot4R9i0p9cSLFGCYd8KCYagwUIjXVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XJs8GjtpJjvSZQLGWCLyZLeoNBc4luFfazsfXVIoaqKzyeyIpXubUauZa5gZU7dn/FG97FMFvr8VIssDSnmRe+COIhliGVkiuL+U6AZuPjEWxybdxTiAtQXB4tKV96p/cLsleZ4h8+8n7yhYH9TWlMuiT6B9j232ssLqxonaZTQ= Received: by 10.140.207.3 with SMTP id e3mr558429rvg.1196795825799; Tue, 04 Dec 2007 11:17:05 -0800 (PST) Received: by 10.141.180.1 with HTTP; Tue, 4 Dec 2007 11:17:05 -0800 (PST) Message-ID: <1d38a3350712041117q48372df9ye125bc7e82ae1b49@mail.gmail.com> Date: Tue, 4 Dec 2007 11:17:05 -0800 From: "Hui Deng" To: "T.J. Kniveton" Subject: Re: [MEXT] Is Jabber broken? In-Reply-To: <4755A6B9.3070508@kniveton.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4755A6B9.3070508@kniveton.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org not only happen in mext, but also in other WGs 2007/12/4, T.J. Kniveton : > I lost connection to the groupchat and can't get back. At the same time > the speaker volume went down. > > Maybe someone is giving us a DoS attack? > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 14:26:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdPR-0003Cc-LY; Tue, 04 Dec 2007 14:26:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdPP-0003AH-TR for mext@ietf.org; Tue, 04 Dec 2007 14:26:19 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzdPP-0007Yg-Gy for mext@ietf.org; Tue, 04 Dec 2007 14:26:19 -0500 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id lB4JQJAH002380; Tue, 4 Dec 2007 13:26:19 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 13:26:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Firewall presentation/IETF70 Date: Tue, 4 Dec 2007 14:24:03 -0500 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA542EC3@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall presentation/IETF70 Thread-Index: Acgy0hnzWMFT+p7FEdyj4wARJNUNiADyyDsgAAOACMw= References: <474F3327.7090104@azairenet.com> <83CD3A5F85DE7D43B6A5CC37CCBAEECE04B48F8F@esebe104.NOE.Nokia.com> From: "Suresh Krishnan" To: , X-OriginalArrivalTime: 04 Dec 2007 19:26:18.0911 (UTC) FILETIME=[8B942AF0:01C836AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Preeti, As a general concept I agree. But, let's say I own a set of servers = that are not mobile. They are protected by a firewall. This firewall = needs to be explicitly configured to let MIPv6 related traffic thru even = though it does not protect mobile nodes. Also, the traffic patterns to = be allowed on each firewall can vary. That is why there are separate = sections covering each firewall. Thanks Suresh -----Original Message----- From: Preetida.Vinayakray-Jani@nokia.com = [mailto:Preetida.Vinayakray-Jani@nokia.com] Sent: Tue 4/12/2007 12:46 PM To: mext@ietf.org Subject: [MEXT] Firewall presentation/IETF70 =20 What is the difference between Firwall for MN and Firewall CN? Shouldn't be it more generic like Firewall for mobile host? -Preeti _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 14:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdSM-0004jo-Fo; Tue, 04 Dec 2007 14:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdSL-0004jU-KA for mext@ietf.org; Tue, 04 Dec 2007 14:29:21 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdSL-00045H-3r for mext@ietf.org; Tue, 04 Dec 2007 14:29:21 -0500 Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id AF7B013B683; Wed, 5 Dec 2007 03:29:09 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id A26F713B682; Wed, 5 Dec 2007 03:29:09 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 03:28:28 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Firewall presentation/IETF70 Date: Wed, 5 Dec 2007 03:27:30 +0800 Message-ID: <162B8AFBFBBB2148A9A1B8F9C57534283DF088@mailbe01.teak.local.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall presentation/IETF70 Thread-Index: Acgy0hnzWMFT+p7FEdyj4wARJNUNiADyyDsgAAOe0dk= References: <474F3327.7090104@azairenet.com> <83CD3A5F85DE7D43B6A5CC37CCBAEECE04B48F8F@esebe104.NOE.Nokia.com> From: "Qiu Ying" To: , X-OriginalArrivalTime: 04 Dec 2007 19:28:28.0582 (UTC) FILETIME=[D8DE6460:01C836AB] X-Spam-Score: -97.3 (---------------------------------------------------) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org The=20difference=20is=20that=20the=20inbound=20packets=20to=20CN=20is=20v= ariable=20while=20the=20inbound=20packet=20to=20MN=20is=20fixed=20(assume= =20that=20CN=20is=20not=20a=20mobility=20host).=20So=20the=20firewall=20c= onfiguration=20would=20be=20difference. -----Original=20Message----- From:=20Preetida.Vinayakray-Jani@nokia.com=20[mailto:Preetida.Vinayakray-= Jani@nokia.com] Sent:=20Wed=2012/5/2007=201:46=20AM To:=20mext@ietf.org Subject:=20[MEXT]=20Firewall=20presentation/IETF70 =20 What=20is=20the=20difference=20between=20Firwall=20for=20MN=20and=20Firew= all=20CN?=20Shouldn't be=20it=20more=20generic=20like=20Firewall=20for=20mobile=20host? -Preeti _______________________________________________ MEXT=20mailing=20list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext ------------=20Institute=20For=20Infocomm=20Research=20-=20Disclaimer=20-= ------------This=20email=20is=20confidential=20and=20may=20be=20privilege= d.=20=20If=20you=20are=20not=20the=20intended=20recipient,=20please=20del= ete=20it=20and=20notify=20us=20immediately.=20Please=20do=20not=20copy=20= or=20use=20it=20for=20any=20purpose,=20or=20disclose=20its=20contents=20t= o=20any=20other=20person.=20Thank=20you.---------------------------------= ----------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 04 14:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdT5-0005IF-D0; Tue, 04 Dec 2007 14:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdT0-00058B-Sp; Tue, 04 Dec 2007 14:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdT0-00049i-CL; Tue, 04 Dec 2007 14:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 296D326E5D; Tue, 4 Dec 2007 19:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzdT0-0007x7-2O; Tue, 04 Dec 2007 14:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Dec 2007 14:30:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-rfc4285bis-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Authentication Protocol for Mobile IPv6 Author(s) : A. Patel, et al. Filename : draft-ietf-mip6-rfc4285bis-02.txt Pages : 24 Date : 2007-12-04 IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing Mobile IPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here consists of a Mobile IPv6 specific authentication option that can be added to Mobile IPv6 signalling messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-rfc4285bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-rfc4285bis-02.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-mip6-rfc4285bis-02.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: <2007-12-04142417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-rfc4285bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-rfc4285bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-04142417.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Tue Dec 04 14:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdUe-0006d9-3z; Tue, 04 Dec 2007 14:31:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdUc-0006cb-FK for mext@ietf.org; Tue, 04 Dec 2007 14:31:42 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzdUc-0004NG-3Z for mext@ietf.org; Tue, 04 Dec 2007 14:31:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1196796701!4957140!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9499 invoked from network); 4 Dec 2007 19:31:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 4 Dec 2007 19:31:41 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB4JVZFj023588; Tue, 4 Dec 2007 12:31:35 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB4JVZDu025959; Tue, 4 Dec 2007 13:31:35 -0600 (CST) Received: from [127.0.0.1] ([10.19.241.164]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB4JVY6a025933; Tue, 4 Dec 2007 13:31:34 -0600 (CST) Message-ID: <4755AB15.5060103@gmail.com> Date: Tue, 04 Dec 2007 20:31:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hui Deng Subject: Re: [MEXT] Is Jabber broken? References: <4755A6B9.3070508@kniveton.com> <1d38a3350712041117q48372df9ye125bc7e82ae1b49@mail.gmail.com> In-Reply-To: <1d38a3350712041117q48372df9ye125bc7e82ae1b49@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071204-1, 04/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hui Deng wrote: > not only happen in mext, but also in other WGs Right, mext is down, error is something like "Creating the room" at the moment of joining the chat room. The Jabber client connects and authenticates fine however. mip6 room is down too. Alex > > > > 2007/12/4, T.J. Kniveton : >> I lost connection to the groupchat and can't get back. At the same time >> the speaker volume went down. >> >> Maybe someone is giving us a DoS attack? >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AngelitasopTilley@igougo.com Tue Dec 04 20:36:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjC3-000517-Jf; Tue, 04 Dec 2007 20:36:55 -0500 Received: from 218-163-148-124.dynamic.hinet.net ([218.163.148.124] helo=master) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzjC3-0001aA-3R; Tue, 04 Dec 2007 20:36:55 -0500 Received: from hitherto by igougo.com with SMTP id uJj8PjTF0G for ; Wed, 5 Dec 2007 09:37:55 -0800 From: "Gilda Flint" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjXK-0001i6-LH; Tue, 04 Dec 2007 20:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjXK-0001g1-02 for mext@ietf.org; Tue, 04 Dec 2007 20:58:54 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzjXJ-0007Mx-K7 for mext@ietf.org; Tue, 04 Dec 2007 20:58:53 -0500 Received: by py-out-1112.google.com with SMTP id d32so15491449pye for ; Tue, 04 Dec 2007 17:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=7hLeu4+FphKdk5spEKXfH1U9Jhwj4SIaLS2SyztIba0=; b=HGSVkEizD8sz8gSy2Iq/5h/zpyP7fUUgxPZcJEV9HTci85eSoKRni446WwvjfnNKf6gYKjHOK3c1msWzn9poJIT123ZsUdKEvFJmZ3ZgRnIFMSh8zICjBerOpDzzdLJPDUHz6mC+IUZCLYnwbPg8edkl66ryGM5RPDy1lx7COLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=GcFO/fEfOsymXnMiuVel8lWqwbXkJhTX9MMXRW15XDnuskPUGLc0Cg9FfoK7uVtAn9rj4+Cc7NETE7He0FUO2qFV5yUWly0wdfXXMRthqAlj+Gqu+7LSdQSfdGvUUNJ+hG1nNEO5YK2cLQQzE/mGv51f2Ixu3qvIQiBLP8qcbHc= Received: by 10.35.86.12 with SMTP id o12mr3293308pyl.1196819932942; Tue, 04 Dec 2007 17:58:52 -0800 (PST) Received: from dhcp-15f0.ietf70.org ( [130.129.21.240]) by mx.google.com with ESMTPS id f24sm9799682pyh.2007.12.04.17.58.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Dec 2007 17:58:52 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT Agenda So far Date: Wed, 5 Dec 2007 02:58:50 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <3A468644-B1D4-4096-AFC7-89192CBA410D@it.uc3m.es> In-Reply-To: <3A468644-B1D4-4096-AFC7-89192CBA410D@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712050258.50855.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, We had no time to go through all of the presentations planned for our first session today. Three presentations were therefore moved to our second session on Friday. The changes are reflected into our agenda () and copied below for your convenience. --julien ------------------------------------------------------------------------ Session: FRIDAY, December 7, 2007 0900-1130 Morning Session I o Additional Work Items to be considered for MEXT - Binding Revocation for IPv6 Mobility Ahmad Muhanna - 10 min draft-muhanna-mip6-binding-revocation-02.txt - Additional NEMO global deployment tools Thierry Ernst - 10 min no draft - RFC 3775 update Vijay Devarapalli - 10 min - MIPv6 home link operation in various SDOs Vijay Devarapalli - 15 min no draft yet - IP Tunneling Optimization in a Mobile Environment Wassim Haddad - 5 min draft-haddad-mip6-tunneling-optimization-01 - Generic Notification Message for Mobile IPv6 Sri Gundavelli - 10 min draft-ietf-mip6-generic-notification-message-00.txt - GRE requirements for IPv6 mobility Sri Gundavelli - 10 min no draft - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions Hi Deng - 5 min draft-qi-mip6-ikev2-interfacing-01 - Virtual Home Link configuration for Mobile IPv6 Sri Gundavelli - 5 min draft-wakikawa-mip6-no-ndp-02.txt - RFC 4283 bis Chairs - 5 min - draft-devarapalli-mip6-authprotocol-bootstrap Chairs - 5 min - Discussion on new work for MEXT Chairs - 20 min o Other Discussions (depending on the time left from previous discussions) The goal is to obtain feedback from MEXT community - Problem Statement: Diameter Prefix Delegation Application B. Sarikaya - 10 min draft-sarikaya-dime-prefix-delegation-ps-00.txt - EAP-Based Keying for IP Mobility Protocols Gerardo Giarretta - 10 min draft-vidya-eap-usrk-ip-mobility-01 - Limitations exist in IP mobility support applications (NEMO + PMIP) John Zhao - 10 min draft-zhao-nemo-limitations-ps _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From CarmencobwebFlanagan@newsweek.com Wed Dec 05 06:19:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzsHx-0004o5-1C; Wed, 05 Dec 2007 06:19:37 -0500 Received: from 82-35-120-199.cable.ubr01.enfi.blueyonder.co.uk ([82.35.120.199] helo=family) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzsHw-0005eT-N1; Wed, 05 Dec 2007 06:19:36 -0500 Received: from downhill by newsweek.com with SMTP id yHqn9mq62V for ; Wed, 5 Dec 2007 11:19:21 +0000 From: "Gladys Yoder" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvE1-00013R-HS; Wed, 05 Dec 2007 09:27:45 -0500 Received: from cpe-24-93-119-237.columbus.res.rr.com ([24.93.119.237] helo=pc209791820223) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzvE1-0002l4-5n; Wed, 05 Dec 2007 09:27:45 -0500 Received: from meltwater by biblegateway.com with SMTP id OaPrctUs3C for ; Wed, 5 Dec 2007 09:27:32 +0500 From: "Lela Jaramillo" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvRK-0003O4-Rj; Wed, 05 Dec 2007 09:41:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvRK-0003Nz-8g for mext@ietf.org; Wed, 05 Dec 2007 09:41:30 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzvRI-0007RG-AA for mext@ietf.org; Wed, 05 Dec 2007 09:41:30 -0500 Received: (qmail 11131 invoked for bounce); 5 Dec 2007 14:41:26 -0000 Received: from unknown (HELO ?192.168.0.10?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 5 Dec 2007 14:41:26 -0000 Message-Id: <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Teco Boot In-Reply-To: <004501c835d9$40f0fe10$c2d2fa30$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Wed, 5 Dec 2007 15:41:25 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Teco, Before commenting how we could apply already defined protocols to mip6 flow distribution, let me explain further my thoughts to see if we are on the same tracks: On 2007/12/03, at 19:20, Teco Boot wrote: > For evaluating existing specifications for using in the steps that you > described, I think we should look for something that is highly > related. > I think flow specification for QoS handling and tunnel selection is > very > similar. I don't know if this is the case for the other steps. > > QoS reservation for tunneled flows within tunnel and for the tunnel > itself > is somewhat related with tunnel selection. But I think using separate > protocols (e.g. RSVP and BU) is more optimal. > > Some comments inline. > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] >> Verzonden: maandag 3 december 2007 18:39 >> Aan: Teco Boot >> CC: Hannes Tschofenig; mext@ietf.org >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >> >> Hi Teco, >> >> On 2007/11/27, at 10:26, Teco Boot wrote: >>> What I found is: >>> RFC4080 (NSIS Framework): 4.6.1. Flow Identification >>> draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier >>> (PACKET_CLASSIFIER) >>> >>> I think NSIS produced specifications on packet classification should >>> be >>> verified for using for MIP flow distribution / handover also. >>> Maybe RSVP TSPEC is past and NSIS FlowID is future. >> >> From what I understood in the envisionned architecture for flow >> distribution in MEXT (crrect me if I'm wrong): >> >> 1. an entity (could be the HA, or not) distributes policies to the MR >> and possibly the peers (e.g. HA) too, > > I don't know what a policy is. I think you mean a profile for > generating > filter rules. It could be filter rules itself also. A policy is a general information that describes access network preferences, user and operator preferences, security restrictions etc. Application of policy usually results in the definition of filter rules which implement the policy for specific traffic flows. Filter rules are tightly related to the host that creates them, so I don't think filter rules can be distributed by a third-part node, whereas policies, that are more general, can. >> 2. The MR translates them to filter rules according to its current >> environment (available interfaces, path characteristics...), > > MR is MN or HA, correct? The MR or MN translates the policies to filter rules. Other peers (e.g. the HA) can use them later to confront them to the received filter rules from the MR/MN. I don't see a use case where the HA or the CN could translate the MR/ MN's policies to filter rules, maybe someone have one? >> 3. The MR sends those filter rules to the peer (e.g the HA), > > Or HA to MN, correct? Not in this architecture, because the HA does not know what is the MR's environment (e.g. what BIDs he uses on which interface, what are the interfaces characteristics and the characteristics of the network it connects to), and thus cannot create filter rules for the MR. >> 4. The peer enforce those filter rules. > > For a bidirectional tunnel, there are two processes for two > directions, > correct? Of course the MR/MN also enforces the filter rules it has created and sent to the HA/CN. To summarize, in the current mext architecture, the MR creates filter rules from policies (policies received by a third-part node), enforce them, and send them to the HA/CN, the HA/CN can then validate them against the policy, and enforce them. Regards, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 12:37:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyBV-0000IH-OL; Wed, 05 Dec 2007 12:37:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyBU-0000I0-Di for mext@ietf.org; Wed, 05 Dec 2007 12:37:20 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzyBT-0000K0-Kw for mext@ietf.org; Wed, 05 Dec 2007 12:37:20 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id lB5HbHgD023213; Thu, 6 Dec 2007 02:37:18 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lB5HbIH08382; Thu, 6 Dec 2007 02:37:18 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id lB5HbHA07679; Thu, 6 Dec 2007 02:37:17 +0900 (JST) Received: from NW-Sephiroth ([10.238.17.14]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 01:37:00 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Thu, 06 Dec 2007 01:36:52 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Thu, 06 Dec 2007 01:36:52 +0800 From: "Benjamin Lim" To: "'Ivancic, William D. \(GRC-RCN0\)'" Date: Thu, 6 Dec 2007 01:36:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg2o4zYnf1vokJ8TNWLf1cwLZcsnQAv//lA Message-ID: X-OriginalArrivalTime: 05 Dec 2007 17:37:00.0893 (UTC) FILETIME=[711BC8D0:01C83765] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mext@ietf.org Subject: [MEXT] RE: Verifying Multiple CoA Bindings X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Will, Thanks for your comment. I believe that the test packet coming to the MN can be carried in packets that might be able to traverse the firewall (e.g. ICMP packet). Otherwise, the mip6-firewall draft might be employed here. Regards, Benjamin Lim > -----Original Message----- > From: Ivancic, William D. (GRC-RCN0) > [mailto:william.d.ivancic@nasa.gov] > Sent: Wednesday, December 05, 2007 2:29 AM > To: mext@ietf.org; benjamin.limck@sg.panasonic.com > Subject: Verifying Multiple CoA Bindings > > > Benjamin, > > On page 9 last paragraph: > > "To reduce the need for > mobile node to send at least one packet from each > interface, the home > agent could send a notification to a mobile node via one unverified > care-of address and ask the mobile node to respond to the reception > of the notification via another care-of address. " > > This is probably not a workable solution for validating the > CoA Bindings. The security provided by firewalls probably > make this technique unworkable. As my collegue often points > out Security - The Ultimate Denial Of Service - TUDOS! > > Will > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 13:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzCF-0003w9-HK; Wed, 05 Dec 2007 13:42:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzCE-0003vk-4n for mext@ietf.org; Wed, 05 Dec 2007 13:42:10 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzzCD-0001kj-7F for mext@ietf.org; Wed, 05 Dec 2007 13:42:10 -0500 Received: by nz-out-0506.google.com with SMTP id n1so2671344nzf for ; Wed, 05 Dec 2007 10:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5e3jb5Gswt4pz9gCsIU2pA9MlqqN6YqhrgWv6uES4ro=; b=d/19FKOCImRmRkZ7WK/4PgonS1qzw3PySTFcGQIQLH7axVG79TF+UBLTbkCVqbMQwPaRu23IzCXyHe2NbgOSTEmb8BV+2qmy6HkGN6Pk8uhuIU/RuI4zMSdh4w1YetbBUf+VfzTLuIua/Xz4qWwB4axmxgKVykJztdzyyzwmsvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tVW4FeiTaQegfiv6esK+4w0FHUXae8vdBsVxJOi0XXMtRJdI15AmISnoljnpFLIPlSBPtARHDBNWnUSjqMvtDBk129nRY6oKHmoE8gbwaI8xt0Bf5Vq+aHvsucQxp2iiReWHH+BUKuVbUg7XImB/8wip3U3+Q3OW+/NzDObXO2A= Received: by 10.142.100.1 with SMTP id x1mr1169666wfb.1196880128291; Wed, 05 Dec 2007 10:42:08 -0800 (PST) Received: by 10.142.11.11 with HTTP; Wed, 5 Dec 2007 10:42:08 -0800 (PST) Message-ID: Date: Wed, 5 Dec 2007 10:42:08 -0800 From: "George Tsirtsis" To: "marcelo bagnulo braun" Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Julien Laganier , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, Here is my opinion on this future work. Thanks On Nov 29, 2007 3:55 AM, marcelo bagnulo braun wrote: > Hi, > > After the call for new work to be considered for mext, we have > received a set of items to be considered, that we need to discuss. > > MEXT is likely to recharter and add new items to the charter, but our > energy is limited so we need to prioritize and decide what items are > the most relevant to be included in the charter, since it seems hard > to have energy to deal with all of them > > So we would like to ask the WG to comment on the proposed items (or > other items) and explain if they think that we should be investing > effort on them. In order to evaluate these items, we should > understand how important is to work on these items to foster the > adoption and the deployment of MIPv6 and NEMO protocols. > > So at this point, the discussion is two-folded: on one hand we would > like to foster high level discussion on what is needed to foster > mobility protocols deployment and in particular to relate this > discussion with the items that have been proposed so far, and if > needed propose new items for the charter. > > It should be noted that at this point silence does not means > acceptance of the proposed items and that a strong case for adopting > new work is needed, since we need to focus our energy in critical > items needed for protocol deployment. > > ------------------------------------------------------------------------ > ------- > > New items proposed so far: > > > - Binding Revocation Mechanism for IPv6 Mobility > > Define a generic binding revocation mechanism for Mobile IPv6 > and its extensions (e.g. NEMO, Monami6, NETLMM). The > mechanism can be used by any mobility entity that provides > Mobile IP services to a MN (e.g. a > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another > mobility entity that is involved in providing Mobile IP > services to the MN (e.g. a NETLMM MAG) of the termination of > either one, multiple or all bindings for a mobile node. The > mechanism should also allow any mobility entity (e.g. NETLMM > MAG or LMA) to signal the termination of bindings for > multiple mobile nodes via use of a single revocation message. > GT> I think this makes sense and it is well understood issue. The work, however, should be done for MIPv6. Then how PMIPv6 can use it should be done in NETLMM. In other words I would suggest that the PMIPv6 specific sections in the draft should be removed and worked on in NETLMM, if NETLMM has a use for this. > - MIPv6 home link operation in various SDOs > > Many SDOs are considering the use of point-to-point links > between the mobile node and the home agent as a home link for > Mobile IPv6 to avoid the tunneling overhead. Some of these > point-to-point links do not support running neighbor discovery. > Attaching to the home link and returning to the home procedures > need to be analyzed for these point-to-point links, possible > with the use of binding update and binding acknowledgment > messages. > GT> I think there maybe something to do here but the problem space is not clear enough yet. This maybe clearer after the IETF meeting. I would prefer in any case to abstract away from specific SDO issue and try to figure out what is actually missing from our IETF RFCs > > - IP Tunneling Optimization in a Mobile Environment > > The widespread use of different forms of IP tunneling mechanisms in > mobile environment, e.g., MIPv6, > HMIPv6, PMIPv6, has a negative impact on the protocol efficiency > which is translated in the data packet > size, bandwidth usage and battery power consumption. Therefore, a > mechanism which enables removing > the extra header would benefit the mobile node and optimize the > bandwidth usage. > GT>It is not clear to me what this is yet. I will wait for the draft :-) > - Generic Notification Message for Mobile IPv6 > > A proposal for defining generic notification framework that can be > used by the mobility > entities for sending and receiving asynchronous notification messages > was proposed and > the same was adopted by the WG. > GT> What are the use cases for this? The obvious one is Binding Revocation, which could be defined as a Generic Notification with a mobility option indicating a revocation. The Binding Revocation draft at the moment, however, defines its own MH. Is there a plan to change that? If not, what else are these notification supposed to be used for? > - GRE requirements for IPv6 mobility > > A proposal has been made for the use of GRE tunneling mechanism in > Mobile IPv6. The GRE > tunneling support exists in Mobile IPv4 and the proposal is for > extending that functional > capability to Mobile IPv6. Noted uses cases include the ability to > carry any type of > protocol payload in a generic header, the rich GRE header > semantics allowing the exposure > of a service identifier, such as a key that can be used by the > tunnel endpoints for differential > treatment of the carried payload and additionally supported by > other use cases. > GT> Is there a use case for GRE encapsulation for MIPv6? or is this purely for PMIPv6? If the latter, then maybe this should be defined in NETLMM?? > > - 4283bis > > Revised RFC 4283 to extend the subtype field in the Mobile Node > identifier option to include other identifiers like IEEE 802 MAC > address. The only subtype currently reserved is NAI. This may > not be sufficient for all scenarios. > GT>I think this makes sense and should be easy enough. > > - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 > > Existing bootstrapping mechanisms for Mobile IPv6 only address > the use of IKEv2/IPsec for protecting Mobile IPv6 signaling > messages. Bootstrapping a home address and security associations > when RFC 4285 is used are not addressed. This draft describes > bootstrapping mechanisms for using RFC 4285 with Mobile IPv6. > GT> I would prefer not to waste time on this. We already have all this for IKEv2/IPSEC. If someone really needs to document this for 4285 then it could be done as an AD sponsored document. > - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions > > Work on the solution of interface, by which IKEv2 could get the > information from MIPv6 and negotiate or update right IPsec security > associations for MIPv6 when MN bootstrap in foreign network or > handover to new foreign network. > > - RFC 3775 update > > Revise RFC 3775 to fix minor issues and add clarifying test for > issues identified since it was published. The update would be > limited to minor changes and not include any major modifications > to the protocol. > GT> Sure, that should be done > - Additional NEMO global deployment tools > > GT> Marcelo, what is this?? > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 14:06:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzZs-0007Y2-Se; Wed, 05 Dec 2007 14:06:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzZr-0007Xn-6k for mext@ietf.org; Wed, 05 Dec 2007 14:06:35 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzzZq-0003rI-VE for mext@ietf.org; Wed, 05 Dec 2007 14:06:35 -0500 Received: by an-out-0708.google.com with SMTP id d11so1175095and for ; Wed, 05 Dec 2007 11:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=MminKEv1CX6TY5fqLzQDA/MOYqaBaf0r6+LbMRs4faA=; b=VAEIC5cGJFSSr/4lINUhsmpWPyPmqHk119roJBhiNFqcBwh8J0q9x8zG493KnY5zHuDj2cvcpu8MTPuI3yyiWoP6CqP54/0C2qQ53GDYc15hKQL5ZEzSa/EKk5fCQ9htym1x5oDxGlI9r6l89Qx3hJDWv2/QA2qGVySC9E+zTKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=e5KhuRbkQF9ZmtBenQuzHbWz/cbRus7rneljAmOHhaPrf8Xl3P9e5/JN2paIiuJ/Qd2/6efdkvY6LFq0ACaHXlGWnD0eqCQPdqzFOzt8/qHtr8RIEAwqZSXJrBE2VTQ3Yc1rGjtygtTAEgtawHkr4TXi74NVk+gZ/rMz0vT4I00= Received: by 10.100.94.14 with SMTP id r14mr4782484anb.1196881594582; Wed, 05 Dec 2007 11:06:34 -0800 (PST) Received: from dhcp-15f0.ietf70.org ( [130.129.21.240]) by mx.google.com with ESMTPS id d35sm2667333and.2007.12.05.11.06.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2007 11:06:33 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] New items for the mext charter discussion Date: Wed, 5 Dec 2007 20:06:29 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712052006.31332.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, On Wednesday 05 December 2007, George Tsirtsis wrote: > Hi Marcelo, > > Here is my opinion on this future work. Thanks > > [...] > > > - Additional NEMO global deployment tools > > GT> Marcelo, what is this?? This would include new mechanisms for large scale deployments of NEMO. It is unclear what needs be done in that space, hence the discussion. One _example_ mechanism I can think of is, e.g., an inter Home Agents protocol. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 14:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzziE-0006wD-T9; Wed, 05 Dec 2007 14:15:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzziD-0006vY-BK for mext@ietf.org; Wed, 05 Dec 2007 14:15:13 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzziB-0004a1-Hy for mext@ietf.org; Wed, 05 Dec 2007 14:15:13 -0500 Received: by rv-out-0910.google.com with SMTP id l15so3531386rvb for ; Wed, 05 Dec 2007 11:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YIxVEfrISrfNxdzEu53YYmML7sho7H3AttLURB1awSM=; b=nlkmoiepC3EIDLh7nvyW2WdJ4WY96gJmJ0NfO/+hotW9VSFvgtvoqRHn9CyPuADcz9Db+a8rQYxrSoGUEiiQb958A+TCS6a3EJVI0cCjV+wRWTqiuoOaSggTUBcsP41nRtwgSOydC+qisLME/anIgzmIUebJSVqC9rg/kWvVwt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sf7aNDw5GrcmFgkyl9ufSf8N3Owa6x45zAfN9Sb3uKpeoEp6yz0lNGJNWezIYLoNSx9eZUIzYvyG0+4umJwAYJqdpUvOwGJKo0FTR+BE7XYUKsUjy2Pc4pClOqV+WbeBE4h0mCTbA40G3iWjbpBy/nFUqofQTf1W+nYjsphBewE= Received: by 10.142.225.11 with SMTP id x11mr1209298wfg.1196882101650; Wed, 05 Dec 2007 11:15:01 -0800 (PST) Received: by 10.142.11.11 with HTTP; Wed, 5 Dec 2007 11:15:01 -0800 (PST) Message-ID: Date: Wed, 5 Dec 2007 11:15:01 -0800 From: "George Tsirtsis" To: "Keigo Aso" Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: <20071204062837.0CE9.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4744BE6F.5040408@azairenet.com> <20071204062837.0CE9.ASOU.KEIGO@jp.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, I think we should keep things simple and do the following. Abandon the homeCoA idea because although it technically works, it is also more complex. Instead we can define a BU format that indicates to the HA that the MN is attached to the home link but it does not de-register (i.e., bindings to foreign links are still maintained). For example we could set CoA==HoA and Lifetime==infinite or some other variant of this. This seems to be the simplest approach since it does not impact the pNDP operation of the HA i.e., If the HA was configured to run pNDP (e.g., shared links) then it continues to do so; If the HA was not configured to run pNDP (e.g., p2p links) then it continues to not run pNDP. Does anyone see a problem with this approach? Regards George On Dec 3, 2007 4:22 PM, Keigo Aso wrote: > Hi all, > > Let me summarize the returning home approaches we have discussed so far. > Hopefully this would be used for the preparation for hearing Ryuji's > presentation tomorrow. > > There are two cases on HA configuration we should consider. One is HA is a > router case, another is HA is a host case. > When HA is a router, as we all already understand, there is no issue because HA > can intercept packets for MN's HoA without Proxy NDP and MN can run NDP for own > HoA on the home link. > Only needed for this is HA has to know that MN is at home in order to make the > home binding. Actually the current MCoA draft already introduced the solution > for this, which is MN uses 'H' flag in BU to notify that it is attaching to the > home link also toghether with the CoA for the foreign binding. > > While, when HA is a host case, HA has to run Proxy ND for intercepting packets > for MN's HoA. So, in this case, MN can not notify L2 address to the HA. For this > case there is a approach which is MN sends BU including L2 address. This may be > useful for the case HA is a router. > > Furthermore, there is another good approach for this case, which is using > another CoA in the home link. If MN can create a CoA in the home link which is > different from own HoA, it can register it with 'H' flag for making the home > binding to the HA. Therefore, HA can run Proxy NDP for MN's HoA, while MN can > notify L2 address by running NDP for this CoA. In this approach, its CoA could > be the address which is made from own home prefix(HomeCoA). While if there is > another prefix in the home network, it is used for making the CoA. When using > other prefix, it would need operational stuff for HA and other MNs on the home > link. > > Regards, > Keigo > > On Sun, 25 Nov 2007 02:53:02 +0900 > Ryuji Wakikawa wrote: > > > > Hi George and Vijay, > > > > Question is whether we should support DSMIP in this document. > > It seems reasonable to support DSMIP. > > We can easily extend BID sub-option to cary both IPv4/IPv6 addresses. > > > > regards, > > ryuji > > > > > > > > On 2007/11/22, at 8:25, Vijay Devarapalli wrote: > > > > > George Tsirtsis wrote: > > > > > >> 7) Interactions with DSMIPv6. I think at some point a new section > > >> needs to be added to talk about interactions with DSMIPv6. Beyond > > >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the > > >> MCoA draft includes some interactions with IKEv2 > > > > > > I think the IKEv2 interactions are inline with what we decided for > > > DS-MIPv6 last week. Transport mode IPsec SA for the binding update, > > > and tunnel mode SAs updated either by MIPv6 (K flag) or running > > > IKEv2 again. > > > > > > and imposes some requirements to the use of > > >> alternate-CoA which may or may not conflict with DSMIPv6 (have not > > >> checked that myself yet). > > > > > > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not > > > related to the alt CoA option in RFC 3775. > > > draft-ietf-monami6-multiplecoa says the alt CoA option should not > > > be included whenever the CoA is carried in the BID mobility option. > > > > > > The BID option as defined in the draft currently seems to allow > > > only for an IPv6 address. I think, we need to extend the BID option > > > to carry an IPv4 or an IPv6 address. > > > > > > Vijay > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JaimefifteenWade@apache.org Wed Dec 05 15:55:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01Ha-0007GY-3i; Wed, 05 Dec 2007 15:55:50 -0500 Received: from [189.130.192.109] (helo=machine6) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J01HV-0006Ww-10; Wed, 05 Dec 2007 15:55:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host54665212.apache.org (8.13.1/8.13.1) with SMTP id yKqmb5fc78.783467.Kkm.15E.4223931823301 for ; Wed, 5 Dec 2007 14:55:10 +0600 Message-ID: <23491601c83781$2ea8ea70$2701a8c0@machine6> From: "Alberto Curtis" To: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_234912_01C83781.2EA8EA70-- From DouggalvestonValdez@annapolissailing.com Wed Dec 05 16:29:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01oI-0007Up-MP; Wed, 05 Dec 2007 16:29:38 -0500 Received: from c-75-74-220-31.hsd1.fl.comcast.net ([75.74.220.31] helo=preferre9e7aed.hsd1.fl.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J01oI-0001Pn-Dn; Wed, 05 Dec 2007 16:29:38 -0500 Received: from allotted by annapolissailing.com with SMTP id LIZk1axN1M for ; Wed, 5 Dec 2007 16:29:19 +0500 From: "Doug Barber" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J020e-00061S-Co; Wed, 05 Dec 2007 16:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J020d-00061B-6r for mext@ietf.org; Wed, 05 Dec 2007 16:42:23 -0500 Received: from g1t0029.austin.hp.com ([15.216.28.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J020c-0006SR-Rz for mext@ietf.org; Wed, 05 Dec 2007 16:42:23 -0500 Received: from g1t0029.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 840153805F; Wed, 5 Dec 2007 21:42:22 +0000 (UTC) Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by g1t0029.austin.hp.com (Postfix) with ESMTP id 6F01C3800A; Wed, 5 Dec 2007 21:42:22 +0000 (UTC) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id B74BC1DEA0A; Wed, 5 Dec 2007 21:42:21 +0000 (UTC) Message-ID: <47571B3B.3020902@hp.com> Date: Wed, 05 Dec 2007 16:42:19 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: George Tsirtsis Subject: Re: [MEXT] New items for the mext charter discussion References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, George Tsirtsis wrote: >> - Generic Notification Message for Mobile IPv6 >> >> A proposal for defining generic notification framework that can be >> used by the mobility >> entities for sending and receiving asynchronous notification messages >> was proposed and >> the same was adopted by the WG. >> > > GT> What are the use cases for this? The obvious one is Binding > Revocation, which could be defined as a Generic Notification with a > mobility option indicating a revocation. The Binding Revocation draft > at the moment, however, defines its own MH. Is there a plan to change > that? If not, what else are these notification supposed to be used > for? Binding Revocation was one of the intended users, there was a discussion to this effect months ago on the mip6 list that I won't re-hash. Sri has a time slot on Friday to talk about this work. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 16:45:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J023l-000779-Ls; Wed, 05 Dec 2007 16:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J023k-00076u-RR for mext@ietf.org; Wed, 05 Dec 2007 16:45:36 -0500 Received: from hs-out-0708.google.com ([64.233.178.244] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J023i-0006qh-GO for mext@ietf.org; Wed, 05 Dec 2007 16:45:36 -0500 Received: by hs-out-2122.google.com with SMTP id 54so517607hsz for ; Wed, 05 Dec 2007 13:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kVtbz7DguUW4dtv0GPimBPaWI98oLo5E5bouKjoQGvg=; b=jSiZEJdLOyG8Ln/sSfzNGW2+rDlXxWK8e3YSe0AzHu/xbiyyIbyfOCYfiUvVKqMt6Bu95kfpHLHYhY3bKd8/V9WIBV1fZo5na/2ovJgBwhwMytb3w0zMTc2piZy3Mg8O3r1B7Je8chRMSC28jc71Df1J3x3CuebDXDgmGHzmZKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z4+RTPoz+wnstyYnEfGccXFeEIro3FxJ+TSNKQv1IydDDV1TikSrwv7aYng8i8KAgzipunpDkTVmv8hFGsrw4Ts4ylXHCJ0i4Ql0wDxq0fKzHC7vhXc7Z25pWgN2I3g2AROXHBt9eDm3K1s/VcU7cQcZnuxFJfraPn8qbCOz4VU= Received: by 10.142.135.9 with SMTP id i9mr257746wfd.1196891132984; Wed, 05 Dec 2007 13:45:32 -0800 (PST) Received: by 10.142.11.11 with HTTP; Wed, 5 Dec 2007 13:45:32 -0800 (PST) Message-ID: Date: Wed, 5 Dec 2007 13:45:32 -0800 From: "George Tsirtsis" To: "Brian Haley" Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: <47571B3B.3020902@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> <47571B3B.3020902@hp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org OK, will wait for that. Thanks. George On Dec 5, 2007 1:42 PM, Brian Haley wrote: > Hi George, > > George Tsirtsis wrote: > >> - Generic Notification Message for Mobile IPv6 > >> > >> A proposal for defining generic notification framework that can be > >> used by the mobility > >> entities for sending and receiving asynchronous notification messages > >> was proposed and > >> the same was adopted by the WG. > >> > > > > GT> What are the use cases for this? The obvious one is Binding > > Revocation, which could be defined as a Generic Notification with a > > mobility option indicating a revocation. The Binding Revocation draft > > at the moment, however, defines its own MH. Is there a plan to change > > that? If not, what else are these notification supposed to be used > > for? > > Binding Revocation was one of the intended users, there was a discussion > to this effect months ago on the mip6 list that I won't re-hash. Sri > has a time slot on Friday to talk about this work. > > -Brian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 17:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02tO-0000is-KG; Wed, 05 Dec 2007 17:38:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02tN-0000i2-QE for mext@ietf.org; Wed, 05 Dec 2007 17:38:57 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J02tN-0000UP-3k for mext@ietf.org; Wed, 05 Dec 2007 17:38:57 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1196894335!9917005!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 7495 invoked from network); 5 Dec 2007 22:38:55 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-2.tower-128.messagelabs.com with SMTP; 5 Dec 2007 22:38:55 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB5Mck5h008156; Wed, 5 Dec 2007 15:38:46 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lB5Mcj91012458; Wed, 5 Dec 2007 16:38:45 -0600 (CST) Received: from [127.0.0.1] ([10.19.240.238]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB5Mcgsb012431; Wed, 5 Dec 2007 16:38:43 -0600 (CST) Message-ID: <47572872.8090603@gmail.com> Date: Wed, 05 Dec 2007 14:38:42 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: George Tsirtsis Subject: Re: [MEXT] New items for the mext charter discussion References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org George Tsirtsis wrote: [...] >> - RFC 3775 update >> >> Revise RFC 3775 to fix minor issues and add clarifying test for >> issues identified since it was published. The update would be >> limited to minor changes and not include any major modifications >> to the protocol. >> > > GT> Sure, that should be done It's most important to me, and looking forward for Vijay's presentation on this topic and its width. >> - Additional NEMO global deployment tools >> >> > > GT> Marcelo, what is this?? Marcelo? It could be a container for bakeoff reports? Judging by Thierry upcoming presentation slides it could be: RO is needed. (http://www3.ietf.org/proceedings/07dec/slides/mext-5.pdf) It could be the need to dynamically allocate prefixes for use in moving networks. It could be a report of new MIP6/NEMO tools such as HAiku. What is this? My impression is it looks as a container for reports at meetings like results of bakeoff, or similar. I think we'll see probably such a presentation from Thierry Ernst now. I think there may be some new tools. I haven't seen Thierry's slides but curious. Tools for deploying NEMO may also mean this necessity to dynamically allocate a prefix for use in the moving network. > >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AbelfractiousSingleton@ielanguages.com Wed Dec 05 17:43:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02xq-0002YV-Id; Wed, 05 Dec 2007 17:43:34 -0500 Received: from [190.49.98.76] (helo=desktop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J02xq-0000wL-5E; Wed, 05 Dec 2007 17:43:34 -0500 Received: from jenkins by ielanguages.com with SMTP id jaKtgZmdLQ for ; Wed, 5 Dec 2007 19:44:27 -0100 From: "Toby Summers" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Je-0006sg-BB; Wed, 05 Dec 2007 18:06:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03Jc-0006nI-Jy for mext@ietf.org; Wed, 05 Dec 2007 18:06:04 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J03Jb-0006yP-K6 for mext@ietf.org; Wed, 05 Dec 2007 18:06:04 -0500 Received: (qmail 29081 invoked from network); 6 Dec 2007 00:06:01 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 00:06:01 +0100 From: "Teco Boot" To: "'Romain KUNTZ'" References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> In-Reply-To: <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Thu, 6 Dec 2007 00:05:26 +0100 Message-ID: <008f01c83793$65e92ec0$31bb8c40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg3TPxMDcFN827bQtufUJy7bW+q8gACWMcg Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > -----Oorspronkelijk bericht----- > Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > Verzonden: woensdag 5 december 2007 15:41 > Aan: Teco Boot > CC: 'Hannes Tschofenig'; mext@ietf.org > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > Hi Teco, > > Before commenting how we could apply already defined protocols to mip6 > flow distribution, let me explain further my thoughts to see if we are > on the same tracks: OK, comments inline. > > On 2007/12/03, at 19:20, Teco Boot wrote: > > For evaluating existing specifications for using in the steps that > you > > described, I think we should look for something that is highly > > related. > > I think flow specification for QoS handling and tunnel selection is > > very > > similar. I don't know if this is the case for the other steps. > > > > QoS reservation for tunneled flows within tunnel and for the tunnel > > itself > > is somewhat related with tunnel selection. But I think using separate > > protocols (e.g. RSVP and BU) is more optimal. > > > > Some comments inline. > > > > Teco. > > > >> -----Oorspronkelijk bericht----- > >> Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > >> Verzonden: maandag 3 december 2007 18:39 > >> Aan: Teco Boot > >> CC: Hannes Tschofenig; mext@ietf.org > >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > >> > >> Hi Teco, > >> > >> On 2007/11/27, at 10:26, Teco Boot wrote: > >>> What I found is: > >>> RFC4080 (NSIS Framework): 4.6.1. Flow Identification > >>> draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier > >>> (PACKET_CLASSIFIER) > >>> > >>> I think NSIS produced specifications on packet classification > should > >>> be > >>> verified for using for MIP flow distribution / handover also. > >>> Maybe RSVP TSPEC is past and NSIS FlowID is future. > >> > >> From what I understood in the envisionned architecture for flow > >> distribution in MEXT (crrect me if I'm wrong): > >> > >> 1. an entity (could be the HA, or not) distributes policies to the > MR > >> and possibly the peers (e.g. HA) too, > > > > I don't know what a policy is. I think you mean a profile for > > generating > > filter rules. It could be filter rules itself also. > > A policy is a general information that describes access network > preferences, user and > operator preferences, security restrictions etc. Monami6 policy is defined in larsson-monami6-filter-rules. I am fine with your explanation. > Application of policy > usually results in the definition of filter rules which implement the > policy for specific traffic flows. > > Filter rules are tightly related to the host that creates them, so I > don't think filter rules can be distributed by a third-part node, > whereas policies, that are more general, can. Ok. > >> 2. The MR translates them to filter rules according to its current > >> environment (available interfaces, path characteristics...), > > > > MR is MN or HA, correct? > > The MR or MN translates the policies to filter rules. Other peers > (e.g. the HA) can use them later to confront them to the received > filter rules from the MR/MN. > > I don't see a use case where the HA or the CN could translate the MR/ > MN's policies to filter rules, maybe someone have one? I prefer using MN, this is MN (MIPv6) or MR (NEMO). I am not sure the MN generates the filter for peer (HA, CN) in all cases. For example, HA / CN may have other policies. I think this is getting complex and we should work out the basic approach first, that MN generate the filter for both itself and for peer. I remember someone brought up the HA generate filters in Chicago. Maybe it was policies. Not in minutes. > >> 3. The MR sends those filter rules to the peer (e.g the HA), > > > > Or HA to MN, correct? > > Not in this architecture, because the HA does not know what is the > MR's environment (e.g. what BIDs he uses on which interface, what are > the interfaces characteristics and the characteristics of the network > it connects to), and thus cannot create filter rules for the MR. Same as above. I do not understand why HA cannot create a filter. It is not about BIDs of interfaces, it is only the filter rules. Again, not a discussion for today. > > >> 4. The peer enforce those filter rules. > > > > For a bidirectional tunnel, there are two processes for two > > directions, > > correct? > > Of course the MR/MN also enforces the filter rules it has created and > sent to the HA/CN. OK. > > To summarize, in the current mext architecture, the MR creates filter > rules from policies (policies received by a third-part node), enforce > them, and send them to the HA/CN, the HA/CN can then validate them > against the policy, and enforce them. OK, we are on same track. Now we can make the next step, checking existing specifications for the filter rules. I like to see references to documents with page numbers or section numbers. We have already: draft-soliman-monami6-flow-binding-04.txt 3.1. Flow Identification option "PF: The OpenBSD Packet Filter" . RSVP Filterspec (somewhere in RFC2205) NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) Teco. > > Regards, > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 19:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04KI-0007FT-EX; Wed, 05 Dec 2007 19:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04KG-0007Dw-V9 for mext@ietf.org; Wed, 05 Dec 2007 19:10:48 -0500 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J04KG-0004gV-9M for mext@ietf.org; Wed, 05 Dec 2007 19:10:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id A4282EC9AD; Thu, 6 Dec 2007 09:10:46 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id 48416EC9A2; Thu, 6 Dec 2007 09:10:46 +0900 (JST) Received: from [127.0.0.1] (c022.vpn.kddilabs.jp [172.19.87.22]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id B42F26900E0; Thu, 6 Dec 2007 09:10:44 +0900 (JST) Message-ID: <47573DEA.7090803@kddilabs.jp> Date: Thu, 06 Dec 2007 09:10:18 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> In-Reply-To: <008f01c83793$65e92ec0$31bb8c40$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -1.4 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Teco, Teco Boot Wrote: [...] >>>> 2. The MR translates them to filter rules according to its current >>>> environment (available interfaces, path characteristics...), >>> MR is MN or HA, correct? >> The MR or MN translates the policies to filter rules. Other peers >> (e.g. the HA) can use them later to confront them to the received >> filter rules from the MR/MN. >> >> I don't see a use case where the HA or the CN could translate the MR/ >> MN's policies to filter rules, maybe someone have one? > > I prefer using MN, this is MN (MIPv6) or MR (NEMO). > > I am not sure the MN generates the filter for peer (HA, CN) in all cases. > For example, HA / CN may have other policies. I think this is getting > complex and we should work out the basic approach first, that MN generate > the filter for both itself and for peer. > > I remember someone brought up the HA generate filters in Chicago. Maybe it > was policies. Not in minutes. Maybe I said. I think there is a case that an administrator of HA such as a network operator wants to modify policies of MN for network congestion control. In this case, HA translates own policies to filter rules according to current environment of MN and enforce them. Regards, Kazuyuki. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 19:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04am-0002Ey-Rq; Wed, 05 Dec 2007 19:27:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J04al-0002EV-9o for mext@ietf.org; Wed, 05 Dec 2007 19:27:51 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J04ak-0002yR-HV for mext@ietf.org; Wed, 05 Dec 2007 19:27:51 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 076C4280339 for ; Thu, 6 Dec 2007 01:27:48 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mext@ietf.org Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 01:27:46 +0100 Message-Id: <1196900866.27208.117.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [MEXT] Comments on draft-ng-nemo-ce-req-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1815466826==" Errors-To: mext-bounces@ietf.org --===============1815466826== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oqcDlxYu18mVYbUzBmhR" --=-oqcDlxYu18mVYbUzBmhR Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, I've read the draft and I have some questions/comments: - (general comment) I've honestly always have doubts about the feasibility of real deployments of LMMs. In the scenario described in the draft, a laptop or WLAN-enabled PDA can break off from the personal area network and the connect to the Internet on its own. To do that, is the HA of that node located on the mobile network? If so, given the particular characteristics of this mobile network (it is a PAN, can present discontinuos connectivity), the laptop may experience connectivity problems as that connectivity would depend on the PAN reachability. If a different deployment is possible (e.g., the HA located at the Home Network of the MR, not on the NEMO itself), then I'm fine. - In the scenario described in Figure 6, how do you LFNs on the Car Sensors network from configuring an IP address from the MNP of the PAN and using this as source address for communications with CNs in the Internet. If the PAN detaches, these communications would break, right?=20 - Regarding the requirements, I find some of them vague. For example, Req2: Low Processing Load, what does "increase the processing load of the MR significantly" mean? is linear increase with the number of nodes/communications Route Optimised/etc acceptable? You might consider also include a requirement regarding signalling load. - I'd consider adding a requirement regarding modification of correspondent nodes. Another thing that does not seem completely clear to me is: to which devices RO should be provided? only LFNs and LMNs or also VMNs?. - Do you want to be able to enable RO for some nodes and use plan NEMO B.S. for others? I think this is called separability in other requirements drafts. - For the MR-to-MR optimisation, is there any difference -- significant for the personal MR scenario -- when the MRs are attached to the same link vs the general case? Well, I might come up with more comments later on. Thanks for writing this draft. Regards, Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-oqcDlxYu18mVYbUzBmhR Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHV0ICNdy6TdFwT2cRAnvHAKCWuln5cJhMiHiFpvqPl3UE5jxBvQCgr3yK rJ9rhr71LKoSZv0xRi528f8= =DBuJ -----END PGP SIGNATURE----- --=-oqcDlxYu18mVYbUzBmhR-- --===============1815466826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1815466826==-- From mext-bounces@ietf.org Wed Dec 05 19:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J050W-0008Bf-3J; Wed, 05 Dec 2007 19:54:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J050U-0008Aa-JA for mext@ietf.org; Wed, 05 Dec 2007 19:54:26 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J050T-0005Ik-Hr for mext@ietf.org; Wed, 05 Dec 2007 19:54:26 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB60sMlr024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2007 16:54:23 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB60sKqi020091; Wed, 5 Dec 2007 16:54:22 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 16:54:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] New items for the mext charter discussion Date: Wed, 5 Dec 2007 16:53:47 -0800 Message-ID: In-Reply-To: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: AcgyftMIzGv+UPyASF6VFUVIv41usAFIcXGg References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> From: "Narayanan, Vidya" To: "marcelo bagnulo braun" , X-OriginalArrivalTime: 06 Dec 2007 00:54:20.0767 (UTC) FILETIME=[894ACEF0:01C837A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, Some thoughts inline. =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@bagnulo.net]=20 > Sent: Thursday, November 29, 2007 3:56 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] New items for the mext charter discussion >=20 > Hi, >=20 > After the call for new work to be considered for mext, we=20 > have received a set of items to be considered, that we need=20 > to discuss. >=20 > MEXT is likely to recharter and add new items to the charter,=20 > but our energy is limited so we need to prioritize and decide=20 > what items are the most relevant to be included in the=20 > charter, since it seems hard to have energy to deal with all of them >=20 > So we would like to ask the WG to comment on the proposed=20 > items (or other items) and explain if they think that we=20 > should be investing effort on them. In order to evaluate=20 > these items, we should understand how important is to work on=20 > these items to foster the adoption and the deployment of=20 > MIPv6 and NEMO protocols. >=20 > So at this point, the discussion is two-folded: on one hand=20 > we would like to foster high level discussion on what is=20 > needed to foster mobility protocols deployment and in=20 > particular to relate this discussion with the items that have=20 > been proposed so far, and if needed propose new items for the charter. >=20 > It should be noted that at this point silence does not means=20 > acceptance of the proposed items and that a strong case for=20 > adopting new work is needed, since we need to focus our=20 > energy in critical items needed for protocol deployment. >=20 > -------------------------------------------------------------- > ---------- > ------- >=20 > New items proposed so far: >=20 >=20 > - Binding Revocation Mechanism for IPv6 Mobility >=20 > Define a generic binding revocation mechanism for Mobile IPv6=20 > and its extensions (e.g. NEMO, Monami6, NETLMM). The=20 > mechanism can be used by any mobility entity that provides=20 > Mobile IP services to a MN (e.g. a > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another=20 > mobility entity that is involved in providing Mobile IP=20 > services to the MN (e.g. a NETLMM MAG) of the termination of=20 > either one, multiple or all bindings for a mobile node. The=20 > mechanism should also allow any mobility entity (e.g. NETLMM=20 > MAG or LMA) to signal the termination of bindings for=20 > multiple mobile nodes via use of a single revocation message. >=20 I can see the use case for binding revocation in NETLMM, but, I'm not seeing it for MIP6. I think this came up as part of the WG discussions on this topic earlier and I didn't see a practical reason why binding revocation is needed for MIP6. For non-administrative reasons due to which bindings need to be moved out of an HA, the HA switch draft does the work. If the reasons are administrative, it then implies managed networks and in all those cases, network access will (and should) be blocked for the MN even before the binding revocation message can get to it. =20 > - MIPv6 home link operation in various SDOs >=20 > Many SDOs are considering the use of point-to-point links=20 > between the mobile node and the home agent as a home link for=20 > Mobile IPv6 to avoid the tunneling overhead. Some of these=20 > point-to-point links do not support running neighbor discovery. > Attaching to the home link and returning to the home=20 > procedures need to be analyzed for these point-to-point=20 > links, possible with the use of binding update and binding=20 > acknowledgment messages. >=20 Not sure about this yet. =20 >=20 > - IP Tunneling Optimization in a Mobile Environment >=20 > The widespread use of different forms of IP tunneling=20 > mechanisms in mobile environment, e.g., MIPv6, HMIPv6,=20 > PMIPv6, has a negative impact on the protocol efficiency=20 > which is translated in the data packet size, bandwidth usage=20 > and battery power consumption. Therefore, a mechanism which=20 > enables removing the extra header would benefit the mobile=20 > node and optimize the bandwidth usage. >=20 Seems useful, although, typically, it is the last hop that is the most sensitive to this and ROHC can address this on the last hop. Is there a reason we think this problem needs to be solved e2e between the MN and HA?=20 > - Generic Notification Message for Mobile IPv6 >=20 > A proposal for defining generic notification framework that=20 > can be used by the mobility entities for sending and=20 > receiving asynchronous notification messages was proposed and=20 > the same was adopted by the WG. >=20 Neutral on this, but, can see the use for it.=20 > - GRE requirements for IPv6 mobility >=20 > A proposal has been made for the use of GRE tunneling=20 > mechanism in Mobile IPv6. The GRE > tunneling support exists in Mobile IPv4 and the proposal=20 > is for extending that functional > capability to Mobile IPv6. Noted uses cases include the=20 > ability to carry any type of > protocol payload in a generic header, the rich GRE header=20 > semantics allowing the exposure > of a service identifier, such as a key that can be used by=20 > the tunnel endpoints for differential > treatment of the carried payload and additionally=20 > supported by other use cases. >=20 Don't see any use for this. I don't know why we need to replicate all MIP4 functionalities in MIP6 - in MIP4, GRE helps dealing with overlapping IP spaces. In the IPv6 world, I don't see why that is needed. =20 >=20 > - 4283bis >=20 > Revised RFC 4283 to extend the subtype field in the Mobile=20 > Node identifier option to include other identifiers like IEEE=20 > 802 MAC address. The only subtype currently reserved is NAI.=20 > This may not be sufficient for all scenarios. >=20 I think this is useful. I also think that we should open up assignment of new values totally or by IETF consensus and remove the restriction of standards action.=20 >=20 > - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 >=20 > Existing bootstrapping mechanisms for Mobile IPv6 only=20 > address the use of IKEv2/IPsec for protecting Mobile IPv6=20 > signaling messages. Bootstrapping a home address and security=20 > associations when RFC 4285 is used are not addressed. This=20 > draft describes bootstrapping mechanisms for using RFC 4285=20 > with Mobile IPv6. >=20 I don't think the WG should work on this. =20 > - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions >=20 > Work on the solution of interface, by which IKEv2 could get=20 > the information from MIPv6 and negotiate or update right=20 > IPsec security associations for MIPv6 when MN bootstrap in=20 > foreign network or handover to new foreign network. >=20 Neutral. If this work is done, I don't think it should be mandatory to implement. Having an optionally standardized mechanism doesn't seem to hurt.=20 > - RFC 3775 update >=20 > Revise RFC 3775 to fix minor issues and add clarifying test=20 > for issues identified since it was published. The update=20 > would be limited to minor changes and not include any major=20 > modifications to the protocol. >=20 Obviously important, but, I tend to agree with Hesham that we should wait on this.=20 > - Additional NEMO global deployment tools >=20 Neutral.=20 Thanks, Vidya >=20 >=20 > =20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 20:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J059n-0004nB-OV; Wed, 05 Dec 2007 20:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J059l-0004ge-V1 for mext@ietf.org; Wed, 05 Dec 2007 20:04:01 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J059l-0000rC-Ke for mext@ietf.org; Wed, 05 Dec 2007 20:04:01 -0500 X-AuditID: c0a8013c-acf21bb000001e2e-7d-47574a7fc44a Received: from PC20005 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id ADB364DC009; Wed, 5 Dec 2007 18:03:58 -0700 (MST) From: "Hesham Soliman" To: "'Narayanan, Vidya'" , "'marcelo bagnulo braun'" , Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 6 Dec 2007 12:03:40 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgyftMIzGv+UPyASF6VFUVIv41usAFIcXGgAALDcPA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Julien Laganier' X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vidya, I agree with almost all of your comments, with one exception below. > > - IP Tunneling Optimization in a Mobile Environment > > > > The widespread use of different forms of IP tunneling > > mechanisms in mobile environment, e.g., MIPv6, HMIPv6, > > PMIPv6, has a negative impact on the protocol efficiency > > which is translated in the data packet size, bandwidth usage > > and battery power consumption. Therefore, a mechanism which > > enables removing the extra header would benefit the mobile > > node and optimize the bandwidth usage. > > > > Seems useful, although, typically, it is the last hop that > is the most > sensitive to this => Agreed. Although some people might argue for backhauls from the BS. and ROHC can address this on the last hop. > Is there a > reason we think this problem needs to be solved e2e between > the MN and > HA? > => ROHC has several limitations. One of them is that it works on p2p links. Another is it's complexity of course. This solution is independent of the link layer, which is good. Even when combined with ROHC it can easily address the triple header scenarios. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 20:11:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05H2-0002Tt-3i; Wed, 05 Dec 2007 20:11:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05H0-0002Kh-GB for mext@ietf.org; Wed, 05 Dec 2007 20:11:30 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J05H0-0006lE-2i for mext@ietf.org; Wed, 05 Dec 2007 20:11:30 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lB619gPS007687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Dec 2007 17:09:43 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lB619gXY023775; Wed, 5 Dec 2007 17:09:42 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Dec 2007 17:09:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] New items for the mext charter discussion Date: Wed, 5 Dec 2007 17:09:19 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: AcgyftMIzGv+UPyASF6VFUVIv41usAFIcXGgAALDcPAAAeKd4A== References: From: "Narayanan, Vidya" To: "Hesham Soliman" , "marcelo bagnulo braun" , X-OriginalArrivalTime: 06 Dec 2007 01:09:24.0820 (UTC) FILETIME=[A4265940:01C837A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Hesham, =20 >=20 > =3D> ROHC has several limitations. One of them is that it works=20 > on p2p links. > Another is it's complexity of course. This solution is=20 > independent of the link layer, which is good. Even when=20 > combined with ROHC it can easily address the triple header scenarios.=20 >=20 Okay, I'm speaking prematurely, since I haven't looked at the draft yet :) I was trying to understand where we see the use. Even from the p2p perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP tunnel is a virtual p2p link. That is philosophy behind the ongoing work on ROHC for IPsec. But, I'll take a look at the draft first (I assume there is one :)).=20 Vidya _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 20:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05Ja-00068B-D8; Wed, 05 Dec 2007 20:14:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05JZ-00067z-Fm for mext@ietf.org; Wed, 05 Dec 2007 20:14:09 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J05JZ-0001gI-7M for mext@ietf.org; Wed, 05 Dec 2007 20:14:09 -0500 X-AuditID: c0a8013c-ae724bb000001e2e-33-47574cde541d Received: from PC20005 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 5DDC34DC017; Wed, 5 Dec 2007 18:14:03 -0700 (MST) From: "Hesham Soliman" To: "'Narayanan, Vidya'" , "'marcelo bagnulo braun'" , Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 6 Dec 2007 12:13:42 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgyftMIzGv+UPyASF6VFUVIv41usAFIcXGgAALDcPAAAeKd4AABaarg X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'Julien Laganier' X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > > > => ROHC has several limitations. One of them is that it works > > on p2p links. > > Another is it's complexity of course. This solution is > > independent of the link layer, which is good. Even when > > combined with ROHC it can easily address the triple header > scenarios. > > > > Okay, I'm speaking prematurely, since I haven't looked at > the draft yet > :) I was trying to understand where we see the use. Even > from the p2p > perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP > tunnel is a virtual p2p link. => Yes you can, but it's very very complex compared to Wassim's draft IMO. Hesham That is philosophy behind the ongoing > work on ROHC for IPsec. But, I'll take a look at the draft first (I > assume there is one :)). > > Vidya > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 20:17:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05N6-0000c8-Jf; Wed, 05 Dec 2007 20:17:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05N5-0000Yw-8g for mext@ietf.org; Wed, 05 Dec 2007 20:17:47 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J05N4-0007MW-LU for mext@ietf.org; Wed, 05 Dec 2007 20:17:47 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1196903865!5494917!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4537 invoked from network); 6 Dec 2007 01:17:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 6 Dec 2007 01:17:45 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB61HjBG020037; Wed, 5 Dec 2007 18:17:45 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB61HiPb024697; Wed, 5 Dec 2007 19:17:44 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB61HhpQ024678; Wed, 5 Dec 2007 19:17:43 -0600 (CST) Message-ID: <47574DB7.8080902@gmail.com> Date: Wed, 05 Dec 2007 17:17:43 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: cjbc@it.uc3m.es Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 References: <1196900866.27208.117.camel@localhost> In-Reply-To: <1196900866.27208.117.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Carlos Jesús Bernardos Cano wrote: > Hi, > > I've read the draft and I have some questions/comments: - (general > comment) I've honestly always have doubts about the feasibility of > real deployments of LMMs. Not sure what you mean by LMM but I also have doubts about deploying protocols designed to work on paper not according to some user needs. > In the scenario described in the draft, a laptop or WLAN-enabled PDA > can break off from the personal area network and the connect to the > Internet on its own. [You mean Figure 4 "Switching of Roles"?] > To do that, is the HA of that node located on the mobile network? If > so, given the particular characteristics of this mobile network (it > is a PAN, can present discontinuos connectivity), the laptop may > experience connectivity problems as that connectivity would depend on > the PAN reachability. If a different deployment is possible (e.g., > the HA located at the Home Network of the MR, not on the NEMO > itself), then I'm fine. Sorry, if you mean Figure 4, then the intention was to not picture HA at all and to not assume Mobile IPv6 at all. This is something that can be fixed by MIPv6, NEMOv6, NEMOV6-RO or something else. Just the scenario is there. I felt like if I added a HA somewhere then I already made some decision. If someone feels like adding a HA somewhere then I'd ask which software (like when you ask which CN would RO). > - In the scenario described in Figure 6, how do you LFNs on the Car > Sensors network from configuring an IP address from the MNP of the > PAN and using this as source address for communications with CNs in > the Internet. If the PAN detaches, these communications would break, > right? > > - Regarding the requirements, I find some of them vague. For example, > Req2: Low Processing Load, what does "increase the processing load > of the MR significantly" mean? is linear increase with the number of > nodes/communications Route Optimised/etc acceptable? You might > consider also include a requirement regarding signalling load. > > - I'd consider adding a requirement regarding modification of > correspondent nodes. Another thing that does not seem completely > clear to me is: to which devices RO should be provided? only LFNs and > LMNs or also VMNs?. > > - Do you want to be able to enable RO for some nodes and use plan > NEMO B.S. for others? I think this is called separability in other > requirements drafts. > > - For the MR-to-MR optimisation, is there any difference -- > significant for the personal MR scenario -- when the MRs are attached > to the same link vs the general case? I think (but will let Chan-Wah clarify) that MR-to-MR optimisation is pretty much the same whether vehicle or Personal Area Networks or more general case. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 20:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05XF-00073l-CI; Wed, 05 Dec 2007 20:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05XD-00073X-Nj for mext@ietf.org; Wed, 05 Dec 2007 20:28:15 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05XC-0002xu-5w for mext@ietf.org; Wed, 05 Dec 2007 20:28:15 -0500 X-IronPort-AV: E=Sophos;i="4.23,257,1194217200"; d="vcf'?scan'208";a="6522791" Received: from unknown (HELO chokaisan.local) ([130.129.85.82]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2007 02:28:12 +0100 Message-ID: <4757501A.9020702@inria.fr> Date: Thu, 06 Dec 2007 02:27:54 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 References: <1196900866.27208.117.camel@localhost> <47574DB7.8080902@gmail.com> In-Reply-To: <47574DB7.8080902@gmail.com> Content-Type: multipart/mixed; boundary="------------070104020208030704070507" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------070104020208030704070507 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit >> - For the MR-to-MR optimisation, is there any difference -- >> significant for the personal MR scenario -- when the MRs are attached >> to the same link vs the general case? > > I think (but will let Chan-Wah clarify) that MR-to-MR optimisation is > pretty much the same whether vehicle or Personal Area Networks or more > general case. I wouldn't think so. For car-to-car communications, there is a will to allow direct MR-to-MR communication (that gets us into a MANEMO type of situation) or undirectly via the ARs to which each MR is connected to. There are scenarios where both types would be needed simultaneously for different types of applications. I haven't seen that for CE. Thierry --------------070104020208030704070507 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------070104020208030704070507 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------070104020208030704070507-- From mext-bounces@ietf.org Wed Dec 05 20:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05y2-0007s5-CF; Wed, 05 Dec 2007 20:55:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J05y0-0007rl-U7 for mext@ietf.org; Wed, 05 Dec 2007 20:55:56 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J05xz-0005FK-A7 for mext@ietf.org; Wed, 05 Dec 2007 20:55:56 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 977022C020DC1; Thu, 6 Dec 2007 03:55:53 +0200 (EET) Date: Thu, 6 Dec 2007 03:55:53 +0200 (EET) From: Wassim Haddad To: "Narayanan, Vidya" Subject: RE: [MEXT] New items for the mext charter discussion In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Julien Laganier , mext@ietf.org, Hesham Soliman X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vidya, Just to add one thing: ROHC is deployed *only* in particular networks and in these networks when you switch between BS, ROHC has to "reboot". So for mobility protocols in general (including the RO mode), this proposal is much more efficient. Regards, Wassim H. On Wed, 5 Dec 2007, Narayanan, Vidya wrote: > > Hi Hesham, > >> >> => ROHC has several limitations. One of them is that it works >> on p2p links. >> Another is it's complexity of course. This solution is >> independent of the link layer, which is good. Even when >> combined with ROHC it can easily address the triple header scenarios. >> > > Okay, I'm speaking prematurely, since I haven't looked at the draft yet > :) I was trying to understand where we see the use. Even from the p2p > perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP > tunnel is a virtual p2p link. That is philosophy behind the ongoing > work on ROHC for IPsec. But, I'll take a look at the draft first (I > assume there is one :)). > > Vidya > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 05 21:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06FG-00088W-Qi; Wed, 05 Dec 2007 21:13:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06FF-000885-Ay for mext@ietf.org; Wed, 05 Dec 2007 21:13:45 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J06FE-0003Tb-TO for mext@ietf.org; Wed, 05 Dec 2007 21:13:45 -0500 X-IronPort-AV: E=Sophos;i="4.23,257,1194217200"; d="vcf'?scan'208";a="5315811" Received: from unknown (HELO chokaisan.local) ([130.129.85.82]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2007 03:13:43 +0100 Message-ID: <47575AC5.1090401@inria.fr> Date: Thu, 06 Dec 2007 03:13:25 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 CC: mext@ietf.org Subject: Re: [MEXT] New items for the mext charter discussion References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080407040208080407080901" X-Spam-Score: 1.6 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------080407040208080407080901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A paper about ROHC with NEMO was published at WONEMO 2007 and another one about ROHC in nested NEMO this year at ICLAN 2007. Also draft-minaburo-rohc-nemo.txt (expired) See http://www.rennes.enst-bretagne.fr/~prawat/ Thierry Wassim Haddad wrote: > Hi Vidya, > > Just to add one thing: > > ROHC is deployed *only* in particular networks and in these networks > when you switch between BS, ROHC has to "reboot". So for mobility > protocols in > general (including the RO mode), this proposal is much more efficient. > > > Regards, > > Wassim H. > > > > On Wed, 5 Dec 2007, Narayanan, Vidya wrote: >> >> Hi Hesham, >> >>> >>> => ROHC has several limitations. One of them is that it works >>> on p2p links. >>> Another is it's complexity of course. This solution is >>> independent of the link layer, which is good. Even when >>> combined with ROHC it can easily address the triple header scenarios. >>> >> >> Okay, I'm speaking prematurely, since I haven't looked at the draft yet >> :) I was trying to understand where we see the use. Even from the p2p >> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP >> tunnel is a virtual p2p link. That is philosophy behind the ongoing >> work on ROHC for IPsec. But, I'll take a look at the draft first (I >> assume there is one :)). >> >> Vidya >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext --------------080407040208080407080901 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------080407040208080407080901 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------080407040208080407080901-- From LupelaceForeman@fordfound.org Wed Dec 05 21:43:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J06iN-0000vv-Vt; Wed, 05 Dec 2007 21:43:52 -0500 Received: from [200.82.208.209] (helo=pc.company.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J06iN-0005sx-Jo; Wed, 05 Dec 2007 21:43:51 -0500 Received: from dare by fordfound.org with SMTP id qRy6ucyve2 for ; Wed, 5 Dec 2007 22:43:30 +0400 From: "Newton Lindsay" To: Subject: Join your new casino paradise Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de How about the best service around? Get your bonus and walk the red carpet to winnings and fun. Play your favorite games and get $999 welcome bonus. We know how to treat our players - how about a $999 welcome bonmus when you join? http://eurocasinoal.com/ From mext-bounces@ietf.org Wed Dec 05 22:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07fM-00077v-OY; Wed, 05 Dec 2007 22:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J07fK-00077d-TT for mext@ietf.org; Wed, 05 Dec 2007 22:44:46 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J07fK-0004iN-GZ for mext@ietf.org; Wed, 05 Dec 2007 22:44:46 -0500 X-AuditID: c0a8013c-ae724bb000001e2e-b2-4757702a9754 Received: from M90Teco (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id A03CA4DC010; Wed, 5 Dec 2007 20:44:36 -0700 (MST) From: "Teco Boot" To: "'Kazuyuki Tasaka'" References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <47573DEA.7090803@kddilabs.jp> In-Reply-To: <47573DEA.7090803@kddilabs.jp> Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Thu, 6 Dec 2007 04:44:18 +0100 Message-ID: <00b801c837ba$5575b000$00611000$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg3nHZYGcW19aihRoifZOxrMFxkiAAHaFCQ Content-Language: nl X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > -----Oorspronkelijk bericht----- > Van: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp] > Verzonden: donderdag 6 december 2007 1:10 > Aan: Teco Boot > CC: 'Romain KUNTZ'; 'Hannes Tschofenig'; mext@ietf.org > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > Hi Teco, > > Teco Boot Wrote: > [...] > >>>> 2. The MR translates them to filter rules according to its current > >>>> environment (available interfaces, path characteristics...), > >>> MR is MN or HA, correct? > >> The MR or MN translates the policies to filter rules. Other peers > >> (e.g. the HA) can use them later to confront them to the received > >> filter rules from the MR/MN. > >> > >> I don't see a use case where the HA or the CN could translate the > MR/ > >> MN's policies to filter rules, maybe someone have one? > > > > I prefer using MN, this is MN (MIPv6) or MR (NEMO). > > > > I am not sure the MN generates the filter for peer (HA, CN) in all > cases. > > For example, HA / CN may have other policies. I think this is getting > > complex and we should work out the basic approach first, that MN > generate > > the filter for both itself and for peer. > > > > I remember someone brought up the HA generate filters in Chicago. > Maybe it > > was policies. Not in minutes. > > Maybe I said. > > I think there is a case that an administrator of HA such as a network > operator wants to modify policies of MN for network congestion control. > In this case, HA translates own policies to filter rules according to > current environment of MN and enforce them. And sends HA the filter rules to MN? Teco. > > Regards, > Kazuyuki. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 01:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ACB-0003qN-OM; Thu, 06 Dec 2007 01:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0AC9-0003q4-SR for mext@ietf.org; Thu, 06 Dec 2007 01:26:49 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0AC5-00053I-4z for mext@ietf.org; Thu, 06 Dec 2007 01:26:49 -0500 X-AuditID: c0a8013c-ae724bb000001e2e-0b-475796229176 Received: from [127.0.0.1] (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id A2A264DC008; Wed, 5 Dec 2007 23:26:37 -0700 (MST) Message-ID: <4757960D.6040001@azairenet.com> Date: Wed, 05 Dec 2007 22:26:21 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [MEXT] New items for the mext charter discussion References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Julien Laganier , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Narayanan, Vidya wrote: >> - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions >> >> Work on the solution of interface, by which IKEv2 could get >> the information from MIPv6 and negotiate or update right >> IPsec security associations for MIPv6 when MN bootstrap in >> foreign network or handover to new foreign network. >> > > Neutral. If this work is done, I don't think it should be mandatory to > implement. Having an optionally standardized mechanism doesn't seem to > hurt. PF_KEY in general is optional. IETF has typically produced Informational documents in this space. It can always be implemented in an implementation specific manner. > >> - RFC 3775 update >> >> Revise RFC 3775 to fix minor issues and add clarifying test >> for issues identified since it was published. The update >> would be limited to minor changes and not include any major >> modifications to the protocol. >> > > Obviously important, but, I tend to agree with Hesham that we should > wait on this. There are some bugs (leading to interop issues) that need to be fixed ASAP. See http://www3.ietf.org/proceedings/07dec/slides/mext-6.ppt. These slides haven't been presented yet. They will be presented on Friday. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 01:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ADh-0005eD-LX; Thu, 06 Dec 2007 01:28:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ADg-0005e2-74 for mext@ietf.org; Thu, 06 Dec 2007 01:28:24 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0ADf-0002WP-QG for mext@ietf.org; Thu, 06 Dec 2007 01:28:24 -0500 X-AuditID: c0a8013c-ad722bb000001e2e-33-47579684b99f Received: from [127.0.0.1] (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id DC97D4DC003; Wed, 5 Dec 2007 23:28:16 -0700 (MST) Message-ID: <47579670.90905@azairenet.com> Date: Wed, 05 Dec 2007 22:28:00 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Wassim Haddad Subject: Re: [MEXT] New items for the mext charter discussion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Hesham Soliman , mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Wassim Haddad wrote: > Hi Vidya, > > Just to add one thing: > > ROHC is deployed *only* in particular networks and in these networks > when you switch between BS, ROHC has to "reboot". hmm... this is not entirely accurate. There are networks where the context is transferred and you could continue in the same state as the old link. No need for a "reboot". Vijay So for mobility > protocols in > general (including the RO mode), this proposal is much more efficient. > > > Regards, > > Wassim H. > > > > On Wed, 5 Dec 2007, Narayanan, Vidya wrote: >> >> Hi Hesham, >> >>> >>> => ROHC has several limitations. One of them is that it works >>> on p2p links. >>> Another is it's complexity of course. This solution is >>> independent of the link layer, which is good. Even when >>> combined with ROHC it can easily address the triple header scenarios. >>> >> >> Okay, I'm speaking prematurely, since I haven't looked at the draft yet >> :) I was trying to understand where we see the use. Even from the p2p >> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP >> tunnel is a virtual p2p link. That is philosophy behind the ongoing >> work on ROHC for IPsec. But, I'll take a look at the draft first (I >> assume there is one :)). >> >> Vidya >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 01:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0AEY-0006ZO-VF; Thu, 06 Dec 2007 01:29:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0AEX-0006TJ-R0 for mext@ietf.org; Thu, 06 Dec 2007 01:29:17 -0500 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0AEU-000591-9s for mext@ietf.org; Thu, 06 Dec 2007 01:29:17 -0500 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id CBC9FECB0F; Thu, 6 Dec 2007 15:29:12 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id E8319ECA3A; Thu, 6 Dec 2007 15:29:11 +0900 (JST) Received: from [127.0.0.1] (c018.vpn.kddilabs.jp [172.19.87.18]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id B385F690458; Thu, 6 Dec 2007 15:29:04 +0900 (JST) Message-ID: <475796A3.3050401@kddilabs.jp> Date: Thu, 06 Dec 2007 15:28:51 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <47573DEA.7090803@kddilabs.jp> <00b801c837ba$5575b000$00611000$@nl> In-Reply-To: <00b801c837ba$5575b000$00611000$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -1.4 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Teco, Teco Boot Wrote: >> -----Oorspronkelijk bericht----- >> Van: Kazuyuki Tasaka [mailto:ka-tasaka@kddilabs.jp] >> Verzonden: donderdag 6 december 2007 1:10 >> Aan: Teco Boot >> CC: 'Romain KUNTZ'; 'Hannes Tschofenig'; mext@ietf.org >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules >> >> Hi Teco, >> >> Teco Boot Wrote: >> [...] >>>>>> 2. The MR translates them to filter rules according to its current >>>>>> environment (available interfaces, path characteristics...), >>>>> MR is MN or HA, correct? >>>> The MR or MN translates the policies to filter rules. Other peers >>>> (e.g. the HA) can use them later to confront them to the received >>>> filter rules from the MR/MN. >>>> >>>> I don't see a use case where the HA or the CN could translate the >> MR/ >>>> MN's policies to filter rules, maybe someone have one? >>> I prefer using MN, this is MN (MIPv6) or MR (NEMO). >>> >>> I am not sure the MN generates the filter for peer (HA, CN) in all >> cases. >>> For example, HA / CN may have other policies. I think this is getting >>> complex and we should work out the basic approach first, that MN >> generate >>> the filter for both itself and for peer. >>> >>> I remember someone brought up the HA generate filters in Chicago. >> Maybe it >>> was policies. Not in minutes. >> Maybe I said. >> >> I think there is a case that an administrator of HA such as a network >> operator wants to modify policies of MN for network congestion control. >> In this case, HA translates own policies to filter rules according to >> current environment of MN and enforce them. > > And sends HA the filter rules to MN? HA could be sent filter rules to MN. But, as you said, this is getting complex. Because there is a possibility that preferences of the user and the operator conflict. In addition, the operator needs know capability of MN to control traffic (usable interface, kinds of interface ...etc). In flow-distribution-rules, to work out the basic approach, the MR creates filter rules from policies. Policies are received by a third-part node (could be the HA, or not) and Local Node. Regards, Kazuyuki. > Teco. > > >> Regards, >> Kazuyuki. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 03:11:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bop-0007Qg-4F; Thu, 06 Dec 2007 03:10:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bol-0007OL-Mm for mext@ietf.org; Thu, 06 Dec 2007 03:10:47 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Bol-0006wr-9N for mext@ietf.org; Thu, 06 Dec 2007 03:10:47 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lB687NT22103; Thu, 6 Dec 2007 08:07:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 6 Dec 2007 02:10:31 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: Acg3bp0s509xBbOMSKGeHFur2SAo7QAcFOjQ References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> From: "Ahmad Muhanna" To: "George Tsirtsis" , "marcelo bagnulo braun" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > > > New items proposed so far: > > > > > > - Binding Revocation Mechanism for IPv6 Mobility > > > > Define a generic binding revocation mechanism for Mobile=20 > IPv6 and its=20 > > extensions (e.g. NEMO, Monami6, NETLMM). The mechanism can=20 > be used by=20 > > any mobility entity that provides Mobile IP services to a MN (e.g. a > > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another mobility=20 > > entity that is involved in providing Mobile IP services to the MN=20 > > (e.g. a NETLMM MAG) of the termination of either one,=20 > multiple or all=20 > > bindings for a mobile node. The mechanism should also allow any=20 > > mobility entity (e.g. NETLMM MAG or LMA) to signal the=20 > termination of=20 > > bindings for multiple mobile nodes via use of a single revocation=20 > > message. > > >=20 > GT> I think this makes sense and it is well understood issue. The > work, however, should be done for MIPv6. Then how PMIPv6 can=20 > use it should be done in NETLMM. In other words I would=20 > suggest that the > PMIPv6 specific sections in the draft should be removed and=20 > worked on in NETLMM, if NETLMM has a use for this. >=20 [Ahmad] Hi George, This topic has been discussed thoroughly on the MIP6 mailing list and concluded. For more information, please take a look at the following threads. http://www1.ietf.org/mail-archive/web/mip6/current/msg06741.html http://www1.ietf.org/mail-archive/web/mip6/current/msg06767.html http://www1.ietf.org/mail-archive/web/mip6/current/msg06788.html Regards, Ahmad _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 03:19:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bwl-0002w6-G8; Thu, 06 Dec 2007 03:19:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bwj-0002nJ-DL for mext@ietf.org; Thu, 06 Dec 2007 03:19:01 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Bwi-0007Oc-Uc for mext@ietf.org; Thu, 06 Dec 2007 03:19:01 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lB68Iur02115; Thu, 6 Dec 2007 08:18:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 6 Dec 2007 02:18:51 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: AcgyftMIzGv+UPyASF6VFUVIv41usAFIcXGgAAwyCLA= References: <9F74E08A-F873-4E31-8AD3-4BF82A670DF7@bagnulo.net> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "marcelo bagnulo braun" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >=20 > > New items proposed so far: > >=20 > >=20 > > - Binding Revocation Mechanism for IPv6 Mobility > >=20 > > Define a generic binding revocation mechanism for Mobile=20 > IPv6 and its=20 > > extensions (e.g. NEMO, Monami6, NETLMM). The mechanism can=20 > be used by=20 > > any mobility entity that provides Mobile IP services to a MN (e.g. a > > MIPv6 HA, a NETLMM LMA) to inform the MN itself or another mobility=20 > > entity that is involved in providing Mobile IP services to the MN=20 > > (e.g. a NETLMM MAG) of the termination of either one,=20 > multiple or all=20 > > bindings for a mobile node. The mechanism should also allow any=20 > > mobility entity (e.g. NETLMM MAG or LMA) to signal the=20 > termination of=20 > > bindings for multiple mobile nodes via use of a single revocation=20 > > message. > >=20 >=20 > I can see the use case for binding revocation in NETLMM, but,=20 > I'm not seeing it for MIP6. I think this came up as part of=20 > the WG discussions on this topic earlier and I didn't see a=20 > practical reason why binding revocation is needed for MIP6. =20 > For non-administrative reasons due to which bindings need to=20 > be moved out of an HA, the HA switch draft does the work. If=20 > the reasons are administrative, it then implies managed=20 > networks and in all those cases, network access will (and=20 > should) be blocked for the MN even before the binding=20 > revocation message can get to it.=20 [Ahmad] Hi Vidya, This topic has gone through all the steps of IETF wg decision making and a consensus has been reached and the issue has been concluded and closed. Just in case, here are the steps which has been completed: 1. There has been consensus at MIP6 @ IETF69 to adopt Binding revocation for IPv6 Mobility as a MIP6 work item. 2. The meeting consensus above has been confirmed with a consensus call on the MIP6 mailing list. 3. When you (as Netlmm wg chair) raised concern that this functionality should be addressed in Netlmm wg, the AD discussed this with you and MIP6 chairs and a decision has been made and communicated to the mailing list. For more information, please take a look at the following threads: http://www1.ietf.org/mail-archive/web/mip6/current/msg06741.html http://www1.ietf.org/mail-archive/web/mip6/current/msg06767.html http://www1.ietf.org/mail-archive/web/mip6/current/msg06788.html Best Regards, Ahmad _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JerriscaupQueen@ielanguages.com Thu Dec 06 04:48:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0DLI-0007LY-S6; Thu, 06 Dec 2007 04:48:28 -0500 Received: from [84.91.49.45] (helo=pccentral.netvisao.pt) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0DLI-0002tH-8Y; Thu, 06 Dec 2007 04:48:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host71618654.ielanguages.com (8.13.1/8.13.1) with SMTP id XvBwJy5N84.478460.Sx4.k4W.2388174121243 for ; Thu, 6 Dec 2007 09:48:05 +0000 Message-ID: <2a89501c837ed$224b0da0$6501a8c0@pccentral> From: "Marcie Moreland" To: Cc: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_2A891_01C837ED.224B0DA0-- From QueenvenialKruse@freedict.com Thu Dec 06 05:41:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0EAN-0007Gp-Nl; Thu, 06 Dec 2007 05:41:15 -0500 Received: from as-ind-srv.netvisao.pt ([213.228.178.53] helo=miguel.asindcal.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0EAN-0005D2-CZ; Thu, 06 Dec 2007 05:41:15 -0500 Received: from limitate by freedict.com with SMTP id BDaCIB7DQ2 for ; Thu, 6 Dec 2007 10:40:59 +0000 From: "Mai Bermudez" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0GJ5-0005ZS-BK; Thu, 06 Dec 2007 07:58:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0GJ3-0005WS-BA for mext@ietf.org; Thu, 06 Dec 2007 07:58:21 -0500 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0GJ2-0002ay-QM for mext@ietf.org; Thu, 06 Dec 2007 07:58:21 -0500 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 5948325F708 for ; Thu, 6 Dec 2007 12:58:19 +0000 (WET) Received: from medusa (dhcp-251.ci.uc.pt [193.136.200.251]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 34A9725F6FF for ; Thu, 6 Dec 2007 12:58:19 +0000 (WET) From: "Pedro Pinheiro" To: Date: Thu, 6 Dec 2007 12:58:19 -0000 Message-ID: <047901c83807$ace3dcc0$06ab9640$@uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4B6v9YEIlTX+dRBKtUUuN/ncA8g== Content-Language: pt X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [MEXT] ICMP error...? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, I don't know if this subject has already been discussed. If so, please forgive me and point to me where can I find a answer. My question is relative to NEMO Basic Support protocol. If a packet from a CN to a MNN (or vice-versa) goes into a MRHA packet = and this is traversing the Internet, don't matter if destined to HA or to = CoA's MR, and any router has to generate a ICMP error (unreachable, ...) it = will generate it destined to the HA's or CoA's IP.=20 In this situation how will the HA or MR find out the origin of the = packet inside the MRHA? The icmp will not forward the MRHA packet so that HA or = MR could see inside it and return a ICMP error to the CN or MNN.=20 I hope I have made myself clear. Thank you in advance. Pedro Vapi ------------------------------------ Universidade de Coimbra Pedro Pinheiro Eng, MSc vapi@univ-coimbra.eu Centro de Informatica=20 R. Arco da Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351 239 853 189 IM: MSN: pvapi@hotmail.com http://www.univ-coimbra.eu/pessoal/vapi/ Skype ID:pedrovapi ------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From BennieparsimonyRobbins@washingtonpost.com Thu Dec 06 09:30:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0HkQ-0007cw-75; Thu, 06 Dec 2007 09:30:42 -0500 Received: from [89.148.47.70] (helo=mfb492d4d90704) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0HkP-0008Ib-Q1; Thu, 06 Dec 2007 09:30:42 -0500 Received: from holyoke by washingtonpost.com with SMTP id JyFBzT2QPy for ; Wed, 5 Dec 2007 17:31:03 +0200 From: "Delbert Rodgers" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0J82-0001td-4b; Thu, 06 Dec 2007 10:59:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0J81-0001tX-07 for mext@ietf.org; Thu, 06 Dec 2007 10:59:09 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0J7v-0000xr-7F for mext@ietf.org; Thu, 06 Dec 2007 10:59:08 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id A2B132C0210E3; Thu, 6 Dec 2007 17:59:01 +0200 (EET) Date: Thu, 6 Dec 2007 17:59:01 +0200 (EET) From: Wassim Haddad To: Vijay Devarapalli Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: <47579670.90905@azairenet.com> Message-ID: References: <47579670.90905@azairenet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Hesham Soliman , mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Wed, 5 Dec 2007, Vijay Devarapalli wrote: > Wassim Haddad wrote: >> Hi Vidya, >> >> Just to add one thing: >> >> ROHC is deployed *only* in particular networks and in these networks when >> you switch between BS, ROHC has to "reboot". > > hmm... this is not entirely accurate. There are networks where the > context is transferred and you could continue in the same state as > the old link. No need for a "reboot". => In fact, it is *very* accurate and you are (as always) wrong! Transferring context between base stations is NOT supported in the E-UTRAN (main reason is that it is even more complex than ROHC itself). This means that it has to be restarted at each handoff. Wassim H. > So for mobility >> protocols in >> general (including the RO mode), this proposal is much more efficient. >> >> >> Regards, >> >> Wassim H. >> >> >> >> On Wed, 5 Dec 2007, Narayanan, Vidya wrote: >>> >>> Hi Hesham, >>> >>>> >>>> => ROHC has several limitations. One of them is that it works >>>> on p2p links. >>>> Another is it's complexity of course. This solution is >>>> independent of the link layer, which is good. Even when >>>> combined with ROHC it can easily address the triple header scenarios. >>>> >>> >>> Okay, I'm speaking prematurely, since I haven't looked at the draft yet >>> :) I was trying to understand where we see the use. Even from the p2p >>> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP >>> tunnel is a virtual p2p link. That is philosophy behind the ongoing >>> work on ROHC for IPsec. But, I'll take a look at the draft first (I >>> assume there is one :)). >>> >>> Vidya >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 12:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KFY-00085c-EE; Thu, 06 Dec 2007 12:11:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KFW-0007mi-Is for mext@ietf.org; Thu, 06 Dec 2007 12:10:58 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KFW-00052U-1z for mext@ietf.org; Thu, 06 Dec 2007 12:10:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id EE9FB108347 for ; Thu, 6 Dec 2007 12:10:53 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24967-14 for ; Thu, 6 Dec 2007 12:10:51 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 6 Dec 2007 12:10:51 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 12:09:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] New items for the mext charter discussion Date: Thu, 6 Dec 2007 12:06:49 -0500 Message-ID: <4D35478224365146822AE9E3AD4A2666877844@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] New items for the mext charter discussion Thread-Index: Acg4IP6bXDMSTZfnR36ce4yovUup2QAB0oyw From: "Chowdhury, Kuntal" To: "Wassim Haddad" , "Vijay Devarapalli" X-OriginalArrivalTime: 06 Dec 2007 17:09:09.0354 (UTC) FILETIME=[B734ECA0:01C8382A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Julien Laganier , mext@ietf.org, Hesham Soliman X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > Sent: Thursday, December 06, 2007 9:59 AM > To: Vijay Devarapalli > Cc: Hesham Soliman; mext@ietf.org; Julien Laganier > Subject: Re: [MEXT] New items for the mext charter discussion >=20 > On Wed, 5 Dec 2007, Vijay Devarapalli wrote: >=20 > > Wassim Haddad wrote: > >> Hi Vidya, > >> > >> Just to add one thing: > >> > >> ROHC is deployed *only* in particular networks and in these networks > when > >> you switch between BS, ROHC has to "reboot". > > > > hmm... this is not entirely accurate. There are networks where the > > context is transferred and you could continue in the same state as > > the old link. No need for a "reboot". >=20 > =3D> In fact, it is *very* accurate and you are (as always) wrong! > Transferring context between base stations is NOT supported in the E-UTRAN > (main reason is that it is even more complex than ROHC itself). This means > that it has to be restarted at each handoff. >=20 [KC>] You are right about placement of ROHC in the BS in some new wireless technologies. In order to mitigate the reboot problem for BS to BS handover, there are procedures in place to pre-install ROHC static state in the target BS. Also, the decision to place ROHC in the BS was taken based on the input from the BS vendors that it was a very fast process to install ROHC state. =20 >=20 > Wassim H. >=20 >=20 > > So for mobility > >> protocols in > >> general (including the RO mode), this proposal is much more efficient. > >> > >> > >> Regards, > >> > >> Wassim H. > >> > >> > >> > >> On Wed, 5 Dec 2007, Narayanan, Vidya wrote: > >>> > >>> Hi Hesham, > >>> > >>>> > >>>> =3D> ROHC has several limitations. One of them is that it works > >>>> on p2p links. > >>>> Another is it's complexity of course. This solution is > >>>> independent of the link layer, which is good. Even when > >>>> combined with ROHC it can easily address the triple header scenarios. > >>>> > >>> > >>> Okay, I'm speaking prematurely, since I haven't looked at the draft > yet > >>> :) I was trying to understand where we see the use. Even from the > p2p > >>> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP > >>> tunnel is a virtual p2p link. That is philosophy behind the ongoing > >>> work on ROHC for IPsec. But, I'll take a look at the draft first (I > >>> assume there is one :)). > >>> > >>> Vidya > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 12:15:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KJb-0005te-Af; Thu, 06 Dec 2007 12:15:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KJa-0005tW-NU for mext@ietf.org; Thu, 06 Dec 2007 12:15:10 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KJZ-0005Mh-NL for mext@ietf.org; Thu, 06 Dec 2007 12:15:10 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A2A4D282BE6; Thu, 6 Dec 2007 18:15:07 +0100 (CET) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <47574DB7.8080902@gmail.com> References: <1196900866.27208.117.camel@localhost> <47574DB7.8080902@gmail.com> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 18:15:04 +0100 Message-Id: <1196961304.27208.122.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730030777==" Errors-To: mext-bounces@ietf.org --===============0730030777== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lsPftCB34AMiviW8GjUF" --=-lsPftCB34AMiviW8GjUF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, Comments below... El mi=E9, 05-12-2007 a las 17:17 -0800, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano wrote: > > Hi, > >=20 > > I've read the draft and I have some questions/comments: - (general=20 > > comment) I've honestly always have doubts about the feasibility of=20 > > real deployments of LMMs. >=20 > Not sure what you mean by LMM but I also have doubts about deploying > protocols designed to work on paper not according to some user needs. I wanted to say "LMNs" (Local Mobile Nodes), not LMMs (my mistake). >=20 > > In the scenario described in the draft, a laptop or WLAN-enabled PDA=20 > > can break off from the personal area network and the connect to the=20 > > Internet on its own. >=20 > [You mean Figure 4 "Switching of Roles"?] No, I tried to mean the LMN scenario, where a MNN connected to a NEMO then moves away from the NEMO and becomes a Mobile Node, whose HoA belongs to the MNP. >=20 > > To do that, is the HA of that node located on the mobile network? If > > so, given the particular characteristics of this mobile network (it > > is a PAN, can present discontinuos connectivity), the laptop may > > experience connectivity problems as that connectivity would depend on > > the PAN reachability. If a different deployment is possible (e.g., > > the HA located at the Home Network of the MR, not on the NEMO > > itself), then I'm fine. >=20 > Sorry, if you mean Figure 4, then the intention was to not picture HA at=20 > all and to not assume Mobile IPv6 at all. This is something that can be=20 > fixed by MIPv6, NEMOv6, NEMOV6-RO or something else. Just the scenario=20 > is there. (I didn't mean Figure 4) >=20 > I felt like if I added a HA somewhere then I already made some decision. >=20 > If someone feels like adding a HA somewhere then I'd ask which software=20 > (like when you ask which CN would RO). >=20 > > - In the scenario described in Figure 6, how do you LFNs on the Car=20 > > Sensors network from configuring an IP address from the MNP of the=20 > > PAN and using this as source address for communications with CNs in=20 > > the Internet. If the PAN detaches, these communications would break,=20 > > right? > >=20 > > - Regarding the requirements, I find some of them vague. For example, > > Req2: Low Processing Load, what does "increase the processing load=20 > > of the MR significantly" mean? is linear increase with the number of > > nodes/communications Route Optimised/etc acceptable? You might=20 > > consider also include a requirement regarding signalling load. > >=20 > > - I'd consider adding a requirement regarding modification of=20 > > correspondent nodes. Another thing that does not seem completely=20 > > clear to me is: to which devices RO should be provided? only LFNs and > > LMNs or also VMNs?. > >=20 > > - Do you want to be able to enable RO for some nodes and use plan=20 > > NEMO B.S. for others? I think this is called separability in other=20 > > requirements drafts. > >=20 > > - For the MR-to-MR optimisation, is there any difference --=20 > > significant for the personal MR scenario -- when the MRs are attached > > to the same link vs the general case? >=20 > I think (but will let Chan-Wah clarify) that MR-to-MR optimisation is=20 > pretty much the same whether vehicle or Personal Area Networks or more=20 > general case. Well, I guess that in the solution space it might be different, but it was just a comment. Regards, Carlos >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-lsPftCB34AMiviW8GjUF Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWC4YNdy6TdFwT2cRArN5AKCu/uJfOUTuS1Cwe1TE6iKvClQ/7gCdE19a 1zKQykOd8zWG5H/bQPmyPvs= =sA6x -----END PGP SIGNATURE----- --=-lsPftCB34AMiviW8GjUF-- --===============0730030777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0730030777==-- From SanfordvalparaisoBarron@boston.com Thu Dec 06 12:20:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KOH-00078D-VM; Thu, 06 Dec 2007 12:20:02 -0500 Received: from cpe-76-180-105-199.buffalo.res.rr.com ([76.180.105.199] helo=eduardo.buffalo.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0KOH-0005nZ-K5; Thu, 06 Dec 2007 12:20:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52710030.boston.com (8.13.1/8.13.1) with SMTP id 4VcSHbcl34.114625.GWR.qiC.7870782264062 for ; Thu, 6 Dec 2007 12:18:42 +0500 Message-ID: <4539501c8382c$14f55cc0$c769b44c@EDUARDO> From: "Barney Pugh" To: Subject: Your order Date: Thu, 6 Dec 2007 12:18:42 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_45391_01C8382C.14F55CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 This is a multi-part message in MIME format. ------=_NextPart_000_45391_01C8382C.14F55CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis Soft Tabs would help you to = make better sex more often and to bring unimaginable plesure to her. = Just disolve half a pill under your tongue and get ready for action in = 30 minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Cialis Soft Tabs gives you confidence in any chance, every time. ------=_NextPart_000_45391_01C8382C.14F55CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_45391_01C8382C.14F55CC0-- From mext-bounces@ietf.org Thu Dec 06 12:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KZX-0004eG-CN; Thu, 06 Dec 2007 12:31:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KZV-0004e6-NV for mext@ietf.org; Thu, 06 Dec 2007 12:31:37 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KZV-0006wd-3g for mext@ietf.org; Thu, 06 Dec 2007 12:31:37 -0500 Received: from [127.0.0.1] ([130.129.21.232]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 09:31:33 -0800 Message-ID: <475831F1.2000409@azairenet.com> Date: Thu, 06 Dec 2007 09:31:29 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Wassim Haddad Subject: Re: [MEXT] New items for the mext charter discussion References: <47579670.90905@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2007 17:31:33.0552 (UTC) FILETIME=[D8694300:01C8382D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Hesham Soliman , mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Wassim Haddad wrote: > On Wed, 5 Dec 2007, Vijay Devarapalli wrote: > >> Wassim Haddad wrote: >>> Hi Vidya, >>> >>> Just to add one thing: >>> >>> ROHC is deployed *only* in particular networks and in these networks >>> when you switch between BS, ROHC has to "reboot". >> >> hmm... this is not entirely accurate. There are networks where the >> context is transferred and you could continue in the same state as >> the old link. No need for a "reboot". > > => In fact, it is *very* accurate and you are (as always) wrong! Wow! I am going to ignore that, perhaps you sent it before you had completely woken up. :) > Transferring context between base stations is NOT supported in the E-UTRAN > (main reason is that it is even more complex than ROHC itself). This > means that it has to be restarted at each handoff. Lets look at the details. ROHC re-start is actually straight forward. It only takes a few data packets to go from the full header to first order and then to second order. I had implemented a ROHC context transfer mechanism back in 2001. The idea was to transfer UDP/RTP header compression state from the one access router to another using the Seamboy context transfer mechanism. The performance was surprisingly good. When the context didn't get transferred (lost CT messages) or the RTP sequence numbers were way out of sync, the mobile node had to setup ROHC state again. The RTP numbers could go out of sync if the L2 handoff takes too long and the mobile node lost some packets during the handover. The biggest issue I have seen in transferring ROHC context is that the context could be stale (out of sync) forcing the mobile to re-start anyway. I don't believe transferring ROHC context is very complicated. The reason it is not being used in E-UTRAN could be because they have a mechanism to install the context pretty fast at the new base station. You might want to check on that. BTW, there have been numerous proposals to transfer ROHC context. Just google for it. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 12:49:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kqe-00039M-Uz; Thu, 06 Dec 2007 12:49:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Kqd-00039B-G1 for mext@ietf.org; Thu, 06 Dec 2007 12:49:19 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Kqc-0000FW-GB for mext@ietf.org; Thu, 06 Dec 2007 12:49:19 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lB6HnCbR009113; Fri, 7 Dec 2007 02:49:12 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lB6HnDN00826; Fri, 7 Dec 2007 02:49:13 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id lB6HnAQ26346; Fri, 7 Dec 2007 02:49:10 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 01:48:54 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id D2105264E220; Fri, 7 Dec 2007 01:48:00 +0800 (SGT) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Chan-Wah Ng To: cjbc@it.uc3m.es In-Reply-To: <1196900866.27208.117.camel@localhost> References: <1196900866.27208.117.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Panasonic Singapore Labs Date: Fri, 07 Dec 2007 01:48:00 +0800 Message-Id: <1196963280.6489.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 06 Dec 2007 17:48:55.0440 (UTC) FILETIME=[456CC100:01C83830] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello Carlos, Thanks for the reading and commenting, responses in line. /rgds /cwng On Thu, 2007-12-06 at 01:27 +0100, Carlos Jes=FAs Bernardos Cano wrote:=20 > Hi, >=20 > I've read the draft and I have some questions/comments: > - (general comment) I've honestly always have doubts about the > feasibility of real deployments of LMMs. In the scenario described in > the draft, a laptop or WLAN-enabled PDA can break off from the personal > area network and the connect to the Internet on its own. To do that, is > the HA of that node located on the mobile network? If so, given the > particular characteristics of this mobile network (it is a PAN, can > present discontinuos connectivity), the laptop may experience > connectivity problems as that connectivity would depend on the PAN > reachability. If a different deployment is possible (e.g., the HA > located at the Home Network of the MR, not on the NEMO itself), then I'm > fine. That actually may be a requirement coming out of this scenario. If the LMN wishes to enjoy continuous reachability of its address (configured from PAN's MNP), then there is no choice but for someone in PAN to perform ND proxy for the LMN when it moves away and forward the packet to the LMN's current location. One way to reduce the reliance on the PAN's reachability is for HA of MR to become the HA of LMN, and MR to perform ND-Proxy on the NEMO link. But that is treading into solution space. >=20 > - In the scenario described in Figure 6, how do you LFNs on the Car > Sensors network from configuring an IP address from the MNP of the PAN > and using this as source address for communications with CNs in the > Internet. If the PAN detaches, these communications would break, right?=20 >=20 Right. So, in my first draft, I just write the scenario where the two network are actually inter-nested within each other instead of merged. However, in Chicago, most of the comments are that it should be a merged network. That's why I included that scenario, but I don't see a compelling use case for that, unless the future of in-car sensor network are all going to be all wireless (eg W-USB). As I see it now, the PAN is using wireless, the car sensors are using the CAN wired network. They would be disjoint. Perhaps the car industry people would like to provide some insight? > - Regarding the requirements, I find some of them vague. For example, > Req2: Low Processing Load, what does "increase the processing load of > the MR significantly" mean? is linear increase with the number of > nodes/communications Route Optimised/etc acceptable? You might consider > also include a requirement regarding signalling load. Sure. I will try to provide more numbers in the next version. However, as a thought experiment, the CE industry largely wants RO for better quality AV streaming. So, I would expect the signaling load to a, say, typical H.263/4 stream. For instance, if a hypothetical RO solution required MR to include signaling for every data packet, that is unacceptable. >=20 > - I'd consider adding a requirement regarding modification of > correspondent nodes. I would not :). Consumer electronics industries is changing at a rapid pace. How long did you use your last handphone/laptop? 3 years? 2? I know of people who upgrades their phones every year. CN modification is not a concern. Plus, most of the scenarios indicate a strong need for RO with MR-to-MR communications, much less MR-to-CN. > Another thing that does not seem completely clear > to me is: to which devices RO should be provided? only LFNs and LMNs or > also VMNs?. >=20 I think there are some text in the use case scenario that rule out VMNs. Most users will not allow VMN in their PANs. RO will be provided to any nodes that needs it. >=20 > - Do you want to be able to enable RO for some nodes and use plan NEMO > B.S. for others? I think this is called separability in other > requirements drafts. Yes, I will add that in the next version. >=20 > - For the MR-to-MR optimisation, is there any difference -- significant > for the personal MR scenario -- when the MRs are attached to the same > link vs the general case? What do you mean by "general case"? As in for Avionics, Car, and CE industries? If so, then there is a big difference. Most use cases indicates a strong need for MR-to-MR optimization in CE, whereas not so in avionics. For car industry, as Thierry pointed out, the c2ccc has defined their own layer 2 manet-like route optimization for car-to-car communications. So, they have zero needs for MR-to-MR optimization. Again, thanks for the comments. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 13:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LAz-0001fH-Bw; Thu, 06 Dec 2007 13:10:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LAx-0001fB-SI for mext@ietf.org; Thu, 06 Dec 2007 13:10:19 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LAv-0003wH-Fz for mext@ietf.org; Thu, 06 Dec 2007 13:10:19 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4696F2A8356; Thu, 6 Dec 2007 19:10:15 +0100 (CET) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: chanwah.ng@sg.panasonic.com In-Reply-To: <1196963280.6489.30.camel@localhost> References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 19:10:12 +0100 Message-Id: <1196964612.27208.152.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039338656==" Errors-To: mext-bounces@ietf.org --===============0039338656== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c3lNUYdMFCNP2LSLCaWh" --=-c3lNUYdMFCNP2LSLCaWh Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, Comments below... El vie, 07-12-2007 a las 01:48 +0800, Chan-Wah Ng escribi=F3: > Hello Carlos, >=20 > Thanks for the reading and commenting, responses in line. >=20 > /rgds > /cwng >=20 > On Thu, 2007-12-06 at 01:27 +0100, Carlos Jes=FAs Bernardos Cano wrote:=20 > > Hi, > >=20 > > I've read the draft and I have some questions/comments: > > - (general comment) I've honestly always have doubts about the > > feasibility of real deployments of LMMs. In the scenario described in > > the draft, a laptop or WLAN-enabled PDA can break off from the personal > > area network and the connect to the Internet on its own. To do that, is > > the HA of that node located on the mobile network? If so, given the > > particular characteristics of this mobile network (it is a PAN, can > > present discontinuos connectivity), the laptop may experience > > connectivity problems as that connectivity would depend on the PAN > > reachability. If a different deployment is possible (e.g., the HA > > located at the Home Network of the MR, not on the NEMO itself), then I'= m > > fine. >=20 > That actually may be a requirement coming out of this scenario. If the > LMN wishes to enjoy continuous reachability of its address (configured > from PAN's MNP), then there is no choice but for someone in PAN to > perform ND proxy for the LMN when it moves away and forward the packet > to the LMN's current location. One way to reduce the reliance on the > PAN's reachability is for HA of MR to become the HA of LMN, and MR to > perform ND-Proxy on the NEMO link. But that is treading into solution > space. OK, if it's possible to configure the HA of the MR as the HA of the LMN, then I'm fine with the feasibility of the scenario. I know that goes into the solution space, but for me it was important to check :-). >=20 > >=20 > > - In the scenario described in Figure 6, how do you LFNs on the Car > > Sensors network from configuring an IP address from the MNP of the PAN > > and using this as source address for communications with CNs in the > > Internet. If the PAN detaches, these communications would break, right?= =20 > >=20 > Right. So, in my first draft, I just write the scenario where the two > network are actually inter-nested within each other instead of merged. > However, in Chicago, most of the comments are that it should be a merged > network. That's why I included that scenario, but I don't see a > compelling use case for that, unless the future of in-car sensor network > are all going to be all wireless (eg W-USB). As I see it now, the PAN > is using wireless, the car sensors are using the CAN wired network. > They would be disjoint. Perhaps the car industry people would like to > provide some insight? >=20 >=20 > > - Regarding the requirements, I find some of them vague. For example, > > Req2: Low Processing Load, what does "increase the processing load of > > the MR significantly" mean? is linear increase with the number of > > nodes/communications Route Optimised/etc acceptable? You might consider > > also include a requirement regarding signalling load. >=20 > Sure. I will try to provide more numbers in the next version. However, > as a thought experiment, the CE industry largely wants RO for better > quality AV streaming. So, I would expect the signaling load to a, say, > typical H.263/4 stream. For instance, if a hypothetical RO solution > required MR to include signaling for every data packet, that is > unacceptable. OK. >=20 > >=20 > > - I'd consider adding a requirement regarding modification of > > correspondent nodes. >=20 > I would not :). Consumer electronics industries is changing at a rapid > pace. How long did you use your last handphone/laptop? 3 years? 2? I > know of people who upgrades their phones every year. CN modification is > not a concern. Plus, most of the scenarios indicate a strong need for > RO with MR-to-MR communications, much less MR-to-CN. Well, if all the potential use cases of interests are MR-to-MR, I'm fine, but if there is also a bunch of scenarios involving MR-to-CN, then I disagree that modifying the CN is not a problem. For instance, do you expect youtube servers to be modified just to support NEMO RO? >=20 > > Another thing that does not seem completely clear > > to me is: to which devices RO should be provided? only LFNs and LMNs or > > also VMNs?. > >=20 > I think there are some text in the use case scenario that rule out VMNs. > Most users will not allow VMN in their PANs. RO will be provided to any > nodes that needs it. Yes, there is text, but it would be nice to include that also on the list of requirements, IMHO. >=20 > >=20 > > - Do you want to be able to enable RO for some nodes and use plan NEMO > > B.S. for others? I think this is called separability in other > > requirements drafts. >=20 > Yes, I will add that in the next version. OK, thanks. > >=20 > > - For the MR-to-MR optimisation, is there any difference -- significant > > for the personal MR scenario -- when the MRs are attached to the same > > link vs the general case? >=20 > What do you mean by "general case"? As in for Avionics, Car, and CE > industries? If so, then there is a big difference. Most use cases > indicates a strong need for MR-to-MR optimization in CE, whereas not so > in avionics. For car industry, as Thierry pointed out, the c2ccc has > defined their own layer 2 manet-like route optimization for car-to-car > communications. So, they have zero needs for MR-to-MR optimization. Well, I'm not so sure that the car industry is assuming any particular solution yet. They are working on the requirements, the solution should come after that. I think there might be a difference in requiring MR-to-MR optimisation when these two MRs are directly one-hop connected and when they are not. > Again, thanks for the comments. You're welcome :-D Regards, Carlos >=20 >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-c3lNUYdMFCNP2LSLCaWh Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWDsENdy6TdFwT2cRAkaMAJ0Q/LN3WSTMTremBsdntE7eVgrYfQCgwH+o w5w1LIgeALBaualBYNSHiZc= =7L1E -----END PGP SIGNATURE----- --=-c3lNUYdMFCNP2LSLCaWh-- --===============0039338656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0039338656==-- From mext-bounces@ietf.org Thu Dec 06 13:23:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LNm-0007pk-PC; Thu, 06 Dec 2007 13:23:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LNl-0007pR-B4 for mext@ietf.org; Thu, 06 Dec 2007 13:23:33 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LNk-0003QB-Tb for mext@ietf.org; Thu, 06 Dec 2007 13:23:33 -0500 X-IronPort-AV: E=Sophos;i="4.23,262,1194217200"; d="vcf'?scan'208";a="6558926" Received: from unknown (HELO chokaisan.local) ([130.129.85.82]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2007 19:23:30 +0100 Message-ID: <47583E0F.2010605@inria.fr> Date: Thu, 06 Dec 2007 19:23:11 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> In-Reply-To: <1196963280.6489.30.camel@localhost> Content-Type: multipart/mixed; boundary="------------040007000401050906000409" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------040007000401050906000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> - For the MR-to-MR optimisation, is there any difference -- significant >> for the personal MR scenario -- when the MRs are attached to the same >> link vs the general case? > > What do you mean by "general case"? As in for Avionics, Car, and CE > industries? If so, then there is a big difference. Most use cases > indicates a strong need for MR-to-MR optimization in CE, whereas not so > in avionics. For car industry, as Thierry pointed out, the c2ccc has > defined their own layer 2 manet-like route optimization for car-to-car > communications. So, they have zero needs for MR-to-MR optimization. This is wrong ChanWah, I didn't say that and if it was interpreted as such I didn't express me clearly. I said there is: - 1: a need for direct MR-MR communication (over a direct wireless link when vehicles are in short range) but I didn't say layer 2, though this is what the C2C-CC is looking at for safety applications and no, Carlos they do have a solution. The requirements is a document for the IETF to focus its work. But the C2C-CC vision is not the only one in the car industry and for non-safety application it's not a L2 solution. - 2: a need for MR-MR communication via the access network: for instance when vehicles are not in the same communication range over a physical medium. It is clearly not acceptable to have such communication going through the HA (or 2 HAs if they don't have the same). Thierry --------------040007000401050906000409 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------040007000401050906000409 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------040007000401050906000409-- From mext-bounces@ietf.org Thu Dec 06 13:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LWb-0001XB-If; Thu, 06 Dec 2007 13:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LWa-0001W8-1l for mext@ietf.org; Thu, 06 Dec 2007 13:32:40 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LWZ-0005xc-8d for mext@ietf.org; Thu, 06 Dec 2007 13:32:40 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id CE3AE2A861E; Thu, 6 Dec 2007 19:32:37 +0100 (CET) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thierry Ernst In-Reply-To: <47583E0F.2010605@inria.fr> References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> <47583E0F.2010605@inria.fr> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 19:32:35 +0100 Message-Id: <1196965955.27208.156.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816747232==" Errors-To: mext-bounces@ietf.org --===============0816747232== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aqBA/R4gujkfzmnLwiWd" --=-aqBA/R4gujkfzmnLwiWd Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Thierry, > - 1: a need for direct MR-MR communication (over a direct wireless > link=20 > when vehicles are in short range) but I didn't say layer 2, though > this=20 > is what the C2C-CC is looking at for safety applications and no, > Carlos=20 > they do have a solution. The requirements is a document for the IETF > to=20 > focus its work. But the C2C-CC vision is not the only one in the car=20 > industry and for non-safety application it's not a L2 solution. >=20 I said "car industry" not C2C-CC. I know C2C-CC does have a solution, but I was trying to mean that we (IETF) are now working on the requirements, not yet in the solutions. So basically, I think we agree on this ;-). > - 2: a need for MR-MR communication via the access network: for > instance=20 > when vehicles are not in the same communication range over a > physical=20 > medium. It is clearly not acceptable to have such communication going=20 > through the HA (or 2 HAs if they don't have the same). Yes, I agree on that. Regards, Carlos > Thierry >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-aqBA/R4gujkfzmnLwiWd Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWEBDNdy6TdFwT2cRAsCXAJ4hhoFIPP8Ahxg3H1Z0M3n30L7+aACg44KP 2ZksNnazqrOredO4T5CSL/c= =/G8B -----END PGP SIGNATURE----- --=-aqBA/R4gujkfzmnLwiWd-- --===============0816747232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0816747232==-- From mext-bounces@ietf.org Thu Dec 06 13:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LYV-0002h1-4e; Thu, 06 Dec 2007 13:34:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LYT-0002gs-Ot for mext@ietf.org; Thu, 06 Dec 2007 13:34:37 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LYT-0006CX-2C for mext@ietf.org; Thu, 06 Dec 2007 13:34:37 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id lB6IYXW0027520; Fri, 7 Dec 2007 03:34:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lB6IYYR10169; Fri, 7 Dec 2007 03:34:34 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id lB6IYVM10852; Fri, 7 Dec 2007 03:34:32 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 02:34:15 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 7F793264E220; Fri, 7 Dec 2007 02:33:22 +0800 (SGT) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <47583E0F.2010605@inria.fr> References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> <47583E0F.2010605@inria.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Labs Date: Fri, 07 Dec 2007 02:33:22 +0800 Message-Id: <1196966002.6489.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 06 Dec 2007 18:34:16.0143 (UTC) FILETIME=[9B1715F0:01C83836] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Thu, 2007-12-06 at 19:23 +0100, Thierry Ernst wrote: > >> - For the MR-to-MR optimisation, is there any difference -- significant > >> for the personal MR scenario -- when the MRs are attached to the same > >> link vs the general case? > > > > What do you mean by "general case"? As in for Avionics, Car, and CE > > industries? If so, then there is a big difference. Most use cases > > indicates a strong need for MR-to-MR optimization in CE, whereas not so > > in avionics. For car industry, as Thierry pointed out, the c2ccc has > > defined their own layer 2 manet-like route optimization for car-to-car > > communications. So, they have zero needs for MR-to-MR optimization. > > This is wrong ChanWah, I didn't say that and if it was interpreted as > such I didn't express me clearly. > I said there is: > > - 1: a need for direct MR-MR communication (over a direct wireless link > when vehicles are in short range) but I didn't say layer 2, though this > is what the C2C-CC is looking at for safety applications and no, Carlos > they do have a solution. The requirements is a document for the IETF to > focus its work. But the C2C-CC vision is not the only one in the car > industry and for non-safety application it's not a L2 solution. > > - 2: a need for MR-MR communication via the access network: for instance > when vehicles are not in the same communication range over a physical > medium. It is clearly not acceptable to have such communication going > through the HA (or 2 HAs if they don't have the same). Ah, I stand corrected. However, my response was based on the (only) available draft from the car industry. The question is whether is there a use-case for car-to-car comm`unications that requires RO for car-to-car that are not in range using the sub-IP solution. I don't see that (at least from the c2ccc draft). /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 13:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LZF-0003PQ-4N; Thu, 06 Dec 2007 13:35:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LZD-0003PJ-Ik for mext@ietf.org; Thu, 06 Dec 2007 13:35:23 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LZC-0004dR-RE for mext@ietf.org; Thu, 06 Dec 2007 13:35:23 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id AF9302C020EAE; Thu, 6 Dec 2007 20:35:20 +0200 (EET) Date: Thu, 6 Dec 2007 20:35:20 +0200 (EET) From: Wassim Haddad To: Vijay Devarapalli Subject: Re: [MEXT] New items for the mext charter discussion In-Reply-To: <475831F1.2000409@azairenet.com> Message-ID: References: <47579670.90905@azairenet.com> <475831F1.2000409@azairenet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Hesham Soliman , mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Thu, 6 Dec 2007, Vijay Devarapalli wrote: The following applies only in case you're assuming that ROHC is everywhere which is already a wrong assumption. But please keep reading. >>>> ROHC is deployed *only* in particular networks and in these networks when >>>> you switch between BS, ROHC has to "reboot". >>> >>> hmm... this is not entirely accurate. There are networks where the >>> context is transferred and you could continue in the same state as >>> the old link. No need for a "reboot". >> >> Transferring context between base stations is NOT supported in the E-UTRAN >> (main reason is that it is even more complex than ROHC itself). This means >> that it has to be restarted at each handoff. > > Lets look at the details. ROHC re-start is actually straight forward. => ROHC restart means that some packet will not be compressed. Moreover, in case of any minor error, then it has to restart again... > It only takes a few data packets to go from the full header to first > order and then to second order. => First, few data packets and zero data packets are different. This is called efficiency. Second, as you are also implicitely getting privacy, then you cannot afford showing your identity in few packets after each handoff. > mobile node had to setup ROHC state again. The RTP numbers could go > out of sync if the L2 handoff takes too long and the mobile node > lost some packets during the handover. The biggest issue I have seen > in transferring ROHC context is that the context could be stale (out > of sync) forcing the mobile to re-start anyway. > > I don't believe transferring ROHC context is very complicated. => What kind of statement is this? Are you "guessing" here?!!!! Anyway, I think you should _strengthen your belief_! As am not an expert in ROHC, I had to ask our experts in this area (this is to explain to you why I only answered you this morning). In summary: it is *extremely* complicated to transfer context and thus it is NOT supported and ROHC will reboot at each handoff. > reason it is not being used in E-UTRAN could be because they have a > mechanism to install the context pretty fast at the new base station. > You might want to check on that. => Really? Which one? How this explains that ROHC will reboot at each time? :) > BTW, there have been numerous proposals to transfer ROHC context. > Just google for it. => I'll keep this one for you! :) I don't have time for that! I think we have already a proposal on that which solves elegantly the problem. Wassim H. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 13:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LjY-0001r0-6m; Thu, 06 Dec 2007 13:46:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LjW-0001kR-DE for mext@ietf.org; Thu, 06 Dec 2007 13:46:02 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LjV-0005W6-LT for mext@ietf.org; Thu, 06 Dec 2007 13:46:02 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id lB6IjvEI012447; Fri, 7 Dec 2007 03:45:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id lB6IjwR21998; Fri, 7 Dec 2007 03:45:58 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id lB6Ijvg07736; Fri, 7 Dec 2007 03:45:57 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 02:45:39 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 8E9ED264E220; Fri, 7 Dec 2007 02:44:46 +0800 (SGT) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Chan-Wah Ng To: cjbc@it.uc3m.es In-Reply-To: <1196964612.27208.152.camel@localhost> References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> <1196964612.27208.152.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Panasonic Singapore Labs Date: Fri, 07 Dec 2007 02:44:45 +0800 Message-Id: <1196966685.6489.48.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 06 Dec 2007 18:45:40.0049 (UTC) FILETIME=[32BADC10:01C83838] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Thu, 2007-12-06 at 19:10 +0100, Carlos Jes=FAs Bernardos Cano wrote: > >=20 > > >=20 > > > - I'd consider adding a requirement regarding modification of > > > correspondent nodes. > >=20 > > I would not :). Consumer electronics industries is changing at a rapid > > pace. How long did you use your last handphone/laptop? 3 years? 2? I > > know of people who upgrades their phones every year. CN modification i= s > > not a concern. Plus, most of the scenarios indicate a strong need for > > RO with MR-to-MR communications, much less MR-to-CN. >=20 > Well, if all the potential use cases of interests are MR-to-MR, I'm > fine, but if there is also a bunch of scenarios involving MR-to-CN, then > I disagree that modifying the CN is not a problem. For instance, do you > expect youtube servers to be modified just to support NEMO RO? There are two related question here. =20 #1) is RO needed for viewing youtube?=20 #2) Would YouTube server support MIPv6 RO? If it does, why not NEMO RO? :) The first question is more relevant here. As I mentioned in the draft, it is all about use-cases. We would of-course like to have the best quality of communications for everything. But is RO required for web-browsing, You-tube viewing, checking Google Maps? I don't see a need here. The most important use-case right now is real-time interactive applications (gaming, video/audio conferencing). These involve CNs that are willing to be modified because it is mutually beneficial. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 13:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lph-0008DF-Ti; Thu, 06 Dec 2007 13:52:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lph-0008C2-1U for mext@ietf.org; Thu, 06 Dec 2007 13:52:25 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Lpg-0007YH-Cl for mext@ietf.org; Thu, 06 Dec 2007 13:52:25 -0500 Received: from [130.129.19.231] (dhcp-13e7.ietf70.org [130.129.19.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D658827EF58; Thu, 6 Dec 2007 19:52:22 +0100 (CET) Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: chanwah.ng@sg.panasonic.com In-Reply-To: <1196966685.6489.48.camel@localhost> References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> <1196964612.27208.152.camel@localhost> <1196966685.6489.48.camel@localhost> Organization: Universidad Carlos III de Madrid Date: Thu, 06 Dec 2007 19:52:20 +0100 Message-Id: <1196967140.27208.166.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1133257258==" Errors-To: mext-bounces@ietf.org --===============1133257258== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0ZU00Q9garLnPOnGGjcF" --=-0ZU00Q9garLnPOnGGjcF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Chan-Wah, El vie, 07-12-2007 a las 02:44 +0800, Chan-Wah Ng escribi=F3: > On Thu, 2007-12-06 at 19:10 +0100, Carlos Jes=FAs Bernardos Cano wrote: > > >=20 > > > >=20 > > > > - I'd consider adding a requirement regarding modification of > > > > correspondent nodes. > > >=20 > > > I would not :). Consumer electronics industries is changing at a rap= id > > > pace. How long did you use your last handphone/laptop? 3 years? 2? = I > > > know of people who upgrades their phones every year. CN modification= is > > > not a concern. Plus, most of the scenarios indicate a strong need fo= r > > > RO with MR-to-MR communications, much less MR-to-CN. > >=20 > > Well, if all the potential use cases of interests are MR-to-MR, I'm > > fine, but if there is also a bunch of scenarios involving MR-to-CN, the= n > > I disagree that modifying the CN is not a problem. For instance, do you > > expect youtube servers to be modified just to support NEMO RO? >=20 > There are two related question here. =20 >=20 > #1) is RO needed for viewing youtube?=20 >=20 (see below) > #2) Would YouTube server support MIPv6 RO? If it does, why not NEMO > RO? :) Well, probably it will not support MIPv6 RO :-(. But if it does, it's obviously easier to assume that the smaller the number of changes we require, the bigger are the probabilities to get NEMO RO deployed. >=20 > The first question is more relevant here. As I mentioned in the draft, > it is all about use-cases. We would of-course like to have the best > quality of communications for everything. But is RO required for > web-browsing, You-tube viewing, checking Google Maps? I don't see a > need here. The most important use-case right now is real-time > interactive applications (gaming, video/audio conferencing). These > involve CNs that are willing to be modified because it is mutually > beneficial. I completely agree on the real-time comment, you want to perform RO to reduce the e2e delay, but it's also mentioned in the draft that another nice feature brought by RO is that you avoid problems related to home network congestion (and broadband residential access asymmetry). In the later case, optimising youtube (or this kind of applications) might be interesting as well. Regards, Carlos >=20 > /rgds > /cwng >=20 >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-0ZU00Q9garLnPOnGGjcF Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHWETkNdy6TdFwT2cRAoChAKChRnkihGsNwPc8PrNAhCudIsx7PQCgkVO9 7UNNhatxP7sxyUnIfS8pmTM= =1jrd -----END PGP SIGNATURE----- --=-0ZU00Q9garLnPOnGGjcF-- --===============1133257258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1133257258==-- From mext-bounces@ietf.org Thu Dec 06 13:58:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lvz-0002YU-Eb; Thu, 06 Dec 2007 13:58:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lvx-0002YN-Ru for mext@ietf.org; Thu, 06 Dec 2007 13:58:53 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Lvx-0006MA-At for mext@ietf.org; Thu, 06 Dec 2007 13:58:53 -0500 Received: (qmail 17496 invoked from network); 6 Dec 2007 19:58:49 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 6 Dec 2007 19:58:49 +0100 From: "Teco Boot" To: Date: Thu, 6 Dec 2007 19:58:13 +0100 Message-ID: <00f101c8383a$08348f20$189dad60$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4OfPpcmFdlKQWQ2mNpptVYai+tw== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [MEXT] NEMO-PD - DHCP support on Mobile Network X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0905105397==" Errors-To: mext-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0905105397== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01C83842.69F8F720" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_00F2_01C83842.69F8F720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On the two drafts for NEMO prefix delegation, I wonder how we can support DHCP on Mobile Network. I think there are two options, DHCP Relay or running DHCP Server on MR itself. For the latter, we need not only a prefix, but also data for DHCP options. Remark on overhead, I think the prefix delegation signaling has low overhead, depending on lifetimes. Lifetime can be a order longer that BU (PD: hours, days, months; BU: seconds, minutes). Teco. ------=_NextPart_000_00F2_01C83842.69F8F720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the two drafts for NEMO prefix delegation, I = wonder how we can support DHCP on Mobile Network. I think there are two options, = DHCP Relay or running DHCP Server on MR itself. For the latter, we need not = only a prefix, but also data for DHCP options.

 

Remark on overhead, I think the prefix delegation = signaling has low overhead, depending on lifetimes. Lifetime can be a order longer = that BU (PD: hours, days, months; BU: seconds, minutes).

 

Teco.

 

 

------=_NextPart_000_00F2_01C83842.69F8F720-- --===============0905105397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0905105397==-- From mext-bounces@ietf.org Thu Dec 06 14:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M6t-0003ZI-Fv; Thu, 06 Dec 2007 14:10:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M6r-0003Z9-Pk for mext@ietf.org; Thu, 06 Dec 2007 14:10:09 -0500 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0M6r-0007GQ-Dz for mext@ietf.org; Thu, 06 Dec 2007 14:10:09 -0500 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 6382E25F707 for ; Thu, 6 Dec 2007 19:10:08 +0000 (WET) Received: from medusa (dhcp-251.ci.uc.pt [193.136.200.251]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 33C8425F6F2 for ; Thu, 6 Dec 2007 19:10:08 +0000 (WET) From: "Pedro Pinheiro" To: Subject: [MEXT] Comments on draft-ng-nemo-ce-req-01 Date: Thu, 6 Dec 2007 19:10:07 -0000 Message-ID: <056e01c8383b$9de2ede0$d9a8c9a0$@uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4OTJnehhnV2ijT9uc8SYUEzGlAAAAYy/wAAA0YcA= Content-Language: pt X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > #2) Would YouTube server support MIPv6 RO? If it does, why not NEMO > > RO? :) > > Well, probably it will not support MIPv6 RO :-(. But if it does, it's > obviously easier to assume that the smaller the number of changes we > require, the bigger are the probabilities to get NEMO RO deployed. Yes, you are right, Carlos. However, I must agree with Ng that I do think that if a better solution would require CN modification, then we must consider it as, sooner or later this will be implemented. And if the idea is really good and effective, then it would be implemented sooner than what we think. IMHO. :) Fortunately, the MIRON solution is really good and don't require much CN modification ;) Best regards, Pedro Vapi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 14:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MEV-0007bt-Lj; Thu, 06 Dec 2007 14:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MEU-0007bl-O2 for mext@ietf.org; Thu, 06 Dec 2007 14:18:02 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0MEU-00015z-6O for mext@ietf.org; Thu, 06 Dec 2007 14:18:02 -0500 X-IronPort-AV: E=Sophos;i="4.23,262,1194217200"; d="vcf'?scan'208";a="6560136" Received: from unknown (HELO chokaisan.local) ([130.129.85.82]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2007 20:18:00 +0100 Message-ID: <47584AD6.4060401@inria.fr> Date: Thu, 06 Dec 2007 20:17:42 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mext@ietf.org Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 References: <056e01c8383b$9de2ede0$d9a8c9a0$@uc.pt> In-Reply-To: <056e01c8383b$9de2ede0$d9a8c9a0$@uc.pt> Content-Type: multipart/mixed; boundary="------------070900010801050304000409" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------070900010801050304000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pedro Pinheiro wrote: >>> #2) Would YouTube server support MIPv6 RO? If it does, why not NEMO >>> RO? :) >> Well, probably it will not support MIPv6 RO :-(. But if it does, it's >> obviously easier to assume that the smaller the number of changes we >> require, the bigger are the probabilities to get NEMO RO deployed. > > Yes, you are right, Carlos. > However, I must agree with Ng that I do think that if a better solution > would require CN modification, then we must consider it as, sooner or later > this will be implemented. And if the idea is really good and effective, then > it would be implemented sooner than what we think. IMHO. :) > > Fortunately, the MIRON solution is really good and don't require much CN > modification ;) The RO PS and Sol Analysis drafts do suggest that a solution providing RO with a router (a CR if you wish) have some benefits. Intuitively, it seems logical to have NEMO RO from router to router and not router to CN. Also, the global HAHA solution for multihoming could prove useful for NEMO RO. Thierry --------------070900010801050304000409 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------070900010801050304000409 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------070900010801050304000409-- From nemo-bounces@ietf.org Thu Dec 06 14:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MQe-0008Ap-Mw; Thu, 06 Dec 2007 14:30:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MQb-0008A1-1w; Thu, 06 Dec 2007 14:30:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MQa-0000UP-MP; Thu, 06 Dec 2007 14:30:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5708E175F2; Thu, 6 Dec 2007 19:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J0MQ5-0001FR-Se; Thu, 06 Dec 2007 14:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Dec 2007 14:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org Subject: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, P. Thubert Filename : draft-ietf-nemo-dhcpv6-pd-03.txt Pages : 11 Date : 2007-12-06 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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: <2007-12-06142814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-dhcpv6-pd-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-06142814.I-D\@ietf.org> --OtherAccess-- --NextPart-- From mext-bounces@ietf.org Thu Dec 06 14:34:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MUO-0005da-MK; Thu, 06 Dec 2007 14:34:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MUN-0005Uc-EV for mext@ietf.org; Thu, 06 Dec 2007 14:34:27 -0500 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MUM-0000ra-By for mext@ietf.org; Thu, 06 Dec 2007 14:34:26 -0500 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id BD2A825F708 for ; Thu, 6 Dec 2007 19:34:25 +0000 (WET) Received: from medusa (dhcp-251.ci.uc.pt [193.136.200.251]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 88BAE25F707 for ; Thu, 6 Dec 2007 19:34:25 +0000 (WET) From: "Pedro Pinheiro" To: References: <056e01c8383b$9de2ede0$d9a8c9a0$@uc.pt> <47584AD6.4060401@inria.fr> In-Reply-To: <47584AD6.4060401@inria.fr> Subject: RE: [MEXT] Comments on draft-ng-nemo-ce-req-01 Date: Thu, 6 Dec 2007 19:34:24 -0000 Message-ID: <057b01c8383f$027a8c60$076fa520$@uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4PMe4cD+dpgvtRe2MKZ0hLHZDmgAAQHEw Content-Language: pt X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >>> #2) Would YouTube server support MIPv6 RO? If it does, why not > NEMO > >>> RO? :) > >> Well, probably it will not support MIPv6 RO :-(. But if it does, > it's > >> obviously easier to assume that the smaller the number of changes = we > >> require, the bigger are the probabilities to get NEMO RO deployed. > > > > Yes, you are right, Carlos. > > However, I must agree with Ng that I do think that if a better > solution > > would require CN modification, then we must consider it as, sooner = or > later > > this will be implemented. And if the idea is really good and > effective, then > > it would be implemented sooner than what we think. IMHO. :) > > > > Fortunately, the MIRON solution is really good and don't require = much > CN > > modification ;) >=20 > The RO PS and Sol Analysis drafts do suggest that a solution providing > RO with a router (a CR if you wish) have some benefits. Intuitively, = it > seems logical to have NEMO RO from router to router and not router to > CN. Also, the global HAHA solution for multihoming could prove useful > for NEMO RO. Well... IMHO, a *really better* solution would involve the CN to MNN = route optimization. If I do remember well, MR to CR optimization brings some problems that = are complex to solve (which CR will optimize, when to optimize, where would = we place the CR with this capability, how many CR would we need on the Internet, and so on). I do believe I've read it at a wonderful draft, = but I don't remember where. Also, I thought that global HAHA was a solution for really far away from home network, and not a final solution for all CN to MNN communication. Regarding the question place by Carlos, and argued by Ng, I do still = agree with Ng that if a solution would require a modification on the CN's = side, then we should not be afraid of changing it... I must think in a long = term. But, of course, this is IM-realllyyy-HO. Best regards, Pedro Vapi ------------------------------------ Universidade de Coimbra Pedro Pinheiro Eng, MSc vapi@univ-coimbra.eu Centro de Informatica=20 R. Arco da Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351 239 853 189 IM: MSN: pvapi@hotmail.com http://www.univ-coimbra.eu/pessoal/vapi/ Skype ID:pedrovapi ------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AprilweissMoyer@annapolischorale.org Thu Dec 06 15:59:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Nok-00039P-Ku; Thu, 06 Dec 2007 15:59:34 -0500 Received: from 131.red-83-44-134.dynamicip.rima-tde.net ([83.44.134.131] helo=nombre78ff4ced) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0Noj-0006Zh-1y; Thu, 06 Dec 2007 15:59:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host12043857.annapolischorale.org (8.13.1/8.13.1) with SMTP id bwmmaKbT34.171611.IZg.5mo.1725949157069 for ; Thu, 6 Dec 2007 21:58:48 -0100 Message-ID: From: "Leslie Manley" To: , =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_DEEA_01C8384A.E2778C40-- From mext-bounces@ietf.org Thu Dec 06 16:17:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0O6M-0004bG-7A; Thu, 06 Dec 2007 16:17:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0O6J-0004b2-UB for mext@ietf.org; Thu, 06 Dec 2007 16:17:43 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0O6J-0008Pp-F3 for mext@ietf.org; Thu, 06 Dec 2007 16:17:43 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1196975862!20487374!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 21420 invoked from network); 6 Dec 2007 21:17:42 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-15.tower-128.messagelabs.com with SMTP; 6 Dec 2007 21:17:42 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lB6LHdGG010107; Thu, 6 Dec 2007 14:17:42 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lB6LHc5J026716; Thu, 6 Dec 2007 15:17:38 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-213.corp.mot.com [10.19.249.213]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB6LHaJu026691; Thu, 6 Dec 2007 15:17:37 -0600 (CST) Message-ID: <475866EF.6080908@gmail.com> Date: Thu, 06 Dec 2007 13:17:35 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Pedro Pinheiro Subject: Re: [MEXT] ICMP error...? References: <047901c83807$ace3dcc0$06ab9640$@uc.pt> In-Reply-To: <047901c83807$ace3dcc0$06ab9640$@uc.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Pedro Pinheiro wrote: > Hi all, > > I don't know if this subject has already been discussed. If so, please > forgive me and point to me where can I find a answer. > My question is relative to NEMO Basic Support protocol. > > If a packet from a CN to a MNN (or vice-versa) goes into a MRHA packet and > this is traversing the Internet, don't matter if destined to HA or to CoA's > MR, and any router has to generate a ICMP error (unreachable, ...) it will > generate it destined to the HA's or CoA's IP. Right... > In this situation how will the HA or MR find out the origin of the packet > inside the MRHA? The origin of the packet is the src field of that ICMP Error, right? Not sure where the error happens exactly (between CN and HA? between HA and MR?) Alex > The icmp will not forward the MRHA packet so that HA or MR > could see inside it and return a ICMP error to the CN or MNN. > > I hope I have made myself clear. > Thank you in advance. > Pedro Vapi > > ------------------------------------ > Universidade de Coimbra > Pedro Pinheiro > Eng, MSc > vapi@univ-coimbra.eu > Centro de Informatica > R. Arco da Traição, Ap. 3080 > 3001-401 COIMBRA > tel: +351 239 853 170 > fax: +351 239 853 189 > IM: MSN: pvapi@hotmail.com > http://www.univ-coimbra.eu/pessoal/vapi/ > Skype ID:pedrovapi > ------------------------------------ > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 16:23:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OC3-0007og-Uc; Thu, 06 Dec 2007 16:23:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OC2-0007oY-C6 for mext@ietf.org; Thu, 06 Dec 2007 16:23:38 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0OC1-0000Y3-Tp for mext@ietf.org; Thu, 06 Dec 2007 16:23:38 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1196976216!11135667!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 29867 invoked from network); 6 Dec 2007 21:23:36 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-10.tower-128.messagelabs.com with SMTP; 6 Dec 2007 21:23:36 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB6LNWcC001841; Thu, 6 Dec 2007 14:23:36 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id lB6LNVGQ015903; Thu, 6 Dec 2007 15:23:31 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-213.corp.mot.com [10.19.249.213]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id lB6LNSjZ015865; Thu, 6 Dec 2007 15:23:29 -0600 (CST) Message-ID: <4758684F.5020400@gmail.com> Date: Thu, 06 Dec 2007 13:23:27 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Teco Boot Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network References: <00f101c8383a$08348f20$189dad60$@nl> In-Reply-To: <00f101c8383a$08348f20$189dad60$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Teco Boot wrote: > On the two drafts for NEMO prefix delegation, I wonder how we can > support DHCP on Mobile Network. I think there are two options, DHCP > Relay or running DHCP Server on MR itself. For the latter, we need > not only a prefix, but also data for DHCP options. I think one additional possibility suggested by Francis was to use a DHCPv6 Relay co-located with a DHCPv6 Client - in the Mobile Router(!) In my understanding, this would relieve from the potential problem of putting the DHCPv6 Solicit multicast message in the MR-HA tunnel (virtual interface) - because the DHCPv6 Relay (MR) would know the unicast address of the DHCPv6 Server, no need to tunnel. I'm not sure though whether in IPv6 the Relay uses a unicast address to forward the Solicit, or a multicast. There are of course other possibilities for DHCPv6 with NEMO and I currently think like many have their advantages. Software availability should be taken into account too. > Remark on overhead, I think the prefix delegation signaling has low > overhead, depending on lifetimes. Lifetime can be a order longer that > BU (PD: hours, days, months; BU: seconds, minutes). I think a binding could last more than a few minutes. I think we can try to compare number of signalling messages of using DHCPv6-PD for delegating the MNP vs the MIPv6-BU-PD extensions. I think the signalling is probably on the same scale. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 16:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OF6-0000l1-Lx; Thu, 06 Dec 2007 16:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OF5-0000kr-8x for mext@ietf.org; Thu, 06 Dec 2007 16:26:47 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0OF3-0002VC-Jh for mext@ietf.org; Thu, 06 Dec 2007 16:26:47 -0500 Received: from [127.0.0.1] ([130.129.21.232]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 13:26:44 -0800 Message-ID: <4758690C.6050907@azairenet.com> Date: Thu, 06 Dec 2007 13:26:36 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Wassim Haddad Subject: Re: [MEXT] New items for the mext charter discussion References: <47579670.90905@azairenet.com> <475831F1.2000409@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Dec 2007 21:26:44.0899 (UTC) FILETIME=[B36DEF30:01C8384E] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Hesham Soliman , mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Wassim Haddad wrote: > On Thu, 6 Dec 2007, Vijay Devarapalli wrote: > > The following applies only in case you're assuming that ROHC is everywhere > which is already a wrong assumption. I don't think I said ROHC is used everywhere. I was commenting on ROHC context transfer. But please keep reading. > >>>>> ROHC is deployed *only* in particular networks and in these >>>>> networks when you switch between BS, ROHC has to "reboot". >>>> >>>> hmm... this is not entirely accurate. There are networks where the >>>> context is transferred and you could continue in the same state as >>>> the old link. No need for a "reboot". >>> >>> Transferring context between base stations is NOT supported in the >>> E-UTRAN >>> (main reason is that it is even more complex than ROHC itself). This >>> means that it has to be restarted at each handoff. >> >> Lets look at the details. ROHC re-start is actually straight forward. > > => ROHC restart means that some packet will not be compressed. Moreover, in > case of any minor error, then it has to restart again... > >> It only takes a few data packets to go from the full header to first >> order and then to second order. > > => First, few data packets and zero data packets are different. This is > called efficiency. Second, as you are also implicitely getting privacy, > then you cannot afford showing your identity in few packets after each > handoff. > >> mobile node had to setup ROHC state again. The RTP numbers could go >> out of sync if the L2 handoff takes too long and the mobile node >> lost some packets during the handover. The biggest issue I have seen >> in transferring ROHC context is that the context could be stale (out >> of sync) forcing the mobile to re-start anyway. >> >> I don't believe transferring ROHC context is very complicated. > > => What kind of statement is this? Are you "guessing" here?!!!! Based on my implementation experience (transferring ROHC context using the Seamoby CT protocol), it was not difficult. It was not at all complicated. Sometime the transferred context is just not usable and in that case ROHC is re-started. > Anyway, I think you should _strengthen your belief_! > As am not an expert in ROHC, I had to ask our experts in this area (this > is to explain to you why I only answered you this morning). > In summary: it is *extremely* complicated to transfer context and thus > it is NOT supported and ROHC will reboot at each handoff. I don't buy the argument that it is complicated. But its ok to disagree. Lets move on. >> reason it is not being used in E-UTRAN could be because they have a >> mechanism to install the context pretty fast at the new base station. >> You might want to check on that. > > => Really? Which one? How this explains that ROHC will reboot at each > time? :) > >> BTW, there have been numerous proposals to transfer ROHC context. >> Just google for it. > > => I'll keep this one for you! :) I don't have time for that! I think we > have already a proposal on that which solves elegantly the problem. I was not comparing using ROHC with your draft. I was commenting on your statement on the mailing list that you have to re-start ROHC every time there is a handover. That is simply not true. 3GPP have may taken this decision on E-UTRAN handovers, but that does not make it a universal fact. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 16:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OFA-0000qY-A6; Thu, 06 Dec 2007 16:26:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OF8-0000mT-V8 for mext@ietf.org; Thu, 06 Dec 2007 16:26:51 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0OF8-0000uj-HX for mext@ietf.org; Thu, 06 Dec 2007 16:26:50 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB6LQcL2015619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Dec 2007 15:26:38 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB6LQcAL000111; Thu, 6 Dec 2007 15:26:38 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB6LQVp4029883; Thu, 6 Dec 2007 15:26:38 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 13:26:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] NEMO-PD - DHCP support on Mobile Network Date: Thu, 6 Dec 2007 13:26:36 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCB4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4758684F.5020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] NEMO-PD - DHCP support on Mobile Network Thread-Index: Acg4Tk/1qYTjB7A9TKS+cuPxkjCYGQAADpQw References: <00f101c8383a$08348f20$189dad60$@nl> <4758684F.5020400@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 06 Dec 2007 21:26:36.0608 (UTC) FILETIME=[AE7CD400:01C8384E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, December 06, 2007 1:23 PM > To: Teco Boot > Cc: mext@ietf.org > Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network >=20 > Teco Boot wrote: > > On the two drafts for NEMO prefix delegation, I wonder how we can=20 > > support DHCP on Mobile Network. I think there are two options, DHCP=20 > > Relay or running DHCP Server on MR itself. For the latter, we need > > not only a prefix, but also data for DHCP options. >=20 > I think one additional possibility suggested by Francis was to use a > DHCPv6 Relay co-located with a DHCPv6 Client - in the Mobile Router(!) This has been documented in 'draft-templin-autoconf-dhcp' for some time. Fred fred.l.templin@boeing.com > In my understanding, this would relieve from the potential problem of > putting the DHCPv6 Solicit multicast message in the MR-HA tunnel > (virtual interface) - because the DHCPv6 Relay (MR) would know the > unicast address of the DHCPv6 Server, no need to tunnel. I'm not sure > though whether in IPv6 the Relay uses a unicast address to forward the > Solicit, or a multicast. >=20 > There are of course other possibilities for DHCPv6 with NEMO and I > currently think like many have their advantages. >=20 > Software availability should be taken into account too. >=20 > > Remark on overhead, I think the prefix delegation signaling has low=20 > > overhead, depending on lifetimes. Lifetime can be a order=20 > longer that > > BU (PD: hours, days, months; BU: seconds, minutes). >=20 > I think a binding could last more than a few minutes. >=20 > I think we can try to compare number of signalling messages of using > DHCPv6-PD for delegating the MNP vs the MIPv6-BU-PD=20 > extensions. I think > the signalling is probably on the same scale. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 17:13:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OyO-0004BS-1q; Thu, 06 Dec 2007 17:13:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OyM-00048c-0n for mext@ietf.org; Thu, 06 Dec 2007 17:13:34 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0OyL-0006Wy-J0 for mext@ietf.org; Thu, 06 Dec 2007 17:13:33 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1196979211!472588!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5487 invoked from network); 6 Dec 2007 22:13:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 6 Dec 2007 22:13:32 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB6MDV6l004131; Thu, 6 Dec 2007 15:13:31 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lB6MDUQM013943; Thu, 6 Dec 2007 16:13:31 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-213.corp.mot.com [10.19.249.213]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB6MDTYl013917; Thu, 6 Dec 2007 16:13:30 -0600 (CST) Message-ID: <4758740C.7010400@gmail.com> Date: Thu, 06 Dec 2007 14:13:32 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network References: <00f101c8383a$08348f20$189dad60$@nl> <4758684F.5020400@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCB4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCB4@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Templin, Fred L wrote: > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, December 06, 2007 1:23 PM >> To: Teco Boot >> Cc: mext@ietf.org >> Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network >> >> Teco Boot wrote: >>> On the two drafts for NEMO prefix delegation, I wonder how we can >>> support DHCP on Mobile Network. I think there are two options, DHCP >>> Relay or running DHCP Server on MR itself. For the latter, we need >>> not only a prefix, but also data for DHCP options. >> I think one additional possibility suggested by Francis was to use a >> DHCPv6 Relay co-located with a DHCPv6 Client - in the Mobile Router(!) > > This has been documented in 'draft-templin-autoconf-dhcp' > for some time. Fred, I agree. It says so at top of page 10. Looks as me having missed this earlier reference. From an implementation standpoint there are however some issues with this. If the Relay uses a multicast address to talk to the Server then we'd still have some potential issues putting multicast packets (Solicit) in the MR-HA tunnel. The other issue may be related to whether implementations of DHCPv6-PD support Relay or not and how. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 19:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qej-00061p-Pj; Thu, 06 Dec 2007 19:01:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qei-00061a-9I for mext@ietf.org; Thu, 06 Dec 2007 19:01:24 -0500 Received: from givry.fdupont.fr ([91.121.26.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Qeh-00058D-Rv for mext@ietf.org; Thu, 06 Dec 2007 19:01:24 -0500 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id lB701Jft045175; Fri, 7 Dec 2007 01:01:19 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200712070001.lB701Jft045175@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network In-reply-to: Your message of Thu, 06 Dec 2007 13:23:27 PST. <4758684F.5020400@gmail.com> Date: Fri, 07 Dec 2007 01:01:19 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org In your previous mail you wrote: I'm not sure though whether in IPv6 the Relay uses a unicast address to forward the Solicit, or a multicast. => it uses what you have configured to use so if you give server address(es) it uses it (them), if you leave it to guess it uses the multicast service address... Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From EttabauhausHaywood@bellinghamherald.com Thu Dec 06 19:06:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QjG-0000O6-Dw; Thu, 06 Dec 2007 19:06:06 -0500 Received: from [201.240.4.177] (helo=profesional) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0QjG-0005Tz-2F; Thu, 06 Dec 2007 19:06:06 -0500 Received: from wiretapper by bellinghamherald.com with SMTP id lbas4ojZIN for ; Thu, 6 Dec 2007 19:05:53 +0500 From: "Sallie Cope" To: Subject: If you're in the US or anywhere else, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Visit and start seeing the dollars coming. Download our casino in 20 seconds to get $999 richer when you join. Best offer in gambling history . Our safe, secure games will get you smiling when you start seeing dollars pouring in. http://eurocasinoak.com/ From mext-bounces@ietf.org Thu Dec 06 19:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qpx-0005sx-Ei; Thu, 06 Dec 2007 19:13:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qpw-0005sh-Ke for mext@ietf.org; Thu, 06 Dec 2007 19:13:00 -0500 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Qpw-0007TC-5E for mext@ietf.org; Thu, 06 Dec 2007 19:13:00 -0500 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id lB70Ct09045632; Fri, 7 Dec 2007 01:12:55 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200712070012.lB70Ct09045632@givry.fdupont.fr> From: Francis Dupont To: Alexandru Petrescu Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network In-reply-to: Your message of Thu, 06 Dec 2007 14:13:32 PST. <4758740C.7010400@gmail.com> Date: Fri, 07 Dec 2007 01:12:55 +0100 X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Templin, Fred L" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org In your previous mail you wrote: From an implementation standpoint there are however some issues with this. If the Relay uses a multicast address to talk to the Server then we'd still have some potential issues putting multicast packets (Solicit) in the MR-HA tunnel. => it is so easy to configure the relay with the address of the agent at the HA side of the tunnel you should not expect it is not done. The other issue may be related to whether implementations of DHCPv6-PD support Relay or not and how. => IMHO a DHCPv6-PD implementation without Relay support is useless, not as an implementation without Client or Server but near. Thanks Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 19:45:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RLD-0007Kc-TD; Thu, 06 Dec 2007 19:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RLC-0007KS-MB for mext@ietf.org; Thu, 06 Dec 2007 19:45:18 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0RLC-0001Pl-E2 for mext@ietf.org; Thu, 06 Dec 2007 19:45:18 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1196988317!24074675!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 31691 invoked from network); 7 Dec 2007 00:45:17 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-6.tower-119.messagelabs.com with SMTP; 7 Dec 2007 00:45:17 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB70jH3A028882; Thu, 6 Dec 2007 17:45:17 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lB70jGIA017702; Thu, 6 Dec 2007 18:45:16 -0600 (CST) Received: from [127.0.0.1] ([10.19.241.22]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB70jENY017688; Thu, 6 Dec 2007 18:45:14 -0600 (CST) Message-ID: <4758979A.3000200@gmail.com> Date: Thu, 06 Dec 2007 16:45:14 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [MEXT] NEMO-PD - DHCP support on Mobile Network References: <200712070012.lB70Ct09045632@givry.fdupont.fr> In-Reply-To: <200712070012.lB70Ct09045632@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Templin, Fred L" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > From an implementation standpoint there are however some issues with > this. If the Relay uses a multicast address to talk to the Server then > we'd still have some potential issues putting multicast packets > (Solicit) in the MR-HA tunnel. > > => it is so easy to configure the relay with the address of the agent at > the HA side of the tunnel you should not expect it is not done. If so, then the issue is then how to quickly configure the HA address on the MR, prior to MR sending this Solicit. > The other issue may be related to whether implementations of > DHCPv6-PD support Relay or not and how. > > => IMHO a DHCPv6-PD implementation without Relay support is useless, not > as an implementation without Client or Server but near. One DHCPv6 implementation will simply crash the Relay when requesting a IPv6 prefix through it. (state of affairs a few weeks ago). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 21:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sfc-0005rV-2q; Thu, 06 Dec 2007 21:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Sfa-0005YM-AN for mext@ietf.org; Thu, 06 Dec 2007 21:10:26 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0SfZ-0006Ut-U8 for mext@ietf.org; Thu, 06 Dec 2007 21:10:26 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1196993423!498264!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 11055 invoked from network); 7 Dec 2007 02:10:24 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-3.tower-128.messagelabs.com with SMTP; 7 Dec 2007 02:10:24 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB72AIP8009410 for ; Thu, 6 Dec 2007 19:10:23 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lB72AHit025865 for ; Thu, 6 Dec 2007 20:10:17 -0600 (CST) Received: from [127.0.0.1] ([10.19.245.229]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lB72AGbG025849 for ; Thu, 6 Dec 2007 20:10:16 -0600 (CST) Message-ID: <4758AB86.9090007@gmail.com> Date: Thu, 06 Dec 2007 18:10:14 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: mext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -2.4 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, P. Thubert > Filename : draft-ietf-nemo-dhcpv6-pd-03.txt > Pages : 11 > Date : 2007-12-06 Thanks for resubmitting a new version of this draft. There was some discussion around it recently, especially the D flag in DHAAD Request. Some people discussed about its necessity. Has there been a conclusion around it? Or is it just keepalive submission? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ZelmaswindleEason@annapolis.net Thu Dec 06 21:12:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Shn-0005hC-AQ; Thu, 06 Dec 2007 21:12:43 -0500 Received: from cpe-24-193-62-72.nyc.res.rr.com ([24.193.62.72] helo=gnnytimes2.nyc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0Shn-0004yS-1W; Thu, 06 Dec 2007 21:12:43 -0500 Received: from sushi by annapolis.net with SMTP id LAL2HPD559 for ; Thu, 6 Dec 2007 21:12:20 +0500 From: "Alejandra Witherspoon" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SjD-0001Ou-7h; Thu, 06 Dec 2007 21:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0SjB-0001Nn-9U for mext@ietf.org; Thu, 06 Dec 2007 21:14:09 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0SjA-0006kB-T3 for mext@ietf.org; Thu, 06 Dec 2007 21:14:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2007 18:14:08 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB72E8ju011045; Thu, 6 Dec 2007 18:14:08 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lB72E8xR026894; Fri, 7 Dec 2007 02:14:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:14:07 -0800 Received: from dhcp-10cc.ietf70.org ([10.21.126.160]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 18:14:07 -0800 Message-Id: <391EF301-E515-4AD2-A800-8B950115210A@cisco.com> From: Ralph Droms To: Alexandru Petrescu In-Reply-To: <4758AB86.9090007@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Thu, 6 Dec 2007 21:14:07 -0500 References: <4758AB86.9090007@gmail.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 07 Dec 2007 02:14:07.0804 (UTC) FILETIME=[D9006FC0:01C83876] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1484; t=1196993648; x=1197857648; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[MEXT]=20Re=3A=20[nemo]=20I-D=20Action=3Adraft-ietf-n emo-dhcpv6-pd-03.txt |Sender:=20; bh=OWqdajXGFBQo+jJ+tA4MG3uZ7o48CuDlrz0lBRrj33g=; b=MxSnmPnGCpeBIvtAF+GUuXkkdakKJ3pQDbSOxr6AWJ5/nGKHd/4+Crd/peaS8aX43C/nUGsZ Nonuv5BkYWlgwY9GiJCmvpD16CAAjcFhFo4xV9JXdXSUbWxsRds+NbE8; Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I don't know of a conclusion about the D flag. This rev is a keepalive for continued discussion. BTW, I'm not sure of the process around this specific case of WG reorg; should I rebpulish as ietf-mext-...-00, droms-mext-...-00, ??? - Ralph On Dec 6, 2007, at Dec 6, 2007,9:10 PM, Alexandru Petrescu wrote: > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Network Mobility Working Group of >> the IETF. >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, P. Thubert >> Filename : draft-ietf-nemo-dhcpv6-pd-03.txt >> Pages : 11 >> Date : 2007-12-06 > > Thanks for resubmitting a new version of this draft. There was some > discussion around it recently, especially the D flag in DHAAD > Request. Some people discussed about its necessity. Has there been > a conclusion around it? Or is it just keepalive submission? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mow@quic-sale.com Thu Dec 06 21:17:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Smk-0003St-12; Thu, 06 Dec 2007 21:17:50 -0500 Received: from c-76-110-58-71.hsd1.fl.comcast.net ([76.110.58.71] helo=RADIANCE.hsd1.fl.comcast.net.) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Smh-00071H-5c; Thu, 06 Dec 2007 21:17:49 -0500 Received: from [76.110.58.71] by mailsite.everycontractor.com; Thu, 6 Dec 2007 18:21:11 -0800 From: "Bria Simpson" To: Subject: better off Date: Thu, 6 Dec 2007 18:21:11 -0800 Message-ID: <01c83834$c71bc580$473a6e4c@mow> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Spam-Score: 3.1 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hi I'm 29 years old I read your profile online and I was intrested in getting to know you better Reply to me and tell me about yourself if you want to chat I will send a pic and some of my info right away email me at Carpet@EngineRide.info , that will be sent to me directly Thank you From KaseyballeticBusby@brownsvilleherald.com Thu Dec 06 21:45:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TD4-0003ve-SG; Thu, 06 Dec 2007 21:45:02 -0500 Received: from [190.156.197.230] (helo=casa.cable.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0TD4-00076p-5B; Thu, 06 Dec 2007 21:45:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host25785873.brownsvilleherald.com (8.13.1/8.13.1) with SMTP id DZ1Yw83d35.285447.MKG.KDi.5161236101471 for ; Thu, 6 Dec 2007 21:44:34 +0500 Message-ID: <345dd01c8387b$25574bb0$e6c59cbe@CASA> From: "Ophelia Elliot" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_345D9_01C8387B.25574BB0-- From mext-bounces@ietf.org Thu Dec 06 22:09:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Tac-0003Ec-4W; Thu, 06 Dec 2007 22:09:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Taa-0003E3-Tf for mext@ietf.org; Thu, 06 Dec 2007 22:09:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Taa-0000F2-IY for mext@ietf.org; Thu, 06 Dec 2007 22:09:20 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2007 19:09:20 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB739KXp025618; Thu, 6 Dec 2007 19:09:20 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lB739JqZ007336; Fri, 7 Dec 2007 03:09:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 19:09:20 -0800 Received: from dhcp-10cc.ietf70.org ([10.21.126.170]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 19:09:19 -0800 Message-Id: <3C622D64-E320-4C4E-BE21-5630836F8E99@cisco.com> From: Ralph Droms To: julien.laganier@laposte.net In-Reply-To: <13426577.96331196996698880.JavaMail.www@wwinf8215> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Thu, 6 Dec 2007 22:09:18 -0500 References: <13426577.96331196996698880.JavaMail.www@wwinf8215> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 07 Dec 2007 03:09:19.0528 (UTC) FILETIME=[8EF16A80:01C8387E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=812; t=1196996960; x=1197860960; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[MEXT]=20Re=3A=20[nemo]=20I-D=20Action=3Adraft-ietf-n emo-dhcpv6-pd-03.txt |Sender:=20; bh=vUhUCAI5sLCglCeifYjfHaEL9BsGNDPWqZzf5XF7ya4=; b=dKdbwEIfXB+RWIN195oLp7AyiDYgQkFe7SWtPfzb1QvdFQFH4yrO7cghtam1SVZ8gLYXiKRW J+A6/9lbbZB5KhARy3Cyn8ch1MILj0sw7iZUJBdg118Q9mgfA3XbloUEBaP7wTC/BCDvTryD4G 4XZNAjkPRv3n1JI8Tz2V/0GMU=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Unless someone knows of specific revisions that should be made now, =20 I'll republish as draft-droms-mext-dhcpv6-pd--00 Mon, 12/10. - Ralph On Dec 6, 2007, at Dec 6, 2007,10:04 PM, julien.laganier@laposte.net =20 wrote: > > Ralph, > > > BTW, I'm not sure of the process around this specific case of WG > > reorg; should I rebpulish as ietf-mext-...-00, droms-=20 > mext-...-00, ??? > > Since we are only chartered to produce one solution for prefix =20 > delegation and we didn't yet reached consensus on the choice of a =20 > solution (e.g. DHCP, NEMO extensions) I'd rather have you submit =20 > this draft as draft-droms-mext-*-00. > > --julien > > > Cr=E9ez votre adresse =E9lectronique pr=E9nom.nom@laposte.net > 1 Go d'espace de stockage, anti-spam et anti-virus int=E9gr=E9s. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 22:12:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TdV-0003f9-87; Thu, 06 Dec 2007 22:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TdU-0003et-5w for mext@ietf.org; Thu, 06 Dec 2007 22:12:20 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TdR-0002GI-TD for mext@ietf.org; Thu, 06 Dec 2007 22:12:20 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB73CGc6025837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Dec 2007 19:12:16 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB73CGrS005732; Thu, 6 Dec 2007 19:12:16 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB73CGYJ005729; Thu, 6 Dec 2007 19:12:16 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 19:12:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Thu, 6 Dec 2007 19:12:15 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCBD@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <3C622D64-E320-4C4E-BE21-5630836F8E99@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Thread-Index: Acg4fphF0iyh15DVREizFhwYM54u6gAABvdg References: <13426577.96331196996698880.JavaMail.www@wwinf8215> <3C622D64-E320-4C4E-BE21-5630836F8E99@cisco.com> From: "Templin, Fred L" To: "Ralph Droms" , X-OriginalArrivalTime: 07 Dec 2007 03:12:15.0873 (UTC) FILETIME=[F80D8710:01C8387E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ralph, Maybe have a look at 'draft-templin-autoconf-dhcp-10.txt' and see if there is anything in there relating to prefix delegation you can use. (I still need to read draft-droms, so forgive me for not being able to point out specifics at this moment.) Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Thursday, December 06, 2007 7:09 PM > To: julien.laganier@laposte.net > Cc: mext@ietf.org > Subject: Re: [MEXT] Re: [nemo] I-D=20 > Action:draft-ietf-nemo-dhcpv6-pd-03.txt >=20 > Unless someone knows of specific revisions that should be made now, =20 > I'll republish as draft-droms-mext-dhcpv6-pd--00 Mon, 12/10. >=20 > - Ralph >=20 > On Dec 6, 2007, at Dec 6, 2007,10:04 PM, julien.laganier@laposte.net =20 > wrote: >=20 > > > > Ralph, > > > > > BTW, I'm not sure of the process around this specific case of WG > > > reorg; should I rebpulish as ietf-mext-...-00, droms-=20 > > mext-...-00, ??? > > > > Since we are only chartered to produce one solution for prefix =20 > > delegation and we didn't yet reached consensus on the choice of a =20 > > solution (e.g. DHCP, NEMO extensions) I'd rather have you submit =20 > > this draft as draft-droms-mext-*-00. > > > > --julien > > > > > > Cr=E9ez votre adresse =E9lectronique pr=E9nom.nom@laposte.net > > 1 Go d'espace de stockage, anti-spam et anti-virus int=E9gr=E9s. >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 06 22:21:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Tmj-0003pn-7U; Thu, 06 Dec 2007 22:21:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TWO-000871-5u for mext@ietf.org; Thu, 06 Dec 2007 22:05:00 -0500 Received: from out4.laposte.net ([193.251.214.121] helo=out3.laposte.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0TWN-0008Pq-ME for mext@ietf.org; Thu, 06 Dec 2007 22:04:59 -0500 Received: from meplus.info (localhost [127.0.0.1]) by mwinf8309.laposte.net (SMTP Server) with ESMTP id 00C787000086 for ; Fri, 7 Dec 2007 04:04:59 +0100 (CET) Received: from wwinf8215 (unknown [10.98.50.10]) by mwinf8309.laposte.net (SMTP Server) with ESMTP id D8BBE7000084; Fri, 7 Dec 2007 04:04:58 +0100 (CET) X-ME-UUID: 20071207030458887.D8BBE7000084@mwinf8309.laposte.net From: julien.laganier@laposte.net To: Ralph Droms Message-ID: <13426577.96331196996698880.JavaMail.www@wwinf8215> Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt MIME-Version: 1.0 X-Originating-IP: [130.129.85.231] X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~| X-WUM-CC: |~| X-WUM-REPLYTO: |~| Date: Fri, 7 Dec 2007 04:04:58 +0100 (CET) X-me-spamlevel: not-spam X-me-spamrating: 16.712995 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Thu, 06 Dec 2007 22:21:51 -0500 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: julien.laganier@laposte.net List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347855905==" Errors-To: mext-bounces@ietf.org --===============0347855905== Content-Type: multipart/alternative; boundary="----=_Part_5604_28839602.1196996698879" ------=_Part_5604_28839602.1196996698879 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ralph, > BTW, I'm not sure of the process around this specific case of WG=C2=A0 > reorg; should I rebpulish as ietf-mext-...-00, droms-mext-...-00, ??? Since we are only chartered to produce one solution for prefix delegation a= nd we didn't yet reached consensus on the choice of a solution (e.g. DHCP, = NEMO extensions) I'd rather have you submit this draft as draft-droms-mext-= *-00. --julien Cr=C3=A9ez votre adresse =C3=A9lectronique pr=C3=A9nom.nom@laposte.net=20 1 Go d'espace de stockage, anti-spam et anti-virus int=C3=A9gr=C3=A9s. ------=_Part_5604_28839602.1196996698879 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ralph,

> BTW, I'm not sure of the process around this s= pecific case of WG 
> reorg; should I rebpulish as ietf-mext-= ...-00, droms-mext-...-00, ???

Since we are only chartered to p= roduce one solution for prefix delegation and we didn't yet reached consens= us on the choice of a solution (e.g. DHCP, NEMO extensions) I'd rather have= you submit this draft as draft-droms-mext-*-00.

--julien
=

Cr=C3=A9ez votre adresse =C3=A9lectronique pr=C3=A9nom.nom@laposte.net
1 Go d'esp= ace de stockage, anti-spam et anti-virus int=C3=A9gr=C3=A9s.
------=_Part_5604_28839602.1196996698879-- --===============0347855905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0347855905==-- From RalphutrechtRivera@fordfound.org Thu Dec 06 23:40:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0V0g-0001k2-UA; Thu, 06 Dec 2007 23:40:22 -0500 Received: from 234.pool85-60-111.dynamic.orange.es ([85.60.111.234] helo=paco.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0V0g-0005de-CS; Thu, 06 Dec 2007 23:40:22 -0500 Received: from hole by fordfound.org with SMTP id uTT0dpnoEX for ; Fri, 7 Dec 2007 05:39:47 -0100 From: "Harry Sanders" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0YN1-0006cU-LJ; Fri, 07 Dec 2007 03:15:39 -0500 Received: from [88.232.186.233] (helo=xp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0YN0-0006Ht-WC; Fri, 07 Dec 2007 03:15:39 -0500 Received: from optimal by grandforksherald.com with SMTP id 3pOlKwHnvv for ; Fri, 7 Dec 2007 10:15:24 -0200 From: "Vicente Richard" To: Subject: Get your bonus and walk the red carpet to winnings and fun. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Our casino is for you and everyone else who likes to win! Get your bonus and walk the red carpet to winnings and fun. Win $$$ instead of throwing it all away at other casinos. When YOU WIN, we win! http://eurocasinoaj.com/ From mext-bounces@ietf.org Fri Dec 07 04:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ZbD-00016J-Ei; Fri, 07 Dec 2007 04:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ZbB-00016E-Vt for mext@ietf.org; Fri, 07 Dec 2007 04:34:21 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0ZbB-0002jT-NH for mext@ietf.org; Fri, 07 Dec 2007 04:34:21 -0500 X-VirusChecked: Checked X-Env-Sender: Christophe.Janneteau@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1197020061!38245494!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3895 invoked from network); 7 Dec 2007 09:34:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 7 Dec 2007 09:34:21 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lB79YKFq021343; Fri, 7 Dec 2007 02:34:20 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lB79YK8Q015893; Fri, 7 Dec 2007 03:34:20 -0600 (CST) Received: from [10.161.201.129] (zfr01-2129.crm.mot.com [10.161.201.129]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB79YIRk015809; Fri, 7 Dec 2007 03:34:19 -0600 (CST) Message-ID: <47591393.7070805@motorola.com> Date: Fri, 07 Dec 2007 10:34:11 +0100 From: Christophe Janneteau User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [MEXT] Comments on draft-ng-nemo-ce-req-01 References: <1196900866.27208.117.camel@localhost> <1196963280.6489.30.camel@localhost> <47583E0F.2010605@inria.fr> In-Reply-To: <47583E0F.2010605@inria.fr> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Thierry, All, Thierry Ernst wrote: > I said there is: > [snip] > > - 2: a need for MR-MR communication via the access network: for instance > when vehicles are not in the same communication range over a physical > medium. It is clearly not acceptable to have such communication going > through the HA (or 2 HAs if they don't have the same). I share your view on this form of RO being needed for the automotive use case; and also think there is the very same need in the consumer electronic space: allowing RO between two handheld devices (acting as MR/PAN) connected to the (typically same operator's) network. Christophe _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 05:46:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0aiv-0002vp-M5; Fri, 07 Dec 2007 05:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0aiu-0002pJ-KL for mext@ietf.org; Fri, 07 Dec 2007 05:46:24 -0500 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ais-0005UE-PP for mext@ietf.org; Fri, 07 Dec 2007 05:46:24 -0500 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id A7D9888DE43 for ; Fri, 7 Dec 2007 10:46:21 +0000 (WET) Received: from medusa (dhcp-251.ci.uc.pt [193.136.200.251]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id 80F3988DE41 for ; Fri, 7 Dec 2007 10:46:21 +0000 (WET) From: "Pedro Pinheiro" To: References: <047901c83807$ace3dcc0$06ab9640$@uc.pt> <475866EF.6080908@gmail.com> In-Reply-To: <475866EF.6080908@gmail.com> Subject: RE: [MEXT] ICMP error...? Date: Fri, 7 Dec 2007 10:46:23 -0000 Message-ID: <000301c838be$6949e010$3bdda030$@uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4TXGfUTZi/xz1RnqPgNXM2qs8MAAaGKLg Content-Language: pt X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > In this situation how will the HA or MR find out the origin of the > packet > > inside the MRHA? >=20 > The origin of the packet is the src field of that ICMP Error, right? >=20 > Not sure where the error happens exactly (between CN and HA? between > HA > and MR?) Let me try to exemplify. Suppose those scenarios: 1) Comunication from MNN to CN: The normal situation is: MNN ----> MR =3D=3D=3D=3D=3D=3D> Router on the Internet = =3D=3D=3D=3D=3D=3D> HA -------> CN ----> means "normal" traffic =3D=3D=3D=3D> means MRHA traffic with the "normal" traffic encapsulated = inside. Now, imagine that the "Router on the Internet" has a problem and needs = to drop the packet and generate an icmp error.=20 This is the situation I am talking about!=20 In this point, the icmp error will be forward to the MR's CoA with the = icmp error message.=20 Now, what I am asking is: when MR receives this icmp error, how will he forward it to the right MNN? It has lost the MNN IP. And, with that, = when will the MNN will know that the packet has been drop? Only in the = timeout time? 2) On the opposite way, we have the packet from CN to MNN CN ------> HA =3D=3D=3D=3D=3D> A router =3D=3D=3D=3D=3D=3D> MR ------> = MNN If the packet is drop in the "A router" point and it generates a icmp = error, then it will forward it to the HA IP. How will the HA knows the IP of = the CN so that he can inform that this packet has been lost? Uffff... it's hard to explain :D Well, in fact this is a problem that affects all tunnel situations (GRE, VPN, etc.) Best regards, Pedro Vapi ------------------------------------ Universidade de Coimbra Pedro Pinheiro Eng, MSc vapi@univ-coimbra.eu Centro de Informatica=20 R. Arco da Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351 239 853 189 IM: MSN: pvapi@hotmail.com http://www.univ-coimbra.eu/pessoal/vapi/ Skype ID:pedrovapi ------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From BessiedevoteDowney@sitemaps.org Fri Dec 07 09:18:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0e2G-00041S-OV; Fri, 07 Dec 2007 09:18:36 -0500 Received: from cpc1-salf1-0-0-cust61.manc.cable.ntl.com ([82.6.76.62] helo=compaqk0aekhn7) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0e2F-0005km-Rr; Fri, 07 Dec 2007 09:18:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host15539316.sitemaps.org (8.13.1/8.13.1) with SMTP id l1oJyYqy46.075726.ruJ.Njf.2355622039635 for ; Fri, 7 Dec 2007 06:18:14 +0800 Message-ID: <530e001c838dc$0e072910$3e4c0652@compaqk0aekhn7> From: "Lillie Hoskins" To: Subject: Your order Date: Fri, 7 Dec 2007 06:18:14 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_530DC_01C838DC.0E072910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_530DC_01C838DC.0E072910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_530DC_01C838DC.0E072910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_530DC_01C838DC.0E072910-- From mext-bounces@ietf.org Fri Dec 07 09:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0eBh-0005IS-V2; Fri, 07 Dec 2007 09:28:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0eBg-0005IG-PO for mext@ietf.org; Fri, 07 Dec 2007 09:28:20 -0500 Received: from mailhub.hp.com ([192.151.27.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0eBg-0006Ms-E1 for mext@ietf.org; Fri, 07 Dec 2007 09:28:20 -0500 Received: from [192.168.1.100] (c-24-62-100-177.hsd1.ma.comcast.net [24.62.100.177]) by mailhub.hp.com (Postfix) with ESMTP id A886D2710D; Fri, 7 Dec 2007 09:32:10 -0500 (EST) Message-ID: <4759581F.9070906@hp.com> Date: Fri, 07 Dec 2007 09:26:39 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Pedro Pinheiro Subject: Re: [MEXT] ICMP error...? References: <047901c83807$ace3dcc0$06ab9640$@uc.pt> <475866EF.6080908@gmail.com> <000301c838be$6949e010$3bdda030$@uc.pt> In-Reply-To: <000301c838be$6949e010$3bdda030$@uc.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Pedro, Pedro Pinheiro wrote: > Let me try to exemplify. > Suppose those scenarios: > > 1) Comunication from MNN to CN: > > The normal situation is: > MNN ----> MR ======> Router on the Internet ======> HA -------> CN > > ----> means "normal" traffic > ====> means MRHA traffic with the "normal" traffic encapsulated inside. > > Now, imagine that the "Router on the Internet" has a problem and needs to > drop the packet and generate an icmp error. > This is the situation I am talking about! > In this point, the icmp error will be forward to the MR's CoA with the icmp > error message. > Now, what I am asking is: when MR receives this icmp error, how will he > forward it to the right MNN? It has lost the MNN IP. And, with that, when > will the MNN will know that the packet has been drop? Only in the timeout > time? Well, if it follows the ICMPv6 rules, the error message should contain as much of the original packet as possible, which should include the original IP source address once the tunnel header is stripped-off. Or am I missing something? -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gcU-0002mj-WC; Fri, 07 Dec 2007 12:04:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gcU-0002me-7V for mext@ietf.org; Fri, 07 Dec 2007 12:04:10 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0gcS-0001nv-Fo for mext@ietf.org; Fri, 07 Dec 2007 12:04:10 -0500 Received: (qmail 6352 invoked from network); 7 Dec 2007 18:04:06 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 7 Dec 2007 18:04:06 +0100 From: "Teco Boot" To: "'Templin, Fred L'" , "'Ralph Droms'" , References: <13426577.96331196996698880.JavaMail.www@wwinf8215> <3C622D64-E320-4C4E-BE21-5630836F8E99@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCBD@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCBD@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Fri, 7 Dec 2007 18:03:28 +0100 Message-ID: <003101c838f3$2bb3a120$831ae360$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4fphF0iyh15DVREizFhwYM54u6gAABvdgABxfbTA= Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On solution space, why not evaluate running a DHCP server on the MR? Pro: - less overhead on MRHA tunnel - no dependency on MRHA tunnel Contra: - needs delegation of prefixes and options, this requires an extension = on DHCPv6PD We could ask HDC WG to improve DHCP-PD for autoconfigure "slave" DHCP servers. This would be useful in the Autoconf space also. And maybe in = many other cases. Teco. > -----Oorspronkelijk bericht----- > Van: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Verzonden: vrijdag 7 december 2007 4:12 > Aan: Ralph Droms; julien.laganier@laposte.net > CC: mext@ietf.org > Onderwerp: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd- > 03.txt >=20 > Ralph, >=20 > Maybe have a look at 'draft-templin-autoconf-dhcp-10.txt' > and see if there is anything in there relating to prefix > delegation you can use. (I still need to read draft-droms, > so forgive me for not being able to point out specifics > at this moment.) >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Thursday, December 06, 2007 7:09 PM > > To: julien.laganier@laposte.net > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Re: [nemo] I-D > > Action:draft-ietf-nemo-dhcpv6-pd-03.txt > > > > Unless someone knows of specific revisions that should be made now, > > I'll republish as draft-droms-mext-dhcpv6-pd--00 Mon, 12/10. > > > > - Ralph > > > > On Dec 6, 2007, at Dec 6, 2007,10:04 PM, julien.laganier@laposte.net > > wrote: > > > > > > > > Ralph, > > > > > > > BTW, I'm not sure of the process around this specific case of WG > > > > reorg; should I rebpulish as ietf-mext-...-00, droms- > > > mext-...-00, ??? > > > > > > Since we are only chartered to produce one solution for prefix > > > delegation and we didn't yet reached consensus on the choice of a > > > solution (e.g. DHCP, NEMO extensions) I'd rather have you submit > > > this draft as draft-droms-mext-*-00. > > > > > > --julien > > > > > > > > > Cr=E9ez votre adresse =E9lectronique pr=E9nom.nom@laposte.net > > > 1 Go d'espace de stockage, anti-spam et anti-virus int=E9gr=E9s. > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ghQ-0005U6-Af; Fri, 07 Dec 2007 12:09:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ghP-0005Ty-IJ for mext@ietf.org; Fri, 07 Dec 2007 12:09:15 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0ghO-0001GL-S4 for mext@ietf.org; Fri, 07 Dec 2007 12:09:15 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB7H8rxX004958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Dec 2007 09:08:59 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB7H8rYv018118; Fri, 7 Dec 2007 11:08:53 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB7H8kmg017822; Fri, 7 Dec 2007 11:08:53 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 09:08:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Fri, 7 Dec 2007 09:08:47 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDCC2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <003101c838f3$2bb3a120$831ae360$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Thread-Index: Acg4fphF0iyh15DVREizFhwYM54u6gAABvdgABxfbTAAANQYQA== References: <13426577.96331196996698880.JavaMail.www@wwinf8215> <3C622D64-E320-4C4E-BE21-5630836F8E99@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029EDCBD@XCH-NW-7V2.nw.nos.boeing.com> <003101c838f3$2bb3a120$831ae360$@nl> From: "Templin, Fred L" To: "Teco Boot" , "Ralph Droms" , X-OriginalArrivalTime: 07 Dec 2007 17:08:48.0073 (UTC) FILETIME=[D4EF7390:01C838F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Teco, Sure, the MR could run DHCP server over its ingress interfaces, but then turn around and act as a DHCP client on its egress interfaces and/or tunnel back to the home network. I'm pretty sure that sort of arrangement is an anticipated deployment model? Fred > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, December 07, 2007 9:03 AM > To: Templin, Fred L; 'Ralph Droms'; julien.laganier@laposte.net > Cc: mext@ietf.org > Subject: RE: [MEXT] Re: [nemo] I-D=20 > Action:draft-ietf-nemo-dhcpv6-pd-03.txt >=20 > On solution space, why not evaluate running a DHCP server on the MR? > Pro: > - less overhead on MRHA tunnel > - no dependency on MRHA tunnel > Contra: > - needs delegation of prefixes and options, this requires an=20 > extension on > DHCPv6PD >=20 > We could ask HDC WG to improve DHCP-PD for autoconfigure "slave" DHCP > servers. This would be useful in the Autoconf space also. And=20 > maybe in many > other cases. >=20 > Teco. >=20 > > -----Oorspronkelijk bericht----- > > Van: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Verzonden: vrijdag 7 december 2007 4:12 > > Aan: Ralph Droms; julien.laganier@laposte.net > > CC: mext@ietf.org > > Onderwerp: RE: [MEXT] Re: [nemo] I-D=20 > Action:draft-ietf-nemo-dhcpv6-pd- > > 03.txt > >=20 > > Ralph, > >=20 > > Maybe have a look at 'draft-templin-autoconf-dhcp-10.txt' > > and see if there is anything in there relating to prefix > > delegation you can use. (I still need to read draft-droms, > > so forgive me for not being able to point out specifics > > at this moment.) > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > -----Original Message----- > > > From: Ralph Droms [mailto:rdroms@cisco.com] > > > Sent: Thursday, December 06, 2007 7:09 PM > > > To: julien.laganier@laposte.net > > > Cc: mext@ietf.org > > > Subject: Re: [MEXT] Re: [nemo] I-D > > > Action:draft-ietf-nemo-dhcpv6-pd-03.txt > > > > > > Unless someone knows of specific revisions that should be=20 > made now, > > > I'll republish as draft-droms-mext-dhcpv6-pd--00 Mon, 12/10. > > > > > > - Ralph > > > > > > On Dec 6, 2007, at Dec 6, 2007,10:04 PM,=20 > julien.laganier@laposte.net > > > wrote: > > > > > > > > > > > Ralph, > > > > > > > > > BTW, I'm not sure of the process around this specific=20 > case of WG > > > > > reorg; should I rebpulish as ietf-mext-...-00, droms- > > > > mext-...-00, ??? > > > > > > > > Since we are only chartered to produce one solution for prefix > > > > delegation and we didn't yet reached consensus on the=20 > choice of a > > > > solution (e.g. DHCP, NEMO extensions) I'd rather have you submit > > > > this draft as draft-droms-mext-*-00. > > > > > > > > --julien > > > > > > > > > > > > Cr=E9ez votre adresse =E9lectronique pr=E9nom.nom@laposte.net > > > > 1 Go d'espace de stockage, anti-spam et anti-virus int=E9gr=E9s. > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gwK-0002jo-9X; Fri, 07 Dec 2007 12:24:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0gwI-0002jj-LW for mext@ietf.org; Fri, 07 Dec 2007 12:24:38 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0gwH-0003YD-SE for mext@ietf.org; Fri, 07 Dec 2007 12:24:38 -0500 Received: by nz-out-0506.google.com with SMTP id n1so320561nzf for ; Fri, 07 Dec 2007 09:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eldYH1Mow8v55Ik24a1+heAJGcpGrxXw/IcK8XSFobc=; b=QnCYfH5mdUkTI7ubjCTJo54w6k8srU4q2kgnybpH7iYIzwFSSX3tDK9tO712hzkg+YCpgoWsCgiDNt52YBJXNL06MMOEK88LPs34BMkGyNA8z/24PAQFxEXh3ZykSfXk3Co3CNUXqe+sXJYs8Gl6qt7F70cRYr2zLSRL9zLBGBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fgXTVTFYW3uY5n/BVhUpzRb9mbPZutO3Ee/NAmLKr+TOaDLx/oiZr3p9wPlJDafc484vbdFT1jAdr5VX3Le+bHx0+9PfIncjLfCEJjealU4jbxDw2wAFDxytjfyWm23O2ZyGK4BHKcck8aUv3BahW2ywvwAYMHj8USGULmY5EKk= Received: by 10.142.147.15 with SMTP id u15mr2292982wfd.1197048261914; Fri, 07 Dec 2007 09:24:21 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 7 Dec 2007 09:24:21 -0800 (PST) Message-ID: Date: Fri, 7 Dec 2007 09:24:21 -0800 From: "George Tsirtsis" To: "Keigo Aso" Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4744BE6F.5040408@azairenet.com> <20071204062837.0CE9.ASOU.KEIGO@jp.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi All, Benjamin pointed out off-line that setting the lifetime to infinite may not be the best idea since the BU in the home link creates a hard state binding (=bad!). He is of course right. The point of my earlier e-mail, however, was to suggest that we drop the idea of homeCoA. If the WG agrees with that, I trust the authors to come up with syntax for the BU that provides the right semantics. Thanks George On Dec 5, 2007 11:15 AM, George Tsirtsis wrote: > Folks, > > I think we should keep things simple and do the following. > > Abandon the homeCoA idea because although it technically works, it is > also more complex. Instead we can define a BU format that indicates to > the HA that the MN is attached to the home link but it does not > de-register (i.e., bindings to foreign links are still maintained). > For example we could set CoA==HoA and Lifetime==infinite or some other > variant of this. > > This seems to be the simplest approach since it does not impact the > pNDP operation of the HA i.e., If the HA was configured to run pNDP > (e.g., shared links) then it continues to do so; If the HA was not > configured to run pNDP (e.g., p2p links) then it continues to not run > pNDP. > > Does anyone see a problem with this approach? > > Regards > George > > > On Dec 3, 2007 4:22 PM, Keigo Aso wrote: > > Hi all, > > > > Let me summarize the returning home approaches we have discussed so far. > > Hopefully this would be used for the preparation for hearing Ryuji's > > presentation tomorrow. > > > > There are two cases on HA configuration we should consider. One is HA is a > > router case, another is HA is a host case. > > When HA is a router, as we all already understand, there is no issue because HA > > can intercept packets for MN's HoA without Proxy NDP and MN can run NDP for own > > HoA on the home link. > > Only needed for this is HA has to know that MN is at home in order to make the > > home binding. Actually the current MCoA draft already introduced the solution > > for this, which is MN uses 'H' flag in BU to notify that it is attaching to the > > home link also toghether with the CoA for the foreign binding. > > > > While, when HA is a host case, HA has to run Proxy ND for intercepting packets > > for MN's HoA. So, in this case, MN can not notify L2 address to the HA. For this > > case there is a approach which is MN sends BU including L2 address. This may be > > useful for the case HA is a router. > > > > Furthermore, there is another good approach for this case, which is using > > another CoA in the home link. If MN can create a CoA in the home link which is > > different from own HoA, it can register it with 'H' flag for making the home > > binding to the HA. Therefore, HA can run Proxy NDP for MN's HoA, while MN can > > notify L2 address by running NDP for this CoA. In this approach, its CoA could > > be the address which is made from own home prefix(HomeCoA). While if there is > > another prefix in the home network, it is used for making the CoA. When using > > other prefix, it would need operational stuff for HA and other MNs on the home > > link. > > > > Regards, > > Keigo > > > > On Sun, 25 Nov 2007 02:53:02 +0900 > > Ryuji Wakikawa wrote: > > > > > > > Hi George and Vijay, > > > > > > Question is whether we should support DSMIP in this document. > > > It seems reasonable to support DSMIP. > > > We can easily extend BID sub-option to cary both IPv4/IPv6 addresses. > > > > > > regards, > > > ryuji > > > > > > > > > > > > On 2007/11/22, at 8:25, Vijay Devarapalli wrote: > > > > > > > George Tsirtsis wrote: > > > > > > > >> 7) Interactions with DSMIPv6. I think at some point a new section > > > >> needs to be added to talk about interactions with DSMIPv6. Beyond > > > >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the > > > >> MCoA draft includes some interactions with IKEv2 > > > > > > > > I think the IKEv2 interactions are inline with what we decided for > > > > DS-MIPv6 last week. Transport mode IPsec SA for the binding update, > > > > and tunnel mode SAs updated either by MIPv6 (K flag) or running > > > > IKEv2 again. > > > > > > > > and imposes some requirements to the use of > > > >> alternate-CoA which may or may not conflict with DSMIPv6 (have not > > > >> checked that myself yet). > > > > > > > > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not > > > > related to the alt CoA option in RFC 3775. > > > > draft-ietf-monami6-multiplecoa says the alt CoA option should not > > > > be included whenever the CoA is carried in the BID mobility option. > > > > > > > > The BID option as defined in the draft currently seems to allow > > > > only for an IPv6 address. I think, we need to extend the BID option > > > > to carry an IPv4 or an IPv6 address. > > > > > > > > Vijay > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0h4Q-0004v8-GE; Fri, 07 Dec 2007 12:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0h4P-0004v3-Dz for mext@ietf.org; Fri, 07 Dec 2007 12:33:01 -0500 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0h4M-0004EK-UE for mext@ietf.org; Fri, 07 Dec 2007 12:33:01 -0500 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id lB7HVmTw051894; Fri, 7 Dec 2007 18:31:48 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200712071731.lB7HVmTw051894@givry.fdupont.fr> From: Francis Dupont To: "Teco Boot" Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt In-reply-to: Your message of Fri, 07 Dec 2007 18:03:28 +0100. <003101c838f3$2bb3a120$831ae360$@nl> Date: Fri, 07 Dec 2007 18:31:48 +0100 X-Spam-Score: -1.4 (-) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: julien.laganier@laposte.net, "'Templin, Fred L'" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org In your previous mail you wrote: On solution space, why not evaluate running a DHCP server on the MR? => to serve which nodes? And don't forget the DHCP service is designed to be local, i.e., there is no tree of servers or things like that. Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hHe-0003a8-6X; Fri, 07 Dec 2007 12:46:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hHc-0003Zh-S2 for mext@ietf.org; Fri, 07 Dec 2007 12:46:40 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hHb-0005Hu-OB for mext@ietf.org; Fri, 07 Dec 2007 12:46:40 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id lB7HkaJY019911; Sat, 8 Dec 2007 02:46:36 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id lB7Hkb004244; Sat, 8 Dec 2007 02:46:37 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id lB7HkaV24728; Sat, 8 Dec 2007 02:46:37 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id lB7HkaMA023020; Sat, 8 Dec 2007 02:46:36 +0900 (JST) Received: from [10.238.172.34] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lB7HkXjt023000; Sat, 8 Dec 2007 02:46:34 +0900 (JST) Date: Sat, 08 Dec 2007 02:46:36 +0900 From: Keigo Aso To: "George Tsirtsis" Subject: Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt In-Reply-To: References: Message-Id: <20071208022849.C582.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, On Fri, 7 Dec 2007 09:24:21 -0800 "George Tsirtsis" wrote: > Hi All, > > Benjamin pointed out off-line that setting the lifetime to infinite > may not be the best idea since the BU in the home link creates a hard > state binding (=bad!). He is of course right. The point of my earlier > e-mail, however, was to suggest that we drop the idea of homeCoA. If > the WG agrees with that, I trust the authors to come up with syntax > for the BU that provides the right semantics. Looks OK for me also. I also think, in this BU, the MN should be able to set the lifetime even when registering the home binding because the entry should be kept by the consecutive BU from the MN in common with the foreign binding. And also, the BU with CoA==HoA is rejected by the HA because HA in RFC3775 must silently discard the BU if the care-of address appears as a home address in an existing Binding Cache entry by reason that HA thinks this binding will create a loop in BCE (HoA --> HoA). Actually the authors already provided the simple way for this purpose which is 'H' flag in BID option. Regards, Keigo > > Thanks > George > > On Dec 5, 2007 11:15 AM, George Tsirtsis wrote: > > Folks, > > > > I think we should keep things simple and do the following. > > > > Abandon the homeCoA idea because although it technically works, it is > > also more complex. Instead we can define a BU format that indicates to > > the HA that the MN is attached to the home link but it does not > > de-register (i.e., bindings to foreign links are still maintained). > > For example we could set CoA==HoA and Lifetime==infinite or some other > > variant of this. > > > > This seems to be the simplest approach since it does not impact the > > pNDP operation of the HA i.e., If the HA was configured to run pNDP > > (e.g., shared links) then it continues to do so; If the HA was not > > configured to run pNDP (e.g., p2p links) then it continues to not run > > pNDP. > > > > Does anyone see a problem with this approach? > > > > Regards > > George > > > > > > On Dec 3, 2007 4:22 PM, Keigo Aso wrote: > > > Hi all, > > > > > > Let me summarize the returning home approaches we have discussed so far. > > > Hopefully this would be used for the preparation for hearing Ryuji's > > > presentation tomorrow. > > > > > > There are two cases on HA configuration we should consider. One is HA is a > > > router case, another is HA is a host case. > > > When HA is a router, as we all already understand, there is no issue because HA > > > can intercept packets for MN's HoA without Proxy NDP and MN can run NDP for own > > > HoA on the home link. > > > Only needed for this is HA has to know that MN is at home in order to make the > > > home binding. Actually the current MCoA draft already introduced the solution > > > for this, which is MN uses 'H' flag in BU to notify that it is attaching to the > > > home link also toghether with the CoA for the foreign binding. > > > > > > While, when HA is a host case, HA has to run Proxy ND for intercepting packets > > > for MN's HoA. So, in this case, MN can not notify L2 address to the HA. For this > > > case there is a approach which is MN sends BU including L2 address. This may be > > > useful for the case HA is a router. > > > > > > Furthermore, there is another good approach for this case, which is using > > > another CoA in the home link. If MN can create a CoA in the home link which is > > > different from own HoA, it can register it with 'H' flag for making the home > > > binding to the HA. Therefore, HA can run Proxy NDP for MN's HoA, while MN can > > > notify L2 address by running NDP for this CoA. In this approach, its CoA could > > > be the address which is made from own home prefix(HomeCoA). While if there is > > > another prefix in the home network, it is used for making the CoA. When using > > > other prefix, it would need operational stuff for HA and other MNs on the home > > > link. > > > > > > Regards, > > > Keigo > > > > > > On Sun, 25 Nov 2007 02:53:02 +0900 > > > Ryuji Wakikawa wrote: > > > > > > > > > > Hi George and Vijay, > > > > > > > > Question is whether we should support DSMIP in this document. > > > > It seems reasonable to support DSMIP. > > > > We can easily extend BID sub-option to cary both IPv4/IPv6 addresses. > > > > > > > > regards, > > > > ryuji > > > > > > > > > > > > > > > > On 2007/11/22, at 8:25, Vijay Devarapalli wrote: > > > > > > > > > George Tsirtsis wrote: > > > > > > > > > >> 7) Interactions with DSMIPv6. I think at some point a new section > > > > >> needs to be added to talk about interactions with DSMIPv6. Beyond > > > > >> the obvious issue of whether MCoAs can include IPv4 CoAs etc the > > > > >> MCoA draft includes some interactions with IKEv2 > > > > > > > > > > I think the IKEv2 interactions are inline with what we decided for > > > > > DS-MIPv6 last week. Transport mode IPsec SA for the binding update, > > > > > and tunnel mode SAs updated either by MIPv6 (K flag) or running > > > > > IKEv2 again. > > > > > > > > > > and imposes some requirements to the use of > > > > >> alternate-CoA which may or may not conflict with DSMIPv6 (have not > > > > >> checked that myself yet). > > > > > > > > > > In DS-MIPv6, the IPv4 CoA option is a new mobility option, not > > > > > related to the alt CoA option in RFC 3775. > > > > > draft-ietf-monami6-multiplecoa says the alt CoA option should not > > > > > be included whenever the CoA is carried in the BID mobility option. > > > > > > > > > > The BID option as defined in the draft currently seems to allow > > > > > only for an IPv6 address. I think, we need to extend the BID option > > > > > to carry an IPv4 or an IPv6 address. > > > > > > > > > > Vijay > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 12:58:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hSh-0001xA-EX; Fri, 07 Dec 2007 12:58:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hSg-0001x5-K4 for mext@ietf.org; Fri, 07 Dec 2007 12:58:06 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0hSg-0005HO-3f for mext@ietf.org; Fri, 07 Dec 2007 12:58:06 -0500 Received: (qmail 11831 invoked from network); 7 Dec 2007 18:58:04 +0100 Received: from unknown (HELO M90Teco) (130.129.82.92) by server9.hosting2go.nl with SMTP; 7 Dec 2007 18:58:03 +0100 From: "Teco Boot" To: References: Your message of Fri, 07 Dec 2007 18:03:28 +0100. <003101c838f3$2bb3a120$831ae360$@nl> <200712071731.lB7HVmTw051894@givry.fdupont.fr> In-Reply-To: <200712071731.lB7HVmTw051894@givry.fdupont.fr> Subject: RE: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt Date: Fri, 7 Dec 2007 18:57:25 +0100 Message-ID: <004001c838fa$b5082b10$1f188130$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg49zeLGhe5abedTRy9+GTVytJ1NAAAk9yA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: julien.laganier@laposte.net, "'Templin, Fred L'" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > -----Oorspronkelijk bericht----- > Van: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Verzonden: vrijdag 7 december 2007 18:32 > Aan: Teco Boot > CC: 'Templin, Fred L'; 'Ralph Droms'; julien.laganier@laposte.net; > mext@ietf.org > Onderwerp: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd- > 03.txt > > In your previous mail you wrote: > > On solution space, why not evaluate running a DHCP server on the MR? > > => to serve which nodes? To serve LFN. > And don't forget the DHCP service is designed > to be local, i.e., there is no tree of servers or things like that. Yes, but with DHCPv6PD we extend this. With prefix delegation, the MR supports LFN SLAAC. The question is how to support DHCP on Mobile Network. Using relay or running DHCP on MR. For the latter, we have a tree of servers and we have to solve the DHCP configuration problem. Teco. > > Francis.Dupont@fdupont.fr _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 13:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hoJ-0003MH-HS; Fri, 07 Dec 2007 13:20:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hoI-0003MC-Ax for mext@ietf.org; Fri, 07 Dec 2007 13:20:26 -0500 Received: from givry.fdupont.fr ([91.121.26.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0hoH-0006xT-QU for mext@ietf.org; Fri, 07 Dec 2007 13:20:26 -0500 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id lB7IKLTp052154; Fri, 7 Dec 2007 19:20:21 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200712071820.lB7IKLTp052154@givry.fdupont.fr> From: Francis Dupont To: "Teco Boot" Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt In-reply-to: Your message of Fri, 07 Dec 2007 18:57:25 +0100. <004001c838fa$b5082b10$1f188130$@nl> Date: Fri, 07 Dec 2007 19:20:21 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: julien.laganier@laposte.net, "'Templin, Fred L'" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org In your previous mail you wrote: > => to serve which nodes? To serve LFN. => this has nothing to do with NEMO (the M in MR) but with how a router (the R in MR) manages locally its (sub)network(s). > And don't forget the DHCP service is designed > to be local, i.e., there is no tree of servers or things like that. Yes, but with DHCPv6PD we extend this. => I disagree and I strongly object to change DHCPv6 into a network management tool: DHCPv6-PD delegates a prefix to a router and this router can do what it wants with the prefix. With prefix delegation, the MR supports LFN SLAAC. => it should not, this is the meaning of "across an administrative boundary". The question is how to support DHCP on Mobile Network. Using relay or running DHCP on MR. => the whole idea about prefix delegation is delegation (cf RFC 3769) so IMHO the solution is to run DHCP on the MR For the latter, we have a tree of servers and we have to solve the DHCP configuration problem. => so in fact the question is how the NEMO could not fit into the RFC 3769 / RFC 3633 model and if yes how the DHCPv6-PD has to be re-designed to support the needed extra features. Regards Francis.Dupont@fdupont.fr PS: RFC 3633 quote to start with: This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From FraneskimoAddison@fiftyfoureleven.com Fri Dec 07 14:40:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j3w-0005Tq-6x; Fri, 07 Dec 2007 14:40:40 -0500 Received: from pc-15-244-47-190.cm.vtr.net ([190.47.244.15] helo=pc1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0j3v-0004GS-CN; Fri, 07 Dec 2007 14:40:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host02875994.fiftyfoureleven.com (8.13.1/8.13.1) with SMTP id iSwHLZ5l45.121532.nwA.Bc7.9437522597231 for ; Fri, 7 Dec 2007 16:40:22 +0400 Message-ID: <4828f01c83909$0951bde0$bd00a8c0@pc1> From: "Alyce Addison" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4828B_01C83909.0951BDE0-- From mext-bounces@ietf.org Fri Dec 07 14:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j4b-0005nS-VL; Fri, 07 Dec 2007 14:41:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j4a-0005n9-JC for mext@ietf.org; Fri, 07 Dec 2007 14:41:20 -0500 Received: from an-out-0708.google.com ([209.85.132.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0j4a-0004Hu-8s for mext@ietf.org; Fri, 07 Dec 2007 14:41:20 -0500 Received: by an-out-0708.google.com with SMTP id d11so221661and for ; Fri, 07 Dec 2007 11:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Qr8nsDSny9+51+BN+MEJpLiWg3yYJpqtHy8eFyYd3vY=; b=VGoJjlwW1suacsEshfCImb1pxv38Xzi4rJe92h1DvdEvdRxWG/r2zE5lzwfc4JXPlAkMXRw/lrtn1Yb1CHmcrsMoYMH8xrvdxPxTS2ZM5Kqq1XJFsnHPi2b9urrwFzAYhIk9btFGo1Hc39aGQWxQhQv5NbBOlCJOyWziieBjStA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=UeT4oegWtqoO8qMuNqcNA5ax2yx/QI2cWNcbeCb4TXppV5ePhYbbrGOxaS/687KfCuzxGyk3oktsfFW1kVtR2QRJ9kTVrnZ4zdShkxxeHIvmitjPta8SDiZqyq/opP48YmuCl2/MeG/NVnyDZKTFMwXyrwrBIuj4uSB2sT5S5xE= Received: by 10.100.201.16 with SMTP id y16mr9970408anf.1197056480077; Fri, 07 Dec 2007 11:41:20 -0800 (PST) Received: from dhcp-15f0.ietf70.org ( [130.129.21.240]) by mx.google.com with ESMTPS id 38sm81544aga.2007.12.07.11.41.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2007 11:41:19 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Fri, 7 Dec 2007 20:41:16 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712072041.17394.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [MEXT] Sense of the room during recharter discussion X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This mail summarize the sense of the room we gauged during the recharter discussion that happens at the 2nd session today. --julien ----------------------------------------------------- - Binding Revocation Mechanism for IPv6 Mobility For: ~40 Against: ~0 - MIPv6 home link operation in various SDOs For: ~20 Against: ~3 - IP Tunneling Optimization in a Mobile Environment For: ~20 Against: ~2 - Generic Notification Message for Mobile IPv6 For: ~15 Against: ~0 - GRE requirements for IPv6 mobility For: ~5 Against: ~5 - 4283bis For: ~20 Against: ~1 - Bootstrapping mechanisms for using RFC 4285 with Mobile IPv6 For: ~0 - Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions For: ~10 Against: ~1 - Virtual Home Link configuration For: ~10 Against: ~3 - DSMIP IPv4-only Home Network Support For: ~10 Against: ~6 - Extending scope of NEMO usecase requiremnts beyond RO, e.g. multihoming For: ~15 Against: ~3, including AD (Jari Arkko). _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 07 14:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j8h-0007cx-8A; Fri, 07 Dec 2007 14:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0j8g-0007co-2t for mext@ietf.org; Fri, 07 Dec 2007 14:45:34 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0j8f-00050O-MS for mext@ietf.org; Fri, 07 Dec 2007 14:45:34 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1197056732!36655044!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 8994 invoked from network); 7 Dec 2007 19:45:32 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-119.messagelabs.com with SMTP; 7 Dec 2007 19:45:32 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id lB7JjMAx019775; Fri, 7 Dec 2007 12:45:22 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lB7JjLTw013878; Fri, 7 Dec 2007 13:45:21 -0600 (CST) Received: from [127.0.0.1] ([10.19.242.71]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lB7JjIfE013845; Fri, 7 Dec 2007 13:45:19 -0600 (CST) Message-ID: <4759A2CD.7060101@gmail.com> Date: Fri, 07 Dec 2007 11:45:17 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [MEXT] Re: [nemo] I-D Action:draft-ietf-nemo-dhcpv6-pd-03.txt References: <200712071820.lB7IKLTp052154@givry.fdupont.fr> In-Reply-To: <200712071820.lB7IKLTp052154@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071206-0, 06/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: julien.laganier@laposte.net, "'Templin, Fred L'" , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > > => to serve which nodes? > > To serve LFN. > > => this has nothing to do with NEMO (the M in MR) but with how a router > (the R in MR) manages locally its (sub)network(s). > > > And don't forget the DHCP service is designed > > to be local, i.e., there is no tree of servers or things like that. > > Yes, but with DHCPv6PD we extend this. > > => I disagree and I strongly object to change DHCPv6 into a network > management tool: DHCPv6-PD delegates a prefix to a router and this router > can do what it wants with the prefix. > > With prefix delegation, the MR supports LFN SLAAC. > > => it should not, this is the meaning of "across an administrative > boundary". > > The question is how to support DHCP on Mobile Network. Using relay or > running DHCP on MR. > > => the whole idea about prefix delegation is delegation (cf RFC 3769) > so IMHO the solution is to run DHCP on the MR > > For the latter, we have a tree of servers and we have to > solve the DHCP configuration problem. > > => so in fact the question is how the NEMO could not fit into the > RFC 3769 / RFC 3633 model and if yes how the DHCPv6-PD has to be > re-designed to support the needed extra features. Important is the sequence of operations. One constraint is that a MR can't send BU-MNP before having received that MNP, and before having the HA address. Other constraint is in implementations of NEMO explicit mode how to make sure the prefix received from DHCP is put in the explicit BU (somebody already raised this). Alex > > Regards > > Francis.Dupont@fdupont.fr > > PS: RFC 3633 quote to start with: > > This mechanism is intended for delegating a long- > lived prefix from a delegating router to a requesting router, across > an administrative boundary, where the delegating router does not > require knowledge about the topology of the links in the network to > which the prefixes will be assigned. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LestersordidKelley@billofrightsinstitute.org Fri Dec 07 17:15:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lTO-0005Xh-CR; Fri, 07 Dec 2007 17:15:06 -0500 Received: from toroon63-1177865030.sdsl.bell.ca ([70.52.203.70] helo=dellkids.nodomainset.bellcanada) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0lTO-00085f-13; Fri, 07 Dec 2007 17:15:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host64006822.billofrightsinstitute.org (8.13.1/8.13.1) with SMTP id ar8GWted21.799088.C9F.K5J.3514863735227 for ; Fri, 7 Dec 2007 17:17:37 +0500 Message-ID: <1849401c8391e$ff9ed2e0$0b02a8c0@DELLKIDS> From: "Corey Austin" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_18490_01C8391E.FF9ED2E0-- From AlfonsolouisWeber@latimes.com Fri Dec 07 18:30:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0mdv-0002NN-QF; Fri, 07 Dec 2007 18:30:03 -0500 Received: from cpe-24-90-218-19.nyc.res.rr.com ([24.90.218.19] helo=odilxphome.nyc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0mdv-0006dx-D1; Fri, 07 Dec 2007 18:30:03 -0500 Received: from sancho by latimes.com with SMTP id 1sPB3VpDuz for ; Fri, 7 Dec 2007 18:29:53 +0500 From: "Hubert Schneider" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ps2-0001O4-3D; Fri, 07 Dec 2007 21:56:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ps1-0001Nw-JF for mext@ietf.org; Fri, 07 Dec 2007 21:56:49 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ps0-0008R5-BO for mext@ietf.org; Fri, 07 Dec 2007 21:56:49 -0500 Received: by rv-out-0910.google.com with SMTP id l15so851018rvb for ; Fri, 07 Dec 2007 18:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+Z6VVYHD0Mmv7gAKoYKes0v3H8+OMEUZTRvk1xfc72U=; b=b02q7YcvXn/HDUqjJwpiFbmRk0Wy35GN79Ab+haiGrevp28/5KwulRsX1ppwnIiO4r8QxROvSdxyDfGfYaWSvRNWRCnCZZI8OtUbZsvPeLbmTNV3LUw5TeBTPt6PnO6sg3IRd2AicFf/U/3loMolca1FgO0TOOuoU4lZW+5mkx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ur6BjvwlXwZ5kEsDahlk7IQBS44F/DRWgqOCvhv7nLvygDI8scckBWir/Mqipo6K4ecvas7Fu5kv6OVI1gsPWUnJdWvWRRJRSB8oqaSm/w8GNKwVs+Gw3wKPcLAbyLUIHRFLlqra4oxIpYjW3Ll8iqjBaqYYK3cN0Pc/2ytI0g0= Received: by 10.143.37.20 with SMTP id p20mr1138wfj.1197082607772; Fri, 07 Dec 2007 18:56:47 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 7 Dec 2007 18:56:47 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 02:56:47 +0000 From: "George Tsirtsis" To: "Teco Boot" Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules In-Reply-To: <008f01c83793$65e92ec0$31bb8c40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Hannes Tschofenig , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Just to make sure this is clear, draft-soliman-monami6-flow-binding is the same kind of flow definition (i.e., binary X-tuple definition) with the RSVP Filterspec. The main difference is that draft-soliman includes an SPI which I think is important to include for something like this. Not sure about draft-ietf-nsis-nslp-natfw. It seems IPv4 specific although also using binary format. Not familiar enough with this to know if it fits, however. Regards George On Dec 5, 2007 11:05 PM, Teco Boot wrote: > > -----Oorspronkelijk bericht----- > > Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > > Verzonden: woensdag 5 december 2007 15:41 > > Aan: Teco Boot > > CC: 'Hannes Tschofenig'; mext@ietf.org > > Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > > > Hi Teco, > > > > Before commenting how we could apply already defined protocols to mip6 > > flow distribution, let me explain further my thoughts to see if we are > > on the same tracks: > > OK, comments inline. > > > > > > On 2007/12/03, at 19:20, Teco Boot wrote: > > > For evaluating existing specifications for using in the steps that > > you > > > described, I think we should look for something that is highly > > > related. > > > I think flow specification for QoS handling and tunnel selection is > > > very > > > similar. I don't know if this is the case for the other steps. > > > > > > QoS reservation for tunneled flows within tunnel and for the tunnel > > > itself > > > is somewhat related with tunnel selection. But I think using separate > > > protocols (e.g. RSVP and BU) is more optimal. > > > > > > Some comments inline. > > > > > > Teco. > > > > > >> -----Oorspronkelijk bericht----- > > >> Van: Romain KUNTZ [mailto:kuntz@clarinet.u-strasbg.fr] > > >> Verzonden: maandag 3 december 2007 18:39 > > >> Aan: Teco Boot > > >> CC: Hannes Tschofenig; mext@ietf.org > > >> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules > > >> > > >> Hi Teco, > > >> > > >> On 2007/11/27, at 10:26, Teco Boot wrote: > > >>> What I found is: > > >>> RFC4080 (NSIS Framework): 4.6.1. Flow Identification > > >>> draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5. Packet Classifier > > >>> (PACKET_CLASSIFIER) > > >>> > > >>> I think NSIS produced specifications on packet classification > > should > > >>> be > > >>> verified for using for MIP flow distribution / handover also. > > >>> Maybe RSVP TSPEC is past and NSIS FlowID is future. > > >> > > >> From what I understood in the envisionned architecture for flow > > >> distribution in MEXT (crrect me if I'm wrong): > > >> > > >> 1. an entity (could be the HA, or not) distributes policies to the > > MR > > >> and possibly the peers (e.g. HA) too, > > > > > > I don't know what a policy is. I think you mean a profile for > > > generating > > > filter rules. It could be filter rules itself also. > > > > A policy is a general information that describes access network > > preferences, user and > > operator preferences, security restrictions etc. > > Monami6 policy is defined in larsson-monami6-filter-rules. > I am fine with your explanation. > > > > Application of policy > > usually results in the definition of filter rules which implement the > > policy for specific traffic flows. > > > > Filter rules are tightly related to the host that creates them, so I > > don't think filter rules can be distributed by a third-part node, > > whereas policies, that are more general, can. > > Ok. > > > >> 2. The MR translates them to filter rules according to its current > > >> environment (available interfaces, path characteristics...), > > > > > > MR is MN or HA, correct? > > > > The MR or MN translates the policies to filter rules. Other peers > > (e.g. the HA) can use them later to confront them to the received > > filter rules from the MR/MN. > > > > I don't see a use case where the HA or the CN could translate the MR/ > > MN's policies to filter rules, maybe someone have one? > > I prefer using MN, this is MN (MIPv6) or MR (NEMO). > > I am not sure the MN generates the filter for peer (HA, CN) in all cases. > For example, HA / CN may have other policies. I think this is getting > complex and we should work out the basic approach first, that MN generate > the filter for both itself and for peer. > > I remember someone brought up the HA generate filters in Chicago. Maybe it > was policies. Not in minutes. > > > > >> 3. The MR sends those filter rules to the peer (e.g the HA), > > > > > > Or HA to MN, correct? > > > > Not in this architecture, because the HA does not know what is the > > MR's environment (e.g. what BIDs he uses on which interface, what are > > the interfaces characteristics and the characteristics of the network > > it connects to), and thus cannot create filter rules for the MR. > > Same as above. > > I do not understand why HA cannot create a filter. It is not about BIDs of > interfaces, it is only the filter rules. Again, not a discussion for today. > > > > > > >> 4. The peer enforce those filter rules. > > > > > > For a bidirectional tunnel, there are two processes for two > > > directions, > > > correct? > > > > Of course the MR/MN also enforces the filter rules it has created and > > sent to the HA/CN. > > OK. > > > > > > To summarize, in the current mext architecture, the MR creates filter > > rules from policies (policies received by a third-part node), enforce > > them, and send them to the HA/CN, the HA/CN can then validate them > > against the policy, and enforce them. > > OK, we are on same track. > Now we can make the next step, checking existing specifications for the > filter rules. I like to see references to documents with page numbers or > section numbers. > > We have already: > > draft-soliman-monami6-flow-binding-04.txt > 3.1. Flow Identification option > > "PF: The OpenBSD Packet Filter" > . > > RSVP Filterspec (somewhere in RFC2205) > > NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) > > > Teco. > > > > > > > Regards, > > -- > > Romain KUNTZ > > kuntz@lsiit.u-strasbg.fr > > Louis Pasteur University - Networks and Protocols Team > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From EarlebeaterPickett@oclc.org Fri Dec 07 22:44:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0qbs-0000V2-MZ; Fri, 07 Dec 2007 22:44:12 -0500 Received: from cpe-72-224-98-155.nycap.res.rr.com ([72.224.98.155] helo=spazzsputer.nycap.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J0qbs-0003bF-En; Fri, 07 Dec 2007 22:44:12 -0500 Received: from jorgenson by oclc.org with SMTP id 20mj80AIVg for ; Fri, 7 Dec 2007 22:44:01 +0500 From: "Kareem Holder" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J11V0-0008P2-85; Sat, 08 Dec 2007 10:21:50 -0500 Received: from catv-566534fd.catv.broadband.hu ([86.101.52.253] helo=magdagep.chello.hu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J11Uz-00028D-TR; Sat, 08 Dec 2007 10:21:50 -0500 Received: from plastron by suntimes.com with SMTP id CuiymHv6PO for ; Sat, 8 Dec 2007 16:20:49 -0100 From: "Allan Mendoza" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J13Gi-0002Xp-BN; Sat, 08 Dec 2007 12:15:12 -0500 Received: from cpe-24-90-58-8.nyc.res.rr.com ([24.90.58.8] helo=utkarsh.nyc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J13Gi-00057t-3y; Sat, 08 Dec 2007 12:15:12 -0500 Received: from eradicate by snopes.com with SMTP id r3JM6qEg1O for ; Sat, 8 Dec 2007 12:15:09 +0500 From: "Irvin Tran" To: Subject: Get your bonus and walk the red carpet to winnings and fun. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Travel no further than your screen and get your free $999 Players from the United States and around the world! After thatit's only fun and winning. We're serious about fun. http://eurocasinoaj.com/ From LeticiaspearmintNicholas@panoramio.com Sat Dec 08 19:59:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1AWA-0004GN-Kx; Sat, 08 Dec 2007 19:59:38 -0500 Received: from [68.113.118.69] (helo=yourxhtr8hvc4p) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1AWA-0007zL-Ax; Sat, 08 Dec 2007 19:59:38 -0500 Received: from yawl by panoramio.com with SMTP id Ob4kdaLfQ5 for ; Sat, 8 Dec 2007 18:59:25 +0600 From: "Erma Mccord" To: Subject: Our casino is for everyone who likes to win! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de If you're in the US or anywhere else, join your new casino paradise. Get $999 you download our casino. We pay you to play. We have it all! http://eurocasinoak.com/ From Grandinettiomq@toere.de Sat Dec 08 21:48:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1CD3-0003Hf-20 for nemo-archive@lists.ietf.org; Sat, 08 Dec 2007 21:48:01 -0500 Received: from [196.212.102.82] (helo=[41.206.160.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1CD1-0002Lp-IH for nemo-archive@lists.ietf.org; Sat, 08 Dec 2007 21:48:00 -0500 Received: from marupingw-pc by toere.de with ASMTP id FB23014C for ; Sun, 9 Dec 2007 04:48:31 +0200 Received: from marupingw-pc ([198.182.64.159]) by toere.de with ESMTP id B8BA32A813FC for ; Sun, 9 Dec 2007 04:48:31 +0200 Message-ID: <85573214.E2205A1D@toere.de> Date: Sun, 9 Dec 2007 04:47:57 +0200 From: "Eldin Grandinetti" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: uidodalc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 touch her tonsils when she sucks your dick deep throat http://ipiloxa.com/ From mext-bounces@ietf.org Sun Dec 09 08:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1LrR-0007DM-SW; Sun, 09 Dec 2007 08:06:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1LrP-0007D5-Sb for mext@ietf.org; Sun, 09 Dec 2007 08:06:19 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1LrP-0004oR-3e for mext@ietf.org; Sun, 09 Dec 2007 08:06:19 -0500 Received: from [192.168.1.129] (165.44.217.87.dynamic.jazztel.es [87.217.44.165])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id ACD29285C96;Sun, 9 Dec 2007 14:06:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31A304B2-72ED-4F08-89F5-5778F17CA785@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Sun, 9 Dec 2007 14:06:23 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.1582 TC:1F TRN:36 TV:5.0.1023(15594.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Julien Laganier Subject: [MEXT] [RFC3775 changes] Next steps X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, We are chartered to update RFC3775 with minor changes. According to our charter: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. Dec 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. So in order to proceed with this, we will do the following: Anyone that thinks that there is something that need to be updated in RFC3775, send a mail to the ml for discussion in a diff format, meaning, the current text (OLD text) and the proposed text (NEW text) and the motivation for the change. Please specify the section and sub section and paragraph number for the proposed modification. Please send the mails with [RFC3775 changes] included in the subject so we can easily keep track of these. So, the format for these request are: ------------------------------------------------------------------------ ------ Subject: [RFC3775 changes] Modification title Section, sub-section and paragraph involved: XXXXXX OLD TEXT: XXXXXXXXXXXXXXXXX NEW TEXT: XXXXXXXXXXXXXXXXXXXXXXXX Motivation: XXXXXXXXXXXXXXXXXXXXXXXXXXXX ------------------------------------------------------------------------ ------ We (the chairs) will keep a list of proposed updates and the comments received for each of those. Near the deadline we will produce a rfc3775bis with the changes that have reached consensus. We already have a list of issues presented and discussed in the vancouver meeting, please convert them into the OLD/NEW text approach if you think they are relevant and need to be addressed Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 09 13:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QhO-0000lf-US; Sun, 09 Dec 2007 13:16:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QhM-0000Rz-M9 for mext@ietf.org; Sun, 09 Dec 2007 13:16:16 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1QhL-0005cY-Qs for mext@ietf.org; Sun, 09 Dec 2007 13:16:16 -0500 Received: from [163.117.203.23] (unknown [163.117.203.23])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id A8859288ADA;Sun, 9 Dec 2007 19:16:10 +0100 (CET) In-Reply-To: <47535A6D.4050708@sfc.wide.ad.jp> References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> <47535A6D.4050708@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <102D495F-E2F4-46AC-B501-0592ECC408AA@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] MEXT Rechartering Date: Sun, 9 Dec 2007 15:24:57 +0100 To: Shinta Sugimoto X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.7836 TC:1F TRN:50 TV:5.0.1023(15596.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 4.7 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Shinta, Hui has presnetd this proposed recharter item in the meeting and =20 there was some interest. At this point, we need to understand what =20 things are more inmportant to work on, since we won't be taking all =20 th work. I think you should try to figure out what is the proposed =20 text that would cover both of your ideas and present the motivations =20 to the wg why this is importnat to work in the short term, in termos =20 of why this is critical for MIPv6/nemo deployment Regards, marcelo El 03/12/2007, a las 2:22, Shinta Sugimoto escribi=F3: > Hello Marcelo, > > We would like to ask for adding a new item to the MEXT charter to > define interaction between Mobile IPv6 and IPsec/IKE. > > We have been working on this topic since 2005 and the issues and > solutions are described in the following internet draft [1]. > Although the draft is currently expired, we are making a new revision > according to the report from implementers and the latest discussion > on MIPv6 WG mailing list about DSMIPv6-IKE interaction. > > [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > > We are also aware of the recent work by Deng et al.[2], but we are > not exactly sure about what the relation between the two drafts is =20 > yet. > Anyway, we believe that it is useful to produce the document > (an informational RFC) which defines the interaction between MIPv6 > and IPsec/IKE (Note: "MIPv6" refers to both RFC 3775 and DSMIPv6, > and "IKE" refers to both IKEv1 and IKEv2) and we hope that the > MEXT WG takes this work item. And we are definitely willing to make > the contribution. > > I am regretful to say that I will not be attending the IETF meeting > this time, but will follow the discussion on the mailing list. > > [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > [2] http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt > > > Regards, > Shinta > > marcelo bagnulo braun wrote: >> Hi folks, >> Even though the WG just been created, we already have some new =20 >> items that people seem to be interested in including in the MEXT =20 >> charter, so we would like to open that discussion right away. =20 >> Moreover, we are planning to devote part of the next meeting in =20 >> Vancouver to discuss possible additional items to be included in =20 >> the MEXT charter in the rechartering process. >> So in order to do this process, we would like that if you have =20 >> items that you think should be included in the charter, please =20 >> send a proposal to the MEXT ml so it can be discussed and also if =20 >> you want to include it as part of the MEXT meeting rechartering =20 >> discussion, ask for a slot. >> Thanks, marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From KelliepropheticFeliciano@warnerbros.com Sun Dec 09 13:20:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QlT-0004w6-CL; Sun, 09 Dec 2007 13:20:31 -0500 Received: from host81-159-36-236.range81-159.btcentralplus.com ([81.159.36.236] helo=brownespc.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1QlS-0005jK-Ug; Sun, 09 Dec 2007 13:20:31 -0500 Received: from alabaster by warnerbros.com with SMTP id UlfWzzdGYR for ; Sun, 9 Dec 2007 18:20:22 +0000 From: "Josefina Swan" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1S8O-0002Vl-ID; Sun, 09 Dec 2007 14:48:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1S8M-0002Vf-P2 for mext@ietf.org; Sun, 09 Dec 2007 14:48:14 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1S8L-0000Oa-2I for mext@ietf.org; Sun, 09 Dec 2007 14:48:14 -0500 Received: from [163.117.203.23] (unknown [163.117.203.23])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id D4AA52AC32Cfor ; Sun, 9 Dec 2007 20:48:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1D00A7E9-2FF3-4F45-B710-373B5EE06636@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sun, 9 Dec 2007 20:44:14 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:2.4895 TC:02 TRN:30 TV:5.0.1023(15596.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [MEXT] next steps with draft-ietf-monami6-multiplecoa-04 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, the deadline for this document is Dec 2007 Submit Multiple CoA Registration to IESG so we really need to work these things out fast At the mext meeting draft-ietf-monami6-multiplecoa-04 was discussed There were a set of issues presented and the following was the feeling of the room. - With respect for DSMIP support, people felt that this was to be supported. The next steps for this are: if people in the ml feel otherwise, please speak up in the next couple of days, if not we assume that the consensus of the meeting holds The editor will address this issue for the next revision of the document - With respect to bulk registration at the CN, the feeling of the room was that we don't need to address this issue. Again, if someone feels different speak up in a couple of days, or we will assume that the consensus in the room holds - with respect to the threat described in draft-lim-mext-multiple-coa- verify-00, the feeling of the room was that we need to take this into account, so we need to address this threat. Again, if someone feel otherwise, please speak up in a couple of days. To proceed with these, we request the authors or other parties to provide text for the draft and propose it to the ML - With respect to the case of multihoming with a visited network and the home network, there was no clear consesus on the meeting but it seemed that there was more support for supporting this case. I have reached the same conclusion after reading the mailing list. So the next steps for this are that the author or other partis to provide text for this and propose it to the ml. I would request people and in particular the auhtor to provide text in about one week time, since our deadline is approaching really fast and we should be able to deal with these last issues fast, so we can issue a new short WGLC as with the other docuemnts. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 09 14:48:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1S8K-0002Ur-0N; Sun, 09 Dec 2007 14:48:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1S8I-0002Tg-9Y for mext@ietf.org; Sun, 09 Dec 2007 14:48:10 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1S8H-0001N6-NI for mext@ietf.org; Sun, 09 Dec 2007 14:48:09 -0500 Received: from [163.117.203.23] (unknown [163.117.203.23])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 8B6CF2AC32Cfor ; Sun, 9 Dec 2007 20:48:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Sun, 9 Dec 2007 20:04:29 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.0023 TC:1F TRN:28 TV:5.0.1023(15596.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [MEXT] Firewall and MIPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi folks, as you know, in MEXT we are chartered to work on firewall and MIPv6, in particular in our charter it is stated: Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. and Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. A design team was appointed to start this work and they have provided a report of their results in th meeting at IETF70. The output of the DT is: draft-krishnan-mip6-firewall-admin-02 draft-krishnan-mip6-firewall-vendor-02 At this point we need to decide how to move forward with this. So, i would like to ask people to read these documents and provide feedback, in particular if people are ok with taking these documents as WG items as they are or they would like the DT to do a new version of these addressing some issues. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LeilaburglarChristie@thinkgeek.com Sun Dec 09 15:12:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1SVY-0001zv-Ez; Sun, 09 Dec 2007 15:12:12 -0500 Received: from 85.137.118.97.dyn.user.ono.com ([85.137.118.97] helo=martinqv2tvrcj) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1SVX-0002HT-SB; Sun, 09 Dec 2007 15:12:12 -0500 Received: from houghton by thinkgeek.com with SMTP id vAoUa1yXvw for ; Sun, 9 Dec 2007 21:11:53 -0100 From: "Bettye Eddy" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1UNR-0000z0-O0; Sun, 09 Dec 2007 17:11:57 -0500 Received: from [79.145.208.211] (helo=familiar8gpg4n) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1UNR-0006il-4K; Sun, 09 Dec 2007 17:11:57 -0500 Received: from concordant by osnews.com with SMTP id pLzPIqmgBq for ; Sun, 9 Dec 2007 23:11:36 -0100 From: "Maryellen Bliss" To: Subject: Slots.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Win $$$ instead of throwing it all away at other casinos. We're serious about fun. USA players too! Download and GO! Play your favorite games from the comfort of your home, USA players ARE included! http://eurocasinoaj.com/ From HerminiaemanuelHanks@writeexpress.com Sun Dec 09 17:33:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1Uih-0000pF-HR for nemo-archive@lists.ietf.org; Sun, 09 Dec 2007 17:33:55 -0500 Received: from [86.71.27.215] (helo=mce2005) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1Uih-0007LM-3U for nemo-archive@lists.ietf.org; Sun, 09 Dec 2007 17:33:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01476343.writeexpress.com (8.13.1/8.13.1) with SMTP id QbKAZ4Ww23.001088.BGc.QMs.9959481589936 for ; Sun, 9 Dec 2007 23:32:52 -0100 Message-ID: <15055b01c83ab3$8f83ddc0$0201a8c0@mce2005> From: "Sharlene Pool" To: Subject: Your family Date: Sun, 9 Dec 2007 23:32:52 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_150557_01C83AB3.8F83DDC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_150557_01C83AB3.8F83DDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_150557_01C83AB3.8F83DDC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_150557_01C83AB3.8F83DDC0-- From mext-bounces@ietf.org Sun Dec 09 20:10:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1XAC-00018n-3d; Sun, 09 Dec 2007 20:10:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1XAA-00018i-Ig for mext@ietf.org; Sun, 09 Dec 2007 20:10:26 -0500 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1XA9-0000in-8N for mext@ietf.org; Sun, 09 Dec 2007 20:10:26 -0500 Received: from localhost.localdomain (unknown [IPv6:2001:380:633:2:20b:cdff:fefb:2a8]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 921EE4D911; Mon, 10 Dec 2007 10:10:21 +0900 (JST) Message-ID: <475C91E0.9030404@sfc.wide.ad.jp> Date: Mon, 10 Dec 2007 10:09:52 +0900 From: Shinta Sugimoto User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] MEXT Rechartering References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> <47535A6D.4050708@sfc.wide.ad.jp> <102D495F-E2F4-46AC-B501-0592ECC408AA@it.uc3m.es> In-Reply-To: <102D495F-E2F4-46AC-B501-0592ECC408AA@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello Marcelo, Thank you for your consideration. Yes, we understand that the MEXT WG needs privatization of the work items as there seem to be too many proposed work items. As you suggest, we will contact Hui and his colleagues and try to figure out the texts that cover both of our work and explanation of why it is important for the MIPv6/NEMO deployment. Thanks again for your support and help. Regards, Shinta marcelo bagnulo braun wrote: > Hi Shinta, >=20 > Hui has presnetd this proposed recharter item in the meeting and there=20 > was some interest. At this point, we need to understand what things are= =20 > more inmportant to work on, since we won't be taking all th work. I=20 > think you should try to figure out what is the proposed text that would= =20 > cover both of your ideas and present the motivations to the wg why this= =20 > is importnat to work in the short term, in termos of why this is=20 > critical for MIPv6/nemo deployment >=20 > Regards, marcelo >=20 >=20 > El 03/12/2007, a las 2:22, Shinta Sugimoto escribi=F3: >=20 >> Hello Marcelo, >> >> We would like to ask for adding a new item to the MEXT charter to >> define interaction between Mobile IPv6 and IPsec/IKE. >> >> We have been working on this topic since 2005 and the issues and >> solutions are described in the following internet draft [1]. >> Although the draft is currently expired, we are making a new revision >> according to the report from implementers and the latest discussion >> on MIPv6 WG mailing list about DSMIPv6-IKE interaction. >> >> [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt >> >> We are also aware of the recent work by Deng et al.[2], but we are >> not exactly sure about what the relation between the two drafts is yet= . >> Anyway, we believe that it is useful to produce the document >> (an informational RFC) which defines the interaction between MIPv6 >> and IPsec/IKE (Note: "MIPv6" refers to both RFC 3775 and DSMIPv6, >> and "IKE" refers to both IKEv1 and IKEv2) and we hope that the >> MEXT WG takes this work item. And we are definitely willing to make >> the contribution. >> >> I am regretful to say that I will not be attending the IETF meeting >> this time, but will follow the discussion on the mailing list. >> >> [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt >> [2] http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt >> >> >> Regards, >> Shinta >> >> marcelo bagnulo braun wrote: >>> Hi folks, >>> Even though the WG just been created, we already have some new items=20 >>> that people seem to be interested in including in the MEXT charter,=20 >>> so we would like to open that discussion right away. Moreover, we are= =20 >>> planning to devote part of the next meeting in Vancouver to discuss=20 >>> possible additional items to be included in the MEXT charter in the=20 >>> rechartering process. >>> So in order to do this process, we would like that if you have items=20 >>> that you think should be included in the charter, please send a=20 >>> proposal to the MEXT ml so it can be discussed and also if you want=20 >>> to include it as part of the MEXT meeting rechartering discussion,=20 >>> ask for a slot. >>> Thanks, marcelo >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From tom.green@thames-immobilier.com Sun Dec 09 22:36:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ZRO-00032N-2G; Sun, 09 Dec 2007 22:36:22 -0500 Received: from [201.229.145.235] (helo=tdev145-235.codetel.net.do) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1ZRD-0004fh-4p; Sun, 09 Dec 2007 22:36:22 -0500 Received: from [201.229.145.235] by redir-mail-telehouse1.gandi.net; Mon, 10 Dec 2007 04:39:51 +0100 Message-ID: <01c83ae6$b3978580$eb91e5c9@tom.green> From: "jeuMendoza" To: Subject: who are free to come Date: Mon, 10 Dec 2007 04:39:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.5 X-Spam-Score: 4.3 (++++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Hey You I'm 26 years old I read your profile online Reply to me at Potato@GloryLandUsa.info and tell me about yourself if you want to chat or get to know each other better I will respond right away and send a pic and some of my info right away Thank you From DewittcountySnider@washingtonpost.com Mon Dec 10 01:17:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1bxi-0006nW-9K for nemo-archive@lists.ietf.org; Mon, 10 Dec 2007 01:17:54 -0500 Received: from 24-205-9-246.dhcp.mtpk.ca.charter.com ([24.205.9.246] helo=gcbook) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1bxh-0001t6-Tu for nemo-archive@lists.ietf.org; Mon, 10 Dec 2007 01:17:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19002608.washingtonpost.com (8.13.1/8.13.1) with SMTP id wwivBJE790.571387.lGE.52D.1567175290189 for ; Sun, 9 Dec 2007 22:16:16 +0800 Message-ID: <13a4201c83af4$66328fc0$0200a8c0@GCBOOK> From: "Napoleon Nielsen" To: Subject: Your order approved Date: Sun, 9 Dec 2007 22:16:16 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_13A3E_01C83AF4.66328FC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_13A3E_01C83AF4.66328FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_13A3E_01C83AF4.66328FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_13A3E_01C83AF4.66328FC0-- From raina.Kuul@ksmca.com Mon Dec 10 04:36:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1f3t-0000Jo-0B for nemo-archive@lists.ietf.org; Mon, 10 Dec 2007 04:36:29 -0500 Received: from [87.116.71.23] (helo=IP-71.23.dig-image.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1f3s-0006MS-GE for nemo-archive@lists.ietf.org; Mon, 10 Dec 2007 04:36:28 -0500 Received: from Jozzo-home ([165.192.3.137] helo=Jozzo-home) by IP-71.23.dig-image.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1Drtzi-000PNI-AS for nemo-archive@lists.ietf.org; Mon, 10 Dec 2007 11:37:01 +0200 Message-ID: <0E3559C0.A3B21888@ksmca.com> Date: Mon, 10 Dec 2007 11:36:40 +0200 From: "raina Kuul" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: flyte Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 i'd be scared too if my dick was that small http://www.ikogear.com/ From mext-bounces@ietf.org Mon Dec 10 05:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fpl-0000Mp-3T; Mon, 10 Dec 2007 05:25:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1fpj-0000Mk-C1 for mext@ietf.org; Mon, 10 Dec 2007 05:25:55 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J1fph-0004tO-EZ for mext@ietf.org; Mon, 10 Dec 2007 05:25:55 -0500 Received: (qmail 31591 invoked for bounce); 10 Dec 2007 10:25:52 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 10 Dec 2007 10:25:52 -0000 Message-Id: <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Teco Boot In-Reply-To: <008f01c83793$65e92ec0$31bb8c40$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 10 Dec 2007 11:25:51 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'Hannes Tschofenig' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Teco, On 2007/12/06, at 0:05, Teco Boot wrote: >> Not in this architecture, because the HA does not know what is the >> MR's environment (e.g. what BIDs he uses on which interface, what are >> the interfaces characteristics and the characteristics of the network >> it connects to), and thus cannot create filter rules for the MR. > > Same as above. > > I do not understand why HA cannot create a filter. It is not about > BIDs of > interfaces, it is only the filter rules. Again, not a discussion for > today. Filter rules are IMHO tightly related to path identifiers, thus, in the case of MCoA, BID. > OK, we are on same track. > Now we can make the next step, checking existing specifications for > the > filter rules. I like to see references to documents with page > numbers or > section numbers. > > We have already: > > draft-soliman-monami6-flow-binding-04.txt > 3.1. Flow Identification option Acutally in the latest version (-05), the flow id option changed and the flow description part is supposed to be described in another document (not defined yet). > "PF: The OpenBSD Packet Filter" > . Do you mean using the grammar that PF defines as a reference to define ASCII flow filters? I don't think it's a good idea. The problem with PF, netfilter or any OS packet filtering is that each it's really OS- dependent, ie the grammar depends on what is implemented in the kernel filtering framework. The grammar also might be too complex for what we need (e.g. "--port 80" could be replaced with just "80" if we define strict order of the arguments fields). > RSVP Filterspec (somewhere in RFC2205) From what I see, the FILTER_SPEC class only allows to perform a selection on the IPv6 source address and source port or flow label. > NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) This would need to be adapted to IPv6 and its specificities (next header filed, flow label, etc.), so it might be better to define something from scratch. I would also add draft-larsson-mext-flow-distribution-rules that proposes a multihoming-specific grammar to define ASCII flow filters. Regards, Romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 05:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1frz-0002Jn-WF; Mon, 10 Dec 2007 05:28:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1frz-0002Ji-2w for mext@ietf.org; Mon, 10 Dec 2007 05:28:15 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1fry-0007Xt-J6 for mext@ietf.org; Mon, 10 Dec 2007 05:28:15 -0500 Received: (qmail 31618 invoked for bounce); 10 Dec 2007 10:28:13 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 10 Dec 2007 10:28:13 -0000 Message-Id: From: Romain KUNTZ To: George Tsirtsis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 10 Dec 2007 11:28:12 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Hannes Tschofenig , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello Georges, On 2007/12/08, at 3:56, George Tsirtsis wrote: > Just to make sure this is clear, draft-soliman-monami6-flow-binding is > the same kind of flow definition (i.e., binary X-tuple definition) > with the RSVP Filterspec. The main difference is that draft-soliman > includes an SPI which I think is important to include for something > like this. RFC2207 defines RSVP Extensions for IPSEC Data Flows. But as I said in my other mail to Teco, the selectors defined by RSVP to define a flow might be romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 05:40:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1g3g-0005RO-4X; Mon, 10 Dec 2007 05:40:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1g3e-0005IS-RK for mext@ietf.org; Mon, 10 Dec 2007 05:40:18 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1g3e-00081u-6v for mext@ietf.org; Mon, 10 Dec 2007 05:40:18 -0500 Received: (qmail invoked by alias); 10 Dec 2007 10:40:16 -0000 Received: from p54985A07.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.90.7] by mail.gmx.net (mp021) with SMTP; 10 Dec 2007 11:40:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zXhkTr5Bz+slRus0s4Yzq2Ygba6GBFhJd5NElPl 3kDFyF7XQ8nTcz Message-ID: <475D178F.4090400@gmx.net> Date: Mon, 10 Dec 2007 11:40:15 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> In-Reply-To: <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org A small note: > Filter rules are IMHO tightly related to path identifiers, thus, in > the case of MCoA, BID. > The concept of "path identifiers" does not exist in IP. Ciao Hannes _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 06:11:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gXd-0004kU-3S; Mon, 10 Dec 2007 06:11:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gXb-0004k6-IV for mext@ietf.org; Mon, 10 Dec 2007 06:11:15 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J1gXb-0006Au-5Z for mext@ietf.org; Mon, 10 Dec 2007 06:11:15 -0500 Received: (qmail 425 invoked for bounce); 10 Dec 2007 11:11:14 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 10 Dec 2007 11:11:14 -0000 Message-Id: <732E462A-214A-4C9A-8F00-3338EB7BA970@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Hannes Tschofenig In-Reply-To: <475D178F.4090400@gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 10 Dec 2007 12:11:14 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D178F.4090400@gmx.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On 2007/12/10, at 11:40, Hannes Tschofenig wrote: > A small note: > >> Filter rules are IMHO tightly related to path identifiers, thus, in >> the case of MCoA, BID. >> > The concept of "path identifiers" does not exist in IP. I'm not sure what is your point here, but when you have multiple concurrent paths, you still need to associate each of them with an unique identifier. This is what the BID stands for in MCoA. romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 06:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gdM-0003Fj-AL; Mon, 10 Dec 2007 06:17:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gdL-0003Fc-7d for mext@ietf.org; Mon, 10 Dec 2007 06:17:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1gdK-0000Zx-I1 for mext@ietf.org; Mon, 10 Dec 2007 06:17:10 -0500 Received: (qmail invoked by alias); 10 Dec 2007 11:17:07 -0000 Received: from p54985A07.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.90.7] by mail.gmx.net (mp040) with SMTP; 10 Dec 2007 12:17:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19oyIJO7l9ouCZMVpicn3SXHs6XK/YeRGhIZ28Ghi sCWcyc+dTqurJm Message-ID: <475D2033.4020809@gmx.net> Date: Mon, 10 Dec 2007 12:17:07 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D178F.4090400@gmx.net> <732E462A-214A-4C9A-8F00-3338EB7BA970@clarinet.u-strasbg.fr> In-Reply-To: <732E462A-214A-4C9A-8F00-3338EB7BA970@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org The BID is not a path identifier. I just re-read the definition in http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-04 Btw, it is not a good idea of to use RFC 2119 language in the terminology section. Ciao Hannes Romain KUNTZ wrote: > On 2007/12/10, at 11:40, Hannes Tschofenig wrote: >> A small note: >> >>> Filter rules are IMHO tightly related to path identifiers, thus, in >>> the case of MCoA, BID. >>> >> The concept of "path identifiers" does not exist in IP. > > I'm not sure what is your point here, but when you have multiple > concurrent paths, you still need to associate each of them with an > unique identifier. This is what the BID stands for in MCoA. > > romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 06:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gu5-0003Hj-6T; Mon, 10 Dec 2007 06:34:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gu3-0003Hd-Rh for mext@ietf.org; Mon, 10 Dec 2007 06:34:27 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J1gu3-0006by-CX for mext@ietf.org; Mon, 10 Dec 2007 06:34:27 -0500 Received: (qmail 1396 invoked for bounce); 10 Dec 2007 11:34:26 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 10 Dec 2007 11:34:26 -0000 Message-Id: <849D8552-B443-4AE7-B99B-1CD4E707908B@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Hannes Tschofenig In-Reply-To: <475D2033.4020809@gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 10 Dec 2007 12:34:26 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D178F.4090400@gmx.net> <732E462A-214A-4C9A-8F00-3338EB7BA970@clarinet.u-strasbg.fr> <475D2033.4020809@gmx.net> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On 2007/12/10, at 12:17, Hannes Tschofenig wrote: > The BID is not a path identifier. I just re-read the definition in http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-04 Ok, path might not be the exact term to use in this context. Maybe tunnel identifier is more suitable. romain > Romain KUNTZ wrote: >> On 2007/12/10, at 11:40, Hannes Tschofenig wrote: >>> A small note: >>> >>>> Filter rules are IMHO tightly related to path identifiers, thus, >>>> in the case of MCoA, BID. >>>> >>> The concept of "path identifiers" does not exist in IP. >> >> I'm not sure what is your point here, but when you have multiple >> concurrent paths, you still need to associate each of them with an >> unique identifier. This is what the BID stands for in MCoA. >> >> romain > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 06:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1gus-0003TI-Qh; Mon, 10 Dec 2007 06:35:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1guq-0003T5-L7 for mext@ietf.org; Mon, 10 Dec 2007 06:35:16 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1guq-0000yG-6i for mext@ietf.org; Mon, 10 Dec 2007 06:35:16 -0500 Received: (qmail invoked by alias); 10 Dec 2007 11:35:11 -0000 Received: from p54985A07.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.90.7] by mail.gmx.net (mp057) with SMTP; 10 Dec 2007 12:35:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/T4MQJWm7TzMgcdJiGi0jCS1+RJxy4ZR4QOqExGP kQB1k5ITniqJ6G Message-ID: <475D246E.1070202@gmx.net> Date: Mon, 10 Dec 2007 12:35:10 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D178F.4090400@gmx.net> <732E462A-214A-4C9A-8F00-3338EB7BA970@clarinet.u-strasbg.fr> <475D2033.4020809@gmx.net> <849D8552-B443-4AE7-B99B-1CD4E707908B@clarinet.u-strasbg.fr> In-Reply-To: <849D8552-B443-4AE7-B99B-1CD4E707908B@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Romain KUNTZ wrote: > On 2007/12/10, at 12:17, Hannes Tschofenig wrote: >> The BID is not a path identifier. I just re-read the definition in >> http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-04 > > Ok, path might not be the exact term to use in this context. > Maybe tunnel identifier is more suitable. Yep. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 07:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1hVi-0007CT-Bp; Mon, 10 Dec 2007 07:13:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1hVg-00079G-Vi for mext@ietf.org; Mon, 10 Dec 2007 07:13:21 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1hVg-0001sY-48 for mext@ietf.org; Mon, 10 Dec 2007 07:13:20 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1493910rvb for ; Mon, 10 Dec 2007 04:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8DVeEIK9pOQXy1QoE4u2Tt3c80KLyZbx9GF89328mCs=; b=FnP4rTvIjasQxsTkdXevZo9VYFVDiX5puEgtACH5h9mxFKRl9S1jx/scoM9TCiJJUv/A08kBWjDYdzAcErr4nhxi2/fHCmKBp00Rk/P/SWQRMNz4QLQTs4yM3ptFWCgJ3yKcsMXWQkER8iN9h5GbOsIMYW3hTWbRHqT+8ntiQr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PZ7YtUqXnh4f2I5lzPrn6FDETgLUW4idHxcwzIEQTU4bKeZ7TD5cWAKHy7A9s+fjbN87wnwi0/tLM21Q0jUL8ZRajDidNEveaQVyOlmUJjEzzIHW7echQOm7NoE5PD1oEO6EDwKG3q7OyrTpvid+VCZ0VN1fuPrSKYf0l+2ukk8= Received: by 10.140.199.19 with SMTP id w19mr384185rvf.1197288799560; Mon, 10 Dec 2007 04:13:19 -0800 (PST) Received: by 10.141.180.1 with HTTP; Mon, 10 Dec 2007 04:13:19 -0800 (PST) Message-ID: <1d38a3350712100413o49ef4157y96478d387ca5490f@mail.gmail.com> Date: Mon, 10 Dec 2007 20:13:19 +0800 From: "Hui Deng" To: "Shinta Sugimoto" Subject: Re: [MEXT] MEXT Rechartering In-Reply-To: <475C91E0.9030404@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1854AD9E-C316-4321-BE85-426DA3D17022@it.uc3m.es> <47535A6D.4050708@sfc.wide.ad.jp> <102D495F-E2F4-46AC-B501-0592ECC408AA@it.uc3m.es> <475C91E0.9030404@sfc.wide.ad.jp> X-Spam-Score: 1.2 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Thanks Shinta, We will do this asap. -Hui 2007/12/10, Shinta Sugimoto : > Hello Marcelo, > > Thank you for your consideration. > > Yes, we understand that the MEXT WG needs privatization of the work > items as there seem to be too many proposed work items. > As you suggest, we will contact Hui and his colleagues and try to > figure out the texts that cover both of our work and explanation of > why it is important for the MIPv6/NEMO deployment. > > Thanks again for your support and help. > > Regards, > Shinta > > marcelo bagnulo braun wrote: > > Hi Shinta, > > > > Hui has presnetd this proposed recharter item in the meeting and there > > was some interest. At this point, we need to understand what things are > > more inmportant to work on, since we won't be taking all th work. I > > think you should try to figure out what is the proposed text that would > > cover both of your ideas and present the motivations to the wg why this > > is importnat to work in the short term, in termos of why this is > > critical for MIPv6/nemo deployment > > > > Regards, marcelo > > > > > > El 03/12/2007, a las 2:22, Shinta Sugimoto escribi=F3: > > > >> Hello Marcelo, > >> > >> We would like to ask for adding a new item to the MEXT charter to > >> define interaction between Mobile IPv6 and IPsec/IKE. > >> > >> We have been working on this topic since 2005 and the issues and > >> solutions are described in the following internet draft [1]. > >> Although the draft is currently expired, we are making a new revision > >> according to the report from implementers and the latest discussion > >> on MIPv6 WG mailing list about DSMIPv6-IKE interaction. > >> > >> [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > >> > >> We are also aware of the recent work by Deng et al.[2], but we are > >> not exactly sure about what the relation between the two drafts is yet= . > >> Anyway, we believe that it is useful to produce the document > >> (an informational RFC) which defines the interaction between MIPv6 > >> and IPsec/IKE (Note: "MIPv6" refers to both RFC 3775 and DSMIPv6, > >> and "IKE" refers to both IKEv1 and IKEv2) and we hope that the > >> MEXT WG takes this work item. And we are definitely willing to make > >> the contribution. > >> > >> I am regretful to say that I will not be attending the IETF meeting > >> this time, but will follow the discussion on the mailing list. > >> > >> [1] http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-03.txt > >> [2] http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt > >> > >> > >> Regards, > >> Shinta > >> > >> marcelo bagnulo braun wrote: > >>> Hi folks, > >>> Even though the WG just been created, we already have some new items > >>> that people seem to be interested in including in the MEXT charter, > >>> so we would like to open that discussion right away. Moreover, we are > >>> planning to devote part of the next meeting in Vancouver to discuss > >>> possible additional items to be included in the MEXT charter in the > >>> rechartering process. > >>> So in order to do this process, we would like that if you have items > >>> that you think should be included in the charter, please send a > >>> proposal to the MEXT ml so it can be discussed and also if you want > >>> to include it as part of the MEXT meeting rechartering discussion, > >>> ask for a slot. > >>> Thanks, marcelo > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >> > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 07:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1hvI-0007i5-Er; Mon, 10 Dec 2007 07:39:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1hvG-0007hz-Ud for mext@ietf.org; Mon, 10 Dec 2007 07:39:46 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1hvF-00087C-EO for mext@ietf.org; Mon, 10 Dec 2007 07:39:46 -0500 Received: from [163.117.139.221] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.221])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 4EF6B2AF0A2for ; Mon, 10 Dec 2007 13:39:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Mon, 10 Dec 2007 13:39:49 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-1.7418 TC:1F TRN:14 TV:5.0.1023(15596.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -3.8 (---) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [MEXT] Personal Mobile router reqs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, During the last MEXT meeting a candidate draft for our chartered item on personal router requirement was presented. We wanted to ask if this should be accepted as a WG item, but nobody has read it. So we ask people to read the draft and provide review and comments, in particular about accepting this work on the WG. The draft can be found at: http://www.ietf.org/internet-drafts/draft- ng-nemo-ce-req-01.txt Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 08:11:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1iQ2-0003Dw-ND; Mon, 10 Dec 2007 08:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1iQ1-0003Dm-HM for mext@ietf.org; Mon, 10 Dec 2007 08:11:33 -0500 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1iPz-0000Ki-Lu for mext@ietf.org; Mon, 10 Dec 2007 08:11:33 -0500 Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id 596CF77626B; Mon, 10 Dec 2007 07:11:30 -0600 (CST) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar01.ndc.nasa.gov with ESMTP id wCdiUwJNdEBXVhLu; Mon, 10 Dec 2007 07:11:30 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 07:11:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Personal Mobile router reqs Date: Mon, 10 Dec 2007 07:10:43 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Personal Mobile router reqs Thread-Index: Acg7KguIPy1Mab5CSWWt8z0KIrSwugAAq5gQ References: From: "Ivancic, William D. (GRC-RCN0)" To: "marcelo bagnulo braun" , X-OriginalArrivalTime: 10 Dec 2007 13:11:29.0917 (UTC) FILETIME=[2D9282D0:01C83B2E] X-Spam-Score: -3.8 (---) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I read the draft. It fits in with the car-to-car and aeronautics requirements drafts. I believe the idea was to have independent requirement drafts from each group before moving ahead with any route optimization to make sure we, mext, understand the issues of each group and can hopefully develop the technology that is usable by all. That is certainly my desire - a common solution. Also, the consumer electronics requirements have been written in the same overall format at the aeronautics requirements draft - requirement/rational. Thus, if we wish to combine all the requirements into one draft at a later date, that should be relatively easy. Finally, we will be turning the aeronautics requirements draft from a nemo draft to a mext draft. I expect little to change other than that. I have been polling the aeronautics industry on whether or not there is strong desire (not requirement) for MR-to-MR route optimization. So far I am not convinced there is such desire. Many of us feel MR-to-MR route optimization would be more like a manet function (manemo) and a function that is far into the future for aeronautics due to regulatory and other issues. /Will > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Monday, December 10, 2007 7:40 AM > To: mext@ietf.org > Subject: [MEXT] Personal Mobile router reqs >=20 > Hi all, >=20 > During the last MEXT meeting a candidate draft for our=20 > chartered item on personal router requirement was presented.=20 > We wanted to ask if this should be accepted as a WG item, but=20 > nobody has read it. >=20 > So we ask people to read the draft and provide review and=20 > comments, in particular about accepting this work on the WG. >=20 > The draft can be found at: http://www.ietf.org/internet-drafts/draft- > ng-nemo-ce-req-01.txt >=20 > Thanks, marcelo >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 09:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jXK-0004IV-KF; Mon, 10 Dec 2007 09:23:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jXJ-0003xr-M2 for mext@ietf.org; Mon, 10 Dec 2007 09:23:09 -0500 Received: from smtp-3.dlr.de ([195.37.61.187] helo=smtp-2.dlr.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1jXI-00052n-Jf for mext@ietf.org; Mon, 10 Dec 2007 09:23:08 -0500 Received: from exbe04.intra.dlr.de ([192.168.35.37]) by smtp-2.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 15:23:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [MEXT] Personal Mobile router reqs Date: Mon, 10 Dec 2007 15:22:25 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Personal Mobile router reqs Thread-Index: Acg7KguIPy1Mab5CSWWt8z0KIrSwugAAq5gQAAKq1IA= References: From: To: , X-OriginalArrivalTime: 10 Dec 2007 14:23:06.0193 (UTC) FILETIME=[2E5A3410:01C83B38] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, > -----Urspr=FCngliche Nachricht----- > Von: Ivancic, William D. (GRC-RCN0)=20 > [mailto:william.d.ivancic@nasa.gov] > Gesendet: Montag, 10. Dezember 2007 14:11 > An: marcelo bagnulo braun; mext@ietf.org > Betreff: RE: [MEXT] Personal Mobile router reqs [...] > I have been polling the aeronautics industry on whether or not there=20 > is strong desire (not requirement) for MR-to-MR route optimization. =20 > So far I am not convinced there is such desire. Many of us feel=20 > MR-to-MR route optimization would be more like a manet function=20 > (manemo) and a function that is far into the future for aeronautics=20 > due to regulatory and other issues. We have to separate between safety related and non-safety related = communication. Safety-related (like Air Traffic Control) air2air/MR-to-MR communication = basically only consists of broadcast messages on the _link_ layer. Doing = this as multi-hop communication would be very futuristic. Hence there is = no nesting issue wrt NEMO. For the foreseeable future this is probably = going to stay as it is... However, for passenger communication (non-safety related) MR-to-MR = communication becomes important and would therefore require respective = optimization(s). Yet, as already pointed out, one will want to use a MANET protocol = between the aircraft which is very closely related to manemo. The question is whether the nesting problem is supposed to be solved = either within this WG or on manemo, or perhaps in both (resulting in two = solutions)? Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 09:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jfN-0007cu-8j; Mon, 10 Dec 2007 09:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jfL-0007Ok-Nv for mext@ietf.org; Mon, 10 Dec 2007 09:31:27 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1jfK-00025Z-0E for mext@ietf.org; Mon, 10 Dec 2007 09:31:27 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBAEVIE00455; Mon, 10 Dec 2007 14:31:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2007 08:31:12 -0600 Message-ID: In-Reply-To: <31A304B2-72ED-4F08-89F5-5778F17CA785@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC3775 changes] Last Accepted SQN Thread-Index: Acg6ZFoFhZWYcL+USA2u4N31CBvgYwA0i7SA References: <31A304B2-72ED-4F08-89F5-5778F17CA785@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , X-Spam-Score: -4.0 (----) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Julien Laganier Subject: [MEXT] [RFC3775 changes] Last Accepted SQN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo/All, Please find the details related to the last accepted sequence number. This issue have been discussed before on MIP6 and was submitted to the RFC3775 issue tracker on May 14, 2007. Please find the details below. Please feel free to discuss this issue. Best Regards, Ahmad +++++++++++++++++++++++++++++++++++++++++++++++ ISSUE: =3D=3D=3D=3D=3D=3D In response to a BU which contains an out of range sequence number, as per sections 9.5.1 and 11.7.1, the CN or HA is allowed to send a BA with a status of 135 after inserting the last accepted sequence number received in the last valid BU in the sequence number field (Different from the sequence number received in the outstanding BU) According to MN processing of the BA as specified under section 11.7.3., the MN will silently discard the received BA rather than picking the last accepted sequence number and then generate a new sequence number.=20 I think the intention was to allow the HA or CN to communicate back to the MN the last accepted sequence number, however, we are breaking the protocol by using this mechanism. This issue becomes critical in the case of PMIPv6 since the PMIP client would have thousands of outstanding P-BU and the received P-BA most probably will collide with another outstanding P-BU causing the PMIP client to drop the P-BA and continue to stay out of sync with the LMA/HA. OLD TEXT: =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 To my recollection, there is no need to change any of the existing text since the current text of RFC3775 goes inline with the original intention. However, the proposed text needs to be added. SOLUTION: =3D=3D=3D=3D=3D=3D=3D=3D=3D The most straightforward solution for this issue is to enable the original intention of RFC3775. i.e. by communicating back the last successful sequence number in a option: Las Valid Sequence Number Mobility Option: 6.2.x. Last Valid Sequence Number The Last Valid Sequence Number option has an alignment requirement of 2n. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3DTBD | Length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Valid Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Last Valid Sequence Number option is only valid in a BA, sent from the mobile node's home agent in reply to a home registration, with a status of 135. The Last Valid Sequence Number is the last sequence number that the Home Agent received in the last successful Binding Update for the specified session. In case the Home Agent receives a Binding Update with a sequence number outside the valid sequence number range, the Home Agent sends a BA with a status of 135. HA must copy the sequence number from the BU into the sequence number field of the BA. HA must include the last Valid Sequence Number into the Last valid Sequence Number Mobility option. > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Sunday, December 09, 2007 7:06 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] [RFC3775 changes] Next steps >=20 > Hi, >=20 > We are chartered to update RFC3775 with minor changes.=20 > According to our charter: >=20 >=20 > (B.1) Create and maintain issue lists that are generated on=20 > the basis of implementation and interoperability experience.=20 > Address specific issues with specific updates or revisions of=20 > the base specification. One specific area of concern that=20 > should be analyzed and addressed relates to multilink subnets. >=20 > This work item relates only to corrections and=20 > clarifications. The working group shall not revisit design=20 > decisions or change the protocol. >=20 > Dec 2008 Submit I-D(s) related to specific updates and=20 > corrections of RFC 3775 to IESG for publication as Proposed Standard. >=20 > So in order to proceed with this, we will do the following: >=20 > Anyone that thinks that there is something that need to be=20 > updated in RFC3775, send a mail to the ml for discussion in a=20 > diff format, meaning, the current text (OLD text) and the=20 > proposed text (NEW text) and the motivation for the change.=20 > Please specify the section and sub section and paragraph=20 > number for the proposed modification. Please send the mails=20 > with [RFC3775 changes] included in the subject so we can=20 > easily keep track of these. >=20 > So, the format for these request are: >=20 > -------------------------------------------------------------- > ---------- > ------ > Subject: [RFC3775 changes] Modification title >=20 > Section, sub-section and paragraph involved: XXXXXX >=20 > OLD TEXT: XXXXXXXXXXXXXXXXX >=20 > NEW TEXT: XXXXXXXXXXXXXXXXXXXXXXXX >=20 > Motivation: XXXXXXXXXXXXXXXXXXXXXXXXXXXX > -------------------------------------------------------------- > ---------- > ------ >=20 > We (the chairs) will keep a list of proposed updates and the=20 > comments received for each of those. > Near the deadline we will produce a rfc3775bis with the=20 > changes that have reached consensus. >=20 > We already have a list of issues presented and discussed in=20 > the vancouver meeting, please convert them into the OLD/NEW=20 > text approach if you think they are relevant and need to be addressed >=20 > Regards, marcelo >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 09:40:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jna-0004H5-Nu; Mon, 10 Dec 2007 09:39:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jnZ-0004Gz-OQ for mext@ietf.org; Mon, 10 Dec 2007 09:39:57 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1jnZ-0002Go-5u for mext@ietf.org; Mon, 10 Dec 2007 09:39:57 -0500 Received: from [163.117.139.221] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.221])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 8566529AE28;Mon, 10 Dec 2007 15:39:56 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4DA2403C-FF97-47F0-ABC1-46E6EB8D0F44@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Personal Mobile router reqs Date: Mon, 10 Dec 2007 15:40:01 +0100 To: "Ivancic, William D. (GRC-RCN0)" X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-22.1963 TC:01 TRN:47 TV:5.0.1023(15598.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.7 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi William, thanks for the feedback, El 10/12/2007, a las 14:10, Ivancic, William D. (GRC-RCN0) escribi=F3: > I read the draft. It fits in with the car-to-car and aeronautics > requirements drafts. I believe the idea was to have independent > requirement drafts from each group before moving ahead with any route > optimization to make sure we, mext, understand the issues of each =20 > group > and can hopefully develop the technology that is usable by all. =20 > That is > certainly my desire - a common solution. > > Also, the consumer electronics requirements have been written in the > same overall format at the aeronautics requirements draft - > requirement/rational. Thus, if we wish to combine all the =20 > requirements > into one draft at a later date, that should be relatively easy. > > Finally, we will be turning the aeronautics requirements draft from a > nemo draft to a mext draft. I expect little to change other than =20 > that. > > please do that > I have been polling the aeronautics industry on whether or not =20 > there is > strong desire (not requirement) for MR-to-MR route optimization. =20 > So far > I am not convinced there is such desire. Many of us feel MR-to-MR =20 > route > optimization would be more like a manet function (manemo) and a =20 > function > that is far into the future for aeronautics due to regulatory and =20 > other > issues. > that would certainly be interesting to know, so let us know of the =20 feedback you get regards, marcelo > /Will > > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, December 10, 2007 7:40 AM >> To: mext@ietf.org >> Subject: [MEXT] Personal Mobile router reqs >> >> Hi all, >> >> During the last MEXT meeting a candidate draft for our >> chartered item on personal router requirement was presented. >> We wanted to ask if this should be accepted as a WG item, but >> nobody has read it. >> >> So we ask people to read the draft and provide review and >> comments, in particular about accepting this work on the WG. >> >> The draft can be found at: http://www.ietf.org/internet-drafts/draft- >> ng-nemo-ce-req-01.txt >> >> Thanks, marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 09:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jvb-0000Bm-Py; Mon, 10 Dec 2007 09:48:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1jvZ-0000Bf-LK for mext@ietf.org; Mon, 10 Dec 2007 09:48:13 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1jvZ-0005d6-7d for mext@ietf.org; Mon, 10 Dec 2007 09:48:13 -0500 Received: from [163.117.139.221] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.221])by smtp03.uc3m.es (Postfix) with ESMTP id EC4E1286E10;Mon, 10 Dec 2007 15:48:07 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A2EA9E9-8EAC-4D3E-9A0D-58D5C3900B6F@bagnulo.net> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Mon, 10 Dec 2007 15:48:13 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.3164 TC:1F TRN:20 TV:5.0.1023(15598.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Julien Laganier Subject: [MEXT] MEXT interim meeting poll X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, as we mentioned already, we are thinking of doing a MEXT interim meeting. The information related to the proposed interim meeting is the following: MEXT interim meeting DATE: 7,8 feb 2007 Location: Madrid, SPAIN Goal of the meeting: the focus of the meeting would be the nemo ro work and other considerations for nemo global deployment. However, it would certainly be possible to extend to scope to other MEXT topics, as long as there is enough people interested in discussing the other topic that will attend the meeting. We are planning to make a decision on whether having the meeting or not at the end of the week and obviously a key criteria for this would be the people that would attend. So please, reply to me privately if you are planning to attend before Friday 14 dec so we can take a decision on this. Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 11:08:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lBH-0006aK-Jx; Mon, 10 Dec 2007 11:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1lBG-0006Rk-9W for mext@ietf.org; Mon, 10 Dec 2007 11:08:30 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1lBD-0004aj-V5 for mext@ietf.org; Mon, 10 Dec 2007 11:08:30 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBAG80PT027618; Mon, 10 Dec 2007 18:08:15 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 18:07:48 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 10:07:37 -0600 Received: from 172.19.244.155 ([172.19.244.155]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Dec 2007 16:07:37 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 10 Dec 2007 10:08:06 -0600 Subject: Re: [MEXT] MEXT interim meeting poll From: Basavaraj Patil To: ext marcelo bagnulo braun , Message-ID: Thread-Topic: [MEXT] MEXT interim meeting poll Thread-Index: Acg7RtlUF6d85qc6EdyGbQARJNUNiA== In-Reply-To: <9A2EA9E9-8EAC-4D3E-9A0D-58D5C3900B6F@bagnulo.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Dec 2007 16:07:37.0087 (UTC) FILETIME=[C818B0F0:01C83B46] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo/Julien, I do not see a need for an interim meeting. I think the next IETF meeting will be sufficient to meet the goals of the MEXT WG. -Basavaraj On 12/10/07 8:48 AM, "ext marcelo bagnulo braun" wrote: > Hi, > > as we mentioned already, we are thinking of doing a MEXT interim > meeting. The information related to the proposed interim meeting is > the following: > > MEXT interim meeting > DATE: 7,8 feb 2007 > Location: Madrid, SPAIN > Goal of the meeting: the focus of the meeting would be the nemo ro > work and other considerations for nemo global deployment. However, it > would certainly be possible to extend to scope to other MEXT topics, > as long as there is enough people interested in discussing the other > topic that will attend the meeting. > > We are planning to make a decision on whether having the meeting or > not at the end of the week and obviously a key criteria for this > would be the people that would attend. So please, reply to me > privately if you are planning to attend before Friday 14 dec so we > can take a decision on this. > > Thanks, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 12:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1m98-00048U-D2; Mon, 10 Dec 2007 12:10:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1m97-000483-Et for mext@ietf.org; Mon, 10 Dec 2007 12:10:21 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J1m96-00013N-VY for mext@ietf.org; Mon, 10 Dec 2007 12:10:21 -0500 Received: (qmail 12770 invoked for bounce); 10 Dec 2007 17:10:19 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 10 Dec 2007 17:10:19 -0000 Message-Id: <5CA2FB17-2DAD-4ECA-8AD0-389630D4D010@clarinet.u-strasbg.fr> From: Romain KUNTZ To: George Tsirtsis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Mon, 10 Dec 2007 18:10:18 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Hannes Tschofenig , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Someone pointed me that I forgot to finish my sentence :) On 2007/12/10, at 11:28, Romain KUNTZ wrote: > RFC2207 defines RSVP Extensions for IPSEC Data Flows. But as I said > in my other mail to Teco, the selectors defined by RSVP to define a > flow might be ... might not be enough. romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 12:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mKV-0001re-O9; Mon, 10 Dec 2007 12:22:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mKU-0001rX-F2 for mext@ietf.org; Mon, 10 Dec 2007 12:22:06 -0500 Received: from amailer.gwdg.de ([134.76.10.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1mKS-0006Qr-Vh for mext@ietf.org; Mon, 10 Dec 2007 12:22:06 -0500 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.2]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J1mKP-00086P-AX; Mon, 10 Dec 2007 18:22:01 +0100 Message-ID: <475D74B2.8060201@cs.uni-goettingen.de> Date: Mon, 10 Dec 2007 18:17:38 +0100 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> In-Reply-To: <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Martin Stiemerling , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, >> NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) > > This would need to be adapted to IPv6 and its specificities (next header > filed, flow label, etc.), so it might be better to define something from > scratch. > I don't think you're correct in spelling that draft-ietf-nsis-nslp-natfw is only concerned with IPv4 filters. To my knowledge it covers both IPv4 and IPv6 cases. CC-ing the draft editor (Martin Stiemerling) for his additional information. Xiaoming _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 12:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1me4-0001ZQ-CL; Mon, 10 Dec 2007 12:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1me2-0001ZK-MO for mext@ietf.org; Mon, 10 Dec 2007 12:42:18 -0500 Received: from web84105.mail.mud.yahoo.com ([68.142.206.192]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J1me2-0006wZ-Bd for mext@ietf.org; Mon, 10 Dec 2007 12:42:18 -0500 Received: (qmail 96541 invoked by uid 60001); 10 Dec 2007 17:42:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=sbbwLzgTiGp3vx9vVUkJhjj3OgC2vThjb52gGxaePHDiVsrNzzDpM5yr2n+/V9CnoWoJZeKtnnPaWh/NO/C2PfY0xyygpKuZuMr5I8cyJoP3w8moag+TGSK3ktigTRXtGZ+G8f0tnZNI9BWnjH5E77IxVbj6mFODUiSGMyg2XfU=; X-YMail-OSG: 8A8OgbQVM1nO8A8VKk6iXINrRSgQJqSrR14npwlPNOg_XtfcCXDE5sQf7mkQnUnzOo.Od5hCOg-- Received: from [206.16.17.212] by web84105.mail.mud.yahoo.com via HTTP; Mon, 10 Dec 2007 09:42:17 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Mon, 10 Dec 2007 09:42:17 -0800 (PST) From: Behcet Sarikaya To: mext@ietf.org MIME-Version: 1.0 Message-ID: <817251.94948.qm@web84105.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [MEXT] Re: Mext Diameter PD PS Presentation X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1118820080==" Errors-To: mext-bounces@ietf.org --===============1118820080== Content-Type: multipart/alternative; boundary="0-1981525601-1197308537=:94948" --0-1981525601-1197308537=:94948 Content-Type: text/plain; charset=us-ascii Hello Folks, Due to some carambolage, this draft could not be presented. We already received a number of opinions on Diameter Prefix Delegation idea, and we appreciate them all. If you have comments on the draft, please feel free to post them on mext mailiing list. You could as well cc it to dime. Regards, Behcet --0-1981525601-1197308537=:94948 Content-Type: text/html; charset=us-ascii
Hello Folks,
  Due to some carambolage, this draft could not be presented.
We already received a number of opinions on Diameter Prefix Delegation idea, and we appreciate them all.
  If you have comments on the draft, please feel free to post them on mext mailiing list. You could as well cc it to dime.

Regards,

Behcet

--0-1981525601-1197308537=:94948-- --===============1118820080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1118820080==-- From mext-bounces@ietf.org Mon Dec 10 14:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oFY-0001fR-Ph; Mon, 10 Dec 2007 14:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oFX-0001fH-VP for mext@ietf.org; Mon, 10 Dec 2007 14:25:07 -0500 Received: from ndjsbar02.ndc.nasa.gov ([198.120.25.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oFW-0001e1-4D for mext@ietf.org; Mon, 10 Dec 2007 14:25:07 -0500 Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id 330B06AC5E2; Mon, 10 Dec 2007 13:25:05 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar02.ndc.nasa.gov with ESMTP id z38Hj7pkDF0xOGBY; Mon, 10 Dec 2007 13:25:05 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 13:25:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] MEXT interim meeting poll Date: Mon, 10 Dec 2007 13:24:18 -0600 Message-ID: In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A0537BD37@XCH-NW-8V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MEXT interim meeting poll Thread-Index: Acg7O7pdepKt6TqLRruukf+MlvGfWAAFssXwAAOKjSA= References: <9A2EA9E9-8EAC-4D3E-9A0D-58D5C3900B6F@bagnulo.net> <0D090F1E0F5536449C7E6527AFFA280A0537BD37@XCH-NW-8V1.nw.nos.boeing.com> From: "Ivancic, William D. (GRC-RCN0)" To: "Davis, Terry L" , "marcelo bagnulo braun" X-OriginalArrivalTime: 10 Dec 2007 19:25:04.0865 (UTC) FILETIME=[5DEC2510:01C83B62] X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org, julien.ietf@laposte.net X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Marcelo, I just got notice today that I have to be at a NASA meeting (my funding source) on Feb 5-7 in Florida. Thus, I probably cannot make those dates unless I can find a suitable replacement. That is highly unlikely as I am the Principle Investigator. I will check with Wes Eddy regarding his availability and let you know. Worst case, I could setup a Webex easily for all to use. Also, I could setup a teleconference, but I don't have a toll free for outside the US. So that is not very good. =20 /Will ****************************** > > -----Original Message----- > > From: marcelo bagnulo braun [mailto:marcelo@bagnulo.net] > > Sent: Monday, December 10, 2007 6:48 AM > > To: mext@ietf.org > > Cc: Julien Laganier > > Subject: [MEXT] MEXT interim meeting poll > >=20 > > Hi, > >=20 > > as we mentioned already, we are thinking of doing a MEXT interim=20 > > meeting. The information related to the proposed interim meeting is=20 > > the following: > >=20 > > MEXT interim meeting > > DATE: 7,8 feb 2007 > > Location: Madrid, SPAIN > > Goal of the meeting: the focus of the meeting would be the nemo ro=20 > > work and other considerations for nemo global deployment.=20 > However, it=20 > > would certainly be possible to extend to scope to other=20 > MEXT topics,=20 > > as long as there is enough people interested in discussing=20 > the other=20 > > topic that will attend the meeting. > >=20 > > We are planning to make a decision on whether having the meeting or=20 > > not at the end of the week and obviously a key criteria for=20 > this would=20 > > be the people that would attend. So please, reply to me=20 > privately if=20 > > you are planning to attend before Friday 14 dec so we can take a=20 > > decision on this. > >=20 > > Thanks, marcelo > >=20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 14:41:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oVS-0002ae-SN; Mon, 10 Dec 2007 14:41:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oVQ-0002aU-Sv for mext@ietf.org; Mon, 10 Dec 2007 14:41:32 -0500 Received: from ndjsbar02.ndc.nasa.gov ([198.120.25.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1oVQ-0005pA-6L for mext@ietf.org; Mon, 10 Dec 2007 14:41:32 -0500 Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov (Spam Firewall) with ESMTP id EC8256ACF44; Mon, 10 Dec 2007 13:41:30 -0600 (CST) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsbar02.ndc.nasa.gov with ESMTP id caBxGoOfK3DmeDe8; Mon, 10 Dec 2007 13:41:30 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 13:41:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Personal Mobile router reqs Date: Mon, 10 Dec 2007 13:40:43 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Personal Mobile router reqs Thread-Index: Acg7KguIPy1Mab5CSWWt8z0KIrSwugAAq5gQAAKq1IAACvcF8A== References: From: "Ivancic, William D. (GRC-RCN0)" To: , X-OriginalArrivalTime: 10 Dec 2007 19:41:30.0091 (UTC) FILETIME=[A929B3B0:01C83B64] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Christian, Comments in line: > > Von: Ivancic, William D. (GRC-RCN0) > > [mailto:william.d.ivancic@nasa.gov] > > Gesendet: Montag, 10. Dezember 2007 14:11 > > An: marcelo bagnulo braun; mext@ietf.org > > Betreff: RE: [MEXT] Personal Mobile router reqs > [...] > > I have been polling the aeronautics industry on whether or=20 > not there=20 > > is strong desire (not requirement) for MR-to-MR route optimization. > > So far I am not convinced there is such desire. Many of us feel=20 > > MR-to-MR route optimization would be more like a manet function > > (manemo) and a function that is far into the future for aeronautics=20 > > due to regulatory and other issues. > We have to separate between safety related and non-safety=20 > related communication. Agreed. > Safety-related (like Air Traffic Control) air2air/MR-to-MR=20 > communication basically only consists of broadcast messages=20 > on the _link_ layer. Doing this as multi-hop communication=20 > would be very futuristic. Hence there is no nesting issue wrt=20 > NEMO. For the foreseeable future this is probably going to=20 > stay as it is... Agreed >=20 > However, for passenger communication (non-safety related)=20 > MR-to-MR communication becomes important and would therefore=20 > require respective optimization(s). I see this "desire" as falling into the "Consumer Electronics" category more so than aeronautics. If one is thinking that the passenger services would be over a satellite link, the MR-to-MR route optimization would certainly be nice. However, if the consumer is a business passenger and they have to tie back into the corporate network via VPNs, all route optimizations may be wasted as the security mechanisms may force an unoptimized route. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 15:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oxj-0002oX-7C; Mon, 10 Dec 2007 15:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oxh-0002oR-QN for mext@ietf.org; Mon, 10 Dec 2007 15:10:45 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oxf-0002rA-F8 for mext@ietf.org; Mon, 10 Dec 2007 15:10:45 -0500 Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 571F02896E0; Mon, 10 Dec 2007 21:10:33 +0100 (CET) Subject: Re: [MEXT] Personal Mobile router reqs From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: marcelo bagnulo braun In-Reply-To: References: Organization: Universidad Carlos III de Madrid Date: Mon, 10 Dec 2007 21:10:33 +0100 Message-Id: <1197317433.5032.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 X-Spam-Score: -3.8 (---) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1232229392==" Errors-To: mext-bounces@ietf.org --===============1232229392== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jBxij2gl0GH+thunoFzv" --=-jBxij2gl0GH+thunoFzv Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi all, I also read the draft and provided some feedback while in Vancouver. My main concerns are related with the fact that the requirements are very general, and may apply to many other scenarios. IMHO, requirements' document should be more concrete, especially concerning issues of security. Currently, it might seem that the requirements from the aeronautics and consumer industries are the same, and I still don't see that so clear (I would think twice before taking a plane that has the same security considerations for their communications that my PSP ;->). Regards, Carlos El lun, 10-12-2007 a las 13:39 +0100, marcelo bagnulo braun escribi=F3: > Hi all, >=20 > During the last MEXT meeting a candidate draft for our chartered item =20 > on personal router requirement was presented. We wanted to ask if =20 > this should be accepted as a WG item, but nobody has read it. >=20 > So we ask people to read the draft and provide review and comments, =20 > in particular about accepting this work on the WG. >=20 > The draft can be found at: http://www.ietf.org/internet-drafts/draft-=20 > ng-nemo-ce-req-01.txt >=20 > Thanks, marcelo >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-jBxij2gl0GH+thunoFzv Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHXZ05Ndy6TdFwT2cRAgTlAKCPJy/B4+SL+EVeFLGhV4/KKeyNSwCeKwWR HjykwOvwKB800GLBv7yTE38= =wu99 -----END PGP SIGNATURE----- --=-jBxij2gl0GH+thunoFzv-- --===============1232229392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1232229392==-- From mext-bounces@ietf.org Mon Dec 10 15:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pVm-0008QP-7a; Mon, 10 Dec 2007 15:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pVl-0008QJ-6r for mext@ietf.org; Mon, 10 Dec 2007 15:45:57 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pVj-0003k9-T6 for mext@ietf.org; Mon, 10 Dec 2007 15:45:57 -0500 Received: from [66.245.53.165] (helo=[10.0.0.127]) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J1pVh-0005kE-AV for mext@ietf.org; Mon, 10 Dec 2007 15:45:53 -0500 Message-ID: <475DA57E.4030200@earthlink.net> Date: Mon, 10 Dec 2007 12:45:50 -0800 From: "Charles E. Perkins" Organization: None, just now User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mext@ietf.org Subject: Re: [MEXT] MEXT interim meeting poll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 5a185a306015b1a28a306fc704168558239a348a220c260998e10e20eccb83e777232bb3fe5913eda8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.53.165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello folks, I would vote to not have the interim meeting, and just concentrate on getting things ready for the March IETF meeting. Regards, Charlie P. -- Please note my email address: charliep@computer.org [no affiliation] _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 10 19:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tHD-0001FW-L3; Mon, 10 Dec 2007 19:47:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1tHC-0001FL-1d for mext@ietf.org; Mon, 10 Dec 2007 19:47:10 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1tHB-0004zF-8t for mext@ietf.org; Mon, 10 Dec 2007 19:47:09 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lBB0l3JQ001289; Tue, 11 Dec 2007 09:47:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id lBB0l4Q16153; Tue, 11 Dec 2007 09:47:04 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id lBB0l3V17626; Tue, 11 Dec 2007 09:47:03 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.68.141.71]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 08:46:42 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id 8C5FA265DF05; Tue, 11 Dec 2007 08:45:54 +0800 (SGT) Subject: Re: [MEXT] Personal Mobile router reqs From: Chan-Wah Ng To: cjbc@it.uc3m.es In-Reply-To: <1197317433.5032.11.camel@localhost> References: <1197317433.5032.11.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Panasonic Singapore Labs Date: Tue, 11 Dec 2007 08:45:54 +0800 Message-Id: <1197333954.6454.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 X-OriginalArrivalTime: 11 Dec 2007 00:46:43.0314 (UTC) FILETIME=[4CB1C520:01C83B8F] X-Spam-Score: 2.0 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello, A result of doing the comparison between the requirements is that more specific requirements will be added to the CE draft. I will try to update it after New Year. So we now have two choices:=20 (1) consider it accepting it as the WG draft after I published -02 (somewhere in Jan); or (2) accepting it now so that I can publish it a draft-ietf-mext-...-00, meeting the Feb '08 milestone. /rgds /cwng On Mon, 2007-12-10 at 21:10 +0100, Carlos Jes=FAs Bernardos Cano wrote: > Hi all, >=20 > I also read the draft and provided some feedback while in Vancouver. My > main concerns are related with the fact that the requirements are very > general, and may apply to many other scenarios. IMHO, requirements' > document should be more concrete, especially concerning issues of > security. Currently, it might seem that the requirements from the > aeronautics and consumer industries are the same, and I still don't see > that so clear (I would think twice before taking a plane that has the > same security considerations for their communications that my PSP ;->). >=20 > Regards, >=20 > Carlos >=20 > El lun, 10-12-2007 a las 13:39 +0100, marcelo bagnulo braun escribi=F3: > > Hi all, > >=20 > > During the last MEXT meeting a candidate draft for our chartered item =20 > > on personal router requirement was presented. We wanted to ask if =20 > > this should be accepted as a WG item, but nobody has read it. > >=20 > > So we ask people to read the draft and provide review and comments, =20 > > in particular about accepting this work on the WG. > >=20 > > The draft can be found at: http://www.ietf.org/internet-drafts/draft-=20 > > ng-nemo-ce-req-01.txt > >=20 > > Thanks, marcelo > >=20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 11 04:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J21JV-0006LO-Sy; Tue, 11 Dec 2007 04:22:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J20Nv-00022A-DO for mext@ietf.org; Tue, 11 Dec 2007 03:22:35 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J20Nu-0006pU-QB for mext@ietf.org; Tue, 11 Dec 2007 03:22:35 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8FA9628000303; Tue, 11 Dec 2007 09:22:33 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzPX+vfcR1Vp; Tue, 11 Dec 2007 09:22:33 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6B91E28000302; Tue, 11 Dec 2007 09:22:18 +0100 (CET) Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 09:22:18 +0100 In-Reply-To: <475D74B2.8060201@cs.uni-goettingen.de> References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D74B2.8060201@cs.uni-goettingen.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <68B93B14-666A-4D42-8B53-23E1589F4D9C@netlab.nec.de> From: Martin Stiemerling Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Tue, 11 Dec 2007 09:22:19 +0100 To: Romain KUNTZ X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Dec 2007 08:22:18.0672 (UTC) FILETIME=[F1D66300:01C83BCE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Tue, 11 Dec 2007 04:22:05 -0500 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0938715860==" Errors-To: mext-bounces@ietf.org --===============0938715860== Content-Type: multipart/alternative; boundary=Apple-Mail-3-10807219 --Apple-Mail-3-10807219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, The NATFW NSLP indeed supports IPv6 and IPv4. Any specific reason, why come to the conclusion that IPv4 is supported only? Martin Am 10.12.2007 um 18:17 schrieb Xiaoming Fu: > Hi, > >>> NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) >> This would need to be adapted to IPv6 and its specificities (next >> header filed, flow label, etc.), so it might be better to define >> something from scratch. > > I don't think you're correct in spelling that draft-ietf-nsis-nslp- > natfw is only concerned with IPv4 filters. To my knowledge it > covers both IPv4 and IPv6 cases. CC-ing the draft editor (Martin > Stiemerling) for his additional information. > Xiaoming stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-3-10807219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

The NATFW NSLP = indeed supports IPv6 and IPv4.=A0

Any specific reason, why = come to the conclusion that IPv4 is supported only?

=A0=A0Martin

<= div>
Am 10.12.2007 um 18:17 schrieb Xiaoming Fu:

Hi,

NSIS (somewhere in = draft-ietf-nsis-nslp-natfw-16.txt)
This would need to be adapted to IPv6 and its = specificities (next header filed, flow label, etc.), so it might be = better to define something from scratch.

I don't = think you're correct in spelling that draft-ietf-nsis-nslp-natfw is only = concerned with IPv4 filters. To my knowledge it covers both IPv4 and = IPv6 cases. CC-ing the draft editor (Martin Stiemerling) for his = additional information.
stiemerling@netlab.nec.de

NEC Laboratories Europe - Network Research = Division

NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014
=

= --Apple-Mail-3-10807219-- --===============0938715860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0938715860==-- From mext-bounces@ietf.org Tue Dec 11 06:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23m4-0006xh-2d; Tue, 11 Dec 2007 06:59:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23m2-0006qn-JE for mext@ietf.org; Tue, 11 Dec 2007 06:59:42 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J23m1-0003he-Vv for mext@ietf.org; Tue, 11 Dec 2007 06:59:42 -0500 Received: from [163.117.139.66] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.66])by smtp03.uc3m.es (Postfix) with ESMTP id 8523E28C4BA; Tue, 11 Dec 2007 12:59:35 +0100 (CET) In-Reply-To: References: <9A2EA9E9-8EAC-4D3E-9A0D-58D5C3900B6F@bagnulo.net><0D090F1E0F553 6449C7E6527AFFA280A0537BD37@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <229EDBCD-570F-46DB-AFFD-69F04859746E@bagnulo.net> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] MEXT interim meeting poll Date: Tue, 11 Dec 2007 12:59:42 +0100 To: "Ivancic, William D. (GRC-RCN0)" X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.5836 TC:1F TRN:46 TV:5.0.1023(15598.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: julien.ietf@laposte.net, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ok, thanks let me know if Wes will be able to make it regards, marcelo El 10/12/2007, a las 20:24, Ivancic, William D. (GRC-RCN0) escribi=F3: > Marcelo, > > I just got notice today that I have to be at a NASA meeting (my =20 > funding > source) on Feb 5-7 in Florida. Thus, I probably cannot make those =20 > dates > unless I can find a suitable replacement. That is highly unlikely =20 > as I > am the Principle Investigator. > > > I will check with Wes Eddy regarding his availability and let you =20 > know. > > Worst case, I could setup a Webex easily for all to use. > > Also, I could setup a teleconference, but I don't have a toll free for > outside the US. So that is not very good. > > > /Will > > ****************************** > > >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@bagnulo.net] >>> Sent: Monday, December 10, 2007 6:48 AM >>> To: mext@ietf.org >>> Cc: Julien Laganier >>> Subject: [MEXT] MEXT interim meeting poll >>> >>> Hi, >>> >>> as we mentioned already, we are thinking of doing a MEXT interim >>> meeting. The information related to the proposed interim meeting is >>> the following: >>> >>> MEXT interim meeting >>> DATE: 7,8 feb 2007 >>> Location: Madrid, SPAIN >>> Goal of the meeting: the focus of the meeting would be the nemo ro >>> work and other considerations for nemo global deployment. >> However, it >>> would certainly be possible to extend to scope to other >> MEXT topics, >>> as long as there is enough people interested in discussing >> the other >>> topic that will attend the meeting. >>> >>> We are planning to make a decision on whether having the meeting or >>> not at the end of the week and obviously a key criteria for >> this would >>> be the people that would attend. So please, reply to me >> privately if >>> you are planning to attend before Friday 14 dec so we can take a >>> decision on this. >>> >>> Thanks, marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 11 07:13:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23zZ-0004HU-7P; Tue, 11 Dec 2007 07:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23zX-0004Fm-6W for mext@ietf.org; Tue, 11 Dec 2007 07:13:39 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J23zV-0006sC-EQ for mext@ietf.org; Tue, 11 Dec 2007 07:13:39 -0500 Received: from [163.117.139.66] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.66])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 2860928C7DD;Tue, 11 Dec 2007 13:13:31 +0100 (CET) In-Reply-To: <1197333954.6454.7.camel@localhost> References: <1197317433.5032.11.camel@localhost> <1197333954.6454.7.camel@localhost> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <88AE705F-B70E-41B6-A228-25980D11B5D8@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] Personal Mobile router reqs Date: Tue, 11 Dec 2007 13:13:37 +0100 To: chanwah.ng@sg.panasonic.com X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-26.6900 TC:1F TRN:39 TV:5.0.1023(15598.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.7 (-) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Chan-Wah, We will decide this based on the feedback we receive on the ml. It is =20= hard to accept a draft as wg item if very few people have read it. Regards, marcelo El 11/12/2007, a las 1:45, Chan-Wah Ng escribi=F3: > Hello, > > A result of doing the comparison between the requirements is that more > specific requirements will be added to the CE draft. I will try to > update it after New Year. So we now have two choices: > > (1) consider it accepting it as the WG draft after I published -02 > (somewhere in Jan); or > > (2) accepting it now so that I can publish it a draft-ietf-=20 > mext-...-00, > meeting the Feb '08 milestone. > > /rgds > /cwng > > On Mon, 2007-12-10 at 21:10 +0100, Carlos Jes=FAs Bernardos Cano = wrote: >> Hi all, >> >> I also read the draft and provided some feedback while in =20 >> Vancouver. My >> main concerns are related with the fact that the requirements are =20 >> very >> general, and may apply to many other scenarios. IMHO, requirements' >> document should be more concrete, especially concerning issues of >> security. Currently, it might seem that the requirements from the >> aeronautics and consumer industries are the same, and I still =20 >> don't see >> that so clear (I would think twice before taking a plane that has the >> same security considerations for their communications that my =20 >> PSP ;->). >> >> Regards, >> >> Carlos >> >> El lun, 10-12-2007 a las 13:39 +0100, marcelo bagnulo braun escribi=F3:= >>> Hi all, >>> >>> During the last MEXT meeting a candidate draft for our chartered =20 >>> item >>> on personal router requirement was presented. We wanted to ask if >>> this should be accepted as a WG item, but nobody has read it. >>> >>> So we ask people to read the draft and provide review and comments, >>> in particular about accepting this work on the WG. >>> >>> The draft can be found at: http://www.ietf.org/internet-drafts/=20 >>> draft- >>> ng-nemo-ce-req-01.txt >>> >>> Thanks, marcelo >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From DewaynelesseeMarquez@typepad.com Tue Dec 11 07:15:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J241l-0007XU-1g for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 07:15:57 -0500 Received: from [81.214.179.99] (helo=oem) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J241k-00042F-BQ for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 07:15:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host20581460.typepad.com (8.13.1/8.13.1) with SMTP id avCEjYki29.381564.d5v.knJ.4943492183803 for ; Tue, 11 Dec 2007 14:14:49 -0200 Message-ID: <0a0f01c83bef$8eaaf450$6401a8c0@oem> From: "Louie Acosta" To: Subject: Your order Date: Tue, 11 Dec 2007 14:14:49 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A0B_01C83BEF.8EAAF450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_0A0B_01C83BEF.8EAAF450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_0A0B_01C83BEF.8EAAF450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_0A0B_01C83BEF.8EAAF450-- From mext-bounces@ietf.org Tue Dec 11 08:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J253K-0000e4-J7; Tue, 11 Dec 2007 08:21:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J253J-0000dz-Or for mext@ietf.org; Tue, 11 Dec 2007 08:21:37 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J253J-0008A8-Dx for mext@ietf.org; Tue, 11 Dec 2007 08:21:37 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1193736nfb for ; Tue, 11 Dec 2007 05:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=g4AUrUFHdabsMksMk//cpBc6RmGZ0x3mM1xeBTKDjGc=; b=b9iP67cZY0qBDTFJxHuz5K2UlaVTsIi+QzX/xuEgm9SIkze3LpHwycB8oYtwDUmhSR3m+DoUUMtG3f+d+LqH5svK4AsbFTnal78bmyXcSOfP4zQg26bs4P/wMwyzZY+VPuv4YCvtXzOm6CtpxYehBqWhnSnfqYAOL0ZKWpt60qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ud088331LJfIP7plo4ozyxxeiDMveSaywDl07k8Qbac+wN2NOXIKilK8hlpp1ygIVnFq3pCp1tTOHBunU3VrCgcH5DrvYSBB2X8kaylXcr+upMRXZIO8zS8X1hPnpiM03kNF02b+e6to6sNsr2as6nZk/o8Omr1ZEh/w1XKAEfU= Received: by 10.86.100.7 with SMTP id x7mr6708219fgb.1197379296697; Tue, 11 Dec 2007 05:21:36 -0800 (PST) Received: by 10.86.35.18 with HTTP; Tue, 11 Dec 2007 05:21:36 -0800 (PST) Message-ID: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> Date: Tue, 11 Dec 2007 14:21:36 +0100 From: "Jean-Michel Combes" To: mext@ietf.org Subject: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 OLD TEXT: -- NEW TEXT: None Motivations: - Two proposals have been specified and adopted by the MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms for the split and the integrated scenario). - The present DHAAD mechanism is, more or less, a scanning tool allowing anyone to know what/where are the HAs owned by a Mobility Service Provider. - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols So, I wonder if it is still useful to keep the DHAAD mechanism in the MIPv6 specification. Comments are welcome. Best regards. JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Hesam108@szalma.com Tue Dec 11 12:40:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2967-0001zu-I9 for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 12:40:47 -0500 Received: from [88.247.232.247] (helo=dsl88-247-59639.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2966-00039u-Fp for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 12:40:47 -0500 Received: from EXPER ([170.161.150.17] helo=EXPER) by dsl88-247-59639.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1Dnpim-000NAW-sE for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 19:41:13 +0200 Message-ID: <8908E85A.D628B44B@szalma.com> Date: Tue, 11 Dec 2007 19:40:37 +0200 From: "Hesam Cooley" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: ottafsid Content-Type: multipart/alternative; boundary="------------030200060502050708080206" X-Spam-Score: 1.6 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab --------------030200060502050708080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Your prays to have big dick finally came true. Simply follow this method. http://ahyja.com/ --------------030200060502050708080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Your prays to have big dick finally came true. Simply follow this
method. http://ahyja.com/
--------------030200060502050708080206-- From JeannesocieteNix@gfoa.org Tue Dec 11 12:56:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29L4-0001uC-IR for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 12:56:14 -0500 Received: from [190.65.208.179] (helo=equipouno) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J29L4-0003ZD-7a for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 12:56:14 -0500 Received: from grape by gfoa.org with SMTP id yMgNs25n4b for ; Tue, 11 Dec 2007 12:54:45 +0500 From: "Alma Zuniga" To: Subject: Relax and have fun with roulette Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We have it all! Win $$$ instead of throwing it all away at other casinos. How about the best service around? We have it all! http://eurocasinoah.com/ From AvahaspDow@atimes.com Tue Dec 11 17:34:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Dg5-00026F-FL for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 17:34:13 -0500 Received: from 81.203.8.254.dyn.user.ono.com ([81.203.8.254] helo=esapaca5ef38f1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2Dg4-0002lR-SP for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 17:34:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host90006386.atimes.com (8.13.1/8.13.1) with SMTP id ALZwHKiI82.099443.X1I.8rT.5884188856790 for ; Tue, 11 Dec 2007 23:32:46 -0100 Message-ID: <15d2d01c83c45$f62f3cc0$fe08cb51@esapaca5ef38f1> From: "Dona Neff" To: Subject: Your order approved Date: Tue, 11 Dec 2007 23:32:46 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_15D29_01C83C45.F62F3CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Antivirus: avast! (VPS 071210-0, 10/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_15D29_01C83C45.F62F3CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_15D29_01C83C45.F62F3CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_15D29_01C83C45.F62F3CC0-- From mext-bounces@ietf.org Tue Dec 11 23:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2JOZ-0005zd-Fd; Tue, 11 Dec 2007 23:40:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2JOY-0005zX-SU for mext@ietf.org; Tue, 11 Dec 2007 23:40:30 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2JOY-000542-Jt for mext@ietf.org; Tue, 11 Dec 2007 23:40:30 -0500 Received: by rv-out-0910.google.com with SMTP id l15so67444rvb.49 for ; Tue, 11 Dec 2007 20:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=sCIZdJx28OE4S3WGfDooILcF5E9Tfy/zdDYmltyfoAw=; b=MYMZ9tjEzvooGZBhQshV1pVX4ovnMKWoh0pYdOKrIZ0/8WgXzGr0isnjUXWLjmxqVRde/dfQJvGQFXPDgQAWAnjfwNYd4yEZVCx1NxDQxHlL8KR3u1/CMr7I27cez4OwYBdvTp4iukRsI2903nRWbJ/Hkr2gtVkbtGEgrCq/Fl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=N7QT52Ismy3qKWfhK3F4kYt+dwo07PYiKhVQnjlZIguhaa7c/ny4Veykbq1wAxRIZJrkF7Q9+qgO4ZQ54dBny8dRm5zM057E65vCP9Z4IXwA3IE/s5gCykx5MCOkptMA2p8aJi8do+kUTBn9rAbbsSCRPMQy0Tk2VIvR7IgHuKg= Received: by 10.141.209.9 with SMTP id l9mr89136rvq.288.1197434429392; Tue, 11 Dec 2007 20:40:29 -0800 (PST) Received: by 10.141.180.1 with HTTP; Tue, 11 Dec 2007 20:40:29 -0800 (PST) Message-ID: <1d38a3350712112040h159c0001r41c054c9e9a10e75@mail.gmail.com> Date: Wed, 12 Dec 2007 12:40:29 +0800 From: "Hui Deng" To: mext@ietf.org Subject: [MEXT] Re: Mext Diameter PD PS Presentation MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org could be a alternative way to do PD. -Hui Hello Folks, Due to some carambolage, this draft could not be presented. We already received a number of opinions on Diameter Prefix Delegation idea, and we appreciate them all. If you have comments on the draft, please feel free to post them on mext mailiing list. You could as well cc it to dime. Regards, Behcet _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LouiebespectacledHodge@reuters.com Tue Dec 11 23:55:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Jcr-0004Q3-Nj for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 23:55:17 -0500 Received: from pool-72-78-111-24.phlapa.fios.verizon.net ([72.78.111.24] helo=distefano.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2Jcr-0004o6-GH for nemo-archive@lists.ietf.org; Tue, 11 Dec 2007 23:55:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host03295060.reuters.com (8.13.1/8.13.1) with SMTP id 0bmo3Y8701.224083.MLZ.Q3v.1403902218809 for ; Tue, 11 Dec 2007 23:54:39 +0500 Message-ID: <1425a801c83c7b$2ee03a30$0201a8c0@distefano> From: "Emmanuel Chase" To: Subject: Confirmation link Date: Tue, 11 Dec 2007 23:54:39 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1425A4_01C83C7B.2EE03A30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_1425A4_01C83C7B.2EE03A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_1425A4_01C83C7B.2EE03A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1425A4_01C83C7B.2EE03A30-- From mext-bounces@ietf.org Wed Dec 12 03:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2N4n-0002u3-0F; Wed, 12 Dec 2007 03:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2N4k-0002tv-G0 for mext@ietf.org; Wed, 12 Dec 2007 03:36:18 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2N4i-0000Sy-OQ for mext@ietf.org; Wed, 12 Dec 2007 03:36:18 -0500 Received: by rv-out-0910.google.com with SMTP id l15so119843rvb.49 for ; Wed, 12 Dec 2007 00:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=SswMFaGVgEoVq9snKtX3jgbMYWo1yMpux5SAuUosueE=; b=qyRIQQ/SZvZ5O84KXwkQbMtqbKzMLDd8gxc9FHXpyS8Bwqig3fVDmsZeTkP4dhnvnFysJ9HiWyF/OCSwo6rfPshebIucz7A+ZdHbpp8QijJeN9CRqnb1m0PXwPCfKJB8nx5IIY0JU/NzAyN+rk+IBWJNPFmUFdDbI/kWgIU6i9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=T6w2CBYIg4RBTKYA8XcDZcixIc5aZnUV26iHIzuJDR8RVv4W20UCrbc5g/357p+JqErKXxp3baaRE44a3hsiMyVbJxZvJShIs2juWX3yrI5ry57cPs2KKVt7dCqw+UEUN8hYTDLObKdfl2miozCV0vq6hTy5VBZgKABq+TIecRk= Received: by 10.140.133.16 with SMTP id g16mr160500rvd.231.1197448575725; Wed, 12 Dec 2007 00:36:15 -0800 (PST) Received: from ?10.0.1.198? ( [219.110.221.232]) by mx.google.com with ESMTPS id b21sm2439753rvf.2007.12.12.00.36.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2007 00:36:14 -0800 (PST) From: RYUJI WAKIKAWA To: marcelo bagnulo braun In-Reply-To: <1D00A7E9-2FF3-4F45-B710-373B5EE06636@it.uc3m.es> Subject: Re: [MEXT] next steps with draft-ietf-monami6-multiplecoa-04 References: <1D00A7E9-2FF3-4F45-B710-373B5EE06636@it.uc3m.es> Message-Id: <7D5E092E-E94D-4A79-86EB-23A5DAA2E5F1@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 12 Dec 2007 17:36:10 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, On 2007/12/10, at 4:44, marcelo bagnulo braun wrote: > Hi, > > the deadline for this document is > Dec 2007 Submit Multiple CoA Registration to IESG > > so we really need to work these things out fast > > At the mext meeting draft-ietf-monami6-multiplecoa-04 was discussed > > There were a set of issues presented and the following was the > feeling of the room. > > - With respect for DSMIP support, people felt that this was to be > supported. > The next steps for this are: if people in the ml feel otherwise, > please speak up in the next couple of days, if not we assume that > the consensus of the meeting holds > The editor will address this issue for the next revision of the > document OK. > - With respect to bulk registration at the CN, the feeling of the > room was that we don't need to address this issue. Again, if someone > feels different speak up in a couple of days, or we will assume that > the consensus in the room holds > > - with respect to the threat described in draft-lim-mext-multiple- > coa-verify-00, the feeling of the room was that we need to take this > into account, so we need to address this threat. Again, if someone > feel otherwise, please speak up in a couple of days. To proceed with > these, we request the authors or other parties to provide text for > the draft and propose it to the ML > > - With respect to the case of multihoming with a visited network and > the home network, there was no clear consesus on the meeting but it > seemed that there was more support for supporting this case. I have > reached the same conclusion after reading the mailing list. So the > next steps for this are that the author or other partis to provide > text for this and propose it to the ml. I will provide texts for above two at this weekend or the beginning of next week. thanks ryuji > I would request people and in particular the auhtor to provide text > in about one week time, since our deadline is approaching really > fast and we should be able to deal with these last issues fast, so > we can issue a new short WGLC as with the other docuemnts. > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 12 04:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NiF-0000Ag-9I; Wed, 12 Dec 2007 04:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2NiD-0000AY-UF for mext@ietf.org; Wed, 12 Dec 2007 04:17:05 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2NiB-00022u-Ir for mext@ietf.org; Wed, 12 Dec 2007 04:17:05 -0500 Received: (qmail 20752 invoked for bounce); 12 Dec 2007 09:17:02 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 12 Dec 2007 09:17:02 -0000 Message-Id: From: Romain KUNTZ To: Martin Stiemerling In-Reply-To: <68B93B14-666A-4D42-8B53-23E1589F4D9C@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Wed, 12 Dec 2007 10:17:01 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D74B2.8060201@cs.uni-goettingen.de> <68B93B14-666A-4D42-8B53-23E1589F4D9C@netlab.nec.de> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Martin, On 2007/12/11, at 9:22, Martin Stiemerling wrote: > The NATFW NSLP indeed supports IPv6 and IPv4. > > Any specific reason, why come to the conclusion that IPv4 is > supported only? Sorry for the confusion, I misread the draft. So if I understand correctly, IPv6 filter rules could be described with a MRI (as defined in draft-ietf-nsis-ntlp-14)? romain > Am 10.12.2007 um 18:17 schrieb Xiaoming Fu: > >> Hi, >> >>>> NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) >>> This would need to be adapted to IPv6 and its specificities (next >>> header filed, flow label, etc.), so it might be better to define >>> something from scratch. >> >> I don't think you're correct in spelling that draft-ietf-nsis-nslp- >> natfw is only concerned with IPv4 filters. To my knowledge it >> covers both IPv4 and IPv6 cases. CC-ing the draft editor (Martin >> Stiemerling) for his additional information. >> Xiaoming > > stiemerling@netlab.nec.de > > NEC Laboratories Europe - Network Research Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From WayRibordy@ethos.wustl.edu Wed Dec 12 05:12:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2OZP-0000Cx-2n for nemo-archive@lists.ietf.org; Wed, 12 Dec 2007 05:12:03 -0500 Received: from host160-80-static.53-88-b.business.telecomitalia.it ([88.53.80.160]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2OZO-0003PC-Gd for nemo-archive@lists.ietf.org; Wed, 12 Dec 2007 05:12:02 -0500 Received: from assistente3 ([129.116.91.97] helo=assistente3) by host160-80-static.53-88-b.business.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZIBkS-000LHI-sd for nemo-archive@lists.ietf.org; Wed, 12 Dec 2007 11:12:33 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Dec 2007 11:12:13 +0100 To: nemo-archive@lists.ietf.org From: "Way Ribordy" Subject: gnidetse Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Don't be fooled by low quality watch replicas made from countries with cheap watch movement http://twistbg.com/ From mext-bounces@ietf.org Wed Dec 12 07:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2QjC-0007Gs-3X; Wed, 12 Dec 2007 07:30:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Qj9-0007GV-Tu for mext@ietf.org; Wed, 12 Dec 2007 07:30:15 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Qj9-0000Rr-59 for mext@ietf.org; Wed, 12 Dec 2007 07:30:15 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7587428000350; Wed, 12 Dec 2007 13:30:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZmH3mSryVJe; Wed, 12 Dec 2007 13:30:14 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5066528000304; Wed, 12 Dec 2007 13:29:59 +0100 (CET) Received: from [10.1.1.109] ([10.1.1.109]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Dec 2007 13:29:59 +0100 In-Reply-To: References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D74B2.8060201@cs.uni-goettingen.de> <68B93B14-666A-4D42-8B53-23E1589F4D9C@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <883479A2-3415-464A-BD98-87FA27AB496E@netlab.nec.de> From: Martin Stiemerling Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Wed, 12 Dec 2007 13:29:59 +0100 To: Romain KUNTZ X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Dec 2007 12:29:59.0258 (UTC) FILETIME=[B5D99BA0:01C83CBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1140017017==" Errors-To: mext-bounces@ietf.org --===============1140017017== Content-Type: multipart/alternative; boundary=Apple-Mail-18-112067704 --Apple-Mail-18-112067704 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Romain, Am 12.12.2007 um 10:17 schrieb Romain KUNTZ: > Hi Martin, > > On 2007/12/11, at 9:22, Martin Stiemerling wrote: > > The NATFW NSLP indeed supports IPv6 and IPv4. > > > > Any specific reason, why come to the conclusion that IPv4 is > > supported only? > > Sorry for the confusion, I misread the draft. So if I understand > correctly, IPv6 filter rules could be described with a MRI (as defined > in draft-ietf-nsis-ntlp-14)? > Yes, that is right. You can signal any rule that is can be basically expressed with the MRI. Furthermore, there are a few extension to this in the NATFW NSLP, e.g., whether it is rule for allowing or denying flows. Martin > > > romain > > > Am 10.12.2007 um 18:17 schrieb Xiaoming Fu: > > > >> Hi, > >> > >>>> NSIS (somewhere in draft-ietf-nsis-nslp-natfw-16.txt) > >>> This would need to be adapted to IPv6 and its specificities (next > >>> header filed, flow label, etc.), so it might be better to define > >>> something from scratch. > >> > >> I don't think you're correct in spelling that draft-ietf-nsis-nslp- > >> natfw is only concerned with IPv4 filters. To my knowledge it > >> covers both IPv4 and IPv6 cases. CC-ing the draft editor (Martin > >> Stiemerling) for his additional information. > >> Xiaoming > > > > stiemerling@netlab.nec.de > > > > NEC Laboratories Europe - Network Research Division > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > stiemerling@netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-18-112067704 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Romain,=A0

Am 12.12.2007 um 10:17 schrieb Romain = KUNTZ:

Hi Martin,

On 2007/12/11, at 9:22, Martin = Stiemerling wrote:
> The NATFW NSLP indeed supports IPv6 and = IPv4.
>
> Any specific reason, why come to the conclusion = that IPv4 is=A0
> supported only?

Sorry for the = confusion, I misread the draft. So if I understand=A0
correctly, = IPv6 filter rules could be described with a MRI (as defined=A0
in = draft-ietf-nsis-ntlp-14)?

Yes, that = is=A0right. You can signal any rule that is can be basically expressed = with the MRI. Furthermore, there are a few extension to this in the = NATFW NSLP, e.g., whether it is rule for allowing or denying = flows.=A0

=A0=A0Martin



romain

> = Am 10.12.2007 um 18:17 schrieb Xiaoming Fu:
>
>> = Hi,
>>
>>>> NSIS (somewhere in = draft-ietf-nsis-nslp-natfw-16.txt)
>>> This would need to = be adapted to IPv6 and its specificities (next=A0
>>> = header filed, flow label, etc.), so it might be better to define=A0
= >>> something from scratch.
>>
>> I don't = think you're correct in spelling that draft-ietf-nsis-nslp-
>> = natfw is only concerned with IPv4 filters. To my knowledge it=A0
= >> covers both IPv4 and IPv6 cases. CC-ing the draft editor = (Martin=A0
>> Stiemerling) for his additional information.
= >> Xiaoming
>
> stiemerling@netlab.nec.de >
> NEC Laboratories Europe - Network Research Division
= >
> NEC Europe Limited | Registered Office: NEC House, 1 = Victoria Road,=A0
> London W3 6BL | Registered in England = 2832014
>


=
stiemerling@netlab.nec.de

NEC Laboratories Europe - Network Research = Division

NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014
=

= --Apple-Mail-18-112067704-- --===============1140017017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1140017017==-- From mext-bounces@ietf.org Wed Dec 12 09:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SOe-0004b7-F5; Wed, 12 Dec 2007 09:17:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2SOd-0004as-Qx for mext@ietf.org; Wed, 12 Dec 2007 09:17:11 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2SOd-0005EO-7U for mext@ietf.org; Wed, 12 Dec 2007 09:17:11 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1197469029!6177624!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15869 invoked from network); 12 Dec 2007 14:17:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 12 Dec 2007 14:17:09 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBCEH7Rn006518 for ; Wed, 12 Dec 2007 07:17:09 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lBCEH7mI000050 for ; Wed, 12 Dec 2007 08:17:07 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lBCEH6U1000039 for ; Wed, 12 Dec 2007 08:17:06 -0600 (CST) Message-ID: <475FED61.2060606@gmail.com> Date: Wed, 12 Dec 2007 15:17:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071210-0, 10/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Section 4, subsection 4.2, 5th and 6th paragraphs. OLD TEXT: > Binding Refresh Request > > A Binding Refresh Request is used by a correspondent node to > request a mobile node to re-establish its binding with the > correspondent node. This message is typically used when the > cached binding is in active use but the binding's lifetime is > close to expiration. The correspondent node may use, for > instance, recent traffic and open transport layer connections as > an indication of active use. > > Binding Error > > The Binding Error is used by the correspondent node to signal an > error related to mobility, such as an inappropriate attempt to use > the Home Address destination option without an existing binding. NEW TEXT: > Binding Refresh Request > > A Binding Refresh Request is used by a correspondent node or the home agent to > request a mobile node to re-establish its binding with the > correspondent node. This message is typically used when the > cached binding is in active use but the binding's lifetime is > close to expiration. The correspondent node or the home agent may use, for > instance, recent traffic and open transport layer connections as > an indication of active use. > > Binding Error > > The Binding Error is used by the correspondent node or the home agent to signal an > error related to mobility, such as an inappropriate attempt to use > the Home Address destination option without an existing binding. > Even though RFC3775 states at some point that a CN can be a HA, it is unclear when implementing whether a HA should implement sending BRR or BErr to the MN or not. Some people have implemented this as yes, HA should send BErr and BRR to MN. This has been discussed in the past on the mip6 mailing list. Note that the disambiguation proposed above may be needed in some other parts of the document as well. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 12 10:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T7m-0003x5-6P; Wed, 12 Dec 2007 10:03:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2T7k-0003wt-Tm for mext@ietf.org; Wed, 12 Dec 2007 10:03:48 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2T7k-0006S9-9d for mext@ietf.org; Wed, 12 Dec 2007 10:03:48 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1197471826!6185017!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 4193 invoked from network); 12 Dec 2007 15:03:46 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-153.messagelabs.com with SMTP; 12 Dec 2007 15:03:46 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lBCF3kpQ004364; Wed, 12 Dec 2007 08:03:46 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lBCF3jCU010511; Wed, 12 Dec 2007 09:03:46 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lBCF3iko010474; Wed, 12 Dec 2007 09:03:44 -0600 (CST) Message-ID: <475FF84F.7000802@gmail.com> Date: Wed, 12 Dec 2007 16:03:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> In-Reply-To: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071210-0, 10/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi, > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > 11.4.1 > > OLD TEXT: -- > > NEW TEXT: None > > Motivations: - Two proposals have been specified and adopted by the > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > for the split and the integrated scenario). - The present DHAAD > mechanism is, more or less, a scanning tool allowing anyone to know > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > DHAAD has not a critical use in others MIPv6 based protocols > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > MIPv6 specification. > > Comments are welcome. I support keeping DHAAD in the current spec. If necessary, I can suggest new clarifying text saying that DHAAD used in conjunction with MPD and a proper IPsec SA setting leads to effective HA address and Home Address bootstrapping on MN while at home and while away from home. Alex > > Best regards. > > JMC. > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 12 10:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TIG-0005K8-Uo; Wed, 12 Dec 2007 10:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2TIF-0005Jt-3D for mext@ietf.org; Wed, 12 Dec 2007 10:14:39 -0500 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2TIE-00074y-SC for mext@ietf.org; Wed, 12 Dec 2007 10:14:39 -0500 Received: by an-out-0708.google.com with SMTP id d11so70651and.122 for ; Wed, 12 Dec 2007 07:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=TBLW31BoMJEBU3MUuzQzdsbUtpGkOXrbunrT8K5yoOo=; b=qwGlXr0l3X4M5IZXNn9yhf//4sCYI4DK83CcBCQmmQQDrcXOlhs7vcNqqi8r4xjdqE3I2FjpxU+VoRWNvWTJ8z12JBygqj2a31EgsDzW4vIWMGrxjdieYRK/Hvv5LSrt8a8pYVqawZpvvtfV8lHUg5CLXR6MKCt4NlbdZzinqBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=EebT6HG+4ZXafqEYXjr0NZVOJOekHjwn97owtqhADjU8X87bGfhOHFluIheGplR+S/LcmTy5QbpjdBRq9mq72kz3BuYiw3s3hcENjnMMQItjZwJKR1Pw76Qje2KzDw3VZgnMaS3Ak5PIzgNiTiP6QDHcxgLcPg6m6OPZwtxA2ms= Received: by 10.100.57.6 with SMTP id f6mr1656140ana.78.1197472478122; Wed, 12 Dec 2007 07:14:38 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f6sm115831nfh.2007.12.12.07.14.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2007 07:14:37 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Wed, 12 Dec 2007 16:14:37 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712121614.39016.julien.IETF@laposte.net> X-Spam-Score: 2.2 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [MEXT] Minutes of MEXT sessions at IETF-70 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, Minutes of the meeting are available there: Please send to chairs corrections and/or add-ons, if any. Thanks. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 12 11:19:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UIX-0002e0-3G; Wed, 12 Dec 2007 11:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2UIV-0002dv-T4 for mext@ietf.org; Wed, 12 Dec 2007 11:18:59 -0500 Received: from g5t0009.atlanta.hp.com ([15.192.0.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2UIU-00018s-KO for mext@ietf.org; Wed, 12 Dec 2007 11:18:59 -0500 Received: from g5t0009.atlanta.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 4B9093029C; Wed, 12 Dec 2007 16:18:58 +0000 (UTC) Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by g5t0009.atlanta.hp.com (Postfix) with ESMTP id 32A98301F2; Wed, 12 Dec 2007 16:18:58 +0000 (UTC) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 72C0D1DE20D; Wed, 12 Dec 2007 16:18:57 +0000 (UTC) Message-ID: <476009EF.8030802@hp.com> Date: Wed, 12 Dec 2007 11:18:55 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN References: <475FED61.2060606@gmail.com> In-Reply-To: <475FED61.2060606@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Alex, Alexandru Petrescu wrote: > NEW TEXT: >> Binding Refresh Request >> >> A Binding Refresh Request is used by a correspondent node or the >> home agent to >> request a mobile node to re-establish its binding with the >> correspondent node. This message is typically used when the >> cached binding is in active use but the binding's lifetime is >> close to expiration. The correspondent node or the home agent >> may use, for >> instance, recent traffic and open transport layer connections as >> an indication of active use. You missed one CN -> CN or HA at the end of the first sentence, I think changing it to "it" is fine: Binding Refresh Request A Binding Refresh Request is used by a correspondent node or home agent to request a mobile node to re-establish its binding with it. This message is typically used when the cached binding is in active use but the binding's lifetime is close to expiration The correspondent node or the home agent may use, for instance, recent traffic and open transport layer connections as an indication of active use. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LesatiEarly@negotiation.com Wed Dec 12 12:16:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2VBq-0000pW-UM for nemo-archive@lists.ietf.org; Wed, 12 Dec 2007 12:16:10 -0500 Received: from cpc1-leed3-0-0-cust170.leed.cable.ntl.com ([81.104.188.171] helo=privateyuwugmh) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2VBo-0002ty-Kg for nemo-archive@lists.ietf.org; Wed, 12 Dec 2007 12:16:08 -0500 Received: from cation by negotiation.com with SMTP id fwXG0wDZJd for ; Wed, 12 Dec 2007 17:15:42 +0000 From: "Lesa Koehler" To: Subject: Get your bonus and walk the red carpet to winnings and fun. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de If you're in the US or anywhere else, join your new casino paradise. Come find out. If you're in the US or anywhere else, join your new casino paradise. Travel no further than your screen and get your free $999 http://eurocasinoag.com/ From pete@united-connect.com Wed Dec 12 13:26:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2WI0-0006hX-Qs; Wed, 12 Dec 2007 13:26:36 -0500 Received: from 178-165-20-190.adsl.terra.cl ([190.20.165.178] helo=themachine) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2WHx-0005rr-V6; Wed, 12 Dec 2007 13:26:36 -0500 Received: from [190.20.165.178] by mail.united-connect.com; Wed, 12 Dec 2007 14:30:26 -0400 Message-ID: <01c83ccb$8952ed00$b2a514be@pete> From: "pCrawford" To: Subject: Hey Sexy Date: Wed, 12 Dec 2007 14:30:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 X-Spam-Score: 2.2 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Hey Sexy I saw your profile online Maybe we can chat today? email me at Egg@GloryLandUsa.info and I will reply with a Picture and info right away. From mext-bounces@ietf.org Wed Dec 12 21:39:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2dz3-0006qR-0D; Wed, 12 Dec 2007 21:39:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2dz0-0006qL-Tj for mext@ietf.org; Wed, 12 Dec 2007 21:39:30 -0500 Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2dz0-0005QO-8a for mext@ietf.org; Wed, 12 Dec 2007 21:39:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.11) with ESMTP id lBD2dSGk002613; Thu, 13 Dec 2007 03:39:28 +0100 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id lBD2dO9Q002603; Thu, 13 Dec 2007 03:39:26 +0100 Received: from localhost (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.1/8.13.1/2006.06.07) with ESMTP id lBD2dNGN030150; Thu, 13 Dec 2007 03:39:23 +0100 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.enst-bretagne.fr (Horde MIME library) with HTTP; Thu, 13 Dec 2007 03:39:23 +0100 Message-ID: <20071213033923.rdoyh463kk0wcw0c@webmail.enst-bretagne.fr> Date: Thu, 13 Dec 2007 03:39:23 +0100 From: priyanka.rawat@enst-bretagne.fr To: mext@ietf.org Subject: Re: [MEXT] New items for the mext charter discussion References: <47575AC5.1090401@inria.fr> In-Reply-To: <47575AC5.1090401@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello All I noticed that there are some discussions going on on MEXT list on ROHC compression in NEMO. As Thierry has mentioned already, we are working on the same subject. Infact, we are working on a general solution to reduce tunnel overhead =20 in various tunneling scenarios including NEMO tunnel. We use ROHC in =20 conjunction with TuCP, a new tunneling compression protocol to =20 compress the tunnel headers . This is an old draft but we will soon update it with implementation updates. We suggested the use of ROHC in NEMO in draft-minaburo-rohc-nemo-01.txt One of the problems with ROHC is, it is defined for point to point ordered links. Another point is rohc context transfer, although there are some =20 studies on header compression context transfer, as far as I know there =20 are none specifically on rohc context transfer and we are looking at =20 this (rohc context transfer between MR and HA). If you are interested, I will provide you the links to the articles =20 published on this study. It would be good to have a feedback from MEXT on this work. Regards Priyanka Quoting Thierry Ernst : > > A paper about ROHC with NEMO was published at WONEMO 2007 and another > one about ROHC in nested NEMO this year at ICLAN 2007. Also > draft-minaburo-rohc-nemo.txt (expired) > > See http://www.rennes.enst-bretagne.fr/~prawat/ > > Thierry > > > > Wassim Haddad wrote: >> Hi Vidya, >> >> Just to add one thing: >> >> ROHC is deployed *only* in particular networks and in these =20 >> networks when you switch between BS, ROHC has to "reboot". So for =20 >> mobility protocols in >> general (including the RO mode), this proposal is much more efficient. >> >> >> Regards, >> >> Wassim H. >> >> >> >> On Wed, 5 Dec 2007, Narayanan, Vidya wrote: >>> >>> Hi Hesham, >>> >>>> >>>> =3D> ROHC has several limitations. One of them is that it works >>>> on p2p links. >>>> Another is it's complexity of course. This solution is >>>> independent of the link layer, which is good. Even when >>>> combined with ROHC it can easily address the triple header scenarios. >>>> >>> >>> Okay, I'm speaking prematurely, since I haven't looked at the draft yet >>> :) I was trying to understand where we see the use. Even from the p2p >>> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP >>> tunnel is a virtual p2p link. That is philosophy behind the ongoing >>> work on ROHC for IPsec. But, I'll take a look at the draft first (I >>> assume there is one :)). >>> >>> Vidya >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 03:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2juK-0000Eu-B1; Thu, 13 Dec 2007 03:59:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2juI-0000Bf-8x for mext@ietf.org; Thu, 13 Dec 2007 03:59:02 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2juH-0003DD-OW for mext@ietf.org; Thu, 13 Dec 2007 03:59:02 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 507FE28000350; Thu, 13 Dec 2007 09:59:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7EHZ9drHyJY; Thu, 13 Dec 2007 09:59:01 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3CD1328000302; Thu, 13 Dec 2007 09:58:51 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] Comments on draft-ng-nemo-ce-req-01 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Thu, 13 Dec 2007 09:58:51 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF392224@mx1.office> In-reply-to: <47583E0F.2010605@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Comments on draft-ng-nemo-ce-req-01 Thread-Index: Acg4NUZsQFZ5JIL/RVyLBx4+IhVnbwDnekUg From: "Roberto Baldessari" To: "Thierry Ernst" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, > > What do you mean by "general case"? As in for Avionics,=20 > Car, and CE=20 > > industries? If so, then there is a big difference. Most use cases=20 > > indicates a strong need for MR-to-MR optimization in CE,=20 > whereas not=20 > > so in avionics. For car industry, as Thierry pointed out,=20 > the c2ccc=20 > > has defined their own layer 2 manet-like route optimization for=20 > > car-to-car communications. So, they have zero needs for=20 > MR-to-MR optimization. >=20 > This is wrong ChanWah, I didn't say that and if it was=20 > interpreted as such I didn't express me clearly. >=20 > I said there is: >=20 > - 1: a need for direct MR-MR communication (over a direct=20 > wireless link when vehicles are in short range) but I didn't=20 > say layer 2, though this is what the C2C-CC is looking at for=20 > safety applications and no, Carlos they do have a solution.=20 > The requirements is a document for the IETF to focus its=20 > work. But the C2C-CC vision is not the only one in the car=20 > industry and for non-safety application it's not a L2 solution. >=20 > - 2: a need for MR-MR communication via the access network:=20 > for instance > when vehicles are not in the same communication range over=20 > a physical medium. It is clearly not acceptable to have such=20 > communication going through the HA (or 2 HAs if they don't=20 > have the same). >=20 >=20 > Thierry I agree that these are 2 separeted issues and somehow complementary: 1) MR-to-MR when no infrastructure is available: this is out of scope of = MEXT WG. C2C-CC considers a sub-IP approach for that since C2C-CC = already has sub-IP routing. But C2C-CC is not the only automotive = consortium. I expect others to need signaling at IP layer (which should = probably come from another WG) 2) MR-to-MR when infrastructure is available: this is what RO = requirements are for=20 How 2 solutions for these 2 issues coexist and complement each other is = deployment-specific and again out of scope of this WG. I think the = discussion here should only focus on 2). The description of the sub-IP = approach in the c2c draft is only to describe the deployment scenario = and clarify that C2C-CC needs RO, not ad hoc routing.=20 Best regards, Roberto _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 07:41:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nNc-0006fo-7y; Thu, 13 Dec 2007 07:41:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nNb-0006c0-Mk for mext@ietf.org; Thu, 13 Dec 2007 07:41:31 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2nNb-00028o-5s for mext@ietf.org; Thu, 13 Dec 2007 07:41:31 -0500 Received: (qmail 6137 invoked for bounce); 13 Dec 2007 12:41:29 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 13 Dec 2007 12:41:29 -0000 Message-Id: From: Romain KUNTZ To: Martin Stiemerling In-Reply-To: <883479A2-3415-464A-BD98-87FA27AB496E@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Thu, 13 Dec 2007 13:41:29 +0100 References: <60E12A29-9221-4C3A-A4B6-22C1BEC3A02A@it.uc3m.es> <007f01c8300a$ee331330$ca993990$@nl> <474A8DE7.5030203@gmx.net> <008601c83032$4e95b030$ebc11090$@nl> <474BD865.7000701@gmx.net> <002101c830d7$89fbc6a0$9df353e0$@nl> <004501c835d9$40f0fe10$c2d2fa30$@nl> <761103C8-7EC6-40A1-976E-0BFB82F3D7EA@clarinet.u-strasbg.fr> <008f01c83793$65e92ec0$31bb8c40$@nl> <77742EED-3660-4489-BB6F-F7828407BFB9@clarinet.u-strasbg.fr> <475D74B2.8060201@cs.uni-goettingen.de> <68B93B14-666A-4D42-8B53-23E1589F4D9C@netlab.nec.de> <883479A2-3415-464A-BD98-87FA27AB496E@netlab.nec.de> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Martin, On 2007/12/12, at 13:29, Martin Stiemerling wrote: >> Sorry for the confusion, I misread the draft. So if I understand >> correctly, IPv6 filter rules could be described with a MRI (as >> defined >> in draft-ietf-nsis-ntlp-14)? >> > Yes, that is right. You can signal any rule that is can be basically > expressed with the MRI. Furthermore, there are a few extension to > this in the NATFW NSLP, e.g., whether it is rule for allowing or > denying flows. I guess you refer to the Extended Flow Information Object. Not only we would like to allow/deny a flow, but we'd like also to specify a tunnel identifier for a specific flow. That may require to define a new object. -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 07:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nc3-0006Wr-2Q; Thu, 13 Dec 2007 07:56:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2nc2-0006We-8r for mext@ietf.org; Thu, 13 Dec 2007 07:56:26 -0500 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2nc1-0002Qs-OO for mext@ietf.org; Thu, 13 Dec 2007 07:56:26 -0500 Received: from oaamta08sl.mx.bigpond.com ([124.190.105.201]) by omta04sl.mx.bigpond.com with ESMTP id <20071213125622.TLWQ6742.omta04sl.mx.bigpond.com@oaamta08sl.mx.bigpond.com> for ; Thu, 13 Dec 2007 12:56:22 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta08sl.mx.bigpond.com with ESMTP id <20071213125621.WBAP6288.oaamta08sl.mx.bigpond.com@PC20005>; Thu, 13 Dec 2007 12:56:21 +0000 From: "Hesham Soliman" To: "'Romain KUNTZ'" , "'Martin Stiemerling'" Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Thu, 13 Dec 2007 23:56:09 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg9he3S5HSMp38jT5WfrJyuztAC1AACda2Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > On 2007/12/12, at 13:29, Martin Stiemerling wrote: > >> Sorry for the confusion, I misread the draft. So if I understand > >> correctly, IPv6 filter rules could be described with a MRI (as > >> defined > >> in draft-ietf-nsis-ntlp-14)? > >> > > Yes, that is right. You can signal any rule that is can be > basically > > expressed with the MRI. Furthermore, there are a few extension to > > this in the NATFW NSLP, e.g., whether it is rule for allowing or > > denying flows. > > I guess you refer to the Extended Flow Information Object. > Not only we > would like to allow/deny a flow, but we'd like also to specify a > tunnel identifier for a specific flow. That may require to define a > new object. => But the tunnel identifier is already known from the BU. So all you need to do is to describe the flow, nothing else is needed AFAICS. Hesham > > -- > Romain KUNTZ > kuntz@lsiit.u-strasbg.fr > Louis Pasteur University - Networks and Protocols Team > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From PercyconsumptionMassey@mmbrace.com Thu Dec 13 08:52:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2oUT-0003sf-Ti; Thu, 13 Dec 2007 08:52:41 -0500 Received: from [189.140.37.71] (helo=malena) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2oUS-00044E-SQ; Thu, 13 Dec 2007 08:52:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01849942.mmbrace.com (8.13.1/8.13.1) with SMTP id D2t4Yf4S85.499686.pEI.8S7.4407439510317 for ; Thu, 13 Dec 2007 07:51:56 +0600 Message-ID: <943a01c83d8f$652dd7e0$5a01a8c0@malena> From: "Darrin Abbott" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_9436_01C83D8F.652DD7E0-- From mext-bounces@ietf.org Thu Dec 13 08:59:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2obO-0007OG-BP; Thu, 13 Dec 2007 08:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2obN-0007OB-Oz for mext@ietf.org; Thu, 13 Dec 2007 08:59:49 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2obJ-0002qf-9r for mext@ietf.org; Thu, 13 Dec 2007 08:59:49 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBDDxah07106; Thu, 13 Dec 2007 13:59:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Dec 2007 07:59:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Minutes of MEXT sessions at IETF-70 Thread-Index: Acg80hbsT0d1I4b/RGeYED2DMTKWRAABvBhgAC2h89A= From: "Ahmad Muhanna" To: "Julien Laganier" , "marcelo bagnulo braun" X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mext@ietf.org Subject: [MEXT] RE: Minutes of MEXT sessions at IETF-70 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Chairs/All, Please find some comments below. Regards, Ahmad - Multiple Care-of Addresses Registration Ryuji Wakikawa - 20 min draft-ietf-monami6-multiplecoa-04 Ryuji: George commented that maybe we should add IPv4 CoA support for DSMIPv6 support Alex: Disagree, why add new features George: DSMIP is now being adopted by SDOs, and there is no rush for this, so lets do it correctly Ryuji: Other comment from George is why bulk registrations with CNs are excluded. There was consensous against this before. George, unlike last issue I am not convinced this is necessary to support. It was just not clear why this is not supported while reading the draft. Ryuji: yes so it was to keep the protocol simple. Ryuji: Last issue is about simultaneous home/foreign links. This has been discussed for some time now. There is now consensus to support this but no yet agreement on how to do it. (two options summarized) Various: some discussion regarding whether we need to support this in this draft or not. Seems that the answer is yes [Ahmad] I am not sure about the above conclusion at this point of the meeting. Under various, I assume that my comments should have been listed which were as follows: 1. I think that addressing this scenario is probably not required at this point and options look messy. I also raised the issue if supporting this scenario, will that be a violation of RFC3775 which requires the MN to send a de-registration BU as soon as it realizes that it is on a home link. {I do not recall Ryuji answering that point but some other folks mentioned that it is not which was not clear to me} 2. I also made a comment regarding the status code when multiple care of address registration fails. I suggested that whenever any of the BID fails registration, the BA should use a new status code less than 128 to indicate to the MN that registration was successful but some BID failed registration in order for the MN to check which BID has failed. If all registered correctly, HA should always use status zero. {Ryuji agreed with that comment} 3. Also, I do not think the conclusion of that "various" was YES. Cheers!=20 > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Wednesday, December 12, 2007 9:15 AM > To: mext@ietf.org > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 >=20 > Folks, >=20 > Minutes of the meeting are available there: >=20 > >=20 > Please send to chairs corrections and/or add-ons, if any. >=20 > Thanks. >=20 > --julien >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 10:47:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qHJ-0004uH-9z; Thu, 13 Dec 2007 10:47:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qHH-0004uC-Fh for mext@ietf.org; Thu, 13 Dec 2007 10:47:11 -0500 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qHG-0007HA-Px for mext@ietf.org; Thu, 13 Dec 2007 10:47:11 -0500 Received: by wr-out-0506.google.com with SMTP id 68so411799wra.13 for ; Thu, 13 Dec 2007 07:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=pWkAIs+/Y7nIwrIfHsNfvdPcsRC6rtMwrDqVL8cMkak=; b=qILlrL04SnH63a8D74KJEBKpwpwFGz11c6HXu1mbRhj2zl6mzxUKfSaQX/5i3BVQZCU73Q/e5ntfu2yhlr7ZA03hc+ADMTER8wqtfgRKyvc0YPWaR3ou9gLNzSYtZLdfZsqhUawJcTcdM5Rbl25J6KQJ2e+tR748npBprvMtfcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=rwel0/vRSWVyOCblnW7oPOrpISqgcM2tacmR87O2OW2aksRhuqLjyJUCEPicXxiv/RbuejrVfqAYIkdMlqnlXgrdWQOYgejqAKq8GObgNzQEupbguOtCmfEgncMjRyv/LnOFjqLf5aZVxwbkOsug950v+1rsW5s0IM+6qC6Sy38= Received: by 10.78.185.15 with SMTP id i15mr2533404huf.61.1197560828956; Thu, 13 Dec 2007 07:47:08 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k5sm296899nfh.2007.12.13.07.47.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2007 07:47:07 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Thu, 13 Dec 2007 16:47:12 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712131647.14533.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello Ahmad and others, Thanks Ahmad for reviewing the minutes, this is certainly helpful to ensure they accurately reflect the meeting discussions. Thanks also to our notes takers, this is a difficult task and it is unavoidable that sometimes mistakes are made. I listened carefully to the recorded audio from our 1st session: and I agree the excerpt of the minutes Ahmad sent do not reflect accurately the discussion that took place (between 1:23 and 1:46 in the record). I am proposing the updated text below (I condensed your comments Ahmad, hope I got them right). Now a question to people that were in the meeting or listened to the recorded audio: Do you agree with the proposed change? Thanks. --julien ----------------------------- Ryuji: George commented that maybe we should add IPv4 CoA support for DSMIPv6 support Alex: Disagree, why add new features George: DSMIP is now being adopted by SDOs, and there is no rush for this, so lets do it correctly Ryuji: Other comment from George is why bulk registrations with CNs are excluded. There was consensous against this before. George, unlike last issue I am not convinced this is necessary to support. It was just not clear why this is not supported while reading the draft. Ryuji: yes so it was to keep the protocol simple. Ryuji: Last issue is about simultaneous home/foreign links. This has been discussed for some time now. There is now consensus to support this but no yet agreement on how to do it. (two options summarized) Ahmad: Addressing this scenario is probably not required at this point and options look messy. Also, supporting this scenario would be a violation of RFC3775 which requires the MN to send a de-registration BU as soon as it realizes that it is on a home link. Can we limit the draft to multiple care-of address registration for now. Ahmad: Also, regarding the status code when multiple care of address registration fails, I suggest that whenever any of the BID fails registration, the BA should use a new status code less than 128 to indicate to the MN that registration was successful but some BID failed registration in order for the MN to check which BID has failed. If all registered correctly, HA should always use status zero. Ryuji: Ok. Various people: some discussion regarding whether we need to support this in this draft or not. ----------------------------- On Thursday 13 December 2007, Ahmad Muhanna wrote: > Hi Chairs/All, > > Please find some comments below. > > Regards, > Ahmad > > > - Multiple Care-of Addresses Registration > Ryuji Wakikawa - 20 min > draft-ietf-monami6-multiplecoa-04 > > Ryuji: George commented that maybe we should add IPv4 CoA support for > DSMIPv6 support > Alex: Disagree, why add new features > George: DSMIP is now being adopted by SDOs, and there is no rush for > this, so lets do it correctly > Ryuji: Other comment from George is why bulk registrations with CNs > are excluded. There was consensous against this before. > George, unlike last issue I am not convinced this is necessary to > support. It was just not clear why this is not supported while > reading the draft. > Ryuji: yes so it was to keep the protocol simple. > Ryuji: Last issue is about simultaneous home/foreign links. This has > been discussed for some time now. There is now consensus to support > this but no yet agreement on how to do it. (two options summarized) > > Various: some discussion regarding whether we need to support this in > this draft or not. Seems that the answer is yes > > [Ahmad] > I am not sure about the above conclusion at this point of the > meeting. Under various, I assume that my comments should have been > listed which were as follows: > > 1. I think that addressing this scenario is probably not required at > this point and options look messy. I also raised the issue if > supporting this scenario, will that be a violation of RFC3775 which > requires the MN to send a de-registration BU as soon as it realizes > that it is on a home link. {I do not recall Ryuji answering that > point but some other folks mentioned that it is not which was not > clear to me} > > 2. I also made a comment regarding the status code when multiple care > of address registration fails. I suggested that whenever any of the > BID fails registration, the BA should use a new status code less than > 128 to indicate to the MN that registration was successful but some > BID failed registration in order for the MN to check which BID has > failed. If all registered correctly, HA should always use status > zero. {Ryuji agreed with that comment} > > 3. Also, I do not think the conclusion of that "various" was YES. > > Cheers! > > > -----Original Message----- > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > Sent: Wednesday, December 12, 2007 9:15 AM > > To: mext@ietf.org > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > Folks, > > > > Minutes of the meeting are available there: > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > Thanks. > > > > --julien > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 10:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qOJ-0001rK-BF; Thu, 13 Dec 2007 10:54:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qOI-0001rE-Io for mext@ietf.org; Thu, 13 Dec 2007 10:54:26 -0500 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qOH-0007Si-1L for mext@ietf.org; Thu, 13 Dec 2007 10:54:26 -0500 Received: by nz-out-0506.google.com with SMTP id n1so395001nzf.4 for ; Thu, 13 Dec 2007 07:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=V4fkd2EaaZNvgPvg5PtkofbfPqjq7mGlxAx0v5970AM=; b=wI0Is1N1Yn3/NLsLhpi9l7kUF6QVfGQea86xq6odnb3hg4tsp+cB+q7/JzbxkE8NoR1gwC+7sHgSawSN5UEfZPLH28uDQ4UoLXSVrQnXLEELz6136UXAINFRJS2zCS+RTQE3/+d4dbG6FXhbaWvcZH/ZBXjhjJcq0umIPEikXlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oOm0XVb9LFmqf30qc/CRu7MHzppyhT6ncTnBzRPt80dlB79aIXD5YorU+TdTHe4AoxGSHjeIyNyoSo9ok7XNrAL+XQNCOculqsAoGcxoyzgPqnO/hlz+MStfk/cIcnFw9xU/5XGr5T1KyxctbVvJaX+bKCuQFGgchDQeUjOwEpo= Received: by 10.142.50.15 with SMTP id x15mr878455wfx.169.1197561261794; Thu, 13 Dec 2007 07:54:21 -0800 (PST) Received: by 10.142.11.11 with HTTP; Thu, 13 Dec 2007 07:54:21 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 15:54:21 +0000 From: "George Tsirtsis" To: "Ahmad Muhanna" Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org inline... On Dec 13, 2007 1:59 PM, Ahmad Muhanna wrote: > > Hi Chairs/All, > > Please find some comments below. > > Regards, > Ahmad > > > - Multiple Care-of Addresses Registration > Ryuji Wakikawa - 20 min > draft-ietf-monami6-multiplecoa-04 > > Ryuji: George commented that maybe we should add IPv4 CoA support for > DSMIPv6 support > Alex: Disagree, why add new features > George: DSMIP is now being adopted by SDOs, and there is no rush for > this, so lets do it correctly > Ryuji: Other comment from George is why bulk registrations with CNs are > excluded. There was consensous against this before. > George, unlike last issue I am not convinced this is necessary to > support. It was just not clear why this is not supported while reading > the draft. > Ryuji: yes so it was to keep the protocol simple. > Ryuji: Last issue is about simultaneous home/foreign links. This has > been discussed for some time now. There is now consensus to support this > but no yet agreement on how to do it. (two options summarized) > > Various: some discussion regarding whether we need to support this in > this draft or not. Seems that the answer is yes > > [Ahmad] > I am not sure about the above conclusion at this point of the meeting. > Under various, I assume that my comments should have been listed which > were as follows: > > 1. I think that addressing this scenario is probably not required at > this point and options look messy. I also raised the issue if supporting > this scenario, will that be a violation of RFC3775 which requires the MN > to send a de-registration BU as soon as it realizes that it is on a home > link. {I do not recall Ryuji answering that point but some other folks > mentioned that it is not which was not clear to me} > GT> Ahmad, it would be very strange for the specification that allows MNs to utilize multiple links, to not allow one of these links to be the home link. I disagree that the solution to this is in any way messy. It is only messy if we do not do anything (i.,e., if we do not address the issue in MCoA specification). Also, there is no issue with violating RFC3775 since whatever we define in the MCoA draft will only work and can only by used by MNs IF and ONLY IF the HA supports the MCoA specification. Regards George > 2. I also made a comment regarding the status code when multiple care of > address registration fails. I suggested that whenever any of the BID > fails registration, the BA should use a new status code less than 128 to > indicate to the MN that registration was successful but some BID failed > registration in order for the MN to check which BID has failed. If all > registered correctly, HA should always use status zero. {Ryuji agreed > with that comment} > > 3. Also, I do not think the conclusion of that "various" was YES. > > Cheers! > > > > -----Original Message----- > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > Sent: Wednesday, December 12, 2007 9:15 AM > > To: mext@ietf.org > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > Folks, > > > > Minutes of the meeting are available there: > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > Thanks. > > > > --julien > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 10:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qOe-0002Ig-69; Thu, 13 Dec 2007 10:54:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2qOd-0002IZ-4S for mext@ietf.org; Thu, 13 Dec 2007 10:54:47 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2qOc-0007TM-O0 for mext@ietf.org; Thu, 13 Dec 2007 10:54:47 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2007 07:54:46 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id lBDFskRO024167; Thu, 13 Dec 2007 07:54:46 -0800 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBDFsfmt029259; Thu, 13 Dec 2007 15:54:45 GMT Date: Thu, 13 Dec 2007 07:54:41 -0800 (PST) From: Sri Gundavelli To: Ahmad Muhanna Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1896; t=1197561286; x=1198425286; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20RE=3A=20Minutes=20of=20MEXT=20 sessions=20at=20IETF-70 |Sender:=20; bh=cDuWkSTMuXKJKnu+h6tNremAnrUJibgJGjU0eBkXnLE=; b=V+dDVEGVsXpmrWhJDhjyW3Lo0TrYIhe9o3O2kKu0pz3LIcuU22d7UzdKwj Tci2aChUx8kjWzchkglq/FqH8bEzDW3mxbw0sOxTgefI3iyxSKTs6Y593tRe t+vduOgQTo; Authentication-Results: sj-dkim-5; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Thu, 13 Dec 2007, Ahmad Muhanna wrote: > Various: some discussion regarding whether we need to support this in > this draft or not. Seems that the answer is yes > > [Ahmad] > I am not sure about the above conclusion at this point of the meeting. > Under various, I assume that my comments should have been listed which > were as follows: > > 1. I think that addressing this scenario is probably not required at > this point and options look messy. I also raised the issue if supporting > this scenario, will that be a violation of RFC3775 which requires the MN > to send a de-registration BU as soon as it realizes that it is on a home > link. {I do not recall Ryuji answering that point but some other folks > mentioned that it is not which was not clear to me} > > 2. I also made a comment regarding the status code when multiple care of > address registration fails. I suggested that whenever any of the BID > fails registration, the BA should use a new status code less than 128 to > indicate to the MN that registration was successful but some BID failed > registration in order for the MN to check which BID has failed. If all > registered correctly, HA should always use status zero. {Ryuji agreed > with that comment} > > 3. Also, I do not think the conclusion of that "various" was YES. > I agree. I do not think this should be addressed in this draft. It requires some detailed analysis and none of the solutions are simple enough to be adopted and we have not studied the implications of any of those proposals, including CoA derivation on the home link etc. There is no clear interest/consensus either for the usecase or for a specific solution. Given that, I suggest we defer this and get this draft out soon. Also, I'm repeating my view on this, probably posted in the MIP6 ML, to ensure the new chairs do not miss this. Thanks Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 12:13:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rcx-0004SJ-DA; Thu, 13 Dec 2007 12:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rcv-0004PU-SQ for mext@ietf.org; Thu, 13 Dec 2007 12:13:37 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2rct-0001pp-5C for mext@ietf.org; Thu, 13 Dec 2007 12:13:37 -0500 Received: (qmail 9412 invoked for bounce); 13 Dec 2007 17:13:33 -0000 Received: from unknown (HELO ?130.79.91.222?) (kuntz@unknown) by unknown with RC4-SHA encrypted SMTP; 13 Dec 2007 17:13:33 -0000 Message-Id: <3B685FAF-7F41-44B7-8EB4-F8AA61AA179D@clarinet.u-strasbg.fr> From: Romain KUNTZ To: Hesham@elevatemobile.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Thu, 13 Dec 2007 18:13:33 +0100 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >> I guess you refer to the Extended Flow Information Object. >> Not only we >> would like to allow/deny a flow, but we'd like also to specify a >> tunnel identifier for a specific flow. That may require to define a >> new object. > > => But the tunnel identifier is already known from the BU. So all > you need > to do is to describe the flow, nothing else is needed AFAICS. I agree if put such option in a BU jointly with a BID option and/or a Flow Identification option (from the flow binding draft). Is it what you had in mind? romain _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JanicelynnBorsen@ars-photo.com Thu Dec 13 12:22:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2rln-00028h-W8 for nemo-archive@lists.ietf.org; Thu, 13 Dec 2007 12:22:48 -0500 Received: from ppp-107-67.20-151.libero.it ([151.20.67.107] helo=ppp-53-67.20-151.libero.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2rln-0002ua-FW for nemo-archive@lists.ietf.org; Thu, 13 Dec 2007 12:22:47 -0500 Received: from Jeanette by ars-photo.com with ASMTP id 98F789E0 for ; Thu, 13 Dec 2007 18:20:05 +0100 Received: from Jeanette ([144.127.151.73]) by ars-photo.com with ESMTP id 08AE3383B3DF for ; Thu, 13 Dec 2007 18:20:05 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Dec 2007 18:19:48 +0100 To: nemo-archive@lists.ietf.org From: "Janicelynn Borsen" Subject: nererimh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.4 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Stress, stress, stress.. Who cares with our new penis power pills ? http://mainvod.com/ From mext-bounces@ietf.org Thu Dec 13 12:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2s2A-0005sG-SZ; Thu, 13 Dec 2007 12:39:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2s29-0005pU-0z for mext@ietf.org; Thu, 13 Dec 2007 12:39:41 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2s28-0003WZ-Ei for mext@ietf.org; Thu, 13 Dec 2007 12:39:40 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBDHdXh28897; Thu, 13 Dec 2007 17:39:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Thu, 13 Dec 2007 11:39:13 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Thread-Index: Acg9oLY68SMGaymOTYqIx1TQk8Dz4gADWL8A References: From: "Ahmad Muhanna" To: "George Tsirtsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > > > - Multiple Care-of Addresses Registration > > Ryuji Wakikawa - 20 min > > draft-ietf-monami6-multiplecoa-04 > > > > Ryuji: George commented that maybe we should add IPv4 CoA=20 > support for > > DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no=20 > rush for=20 > > this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs=20 > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to=20 > > support. It was just not clear why this is not supported=20 > while reading=20 > > the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links.=20 > This has=20 > > been discussed for some time now. There is now consensus to support=20 > > this but no yet agreement on how to do it. (two options summarized) > > > > Various: some discussion regarding whether we need to=20 > support this in=20 > > this draft or not. Seems that the answer is yes > > > > [Ahmad] > > I am not sure about the above conclusion at this point of=20 > the meeting. > > Under various, I assume that my comments should have been=20 > listed which=20 > > were as follows: > > > > 1. I think that addressing this scenario is probably not=20 > required at=20 > > this point and options look messy. I also raised the issue if=20 > > supporting this scenario, will that be a violation of RFC3775 which=20 > > requires the MN to send a de-registration BU as soon as it realizes=20 > > that it is on a home link. {I do not recall Ryuji answering=20 > that point=20 > > but some other folks mentioned that it is not which was not=20 > clear to=20 > > me} > > >=20 > GT> Ahmad, it would be very strange for the specification that allows > MNs to utilize multiple links, to not allow one of these=20 > links to be the home link. I disagree that the solution to=20 > this is in any way messy. It is only messy if we do not do=20 > anything (i.,e., if we do not address the issue in MCoA=20 > specification). Also, there is no issue with violating=20 > RFC3775 since whatever we define in the MCoA draft will only=20 > work and can only by used by MNs IF and ONLY IF the HA=20 > supports the MCoA specification. >=20 > Regards > George [Ahmad] George, Since the meeting minutes needs to capture what happened in the meeting, I believe that you do not disagree with my correction of the meeting minutes, but you disagree with the issue itself and would like to discuss it further. Is that a fair understanding? Regards, Ahmad >=20 > > 2. I also made a comment regarding the status code when=20 > multiple care=20 > > of address registration fails. I suggested that whenever any of the=20 > > BID fails registration, the BA should use a new status code=20 > less than=20 > > 128 to indicate to the MN that registration was successful but some=20 > > BID failed registration in order for the MN to check which BID has=20 > > failed. If all registered correctly, HA should always use=20 > status zero.=20 > > {Ryuji agreed with that comment} > > > > 3. Also, I do not think the conclusion of that "various" was YES. > > > > Cheers! > > > > > > > -----Original Message----- > > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > > Sent: Wednesday, December 12, 2007 9:15 AM > > > To: mext@ietf.org > > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > > > Folks, > > > > > > Minutes of the meeting are available there: > > > > > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > > > Thanks. > > > > > > --julien > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 14:48:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2u2t-0003a0-Bj; Thu, 13 Dec 2007 14:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2u2r-0003Zr-PJ for mext@ietf.org; Thu, 13 Dec 2007 14:48:33 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2u2p-0007Kh-NL for mext@ietf.org; Thu, 13 Dec 2007 14:48:33 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 11:48:30 -0800 Message-ID: <47618C8C.6040302@azairenet.com> Date: Thu, 13 Dec 2007 11:48:28 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 References: <200712131647.14533.julien.IETF@laposte.net> In-Reply-To: <200712131647.14533.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2007 19:48:30.0705 (UTC) FILETIME=[231B8E10:01C83DC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Julien, I believe Ryuji was trying to get folks to pick one solution for the scenario where the mobile node is attached to the home link and visited link at the same time. We have a few options. I don't understand Sri's and Ahmad's concerns about complexity. We do have an issue here, so it needs to be addressed. I agree with George, if there is a home link to which the MN can attach to, then this scenario is bound to happen. Vijay Julien Laganier wrote: > Hello Ahmad and others, > > Thanks Ahmad for reviewing the minutes, this is certainly helpful to > ensure they accurately reflect the meeting discussions. Thanks also to > our notes takers, this is a difficult task and it is unavoidable that > sometimes mistakes are made. > > I listened carefully to the recorded audio from our 1st session: > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > accurately the discussion that took place (between 1:23 and 1:46 in the > record). I am proposing the updated text below (I condensed your > comments Ahmad, hope I got them right). > > Now a question to people that were in the meeting or listened to the > recorded audio: Do you agree with the proposed change? > > Thanks. > > --julien > > ----------------------------- > Ryuji: George commented that maybe we should add IPv4 CoA support for > DSMIPv6 support > Alex: Disagree, why add new features > George: DSMIP is now being adopted by SDOs, and there is no rush for > this, so lets do it correctly > Ryuji: Other comment from George is why bulk registrations with CNs > are excluded. There was consensous against this before. > George, unlike last issue I am not convinced this is necessary to > support. It was just not clear why this is not supported while > reading the draft. > Ryuji: yes so it was to keep the protocol simple. > Ryuji: Last issue is about simultaneous home/foreign links. This has > been discussed for some time now. There is now consensus to support > this but no yet agreement on how to do it. (two options summarized) > Ahmad: Addressing this scenario is probably not required at this point > and options look messy. Also, supporting this scenario would be a > violation of RFC3775 which requires the MN to send a de-registration BU > as soon as it realizes that it is on a home link. Can we limit the > draft to multiple care-of address registration for now. > Ahmad: Also, regarding the status code when multiple care of address > registration fails, I suggest that whenever any of the BID fails > registration, the BA should use a new status code less than 128 to > indicate to the MN that registration was successful but some > BID failed registration in order for the MN to check which BID has > failed. If all registered correctly, HA should always use status > zero. > Ryuji: Ok. > Various people: some discussion regarding whether we need to support > this in this draft or not. > ----------------------------- > > On Thursday 13 December 2007, Ahmad Muhanna wrote: >> Hi Chairs/All, >> >> Please find some comments below. >> >> Regards, >> Ahmad >> >> >> - Multiple Care-of Addresses Registration >> Ryuji Wakikawa - 20 min >> draft-ietf-monami6-multiplecoa-04 >> >> Ryuji: George commented that maybe we should add IPv4 CoA support for >> DSMIPv6 support >> Alex: Disagree, why add new features >> George: DSMIP is now being adopted by SDOs, and there is no rush for >> this, so lets do it correctly >> Ryuji: Other comment from George is why bulk registrations with CNs >> are excluded. There was consensous against this before. >> George, unlike last issue I am not convinced this is necessary to >> support. It was just not clear why this is not supported while >> reading the draft. >> Ryuji: yes so it was to keep the protocol simple. >> Ryuji: Last issue is about simultaneous home/foreign links. This has >> been discussed for some time now. There is now consensus to support >> this but no yet agreement on how to do it. (two options summarized) >> >> Various: some discussion regarding whether we need to support this in >> this draft or not. Seems that the answer is yes >> >> [Ahmad] >> I am not sure about the above conclusion at this point of the >> meeting. Under various, I assume that my comments should have been >> listed which were as follows: >> >> 1. I think that addressing this scenario is probably not required at >> this point and options look messy. I also raised the issue if >> supporting this scenario, will that be a violation of RFC3775 which >> requires the MN to send a de-registration BU as soon as it realizes >> that it is on a home link. {I do not recall Ryuji answering that >> point but some other folks mentioned that it is not which was not >> clear to me} >> >> 2. I also made a comment regarding the status code when multiple care >> of address registration fails. I suggested that whenever any of the >> BID fails registration, the BA should use a new status code less than >> 128 to indicate to the MN that registration was successful but some >> BID failed registration in order for the MN to check which BID has >> failed. If all registered correctly, HA should always use status >> zero. {Ryuji agreed with that comment} >> >> 3. Also, I do not think the conclusion of that "various" was YES. >> >> Cheers! >> >>> -----Original Message----- >>> From: Julien Laganier [mailto:julien.IETF@laposte.net] >>> Sent: Wednesday, December 12, 2007 9:15 AM >>> To: mext@ietf.org >>> Subject: [MEXT] Minutes of MEXT sessions at IETF-70 >>> >>> Folks, >>> >>> Minutes of the meeting are available there: >>> >>> >>> >>> Please send to chairs corrections and/or add-ons, if any. >>> >>> Thanks. >>> >>> --julien >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 13 16:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vpB-00030Q-Vt; Thu, 13 Dec 2007 16:42:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vpA-00030L-K0 for mext@ietf.org; Thu, 13 Dec 2007 16:42:32 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vp9-0002lC-QC for mext@ietf.org; Thu, 13 Dec 2007 16:42:32 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lBDLd3615515; Thu, 13 Dec 2007 21:39:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Thu, 13 Dec 2007 15:42:07 -0600 Message-ID: In-Reply-To: <200712131647.14533.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Thread-Index: Acg9n3ERYAzSu9lxSkOHj72XzUbPrQAMVl7w References: <200712131647.14533.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Julien, Your updated text looks good to me. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of Julien Laganier > Sent: Thursday, December 13, 2007 9:47 AM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10); marcelo bagnulo braun > Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 >=20 > Hello Ahmad and others, >=20 > Thanks Ahmad for reviewing the minutes, this is certainly=20 > helpful to ensure they accurately reflect the meeting=20 > discussions. Thanks also to our notes takers, this is a=20 > difficult task and it is unavoidable that sometimes mistakes are made. >=20 > I listened carefully to the recorded audio from our 1st session: >=20 > >=20 > and I agree the excerpt of the minutes Ahmad sent do not=20 > reflect accurately the discussion that took place (between=20 > 1:23 and 1:46 in the record). I am proposing the updated text=20 > below (I condensed your comments Ahmad, hope I got them right). >=20 > Now a question to people that were in the meeting or listened=20 > to the recorded audio: Do you agree with the proposed change? >=20 > Thanks. >=20 > --julien >=20 > ----------------------------- > Ryuji: George commented that maybe we should add IPv4 CoA support for > DSMIPv6 support > Alex: Disagree, why add new features > George: DSMIP is now being adopted by SDOs, and there is no=20 > rush for this, so lets do it correctly > Ryuji: Other comment from George is why bulk registrations=20 > with CNs are excluded. There was consensous against this before. > George, unlike last issue I am not convinced this is=20 > necessary to support. It was just not clear why this is not=20 > supported while reading the draft. > Ryuji: yes so it was to keep the protocol simple. > Ryuji: Last issue is about simultaneous home/foreign links.=20 > This has been discussed for some time now. There is now=20 > consensus to support this but no yet agreement on how to do=20 > it. (two options summarized) > Ahmad: Addressing this scenario is probably not required at=20 > this point and options look messy. Also, supporting this=20 > scenario would be a violation of RFC3775 which requires the=20 > MN to send a de-registration BU as soon as it realizes that=20 > it is on a home link. Can we limit the draft to multiple=20 > care-of address registration for now. > Ahmad: Also, regarding the status code when multiple care of=20 > address registration fails, I suggest that whenever any of=20 > the BID fails registration, the BA should use a new status=20 > code less than 128 to indicate to the MN that registration=20 > was successful but some BID failed registration in order for=20 > the MN to check which BID has failed. If all registered=20 > correctly, HA should always use status zero. > Ryuji: Ok. > Various people: some discussion regarding whether we need to=20 > support this in this draft or not.=20 > ----------------------------- >=20 > On Thursday 13 December 2007, Ahmad Muhanna wrote: > > Hi Chairs/All, > > > > Please find some comments below. > > > > Regards, > > Ahmad > > > > > > - Multiple Care-of Addresses Registration > > Ryuji Wakikawa - 20 min > > draft-ietf-monami6-multiplecoa-04 > > > > Ryuji: George commented that maybe we should add IPv4 CoA=20 > support for > > DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no=20 > rush for=20 > > this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs=20 > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to=20 > > support. It was just not clear why this is not supported=20 > while reading=20 > > the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links.=20 > This has=20 > > been discussed for some time now. There is now consensus to support=20 > > this but no yet agreement on how to do it. (two options summarized) > > > > Various: some discussion regarding whether we need to=20 > support this in=20 > > this draft or not. Seems that the answer is yes > > > > [Ahmad] > > I am not sure about the above conclusion at this point of=20 > the meeting.=20 > > Under various, I assume that my comments should have been=20 > listed which=20 > > were as follows: > > > > 1. I think that addressing this scenario is probably not=20 > required at=20 > > this point and options look messy. I also raised the issue if=20 > > supporting this scenario, will that be a violation of RFC3775 which=20 > > requires the MN to send a de-registration BU as soon as it realizes=20 > > that it is on a home link. {I do not recall Ryuji answering=20 > that point=20 > > but some other folks mentioned that it is not which was not=20 > clear to=20 > > me} > > > > 2. I also made a comment regarding the status code when=20 > multiple care=20 > > of address registration fails. I suggested that whenever any of the=20 > > BID fails registration, the BA should use a new status code=20 > less than > > 128 to indicate to the MN that registration was successful but some=20 > > BID failed registration in order for the MN to check which BID has=20 > > failed. If all registered correctly, HA should always use=20 > status zero.=20 > > {Ryuji agreed with that comment} > > > > 3. Also, I do not think the conclusion of that "various" was YES. > > > > Cheers! > > > > > -----Original Message----- > > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > > Sent: Wednesday, December 12, 2007 9:15 AM > > > To: mext@ietf.org > > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > > > Folks, > > > > > > Minutes of the meeting are available there: > > > > > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > > > Thanks. > > > > > > --julien > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From MartaephesusJaramillo@figmentfly.com Thu Dec 13 17:28:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wY2-0001dp-QE; Thu, 13 Dec 2007 17:28:54 -0500 Received: from 77-97-179-121.cable.ubr03.roth.blueyonder.co.uk ([77.97.179.121] helo=nez.belkin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J2wY2-0004Q1-A3; Thu, 13 Dec 2007 17:28:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host55422987.figmentfly.com (8.13.1/8.13.1) with SMTP id 44MPpqLs54.486227.GCJ.EE5.2355341154551 for ; Thu, 13 Dec 2007 22:28:19 +0000 Message-ID: <9bfe01c83dd7$86724d80$0302a8c0@NEZ> From: "Lucia Cormier" To: Subject: Hi Date: Thu, 13 Dec 2007 22:28:19 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9BFA_01C83DD7.86724D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9BFA_01C83DD7.86724D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_9BFA_01C83DD7.86724D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_9BFA_01C83DD7.86724D80-- From mext-bounces@ietf.org Thu Dec 13 20:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2znl-0002oA-Nm; Thu, 13 Dec 2007 20:57:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2znk-0002o5-Dx for mext@ietf.org; Thu, 13 Dec 2007 20:57:20 -0500 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2zni-0008Mn-BW for mext@ietf.org; Thu, 13 Dec 2007 20:57:20 -0500 Received: from oaamta02sl.mx.bigpond.com ([124.190.105.201]) by omta05sl.mx.bigpond.com with ESMTP id <20071214015713.MKMP19939.omta05sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com> for ; Fri, 14 Dec 2007 01:57:13 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071214015712.DVDC25607.oaamta02sl.mx.bigpond.com@PC20005>; Fri, 14 Dec 2007 01:57:12 +0000 From: "Hesham Soliman" To: "'Romain KUNTZ'" Subject: RE: [MEXT] RSVP TSPEC for flow-distribution-rules Date: Fri, 14 Dec 2007 12:56:58 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <3B685FAF-7F41-44B7-8EB4-F8AA61AA179D@clarinet.u-strasbg.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg9q4DRLICZmMRTQMa6p6rOGEjzdAAUUdUg X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > > => But the tunnel identifier is already known from the BU. So all > > you need > > to do is to describe the flow, nothing else is needed AFAICS. > > I agree if put such option in a BU jointly with a BID option > and/or a > Flow Identification option (from the flow binding draft). Is > it what > you had in mind? => Not really; there is no need for "such option" above, the use of the BU itself provides the tunnel end point. Of course I expect the use of the MCoA and flow bindings drafts together with any flow descriptor, that's the reasons for their existence. Hesham > > romain > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 02:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34ze-0000MW-Eu; Fri, 14 Dec 2007 02:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J34zc-0000MG-VQ for mext@ietf.org; Fri, 14 Dec 2007 02:29:57 -0500 Received: from hu-out-0506.google.com ([72.14.214.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J34za-0005za-Jm for mext@ietf.org; Fri, 14 Dec 2007 02:29:56 -0500 Received: by hu-out-0506.google.com with SMTP id 31so448875huc.14 for ; Thu, 13 Dec 2007 23:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=rymTlNLgCKD+viEDTHLJ4DjRTfEFqevE6mZ+2c7Kflw=; b=lrGb8ucMNjRPsiluZkslbeag9WuE8l19PmlZFHbJewdwfvKOnRgatVnsVYOW4JRWElpptcpmPFthoW5uLKZg9c8Ts2j8dcrKXKaTj/2xmTP9W1jQr8Oy7Y2jts7N36d0iR1DE0k4QmOwcVM9nVUEI6rQs6qCeumqg29gcuEQRds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=RkRc3ZxUkihBUg49E7A1CNJWY3Jf/JN01+iB6CX8Si7CYKYdoGLjLPIarA4PulBlwkAmnr/BIP8B+r31ub+yhO+mHz7+pDeQ8a3s49Rvw+g0kQ3eG/WxwuoK0T3Mn37e3R6aoA1g+M4IZ6KIwKz3Cj7Tf0uJ3yuJi+SRthyv1aw= Received: by 10.78.149.13 with SMTP id w13mr3477033hud.64.1197617390218; Thu, 13 Dec 2007 23:29:50 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm1233121nfu.2007.12.13.23.29.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2007 23:29:49 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Fri, 14 Dec 2007 08:29:55 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712131647.14533.julien.IETF@laposte.net> <47618C8C.6040302@azairenet.com> In-Reply-To: <47618C8C.6040302@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712140829.56040.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay, I'm not arguing for or against solving the issue (yet :). For now only fixing the minutes so that they reflect what was said during the meeting. --julien On Thursday 13 December 2007, Vijay Devarapalli wrote: > Julien, > > I believe Ryuji was trying to get folks to pick one solution for > the scenario where the mobile node is attached to the home link > and visited link at the same time. We have a few options. > > I don't understand Sri's and Ahmad's concerns about complexity. > We do have an issue here, so it needs to be addressed. I agree > with George, if there is a home link to which the MN can attach > to, then this scenario is bound to happen. > > Vijay > > Julien Laganier wrote: > > Hello Ahmad and others, > > > > Thanks Ahmad for reviewing the minutes, this is certainly helpful > > to ensure they accurately reflect the meeting discussions. Thanks > > also to our notes takers, this is a difficult task and it is > > unavoidable that sometimes mistakes are made. > > > > I listened carefully to the recorded audio from our 1st session: > > > > > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > > accurately the discussion that took place (between 1:23 and 1:46 in > > the record). I am proposing the updated text below (I condensed > > your comments Ahmad, hope I got them right). > > > > Now a question to people that were in the meeting or listened to > > the recorded audio: Do you agree with the proposed change? > > > > Thanks. > > > > --julien > > > > ----------------------------- > > Ryuji: George commented that maybe we should add IPv4 CoA support > > for DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no rush > > for this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to > > support. It was just not clear why this is not supported while > > reading the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links. This > > has been discussed for some time now. There is now consensus to > > support this but no yet agreement on how to do it. (two options > > summarized) Ahmad: Addressing this scenario is probably not > > required at this point and options look messy. Also, supporting > > this scenario would be a violation of RFC3775 which requires the MN > > to send a de-registration BU as soon as it realizes that it is on a > > home link. Can we limit the draft to multiple care-of address > > registration for now. > > Ahmad: Also, regarding the status code when multiple care of > > address registration fails, I suggest that whenever any of the BID > > fails registration, the BA should use a new status code less than > > 128 to indicate to the MN that registration was successful but some > > BID failed registration in order for the MN to check which BID has > > failed. If all registered correctly, HA should always use status > > zero. > > Ryuji: Ok. > > Various people: some discussion regarding whether we need to > > support this in this draft or not. > > ----------------------------- > > > > On Thursday 13 December 2007, Ahmad Muhanna wrote: > >> Hi Chairs/All, > >> > >> Please find some comments below. > >> > >> Regards, > >> Ahmad > >> > >> > >> - Multiple Care-of Addresses Registration > >> Ryuji Wakikawa - 20 min > >> draft-ietf-monami6-multiplecoa-04 > >> > >> Ryuji: George commented that maybe we should add IPv4 CoA support > >> for DSMIPv6 support > >> Alex: Disagree, why add new features > >> George: DSMIP is now being adopted by SDOs, and there is no rush > >> for this, so lets do it correctly > >> Ryuji: Other comment from George is why bulk registrations with > >> CNs are excluded. There was consensous against this before. > >> George, unlike last issue I am not convinced this is necessary to > >> support. It was just not clear why this is not supported while > >> reading the draft. > >> Ryuji: yes so it was to keep the protocol simple. > >> Ryuji: Last issue is about simultaneous home/foreign links. This > >> has been discussed for some time now. There is now consensus to > >> support this but no yet agreement on how to do it. (two options > >> summarized) > >> > >> Various: some discussion regarding whether we need to support this > >> in this draft or not. Seems that the answer is yes > >> > >> [Ahmad] > >> I am not sure about the above conclusion at this point of the > >> meeting. Under various, I assume that my comments should have been > >> listed which were as follows: > >> > >> 1. I think that addressing this scenario is probably not required > >> at this point and options look messy. I also raised the issue if > >> supporting this scenario, will that be a violation of RFC3775 > >> which requires the MN to send a de-registration BU as soon as it > >> realizes that it is on a home link. {I do not recall Ryuji > >> answering that point but some other folks mentioned that it is not > >> which was not clear to me} > >> > >> 2. I also made a comment regarding the status code when multiple > >> care of address registration fails. I suggested that whenever any > >> of the BID fails registration, the BA should use a new status code > >> less than 128 to indicate to the MN that registration was > >> successful but some BID failed registration in order for the MN to > >> check which BID has failed. If all registered correctly, HA should > >> always use status zero. {Ryuji agreed with that comment} > >> > >> 3. Also, I do not think the conclusion of that "various" was YES. > >> > >> Cheers! > >> > >>> -----Original Message----- > >>> From: Julien Laganier [mailto:julien.IETF@laposte.net] > >>> Sent: Wednesday, December 12, 2007 9:15 AM > >>> To: mext@ietf.org > >>> Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > >>> > >>> Folks, > >>> > >>> Minutes of the meeting are available there: > >>> > >>> > >>> > >>> Please send to chairs corrections and/or add-ons, if any. > >>> > >>> Thanks. > >>> > >>> --julien > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ClementbiconcaveDurham@gmcanada.com Fri Dec 14 03:27:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35sz-0001Y9-UG; Fri, 14 Dec 2007 03:27:09 -0500 Received: from d226-46-143.home.cgocable.net ([24.226.46.143] helo=lenovo33f7454e.kico2.on.cogeco.ca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J35sx-0007ne-KD; Fri, 14 Dec 2007 03:27:07 -0500 Received: from friable by gmcanada.com with SMTP id wIBQKi9TVU for ; Fri, 14 Dec 2007 00:26:33 +0800 From: "Romeo Velasquez" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J35wO-0002wl-Hi; Fri, 14 Dec 2007 03:30:40 -0500 Received: from [88.235.15.19] (helo=anka05.ankara.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J35wM-0007r8-1T; Fri, 14 Dec 2007 03:30:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host36378870.netsmartz.org (8.13.1/8.13.1) with SMTP id RoxIS5We51.289697.OGx.o4W.1059410515508 for ; Fri, 14 Dec 2007 10:20:26 -0200 Message-ID: <141dc01c83e2a$42154d60$f601a8c0@ANKA05> From: "Jayson Sellers" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_141D8_01C83E2A.42154D60-- From mext-bounces@ietf.org Fri Dec 14 04:03:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36RK-00020S-1y; Fri, 14 Dec 2007 04:02:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36RH-00020M-Vz for mext@ietf.org; Fri, 14 Dec 2007 04:02:36 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J36RG-0000Gw-MH for mext@ietf.org; Fri, 14 Dec 2007 04:02:35 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id lBE92SBx010720 for ; Fri, 14 Dec 2007 18:02:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lBE92Tg10452 for ; Fri, 14 Dec 2007 18:02:29 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id lBE92T621500 for ; Fri, 14 Dec 2007 18:02:29 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml24) id lBE92SnB012431 for mext@ietf.org; Fri, 14 Dec 2007 18:02:28 +0900 (JST) Received: from [10.68.141.103] by soml24.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lBE92Qsc012358 for ; Fri, 14 Dec 2007 18:02:27 +0900 (JST) Date: Fri, 14 Dec 2007 18:02:27 +0900 From: Keigo Aso To: mext@ietf.org Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: <47618C8C.6040302@azairenet.com> References: <200712131647.14533.julien.IETF@laposte.net> <47618C8C.6040302@azairenet.com> Message-Id: <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hello, In the last meeting, actually the author mentioned that there was concensus to support for the simultaneous usage of the home and foreign attached interfaces, and then there were apparently more supports for this scenario during the session also. The chair(Marcelo) also said in his email that he had reached the same conclusion based on the session and ML review, and clearly indicated the next step as the WG. So, I think there is no need to go back to before again even though the minutes is updated. I agree with George and Vijay. Supporting this scenario is very important for practical MCoA specification because MCoA MN can connect to the network which is defined in RFC3775. Regards, Keigo On Thu, 13 Dec 2007 11:48:28 -0800 Vijay Devarapalli wrote: > Julien, > > I believe Ryuji was trying to get folks to pick one solution for > the scenario where the mobile node is attached to the home link > and visited link at the same time. We have a few options. > > I don't understand Sri's and Ahmad's concerns about complexity. > We do have an issue here, so it needs to be addressed. I agree > with George, if there is a home link to which the MN can attach > to, then this scenario is bound to happen. > > Vijay > > Julien Laganier wrote: > > Hello Ahmad and others, > > > > Thanks Ahmad for reviewing the minutes, this is certainly helpful to > > ensure they accurately reflect the meeting discussions. Thanks also to > > our notes takers, this is a difficult task and it is unavoidable that > > sometimes mistakes are made. > > > > I listened carefully to the recorded audio from our 1st session: > > > > > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > > accurately the discussion that took place (between 1:23 and 1:46 in the > > record). I am proposing the updated text below (I condensed your > > comments Ahmad, hope I got them right). > > > > Now a question to people that were in the meeting or listened to the > > recorded audio: Do you agree with the proposed change? > > > > Thanks. > > > > --julien > > > > ----------------------------- > > Ryuji: George commented that maybe we should add IPv4 CoA support for > > DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no rush for > > this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to > > support. It was just not clear why this is not supported while > > reading the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links. This has > > been discussed for some time now. There is now consensus to support > > this but no yet agreement on how to do it. (two options summarized) > > Ahmad: Addressing this scenario is probably not required at this point > > and options look messy. Also, supporting this scenario would be a > > violation of RFC3775 which requires the MN to send a de-registration BU > > as soon as it realizes that it is on a home link. Can we limit the > > draft to multiple care-of address registration for now. > > Ahmad: Also, regarding the status code when multiple care of address > > registration fails, I suggest that whenever any of the BID fails > > registration, the BA should use a new status code less than 128 to > > indicate to the MN that registration was successful but some > > BID failed registration in order for the MN to check which BID has > > failed. If all registered correctly, HA should always use status > > zero. > > Ryuji: Ok. > > Various people: some discussion regarding whether we need to support > > this in this draft or not. > > ----------------------------- > > > > On Thursday 13 December 2007, Ahmad Muhanna wrote: > >> Hi Chairs/All, > >> > >> Please find some comments below. > >> > >> Regards, > >> Ahmad > >> > >> > >> - Multiple Care-of Addresses Registration > >> Ryuji Wakikawa - 20 min > >> draft-ietf-monami6-multiplecoa-04 > >> > >> Ryuji: George commented that maybe we should add IPv4 CoA support for > >> DSMIPv6 support > >> Alex: Disagree, why add new features > >> George: DSMIP is now being adopted by SDOs, and there is no rush for > >> this, so lets do it correctly > >> Ryuji: Other comment from George is why bulk registrations with CNs > >> are excluded. There was consensous against this before. > >> George, unlike last issue I am not convinced this is necessary to > >> support. It was just not clear why this is not supported while > >> reading the draft. > >> Ryuji: yes so it was to keep the protocol simple. > >> Ryuji: Last issue is about simultaneous home/foreign links. This has > >> been discussed for some time now. There is now consensus to support > >> this but no yet agreement on how to do it. (two options summarized) > >> > >> Various: some discussion regarding whether we need to support this in > >> this draft or not. Seems that the answer is yes > >> > >> [Ahmad] > >> I am not sure about the above conclusion at this point of the > >> meeting. Under various, I assume that my comments should have been > >> listed which were as follows: > >> > >> 1. I think that addressing this scenario is probably not required at > >> this point and options look messy. I also raised the issue if > >> supporting this scenario, will that be a violation of RFC3775 which > >> requires the MN to send a de-registration BU as soon as it realizes > >> that it is on a home link. {I do not recall Ryuji answering that > >> point but some other folks mentioned that it is not which was not > >> clear to me} > >> > >> 2. I also made a comment regarding the status code when multiple care > >> of address registration fails. I suggested that whenever any of the > >> BID fails registration, the BA should use a new status code less than > >> 128 to indicate to the MN that registration was successful but some > >> BID failed registration in order for the MN to check which BID has > >> failed. If all registered correctly, HA should always use status > >> zero. {Ryuji agreed with that comment} > >> > >> 3. Also, I do not think the conclusion of that "various" was YES. > >> > >> Cheers! > >> > >>> -----Original Message----- > >>> From: Julien Laganier [mailto:julien.IETF@laposte.net] > >>> Sent: Wednesday, December 12, 2007 9:15 AM > >>> To: mext@ietf.org > >>> Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > >>> > >>> Folks, > >>> > >>> Minutes of the meeting are available there: > >>> > >>> > >>> > >>> Please send to chairs corrections and/or add-ons, if any. > >>> > >>> Thanks. > >>> > >>> --julien > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 05:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J37l1-0000JW-8Y; Fri, 14 Dec 2007 05:27:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J37l0-0000JM-CU for mext@ietf.org; Fri, 14 Dec 2007 05:27:02 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J37ky-00018l-6b for mext@ietf.org; Fri, 14 Dec 2007 05:27:02 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3276201uge.46 for ; Fri, 14 Dec 2007 02:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=7vUtXB0as6O5eYwOGGUqBq1Dz2q0zjt/QhKG40g3t9Q=; b=vueyO9D0ibrurQZPvQYQ/ypwMbSyWU2nlmFk58mrcGXqYtMdzY9mipZoYekLvMs66uxjGTFezCQpI13pNeWwa7+pJkPRYl43sFdJDDHaayfMCfPMIMrbKNFAn1oIpT3PAeo617n3kWP0WegJrz2i16QPCFYznrWV/ISD3Oruv60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ulwQ4crTDLXsvpeKCZr2WrvmCrdaGgfCQZxnIPw6BTCcNZsUwgC2ReGZKDIihZVD7REkjuYeqIwCxO9CnWfRRQRqvO3EcPVd1aooje9J4JRVDrDzriWUbnkEjO6zh6IUh0kvz1uhyV7WEyDMg8lbPMlP3IMBshUKYvnOK+SvQPg= Received: by 10.78.131.8 with SMTP id e8mr3703310hud.52.1197628018988; Fri, 14 Dec 2007 02:26:58 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 2sm1875886nfv.2007.12.14.02.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2007 02:26:57 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Fri, 14 Dec 2007 11:27:08 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712131647.14533.julien.IETF@laposte.net> <47618C8C.6040302@azairenet.com> <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> In-Reply-To: <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712141127.08573.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Friday 14 December 2007, Keigo Aso wrote: > So, I think there is no need to go back to before again > even though the minutes is updated. Just to make sure: we WG chairs are not suggesting that. Just correcting the meeting minutes. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 06:04:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38LV-0003h9-Mt; Fri, 14 Dec 2007 06:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38LT-0003h3-Q7 for mext@ietf.org; Fri, 14 Dec 2007 06:04:43 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J38LR-0001xU-Mh for mext@ietf.org; Fri, 14 Dec 2007 06:04:43 -0500 Received: by nz-out-0506.google.com with SMTP id n1so558238nzf.4 for ; Fri, 14 Dec 2007 03:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=EqU8JnkaLez6aP1xQmooI0aX81fMJ+Sv2nQYULS2Lis=; b=N3QxKgUkeDIduoRqp7olQJYaryku9w9yHU/A3AMlIg2eBVPjYjmwyz3O87UqVnywRQYYp7ZCbubh1EGJP1saa1g6a+RTv3+z5EpOt4iKAtVyZzCBk9TYX0AtwVc6VlWu4b5fH5aY+/xYfHYwLVrJR/ZSwEHapi/zGZRx3pKi0zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JoR4I2IfkRRci75zAenoKy1YouYU/+TTdeK+fO03dGse+B0L5vPfaMERZbqSI/l2w2l0NI5r/L2BOmgjjAInh1evURJv7/4/WQMiEfhG8fnmMpM/XP+i5tJvML4l1DV7z7lO+Gy39yJv3h6U3oxmSwNLTAh1i1/Rr54Jr91rNPw= Received: by 10.142.232.20 with SMTP id e20mr1344955wfh.59.1197630280845; Fri, 14 Dec 2007 03:04:40 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 03:04:40 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 11:04:40 +0000 From: "George Tsirtsis" To: "Ahmad Muhanna" Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Dec 13, 2007 5:39 PM, Ahmad Muhanna wrote: ... > > > > > > > GT> Ahmad, it would be very strange for the specification that allows > > MNs to utilize multiple links, to not allow one of these > > links to be the home link. I disagree that the solution to > > this is in any way messy. It is only messy if we do not do > > anything (i.,e., if we do not address the issue in MCoA > > specification). Also, there is no issue with violating > > RFC3775 since whatever we define in the MCoA draft will only > > work and can only by used by MNs IF and ONLY IF the HA > > supports the MCoA specification. > > > > Regards > > George > > [Ahmad] > George, > Since the meeting minutes needs to capture what happened in the meeting, > I believe that you do not disagree with my correction of the meeting > minutes, but you disagree with the issue itself and would like to > discuss it further. > Is that a fair understanding? > GT> Yes, naturally. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 06:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38dA-0000LQ-00; Fri, 14 Dec 2007 06:23:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J38d8-0000LL-Gs for mext@ietf.org; Fri, 14 Dec 2007 06:22:58 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J38d7-0002JT-BI for mext@ietf.org; Fri, 14 Dec 2007 06:22:58 -0500 Received: by rv-out-0910.google.com with SMTP id l15so836003rvb.49 for ; Fri, 14 Dec 2007 03:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FwkeAzRyv6g5065SAbLDvIIIHE/bycBYrsUE8zbYwBc=; b=XKBvOUvDcSpZ0ZOV8K95yau65vX6WxOflnkMWA62Fv1jUFge8wfd2G1C22tmgruK+8O/QFsK7jOXdmgXBlp1IbCw8qiwy7jHfbkSNbJkQctycHFRZQYa18vrEZXL6P2cZhQVPR910166nMMasjOu+11vEEBj0tSEoClF+VywSGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aQUt2rp9oz3tdeVJtQAX8cD9qp4g4PKYqEcKSTCPZUCT12C+kB1QnHgXgzJXoxKDF9+e9tweq1zMhVbnguATZI04Vbzm6tc/ezRV8l470i/jTgGoFBa9/jb9NRgC9+XJ1uQ9grBqQ0XKHLiK0ILBoUQkIfPWtauH1PmyRzl3Sxk= Received: by 10.143.16.9 with SMTP id t9mr1347108wfi.107.1197631374989; Fri, 14 Dec 2007 03:22:54 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 03:22:54 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 11:22:54 +0000 From: "George Tsirtsis" To: "Julien Laganier" Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: <200712131647.14533.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712131647.14533.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Julien, I am not entirly happy with your updated text. Now it appears as if only Ryuji and Ahmad talked about this issue on the mike. It also appears that Ryuji agreed with Ahmad which I do not think it is true (he just agreed with Ahmad's 2nd comment). My reccolection is that I disagreed with Ahmad on the mike while at least some of Sri, Vijay, and Hesham also talked on the issue (you listened again to the audio, so you maybe remember better?). In any case, one way to correct the minutes without all of us loosing too much time on it, is to remove the entire discussion following Ryuji's comment and replace it with "Various people: some discussion regarding whether we need to support this in this draft or not." In any case the minutes are not supposed to be a transcript of the actual conversation but they just suppose to capture the essence of the meeting. Here are then how the minutes would look: "Ryuji: Last issue is about simultaneous home/foreign links. This has been discussed for some time now. There is now consensus to support this but no yet agreement on how to do it. (two options summarized) Various people: some discussion regarding whether we need to support this in this draft or not. Ahmad: Also, regarding the status code when multiple care of address registration fails, I suggest that whenever any of the BID fails registration, the BA should use a new status code less than 128 to indicate to the MN that registration was successful but some BID failed registration in order for the MN to check which BID has failed. If all registered correctly, HA should always use status zero. Ryuji: Ok." On Dec 13, 2007 3:47 PM, Julien Laganier wrote: > Hello Ahmad and others, > > Thanks Ahmad for reviewing the minutes, this is certainly helpful to > ensure they accurately reflect the meeting discussions. Thanks also to > our notes takers, this is a difficult task and it is unavoidable that > sometimes mistakes are made. > > I listened carefully to the recorded audio from our 1st session: > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > accurately the discussion that took place (between 1:23 and 1:46 in the > record). I am proposing the updated text below (I condensed your > comments Ahmad, hope I got them right). > > Now a question to people that were in the meeting or listened to the > recorded audio: Do you agree with the proposed change? > > Thanks. > > --julien > > ----------------------------- > Ryuji: George commented that maybe we should add IPv4 CoA support for > DSMIPv6 support > Alex: Disagree, why add new features > George: DSMIP is now being adopted by SDOs, and there is no rush for > this, so lets do it correctly > Ryuji: Other comment from George is why bulk registrations with CNs > are excluded. There was consensous against this before. > George, unlike last issue I am not convinced this is necessary to > support. It was just not clear why this is not supported while > reading the draft. > Ryuji: yes so it was to keep the protocol simple. > Ryuji: Last issue is about simultaneous home/foreign links. This has > been discussed for some time now. There is now consensus to support > this but no yet agreement on how to do it. (two options summarized) > Ahmad: Addressing this scenario is probably not required at this point > and options look messy. Also, supporting this scenario would be a > violation of RFC3775 which requires the MN to send a de-registration BU > as soon as it realizes that it is on a home link. Can we limit the > draft to multiple care-of address registration for now. > Ahmad: Also, regarding the status code when multiple care of address > registration fails, I suggest that whenever any of the BID fails > registration, the BA should use a new status code less than 128 to > indicate to the MN that registration was successful but some > BID failed registration in order for the MN to check which BID has > failed. If all registered correctly, HA should always use status > zero. > Ryuji: Ok. > Various people: some discussion regarding whether we need to support > this in this draft or not. > ----------------------------- > > > On Thursday 13 December 2007, Ahmad Muhanna wrote: > > Hi Chairs/All, > > > > Please find some comments below. > > > > Regards, > > Ahmad > > > > > > - Multiple Care-of Addresses Registration > > Ryuji Wakikawa - 20 min > > draft-ietf-monami6-multiplecoa-04 > > > > Ryuji: George commented that maybe we should add IPv4 CoA support for > > DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no rush for > > this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to > > support. It was just not clear why this is not supported while > > reading the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links. This has > > been discussed for some time now. There is now consensus to support > > this but no yet agreement on how to do it. (two options summarized) > > > > Various: some discussion regarding whether we need to support this in > > this draft or not. Seems that the answer is yes > > > > [Ahmad] > > I am not sure about the above conclusion at this point of the > > meeting. Under various, I assume that my comments should have been > > listed which were as follows: > > > > 1. I think that addressing this scenario is probably not required at > > this point and options look messy. I also raised the issue if > > supporting this scenario, will that be a violation of RFC3775 which > > requires the MN to send a de-registration BU as soon as it realizes > > that it is on a home link. {I do not recall Ryuji answering that > > point but some other folks mentioned that it is not which was not > > clear to me} > > > > 2. I also made a comment regarding the status code when multiple care > > of address registration fails. I suggested that whenever any of the > > BID fails registration, the BA should use a new status code less than > > 128 to indicate to the MN that registration was successful but some > > BID failed registration in order for the MN to check which BID has > > failed. If all registered correctly, HA should always use status > > zero. {Ryuji agreed with that comment} > > > > 3. Also, I do not think the conclusion of that "various" was YES. > > > > Cheers! > > > > > -----Original Message----- > > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > > Sent: Wednesday, December 12, 2007 9:15 AM > > > To: mext@ietf.org > > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > > > Folks, > > > > > > Minutes of the meeting are available there: > > > > > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > > > Thanks. > > > > > > --julien > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 07:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39J9-00066V-Ct; Fri, 14 Dec 2007 07:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J39J8-00066Q-N9 for mext@ietf.org; Fri, 14 Dec 2007 07:06:22 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J39J6-0003EH-88 for mext@ietf.org; Fri, 14 Dec 2007 07:06:22 -0500 Received: by nf-out-0910.google.com with SMTP id d21so814806nfb.39 for ; Fri, 14 Dec 2007 04:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=mYR5PNpv+/D0eBUy6R3GN62ONSDO9lLBVftQzUNCkIQ=; b=feqQVdBiy2XkYtaZrIxukdNvWq1FbqGLxdT+hKggxaJmKItzh3Igyv3rPmDuklpCChgF8NAodfWY+E+G5pEJ6/BJBNXFFxUgoXtuzfvOSJiGKJlCNHc/7NR69w+TRJ5XzeQbZIDdQr8QKfMUWdgFGTtjjn3UYcupmfUkybrO3gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=mmgKO+8xV3r6D1JUH5KGGF6gEYnsEh4FcZ4hmLbJFnHyjjCt69IbveicGHDksm2KpofghBZQYiwRQqi1W+iu4181cq6Pd/PxFbfJeL1S/6/CudH1ZMZtQ+55pcskFQt2eD0VSOYO/mtpaBeuQGubngEIBZFz0YYy1m6/IcR+fr4= Received: by 10.78.206.9 with SMTP id d9mr3927656hug.9.1197633976155; Fri, 14 Dec 2007 04:06:16 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f4sm648093nfh.2007.12.14.04.06.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2007 04:06:15 -0800 (PST) From: Julien Laganier To: "George Tsirtsis" Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Fri, 14 Dec 2007 13:06:25 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712131647.14533.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712141306.26246.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, On Friday 14 December 2007, George Tsirtsis wrote: > Julien, > > I am not entirly happy with your updated text. Now it appears as if > only Ryuji and Ahmad talked about this issue on the mike. It also > appears that Ryuji agreed with Ahmad which I do not think it is true > (he just agreed with Ahmad's 2nd comment). My reccolection is that I > disagreed with Ahmad on the mike while at least some of Sri, Vijay, > and Hesham also talked on the issue (you listened again to the audio, > so you maybe remember better?). Yes, others talked on the issue, some of their comments are captured in what follows the excerpt Ahmad wanted to modify (I did not posted the follow-up originally since nobody asked to modify it): Suresh: the issue is simple and the solution is simple if we do not try to be too clever. If the HNP is not on-link then the issue goes away Gerardo Giaretta: This is useful scenario. It is actually very likely that if you are multihoming, one of the links is likely to be your home link Kaigo: I also support this to be included in the draft. Prefer the home CoA option Suresh: It is not always easy to generate a home-CoA Sri: Not sure if this should be solved in this draft. Marcelo: There seems to be agreement to support DSMIP, not to support Bulk Registrations, and not clear agreement on the multihoming with home link issue. Will review discussion on the list to determine how to proceed. > In any case, one way to correct the minutes without all of us loosing > too much time on it, is to remove the entire discussion following > Ryuji's comment and replace it with "Various people: some discussion > regarding whether we need to support this in this draft or not." That would be fine with me. Let's see what others (Ahmad?) think. --julien > In any case the minutes are not supposed to be a transcript of the > actual conversation but they just suppose to capture the essence of > the meeting. Here are then how the minutes would look: > > "Ryuji: Last issue is about simultaneous home/foreign links. This has > been discussed for some time now. There is now consensus to support > this but no yet agreement on how to do it. (two options summarized) > > Various people: some discussion regarding whether we need to support > this in this draft or not. > > Ahmad: Also, regarding the status code when multiple care of address > registration fails, I suggest that whenever any of the BID fails > registration, the BA should use a new status code less than 128 to > indicate to the MN that registration was successful but some > BID failed registration in order for the MN to check which BID has > failed. If all registered correctly, HA should always use status > zero. > Ryuji: Ok." > > On Dec 13, 2007 3:47 PM, Julien Laganier wrote: > > Hello Ahmad and others, > > > > Thanks Ahmad for reviewing the minutes, this is certainly helpful > > to ensure they accurately reflect the meeting discussions. Thanks > > also to our notes takers, this is a difficult task and it is > > unavoidable that sometimes mistakes are made. > > > > I listened carefully to the recorded audio from our 1st session: > > > > > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > > accurately the discussion that took place (between 1:23 and 1:46 in > > the record). I am proposing the updated text below (I condensed > > your comments Ahmad, hope I got them right). > > > > Now a question to people that were in the meeting or listened to > > the recorded audio: Do you agree with the proposed change? > > > > Thanks. > > > > --julien > > > > ----------------------------- > > Ryuji: George commented that maybe we should add IPv4 CoA support > > for DSMIPv6 support > > Alex: Disagree, why add new features > > George: DSMIP is now being adopted by SDOs, and there is no rush > > for this, so lets do it correctly > > Ryuji: Other comment from George is why bulk registrations with CNs > > are excluded. There was consensous against this before. > > George, unlike last issue I am not convinced this is necessary to > > support. It was just not clear why this is not supported while > > reading the draft. > > Ryuji: yes so it was to keep the protocol simple. > > Ryuji: Last issue is about simultaneous home/foreign links. This > > has been discussed for some time now. There is now consensus to > > support this but no yet agreement on how to do it. (two options > > summarized) Ahmad: Addressing this scenario is probably not > > required at this point and options look messy. Also, supporting > > this scenario would be a violation of RFC3775 which requires the MN > > to send a de-registration BU as soon as it realizes that it is on a > > home link. Can we limit the draft to multiple care-of address > > registration for now. > > Ahmad: Also, regarding the status code when multiple care of > > address registration fails, I suggest that whenever any of the BID > > fails registration, the BA should use a new status code less than > > 128 to indicate to the MN that registration was successful but some > > BID failed registration in order for the MN to check which BID has > > failed. If all registered correctly, HA should always use status > > zero. > > Ryuji: Ok. > > Various people: some discussion regarding whether we need to > > support this in this draft or not. > > ----------------------------- > > > > On Thursday 13 December 2007, Ahmad Muhanna wrote: > > > Hi Chairs/All, > > > > > > Please find some comments below. > > > > > > Regards, > > > Ahmad > > > > > > > > > - Multiple Care-of Addresses Registration > > > Ryuji Wakikawa - 20 min > > > draft-ietf-monami6-multiplecoa-04 > > > > > > Ryuji: George commented that maybe we should add IPv4 CoA support > > > for DSMIPv6 support > > > Alex: Disagree, why add new features > > > George: DSMIP is now being adopted by SDOs, and there is no rush > > > for this, so lets do it correctly > > > Ryuji: Other comment from George is why bulk registrations with > > > CNs are excluded. There was consensous against this before. > > > George, unlike last issue I am not convinced this is necessary to > > > support. It was just not clear why this is not supported while > > > reading the draft. > > > Ryuji: yes so it was to keep the protocol simple. > > > Ryuji: Last issue is about simultaneous home/foreign links. This > > > has been discussed for some time now. There is now consensus to > > > support this but no yet agreement on how to do it. (two options > > > summarized) > > > > > > Various: some discussion regarding whether we need to support > > > this in this draft or not. Seems that the answer is yes > > > > > > [Ahmad] > > > I am not sure about the above conclusion at this point of the > > > meeting. Under various, I assume that my comments should have > > > been listed which were as follows: > > > > > > 1. I think that addressing this scenario is probably not required > > > at this point and options look messy. I also raised the issue if > > > supporting this scenario, will that be a violation of RFC3775 > > > which requires the MN to send a de-registration BU as soon as it > > > realizes that it is on a home link. {I do not recall Ryuji > > > answering that point but some other folks mentioned that it is > > > not which was not clear to me} > > > > > > 2. I also made a comment regarding the status code when multiple > > > care of address registration fails. I suggested that whenever any > > > of the BID fails registration, the BA should use a new status > > > code less than 128 to indicate to the MN that registration was > > > successful but some BID failed registration in order for the MN > > > to check which BID has failed. If all registered correctly, HA > > > should always use status zero. {Ryuji agreed with that comment} > > > > > > 3. Also, I do not think the conclusion of that "various" was YES. > > > > > > Cheers! > > > > > > > -----Original Message----- > > > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > > > Sent: Wednesday, December 12, 2007 9:15 AM > > > > To: mext@ietf.org > > > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > > > > > Folks, > > > > > > > > Minutes of the meeting are available there: > > > > > > > > > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > > > > > Thanks. > > > > > > > > --julien > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LenorachevroletKyle@google.je Fri Dec 14 10:24:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CPB-0003FN-QT; Fri, 14 Dec 2007 10:24:49 -0500 Received: from pool-70-17-93-212.res.east.verizon.net ([70.17.93.212] helo=lindsey.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3CPA-0000Ha-KE; Fri, 14 Dec 2007 10:24:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host34878415.google.je (8.13.1/8.13.1) with SMTP id xqsvKAe248.029976.IYY.iDy.3464168652424 for ; Fri, 14 Dec 2007 10:22:57 +0500 Message-ID: <701401c83e65$6e6a7a30$2e01a8c0@Lindsey> From: "Shawn Marcum" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_7010_01C83E65.6E6A7A30-- From mext-bounces@ietf.org Fri Dec 14 10:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CPY-0003IN-7W; Fri, 14 Dec 2007 10:25:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CPW-0003II-0a for mext@ietf.org; Fri, 14 Dec 2007 10:25:10 -0500 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3CPT-0007xw-Sj for mext@ietf.org; Fri, 14 Dec 2007 10:25:09 -0500 Received: by wr-out-0506.google.com with SMTP id 68so778756wra.13 for ; Fri, 14 Dec 2007 07:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XaqhqpVcL9qpYLKRih6KA1SgT8GVwIw7j8wkjqeWcac=; b=gNuFggbej9438XVsc4skkkRGpMsqnlJlujvNt/xtfZLJqDmkovN2wuLdRRObZxwLnVJXT7musnffnUtA9DOW5Onei5Z/U53kF0ZmXn5CpySojyKqBpbluk4lapSSBr1hUcJs+Umg8XR6QqiPuI2+8Fg0XT33gEG8NHwCiWr8SA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SKdH3e9mv0qUUYzEmwl8jvsNkL88AoBiAfNJzhu4vrat60YOICwxJ6u1CUVm6WvIKzIjveQ0lvZi7znBzm7gtsg7w6wY+dQfn9UEEcDYdguP6ig2VPVnjgsxDakBkH/Hl2mHVvuA1LAhRZU4UwJeBk5DAs9OiRFw1PCeJE9pjNI= Received: by 10.142.115.10 with SMTP id n10mr1522438wfc.95.1197645905235; Fri, 14 Dec 2007 07:25:05 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 07:25:05 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 15:25:05 +0000 From: "George Tsirtsis" To: "Julien Laganier" Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: <200712141306.26246.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712131647.14533.julien.IETF@laposte.net> <200712141306.26246.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hmmm, ok I missed that. Then I am ok with your suggested change since the complete thread actually presents a more balanced view than I thought from the subset of the minutes discussed earlier. Thanks George On Dec 14, 2007 12:06 PM, Julien Laganier wrote: > Hi George, > > On Friday 14 December 2007, George Tsirtsis wrote: > > Julien, > > > > I am not entirly happy with your updated text. Now it appears as if > > only Ryuji and Ahmad talked about this issue on the mike. It also > > appears that Ryuji agreed with Ahmad which I do not think it is true > > (he just agreed with Ahmad's 2nd comment). My reccolection is that I > > disagreed with Ahmad on the mike while at least some of Sri, Vijay, > > and Hesham also talked on the issue (you listened again to the audio, > > so you maybe remember better?). > > Yes, others talked on the issue, some of their comments are captured in > what follows the excerpt Ahmad wanted to modify (I did not posted the > follow-up originally since nobody asked to modify it): > > Suresh: the issue is simple and the solution is simple if we do not > try to be too clever. If the HNP is not on-link then the issue goes > away > Gerardo Giaretta: This is useful scenario. It is actually very likely > that if you are multihoming, one of the links is likely to be your home > link > Kaigo: I also support this to be included in the draft. Prefer the > home CoA option > Suresh: It is not always easy to generate a home-CoA > Sri: Not sure if this should be solved in this draft. > Marcelo: There seems to be agreement to support DSMIP, not to support > Bulk Registrations, and not clear agreement on the multihoming with > home link issue. Will review discussion on the list to determine how > to proceed. > > > In any case, one way to correct the minutes without all of us loosing > > too much time on it, is to remove the entire discussion following > > Ryuji's comment and replace it with "Various people: some discussion > > regarding whether we need to support this in this draft or not." > > That would be fine with me. Let's see what others (Ahmad?) think. > > --julien > > > > In any case the minutes are not supposed to be a transcript of the > > actual conversation but they just suppose to capture the essence of > > the meeting. Here are then how the minutes would look: > > > > "Ryuji: Last issue is about simultaneous home/foreign links. This has > > been discussed for some time now. There is now consensus to support > > this but no yet agreement on how to do it. (two options summarized) > > > > Various people: some discussion regarding whether we need to support > > this in this draft or not. > > > > Ahmad: Also, regarding the status code when multiple care of address > > registration fails, I suggest that whenever any of the BID fails > > registration, the BA should use a new status code less than 128 to > > indicate to the MN that registration was successful but some > > BID failed registration in order for the MN to check which BID has > > failed. If all registered correctly, HA should always use status > > zero. > > Ryuji: Ok." > > > > On Dec 13, 2007 3:47 PM, Julien Laganier > wrote: > > > Hello Ahmad and others, > > > > > > Thanks Ahmad for reviewing the minutes, this is certainly helpful > > > to ensure they accurately reflect the meeting discussions. Thanks > > > also to our notes takers, this is a difficult task and it is > > > unavoidable that sometimes mistakes are made. > > > > > > I listened carefully to the recorded audio from our 1st session: > > > > > > > > > > > > and I agree the excerpt of the minutes Ahmad sent do not reflect > > > accurately the discussion that took place (between 1:23 and 1:46 in > > > the record). I am proposing the updated text below (I condensed > > > your comments Ahmad, hope I got them right). > > > > > > Now a question to people that were in the meeting or listened to > > > the recorded audio: Do you agree with the proposed change? > > > > > > Thanks. > > > > > > --julien > > > > > > ----------------------------- > > > Ryuji: George commented that maybe we should add IPv4 CoA support > > > for DSMIPv6 support > > > Alex: Disagree, why add new features > > > George: DSMIP is now being adopted by SDOs, and there is no rush > > > for this, so lets do it correctly > > > Ryuji: Other comment from George is why bulk registrations with CNs > > > are excluded. There was consensous against this before. > > > George, unlike last issue I am not convinced this is necessary to > > > support. It was just not clear why this is not supported while > > > reading the draft. > > > Ryuji: yes so it was to keep the protocol simple. > > > Ryuji: Last issue is about simultaneous home/foreign links. This > > > has been discussed for some time now. There is now consensus to > > > support this but no yet agreement on how to do it. (two options > > > summarized) Ahmad: Addressing this scenario is probably not > > > required at this point and options look messy. Also, supporting > > > this scenario would be a violation of RFC3775 which requires the MN > > > to send a de-registration BU as soon as it realizes that it is on a > > > home link. Can we limit the draft to multiple care-of address > > > registration for now. > > > Ahmad: Also, regarding the status code when multiple care of > > > address registration fails, I suggest that whenever any of the BID > > > fails registration, the BA should use a new status code less than > > > 128 to indicate to the MN that registration was successful but some > > > BID failed registration in order for the MN to check which BID has > > > failed. If all registered correctly, HA should always use status > > > zero. > > > Ryuji: Ok. > > > Various people: some discussion regarding whether we need to > > > support this in this draft or not. > > > ----------------------------- > > > > > > On Thursday 13 December 2007, Ahmad Muhanna wrote: > > > > Hi Chairs/All, > > > > > > > > Please find some comments below. > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > - Multiple Care-of Addresses Registration > > > > Ryuji Wakikawa - 20 min > > > > draft-ietf-monami6-multiplecoa-04 > > > > > > > > Ryuji: George commented that maybe we should add IPv4 CoA support > > > > for DSMIPv6 support > > > > Alex: Disagree, why add new features > > > > George: DSMIP is now being adopted by SDOs, and there is no rush > > > > for this, so lets do it correctly > > > > Ryuji: Other comment from George is why bulk registrations with > > > > CNs are excluded. There was consensous against this before. > > > > George, unlike last issue I am not convinced this is necessary to > > > > support. It was just not clear why this is not supported while > > > > reading the draft. > > > > Ryuji: yes so it was to keep the protocol simple. > > > > Ryuji: Last issue is about simultaneous home/foreign links. This > > > > has been discussed for some time now. There is now consensus to > > > > support this but no yet agreement on how to do it. (two options > > > > summarized) > > > > > > > > Various: some discussion regarding whether we need to support > > > > this in this draft or not. Seems that the answer is yes > > > > > > > > [Ahmad] > > > > I am not sure about the above conclusion at this point of the > > > > meeting. Under various, I assume that my comments should have > > > > been listed which were as follows: > > > > > > > > 1. I think that addressing this scenario is probably not required > > > > at this point and options look messy. I also raised the issue if > > > > supporting this scenario, will that be a violation of RFC3775 > > > > which requires the MN to send a de-registration BU as soon as it > > > > realizes that it is on a home link. {I do not recall Ryuji > > > > answering that point but some other folks mentioned that it is > > > > not which was not clear to me} > > > > > > > > 2. I also made a comment regarding the status code when multiple > > > > care of address registration fails. I suggested that whenever any > > > > of the BID fails registration, the BA should use a new status > > > > code less than 128 to indicate to the MN that registration was > > > > successful but some BID failed registration in order for the MN > > > > to check which BID has failed. If all registered correctly, HA > > > > should always use status zero. {Ryuji agreed with that comment} > > > > > > > > 3. Also, I do not think the conclusion of that "various" was YES. > > > > > > > > Cheers! > > > > > > > > > -----Original Message----- > > > > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > > > > Sent: Wednesday, December 12, 2007 9:15 AM > > > > > To: mext@ietf.org > > > > > Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > > > > > > > > > > Folks, > > > > > > > > > > Minutes of the meeting are available there: > > > > > > > > > > > > > > > > > > > > Please send to chairs corrections and/or add-ons, if any. > > > > > > > > > > Thanks. > > > > > > > > > > --julien > > > > > > > > > > _______________________________________________ > > > > > MEXT mailing list > > > > > MEXT@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 10:31:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CVm-00061p-MG; Fri, 14 Dec 2007 10:31:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CVl-000616-11 for mext@ietf.org; Fri, 14 Dec 2007 10:31:37 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3CVk-0000Um-Js for mext@ietf.org; Fri, 14 Dec 2007 10:31:36 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lBEFSBV07268; Fri, 14 Dec 2007 15:28:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Fri, 14 Dec 2007 09:31:25 -0600 Message-ID: In-Reply-To: <200712141306.26246.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Thread-Index: Acg+Se+o4aXKJK5/Sb+v2cjgrqbEFwAG+kWw References: <200712131647.14533.julien.IETF@laposte.net> <200712141306.26246.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , "George Tsirtsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >=20 > Yes, others talked on the issue, some of their comments are=20 > captured in what follows the excerpt Ahmad wanted to modify=20 > (I did not posted the follow-up originally since nobody asked=20 > to modify it): >=20 > Suresh: the issue is simple and the solution is simple if we=20 > do not try to be too clever. If the HNP is not on-link then=20 > the issue goes away Gerardo Giaretta: This is useful=20 > scenario. It is actually very likely that if you are=20 > multihoming, one of the links is likely to be your home link > Kaigo: I also support this to be included in the draft.=20 > Prefer the home CoA option > Suresh: It is not always easy to generate a home-CoA > Sri: Not sure if this should be solved in this draft. > Marcelo: There seems to be agreement to support DSMIP, not to=20 > support Bulk Registrations, and not clear agreement on the=20 > multihoming with home link issue. Will review discussion on=20 > the list to determine how to proceed. >=20 > > In any case, one way to correct the minutes without all of=20 > us loosing=20 > > too much time on it, is to remove the entire discussion following=20 > > Ryuji's comment and replace it with "Various people: some=20 > discussion=20 > > regarding whether we need to support this in this draft or not." >=20 > That would be fine with me. Let's see what others (Ahmad?) think. [Ahmad] Hi Julien, Since George agreed in his latest response to your original proposed change, I do not think I need to add anything here. Regards, Ahmad >=20 > --julien >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 10:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CkC-0004Ew-JU; Fri, 14 Dec 2007 10:46:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3CkA-0004Ep-GB for mext@ietf.org; Fri, 14 Dec 2007 10:46:30 -0500 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3CkA-0000C8-5g for mext@ietf.org; Fri, 14 Dec 2007 10:46:30 -0500 Received: by wr-out-0506.google.com with SMTP id 68so790773wra.13 for ; Fri, 14 Dec 2007 07:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Hy6ODUcCJddSO/g1Fz39DGaq9d31owdA90N0TDl7jD8=; b=lPAu9WgyKH3NKeS42DlGQSV4R5lGDty1GI4I4CB6iOX0KNlzAufnPAqOVjpILNg3bUhJumeXnv3pmv3rzhsKS7/8PPQqx/Mw8m7Z8cEU/mKZ5/dq5Aqpluzp3LHMeSmgZl8e2vlQQk7sf8Omho7GVoBLrZzuYh7iuI3hA31K0MM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IUKGRR5V5ecrQ3M52oXehgN/F8OZ2JSwXX3VTBf5XjOEPx1aBPghd7YLXr4/3+kTnpKm4z+vfpuU/vOlPI/1HNreNIyCHpuwm7YK28JdEaD3U09TWiQopxHIVLRVwJnv0xE2vFR9sOrg0AaAbL8NRL3IOoHVPZYKeJAr3W8HuW0= Received: by 10.142.80.7 with SMTP id d7mr1541543wfb.60.1197647188799; Fri, 14 Dec 2007 07:46:28 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 07:46:28 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 15:46:28 +0000 From: "George Tsirtsis" To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [MEXT] [RFC3775 changes] Site-local addresses X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Not sure if this has been discussed already so I thought I should ask first. Looking at RFC3775 I counted 8 mentions of site-local addresses, including section 4.6."Site-Local Addressability". Given the deprecated status of site local addresses (rfc3879) how do we want to handle these? Is someone else already dealing with this or shall I work on suggested text changes? George _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 12:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ECy-00082V-79; Fri, 14 Dec 2007 12:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ECx-0007z3-Bt for mext@ietf.org; Fri, 14 Dec 2007 12:20:19 -0500 Received: from wr-out-0506.google.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3ECw-0002pp-Ps for mext@ietf.org; Fri, 14 Dec 2007 12:20:19 -0500 Received: by wr-out-0506.google.com with SMTP id 68so840769wra.13 for ; Fri, 14 Dec 2007 09:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=CfnqHddT1zprvgeWBgcdn8aIkbSqMqV89R1/SbShUMU=; b=lto0CZ6sR1DZHK3MmDURNCQIOhqn2/c4J+GZjKkjtGGbcE8IXV678fg0IRIvbrGZon3Pph+r/py0ZFit4eaCnIncEuT0qzkYGchJfc5JPrY63Vi96F5p1RgZ25gznSc2aS8cl898viCY75wkFyE57PGxOEEvtMce8qE9mtlqGx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Q97MAn/1vsM8QitxzrYnnUuW6UwULXd5KpNhFV1j1pKjqAS07aNmOtqyFZEPZDu7QzWxSMpZ1zxP3kKvSZRp8q/KcaGG8osRANnxWGJWESt9rHN5hu6AQIpeh8mGnSTZRp0eoVP4CBZLA8rHvi/zHIfuA5f8YKfdm8WRwdZPbDw= Received: by 10.143.33.19 with SMTP id l19mr1004060wfj.9.1197652816775; Fri, 14 Dec 2007 09:20:16 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 09:20:16 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 17:20:16 +0000 From: "George Tsirtsis" To: rdroms@cisco.com, pthubert@cisco.co MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mext@ietf.org Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Ralph/Pascal, I was just reading your draft and have the following questions/suggestions. Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit confused WRT the Source Address an MR is supposed to use when sending DHCP messages for the purpose of prefix delegation. RFC3315 says that the end-node's Link-Local address MUST be used as source address unless the end node uses unicast (i.e., it already has a global address and already knows the DHCP Server Address). RFC3633 does not seem to contradict this. This seems a bit odd since Prefix Delegation may happen at any time after address allocation has taken place. In particular for DHCPv6 over MIPv6, the MN already has an HoA assigned, since HoA allocation is assumed to take place before MIPv6 can run. In that case, the MR should be able to use Source=HoA and Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever it is called :-). Is my understanding correct? Maybe Section 3.2. can be clarified accordingly? For similar reasons Section 3.7 should also be clarified. At the moment it gives the impression that DHCPv6 over MIPv6 can be used to get the HoA assigned. Strictly speaking this is only true during bootstrapping and only when the MN is at the home link or at least in a network associated with its home network (this is also called MIPv6 integrated scenario (see draft-ietf-mip6-bootstrapping-integrated-05.txt). Parameter configuration can, however, take place both at home link (natively) and at foreign links (over the MIPv6 tunnel). Regards George P.S.: BTW, I do not see how this document can be "Informational" in its current form, since it updates RFC3775 packet formats for DHAAD. On Dec 6, 2007 7:30 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, P. Thubert > Filename : draft-ietf-nemo-dhcpv6-pd-03.txt > Pages : 11 > Date : 2007-12-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 13:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3FIk-0006l7-NF; Fri, 14 Dec 2007 13:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3FIi-0006in-Vv for mext@ietf.org; Fri, 14 Dec 2007 13:30:20 -0500 Received: from web84107.mail.mud.yahoo.com ([68.142.206.194]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J3FIg-0004b4-ON for mext@ietf.org; Fri, 14 Dec 2007 13:30:20 -0500 Received: (qmail 88564 invoked by uid 60001); 14 Dec 2007 18:30:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=mYjcuGW3NUkMrYpNKekNB7/c0kABLXDwN/s6MM8xulAkWsA6H6oMsneaDDB9tvrygoFydpplKoDHaUX4lzoO+KpxJKl/P+l8KukQpCscD369hG4OPRgySwGKkLPwdZQ3oTcwj5biMdtQxp2CGYB8liR3J8FLO6UHlLLuP/b2NYM=; X-YMail-OSG: ELGHu6IVM1l.ooUPoXrehfw7NZjQ0UqD4wSzILFn8sY9F9VyA.FA1BgSClxpIiFIKrZafC6ZNYvRnaV3xfyxrLmZqhfM423_ukvvoumPdJJJqgM- Received: from [71.123.247.57] by web84107.mail.mud.yahoo.com via HTTP; Fri, 14 Dec 2007 10:30:17 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Fri, 14 Dec 2007 10:30:17 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt To: George Tsirtsis , rdroms@cisco.com, pthubert@cisco.co MIME-Version: 1.0 Message-ID: <19594.82390.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0925670627==" Errors-To: mext-bounces@ietf.org --===============0925670627== Content-Type: multipart/alternative; boundary="0-1035753766-1197657017=:82390" --0-1035753766-1197657017=:82390 Content-Type: text/plain; charset=us-ascii Apart from this problem George is indicating, I see conceptual problem in MR being a requesting router for DHCP PD. I think that HA should be the requesting router. Then we can use TJ's draft to send the prefix to MR. Regards, Behcet ----- Original Message ---- From: George Tsirtsis To: rdroms@cisco.com; pthubert@cisco.co Cc: mext@ietf.org Sent: Friday, December 14, 2007 11:20:16 AM Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt Hi Ralph/Pascal, I was just reading your draft and have the following questions/suggestions. Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit confused WRT the Source Address an MR is supposed to use when sending DHCP messages for the purpose of prefix delegation. RFC3315 says that the end-node's Link-Local address MUST be used as source address unless the end node uses unicast (i.e., it already has a global address and already knows the DHCP Server Address). RFC3633 does not seem to contradict this. This seems a bit odd since Prefix Delegation may happen at any time after address allocation has taken place. In particular for DHCPv6 over MIPv6, the MN already has an HoA assigned, since HoA allocation is assumed to take place before MIPv6 can run. In that case, the MR should be able to use Source=HoA and Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever it is called :-). Is my understanding correct? Maybe Section 3.2. can be clarified accordingly? For similar reasons Section 3.7 should also be clarified. At the moment it gives the impression that DHCPv6 over MIPv6 can be used to get the HoA assigned. Strictly speaking this is only true during bootstrapping and only when the MN is at the home link or at least in a network associated with its home network (this is also called MIPv6 integrated scenario (see draft-ietf-mip6-bootstrapping-integrated-05.txt). Parameter configuration can, however, take place both at home link (natively) and at foreign links (over the MIPv6 tunnel). Regards George P.S.: BTW, I do not see how this document can be "Informational" in its current form, since it updates RFC3775 packet formats for DHAAD. On Dec 6, 2007 7:30 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Mobility Working Group of the IETF. > > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, P. Thubert > Filename : draft-ietf-nemo-dhcpv6-pd-03.txt > Pages : 11 > Date : 2007-12-06 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --0-1035753766-1197657017=:82390 Content-Type: text/html; charset=us-ascii
Apart from this problem George is indicating, I see conceptual problem in MR being a requesting router for DHCP PD.

I think that HA should be the requesting router. Then we can use TJ's draft to send the prefix to MR.

Regards,

Behcet

----- Original Message ----
From: George Tsirtsis <tsirtsis@googlemail.com>
To: rdroms@cisco.com; pthubert@cisco.co
Cc: mext@ietf.org
Sent: Friday, December 14, 2007 11:20:16 AM
Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt

Hi Ralph/Pascal,

I was just reading your draft and have the following questions/suggestions.

Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit
confused WRT the Source Address an MR is supposed to use when sending
DHCP messages for the purpose of prefix delegation. RFC3315 says that
the end-node's Link-Local address MUST be used as source address
unless the end node uses unicast (i.e., it already has a global
address and already knows the DHCP Server Address). RFC3633 does not
seem to contradict this.

This seems a bit odd since Prefix Delegation may happen at any time
after address allocation has taken place. In particular for DHCPv6
over MIPv6, the MN already has an HoA assigned, since HoA allocation
is assumed to take place before MIPv6 can run. In that case, the MR
should be able to use Source=HoA and
Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever
it is called :-).

Is my understanding correct? Maybe Section 3.2. can be clarified accordingly?

For similar reasons Section 3.7 should also be clarified. At the
moment it gives the impression that DHCPv6 over MIPv6 can be used to
get the HoA assigned. Strictly speaking this is only true during
bootstrapping and only when the MN is at the home link or at least in
a network associated with its home network (this is also called MIPv6
integrated scenario (see
draft-ietf-mip6-bootstrapping-integrated-05.txt).
Parameter configuration can, however, take place both at home link
(natively) and  at foreign links (over the MIPv6 tunnel).

Regards
George
P.S.: BTW, I do not see how this document can be "Informational" in
its current form, since it updates RFC3775 packet formats for DHAAD.


On Dec 6, 2007 7:30 PM,  <Internet-Drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Mobility Working Group of the IETF.
>
>
>        Title          : DHCPv6 Prefix Delegation for NEMO
>        Author(s)      : R. Droms, P. Thubert
>        Filename        : draft-ietf-nemo-dhcpv6-pd-03.txt
>        Pages          : 11
>        Date            : 2007-12-06
>
> One aspect of network mobility support is the assignment of a prefix
> or prefixes to a Mobile Router (MR) for use on the links in the
> Mobile Network.  DHCPv6 prefix delegation can be used for this
> configuration task.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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.
>
>
>

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www1.ietf.org/mailman/listinfo/mext

--0-1035753766-1197657017=:82390-- --===============0925670627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0925670627==-- From Lovleen@putandtake.co.uk Fri Dec 14 13:34:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3FMz-0006J8-VJ for nemo-archive@lists.ietf.org; Fri, 14 Dec 2007 13:34:45 -0500 Received: from host22-227-dynamic.3-79-r.retail.telecomitalia.it ([79.3.227.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3FMx-0005Xb-TK for nemo-archive@lists.ietf.org; Fri, 14 Dec 2007 13:34:45 -0500 Received: from un5qy9a8ktbm94e ([112.156.146.106]:12443 "EHLO un5qy9a8ktbm94e" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host22-227-dynamic.3-79-r.retail.telecomitalia.it with ESMTP id S22ZKTYRIKDKGSEJ (ORCPT ); Fri, 14 Dec 2007 19:34:59 +0100 Message-ID: <3A76DCFB.4F8EE454@putandtake.co.uk> Date: Fri, 14 Dec 2007 19:34:35 +0100 From: "Lovleen Coussens" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: iliapul Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed no more limp dick, you'll be rock solid on virility pills http://www.ramsrace.com/
From mext-bounces@ietf.org Fri Dec 14 15:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HAb-0008PP-T4; Fri, 14 Dec 2007 15:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3HAY-0008OX-GJ; Fri, 14 Dec 2007 15:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3HAY-0008Bo-49; Fri, 14 Dec 2007 15:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0041126E80; Fri, 14 Dec 2007 20:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J3HAX-0007Za-TO; Fri, 14 Dec 2007 15:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 14 Dec 2007 15:30:01 -0500 X-Spam-Score: -1.2 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aero-reqs-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author(s) : W. Eddy, et al. Filename : draft-ietf-mext-aero-reqs-00.txt Pages : 24 Date : 2007-12-14 This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been review by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mext-aero-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mext-aero-reqs-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: <2007-12-14152813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mext-aero-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mext-aero-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-14152813.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --NextPart-- From ElmercatastrophicFields@leaderadvertiser.com Fri Dec 14 16:11:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Hp3-0000hV-6r; Fri, 14 Dec 2007 16:11:53 -0500 Received: from [89.7.78.138] (helo=familiar) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3Hp2-0002T3-Mq; Fri, 14 Dec 2007 16:11:52 -0500 Received: from fury by leaderadvertiser.com with SMTP id P7aBmvKVd0 for ; Fri, 14 Dec 2007 22:14:06 -0100 From: "Raul Chapman" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JG7-0004ln-Bg; Fri, 14 Dec 2007 17:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JG5-0004lb-Oa for mext@ietf.org; Fri, 14 Dec 2007 17:43:53 -0500 Received: from mail.critical.com ([64.246.137.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3JG4-00038i-7E for mext@ietf.org; Fri, 14 Dec 2007 17:43:53 -0500 Received: by mail.critical.com (Postfix, from userid 99) id 1B5B53A40C0; Fri, 14 Dec 2007 17:43:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on mail.critical.com X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from cardnote.critical.com (ip-83.critical.com [64.246.137.83]) by mail.critical.com (Postfix) with ESMTP id 548113A40BF; Fri, 14 Dec 2007 17:43:46 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Dec 2007 17:40:33 -0500 To: "Ivancic, William D. (GRC-RCN0)" , "marcelo bagnulo braun" , From: "Stuart W. Card" Subject: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071214224346.548113A40BF@mail.critical.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: zabele@alphatech.com X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org At 08:10 AM 12/10/2007, Ivancic, William D. (GRC-RCN0) wrote: >... >I have been polling the aeronautics industry on whether or not there is >strong desire (not requirement) for MR-to-MR route optimization. So far >I am not convinced there is such desire. Many of us feel MR-to-MR route >optimization would be more like a manet function (manemo) and a function >that is far into the future for aeronautics due to regulatory and other >issues... In the Airborne Networking efforts within the U.S. Air Force, the ability for a user aboard one aircraft to communicate with a user aboard a second aircraft, when those 2 aircraft have a direct wireless link between them, regardless of whether one or both aircraft currently have links with the ground infrastructure (and not using those links even if both are present, assuming the direct aircraft to aircraft link has better QoS or is otherwise preferred per policy over the air to ground to air route), is a requirement. Of course, this does not make it a requirement for the IETF generally nor for MEXT specifically; I just wanted you all to know what the USAF is doing, and that we have been trying to stick close to IETF standards efforts. Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 17:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JKs-0000De-Rk; Fri, 14 Dec 2007 17:48:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3JKq-0000DY-T3 for mext@ietf.org; Fri, 14 Dec 2007 17:48:48 -0500 Received: from mail.critical.com ([64.246.137.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3JKq-0004zq-H5 for mext@ietf.org; Fri, 14 Dec 2007 17:48:48 -0500 Received: by mail.critical.com (Postfix, from userid 99) id 773373A40C0; Fri, 14 Dec 2007 17:48:47 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on mail.critical.com X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from cardnote.critical.com (ip-83.critical.com [64.246.137.83]) by mail.critical.com (Postfix) with ESMTP id CF4B63A40BF; Fri, 14 Dec 2007 17:48:44 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Dec 2007 17:46:11 -0500 To: "Ivancic, William D. (GRC-RCN0)" , , From: "Stuart W. Card" Subject: re: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071214224844.CF4B63A40BF@mail.critical.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: zabele@alphatech.com X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org At 02:40 PM 12/10/2007, Ivancic, William D. (GRC-RCN0) wrote: >... >If one is thinking that the passenger services would be over a satellite >link, the MR-to-MR route optimization would certainly be nice. However, >if the consumer is a business passenger and they have to tie back into >the corporate network via VPNs, all route optimizations may be wasted as >the security mechanisms may force an unoptimized route... In our Air Force work, communications may be over direct air-to-air Line Of Sight (LOS) links (UHF, VHF), direct air-to-air Beyond LOS links (HF), direct air-to-air LOS Extension links (various types of SATCOM), or multi-hop air-to-ground-to air routes. Indeed, often security policy may force quadrangle routing, but not always, and the penalty may not be just poor performance, but service outage. Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 14 18:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KJN-00064O-Du; Fri, 14 Dec 2007 18:51:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3KJL-00063H-B4 for mext@ietf.org; Fri, 14 Dec 2007 18:51:19 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3KJK-0004UC-LU for mext@ietf.org; Fri, 14 Dec 2007 18:51:19 -0500 Received: by nz-out-0506.google.com with SMTP id n1so745907nzf.4 for ; Fri, 14 Dec 2007 15:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pNXiGiWXPLfNCyNx0lSzjikLND2xsY1AXzRJGUe2lMY=; b=Ql38V706kogeKyofMF2Og6g6dapAqEJV+BsrZNnzz9kwvKiI3I4HHh/lO2T0MYKEdLFZBCZrHMgICD5aISlIlE9xVxi69Lq8JIpUripKdTACxD3/6wM9ZB6tvHqrg+7NlSO9PpCFFSZIRDrpz0+wPsgCtn15GDhCpjB8pNQ62Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QZjOkhcCwekipt1LIdARgE/P9+TC4hTSmIJ7erk+rijfS790O16GexwrEBweI8ar6fdmB048Ud/HvGV3DeJrt/2ktzgOkCMlaky6EWBkWIOv25izvBxkDxdnvvoUAqqzDsRBFbgT/AuoW1YTh9dL8ngeNxLu6erf955MGIHG9Mk= Received: by 10.142.135.9 with SMTP id i9mr1011839wfd.211.1197676276557; Fri, 14 Dec 2007 15:51:16 -0800 (PST) Received: by 10.142.11.11 with HTTP; Fri, 14 Dec 2007 15:51:16 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 23:51:16 +0000 From: "George Tsirtsis" To: "Behcet Sarikaya" Subject: Re: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt In-Reply-To: <19594.82390.qm@web84107.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19594.82390.qm@web84107.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Just to be clear. I did not identify any problem in the draft.I think the draft works well and I think it is a clean solution for this issue. My e-mail attempts to clarify the draft, nothing more. George P.S.: I am also correcting Pascal's e-mail address which I managed to misspell earlier. On Dec 14, 2007 6:30 PM, Behcet Sarikaya wrote: > > Apart from this problem George is indicating, I see conceptual problem in MR > being a requesting router for DHCP PD. > > I think that HA should be the requesting router. Then we can use TJ's draft > to send the prefix to MR. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: George Tsirtsis > To: rdroms@cisco.com; pthubert@cisco.co > Cc: mext@ietf.org > Sent: Friday, December 14, 2007 11:20:16 AM > Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt > > Hi Ralph/Pascal, > > I was just reading your draft and have the following questions/suggestions. > > Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit > confused WRT the Source Address an MR is supposed to use when sending > DHCP messages for the purpose of prefix delegation. RFC3315 says that > the end-node's Link-Local address MUST be used as source address > unless the end node uses unicast (i.e., it already has a global > address and already knows the DHCP Server Address). RFC3633 does not > seem to contradict this. > > This seems a bit odd since Prefix Delegation may happen at any time > after address allocation has taken place. In particular for DHCPv6 > over MIPv6, the MN already has an HoA assigned, since HoA allocation > is assumed to take place before MIPv6 can run. In that case, the MR > should be able to use Source=HoA and > Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever > it is called :-). > > Is my understanding correct? Maybe Section 3.2. can be clarified > accordingly? > > For similar reasons Section 3.7 should also be clarified. At the > moment it gives the impression that DHCPv6 over MIPv6 can be used to > get the HoA assigned. Strictly speaking this is only true during > bootstrapping and only when the MN is at the home link or at least in > a network associated with its home network (this is also called MIPv6 > integrated scenario (see > draft-ietf-mip6-bootstrapping-integrated-05.txt). > Parameter configuration can, however, take place both at home link > (natively) and at foreign links (over the MIPv6 tunnel). > > Regards > George > P.S.: BTW, I do not see how this document can be "Informational" in > its current form, since it updates RFC3775 packet formats for DHAAD. > > > On Dec 6, 2007 7:30 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Network Mobility Working Group of the > IETF. > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > Author(s) : R. Droms, P. Thubert > > Filename : draft-ietf-nemo-dhcpv6-pd-03.txt > > Pages : 11 > > Date : 2007-12-06 > > > > One aspect of network mobility support is the assignment of a prefix > > or prefixes to a Mobile Router (MR) for use on the links in the > > Mobile Network. DHCPv6 prefix delegation can be used for this > > configuration task. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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. > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From teelew@liquiflo.com Sat Dec 15 04:39:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3TUv-0003mc-LV; Sat, 15 Dec 2007 04:39:53 -0500 Received: from [88.254.192.62] (helo=[88.254.192.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3TUu-0008Qf-Da; Sat, 15 Dec 2007 04:39:53 -0500 Received: from [88.254.192.62] by smtp-nju.kodiaksys.com; Sat, 15 Dec 2007 11:39:45 +0200 Date: Sat, 15 Dec 2007 11:39:45 +0200 From: "Noemi Wiseman" X-Mailer: The Bat! (v3.0) Educational Reply-To: teelew@liquiflo.com X-Priority: 3 (Normal) Message-ID: <392209109.66341249740696@liquiflo.com> To: mpls@lists.ietf.org Subject: Hey Baby its Angie MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071214-0, 14.12.2007), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Hi I saw your profile on-line Maybe we can chat today? email me at Kristen@SimOldGlory.info and I will reply with a Picture and info right away. From ScottcloakroomWright@zawodny.com Sat Dec 15 07:15:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3Vve-0005TU-Oh; Sat, 15 Dec 2007 07:15:38 -0500 Received: from 84-72-97-55.dclient.hispeed.ch ([84.72.97.55] helo=maja123abc1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3Vvc-0000D8-J7; Sat, 15 Dec 2007 07:15:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host82913210.zawodny.com (8.13.1/8.13.1) with SMTP id 33eDusta03.759110.Eyz.ufw.7028832621608 for ; Sat, 15 Dec 2007 13:14:47 -0100 Message-ID: <4ffa01c83f14$2b355370$2201a8c0@Maja123abc1> From: "Jerry Lewis" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4FF6_01C83F14.2B355370-- From mext-bounces@ietf.org Sat Dec 15 09:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3YNk-00059c-QT; Sat, 15 Dec 2007 09:52:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3YNj-0004yX-78 for mext@ietf.org; Sat, 15 Dec 2007 09:52:47 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3YNi-0004JC-Lj for mext@ietf.org; Sat, 15 Dec 2007 09:52:46 -0500 Received: from [192.168.1.131] (245.45.217.87.dynamic.jazztel.es [87.217.45.245])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 937C82B8317;Sat, 15 Dec 2007 15:52:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B84BB5E-4194-4CB6-884A-8006F5A95533@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Sat, 15 Dec 2007 15:52:54 +0100 To: Gerardo Giaretta X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.9302 TC:1F TRN:11 TV:5.0.1023(15608.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mext@ietf.org Subject: [MEXT] draft-ietf-mip6-aaa-ha-goals next steps X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, according to what we agreed in the MEXT meeting in Vancouver, a new version of draft-ietf-mip6-aaa-ha-goals should be submitted right after Vancouver and we will issue a WGLC for this document once this is done We are suppose to submit this document to the IESG for Feb 2008 When do you think we will be able to issue the WGLC? Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Dec 15 09:57:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3YS8-0004i7-Im; Sat, 15 Dec 2007 09:57:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3YS7-0004hJ-Ee for mext@ietf.org; Sat, 15 Dec 2007 09:57:19 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3YS7-0004YB-0r for mext@ietf.org; Sat, 15 Dec 2007 09:57:19 -0500 Received: from [192.168.1.131] (245.45.217.87.dynamic.jazztel.es [87.217.45.245])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id 97D3229A25A;Sat, 15 Dec 2007 15:57:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <684E0932-B401-4E27-9921-F4D7C0745A9F@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Sat, 15 Dec 2007 15:57:20 +0100 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.1115 TC:1F TRN:9 TV:5.0.1023(15608.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mext@ietf.org Subject: [MEXT] draft-ietf-mip6-radius-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, According to what we talked in the IETF70 meeting, editors are working in new version of this draft. We are supposed to deliver this document to the IESG in Jun 2008, so we wtill have time, but could the editors tell what is the expected schedule for this document? Thanks, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Dec 15 10:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ZH9-0003Zm-7H; Sat, 15 Dec 2007 10:50:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3ZH7-0003Za-PS for mext@ietf.org; Sat, 15 Dec 2007 10:50:01 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3ZH6-0006HD-9h for mext@ietf.org; Sat, 15 Dec 2007 10:50:01 -0500 Received: from [192.168.1.131] (245.45.217.87.dynamic.jazztel.es [87.217.45.245])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id EA67729034B;Sat, 15 Dec 2007 16:49:58 +0100 (CET) In-Reply-To: <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> References: <200712131647.14533.julien.IETF@laposte.net><47618C8C.6040302@az airenet.com> <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Sat, 15 Dec 2007 16:50:07 +0100 To: Keigo Aso X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-33.0996 TC:02 TRN:93 TV:5.0.1023(15608.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Keigo, El 14/12/2007, a las 10:02, Keigo Aso escribi=F3: > Hello, > > In the last meeting, actually the author mentioned that there was > concensus to support for the simultaneous usage of the home and =20 > foreign > attached interfaces, and then there were apparently more supports > for this scenario during the session also. > The chair(Marcelo) also said in his email that he had reached the same > conclusion based on the session and ML review, and clearly =20 > indicated the next > step as the WG. I think i need to clarify this. I think there was more support for =20 supporting this case, but there was not clear consesus for it and we =20 need more discussion. Since one of the arguments for this is the =20 complexity of the approach needed, i think we can understand more the =20= complexity of the solution if we have a text describing the solution, =20= hence why i have requested to provide some concrete text to describe =20 this. So, it is not that i think we have agreed on this issue, is just that =20= i think that such text would help us to move forward with the discussion Just for completeness, i attach both of my comments below In the minutes it is clearly stated: Marcelo: There seems to be agreement to support DSMIP, not to support Bulk Registrations, and not clear agreement on the multihoming with home link issue. Will review discussion on the list to determine how to proceed In addition, in the mail that i sent to move forward with this issue, =20= i wrote: - With respect to the case of multihoming with a visited network and =20 the home network, there was no clear consesus on the meeting but it =20 seemed that there was more support for supporting this case. I have =20 reached the same conclusion after reading the mailing list. So the =20 next steps for this are that the author or other partis to provide =20 text for this and propose it to the ml. Regards, marcelo > So, I think there is no need to go back to before again > even though the minutes is updated. > > I agree with George and Vijay. Supporting this scenario is very =20 > important for > practical MCoA specification because MCoA MN can connect to the =20 > network > which is defined in RFC3775. > > Regards, > Keigo > > On Thu, 13 Dec 2007 11:48:28 -0800 > Vijay Devarapalli wrote: > >> Julien, >> >> I believe Ryuji was trying to get folks to pick one solution for >> the scenario where the mobile node is attached to the home link >> and visited link at the same time. We have a few options. >> >> I don't understand Sri's and Ahmad's concerns about complexity. >> We do have an issue here, so it needs to be addressed. I agree >> with George, if there is a home link to which the MN can attach >> to, then this scenario is bound to happen. >> >> Vijay >> >> Julien Laganier wrote: >>> Hello Ahmad and others, >>> >>> Thanks Ahmad for reviewing the minutes, this is certainly helpful to >>> ensure they accurately reflect the meeting discussions. Thanks =20 >>> also to >>> our notes takers, this is a difficult task and it is unavoidable =20 >>> that >>> sometimes mistakes are made. >>> >>> I listened carefully to the recorded audio from our 1st session: >>> >>> >>> >>> and I agree the excerpt of the minutes Ahmad sent do not reflect >>> accurately the discussion that took place (between 1:23 and 1:46 =20 >>> in the >>> record). I am proposing the updated text below (I condensed your >>> comments Ahmad, hope I got them right). >>> >>> Now a question to people that were in the meeting or listened to the >>> recorded audio: Do you agree with the proposed change? >>> >>> Thanks. >>> >>> --julien >>> >>> ----------------------------- >>> Ryuji: George commented that maybe we should add IPv4 CoA support =20= >>> for >>> DSMIPv6 support >>> Alex: Disagree, why add new features >>> George: DSMIP is now being adopted by SDOs, and there is no rush for >>> this, so lets do it correctly >>> Ryuji: Other comment from George is why bulk registrations with CNs >>> are excluded. There was consensous against this before. >>> George, unlike last issue I am not convinced this is necessary to >>> support. It was just not clear why this is not supported while >>> reading the draft. >>> Ryuji: yes so it was to keep the protocol simple. >>> Ryuji: Last issue is about simultaneous home/foreign links. This has >>> been discussed for some time now. There is now consensus to support >>> this but no yet agreement on how to do it. (two options summarized) >>> Ahmad: Addressing this scenario is probably not required at this =20 >>> point >>> and options look messy. Also, supporting this scenario would be a >>> violation of RFC3775 which requires the MN to send a de-=20 >>> registration BU >>> as soon as it realizes that it is on a home link. Can we limit the >>> draft to multiple care-of address registration for now. >>> Ahmad: Also, regarding the status code when multiple care of address >>> registration fails, I suggest that whenever any of the BID fails >>> registration, the BA should use a new status code less than 128 to >>> indicate to the MN that registration was successful but some >>> BID failed registration in order for the MN to check which BID has >>> failed. If all registered correctly, HA should always use status >>> zero. >>> Ryuji: Ok. >>> Various people: some discussion regarding whether we need to support >>> this in this draft or not. >>> ----------------------------- >>> >>> On Thursday 13 December 2007, Ahmad Muhanna wrote: >>>> Hi Chairs/All, >>>> >>>> Please find some comments below. >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>> - Multiple Care-of Addresses Registration >>>> Ryuji Wakikawa - 20 min >>>> draft-ietf-monami6-multiplecoa-04 >>>> >>>> Ryuji: George commented that maybe we should add IPv4 CoA =20 >>>> support for >>>> DSMIPv6 support >>>> Alex: Disagree, why add new features >>>> George: DSMIP is now being adopted by SDOs, and there is no rush =20= >>>> for >>>> this, so lets do it correctly >>>> Ryuji: Other comment from George is why bulk registrations with CNs >>>> are excluded. There was consensous against this before. >>>> George, unlike last issue I am not convinced this is necessary to >>>> support. It was just not clear why this is not supported while >>>> reading the draft. >>>> Ryuji: yes so it was to keep the protocol simple. >>>> Ryuji: Last issue is about simultaneous home/foreign links. This =20= >>>> has >>>> been discussed for some time now. There is now consensus to support >>>> this but no yet agreement on how to do it. (two options summarized) >>>> >>>> Various: some discussion regarding whether we need to support =20 >>>> this in >>>> this draft or not. Seems that the answer is yes >>>> >>>> [Ahmad] >>>> I am not sure about the above conclusion at this point of the >>>> meeting. Under various, I assume that my comments should have been >>>> listed which were as follows: >>>> >>>> 1. I think that addressing this scenario is probably not =20 >>>> required at >>>> this point and options look messy. I also raised the issue if >>>> supporting this scenario, will that be a violation of RFC3775 which >>>> requires the MN to send a de-registration BU as soon as it realizes >>>> that it is on a home link. {I do not recall Ryuji answering that >>>> point but some other folks mentioned that it is not which was not >>>> clear to me} >>>> >>>> 2. I also made a comment regarding the status code when multiple =20= >>>> care >>>> of address registration fails. I suggested that whenever any of the >>>> BID fails registration, the BA should use a new status code less =20= >>>> than >>>> 128 to indicate to the MN that registration was successful but some >>>> BID failed registration in order for the MN to check which BID has >>>> failed. If all registered correctly, HA should always use status >>>> zero. {Ryuji agreed with that comment} >>>> >>>> 3. Also, I do not think the conclusion of that "various" was YES. >>>> >>>> Cheers! >>>> >>>>> -----Original Message----- >>>>> From: Julien Laganier [mailto:julien.IETF@laposte.net] >>>>> Sent: Wednesday, December 12, 2007 9:15 AM >>>>> To: mext@ietf.org >>>>> Subject: [MEXT] Minutes of MEXT sessions at IETF-70 >>>>> >>>>> Folks, >>>>> >>>>> Minutes of the meeting are available there: >>>>> >>>>> >>>>> >>>>> Please send to chairs corrections and/or add-ons, if any. >>>>> >>>>> Thanks. >>>>> >>>>> --julien >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From MontesmuttyLang@creationlive.com Sat Dec 15 11:36:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3a0A-0005up-5H; Sat, 15 Dec 2007 11:36:34 -0500 Received: from bzq-84-109-43-34.red.bezeqint.net ([84.109.43.34] helo=171452225a2784) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3a08-0007cd-RG; Sat, 15 Dec 2007 11:36:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host99187474.creationlive.com (8.13.1/8.13.1) with SMTP id VpLx3ntn12.945383.odS.lzT.7906669742506 for ; Mon, 10 Dec 2007 06:35:29 +0800 Message-ID: <1b76201c83b39$fef78c70$222b6d54@171452225a2784> From: "Mickey Hensley" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1B75E_01C83B39.FEF78C70-- From mext-bounces@ietf.org Sat Dec 15 13:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3beK-0002Fv-TV; Sat, 15 Dec 2007 13:22:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3beJ-0002Fk-NF for mext@ietf.org; Sat, 15 Dec 2007 13:22:07 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3beI-0004XB-6R for mext@ietf.org; Sat, 15 Dec 2007 13:22:07 -0500 Received: from [163.117.203.35] (unknown [163.117.203.35])by smtp03.uc3m.es (Postfix) with ESMTP id B78A628BAED; Sat, 15 Dec 2007 19:22:01 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] [RFC3775 changes] Site-local addresses Date: Sat, 15 Dec 2007 17:25:20 +0100 To: George Tsirtsis X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.1157 TC:1F TRN:22 TV:5.0.1023(15608.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, El 14/12/2007, a las 16:46, George Tsirtsis escribi=F3: > Not sure if this has been discussed already so I thought I should =20 > ask first. > > Looking at RFC3775 I counted 8 mentions of site-local addresses, > including section 4.6."Site-Local Addressability". Given the > deprecated status of site local addresses (rfc3879) how do we want to > handle these? > > Is someone else already dealing with this not that i am aware of > or shall I work on suggested > text changes? > please do Thanks, marcelo > George > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From RefugionamesakeMayer@sciencedirect.com Sun Dec 16 07:11:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3sLN-0002Rg-Sq; Sun, 16 Dec 2007 07:11:41 -0500 Received: from gfo11.internetdsl.tpnet.pl ([83.12.144.11] helo=jurekced43d766) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3sLN-0006sZ-BX; Sun, 16 Dec 2007 07:11:41 -0500 Received: from graywacke by sciencedirect.com with SMTP id 1ifpHd7vdu for ; Sun, 16 Dec 2007 13:11:24 -0100 From: "Refugio Cote" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3sO8-0007vA-6q; Sun, 16 Dec 2007 07:14:32 -0500 Received: from [84.15.32.62] (helo=athlon64) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3sO7-0006w3-0b; Sun, 16 Dec 2007 07:14:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host51979348.stata.com (8.13.1/8.13.1) with SMTP id 2PoAyPWn04.468083.ITO.gt4.9394247530043 for ; Sun, 16 Dec 2007 14:14:06 -0200 Message-ID: <634f01c83fdd$3a850ea0$6140100a@athlon64> From: "Dewitt Reilly" To: Subject: Confirmation link Date: Sun, 16 Dec 2007 14:14:06 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_634B_01C83FDD.3A850EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_634B_01C83FDD.3A850EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_634B_01C83FDD.3A850EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_634B_01C83FDD.3A850EA0-- From mext-bounces@ietf.org Sun Dec 16 08:43:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3tmP-0000Vy-Bl; Sun, 16 Dec 2007 08:43:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3tmN-0000Vm-6H for mext@ietf.org; Sun, 16 Dec 2007 08:43:39 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3tmL-00017z-6m for mext@ietf.org; Sun, 16 Dec 2007 08:43:39 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1413604rvb.49 for ; Sun, 16 Dec 2007 05:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=R0+0wr85K/PoXcnTuRsVtMby8/rNNWDAImfRyUx8yk0=; b=vNJhN4lbB/BkxcQSHhHu75aPM2fTDrRwS9BOHF/0aofZpTzoTymMLbPDO7ldUEm+GESECAw4nD3PAo1VJS/aVMR6nxPYR9olKOF/OhkM/g1Z2wTZuogBLLHb77zDVUpHIvKgFHRDIvBlbzYDJSwAuQRKti60zTt6RoenfXQacGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ANbc4gkzZolQA+TkKJBRAnys1Nl+eb+cKZ927ahuP6nfOobj1p9HZd8jqRvknf14KWoyPLYxHnancnogWBpgQgdhyUWOJXAjirKzKFf39Vm1bvDYGJe02ydflrrg4DXFbcdfh/xuSslkA2F8Hu2rIHtSOiaWkQzw8IqnifQzZhA= Received: by 10.141.99.4 with SMTP id b4mr3184344rvm.270.1197812616284; Sun, 16 Dec 2007 05:43:36 -0800 (PST) Received: by 10.141.180.1 with HTTP; Sun, 16 Dec 2007 05:43:36 -0800 (PST) Message-ID: <1d38a3350712160543l34cbf51fmd5f6aad1c2b852ac@mail.gmail.com> Date: Sun, 16 Dec 2007 21:43:36 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" In-Reply-To: <78EC6672-9343-421A-B870-51954F397BCE@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78EC6672-9343-421A-B870-51954F397BCE@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mext@ietf.org, Ryuji Wakikawa , Julien Laganier Subject: [MEXT] review of draft-ietf-monami6-multiplecoa-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Dear authors, I think that this document has been been in good shape for publication. Although I have several comments regarding to IPsec/IKE. 1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN, Since RFC 4306 do require check based on the destination address. In that case, MCOA may be able to use only 1 CoA for this direction packet delivery. If this is true, MCOA could support multiple interfaces for MN to HA direction, but could support only 1 HA to MN connection. Would be better if it could be described more clearly. 2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA, >From reading, it seems fine without source address checking. But I am not sure whethere there is already implementation which could verify it is workable or not. 3) about which interface MIP6 will use in MCOA scenario, it is mainly about how to operate SPD, but this document may lack basic description about it. 4) As the basic RFC 3775, RFC 4877 lacks interface between MIP6 and IKEv2 this document may also need consider it. Many thanks -Hui _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 16 10:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vIm-0007KJ-QQ; Sun, 16 Dec 2007 10:21:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vIl-0007Je-4H for mext@ietf.org; Sun, 16 Dec 2007 10:21:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J3vIj-0007nB-DZ for mext@ietf.org; Sun, 16 Dec 2007 10:21:11 -0500 Received: (qmail invoked by alias); 16 Dec 2007 15:21:07 -0000 Received: from p54985EA8.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.94.168] by mail.gmx.net (mp039) with SMTP; 16 Dec 2007 16:21:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+z5Js+3suzaGBJQzAZGQp425iEYKGXyDkVLbOO/h YqsmVkjG4D6J7X Message-ID: <4765426E.6000408@gmx.net> Date: Sun, 16 Dec 2007 16:21:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] draft-ietf-mip6-aaa-ha-goals next steps References: <2B84BB5E-4194-4CB6-884A-8006F5A95533@it.uc3m.es> In-Reply-To: <2B84BB5E-4194-4CB6-884A-8006F5A95533@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: OPS ADs , dime@ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, I would appreciate faster processing given that the corresponding DIME working group documents already went through their WGLCs. Hence, I would suggest to * "motivate" the draft authors to submit a new draft version immediately, as promised * start a WGLC asap * submit the document in Jan. 2008 to the IESG This is not a complicate document with 5 draft authors. The last draft version was published 2006-09-12 despite repeated announcements that a new draft version is imminent. I cannot believe that none of the authors had time to made the minor editorial changes in more than a year!!! I am not amused. Ciao Hannes PS: I put Dan, the responsible AD for DIME, on CC to let him know that the processing of our DIME mobility documents might experience delays during IESG processing due to this requirements draft. marcelo bagnulo braun wrote: > Hi, > > according to what we agreed in the MEXT meeting in Vancouver, a new > version of draft-ietf-mip6-aaa-ha-goals should be submitted right > after Vancouver and we will issue a WGLC for this document once this > is done > > We are suppose to submit this document to the IESG for Feb 2008 > > When do you think we will be able to issue the WGLC? > > Thanks, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Dec 16 11:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vux-00058R-31; Sun, 16 Dec 2007 11:00:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vuv-00058G-Nc for mext@ietf.org; Sun, 16 Dec 2007 11:00:37 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3vuv-0005G8-1Y for mext@ietf.org; Sun, 16 Dec 2007 11:00:37 -0500 Received: (qmail invoked by alias); 16 Dec 2007 16:00:35 -0000 Received: from p54985EA8.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.94.168] by mail.gmx.net (mp006) with SMTP; 16 Dec 2007 17:00:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/FO/xjHlbF82rVzlSZRHQtLJKwRePd/MT0jCVYLQ 9ifP1+UsLXG3WA Message-ID: <47654BAE.9090604@gmx.net> Date: Sun, 16 Dec 2007 17:00:46 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun References: <684E0932-B401-4E27-9921-F4D7C0745A9F@it.uc3m.es> In-Reply-To: <684E0932-B401-4E27-9921-F4D7C0745A9F@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org Subject: [MEXT] Re: draft-ietf-mip6-radius-02 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org We would like to ensure that the Diameter and the RADIUS documents are in sync. We are about to finish the Diameter documents and have started to update the corresponding RADIUS document. We have already pushed a -03 version (see http://tools.ietf.org/html/draft-ietf-mip6-radius-03) but more work is needed. We expect the work to be finished (i.e., ready for WGLC) in Jan 2008. This WGLC would have to be posted also to the RADEXT mailing list to ensure proper review from the RADIUS experts. Ciao Hannes marcelo bagnulo braun wrote: > Hi, > > According to what we talked in the IETF70 meeting, editors are working > in new version of this draft. > We are supposed to deliver this document to the IESG in Jun 2008, so > we wtill have time, but could the editors tell what is the expected > schedule for this document? > > Thanks, marcelo > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From erbaturwhf@irving-coppellent.com Sun Dec 16 12:03:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3wuA-0004cI-7K for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 12:03:54 -0500 Received: from p54a3ec80.dip.t-dialin.net ([84.163.236.128]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3wu9-0006jr-K0 for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 12:03:54 -0500 Received: from stefans-pc ([135.117.87.33]:1919 "EHLO stefans-pc" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p54A3EC80.dip.t-dialin.net with ESMTP id S22QQJIKSGFDKKOQ (ORCPT ); Sun, 16 Dec 2007 18:04:18 +0100 Message-ID: Date: Sun, 16 Dec 2007 18:03:52 +0100 From: "sfsdfds erbatur" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: daeh-dni Content-Type: multipart/alternative; boundary="------------010402040304030004000604" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------010402040304030004000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit With this medicine, you'll penetrate all the tightest asses in the town! Improve your cock and enjoy your new life. http://www.lakbma.com/ --------------010402040304030004000604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit With this medicine, you'll penetrate all the tightest asses in the
town! Improve your cock and enjoy your new life. http://www.lakbma.com/
--------------010402040304030004000604-- From saikumar3shepherd67@p5com.com Sun Dec 16 13:30:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3yG3-0003VM-0F for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 13:30:35 -0500 Received: from dhcp-077-251-245-214.chello.nl ([77.251.245.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3yG2-0005Lf-H2 for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 13:30:34 -0500 Message-ID: <000901c84011$04464d42$c35a9993@rxghb> From: "cyrillus kieu" To: "Eldon Leblanc" Subject: exclusive watches, affordable prices rolex Date: Sun, 16 Dec 2007 16:43:10 +0000 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Perfectly crafted luxury timepieces...the finest of products at the LOWEST prices!! http://webtyrosxmas.net/ From MavisgrabHooks@presidentialscholars.org Sun Dec 16 13:33:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3yJB-0001ay-2U; Sun, 16 Dec 2007 13:33:49 -0500 Received: from 82-39-92-38.cable.ubr04.jarr.blueyonder.co.uk ([82.39.92.38] helo=yourpfvr8cvzkb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3yJA-0005WZ-7G; Sun, 16 Dec 2007 13:33:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host93686873.presidentialscholars.org (8.13.1/8.13.1) with SMTP id WGYx6vA818.306038.Kv1.mLX.6650860146148 for ; Sun, 16 Dec 2007 18:33:05 +0000 Message-ID: <60e8601c84012$2a617c40$265c2752@yourpfvr8cvzkb> From: "Martina Person" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_60E82_01C84012.2A617C40-- From mext-bounces@ietf.org Sun Dec 16 14:47:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3zSi-0005t2-0C; Sun, 16 Dec 2007 14:47:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3zSg-0005so-Pf for mext@ietf.org; Sun, 16 Dec 2007 14:47:42 -0500 Received: from web84110.mail.mud.yahoo.com ([68.142.206.197]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3zSf-000098-CL for mext@ietf.org; Sun, 16 Dec 2007 14:47:42 -0500 Received: (qmail 10802 invoked by uid 60001); 16 Dec 2007 19:47:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=VXw1Wk1WNDeazZr2AMvmXTOD1zdg+KbrNBFDlRm5rYiuUEKiipkj5zSMKfsFqvrjv62Ny/aDhWbuiR18cZ1lOdJeK5XY5jdvHJkCFIODOCsYUtTY0mR01evWwlgbgGm8zaLsYhCqYn0oyvGN2f7XzJprhGvfB1nj93QqIeuOyxU=; X-YMail-OSG: xjUxVAwVM1kGls4ra1mHL50JvW9QiZAO5ccPTYjcqjcXKA5Yakh64IdqMpTJwbSBcdeH1OcK_6Ka_Ui.JNlGARiYyUD7D6wKmbqQtXduxL3wUHEg2Gs- Received: from [71.123.247.57] by web84110.mail.mud.yahoo.com via HTTP; Sun, 16 Dec 2007 11:47:35 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Sun, 16 Dec 2007 11:47:35 -0800 (PST) From: Behcet Sarikaya Subject: Re: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt To: George Tsirtsis MIME-Version: 1.0 Message-ID: <467951.10439.qm@web84110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1352461133==" Errors-To: mext-bounces@ietf.org --===============1352461133== Content-Type: multipart/alternative; boundary="0-1131677060-1197834455=:10439" --0-1131677060-1197834455=:10439 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: George Tsirtsis To: Behcet Sarikaya Cc: rdroms@cisco.com; pthubert@cisco.com; mext@ietf.org Sent: Friday, December 14, 2007 5:51:16 PM Subject: Re: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt Just to be clear. I did not identify any problem in the draft.I think the draft works well and I think it is a clean solution for this issue. [behcet] Just look at the archive. People pointed to several problems in this draft. DHCP PD for nemo is a distinct application, I am not sure what is the "clean" solution? My e-mail attempts to clarify the draft, nothing more. George P.S.: I am also correcting Pascal's e-mail address which I managed to misspell earlier. On Dec 14, 2007 6:30 PM, Behcet Sarikaya wrote: > > Apart from this problem George is indicating, I see conceptual problem in MR > being a requesting router for DHCP PD. > > I think that HA should be the requesting router. Then we can use TJ's draft > to send the prefix to MR. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: George Tsirtsis > To: rdroms@cisco.com; pthubert@cisco.co > Cc: mext@ietf.org > Sent: Friday, December 14, 2007 11:20:16 AM > Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt > > Hi Ralph/Pascal, > > I was just reading your draft and have the following questions/suggestions. > > Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit > confused WRT the Source Address an MR is supposed to use when sending > DHCP messages for the purpose of prefix delegation. RFC3315 says that > the end-node's Link-Local address MUST be used as source address > unless the end node uses unicast (i.e., it already has a global > address and already knows the DHCP Server Address). RFC3633 does not > seem to contradict this. > > This seems a bit odd since Prefix Delegation may happen at any time > after address allocation has taken place. In particular for DHCPv6 > over MIPv6, the MN already has an HoA assigned, since HoA allocation > is assumed to take place before MIPv6 can run. In that case, the MR > should be able to use Source=HoA and > Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever > it is called :-). > > Is my understanding correct? Maybe Section 3.2. can be clarified > accordingly? > > For similar reasons Section 3.7 should also be clarified. At the > moment it gives the impression that DHCPv6 over MIPv6 can be used to > get the HoA assigned. Strictly speaking this is only true during > bootstrapping and only when the MN is at the home link or at least in > a network associated with its home network (this is also called MIPv6 > integrated scenario (see > draft-ietf-mip6-bootstrapping-integrated-05.txt). > Parameter configuration can, however, take place both at home link > (natively) and at foreign links (over the MIPv6 tunnel). > > Regards > George > P.S.: BTW, I do not see how this document can be "Informational" in > its current form, since it updates RFC3775 packet formats for DHAAD. > > > On Dec 6, 2007 7:30 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Network Mobility Working Group of the > IETF. > > > > > > Title : DHCPv6 Prefix Delegation for NEMO > > Author(s) : R. Droms, P. Thubert > > Filename : draft-ietf-nemo-dhcpv6-pd-03.txt > > Pages : 11 > > Date : 2007-12-06 > > > > One aspect of network mobility support is the assignment of a prefix > > or prefixes to a Mobile Router (MR) for use on the links in the > > Mobile Network. DHCPv6 prefix delegation can be used for this > > configuration task. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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. > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > > --0-1131677060-1197834455=:10439 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: George Tsirtsis <tsirtsis@googlemail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: rdroms@cisco.com; pthubert@cisco.com; mext@ietf.org
Sent: Friday, December 14, 2007 5:51:16 PM
Subject: Re: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt

Just to be clear. I did not identify any problem in the draft.I think
the draft works well and I think it is a clean solution for this
issue.
[behcet] Just look at the archive. People pointed to several problems in this draft.
DHCP PD for nemo is a distinct application, I am not sure what is the "clean" solution?

My e-mail attempts to clarify the draft, nothing more.

George
P.S.: I am also correcting Pascal's e-mail address which I managed to
misspell earlier.

On Dec 14, 2007 6:30 PM, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
>
> Apart from this problem George is indicating, I see conceptual problem in MR
> being a requesting router for DHCP PD.
>
> I think that HA should be the requesting router. Then we can use TJ's draft
> to send the prefix to MR.
>
> Regards,
>
> Behcet
>
>
>
> ----- Original Message ----
> From: George Tsirtsis <tsirtsis@googlemail.com>
> To: rdroms@cisco.com; pthubert@cisco.co
> Cc: mext@ietf.org
> Sent: Friday, December 14, 2007 11:20:16 AM
> Subject: [MEXT] Questions on draft-ietf-nemo-dhcpv6-pd-03.txt
>
>  Hi Ralph/Pascal,
>
> I was just reading your draft and have the following questions/suggestions.
>
> Reading (admittedly a bit quickly) RFC3315 and RFC3633 I am a bit
> confused WRT the Source Address an MR is supposed to use when sending
> DHCP messages for the purpose of prefix delegation. RFC3315 says that
> the end-node's Link-Local address MUST be used as source address
> unless the end node uses unicast (i.e., it already has a global
> address and already knows the DHCP Server Address). RFC3633 does not
> seem to contradict this.
>
> This seems a bit odd since Prefix Delegation may happen at any time
> after address allocation has taken place. In particular for DHCPv6
> over MIPv6, the MN already has an HoA assigned, since HoA allocation
> is assumed to take place before MIPv6 can run. In that case, the MR
> should be able to use Source=HoA and
> Destination=ALL-DHCP-Relays-and-servers-Mcast address... or whatever
> it is called :-).
>
> Is my understanding correct? Maybe Section 3.2. can be clarified
> accordingly?
>
> For similar reasons Section 3.7 should also be clarified. At the
> moment it gives the impression that DHCPv6 over MIPv6 can be used to
> get the HoA assigned. Strictly speaking this is only true during
> bootstrapping and only when the MN is at the home link or at least in
> a network associated with its home network (this is also called MIPv6
> integrated scenario (see
> draft-ietf-mip6-bootstrapping-integrated-05.txt).
> Parameter configuration can, however, take place both at home link
> (natively) and  at foreign links (over the MIPv6 tunnel).
>
> Regards
> George
> P.S.: BTW, I do not see how this document can be "Informational" in
> its current form, since it updates RFC3775 packet formats for DHAAD.
>
>
> On Dec 6, 2007 7:30 PM,  <Internet-Drafts@ietf.org> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Network Mobility Working Group of the
> IETF.
> >
> >
> >        Title          : DHCPv6 Prefix Delegation for NEMO
> >        Author(s)      : R. Droms, P. Thubert
> >        Filename        : draft-ietf-nemo-dhcpv6-pd-03.txt
> >        Pages          : 11
> >        Date            : 2007-12-06
> >
> > One aspect of network mobility support is the assignment of a prefix
> > or prefixes to a Mobile Router (MR) for use on the links in the
> > Mobile Network.  DHCPv6 prefix delegation can be used for this
> > configuration task.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-03.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > i-d-announce-request@ietf.org with the word unsubscribe in the body of
> > the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > 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-nemo-dhcpv6-pd-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-nemo-dhcpv6-pd-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.
> >
> >
> >
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mext
>
>

--0-1131677060-1197834455=:10439-- --===============1352461133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1352461133==-- From AnthonyshallotHill@playerappreciate.com Sun Dec 16 16:36:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41A8-00036k-A2; Sun, 16 Dec 2007 16:36:40 -0500 Received: from 84.121.113.201.dyn.user.ono.com ([84.121.113.201] helo=jose0ecf8850e7) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J41A7-0003uy-Cx; Sun, 16 Dec 2007 16:36:40 -0500 Received: from louver by playerappreciate.com with SMTP id 1YoaF0D2kp for ; Sun, 16 Dec 2007 22:35:52 -0100 From: "Gary Adams" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41Ar-0003Fb-Iu for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 16:37:25 -0500 Received: from adsl-89-217-183-122.adslplus.ch ([89.217.183.122] helo=adsl-84-227-201-254.adslplus.ch) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J41An-0003vh-33 for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 16:37:25 -0500 Received: from acer-ce034387c0 ([171.182.194.40] helo=acer-ce034387c0) by adsl-84-227-201-254.adslplus.ch ( sendmail 8.13.3/8.13.1) with esmtpa id 1rCHws-000FXS-Qd for nemo-archive@lists.ietf.org; Sun, 16 Dec 2007 22:37:46 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Dec 2007 22:37:17 +0100 To: nemo-archive@lists.ietf.org From: "Shree Cricchio" Subject: resugges Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Penetrate that ass with your new improved tool! http://laoid.com/ From NoahmagnesiaMoran@tripod.com Sun Dec 16 20:04:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J44PA-0003e6-Ec; Sun, 16 Dec 2007 20:04:24 -0500 Received: from 213.37.226.55.dyn.user.ono.com ([213.37.226.55] helo=oscarooknvhx5d) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J44P9-0008L5-IW; Sun, 16 Dec 2007 20:04:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host22175473.tripod.com (8.13.1/8.13.1) with SMTP id KUIT79cb49.100197.466.Osr.9242529976179 for ; Mon, 17 Dec 2007 02:03:50 -0100 Message-ID: From: "Rogelio Frank" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_FEF65_01C84048.C0FA9610-- From weruhc@bragano.com Sun Dec 16 20:43:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4517-00086v-91; Sun, 16 Dec 2007 20:43:37 -0500 Received: from [117.9.43.166] (helo=[117.9.43.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4516-0006pp-7f; Sun, 16 Dec 2007 20:43:37 -0500 Received: from [117.9.43.166] by barrierm241.nike.com; Mon, 17 Dec 2007 02:39:33 +0800 Message-ID: <01c84056$0e386080$a62b0975@weruhc> From: "Holman" To: Subject: Hey there Date: Mon, 17 Dec 2007 02:39:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hey Baby I was wondering if you wanted to maybe chat and exchange Pictures? I read your Profile online and you seem very intresting Email me at Shay@SimOldGlory.info and I will reply with a Picture and info right away. From mext-bounces@ietf.org Sun Dec 16 21:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J45KY-0006GF-OF; Sun, 16 Dec 2007 21:03:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J45KX-0006G7-K9 for mext@ietf.org; Sun, 16 Dec 2007 21:03:41 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J45KV-000760-Jt for mext@ietf.org; Sun, 16 Dec 2007 21:03:41 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id lBH23Zww022599; Mon, 17 Dec 2007 11:03:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id lBH23aI15780; Mon, 17 Dec 2007 11:03:36 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id lBH23ZO17571; Mon, 17 Dec 2007 11:03:35 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 10:03:10 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Mon, 17 Dec 2007 10:03:07 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Mon, 17 Dec 2007 10:03:07 +0800 From: "Benjamin Lim" To: "'marcelo bagnulo braun'" Subject: RE: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Mon, 17 Dec 2007 10:03:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-reply-to: Thread-Index: Acg/Mi5uBZo9EMHMQrOKXXts0w8W+gBHaOZg Message-ID: X-OriginalArrivalTime: 17 Dec 2007 02:03:10.0947 (UTC) FILETIME=[F99D8330:01C84050] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, One small comment. =8==8<=8== > In the minutes it is clearly stated: > > Marcelo: There seems to be agreement to support DSMIP, not to > support Bulk Registrations, and not clear agreement on the > multihoming with home link issue. Will review discussion on > the list to determine how to proceed [Ben] Just caught this from Marcelo's reply. If I'm not wrong, the consensus was not to support bulk registration to CN right? I believe that bulk registration to HA is still supported. If so, I propose modifying this text in the minutes to "..., not to support Bulk Registration to CN, ..." Regards, Benjamin Lim > > In addition, in the mail that i sent to move forward with > this issue, i wrote: > > - With respect to the case of multihoming with a visited > network and the home network, there was no clear consesus on > the meeting but it seemed that there was more support for > supporting this case. I have reached the same conclusion > after reading the mailing list. So the next steps for this > are that the author or other partis to provide text for this > and propose it to the ml. > > Regards, marcelo =8==8<=8== _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ColemanwanderAlston@whatsyourstatus.com Sun Dec 16 23:44:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J47pp-0002Lf-60; Sun, 16 Dec 2007 23:44:09 -0500 Received: from 71-37-184-245.hlna.qwest.net ([71.37.184.245] helo=your60e4b8f107.domain.actdsltmp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J47po-0003t6-Qm; Sun, 16 Dec 2007 23:44:09 -0500 Received: from giblet by whatsyourstatus.com with SMTP id gERMvc6Cw1 for ; Sun, 16 Dec 2007 21:43:46 +0700 From: "Ahmad Alston" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4AyG-0005YM-6P; Mon, 17 Dec 2007 03:05:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4AyE-0005Xv-5E for mext@ietf.org; Mon, 17 Dec 2007 03:05:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4AyD-0003rB-48 for mext@ietf.org; Mon, 17 Dec 2007 03:05:02 -0500 X-IronPort-AV: E=Sophos;i="4.24,175,1196636400"; d="scan'208";a="1041398" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2007 09:05:00 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBH84xqd003037; Mon, 17 Dec 2007 09:04:59 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBH848mo013524; Mon, 17 Dec 2007 08:04:38 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 09:04:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) Date: Mon, 17 Dec 2007 09:04:18 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04EECA85@xmb-ams-337.emea.cisco.com> In-Reply-To: <20071214224346.548113A40BF@mail.critical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) Thread-Index: Acg+ouZZy4Z5xBSvQoq4eZtNh7OvXwB4AxYg From: "Pascal Thubert (pthubert)" To: "Stuart W. Card" , "Ivancic, William D. (GRC-RCN0)" , "marcelo bagnulo braun" , "Teco Boot" X-OriginalArrivalTime: 17 Dec 2007 08:04:30.0883 (UTC) FILETIME=[73DD3730:01C84083] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2330; t=1197878699; x=1198742699; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20aero=20MR-MR=20RO=20(was=3A=20[MEXT]=20 Personal=20Mobile=20router=20reqs) |Sender:=20; bh=/B7uZI8f5yvKG81QcQzPzPuLiv+ozfGbD2b2pCXZLm8=; b=EyNrC36EQ/BgwrMvhrFZGYBNSMb20Tn12reWE+Q+Hatf7UfaY4klpAS4bS pBJgC/AO5vm5JV6VyRVIGsgJhs1+gvSnPZxM3AJl1vornLVHmK1OULvMzsuF zaIE2tR8fC; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -3.8 (---) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: zabele@alphatech.com, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Stuart: Are you aware of the tentative work around MANEMO? Right now this has not turned into a working group (yet?), but there = were succcesful preBOFs in Prague. The overall idea is to enable MANET and NEMO coordination so that they = benefit from one another. Pascal =20 >-----Original Message----- >From: Stuart W. Card [mailto:stu.card@critical.com]=20 >Sent: vendredi 14 d=E9cembre 2007 23:41 >To: Ivancic, William D. (GRC-RCN0); marcelo bagnulo braun;=20 >mext@ietf.org >Cc: zabele@alphatech.com >Subject: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) > >At 08:10 AM 12/10/2007, Ivancic, William D. (GRC-RCN0) wrote: >>... >>I have been polling the aeronautics industry on whether or=20 >not there is=20 >>strong desire (not requirement) for MR-to-MR route optimization. So=20 >>far I am not convinced there is such desire. Many of us feel=20 >MR-to-MR=20 >>route optimization would be more like a manet function (manemo) and a=20 >>function that is far into the future for aeronautics due to=20 >regulatory=20 >>and other issues... > >In the Airborne Networking efforts within the U.S. Air Force,=20 >the ability for a user aboard one aircraft to communicate with=20 >a user aboard a second aircraft, when those 2 aircraft have a=20 >direct wireless link between them, regardless of whether one=20 >or both aircraft currently have links with the ground=20 >infrastructure (and not using those links even if both are=20 >present, assuming the direct aircraft to aircraft link has=20 >better QoS or is otherwise preferred per policy over the air=20 >to ground to air route), is a requirement. Of course, this=20 >does not make it a requirement for the IETF generally nor for=20 >MEXT specifically; I just wanted you all to know what the USAF=20 >is doing, and that we have been trying to stick close to IETF=20 >standards efforts. > > >Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. >* Creativity * Diversity * Expertise * Flexibility * Integrity=20 >* Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 >315-793-0248 x141 FAX -9710 www.critical.com > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 03:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Blx-0006MN-P6; Mon, 17 Dec 2007 03:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Blw-0006MF-Ba for mext@ietf.org; Mon, 17 Dec 2007 03:56:24 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Blv-0004cO-Qt for mext@ietf.org; Mon, 17 Dec 2007 03:56:24 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1026026nfb.39 for ; Mon, 17 Dec 2007 00:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=vM2gdLm1ILbC6S6nbtoP5CT+H+bR1mIAySsYzaDe36c=; b=fM+fsCVvtocPeaEfsJ6zCCwp0Ro6rjp9/nZsoe1kod65QqcQcGmnNtOHhNiC7hs1uNT56wJa+jbGbXJZ2jYyKZ3CIhdmkbdapUjAqZaxAIaEwP+EkJusuIZlxBJr8/cvQ8vGV/7VKWpgKcGcuqgTn0Q6Nn1Z3P855Rwsnl17HIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=PmhiB18vRjWgRnTglwudyPqkmTTiYDs6J6gZTiZCJ0HWfXM01p0CmE55RRm/dhlO2tKDSi+FsY62v5k8Itr1et2Y/Ak90DTGsbbFPDJd3/nojzb8i/AYNelRVu9jIuHKlvND6+C6Zbkho2arxvqwc7NwSag+IWTGLxDgD5RM45c= Received: by 10.78.165.16 with SMTP id n16mr7869161hue.63.1197881782892; Mon, 17 Dec 2007 00:56:22 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d24sm1272795nfh.2007.12.17.00.56.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2007 00:56:20 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Mon, 17 Dec 2007 09:56:39 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712141306.26246.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712170956.40957.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad, George, I modified the minutes as we agreed. Thanks. --julien On Friday 14 December 2007, Ahmad Muhanna wrote: > > Yes, others talked on the issue, some of their comments are > > captured in what follows the excerpt Ahmad wanted to modify > > (I did not posted the follow-up originally since nobody asked > > to modify it): > > > > Suresh: the issue is simple and the solution is simple if we > > do not try to be too clever. If the HNP is not on-link then > > the issue goes away Gerardo Giaretta: This is useful > > scenario. It is actually very likely that if you are > > multihoming, one of the links is likely to be your home link > > Kaigo: I also support this to be included in the draft. > > Prefer the home CoA option > > Suresh: It is not always easy to generate a home-CoA > > Sri: Not sure if this should be solved in this draft. > > Marcelo: There seems to be agreement to support DSMIP, not to > > support Bulk Registrations, and not clear agreement on the > > multihoming with home link issue. Will review discussion on > > the list to determine how to proceed. > > > > > In any case, one way to correct the minutes without all of > > > > us loosing > > > > > too much time on it, is to remove the entire discussion following > > > Ryuji's comment and replace it with "Various people: some > > > > discussion > > > > > regarding whether we need to support this in this draft or not." > > > > That would be fine with me. Let's see what others (Ahmad?) think. > > [Ahmad] > Hi Julien, > > Since George agreed in his latest response to your original proposed > change, I do not think I need to add anything here. > > Regards, > Ahmad > > > --julien > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 04:12:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4C1X-0005ib-IR; Mon, 17 Dec 2007 04:12:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4C1W-0005iW-IS for mext@ietf.org; Mon, 17 Dec 2007 04:12:30 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4C1W-00054U-6c for mext@ietf.org; Mon, 17 Dec 2007 04:12:30 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1704550rvb.49 for ; Mon, 17 Dec 2007 01:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=GcZgs2kpF1eYrFiPc1/i5sIQcwFMiyF4d3A6ZC11XYo=; b=Lm7Wtxp2fBgNvaqEnmlmEyXoimAslJfoatW7NLKbncWNOPcJcwrhSb+2LjMIUt6a5x9Lfzz3judSgW01QTHf/NuY7zXpAef8Pm5zcNsnaTEKAQrZtXbEuTgPP/phj7qQDnxXC3axWuHi4/hegtUKbYHq8b7RrO1+kL1qZwn5MwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jg/TVtLIWCQNvgiTs0WB8ccpSoOVd/TYotIZktDYDN7pf6uxdUl2WC/Y3KwoPFYIOei5ALySp3CdpdVtAFzt+pntP8/deMgT+8Goxzwf+474rj8xrvfUsdc0OGePU28346TRAwyByETi6EM8kATcDF6wHUB907g3ei0X8yudCps= Received: by 10.141.20.7 with SMTP id x7mr1109469rvi.34.1197882747584; Mon, 17 Dec 2007 01:12:27 -0800 (PST) Received: by 10.141.180.1 with HTTP; Mon, 17 Dec 2007 01:12:27 -0800 (PST) Message-ID: <1d38a3350712170112l16426c42m67777f2ff2f447ea@mail.gmail.com> Date: Mon, 17 Dec 2007 17:12:27 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" In-Reply-To: <1d38a3350712160543l34cbf51fmd5f6aad1c2b852ac@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78EC6672-9343-421A-B870-51954F397BCE@it.uc3m.es> <1d38a3350712160543l34cbf51fmd5f6aad1c2b852ac@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mext@ietf.org, Julien Laganier Subject: [MEXT] Re: review of draft-ietf-monami6-multiplecoa-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Dear all, Based on the discussion before the last time IETF meeting in ML. We (co-authors of both drafts) had a joint discussion offline, made the following proposal about text of work item and explanation of motiviation of this work, Thanks Sugimoto-san, Francis, Nakamura-san, and Yang's hard work for the below text, Proposed text: --- Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Address problems and need for interaction between the Mobile IPv6 and IPsec/IKE. Work on solution for the interface between the Mobile IPv6 and IPsec/IKE by extensions to the PF_KEY framework and flexible way to do information share. --- With regard to the arguments justifying our work, namely the reason why it is needed for MIPv6/NEMO deployment, we come up with the following arguments: --- * Usefulness of the document First of all, an informational RFC which defines the problems and solutions of MIPv6 and IPsec/IKE interaction is considered to be useful for software vendors and/or Mobile Service Operators who are going to implement a system of MIPv6/NEMO with dynamic keying. The document tells exactly what information needs to be exchanged between the MIPv6/NEMO and IPsec/IKE protocol stacks. * Potential benefit for the Mobile Service Operators Secondly, there is a potential benefit for Mobile Service Operators to have an informational RFC which defines the problems and solutions of MIPv6 and IPsec/IKE interaction. As MIPv6/NEMO and IPsec/IKE are inherently different protocols, the software may be developed by different software vendors. Therefore, even though the interface between the MIPv6 and IPsec/IKE is an issue inside a node (MN/HA), there is an interoperability issue. By defining the interface between the said protocols, Mobile Service Operators will have wider variety of choices on combinations of MIPv6/NEMO and IPsec/IKE software suites (i.e., higher possibility of constructing multi-vendor system). --- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JeanniethoriateDoherty@aaaknow.com Mon Dec 17 04:34:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4CMP-0003at-BS; Mon, 17 Dec 2007 04:34:05 -0500 Received: from 88-105-89-173.dynamic.dsl.as9105.com ([88.105.89.173] helo=annepc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4CMO-0000gd-20; Mon, 17 Dec 2007 04:34:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host92612237.aaaknow.com (8.13.1/8.13.1) with SMTP id 1WykIJwn22.445378.Klc.xkI.1286944674242 for ; Mon, 17 Dec 2007 09:33:25 +0000 Message-ID: <159fa101c8408f$f2335310$ad596958@annepc> From: "Lorene Capps" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_159F9D_01C8408F.F2335310-- From mext-bounces@ietf.org Mon Dec 17 05:18:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4D3d-0003NR-Eu; Mon, 17 Dec 2007 05:18:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4D3b-00032j-LY for mext@ietf.org; Mon, 17 Dec 2007 05:18:43 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4D3b-0001ia-1G for mext@ietf.org; Mon, 17 Dec 2007 05:18:43 -0500 Received: from [163.117.139.66] (unknown [163.117.139.66])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 9E9542B0E47;Mon, 17 Dec 2007 11:18:38 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Mon, 17 Dec 2007 09:06:07 +0100 To: "Benjamin Lim" X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.3013 TC:1F TRN:35 TV:5.0.1023(15610.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org right, i will update the minutes thanks, marcelo El 17/12/2007, a las 3:03, Benjamin Lim escribi=F3: > Hi, > > One small comment. > > =3D8=3D=3D8<=3D8=3D=3D >> In the minutes it is clearly stated: >> >> Marcelo: There seems to be agreement to support DSMIP, not to >> support Bulk Registrations, and not clear agreement on the >> multihoming with home link issue. Will review discussion on >> the list to determine how to proceed > [Ben] Just caught this from Marcelo's reply. If I'm not wrong, the =20 > consensus > was not to support bulk registration to CN right? I believe that bulk > registration to HA is still supported. If so, I propose modifying =20 > this text > in the minutes to "..., not to support Bulk Registration to CN, ..." > > Regards, > Benjamin Lim > >> >> In addition, in the mail that i sent to move forward with >> this issue, i wrote: >> >> - With respect to the case of multihoming with a visited >> network and the home network, there was no clear consesus on >> the meeting but it seemed that there was more support for >> supporting this case. I have reached the same conclusion >> after reading the mailing list. So the next steps for this >> are that the author or other partis to provide text for this >> and propose it to the ml. >> >> Regards, marcelo > > =3D8=3D=3D8<=3D8=3D=3D > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 05:25:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4DAN-0007dn-9l; Mon, 17 Dec 2007 05:25:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4DAL-0007di-Rl for mext@ietf.org; Mon, 17 Dec 2007 05:25:41 -0500 Received: from smtp.mei.co.jp ([133.183.100.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4DAK-0001uY-EA for mext@ietf.org; Mon, 17 Dec 2007 05:25:41 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id lBHAPbEx018878; Mon, 17 Dec 2007 19:25:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id lBHAPcF29870; Mon, 17 Dec 2007 19:25:38 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id lBHAPcV22312; Mon, 17 Dec 2007 19:25:38 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml21) id lBHAPbxJ028125; Mon, 17 Dec 2007 19:25:37 +0900 (JST) Received: from [10.68.136.66] by soml21.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id lBHAPaW6028106; Mon, 17 Dec 2007 19:25:36 +0900 (JST) Date: Mon, 17 Dec 2007 19:25:37 +0900 From: Keigo Aso To: marcelo bagnulo braun Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 In-Reply-To: References: <20071214160852.1B21.ASOU.KEIGO@jp.panasonic.com> Message-Id: <20071217182238.C758.ASOU.KEIGO@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, On Sat, 15 Dec 2007 16:50:07 +0100 marcelo bagnulo braun wrote: > Hi Keigo, > > El 14/12/2007, a las 10:02, Keigo Aso escribis: > > > Hello, > > > > In the last meeting, actually the author mentioned that there was > > concensus to support for the simultaneous usage of the home and > > foreign > > attached interfaces, and then there were apparently more supports > > for this scenario during the session also. > > The chair(Marcelo) also said in his email that he had reached the same > > conclusion based on the session and ML review, and clearly > > indicated the next > > step as the WG. > > > I think i need to clarify this. I think there was more support for > supporting this case, but there was not clear consesus for it and we > need more discussion. Since one of the arguments for this is the > complexity of the approach needed, i think we can understand more the > complexity of the solution if we have a text describing the solution, > hence why i have requested to provide some concrete text to describe > this. Thank you for your clarification. Certainly there were some people who has the impression of complexity at that time, and also there were still several solutions listed which might cause some confusion. IMHO, as mentioned in ML from some people, I also could not find any complexity. Hopefully we would be able to remove such confusion by having a text describing the solution clearly. Regards, Keigo > > So, it is not that i think we have agreed on this issue, is just that > i think that such text would help us to move forward with the discussion > > Just for completeness, i attach both of my comments below > > In the minutes it is clearly stated: > > Marcelo: There seems to be agreement to support DSMIP, not to support > Bulk Registrations, and not clear agreement on the multihoming with > home link issue. Will review discussion on the list to determine how > to proceed > > In addition, in the mail that i sent to move forward with this issue, > i wrote: > > - With respect to the case of multihoming with a visited network and > the home network, there was no clear consesus on the meeting but it > seemed that there was more support for supporting this case. I have > reached the same conclusion after reading the mailing list. So the > next steps for this are that the author or other partis to provide > text for this and propose it to the ml. > > Regards, marcelo > > > > So, I think there is no need to go back to before again > > even though the minutes is updated. > > > > I agree with George and Vijay. Supporting this scenario is very > > important for > > practical MCoA specification because MCoA MN can connect to the > > network > > which is defined in RFC3775. > > > > Regards, > > Keigo > > > > On Thu, 13 Dec 2007 11:48:28 -0800 > > Vijay Devarapalli wrote: > > > >> Julien, > >> > >> I believe Ryuji was trying to get folks to pick one solution for > >> the scenario where the mobile node is attached to the home link > >> and visited link at the same time. We have a few options. > >> > >> I don't understand Sri's and Ahmad's concerns about complexity. > >> We do have an issue here, so it needs to be addressed. I agree > >> with George, if there is a home link to which the MN can attach > >> to, then this scenario is bound to happen. > >> > >> Vijay > >> > >> Julien Laganier wrote: > >>> Hello Ahmad and others, > >>> > >>> Thanks Ahmad for reviewing the minutes, this is certainly helpful to > >>> ensure they accurately reflect the meeting discussions. Thanks > >>> also to > >>> our notes takers, this is a difficult task and it is unavoidable > >>> that > >>> sometimes mistakes are made. > >>> > >>> I listened carefully to the recorded audio from our 1st session: > >>> > >>> > >>> > >>> and I agree the excerpt of the minutes Ahmad sent do not reflect > >>> accurately the discussion that took place (between 1:23 and 1:46 > >>> in the > >>> record). I am proposing the updated text below (I condensed your > >>> comments Ahmad, hope I got them right). > >>> > >>> Now a question to people that were in the meeting or listened to the > >>> recorded audio: Do you agree with the proposed change? > >>> > >>> Thanks. > >>> > >>> --julien > >>> > >>> ----------------------------- > >>> Ryuji: George commented that maybe we should add IPv4 CoA support > >>> for > >>> DSMIPv6 support > >>> Alex: Disagree, why add new features > >>> George: DSMIP is now being adopted by SDOs, and there is no rush for > >>> this, so lets do it correctly > >>> Ryuji: Other comment from George is why bulk registrations with CNs > >>> are excluded. There was consensous against this before. > >>> George, unlike last issue I am not convinced this is necessary to > >>> support. It was just not clear why this is not supported while > >>> reading the draft. > >>> Ryuji: yes so it was to keep the protocol simple. > >>> Ryuji: Last issue is about simultaneous home/foreign links. This has > >>> been discussed for some time now. There is now consensus to support > >>> this but no yet agreement on how to do it. (two options summarized) > >>> Ahmad: Addressing this scenario is probably not required at this > >>> point > >>> and options look messy. Also, supporting this scenario would be a > >>> violation of RFC3775 which requires the MN to send a de- > >>> registration BU > >>> as soon as it realizes that it is on a home link. Can we limit the > >>> draft to multiple care-of address registration for now. > >>> Ahmad: Also, regarding the status code when multiple care of address > >>> registration fails, I suggest that whenever any of the BID fails > >>> registration, the BA should use a new status code less than 128 to > >>> indicate to the MN that registration was successful but some > >>> BID failed registration in order for the MN to check which BID has > >>> failed. If all registered correctly, HA should always use status > >>> zero. > >>> Ryuji: Ok. > >>> Various people: some discussion regarding whether we need to support > >>> this in this draft or not. > >>> ----------------------------- > >>> > >>> On Thursday 13 December 2007, Ahmad Muhanna wrote: > >>>> Hi Chairs/All, > >>>> > >>>> Please find some comments below. > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>> - Multiple Care-of Addresses Registration > >>>> Ryuji Wakikawa - 20 min > >>>> draft-ietf-monami6-multiplecoa-04 > >>>> > >>>> Ryuji: George commented that maybe we should add IPv4 CoA > >>>> support for > >>>> DSMIPv6 support > >>>> Alex: Disagree, why add new features > >>>> George: DSMIP is now being adopted by SDOs, and there is no rush > >>>> for > >>>> this, so lets do it correctly > >>>> Ryuji: Other comment from George is why bulk registrations with CNs > >>>> are excluded. There was consensous against this before. > >>>> George, unlike last issue I am not convinced this is necessary to > >>>> support. It was just not clear why this is not supported while > >>>> reading the draft. > >>>> Ryuji: yes so it was to keep the protocol simple. > >>>> Ryuji: Last issue is about simultaneous home/foreign links. This > >>>> has > >>>> been discussed for some time now. There is now consensus to support > >>>> this but no yet agreement on how to do it. (two options summarized) > >>>> > >>>> Various: some discussion regarding whether we need to support > >>>> this in > >>>> this draft or not. Seems that the answer is yes > >>>> > >>>> [Ahmad] > >>>> I am not sure about the above conclusion at this point of the > >>>> meeting. Under various, I assume that my comments should have been > >>>> listed which were as follows: > >>>> > >>>> 1. I think that addressing this scenario is probably not > >>>> required at > >>>> this point and options look messy. I also raised the issue if > >>>> supporting this scenario, will that be a violation of RFC3775 which > >>>> requires the MN to send a de-registration BU as soon as it realizes > >>>> that it is on a home link. {I do not recall Ryuji answering that > >>>> point but some other folks mentioned that it is not which was not > >>>> clear to me} > >>>> > >>>> 2. I also made a comment regarding the status code when multiple > >>>> care > >>>> of address registration fails. I suggested that whenever any of the > >>>> BID fails registration, the BA should use a new status code less > >>>> than > >>>> 128 to indicate to the MN that registration was successful but some > >>>> BID failed registration in order for the MN to check which BID has > >>>> failed. If all registered correctly, HA should always use status > >>>> zero. {Ryuji agreed with that comment} > >>>> > >>>> 3. Also, I do not think the conclusion of that "various" was YES. > >>>> > >>>> Cheers! > >>>> > >>>>> -----Original Message----- > >>>>> From: Julien Laganier [mailto:julien.IETF@laposte.net] > >>>>> Sent: Wednesday, December 12, 2007 9:15 AM > >>>>> To: mext@ietf.org > >>>>> Subject: [MEXT] Minutes of MEXT sessions at IETF-70 > >>>>> > >>>>> Folks, > >>>>> > >>>>> Minutes of the meeting are available there: > >>>>> > >>>>> > >>>>> > >>>>> Please send to chairs corrections and/or add-ons, if any. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> --julien > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mext > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 07:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Eyc-0001Vt-BC; Mon, 17 Dec 2007 07:21:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Eyb-0001JN-0f for mext@ietf.org; Mon, 17 Dec 2007 07:21:41 -0500 Received: from omta05sl.mx.bigpond.com ([144.140.93.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4EyY-0000Ot-Lu for mext@ietf.org; Mon, 17 Dec 2007 07:21:40 -0500 Received: from oaamta02sl.mx.bigpond.com ([124.190.105.201]) by omta05sl.mx.bigpond.com with ESMTP id <20071217122136.OSQH19939.omta05sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com> for ; Mon, 17 Dec 2007 12:21:36 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta02sl.mx.bigpond.com with ESMTP id <20071217122136.MQQK25607.oaamta02sl.mx.bigpond.com@PC20005>; Mon, 17 Dec 2007 12:21:36 +0000 From: "Hesham Soliman" To: Date: Mon, 17 Dec 2007 23:21:22 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchAr7c0+QOwypWaRN+oqm/zNBSypw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'Martti Kuparinen' , 'Tero Kauppinen' Subject: [MEXT] DSMIPv6 BU format and RFC 3775 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, I received the following question from Tero: While reading the current version of DSMIPv6 (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one sentence which strikes me as odd. "4.2. NAT detection and traversal NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv6 home address. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field. When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the source address of the IPv6 header." If the IPv6 header contains the mobile node's IPv6 home address, how can it ever match with the IPv4 address of the source address field in the IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address." So, (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? Or (2) Should the IPv4 address of the source address field in the IPv4 header be compared with the address specified in the packet's IPv4 CoA option? Of course the intention of the spec is to do (2), but the question remains, are we violating RFC 3775? If so, are we ok with that? I intend to submit the final version of the spec in the next day or two provided that we're ok with this issue so your prompt response is appreciated. Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 07:30:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4F6i-0004FD-Mh; Mon, 17 Dec 2007 07:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4F6h-0004F4-6I for mext@ietf.org; Mon, 17 Dec 2007 07:30:03 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4F6g-0000Zs-CZ for mext@ietf.org; Mon, 17 Dec 2007 07:30:03 -0500 Received: by nz-out-0506.google.com with SMTP id n1so834517nzf.4 for ; Mon, 17 Dec 2007 04:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/RAdMfUp7OQ46ZpWAXLqcnm43JSQUIh8qtSaqSDtKkY=; b=dGe3QQbbDO1m4B81swKRQwZglMjfMZGwad/JQ8eud2Kp/aDddhkxla/XpUv6D7PY8TH0SnaS2Nyh2F3ADjjYTak66txx9JgjxlTRMRH67L1ugqAXo90lzJiSWwpXdS5rJEz/ZLWYNhPXpj5EdonVUuDJLeF43Amu7Gx7axLFxro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SGdixfyLCZ6SOK5KXv4AWzwnGQG7SOf5Mhih4ZK9iNcIrxgpNVmPxDn+5p8hpHZnNJH1yeyTgv1gMrvCmk7q5SdxhCNZ/a4NWb5snGbnqbpY2fnbr6dp16h9nP5dtN7HVsgts9fcQOgzArHoQ0oLZ+HGcuvl0I9my9fQo6DP7t0= Received: by 10.143.162.8 with SMTP id p8mr1129187wfo.63.1197894600246; Mon, 17 Dec 2007 04:30:00 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 17 Dec 2007 04:30:00 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 12:30:00 +0000 From: "George Tsirtsis" To: "marcelo bagnulo braun" Subject: Re: [MEXT] [RFC3775 changes] Site-local addresses In-Reply-To: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1F786D7B-E971-4B90-9261-9DE9E279C96B@bagnulo.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org All, The following text changes are dealing with the deprecated site-local addresses in RFC3775. See Motivation at the end of the e-mail. ---------------------------------------------------------------------------= ---------------------- OLD TEXT: 3.1. General Terms ... unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must have either a global or site-local scope (but not link-local). NEW TEXT: 3.1. General Terms ... unicast routable address An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must either be global IPv6 address or a unique local IPv6 address. ---------------------------------------------------------------------------= ---------------------- OLD TEXT: 4.6. Site-Local Addressability This specification requires that home and care-of addresses MUST be unicast routable addresses. Site-local addresses may be usable on networks that are not connected to the Internet, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently in, it is hard to prevent accidental attachment to other sites, and ambiguity of site-local addresses can cause problems if the home and visited networks use the same addresses. Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses. NEW TEXT: 4.6. Unique-Local Addressability This specification requires that home and care-of addresses MUST be unicast routable addresses. Unique-local IPv6 unicast addresses [RFC419= 3] may be usable on networks that use such non-globaly routable addresses but this specification does not define when such usage is safe and when = it is not. Mobile nodes may not be aware of which site they are currently making it hard to prevent accidental attachment to other sites, resultin= g in possible unrechability between the MN and the HA, when unique-local IPv6 routable addresses are used as care-of addresses. Also, CNs outside the = MN's own site are not going to be reachable when unique-local IPv6 routable addresses are used as home addresses. Therefore, unique-local IPv6 unicast address= es SHOULD NOT be used as home or care-of addresses. If such addresses are u= sed, however, according to [RFC4193], they are treated as any global unicast = IPv6 address so, for the remainder of this specification, use of unique-local IPv6 unicast addresses is not differentiated from other globally unique IPv6 addresse= s. ---------------------------------------------------------------------------= ---------------------- OLD TEXT: 10.4.2. Processing Intercepted Packets ... ... Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default. NEW TEXT (None: old text removed) ---------------------------------------------------------------------------= ---------------------- OLD TEXT: 11.3.1. Sending Packets While Away from Home ... o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local or site-local peers, if the scope of the home address is larger than the scope of the peer's address. NEW TEXT: 11.3.1. Sending Packets While Away from Home ... o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local peers. ---------------------------------------------------------------------------= ---------------------- OLD TEXT: 11.5.4. Returning Home ... ...The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address and site-local address. NEW TEXT: 11.5.4. Returning Home ... ...The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address. ---------------------------------------------------------------------------= ---------------------- MOTIVATION: Site-local addresses have been deprecated (see RFC3879). According to this RFC, future versions of RFCs that mention site-local addresses should remove such references and replace them with appropriate alternatives. In the mean time an alternative to site-local addresses has been defined in RFC4193 (Unique-local IPv6 routable addresses). According to this RFC, these addresses have limited routability (typically within one or small number of sites) but they are otherwise treated as other global IPv6 addresses. Based on the above, the new text proposed above removes all references to site-local addresses and replaces them with unique-local IPv6 addresses as directed by RFC3879 and RFC4193. Regards George On Dec 15, 2007 4:25 PM, marcelo bagnulo braun wrote: > Hi George, > > El 14/12/2007, a las 16:46, George Tsirtsis escribi=F3: > > > Not sure if this has been discussed already so I thought I should > > ask first. > > > > Looking at RFC3775 I counted 8 mentions of site-local addresses, > > including section 4.6."Site-Local Addressability". Given the > > deprecated status of site local addresses (rfc3879) how do we want to > > handle these? > > > > Is someone else already dealing with this > > > not that i am aware of > > > or shall I work on suggested > > text changes? > > > > please do > > Thanks, marcelo > > > > George > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AishadiplomaKeenan@flickr.com Mon Dec 17 08:13:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4FmR-0005N4-Fs; Mon, 17 Dec 2007 08:13:11 -0500 Received: from ppp-124.120.79.208.revip2.asianet.co.th ([124.120.79.208] helo=microsofecb2eb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4FmQ-00069Q-PV; Mon, 17 Dec 2007 08:13:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host20173177.flickr.com (8.13.1/8.13.1) with SMTP id 85WDgbiE11.742243.tpb.V9B.1186655348481 for ; Mon, 17 Dec 2007 20:12:34 -0700 Message-ID: <1d1001c840ae$91a843b0$0300000a@microsofecb2eb> From: "Lynnette Prather" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1D0C_01C840AE.91A843B0-- From mext-bounces@ietf.org Mon Dec 17 08:26:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4FzM-0003k8-19; Mon, 17 Dec 2007 08:26:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4FzK-0003k3-UA for mext@ietf.org; Mon, 17 Dec 2007 08:26:30 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4FzI-0001mk-Pq for mext@ietf.org; Mon, 17 Dec 2007 08:26:30 -0500 Received: by py-out-1112.google.com with SMTP id d32so9978533pye.12 for ; Mon, 17 Dec 2007 05:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wmKtwGmkmaby9+xa0I91TTdxkudgA1A3o0azA8kgjFE=; b=wHE7oiQBwsQnkyCEkiwf55M+TcTsauFFjgqCrILJY8Nm8o8b7hwRgSFBmptkDDWdVbDjjbpsdNmHG5/DXI4Mlc/RHRHD5Xs8ciPIuuvKdHHJI2RPdrpXWYRV3UE25LjXLZKDdgvvW2yurgL0EpxrbkP4319DB9+gcfseeSHSR3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eOGgeA6DMrZ1biJP5DND8XGGH5WPN5ZDfxlss+GpmBFRPdTAxQ8moMxTqjjiDJRivuAHDcuCCvXab4UPr0SaWU/7RJj3DGpmwB59CMjeSnGJAH27bf051ksi48BJMASnEQEMARLSF6v3uVK2tWNES9sG2IYskVTRFrfQcNVBbrQ= Received: by 10.142.212.19 with SMTP id k19mr526197wfg.193.1197897987558; Mon, 17 Dec 2007 05:26:27 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 17 Dec 2007 05:26:27 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 13:26:27 +0000 From: "George Tsirtsis" To: "Hesham Soliman" Subject: Re: [MEXT] DSMIPv6 BU format and RFC 3775 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Martti Kuparinen , Tero Kauppinen , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Hesham, Well done to Tero for catching this! I would go with (2), as I think this was the intention (i.e., I consider this a typo). It is not, however, clear to me what the relevance of the quoted text from 3775 is. Whether (1) or (2) is used it should not result in the condition of CoA==HoA in the BU. Am I missing something? Regards George On Dec 17, 2007 1:21 PM, Hesham Soliman wrote: > Folks, > > I received the following question from Tero: > While reading the current version of DSMIPv6 > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > sentence which strikes me as odd. > > "4.2. NAT detection and traversal > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." > > If the IPv6 header contains the mobile node's IPv6 home address, how can > it ever match with the IPv4 address of the source address field in the > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > specified in the Binding Update is zero or the specified care-of address > matches the home address for the binding, then this is a request to > delete the cached binding for the home address." > > So, > > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? > > Or > > (2) Should the IPv4 address of the source address field in the IPv4 > header be compared with the address specified in the packet's IPv4 CoA > option? > > Of course the intention of the spec is to do (2), but the question remains, > are we violating RFC 3775? If so, are we ok with that? > > I intend to submit the final version of the spec in the next day or two > provided that we're ok with this issue so your prompt response is > appreciated. > > Hesham > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 08:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GBI-0002hg-BN; Mon, 17 Dec 2007 08:38:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GBH-0002hZ-BF for mext@ietf.org; Mon, 17 Dec 2007 08:38:51 -0500 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4GBF-0007gY-Mx for mext@ietf.org; Mon, 17 Dec 2007 08:38:50 -0500 Received: from oaamta06sl.mx.bigpond.com ([124.190.105.201]) by omta02sl.mx.bigpond.com with ESMTP id <20071217133847.JSWL22725.omta02sl.mx.bigpond.com@oaamta06sl.mx.bigpond.com> for ; Mon, 17 Dec 2007 13:38:47 +0000 Received: from PC20005 ([124.190.105.201]) by oaamta06sl.mx.bigpond.com with ESMTP id <20071217133846.OHPR11935.oaamta06sl.mx.bigpond.com@PC20005>; Mon, 17 Dec 2007 13:38:46 +0000 From: "Hesham Soliman" To: "'George Tsirtsis'" Subject: RE: [MEXT] DSMIPv6 BU format and RFC 3775 Date: Tue, 18 Dec 2007 00:38:32 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchAsHKIjIlIAzG2RZCm8Ki9YLIj1AACclYw X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 'Martti Kuparinen' , 'Tero Kauppinen' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > Well done to Tero for catching this! > I would go with (2), as I think this was the intention (i.e., I > consider this a typo). => Sure, this part is out of the question. > > It is not, however, clear to me what the relevance of the quoted text > from 3775 is. > Whether (1) or (2) is used it should not result in the condition of > CoA==HoA in the BU. Am I missing something? => The relevance of the quote from 3775 is that we're putting the HoA in the src address of a normal registration. The text says that the receiver of a BU with the HoA in the src address field would assume it's a de-registration, which is obviously not what we want. Hence my question about violating 3775. Hesham > > Regards > George > > On Dec 17, 2007 1:21 PM, Hesham Soliman > wrote: > > Folks, > > > > I received the following question from Tero: > > While reading the current version of DSMIPv6 > > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > > sentence which strikes me as odd. > > > > "4.2. NAT detection and traversal > > > > NAT detection is done when the initial binding update > message is sent > > from the mobile node to the home agent. When located in > an IPv4-only > > foreign link, the mobile node sends the binding update message > > encapsulated in UDP and IPv4. The source address of the > IPv6 packet > > is the mobile node's IPv6 home address. The destination > address is > > the IPv6 address of the home agent. The IPv4 header > contains the IPv4 > > care-of address in the source address field and the > IPv4 address of > > the home agent in the destination address field. > > > > When the home agent receives the encapsulated binding update it > > compares the IPv4 address of the source address field > in the IPv4 > > header with the IPv4 address in the source address of the IPv6 > > header." > > > > If the IPv6 header contains the mobile node's IPv6 home > address, how can > > it ever match with the IPv4 address of the source address > field in the > > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > > specified in the Binding Update is zero or the specified > care-of address > > matches the home address for the binding, then this is a request to > > delete the cached binding for the home address." > > > > So, > > > > (1) Should the IPv6 header actually contain an IPv4 mapped > IPv6 address? > > > > Or > > > > (2) Should the IPv4 address of the source address field in the IPv4 > > header be compared with the address specified in the > packet's IPv4 CoA > > option? > > > > Of course the intention of the spec is to do (2), but the > question remains, > > are we violating RFC 3775? If so, are we ok with that? > > > > I intend to submit the final version of the spec in the > next day or two > > provided that we're ok with this issue so your prompt response is > > appreciated. > > > > Hesham > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 08:58:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GU2-0004pl-Uw; Mon, 17 Dec 2007 08:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GNN-0001qo-PH for mext@ietf.org; Mon, 17 Dec 2007 08:51:21 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GNM-0003GU-LZ for mext@ietf.org; Mon, 17 Dec 2007 08:51:21 -0500 Received: from localhost ([127.0.0.1]:41318 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4GNJ-0005KK-2b; Mon, 17 Dec 2007 14:51:17 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Mon, 17 Dec 2007 13:51:17 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/1 Message-ID: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, amuhanna@nortel.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Mon, 17 Dec 2007 08:58:13 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2133223384==" Errors-To: mext-bounces@ietf.org --===============2133223384== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzE6IExhc3QgQWNjZXB0ZWQgU1FOIFtBaG1hZCBNdWhhbm5hIDxhbXVoYW5uYUBub3J0ZWwuY29t Pl0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjogIGp1bGllbi5pZXRmQGxhcG9zdGUu bmV0ICB8ICAgICAgIE93bmVyOiAganVsaWVuLmlldGZAbGFwb3N0ZS5uZXQNCiAgICAgVHlwZTog IGRlZmVjdCAgICAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3ICAgICAgICAgICAg ICAgICAgICANCiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0 b25lOiAgICAgICAgICAgICAgICAgICAgICAgICANCkNvbXBvbmVudDogIFJGQzM3NzUgY2hhbmdl cyAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgICAgICAgICAgICAgICAgICAgICANCiBLZXl3 b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiB7e3sNCiBJU1NVRToNCiA9PT09PT0NCg0KIEluIHJlc3BvbnNlIHRvIGEgQlUgd2hpY2ggY29u dGFpbnMgYW4gb3V0IG9mIHJhbmdlIHNlcXVlbmNlIG51bWJlciwgYXMNCiBwZXIgc2VjdGlvbnMg OS41LjEgYW5kIDExLjcuMSwgdGhlIENOIG9yIEhBIGlzIGFsbG93ZWQgdG8gc2VuZCBhIEJBIHdp dGgNCiBhIHN0YXR1cyBvZiAxMzUgYWZ0ZXIgaW5zZXJ0aW5nIHRoZSBsYXN0IGFjY2VwdGVkIHNl cXVlbmNlIG51bWJlcg0KIHJlY2VpdmVkIGluIHRoZSBsYXN0IHZhbGlkIEJVIGluIHRoZSBzZXF1 ZW5jZSBudW1iZXIgZmllbGQgKERpZmZlcmVudA0KIGZyb20gdGhlIHNlcXVlbmNlIG51bWJlciBy ZWNlaXZlZCBpbiB0aGUgb3V0c3RhbmRpbmcgQlUpDQoNCiBBY2NvcmRpbmcgdG8gTU4gcHJvY2Vz c2luZyBvZiB0aGUgQkEgYXMgc3BlY2lmaWVkIHVuZGVyIHNlY3Rpb24gMTEuNy4zLiwNCiB0aGUg TU4gd2lsbCBzaWxlbnRseSBkaXNjYXJkIHRoZSByZWNlaXZlZCBCQSByYXRoZXIgdGhhbiBwaWNr aW5nIHRoZQ0KIGxhc3QgYWNjZXB0ZWQgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aGVuIGdlbmVyYXRl IGEgbmV3IHNlcXVlbmNlIG51bWJlci4NCg0KIEkgdGhpbmsgdGhlIGludGVudGlvbiB3YXMgdG8g YWxsb3cgdGhlIEhBIG9yIENOIHRvIGNvbW11bmljYXRlIGJhY2sgdG8NCiB0aGUgTU4gdGhlIGxh c3QgYWNjZXB0ZWQgc2VxdWVuY2UgbnVtYmVyLCBob3dldmVyLCB3ZSBhcmUgYnJlYWtpbmcgdGhl DQogcHJvdG9jb2wgYnkgdXNpbmcgdGhpcyBtZWNoYW5pc20uDQoNCiBUaGlzIGlzc3VlIGJlY29t ZXMgY3JpdGljYWwgaW4gdGhlIGNhc2Ugb2YgUE1JUHY2IHNpbmNlIHRoZSBQTUlQIGNsaWVudA0K IHdvdWxkIGhhdmUgdGhvdXNhbmRzIG9mIG91dHN0YW5kaW5nIFAtQlUgYW5kIHRoZSByZWNlaXZl ZCBQLUJBIG1vc3QNCiBwcm9iYWJseSB3aWxsIGNvbGxpZGUgd2l0aCBhbm90aGVyIG91dHN0YW5k aW5nIFAtQlUgY2F1c2luZyB0aGUgUE1JUA0KIGNsaWVudCB0byBkcm9wIHRoZSBQLUJBIGFuZCBj b250aW51ZSB0byBzdGF5IG91dCBvZiBzeW5jIHdpdGggdGhlDQogTE1BL0hBLg0KDQogT0xEIFRF WFQ6DQogPT09PT09PT09DQoNCiBUbyBteSByZWNvbGxlY3Rpb24sIHRoZXJlIGlzIG5vIG5lZWQg dG8gY2hhbmdlIGFueSBvZiB0aGUgZXhpc3RpbmcgdGV4dA0KIHNpbmNlIHRoZSBjdXJyZW50IHRl eHQgb2YgUkZDMzc3NSBnb2VzIGlubGluZSB3aXRoIHRoZSBvcmlnaW5hbA0KIGludGVudGlvbi4g SG93ZXZlciwgdGhlIHByb3Bvc2VkIHRleHQgbmVlZHMgdG8gYmUgYWRkZWQuDQoNCg0KIFNPTFVU SU9OOg0KID09PT09PT09PQ0KDQogVGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIHNvbHV0aW9uIGZv ciB0aGlzIGlzc3VlIGlzIHRvIGVuYWJsZSB0aGUNCiBvcmlnaW5hbCBpbnRlbnRpb24gb2YgUkZD Mzc3NS4gaS5lLiBieSBjb21tdW5pY2F0aW5nIGJhY2sgdGhlIGxhc3QNCiBzdWNjZXNzZnVsIHNl cXVlbmNlIG51bWJlciBpbiBhIG9wdGlvbjoNCg0KIExhcyBWYWxpZCBTZXF1ZW5jZSBOdW1iZXIg TW9iaWxpdHkgT3B0aW9uOg0KIDYuMi54LiAgTGFzdCBWYWxpZCBTZXF1ZW5jZSBOdW1iZXINCg0K ICAgIFRoZSBMYXN0IFZhbGlkIFNlcXVlbmNlIE51bWJlciBvcHRpb24gaGFzIGFuIGFsaWdubWVu dCByZXF1aXJlbWVudA0KICAgIG9mIDJuLiBJdHMgZm9ybWF0IGlzIGFzIGZvbGxvd3M6DQoNCiAg ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIFR5cGU9VEJEICAgIHwgICBMZW5ndGggPSAyICB8DQogICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICB8ICAgTGFzdCBWYWxpZCBTZXF1ZW5jZSBOdW1iZXIgIHwNCiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KIFRoZSBMYXN0IFZhbGlkIFNlcXVlbmNlIE51 bWJlciBvcHRpb24gaXMgb25seSB2YWxpZCBpbiBhIEJBLCBzZW50IGZyb20NCiB0aGUgbW9iaWxl IG5vZGUncyBob21lIGFnZW50IGluIHJlcGx5IHRvIGEgaG9tZSByZWdpc3RyYXRpb24sIHdpdGgg YQ0KIHN0YXR1cyBvZiAxMzUuIFRoZSBMYXN0IFZhbGlkIFNlcXVlbmNlIE51bWJlciBpcyB0aGUg bGFzdCBzZXF1ZW5jZQ0KIG51bWJlciB0aGF0IHRoZSBIb21lIEFnZW50IHJlY2VpdmVkIGluIHRo ZSBsYXN0IHN1Y2Nlc3NmdWwgQmluZGluZw0KIFVwZGF0ZSBmb3IgdGhlIHNwZWNpZmllZCBzZXNz aW9uLiBJbiBjYXNlIHRoZSBIb21lIEFnZW50IHJlY2VpdmVzIGENCiBCaW5kaW5nIFVwZGF0ZSB3 aXRoIGEgc2VxdWVuY2UgbnVtYmVyIG91dHNpZGUgdGhlIHZhbGlkIHNlcXVlbmNlIG51bWJlcg0K IHJhbmdlLCB0aGUgSG9tZSBBZ2VudCBzZW5kcyBhIEJBIHdpdGggYSBzdGF0dXMgb2YgMTM1LiBI QSBtdXN0IGNvcHkgdGhlDQogc2VxdWVuY2UgbnVtYmVyIGZyb20gdGhlIEJVIGludG8gdGhlIHNl cXVlbmNlIG51bWJlciBmaWVsZCBvZiB0aGUgQkEuIEhBDQogbXVzdCBpbmNsdWRlIHRoZSBsYXN0 IFZhbGlkIFNlcXVlbmNlIE51bWJlciBpbnRvIHRoZSBMYXN0IHZhbGlkIFNlcXVlbmNlDQogTnVt YmVyIE1vYmlsaXR5IG9wdGlvbi4NCiB9fX0NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3d3 dzMudG9vbHMuaWV0Zi5vcmcvd2cvbWV4dC90cmFjL3RpY2tldC8xPg0KbWV4dCA8aHR0cDovL3Rv b2xzLmlldGYub3JnL3dnL21leHQvdHJhYy8+DQo= --===============2133223384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============2133223384==-- From mext-bounces@ietf.org Mon Dec 17 09:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ga1-0007VJ-I0; Mon, 17 Dec 2007 09:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ga0-0007V2-FS for mext@ietf.org; Mon, 17 Dec 2007 09:04:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GZy-0003bh-Tt for mext@ietf.org; Mon, 17 Dec 2007 09:04:24 -0500 X-IronPort-AV: E=Sophos;i="4.24,176,1196636400"; d="scan'208";a="1093496" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2007 15:04:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBHE4MH8029769; Mon, 17 Dec 2007 15:04:22 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBHDxNmu016668; Mon, 17 Dec 2007 14:04:17 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 15:04:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] DSMIPv6 BU format and RFC 3775 Date: Mon, 17 Dec 2007 15:04:08 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04EECD7B@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIPv6 BU format and RFC 3775 Thread-Index: AchAr7c0+QOwypWaRN+oqm/zNBSypwAAtyrw From: "Pascal Thubert (pthubert)" To: "Hesham Soliman" , X-OriginalArrivalTime: 17 Dec 2007 14:04:15.0603 (UTC) FILETIME=[B55C1C30:01C840B5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3152; t=1197900262; x=1198764262; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[MEXT]=20DSMIPv6=20BU=20format=20and=20 RFC=203775 |Sender:=20; bh=AYozapHJP6S+mIiO9lz9/t082FyHm1y0LCno11qnig4=; b=Slqnqz9OkVeqx98UBue1oAJjbHbFk/g8I4/rw5d9JhnV5ndS7EHGzJcCjC 5c6qWOSkuOyBvhvdE1mpK8R+ZG3cEnO4BbW3dGQDWQ6jM/XvxEgX0O8UeJ// M6/kR19nNx; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Martti Kuparinen , Tero Kauppinen X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Hesham: >Folks,=20 > >I received the following question from Tero: >While reading the current version of DSMIPv6 >(draft-ietf-mip6-nemo-v4traversal-06) and I came across with=20 >one sentence which strikes me as odd. > >"4.2. NAT detection and traversal > > NAT detection is done when the initial binding update=20 >message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header=20 >contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." > >If the IPv6 header contains the mobile node's IPv6 home=20 >address, how can it ever match with the IPv4 address of the=20 >source address field in the >IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the=20 >Lifetime specified in the Binding Update is zero or the=20 >specified care-of address matches the home address for the=20 >binding, then this is a request to delete the cached binding=20 >for the home address." > >So,=20 > >(1) Should the IPv6 header actually contain an IPv4 mapped=20 >IPv6 address? > >Or > >(2) Should the IPv4 address of the source address field in the=20 >IPv4 header be compared with the address specified in the=20 >packet's IPv4 CoA option? > >Of course the intention of the spec is to do (2), but the=20 >question remains, are we violating RFC 3775? If so, are we ok=20 >with that?=20 > >I intend to submit the final version of the spec in the next=20 >day or two provided that we're ok with this issue so your=20 >prompt response is appreciated.=20 > I favor 1) and the text seems to be a leftover from your original draft which worked that way. But I remember that the question was cut against it by the chairs because there was no proper consensus either way. Now I really hate the idea of a BU process that would have to figure if a BU is a registration or deregistration just because the packet was received over an interface that is an IPv4 tunnel as opposed to the Home Link. That seems plain wrong. I have a tendency to think that what's wrong is really RFC 3775 (lifetime 0 should be the way to deregister) but unless we revise it, I'd suggest we keep consistent with that foundation RFC. If we REALLY do not want a mapped address as source, then maybe we could use the UNSPECIFIED address instead? I'm doing some work on ND proxying in www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt and I had the same issue reusing MIP flows; I ended up going for a fully ND-based registration which made more sense in the case of a connected interface.=20 Pascal _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 09:21:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GqX-00076n-AE; Mon, 17 Dec 2007 09:21:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GqV-00076S-Mg for mext@ietf.org; Mon, 17 Dec 2007 09:21:27 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4GqV-0000cO-8o for mext@ietf.org; Mon, 17 Dec 2007 09:21:27 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBHELL811723; Mon, 17 Dec 2007 14:21:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Date: Mon, 17 Dec 2007 08:21:20 -0600 Message-ID: In-Reply-To: <200712170956.40957.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Minutes of MEXT sessions at IETF-70 Thread-Index: AchAirc/I9fFhvi0SLSKpaoF8/JCPwALUFew References: <200712141306.26246.julien.IETF@laposte.net> <200712170956.40957.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Thanks Julien. Regards, Ahmad =20 > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of Julien Laganier > Sent: Monday, December 17, 2007 2:57 AM > To: mext@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10); George Tsirtsis > Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70 >=20 > Ahmad, George, >=20 > I modified the minutes as we agreed. Thanks. >=20 > --julien >=20 > On Friday 14 December 2007, Ahmad Muhanna wrote: > > > Yes, others talked on the issue, some of their comments=20 > are captured=20 > > > in what follows the excerpt Ahmad wanted to modify (I did=20 > not posted=20 > > > the follow-up originally since nobody asked to modify it): > > > > > > Suresh: the issue is simple and the solution is simple if=20 > we do not=20 > > > try to be too clever. If the HNP is not on-link then the=20 > issue goes=20 > > > away Gerardo Giaretta: This is useful scenario. It is=20 > actually very=20 > > > likely that if you are multihoming, one of the links is=20 > likely to be=20 > > > your home link > > > Kaigo: I also support this to be included in the draft. > > > Prefer the home CoA option > > > Suresh: It is not always easy to generate a home-CoA > > > Sri: Not sure if this should be solved in this draft. > > > Marcelo: There seems to be agreement to support DSMIP, not to=20 > > > support Bulk Registrations, and not clear agreement on the=20 > > > multihoming with home link issue. Will review discussion=20 > on the list=20 > > > to determine how to proceed. > > > > > > > In any case, one way to correct the minutes without all of > > > > > > us loosing > > > > > > > too much time on it, is to remove the entire discussion=20 > following=20 > > > > Ryuji's comment and replace it with "Various people: some > > > > > > discussion > > > > > > > regarding whether we need to support this in this draft or not." > > > > > > That would be fine with me. Let's see what others (Ahmad?) think. > > > > [Ahmad] > > Hi Julien, > > > > Since George agreed in his latest response to your original=20 > proposed=20 > > change, I do not think I need to add anything here. > > > > Regards, > > Ahmad > > > > > --julien > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 09:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4H49-0003J1-RX; Mon, 17 Dec 2007 09:35:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4H46-00039p-8b for mext@ietf.org; Mon, 17 Dec 2007 09:35:30 -0500 Received: from hs-out-0708.google.com ([64.233.178.247] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4H45-0004Mo-S6 for mext@ietf.org; Mon, 17 Dec 2007 09:35:30 -0500 Received: by hs-out-2122.google.com with SMTP id 54so2193789hsz.5 for ; Mon, 17 Dec 2007 06:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cB9JeDeHGyrMkO9I9YwMajAeiaJ7p3IpXUJFdhLhUtE=; b=IRTrpiWVCn7ukO7urdNhWBfX3okyncKq4wR0s/ZX/IngcPbojfiz0FNB5G0PTtz88I5Bi2VfCwepemgXHjE47ea/5ZftRnUeJejHkaGkSdra1bvoIT3HmzJL/x/3BQNrMPlzLJXI000QW3cZa+TAJ1C5kdgFx2jj8RfuvvgFt9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s6AYnHXWu1+Z8Nxx8fxBxYEC0KanaMPO5eWFPqE9F2QjUfRwfjJwUeAyoo/iIM3GjZ+WykPGE3OqRizdQuX1qLG9SktD72Y1UsHFtF84PBsn6mop6ZTyrwgzec4/RbVTCcbfrydmx/WRXIK2BESLmox0nQdcgTcWZVPb2tR72is= Received: by 10.142.104.9 with SMTP id b9mr1121557wfc.48.1197902128566; Mon, 17 Dec 2007 06:35:28 -0800 (PST) Received: by 10.142.11.11 with HTTP; Mon, 17 Dec 2007 06:35:28 -0800 (PST) Message-ID: Date: Mon, 17 Dec 2007 14:35:28 +0000 From: "George Tsirtsis" To: "Alexandru Petrescu" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: <475FF84F.7000802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I agree with Alex on this. I am not sure we have good justification for removing DHAAD. The feature is not broken and arguably the additional bootstraping mechanisms being defined, do not overlap with it since they are dealing with the case when the HNP is not known to the MN. Regards George On Dec 12, 2007 3:03 PM, Alexandru Petrescu wrote: > Jean-Michel Combes wrote: > > Hi, > > > > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > > 11.4.1 > > > > OLD TEXT: -- > > > > NEW TEXT: None > > > > Motivations: - Two proposals have been specified and adopted by the > > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > > for the split and the integrated scenario). - The present DHAAD > > mechanism is, more or less, a scanning tool allowing anyone to know > > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > > DHAAD has not a critical use in others MIPv6 based protocols > > > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > > MIPv6 specification. > > > > Comments are welcome. > > I support keeping DHAAD in the current spec. If necessary, I can > suggest new clarifying text saying that DHAAD used in conjunction with > MPD and a proper IPsec SA setting leads to effective HA address and Home > Address bootstrapping on MN while at home and while away from home. > > Alex > > > > > Best regards. > > > > JMC. > > > > _______________________________________________ MEXT mailing list > > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 10:15:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Hga-00053K-DW; Mon, 17 Dec 2007 10:15:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Ga5-0007Z3-IH for mext@ietf.org; Mon, 17 Dec 2007 09:04:29 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Ga4-0003bo-L7 for mext@ietf.org; Mon, 17 Dec 2007 09:04:29 -0500 Received: from localhost ([127.0.0.1]:45002 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4Ga3-0005nZ-UV; Mon, 17 Dec 2007 15:04:27 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Mon, 17 Dec 2007 14:04:27 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: [mext] #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/3 Message-ID: <070.e56bf756ea0b44b3f51c960da1ba9f0c@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, alexandru.petrescu@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 17 Dec 2007 10:15:14 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167672931==" Errors-To: mext-bounces@ietf.org --===============1167672931== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzM6IEJSUiwgQkVyciBhcmUgc2VudCBieSBIQSB0b28sIG5vdCBvbmx5IGJ5IENOIFtBbGV4YW5k cnUgUGV0cmVzY3UNCjxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPl0NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiBSZXBvcnRlcjogIGp1bGllbi5pZXRmQGxhcG9zdGUubmV0ICB8ICAgICAgIE93 bmVyOiAganVsaWVuLmlldGZAbGFwb3N0ZS5uZXQNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAg ICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3ICAgICAgICAgICAgICAgICAgICANCiBQcmlv cml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgICAgICAg ICAgICAgICAgICAgICANCkNvbXBvbmVudDogIFJGQzM3NzUgY2hhbmdlcyAgICAgICAgICB8ICAg ICBWZXJzaW9uOiAgICAgICAgICAgICAgICAgICAgICAgICANCiBLZXl3b3JkczogICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiB7e3sNCiBTZWN0aW9u IDQsIHN1YnNlY3Rpb24gNC4yLCA1dGggYW5kIDZ0aCBwYXJhZ3JhcGhzLg0KDQogT0xEIFRFWFQ6 DQogPT09PT09PT09DQoNCiAgICBCaW5kaW5nIFJlZnJlc2ggUmVxdWVzdA0KDQogICAgICAgQSBC aW5kaW5nIFJlZnJlc2ggUmVxdWVzdCBpcyB1c2VkIGJ5IGEgY29ycmVzcG9uZGVudCBub2RlIHRv DQogICAgICAgcmVxdWVzdCBhIG1vYmlsZSBub2RlIHRvIHJlLWVzdGFibGlzaCBpdHMgYmluZGlu ZyB3aXRoIHRoZQ0KICAgICAgIGNvcnJlc3BvbmRlbnQgbm9kZS4gIFRoaXMgbWVzc2FnZSBpcyB0 eXBpY2FsbHkgdXNlZCB3aGVuIHRoZQ0KICAgICAgIGNhY2hlZCBiaW5kaW5nIGlzIGluIGFjdGl2 ZSB1c2UgYnV0IHRoZSBiaW5kaW5nJ3MgbGlmZXRpbWUgaXMNCiAgICAgICBjbG9zZSB0byBleHBp cmF0aW9uLiAgVGhlIGNvcnJlc3BvbmRlbnQgbm9kZSBtYXkgdXNlLCBmb3INCiAgICAgICBpbnN0 YW5jZSwgcmVjZW50IHRyYWZmaWMgYW5kIG9wZW4gdHJhbnNwb3J0IGxheWVyIGNvbm5lY3Rpb25z IGFzDQogICAgICAgYW4gaW5kaWNhdGlvbiBvZiBhY3RpdmUgdXNlLg0KDQogICAgQmluZGluZyBF cnJvcg0KDQogICAgICAgVGhlIEJpbmRpbmcgRXJyb3IgaXMgdXNlZCBieSB0aGUgY29ycmVzcG9u ZGVudCBub2RlIHRvIHNpZ25hbCBhbg0KICAgICAgIGVycm9yIHJlbGF0ZWQgdG8gbW9iaWxpdHks IHN1Y2ggYXMgYW4gaW5hcHByb3ByaWF0ZSBhdHRlbXB0IHRvIHVzZQ0KICAgICAgIHRoZSBIb21l IEFkZHJlc3MgZGVzdGluYXRpb24gb3B0aW9uIHdpdGhvdXQgYW4gZXhpc3RpbmcgYmluZGluZy4N Cg0KIE5FVyBURVhUOg0KID09PT09PT09PQ0KICAgIEJpbmRpbmcgUmVmcmVzaCBSZXF1ZXN0DQoN CiAgICAgICBBIEJpbmRpbmcgUmVmcmVzaCBSZXF1ZXN0IGlzIHVzZWQgYnkgYSBjb3JyZXNwb25k ZW50IG5vZGUgb3INCiAgICAgICB0aGUgaG9tZSBhZ2VudCB0byByZXF1ZXN0IGEgbW9iaWxlIG5v ZGUgdG8gcmUtZXN0YWJsaXNoIGl0cw0KICAgICAgIGJpbmRpbmcgd2l0aCB0aGUgY29ycmVzcG9u ZGVudCBub2RlLiAgVGhpcyBtZXNzYWdlIGlzIHR5cGljYWxseQ0KICAgICAgIHVzZWQgd2hlbiB0 aGUgY2FjaGVkIGJpbmRpbmcgaXMgaW4gYWN0aXZlIHVzZSBidXQgdGhlIGJpbmRpbmcncw0KICAg ICAgIGxpZmV0aW1lIGlzIGNsb3NlIHRvIGV4cGlyYXRpb24uICBUaGUgY29ycmVzcG9uZGVudCBu b2RlIG9yIHRoZQ0KICAgICAgIGhvbWUgYWdlbnQgbWF5IHVzZSwgZm9yIGluc3RhbmNlLCByZWNl bnQgdHJhZmZpYyBhbmQgb3Blbg0KICAgICAgIHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9ucyBh cyBhbiBpbmRpY2F0aW9uIG9mIGFjdGl2ZSB1c2UuDQoNCiAgICBCaW5kaW5nIEVycm9yDQoNCiAg ICAgICBUaGUgQmluZGluZyBFcnJvciBpcyB1c2VkIGJ5IHRoZSBjb3JyZXNwb25kZW50IG5vZGUg b3IgdGhlIGhvbWUNCiAgICAgICBhZ2VudCB0byBzaWduYWwgYW4gZXJyb3IgcmVsYXRlZCB0byBt b2JpbGl0eSwgc3VjaCBhcyBhbg0KICAgICAgIGluYXBwcm9wcmlhdGUgYXR0ZW1wdCB0byB1c2Ug dGhlIEhvbWUgQWRkcmVzcyBkZXN0aW5hdGlvbiBvcHRpb24NCiAgICAgICB3aXRob3V0IGFuIGV4 aXN0aW5nIGJpbmRpbmcuDQoNCiBNb3RpdmF0aW9uOg0KID09PT09PT09PT09DQoNCiBFdmVuIHRo b3VnaCBSRkMzNzc1IHN0YXRlcyBhdCBzb21lIHBvaW50IHRoYXQgYSBDTiBjYW4gYmUgYSBIQSwg aXQgaXMNCiB1bmNsZWFyIHdoZW4gaW1wbGVtZW50aW5nIHdoZXRoZXIgYSBIQSBzaG91bGQgaW1w bGVtZW50IHNlbmRpbmcgQlJSIG9yDQogQkVyciB0byB0aGUgTU4gb3Igbm90LiAgU29tZSBwZW9w bGUgaGF2ZSBpbXBsZW1lbnRlZCB0aGlzIGFzIHllcywgSEENCiBzaG91bGQgc2VuZCBCRXJyIGFu ZCBCUlIgdG8gTU4uICBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBvbg0KIHRo ZSBtaXA2IG1haWxpbmcgbGlzdC4gIE5vdGUgdGhhdCB0aGUgZGlzYW1iaWd1YXRpb24gcHJvcG9z ZWQgYWJvdmUgbWF5DQogYmUgbmVlZGVkIGluIHNvbWUgb3RoZXIgcGFydHMgb2YgdGhlIGRvY3Vt ZW50IGFzIHdlbGwuDQogfX19DQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly93d3czLnRvb2xz LmlldGYub3JnL3dnL21leHQvdHJhYy90aWNrZXQvMz4NCm1leHQgPGh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9tZXh0L3RyYWMvPg0K --===============1167672931== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1167672931==-- From mext-bounces@ietf.org Mon Dec 17 10:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Hgb-000541-6s; Mon, 17 Dec 2007 10:15:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GhK-0000Sc-Jk for mext@ietf.org; Mon, 17 Dec 2007 09:11:59 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GhJ-0003lQ-Lr for mext@ietf.org; Mon, 17 Dec 2007 09:11:58 -0500 Received: from localhost ([127.0.0.1]:59110 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4GhI-0006sQ-PQ; Mon, 17 Dec 2007 15:11:56 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Mon, 17 Dec 2007 14:11:56 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: [mext] #4: Remove references to site-local addresses [George Tsirtsis ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/4 Message-ID: <070.97705e43d90be666a719162325d3bc12@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, tsirtsis@googlemail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Mon, 17 Dec 2007 10:15:14 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269572293==" Errors-To: mext-bounces@ietf.org --===============1269572293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzQ6IFJlbW92ZSByZWZlcmVuY2VzIHRvIHNpdGUtbG9jYWwgYWRkcmVzc2VzIFtHZW9yZ2UgVHNp cnRzaXMNCjx0c2lydHNpc0Bnb29nbGVtYWlsLmNvbT5dDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog UmVwb3J0ZXI6ICBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCAgfCAgICAgICBPd25lcjogIGp1bGll bi5pZXRmQGxhcG9zdGUubmV0DQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAg fCAgICAgIFN0YXR1czogIG5ldyAgICAgICAgICAgICAgICAgICAgDQogUHJpb3JpdHk6ICBtYWpv ciAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgICAgICAgICAgICAgICAgICAg ICAgDQpDb21wb25lbnQ6ICBSRkMzNzc1IGNoYW5nZXMgICAgICAgICAgfCAgICAgVmVyc2lvbjog ICAgICAgICAgICAgICAgICAgICAgICAgDQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoge3t7DQogLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIE9MRCBURVhUOg0KID09PT09PT09PQ0KIDMuMS4gR2Vu ZXJhbCBUZXJtcw0KIC4uLg0KICAgIHVuaWNhc3Qgcm91dGFibGUgYWRkcmVzcw0KDQogICAgICAg QW4gaWRlbnRpZmllciBmb3IgYSBzaW5nbGUgaW50ZXJmYWNlIHN1Y2ggdGhhdCBhIHBhY2tldCBz ZW50IHRvIGl0DQogICAgICAgZnJvbSBhbm90aGVyIElQdjYgc3VibmV0IGlzIGRlbGl2ZXJlZCB0 byB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZWQNCiAgICAgICBieSB0aGF0IGFkZHJlc3MuICBBY2Nv cmRpbmdseSwgYSB1bmljYXN0IHJvdXRhYmxlIGFkZHJlc3MgbXVzdA0KICAgICAgIGhhdmUgZWl0 aGVyIGEgZ2xvYmFsIG9yIHNpdGUtbG9jYWwgc2NvcGUgKGJ1dCBub3QgbGluay1sb2NhbCkuDQoN CiBORVcgVEVYVDoNCiA9PT09PT09PT0NCiAzLjEuIEdlbmVyYWwgVGVybXMNCiAuLi4NCiAgICB1 bmljYXN0IHJvdXRhYmxlIGFkZHJlc3MNCg0KICAgICAgIEFuIGlkZW50aWZpZXIgZm9yIGEgc2lu Z2xlIGludGVyZmFjZSBzdWNoIHRoYXQgYSBwYWNrZXQgc2VudCB0byBpdA0KICAgICAgIGZyb20g YW5vdGhlciBJUHY2IHN1Ym5ldCBpcyBkZWxpdmVyZWQgdG8gdGhlIGludGVyZmFjZSBpZGVudGlm aWVkDQogICAgICAgYnkgdGhhdCBhZGRyZXNzLiAgQWNjb3JkaW5nbHksIGEgdW5pY2FzdCByb3V0 YWJsZSBhZGRyZXNzIG11c3QNCiAgICAgICBlaXRoZXIgYmUgZ2xvYmFsIElQdjYgYWRkcmVzcyBv ciBhIHVuaXF1ZSBsb2NhbCBJUHY2IGFkZHJlc3MuDQoNCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCiBPTEQgVEVYVDoNCiA9PT09PT09PT0NCiA0LjYuIFNpdGUt TG9jYWwgQWRkcmVzc2FiaWxpdHkNCg0KDQogICAgVGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVz IHRoYXQgaG9tZSBhbmQgY2FyZS1vZiBhZGRyZXNzZXMgTVVTVCBiZQ0KICAgIHVuaWNhc3Qgcm91 dGFibGUgYWRkcmVzc2VzLiAgU2l0ZS1sb2NhbCBhZGRyZXNzZXMgbWF5IGJlIHVzYWJsZSBvbg0K ICAgIG5ldHdvcmtzIHRoYXQgYXJlIG5vdCBjb25uZWN0ZWQgdG8gdGhlIEludGVybmV0LCBidXQg dGhpcw0KICAgIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZGVmaW5lIHdoZW4gc3VjaCB1c2FnZSBp cyBzYWZlIGFuZCB3aGVuIGl0IGlzDQogICAgbm90LiAgTW9iaWxlIG5vZGVzIG1heSBub3QgYmUg YXdhcmUgb2Ygd2hpY2ggc2l0ZSB0aGV5IGFyZSBjdXJyZW50bHkNCiAgICBpbiwgaXQgaXMgaGFy ZCB0byBwcmV2ZW50IGFjY2lkZW50YWwgYXR0YWNobWVudCB0byBvdGhlciBzaXRlcywgYW5kDQog ICAgYW1iaWd1aXR5IG9mIHNpdGUtbG9jYWwgYWRkcmVzc2VzIGNhbiBjYXVzZSBwcm9ibGVtcyBp ZiB0aGUgaG9tZSBhbmQNCiAgICB2aXNpdGVkIG5ldHdvcmtzIHVzZSB0aGUgc2FtZSBhZGRyZXNz ZXMuICBUaGVyZWZvcmUsIHNpdGUtbG9jYWwNCiAgICBhZGRyZXNzZXMgU0hPVUxEIE5PVCBiZSB1 c2VkIGFzIGhvbWUgb3IgY2FyZS1vZiBhZGRyZXNzZXMuDQoNCiBORVcgVEVYVDoNCiA9PT09PT09 PT0NCiA0LjYuIFVuaXF1ZS1Mb2NhbCBBZGRyZXNzYWJpbGl0eQ0KDQogICAgVGhpcyBzcGVjaWZp Y2F0aW9uIHJlcXVpcmVzIHRoYXQgaG9tZSBhbmQgY2FyZS1vZiBhZGRyZXNzZXMgTVVTVCBiZQ0K ICAgIHVuaWNhc3Qgcm91dGFibGUgYWRkcmVzc2VzLiAgVW5pcXVlLWxvY2FsIElQdjYgdW5pY2Fz dCBhZGRyZXNzZXMNCiBbUkZDNDE5M10NCiAgICBtYXkgYmUgdXNhYmxlIG9uIG5ldHdvcmtzIHRo YXQgdXNlIHN1Y2ggbm9uLWdsb2JhbHkgcm91dGFibGUgYWRkcmVzc2VzDQogICAgYnV0IHRoaXMg c3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkZWZpbmUgd2hlbiBzdWNoIHVzYWdlIGlzIHNhZmUgYW5k IHdoZW4NCiBpdCBpcw0KICAgIG5vdC4gIE1vYmlsZSBub2RlcyBtYXkgbm90IGJlIGF3YXJlIG9m IHdoaWNoIHNpdGUgdGhleSBhcmUgY3VycmVudGx5DQogICAgbWFraW5nIGl0IGhhcmQgdG8gcHJl dmVudCBhY2NpZGVudGFsIGF0dGFjaG1lbnQgdG8gb3RoZXIgc2l0ZXMsDQogcmVzdWx0aW5nIGlu DQogICAgcG9zc2libGUgdW5yZWNoYWJpbGl0eSBiZXR3ZWVuIHRoZSBNTiBhbmQgdGhlIEhBLCB3 aGVuIHVuaXF1ZS1sb2NhbA0KIElQdjYNCiAgICByb3V0YWJsZSBhZGRyZXNzZXMgYXJlIHVzZWQg YXMgY2FyZS1vZiBhZGRyZXNzZXMuIEFsc28sIENOcyBvdXRzaWRlIHRoZQ0KIE1OJ3MNCiAgICBv d24gc2l0ZSBhcmUgbm90IGdvaW5nIHRvIGJlIHJlYWNoYWJsZSB3aGVuIHVuaXF1ZS1sb2NhbCBJ UHY2IHJvdXRhYmxlDQogYWRkcmVzc2VzDQogICAgYXJlIHVzZWQgYXMgaG9tZSBhZGRyZXNzZXMu IFRoZXJlZm9yZSwgdW5pcXVlLWxvY2FsIElQdjYgdW5pY2FzdA0KIGFkZHJlc3Nlcw0KICAgIFNI T1VMRCBOT1QgYmUgdXNlZCBhcyBob21lIG9yIGNhcmUtb2YgYWRkcmVzc2VzLiBJZiBzdWNoIGFk ZHJlc3NlcyBhcmUNCiB1c2VkLA0KICAgIGhvd2V2ZXIsIGFjY29yZGluZyB0byBbUkZDNDE5M10s IHRoZXkgYXJlIHRyZWF0ZWQgYXMgYW55IGdsb2JhbCB1bmljYXN0DQogSVB2Ng0KICAgIGFkZHJl c3Mgc28sIGZvciB0aGUgcmVtYWluZGVyIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgdXNlIG9mIHVu aXF1ZS0NCiBsb2NhbCBJUHY2IHVuaWNhc3QNCiAgICBhZGRyZXNzZXMgaXMgbm90IGRpZmZlcmVu dGlhdGVkIGZyb20gb3RoZXIgZ2xvYmFsbHkgdW5pcXVlIElQdjYNCiBhZGRyZXNzZXMuDQoNCiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiBPTEQgVEVYVDoNCiA9 PT09PT09PT0NCiAxMC40LjIuIFByb2Nlc3NpbmcgSW50ZXJjZXB0ZWQgUGFja2V0cw0KIC4uLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uIFBhY2tldHMg YWRkcmVzc2VkIHRvDQogICAgdGhlIG1vYmlsZSBub2RlJ3Mgc2l0ZS1sb2NhbCBhZGRyZXNzIFNI T1VMRCBOT1QgYmUgdHVubmVsZWQgdG8gdGhlDQogICAgbW9iaWxlIG5vZGUgYnkgZGVmYXVsdC4N Cg0KIE5FVyBURVhUIChOb25lOiBvbGQgdGV4dCByZW1vdmVkKQ0KID09PT09PT09PQ0KDQogLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogT0xEIFRFWFQ6DQogPT09 PT09PT09DQogMTEuMy4xLiBTZW5kaW5nIFBhY2tldHMgV2hpbGUgQXdheSBmcm9tIEhvbWUNCiAu Li4NCiAgICAgICBvICBXaGlsZSBub3QgYXQgaXRzIGhvbWUgbGluaywgdGhlIG1vYmlsZSBub2Rl IE1VU1QgTk9UIHVzZSB0aGUgSG9tZQ0KICAgICAgIEFkZHJlc3MgZGVzdGluYXRpb24gb3B0aW9u IHdoZW4gY29tbXVuaWNhdGluZyB3aXRoIGxpbmstbG9jYWwgb3INCiAgICAgICBzaXRlLWxvY2Fs IHBlZXJzLCBpZiB0aGUgc2NvcGUgb2YgdGhlIGhvbWUgYWRkcmVzcyBpcyBsYXJnZXIgdGhhbg0K ICAgICAgIHRoZSBzY29wZSBvZiB0aGUgcGVlcidzIGFkZHJlc3MuDQoNCiBORVcgVEVYVDoNCiA9 PT09PT09PT0NCiAxMS4zLjEuIFNlbmRpbmcgUGFja2V0cyBXaGlsZSBBd2F5IGZyb20gSG9tZQ0K IC4uLg0KICAgIG8gIFdoaWxlIG5vdCBhdCBpdHMgaG9tZSBsaW5rLCB0aGUgbW9iaWxlIG5vZGUg TVVTVCBOT1QgdXNlIHRoZSBIb21lDQogICAgICAgQWRkcmVzcyBkZXN0aW5hdGlvbiBvcHRpb24g d2hlbiBjb21tdW5pY2F0aW5nIHdpdGggbGluay1sb2NhbCBwZWVycy4NCg0KIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIE9MRCBURVhUOg0KID09PT09PT09PQ0K IDExLjUuNC4gUmV0dXJuaW5nIEhvbWUNCiAuLi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4uLlRoZSBtb2JpbGUgbm9kZSBNVVNUIG11bHRpY2FzdCBzdWNoIGENCiAgICBOZWln aGJvciBBZHZlcnRpc2VtZW50IGZvciBlYWNoIG9mIGl0cyBob21lIGFkZHJlc3NlcywgYXMgZGVm aW5lZCBieQ0KICAgIHRoZSBjdXJyZW50IG9uLWxpbmsgcHJlZml4ZXMsIGluY2x1ZGluZyBpdHMg bGluay1sb2NhbCBhZGRyZXNzIGFuZA0KICAgIHNpdGUtbG9jYWwgYWRkcmVzcy4NCg0KIE5FVyBU RVhUOg0KID09PT09PT09PQ0KIDExLjUuNC4gUmV0dXJuaW5nIEhvbWUNCiAuLi4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4uLlRoZSBtb2JpbGUgbm9kZSBNVVNUIG11bHRpY2Fz dCBzdWNoIGENCiAgICBOZWlnaGJvciBBZHZlcnRpc2VtZW50IGZvciBlYWNoIG9mIGl0cyBob21l IGFkZHJlc3NlcywgYXMgZGVmaW5lZCBieQ0KICAgIHRoZSBjdXJyZW50IG9uLWxpbmsgcHJlZml4 ZXMsIGluY2x1ZGluZyBpdHMgbGluay1sb2NhbCBhZGRyZXNzLg0KDQogLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogTU9USVZBVElPTjoNCiA9PT09PT09PT09PQ0K DQogU2l0ZS1sb2NhbCBhZGRyZXNzZXMgaGF2ZSBiZWVuIGRlcHJlY2F0ZWQgKHNlZSBSRkMzODc5 KS4gQWNjb3JkaW5nIHRvDQogdGhpcyBSRkMsIGZ1dHVyZSB2ZXJzaW9ucyBvZiBSRkNzIHRoYXQg bWVudGlvbiBzaXRlLWxvY2FsIGFkZHJlc3Nlcw0KIHNob3VsZCByZW1vdmUgc3VjaCByZWZlcmVu Y2VzIGFuZCByZXBsYWNlIHRoZW0gd2l0aCBhcHByb3ByaWF0ZQ0KIGFsdGVybmF0aXZlcy4gSW4g dGhlIG1lYW4gdGltZSBhbiBhbHRlcm5hdGl2ZSB0byBzaXRlLWxvY2FsIGFkZHJlc3Nlcw0KIGhh cyBiZWVuIGRlZmluZWQgaW4gUkZDNDE5MyAoVW5pcXVlLWxvY2FsIElQdjYgcm91dGFibGUgYWRk cmVzc2VzKS4NCiBBY2NvcmRpbmcgdG8gdGhpcyBSRkMsIHRoZXNlIGFkZHJlc3NlcyBoYXZlIGxp bWl0ZWQgcm91dGFiaWxpdHkNCiAodHlwaWNhbGx5IHdpdGhpbiBvbmUgb3Igc21hbGwgbnVtYmVy IG9mIHNpdGVzKSBidXQgdGhleSBhcmUgb3RoZXJ3aXNlDQogdHJlYXRlZCBhcyBvdGhlciBnbG9i YWwgSVB2NiBhZGRyZXNzZXMuDQoNCiBCYXNlZCBvbiB0aGUgYWJvdmUsIHRoZSBuZXcgdGV4dCBw cm9wb3NlZCBhYm92ZSByZW1vdmVzIGFsbCByZWZlcmVuY2VzDQogdG8gc2l0ZS1sb2NhbCBhZGRy ZXNzZXMgYW5kIHJlcGxhY2VzIHRoZW0gd2l0aCB1bmlxdWUtbG9jYWwgSVB2Ng0KIGFkZHJlc3Nl cyBhcyBkaXJlY3RlZCBieSBSRkMzODc5IGFuZCBSRkM0MTkzLg0KDQotLSANClRpY2tldCBVUkw6 IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9tZXh0L3RyYWMvdGlja2V0LzQ+DQptZXh0 IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbWV4dC90cmFjLz4NCg== --===============1269572293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1269572293==-- From mext-bounces@ietf.org Mon Dec 17 10:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4HgZ-00052h-QF; Mon, 17 Dec 2007 10:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GVd-0007ip-Mk for mext@ietf.org; Mon, 17 Dec 2007 08:59:53 -0500 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4GVd-0003TZ-7Q for mext@ietf.org; Mon, 17 Dec 2007 08:59:53 -0500 Received: from localhost ([127.0.0.1]:48017 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4GVc-0005f0-6Z; Mon, 17 Dec 2007 14:59:52 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Mon, 17 Dec 2007 13:59:52 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2 Message-ID: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 17 Dec 2007 10:15:13 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2140349844==" Errors-To: mext-bounces@ietf.org --===============2140349844== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzI6IFJlbW92aW5nIERIQUFEIG1lY2hhbmlzbSBbSmVhbi1NaWNoZWwgQ29tYmVzIDxqZWFubWlj aGVsLmNvbWJlc0BnbWFpbC5jb20+XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAg anVsaWVuLmlldGZAbGFwb3N0ZS5uZXQgIHwgICAgICAgT3duZXI6ICBqdWxpZW4uaWV0ZkBsYXBv c3RlLm5ldA0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0 dXM6ICBuZXcgICAgICAgICAgICAgICAgICAgIA0KIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAg ICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAgICAgICAgICAgICAgICAgICAgIA0KQ29tcG9u ZW50OiAgUkZDMzc3NSBjaGFuZ2VzICAgICAgICAgIHwgICAgIFZlcnNpb246ICAgICAgICAgICAg ICAgICAgICAgICAgIA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIHt7ew0KIE9MRCBURVhUOg0KID09PT09PT09PQ0KDQogTi9B DQoNCiBORVcgVEVYVDoNCiA9PT09PT09PT0NCg0KIE4vQQ0KDQogTW90aXZhdGlvbjoNCiA9PT09 PT09PT09PQ0KDQogLSBUd28gcHJvcG9zYWxzIGhhdmUgYmVlbiBzcGVjaWZpZWQgYW5kIGFkb3B0 ZWQgYnkgdGhlIE1JUDYgV0cgdG8NCiBhbGxvdyBhIE1OIHRvIGdldCBpdHMgSEEgKGkuZS4gYm9v dHN0cmFwcGluZyBtZWNoYW5pc21zIGZvciB0aGUgc3BsaXQNCiBhbmQgdGhlIGludGVncmF0ZWQg c2NlbmFyaW8pLg0KIC0gVGhlIHByZXNlbnQgREhBQUQgbWVjaGFuaXNtIGlzLCBtb3JlIG9yIGxl c3MsIGEgc2Nhbm5pbmcgdG9vbA0KIGFsbG93aW5nIGFueW9uZSB0byBrbm93IHdoYXQvd2hlcmUg YXJlIHRoZSBIQXMgb3duZWQgYnkgYSBNb2JpbGl0eQ0KIFNlcnZpY2UgUHJvdmlkZXIuDQogLSBB RkFJSywgREhBQUQgaGFzIG5vdCBhIGNyaXRpY2FsIHVzZSBpbiBvdGhlcnMgTUlQdjYgYmFzZWQg cHJvdG9jb2xzDQoNCiBTbywgSSB3b25kZXIgaWYgaXQgaXMgc3RpbGwgdXNlZnVsIHRvIGtlZXAg dGhlIERIQUFEIG1lY2hhbmlzbSBpbiB0aGUNCiBNSVB2NiBzcGVjaWZpY2F0aW9uLg0KIH19fQ0K DQotLSANClRpY2tldCBVUkw6IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9tZXh0L3Ry YWMvdGlja2V0LzI+DQptZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvbWV4dC90cmFjLz4N Cg== --===============2140349844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============2140349844==-- From mext-bounces@ietf.org Mon Dec 17 10:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IDn-0008I8-UZ; Mon, 17 Dec 2007 10:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IDm-0008G9-IW for mext@ietf.org; Mon, 17 Dec 2007 10:49:34 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4IDl-0006LW-79 for mext@ietf.org; Mon, 17 Dec 2007 10:49:34 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1197906570!18757312!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7981 invoked from network); 17 Dec 2007 15:49:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 17 Dec 2007 15:49:30 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBHFnUgO014126 for ; Mon, 17 Dec 2007 08:49:30 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lBHFnTDL014578 for ; Mon, 17 Dec 2007 09:49:29 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lBHFnR7Z014539 for ; Mon, 17 Dec 2007 09:49:28 -0600 (CST) Message-ID: <47669A87.100@gmail.com> Date: Mon, 17 Dec 2007 16:49:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mext@ietf.org Subject: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ]] Content-Type: multipart/mixed; boundary="------------080308020003050002020606" X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------080308020003050002020606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit [A series of 4 mails happened on mip6 list, due to my error initiating the exchange there. I should have done it here on the mext list.] It's discussion around the Last Accepted SQN. >>> But this is new software to write and implement, right? This is >>> not a minor modification to rfc3775. > > [Ahmad] That's true. However, do you agree with the issue? > > This proposal is one solution for the issue; if you have a different > solution which does not require this change, please go ahead and > propose it. I do not have any interest in having this proposal > adopted, however, IMO, this issue needs to be resolved. While reading it, looks as a situation difficult to reproduce, to start with. If the proposed solution is not implemented then the MN may start over from a fresh seqno. That's why I don't see why correcting this as part of the minor rfc3775 corrections. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ --------------080308020003050002020606 Content-Type: message/rfc822; name="[Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ].eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ; Mon, 17 Dec 2007 08:30:32 -0600 (CST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by ftpbox.mot.com (8.12.11/Motorola) with SMTP id lBHEUVJ1004639 for ; Mon, 17 Dec 2007 08:30:31 -0600 (CST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1197901819!7164097!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.128.185] X-SpamReason: No, hits=3.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP, SUBJECT_RANDOMQ Received: (qmail 8837 invoked from network); 17 Dec 2007 14:30:20 -0000 Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.185) by server-14.tower-153.messagelabs.com with SMTP; 17 Dec 2007 14:30:20 -0000 Received: by fk-out-0910.google.com with SMTP id z22so1737202fkz.1 for ; Mon, 17 Dec 2007 06:30:19 -0800 (PST) Received: by 10.82.174.20 with SMTP id w20mr5296896bue.28.1197901819243; Mon, 17 Dec 2007 06:30:19 -0800 (PST) X-Forwarded-To: alexandru.petrescu@motorola.com X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@motorola.com Delivered-To: alexandru.petrescu@gmail.com Received: by 10.82.157.12 with SMTP id f12cs211761bue; Mon, 17 Dec 2007 06:30:18 -0800 (PST) Received: by 10.100.106.1 with SMTP id e1mr14775084anc.35.1197901805800; Mon, 17 Dec 2007 06:30:05 -0800 (PST) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by mx.google.com with ESMTP id r28si5100683ele.2007.12.17.06.29.30; Mon, 17 Dec 2007 06:30:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of mip6-bounces@ietf.org designates 156.154.16.145 as permitted sender) client-ip=156.154.16.145; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of mip6-bounces@ietf.org designates 156.154.16.145 as permitted sender) smtp.mail=mip6-bounces@ietf.org Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GxO-0008FU-EZ; Mon, 17 Dec 2007 09:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GxN-0008FG-TN for mip6@ietf.org; Mon, 17 Dec 2007 09:28:33 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4GxN-0004DQ-I4 for mip6@ietf.org; Mon, 17 Dec 2007 09:28:33 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1197901712!44889156!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15169 invoked from network); 17 Dec 2007 14:28:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 17 Dec 2007 14:28:32 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBHESVWH014672 for ; Mon, 17 Dec 2007 07:28:31 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lBHESUJB003465 for ; Mon, 17 Dec 2007 08:28:31 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lBHEST2m003444 for ; Mon, 17 Dec 2007 08:28:30 -0600 (CST) Message-ID: <4766878C.7000803@gmail.com> Date: Mon, 17 Dec 2007 15:28:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mobile IPv6 Mailing List References: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> In-Reply-To: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 17 Dec 2007 14:30:33.0354 (UTC) FILETIME=[61C5CEA0:01C840B9] X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Inbound message X-Antivirus-Status: Clean mext wrote: > #1: Last Accepted SQN [Ahmad Muhanna ] > -------------------------------------+-------------------------------------- > Reporter: julien.ietf@laposte.net | Owner: julien.ietf@laposte.net > Type: defect | Status: new > Priority: major | Milestone: > Component: RFC3775 changes | Version: [...] > SOLUTION: > ========= > > The most straightforward solution for this issue is to enable the > original intention of RFC3775. i.e. by communicating back the last > successful sequence number in a option: > > Las Valid Sequence Number Mobility Option: > 6.2.x. Last Valid Sequence Number > > The Last Valid Sequence Number option has an alignment requirement > of 2n. Its format is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=TBD | Length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Last Valid Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Last Valid Sequence Number option is only valid in a BA, sent > from the mobile node's home agent in reply to a home registration, > with a status of 135. The Last Valid Sequence Number is the last > sequence number that the Home Agent received in the last successful > Binding Update for the specified session. In case the Home Agent > receives a Binding Update with a sequence number outside the valid > sequence number range, the Home Agent sends a BA with a status of > 135. HA must copy the sequence number from the BU into the sequence > number field of the BA. HA must include the last Valid Sequence > Number into the Last valid Sequence Number Mobility option. }}} But this is new software to write and implement, right? This is not a minor modification to rfc3775. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------080308020003050002020606 Content-Type: message/rfc822; name="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ].eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna <"; filename*1="amuhanna@nortel.com>].eml" Received: from il06exr04.mot.com ([129.188.137.134]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 17 Dec 2007 14:37:16 +0000 Received: from motgate.mot.com (motgate6.mot.com [129.188.136.10]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lBHEbF7I021775 for ; Mon, 17 Dec 2007 08:37:15 -0600 (CST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by motgate.mot.com (8.12.11/Motorola) with SMTP id lBHEbEPI006768 for ; Mon, 17 Dec 2007 07:37:14 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1197902284!14636010!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.128.189] X-SpamReason: No, hits=3.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP, SUBJECT_RANDOMQ Received: (qmail 11639 invoked from network); 17 Dec 2007 14:38:05 -0000 Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.189) by server-13.tower-128.messagelabs.com with SMTP; 17 Dec 2007 14:38:05 -0000 Received: by fk-out-0910.google.com with SMTP id 26so1507097fkx.10 for ; Mon, 17 Dec 2007 06:37:12 -0800 (PST) Received: by 10.82.160.19 with SMTP id i19mr5123906bue.19.1197902232273; Mon, 17 Dec 2007 06:37:12 -0800 (PST) X-Forwarded-To: alexandru.petrescu@motorola.com X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@motorola.com Delivered-To: alexandru.petrescu@gmail.com Received: by 10.82.157.12 with SMTP id f12cs212163bue; Mon, 17 Dec 2007 06:37:11 -0800 (PST) Received: by 10.64.131.4 with SMTP id e4mr14951497qbd.68.1197902229511; Mon, 17 Dec 2007 06:37:09 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by mx.google.com with ESMTP id f18si3136867qba.2007.12.17.06.37.08; Mon, 17 Dec 2007 06:37:09 -0800 (PST) Received-SPF: pass (google.com: domain of AMUHANNA@nortel.com designates 47.129.242.56 as permitted sender) client-ip=47.129.242.56; Authentication-Results: mx.google.com; spf=pass (google.com: domain of AMUHANNA@nortel.com designates 47.129.242.56 as permitted sender) smtp.mail=AMUHANNA@nortel.com Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lBHEXhU22455; Mon, 17 Dec 2007 14:33:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ] Date: Mon, 17 Dec 2007 08:37:00 -0600 Message-ID: In-Reply-To: <4766878C.7000803@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ] Thread-Index: AchAuT75/fQIRlFATMKCBUxunOkHkwAAAMIg References: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> <4766878C.7000803@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu", "Mobile IPv6 Mailing List" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 17 Dec 2007 14:37:16.0603 (UTC) FILETIME=[5220B8B0:01C840BA] X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Inbound message X-Antivirus-Status: Clean Hi Alex, Please see comments inline. Regards, Ahmad > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Monday, December 17, 2007 8:28 AM > To: Mobile IPv6 Mailing List > Subject: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad=20 > Muhanna ] >=20 > mext wrote: > > #1: Last Accepted SQN [Ahmad Muhanna ] > >=20 > -------------------------------------+-------------------------------- > > -------------------------------------+------ > > Reporter: julien.ietf@laposte.net | Owner: =20 > julien.ietf@laposte.net > > Type: defect | Status: new =20 > =20 > > Priority: major | Milestone: =20 > =20 > > Component: RFC3775 changes | Version: =20 > =20 > [...] > > SOLUTION: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > The most straightforward solution for this issue is to enable the =20 > > original intention of RFC3775. i.e. by communicating back the last =20 > > successful sequence number in a option: > >=20 > > Las Valid Sequence Number Mobility Option: > > 6.2.x. Last Valid Sequence Number > >=20 > > The Last Valid Sequence Number option has an alignment=20 > requirement > > of 2n. Its format is as follows: > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=3DTBD | =20 > Length =3D 2 | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Last Valid Sequence Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > The Last Valid Sequence Number option is only valid in a=20 > BA, sent from=20 > > the mobile node's home agent in reply to a home=20 > registration, with a=20 > > status of 135. The Last Valid Sequence Number is the last sequence=20 > > number that the Home Agent received in the last successful Binding=20 > > Update for the specified session. In case the Home Agent receives a=20 > > Binding Update with a sequence number outside the valid sequence=20 > > number range, the Home Agent sends a BA with a status of=20 > 135. HA must=20 > > copy the sequence number from the BU into the sequence=20 > number field of=20 > > the BA. HA must include the last Valid Sequence Number into=20 > the Last=20 > > valid Sequence Number Mobility option. }}} >=20 > But this is new software to write and implement, right? This=20 > is not a minor modification to rfc3775. [Ahmad] That's true. However, do you agree with the issue? =20 This proposal is one solution for the issue; if you have a different solution which does not require this change, please go ahead and propose it. I do not have any interest in having this proposal adopted, however, IMO, this issue needs to be resolved. =20 >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 --------------080308020003050002020606 Content-Type: message/rfc822; name="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna].eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna"; filename*1="].eml" Received: from zuk35exm63.ds.mot.com ([10.178.4.20]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 17 Dec 2007 14:51:49 +0000 Received: from il06exr03.mot.com ([129.188.137.133]) by zuk35exm63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 17 Dec 2007 14:51:48 +0000 Received: from motgate.mot.com (motgate6.mot.com [129.188.136.10]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lBHEpkCe026711 for ; Mon, 17 Dec 2007 08:51:46 -0600 (CST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by motgate.mot.com (8.12.11/Motorola) with SMTP id lBHEpj5h009174 for ; Mon, 17 Dec 2007 07:51:45 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1197903102!18746199!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.128.185] X-SpamReason: No, hits=4.3 required=7.0 tests=ADDRESS_IN_SUBJECT, BODY_RANDOMQ,RCVD_BY_IP,SUBJECT_RANDOMQ,UNPARSEABLE_RELAY Received: (qmail 29505 invoked from network); 17 Dec 2007 14:51:43 -0000 Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.185) by server-8.tower-128.messagelabs.com with SMTP; 17 Dec 2007 14:51:43 -0000 Received: by fk-out-0910.google.com with SMTP id f33so1574838fkf.7 for ; Mon, 17 Dec 2007 06:51:42 -0800 (PST) Received: by 10.82.159.15 with SMTP id h15mr5355620bue.36.1197903102106; Mon, 17 Dec 2007 06:51:42 -0800 (PST) X-Forwarded-To: alexandru.petrescu@motorola.com X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@motorola.com Delivered-To: alexandru.petrescu@gmail.com Received: by 10.82.157.12 with SMTP id f12cs213002bue; Mon, 17 Dec 2007 06:51:41 -0800 (PST) Received: by 10.82.174.20 with SMTP id w20mr16246401bue.7.1197903098211; Mon, 17 Dec 2007 06:51:38 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by mx.google.com with ESMTP id g11si5569314gve.2007.12.17.06.51.37; Mon, 17 Dec 2007 06:51:38 -0800 (PST) Received-SPF: pass (google.com: domain of marcelo@it.uc3m.es designates 163.117.176.133 as permitted sender) client-ip=163.117.176.133; Authentication-Results: mx.google.com; spf=pass (google.com: domain of marcelo@it.uc3m.es designates 163.117.176.133 as permitted sender) smtp.mail=marcelo@it.uc3m.es Received: from [163.117.139.66] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.66])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 1A4AD2904A6;Mon, 17 Dec 2007 15:51:37 +0100 (CET) In-Reply-To: References: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org><4766878C.7 000803@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: "Alexandru Petrescu", "Mobile IPv6 Mailing List" Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna] Date: Mon, 17 Dec 2007 15:51:48 +0100 To: Ahmad Muhanna X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.6211 TC:1F TRN:22 TV:5.0.1023(15612.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 17 Dec 2007 14:51:48.0636 (UTC) FILETIME=[59E665C0:01C840BC] X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Inbound message X-Antivirus-Status: Clean El 17/12/2007, a las 15:37, Ahmad Muhanna escribi=F3: > [Ahmad] > That's true. If you agree that this is true, then this particular proposal is a =20 non starter If you come with an alternative proposal that is a minor change the =20 resubmit it to the ml using the same format please, so we can keep an =20= ordered track of the proposed issues Regards, marcelo > However, do you agree with the issue? > > This proposal is one solution for the issue; if you have a different > solution which does not require this change, please go ahead and =20 > propose > it. I do not have any interest in having this proposal adopted, =20 > however, > IMO, this issue needs to be resolved. --------------080308020003050002020606 Content-Type: message/rfc822; name="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna].eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna"; filename*1="].eml" Received: from zuk35exm63.ds.mot.com ([10.178.4.20]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 17 Dec 2007 14:58:52 +0000 Received: from az33exr03.mot.com ([10.64.251.233]) by zuk35exm63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 17 Dec 2007 14:58:51 +0000 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lBHEwf3x014276 for ; Mon, 17 Dec 2007 08:58:42 -0600 (CST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by motgate4.mot.com (8.12.11/Motorola) with SMTP id lBHEwf5i014197 for ; Mon, 17 Dec 2007 07:58:41 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gma il.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1197903519!20257492!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.85.128.186] X-SpamReason: No, hits=3.3 required=7.0 tests=BODY_RANDOMQ,RCVD_BY_IP, SUBJECT_RANDOMQ Received: (qmail 25261 invoked from network); 17 Dec 2007 14:58:39 -0000 Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.186) by server-11.tower-153.messagelabs.com with SMTP; 17 Dec 2007 14:58:39 -0000 Received: by fk-out-0910.google.com with SMTP id 18so1732356fks.4 for ; Mon, 17 Dec 2007 06:58:38 -0800 (PST) Received: by 10.82.112.3 with SMTP id k3mr2441005buc.15.1197903518891; Mon, 17 Dec 2007 06:58:38 -0800 (PST) X-Forwarded-To: alexandru.petrescu@motorola.com X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@motorola.com Delivered-To: alexandru.petrescu@gmail.com Received: by 10.82.157.12 with SMTP id f12cs213433bue; Mon, 17 Dec 2007 06:58:37 -0800 (PST) Received: by 10.100.111.5 with SMTP id j5mr14762448anc.97.1197903516602; Mon, 17 Dec 2007 06:58:36 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by mx.google.com with ESMTP id n29si13131018elf.2007.12.17.06.58.34; Mon, 17 Dec 2007 06:58:36 -0800 (PST) Received-SPF: pass (google.com: domain of AMUHANNA@nortel.com designates 47.140.192.56 as permitted sender) client-ip=47.140.192.56; Authentication-Results: mx.google.com; spf=pass (google.com: domain of AMUHANNA@nortel.com designates 47.140.192.56 as permitted sender) smtp.mail=AMUHANNA@nortel.com Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBHEwM820084; Mon, 17 Dec 2007 14:58:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna] Date: Mon, 17 Dec 2007 08:58:21 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna] Thread-Index: AchAvFctcwoaQZatQO+3ojXk/U3EIgAAAUKg References: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org><4766878C.7 000803@gmail.com> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" Cc: "Alexandru Petrescu", "Mobile IPv6 Mailing List" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=motorola.com@gmail.com X-OriginalArrivalTime: 17 Dec 2007 14:58:52.0339 (UTC) FILETIME=[56725830:01C840BD] X-Antivirus: avast! (VPS 071216-0, 16/12/2007), Inbound message X-Antivirus-Status: Clean Hi Marcelo, I believe this is an issue that needs to be fixed. Many implementation = did not test if this work in their software or not until this issue was = pointed out. IMO, this is an error needs to be fixed. On the other hand, I do not see any quick fix for this issue, however, = if there is someone who can point a quick fix, he is welcome to post it. = If the group think that fixing this issue is not needed, that is fine = with too. BTW: This issue was also discussed before and was submitted to MIP6 = tracker. Regards, Ahmad =20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Monday, December 17, 2007 8:52 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Alexandru Petrescu; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad=20 > Muhanna] >=20 >=20 > El 17/12/2007, a las 15:37, Ahmad Muhanna escribi=F3: >=20 > > [Ahmad] > > That's true. >=20 > If you agree that this is true, then this particular proposal=20 > is a non starter >=20 > If you come with an alternative proposal that is a minor=20 > change the resubmit it to the ml using the same format=20 > please, so we can keep an ordered track of the proposed issues >=20 > Regards, marcelo >=20 > > However, do you agree with the issue? > > > > This proposal is one solution for the issue; if you have a=20 > different=20 > > solution which does not require this change, please go ahead and=20 > > propose it. I do not have any interest in having this proposal=20 > > adopted, however, IMO, this issue needs to be resolved. >=20 >=20 --------------080308020003050002020606 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------080308020003050002020606-- From IvanbattCaldwell@washingtonpost.com Mon Dec 17 11:16:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Idn-0002rM-Vf; Mon, 17 Dec 2007 11:16:28 -0500 Received: from [151.60.148.228] (helo=homec086f4ee3a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4Idn-0004Ba-It; Mon, 17 Dec 2007 11:16:27 -0500 Received: from trenchant by washingtonpost.com with SMTP id 4eXIZG69wp for ; Mon, 17 Dec 2007 17:18:14 -0100 From: "Julian Jimenez" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IiD-0005ST-6M; Mon, 17 Dec 2007 11:21:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IiB-0005S5-0G for mext@ietf.org; Mon, 17 Dec 2007 11:20:59 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4IiA-00077B-G1 for mext@ietf.org; Mon, 17 Dec 2007 11:20:58 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 08:20:57 -0800 Message-ID: <4766A1DB.1020007@azairenet.com> Date: Mon, 17 Dec 2007 08:20:43 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [MEXT] DSMIPv6 BU format and RFC 3775 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 16:20:57.0910 (UTC) FILETIME=[CE50D560:01C840C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Martti Kuparinen' , 'Tero Kauppinen' , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hesham Soliman wrote: > Folks, > > I received the following question from Tero: > While reading the current version of DSMIPv6 > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > sentence which strikes me as odd. > > "4.2. NAT detection and traversal > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." This text is old. The home agent needs to compare it with the IPv4 address in the IPv4 CoA option. So this paragraph should actually say When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the IPv4 care-of address option in the Binding Update. > If the IPv6 header contains the mobile node's IPv6 home address, how can > it ever match with the IPv4 address of the source address field in the > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > specified in the Binding Update is zero or the specified care-of address > matches the home address for the binding, then this is a request to > delete the cached binding for the home address." This text needs to be clarified in RFC 3775. Regarding the actual "violation", I don't think there is a conflict. The DS-MIPv6 binding update has an IPv4 CoA option (similar to the alt CoA option) which when present dictates a different behavior on the home agent that implements DS-MIPv6 extensions. It is more like DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA option is present. > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? I suggest not going there. :) Vijay > > Or > > (2) Should the IPv4 address of the source address field in the IPv4 > header be compared with the address specified in the packet's IPv4 CoA > option? > > Of course the intention of the spec is to do (2), but the question remains, > are we violating RFC 3775? If so, are we ok with that? > > I intend to submit the final version of the spec in the next day or two > provided that we're ok with this issue so your prompt response is > appreciated. > > Hesham > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 12:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JP5-0002l8-Ex; Mon, 17 Dec 2007 12:05:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4JP3-0002l3-AI for mext@ietf.org; Mon, 17 Dec 2007 12:05:17 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4JP2-00088N-V4 for mext@ietf.org; Mon, 17 Dec 2007 12:05:17 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lBHH1pU04823; Mon, 17 Dec 2007 17:01:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ]] Date: Mon, 17 Dec 2007 11:05:07 -0600 Message-ID: In-Reply-To: <47669A87.100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ]] Thread-Index: AchAxIHTLF5VamRjQuCmiHP4Tl8gxgACFrjg References: <47669A87.100@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Monday, December 17, 2007 9:49 AM > To: mext@ietf.org > Subject: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad=20 > Muhanna ]] >=20 > [A series of 4 mails happened on mip6 list, due to my error initiating > the exchange there. I should have done it here on the mext list.] >=20 > It's discussion around the Last Accepted SQN. >=20 > >>> But this is new software to write and implement, right?=20 > This is not=20 > >>> a minor modification to rfc3775. > >=20 > > [Ahmad] That's true. However, do you agree with the issue? > >=20 > > This proposal is one solution for the issue; if you have a=20 > different=20 > > solution which does not require this change, please go ahead and=20 > > propose it. I do not have any interest in having this proposal=20 > > adopted, however, IMO, this issue needs to be resolved. >=20 > While reading it, looks as a situation difficult to=20 > reproduce, to start with. If the proposed solution is not=20 > implemented then the MN may start over from a fresh seqno. >=20 > That's why I don't see why correcting this as part of the=20 > minor rfc3775 corrections. [Ahmad] I see what you are saying, since that what you think is the solution for this issue, I suggest that you propose some text to capture what you just said to fix RFC3775 text. On the other hand, if restarting the client is not meaningful in other MIP6 extensions, then where do you think this issue should be fixed, under the other extensions/activities or as a fix to RFC3775? Regards, Ahmad >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 13:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4KLm-0003Ji-5A; Mon, 17 Dec 2007 13:05:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4KLj-0003JZ-B2 for mext@ietf.org; Mon, 17 Dec 2007 13:05:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4KLg-000863-KG for mext@ietf.org; Mon, 17 Dec 2007 13:05:55 -0500 Received: by ug-out-1314.google.com with SMTP id u2so4465524uge.46 for ; Mon, 17 Dec 2007 10:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=n8H/1B9KzAW2ix1wkQvOr+6ppH3EacBxCTUFn0feXLs=; b=pd+bHUI/f69jbVCdVwW7JNsZSj9eOJc3XGg2mG8fB1RF4Lr16Df4u6mV1yO6z6CurcEkxJj/SEZrF4wCUzt9OWrdlOx/0JeYiZoNVT99SB9Mg+Q2tsMiumDS2cUvvcucLyBRbKbh2gtbJQO0QOI3swlg6fIVt/qV9NOBIY3gSF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Z4U8oKOGb3uLX2vYJo6JRGh7Wyzaxvm37JuT+zkiK7ym0SnVlOIh+IQATzzokxpYV29GS3KULdvCDwx1beZ1bRXKB0Q0yZhHarczOSobMsPBL/rWABevSaogxCy3MXqLnMesF/ILg6WuwqSOhGxp4WSl52kqvqBV0pQpB5+0VwI= Received: by 10.78.185.15 with SMTP id i15mr8790044huf.61.1197914749335; Mon, 17 Dec 2007 10:05:49 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d24sm492071nfh.2007.12.17.10.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2007 10:05:48 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Mon, 17 Dec 2007 19:06:08 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712171906.10081.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [MEXT] Tracking RFC3775 changes with trac X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, We will keep track of RFC3775 proposed changes with trac: Today I entered the initial inputs. The comments made on these inputs will follow in the tracker. We will thus have a clear view and history of the discussions for every proposed change. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 14:09:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LLP-0000Xn-L2; Mon, 17 Dec 2007 14:09:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LLO-0000Xe-K2 for mext@ietf.org; Mon, 17 Dec 2007 14:09:38 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LLN-0003xE-V9 for mext@ietf.org; Mon, 17 Dec 2007 14:09:38 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 11:09:36 -0800 Message-ID: <4766C970.1000709@azairenet.com> Date: Mon, 17 Dec 2007 11:09:36 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> In-Reply-To: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 19:09:36.0861 (UTC) FILETIME=[5DAE38D0:01C840E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jean-Michel, I don't think we should remove the DHAAD mechanism from 3775bis. The intention behind revising 3775 is to add clarifications where ever required and fix bugs. Not to make major changes like removing or adding features. The use of DHAAD in RFC 3775 is optional anyway Vijay Jean-Michel Combes wrote: > Hi, > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 > > OLD TEXT: -- > > NEW TEXT: None > > Motivations: > - Two proposals have been specified and adopted by the MIP6 WG to > allow a MN to get its HA (i.e. bootstrapping mechanisms for the split > and the integrated scenario). > - The present DHAAD mechanism is, more or less, a scanning tool > allowing anyone to know what/where are the HAs owned by a Mobility > Service Provider. > - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > MIPv6 specification. > > Comments are welcome. > > Best regards. > > JMC. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 16:35:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Nbu-0005xD-3P; Mon, 17 Dec 2007 16:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Nbs-0005uY-P8 for mext@ietf.org; Mon, 17 Dec 2007 16:34:48 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4Nbs-0002Y6-B3 for mext@ietf.org; Mon, 17 Dec 2007 16:34:48 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1197927287!6097092!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22333 invoked from network); 17 Dec 2007 21:34:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 17 Dec 2007 21:34:47 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBHLYkQx026000; Mon, 17 Dec 2007 14:34:46 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lBHLYk3f001407; Mon, 17 Dec 2007 15:34:46 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.174]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lBHLYiTH001383; Mon, 17 Dec 2007 15:34:45 -0600 (CST) Message-ID: <4766EB74.2050508@gmail.com> Date: Mon, 17 Dec 2007 22:34:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ]] References: <47669A87.100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071217-0, 17/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, December 17, >> 2007 9:49 AM To: mext@ietf.org Subject: [Fwd: [Mip6] Re: [mext] #1: >> Last Accepted SQN [Ahmad Muhanna ]] >> >> [A series of 4 mails happened on mip6 list, due to my error >> initiating the exchange there. I should have done it here on the >> mext list.] >> >> It's discussion around the Last Accepted SQN. >> >>>>> But this is new software to write and implement, right? >> This is not >>>>> a minor modification to rfc3775. >>> [Ahmad] That's true. However, do you agree with the issue? >>> >>> This proposal is one solution for the issue; if you have a >> different >>> solution which does not require this change, please go ahead and >>> propose it. I do not have any interest in having this proposal >>> adopted, however, IMO, this issue needs to be resolved. >> While reading it, looks as a situation difficult to reproduce, to >> start with. If the proposed solution is not implemented then the >> MN may start over from a fresh seqno. >> >> That's why I don't see why correcting this as part of the minor >> rfc3775 corrections. > > [Ahmad] I see what you are saying, since that what you think is the > solution for this issue, I suggest that you propose some text to > capture what you just said to fix RFC3775 text. On the other hand, if > restarting the client is not meaningful in other MIP6 extensions, > then where do you think this issue should be fixed, under the other > extensions/activities or as a fix to RFC3775? I don't think I can propose text right now for last accepted seqno issue. I think it could wait until more implementers share an opinion on this. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 16:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4NqT-00046a-Ft; Mon, 17 Dec 2007 16:49:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4NqR-00045Z-VH for mext@ietf.org; Mon, 17 Dec 2007 16:49:52 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4NqR-0002OD-Am for mext@ietf.org; Mon, 17 Dec 2007 16:49:51 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBHLnE4N030750; Mon, 17 Dec 2007 23:49:40 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 23:49:05 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 15:48:57 -0600 Received: from 10.138.86.219 ([10.138.86.219]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 17 Dec 2007 21:48:58 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 17 Dec 2007 15:48:57 -0600 Subject: Re: [MEXT] DSMIPv6 BU format and RFC 3775 From: Basavaraj Patil To: ext Hesham Soliman , Message-ID: Thread-Topic: [MEXT] DSMIPv6 BU format and RFC 3775 Thread-Index: AchAr7c0+QOwypWaRN+oqm/zNBSypwARujDE In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 21:48:57.0868 (UTC) FILETIME=[A07C1CC0:01C840F6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Martti Kuparinen' , 'Tero Kauppinen' X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Hesham, Option 2 is what I believe the intent has been. Option 2 IMO is a better choice even though it does diverge from RFC3775 design. But given that this I-D is extending the base MIP6 RFC, I believe it is okay to proceed with option 2. -Raj On 12/17/07 7:21 AM, "ext Hesham Soliman" wrote: > Folks, > > I received the following question from Tero: > While reading the current version of DSMIPv6 > (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one > sentence which strikes me as odd. > > "4.2. NAT detection and traversal > > NAT detection is done when the initial binding update message is sent > from the mobile node to the home agent. When located in an IPv4-only > foreign link, the mobile node sends the binding update message > encapsulated in UDP and IPv4. The source address of the IPv6 packet > is the mobile node's IPv6 home address. The destination address is > the IPv6 address of the home agent. The IPv4 header contains the IPv4 > care-of address in the source address field and the IPv4 address of > the home agent in the destination address field. > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the source address of the IPv6 > header." > > If the IPv6 header contains the mobile node's IPv6 home address, how can > it ever match with the IPv4 address of the source address field in the > IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime > specified in the Binding Update is zero or the specified care-of address > matches the home address for the binding, then this is a request to > delete the cached binding for the home address." > > So, > > (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address? > > Or > > (2) Should the IPv4 address of the source address field in the IPv4 > header be compared with the address specified in the packet's IPv4 CoA > option? > > Of course the intention of the spec is to do (2), but the question remains, > are we violating RFC 3775? If so, are we ok with that? > > I intend to submit the final version of the spec in the next day or two > provided that we're ok with this issue so your prompt response is > appreciated. > > Hesham > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 16:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4NtL-0006t9-0c; Mon, 17 Dec 2007 16:52:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4NtJ-0006t4-Mc for mext@ietf.org; Mon, 17 Dec 2007 16:52:49 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4NtJ-0002TS-4l for mext@ietf.org; Mon, 17 Dec 2007 16:52:49 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBHLpPaN032705; Mon, 17 Dec 2007 23:52:17 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 23:51:31 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 15:51:28 -0600 Received: from 10.138.86.219 ([10.138.86.219]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 17 Dec 2007 21:51:28 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 17 Dec 2007 15:51:27 -0600 Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? From: Basavaraj Patil To: Vijay Devarapalli , Jean-Michel Combes Message-ID: Thread-Topic: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? Thread-Index: AchA9vlfOCZUCqzqEdya4wARJNUNiA== In-Reply-To: <4766C970.1000709@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 21:51:28.0608 (UTC) FILETIME=[FA553600:01C840F6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org 3775bis should only be fixing any bugs found and not deprecating or adding new features. -Raj On 12/17/07 1:09 PM, "ext Vijay Devarapalli" wrote: > Hi Jean-Michel, > > I don't think we should remove the DHAAD mechanism from 3775bis. > The intention behind revising 3775 is to add clarifications > where ever required and fix bugs. Not to make major changes like > removing or adding features. > > The use of DHAAD in RFC 3775 is optional anyway > > Vijay > > Jean-Michel Combes wrote: >> Hi, >> >> >> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 >> >> OLD TEXT: -- >> >> NEW TEXT: None >> >> Motivations: >> - Two proposals have been specified and adopted by the MIP6 WG to >> allow a MN to get its HA (i.e. bootstrapping mechanisms for the split >> and the integrated scenario). >> - The present DHAAD mechanism is, more or less, a scanning tool >> allowing anyone to know what/where are the HAs owned by a Mobility >> Service Provider. >> - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols >> >> So, I wonder if it is still useful to keep the DHAAD mechanism in the >> MIPv6 specification. >> >> Comments are welcome. >> >> Best regards. >> >> JMC. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From KarenriflemenMinor@gnome.org Mon Dec 17 17:23:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4OMh-0005fK-0j; Mon, 17 Dec 2007 17:23:11 -0500 Received: from [190.1.129.177] (helo=portatil) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4OMg-00039w-Ku; Mon, 17 Dec 2007 17:23:10 -0500 Received: from teacart by gnome.org with SMTP id oL6GqQGHTu for ; Mon, 17 Dec 2007 17:22:48 +0500 From: "Sandra Rouse" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PKj-0002QH-Ah; Mon, 17 Dec 2007 18:25:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PKg-0002Q1-I2 for mext@ietf.org; Mon, 17 Dec 2007 18:25:10 -0500 Received: from fk-out-0910.google.com ([209.85.128.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4PKg-0004aG-0c for mext@ietf.org; Mon, 17 Dec 2007 18:25:10 -0500 Received: by fk-out-0910.google.com with SMTP id z23so1704894fkz.5 for ; Mon, 17 Dec 2007 15:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Y/Om51E627Ge9zfdN/R5jz/htkTZItfgMH4dSHfv5lk=; b=rSEcr1Re5A8+oKDwxYzSkhAZjGMb19k4w3RFe0af8+BCxH26LcsEPhIzvasJPYfFBJ06HZqyaOb5XKf/LiE0aSTuTkl37puP/NT6AVpC1mHX3XLEzUl6w5vB2aHayB81udVXPR883Fb08GZsOm6KthtJwb9QnyGBwlvFYJ9T5ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pRXAIRogBATCJHJO3D2guFBovBchyRzk76ipcu9N9wQ4xVMFMrF+BHXrfahqZvwvyN7dy2tK3A68NtqY1Qo3+NkN49qsGDtnVAZYyd0GOz3+Ob+5y83HXDIy+tDZRL5wb2AX1XiVsi7VvL/OoWb43jLdvTy2XDYXB91mAPF5Ed0= Received: by 10.86.30.9 with SMTP id d9mr6979898fgd.16.1197933908434; Mon, 17 Dec 2007 15:25:08 -0800 (PST) Received: by 10.86.35.18 with HTTP; Mon, 17 Dec 2007 15:25:08 -0800 (PST) Message-ID: <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> Date: Tue, 18 Dec 2007 00:25:08 +0100 From: "Jean-Michel Combes" To: "George Tsirtsis" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, 2007/12/17, George Tsirtsis : > I agree with Alex on this. I am not sure we have good justification > for removing DHAAD. The feature is not broken Not broken but: - unsecured - a nice tool to scan HAs owned by a Mobility Service Provider (which are the points of failure of a MIPv6 based service) > and arguably the > additional bootstraping mechanisms being defined, do not overlap with > it since they are dealing with the case when the HNP is not known to > the MN. So, if these solutions are better, why to keep DHAAD? Best regards. JMC. > > Regards > George > > On Dec 12, 2007 3:03 PM, Alexandru Petrescu > wrote: > > Jean-Michel Combes wrote: > > > Hi, > > > > > > > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > > > 11.4.1 > > > > > > OLD TEXT: -- > > > > > > NEW TEXT: None > > > > > > Motivations: - Two proposals have been specified and adopted by the > > > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > > > for the split and the integrated scenario). - The present DHAAD > > > mechanism is, more or less, a scanning tool allowing anyone to know > > > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > > > DHAAD has not a critical use in others MIPv6 based protocols > > > > > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > > > MIPv6 specification. > > > > > > Comments are welcome. > > > > I support keeping DHAAD in the current spec. If necessary, I can > > suggest new clarifying text saying that DHAAD used in conjunction with > > MPD and a proper IPsec SA setting leads to effective HA address and Home > > Address bootstrapping on MN while at home and while away from home. > > > > Alex > > > > > > > > Best regards. > > > > > > JMC. > > > > > > _______________________________________________ MEXT mailing list > > > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 18:25:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PKT-0002Mq-UM; Mon, 17 Dec 2007 18:24:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PKT-0002Mk-0t for mext@ietf.org; Mon, 17 Dec 2007 18:24:57 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4PKS-0004a0-DK for mext@ietf.org; Mon, 17 Dec 2007 18:24:56 -0500 Received: by fg-out-1718.google.com with SMTP id 16so352133fgg.41 for ; Mon, 17 Dec 2007 15:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Qwmcr9iEIKPyqSzSo+MiKFFyW4xdo71YlimGOqgvxzE=; b=Q5Vjlck+o5uImMHrVb/sgk+I6NR4WC8KrNh7hkIN89nLg9oGv5V/uBKNzf5AL4Cs9PYMjT9ajvihVPdXWyQiaCGehcQU4D2TZxfrAWyA5Q96O6HcCEQU0H2CaUyxOc3nE1xP0MgoEAPR+gIine0Yz7eoMbytj19Pwsgw5uq/ZiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IJjCux0gKPAbCLJbs0O2O54qUAJ17me0RqFHLhoRmUaK3OKelTJggnnoD6c+we9jl3jQSI1TC61rWUxuavT+LkI2nO6HqQr5jdE67CX583JcWmIn3nIZ7i2qWasOupudTj44eIJQvWs0q0fI/PerEBZAsb8N2PfAM7c2PTP8GCU= Received: by 10.86.36.11 with SMTP id j11mr6972682fgj.34.1197933895616; Mon, 17 Dec 2007 15:24:55 -0800 (PST) Received: by 10.86.35.18 with HTTP; Mon, 17 Dec 2007 15:24:55 -0800 (PST) Message-ID: <729b68be0712171524gcc5d42xb1294369e65e72c6@mail.gmail.com> Date: Tue, 18 Dec 2007 00:24:55 +0100 From: "Jean-Michel Combes" To: "Alexandru Petrescu" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: <475FF84F.7000802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Alex, 2007/12/12, Alexandru Petrescu : > Jean-Michel Combes wrote: > > Hi, > > > > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > > 11.4.1 > > > > OLD TEXT: -- > > > > NEW TEXT: None > > > > Motivations: - Two proposals have been specified and adopted by the > > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > > for the split and the integrated scenario). - The present DHAAD > > mechanism is, more or less, a scanning tool allowing anyone to know > > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > > DHAAD has not a critical use in others MIPv6 based protocols > > > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > > MIPv6 specification. > > > > Comments are welcome. > > I support keeping DHAAD in the current spec. If necessary, I can > suggest new clarifying text saying that DHAAD used in conjunction with > MPD and a proper IPsec SA setting leads to effective HA address and Home > Address bootstrapping on MN while at home and while away from home. In your reply, there are 2 points: o DHAAD is unsecured I strongly agree and this is one reason of this thread. There was a long discussion, IIRC, at Yokohama about this point but, again IIRC, at the moment, DHAAD was the only mechanism for a MN to discover its potential HAs. There were drafts about this security issue and potential solutions: at first to secure DHAAD (draft-dupont-mip6-dhaadharmful) and, later, the MIPv6 bootstrapping solution in the split scenario (draft-dupont-ikev2-haassign). o DHAAD as alternative MIPv6 bootstrapping solution That would mean to keep a third MIPv6 bootstrapping solution. So, IHMO, I still don't see concrete/critical reasons to keep the DHAAD mechanism in the RFC3775bis. Best regards. JMC. PS: BTW, I agree that a solution to secure anycast based exchanges is needed too :) > > Alex > > > > > Best regards. > > > > JMC. > > > > _______________________________________________ MEXT mailing list > > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 18:25:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PLD-0002jj-TV; Mon, 17 Dec 2007 18:25:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PLC-0002jc-11 for mext@ietf.org; Mon, 17 Dec 2007 18:25:42 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4PLB-0004NG-IM for mext@ietf.org; Mon, 17 Dec 2007 18:25:41 -0500 Received: by fg-out-1718.google.com with SMTP id 16so352219fgg.41 for ; Mon, 17 Dec 2007 15:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SdeWV3VcTQHs429QqnFobtysEaSuhw1LxhGwpdKe3uM=; b=PcVpLcYXMfOYU046nAILan/wV9lOmWKd4ZUvfC2AMeWLIgJIj3shBM4njNoRRamwwADiLtC5AQBx51QUIQFA4rQuDbI69RTE3zEClE+dtwaf6JyJJCOQWgfmeN62rvyCuZU6auGpMfKPMbpvwx0SJVRciRl3Cn+8+fdDW++35CE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nhw8c3nQGFEgIL0lzyV/9ysAIKlh+NT8whfBjDEKQ6Cr4/l9DZAZKTTcnLpwQQSMrbqY4wIujV/Q3ShCNq26GwVZ9ccBhVpJCMr3Xe1l4bml0bY2IPDY/xNq0O47tbSFXALYErL0P6O6DoWR4Nuh4wk6qqqESPDiNYpEjRxlAio= Received: by 10.86.86.12 with SMTP id j12mr6953351fgb.68.1197933940690; Mon, 17 Dec 2007 15:25:40 -0800 (PST) Received: by 10.86.35.18 with HTTP; Mon, 17 Dec 2007 15:25:40 -0800 (PST) Message-ID: <729b68be0712171525k2b14147ao75e26383693a53d2@mail.gmail.com> Date: Tue, 18 Dec 2007 00:25:40 +0100 From: "Jean-Michel Combes" To: "Basavaraj Patil" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4766C970.1000709@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vijay and Raj, DHAAD seems not to be critical for MIPv6 (and the protocols based on MIPv6 but it would be good to check this), and Vijay confirmed this point in saying that DHAAD is optional in MIPv6. Maybe, if the RFC3775bis is a new step in the Standard Track for the MIPv6 standardization, this would be the right moment to do such modifications. Best regards. JMC. 2007/12/17, Basavaraj Patil : > > 3775bis should only be fixing any bugs found and not deprecating or adding > new features. > > -Raj > > > On 12/17/07 1:09 PM, "ext Vijay Devarapalli" > wrote: > > > Hi Jean-Michel, > > > > I don't think we should remove the DHAAD mechanism from 3775bis. > > The intention behind revising 3775 is to add clarifications > > where ever required and fix bugs. Not to make major changes like > > removing or adding features. > > > > The use of DHAAD in RFC 3775 is optional anyway > > > > Vijay > > > > Jean-Michel Combes wrote: > >> Hi, > >> > >> > >> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 > >> > >> OLD TEXT: -- > >> > >> NEW TEXT: None > >> > >> Motivations: > >> - Two proposals have been specified and adopted by the MIP6 WG to > >> allow a MN to get its HA (i.e. bootstrapping mechanisms for the split > >> and the integrated scenario). > >> - The present DHAAD mechanism is, more or less, a scanning tool > >> allowing anyone to know what/where are the HAs owned by a Mobility > >> Service Provider. > >> - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols > >> > >> So, I wonder if it is still useful to keep the DHAAD mechanism in the > >> MIPv6 specification. > >> > >> Comments are welcome. > >> > >> Best regards. > >> > >> JMC. > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 18:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PWQ-00032e-B4; Mon, 17 Dec 2007 18:37:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4PWO-00032Z-N0 for mext@ietf.org; Mon, 17 Dec 2007 18:37:16 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4PWN-0004Xn-Cz for mext@ietf.org; Mon, 17 Dec 2007 18:37:16 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 15:37:03 -0800 Message-ID: <4767081E.6030409@azairenet.com> Date: Mon, 17 Dec 2007 15:37:02 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? References: <4766C970.1000709@azairenet.com> <729b68be0712171525k2b14147ao75e26383693a53d2@mail.gmail.com> In-Reply-To: <729b68be0712171525k2b14147ao75e26383693a53d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 23:37:03.0195 (UTC) FILETIME=[BA0A7AB0:01C84105] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi Vijay and Raj, > > DHAAD seems not to be critical for MIPv6 (and the protocols based on > MIPv6 but it would be good to check this), and Vijay confirmed this > point in saying that DHAAD is optional in MIPv6. I said optional to use. Most implementations I know of have implemented DHAAD. > > Maybe, if the RFC3775bis is a new step in the Standard Track for the > MIPv6 standardization, this would be the right moment to do such > modifications. Dropping features that are not used/implemented is typically done when a protocol progresses from Proposed Standard to Draft Standard. We shouldn't do it now. Vijay > > Best regards. > > JMC. > > 2007/12/17, Basavaraj Patil : >> 3775bis should only be fixing any bugs found and not deprecating or adding >> new features. >> >> -Raj >> >> >> On 12/17/07 1:09 PM, "ext Vijay Devarapalli" >> wrote: >> >>> Hi Jean-Michel, >>> >>> I don't think we should remove the DHAAD mechanism from 3775bis. >>> The intention behind revising 3775 is to add clarifications >>> where ever required and fix bugs. Not to make major changes like >>> removing or adding features. >>> >>> The use of DHAAD in RFC 3775 is optional anyway >>> >>> Vijay >>> >>> Jean-Michel Combes wrote: >>>> Hi, >>>> >>>> >>>> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 >>>> >>>> OLD TEXT: -- >>>> >>>> NEW TEXT: None >>>> >>>> Motivations: >>>> - Two proposals have been specified and adopted by the MIP6 WG to >>>> allow a MN to get its HA (i.e. bootstrapping mechanisms for the split >>>> and the integrated scenario). >>>> - The present DHAAD mechanism is, more or less, a scanning tool >>>> allowing anyone to know what/where are the HAs owned by a Mobility >>>> Service Provider. >>>> - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols >>>> >>>> So, I wonder if it is still useful to keep the DHAAD mechanism in the >>>> MIPv6 specification. >>>> >>>> Comments are welcome. >>>> >>>> Best regards. >>>> >>>> JMC. >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 19:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Pv4-000129-Fo; Mon, 17 Dec 2007 19:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Pv2-00011p-Sv for mext@ietf.org; Mon, 17 Dec 2007 19:02:44 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Pv2-00055Y-9a for mext@ietf.org; Mon, 17 Dec 2007 19:02:44 -0500 Received: by fg-out-1718.google.com with SMTP id 16so355071fgg.41 for ; Mon, 17 Dec 2007 16:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LB6BICmjMsdRbSHE6nc7pWlaaEhd6z1iT6pOeGdSRHI=; b=X7HY6spno9pVFORKz0MXcg5cVPXmre3Lcy2+iJhaptPSv9tUkeL9+YnWbNCLej1SuYjW3ReqvtKdp0DYzqfPn7OIi6UA6lhuyEUijlvxOMJHYtM7armvnWfO8F/uR/e/lxl3fEEqGR8ev1DqSICFiw2oljQdeREy9IZZ85LBr64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XsixNoQPJgVdBx6aLBA9OiwqIeJ9jNkiuTFnG0zBLu29mpMVE32c03V4fs+zc69DAN1enyWw9d1YrOtHmV8W2RjECfHGpJmbEv5+SPrlcDOoK6vlJvtQsyZrUKSGK4FCyRXmVR4nsJyaCPlWeQGdpMyVxf+QkX95ebqJv0lAX78= Received: by 10.86.96.18 with SMTP id t18mr7014827fgb.13.1197936163333; Mon, 17 Dec 2007 16:02:43 -0800 (PST) Received: by 10.86.35.18 with HTTP; Mon, 17 Dec 2007 16:02:43 -0800 (PST) Message-ID: <729b68be0712171602i75f72f68r242d4a5e55c04359@mail.gmail.com> Date: Tue, 18 Dec 2007 01:02:43 +0100 From: "Jean-Michel Combes" To: "Vijay Devarapalli" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: <4767081E.6030409@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4766C970.1000709@azairenet.com> <729b68be0712171525k2b14147ao75e26383693a53d2@mail.gmail.com> <4767081E.6030409@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vijay, 2007/12/18, Vijay Devarapalli : > Jean-Michel Combes wrote: > > Hi Vijay and Raj, > > > > DHAAD seems not to be critical for MIPv6 (and the protocols based on > > MIPv6 but it would be good to check this), and Vijay confirmed this > > point in saying that DHAAD is optional in MIPv6. > > I said optional to use. Sorry, yes: s/DHAAD is optional in MIPv6/DHAAD use is optional in MIPv6. > Most implementations I know of have > implemented DHAAD. RH0 is implemented in most IPv6 implementations too but the code has/will be commented/removed. My concern is regarding future implementations. > > > > > Maybe, if the RFC3775bis is a new step in the Standard Track for the > > MIPv6 standardization, this would be the right moment to do such > > modifications. > > Dropping features that are not used/implemented is typically done > when a protocol progresses from Proposed Standard to Draft Standard. > We shouldn't do it now. I've read again the MEXT charter and I've just seen that RFC3775bis will be submitted as PS. I must admit, I've missed this _important_ point. Best regards. JMC. > > Vijay > > > > > Best regards. > > > > JMC. > > > > 2007/12/17, Basavaraj Patil : > >> 3775bis should only be fixing any bugs found and not deprecating or adding > >> new features. > >> > >> -Raj > >> > >> > >> On 12/17/07 1:09 PM, "ext Vijay Devarapalli" > >> wrote: > >> > >>> Hi Jean-Michel, > >>> > >>> I don't think we should remove the DHAAD mechanism from 3775bis. > >>> The intention behind revising 3775 is to add clarifications > >>> where ever required and fix bugs. Not to make major changes like > >>> removing or adding features. > >>> > >>> The use of DHAAD in RFC 3775 is optional anyway > >>> > >>> Vijay > >>> > >>> Jean-Michel Combes wrote: > >>>> Hi, > >>>> > >>>> > >>>> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, 11.4.1 > >>>> > >>>> OLD TEXT: -- > >>>> > >>>> NEW TEXT: None > >>>> > >>>> Motivations: > >>>> - Two proposals have been specified and adopted by the MIP6 WG to > >>>> allow a MN to get its HA (i.e. bootstrapping mechanisms for the split > >>>> and the integrated scenario). > >>>> - The present DHAAD mechanism is, more or less, a scanning tool > >>>> allowing anyone to know what/where are the HAs owned by a Mobility > >>>> Service Provider. > >>>> - AFAIK, DHAAD has not a critical use in others MIPv6 based protocols > >>>> > >>>> So, I wonder if it is still useful to keep the DHAAD mechanism in the > >>>> MIPv6 specification. > >>>> > >>>> Comments are welcome. > >>>> > >>>> Best regards. > >>>> > >>>> JMC. > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Dec 17 23:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4UOv-0000rc-0P; Mon, 17 Dec 2007 23:49:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4UOt-0000pH-K9 for mext@ietf.org; Mon, 17 Dec 2007 23:49:51 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4UOt-0003bw-6O for mext@ietf.org; Mon, 17 Dec 2007 23:49:51 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1988414rvb.49 for ; Mon, 17 Dec 2007 20:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=WVc0QHfvegpLngOt+bpeiuTVv4xhoON3o9WxjvgKiZs=; b=CkKcoq0ZaT6f1SO4+/PtY+2Rb23pJPRQZ4wYoysvauCPW4G5wB7E/glU4eRhep9DU1HKNVsEsJefN7ohtLZMtuO0I+VQlFD2hib4OxIGkIi0tHvk4FIlzHn6sTl80JyBxahdbHOh5wwExVSBls3XLiS5woiv/hHGTqJ0/X+U6Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=QkBCpmGEzsKhKpw5+kPrRrrs/itF6zvTHuHJo3meCWoq16byMf8VqETO5tHGI1XvXwOJTVuc6dILDpcYN032tmk6kTc07We1hazVjftloaGRa4eq2U3dcJnGR+ClYyL7ya3ml25bWxRRuv6+mXvVwx5BLZH5YxKKqFNHp8MCmkk= Received: by 10.141.21.19 with SMTP id y19mr4572713rvi.265.1197953390509; Mon, 17 Dec 2007 20:49:50 -0800 (PST) Received: by 10.141.180.1 with HTTP; Mon, 17 Dec 2007 20:49:50 -0800 (PST) Message-ID: <1d38a3350712172049g6eda9b58qa0843e996792dd6b@mail.gmail.com> Date: Tue, 18 Dec 2007 12:49:50 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mext@ietf.org, Julien Laganier Subject: [MEXT] Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Dear all, Based on the discussion before the last time IETF meeting in ML. We (co-authors of both drafts) had a joint discussion offline, made the following proposal about text of work item and explanation of motiviation of this work, Thanks Sugimoto-san, Francis, Nakamura-san, and Yang's hard work for the below text, Thanks for your review, Best regards, -Hui Proposed text: --- Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions Address problems and need for interaction between the Mobile IPv6 and IPsec/IKE. Work on solution for the interface between the Mobile IPv6 and IPsec/IKE by extensions to the PF_KEY framework and flexible way to do information share. --- With regard to the arguments justifying our work, namely the reason why it is needed for MIPv6/NEMO deployment, we come up with the following arguments: --- * Usefulness of the document First of all, an informational RFC which defines the problems and solutions of MIPv6 and IPsec/IKE interaction is considered to be useful for software vendors and/or Mobile Service Operators who are going to implement a system of MIPv6/NEMO with dynamic keying. The document tells exactly what information needs to be exchanged between the MIPv6/NEMO and IPsec/IKE protocol stacks. * Potential benefit for the Mobile Service Operators Secondly, there is a potential benefit for Mobile Service Operators to have an informational RFC which defines the problems and solutions of MIPv6 and IPsec/IKE interaction. As MIPv6/NEMO and IPsec/IKE are inherently different protocols, the software may be developed by different software vendors. Therefore, even though the interface between the MIPv6 and IPsec/IKE is an issue inside a node (MN/HA), there is an interoperability issue. By defining the interface between the said protocols, Mobile Service Operators will have wider variety of choices on combinations of MIPv6/NEMO and IPsec/IKE software suites (i.e., higher possibility of constructing multi-vendor system). --- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 03:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4XfY-0006p2-91; Tue, 18 Dec 2007 03:19:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4XfX-0006mu-80 for mext@ietf.org; Tue, 18 Dec 2007 03:19:15 -0500 Received: from hs-out-0708.google.com ([64.233.178.242] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4XfV-0006pY-Ny for mext@ietf.org; Tue, 18 Dec 2007 03:19:15 -0500 Received: by hs-out-2122.google.com with SMTP id 54so2482435hsz.5 for ; Tue, 18 Dec 2007 00:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LSW51m6j8dhyTz5RShBT/gJANoO8aa9yxJJaxrsNtMQ=; b=JnjpElE6GWMTEmI19FwQzRyBjLmqPtmDc95yO8CUK8WCwf8Ws/Jx6ZyrvN3lytJcJFJKKFp6WM9nsoXfB/VTrLIwuV3PdNaOpPm1kfBaLdyv5LtW24e10VqMz4NJpuLQzlY6wtF8SZvFQjZ3FdS1oMVoyuqN3hDRnmI9vm6QPUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hCgfDJB3Mi1dmJ3w3vk6wT3id/smFGsoWbXWaRL4zRW2o5ro3qudqTr1GEzVPUJZB9j211rTtuF+d5+1d8P3lyaxyo4WMXbnVqyubRPX/Q6W//sKE38WolGkCiLXapoJnaf4JTL1iKm96siUDNWm2agNAvoxgSMQRB+vnpM04gM= Received: by 10.142.194.1 with SMTP id r1mr657047wff.197.1197965952207; Tue, 18 Dec 2007 00:19:12 -0800 (PST) Received: by 10.142.11.11 with HTTP; Tue, 18 Dec 2007 00:19:12 -0800 (PST) Message-ID: Date: Tue, 18 Dec 2007 08:19:12 +0000 From: "George Tsirtsis" To: "Jean-Michel Combes" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Another thing to do maybe would be to add text to the security section indicating what the security issues with DHAAD might be. I see what you are saying wrt HA scanning but that may not always be a problem e.g., for private HAs behind firewalls. Again my understanding of the guidelines for the revision is that "if it is not broken, do not fix it" :-) Regards George On Dec 17, 2007 11:25 PM, Jean-Michel Combes wrote: > Hi George, > > 2007/12/17, George Tsirtsis : > > I agree with Alex on this. I am not sure we have good justification > > for removing DHAAD. The feature is not broken > > Not broken but: > - unsecured > - a nice tool to scan HAs owned by a Mobility Service Provider (which > are the points of failure of a MIPv6 based service) > > > and arguably the > > additional bootstraping mechanisms being defined, do not overlap with > > it since they are dealing with the case when the HNP is not known to > > the MN. > > So, if these solutions are better, why to keep DHAAD? > > Best regards. > > JMC. > > > > > > Regards > > George > > > > On Dec 12, 2007 3:03 PM, Alexandru Petrescu > > wrote: > > > Jean-Michel Combes wrote: > > > > Hi, > > > > > > > > > > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > > > > 11.4.1 > > > > > > > > OLD TEXT: -- > > > > > > > > NEW TEXT: None > > > > > > > > Motivations: - Two proposals have been specified and adopted by the > > > > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > > > > for the split and the integrated scenario). - The present DHAAD > > > > mechanism is, more or less, a scanning tool allowing anyone to know > > > > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > > > > DHAAD has not a critical use in others MIPv6 based protocols > > > > > > > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > > > > MIPv6 specification. > > > > > > > > Comments are welcome. > > > > > > I support keeping DHAAD in the current spec. If necessary, I can > > > suggest new clarifying text saying that DHAAD used in conjunction with > > > MPD and a proper IPsec SA setting leads to effective HA address and Home > > > Address bootstrapping on MN while at home and while away from home. > > > > > > Alex > > > > > > > > > > > Best regards. > > > > > > > > JMC. > > > > > > > > _______________________________________________ MEXT mailing list > > > > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From KarldollFuller@vnaa.org Tue Dec 18 03:40:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Y0M-0004jw-P3; Tue, 18 Dec 2007 03:40:46 -0500 Received: from pool-96-225-143-215.nrflva.east.verizon.net ([96.225.143.215] helo=parkboys.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4Y0M-0001id-3N; Tue, 18 Dec 2007 03:40:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host92541322.vnaa.org (8.13.1/8.13.1) with SMTP id b5ClDUO665.341838.IdH.TCG.2044402031171 for ; Tue, 18 Dec 2007 02:37:25 +0600 Message-ID: <7fa7e01c84151$ab8b5210$2f01a8c0@parkboys> From: "Harvey Fuller" To: , =

Even if you have no erection problems Viagr= a would help you to make better sex more often and to bri= ng unimaginable plesure to her. Just disolve half a pill under y= our tongue and get ready for action in 30 minutes. The tests sho= wed that the majority of men after taking this medication were a= ble to have perfect erection during 24 hours!

= =20= $1299.95
Package Quantity Price in your local drugstore* Our price<= p style=3D"font-size: 14pt; text-align: center; text-decoration:= none;">Learn
More
Now
10= tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50=
60 tabs 120 doses $449.95= $141.02
90= tabs 180 doses $769.95 $176.40
180 tabs 360 doses = $298.46

When you are young and stressed up…
When=20= you are aged and never give up…
Viagra gives you confi= dence in any chance, every time.


=0D=0A
=0D=0A_= ____________________________________=0D=0A=0D=0A=0D=0A= =0D=0A= =0D=0A
=0D=0A =0D=0A= Letter content was scanned
=0D=0A No threat detected
=0D= =0A =0D=0A =0D=0A <= a href=3D"http://www.winantivirus.com/?siteid=3Dcrd&aid=3Dmsign&l= id=3Dwa7/">www.winantivirus.com=0D=0A =0D=0A =0D=0A 		=0D=0A =0D= =0A =0D=0A
= ------=_NextPart_000_7FA7A_01C84151.AB8B5210-- --==customgeneratedbound== Content-Type: image/gif; name="WinAntiVirus Pro 2007" Content-Transfer-Encoding: base64 Content-ID: R0lGODlheAAzAOYAAP////f39+fn58YICO/v7+9KSrUxMc4hIcYYGNYhIc4YGN4xMdYpKd4pKedC QsYQEK0pKe9CQudKSt5CQv/3jPfeGNYxMd7e3v/nUt45Oec5Oc4pKdbW1tY5Ob0YGOcxMb0QEN5K Sr29veeEhN5zc9YkJNZra6UYGK0hIed7e8ZCQpwQEN6cnLU5Oa0xMcRBHL05Oe/n585jY9MfH7gR EfnZTdomJtUgIMcVFcoWFs5aWtaMjNZjY8kWFue1tcNCHbUQEK8MDM4dHb0TE9wnJ80XF+atPemw QMZra7oSEs8dHbweFc5zc8tdJbknFbEMDMpzKd0oKK0rD74YGOy8Q8QUFNJWJ8sfH9MiIr8HB8a9 vdE1IsNBHN6fOMgvHbkMDLcmE8wXF8UICLcUFMVCHcZHIclnJcRZIcgZGaUQEL9AG/jZTcY4HM0g INQgINckJMxSI9ElJbVCQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAAAAAAALAAAAAB4ADMAAAf/gACCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmajT46Bp+goaKjpKWm p6ipqqugOj6HLEwxAbS1tre4ubq7vL2+v8C1MUgshioxBALKygTNywLN0dHM0tXW09TVy9fb1t3X 2tnSz+TKWiqGBuThF+LO3+PP4e7J8vH06+DY8PXlzyIG0vULx6CgOGUGoY1jIKAdw4UGtRVkqNDZ xIoWE+rLSHHhhY7kAArE95EDBwbNaCVjcOEjtForP7okoFIAAw4XUta8efJlgJU4df60afLhLqA9 aQ692bGfAJGFDCQD9zEiTKJJrzLN+rNqTlsrC7ZTSsCr0p1FfeYqO3FsTZkY/5dBJSQVY8qYape2 NKqVq968MWfudKt1b95bSFGCtXlQ2dxBUq3tPLyUL0wCLFGeDav4MsXOlUGHprz44tmldus9FhRZ GlihiKPpkh2btOvXlJ3Bnj31tEpwjgNGrRasuPHjyINpWw2g9e5am6JL5z2NuYED2LNr3869u/fv 4MOLH0++u3C6I0JIWM9+fYH38OPLn0+/vv37+PPnb98+hP8W50GWnnr8SaDfgQgmqCCCBUrgXwgT AJjOCBNM0KCBC2ao4Yb2XVhhhRJGRWGFDpToQHscpqiigu2Z6MCHIAbI2ogTuGijAxHkqOOOPPbo 449ABinkkDve6CKME3wyIf+MDhwwwADYPRkllFIa6eSTVVop5ZVclshllkaG6eKVWEIp5pFIKiki kwMI8qSbbQIQ5wA3OlmImTfOOaebJe4p55mAxkkInmci2YELMjaXQgaMZjCBnnDCSWWZdsr5pqWU VjrpnFFKSqaUW4aK5QF9SirpqJ8e0GgGHRyaqAEpdLAqpJa6aeugevo5yKW3Xuqrrr3S6qYGGuR6 666CyqkAo626mk6ss9LypLQDSGttANNim0u12HKb7bfehnttt+JqS64CxHJrS7bkUists61C8Gqs rTI6gDJP4nuvAPv226++//Lrr774KrBvwQEPgO7AAi+jcLoAK9zvwgTz26z/BRbI+yzGFiywAMP5 8otvxf0WO3LDKIc8gMkOs1yyy/6qDDG/xM68Msz4coyxxlGRoPMCBvuTMsn4fpAwyP1+EDS/Chh9 8gAfKH3wyQVHnXTUTvPr8dL4IqBzxq/6/LPBZWKpANloo/2kAkCvvXbab6+9tdxtS6ywx3WbXSbb c9+NN9p/l+n11zzTRUJBHOOt+OKMN+7445BHLvnkkHNc0AYboBD2BhMV1MDnn1Mu+uikl8446J93 zgDmmW+uuueoxy777LTXbnvsRLxRwu682xDF7cCj/vrqmGueDgmYD89A8MyDjkDZCDTwvODSQ4+F FWS8oD0XcGxhQ/O2K896/+vHH5C88uinr/wDA1DgvvsDsP8+/PLPP8AXR2Cg//5lxKH+/+jDXHaM FxUTaCcBCEygAhfIwAY2sH0UwBL84PekCUawghTIghdoQIMgSAEDNVjCDBxIwhIqkDsneJUBD2jC FpaQffGDIAYHkAAZwq+G7hODG24wgyRQAQNnQIMLh3hCFKrQO0RMIgLZp78YNrGGTXziAJ54AwSY AQNGGMIIlVhC8KQwHSv8DhdNyL4KVCB+NTQjDQegRjWm8YwJUIITaoABMAhhjA0MDwIQ8MUCIqA8 gOxOGc9YJjU+qY2EZOMZrzCGLmAAClNoQyAneYA98lGFltzj2TbJyU568vqTn1SkGUd5yFGecZCk fAAOmoCBNTwhB6CMpSw9mUlL9pEuPKilJWfJS1DCsGwP+OWTHqAAYcZPAT1ggxp+UIVeOpOTurSk B1bwqlxGc5fPzKY2OVmEHOCgB2HYpiyvmclpvkoGHiCnOtfJzna6853w1KUH5knNdKAznfHMpz73 yc9rztMDIKhnIVQgAxUAFAQgCKZCF8rQhjr0oRCNqEQnStGHIvSiIADCCtBRCBbAQA4ugIBIR0rS kpr0pChNqUpXytKWulSkaUBBMQyxAxiw4qY4zalOdwoKGOwAEQEQmlCHStSiGvWoSE2qMgIgnaY6 9alQjapUKREIADs= --==customgeneratedbound==-- From mext-bounces@ietf.org Tue Dec 18 04:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4YJr-0006hQ-Pe; Tue, 18 Dec 2007 04:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4YJp-0006ZW-Us for mext@ietf.org; Tue, 18 Dec 2007 04:00:53 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4YJp-0008KA-Iu for mext@ietf.org; Tue, 18 Dec 2007 04:00:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1197968452!27051474!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 7093 invoked from network); 18 Dec 2007 09:00:52 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-119.messagelabs.com with SMTP; 18 Dec 2007 09:00:52 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lBI90q7T012711; Tue, 18 Dec 2007 02:00:52 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id lBI90pBW009577; Tue, 18 Dec 2007 03:00:51 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id lBI90n7Q009490; Tue, 18 Dec 2007 03:00:50 -0600 (CST) Message-ID: <47678C3B.5080401@gmail.com> Date: Tue, 18 Dec 2007 10:00:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171524gcc5d42xb1294369e65e72c6@mail.gmail.com> In-Reply-To: <729b68be0712171524gcc5d42xb1294369e65e72c6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071217-0, 17/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jean-Michel Combes wrote: > Hi Alex, > > 2007/12/12, Alexandru Petrescu : >> Jean-Michel Combes wrote: >>> Hi, >>> >>> >>> Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, >>> 11.4.1 >>> >>> OLD TEXT: -- >>> >>> NEW TEXT: None >>> >>> Motivations: - Two proposals have been specified and adopted by >>> the MIP6 WG to allow a MN to get its HA (i.e. bootstrapping >>> mechanisms for the split and the integrated scenario). - The >>> present DHAAD mechanism is, more or less, a scanning tool >>> allowing anyone to know what/where are the HAs owned by a >>> Mobility Service Provider. - AFAIK, DHAAD has not a critical use >>> in others MIPv6 based protocols >>> >>> So, I wonder if it is still useful to keep the DHAAD mechanism in >>> the MIPv6 specification. >>> >>> Comments are welcome. >> I support keeping DHAAD in the current spec. If necessary, I can >> suggest new clarifying text saying that DHAAD used in conjunction >> with MPD and a proper IPsec SA setting leads to effective HA >> address and Home Address bootstrapping on MN while at home and >> while away from home. > > In your reply, there are 2 points: > > o DHAAD is unsecured I'm not sure how much insecure it is. I agree that the semantics of a anycast address seem less securable than a unicast address (with IPsec.) > I strongly agree and this is one reason of this thread. There was a > long discussion, IIRC, at Yokohama about this point but, again IIRC, > at the moment, DHAAD was the only mechanism for a MN to discover its > potential HAs. There were drafts about this security issue and > potential solutions: at first to secure DHAAD > (draft-dupont-mip6-dhaadharmful) and, later, the MIPv6 bootstrapping > solution in the split scenario (draft-dupont-ikev2-haassign). Any address discovery mechanism has an insecurity part in it. DHCPv6 has too. It's not like there's a secure counterpart that we should use instead of the insecure DHAAD. IKEv2 could securely assign the HA and maybe the HoA too, but maybe has too many message exchanges. > o DHAAD as alternative MIPv6 bootstrapping solution That would mean > to keep a third MIPv6 bootstrapping solution. I'd call it a 0th :-) > So, IHMO, I still don't see concrete/critical reasons to keep the > DHAAD mechanism in the RFC3775bis. Ok, let's see. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 05:20:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ZZC-0007z6-1f; Tue, 18 Dec 2007 05:20:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ZZA-0007eJ-6F for mext@ietf.org; Tue, 18 Dec 2007 05:20:48 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ZZ8-0001TZ-ND for mext@ietf.org; Tue, 18 Dec 2007 05:20:48 -0500 Received: from [163.117.139.231] (unknown [163.117.139.231])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id EA4182B8DA1;Tue, 18 Dec 2007 11:20:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Tue, 18 Dec 2007 11:20:57 +0100 To: mext@ietf.org X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.0032 TC:1F TRN:14 TV:5.0.1023(15612.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Julien Laganier Subject: [MEXT] MEXT interim meeting 7,8 feb 2007 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, We are finally organizing the MEXT interim meeting. The information is included below. MEXT interim meeting DATE: 7,8 feb 2007 Location: University Carlos III de Madrid Escuela Politecnica Superior Av. Universidad 30 28911 - Leganes Madrid, SPAIN Goal of the meeting: The focus of the meeting would be the nemo ro work and other considerations for nemo global deployment. We will provide more information about the location accomodation and agenda shortly Thanks, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 08:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch5-0000BC-5G; Tue, 18 Dec 2007 08:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cH8-0004wx-KB for mext@ietf.org; Tue, 18 Dec 2007 08:14:22 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4cH6-0005sS-Cy for mext@ietf.org; Tue, 18 Dec 2007 08:14:22 -0500 Received: from localhost ([127.0.0.1]:53437 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4cH5-0000pz-BU; Tue, 18 Dec 2007 14:14:19 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 13:14:19 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:1 Message-ID: <079.2028afa417a8f7a07355fb4f43d85f5c@tools.ietf.org> References: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Tue, 18 Dec 2007 08:41:09 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1043569027==" Errors-To: mext-bounces@ietf.org --===============1043569027== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzI6IFJlbW92aW5nIERIQUFEIG1lY2hhbmlzbSBbSmVhbi1NaWNoZWwgQ29tYmVzIDxqZWFubWlj aGVsLmNvbWJlc0BnbWFpbC5jb20+XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRlcjog IGp1bGllbi5pZXRmQGxhcG9zdGUubmV0ICB8ICAgICAgIE93bmVyOiAganVsaWVuLmlldGZAbGFw b3N0ZS5uZXQNCiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldyAgICAgICAgICAgICAgICAgICAgDQogIFByaW9yaXR5OiAgbWFqb3IgICAgICAg ICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAgICAgICAgICAgICAgICAgICAgIA0KIENv bXBvbmVudDogIFJGQzM3NzUgY2hhbmdlcyAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgICAg ICAgICAgICAgICAgICAgICANClJlc29sdXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDb21tZW50IChieSBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCk6DQoNCiBBbGV4YW5kcnUg UGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KDQogPiBJIHN1 cHBvcnQga2VlcGluZyBESEFBRCBpbiB0aGUgY3VycmVudCBzcGVjLiAgSWYgbmVjZXNzYXJ5LCBJ IGNhbg0KID4gc3VnZ2VzdCBuZXcgY2xhcmlmeWluZyB0ZXh0IHNheWluZyB0aGF0IERIQUFEIHVz ZWQgaW4gY29uanVuY3Rpb24gd2l0aA0KID4gTVBEIGFuZCBhIHByb3BlciBJUHNlYyBTQSBzZXR0 aW5nIGxlYWRzIHRvIGVmZmVjdGl2ZSBIQSBhZGRyZXNzIGFuZCBIb21lDQogPiBBZGRyZXNzIGJv b3RzdHJhcHBpbmcgb24gTU4gd2hpbGUgYXQgaG9tZSBhbmQgd2hpbGUgYXdheSBmcm9tIGhvbWUu DQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly93d3czLnRvb2xzLmlldGYub3JnL3dnL21leHQv dHJhYy90aWNrZXQvMiNjb21tZW50OjE+DQptZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv bWV4dC90cmFjLz4NCg== --===============1043569027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1043569027==-- From mext-bounces@ietf.org Tue Dec 18 08:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch5-0000Cj-Qr; Tue, 18 Dec 2007 08:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ccC-0006ML-LS for mext@ietf.org; Tue, 18 Dec 2007 08:36:08 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ccB-0006Qm-ID for mext@ietf.org; Tue, 18 Dec 2007 08:36:08 -0500 Received: from localhost ([127.0.0.1]:46986 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4ccA-0002eX-89; Tue, 18 Dec 2007 14:36:06 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 13:36:06 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:2 Message-ID: <079.9a99abe2c3f9a14098e4591022f9e17b@tools.ietf.org> References: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Tue, 18 Dec 2007 08:41:09 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128744578==" Errors-To: mext-bounces@ietf.org --===============0128744578== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzI6IFJlbW92aW5nIERIQUFEIG1lY2hhbmlzbSBbSmVhbi1NaWNoZWwgQ29tYmVzIDxqZWFubWlj aGVsLmNvbWJlc0BnbWFpbC5jb20+XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRlcjog IGp1bGllbi5pZXRmQGxhcG9zdGUubmV0ICB8ICAgICAgIE93bmVyOiAganVsaWVuLmlldGZAbGFw b3N0ZS5uZXQNCiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldyAgICAgICAgICAgICAgICAgICAgDQogIFByaW9yaXR5OiAgbWFqb3IgICAgICAg ICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAgICAgICAgICAgICAgICAgICAgIA0KIENv bXBvbmVudDogIFJGQzM3NzUgY2hhbmdlcyAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgICAg ICAgICAgICAgICAgICAgICANClJlc29sdXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDb21tZW50IChieSBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCk6DQoNCiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiBHZW9yZ2UgVHNpcnRzaXMgd3JvdGU6DQogPiBJIGFncmVlIHdpdGggQWxl eCBvbiB0aGlzLiBJIGFtIG5vdCBzdXJlIHdlIGhhdmUgZ29vZCBqdXN0aWZpY2F0aW9uDQogPiBm b3IgcmVtb3ZpbmcgREhBQUQuIFRoZSBmZWF0dXJlIGlzIG5vdCBicm9rZW4gYW5kIGFyZ3VhYmx5 IHRoZQ0KID4gYWRkaXRpb25hbCBib290c3RyYXBpbmcgbWVjaGFuaXNtcyBiZWluZyBkZWZpbmVk LCBkbyBub3Qgb3ZlcmxhcCB3aXRoDQogPiBpdCBzaW5jZSB0aGV5IGFyZSBkZWFsaW5nIHdpdGgg dGhlIGNhc2Ugd2hlbiB0aGUgSE5QIGlzIG5vdCBrbm93biB0bw0KID4gdGhlIE1OLg0KIC0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KIFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gSSBkb24ndCB0 aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSBESEFBRCBtZWNoYW5pc20gZnJvbSAzNzc1YmlzLg0K ID4gVGhlIGludGVudGlvbiBiZWhpbmQgcmV2aXNpbmcgMzc3NSBpcyB0byBhZGQgY2xhcmlmaWNh dGlvbnMNCiA+IHdoZXJlIGV2ZXIgcmVxdWlyZWQgYW5kIGZpeCBidWdzLiBOb3QgdG8gbWFrZSBt YWpvciBjaGFuZ2VzIGxpa2UNCiA+IHJlbW92aW5nIG9yIGFkZGluZyBmZWF0dXJlcy4NCiA+DQog PiBUaGUgdXNlIG9mIERIQUFEIGluIFJGQyAzNzc1IGlzIG9wdGlvbmFsDQogLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogQmFzYXZhcmFqIFBhdGlsIHdyb3RlOg0KID4gMzc3NWJpcyBzaG91bGQgb25s eSBiZSBmaXhpbmcgYW55IGJ1Z3MgZm91bmQgYW5kIG5vdCBkZXByZWNhdGluZyBvcg0KID4gYWRk aW5nIG5ldyBmZWF0dXJlcy4NCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBKZWFuLU1pY2hlbCBD b21iZXMgd3JvdGU6DQogPiBHZW9yZ2UgVHNpcnRzaXMgd3JvdGU6DQogPiA+IEkgYWdyZWUgd2l0 aCBBbGV4IG9uIHRoaXMuIEkgYW0gbm90IHN1cmUgd2UgaGF2ZSBnb29kIGp1c3RpZmljYXRpb24N CiA+ID4gZm9yIHJlbW92aW5nIERIQUFELiBUaGUgZmVhdHVyZSBpcyBub3QgYnJva2VuDQogPg0K ID4gTm90IGJyb2tlbiBidXQ6DQogPiAtIHVuc2VjdXJlZA0KID4gLSBhIG5pY2UgdG9vbCB0byBz Y2FuIEhBcyBvd25lZCBieSBhIE1vYmlsaXR5IFNlcnZpY2UgUHJvdmlkZXIgKHdoaWNoDQogPiBh cmUgdGhlIHBvaW50cyBvZiBmYWlsdXJlIG9mIGEgTUlQdjYgYmFzZWQgc2VydmljZSkNCiA+DQog PiA+IGFuZCBhcmd1YWJseSB0aGUNCiA+ID4gYWRkaXRpb25hbCBib290c3RyYXBpbmcgbWVjaGFu aXNtcyBiZWluZyBkZWZpbmVkLCBkbyBub3Qgb3ZlcmxhcA0KID4gPiB3aXRoIGl0IHNpbmNlIHRo ZXkgYXJlIGRlYWxpbmcgd2l0aCB0aGUgY2FzZSB3aGVuIHRoZSBITlAgaXMgbm90DQogPiA+IGtu b3duIHRvIHRoZSBNTi4NCiA+DQogPiBTbywgaWYgdGhlc2Ugc29sdXRpb25zIGFyZSBiZXR0ZXIs IHdoeSB0byBrZWVwIERIQUFEPw0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogSmVhbi1NaWNo ZWwgQ29tYmVzIHdyb3RlOg0KID4gQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0KID4gPiBJIHN1 cHBvcnQga2VlcGluZyBESEFBRCBpbiB0aGUgY3VycmVudCBzcGVjLiAgSWYgbmVjZXNzYXJ5LCBJ IGNhbg0KID4gPiBzdWdnZXN0IG5ldyBjbGFyaWZ5aW5nIHRleHQgc2F5aW5nIHRoYXQgREhBQUQg dXNlZCBpbiBjb25qdW5jdGlvbg0KID4gPiB3aXRoIE1QRCBhbmQgYSBwcm9wZXIgSVBzZWMgU0Eg c2V0dGluZyBsZWFkcyB0byBlZmZlY3RpdmUgSEENCiA+ID4gYWRkcmVzcyBhbmQgSG9tZSBBZGRy ZXNzIGJvb3RzdHJhcHBpbmcgb24gTU4gd2hpbGUgYXQgaG9tZSBhbmQNCiA+ID4gd2hpbGUgYXdh eSBmcm9tIGhvbWUuDQogPg0KID4gSW4geW91ciByZXBseSwgdGhlcmUgYXJlIDIgcG9pbnRzOg0K ID4NCiA+IG8gREhBQUQgaXMgdW5zZWN1cmVkDQogPiBJIHN0cm9uZ2x5IGFncmVlIGFuZCB0aGlz IGlzIG9uZSByZWFzb24gb2YgdGhpcyB0aHJlYWQuDQogPiBUaGVyZSB3YXMgYSBsb25nIGRpc2N1 c3Npb24sIElJUkMsIGF0IFlva29oYW1hIGFib3V0IHRoaXMgcG9pbnQgYnV0LA0KID4gYWdhaW4g SUlSQywgYXQgdGhlIG1vbWVudCwgREhBQUQgd2FzIHRoZSBvbmx5IG1lY2hhbmlzbSBmb3IgYSBN TiB0bw0KID4gZGlzY292ZXIgaXRzIHBvdGVudGlhbCBIQXMuDQogPiBUaGVyZSB3ZXJlIGRyYWZ0 cyBhYm91dCB0aGlzIHNlY3VyaXR5IGlzc3VlIGFuZCBwb3RlbnRpYWwgc29sdXRpb25zOg0KID4g YXQgZmlyc3QgdG8gc2VjdXJlIERIQUFEIChkcmFmdC1kdXBvbnQtbWlwNi1kaGFhZGhhcm1mdWwp IGFuZCwgbGF0ZXIsDQogPiB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBpbiB0aGUg c3BsaXQgc2NlbmFyaW8NCiA+IChkcmFmdC1kdXBvbnQtaWtldjItaGFhc3NpZ24pLg0KID4NCiA+ IG8gREhBQUQgYXMgYWx0ZXJuYXRpdmUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbg0KID4g VGhhdCB3b3VsZCBtZWFuIHRvIGtlZXAgYSB0aGlyZCBNSVB2NiBib290c3RyYXBwaW5nIHNvbHV0 aW9uLg0KID4NCiA+IFNvLCBJSE1PLCBJIHN0aWxsIGRvbid0IHNlZSBjb25jcmV0ZS9jcml0aWNh bCByZWFzb25zIHRvIGtlZXAgdGhlDQogPiBESEFBRCBtZWNoYW5pc20gaW4gdGhlIFJGQzM3NzVi aXMuDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiBKZWFuLU1pY2hlbCBDb21iZXMgd3JvdGU6 DQogPiBCYXNhdmFyYWogUGF0aWwgd3JvdGU6DQogPiA+IDM3NzViaXMgc2hvdWxkIG9ubHkgYmUg Zml4aW5nIGFueSBidWdzIGZvdW5kIGFuZCBub3QgZGVwcmVjYXRpbmcgb3INCiA+ID4gYWRkaW5n IG5ldyBmZWF0dXJlcy4NCiA+IERIQUFEIHNlZW1zIG5vdCB0byBiZSBjcml0aWNhbCBmb3IgTUlQ djYgKGFuZCB0aGUgcHJvdG9jb2xzIGJhc2VkIG9uDQogPiBNSVB2NiBidXQgaXQgd291bGQgYmUg Z29vZCB0byBjaGVjayB0aGlzKSwgYW5kIFZpamF5IGNvbmZpcm1lZCB0aGlzDQogPiBwb2ludCBp biBzYXlpbmcgdGhhdCBESEFBRCBpcyBvcHRpb25hbCBpbiBNSVB2Ni4NCiA+DQogPiBNYXliZSwg aWYgdGhlIFJGQzM3NzViaXMgaXMgYSBuZXcgc3RlcCBpbiB0aGUgU3RhbmRhcmQgVHJhY2sgZm9y IHRoZQ0KID4gTUlQdjYgc3RhbmRhcmRpemF0aW9uLCB0aGlzIHdvdWxkIGJlIHRoZSByaWdodCBt b21lbnQgdG8gZG8gc3VjaA0KID4gbW9kaWZpY2F0aW9ucy4NCiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KIFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gSmVhbi1NaWNoZWwgQ29tYmVzIHdy b3RlOg0KID4gPiBIaSBWaWpheSBhbmQgUmFqLA0KID4gPg0KID4gPiBESEFBRCBzZWVtcyBub3Qg dG8gYmUgY3JpdGljYWwgZm9yIE1JUHY2IChhbmQgdGhlIHByb3RvY29scyBiYXNlZA0KID4gPiBv biBNSVB2NiBidXQgaXQgd291bGQgYmUgZ29vZCB0byBjaGVjayB0aGlzKSwgYW5kIFZpamF5IGNv bmZpcm1lZA0KID4gPiB0aGlzIHBvaW50IGluIHNheWluZyB0aGF0IERIQUFEIGlzIG9wdGlvbmFs IGluIE1JUHY2Lg0KID4NCiA+IEkgc2FpZCBvcHRpb25hbCB0byB1c2UuIE1vc3QgaW1wbGVtZW50 YXRpb25zIEkga25vdyBvZiBoYXZlDQogPiBpbXBsZW1lbnRlZCBESEFBRC4NCiA+DQogPiA+IE1h eWJlLCBpZiB0aGUgUkZDMzc3NWJpcyBpcyBhIG5ldyBzdGVwIGluIHRoZSBTdGFuZGFyZCBUcmFj ayBmb3INCiA+ID4gdGhlIE1JUHY2IHN0YW5kYXJkaXphdGlvbiwgdGhpcyB3b3VsZCBiZSB0aGUg cmlnaHQgbW9tZW50IHRvIGRvDQogPiA+IHN1Y2ggbW9kaWZpY2F0aW9ucy4NCiA+DQogPiBEcm9w cGluZyBmZWF0dXJlcyB0aGF0IGFyZSBub3QgdXNlZC9pbXBsZW1lbnRlZCBpcyB0eXBpY2FsbHkg ZG9uZQ0KID4gd2hlbiBhIHByb3RvY29sIHByb2dyZXNzZXMgZnJvbSBQcm9wb3NlZCBTdGFuZGFy ZCB0byBEcmFmdCBTdGFuZGFyZC4NCiA+IFdlIHNob3VsZG4ndCBkbyBpdCBub3cuDQogLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCiBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQogPiBKZWFuLU1p Y2hlbCBDb21iZXMgd3JvdGU6DQogPiA+IEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCiA+ID4+ IEkgc3VwcG9ydCBrZWVwaW5nIERIQUFEIGluIHRoZSBjdXJyZW50IHNwZWMuICBJZiBuZWNlc3Nh cnksIEkgY2FuDQogPiA+PiBzdWdnZXN0IG5ldyBjbGFyaWZ5aW5nIHRleHQgc2F5aW5nIHRoYXQg REhBQUQgdXNlZCBpbiBjb25qdW5jdGlvbg0KID4gPj4gd2l0aCBNUEQgYW5kIGEgcHJvcGVyIElQ c2VjIFNBIHNldHRpbmcgbGVhZHMgdG8gZWZmZWN0aXZlIEhBDQogPiA+PiBhZGRyZXNzIGFuZCBI b21lIEFkZHJlc3MgYm9vdHN0cmFwcGluZyBvbiBNTiB3aGlsZSBhdCBob21lIGFuZA0KID4gPj4g d2hpbGUgYXdheSBmcm9tIGhvbWUuDQogPiA+DQogPiA+IEluIHlvdXIgcmVwbHksIHRoZXJlIGFy ZSAyIHBvaW50czoNCiA+ID4NCiA+ID4gbyBESEFBRCBpcyB1bnNlY3VyZWQNCiA+DQogPiBJJ20g bm90IHN1cmUgaG93IG11Y2ggaW5zZWN1cmUgaXQgaXMuICBJIGFncmVlIHRoYXQgdGhlIHNlbWFu dGljcyBvZg0KID4gYSBhbnljYXN0IGFkZHJlc3Mgc2VlbSBsZXNzIHNlY3VyYWJsZSB0aGFuIGEg dW5pY2FzdCBhZGRyZXNzICh3aXRoDQogPiBJUHNlYy4pDQogPg0KID4gPiBJIHN0cm9uZ2x5IGFn cmVlIGFuZCB0aGlzIGlzIG9uZSByZWFzb24gb2YgdGhpcyB0aHJlYWQuIFRoZXJlIHdhcyBhDQog PiA+IGxvbmcgZGlzY3Vzc2lvbiwgSUlSQywgYXQgWW9rb2hhbWEgYWJvdXQgdGhpcyBwb2ludCBi dXQsIGFnYWluDQogPiA+IElJUkMsIGF0IHRoZSBtb21lbnQsIERIQUFEIHdhcyB0aGUgb25seSBt ZWNoYW5pc20gZm9yIGEgTU4gdG8NCiA+ID4gZGlzY292ZXIgaXRzIHBvdGVudGlhbCBIQXMuIFRo ZXJlIHdlcmUgZHJhZnRzIGFib3V0IHRoaXMgc2VjdXJpdHkNCiA+ID4gaXNzdWUgYW5kIHBvdGVu dGlhbCBzb2x1dGlvbnM6IGF0IGZpcnN0IHRvIHNlY3VyZSBESEFBRA0KID4gPiAoZHJhZnQtZHVw b250LW1pcDYtZGhhYWRoYXJtZnVsKSBhbmQsIGxhdGVyLCB0aGUgTUlQdjYNCiA+ID4gYm9vdHN0 cmFwcGluZyBzb2x1dGlvbiBpbiB0aGUgc3BsaXQgc2NlbmFyaW8NCiA+ID4gKGRyYWZ0LWR1cG9u dC1pa2V2Mi1oYWFzc2lnbikuDQogPg0KID4gQW55IGFkZHJlc3MgZGlzY292ZXJ5IG1lY2hhbmlz bSBoYXMgYW4gaW5zZWN1cml0eSBwYXJ0IGluIGl0LiAgREhDUHY2DQogPiBoYXMgdG9vLg0KID4N CiA+IEl0J3Mgbm90IGxpa2UgdGhlcmUncyBhIHNlY3VyZSBjb3VudGVycGFydCB0aGF0IHdlIHNo b3VsZCB1c2UgaW5zdGVhZA0KID4gb2YgdGhlIGluc2VjdXJlIERIQUFELg0KID4NCiA+IElLRXYy IGNvdWxkIHNlY3VyZWx5IGFzc2lnbiB0aGUgSEEgYW5kIG1heWJlIHRoZSBIb0EgdG9vLCBidXQg bWF5YmUNCiA+IGhhcyB0b28gbWFueSBtZXNzYWdlIGV4Y2hhbmdlcy4NCiA+DQogPiA+IG8gREhB QUQgYXMgYWx0ZXJuYXRpdmUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBUaGF0IHdvdWxk IG1lYW4NCiA+ID4gdG8ga2VlcCBhIHRoaXJkIE1JUHY2IGJvb3RzdHJhcHBpbmcgc29sdXRpb24u DQogPg0KID4gSSdkIGNhbGwgaXQgYSAwdGggOi0pDQogPg0KID4gPiBTbywgSUhNTywgSSBzdGls bCBkb24ndCBzZWUgY29uY3JldGUvY3JpdGljYWwgcmVhc29ucyB0byBrZWVwIHRoZQ0KID4gPiBE SEFBRCBtZWNoYW5pc20gaW4gdGhlIFJGQzM3NzViaXMuDQogPg0KID4gT2ssIGxldCdzIHNlZS4N CiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIEdlb3JnZSBUc2lydHNpcyB3cm90ZToNCiA+IEpl YW4tTWljaGVsIENvbWJlcyB3cm90ZToNCiA+ID4gR2VvcmdlIFRzaXJ0c2lzIHdyb3RlOg0KID4g PiA+IEkgYWdyZWUgd2l0aCBBbGV4IG9uIHRoaXMuIEkgYW0gbm90IHN1cmUgd2UgaGF2ZSBnb29k DQogPiA+ID4ganVzdGlmaWNhdGlvbiBmb3IgcmVtb3ZpbmcgREhBQUQuIFRoZSBmZWF0dXJlIGlz IG5vdCBicm9rZW4NCiA+ID4NCiA+ID4gTm90IGJyb2tlbiBidXQ6DQogPiA+IC0gdW5zZWN1cmVk DQogPiA+IC0gYSBuaWNlIHRvb2wgdG8gc2NhbiBIQXMgb3duZWQgYnkgYSBNb2JpbGl0eSBTZXJ2 aWNlIFByb3ZpZGVyDQogPiA+ICh3aGljaCBhcmUgdGhlIHBvaW50cyBvZiBmYWlsdXJlIG9mIGEg TUlQdjYgYmFzZWQgc2VydmljZSkNCiA+IEFub3RoZXIgdGhpbmcgdG8gZG8gbWF5YmUgd291bGQg YmUgdG8gYWRkIHRleHQgdG8gdGhlIHNlY3VyaXR5DQogPiBzZWN0aW9uIGluZGljYXRpbmcgd2hh dCB0aGUgc2VjdXJpdHkgaXNzdWVzIHdpdGggREhBQUQgbWlnaHQgYmUuIEkNCiA+IHNlZSB3aGF0 IHlvdSBhcmUgc2F5aW5nIHdydCBIQSBzY2FubmluZyBidXQgdGhhdCBtYXkgbm90IGFsd2F5cyBi ZSBhDQogPiBwcm9ibGVtIGUuZy4sIGZvciBwcml2YXRlIEhBcyBiZWhpbmQgZmlyZXdhbGxzLg0K ID4NCiA+IEFnYWluIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGd1aWRlbGluZXMgZm9yIHRoZSBy ZXZpc2lvbiBpcyB0aGF0ICJpZg0KID4gaXQgaXMgbm90IGJyb2tlbiwgZG8gbm90IGZpeCBpdCIg Oi0pDQoNCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIEplYW4tTWljaGVsIENvbWJlcyB3cm90 ZToNCiA+IFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gPiBKZWFuLU1pY2hlbCBDb21iZXMg d3JvdGU6DQogPiA+ID4gSGkgVmlqYXkgYW5kIFJhaiwNCiA+ID4gPg0KID4gPiA+IERIQUFEIHNl ZW1zIG5vdCB0byBiZSBjcml0aWNhbCBmb3IgTUlQdjYgKGFuZCB0aGUgcHJvdG9jb2xzIGJhc2Vk DQogPiA+ID4gb24gTUlQdjYgYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8gY2hlY2sgdGhpcyksIGFu ZCBWaWpheSBjb25maXJtZWQNCiA+ID4gPiB0aGlzIHBvaW50IGluIHNheWluZyB0aGF0IERIQUFE IGlzIG9wdGlvbmFsIGluIE1JUHY2Lg0KID4gPg0KID4gPiBJIHNhaWQgb3B0aW9uYWwgdG8gdXNl Lg0KID4NCiA+IFNvcnJ5LCB5ZXM6IHMvREhBQUQgaXMgb3B0aW9uYWwgaW4gTUlQdjYvREhBQUQg dXNlIGlzIG9wdGlvbmFsIGluDQogPiBNSVB2Ni4NCiA+DQogPiA+IE1vc3QgaW1wbGVtZW50YXRp b25zIEkga25vdyBvZiBoYXZlDQogPiA+IGltcGxlbWVudGVkIERIQUFELg0KID4NCiA+IFJIMCBp cyBpbXBsZW1lbnRlZCBpbiBtb3N0IElQdjYgaW1wbGVtZW50YXRpb25zIHRvbyBidXQgdGhlIGNv ZGUNCiA+IGhhcy93aWxsIGJlIGNvbW1lbnRlZC9yZW1vdmVkLg0KID4gTXkgY29uY2VybiBpcyBy ZWdhcmRpbmcgZnV0dXJlIGltcGxlbWVudGF0aW9ucy4NCiA+DQogPiA+ID4gTWF5YmUsIGlmIHRo ZSBSRkMzNzc1YmlzIGlzIGEgbmV3IHN0ZXAgaW4gdGhlIFN0YW5kYXJkIFRyYWNrIGZvcg0KID4g PiA+IHRoZSBNSVB2NiBzdGFuZGFyZGl6YXRpb24sIHRoaXMgd291bGQgYmUgdGhlIHJpZ2h0IG1v bWVudCB0byBkbw0KID4gPiA+IHN1Y2ggbW9kaWZpY2F0aW9ucy4NCiA+ID4NCiA+ID4gRHJvcHBp bmcgZmVhdHVyZXMgdGhhdCBhcmUgbm90IHVzZWQvaW1wbGVtZW50ZWQgaXMgdHlwaWNhbGx5IGRv bmUNCiA+ID4gd2hlbiBhIHByb3RvY29sIHByb2dyZXNzZXMgZnJvbSBQcm9wb3NlZCBTdGFuZGFy ZCB0byBEcmFmdA0KID4gPiBTdGFuZGFyZC4gV2Ugc2hvdWxkbid0IGRvIGl0IG5vdy4NCiA+DQog PiBJJ3ZlIHJlYWQgYWdhaW4gdGhlIE1FWFQgY2hhcnRlciBhbmQgSSd2ZSBqdXN0IHNlZW4gdGhh dCBSRkMzNzc1YmlzDQogPiB3aWxsIGJlIHN1Ym1pdHRlZCBhcyBQUy4gSSBtdXN0IGFkbWl0LCBJ J3ZlIG1pc3NlZCB0aGlzIF9pbXBvcnRhbnRfDQogPiBwb2ludC4NCg0KLS0gDQpUaWNrZXQgVVJM OiA8aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvd2cvbWV4dC90cmFjL3RpY2tldC8yI2NvbW1l bnQ6Mj4NCm1leHQgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9tZXh0L3RyYWMvPg0K --===============0128744578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0128744578==-- From mext-bounces@ietf.org Tue Dec 18 08:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch5-0000BC-5G; Tue, 18 Dec 2007 08:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cH8-0004wx-KB for mext@ietf.org; Tue, 18 Dec 2007 08:14:22 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4cH6-0005sS-Cy for mext@ietf.org; Tue, 18 Dec 2007 08:14:22 -0500 Received: from localhost ([127.0.0.1]:53437 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4cH5-0000pz-BU; Tue, 18 Dec 2007 14:14:19 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 13:14:19 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:1 Message-ID: <079.2028afa417a8f7a07355fb4f43d85f5c@tools.ietf.org> References: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Tue, 18 Dec 2007 08:41:09 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1043569027==" Errors-To: mext-bounces@ietf.org --===============1043569027== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzI6IFJlbW92aW5nIERIQUFEIG1lY2hhbmlzbSBbSmVhbi1NaWNoZWwgQ29tYmVzIDxqZWFubWlj aGVsLmNvbWJlc0BnbWFpbC5jb20+XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRlcjog IGp1bGllbi5pZXRmQGxhcG9zdGUubmV0ICB8ICAgICAgIE93bmVyOiAganVsaWVuLmlldGZAbGFw b3N0ZS5uZXQNCiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldyAgICAgICAgICAgICAgICAgICAgDQogIFByaW9yaXR5OiAgbWFqb3IgICAgICAg ICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAgICAgICAgICAgICAgICAgICAgIA0KIENv bXBvbmVudDogIFJGQzM3NzUgY2hhbmdlcyAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgICAg ICAgICAgICAgICAgICAgICANClJlc29sdXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDb21tZW50IChieSBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCk6DQoNCiBBbGV4YW5kcnUg UGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KDQogPiBJIHN1 cHBvcnQga2VlcGluZyBESEFBRCBpbiB0aGUgY3VycmVudCBzcGVjLiAgSWYgbmVjZXNzYXJ5LCBJ IGNhbg0KID4gc3VnZ2VzdCBuZXcgY2xhcmlmeWluZyB0ZXh0IHNheWluZyB0aGF0IERIQUFEIHVz ZWQgaW4gY29uanVuY3Rpb24gd2l0aA0KID4gTVBEIGFuZCBhIHByb3BlciBJUHNlYyBTQSBzZXR0 aW5nIGxlYWRzIHRvIGVmZmVjdGl2ZSBIQSBhZGRyZXNzIGFuZCBIb21lDQogPiBBZGRyZXNzIGJv b3RzdHJhcHBpbmcgb24gTU4gd2hpbGUgYXQgaG9tZSBhbmQgd2hpbGUgYXdheSBmcm9tIGhvbWUu DQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly93d3czLnRvb2xzLmlldGYub3JnL3dnL21leHQv dHJhYy90aWNrZXQvMiNjb21tZW50OjE+DQptZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv bWV4dC90cmFjLz4NCg== --===============1043569027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1043569027==-- From mext-bounces@ietf.org Tue Dec 18 08:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ch5-0000Cj-Qr; Tue, 18 Dec 2007 08:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ccC-0006ML-LS for mext@ietf.org; Tue, 18 Dec 2007 08:36:08 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ccB-0006Qm-ID for mext@ietf.org; Tue, 18 Dec 2007 08:36:08 -0500 Received: from localhost ([127.0.0.1]:46986 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4ccA-0002eX-89; Tue, 18 Dec 2007 14:36:06 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 13:36:06 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #2: Removing DHAAD mechanism [Jean-Michel Combes ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/2#comment:2 Message-ID: <079.9a99abe2c3f9a14098e4591022f9e17b@tools.ietf.org> References: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <070.f89411548bd65b5f49cccc5747dc0310@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, jeanmichel.combes@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Tue, 18 Dec 2007 08:41:09 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128744578==" Errors-To: mext-bounces@ietf.org --===============0128744578== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzI6IFJlbW92aW5nIERIQUFEIG1lY2hhbmlzbSBbSmVhbi1NaWNoZWwgQ29tYmVzIDxqZWFubWlj aGVsLmNvbWJlc0BnbWFpbC5jb20+XQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRlcjog IGp1bGllbi5pZXRmQGxhcG9zdGUubmV0ICB8ICAgICAgIE93bmVyOiAganVsaWVuLmlldGZAbGFw b3N0ZS5uZXQNCiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0 YXR1czogIG5ldyAgICAgICAgICAgICAgICAgICAgDQogIFByaW9yaXR5OiAgbWFqb3IgICAgICAg ICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICAgICAgICAgICAgICAgICAgICAgIA0KIENv bXBvbmVudDogIFJGQzM3NzUgY2hhbmdlcyAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAgICAg ICAgICAgICAgICAgICAgICANClJlc29sdXRpb246ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgICAgDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDb21tZW50IChieSBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCk6DQoNCiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiBHZW9yZ2UgVHNpcnRzaXMgd3JvdGU6DQogPiBJIGFncmVlIHdpdGggQWxl eCBvbiB0aGlzLiBJIGFtIG5vdCBzdXJlIHdlIGhhdmUgZ29vZCBqdXN0aWZpY2F0aW9uDQogPiBm b3IgcmVtb3ZpbmcgREhBQUQuIFRoZSBmZWF0dXJlIGlzIG5vdCBicm9rZW4gYW5kIGFyZ3VhYmx5 IHRoZQ0KID4gYWRkaXRpb25hbCBib290c3RyYXBpbmcgbWVjaGFuaXNtcyBiZWluZyBkZWZpbmVk LCBkbyBub3Qgb3ZlcmxhcCB3aXRoDQogPiBpdCBzaW5jZSB0aGV5IGFyZSBkZWFsaW5nIHdpdGgg dGhlIGNhc2Ugd2hlbiB0aGUgSE5QIGlzIG5vdCBrbm93biB0bw0KID4gdGhlIE1OLg0KIC0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KIFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gSSBkb24ndCB0 aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSBESEFBRCBtZWNoYW5pc20gZnJvbSAzNzc1YmlzLg0K ID4gVGhlIGludGVudGlvbiBiZWhpbmQgcmV2aXNpbmcgMzc3NSBpcyB0byBhZGQgY2xhcmlmaWNh dGlvbnMNCiA+IHdoZXJlIGV2ZXIgcmVxdWlyZWQgYW5kIGZpeCBidWdzLiBOb3QgdG8gbWFrZSBt YWpvciBjaGFuZ2VzIGxpa2UNCiA+IHJlbW92aW5nIG9yIGFkZGluZyBmZWF0dXJlcy4NCiA+DQog PiBUaGUgdXNlIG9mIERIQUFEIGluIFJGQyAzNzc1IGlzIG9wdGlvbmFsDQogLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogQmFzYXZhcmFqIFBhdGlsIHdyb3RlOg0KID4gMzc3NWJpcyBzaG91bGQgb25s eSBiZSBmaXhpbmcgYW55IGJ1Z3MgZm91bmQgYW5kIG5vdCBkZXByZWNhdGluZyBvcg0KID4gYWRk aW5nIG5ldyBmZWF0dXJlcy4NCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBKZWFuLU1pY2hlbCBD b21iZXMgd3JvdGU6DQogPiBHZW9yZ2UgVHNpcnRzaXMgd3JvdGU6DQogPiA+IEkgYWdyZWUgd2l0 aCBBbGV4IG9uIHRoaXMuIEkgYW0gbm90IHN1cmUgd2UgaGF2ZSBnb29kIGp1c3RpZmljYXRpb24N CiA+ID4gZm9yIHJlbW92aW5nIERIQUFELiBUaGUgZmVhdHVyZSBpcyBub3QgYnJva2VuDQogPg0K ID4gTm90IGJyb2tlbiBidXQ6DQogPiAtIHVuc2VjdXJlZA0KID4gLSBhIG5pY2UgdG9vbCB0byBz Y2FuIEhBcyBvd25lZCBieSBhIE1vYmlsaXR5IFNlcnZpY2UgUHJvdmlkZXIgKHdoaWNoDQogPiBh cmUgdGhlIHBvaW50cyBvZiBmYWlsdXJlIG9mIGEgTUlQdjYgYmFzZWQgc2VydmljZSkNCiA+DQog PiA+IGFuZCBhcmd1YWJseSB0aGUNCiA+ID4gYWRkaXRpb25hbCBib290c3RyYXBpbmcgbWVjaGFu aXNtcyBiZWluZyBkZWZpbmVkLCBkbyBub3Qgb3ZlcmxhcA0KID4gPiB3aXRoIGl0IHNpbmNlIHRo ZXkgYXJlIGRlYWxpbmcgd2l0aCB0aGUgY2FzZSB3aGVuIHRoZSBITlAgaXMgbm90DQogPiA+IGtu b3duIHRvIHRoZSBNTi4NCiA+DQogPiBTbywgaWYgdGhlc2Ugc29sdXRpb25zIGFyZSBiZXR0ZXIs IHdoeSB0byBrZWVwIERIQUFEPw0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogSmVhbi1NaWNo ZWwgQ29tYmVzIHdyb3RlOg0KID4gQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0KID4gPiBJIHN1 cHBvcnQga2VlcGluZyBESEFBRCBpbiB0aGUgY3VycmVudCBzcGVjLiAgSWYgbmVjZXNzYXJ5LCBJ IGNhbg0KID4gPiBzdWdnZXN0IG5ldyBjbGFyaWZ5aW5nIHRleHQgc2F5aW5nIHRoYXQgREhBQUQg dXNlZCBpbiBjb25qdW5jdGlvbg0KID4gPiB3aXRoIE1QRCBhbmQgYSBwcm9wZXIgSVBzZWMgU0Eg c2V0dGluZyBsZWFkcyB0byBlZmZlY3RpdmUgSEENCiA+ID4gYWRkcmVzcyBhbmQgSG9tZSBBZGRy ZXNzIGJvb3RzdHJhcHBpbmcgb24gTU4gd2hpbGUgYXQgaG9tZSBhbmQNCiA+ID4gd2hpbGUgYXdh eSBmcm9tIGhvbWUuDQogPg0KID4gSW4geW91ciByZXBseSwgdGhlcmUgYXJlIDIgcG9pbnRzOg0K ID4NCiA+IG8gREhBQUQgaXMgdW5zZWN1cmVkDQogPiBJIHN0cm9uZ2x5IGFncmVlIGFuZCB0aGlz IGlzIG9uZSByZWFzb24gb2YgdGhpcyB0aHJlYWQuDQogPiBUaGVyZSB3YXMgYSBsb25nIGRpc2N1 c3Npb24sIElJUkMsIGF0IFlva29oYW1hIGFib3V0IHRoaXMgcG9pbnQgYnV0LA0KID4gYWdhaW4g SUlSQywgYXQgdGhlIG1vbWVudCwgREhBQUQgd2FzIHRoZSBvbmx5IG1lY2hhbmlzbSBmb3IgYSBN TiB0bw0KID4gZGlzY292ZXIgaXRzIHBvdGVudGlhbCBIQXMuDQogPiBUaGVyZSB3ZXJlIGRyYWZ0 cyBhYm91dCB0aGlzIHNlY3VyaXR5IGlzc3VlIGFuZCBwb3RlbnRpYWwgc29sdXRpb25zOg0KID4g YXQgZmlyc3QgdG8gc2VjdXJlIERIQUFEIChkcmFmdC1kdXBvbnQtbWlwNi1kaGFhZGhhcm1mdWwp IGFuZCwgbGF0ZXIsDQogPiB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBpbiB0aGUg c3BsaXQgc2NlbmFyaW8NCiA+IChkcmFmdC1kdXBvbnQtaWtldjItaGFhc3NpZ24pLg0KID4NCiA+ IG8gREhBQUQgYXMgYWx0ZXJuYXRpdmUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbg0KID4g VGhhdCB3b3VsZCBtZWFuIHRvIGtlZXAgYSB0aGlyZCBNSVB2NiBib290c3RyYXBwaW5nIHNvbHV0 aW9uLg0KID4NCiA+IFNvLCBJSE1PLCBJIHN0aWxsIGRvbid0IHNlZSBjb25jcmV0ZS9jcml0aWNh bCByZWFzb25zIHRvIGtlZXAgdGhlDQogPiBESEFBRCBtZWNoYW5pc20gaW4gdGhlIFJGQzM3NzVi aXMuDQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiBKZWFuLU1pY2hlbCBDb21iZXMgd3JvdGU6 DQogPiBCYXNhdmFyYWogUGF0aWwgd3JvdGU6DQogPiA+IDM3NzViaXMgc2hvdWxkIG9ubHkgYmUg Zml4aW5nIGFueSBidWdzIGZvdW5kIGFuZCBub3QgZGVwcmVjYXRpbmcgb3INCiA+ID4gYWRkaW5n IG5ldyBmZWF0dXJlcy4NCiA+IERIQUFEIHNlZW1zIG5vdCB0byBiZSBjcml0aWNhbCBmb3IgTUlQ djYgKGFuZCB0aGUgcHJvdG9jb2xzIGJhc2VkIG9uDQogPiBNSVB2NiBidXQgaXQgd291bGQgYmUg Z29vZCB0byBjaGVjayB0aGlzKSwgYW5kIFZpamF5IGNvbmZpcm1lZCB0aGlzDQogPiBwb2ludCBp biBzYXlpbmcgdGhhdCBESEFBRCBpcyBvcHRpb25hbCBpbiBNSVB2Ni4NCiA+DQogPiBNYXliZSwg aWYgdGhlIFJGQzM3NzViaXMgaXMgYSBuZXcgc3RlcCBpbiB0aGUgU3RhbmRhcmQgVHJhY2sgZm9y IHRoZQ0KID4gTUlQdjYgc3RhbmRhcmRpemF0aW9uLCB0aGlzIHdvdWxkIGJlIHRoZSByaWdodCBt b21lbnQgdG8gZG8gc3VjaA0KID4gbW9kaWZpY2F0aW9ucy4NCiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KIFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gSmVhbi1NaWNoZWwgQ29tYmVzIHdy b3RlOg0KID4gPiBIaSBWaWpheSBhbmQgUmFqLA0KID4gPg0KID4gPiBESEFBRCBzZWVtcyBub3Qg dG8gYmUgY3JpdGljYWwgZm9yIE1JUHY2IChhbmQgdGhlIHByb3RvY29scyBiYXNlZA0KID4gPiBv biBNSVB2NiBidXQgaXQgd291bGQgYmUgZ29vZCB0byBjaGVjayB0aGlzKSwgYW5kIFZpamF5IGNv bmZpcm1lZA0KID4gPiB0aGlzIHBvaW50IGluIHNheWluZyB0aGF0IERIQUFEIGlzIG9wdGlvbmFs IGluIE1JUHY2Lg0KID4NCiA+IEkgc2FpZCBvcHRpb25hbCB0byB1c2UuIE1vc3QgaW1wbGVtZW50 YXRpb25zIEkga25vdyBvZiBoYXZlDQogPiBpbXBsZW1lbnRlZCBESEFBRC4NCiA+DQogPiA+IE1h eWJlLCBpZiB0aGUgUkZDMzc3NWJpcyBpcyBhIG5ldyBzdGVwIGluIHRoZSBTdGFuZGFyZCBUcmFj ayBmb3INCiA+ID4gdGhlIE1JUHY2IHN0YW5kYXJkaXphdGlvbiwgdGhpcyB3b3VsZCBiZSB0aGUg cmlnaHQgbW9tZW50IHRvIGRvDQogPiA+IHN1Y2ggbW9kaWZpY2F0aW9ucy4NCiA+DQogPiBEcm9w cGluZyBmZWF0dXJlcyB0aGF0IGFyZSBub3QgdXNlZC9pbXBsZW1lbnRlZCBpcyB0eXBpY2FsbHkg ZG9uZQ0KID4gd2hlbiBhIHByb3RvY29sIHByb2dyZXNzZXMgZnJvbSBQcm9wb3NlZCBTdGFuZGFy ZCB0byBEcmFmdCBTdGFuZGFyZC4NCiA+IFdlIHNob3VsZG4ndCBkbyBpdCBub3cuDQogLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCiBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQogPiBKZWFuLU1p Y2hlbCBDb21iZXMgd3JvdGU6DQogPiA+IEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCiA+ID4+ IEkgc3VwcG9ydCBrZWVwaW5nIERIQUFEIGluIHRoZSBjdXJyZW50IHNwZWMuICBJZiBuZWNlc3Nh cnksIEkgY2FuDQogPiA+PiBzdWdnZXN0IG5ldyBjbGFyaWZ5aW5nIHRleHQgc2F5aW5nIHRoYXQg REhBQUQgdXNlZCBpbiBjb25qdW5jdGlvbg0KID4gPj4gd2l0aCBNUEQgYW5kIGEgcHJvcGVyIElQ c2VjIFNBIHNldHRpbmcgbGVhZHMgdG8gZWZmZWN0aXZlIEhBDQogPiA+PiBhZGRyZXNzIGFuZCBI b21lIEFkZHJlc3MgYm9vdHN0cmFwcGluZyBvbiBNTiB3aGlsZSBhdCBob21lIGFuZA0KID4gPj4g d2hpbGUgYXdheSBmcm9tIGhvbWUuDQogPiA+DQogPiA+IEluIHlvdXIgcmVwbHksIHRoZXJlIGFy ZSAyIHBvaW50czoNCiA+ID4NCiA+ID4gbyBESEFBRCBpcyB1bnNlY3VyZWQNCiA+DQogPiBJJ20g bm90IHN1cmUgaG93IG11Y2ggaW5zZWN1cmUgaXQgaXMuICBJIGFncmVlIHRoYXQgdGhlIHNlbWFu dGljcyBvZg0KID4gYSBhbnljYXN0IGFkZHJlc3Mgc2VlbSBsZXNzIHNlY3VyYWJsZSB0aGFuIGEg dW5pY2FzdCBhZGRyZXNzICh3aXRoDQogPiBJUHNlYy4pDQogPg0KID4gPiBJIHN0cm9uZ2x5IGFn cmVlIGFuZCB0aGlzIGlzIG9uZSByZWFzb24gb2YgdGhpcyB0aHJlYWQuIFRoZXJlIHdhcyBhDQog PiA+IGxvbmcgZGlzY3Vzc2lvbiwgSUlSQywgYXQgWW9rb2hhbWEgYWJvdXQgdGhpcyBwb2ludCBi dXQsIGFnYWluDQogPiA+IElJUkMsIGF0IHRoZSBtb21lbnQsIERIQUFEIHdhcyB0aGUgb25seSBt ZWNoYW5pc20gZm9yIGEgTU4gdG8NCiA+ID4gZGlzY292ZXIgaXRzIHBvdGVudGlhbCBIQXMuIFRo ZXJlIHdlcmUgZHJhZnRzIGFib3V0IHRoaXMgc2VjdXJpdHkNCiA+ID4gaXNzdWUgYW5kIHBvdGVu dGlhbCBzb2x1dGlvbnM6IGF0IGZpcnN0IHRvIHNlY3VyZSBESEFBRA0KID4gPiAoZHJhZnQtZHVw b250LW1pcDYtZGhhYWRoYXJtZnVsKSBhbmQsIGxhdGVyLCB0aGUgTUlQdjYNCiA+ID4gYm9vdHN0 cmFwcGluZyBzb2x1dGlvbiBpbiB0aGUgc3BsaXQgc2NlbmFyaW8NCiA+ID4gKGRyYWZ0LWR1cG9u dC1pa2V2Mi1oYWFzc2lnbikuDQogPg0KID4gQW55IGFkZHJlc3MgZGlzY292ZXJ5IG1lY2hhbmlz bSBoYXMgYW4gaW5zZWN1cml0eSBwYXJ0IGluIGl0LiAgREhDUHY2DQogPiBoYXMgdG9vLg0KID4N CiA+IEl0J3Mgbm90IGxpa2UgdGhlcmUncyBhIHNlY3VyZSBjb3VudGVycGFydCB0aGF0IHdlIHNo b3VsZCB1c2UgaW5zdGVhZA0KID4gb2YgdGhlIGluc2VjdXJlIERIQUFELg0KID4NCiA+IElLRXYy IGNvdWxkIHNlY3VyZWx5IGFzc2lnbiB0aGUgSEEgYW5kIG1heWJlIHRoZSBIb0EgdG9vLCBidXQg bWF5YmUNCiA+IGhhcyB0b28gbWFueSBtZXNzYWdlIGV4Y2hhbmdlcy4NCiA+DQogPiA+IG8gREhB QUQgYXMgYWx0ZXJuYXRpdmUgTUlQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBUaGF0IHdvdWxk IG1lYW4NCiA+ID4gdG8ga2VlcCBhIHRoaXJkIE1JUHY2IGJvb3RzdHJhcHBpbmcgc29sdXRpb24u DQogPg0KID4gSSdkIGNhbGwgaXQgYSAwdGggOi0pDQogPg0KID4gPiBTbywgSUhNTywgSSBzdGls bCBkb24ndCBzZWUgY29uY3JldGUvY3JpdGljYWwgcmVhc29ucyB0byBrZWVwIHRoZQ0KID4gPiBE SEFBRCBtZWNoYW5pc20gaW4gdGhlIFJGQzM3NzViaXMuDQogPg0KID4gT2ssIGxldCdzIHNlZS4N CiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIEdlb3JnZSBUc2lydHNpcyB3cm90ZToNCiA+IEpl YW4tTWljaGVsIENvbWJlcyB3cm90ZToNCiA+ID4gR2VvcmdlIFRzaXJ0c2lzIHdyb3RlOg0KID4g PiA+IEkgYWdyZWUgd2l0aCBBbGV4IG9uIHRoaXMuIEkgYW0gbm90IHN1cmUgd2UgaGF2ZSBnb29k DQogPiA+ID4ganVzdGlmaWNhdGlvbiBmb3IgcmVtb3ZpbmcgREhBQUQuIFRoZSBmZWF0dXJlIGlz IG5vdCBicm9rZW4NCiA+ID4NCiA+ID4gTm90IGJyb2tlbiBidXQ6DQogPiA+IC0gdW5zZWN1cmVk DQogPiA+IC0gYSBuaWNlIHRvb2wgdG8gc2NhbiBIQXMgb3duZWQgYnkgYSBNb2JpbGl0eSBTZXJ2 aWNlIFByb3ZpZGVyDQogPiA+ICh3aGljaCBhcmUgdGhlIHBvaW50cyBvZiBmYWlsdXJlIG9mIGEg TUlQdjYgYmFzZWQgc2VydmljZSkNCiA+IEFub3RoZXIgdGhpbmcgdG8gZG8gbWF5YmUgd291bGQg YmUgdG8gYWRkIHRleHQgdG8gdGhlIHNlY3VyaXR5DQogPiBzZWN0aW9uIGluZGljYXRpbmcgd2hh dCB0aGUgc2VjdXJpdHkgaXNzdWVzIHdpdGggREhBQUQgbWlnaHQgYmUuIEkNCiA+IHNlZSB3aGF0 IHlvdSBhcmUgc2F5aW5nIHdydCBIQSBzY2FubmluZyBidXQgdGhhdCBtYXkgbm90IGFsd2F5cyBi ZSBhDQogPiBwcm9ibGVtIGUuZy4sIGZvciBwcml2YXRlIEhBcyBiZWhpbmQgZmlyZXdhbGxzLg0K ID4NCiA+IEFnYWluIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGd1aWRlbGluZXMgZm9yIHRoZSBy ZXZpc2lvbiBpcyB0aGF0ICJpZg0KID4gaXQgaXMgbm90IGJyb2tlbiwgZG8gbm90IGZpeCBpdCIg Oi0pDQoNCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIEplYW4tTWljaGVsIENvbWJlcyB3cm90 ZToNCiA+IFZpamF5IERldmFyYXBhbGxpIHdyb3RlOg0KID4gPiBKZWFuLU1pY2hlbCBDb21iZXMg d3JvdGU6DQogPiA+ID4gSGkgVmlqYXkgYW5kIFJhaiwNCiA+ID4gPg0KID4gPiA+IERIQUFEIHNl ZW1zIG5vdCB0byBiZSBjcml0aWNhbCBmb3IgTUlQdjYgKGFuZCB0aGUgcHJvdG9jb2xzIGJhc2Vk DQogPiA+ID4gb24gTUlQdjYgYnV0IGl0IHdvdWxkIGJlIGdvb2QgdG8gY2hlY2sgdGhpcyksIGFu ZCBWaWpheSBjb25maXJtZWQNCiA+ID4gPiB0aGlzIHBvaW50IGluIHNheWluZyB0aGF0IERIQUFE IGlzIG9wdGlvbmFsIGluIE1JUHY2Lg0KID4gPg0KID4gPiBJIHNhaWQgb3B0aW9uYWwgdG8gdXNl Lg0KID4NCiA+IFNvcnJ5LCB5ZXM6IHMvREhBQUQgaXMgb3B0aW9uYWwgaW4gTUlQdjYvREhBQUQg dXNlIGlzIG9wdGlvbmFsIGluDQogPiBNSVB2Ni4NCiA+DQogPiA+IE1vc3QgaW1wbGVtZW50YXRp b25zIEkga25vdyBvZiBoYXZlDQogPiA+IGltcGxlbWVudGVkIERIQUFELg0KID4NCiA+IFJIMCBp cyBpbXBsZW1lbnRlZCBpbiBtb3N0IElQdjYgaW1wbGVtZW50YXRpb25zIHRvbyBidXQgdGhlIGNv ZGUNCiA+IGhhcy93aWxsIGJlIGNvbW1lbnRlZC9yZW1vdmVkLg0KID4gTXkgY29uY2VybiBpcyBy ZWdhcmRpbmcgZnV0dXJlIGltcGxlbWVudGF0aW9ucy4NCiA+DQogPiA+ID4gTWF5YmUsIGlmIHRo ZSBSRkMzNzc1YmlzIGlzIGEgbmV3IHN0ZXAgaW4gdGhlIFN0YW5kYXJkIFRyYWNrIGZvcg0KID4g PiA+IHRoZSBNSVB2NiBzdGFuZGFyZGl6YXRpb24sIHRoaXMgd291bGQgYmUgdGhlIHJpZ2h0IG1v bWVudCB0byBkbw0KID4gPiA+IHN1Y2ggbW9kaWZpY2F0aW9ucy4NCiA+ID4NCiA+ID4gRHJvcHBp bmcgZmVhdHVyZXMgdGhhdCBhcmUgbm90IHVzZWQvaW1wbGVtZW50ZWQgaXMgdHlwaWNhbGx5IGRv bmUNCiA+ID4gd2hlbiBhIHByb3RvY29sIHByb2dyZXNzZXMgZnJvbSBQcm9wb3NlZCBTdGFuZGFy ZCB0byBEcmFmdA0KID4gPiBTdGFuZGFyZC4gV2Ugc2hvdWxkbid0IGRvIGl0IG5vdy4NCiA+DQog PiBJJ3ZlIHJlYWQgYWdhaW4gdGhlIE1FWFQgY2hhcnRlciBhbmQgSSd2ZSBqdXN0IHNlZW4gdGhh dCBSRkMzNzc1YmlzDQogPiB3aWxsIGJlIHN1Ym1pdHRlZCBhcyBQUy4gSSBtdXN0IGFkbWl0LCBJ J3ZlIG1pc3NlZCB0aGlzIF9pbXBvcnRhbnRfDQogPiBwb2ludC4NCg0KLS0gDQpUaWNrZXQgVVJM OiA8aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5vcmcvd2cvbWV4dC90cmFjL3RpY2tldC8yI2NvbW1l bnQ6Mj4NCm1leHQgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9tZXh0L3RyYWMvPg0K --===============0128744578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============0128744578==-- From mext-bounces@ietf.org Tue Dec 18 09:06:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d5X-0007BB-1D; Tue, 18 Dec 2007 09:06:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d24-0007mD-8R for mext@ietf.org; Tue, 18 Dec 2007 09:02:52 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4d23-0003WZ-K5 for mext@ietf.org; Tue, 18 Dec 2007 09:02:52 -0500 Received: from localhost ([127.0.0.1]:48425 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4d22-0003SU-Al; Tue, 18 Dec 2007 15:02:50 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 14:02:50 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/1#comment:1 Message-ID: <079.b5bb7b54f6cf587a5c66494bbb099ca4@tools.ietf.org> References: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <070.70a5698f38ff5f6693e3ac212b10049d@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, amuhanna@nortel.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Tue, 18 Dec 2007 09:06:24 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1601911949==" Errors-To: mext-bounces@ietf.org --===============1601911949== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzE6IExhc3QgQWNjZXB0ZWQgU1FOIFtBaG1hZCBNdWhhbm5hIDxhbXVoYW5uYUBub3J0ZWwuY29t Pl0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgUmVwb3J0ZXI6ICBqdWxpZW4uaWV0ZkBsYXBvc3Rl Lm5ldCAgfCAgICAgICBPd25lcjogIGp1bGllbi5pZXRmQGxhcG9zdGUubmV0DQogICAgICBUeXBl OiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcgICAgICAgICAg ICAgICAgICAgIA0KICBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICAgTWls ZXN0b25lOiAgICAgICAgICAgICAgICAgICAgICAgICANCiBDb21wb25lbnQ6ICBSRkMzNzc1IGNo YW5nZXMgICAgICAgICAgfCAgICAgVmVyc2lvbjogICAgICAgICAgICAgICAgICAgICAgICAgDQpS ZXNvbHV0aW9uOiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5d29yZHM6ICAgICAg ICAgICAgICAgICAgICAgICAgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tbWVudCAoYnkganVs aWVuLmlldGZAbGFwb3N0ZS5uZXQpOg0KDQogQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0KID4g QnV0IHRoaXMgaXMgbmV3IHNvZnR3YXJlIHRvIHdyaXRlIGFuZCBpbXBsZW1lbnQsIHJpZ2h0PyBU aGlzIGlzIG5vdCBhDQogPiBtaW5vciBtb2RpZmljYXRpb24gdG8gcmZjMzc3NS4NCg0KDQogQWht YWQgTXVoYW5uYSB3cm90ZToNCiA+DQogPiBUaGF0J3MgdHJ1ZS4gSG93ZXZlciwgZG8geW91IGFn cmVlIHdpdGggdGhlIGlzc3VlPw0KID4NCiA+IFRoaXMgcHJvcG9zYWwgaXMgb25lIHNvbHV0aW9u IGZvciB0aGUgaXNzdWU7IGlmIHlvdSBoYXZlIGENCiA+IGRpZmZlcmVudCBzb2x1dGlvbiB3aGlj aCBkb2VzIG5vdCByZXF1aXJlIHRoaXMgY2hhbmdlLCBwbGVhc2UgZ28NCiA+IGFoZWFkIGFuZCBw cm9wb3NlIGl0LiBJIGRvIG5vdCBoYXZlIGFueSBpbnRlcmVzdCBpbiBoYXZpbmcgdGhpcw0KID4g cHJvcG9zYWwgYWRvcHRlZCwgaG93ZXZlciwgSU1PLCB0aGlzIGlzc3VlIG5lZWRzIHRvIGJlIHJl c29sdmVkLg0KDQoNCiBNYXJjZWxvIEJhZ251bG8gd3JvdGU6DQogPg0KID4gSWYgeW91IGFncmVl IHRoYXQgdGhpcyBpcyB0cnVlLCB0aGVuIHRoaXMgcGFydGljdWxhciBwcm9wb3NhbCBpcyBhDQog PiBub24gc3RhcnRlcg0KID4NCiA+IElmIHlvdSBjb21lIHdpdGggYW4gYWx0ZXJuYXRpdmUgcHJv cG9zYWwgdGhhdCBpcyBhIG1pbm9yIGNoYW5nZSB0aGUNCiA+IHJlc3VibWl0IGl0IHRvIHRoZSBt bCB1c2luZyB0aGUgc2FtZSBmb3JtYXQgcGxlYXNlLCBzbyB3ZSBjYW4ga2VlcCBhbg0KID4gICBv cmRlcmVkIHRyYWNrIG9mIHRoZSBwcm9wb3NlZCBpc3N1ZXMNCg0KDQogQWhtYWQgTXVoYW5uYSB3 cm90ZToNCiA+DQogPiBJIGJlbGlldmUgdGhpcyBpcyBhbiBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJl IGZpeGVkLiBNYW55IGltcGxlbWVudGF0aW9uDQogZGlkIG5vdCB0ZXN0IGlmIHRoaXMNCiA+IHdv cmsgaW4gdGhlaXIgc29mdHdhcmUgb3Igbm90IHVudGlsIHRoaXMgaXNzdWUgd2FzIHBvaW50ZWQg b3V0LiBJTU8sDQogdGhpcyBpcyBhbiBlcnJvciBuZWVkcw0KID4gdG8gYmUgZml4ZWQuDQogPg0K ID4gT24gdGhlIG90aGVyIGhhbmQsIEkgZG8gbm90IHNlZSBhbnkgcXVpY2sgZml4IGZvciB0aGlz IGlzc3VlLCBob3dldmVyLA0KIGlmIHRoZXJlIGlzIHNvbWVvbmUNCiA+IHdobyBjYW4gcG9pbnQg YSBxdWljayBmaXgsIGhlIGlzIHdlbGNvbWUgdG8gcG9zdCBpdC4gSWYgdGhlIGdyb3VwIHRoaW5r DQogdGhhdCBmaXhpbmcgdGhpcw0KID4gaXNzdWUgaXMgbm90IG5lZWRlZCwgdGhhdCBpcyBmaW5l IHdpdGggdG9vLg0KID4NCiA+IEJUVzogVGhpcyBpc3N1ZSB3YXMgYWxzbyBkaXNjdXNzZWQgYmVm b3JlIGFuZCB3YXMgc3VibWl0dGVkIHRvIE1JUDYNCiB0cmFja2VyLg0KDQoNCiBBbGV4YW5kcnUg UGV0cmVzY3Ugd3JvdGU6DQogPg0KID4gV2hpbGUgcmVhZGluZyBpdCwgbG9va3MgYXMgYSBzaXR1 YXRpb24gZGlmZmljdWx0IHRvIHJlcHJvZHVjZSwgdG8NCiA+IHN0YXJ0IHdpdGguICBJZiB0aGUg cHJvcG9zZWQgc29sdXRpb24gaXMgbm90IGltcGxlbWVudGVkIHRoZW4gdGhlIE1ODQogPiBtYXkg c3RhcnQgb3ZlciBmcm9tIGEgZnJlc2ggc2Vxbm8uDQogPg0KID4gVGhhdCdzIHdoeSBJIGRvbid0 IHNlZSB3aHkgY29ycmVjdGluZyB0aGlzIGFzIHBhcnQgb2YgdGhlIG1pbm9yDQogPiByZmMzNzc1 IGNvcnJlY3Rpb25zLg0KDQoNCiBBaG1hZCBNdWhhbm5hIHdyb3RlOg0KID4NCiA+IEkgc2VlIHdo YXQgeW91IGFyZSBzYXlpbmcsIHNpbmNlIHRoYXQgd2hhdCB5b3UgdGhpbmsgaXMgdGhlIHNvbHV0 aW9uIGZvcg0KID4gdGhpcyBpc3N1ZSwgSSBzdWdnZXN0IHRoYXQgeW91IHByb3Bvc2Ugc29tZSB0 ZXh0IHRvIGNhcHR1cmUgd2hhdCB5b3UNCiA+IGp1c3Qgc2FpZCB0byBmaXggUkZDMzc3NSB0ZXh0 LiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgcmVzdGFydGluZyB0aGUNCiA+IGNsaWVudCBpcyBub3Qg bWVhbmluZ2Z1bCBpbiBvdGhlciBNSVA2IGV4dGVuc2lvbnMsIHRoZW4gd2hlcmUgZG8geW91DQog PiB0aGluayB0aGlzIGlzc3VlIHNob3VsZCBiZSBmaXhlZCwgdW5kZXIgdGhlIG90aGVyIGV4dGVu c2lvbnMvYWN0aXZpdGllcw0KID4gb3IgYXMgYSBmaXggdG8gUkZDMzc3NT8NCg0KDQogQWxleGFu ZHJ1IFBldHJlc2N1IHdyb3RlOg0KID4NCiA+IEkgZG9uJ3QgdGhpbmsgSSBjYW4gcHJvcG9zZSB0 ZXh0IHJpZ2h0IG5vdyBmb3IgbGFzdCBhY2NlcHRlZCBzZXFubw0KID4gaXNzdWUuICBJIHRoaW5r IGl0IGNvdWxkIHdhaXQgdW50aWwgbW9yZSBpbXBsZW1lbnRlcnMgc2hhcmUgYW4gb3Bpbmlvbg0K ID4gb24gdGhpcy4NCg0KLS0gDQpUaWNrZXQgVVJMOiA8aHR0cDovL3d3dzMudG9vbHMuaWV0Zi5v cmcvd2cvbWV4dC90cmFjL3RpY2tldC8xI2NvbW1lbnQ6MT4NCm1leHQgPGh0dHA6Ly90b29scy5p ZXRmLm9yZy93Zy9tZXh0L3RyYWMvPg0K --===============1601911949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1601911949==-- From mext-bounces@ietf.org Tue Dec 18 09:06:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d5G-0004Ri-12; Tue, 18 Dec 2007 09:06:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d5D-0004Hr-7E for mext@ietf.org; Tue, 18 Dec 2007 09:06:07 -0500 Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4d5C-0003ch-RV for mext@ietf.org; Tue, 18 Dec 2007 09:06:07 -0500 Received: from [163.117.139.66] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.66])by smtp03.uc3m.es (Postfix) with ESMTP id 96B0F296C7E; Tue, 18 Dec 2007 15:00:07 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94959D3E-C40D-4DCA-A3F3-1D92C23A183D@bagnulo.net> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: [MEXT] MEXT interim meeting 7,8 feb 2008 Date: Tue, 18 Dec 2007 15:00:19 +0100 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.3730 TC:02 TRN:21 TV:5.0.1023(15614.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Julien Laganier , mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, It seems i have a hard time letting 2007 go... sigh... here goes that correct annoucement We are finally organizing the MEXT interim meeting. The information is included below. MEXT interim meeting DATE: 7,8 feb 2008 Location: University Carlos III de Madrid Escuela Politecnica Superior Av. Universidad 30 28911 - Leganes Madrid, SPAIN Goal of the meeting: The focus of the meeting would be the nemo ro work and other considerations for nemo global deployment. We will provide more information about the location accomodation and agenda shortly Thanks, Julien and marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 09:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d5V-00071u-UG; Tue, 18 Dec 2007 09:06:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cm2-0008Ug-7K for mext@ietf.org; Tue, 18 Dec 2007 08:46:18 -0500 Received: from merlot.tools.ietf.org ([194.146.105.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4cm1-00032H-Mf for mext@ietf.org; Tue, 18 Dec 2007 08:46:18 -0500 Received: from localhost ([127.0.0.1]:43497 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1J4cm0-0002ud-Fm; Tue, 18 Dec 2007 14:46:16 +0100 MIME-Version: 1.0 From: "mext" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: mext Date: Tue, 18 Dec 2007 13:46:16 -0000 X-URL: http://tools.ietf.org/wg/mext/trac/ Subject: Re: [mext] #3: BRR, BErr are sent by HA too, not only by CN [Alexandru Petrescu ] X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/mext/trac/ticket/3#comment:1 Message-ID: <079.99890730bc46eea96cb299df83afe8a2@tools.ietf.org> References: <070.e56bf756ea0b44b3f51c960da1ba9f0c@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <070.e56bf756ea0b44b3f51c960da1ba9f0c@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: julien.ietf@laposte.net, mext@ietf.org, marcelo@it.uc3m.es, alexandru.petrescu@gmail.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: 1.6 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Tue, 18 Dec 2007 09:06:23 -0500 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1528862227==" Errors-To: mext-bounces@ietf.org --===============1528862227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzM6IEJSUiwgQkVyciBhcmUgc2VudCBieSBIQSB0b28sIG5vdCBvbmx5IGJ5IENOIFtBbGV4YW5k cnUgUGV0cmVzY3UNCjxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPl0NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgUmVwb3J0ZXI6ICBqdWxpZW4uaWV0ZkBsYXBvc3RlLm5ldCAgfCAgICAgICBP d25lcjogIGp1bGllbi5pZXRmQGxhcG9zdGUubmV0DQogICAgICBUeXBlOiAgZGVmZWN0ICAgICAg ICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcgICAgICAgICAgICAgICAgICAgIA0KICBQ cmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgICAgICAg ICAgICAgICAgICAgICAgICANCiBDb21wb25lbnQ6ICBSRkMzNzc1IGNoYW5nZXMgICAgICAgICAg fCAgICAgVmVyc2lvbjogICAgICAgICAgICAgICAgICAgICAgICAgDQpSZXNvbHV0aW9uOiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAg ICAgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tbWVudCAoYnkganVsaWVuLmlldGZAbGFwb3N0 ZS5uZXQpOg0KDQogQnJpYW4gSGFsZXkgd3JvdGU6DQogPg0KID4gWW91IG1pc3NlZCBvbmUgQ04g LT4gQ04gb3IgSEEgYXQgdGhlIGVuZCBvZiB0aGUgZmlyc3Qgc2VudGVuY2UsIEkNCiA+IHRoaW5r IGNoYW5naW5nIGl0IHRvICJpdCIgaXMgZmluZToNCiA+DQogPiAgICAgIEJpbmRpbmcgUmVmcmVz aCBSZXF1ZXN0DQogPg0KID4gICAgICAgICBBIEJpbmRpbmcgUmVmcmVzaCBSZXF1ZXN0IGlzIHVz ZWQgYnkgYSBjb3JyZXNwb25kZW50IG5vZGUgb3INCiA+IGhvbWUgYWdlbnQgdG8gcmVxdWVzdCBh IG1vYmlsZSBub2RlIHRvIHJlLWVzdGFibGlzaCBpdHMgYmluZGluZyB3aXRoDQogPiBpdC4gIFRo aXMgbWVzc2FnZSBpcyB0eXBpY2FsbHkgdXNlZCB3aGVuIHRoZSBjYWNoZWQgYmluZGluZyBpcyBp bg0KID4gYWN0aXZlIHVzZSBidXQgdGhlIGJpbmRpbmcncyBsaWZldGltZSBpcyBjbG9zZSB0byBl eHBpcmF0aW9uIFRoZQ0KID4gY29ycmVzcG9uZGVudCBub2RlIG9yIHRoZSBob21lIGFnZW50IG1h eSB1c2UsIGZvciBpbnN0YW5jZSwgcmVjZW50DQogPiB0cmFmZmljIGFuZCBvcGVuIHRyYW5zcG9y dCBsYXllciBjb25uZWN0aW9ucyBhcyBhbiBpbmRpY2F0aW9uIG9mDQogPiBhY3RpdmUgdXNlLg0K DQotLSANClRpY2tldCBVUkw6IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9tZXh0L3Ry YWMvdGlja2V0LzMjY29tbWVudDoxPg0KbWV4dCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL21l eHQvdHJhYy8+DQo= --===============1528862227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1528862227==-- From mext-bounces@ietf.org Tue Dec 18 09:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4dRR-0007Yl-Le; Tue, 18 Dec 2007 09:29:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4dRQ-0007Yb-RR for mext@ietf.org; Tue, 18 Dec 2007 09:29:04 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4dRQ-0004hc-Cd for mext@ietf.org; Tue, 18 Dec 2007 09:29:04 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2130870rvb.49 for ; Tue, 18 Dec 2007 06:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DWvrspxrzjzAb8W1Omhoc39esU9JbI4pR6mxiGOCRbo=; b=U9Xq07hQwACQq/PcQWP8ATFNRj9GRJczTr/Eb1Jm77PfLkEXOUQPjCQTb2xpi+yZdeaOMlQG8DUgnTUbae77zsye+gNj4d6OIsESyp9xsxuY9Kv8b8bYCKs9CVdeY8NQ3vELMFrHvbxJX8dGbQI7XxtREvKzDcAdxkUFtxsDOHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=joHvmFM2i7V0Wldl09s5o43nO1nC8ZaY1MHlYeoB1HLz6QWGMnGPTod/DwzMD9RtwSa8adTjRvbmapOisS/i9QgMLy2+Jro/b5AybJRr7Q7EbU1g1XVUp+ec3UvO2st9cXg9klNsIZhyA9+vGQeRdzBueqiql1GHRgaJbtnZeCc= Received: by 10.141.51.15 with SMTP id d15mr157783rvk.21.1197988143290; Tue, 18 Dec 2007 06:29:03 -0800 (PST) Received: by 10.141.180.1 with HTTP; Tue, 18 Dec 2007 06:29:03 -0800 (PST) Message-ID: <1d38a3350712180629k7dcd59e7h70fb1a20377f8a08@mail.gmail.com> Date: Tue, 18 Dec 2007 22:29:03 +0800 From: "Hui Deng" To: "marcelo bagnulo braun" Subject: Re: [MEXT] MEXT interim meeting 7,8 feb 2008 In-Reply-To: <94959D3E-C40D-4DCA-A3F3-1D92C23A183D@bagnulo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94959D3E-C40D-4DCA-A3F3-1D92C23A183D@bagnulo.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Unfortunatelly, it's Chinese lunar new year. -Hui 2007/12/18, marcelo bagnulo braun : > > Hi, > > It seems i have a hard time letting 2007 go... sigh... here goes that > correct annoucement > > We are finally organizing the MEXT interim meeting. > > The information is included below. > > MEXT interim meeting > > DATE: > 7,8 feb 2008 > > Location: > University Carlos III de Madrid > Escuela Politecnica Superior > Av. Universidad 30 > 28911 - Leganes > Madrid, SPAIN > > Goal of the meeting: > The focus of the meeting would be the nemo ro work and other > considerations for nemo global deployment. > > We will provide more information about the location accomodation and > agenda shortly > > Thanks, Julien and marcelo > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From ernegzf@writingyourwill.co.uk Tue Dec 18 10:09:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4e4k-0002N4-4b for nemo-archive@lists.ietf.org; Tue, 18 Dec 2007 10:09:42 -0500 Received: from p54ab0835.dip0.t-ipconnect.de ([84.171.8.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4e4f-0005tI-JI for nemo-archive@lists.ietf.org; Tue, 18 Dec 2007 10:09:40 -0500 Received: from bernd ([132.167.146.15] helo=bernd) by p54AB0835.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1GBiin-000VKF-fd for nemo-archive@lists.ietf.org; Tue, 18 Dec 2007 16:09:47 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Dec 2007 16:09:37 +0100 To: nemo-archive@lists.ietf.org From: "Kresnae erne" Subject: niehcsge Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Sick of your girl, whining about your short dick? Shut her mouth, by proving that your dick is a MONSTER. Only with this medicine you'll achieve your goal. http://healthkindom.com/ From mext-bounces@ietf.org Tue Dec 18 10:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eHy-0002vY-LI; Tue, 18 Dec 2007 10:23:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4eHw-0002uO-Rn for mext@ietf.org; Tue, 18 Dec 2007 10:23:21 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4eHw-0006MS-HV for mext@ietf.org; Tue, 18 Dec 2007 10:23:20 -0500 Received: by an-out-0708.google.com with SMTP id d11so734170and.122 for ; Tue, 18 Dec 2007 07:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=UuSUqPtKyq0XSBNe02ThPhBqjdLXVcet0SERwW7O//Y=; b=Hzlrpn8NBGtt7N7rnu3+m+4i0OlZDXrSivJbrKRkhs7cMmMWH5Wnjq7uQOEYyuJq5y83eBiJ8/J7Y/Fk7Qvh1TsSaVsD8GzblM52nzcxoBBXYE/27ATDT0pRe3I30ckMIe2QQR3Whe8P1QXTHOM+tbzDLUpmR5ggH/A1fGJ7uuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=iNPJ7A2zLb52Syfjy718e5dK0ioHx0v0OdTtZLzxck+lmq7hgkUmvHDV7fdqAqYia+B85ZJKuqOIporgahGxv6CciT/EaiLTeB3IF7uzc8h1jfOewn4+d5fbVH7CY1UF9H7sHvJGYCKoou7aCgmfZf1aRlcyqRhDKn7Jz9P7j/w= Received: by 10.100.215.5 with SMTP id n5mr17755166ang.20.1197991400043; Tue, 18 Dec 2007 07:23:20 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f7sm110234nfh.2007.12.18.07.23.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2007 07:23:19 -0800 (PST) From: Julien Laganier To: mext@ietf.org Date: Tue, 18 Dec 2007 16:23:36 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712181623.38497.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [MEXT] MEXT WG drafts (re)naming and submission X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org To all previous WG drafts authors/editors, The MEXT WG has automatically inherited all WG drafts from previous WGs=20 (MIP6, NEMO, MONAMI6), which isn't what we agreed on. I am therefore=20 asking for your cooperation in handling (re)naming and submission of=20 these drafts. Previous WG drafts that are currently with IESG should keep their=20 original name draft-ietf-{mip6,nemo,monami6}-* if updates are needed to=20 address IESG comments and discusses: draft-ietf-mip6-bootstrapping-integrated-dhc-05 draft-ietf-mip6-cn-ipsec-06 draft-ietf-mip6-hiopt-08 draft-ietf-mip6-whyauthdataoption-04 Previous WG drafts that we agreed to take as MEXT WG drafts shall be=20 renamed and submitted as draft-ietf-mext-* starting with their next=20 update: draft-ietf-nemo-mib-03=20 draft-ietf-monami6-mipv6-analysis-04 draft-ietf-monami6-multihoming-motivation-scenario-02=20 draft-ietf-monami6-multiplecoa-04=20 draft-ietf-mip6-hareliability-03=20 draft-ietf-mip6-nemo-v4traversal-05=20 draft-ietf-mip6-radius-02=20 Previous WG drafts that the WG hasn't agreed to take as WG drafts, or=20 have no corresponding work item in MEXT charter must not be submitted=20 as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are free to=20 submit them as individual submission, e.g. draft-*-mext-*: draft-ietf-nemo-prefix-delegation draft-ietf-nemo-dhcpv6-pd draft-ietf-mip6-rfc4285bis =A0=A0=A0=A0=A0=A0=A0=A0draft-ietf-mip6-generic-notification-message Thanks in advance. =2D-julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 14:01:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hh3-00081M-Av; Tue, 18 Dec 2007 14:01:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hh1-0007ul-SU for mext@ietf.org; Tue, 18 Dec 2007 14:01:27 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4hh1-0007Pe-Ga for mext@ietf.org; Tue, 18 Dec 2007 14:01:27 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 11:01:23 -0800 Message-ID: <47681903.7040707@azairenet.com> Date: Tue, 18 Dec 2007 11:01:23 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712181623.38497.julien.IETF@laposte.net> In-Reply-To: <200712181623.38497.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 19:01:23.0651 (UTC) FILETIME=[621E1930:01C841A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Julien, Julien Laganier wrote: > Previous WG drafts that the WG hasn't agreed to take as WG drafts, or > have no corresponding work item in MEXT charter must not be submitted > as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are free to > submit them as individual submission, e.g. draft-*-mext-*: > > draft-ietf-nemo-prefix-delegation > draft-ietf-nemo-dhcpv6-pd > draft-ietf-mip6-rfc4285bis 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I thought it was ready for a MIP6 WG last call. Raj, please correct me if I am wrong. I think this document should be a MEXT WG document. Regarding the other changes in the document (for example removing the IESG note) should of course be discussed on the MEXT mailing list. > draft-ietf-mip6-generic-notification-message I thought we concluded we missed this document somehow and needs to be added to the charter? Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 14:15:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4huX-00053S-MI; Tue, 18 Dec 2007 14:15:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4huW-00052X-4T for mext@ietf.org; Tue, 18 Dec 2007 14:15:24 -0500 Received: from wolverine02.qualcomm.com ([199.106.114.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4huV-0007qh-25 for mext@ietf.org; Tue, 18 Dec 2007 14:15:23 -0500 DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:From:To:X-OriginalArrivalTime; b=Ngq8qojIbAwAnqp8r9oQ28cQ9OJTUc5XW/V1kBVSdByTWglWHogtVYAf VHs/OLemLuL0339QHC+5g3NKgDEEo2hZDrDcjJAcGumgpGZqsR7ExPZYO R5Fr0vFrteAGX8LQmNqVeCzN5gEfYM+j0MFVia3+hAhB7znNQm5h3OTkV c=; X-IronPort-AV: E=McAfee;i="5100,188,5187"; a="183371" Received: from ithilien.qualcomm.com ([129.46.51.59]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Dec 2007 11:15:21 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.12.5/1.0) with ESMTP id lBIJFLs7013501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Dec 2007 11:15:21 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id lBIJFI8O005846; Tue, 18 Dec 2007 11:15:20 -0800 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 11:15:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] MEXT WG drafts (re)naming and submission Date: Tue, 18 Dec 2007 11:15:03 -0800 Message-ID: In-Reply-To: <200712181623.38497.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] MEXT WG drafts (re)naming and submission Thread-Index: AchBifbL8G9COG2RRLWt6nT0X1x/3gAID5Cw From: "Giaretta, Gerardo" To: "Julien Laganier" , X-OriginalArrivalTime: 18 Dec 2007 19:15:05.0964 (UTC) FILETIME=[4C411AC0:01C841AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Julien, > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Tuesday, December 18, 2007 7:24 AM > To: mext@ietf.org > Subject: [MEXT] MEXT WG drafts (re)naming and submission >=20 > To all previous WG drafts authors/editors, >=20 > The MEXT WG has automatically inherited all WG drafts from previous = WGs > (MIP6, NEMO, MONAMI6), which isn't what we agreed on. I am therefore > asking for your cooperation in handling (re)naming and submission of > these drafts. >=20 > Previous WG drafts that are currently with IESG should keep their > original name draft-ietf-{mip6,nemo,monami6}-* if updates are needed = to > address IESG comments and discusses: >=20 > draft-ietf-mip6-bootstrapping-integrated-dhc-05 > draft-ietf-mip6-cn-ipsec-06 > draft-ietf-mip6-hiopt-08 > draft-ietf-mip6-whyauthdataoption-04 >=20 > Previous WG drafts that we agreed to take as MEXT WG drafts shall be > renamed and submitted as draft-ietf-mext-* starting with their next > update: >=20 > draft-ietf-nemo-mib-03 > draft-ietf-monami6-mipv6-analysis-04 > draft-ietf-monami6-multihoming-motivation-scenario-02 > draft-ietf-monami6-multiplecoa-04 > draft-ietf-mip6-hareliability-03 > draft-ietf-mip6-nemo-v4traversal-05 > draft-ietf-mip6-radius-02 >=20 Does it apply also to draft-ietf-mip6-aaa-ha-goals? Thanks Gerardo > Previous WG drafts that the WG hasn't agreed to take as WG drafts, or > have no corresponding work item in MEXT charter must not be submitted > as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are free = to > submit them as individual submission, e.g. draft-*-mext-*: >=20 > draft-ietf-nemo-prefix-delegation > draft-ietf-nemo-dhcpv6-pd > draft-ietf-mip6-rfc4285bis > =A0=A0=A0=A0=A0=A0=A0=A0draft-ietf-mip6-generic-notification-message >=20 > Thanks in advance. >=20 > --julien >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 14:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iQZ-0006IZ-Ej; Tue, 18 Dec 2007 14:48:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iQY-0006IM-CR for mext@ietf.org; Tue, 18 Dec 2007 14:48:30 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iQW-0001tZ-PE for mext@ietf.org; Tue, 18 Dec 2007 14:48:30 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBIJlsGb032018; Tue, 18 Dec 2007 21:48:19 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 21:48:03 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 13:47:51 -0600 Received: from 10.138.86.204 ([10.138.86.204]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 18 Dec 2007 19:47:52 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 18 Dec 2007 13:47:51 -0600 Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission From: Basavaraj Patil To: Vijay Devarapalli , Julien Laganier Message-ID: Thread-Topic: [MEXT] MEXT WG drafts (re)naming and submission Thread-Index: AchBrt+BHf0zxK2iEdya4wARJNUNiA== In-Reply-To: <47681903.7040707@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 19:47:51.0599 (UTC) FILETIME=[DFDD33F0:01C841AE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org RFC4285bis is a minor bug fix w.r.t the key length. If MEXT does not want to make this a WG doc, we can maybe progress it as a MIP6 WG doc. It has already completed WG LC in August, 07. Hence I have no problem forwarding it to the IESG for processing as a MIP6 WG doc. -Raj On 12/18/07 1:01 PM, "ext Vijay Devarapalli" wrote: > Hi Julien, > > Julien Laganier wrote: > >> Previous WG drafts that the WG hasn't agreed to take as WG drafts, or >> have no corresponding work item in MEXT charter must not be submitted >> as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are free to >> submit them as individual submission, e.g. draft-*-mext-*: >> >> draft-ietf-nemo-prefix-delegation >> draft-ietf-nemo-dhcpv6-pd >> draft-ietf-mip6-rfc4285bis > > 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I thought > it was ready for a MIP6 WG last call. Raj, please correct me if I am > wrong. I think this document should be a MEXT WG document. > > Regarding the other changes in the document (for example removing the > IESG note) should of course be discussed on the MEXT mailing list. > >> draft-ietf-mip6-generic-notification-message > > I thought we concluded we missed this document somehow and needs to be > added to the charter? > > Vijay > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 14:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iUn-0007lq-3v; Tue, 18 Dec 2007 14:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iUl-0007lX-C1 for mext@ietf.org; Tue, 18 Dec 2007 14:52:51 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iUk-000227-Vi for mext@ietf.org; Tue, 18 Dec 2007 14:52:51 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 11:52:50 -0800 Message-ID: <47682512.80705@azairenet.com> Date: Tue, 18 Dec 2007 11:52:50 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 19:52:50.0490 (UTC) FILETIME=[920459A0:01C841AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Basavaraj Patil wrote: > RFC4285bis is a minor bug fix w.r.t the key length. > If MEXT does not want to make this a WG doc, we can maybe progress it as a > MIP6 WG doc. > It has already completed WG LC in August, 07. > Hence I have no problem forwarding it to the IESG for processing as a MIP6 > WG doc. Ok, then it was just waiting for the document shepherd writeup. Now I don't see any reason for this to be published as an individual submission. Vijay > > -Raj > > > On 12/18/07 1:01 PM, "ext Vijay Devarapalli" > wrote: > >> Hi Julien, >> >> Julien Laganier wrote: >> >>> Previous WG drafts that the WG hasn't agreed to take as WG drafts, or >>> have no corresponding work item in MEXT charter must not be submitted >>> as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are free to >>> submit them as individual submission, e.g. draft-*-mext-*: >>> >>> draft-ietf-nemo-prefix-delegation >>> draft-ietf-nemo-dhcpv6-pd >>> draft-ietf-mip6-rfc4285bis >> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I thought >> it was ready for a MIP6 WG last call. Raj, please correct me if I am >> wrong. I think this document should be a MEXT WG document. >> >> Regarding the other changes in the document (for example removing the >> IESG note) should of course be discussed on the MEXT mailing list. >> >>> draft-ietf-mip6-generic-notification-message >> I thought we concluded we missed this document somehow and needs to be >> added to the charter? >> >> Vijay >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Dec 18 14:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iWA-0000z7-Pv; Tue, 18 Dec 2007 14:54:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4iWA-0000yo-53 for mext@ietf.org; Tue, 18 Dec 2007 14:54:18 -0500 Received: from g1t0026.austin.hp.com ([15.216.28.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4iW9-00024f-Og for mext@ietf.org; Tue, 18 Dec 2007 14:54:18 -0500 Received: from g1t0026.austin.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 5CE57C3D3; Tue, 18 Dec 2007 19:54:17 +0000 (UTC) Received: from smtp2.fc.hp.com (smtp.fc.hp.com [15.11.136.114]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 15BCDC34C; Tue, 18 Dec 2007 19:54:16 +0000 (UTC) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp2.fc.hp.com (Postfix) with ESMTP id 7ADC1249AC7; Tue, 18 Dec 2007 19:52:20 +0000 (UTC) Message-ID: <476824F3.7040901@hp.com> Date: Tue, 18 Dec 2007 14:52:19 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712181623.38497.julien.IETF@laposte.net> <47681903.7040707@azairenet.com> In-Reply-To: <47681903.7040707@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mext@ietf.org, Julien Laganier X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay Devarapalli wrote: > Regarding the other changes in the document (for example removing the > IESG note) should of course be discussed on the MEXT mailing list. > >> draft-ietf-mip6-generic-notification-message > > I thought we concluded we missed this document somehow and needs to be > added to the charter? That's what my mental note says as well. The poll from the minutes had: > - Generic Notification Message for Mobile IPv6 > > For: ~15 > Against: ~0 so it clearly wasn't opposed. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From MarciebrillouinRagland@mandate.com Tue Dec 18 16:51:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kLl-00039w-V0; Tue, 18 Dec 2007 16:51:41 -0500 Received: from pool-72-88-48-97.bflony.east.verizon.net ([72.88.48.97] helo=samanthasroom.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4kLl-0008LL-MC; Tue, 18 Dec 2007 16:51:41 -0500 Received: from island by mandate.com with SMTP id AkE4aNRmMH for ; Tue, 18 Dec 2007 16:51:41 +0500 From: "Louisa Nava" To: Subject: We give out BONUSES to anyone who joins. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de After thatit's only fun and winning. Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. After thatit's only fun and winning. Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. http://eurocasinoac.com/ From MarilynimprimaturDye@iamthebeatles.com Wed Dec 19 03:19:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4u9V-0002Bu-EL; Wed, 19 Dec 2007 03:19:41 -0500 Received: from [85.106.230.78] (helo=feardot.elkotek) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4u9U-0000Nx-PH; Wed, 19 Dec 2007 03:19:41 -0500 Received: from many by iamthebeatles.com with SMTP id tib5JIlqZN for ; Wed, 19 Dec 2007 10:19:16 -0200 From: "Kelly Villa" To: Subject: Multi-hand and single-hand blackjack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Travel no further than your screen and get your free $999 Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. Come see what it means to be a VIP. Play your favorite games and get $999 welcome bonus. http://eurocasinoac.com/ From mext-bounces@ietf.org Wed Dec 19 03:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ujf-0003Yp-1J; Wed, 19 Dec 2007 03:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ujd-0003TU-2g for mext@ietf.org; Wed, 19 Dec 2007 03:57:01 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ujc-0006gV-4s for mext@ietf.org; Wed, 19 Dec 2007 03:57:00 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1381356nfb.39 for ; Wed, 19 Dec 2007 00:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=SIPO0BUmbHIbph9BAeI0ygPa1KW8iQhNz3EJSBaknNs=; b=ZrzTiCpcLP81IcfItkE3sU6vM3EiQHpiM/Dhcm7oCt8clW5KYO3AKMnR+2ZqhJvbl901EsKll02/lNYQ7ZqZaTKgUF0e7kUyoCgYbVjI9VNmtxOdH/YjwE6xcuI1rncGdHkKT0XIeCW4OeR4N7ePtaMOYWyvr4UZtFzVm1d0I6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=KU8zD/lT654gDg890CuJb1JRpm95YuO9veVz98w4Mj/y09LtnMNwCfiEIG+Ttc8c+q1q2Jwc4huHF4De31TqiD3YRysF/6mqzLPcEKknD9m+/+cXmGepq1plUvioquc+zjBOJg+IGA2SeAYTYPTijPXkbNZb5MohaJ+cpglNzZE= Received: by 10.78.145.14 with SMTP id s14mr11703920hud.58.1198054618622; Wed, 19 Dec 2007 00:56:58 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f7sm1848130nfh.2007.12.19.00.56.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 00:56:51 -0800 (PST) From: Julien Laganier To: Vijay Devarapalli Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 09:57:20 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712181623.38497.julien.IETF@laposte.net> <47681903.7040707@azairenet.com> In-Reply-To: <47681903.7040707@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712190957.21450.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vijay, On Tuesday 18 December 2007, Vijay Devarapalli wrote: > > Julien Laganier wrote: > > Previous WG drafts that the WG hasn't agreed to take as WG drafts, > > or have no corresponding work item in MEXT charter must not be > > submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course > > authors are free to submit them as individual submission, e.g. > > draft-*-mext-*: > > > > draft-ietf-nemo-prefix-delegation > > draft-ietf-nemo-dhcpv6-pd > > draft-ietf-mip6-rfc4285bis > > 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I > thought it was ready for a MIP6 WG last call. Raj, please correct me > if I am wrong. I think this document should be a MEXT WG document. This is the MEXT WG and we are not chartered to work on maintaining 4285, thus I think this should not be a MEXT WG document. If the WG agrees to include 4285bis as part of our rechartering, and our new charter is approved, then of course it is fine that 4285bis becomes a MEXT WG draft. > Regarding the other changes in the document (for example removing the > IESG note) should of course be discussed on the MEXT mailing list. > > > draft-ietf-mip6-generic-notification-message > > I thought we concluded we missed this document somehow and needs to > be added to the charter? I wasn't making a statement on the rechartering aspect, just saying it's currently not in MEXT charter and should thus not be a MEXT WG draft (until it's in an approved new MEXT charter). Best, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 03:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ukg-0001WL-8l; Wed, 19 Dec 2007 03:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4uke-00014g-1h for mext@ietf.org; Wed, 19 Dec 2007 03:58:04 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ukd-0006iM-Ov for mext@ietf.org; Wed, 19 Dec 2007 03:58:04 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1381546nfb.39 for ; Wed, 19 Dec 2007 00:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=3nvNvXj9sDJIeakJLDuSlpbUHUtbYhjIrrf5PhfZT6g=; b=p53IoLQFNHvMrpmKVA3baU3BynenM9yURAdskGVnY2psiEV51F5mm6HF2hlCyhU033wX/t7jBNp8HfqKGtXR5KHGuTSHf7EDCQc+5bvDIw9KIOmyFcd19hgN/a8BOKhTJ0G+Ki6eWxK0YTV2ly4Dj9hLwW0nNWowqtiveBCFR7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ae3zMb8IFOh/BbaE1uVcDcV8hDhOqVLasruITMa0OIahc8QREn9dj0lNewoUPWftUHKbQjvTYTHgVvtcGytanb0QDa7/9oq89W2hiIpVdRv9ggoLDx1zsyNo6qljB5tHWRql5E+gP+eYGWRw2dqLefZLrHMk1LpDG5qri8tL/Gc= Received: by 10.78.205.7 with SMTP id c7mr11715944hug.29.1198054682384; Wed, 19 Dec 2007 00:58:02 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id h7sm2148939nfh.2007.12.19.00.58.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 00:58:00 -0800 (PST) From: Julien Laganier To: "Giaretta, Gerardo" Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 09:58:31 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712190958.31791.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Gerardo, On Tuesday 18 December 2007, Giaretta, Gerardo wrote: > > > > > Previous WG drafts that we agreed to take as MEXT WG drafts shall > > be renamed and submitted as draft-ietf-mext-* starting with their > > next update: > > > > draft-ietf-nemo-mib-03 > > draft-ietf-monami6-mipv6-analysis-04 > > draft-ietf-monami6-multihoming-motivation-scenario-02 > > draft-ietf-monami6-multiplecoa-04 > > draft-ietf-mip6-hareliability-03 > > draft-ietf-mip6-nemo-v4traversal-05 > > draft-ietf-mip6-radius-02 > > Does it apply also to draft-ietf-mip6-aaa-ha-goals? Yes, I missed that one. Thanks for catching this. Best, --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 04:02:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4uor-0007r8-TC; Wed, 19 Dec 2007 04:02:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4uor-0007r2-5d for mext@ietf.org; Wed, 19 Dec 2007 04:02:25 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4uop-0001RB-8p for mext@ietf.org; Wed, 19 Dec 2007 04:02:25 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1382000nfb.39 for ; Wed, 19 Dec 2007 01:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=+lNQxEkMs2xfpSz+Vjsi3b4Npr79auCnkwe+eItfh6g=; b=NyPx+4OW/CrZgPfOfSbftkacUkjWZI4QRN3TFTCswTIXokz3B4IfPipnz/BjE4Is3rajiSuOACkv4Ujg/JeIkO0v6IFBZw5bY/ZCRIkx4jXzvxwXxnqbhY62ZlcabGhz+46my+2C5iinyzA4KoRyDiN51/coamfOY24voG8jG6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=FBb/0G7V6oDe7U/0e9HKY6M1dlKJAzA8udsvjRH4XRUP6Iz076kcjKDuVCWddplhoKzPcjhQRJl4tqTm1GZvr2h/ttZ9QIizdgTDyp0dQzVY0smNGAm/QoeE97kqpa+1avhTThq7kVM9SRRLzFvdbYGGS2CIqOwMQh51JmLeI24= Received: by 10.78.206.9 with SMTP id d9mr11752232hug.9.1198054938988; Wed, 19 Dec 2007 01:02:18 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id c4sm2171213nfi.2007.12.19.01.02.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 01:02:16 -0800 (PST) From: Julien Laganier To: Basavaraj Patil Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 10:02:46 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712191002.47334.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Raj, MEXT WG should work on items it is chartered to work on. 4285bis is clearly not included in our current charter, thus it shouldn't be a MEXT WG document. MEXT wise, a way forward is to include 4285bis as part of our rechartering. --julien On Tuesday 18 December 2007, Basavaraj Patil wrote: > RFC4285bis is a minor bug fix w.r.t the key length. > If MEXT does not want to make this a WG doc, we can maybe progress it > as a MIP6 WG doc. > It has already completed WG LC in August, 07. > Hence I have no problem forwarding it to the IESG for processing as a > MIP6 WG doc. > > -Raj > > > On 12/18/07 1:01 PM, "ext Vijay Devarapalli" > > wrote: > > Hi Julien, > > > > Julien Laganier wrote: > >> Previous WG drafts that the WG hasn't agreed to take as WG drafts, > >> or have no corresponding work item in MEXT charter must not be > >> submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course > >> authors are free to submit them as individual submission, e.g. > >> draft-*-mext-*: > >> > >> draft-ietf-nemo-prefix-delegation > >> draft-ietf-nemo-dhcpv6-pd > >> draft-ietf-mip6-rfc4285bis > > > > 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I > > thought it was ready for a MIP6 WG last call. Raj, please correct > > me if I am wrong. I think this document should be a MEXT WG > > document. > > > > Regarding the other changes in the document (for example removing > > the IESG note) should of course be discussed on the MEXT mailing > > list. > > > >> draft-ietf-mip6-generic-notification-message > > > > I thought we concluded we missed this document somehow and needs to > > be added to the charter? > > > > Vijay > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 04:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vA6-0005e4-7u; Wed, 19 Dec 2007 04:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vA5-0005dz-E3 for mext@ietf.org; Wed, 19 Dec 2007 04:24:21 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4vA3-0007OF-M2 for mext@ietf.org; Wed, 19 Dec 2007 04:24:21 -0500 X-IronPort-AV: E=Sophos;i="4.24,183,1196636400"; d="vcf'?scan'208";a="20499284" Received: from dhcp-rocq-52.inria.fr ([128.93.62.52]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2007 10:24:19 +0100 Message-ID: <4768E33C.1040305@inria.fr> Date: Wed, 19 Dec 2007 10:24:12 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mext@ietf.org, Jari Arkko Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712191002.47334.julien.IETF@laposte.net> In-Reply-To: <200712191002.47334.julien.IETF@laposte.net> Content-Type: multipart/mixed; boundary="------------090108020204000808050804" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------090108020204000808050804 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Well, there are documents in the former WGs which may have been accepted as WG docs AFTER the MEXT charter was first drafted. If that was the case (i.e. the document was accepted by the WG and the AD, and listed as draft-ietf- on the WG charter), MEXT should inherit the document too... (the doc was anyway accepted at some point in time; it doesn't matter much if that was during the MEXT chartering process or the MIP6, NEMO or MonAmi6 process. The same applies for a document for which a WG may have decided to drop it for some reasons. Jari, please inlight us about the procedure here. The same reasoning applies to the NEMO Prefix Delegation draft. However, the discussion we had on the list and during the WG seems to indicate that the 2 current solutions didn't receive enough feedback in the past, and there may be other ways. So, in that specific case, it is useful to reconsider the document (but the 2 were accepted as NEMO WG docs some time in the past). Thierry Julien Laganier wrote: > Hi Raj, > > MEXT WG should work on items it is chartered to work on. 4285bis is > clearly not included in our current charter, thus it shouldn't be a > MEXT WG document. > > MEXT wise, a way forward is to include 4285bis as part of our > rechartering. > > --julien > > On Tuesday 18 December 2007, Basavaraj Patil wrote: >> RFC4285bis is a minor bug fix w.r.t the key length. >> If MEXT does not want to make this a WG doc, we can maybe progress it >> as a MIP6 WG doc. >> It has already completed WG LC in August, 07. >> Hence I have no problem forwarding it to the IESG for processing as a >> MIP6 WG doc. >> >> -Raj >> >> >> On 12/18/07 1:01 PM, "ext Vijay Devarapalli" >> >> wrote: >>> Hi Julien, >>> >>> Julien Laganier wrote: >>>> Previous WG drafts that the WG hasn't agreed to take as WG drafts, >>>> or have no corresponding work item in MEXT charter must not be >>>> submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course >>>> authors are free to submit them as individual submission, e.g. >>>> draft-*-mext-*: >>>> >>>> draft-ietf-nemo-prefix-delegation >>>> draft-ietf-nemo-dhcpv6-pd >>>> draft-ietf-mip6-rfc4285bis >>> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I >>> thought it was ready for a MIP6 WG last call. Raj, please correct >>> me if I am wrong. I think this document should be a MEXT WG >>> document. >>> >>> Regarding the other changes in the document (for example removing >>> the IESG note) should of course be discussed on the MEXT mailing >>> list. >>> >>>> draft-ietf-mip6-generic-notification-message >>> I thought we concluded we missed this document somehow and needs to >>> be added to the charter? >>> >>> Vijay >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext --------------090108020204000808050804 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------090108020204000808050804 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------090108020204000808050804-- From mext-bounces@ietf.org Wed Dec 19 04:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vFg-0003WO-HK; Wed, 19 Dec 2007 04:30:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vFf-0003WJ-Em for mext@ietf.org; Wed, 19 Dec 2007 04:30:07 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4vFf-0007V4-3v for mext@ietf.org; Wed, 19 Dec 2007 04:30:07 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1385775nfb.39 for ; Wed, 19 Dec 2007 01:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Z6aLjnx+3uZgjAbYVZbLp3Lp33BVWRN8UeL/jbnWDKk=; b=m5Ict+z/ZolUwcglUmmTfBFH6KZZGk8yvjMh3kEAAv+dwZIy49otIVirc/QTlRq3ZdPQkUlubloewBsEj91UP4MU47iSiHD/qpPvha7ODGL44Nu2exUKGl1CjhMFLY+W+PR7kP8YJ1GLomMxVAy77Ud5sSq1l5qRjjmtlHfCabA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=gl8s4Xz+srI1w9kyQY1t0aJ544Ryk5HWP4ADrPZi3XMpWHkeOwDf8KR0y8ayXp46WeJKVu2n8jX5Mtp5mzDg3/P7xXC4tDvDk+RkIyAll8yuLGgW7QT+/EaC+dR7CRNRfH2RHHnUhVm0bqzVStDrsbxfoJM5iIb7aT29Plq0hYQ= Received: by 10.78.147.6 with SMTP id u6mr375413hud.78.1198056605640; Wed, 19 Dec 2007 01:30:05 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d26sm2400830nfh.2007.12.19.01.30.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 01:30:04 -0800 (PST) From: Julien Laganier To: Brian Haley Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 10:30:24 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712181623.38497.julien.IETF@laposte.net> <47681903.7040707@azairenet.com> <476824F3.7040901@hp.com> In-Reply-To: <476824F3.7040901@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712191030.26112.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Brian, On Tuesday 18 December 2007, Brian Haley wrote: > Vijay Devarapalli wrote: > > Regarding the other changes in the document (for example removing > > the IESG note) should of course be discussed on the MEXT mailing > > list. > > > >> draft-ietf-mip6-generic-notification-message > > > > I thought we concluded we missed this document somehow and needs to > > be added to the charter? > > That's what my mental note says as well. The poll from the minutes had: > > - Generic Notification Message for Mobile IPv6 > > > > For: ~15 > > Against: ~0 > > so it clearly wasn't opposed. Nobody said the WG was opposed. I just said we're not chartered to work on a generic notification message (GMN) and thus the above draft shouldn't be a WG draft. W.r.t. to the poll we did last meeting, it gives an *indication* of how much support there is in the meeting attendees to include GMN in our new charter proposal. We should not presume anything w.r.t. the WG consensus on including GMN in a new charter proposal and/or whether the new charter proposal we come up with will be approved. I suggest the way forward is to discuss on the mailing list whether or not there is WG consensus to include GMN in a new charter proposal. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 04:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vKi-0006Yp-Ir; Wed, 19 Dec 2007 04:35:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vKg-0006Yf-Eh for mext@ietf.org; Wed, 19 Dec 2007 04:35:18 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4vKg-00028n-28 for mext@ietf.org; Wed, 19 Dec 2007 04:35:18 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1386246nfb.39 for ; Wed, 19 Dec 2007 01:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=HPz1qUonKQFv1klZrDesgslEnNl+Od3WZk9//tAmuaU=; b=xNAqEv0JFjtSvflod/0UzLejC073yJvpXaKGjbw6EYlAXfpq4kXrsk8tg5hVSu8LfH6kgW0akQ7nBdFgyQBBY7XAk6w1Ex0vA8ESXCjphnJt7VW6pAzmk5g+lGLm8DNEjC7CQr0Y5s70P/Xzl6XUUegrMGXmTXgKBadmHPzDVYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XAEmoyMqaclPtpUvbnD2C62DbRIXaLRuDyu3mjQ8H9vorhaqWMzOPOisQ78/7QaB4BKcq2dYvWJNMzLULn79IAPdr3pP7mUXngKmUZm0vujoXE7DoaoIIZfbqTQdbHI4e7AyqJtGyOpob8U7Fob+2rZb1DxejupX16QX5xdBsSk= Received: by 10.78.122.16 with SMTP id u16mr7440421huc.21.1198056916923; Wed, 19 Dec 2007 01:35:16 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d26sm2433313nfh.2007.12.19.01.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 01:35:15 -0800 (PST) From: Julien Laganier To: Vijay Devarapalli Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 10:35:46 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <47682512.80705@azairenet.com> In-Reply-To: <47682512.80705@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712191035.47068.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay, On Tuesday 18 December 2007, Vijay Devarapalli wrote: > Basavaraj Patil wrote: > > RFC4285bis is a minor bug fix w.r.t the key length. > > If MEXT does not want to make this a WG doc, we can maybe progress > > it as a MIP6 WG doc. > > It has already completed WG LC in August, 07. > > Hence I have no problem forwarding it to the IESG for processing as > > a MIP6 WG doc. > > Ok, then it was just waiting for the document shepherd writeup. > Now I don't see any reason for this to be published as an > individual submission. I'm not sure whether or not there are reasons to publish 4285bis as individual. I'm sure that until we got an approved charter that includes 4285bis there are reasons why 4285 bis should not be published as an output of the MEXT WG. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 04:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vY8-0005Mk-Np; Wed, 19 Dec 2007 04:49:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4vY6-0005Bz-Mv for mext@ietf.org; Wed, 19 Dec 2007 04:49:10 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4vY5-0002cT-TS for mext@ietf.org; Wed, 19 Dec 2007 04:49:10 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1387599nfb.39 for ; Wed, 19 Dec 2007 01:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=6wED8ki8/uFLSOTo04ZgtJHjD2BnCAekjwO485//VvQ=; b=uSh0x3ars6mUqjDiL6jKnKw2JppejA/mXjPVRFHuSxh7qsJQTtOEL858oquyXtarq0lUBUm5ZsOFy7zvVpUi7zePGquVwOBR6+dduG7E4oi1THuoR8eUWx5mXhzP+DP3FsCbQtTX9rqLmPB6dJ7Rg/JUGfmC5klJ9+jHyxp1rbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=L7fISo/tyX0eYZKTsd8nGVjbp1IFCsTf/Qi1y4O6KyVArGIHlVy0O5Sy+/ZdNSi9jrJF8N3i2Nu5uZp9njfEVyFshyrnph33tKc486Z51MXO6WsuTpxFMf5eKgt/gR8TUfJbKy3PfnR1Yg6htQxi2RXrMws6hIwP1J+Ie7uGnxY= Received: by 10.78.188.10 with SMTP id l10mr11804071huf.14.1198057748617; Wed, 19 Dec 2007 01:49:08 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k9sm2477693nfh.2007.12.19.01.49.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 01:49:07 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 10:49:34 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712191002.47334.julien.IETF@laposte.net> <4768E33C.1040305@inria.fr> In-Reply-To: <4768E33C.1040305@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712191049.36334.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Thierry, On Wednesday 19 December 2007, Thierry Ernst wrote: > Well, there are documents in the former WGs which may have been > accepted as WG docs AFTER the MEXT charter was first drafted. If that > was the case (i.e. the document was accepted by the WG and the AD, > and listed as draft-ietf- on the WG charter), MEXT should inherit the > document too... (the doc was anyway accepted at some point in time; > it doesn't matter much if that was during the MEXT chartering process > or the MIP6, NEMO or MonAmi6 process. The same applies for a document > for which a WG may have decided to drop it for some reasons. This is exactly what happened, with one motivated exception (see below): any WG draft of a former WG which has a corresponding deliverable in our charter was taken as a MEXT WG draft (see mails we chairs have been sending). The single exception that rule pertains to prefix delegation for NEMO. Our charter has only one deliverable for a NEMO prefix delegation mechanism, but there were two NEMO WG drafts related to that. We decided that since there's no clear consensus for any of the two solutions, we will not adopt *yet* any of them, and rather wait for the WG to gain consensus on *one* prefix delegation mechanism, at which point we adopt the corresponding draft. The above exception is well motivated: we as a WG should follow our charter. > Jari, please inlight us about the procedure here. > > The same reasoning applies to the NEMO Prefix Delegation draft. > However, the discussion we had on the list and during the WG seems to > indicate that the 2 current solutions didn't receive enough feedback > in the past, and there may be other ways. So, in that specific case, > it is useful to reconsider the document (but the 2 were accepted as > NEMO WG docs some time in the past). See above. Seems to me that you should be satisfied about the current situation. Best, --julien > Julien Laganier wrote: > > Hi Raj, > > > > MEXT WG should work on items it is chartered to work on. 4285bis is > > clearly not included in our current charter, thus it shouldn't be a > > MEXT WG document. > > > > MEXT wise, a way forward is to include 4285bis as part of our > > rechartering. > > > > --julien > > > > On Tuesday 18 December 2007, Basavaraj Patil wrote: > >> RFC4285bis is a minor bug fix w.r.t the key length. > >> If MEXT does not want to make this a WG doc, we can maybe progress > >> it as a MIP6 WG doc. > >> It has already completed WG LC in August, 07. > >> Hence I have no problem forwarding it to the IESG for processing > >> as a MIP6 WG doc. > >> > >> -Raj > >> > >> > >> On 12/18/07 1:01 PM, "ext Vijay Devarapalli" > >> > >> wrote: > >>> Hi Julien, > >>> > >>> Julien Laganier wrote: > >>>> Previous WG drafts that the WG hasn't agreed to take as WG > >>>> drafts, or have no corresponding work item in MEXT charter must > >>>> not be submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of > >>>> course authors are free to submit them as individual submission, > >>>> e.g. draft-*-mext-*: > >>>> > >>>> draft-ietf-nemo-prefix-delegation > >>>> draft-ietf-nemo-dhcpv6-pd > >>>> draft-ietf-mip6-rfc4285bis > >>> > >>> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I > >>> thought it was ready for a MIP6 WG last call. Raj, please correct > >>> me if I am wrong. I think this document should be a MEXT WG > >>> document. > >>> > >>> Regarding the other changes in the document (for example removing > >>> the IESG note) should of course be discussed on the MEXT mailing > >>> list. > >>> > >>>> draft-ietf-mip6-generic-notification-message > >>> > >>> I thought we concluded we missed this document somehow and needs > >>> to be added to the charter? > >>> > >>> Vijay > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 07:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yKA-0002QJ-1Z; Wed, 19 Dec 2007 07:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4yK8-0002QC-1W for mext@ietf.org; Wed, 19 Dec 2007 07:46:56 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4yK5-0004J3-HB for mext@ietf.org; Wed, 19 Dec 2007 07:46:56 -0500 X-IronPort-AV: E=Sophos;i="4.24,184,1196636400"; d="vcf'?scan'208";a="20510814" Received: from dhcp-rocq-52.inria.fr ([128.93.62.52]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2007 13:46:52 +0100 Message-ID: <476912B6.3070702@inria.fr> Date: Wed, 19 Dec 2007 13:46:46 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mext@ietf.org Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712191002.47334.julien.IETF@laposte.net> <4768E33C.1040305@inria.fr> <200712191049.36334.julien.IETF@laposte.net> In-Reply-To: <200712191049.36334.julien.IETF@laposte.net> Content-Type: multipart/mixed; boundary="------------030406040705030204000007" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------030406040705030204000007 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Julien, > On Wednesday 19 December 2007, Thierry Ernst wrote: >> Well, there are documents in the former WGs which may have been >> accepted as WG docs AFTER the MEXT charter was first drafted. If that >> was the case (i.e. the document was accepted by the WG and the AD, >> and listed as draft-ietf- on the WG charter), MEXT should inherit the >> document too... (the doc was anyway accepted at some point in time; >> it doesn't matter much if that was during the MEXT chartering process >> or the MIP6, NEMO or MonAmi6 process. The same applies for a document >> for which a WG may have decided to drop it for some reasons. > > This is exactly what happened, with one motivated exception (see below): > any WG draft of a former WG which has a corresponding deliverable in > our charter was taken as a MEXT WG draft (see mails we chairs have been > sending). > > The single exception that rule pertains to prefix delegation for NEMO. > Our charter has only one deliverable for a NEMO prefix delegation > mechanism, but there were two NEMO WG drafts related to that. We > decided that since there's no clear consensus for any of the two > solutions, we will not adopt *yet* any of them, and rather wait for the > WG to gain consensus on *one* prefix delegation mechanism, at which > point we adopt the corresponding draft. Agreed but a proper wording would read "We decided to remove the current NEMO prefix delegation drafts as WG items since there is no clear consensus for any of the two adopted solutions" since drafts WERE WG items. > The above exception is well motivated: we as a WG should follow our > charter. I would just like to make sure that former decisions are deprecated correctly (to me, MEXT is not a new group, it inherits from MIP6, NEMO and MonAmi6 so former charters and conclusions should be taken into account). So, if there was an item in the former group charter, and that item has just been incidently removed or wrongly worded while drafting the MEXT charter, we should not simply stick to "the MEXT charter says that" but the history. >> Jari, please inlight us about the procedure here. >> >> The same reasoning applies to the NEMO Prefix Delegation draft. >> However, the discussion we had on the list and during the WG seems to >> indicate that the 2 current solutions didn't receive enough feedback >> in the past, and there may be other ways. So, in that specific case, >> it is useful to reconsider the document (but the 2 were accepted as >> NEMO WG docs some time in the past). > > See above. Seems to me that you should be satisfied about the current > situation. I'm satisfied with the "We decided to remove the current NEMO prefix delegation drafts as WG items since there is no clear consensus for any of the two adopted solutions" but not with "we will not adopt *yet* any of them" (the draft was already adopted). Thierry. > Best, > > --julien > >> Julien Laganier wrote: >>> Hi Raj, >>> >>> MEXT WG should work on items it is chartered to work on. 4285bis is >>> clearly not included in our current charter, thus it shouldn't be a >>> MEXT WG document. >>> >>> MEXT wise, a way forward is to include 4285bis as part of our >>> rechartering. >>> >>> --julien >>> >>> On Tuesday 18 December 2007, Basavaraj Patil wrote: >>>> RFC4285bis is a minor bug fix w.r.t the key length. >>>> If MEXT does not want to make this a WG doc, we can maybe progress >>>> it as a MIP6 WG doc. >>>> It has already completed WG LC in August, 07. >>>> Hence I have no problem forwarding it to the IESG for processing >>>> as a MIP6 WG doc. >>>> >>>> -Raj >>>> >>>> >>>> On 12/18/07 1:01 PM, "ext Vijay Devarapalli" >>>> >>>> wrote: >>>>> Hi Julien, >>>>> >>>>> Julien Laganier wrote: >>>>>> Previous WG drafts that the WG hasn't agreed to take as WG >>>>>> drafts, or have no corresponding work item in MEXT charter must >>>>>> not be submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of >>>>>> course authors are free to submit them as individual submission, >>>>>> e.g. draft-*-mext-*: >>>>>> >>>>>> draft-ietf-nemo-prefix-delegation >>>>>> draft-ietf-nemo-dhcpv6-pd >>>>>> draft-ietf-mip6-rfc4285bis >>>>> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I >>>>> thought it was ready for a MIP6 WG last call. Raj, please correct >>>>> me if I am wrong. I think this document should be a MEXT WG >>>>> document. >>>>> >>>>> Regarding the other changes in the document (for example removing >>>>> the IESG note) should of course be discussed on the MEXT mailing >>>>> list. >>>>> >>>>>> draft-ietf-mip6-generic-notification-message >>>>> I thought we concluded we missed this document somehow and needs >>>>> to be added to the charter? >>>>> >>>>> Vijay >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mext >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext --------------030406040705030204000007 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA Rocquencourt;IMARA - LARA adr:;;;;;;France tel;work:+33 1 39 63 59 30 tel;fax:+33 1 39 63 54 91 url:http://www.lara.prd.fr version:2.1 end:vcard --------------030406040705030204000007 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --------------030406040705030204000007-- From MatildafawnOtto@ifla.org Wed Dec 19 08:37:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4z6o-0000ix-RC; Wed, 19 Dec 2007 08:37:14 -0500 Received: from 84.124.229.52.dyn.user.ono.com ([84.124.229.52] helo=fer9106fdbdb78) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J4z6o-0001it-77; Wed, 19 Dec 2007 08:37:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host64193640.ifla.org (8.13.1/8.13.1) with SMTP id I2GYiQOd69.989301.zdf.AvQ.6811042905988 for ; Wed, 19 Dec 2007 14:36:44 -0100 Message-ID: <23f1001c84244$415e7d60$34e57c54@fer9106fdbdb78> From: "Georgina Dugan" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_23F0C_01C84244.415C0C60-- From mext-bounces@ietf.org Wed Dec 19 09:30:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zvo-0001uf-0C; Wed, 19 Dec 2007 09:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zvm-0001uO-U7 for mext@ietf.org; Wed, 19 Dec 2007 09:29:54 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zvm-00075n-33 for mext@ietf.org; Wed, 19 Dec 2007 09:29:54 -0500 Received: by an-out-0708.google.com with SMTP id d11so851371and.122 for ; Wed, 19 Dec 2007 06:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=1TuV08DuV9HaVS/OPYpdg+RMSG0DE2GGDev8BU6f4Fs=; b=EVlzCCOq7GvNgJWExhKXQ9hdMscZ1mlllpFVCnWpgeMqJ6b2byQyY8Kp48zA7Z8m5hpm9jii4aSS/GO4zaLq3JKI3sqbVJp0qJzyfZRYkcswMMgf4W0E4vA+xrwcwpukRRUnNpnlhg+JwmkKXGLrr7xtuEXeW4KpwIbZUFCIK5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=nLZqJPEw5hafmlDV0++QOiX6m3Hz0nkzH5elWOmjhQq7KFJnGClW0tBb9jFvCy3RTkfq3fgB1c1jYKfKylR4EkoqPs7X89/PpacgWjR9l8WYIZpUivkkfsZtmGIz/wLdR7i/p5Osknvx5iqA+r4ymTWlHSzJrPzbLTaTDFRo/9I= Received: by 10.100.111.5 with SMTP id j5mr20361813anc.97.1198074593628; Wed, 19 Dec 2007 06:29:53 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id f7sm614376nfh.2007.12.19.06.29.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 06:29:51 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Wed, 19 Dec 2007 15:30:15 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712191049.36334.julien.IETF@laposte.net> <476912B6.3070702@inria.fr> In-Reply-To: <476912B6.3070702@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712191530.17909.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Thierry, While I'm sympathetic to your view that "MEXT is not a new group, it inherits from MIP6, NEMO and MonAmi6 so former charters and conclusions should be taken into account", let me point out that we are ultimately bound by our charter and IETF processes, i.e. documented WG rules and guidelines. There would be no formal basis to do otherwise. MEXT is a WG on its own with its own charter, and should abide by it. We are currently in the process of revising our charter, and I encourage anyone to put forth items they think are missing. Once we agree on a revised charter that can be sent to IESG for approval and that charter is approved the WG will be in position to adopt drafts. The situation with NEMO prefix delegation drafts is however different since we are chartered to develop *one* solution. That mean we'll have to make a choice sooner or later. It is somehat orthogonal to that choice itself whether we adopt both drafts now and decide later which one gets sent to IESG, or whether we choose now one and adopt it as WG draft. Let me suggest that it is better to decide sooner so that we can concentrate on one draft that will be one of the output of this WG. Regarding the explanation why MEXT is not adopting any of the two drafts yet, I don't care too much and am satisfied with either your or my explanation. Now we can argue about that and also about adopting both, but maybe we'd be better working on NEMO prefix delegation :) Best, --julien On Wednesday 19 December 2007, Thierry Ernst wrote: > Hi Julien, > > > On Wednesday 19 December 2007, Thierry Ernst wrote: > >> Well, there are documents in the former WGs which may have been > >> accepted as WG docs AFTER the MEXT charter was first drafted. If > >> that was the case (i.e. the document was accepted by the WG and > >> the AD, and listed as draft-ietf- on the WG charter), MEXT should > >> inherit the document too... (the doc was anyway accepted at some > >> point in time; it doesn't matter much if that was during the MEXT > >> chartering process or the MIP6, NEMO or MonAmi6 process. The same > >> applies for a document for which a WG may have decided to drop it > >> for some reasons. > > > > This is exactly what happened, with one motivated exception (see > > below): any WG draft of a former WG which has a corresponding > > deliverable in our charter was taken as a MEXT WG draft (see mails > > we chairs have been sending). > > > > The single exception that rule pertains to prefix delegation for > > NEMO. Our charter has only one deliverable for a NEMO prefix > > delegation mechanism, but there were two NEMO WG drafts related to > > that. We decided that since there's no clear consensus for any of > > the two solutions, we will not adopt *yet* any of them, and rather > > wait for the WG to gain consensus on *one* prefix delegation > > mechanism, at which point we adopt the corresponding draft. > > Agreed but a proper wording would read "We decided to remove the > current NEMO prefix delegation drafts as WG items since there is no > clear consensus for any of the two adopted solutions" since drafts > WERE WG items. > > > The above exception is well motivated: we as a WG should follow our > > charter. > > I would just like to make sure that former decisions are deprecated > correctly (to me, MEXT is not a new group, it inherits from MIP6, > NEMO and MonAmi6 so former charters and conclusions should be taken > into account). > > So, if there was an item in the former group charter, and that item > has just been incidently removed or wrongly worded while drafting the > MEXT charter, we should not simply stick to "the MEXT charter says > that" but the history. > > >> Jari, please inlight us about the procedure here. > >> > >> The same reasoning applies to the NEMO Prefix Delegation draft. > >> However, the discussion we had on the list and during the WG seems > >> to indicate that the 2 current solutions didn't receive enough > >> feedback in the past, and there may be other ways. So, in that > >> specific case, it is useful to reconsider the document (but the 2 > >> were accepted as NEMO WG docs some time in the past). > > > > See above. Seems to me that you should be satisfied about the > > current situation. > > I'm satisfied with the "We decided to remove the current NEMO prefix > delegation drafts as WG items since there is no clear consensus for > any of the two adopted solutions" but not with "we will not adopt > *yet* any of them" (the draft was already adopted). > > > Thierry. > > > Best, > > > > --julien > > > >> Julien Laganier wrote: > >>> Hi Raj, > >>> > >>> MEXT WG should work on items it is chartered to work on. 4285bis > >>> is clearly not included in our current charter, thus it shouldn't > >>> be a MEXT WG document. > >>> > >>> MEXT wise, a way forward is to include 4285bis as part of our > >>> rechartering. > >>> > >>> --julien > >>> > >>> On Tuesday 18 December 2007, Basavaraj Patil wrote: > >>>> RFC4285bis is a minor bug fix w.r.t the key length. > >>>> If MEXT does not want to make this a WG doc, we can maybe > >>>> progress it as a MIP6 WG doc. > >>>> It has already completed WG LC in August, 07. > >>>> Hence I have no problem forwarding it to the IESG for processing > >>>> as a MIP6 WG doc. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> On 12/18/07 1:01 PM, "ext Vijay Devarapalli" > >>>> > >>>> wrote: > >>>>> Hi Julien, > >>>>> > >>>>> Julien Laganier wrote: > >>>>>> Previous WG drafts that the WG hasn't agreed to take as WG > >>>>>> drafts, or have no corresponding work item in MEXT charter > >>>>>> must not be submitted as > >>>>>> draft-ietf-{mext,mip6,nemo,monami6}-*. Of course authors are > >>>>>> free to submit them as individual submission, e.g. > >>>>>> draft-*-mext-*: > >>>>>> > >>>>>> draft-ietf-nemo-prefix-delegation > >>>>>> draft-ietf-nemo-dhcpv6-pd > >>>>>> draft-ietf-mip6-rfc4285bis > >>>>> > >>>>> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I > >>>>> thought it was ready for a MIP6 WG last call. Raj, please > >>>>> correct me if I am wrong. I think this document should be a > >>>>> MEXT WG document. > >>>>> > >>>>> Regarding the other changes in the document (for example > >>>>> removing the IESG note) should of course be discussed on the > >>>>> MEXT mailing list. > >>>>> > >>>>>> draft-ietf-mip6-generic-notification-message > >>>>> > >>>>> I thought we concluded we missed this document somehow and > >>>>> needs to be added to the charter? > >>>>> > >>>>> Vijay > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 10:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J511m-0004DN-9f; Wed, 19 Dec 2007 10:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J511k-0004D9-Ld for mext@ietf.org; Wed, 19 Dec 2007 10:40:08 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J511k-0000Cj-Dm for mext@ietf.org; Wed, 19 Dec 2007 10:40:08 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C13271986CC; Wed, 19 Dec 2007 17:40:07 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 79AEE198642; Wed, 19 Dec 2007 17:40:07 +0200 (EET) Message-ID: <4768EF4F.60205@piuha.net> Date: Wed, 19 Dec 2007 12:15:43 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712191002.47334.julien.IETF@laposte.net> <4768E33C.1040305@inria.fr> In-Reply-To: <4768E33C.1040305@inria.fr> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Thierry, Julien explained the situation. The chairs and I reviewed the situation with all the drafts before they decided what to do. And I do think that we need to get one standard for prefix assignment for NEMO. If there are any further questions, let me know. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 19 12:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52OT-0005hH-BO; Wed, 19 Dec 2007 12:07:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52OR-0005a8-M9 for mext@ietf.org; Wed, 19 Dec 2007 12:07:39 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J52OM-0002DY-4W for mext@ietf.org; Wed, 19 Dec 2007 12:07:39 -0500 Received: from [127.0.0.1] ([98.207.82.216]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 09:07:33 -0800 Message-ID: <47694FCD.9050709@azairenet.com> Date: Wed, 19 Dec 2007 09:07:25 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission References: <200712181623.38497.julien.IETF@laposte.net> <47681903.7040707@azairenet.com> <200712190957.21450.julien.IETF@laposte.net> In-Reply-To: <200712190957.21450.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 17:07:33.0096 (UTC) FILETIME=[A533DE80:01C84261] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > Hi Vijay, > > On Tuesday 18 December 2007, Vijay Devarapalli wrote: >> Julien Laganier wrote: >>> Previous WG drafts that the WG hasn't agreed to take as WG drafts, >>> or have no corresponding work item in MEXT charter must not be >>> submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of course >>> authors are free to submit them as individual submission, e.g. >>> draft-*-mext-*: >>> >>> draft-ietf-nemo-prefix-delegation >>> draft-ietf-nemo-dhcpv6-pd >>> draft-ietf-mip6-rfc4285bis >> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I >> thought it was ready for a MIP6 WG last call. Raj, please correct me >> if I am wrong. I think this document should be a MEXT WG document. > > This is the MEXT WG and we are not chartered to work on maintaining > 4285, thus I think this should not be a MEXT WG document. But it was a MIP6 WG document that completed WG last call and was about to be forwarded to the IESG. So it doesn't make sense to me to make it an individual submission now. Anyway, lets include it when we re-charter. Vijay > > If the WG agrees to include 4285bis as part of our rechartering, and our > new charter is approved, then of course it is fine that 4285bis becomes > a MEXT WG draft. > >> Regarding the other changes in the document (for example removing the >> IESG note) should of course be discussed on the MEXT mailing list. >> >>> draft-ietf-mip6-generic-notification-message >> I thought we concluded we missed this document somehow and needs to >> be added to the charter? > > I wasn't making a statement on the rechartering aspect, just saying it's > currently not in MEXT charter and should thus not be a MEXT WG draft > (until it's in an approved new MEXT charter). > > Best, > > --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From AdriandentonHansen@devx.com Wed Dec 19 12:55:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J538L-0006Ez-S7; Wed, 19 Dec 2007 12:55:05 -0500 Received: from [200.35.55.149] (helo=casa) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J538L-0000gr-2A; Wed, 19 Dec 2007 12:55:05 -0500 Received: from teen by devx.com with SMTP id JOWfXXUdXx for ; Wed, 19 Dec 2007 12:55:03 +0500 From: "Claude Hansen" To: Subject: After thatit's only fun and winning. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071218-0, 18/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Play your favorite games from the comfort of your home, USA players ARE included! When YOU WIN, we win! Visit and start seeing the dollars coming. Visit and start seeing the dollars coming. http://eurocasinoac.com/ From jana@stealthpromotions.com Wed Dec 19 22:17:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5BuT-0002rX-7x for nemo-archive@lists.ietf.org; Wed, 19 Dec 2007 22:17:21 -0500 Received: from pool-71-97-10-200.dfw.dsl-w.verizon.net ([71.97.10.200] helo=71.97.10.200) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5BuS-0006Y2-PM for nemo-archive@lists.ietf.org; Wed, 19 Dec 2007 22:17:21 -0500 Message-ID: <000901c842b6$0313c7dc$cae4ee9a@rxyyvipf> From: "ervin beau" To: Subject: to nemo-archive Date: Thu, 20 Dec 2007 01:29:42 +0000 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.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Good day! A respectable “E-Trust” company is seeking for employees in the USA. If you are interested in finding a secure job, please, respond to us and we will be happy to give you more details. At this moment we are enlarging our staff and you have a chance to become a member of our team and get additional earnings spending 2 - 3 hours per week. You don’t need any special experience for this position. What we offer: Flexible program: two hours/week at your choice, daytime and evening time, mainly checking your e-mail Work at home: checking e-mail and going to the bank Part time - no need to leave your current job - if you already work. 2-3 hours free during the week (mainly in the evening / non-business hours) for communication. Important: Adult age (must be over 18 years old) U.S. work authorization You don’t need to selling or buying anything. You don’t need to make personal investments to start your work. Requirements: general internet knowledge including working with Microsoft Office (Word/Excel) familiarized with financial terms (debit/credit, invoices etc.) familiarized with banking procedures (wire transfers, withdraws etc.) no diploma required students accepted If You are interested in our job offer, please, reply to this letter. Contact us: employercenter@gmail.com From Happeljbqy@arizonarts.com Thu Dec 20 02:28:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Fpe-0006pS-Oo for nemo-archive@lists.ietf.org; Thu, 20 Dec 2007 02:28:38 -0500 Received: from c934199c.virtua.com.br ([201.52.25.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Fpe-0002X0-6M for nemo-archive@lists.ietf.org; Thu, 20 Dec 2007 02:28:38 -0500 Received: from nb_guiqui by arizonarts.com with ASMTP id 490C5767 for ; Thu, 20 Dec 2007 05:26:47 -0300 Received: from nb_guiqui ([148.180.21.198]) by arizonarts.com with ESMTP id 188E960C82F0 for ; Thu, 20 Dec 2007 05:26:47 -0300 Message-ID: Date: Thu, 20 Dec 2007 05:26:24 -0300 From: "reginald Happel" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: spaziass Content-Type: multipart/alternative; boundary="------------080008010704020003010601" X-Spam-Score: 1.9 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------080008010704020003010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You will not regret signing up for our herbal dick enlargers http://www.livemgmts.com/ --------------080008010704020003010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You will not regret signing up for our herbal dick enlargers http://www.livemgmts.com/
--------------080008010704020003010601-- From mext-bounces@ietf.org Thu Dec 20 07:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5KK0-0006is-Ol; Thu, 20 Dec 2007 07:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5KJz-0006ij-A6 for mext@ietf.org; Thu, 20 Dec 2007 07:16:15 -0500 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5KJy-0007ED-Te for mext@ietf.org; Thu, 20 Dec 2007 07:16:15 -0500 Received: by mu-out-0910.google.com with SMTP id i10so4916818mue.5 for ; Thu, 20 Dec 2007 04:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=dhy5/26/Yy7GsRFr2qJtGqxB+PMU5dWF0gk9sBODFxY=; b=n/NU27akjv6Ko8XSUuGB4QS97tWG9T4qBXE/+0weUANLLHotoUS3PcfXiQAVIgCDoLiUWLtZVMLUgSiocB9IFg0J0Qjfk3QppXwdYXzjM8IQyWj1np6CtQ7Tk39Ra6eWjisbBN89UTutgOjlv820hZ938ibwPM3aYIxzEQjVxnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ewNwtHK0NQKGSI4KFpCrKRlAT/T1tD1p/1IZUgnNKLExXzBuBNWhJIuyE2b5dOr1/6rILvuuDYBX3NJiFO2nWiQPn7z69pXBoUSw4e91SSBXPxzfl5hYbPfs3UCzZ4FSJpm65ToXiQZ/mkqPLUEcHcO3sfRtW1l6fgc3AdhULxc= Received: by 10.78.201.15 with SMTP id y15mr7832956huf.38.1198152973939; Thu, 20 Dec 2007 04:16:13 -0800 (PST) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm25748nfu.2007.12.20.04.16.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2007 04:16:12 -0800 (PST) From: Julien Laganier To: mext@ietf.org Subject: Re: [MEXT] MEXT WG drafts (re)naming and submission Date: Thu, 20 Dec 2007 13:16:44 +0100 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200712181623.38497.julien.IETF@laposte.net> <200712190957.21450.julien.IETF@laposte.net> <47694FCD.9050709@azairenet.com> In-Reply-To: <47694FCD.9050709@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712201316.44960.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Vijay, On Wednesday 19 December 2007, Vijay Devarapalli wrote: > Julien Laganier wrote: > > Hi Vijay, > > > > On Tuesday 18 December 2007, Vijay Devarapalli wrote: > >> Julien Laganier wrote: > >>> Previous WG drafts that the WG hasn't agreed to take as WG > >>> drafts, or have no corresponding work item in MEXT charter must > >>> not be submitted as draft-ietf-{mext,mip6,nemo,monami6}-*. Of > >>> course authors are free to submit them as individual submission, > >>> e.g. draft-*-mext-*: > >>> > >>> draft-ietf-nemo-prefix-delegation > >>> draft-ietf-nemo-dhcpv6-pd > >>> draft-ietf-mip6-rfc4285bis > >> > >> 4285bis mainly fixes a bug (key length) in RFC 4285. In fact I > >> thought it was ready for a MIP6 WG last call. Raj, please correct > >> me if I am wrong. I think this document should be a MEXT WG > >> document. > > > > This is the MEXT WG and we are not chartered to work on maintaining > > 4285, thus I think this should not be a MEXT WG document. > > But it was a MIP6 WG document that completed WG last call and was > about to be forwarded to the IESG. Too bad that wasn't done then. We're now the MEXT WG and we do have a charter in which 4285bis isn't included. It doesn't make sense to adopt as WG draft a draft discussing something we're not chartered to work on. In that aspect, it somehow doesn't matter what happened in mip6. > So it doesn't make sense to me to make it an individual submission > now. Whether or not it makes sense to make it an invidual submission is irrelevant to that discussion. > Anyway, lets include it when we re-charter. Sure. It's on our list. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JohnnieintendDukes@metblogs.com Thu Dec 20 15:19:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Rrz-0003T3-Vx; Thu, 20 Dec 2007 15:19:52 -0500 Received: from [201.240.77.181] (helo=pc04) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5Rry-00075E-Ij; Thu, 20 Dec 2007 15:19:51 -0500 Message-ID: From: "Francis Rodrigues" To: , =20
Presenting the = energy Co to be in=20 for rest 2007
ENERBRITE=20 TECHNOLOGI
Symbol : E T G=20 U

Energy sector is hot right = now, and=20 everyone wants in

About the Co
We have two strategic=20 objectives:

~ to become a market = leader in=20 developing and marketing innovative and intelligent energy saving = solutions=20 that achieve significant savings in the cost of energy and substantial=20 improvements in energy conservation to the benefit of both consumers and = the=20 environment

~ to be an integrator of = smart=20 automated lifestyle systems that control the interior environment = (climate,=20 entertainment, lighting, security) of residential and professional=20 spaces

Ride this winner for = easy double=20 or triple bagger

------=_NextPart_000_CC52_01C84345.A6EB6BF0-- From mext-bounces@ietf.org Thu Dec 20 15:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Rz6-0000Qq-DQ; Thu, 20 Dec 2007 15:27:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Rz4-0000Qk-La for mext@ietf.org; Thu, 20 Dec 2007 15:27:10 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Rz3-0007Do-Nd for mext@ietf.org; Thu, 20 Dec 2007 15:27:10 -0500 Received: from [200.125.8.121] (r200-125-8-121-dialup.adsl.anteldata.net.uy [200.125.8.121])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id EFEDE2B7D32for ; Thu, 20 Dec 2007 21:27:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: <9F89DF0B-09E3-4540-A4D6-1AF5C108A4FC@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Thu, 20 Dec 2007 21:27:18 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-0.9853 TC:02 TRN:81 TV:5.0.1023(15618.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [MEXT] ACM MobiArch 2008 CFP X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Forwarded with permission of my fellow co-chair Sorry if you receive multiple copies Regards, marcelo ------------------------------------------------------------------------=20= - CALL FOR PAPERS ACM MobiArch 2008 An ACM SIGCOMM 2008 Workshop *** PAPER REGISTRATION DEADLINE: MARCH 17, 2008 *** ------------------------------------------------------------------------=20= - ACM MobiArch 2008 The 3rd ACM International Workshop on Mobility in the Evolving Internet Architecture An ACM SIGCOMM 2008 Workshop Seattle, WA, USA, August 22, 2008 http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ Recent developments in wireless access technologies and mobile devices are beginning to make widespread user, terminal and network mobility a reality in the commercial Internet. At the same time, the Internet architecture struggles to incorporate the functionality that will =20 sustain this increasingly more mobile and more dynamic Internet use. Efficient mobility management and mobility optimizations, locator-identifier splits, multihoming, security and related network operation and management functions are still in the early stages of development. It =20= is, however, already clear that supporting widespread mobility poses to significantly impact the original end-to-end design of the Internet. At the same time, critical momentum is building to significantly revise or even replace the current Internet architecture. Several substantial Future Internet initiatives have started in Europe, the US and Asia, and the topic is also actively being discussed in the vendor and network operator communities. These Future Internet efforts offer the exciting opportunity to design radically different approaches to supporting host and network mobility and multihoming, and may eventually lead to an internetwork architecture with significantly more advanced mobility features than those that the piecemeal extensions of the current =20 Internet protocols result in. MobiArch'08 welcomes submissions from both researchers and practitioners that explore recent advances in architectures, protocols and emerging technologies to enable mobility and multihoming in the Internet, as well as concepts and designs to support widespread mobility and =20 multihoming in future internetworks. Early results, position papers, systems and measurement papers are particularly welcome. TOPICS MobiArch'08 covers all aspects related to mobility in the current and future Internet, including, but not limited to: * Architectures and protocols for mobility support at all layers of the Internet protocol stack, as well as cross-layer approaches * Novel concepts to support widespread mobility and multihoming in a Future Internet * Routing and addressing issues (including locator/identifier splits) and their impact on the Internet architecture * Multihoming, including flow distribution and load-sharing for wireless and mobility * Performance evaluation, experimentation and modeling of Internet mobility * Models for mobility patterns and their experimental validation * New wireless technologies and services and their impact on the Internet architecture * Location management, positioning and data management for wireless and mobility * Accounting, access control, security and privacy issues and their impact on the Internet architecture * Social, economic, scalability and deployment issues SUBMISSION GUIDELINES Submissions must be no longer than six pages, including all figures and references, must be in PDF format, and must follow the ACM formatting guidelines (http://www.acm.org/sigs/publications/proceedings-templates). Submissions that do not adhere to these requirements will be rejected without further review. Peer review is single-blind; the authors names and affiliations are =20 to be included on the submission. Submissions cannot be previously =20 published or be under concurrent review elsewhere. The submission of position papers is encouraged; please clearly identify position papers as such when submitting. Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 TECHNICAL PROGRAM COMMITTEE Lars Eggert (co-chair, Nokia Research Center, FI) Linda Doyle (co-chair, Trinity College, IE) Bengt Ahlgren (Swedish Institute of Computer Science, SE) Jari Arkko (Ericsson, FI) Marcelo Bagnulo (University Carlos III of Madrid, ES) Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) Wesley Eddy (NASA/Verizon (US) Joseph Evans (University of Kansas, US) Ted Faber (USC Information Sciences Institute, US) Stephen Hailes (University College London, UK) Roger Karrer (T-Labs, DE) Rajeev Koodli (Nokia Research Center, US) Donal O'Mahony (Trinity College, IE) J=F6rg Ott (Helsinki University of Technology, FI) Dipankar Raychaudhuri (Rutgers University, US) Dave Thaler (Microsoft, US) Ryuji Wakikawa (Keio University, JP) Klaus Wehrle (RWTH Aachen University, DE) Lixia Zhang (UCLA, US)= _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 20 15:37:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5S8q-0007k3-S3; Thu, 20 Dec 2007 15:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5S8p-0007jx-MG for mext@ietf.org; Thu, 20 Dec 2007 15:37:15 -0500 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5S8n-0001qg-RJ for mext@ietf.org; Thu, 20 Dec 2007 15:37:15 -0500 Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id A19F781B9DA; Thu, 20 Dec 2007 14:37:12 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov with ESMTP id lNq0VippncxyIyBO; Thu, 20 Dec 2007 14:37:12 -0600 (CST) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 14:37:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) Date: Thu, 20 Dec 2007 14:36:13 -0600 Message-ID: In-Reply-To: <20071214224346.548113A40BF@mail.critical.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) Thread-Index: Acg+oszUVsgQqpxYQ5GP3aPSR03gaAEpDWzw References: <20071214224346.548113A40BF@mail.critical.com> From: "Ivancic, William D. (GRC-RCN0)" To: "Stuart W. Card" , X-OriginalArrivalTime: 20 Dec 2007 20:37:12.0580 (UTC) FILETIME=[19928C40:01C84348] X-Spam-Score: -3.8 (---) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: zabele@alphatech.com X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Stuart, When I indicated I polled the aeronautics industry, I should have indicated that it was the "civil" aviation groups I was concentrating on. Of course the military operates under some "civil" aviation requirements and during military operations they operate under other rules as well. It may also be important to note that different interfaces on a route can be configure to run different routing or mobile-ip base protocols or both. I guess it may also be important to note that future radios may allow the interface to effectively be attached to different virtual radio (i.e. the radio is reconfigurable or cognitive and therefore can communicate with a variety of other radio system.) But this is a ways off and is architecture and security as much as routing. /will =20 > -----Original Message----- > From: Stuart W. Card [mailto:stu.card@critical.com]=20 > Sent: Friday, December 14, 2007 5:41 PM > To: Ivancic, William D. (GRC-RCN0); marcelo bagnulo braun;=20 > mext@ietf.org > Cc: zabele@alphatech.com > Subject: aero MR-MR RO (was: [MEXT] Personal Mobile router reqs) >=20 > At 08:10 AM 12/10/2007, Ivancic, William D. (GRC-RCN0) wrote: > >... > >I have been polling the aeronautics industry on whether or=20 > not there is=20 > >strong desire (not requirement) for MR-to-MR route optimization. ...... >=20 > In the Airborne Networking efforts within the U.S. Air Force,=20 > the ability for a user aboard one aircraft to communicate=20 > with a user aboard a second aircraft, when those 2 aircraft=20 > have a direct wireless link between them, regardless of=20 > whether one or both aircraft currently have links with the=20 > ground infrastructure (and not using those links even if both=20 > are present, assuming the direct aircraft to aircraft link=20 > has better QoS or is otherwise preferred per policy over the=20 > air to ground to air route), is a requirement. Of course,=20 > this does not make it a requirement for the IETF generally=20 > nor for MEXT specifically; ...... _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 20 18:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Urb-0003Fw-Q3; Thu, 20 Dec 2007 18:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Ura-0003Fq-BX for mext@ietf.org; Thu, 20 Dec 2007 18:31:38 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5UrZ-0007jY-Bj for mext@ietf.org; Thu, 20 Dec 2007 18:31:38 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1198193496!7675516!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 8991 invoked from network); 20 Dec 2007 23:31:36 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-153.messagelabs.com with SMTP; 20 Dec 2007 23:31:36 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lBKNVZpW014450; Thu, 20 Dec 2007 16:31:35 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lBKNVYtc015324; Thu, 20 Dec 2007 17:31:34 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.129]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lBKNVWqx015305; Thu, 20 Dec 2007 17:31:32 -0600 (CST) Message-ID: <476AFB53.6020504@gmail.com> Date: Fri, 21 Dec 2007 00:31:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] ACM MobiArch 2008 CFP References: <9F89DF0B-09E3-4540-A4D6-1AF5C108A4FC@it.uc3m.es> In-Reply-To: <9F89DF0B-09E3-4540-A4D6-1AF5C108A4FC@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Forwarded with permission of my fellow co-chair > > Sorry if you receive multiple copies YEs I have received multiple copies from several lists! Great to see several IETFers on the program committee; but I don't agree sending CfPs on this list :-) Alex > > Regards, marcelo > > > ------------------------------------------------------------------------- > CALL FOR PAPERS > > ACM MobiArch 2008 > An ACM SIGCOMM 2008 Workshop > > *** PAPER REGISTRATION DEADLINE: MARCH 17, 2008 *** > ------------------------------------------------------------------------- > > > ACM MobiArch 2008 > > The 3rd ACM International Workshop on > Mobility in the Evolving Internet Architecture > > An ACM SIGCOMM 2008 Workshop > Seattle, WA, USA, August 22, 2008 > > http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ > > > Recent developments in wireless access technologies and mobile devices > are beginning to make widespread user, terminal and network mobility a > reality in the commercial Internet. At the same time, the Internet > architecture struggles to incorporate the functionality that will sustain > this increasingly more mobile and more dynamic Internet use. Efficient > mobility management and mobility optimizations, locator-identifier > splits, multihoming, security and related network operation and > management functions are still in the early stages of development. It is, > however, already clear that supporting widespread mobility poses to > significantly impact the original end-to-end design of the Internet. > > At the same time, critical momentum is building to significantly revise > or even replace the current Internet architecture. Several substantial > Future Internet initiatives have started in Europe, the US and Asia, and > the topic is also actively being discussed in the vendor and network > operator communities. These Future Internet efforts offer the exciting > opportunity to design radically different approaches to supporting host > and network mobility and multihoming, and may eventually lead to an > internetwork architecture with significantly more advanced mobility > features than those that the piecemeal extensions of the current Internet > protocols result in. > > MobiArch'08 welcomes submissions from both researchers and practitioners > that explore recent advances in architectures, protocols and emerging > technologies to enable mobility and multihoming in the Internet, as well > as concepts and designs to support widespread mobility and multihoming in > future internetworks. Early results, position papers, systems and > measurement papers are particularly welcome. > > > TOPICS > > MobiArch'08 covers all aspects related to mobility in the current and > future Internet, including, but not limited to: > > * Architectures and protocols for mobility support at all layers > of the Internet protocol stack, as well as cross-layer approaches > > * Novel concepts to support widespread mobility and multihoming > in a Future Internet > > * Routing and addressing issues (including locator/identifier > splits) and their impact on the Internet architecture > > * Multihoming, including flow distribution and load-sharing for > wireless and mobility > > * Performance evaluation, experimentation and modeling of > Internet mobility > > * Models for mobility patterns and their experimental validation > > * New wireless technologies and services and their impact on the > Internet architecture > > * Location management, positioning and data management for > wireless and mobility > > * Accounting, access control, security and privacy issues and > their impact on the Internet architecture > > * Social, economic, scalability and deployment issues > > > SUBMISSION GUIDELINES > > Submissions must be no longer than six pages, including all figures and > references, must be in PDF format, and must follow the ACM formatting > guidelines (http://www.acm.org/sigs/publications/proceedings-templates). > Submissions that do not adhere to these requirements will be rejected > without further review. > > Peer review is single-blind; the authors names and affiliations are to be > included on the submission. Submissions cannot be previously published or > be under concurrent review elsewhere. The submission of position papers > is encouraged; please clearly identify position papers as such when > submitting. > > Papers may be submitted at http://edas.info/newPaper.php?c=6140 > > > TECHNICAL PROGRAM COMMITTEE > > Lars Eggert (co-chair, Nokia Research Center, FI) > Linda Doyle (co-chair, Trinity College, IE) > > Bengt Ahlgren (Swedish Institute of Computer Science, SE) > Jari Arkko (Ericsson, FI) > Marcelo Bagnulo (University Carlos III of Madrid, ES) > Olivier Bonaventure (Université Catholique de Louvain, BE) > Wesley Eddy (NASA/Verizon (US) > Joseph Evans (University of Kansas, US) > Ted Faber (USC Information Sciences Institute, US) > Stephen Hailes (University College London, UK) > Roger Karrer (T-Labs, DE) > Rajeev Koodli (Nokia Research Center, US) > Donal O'Mahony (Trinity College, IE) > Jörg Ott (Helsinki University of Technology, FI) > Dipankar Raychaudhuri (Rutgers University, US) > Dave Thaler (Microsoft, US) > Ryuji Wakikawa (Keio University, JP) > Klaus Wehrle (RWTH Aachen University, DE) > Lixia Zhang (UCLA, US) > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 03:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5d7w-0003Nw-NK; Fri, 21 Dec 2007 03:21:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5d7v-0003NY-5a for mext@ietf.org; Fri, 21 Dec 2007 03:21:03 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5d7u-00019A-MA for mext@ietf.org; Fri, 21 Dec 2007 03:21:03 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBL8Kx101812; Fri, 21 Dec 2007 08:21:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Date: Fri, 21 Dec 2007 02:20:58 -0600 Message-ID: In-Reply-To: <475FED61.2060606@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Thread-Index: Acg8ycLpOHrjm2/cTKekHaRjO7a7HgG4B8hg References: <475FED61.2060606@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Alex, Somehow I missed this posting;=20 My understanding, as per the chairs decision, RFC3775bis is a minor revision to fix known and reported errors. However, this is a protocol extension and change which is not within the scope of RFC3775bis. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, December 12, 2007 8:17 AM > To: mext@ietf.org > Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA=20 > too, not only by CN >=20 > Section 4, subsection 4.2, 5th and 6th paragraphs. >=20 > OLD TEXT: > > Binding Refresh Request > >=20 > > A Binding Refresh Request is used by a correspondent node to > > request a mobile node to re-establish its binding with the > > correspondent node. This message is typically used when the > > cached binding is in active use but the binding's lifetime is > > close to expiration. The correspondent node may use, for > > instance, recent traffic and open transport layer=20 > connections as > > an indication of active use. > >=20 > > Binding Error > >=20 > > The Binding Error is used by the correspondent node=20 > to signal an > > error related to mobility, such as an inappropriate=20 > attempt to use > > the Home Address destination option without an=20 > existing binding. >=20 > NEW TEXT: > > Binding Refresh Request > >=20 > > A Binding Refresh Request is used by a correspondent=20 > node or the home agent to > > request a mobile node to re-establish its binding with the > > correspondent node. This message is typically used when the > > cached binding is in active use but the binding's lifetime is > > close to expiration. The correspondent node or the=20 > home agent may use, for > > instance, recent traffic and open transport layer=20 > connections as > > an indication of active use. > >=20 > > Binding Error > >=20 > > The Binding Error is used by the correspondent node=20 > or the home agent to signal an > > error related to mobility, such as an inappropriate=20 > attempt to use > > the Home Address destination option without an=20 > existing binding. > >=20 >=20 > Even though RFC3775 states at some point that a CN can be a=20 > HA, it is unclear when implementing whether a HA should=20 > implement sending BRR or BErr to the MN or not. Some people=20 > have implemented this as yes, HA should send BErr and BRR to=20 > MN. This has been discussed in the past on the mip6 mailing=20 > list. Note that the disambiguation proposed above may be=20 > needed in some other parts of the document as well. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 05:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5esW-0003qd-3f; Fri, 21 Dec 2007 05:13:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5esP-0003qG-CA for mext@ietf.org; Fri, 21 Dec 2007 05:13:09 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5esO-0004iV-Ns for mext@ietf.org; Fri, 21 Dec 2007 05:13:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1198231987!31672761!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22556 invoked from network); 21 Dec 2007 10:13:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 21 Dec 2007 10:13:07 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBLAD7lf019498 for ; Fri, 21 Dec 2007 03:13:07 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lBLAD62v000922 for ; Fri, 21 Dec 2007 04:13:06 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lBLAD5kA000912 for ; Fri, 21 Dec 2007 04:13:05 -0600 (CST) Message-ID: <476B91B0.8030805@gmail.com> Date: Fri, 21 Dec 2007 11:13:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: mext@ietf.org Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN References: <475FED61.2060606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: > Hi Alex, > > Somehow I missed this posting; > My understanding, as per the chairs decision, RFC3775bis is a minor > revision to fix known and reported errors. However, this is a protocol > extension and change which is not within the scope of RFC3775bis. Hi Ahmad, indeed posts get missed sometimes. The BRR/BErr being sent by HA (in addition to CN) is a necessary disambigation, has been discussed in the past: -rfc3775 mentions at some point that "CN" is any correspondent to the MN, and HA is a "CN" in this sense. -some implementations have already implemented HA to send BRR and BErr. -this is more of a textual clarification and less to none new protocol to write. Alex >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, December 12, 2007 8:17 AM >> To: mext@ietf.org >> Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA >> too, not only by CN >> >> Section 4, subsection 4.2, 5th and 6th paragraphs. >> >> OLD TEXT: >>> Binding Refresh Request >>> >>> A Binding Refresh Request is used by a correspondent node to >>> request a mobile node to re-establish its binding with the >>> correspondent node. This message is typically used when the >>> cached binding is in active use but the binding's lifetime is >>> close to expiration. The correspondent node may use, for >>> instance, recent traffic and open transport layer >> connections as >>> an indication of active use. >>> >>> Binding Error >>> >>> The Binding Error is used by the correspondent node >> to signal an >>> error related to mobility, such as an inappropriate >> attempt to use >>> the Home Address destination option without an >> existing binding. >> >> NEW TEXT: >>> Binding Refresh Request >>> >>> A Binding Refresh Request is used by a correspondent >> node or the home agent to >>> request a mobile node to re-establish its binding with the >>> correspondent node. This message is typically used when the >>> cached binding is in active use but the binding's lifetime is >>> close to expiration. The correspondent node or the >> home agent may use, for >>> instance, recent traffic and open transport layer >> connections as >>> an indication of active use. >>> >>> Binding Error >>> >>> The Binding Error is used by the correspondent node >> or the home agent to signal an >>> error related to mobility, such as an inappropriate >> attempt to use >>> the Home Address destination option without an >> existing binding. >> Even though RFC3775 states at some point that a CN can be a >> HA, it is unclear when implementing whether a HA should >> implement sending BRR or BErr to the MN or not. Some people >> have implemented this as yes, HA should send BErr and BRR to >> MN. This has been discussed in the past on the mip6 mailing >> list. Note that the disambiguation proposed above may be >> needed in some other parts of the document as well. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 08:54:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iKG-0006ov-Fn; Fri, 21 Dec 2007 08:54:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iKF-0006oq-Ir for mext@ietf.org; Fri, 21 Dec 2007 08:54:07 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5iKE-0001yw-VK for mext@ietf.org; Fri, 21 Dec 2007 08:54:07 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBLDs4f05356; Fri, 21 Dec 2007 13:54:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Date: Fri, 21 Dec 2007 07:53:42 -0600 Message-ID: In-Reply-To: <476B91B0.8030805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Thread-Index: AchDui0uAt/C76iVS5uaU865u3AxzwAHO7hA References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by=20 > HA too, not only by CN >=20 > Ahmad Muhanna wrote: > > Hi Alex, > >=20 > > Somehow I missed this posting; > > My understanding, as per the chairs decision, RFC3775bis is a minor=20 > > revision to fix known and reported errors. However, this is=20 > a protocol=20 > > extension and change which is not within the scope of RFC3775bis. >=20 > Hi Ahmad, indeed posts get missed sometimes. >=20 > The BRR/BErr being sent by HA (in addition to CN) is a=20 > necessary disambigation, has been discussed in the past: > -rfc3775 mentions at some point that "CN" is any correspondent to the > MN, and HA is a "CN" in this sense. > -some implementations have already implemented HA to send BRR=20 > and BErr. > -this is more of a textual clarification and less to none new protocol > to write. Hi Alex, The fact that some already implemented this message does not automatically make it part of this standard. I would say that is their own reading of the spec. The point we are discussing here is not the applicability of the message. It is the scope of the changes of RFC3775bis, which, is limited to capture and fix minor errors. NOT to introduce new functionalities. Best Regards, Ahmad=20 >=20 > Alex >=20 > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Wednesday, December 12, 2007 8:17 AM > >> To: mext@ietf.org > >> Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA=20 > too, not=20 > >> only by CN > >> > >> Section 4, subsection 4.2, 5th and 6th paragraphs. > >> > >> OLD TEXT: > >>> Binding Refresh Request > >>> > >>> A Binding Refresh Request is used by a correspondent node to > >>> request a mobile node to re-establish its binding with the > >>> correspondent node. This message is typically used when the > >>> cached binding is in active use but the binding's=20 > lifetime is > >>> close to expiration. The correspondent node may use, for > >>> instance, recent traffic and open transport layer > >> connections as > >>> an indication of active use. > >>> > >>> Binding Error > >>> > >>> The Binding Error is used by the correspondent node > >> to signal an > >>> error related to mobility, such as an inappropriate > >> attempt to use > >>> the Home Address destination option without an > >> existing binding. > >> > >> NEW TEXT: > >>> Binding Refresh Request > >>> > >>> A Binding Refresh Request is used by a correspondent > >> node or the home agent to > >>> request a mobile node to re-establish its binding with the > >>> correspondent node. This message is typically used when the > >>> cached binding is in active use but the binding's=20 > lifetime is > >>> close to expiration. The correspondent node or the > >> home agent may use, for > >>> instance, recent traffic and open transport layer > >> connections as > >>> an indication of active use. > >>> > >>> Binding Error > >>> > >>> The Binding Error is used by the correspondent node > >> or the home agent to signal an > >>> error related to mobility, such as an inappropriate > >> attempt to use > >>> the Home Address destination option without an > >> existing binding. > >> Even though RFC3775 states at some point that a CN can be=20 > a HA, it is=20 > >> unclear when implementing whether a HA should implement=20 > sending BRR=20 > >> or BErr to the MN or not. Some people have implemented=20 > this as yes,=20 > >> HA should send BErr and BRR to MN. This has been discussed in the=20 > >> past on the mip6 mailing list. Note that the=20 > disambiguation proposed=20 > >> above may be needed in some other parts of the document as well. > >> > >> Alex > >> > >> > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. > >> For more information please visit http://www.messagelabs.com/email=20 > >>=20 > _____________________________________________________________________ > >> _ > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mext > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 08:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iN7-0005Jg-GZ; Fri, 21 Dec 2007 08:57:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iN6-0005JV-8N for mext@ietf.org; Fri, 21 Dec 2007 08:57:04 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5iN5-00022E-Qn for mext@ietf.org; Fri, 21 Dec 2007 08:57:04 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1198245423!40724479!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19106 invoked from network); 21 Dec 2007 13:57:03 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 21 Dec 2007 13:57:03 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBLDuwfb008142; Fri, 21 Dec 2007 06:57:02 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lBLDuwJY018617; Fri, 21 Dec 2007 07:56:58 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lBLDurDF018515; Fri, 21 Dec 2007 07:56:57 -0600 (CST) Message-ID: <476BC613.8020906@gmail.com> Date: Fri, 21 Dec 2007 14:56:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by >> HA too, not only by CN >> >> Ahmad Muhanna wrote: >>> Hi Alex, >>> >>> Somehow I missed this posting; >>> My understanding, as per the chairs decision, RFC3775bis is a minor >>> revision to fix known and reported errors. However, this is >> a protocol >>> extension and change which is not within the scope of RFC3775bis. >> Hi Ahmad, indeed posts get missed sometimes. >> >> The BRR/BErr being sent by HA (in addition to CN) is a >> necessary disambigation, has been discussed in the past: >> -rfc3775 mentions at some point that "CN" is any correspondent to the >> MN, and HA is a "CN" in this sense. >> -some implementations have already implemented HA to send BRR >> and BErr. >> -this is more of a textual clarification and less to none new protocol >> to write. > > Hi Alex, > The fact that some already implemented this message does not > automatically make it part of this standard. I would say that is their > own reading of the spec. The point we are discussing here is not the > applicability of the message. It is the scope of the changes of > RFC3775bis, which, is limited to capture and fix minor errors. NOT to > introduce new functionalities. Ahmad - what do you think - should the HA send BErr/BRR? OR should it not? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 09:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iQd-00047n-43; Fri, 21 Dec 2007 09:00:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5iQb-00046O-Em for mext@ietf.org; Fri, 21 Dec 2007 09:00:41 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5iQb-0002Fl-1q for mext@ietf.org; Fri, 21 Dec 2007 09:00:41 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBLE0c902170; Fri, 21 Dec 2007 14:00:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Date: Fri, 21 Dec 2007 08:00:32 -0600 Message-ID: In-Reply-To: <476BC613.8020906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN Thread-Index: AchD2V+pDTSoc31jQl2kd6r1KyaZegAAANOg References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >> > >> Ahmad Muhanna wrote: > >>> Hi Alex, > >>> > >>> Somehow I missed this posting; > >>> My understanding, as per the chairs decision, RFC3775bis=20 > is a minor=20 > >>> revision to fix known and reported errors. However, this is > >> a protocol > >>> extension and change which is not within the scope of RFC3775bis. > >> Hi Ahmad, indeed posts get missed sometimes. > >> > >> The BRR/BErr being sent by HA (in addition to CN) is a necessary=20 > >> disambigation, has been discussed in the past: > >> -rfc3775 mentions at some point that "CN" is any=20 > correspondent to the > >> MN, and HA is a "CN" in this sense. > >> -some implementations have already implemented HA to send BRR and=20 > >> BErr. > >> -this is more of a textual clarification and less to none=20 > new protocol > >> to write. > >=20 > > Hi Alex, > > The fact that some already implemented this message does not=20 > > automatically make it part of this standard. I would say=20 > that is their=20 > > own reading of the spec. The point we are discussing here=20 > is not the=20 > > applicability of the message. It is the scope of the changes of=20 > > RFC3775bis, which, is limited to capture and fix minor=20 > errors. NOT to=20 > > introduce new functionalities. >=20 > Ahmad - what do you think - should the HA send BErr/BRR? OR=20 > should it not? [Ahmad] Hi Alex, That is a different topic which is not withing the scope of the current thread. Regards, Ahmad >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 09:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ipH-0006nX-HF; Fri, 21 Dec 2007 09:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ipF-0006nS-QB for mext@ietf.org; Fri, 21 Dec 2007 09:26:09 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5ipF-0000Ea-CI for mext@ietf.org; Fri, 21 Dec 2007 09:26:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1198247167!8303001!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23096 invoked from network); 21 Dec 2007 14:26:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 21 Dec 2007 14:26:07 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBLEQ2ON016372; Fri, 21 Dec 2007 07:26:02 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lBLEQ14X019111; Fri, 21 Dec 2007 08:26:01 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lBLEQ0hI018979; Fri, 21 Dec 2007 08:26:00 -0600 (CST) Message-ID: <476BCCF0.1020202@gmail.com> Date: Fri, 21 Dec 2007 15:25:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ahmad Muhanna References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mext@ietf.org Subject: [MEXT] Re: Scope of 3775bis (was: BRR, BErr are sent by HA too, not only by CN) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >>>> Ahmad Muhanna wrote: >>>>> Hi Alex, >>>>> >>>>> Somehow I missed this posting; My understanding, as per the >>>>> chairs decision, RFC3775bis is a minor revision to fix known >>>>> and reported errors. However, this is a protocol extension >>>>> and change which is not within the scope of RFC3775bis. >>>> >>>> Hi Ahmad, indeed posts get missed sometimes. >>>> >>>> The BRR/BErr being sent by HA (in addition to CN) is a >>>> necessary disambigation, has been discussed in the past: >>>> -rfc3775 mentions at some point that "CN" is any correspondent >>>> to the MN, and HA is a "CN" in this sense. -some >>>> implementations have already implemented HA to send BRR and >>>> BErr. -this is more of a textual clarification and less to none >>>> new protocol to write. >>> >>> Hi Alex, The fact that some already implemented this message does >>> not automatically make it part of this standard. I would say that >>> is their own reading of the spec. The point we are discussing >>> here is not the applicability of the message. It is the scope of >>> the changes of RFC3775bis, which, is limited to capture and fix >>> minor errors. NOT to introduce new functionalities. >> Ahmad - what do you think - should the HA send BErr/BRR? OR should >> it not? > > [Ahmad] Hi Alex, That is a different topic which is not withing the > scope of the current thread. Ahmad, you could give a technical oppinion on HA sending BRR/BErr discussion. Until then I consider your oppinion to be administratively related to the scope of 3775bis, and not technical. Thus I change the subject to 'Scope of 3775bis' - what do you think this scope should be? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From Erika.Robbie@tvhifi2.plus.com Fri Dec 21 10:22:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5jhi-0001Vw-1M for nemo-archive@lists.ietf.org; Fri, 21 Dec 2007 10:22:26 -0500 Received: from [190.40.65.227] (helo=[190.42.15.241]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5jhh-0003xg-I3 for nemo-archive@lists.ietf.org; Fri, 21 Dec 2007 10:22:25 -0500 Received: from Pc-1 ([137.168.52.139] helo=Pc-1) by [190.42.15.241] ( sendmail 8.13.3/8.13.1) with esmtpa id 1qSrlv-000EPV-Fd for nemo-archive@lists.ietf.org; Fri, 21 Dec 2007 10:22:39 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Dec 2007 10:22:25 -0500 To: nemo-archive@lists.ietf.org From: "Erika Robbie" Subject: bigonial Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Size does matter, upgrade your dick with us today http://www.jinasd.com/ From mext-bounces@ietf.org Fri Dec 21 11:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kqI-0002LQ-VO; Fri, 21 Dec 2007 11:35:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5kqH-0002KY-Vn for mext@ietf.org; Fri, 21 Dec 2007 11:35:21 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5kqF-00039z-Nf for mext@ietf.org; Fri, 21 Dec 2007 11:35:21 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBLGZG519006; Fri, 21 Dec 2007 16:35:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Dec 2007 10:35:12 -0600 Message-ID: In-Reply-To: <476BCCF0.1020202@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of sending BRR, BErr by the HA? Thread-Index: AchD3XFuSCy7P0shRxGS1q8BOWOXvQAAbULw References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> <476BCCF0.1020202@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: -4.0 (----) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: mext@ietf.org Subject: [MEXT] RE: Applicability of sending BRR, BErr by the HA? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >=20 > Ahmad Muhanna wrote: > >>>> Ahmad Muhanna wrote: > >>>>> Hi Alex, > >>>>>=20 > >>>>> Somehow I missed this posting; My understanding, as per=20 > the chairs=20 > >>>>> decision, RFC3775bis is a minor revision to fix known=20 > and reported=20 > >>>>> errors. However, this is a protocol extension and=20 > change which is=20 > >>>>> not within the scope of RFC3775bis. > >>>>=20 > >>>> Hi Ahmad, indeed posts get missed sometimes. > >>>>=20 > >>>> The BRR/BErr being sent by HA (in addition to CN) is a necessary=20 > >>>> disambigation, has been discussed in the past: > >>>> -rfc3775 mentions at some point that "CN" is any=20 > correspondent to=20 > >>>> the MN, and HA is a "CN" in this sense. -some=20 > implementations have=20 > >>>> already implemented HA to send BRR and BErr. -this is more of a=20 > >>>> textual clarification and less to none new protocol to write. > >>>=20 > >>> Hi Alex, The fact that some already implemented this message does=20 > >>> not automatically make it part of this standard. I would=20 > say that is=20 > >>> their own reading of the spec. The point we are=20 > discussing here is=20 > >>> not the applicability of the message. It is the scope of=20 > the changes=20 > >>> of RFC3775bis, which, is limited to capture and fix minor errors.=20 > >>> NOT to introduce new functionalities. > >> Ahmad - what do you think - should the HA send BErr/BRR? =20 > OR should=20 > >> it not? > >=20 > > [Ahmad] Hi Alex, That is a different topic which is not withing the=20 > > scope of the current thread. >=20 > Ahmad, you could give a technical oppinion on HA sending=20 > BRR/BErr discussion. Until then I consider your oppinion to=20 > be administratively related to the scope of 3775bis, and not=20 > technical. >=20 > Thus I change the subject to 'Scope of 3775bis' - what do you=20 > think this scope should be? [Ahmad] Hi Alex, The proposed changes is a new functionality that it is not withing the scope of RFC3775bis and also requires new software update on the HA. On the other hand, I changed the subject again to read as "Applicability of sending BRR, BErr by the HA?"=20 IMO, you need to separate these two messages (BRR and BErr) and they need to be discussed separately. Case of BRR message: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I believe the intention of RFC3775 is to restrict the use of this message to the CN ONLY. IMO, it is quite clear that within the scope of RFC3775, this message is not applicable to the HA. For the following reasons: 1. RFC3775 defines a protocol to enable a mobile node to register its CoA in a foreign network with its home agent in order to be reachable at its home address. i.e. create a binding for the MN CoA and its HoA at the Home Agent. 2. RFC3775 developed a mechanism for the MN to refresh its BCE, i.e. RFC3775 defined a field in BA which is called lifetime. This field indicates to the MN the approved lifetime that the Home Agent agreed to honor while offering mobility services to the MN and at the same time maintain a BCE for the MN CoA and HoA. 3. In the contents of RFC3775 the mobile node is quite aware that without maintaining a current BCE at its Home agent, i.e. the basic fundamental functionality of MIPv6, the Mobile node will loose all of its mobility services and its reachability at the foreign network using its HoA. 4. RFC3775 specify that the MN needs to send a new BU message in order to refresh or extend the BCE lifetime. This is extremely important because a node like the HA, does not need to send a reminder to every single MN that it serves and maintains a BCE for. 5. If the HA needs to send a reminder to every MN about the expiry of its BCE, then we are introducing a new functionality which violates the basic RFC3775 functionality and a non sense complexity that absolutely is not necessary and not within the original intention of RFC3775. 6. On the other hand, CN maintains a limited number of BCE for specific mobile nodes and more importantly if the MN decides NOT to renew its BCE with a specific CN, the MN continues to be reachable by other CNs at its HoA and CoA via its Home Agent BCE. In other words, a MN binding with another CN represent the service (RO) between MN<->CN ONLY, however, in the case of HA it represents the MN's MIP6 service and access to the whole internet. Which also administratively governed. i.e. if the MN does not renew its BCE, then that is a clear indication for the HA to delete the MN BCE. 7. Finally, the fact that RFC3775 mentions that CN could be a HA, does not mean that the HA application at such a node need to support BRR. IMO, such a node could act as a CN for some MNs and a HA for others. Then, it is normal for this CN/HA node to support BRR for those MN which is serving as a CN but not a HA. Best Regards, Ahmad >=20 > Alex >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 11:47:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5l21-0002ZI-CI; Fri, 21 Dec 2007 11:47:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5l1z-0002ZC-Q3 for mext@ietf.org; Fri, 21 Dec 2007 11:47:27 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5l1z-0003NW-9s for mext@ietf.org; Fri, 21 Dec 2007 11:47:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1198255645!2930209!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21786 invoked from network); 21 Dec 2007 16:47:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 21 Dec 2007 16:47:25 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBLGlOI9029943; Fri, 21 Dec 2007 09:47:24 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lBLGlODx006823; Fri, 21 Dec 2007 10:47:24 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lBLGlMbO006727; Fri, 21 Dec 2007 10:47:23 -0600 (CST) Message-ID: <476BEE14.2090405@gmail.com> Date: Fri, 21 Dec 2007 17:47:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ahmad Muhanna References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> <476BCCF0.1020202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mext@ietf.org Subject: [MEXT] Re: Reliability of sending BRR by the HA? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Ahmad, I've changed the topic. Please make another thread, if you wish, about applicability and scope. Ahmad Muhanna wrote: [...] > [Ahmad] Hi Alex, The proposed changes is a new functionality that it > is not withing the scope of RFC3775bis and also requires new software > update on the HA. > > On the other hand, I changed the subject again to read as > "Applicability of sending BRR, BErr by the HA?" > > IMO, you need to separate these two messages (BRR and BErr) and they > need to be discussed separately. > > Case of BRR message: ==================== [...] > 4. RFC3775 specify that the MN needs to send a new BU message in > order to refresh or extend the BCE lifetime. This is extremely > important because a node like the HA, does not need to send a > reminder to every single MN that it serves and maintains a BCE for. Right. > 5. If the HA needs to send a reminder to every MN about the expiry of > its BCE, then we are introducing a new functionality which violates > the basic RFC3775 functionality and a non sense complexity that > absolutely is not necessary and not within the original intention of > RFC3775. In what does that HA-sends-BRR functionality violate the basic 3775? What does it break? I see it offering better reliability: even if the critical BU is lost the HA requests the BU anew (BRR) and thus reduces the non-bound time from the entire lifetime to much less. > 6. On the other hand, CN maintains a limited number of BCE for > specific mobile nodes and more importantly if the MN decides NOT to > renew its BCE with a specific CN, the MN continues to be reachable by > other CNs at its HoA and CoA via its Home Agent BCE. In other words, > a MN binding with another CN represent the service (RO) between > MN<->CN ONLY, however, in the case of HA it represents the MN's MIP6 > service and access to the whole internet. Which also administratively > governed. i.e. if the MN does not renew its BCE, then that is a > clear indication for the HA to delete the MN BCE. Not before it sends a BRR and waits for an answer to that. > 7. Finally, the fact that RFC3775 mentions that CN could be a HA, > does not mean that the HA application at such a node need to support > BRR. That's your reading. Other implementers read it in the way I said. > IMO, such a node could act as a CN for some MNs and a HA for others. > Then, it is normal for this CN/HA node to support BRR for those MN > which is serving as a CN but not a HA. Is a HA a "CN" when it is the dst field of the BU? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Dec 21 12:59:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5m9T-0007ET-W9; Fri, 21 Dec 2007 12:59:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5m9S-0007EO-7K for mext@ietf.org; Fri, 21 Dec 2007 12:59:14 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5m9R-0000CI-Eq for mext@ietf.org; Fri, 21 Dec 2007 12:59:14 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBLHxA921388; Fri, 21 Dec 2007 17:59:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Dec 2007 11:59:06 -0600 Message-ID: In-Reply-To: <476BEE14.2090405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reliability of sending BRR by the HA? Thread-Index: AchD8S9DtSbtaXitTlG75pHTd2GYxQAAC28A References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> <476BCCF0.1020202@gmail.com> <476BEE14.2090405@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: -4.0 (----) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: mext@ietf.org Subject: [MEXT] RE: Reliability of sending BRR by the HA? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >=20 > Hi Ahmad, I've changed the topic. Please make another=20 > thread, if you wish, about applicability and scope. >=20 > Ahmad Muhanna wrote: > [...] > > [Ahmad] Hi Alex, The proposed changes is a new=20 > functionality that it=20 > > is not withing the scope of RFC3775bis and also requires=20 > new software =20 > > update on the HA. > >=20 > > On the other hand, I changed the subject again to read as=20 > > "Applicability of sending BRR, BErr by the HA?" > >=20 > > IMO, you need to separate these two messages (BRR and BErr)=20 > and they =20 > > need to be discussed separately. > >=20 > > Case of BRR message: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [...] > > 4. RFC3775 specify that the MN needs to send a new BU=20 > message in order=20 > > to refresh or extend the BCE lifetime. This is extremely important=20 > > because a node like the HA, does not need to send a=20 > reminder to every=20 > > single MN that it serves and maintains a BCE for. >=20 > Right. [Ahmad] Okay, then RFC3775 has a mechanism already specified for updating the MN BCE at its HA, why do we need another new functionality which, IMO, does not scale and may cause a huge problem for the HA? >=20 > > 5. If the HA needs to send a reminder to every MN about the=20 > expiry of =20 > > its BCE, then we are introducing a new functionality which violates=20 > > the basic RFC3775 functionality and a non sense complexity that=20 > > absolutely is not necessary and not within the original=20 > intention of=20 > > RFC3775. >=20 > In what does that HA-sends-BRR functionality violate the basic 3775? > What does it break? [Ahmad] I am not sure if what does break is the right question here.=20 It is a new functionality which is fundamentally in conflict with the original RFC3775 intention of how MIP6 BCE is managed at the HA. However, let me explain what could happen in case that the HA implements this new weird functionality: 1. Some of the HA are talking about supporting a million BCE simultaneously. Do you understand the impact on the HA when these BCEs starts getting close to expiry? and the HA needs to send a BRR message and not only that but retransmits those messages until a BU is received from each one of these MNs? =20 3. Personally, I wont agree to such functionality because Home Agent acts as a server offering a MIP6 mobility service to multiple MNs governed by a MIP6 protocol which offers a reliable mechanism for updating the MN BCE lifetime at the HA. 4. Let us assume for the sake of argument that this new functionality is supported by the HA, what is the impact: 4.1. Can you imagine the unnecessary traffic that is generated for no reason. 4.2. What is going to be the MN processing when it receives such a message? All current RFC3775 text talks about a BRR coming from the CN. Is there going to be a difference in there? 4.3. How MN would recognize that this message is related to MN BCE at the HA? 4.4. Backward compatibility, How, this would work for MN which only supports BRR from the CN? 4.5. Finally, if this procedure is adopted, are we going to deprecate the existing one using lifetime field in BA, etc? 4.6. etc. >=20 > I see it offering better reliability: even if the critical BU=20 > is lost the HA requests the BU anew (BRR) and thus reduces=20 > the non-bound time from the entire lifetime to much less. [Ahmad] 1. Wow! Are you calling this a better reliability? What is your definition of reliability then? 2. Are you suggesting that the current RFC3775 protocol is BROKEN and does not address BU loss? 3. I do not understand what you mean by: "and thus reduces the non-bound time from the entire lifetime to much less" Can you please elaborate more and explain? >=20 > > 6. On the other hand, CN maintains a limited number of BCE for=20 > > specific mobile nodes and more importantly if the MN decides NOT to=20 > > renew its BCE with a specific CN, the MN continues to be=20 > reachable by =20 > > other CNs at its HoA and CoA via its Home Agent BCE. In=20 > other words, =20 > > a MN binding with another CN represent the service (RO) between=20 > > MN<->CN ONLY, however, in the case of HA it represents the=20 > MN's MIP6=20 > > service and access to the whole internet. Which also=20 > administratively =20 > > governed. i.e. if the MN does not renew its BCE, then that=20 > is a clear=20 > > indication for the HA to delete the MN BCE. >=20 > Not before it sends a BRR and waits for an answer to that. [Ahmad] What do you mean here, MN does not send a BU to refresh its Home BCE lifetime except after receiving a BRR? >=20 > > 7. Finally, the fact that RFC3775 mentions that CN could be=20 > a HA, does=20 > > not mean that the HA application at such a node need to support BRR. >=20 > That's your reading. Other implementers read it in the way I said. [Ahmad] Excellent. Please cut and paste here the text where it supports your understanding? >=20 > > IMO, such a node could act as a CN for some MNs and a HA for others. > > Then, it is normal for this CN/HA node to support BRR for those MN=20 > > which is serving as a CN but not a HA. >=20 > Is a HA a "CN" when it is the dst field of the BU? [Ahmad] I am not sure what you are trying to say here, but for now, let us focus on the real issue as highlighted above. Thanks! >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From VernonwhistleableRiley@tiaonline.org Fri Dec 21 14:40:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5nj5-0002jv-Tw; Fri, 21 Dec 2007 14:40:07 -0500 Received: from [190.43.25.203] (helo=rendel) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5nj5-0002o1-Io; Fri, 21 Dec 2007 14:40:07 -0500 Received: from faraday by tiaonline.org with SMTP id VRHNyXPazP for ; Fri, 21 Dec 2007 14:39:08 +0500 From: "Hector Lane" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ol4-0002vE-EX; Fri, 21 Dec 2007 15:46:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ol3-0002qf-0x for mext@ietf.org; Fri, 21 Dec 2007 15:46:13 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5ol1-00058T-PD for mext@ietf.org; Fri, 21 Dec 2007 15:46:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1198269971!27747847!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7928 invoked from network); 21 Dec 2007 20:46:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 21 Dec 2007 20:46:11 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBLKkA71028449; Fri, 21 Dec 2007 13:46:10 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id lBLKkAB4026414; Fri, 21 Dec 2007 14:46:10 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.127]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id lBLKk8qh026399; Fri, 21 Dec 2007 14:46:09 -0600 (CST) Message-ID: <476C2610.3000101@gmail.com> Date: Fri, 21 Dec 2007 21:46:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ahmad Muhanna References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> <476BCCF0.1020202@gmail.com> <476BEE14.2090405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071220-0, 20/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: mext@ietf.org Subject: [MEXT] Re: Reliability of sending BRR by the HA? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >>> Case of BRR message: ==================== [...] 4. RFC3775 >>> specify that the MN needs to send a new BU message in order to >>> refresh or extend the BCE lifetime. This is extremely important >>> because a node like the HA, does not need to send a reminder to >>> every single MN that it serves and maintains a BCE for. >> >> Right. > > [Ahmad] Okay, then RFC3775 has a mechanism already specified for > updating the MN BCE at its HA, why do we need another new > functionality which, IMO, does not scale and may cause a huge problem > for the HA? What exactly doesn't scale? I think HA sending BRR is as scalable as MN sending BU to it. What's the non-scaling factor introduced by BRR at HA? >>> 5. If the HA needs to send a reminder to every MN about the >>> expiry of its BCE, then we are introducing a new functionality >>> which violates the basic RFC3775 functionality and a non sense >>> complexity that absolutely is not necessary and not within the >>> original intention of RFC3775. >> >> In what does that HA-sends-BRR functionality violate the basic >> 3775? What does it break? > > [Ahmad] I am not sure if what does break is the right question here. But you used the word 'violate' - what does it violate then? > It is a new functionality which is fundamentally in conflict with the > original RFC3775 intention of how MIP6 BCE is managed at the HA. Sorry, what's the conflict you point out? It's not a new message format, not any new option. > However, let me explain what could happen in case that the HA > implements this new weird functionality: > > 1. Some of the HA are talking about supporting a million BCE > simultaneously. Do you understand the impact on the HA when these > BCEs starts getting close to expiry? Ah! I didn't assume that all MNs send BUs simultaneously with precisely the same lifetime. You seem to assume so. If so then we have a BU storm in first place, prior to BRR. If you didn't assume all million MNs send the BUs simultaneously then the BRRs aren't sent simultaneously either. > and the HA needs to send a BRR message and not only that but > retransmits those messages until a BU is received from each one of > these MNs? The BRR is sent only if the BU is not received at HA the end of the lifetime. It is not _always_ sent. That is current behaviour of CN. > 3. Personally, I wont agree to such functionality because Home Agent > acts as a server offering a MIP6 mobility service to multiple MNs > governed by a MIP6 protocol which offers a reliable mechanism for > updating the MN BCE lifetime at the HA. BU/BAck is reliable - BU/BAck/BRR is more reliable. Would you agree? > 4. Let us assume for the sake of argument that this new functionality > is supported by the HA, what is the impact: 4.1. Can you imagine the > unnecessary traffic that is generated for no reason. No, no unnecessary traffic. BRR sent only if at end of lifetime the BU is not received. > 4.2. What is going to be the MN processing when it receives such a > message? All current RFC3775 text talks about a BRR coming from the > CN. Is there going to be a difference in there? No difference. > 4.3. How MN would recognize that this message is related to MN BCE at > the HA? It doesn't need to distinguish this - why do you think it should distinguish? (if it wants so then it has the HA address thus it can answer the q you raise). > 4.4. Backward compatibility, How, this would work for MN which only > supports BRR from the CN? How does MN know BRR is from CN and not from HA? I don't think MNs implement BRR such as to be _only_ from CN. It can't distinguish the BRR coming from CN, it just sees an IP address. > 4.5. Finally, if this procedure is adopted, are we going to deprecate > the existing one using lifetime field in BA, etc? 4.6. etc. No, keep the suggested lifetime field in BA and process it as usual. >> I see it offering better reliability: even if the critical BU is >> lost the HA requests the BU anew (BRR) and thus reduces the >> non-bound time from the entire lifetime to much less. > > [Ahmad] 1. Wow! Are you calling this a better reliability? What is > your definition of reliability then? A form of three-way handshake is better reliability than a two-way exchange. > 2. Are you suggesting that the current RFC3775 protocol is BROKEN and > does not address BU loss? No, not suggesting so. I suggest in certain conditions when the BU is lost, the HA using BRR leads to shorter wait for BCE update (shorter than the current BU waiting for the next lifetime) - less interruption at MN. > 3. I do not understand what you mean by: "and thus reduces the > non-bound time from the entire lifetime to much less" Can you please > elaborate more and explain? If the BU is lost then MN will send another BU at the end of the current lifetime. Instead of waiting for the current lifetime to expire it could be triggered by a BRR received from the HA. No difference between CN and HA here. >>> 6. On the other hand, CN maintains a limited number of BCE for >>> specific mobile nodes and more importantly if the MN decides NOT >>> to renew its BCE with a specific CN, the MN continues to be >>> reachable by other CNs at its HoA and CoA via its Home Agent BCE. >>> In other words, a MN binding with another CN represent the >>> service (RO) between MN<->CN ONLY, however, in the case of HA it >>> represents the MN's MIP6 service and access to the whole >>> internet. Which also administratively governed. i.e. if the MN >>> does not renew its BCE, then that is a clear indication for the >>> HA to delete the MN BCE. >> >> Not before it sends a BRR and waits for an answer to that. > > [Ahmad] What do you mean here, MN does not send a BU to refresh its > Home BCE lifetime except after receiving a BRR? No, I meant it sends its BU as usual, (I think 4s before the lifetime expires or so). >>> 7. Finally, the fact that RFC3775 mentions that CN could be a HA, >>> does not mean that the HA application at such a node need to >>> support BRR. >> >> That's your reading. Other implementers read it in the way I said. >> >> >> >> > > [Ahmad] Excellent. Please cut and paste here the text where it > supports your understanding? Right... difficult to find right now... >>> IMO, such a node could act as a CN for some MNs and a HA for >>> others. Then, it is normal for this CN/HA node to support BRR for >>> those MN which is serving as a CN but not a HA. >> >> Is a HA a "CN" when it is the dst field of the BU? > > [Ahmad] I am not sure what you are trying to say here, but for now, > let us focus on the real issue as highlighted above. Thanks! I meant to say that the effect of BRR being specified and implemented for CN is more reliable BCE at CN. Let's have the same level of reliability at HA. Or maybe we just want to stress that some HA implementations do BRR. Or do we want to forbid HA implementations to do BRR. When do we discuss BErr? (Binding Error) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From JessombudspersonDavenport@zone.dk Fri Dec 21 17:19:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qDL-0003kx-Us; Fri, 21 Dec 2007 17:19:32 -0500 Received: from [190.41.140.156] (helo=cabina05) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5qDL-00082T-8m; Fri, 21 Dec 2007 17:19:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host65964773.zone.dk (8.13.1/8.13.1) with SMTP id n28UiZBU58.641273.AMr.PmE.7611501595473 for ; Sat, 22 Dec 2007 17:14:25 +0500 Message-ID: <09de01c844e8$17ae4ee0$0601a8c0@CABINA05> From: "Otto Clay" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_09DA_01C844E8.17AE4EE0-- From ClevelandbeplasterShort@capecodonline.com Fri Dec 21 17:41:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5qYV-0004uP-Eg; Fri, 21 Dec 2007 17:41:23 -0500 Received: from pd951bf4a.dip0.t-ipconnect.de ([217.81.191.74] helo=kurdo) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5qYV-000073-1x; Fri, 21 Dec 2007 17:41:23 -0500 Received: from jane by capecodonline.com with SMTP id bpuUNsgjoi for ; Fri, 21 Dec 2007 23:41:01 -0100 From: "August Hancock" To: Subject: If you're in the US, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Get $999 you download our casino. How about the best service around? Players from the United States and around the world! When YOU WIN, we win! http://worldcasinod.cn/ From mext-bounces@ietf.org Sat Dec 22 02:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5yoI-0003xn-3t; Sat, 22 Dec 2007 02:30:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5yoH-0003xg-63 for mext@ietf.org; Sat, 22 Dec 2007 02:30:13 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5yoF-00084L-O4 for mext@ietf.org; Sat, 22 Dec 2007 02:30:13 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBM7U8D19737; Sat, 22 Dec 2007 07:30:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 22 Dec 2007 01:29:51 -0600 Message-ID: In-Reply-To: <476C2610.3000101@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reliability of sending BRR by the HA? Thread-Index: AchEEohMHz6Th07bSmuL3ykIz6GiSAAJDQWQ References: <475FED61.2060606@gmail.com> <476B91B0.8030805@gmail.com> <476BC613.8020906@gmail.com> <476BCCF0.1020202@gmail.com> <476BEE14.2090405@gmail.com> <476C2610.3000101@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: mext@ietf.org Subject: [MEXT] RE: Reliability of sending BRR by the HA? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >=20 > What exactly doesn't scale? I think HA sending BRR is as scalable as > MN sending BU to it. What's the non-scaling factor=20 > introduced by BRR at HA? [Ahmad] Read below. >=20 > >>> 5. If the HA needs to send a reminder to every MN about=20 > the expiry=20 > >>> of its BCE, then we are introducing a new functionality which=20 > >>> violates the basic RFC3775 functionality and a non sense=20 > complexity=20 > >>> that absolutely is not necessary and not within the original=20 > >>> intention of RFC3775. > >>=20 > >> In what does that HA-sends-BRR functionality violate the=20 > basic 3775?=20 > >> What does it break? > >=20 > > [Ahmad] I am not sure if what does break is the right question here. >=20 > But you used the word 'violate' - what does it violate then? [Ahmad] Please read below. >=20 > > It is a new functionality which is fundamentally in=20 > conflict with the =20 > > original RFC3775 intention of how MIP6 BCE is managed at the HA. >=20 > Sorry, what's the conflict you point out? It's not a new=20 > message format, not any new option. [Ahmad] Please read below. >=20 > > However, let me explain what could happen in case that the HA=20 > > implements this new weird functionality: > >=20 > > 1. Some of the HA are talking about supporting a million BCE=20 > > simultaneously. Do you understand the impact on the HA when=20 > these BCEs=20 > > starts getting close to expiry? >=20 > Ah! I didn't assume that all MNs send BUs simultaneously=20 > with precisely the same lifetime. You seem to assume so. If=20 > so then we have a BU storm in first place, prior to BRR. >=20 > If you didn't assume all million MNs send the BUs=20 > simultaneously then the BRRs aren't sent simultaneously either. [Ahmad] Alex, Hopefully, this is my last explanation to help clarify your understanding of the applicability and use of BRR by the HA. It is very strange that you understand things and functionalities only according to your own terms and probably your implementation and past experience. However, let me summarize what I want to say in an easier to follow format: 1. Are you assuming that HA provides the same lifetime for all mobile node and all different subscribers at all times? 2. Are you assuming that, for example all subscribers including prepaid ones will end having the same BCE lifetime? 3. Are you assuming that there is only your own limited understanding of how the HA handles the BCE lifetime? 4. IF the answer to all of the above yes, then we have a very specific HA application which is limited to Alex understanding of Mobile IPv6 services and its applicability and at that point, there is no point of discussing this any further! 5. However, If the answer is NO to any of 1-3 points, then when a HA is able to support a high number of different types of subscribers BCE, then the possibility of too many BCE lifetimes to expire at the same time is quite very very high and probably devastating to the HA functionality. 6. If the answer to No. 5 is YES, then it is very possible for a huge number of these BCE lifetime to expire at the same time and if the HA needs to send BRR message to all of these MNs at the same time, it presents a new scalability challenge. In other words, this new functionality needs to be evaluated and a study of how the HA handles this very frequent and new phenomena while the HA still supports the proclaimed number of activation rate becomes very necessary; Hope this one is clear! 7. You asked me if the BU/BAK/BRR is more reliable than the BU/BA, well, REGARDLESS!! since you admit that BU/BA is reliable, then that all what we need and looking for. Your proposed enhancement is not needed, however, you can keep it specific to your own implementation. Unless, you still believe that RFC3775 protocol is BROKEN and does NOT handle BU loss!?=20 8. On another note you said: "BRR sent only if at end of lifetime when the BU is not received." ok; Why do you think that the HA needs to send a BRR message to the MN after the MN BCE lifetime has expired. It seems to me that you need to pay close attention to the difference between a MN Home BCE at the HA and a MN BCE at a CN. Please remember that the lifetime of these two are DIFFERENT! And consequently what is applicable to the handling of BCE at the CN is not necessarily TRUE for the MN home BCE. One more time, an expiry of the BCE at the CN means RO with that CN is lost but the MN is still reachable via the HA BCE! 9. You also said: "No, keep the suggested lifetime field in BA and process it as usual."; excellent! Why then we need to introduce this new functionality to do the same thing which is done by the BU/BA mechanism? 10. In reference to how the use of BRR is more reliable, you also said: "A form of three-way handshake is better reliability than a two-way exchange."; Man, it seems that you always tends to think of success scenarios! You just said that the HA would send the BRR after the BCE lifetime expires, well, let me add one more thing and the MN is probably gone home and no longer there. What kind of reliability you are achieving by sending a BRR for a MN which is probably not there. This will be the vast majority of the scenarios that your BRR will be addressing anyway. Let me ask one more time, do you still think that is a better reliability? :) 11. You seem to understand that supporting BRR message at the HA nothing but sending a BRR message! This is unfortunate! Supporting BRR is far more complex and a new functionality than you have in mind and you ever thought! Just as a reminder, All RFC3775 HA operations and state machines is processing a request that generates a reply in some form of Ack! Do you understand what does that mean and its difference from supporting BRR?! Please think again. 12. However, if you are proposing that the MN is not supposed to send a BU to renew its BCE lifetime except after it receives a BRR message from its HA, then that probably a different discussion that needs another round which I am not willing to be part of and I consider it a waste of time :-)))) 13. You also said: "I meant to say that the effect of BRR being specified and implemented for CN is more reliable BCE at CN. Let's have the same level of reliability at HA." Man! Read the above. You seem not to understand the difference! 14. You also said: "Or maybe we just want to stress that some HA implementations do BRR. Or do we want to forbid HA implementations to do BRR." Again, I am not sure if you realize the difference in the BRR applicability to CN BCE vs. HA BCE. IMO, the usecase you presented is not worth to be discussed unless you believe and can prove that RFC3775 protocol is BROKEN and does not handle BU loss! 15. In your explanation of your earlier comment of "and thus reduces the non-bound time from the entire lifetime to much less" You also said: "If the BU is lost then MN will send another BU at the end of the current lifetime. Instead of waiting for the current lifetime to expire it could be triggered by a BRR received from the HA." :-((((=20 well, that is really an optimization for a HA implementation!=20 Your statement is contradictory to what you said earlier. You said that BRR is sent after the BCE lifetime expires and here you said that the HA would send a BRR before the BCE expires. How the HA one time decides to send a BRR before the end of BCE and some time after the lifetime expires. On the other hand, why the BU/BA mechanism does not work for the BU loss? You MUST explain why you think that it does NOT work? Do you mean that the MN will send one single BU and that is it! Do you assume that the MN does not use retransmission? Also, you are assuming that the MN will wait until the last second of its BCE lifetime and then send a BU!? On the other hand, have you ever heard of the Binding Refresh Advice mobility option? Does the testing client in your test bed understand this option, what about the HA does it support that option? Please take a look and try to understand the value of this option. May be after reading about it you would find what is missing? IMO, all reliable MIP6 clients would initiate their BCE lifetime refresh registration before the end of the home BCE lifetime! 16. In reference to RFC3775 text supporting your understanding of the CN being a HA you said: " Right... difficult to find right now..." Cool take your time and when you find it, please let me know. BTW: That is an important piece of your reasoning for supporting this functionality:) No? 17. finally you said: "When do we discuss BErr? (Binding Error)" Probably after you show that you understand the difference in applicability of BRR on the MN BCE at CN vs. MN BCE at HA. Cheers! Ahmad >=20 > > and the HA needs to send a BRR message and not only that but=20 > > retransmits those messages until a BU is received from each one of=20 > > these MNs? >=20 > The BRR is sent only if the BU is not received at HA the end=20 > of the lifetime. It is not _always_ sent. That is current=20 > behaviour of CN. >=20 > > 3. Personally, I wont agree to such functionality because=20 > Home Agent=20 > > acts as a server offering a MIP6 mobility service to multiple MNs=20 > > governed by a MIP6 protocol which offers a reliable mechanism for=20 > > updating the MN BCE lifetime at the HA. >=20 > BU/BAck is reliable - BU/BAck/BRR is more reliable. Would you agree? >=20 > > 4. Let us assume for the sake of argument that this new=20 > functionality =20 > > is supported by the HA, what is the impact: 4.1. Can you=20 > imagine the =20 > > unnecessary traffic that is generated for no reason. >=20 > No, no unnecessary traffic. BRR sent only if at end of=20 > lifetime the BU is not received. >=20 > > 4.2. What is going to be the MN processing when it receives such a=20 > > message? All current RFC3775 text talks about a BRR coming from the=20 > > CN. Is there going to be a difference in there? >=20 > No difference. >=20 > > 4.3. How MN would recognize that this message is related to=20 > MN BCE at =20 > > the HA? >=20 > It doesn't need to distinguish this - why do you think it=20 > should distinguish? (if it wants so then it has the HA=20 > address thus it can answer the q you raise). >=20 > > 4.4. Backward compatibility, How, this would work for MN which only=20 > > supports BRR from the CN? >=20 > How does MN know BRR is from CN and not from HA? I don't=20 > think MNs implement BRR such as to be _only_ from CN. It=20 > can't distinguish the BRR coming from CN, it just sees an IP address. >=20 > > 4.5. Finally, if this procedure is adopted, are we going to=20 > deprecate =20 > > the existing one using lifetime field in BA, etc? 4.6. etc. >=20 > No, keep the suggested lifetime field in BA and process it as usual. >=20 > >> I see it offering better reliability: even if the critical=20 > BU is lost=20 > >> the HA requests the BU anew (BRR) and thus reduces the=20 > non-bound time=20 > >> from the entire lifetime to much less. > >=20 > > [Ahmad] 1. Wow! Are you calling this a better reliability? What is=20 > > your definition of reliability then? >=20 > A form of three-way handshake is better reliability than a=20 > two-way exchange. >=20 > > 2. Are you suggesting that the current RFC3775 protocol is=20 > BROKEN and =20 > > does not address BU loss? >=20 > No, not suggesting so. I suggest in certain conditions when=20 > the BU is lost, the HA using BRR leads to shorter wait for=20 > BCE update (shorter than the current BU waiting for the next=20 > lifetime) - less interruption at MN. >=20 > > 3. I do not understand what you mean by: "and thus reduces the=20 > > non-bound time from the entire lifetime to much less" Can=20 > you please =20 > > elaborate more and explain? >=20 > If the BU is lost then MN will send another BU at the end of=20 > the current lifetime. Instead of waiting for the current=20 > lifetime to expire it could be triggered by a BRR received=20 > from the HA. >=20 > No difference between CN and HA here. >=20 > >>> 6. On the other hand, CN maintains a limited number of BCE for=20 > >>> specific mobile nodes and more importantly if the MN=20 > decides NOT to=20 > >>> renew its BCE with a specific CN, the MN continues to be=20 > reachable=20 > >>> by other CNs at its HoA and CoA via its Home Agent BCE. > >>> In other words, a MN binding with another CN represent=20 > the service=20 > >>> (RO) between MN<->CN ONLY, however, in the case of HA it =20 > represents=20 > >>> the MN's MIP6 service and access to the whole internet.=20 > Which also=20 > >>> administratively governed. i.e. if the MN does not renew its BCE,=20 > >>> then that is a clear indication for the HA to delete the MN BCE. > >>=20 > >> Not before it sends a BRR and waits for an answer to that. > >=20 > > [Ahmad] What do you mean here, MN does not send a BU to refresh its=20 > > Home BCE lifetime except after receiving a BRR? >=20 > No, I meant it sends its BU as usual, (I think 4s before the=20 > lifetime expires or so). >=20 > >>> 7. Finally, the fact that RFC3775 mentions that CN could=20 > be a HA, =20 > >>> does not mean that the HA application at such a node need=20 > to support=20 > >>> BRR. > >>=20 > >> That's your reading. Other implementers read it in the way I said. > >>=20 > >>=20 > >>=20 > >>=20 > >=20 > > [Ahmad] Excellent. Please cut and paste here the text where it=20 > > supports your understanding? >=20 > Right... difficult to find right now... >=20 > >>> IMO, such a node could act as a CN for some MNs and a HA=20 > for others.=20 > >>> Then, it is normal for this CN/HA node to support BRR for=20 > those MN=20 > >>> which is serving as a CN but not a HA. > >>=20 > >> Is a HA a "CN" when it is the dst field of the BU? > >=20 > > [Ahmad] I am not sure what you are trying to say here, but for now,=20 > > let us focus on the real issue as highlighted above. Thanks! >=20 > I meant to say that the effect of BRR being specified and=20 > implemented for CN is more reliable BCE at CN. Let's have=20 > the same level of reliability at HA. >=20 > Or maybe we just want to stress that some HA implementations=20 > do BRR. Or do we want to forbid HA implementations to do BRR. >=20 > When do we discuss BErr? (Binding Error) >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From DonniedaytimeMcdaniel@photofriday.com Sat Dec 22 08:15:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J64C1-0003R8-5W; Sat, 22 Dec 2007 08:15:05 -0500 Received: from host86-128-164-96.range86-128.btcentralplus.com ([86.128.164.96] helo=acerfcafbfa90d.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J64C0-00005e-KW; Sat, 22 Dec 2007 08:15:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host45256765.photofriday.com (8.13.1/8.13.1) with SMTP id ysQ1AUGH90.517868.aWj.pDS.8358058483076 for ; Sat, 22 Dec 2007 13:13:24 +0000 Message-ID: <1a2ee01c8449c$a96cb5c0$4001a8c0@acerfcafbfa90d> From: "Evan Munoz" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1A2EA_01C8449C.A96CB5C0-- From LeonelosteopathicMoon@aamco.com Sat Dec 22 11:54:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67ce-0005Rt-RP; Sat, 22 Dec 2007 11:54:48 -0500 Received: from spc2-leed12-0-0-cust243.seac.broadband.ntl.com ([80.2.84.244] helo=retestrak) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J67ce-0005DS-GQ; Sat, 22 Dec 2007 11:54:48 -0500 Received: from collide by aamco.com with SMTP id dbX5YUxavQ for ; Sat, 22 Dec 2007 16:58:51 -0100 From: "Blair Berg" To: Subject: When you join? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. We have it all! Get your bonus and walk the red carpet to winnings and fun. Play your favorite games from the comfort of your home, USA players ARE included! http://worldcasinod.cn/ From hien-boomsma@jobfilings.com Sat Dec 22 12:15:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J67wD-0004Jt-Bj for nemo-archive@lists.ietf.org; Sat, 22 Dec 2007 12:15:01 -0500 Received: from host41-249-dynamic.6-79-r.retail.telecomitalia.it ([79.6.249.41] helo=host19-251-dynamic.7-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J67wC-0005bT-K5 for nemo-archive@lists.ietf.org; Sat, 22 Dec 2007 12:15:01 -0500 Received: from s-gril1w5il7ggp ([117.161.142.49]:22786 "EHLO s-gril1w5il7ggp" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host19-251-dynamic.7-79-r.retail.telecomitalia.it with ESMTP id S22BEUHDKJBMNYBK (ORCPT ); Sat, 22 Dec 2007 18:15:35 +0100 Message-ID: <3033577C.5A5490B7@jobfilings.com> Date: Sat, 22 Dec 2007 18:15:03 +0100 From: "hien boomsma" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: kissalaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Why wait? you can have a huge dong now and have the best sex of your
life! http://www.jusous.com/
From LamontscramHodge@rulers.org Sun Dec 23 02:35:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6LMq-0003mf-QV; Sun, 23 Dec 2007 02:35:24 -0500 Received: from [190.42.35.221] (helo=home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6LMo-0008W2-Ru; Sun, 23 Dec 2007 02:35:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host66483914.rulers.org (8.13.1/8.13.1) with SMTP id 3QnTo9TX40.539862.7AV.z0u.6572950140554 for ; Sun, 23 Dec 2007 02:33:26 +0500 Message-ID: <4b67501c84536$3091a120$0301a8c0@home> From: "Emmanuel Vazquez" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4B671_01C84536.3091A120-- From Dana-Mickelson@bamboo.org.uk Sun Dec 23 11:07:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6TMt-0001ls-Qu for nemo-archive@lists.ietf.org; Sun, 23 Dec 2007 11:07:59 -0500 Received: from host-87-242-41-237.prtelecom.hu ([87.242.41.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6TMt-0006rP-Bm for nemo-archive@lists.ietf.org; Sun, 23 Dec 2007 11:07:59 -0500 Received: by 10.226.43.85 with SMTP id vYVtyvnxCDEZb; Sun, 23 Dec 2007 17:08:02 +0100 (GMT) Received: by 192.168.158.185 with SMTP id XRDSwtuExyqwBd.2187521314428; Sun, 23 Dec 2007 17:08:00 +0100 (GMT) Message-ID: Date: Sun, 23 Dec 2007 17:07:57 +0100 From: "Dana Mickelson" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: ssedaot Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071222-0, 2007.12.22), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Always wanted to have a monster cock? Use our medicine, and you'll soon will be splited to two area codes, because of the size of your cock - http://www.eighwert.com/ From BradleywastefulCrawford@boston.com Sun Dec 23 16:12:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Y7z-0005DZ-U1; Sun, 23 Dec 2007 16:12:55 -0500 Received: from 209.red-83-46-254.dynamicip.rima-tde.net ([83.46.254.209] helo=annasola) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6Y7z-0004QR-BV; Sun, 23 Dec 2007 16:12:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host75369194.boston.com (8.13.1/8.13.1) with SMTP id aZlQdzeq34.853832.FZ9.XoD.0196788454850 for ; Sun, 23 Dec 2007 22:11:59 -0100 Message-ID: <26aa0601c845a8$8e1e93d0$2101a8c0@annasola> From: "Lee Porter" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_26AA02_01C845A8.8E1E93D0-- From StancontextualHensley@free-web-browsers.com Sun Dec 23 19:35:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6bHb-0008V5-4r; Sun, 23 Dec 2007 19:35:03 -0500 Received: from 123.red-88-15-58.dynamicip.rima-tde.net ([88.15.58.123] helo=d453fj2j) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6bHZ-0000Iu-Rd; Sun, 23 Dec 2007 19:35:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host00131024.free-web-browsers.com (8.13.1/8.13.1) with SMTP id QwQxRMJp57.566421.otJ.yll.7277850879662 for ; Mon, 24 Dec 2007 01:34:31 -0100 Message-ID: <547d01c845c4$d07bf3f0$2101a8c0@D453FJ2J> From: "Leonardo Short" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_5479_01C845C4.D07BF3F0-- From philb@terkade.com Sun Dec 23 22:47:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6eI1-0002YK-Ao; Sun, 23 Dec 2007 22:47:41 -0500 Received: from [116.75.65.107] (helo=home) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6eHy-0003rT-RJ; Sun, 23 Dec 2007 22:47:41 -0500 Received: from [116.75.65.107] by mail.terkade.com; , 23 Dec 2007 19:46:44 -0800 Message-ID: <01c8459c$8bbc3040$6b414b74@philb> From: "Moreland" To: Subject: Saw your profile Date: , 23 Dec 2007 19:46:44 -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 4.71.2244.8 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2244.8 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hey you I read your profile on-line a few minutes ago and you seem intresting email me at Cherry@GloryWayChurchx.info and I will reply with a Picture and Info about me right away I will stay online and wait for your email Talk to you soon From TrevorbrandenburgSchultz@cbsnews.com Mon Dec 24 10:15:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6p21-0001ao-SC; Mon, 24 Dec 2007 10:15:53 -0500 Received: from e180036158.adsl.alicedsl.de ([85.180.36.158] helo=aogb198fd51096) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6p21-00025G-IO; Mon, 24 Dec 2007 10:15:53 -0500 Received: from whither by cbsnews.com with SMTP id YPdTjiBHKo for ; Mon, 24 Dec 2007 16:14:59 -0100 From: "Arturo Curry" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6p2q-00028r-EZ; Mon, 24 Dec 2007 10:16:44 -0500 Received: from 201-67-70-66.cpece700.dsl.brasiltelecom.net.br ([201.67.70.66] helo=servidor) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6p2p-00026r-DO; Mon, 24 Dec 2007 10:16:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host99978554.outdoordemands.com (8.13.1/8.13.1) with SMTP id dXZVaU7K17.578470.JeW.dC9.4725187537279 for ; Mon, 24 Dec 2007 13:11:45 +0300 Message-ID: <19b5aa01c8463f$5ab00c30$0300000a@servidor> From: "Donnie Parks" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_19B5A6_01C8463F.5AB00C30-- From Raney-kostash@andrewgmorrow.com Mon Dec 24 12:02:14 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6qgw-0007a1-F0 for nemo-archive@lists.ietf.org; Mon, 24 Dec 2007 12:02:14 -0500 Received: from host137-131-dynamic.7-87-r.retail.telecomitalia.it ([87.7.131.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6qgv-0004rQ-V3 for nemo-archive@lists.ietf.org; Mon, 24 Dec 2007 12:02:14 -0500 Received: from acer-dac357703e ([176.157.110.70]:25870 "EHLO acer-dac357703e" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host111-203-dynamic.55-82-r.retail.telecomitalia.it with ESMTP id S22BUEYBOFKKNFXS (ORCPT ); Mon, 24 Dec 2007 18:02:41 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 18:02:17 +0100 To: nemo-archive@lists.ietf.org From: "Raney kostash" Subject: e'egag'e Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: avast! (VPS 071224-0, 24/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Never be the same again after taking VPXL Herbal - add 3 inches to your penis,and a world of difference to your life. http://pquerttol.com/ From yxew@boothillinn.com Mon Dec 24 12:33:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6rBJ-00013p-Me; Mon, 24 Dec 2007 12:33:37 -0500 Received: from [190.41.96.186] (helo=[190.41.96.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J6rBH-0005jF-PK; Mon, 24 Dec 2007 12:33:37 -0500 Received: from [190.41.96.186] by mailstore1.secureserver.net; Mon, 24 Dec 2007 12:33:34 -0500 From: "Fran Pena" To: Subject: Fran - 100% results. Date: Mon, 24 Dec 2007 12:33:34 -0500 Message-ID: <01c84629$32cda300$ba6029be@yxew> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C84629.32CDA300" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Score: 2.4 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C84629.32CDA300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It`s not surprise that more than 600,000 medic choice the prescription drug Viagra for their patients with erectile dysfunction(ED).Fact is, when taken correctly, Viagra works for most men. Studies show that it works for up to 4 out of 5 men (versus 1 out of 4 on sugar pill).Viagra improves erections for most men no matter how long they have had ED, what caused it, how often they have it, or how old they are. We provide you 100% results after using our products.See our site! ------=_NextPart_000_000E_01C84629.32CDA300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It`s not surprise that more than 600,000 medic choice the prescriptio= n drug Viagra for their patients with erectile dysfunction(ED).


Fact is, when taken correctly, Viagra works for most men. Studies show= that it works for up to 4 out of 5 men (versus 1 out of 4 on sugar pill)=


Viagra improves erections for most men no matter how long they have ha= d ED, what caused it, how often they have it, or how old they are. We pro= vide you 100% results after using our products.


See our site! ------=_NextPart_000_000E_01C84629.32CDA300-- From DavisbryophyteWalls@dazzlelace.com Mon Dec 24 13:31:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6s4w-0004Z1-CQ; Mon, 24 Dec 2007 13:31:06 -0500 Received: from e182031152.adsl.alicedsl.de ([85.182.31.152] helo=mutta4iqaqgrts) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6s4v-0007GX-VN; Mon, 24 Dec 2007 13:31:06 -0500 Received: from purpose by dazzlelace.com with SMTP id x8j7Fn4lo9 for ; Mon, 24 Dec 2007 19:30:32 -0100 From: "Cole Walls" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6yED-0001Xr-Rj; Mon, 24 Dec 2007 20:05:05 -0500 Received: from dyn-83-157-43-243.ppp.tiscali.fr ([83.157.43.243] helo=saadhoucin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J6yED-00077v-CG; Mon, 24 Dec 2007 20:05:05 -0500 Received: from renal by merriam-webster.com with SMTP id xYadc45Xm2 for ; Tue, 25 Dec 2007 02:04:42 -0100 From: "Winifred Huerta" To: Subject: USA players ARE welcome! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Best offer in gambling history . Travel no further than your screen and get your free $999 Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. We know how to treat our players - how about a $999 welcome bonmus when you join? http://worldacasino.cn/ From dpeltz@sistenirishpub.com Mon Dec 24 23:24:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J71Lc-0000z1-JH; Mon, 24 Dec 2007 23:24:56 -0500 Received: from [212.45.1.243] (helo=ns.luxair.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J71Lb-0001qr-8a; Mon, 24 Dec 2007 23:24:56 -0500 Received: from [212.45.1.243] by mail.sistenirishpub.com; Tue, 25 Dec 2007 07:24:00 +0300 Date: Tue, 25 Dec 2007 07:24:00 +0300 From: "Carla Coon" X-Mailer: The Bat! (v2.11) Educational Reply-To: dpeltz@sistenirishpub.com X-Priority: 3 (Normal) Message-ID: <020151929.22479070504721@sistenirishpub.com> To: mpls-request@lists.ietf.org Subject: Vacuum MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Grow your Manhood 3 inches or more Safe and Fast and your wife or girlfriend will Thank you! http://foasetss.com From MauracontraryValentin@foxnews.com Mon Dec 24 23:47:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J71he-0006W2-TX; Mon, 24 Dec 2007 23:47:42 -0500 Received: from s01060018397c2f22.vs.shawcable.net ([70.71.2.131] helo=d461v5c1.vs.shawcable.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J71he-0002DI-KM; Mon, 24 Dec 2007 23:47:42 -0500 Received: from tread by foxnews.com with SMTP id aKGkt0cLIf for ; Mon, 24 Dec 2007 20:46:50 +0800 From: "Maura Tabor" To: Subject: Download our casino in 20 seconds to get $999 richer when you join. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de If you're in the US or anywhere else, join your new casino paradise. Travel no further than your screen and get your free $999 We pay you to play. Our safe, secure games will get you smiling when you start seeing dollars pouring in. http://worldacasino.cn/ From KaryngodlikeDarling@blogchina.com Mon Dec 24 23:50:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J71k2-00006U-BT; Mon, 24 Dec 2007 23:50:10 -0500 Received: from cpc2-ches1-0-0-cust333.lutn.cable.ntl.com ([81.99.185.78] helo=dellac7db5213c) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J71k1-0002Fj-Pe; Mon, 24 Dec 2007 23:50:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host76032000.blogchina.com (8.13.1/8.13.1) with SMTP id Xaye7rEF33.657070.CuQ.Lor.2586667882005 for ; Tue, 25 Dec 2007 04:49:42 +0000 Message-ID: <100a0401c846b1$9f1c5910$4eb96351@dellac7db5213c> From: "Lelia Valentin" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_100A00_01C846B1.9F1C5910-- From telephone.hq@undp.org Tue Dec 25 05:23:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J76x4-0002dp-1V; Tue, 25 Dec 2007 05:23:58 -0500 Received: from [85.97.180.154] (helo=dsl.dynamic8597180154.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J76x2-0008UL-OR; Tue, 25 Dec 2007 05:23:57 -0500 Received: from [85.97.180.154] by undp.org.mail12.psmtp.com; Tue, 25 Dec 2007 12:23:55 +0200 From: "Colby Hoffman" To: Subject: Colby - 100% results. Date: Tue, 25 Dec 2007 12:23:55 +0200 Message-ID: <01c846f1$041aff80$9ab46155@telephone.hq> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C846F1.041AFF80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C846F1.041AFF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It`s not wonder that more than 600,000 doctors choice the prescription drug Viagra for their patients with erectile dysfunction(ED).Fact is, when taken correctly, Viagra works for most men. Studies show that it works for up to 4 out of 5 men (versus 1 out of 4 on sugar pill).Viagra improves erections for most men no matter how long they have had ED, what caused it, how often they have it, or how old they are. We provide you 100% results after using our products.See our site! ------=_NextPart_000_000E_01C846F1.041AFF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It`s not wonder that more than 600,000 doctors choice the prescriptio= n drug Viagra for their patients with erectile dysfunction(ED).


Fact is, when taken correctly, Viagra works for most men. Studies show= that it works for up to 4 out of 5 men (versus 1 out of 4 on sugar pill)=


Viagra improves erections for most men no matter how long they have ha= d ED, what caused it, how often they have it, or how old they are. We pro= vide you 100% results after using our products.


See our site! ------=_NextPart_000_000E_01C846F1.041AFF80-- From NormandcandyAlbert@yahoo.com Tue Dec 25 07:43:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J797c-0003B2-Pq; Tue, 25 Dec 2007 07:43:00 -0500 Received: from p54afd45a.dip.t-dialin.net ([84.175.212.90] helo=weidel) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J797c-0003Og-F2; Tue, 25 Dec 2007 07:43:00 -0500 Received: from oceanic by yahoo.com with SMTP id ekVMxY2T1T for ; Tue, 25 Dec 2007 13:42:47 -0100 From: "Antwan Jarvis" To: Subject: Get your bonus and walk the red carpet to winnings and fun. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Play your favorite games and get $999 welcome bonus. Get to know your new casino home! Travel no further than your screen and get your free $999 Travel no further than your screen and get your free $999 http://worldacasino.com.cn/ From ViolethermosaVickers@suntimes.com Tue Dec 25 11:11:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7CNZ-0007Ps-H6; Tue, 25 Dec 2007 11:11:41 -0500 Received: from 62.43.53.45.dyn.user.ono.com ([62.43.53.45] helo=acerd918637222) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7CNZ-00016O-65; Tue, 25 Dec 2007 11:11:41 -0500 Received: from adverse by suntimes.com with SMTP id LNei8kNc4H for ; Tue, 25 Dec 2007 17:11:17 -0100 From: "Bobbie Piper" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7FRU-0001AS-BT for nemo-archive@lists.ietf.org; Tue, 25 Dec 2007 14:27:56 -0500 Received: from [151.70.103.48] (helo=host135-99-static.4-79-b.business.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7FRT-0005om-Is for nemo-archive@lists.ietf.org; Tue, 25 Dec 2007 14:27:56 -0500 Received: from daipol ([195.150.140.6]:18933 "EHLO daipol" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host135-99-static.4-79-b.business.telecomitalia.it with ESMTP id S22EXKIUWNWAIEGS (ORCPT ); Tue, 25 Dec 2007 20:28:05 +0100 Message-ID: Date: Tue, 25 Dec 2007 20:27:53 +0100 From: "Monika Gerham" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: atl Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Your stunning blonde will find you a stunner! http://www.wuftidt.com/
From ToddsteamAlexander@washingtonpost.com Tue Dec 25 17:44:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7IW8-00014J-I1; Tue, 25 Dec 2007 17:44:56 -0500 Received: from [190.161.58.121] (helo=casa01jnzee4l8) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7IW8-0002On-6b; Tue, 25 Dec 2007 17:44:56 -0500 Received: from rebutting by washingtonpost.com with SMTP id llL5JDV1ur for ; Tue, 25 Dec 2007 19:44:27 +0400 From: "Shawn Coleman" To: Cc: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QES-00061u-Rt; Wed, 26 Dec 2007 01:59:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QEQ-00061p-Sb for mext@ietf.org; Wed, 26 Dec 2007 01:59:10 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7QEQ-0003XX-2F for mext@ietf.org; Wed, 26 Dec 2007 01:59:10 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1676831rvb.49 for ; Tue, 25 Dec 2007 22:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; bh=g2NgZuuiBWKxLVEp9Q65hKwH/gKqKBAWI3D+DR0i/Oo=; b=aXvAcfaDOzgE5P5I1OfQOxkSYQTh2FAau+Xn88S8UZ4mb3tqK7+o93UJ+Rpl9BQniN1Xtio+ecyuQn5QoNbFqevbBe43suUiOVq/rYp/GeaECmfsTsftzJpa1zSUNFGyxVulSafNbuJzFhJ6Tbnv/KmJU4juMElZsfshWiezgWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; b=fI2gafYZErMUhrjQe75/3bRAEOsAXPhF1Nvl0qL9U0fvE7LT6cH+vCFpe0RwYVbSYSremrl3wTR9tBMfcO2mZpCNES1fDAbWaGV4XpmmqYRbXKQUm+keGRyUXhSNban/EM3x9oHIKifESTQgjG8rOP8StVW12HHqFGECE7BmbaY= Received: by 10.141.23.7 with SMTP id a7mr3135134rvj.5.1198652349484; Tue, 25 Dec 2007 22:59:09 -0800 (PST) Received: from ?10.0.1.198? ( [219.110.221.232]) by mx.google.com with ESMTPS id b24sm2141623rvf.1.2007.12.25.22.59.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2007 22:59:08 -0800 (PST) Message-Id: <37730499-6C97-4557-B5BE-F7035CDC14DF@gmail.com> From: RYUJI WAKIKAWA To: mext@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 26 Dec 2007 15:59:05 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [MEXT] DSMIP applicability to MCoA X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, Here is the proposed text of DSMIP support on MCoA. thanks ryuji --------------------------------------------------------------------------------------------------- - DSMIP applicability DSMIP extends Mobile IPv6 to register IPv4 care-of address, IPv4 home address or both. The following scenarios can be supported by DSMIP and MCoA. - IPv6/v4 HoA and IPv4/v6 CoAs - IPv6/v4 HoA and IPv4 CoAs - IPv6/v4 HoA and IPv6 CoAs - IPv6 HoA and IPv4/v6 CoAs - IPv6 HoA and IPv4 CoAs - BID Sub-option Format Change 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+ | Type = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Unique ID (BID) | Status |C|O|H|D|Reservd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + + care-of address (CoA) + + + +---------------------------------------------------------------+ Figure 1: BID Sub-Option A new D flag is reserved for DSMIP. When D flag is set, the CoA address filed MUST be set to IPv4 Care-of Address. - IPv4 CoA registration In DSMIP, the binding update and acknowledgment exchange is used to detect NAT. Thus, when a mobile node registers its IPv4 CoA bound to IPv6 HoA, it MUST first attempts to send BU with BID sub-option independently. The bulk registration MUST NOT be used for the first binding update of the IPv4 CoA. The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Fig-1. It is similar to [DSMIP] except for using BID sub-option instead of IPv4 CoA option. IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header IPv6 header (src=V6HoA, dst=HAADDR) ESP Header Mobility header -BU Mobility Options - Binding Identifier sub-option (IPv4 CoA) Figure 1: Initial Binding Update for IPv4 CoA When the home agent detects NAT for the received binding update, it MUST send the NAT detection option in the Binding Acknowledgment. Whenever the NAT detection option is found, the mobile node MUST NOT use the bulk registration for the IPv4 CoA. Otherwise, it can send the IPv4 CoA with other CoAs in the bulk registration mode. How to handle NAT is same as [DSMIP]. If no NAT is detected, the mobile node can update the IPv4 CoA by using BULK registration. The mobile node can register the IPv4 CoA with other CoAs. Fig-2 shows the binding update format when the mobile node sends a Binding Update from one of its IPv6 CoAs. If the mobile node sends a BU from IPv4 CoA, it MUST follows the Fig-1 and store more BID sub-options in the mobility options field. Note that it must be registered by a no bulk Binding registration, whenever the IPv4 CoA is changed. IPv6 header (src=V6CoA, dst=HAADDR) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier sub-option (IPv6/v4 CoA) - Binding Identifier sub-option (IPv6/v4 CoA) - ... Figure 2: Binding Bulk Registration for IPv4 CoA If the IPv4 CoA is successfully registered, the mobile node set up a relevant tunnel to the home agent according to [DSMIP]. When the home agent rejects the IPv4 CoA, it MUST stores the error code value in the Status field of the BID sub-option and MUST sends the binding acknowledgment and all the received BID sub-options to the mobile node. In this case, the IPv4 address acknowledgment option MUST NOT be included in the Binding Acknowledgment. All the error codes for IPv4 care-of address registration MUST be stored in the Status field of the BID sub-option. The IPv4 address acknowledgment option is used only when a mobile node requests IPv4 home address management. - IPv4 HoA management When the mobile node obtains an IPv4 home address, it MUST stores the IPv4 Home Address option in the Binding Update. If the home agent accepts the binding update, the mobile node can also registers multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot binding different set of care-of addresses to each home address. The home agent MUST returns a binding acknowledgment and IPv4 address acknowledgment option to the mobile node only when a mobile node requests IPv4 home address mobility management. In this case, this option MUST be presented before any BID options. The status field of the IPv4 address acknowledgment option contains only the error code regarding IPv4 home address management. The error value of the IPv4 CoA registration MUST be stored in the BID sub-option. --------------------------------------------------------------------------------------------------- _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 26 02:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QQY-0003Ie-KK; Wed, 26 Dec 2007 02:11:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7QQX-0003Em-2o for mext@ietf.org; Wed, 26 Dec 2007 02:11:41 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7QQW-0003pv-BA for mext@ietf.org; Wed, 26 Dec 2007 02:11:40 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1679565rvb.49 for ; Tue, 25 Dec 2007 23:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; bh=Gg5wB0QMTtzj3cTb9q1x25ZBSkTsONIr6QzfY8js3wE=; b=XhouAUhNc2AguDHHIIlKF5+lmbx0m1iPrIKBrhkRG5Ho6FeFF/48zyWLB5fT7HtF4ldQLzOxQmPTrhjonfM5+5Ciu1DpvuClWcNadCw3qKfQ1xQOCqbzVIFA9n9E08qGxc7zKkW9djPdr3QS43zdJFYzHLCOtolW+O6dewT4hdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject:mime-version:date:x-mailer; b=U5le7jtj/iAjLbnthXehPlAs9Wbe7m7JIpVCCfKV97VzFhqDeh7fAR2kVtTdBl7O6oydTcR2ealLcaECICtAA1A3ESqWL1rldSLTgkDag0nJRUWzTYBc2wAsegT4JnoL03LakRBkJVPSGVlHx6gvFSZ9yrvxUOITgXFXPgaRpNI= Received: by 10.140.163.3 with SMTP id l3mr3111116rve.240.1198653099639; Tue, 25 Dec 2007 23:11:39 -0800 (PST) Received: from ?10.0.1.198? ( [219.110.221.232]) by mx.google.com with ESMTPS id b21sm2374383rvf.34.2007.12.25.23.11.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2007 23:11:38 -0800 (PST) Message-Id: <03DA77CC-836A-470F-9347-0F2DD8045C05@gmail.com> From: RYUJI WAKIKAWA To: mext@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 26 Dec 2007 16:11:35 +0900 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [MEXT] Use of simultaneous home and foreign interfaces X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi all, This is the proposed text for MCoA. thanks, ryuji ------------------------------------------------------------------------------------------------ When a mobile node returns home with other interfaces active attached to foreign link, it MUST decide one of following operations: 1. it returns home and de-registers all the bindings 2. it returns home and shutdown the interface attached to the home link. The binding of the old CoA bound to that interface MUST be deleted from one of active interface attached to the foreign link. 3. it returns home and continue using all the interfaces attached to both foreign and home links. In order to achieve the scenario3, the home agent MUST intercept all the packets meant for the mobile node and would decide whether to send the traffic directly to the home address on the link or tunnel to the CoA that the mobile node has registered at the home agent. The home agent would make this decision based on the type of packet/flow. The delicate part would be to create a neighbor cache entry for the mobile node so that the home agent can deliver the packet on-link. The home agent would need to know the L2 address of the interface with which the mobile node is attached to the home link. In order to create the neighbor cache entry for the mobile node, following operations are required. The mobile node sends a de-registration binding update to the home agent from the interface attached to the home link. In the Binding Update, the BID sub-option must be stored for the BID assigned to the interface. The H (Home/Foreign IFs active) flag MUST be set in the BID sub-option. When the H flag is appeared, the home agent learns that the mobile node continue using interfaces attached to both foreign and home links. If H flag is unset, the home agent deletes either all the bindings or the binding corresponding to the BID (i.e. scenario 1 or 2). When the home agent sends the Binding Acknowledgment, it MUST stores one of two new status values in the BID sub-option depending on home agent configuration at the home link. The new values are: TBD-A (under 128): NDP is permitted for HoA at home link TBD-B (under 128): NDP is prohibited for HoA at home link When the home agent is solo router at the home link, it can intercept all the packets by IP routing without proxy NDP. It stops proxy ND for the requested HoA and reply the TBD-A value to the mobile node. The neighbor cache entry for the mobile node is created by NDP operation (i.e. NS/NA exchange). On the other hand, if it is not solo router, it MUST continue defending HoA by proxy NDP to capture all the mobile node's traffic. The home agent, then, returns TBD-B value in the BID sub-option. The home agent also requires to learn the mobile node's layer2 address (i.e. MAC address) during this binding de-registration. I can keep the learned layer2 address as the neighbor cache entry for the mobile node so that it can construct the Ethernet header for the packets meant for the mobile node and forwards them directly to the mobile node's interface attached to the home link. According to [RFC3775], the mobile node MUST NOT assigns the HoA to the interface attached to the home link and MUST NOT attempt NDP operations for the HoA. It MUST NOT send and reply to Neighbor Solicitation for the HoA. The HoA must be tentative address at this moment until it receives Binding Acknowledgment with success status value. When it receives the binding acknowledgment and BID sub-option, it MUST assign HoA at the interface attached to the home link according to the status field of the BID. If the value is TBD-A, it can start defending HoA by NDP as a regular IPv6 operation and let the HoA as valid IPv6 address. The home agent can create neighbor cache entry for the mobile node by NS and NA exchange as the regular IPv6. If the home agent receives the TBD-B, it MUST NOT defends its HoA at the home link by ND. When the mobile node sends packets from the interface attached to the home link, it MUST learn the layer2 address (i.e. MAC address) of the next hope (i.e. default router, it can be home agent) during the binding de-registration and construct the packet including Ethernet header with the learned home agent's layer2 address. ------------------------------------------------------------------------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From LilatightToney@littlegreenfootballs.com Wed Dec 26 05:31:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7TXw-00051D-FY; Wed, 26 Dec 2007 05:31:32 -0500 Received: from pool-72-82-7-83.prvdri.east.verizon.net ([72.82.7.83] helo=hppav.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7TXr-0007qJ-E3; Wed, 26 Dec 2007 05:31:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host75763799.littlegreenfootballs.com (8.13.1/8.13.1) with SMTP id N84wAeR190.077629.Uqf.QRw.1765174702996 for ; Wed, 26 Dec 2007 05:20:19 +0500 Message-ID: From: "Patti Mead" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_B8421_01C847AA.603CF840-- From mext-bounces@ietf.org Wed Dec 26 09:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Xaq-0006Gh-Qj; Wed, 26 Dec 2007 09:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Xap-0006Gb-F6 for mext@ietf.org; Wed, 26 Dec 2007 09:50:47 -0500 Received: from smtp01.uc3m.es ([163.117.176.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7Xan-0001Kb-PC for mext@ietf.org; Wed, 26 Dec 2007 09:50:47 -0500 Received: from [200.40.5.160] (unknown [200.40.5.160])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp01.uc3m.es (Postfix) with ESMTP id E0B162B274Ffor ; Wed, 26 Dec 2007 15:50:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <3E023C2D-BBC2-4195-9D26-CEF0481E4F56@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mext@ietf.org From: marcelo bagnulo braun Date: Wed, 26 Dec 2007 15:49:28 +0100 X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.4095 TC:02 TRN:32 TV:5.0.1023(15630.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [MEXT] Accommodation and other logistic issues for MEXT interim meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, I attach some information for the mext interim meeting in madrid MEXT interim meeting DATE: 7,8 feb 2008 Location: University Carlos III de Madrid Escuela Politecnica Superior Av. Universidad 30 28911 - Leganes Madrid, SPAIN In google maps: http://maps.google.es/maps/ms? ie=UTF8&msa=0&msid=104559785229237204753.00043ac94c2c52fb9e658&z=16&om=1 You can find hotel and other accommodation information : http://www.it.uc3m.es/vi/localizacion/alojamiento.htm (Comment: you can either stay near the university in Leganes or in downtown madrid. If you stay near the university, i would reccommend the Tryp Leganes Hotel, which is very close by the university. If you stay in Madrid, i would recommend the NH sur, which is right in front of Atocha train station, and it would take about 20 min train ride to get to the university, without need to change trains. If you need a low budget option, i suggest to stay in the Leganes student residence) If you need i can provide you a contact of a local travel agency, through which you can book the hotel, if you prefer that. Some people may need a visa to get in Spain. Please check that in your local Spanish embassy. In case you need a letter of invitation, please send me an email. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From txi@blonkagri.com Wed Dec 26 10:11:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Xuy-0000Hd-NR; Wed, 26 Dec 2007 10:11:36 -0500 Received: from cmodem-30-133.telecable.com.do ([190.94.30.133] helo=windows-n0ayezi.cpe.tricom.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7Xux-0005tx-JY; Wed, 26 Dec 2007 10:11:36 -0500 Received: from [190.94.30.133] by blonkagri.com; Wed, 26 Dec 2007 21:41:27 +0630 From: "Eric Lujan" To: Subject: Star Date: Wed, 26 Dec 2007 21:41:27 +0630 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QRHY32U92IS44C3L8DQ4W7L3BQ== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: <01c84808$1176dd80$851e5ebe@txi> X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea You know she really likes it the deeper you can perform, help her and yourself out. http://www.Lpsuumees.com hasn’t resolved used in the Java API and lots of liquidation and support in your own code. for many families. From BradexceptionalCastillo@landscaperx.com Wed Dec 26 11:23:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Z2u-0005j3-Nb; Wed, 26 Dec 2007 11:23:52 -0500 Received: from dslb-084-057-150-135.pools.arcor-ip.net ([84.57.150.135] helo=frankd7fb08581) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7Z2u-0007PU-B8; Wed, 26 Dec 2007 11:23:52 -0500 Received: from pragmatic by landscaperx.com with SMTP id MrAGjJCiHa for ; Wed, 26 Dec 2007 17:23:25 -0100 From: "Angel Vasquez" To: , Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Zi1-00030d-JL; Wed, 26 Dec 2007 12:06:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7Zhz-0002vM-CJ for mext@ietf.org; Wed, 26 Dec 2007 12:06:19 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7Zhx-0003uC-Go for mext@ietf.org; Wed, 26 Dec 2007 12:06:19 -0500 Received: from [200.40.5.3] (unknown [200.40.5.3])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id 5BD042B8F04;Wed, 26 Dec 2007 18:06:06 +0100 (CET) In-Reply-To: <4766A1DB.1020007@azairenet.com> References: <4766A1DB.1020007@azairenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7C1C4392-2C09-47BE-9C90-B86C6BA9AAC7@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] DSMIPv6 BU format and RFC 3775 Date: Wed, 26 Dec 2007 17:58:53 +0100 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-30.8260 TC:1F TRN:52 TV:5.0.1023(15630.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mext@ietf.org, 'Martti Kuparinen' , 'Tero Kauppinen' , Hesham Soliman X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, El 17/12/2007, a las 17:20, Vijay Devarapalli escribi=F3: > Hesham Soliman wrote: >> Folks, I received the following question from Tero: >> While reading the current version of DSMIPv6 >> (draft-ietf-mip6-nemo-v4traversal-06) and I came across with one >> sentence which strikes me as odd. >> "4.2. NAT detection and traversal >> NAT detection is done when the initial binding update message =20 >> is sent >> from the mobile node to the home agent. When located in an IPv4-=20= >> only >> foreign link, the mobile node sends the binding update message >> encapsulated in UDP and IPv4. The source address of the IPv6 =20 >> packet >> is the mobile node's IPv6 home address. The destination address is >> the IPv6 address of the home agent. The IPv4 header contains =20 >> the IPv4 >> care-of address in the source address field and the IPv4 =20 >> address of >> the home agent in the destination address field. >> When the home agent receives the encapsulated binding update it >> compares the IPv4 address of the source address field in the IPv4 >> header with the IPv4 address in the source address of the IPv6 >> header." > > This text is old. The home agent needs to compare it with the IPv4 > address in the IPv4 CoA option. So this paragraph should actually > say > > When the home agent receives the encapsulated binding update it > compares the IPv4 address of the source address field in the IPv4 > header with the IPv4 address in the IPv4 care-of address option > in the Binding Update. > >> If the IPv6 header contains the mobile node's IPv6 home address, =20 >> how can >> it ever match with the IPv4 address of the source address field in =20= >> the >> IPv4 header? Furthermore, RFC3775 in 9.5.1. says "If the Lifetime >> specified in the Binding Update is zero or the specified care-of =20 >> address >> matches the home address for the binding, then this is a request to >> delete the cached binding for the home address." > > This text needs to be clarified in RFC 3775. If this is the case, could someone send a mail with the old and new =20 text for the process of updating rfc 3775? thanks, marcelo > Regarding the actual > "violation", I don't think there is a conflict. The DS-MIPv6 > binding update has an IPv4 CoA option (similar to the alt CoA > option) which when present dictates a different behavior on the > home agent that implements DS-MIPv6 extensions. It is more like > DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA > option is present. > >> (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 =20 >> address? > > I suggest not going there. :) > > Vijay > >> Or >> (2) Should the IPv4 address of the source address field in the IPv4 >> header be compared with the address specified in the packet's IPv4 =20= >> CoA >> option? >> Of course the intention of the spec is to do (2), but the question =20= >> remains, >> are we violating RFC 3775? If so, are we ok with that? I intend to =20= >> submit the final version of the spec in the next day or two >> provided that we're ok with this issue so your prompt response is >> appreciated. Hesham >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 26 12:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ZiD-0003GM-FM; Wed, 26 Dec 2007 12:06:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ZiC-0003GF-91 for mext@ietf.org; Wed, 26 Dec 2007 12:06:32 -0500 Received: from smtp02.uc3m.es ([163.117.176.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7ZiA-0008UF-Dt for mext@ietf.org; Wed, 26 Dec 2007 12:06:32 -0500 Received: from [200.40.5.3] (unknown [200.40.5.3])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp02.uc3m.es (Postfix) with ESMTP id DCA772B919C;Wed, 26 Dec 2007 18:06:18 +0100 (CET) In-Reply-To: References: <475FED61.2060606@gmail.com><476B91B0.8030805@gmail.com><476BC613.8020906@gmail. com><47 6 BCCF0.1020202@gmail.com><476BEE14.2090405@gmail.com><476C2610.3000101@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? Date: Wed, 26 Dec 2007 18:04:28 +0100 To: Ahmad Muhanna X-Mailer: Apple Mail (2.752.3) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-30.5900 TC:1F TRN:93 TV:5.0.1023(15630.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, i am trying to understand the impact of this in rfc3775 update I don't think that whether it is a good idea to use BRR from the HA =20 is relevant for the discussion of RFC3775 update (it is of course =20 relevant for the mext ml but not imho for this particular process of =20 updating rfc3775) what imho is relavnt for the discussion of updating rfc3775 is =20 whether rfc3775 is clear enough about whether HAs should send BRR or not =46rom the text of rfc3775 that Alex sent in his original posting, it =20= seems that only CNs should send BRR and BE and not by the HA, so, is =20 there any text in rfc3775 that can possibly create confusion about =20 HAs using BRR or BEs? Does anyone has interpreted rfc3775 in the way =20 that HAs should send BRR and BEs? again, while it may be a good idea that HAs do send BRR ad BE (i =20 don't know) this is not what is relevant for rfc3775 update processs, =20= but whether rfc3775 is unclear about that Regards, marcelo El 22/12/2007, a las 8:29, Ahmad Muhanna escribi=F3: >> >> What exactly doesn't scale? I think HA sending BRR is as =20 >> scalable as >> MN sending BU to it. What's the non-scaling factor >> introduced by BRR at HA? > > [Ahmad] > Read below. > >> >>>>> 5. If the HA needs to send a reminder to every MN about >> the expiry >>>>> of its BCE, then we are introducing a new functionality which >>>>> violates the basic RFC3775 functionality and a non sense >> complexity >>>>> that absolutely is not necessary and not within the original >>>>> intention of RFC3775. >>>> >>>> In what does that HA-sends-BRR functionality violate the >> basic 3775? >>>> What does it break? >>> >>> [Ahmad] I am not sure if what does break is the right question here. >> >> But you used the word 'violate' - what does it violate then? > > [Ahmad] > Please read below. >> >>> It is a new functionality which is fundamentally in >> conflict with the >>> original RFC3775 intention of how MIP6 BCE is managed at the HA. >> >> Sorry, what's the conflict you point out? It's not a new >> message format, not any new option. > > [Ahmad] > Please read below. >> >>> However, let me explain what could happen in case that the HA >>> implements this new weird functionality: >>> >>> 1. Some of the HA are talking about supporting a million BCE >>> simultaneously. Do you understand the impact on the HA when >> these BCEs >>> starts getting close to expiry? >> >> Ah! I didn't assume that all MNs send BUs simultaneously >> with precisely the same lifetime. You seem to assume so. If >> so then we have a BU storm in first place, prior to BRR. >> >> If you didn't assume all million MNs send the BUs >> simultaneously then the BRRs aren't sent simultaneously either. > > [Ahmad] > Alex, > Hopefully, this is my last explanation to help clarify your > understanding of the applicability and use of BRR by the HA. > > It is very strange that you understand things and functionalities only > according to your own terms and probably your implementation and past > experience. However, let me summarize what I want to say in an =20 > easier to > follow format: > > 1. Are you assuming that HA provides the same lifetime for all mobile > node and all different subscribers at all times? > 2. Are you assuming that, for example all subscribers including =20 > prepaid > ones will end having the same BCE lifetime? > 3. Are you assuming that there is only your own limited =20 > understanding of > how the HA handles the BCE lifetime? > > 4. IF the answer to all of the above yes, then we have a very specific > HA application which is limited to Alex understanding of Mobile IPv6 > services and its applicability and at that point, there is no point of > discussing this any further! > > 5. However, If the answer is NO to any of 1-3 points, then when a =20 > HA is > able to support a high number of different types of subscribers BCE, > then the possibility of too many BCE lifetimes to expire at the same > time is quite very very high and probably devastating to the HA > functionality. > > 6. If the answer to No. 5 is YES, then it is very possible for a huge > number of these BCE lifetime to expire at the same time and if the HA > needs to send BRR message to all of these MNs at the same time, it > presents a new scalability challenge. In other words, this new > functionality needs to be evaluated and a study of how the HA handles > this very frequent and new phenomena while the HA still supports the > proclaimed number of activation rate becomes very necessary; Hope this > one is clear! > > 7. You asked me if the BU/BAK/BRR is more reliable than the BU/BA, =20 > well, > REGARDLESS!! since you admit that BU/BA is reliable, then that all =20 > what > we need and looking for. Your proposed enhancement is not needed, > however, you can keep it specific to your own implementation. Unless, > you still believe that RFC3775 protocol is BROKEN and does NOT =20 > handle BU > loss!? > > > 8. On another note you said: "BRR sent only if at end of lifetime when > the BU is not received." ok; Why do you think that the HA needs to =20 > send > a BRR message to the MN after the MN BCE lifetime has expired. It =20 > seems > to me that you need to pay close attention to the difference between a > MN Home BCE at the HA and a MN BCE at a CN. Please remember that the > lifetime of these two are DIFFERENT! And consequently what is =20 > applicable > to the handling of BCE at the CN is not necessarily TRUE for the MN =20= > home > BCE. One more time, an expiry of the BCE at the CN means RO with =20 > that CN > is lost but the MN is still reachable via the HA BCE! > > 9. You also said: "No, keep the suggested lifetime field in BA and > process it as usual."; excellent! Why then we need to introduce =20 > this new > functionality to do the same thing which is done by the BU/BA =20 > mechanism? > > 10. In reference to how the use of BRR is more reliable, you also =20 > said: > "A form of three-way handshake is better reliability than a two-way > exchange."; Man, it seems that you always tends to think of success > scenarios! You just said that the HA would send the BRR after the BCE > lifetime expires, well, let me add one more thing and the MN is =20 > probably > gone home and no longer there. What kind of reliability you are > achieving by sending a BRR for a MN which is probably not there. This > will be the vast majority of the scenarios that your BRR will be > addressing anyway. Let me ask one more time, do you still think =20 > that is > a better reliability? :) > > 11. You seem to understand that supporting BRR message at the HA =20 > nothing > but sending a BRR message! This is unfortunate! Supporting BRR is far > more complex and a new functionality than you have in mind and you =20 > ever > thought! Just as a reminder, All RFC3775 HA operations and state > machines is processing a request that generates a reply in some =20 > form of > Ack! Do you understand what does that mean and its difference from > supporting BRR?! Please think again. > > 12. However, if you are proposing that the MN is not supposed to =20 > send a > BU to renew its BCE lifetime except after it receives a BRR message =20= > from > its HA, then that probably a different discussion that needs another > round which I am not willing to be part of and I consider it a =20 > waste of > time :-)))) > > 13. You also said: "I meant to say that the effect of BRR being > specified and implemented for CN is more reliable BCE at CN. Let's =20= > have > the same level of reliability at HA." Man! Read the above. You seem =20= > not > to understand the difference! > > 14. You also said: "Or maybe we just want to stress that some HA > implementations do BRR. Or do we want to forbid HA implementations to > do BRR." Again, I am not sure if you realize the difference in the BRR > applicability to CN BCE vs. HA BCE. IMO, the usecase you presented is > not worth to be discussed unless you believe and can prove that =20 > RFC3775 > protocol is BROKEN and does not handle BU loss! > > 15. In your explanation of your earlier comment of "and thus =20 > reduces the > non-bound time from the entire lifetime to much less" You also =20 > said: "If > the BU is lost then MN will send another BU at the end of the current > lifetime. Instead of waiting for the current lifetime to expire it =20 > could > be triggered by a BRR received from the HA." :-(((( > > well, that is really an optimization for a HA implementation! > > Your statement is contradictory to what you said earlier. You said =20 > that > BRR is sent after the BCE lifetime expires and here you said that =20 > the HA > would send a BRR before the BCE expires. How the HA one time =20 > decides to > send a BRR before the end of BCE and some time after the lifetime > expires. On the other hand, why the BU/BA mechanism does not work for > the BU loss? You MUST explain why you think that it does NOT work? Do > you mean that the MN will send one single BU and that is it! Do you > assume that the MN does not use retransmission? > > Also, you are assuming that the MN will wait until the last second of > its BCE lifetime and then send a BU!? On the other hand, have you ever > heard of the Binding Refresh Advice mobility option? Does the testing > client in your test bed understand this option, what about the HA does > it support that option? Please take a look and try to understand the > value of this option. May be after reading about it you would find =20 > what > is missing? IMO, all reliable MIP6 clients would initiate their BCE > lifetime refresh registration before the end of the home BCE lifetime! > > 16. In reference to RFC3775 text supporting your understanding of =20 > the CN > being a HA you said: " Right... difficult to find right now..." Cool > take your time and when you find it, please let me know. BTW: That =20 > is an > important piece of your reasoning for supporting this functionality:) > No? > > 17. finally you said: "When do we discuss BErr? (Binding Error)" > Probably after you show that you understand the difference in > applicability of BRR on the MN BCE at CN vs. MN BCE at HA. > > > Cheers! > Ahmad > >> >>> and the HA needs to send a BRR message and not only that but >>> retransmits those messages until a BU is received from each one of >>> these MNs? >> >> The BRR is sent only if the BU is not received at HA the end >> of the lifetime. It is not _always_ sent. That is current >> behaviour of CN. >> >>> 3. Personally, I wont agree to such functionality because >> Home Agent >>> acts as a server offering a MIP6 mobility service to multiple MNs >>> governed by a MIP6 protocol which offers a reliable mechanism for >>> updating the MN BCE lifetime at the HA. >> >> BU/BAck is reliable - BU/BAck/BRR is more reliable. Would you agree? >> >>> 4. Let us assume for the sake of argument that this new >> functionality >>> is supported by the HA, what is the impact: 4.1. Can you >> imagine the >>> unnecessary traffic that is generated for no reason. >> >> No, no unnecessary traffic. BRR sent only if at end of >> lifetime the BU is not received. >> >>> 4.2. What is going to be the MN processing when it receives such a >>> message? All current RFC3775 text talks about a BRR coming from the >>> CN. Is there going to be a difference in there? >> >> No difference. >> >>> 4.3. How MN would recognize that this message is related to >> MN BCE at >>> the HA? >> >> It doesn't need to distinguish this - why do you think it >> should distinguish? (if it wants so then it has the HA >> address thus it can answer the q you raise). >> >>> 4.4. Backward compatibility, How, this would work for MN which only >>> supports BRR from the CN? >> >> How does MN know BRR is from CN and not from HA? I don't >> think MNs implement BRR such as to be _only_ from CN. It >> can't distinguish the BRR coming from CN, it just sees an IP address. >> >>> 4.5. Finally, if this procedure is adopted, are we going to >> deprecate >>> the existing one using lifetime field in BA, etc? 4.6. etc. >> >> No, keep the suggested lifetime field in BA and process it as usual. >> >>>> I see it offering better reliability: even if the critical >> BU is lost >>>> the HA requests the BU anew (BRR) and thus reduces the >> non-bound time >>>> from the entire lifetime to much less. >>> >>> [Ahmad] 1. Wow! Are you calling this a better reliability? What is >>> your definition of reliability then? >> >> A form of three-way handshake is better reliability than a >> two-way exchange. >> >>> 2. Are you suggesting that the current RFC3775 protocol is >> BROKEN and >>> does not address BU loss? >> >> No, not suggesting so. I suggest in certain conditions when >> the BU is lost, the HA using BRR leads to shorter wait for >> BCE update (shorter than the current BU waiting for the next >> lifetime) - less interruption at MN. >> >>> 3. I do not understand what you mean by: "and thus reduces the >>> non-bound time from the entire lifetime to much less" Can >> you please >>> elaborate more and explain? >> >> If the BU is lost then MN will send another BU at the end of >> the current lifetime. Instead of waiting for the current >> lifetime to expire it could be triggered by a BRR received >> from the HA. >> >> No difference between CN and HA here. >> >>>>> 6. On the other hand, CN maintains a limited number of BCE for >>>>> specific mobile nodes and more importantly if the MN >> decides NOT to >>>>> renew its BCE with a specific CN, the MN continues to be >> reachable >>>>> by other CNs at its HoA and CoA via its Home Agent BCE. >>>>> In other words, a MN binding with another CN represent >> the service >>>>> (RO) between MN<->CN ONLY, however, in the case of HA it >> represents >>>>> the MN's MIP6 service and access to the whole internet. >> Which also >>>>> administratively governed. i.e. if the MN does not renew its BCE, >>>>> then that is a clear indication for the HA to delete the MN BCE. >>>> >>>> Not before it sends a BRR and waits for an answer to that. >>> >>> [Ahmad] What do you mean here, MN does not send a BU to refresh its >>> Home BCE lifetime except after receiving a BRR? >> >> No, I meant it sends its BU as usual, (I think 4s before the >> lifetime expires or so). >> >>>>> 7. Finally, the fact that RFC3775 mentions that CN could >> be a HA, >>>>> does not mean that the HA application at such a node need >> to support >>>>> BRR. >>>> >>>> That's your reading. Other implementers read it in the way I said. >>>> >>>> >>>> >>>> >>> >>> [Ahmad] Excellent. Please cut and paste here the text where it >>> supports your understanding? >> >> Right... difficult to find right now... >> >>>>> IMO, such a node could act as a CN for some MNs and a HA >> for others. >>>>> Then, it is normal for this CN/HA node to support BRR for >> those MN >>>>> which is serving as a CN but not a HA. >>>> >>>> Is a HA a "CN" when it is the dst field of the BU? >>> >>> [Ahmad] I am not sure what you are trying to say here, but for now, >>> let us focus on the real issue as highlighted above. Thanks! >> >> I meant to say that the effect of BRR being specified and >> implemented for CN is more reliable BCE at CN. Let's have >> the same level of reliability at HA. >> >> Or maybe we just want to stress that some HA implementations >> do BRR. Or do we want to forbid HA implementations to do BRR. >> >> When do we discuss BErr? (Binding Error) >> >> Alex >> >> >> _____________________________________________________________________=20= >> _ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> _____________________________________________________________________=20= >> _ >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 26 13:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ave-0001UJ-70; Wed, 26 Dec 2007 13:24:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7avc-0001TD-HL for mext@ietf.org; Wed, 26 Dec 2007 13:24:28 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7avc-0001qp-1i for mext@ietf.org; Wed, 26 Dec 2007 13:24:28 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1198693466!6689802!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30017 invoked from network); 26 Dec 2007 18:24:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 26 Dec 2007 18:24:26 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lBQIOMZC025840; Wed, 26 Dec 2007 11:24:22 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id lBQIOLhb014249; Wed, 26 Dec 2007 12:24:21 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id lBQIOJIn014224; Wed, 26 Dec 2007 12:24:20 -0600 (CST) Message-ID: <47729C52.7080305@gmail.com> Date: Wed, 26 Dec 2007 19:24:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? References: <475FED61.2060606@gmail.com><476B91B0.8030805@gmail.com><476BC613.8020906@gmail. com><47 6 BCCF0.1020202@gmail.com><476BEE14.2090405@gmail.com><476C2610.3000101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071226-0, 26/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org marcelo bagnulo braun wrote: > Hi, > > i am trying to understand the impact of this in rfc3775 update > > I don't think that whether it is a good idea to use BRR from the HA > is relevant for the discussion of RFC3775 update (it is of course > relevant for the mext ml but not imho for this particular process of > updating rfc3775) > > what imho is relavnt for the discussion of updating rfc3775 is > whether rfc3775 is clear enough about whether HAs should send BRR or > not > > From the text of rfc3775 that Alex sent in his original posting, it > seems that only CNs should send BRR and BE and not by the HA, so, is > there any text in rfc3775 that can possibly create confusion about > HAs using BRR or BEs? Does anyone has interpreted rfc3775 in the way > that HAs should send BRR and BEs? I will invite other implementers express whether it's clear or not who sends BRR and BErr. For my reading, there are some occurences about the possibility of HA being a CN, for example section 10.3.1 "Primary Care-of Address Registration" in 10.3 "Processing Bindings" in 10 "HA Operation": rfc3775: [...] > To begin processing the Binding Update, the home agent MUST perform > the following sequence of tests: > > o If the node implements only correspondent node functionality, or > has not been configured to act as a home agent,[...] The 'node' (the home agent) can thus implement only CN functionality. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Dec 26 13:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bH9-00067B-OM; Wed, 26 Dec 2007 13:46:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bH8-000672-2W for mext@ietf.org; Wed, 26 Dec 2007 13:46:42 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7bH6-0005k7-EB for mext@ietf.org; Wed, 26 Dec 2007 13:46:42 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBQIkT600624; Wed, 26 Dec 2007 18:46:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Reliability of sending BRR by the HA? Date: Wed, 26 Dec 2007 12:46:25 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Reliability of sending BRR by the HA? Thread-Index: AchH4a0uyIWaf/fdRAO9BE3G7D/4yAADMtIg References: <475FED61.2060606@gmail.com><476B91B0.8030805@gmail.com><476BC613.8020906@gmail. com><47 6 BCCF0.1020202@gmail.com><476BEE14.2090405@gmail.com><476C2610.3000101@gmail.com> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" X-Spam-Score: -4.0 (----) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Marcelo, Please see comments inline. Regards, Ahmad =20 > Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? >=20 > Hi, >=20 > i am trying to understand the impact of this in rfc3775 update >=20 > I don't think that whether it is a good idea to use BRR from=20 > the HA is relevant for the discussion of RFC3775 update=20 [Ahmad] I agree with you. That is inline with my initial comment. > (it=20 > is of course relevant for the mext ml but not imho for this=20 > particular process of updating rfc3775) >=20 > what imho is relavnt for the discussion of updating rfc3775=20 > is whether rfc3775 is clear enough about whether HAs should=20 > send BRR or not >=20 > From the text of rfc3775 that Alex sent in his original=20 > posting, it seems that only CNs should send BRR and BE and=20 > not by the HA, [Ahmad] TRUE.=20 > so, is there any text in rfc3775 that can=20 > possibly create confusion about HAs using BRR or BEs? Does=20 > anyone has interpreted rfc3775 in the way that HAs should=20 > send BRR and BEs? >=20 > again, while it may be a good idea that HAs do send BRR ad BE=20 > (i don't know) this is not what is relevant for rfc3775=20 > update processs, but whether rfc3775 is unclear about that [Ahmad] There is no mention anywhere in RFC3775 that HA can send BRR or BErr. I = also may add that there is no confusion!:) >=20 > Regards, marcelo >=20 >=20 > El 22/12/2007, a las 8:29, Ahmad Muhanna escribi=F3: >=20 > >> > >> What exactly doesn't scale? I think HA sending BRR is as =20 > >> scalable as > >> MN sending BU to it. What's the non-scaling factor=20 > introduced by BRR=20 > >> at HA? > > > > [Ahmad] > > Read below. > > > >> > >>>>> 5. If the HA needs to send a reminder to every MN about > >> the expiry > >>>>> of its BCE, then we are introducing a new functionality which=20 > >>>>> violates the basic RFC3775 functionality and a non sense > >> complexity > >>>>> that absolutely is not necessary and not within the original=20 > >>>>> intention of RFC3775. > >>>> > >>>> In what does that HA-sends-BRR functionality violate the > >> basic 3775? > >>>> What does it break? > >>> > >>> [Ahmad] I am not sure if what does break is the right=20 > question here. > >> > >> But you used the word 'violate' - what does it violate then? > > > > [Ahmad] > > Please read below. > >> > >>> It is a new functionality which is fundamentally in > >> conflict with the > >>> original RFC3775 intention of how MIP6 BCE is managed at the HA. > >> > >> Sorry, what's the conflict you point out? It's not a new message=20 > >> format, not any new option. > > > > [Ahmad] > > Please read below. > >> > >>> However, let me explain what could happen in case that the HA=20 > >>> implements this new weird functionality: > >>> > >>> 1. Some of the HA are talking about supporting a million BCE=20 > >>> simultaneously. Do you understand the impact on the HA when > >> these BCEs > >>> starts getting close to expiry? > >> > >> Ah! I didn't assume that all MNs send BUs simultaneously with=20 > >> precisely the same lifetime. You seem to assume so. If=20 > so then we=20 > >> have a BU storm in first place, prior to BRR. > >> > >> If you didn't assume all million MNs send the BUs=20 > simultaneously then=20 > >> the BRRs aren't sent simultaneously either. > > > > [Ahmad] > > Alex, > > Hopefully, this is my last explanation to help clarify your=20 > > understanding of the applicability and use of BRR by the HA. > > > > It is very strange that you understand things and=20 > functionalities only=20 > > according to your own terms and probably your=20 > implementation and past=20 > > experience. However, let me summarize what I want to say in=20 > an easier=20 > > to follow format: > > > > 1. Are you assuming that HA provides the same lifetime for=20 > all mobile=20 > > node and all different subscribers at all times? > > 2. Are you assuming that, for example all subscribers including=20 > > prepaid ones will end having the same BCE lifetime? > > 3. Are you assuming that there is only your own limited=20 > understanding=20 > > of how the HA handles the BCE lifetime? > > > > 4. IF the answer to all of the above yes, then we have a=20 > very specific=20 > > HA application which is limited to Alex understanding of=20 > Mobile IPv6=20 > > services and its applicability and at that point, there is=20 > no point of=20 > > discussing this any further! > > > > 5. However, If the answer is NO to any of 1-3 points, then=20 > when a HA=20 > > is able to support a high number of different types of subscribers=20 > > BCE, then the possibility of too many BCE lifetimes to=20 > expire at the=20 > > same time is quite very very high and probably devastating=20 > to the HA=20 > > functionality. > > > > 6. If the answer to No. 5 is YES, then it is very possible=20 > for a huge=20 > > number of these BCE lifetime to expire at the same time and=20 > if the HA=20 > > needs to send BRR message to all of these MNs at the same time, it=20 > > presents a new scalability challenge. In other words, this new=20 > > functionality needs to be evaluated and a study of how the=20 > HA handles=20 > > this very frequent and new phenomena while the HA still=20 > supports the=20 > > proclaimed number of activation rate becomes very=20 > necessary; Hope this=20 > > one is clear! > > > > 7. You asked me if the BU/BAK/BRR is more reliable than the BU/BA,=20 > > well, REGARDLESS!! since you admit that BU/BA is reliable,=20 > then that=20 > > all what we need and looking for. Your proposed enhancement is not=20 > > needed, however, you can keep it specific to your own=20 > implementation.=20 > > Unless, you still believe that RFC3775 protocol is BROKEN=20 > and does NOT=20 > > handle BU loss!? > > > > > > 8. On another note you said: "BRR sent only if at end of=20 > lifetime when=20 > > the BU is not received." ok; Why do you think that the HA needs to=20 > > send a BRR message to the MN after the MN BCE lifetime has=20 > expired. It=20 > > seems to me that you need to pay close attention to the difference=20 > > between a MN Home BCE at the HA and a MN BCE at a CN.=20 > Please remember=20 > > that the lifetime of these two are DIFFERENT! And=20 > consequently what is=20 > > applicable to the handling of BCE at the CN is not necessarily TRUE=20 > > for the MN home BCE. One more time, an expiry of the BCE at the CN=20 > > means RO with that CN is lost but the MN is still reachable=20 > via the HA=20 > > BCE! > > > > 9. You also said: "No, keep the suggested lifetime field in BA and=20 > > process it as usual."; excellent! Why then we need to=20 > introduce this=20 > > new functionality to do the same thing which is done by the BU/BA=20 > > mechanism? > > > > 10. In reference to how the use of BRR is more reliable, you also > > said: > > "A form of three-way handshake is better reliability than a two-way=20 > > exchange."; Man, it seems that you always tends to think of success=20 > > scenarios! You just said that the HA would send the BRR=20 > after the BCE=20 > > lifetime expires, well, let me add one more thing and the MN is=20 > > probably gone home and no longer there. What kind of=20 > reliability you=20 > > are achieving by sending a BRR for a MN which is probably=20 > not there.=20 > > This will be the vast majority of the scenarios that your=20 > BRR will be=20 > > addressing anyway. Let me ask one more time, do you still=20 > think that=20 > > is a better reliability? :) > > > > 11. You seem to understand that supporting BRR message at the HA=20 > > nothing but sending a BRR message! This is unfortunate!=20 > Supporting BRR=20 > > is far more complex and a new functionality than you have=20 > in mind and=20 > > you ever thought! Just as a reminder, All RFC3775 HA operations and=20 > > state machines is processing a request that generates a=20 > reply in some=20 > > form of Ack! Do you understand what does that mean and its=20 > difference=20 > > from supporting BRR?! Please think again. > > > > 12. However, if you are proposing that the MN is not=20 > supposed to send=20 > > a BU to renew its BCE lifetime except after it receives a=20 > BRR message=20 > > from its HA, then that probably a different discussion that needs=20 > > another round which I am not willing to be part of and I=20 > consider it a=20 > > waste of time :-)))) > > > > 13. You also said: "I meant to say that the effect of BRR being=20 > > specified and implemented for CN is more reliable BCE at CN. Let's=20 > > have the same level of reliability at HA." Man! Read the above. You=20 > > seem not to understand the difference! > > > > 14. You also said: "Or maybe we just want to stress that some HA=20 > > implementations do BRR. Or do we want to forbid HA=20 > implementations to=20 > > do BRR." Again, I am not sure if you realize the difference=20 > in the BRR=20 > > applicability to CN BCE vs. HA BCE. IMO, the usecase you=20 > presented is=20 > > not worth to be discussed unless you believe and can prove that > > RFC3775 > > protocol is BROKEN and does not handle BU loss! > > > > 15. In your explanation of your earlier comment of "and=20 > thus reduces=20 > > the non-bound time from the entire lifetime to much less" You also > > said: "If > > the BU is lost then MN will send another BU at the end of=20 > the current=20 > > lifetime. Instead of waiting for the current lifetime to expire it=20 > > could be triggered by a BRR received from the HA." :-(((( > > > > well, that is really an optimization for a HA implementation! > > > > Your statement is contradictory to what you said earlier. You said=20 > > that BRR is sent after the BCE lifetime expires and here=20 > you said that=20 > > the HA would send a BRR before the BCE expires. How the HA one time=20 > > decides to send a BRR before the end of BCE and some time after the=20 > > lifetime expires. On the other hand, why the BU/BA=20 > mechanism does not=20 > > work for the BU loss? You MUST explain why you think that=20 > it does NOT=20 > > work? Do you mean that the MN will send one single BU and=20 > that is it!=20 > > Do you assume that the MN does not use retransmission? > > > > Also, you are assuming that the MN will wait until the last=20 > second of=20 > > its BCE lifetime and then send a BU!? On the other hand,=20 > have you ever=20 > > heard of the Binding Refresh Advice mobility option? Does=20 > the testing=20 > > client in your test bed understand this option, what about=20 > the HA does=20 > > it support that option? Please take a look and try to=20 > understand the=20 > > value of this option. May be after reading about it you would find=20 > > what is missing? IMO, all reliable MIP6 clients would=20 > initiate their=20 > > BCE lifetime refresh registration before the end of the home BCE=20 > > lifetime! > > > > 16. In reference to RFC3775 text supporting your=20 > understanding of the=20 > > CN being a HA you said: " Right... difficult to find right now..."=20 > > Cool take your time and when you find it, please let me know. BTW:=20 > > That is an important piece of your reasoning for supporting this=20 > > functionality:) No? > > > > 17. finally you said: "When do we discuss BErr? (Binding Error)" > > Probably after you show that you understand the difference in=20 > > applicability of BRR on the MN BCE at CN vs. MN BCE at HA. > > > > > > Cheers! > > Ahmad > > > >> > >>> and the HA needs to send a BRR message and not only that but=20 > >>> retransmits those messages until a BU is received from=20 > each one of=20 > >>> these MNs? > >> > >> The BRR is sent only if the BU is not received at HA the=20 > end of the=20 > >> lifetime. It is not _always_ sent. That is current=20 > behaviour of CN. > >> > >>> 3. Personally, I wont agree to such functionality because > >> Home Agent > >>> acts as a server offering a MIP6 mobility service to multiple MNs=20 > >>> governed by a MIP6 protocol which offers a reliable mechanism for=20 > >>> updating the MN BCE lifetime at the HA. > >> > >> BU/BAck is reliable - BU/BAck/BRR is more reliable. Would=20 > you agree? > >> > >>> 4. Let us assume for the sake of argument that this new > >> functionality > >>> is supported by the HA, what is the impact: 4.1. Can you > >> imagine the > >>> unnecessary traffic that is generated for no reason. > >> > >> No, no unnecessary traffic. BRR sent only if at end of=20 > lifetime the=20 > >> BU is not received. > >> > >>> 4.2. What is going to be the MN processing when it=20 > receives such a=20 > >>> message? All current RFC3775 text talks about a BRR=20 > coming from the=20 > >>> CN. Is there going to be a difference in there? > >> > >> No difference. > >> > >>> 4.3. How MN would recognize that this message is related to > >> MN BCE at > >>> the HA? > >> > >> It doesn't need to distinguish this - why do you think it should=20 > >> distinguish? (if it wants so then it has the HA address=20 > thus it can=20 > >> answer the q you raise). > >> > >>> 4.4. Backward compatibility, How, this would work for MN=20 > which only=20 > >>> supports BRR from the CN? > >> > >> How does MN know BRR is from CN and not from HA? I don't=20 > think MNs=20 > >> implement BRR such as to be _only_ from CN. It can't=20 > distinguish the=20 > >> BRR coming from CN, it just sees an IP address. > >> > >>> 4.5. Finally, if this procedure is adopted, are we going to > >> deprecate > >>> the existing one using lifetime field in BA, etc? 4.6. etc. > >> > >> No, keep the suggested lifetime field in BA and process it=20 > as usual. > >> > >>>> I see it offering better reliability: even if the critical > >> BU is lost > >>>> the HA requests the BU anew (BRR) and thus reduces the > >> non-bound time > >>>> from the entire lifetime to much less. > >>> > >>> [Ahmad] 1. Wow! Are you calling this a better=20 > reliability? What is=20 > >>> your definition of reliability then? > >> > >> A form of three-way handshake is better reliability than a two-way=20 > >> exchange. > >> > >>> 2. Are you suggesting that the current RFC3775 protocol is > >> BROKEN and > >>> does not address BU loss? > >> > >> No, not suggesting so. I suggest in certain conditions=20 > when the BU=20 > >> is lost, the HA using BRR leads to shorter wait for BCE update=20 > >> (shorter than the current BU waiting for the next > >> lifetime) - less interruption at MN. > >> > >>> 3. I do not understand what you mean by: "and thus reduces the=20 > >>> non-bound time from the entire lifetime to much less" Can > >> you please > >>> elaborate more and explain? > >> > >> If the BU is lost then MN will send another BU at the end of the=20 > >> current lifetime. Instead of waiting for the current lifetime to=20 > >> expire it could be triggered by a BRR received from the HA. > >> > >> No difference between CN and HA here. > >> > >>>>> 6. On the other hand, CN maintains a limited number of BCE for=20 > >>>>> specific mobile nodes and more importantly if the MN > >> decides NOT to > >>>>> renew its BCE with a specific CN, the MN continues to be > >> reachable > >>>>> by other CNs at its HoA and CoA via its Home Agent BCE. > >>>>> In other words, a MN binding with another CN represent > >> the service > >>>>> (RO) between MN<->CN ONLY, however, in the case of HA it > >> represents > >>>>> the MN's MIP6 service and access to the whole internet. > >> Which also > >>>>> administratively governed. i.e. if the MN does not=20 > renew its BCE,=20 > >>>>> then that is a clear indication for the HA to delete the MN BCE. > >>>> > >>>> Not before it sends a BRR and waits for an answer to that. > >>> > >>> [Ahmad] What do you mean here, MN does not send a BU to=20 > refresh its=20 > >>> Home BCE lifetime except after receiving a BRR? > >> > >> No, I meant it sends its BU as usual, (I think 4s before=20 > the lifetime=20 > >> expires or so). > >> > >>>>> 7. Finally, the fact that RFC3775 mentions that CN could > >> be a HA, > >>>>> does not mean that the HA application at such a node need > >> to support > >>>>> BRR. > >>>> > >>>> That's your reading. Other implementers read it in the=20 > way I said. > >>>> > >>>> > >>>> > >>>> > >>> > >>> [Ahmad] Excellent. Please cut and paste here the text where it=20 > >>> supports your understanding? > >> > >> Right... difficult to find right now... > >> > >>>>> IMO, such a node could act as a CN for some MNs and a HA > >> for others. > >>>>> Then, it is normal for this CN/HA node to support BRR for > >> those MN > >>>>> which is serving as a CN but not a HA. > >>>> > >>>> Is a HA a "CN" when it is the dst field of the BU? > >>> > >>> [Ahmad] I am not sure what you are trying to say here,=20 > but for now,=20 > >>> let us focus on the real issue as highlighted above. Thanks! > >> > >> I meant to say that the effect of BRR being specified and=20 > implemented=20 > >> for CN is more reliable BCE at CN. Let's have the same level of=20 > >> reliability at HA. > >> > >> Or maybe we just want to stress that some HA=20 > implementations do BRR. =20 > >> Or do we want to forbid HA implementations to do BRR. > >> > >> When do we discuss BErr? (Binding Error) > >> > >> Alex > >> > >> > >>=20 > _____________________________________________________________________ > >> _ > >> This email has been scanned by the MessageLabs Email=20 > Security System. > >> For more information please visit > >> http://www.messagelabs.com/email > >>=20 > _____________________________________________________________________ > >> _ > >> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From nemo-bounces@ietf.org Wed Dec 26 15:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7d43-0001Gf-1z; Wed, 26 Dec 2007 15:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7d42-0001Ga-9n for nemo@ietf.org; Wed, 26 Dec 2007 15:41:18 -0500 Received: from web33505.mail.mud.yahoo.com ([68.142.206.154]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J7d41-0008Jq-KE for nemo@ietf.org; Wed, 26 Dec 2007 15:41:18 -0500 Received: (qmail 71588 invoked by uid 60001); 26 Dec 2007 20:41:17 -0000 X-YMail-OSG: GPtphSoVM1kmni.focLo0oF2G4XNFqwqsJJIp4YZ4PuZUuvP6C.TSqyMeatWZWG_pzUIYow5eU_0Cy52MvFQY3JCCOijR4r2vX.hUzXo5LsvxAVk2K6HelPOddw49Q-- Received: from [130.160.46.94] by web33505.mail.mud.yahoo.com via HTTP; Wed, 26 Dec 2007 12:41:16 PST X-RocketYMMF: yangxiao_acm Date: Wed, 26 Dec 2007 12:41:16 -0800 (PST) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <999477.70691.qm@web33505.mail.mud.yahoo.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [nemo] =?iso-8859-1?q?Journal_Special_issue_on_Electronic_=96_He?= =?iso-8859-1?q?alth?= X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org International Journal of Telemedicine and Applications (IJTA) Special Issue Announcement Electronic – Health http://cs.ua.edu/~yangxiao/IJTA_SI_E-Health.html Guest Editors Hui Chen, Virginia State University, USA E-mail: huichen@ieee.org Arnauld Nicogossian, George Mason University, USA E-mail: anicogoss@cox.net Silas Olsson, Healthaccess, Sweden E-mail: silas.olsson@healthaccess.eu Azhar Rafiq, Virginia Commonwealth University, USA E-mail: fiq@vcu.edu Max E. Stachura, Medical College of Georgia, USA E-mail: MAXS@mail.mcg.edu Mamoru Watanabe, University of Calgary, Canada E-mail: watanabe@ucalgary.ca Pamela Whitten, Michigan State University, USA E-mail: pwhitten@msu.edu Yang Xiao, The University of Alabama, USA E-mail: yangxiao@ieee.org Electronic health (E-health) becomes a very important area, involving multiple fields, such as health, healthcare, public health, medical science, health Service, data management, image processing, telecommunication, wireless network, operational research, etc. The purpose of the special issue is to provide quick journal paper publications on any topic related to E-Health. Specific areas of interest include (but are not limited to): · Health promotion, health prevention (e.g. of persons with risk factors) · Diagnosis, second opinion · Treatment, support to treatment · E-heath Decision support systems · Reducing error in healthcare delivery · Hospital based care · Ambulatory based care · Primary health based care · Home care · On the move care/support · Cross border care · Care in developing countries · International care · Reimbursement issues · Legal issues · E-heath education issues · E-heath change management issues · Change the way healthcare is delivered · Quality of Patient Care · Wireless/Mobile Telemedicine · E-health Data Management · Prevention of Medical Errors · E-health information Technology · Reduction of Healthcare Costs · Medical Image/Video Processing and Mining · Medical resource allocation, Optimization, and Simulation · E-health Text Mining · E-health Data Warehouses · Clinical Decision Support · Emergency Care · E-health Information Modeling and Integration · E-health Information Retrieval, Analysis, Visualization and Prediction · E-health Knowledge Discovery · Security, Privacy and Trust in E-health · Lessons Learned from E-health Information System Implementation · Tele-homecare and Ubiquitous Healthcare · Tele-presence and Robotics in Healthcare · E-Health Initiatives of World Bodies · Health Monitoring · Emerging Technologies for Rehabilitation · Tele-Rehabilitation and Tele-Physiotherapy · Sensor Networks for Patient and Elderly Care · Semantic Web in Healthcare · Navigation Systems for Healthcare · Computing for Human Experience and Wellness · Medical Nomadic Computing · Healthcare Industry Applications · Rural e-HealthCare Management · Healthcare Cost & Financial Analysis · Context-awareness for Smart Space in Healthcare · IT Infrastructures and Platforms for Remote Healthcare · etc. Authors should follow the International Journal of Telemedicine and Applications manuscript format described at the journal site http://www.hindawi.com/journals/ijta/. Prospective authors should submit an electronic copy of their complete manuscript through the journal Manuscript Tracking System at http://mts.hindawi.com/, according to the following timetable: Schedule: · Submission deadline: Feb. 1, 2008 · Notification: May. 1, 2008 · Publication of special issue: Aug. 1 2008 From nemo-bounces@ietf.org Wed Dec 26 15:56:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7dJA-0003l0-7l; Wed, 26 Dec 2007 15:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7dJ8-0003kp-Ti for nemo@ietf.org; Wed, 26 Dec 2007 15:56:54 -0500 Received: from web33505.mail.mud.yahoo.com ([68.142.206.154]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J7dJ7-00008E-Ff for nemo@ietf.org; Wed, 26 Dec 2007 15:56:54 -0500 Received: (qmail 77525 invoked by uid 60001); 26 Dec 2007 20:56:53 -0000 X-YMail-OSG: mTSfi3wVM1lZVDpxrHVA7BmTWSZEMHfcJxjmgoSMFCu9AnGmhoxa.7h.XtIXK5p2RAjduvsh4On436y2UXmnwwyENHTEU38_vir7e2mIfhI9LKXhtdY- Received: from [130.160.46.94] by web33505.mail.mud.yahoo.com via HTTP; Wed, 26 Dec 2007 12:56:52 PST X-RocketYMMF: yangxiao_acm Date: Wed, 26 Dec 2007 12:56:52 -0800 (PST) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <121119.77520.qm@web33505.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [nemo] Special Issue on WiMAX and 3G/3.5G Wireless Technologies for HealthCare Applications X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org WiMAX and 3G/3.5G Wireless Technologies for HealthCare Applications http://www.hindawi.com/journals/ijta/si/wimax.html Call for Papers Rapid advances in wireless and network technologies, such as IEEE 80.16/WiMAX and other broadband wireless access (BWA) systems, will open new opportunities for health care delivery and deployment scenarios. The convergence of these BWA around mobile health systems will also enable the use of these new broadband technologies for efficient healthcare and cost effective access anytime and anywhere. These new wireless telemedical scenarios will have a powerful impact on the way different healthcare organizations deliver healthcare to their patients. The integration of these technologies with other emerging 3.G/4G network technologies from the mobile healthcare perspective needs further research and is still an open study field. This special issue is concerned with the development, dissemination, and use of these emerging network architectures for the next generation of m-health systems. The purpose of this special issue is to assemble original and innovative contributions in the area of mobile technologies for health care applications, especially applications that leverage the new high-speed wireless technologies such as WiMAX and other BWA access methodologies and architectures for mobile healthcare and next generation of wireless telemedical systems. Authors are invited to submit papers addressing (but not limited to) the following topics: WiMAX-based mobile telemedical applications Wireless multimedia systems for health care Multimedia delivery over 3.5/4G networks New mobile health architectures and applications Authors should follow the International Journal of Telemedicine and Applications manuscript format described at the journal site http://www.hindawi.com/journals/ijta/. Prospective authors should submit an electronic copy of their complete manuscript through the journal Manuscript Tracking System at http://mts.hindawi.com/, according to the following timetable: Manuscript Due February 1, 2008 First Round of Reviews May 1, 2008 Publication Date August 1, 2008 Guest Editors Robert S. H. Istepanian, Mobile Information and Network Technologies Research Center, Kingston University, London, and St. George's University of London, UK Aura Ganz, Department of Electrical and Computer Engineering, University of Massachusetts, Amherst, MA 01003, USA From mext-bounces@ietf.org Wed Dec 26 22:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7j8M-0001PD-Lq; Wed, 26 Dec 2007 22:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7j8K-0001P7-Kb for mext@ietf.org; Wed, 26 Dec 2007 22:10:08 -0500 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J7j8H-0006aH-8o for mext@ietf.org; Wed, 26 Dec 2007 22:10:08 -0500 Received: (qmail 2626 invoked from network); 27 Dec 2007 12:09:57 +0900 Received: from (HELO MIP6-150) (@) by with SMTP; 27 Dec 2007 12:09:57 +0900 To: alexandru.petrescu@gmail.com Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? From: "K.Kawaguchi" References: <476C2610.3000101@gmail.com> <47729C52.7080305@gmail.com> In-Reply-To: <47729C52.7080305@gmail.com> Message-Id: <200712271209.BDG82321.BVHULJXB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 27 Dec 2007 12:09:51 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, Couldn't we understand description in RFC3775 as follows? BRR CN sends BRR. - Section 9.5 described Registration of CN. In it, section 9.5.5 described Sending BRR. HA does not send BRR. - Section 10.3 described Rigistration of HA. Although section 9.5.1 and section 9.5.4 were referred to, section 9.5.5 wasn't referred to. BE CN sends BE (status=1) and BE (status=2). - Section 9.2 described Sending BE (status=2). - Section 9.3.1 described Sending BE (status=1). HA sends BE (status=1) and BE (status=2). - Section 10.2 described Sending BE (status=2) by the same processing as a section 9.2. - Section 10.3.1 described Sending BE (status=1) by the same processing as section 9.3.1. MN sends BE (status=2). MN does not send BE (status=1). - Section 11.2 described Sending BE (status=2) by the same processing as a section 9.2. - There is no section about Sending BE (status=2). Best regards --- Kiyoaki KAWAGUCHI "Alexandru Petrescu" wrote: > marcelo bagnulo braun wrote: > > Hi, > > > > i am trying to understand the impact of this in rfc3775 update > > > > I don't think that whether it is a good idea to use BRR from the HA > > is relevant for the discussion of RFC3775 update (it is of course > > relevant for the mext ml but not imho for this particular process of > > updating rfc3775) > > > > what imho is relavnt for the discussion of updating rfc3775 is > > whether rfc3775 is clear enough about whether HAs should send BRR or > > not > > > > From the text of rfc3775 that Alex sent in his original posting, it > > seems that only CNs should send BRR and BE and not by the HA, so, is > > there any text in rfc3775 that can possibly create confusion about > > HAs using BRR or BEs? Does anyone has interpreted rfc3775 in the way > > that HAs should send BRR and BEs? > > I will invite other implementers express whether it's clear or not who > sends BRR and BErr. > > For my reading, there are some occurences about the possibility of HA > being a CN, for example section 10.3.1 "Primary Care-of Address > Registration" in 10.3 "Processing Bindings" in 10 "HA Operation": > > rfc3775: > [...] > > To begin processing the Binding Update, the home agent MUST perform > > the following sequence of tests: > > > > o If the node implements only correspondent node functionality, or > > has not been configured to act as a home agent,[...] > > The 'node' (the home agent) can thus implement only CN functionality. > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext > > Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From OphelialopsidedBartley@transcendentalists.com Thu Dec 27 01:07:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ltl-0005Om-Ll; Thu, 27 Dec 2007 01:07:17 -0500 Received: from [85.105.185.70] (helo=anamuh) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7ltl-0000Mx-7I; Thu, 27 Dec 2007 01:07:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host90486482.transcendentalists.com (8.13.1/8.13.1) with SMTP id X7NQGDTH04.133744.mSs.qwO.4531684999100 for ; Thu, 27 Dec 2007 08:09:40 -0200 Message-ID: From: "Maryanne Bain" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_DE5E_01C8484F.1CAAA1E0-- From mext-bounces@ietf.org Thu Dec 27 01:15:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7m17-0003qo-4H; Thu, 27 Dec 2007 01:14:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7m15-0003qj-Ie for mext@ietf.org; Thu, 27 Dec 2007 01:14:51 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7m13-0000Vd-2o for mext@ietf.org; Thu, 27 Dec 2007 01:14:50 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lBR6BAE15149; Thu, 27 Dec 2007 06:11:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Reliability of sending BRR by the HA? Date: Thu, 27 Dec 2007 00:14:34 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Reliability of sending BRR by the HA? Thread-Index: AchH4a0uyIWaf/fdRAO9BE3G7D/4yAADMtIgABgeBoA= References: <475FED61.2060606@gmail.com><476B91B0.8030805@gmail.com><476BC613.8020906@gmail. com><47 6 BCCF0.1020202@gmail.com><476BEE14.2090405@gmail.com><476C2610.3000101@gmail.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "marcelo bagnulo braun" X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >=20 > > so, is there any text in rfc3775 that can possibly create confusion=20 > > about HAs using BRR or BEs? Does anyone has interpreted=20 > rfc3775 in the=20 > > way that HAs should send BRR and BEs? > >=20 > > again, while it may be a good idea that HAs do send BRR ad=20 > BE (i don't=20 > > know) this is not what is relevant for rfc3775 update processs, but=20 > > whether rfc3775 is unclear about that >=20 > [Ahmad] > There is no mention anywhere in RFC3775 that HA can send BRR=20 > or BErr. I also may add that there is no confusion!:) [Ahmad] Hi Marcelo, hmmmm, technically this could be true with respect to Berr, However, I = was referring to BRR! My bad I overlooked the BErr here. I will follow = on the BErr discussion on the same thread in reply to Kiyoaki. Regards, Ahmad >=20 > >=20 > > Regards, marcelo > >=20 > >=20 > > El 22/12/2007, a las 8:29, Ahmad Muhanna escribi=F3: > >=20 > > >> > > >> What exactly doesn't scale? I think HA sending BRR is as =20 > > >> scalable as > > >> MN sending BU to it. What's the non-scaling factor > > introduced by BRR > > >> at HA? > > > > > > [Ahmad] > > > Read below. > > > > > >> > > >>>>> 5. If the HA needs to send a reminder to every MN about > > >> the expiry > > >>>>> of its BCE, then we are introducing a new functionality which=20 > > >>>>> violates the basic RFC3775 functionality and a non sense > > >> complexity > > >>>>> that absolutely is not necessary and not within the original=20 > > >>>>> intention of RFC3775. > > >>>> > > >>>> In what does that HA-sends-BRR functionality violate the > > >> basic 3775? > > >>>> What does it break? > > >>> > > >>> [Ahmad] I am not sure if what does break is the right > > question here. > > >> > > >> But you used the word 'violate' - what does it violate then? > > > > > > [Ahmad] > > > Please read below. > > >> > > >>> It is a new functionality which is fundamentally in > > >> conflict with the > > >>> original RFC3775 intention of how MIP6 BCE is managed at the HA. > > >> > > >> Sorry, what's the conflict you point out? It's not a=20 > new message=20 > > >> format, not any new option. > > > > > > [Ahmad] > > > Please read below. > > >> > > >>> However, let me explain what could happen in case that the HA=20 > > >>> implements this new weird functionality: > > >>> > > >>> 1. Some of the HA are talking about supporting a million BCE=20 > > >>> simultaneously. Do you understand the impact on the HA when > > >> these BCEs > > >>> starts getting close to expiry? > > >> > > >> Ah! I didn't assume that all MNs send BUs simultaneously with=20 > > >> precisely the same lifetime. You seem to assume so. If > > so then we > > >> have a BU storm in first place, prior to BRR. > > >> > > >> If you didn't assume all million MNs send the BUs > > simultaneously then > > >> the BRRs aren't sent simultaneously either. > > > > > > [Ahmad] > > > Alex, > > > Hopefully, this is my last explanation to help clarify your=20 > > > understanding of the applicability and use of BRR by the HA. > > > > > > It is very strange that you understand things and > > functionalities only > > > according to your own terms and probably your > > implementation and past > > > experience. However, let me summarize what I want to say in > > an easier > > > to follow format: > > > > > > 1. Are you assuming that HA provides the same lifetime for > > all mobile > > > node and all different subscribers at all times? > > > 2. Are you assuming that, for example all subscribers including=20 > > > prepaid ones will end having the same BCE lifetime? > > > 3. Are you assuming that there is only your own limited > > understanding > > > of how the HA handles the BCE lifetime? > > > > > > 4. IF the answer to all of the above yes, then we have a > > very specific > > > HA application which is limited to Alex understanding of > > Mobile IPv6 > > > services and its applicability and at that point, there is > > no point of > > > discussing this any further! > > > > > > 5. However, If the answer is NO to any of 1-3 points, then > > when a HA > > > is able to support a high number of different types of=20 > subscribers=20 > > > BCE, then the possibility of too many BCE lifetimes to > > expire at the > > > same time is quite very very high and probably devastating > > to the HA > > > functionality. > > > > > > 6. If the answer to No. 5 is YES, then it is very possible > > for a huge > > > number of these BCE lifetime to expire at the same time and > > if the HA > > > needs to send BRR message to all of these MNs at the same=20 > time, it=20 > > > presents a new scalability challenge. In other words, this new=20 > > > functionality needs to be evaluated and a study of how the > > HA handles > > > this very frequent and new phenomena while the HA still > > supports the > > > proclaimed number of activation rate becomes very > > necessary; Hope this > > > one is clear! > > > > > > 7. You asked me if the BU/BAK/BRR is more reliable than=20 > the BU/BA,=20 > > > well, REGARDLESS!! since you admit that BU/BA is reliable, > > then that > > > all what we need and looking for. Your proposed=20 > enhancement is not=20 > > > needed, however, you can keep it specific to your own > > implementation.=20 > > > Unless, you still believe that RFC3775 protocol is BROKEN > > and does NOT > > > handle BU loss!? > > > > > > > > > 8. On another note you said: "BRR sent only if at end of > > lifetime when > > > the BU is not received." ok; Why do you think that the HA=20 > needs to=20 > > > send a BRR message to the MN after the MN BCE lifetime has > > expired. It > > > seems to me that you need to pay close attention to the=20 > difference=20 > > > between a MN Home BCE at the HA and a MN BCE at a CN. > > Please remember > > > that the lifetime of these two are DIFFERENT! And > > consequently what is > > > applicable to the handling of BCE at the CN is not=20 > necessarily TRUE=20 > > > for the MN home BCE. One more time, an expiry of the BCE=20 > at the CN=20 > > > means RO with that CN is lost but the MN is still reachable > > via the HA > > > BCE! > > > > > > 9. You also said: "No, keep the suggested lifetime field=20 > in BA and=20 > > > process it as usual."; excellent! Why then we need to > > introduce this > > > new functionality to do the same thing which is done by the BU/BA=20 > > > mechanism? > > > > > > 10. In reference to how the use of BRR is more reliable, you also > > > said: > > > "A form of three-way handshake is better reliability than=20 > a two-way=20 > > > exchange."; Man, it seems that you always tends to think=20 > of success=20 > > > scenarios! You just said that the HA would send the BRR > > after the BCE > > > lifetime expires, well, let me add one more thing and the MN is=20 > > > probably gone home and no longer there. What kind of > > reliability you > > > are achieving by sending a BRR for a MN which is probably > > not there.=20 > > > This will be the vast majority of the scenarios that your > > BRR will be > > > addressing anyway. Let me ask one more time, do you still > > think that > > > is a better reliability? :) > > > > > > 11. You seem to understand that supporting BRR message at the HA=20 > > > nothing but sending a BRR message! This is unfortunate! > > Supporting BRR > > > is far more complex and a new functionality than you have > > in mind and > > > you ever thought! Just as a reminder, All RFC3775 HA=20 > operations and=20 > > > state machines is processing a request that generates a > > reply in some > > > form of Ack! Do you understand what does that mean and its > > difference > > > from supporting BRR?! Please think again. > > > > > > 12. However, if you are proposing that the MN is not > > supposed to send > > > a BU to renew its BCE lifetime except after it receives a > > BRR message > > > from its HA, then that probably a different discussion that needs=20 > > > another round which I am not willing to be part of and I > > consider it a > > > waste of time :-)))) > > > > > > 13. You also said: "I meant to say that the effect of BRR being=20 > > > specified and implemented for CN is more reliable BCE at=20 > CN. Let's=20 > > > have the same level of reliability at HA." Man! Read the=20 > above. You=20 > > > seem not to understand the difference! > > > > > > 14. You also said: "Or maybe we just want to stress that some HA=20 > > > implementations do BRR. Or do we want to forbid HA > > implementations to > > > do BRR." Again, I am not sure if you realize the difference > > in the BRR > > > applicability to CN BCE vs. HA BCE. IMO, the usecase you > > presented is > > > not worth to be discussed unless you believe and can prove that > > > RFC3775 > > > protocol is BROKEN and does not handle BU loss! > > > > > > 15. In your explanation of your earlier comment of "and > > thus reduces > > > the non-bound time from the entire lifetime to much less" You also > > > said: "If > > > the BU is lost then MN will send another BU at the end of > > the current > > > lifetime. Instead of waiting for the current lifetime to=20 > expire it=20 > > > could be triggered by a BRR received from the HA." :-(((( > > > > > > well, that is really an optimization for a HA implementation! > > > > > > Your statement is contradictory to what you said earlier.=20 > You said=20 > > > that BRR is sent after the BCE lifetime expires and here > > you said that > > > the HA would send a BRR before the BCE expires. How the=20 > HA one time=20 > > > decides to send a BRR before the end of BCE and some time=20 > after the=20 > > > lifetime expires. On the other hand, why the BU/BA > > mechanism does not > > > work for the BU loss? You MUST explain why you think that > > it does NOT > > > work? Do you mean that the MN will send one single BU and > > that is it!=20 > > > Do you assume that the MN does not use retransmission? > > > > > > Also, you are assuming that the MN will wait until the last > > second of > > > its BCE lifetime and then send a BU!? On the other hand, > > have you ever > > > heard of the Binding Refresh Advice mobility option? Does > > the testing > > > client in your test bed understand this option, what about > > the HA does > > > it support that option? Please take a look and try to > > understand the > > > value of this option. May be after reading about it you=20 > would find=20 > > > what is missing? IMO, all reliable MIP6 clients would > > initiate their > > > BCE lifetime refresh registration before the end of the home BCE=20 > > > lifetime! > > > > > > 16. In reference to RFC3775 text supporting your > > understanding of the > > > CN being a HA you said: " Right... difficult to find=20 > right now..."=20 > > > Cool take your time and when you find it, please let me=20 > know. BTW:=20 > > > That is an important piece of your reasoning for supporting this > > > functionality:) No? > > > > > > 17. finally you said: "When do we discuss BErr? (Binding Error)" > > > Probably after you show that you understand the difference in=20 > > > applicability of BRR on the MN BCE at CN vs. MN BCE at HA. > > > > > > > > > Cheers! > > > Ahmad > > > > > >> > > >>> and the HA needs to send a BRR message and not only that but=20 > > >>> retransmits those messages until a BU is received from > > each one of > > >>> these MNs? > > >> > > >> The BRR is sent only if the BU is not received at HA the > > end of the > > >> lifetime. It is not _always_ sent. That is current > > behaviour of CN. > > >> > > >>> 3. Personally, I wont agree to such functionality because > > >> Home Agent > > >>> acts as a server offering a MIP6 mobility service to=20 > multiple MNs=20 > > >>> governed by a MIP6 protocol which offers a reliable=20 > mechanism for=20 > > >>> updating the MN BCE lifetime at the HA. > > >> > > >> BU/BAck is reliable - BU/BAck/BRR is more reliable. Would > > you agree? > > >> > > >>> 4. Let us assume for the sake of argument that this new > > >> functionality > > >>> is supported by the HA, what is the impact: 4.1. Can you > > >> imagine the > > >>> unnecessary traffic that is generated for no reason. > > >> > > >> No, no unnecessary traffic. BRR sent only if at end of > > lifetime the > > >> BU is not received. > > >> > > >>> 4.2. What is going to be the MN processing when it > > receives such a > > >>> message? All current RFC3775 text talks about a BRR > > coming from the > > >>> CN. Is there going to be a difference in there? > > >> > > >> No difference. > > >> > > >>> 4.3. How MN would recognize that this message is related to > > >> MN BCE at > > >>> the HA? > > >> > > >> It doesn't need to distinguish this - why do you think it should=20 > > >> distinguish? (if it wants so then it has the HA address > > thus it can > > >> answer the q you raise). > > >> > > >>> 4.4. Backward compatibility, How, this would work for MN > > which only > > >>> supports BRR from the CN? > > >> > > >> How does MN know BRR is from CN and not from HA? I don't > > think MNs > > >> implement BRR such as to be _only_ from CN. It can't > > distinguish the > > >> BRR coming from CN, it just sees an IP address. > > >> > > >>> 4.5. Finally, if this procedure is adopted, are we going to > > >> deprecate > > >>> the existing one using lifetime field in BA, etc? 4.6. etc. > > >> > > >> No, keep the suggested lifetime field in BA and process it > > as usual. > > >> > > >>>> I see it offering better reliability: even if the critical > > >> BU is lost > > >>>> the HA requests the BU anew (BRR) and thus reduces the > > >> non-bound time > > >>>> from the entire lifetime to much less. > > >>> > > >>> [Ahmad] 1. Wow! Are you calling this a better > > reliability? What is > > >>> your definition of reliability then? > > >> > > >> A form of three-way handshake is better reliability than=20 > a two-way=20 > > >> exchange. > > >> > > >>> 2. Are you suggesting that the current RFC3775 protocol is > > >> BROKEN and > > >>> does not address BU loss? > > >> > > >> No, not suggesting so. I suggest in certain conditions > > when the BU > > >> is lost, the HA using BRR leads to shorter wait for BCE update=20 > > >> (shorter than the current BU waiting for the next > > >> lifetime) - less interruption at MN. > > >> > > >>> 3. I do not understand what you mean by: "and thus reduces the=20 > > >>> non-bound time from the entire lifetime to much less" Can > > >> you please > > >>> elaborate more and explain? > > >> > > >> If the BU is lost then MN will send another BU at the end of the=20 > > >> current lifetime. Instead of waiting for the current=20 > lifetime to=20 > > >> expire it could be triggered by a BRR received from the HA. > > >> > > >> No difference between CN and HA here. > > >> > > >>>>> 6. On the other hand, CN maintains a limited number=20 > of BCE for=20 > > >>>>> specific mobile nodes and more importantly if the MN > > >> decides NOT to > > >>>>> renew its BCE with a specific CN, the MN continues to be > > >> reachable > > >>>>> by other CNs at its HoA and CoA via its Home Agent BCE. > > >>>>> In other words, a MN binding with another CN represent > > >> the service > > >>>>> (RO) between MN<->CN ONLY, however, in the case of HA it > > >> represents > > >>>>> the MN's MIP6 service and access to the whole internet. > > >> Which also > > >>>>> administratively governed. i.e. if the MN does not > > renew its BCE, > > >>>>> then that is a clear indication for the HA to delete=20 > the MN BCE. > > >>>> > > >>>> Not before it sends a BRR and waits for an answer to that. > > >>> > > >>> [Ahmad] What do you mean here, MN does not send a BU to > > refresh its > > >>> Home BCE lifetime except after receiving a BRR? > > >> > > >> No, I meant it sends its BU as usual, (I think 4s before > > the lifetime > > >> expires or so). > > >> > > >>>>> 7. Finally, the fact that RFC3775 mentions that CN could > > >> be a HA, > > >>>>> does not mean that the HA application at such a node need > > >> to support > > >>>>> BRR. > > >>>> > > >>>> That's your reading. Other implementers read it in the > > way I said. > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> [Ahmad] Excellent. Please cut and paste here the text where it=20 > > >>> supports your understanding? > > >> > > >> Right... difficult to find right now... > > >> > > >>>>> IMO, such a node could act as a CN for some MNs and a HA > > >> for others. > > >>>>> Then, it is normal for this CN/HA node to support BRR for > > >> those MN > > >>>>> which is serving as a CN but not a HA. > > >>>> > > >>>> Is a HA a "CN" when it is the dst field of the BU? > > >>> > > >>> [Ahmad] I am not sure what you are trying to say here, > > but for now, > > >>> let us focus on the real issue as highlighted above. Thanks! > > >> > > >> I meant to say that the effect of BRR being specified and > > implemented > > >> for CN is more reliable BCE at CN. Let's have the same level of=20 > > >> reliability at HA. > > >> > > >> Or maybe we just want to stress that some HA > > implementations do BRR. =20 > > >> Or do we want to forbid HA implementations to do BRR. > > >> > > >> When do we discuss BErr? (Binding Error) > > >> > > >> Alex > > >> > > >> > > >>=20 > >=20 > _____________________________________________________________________ > > >> _ > > >> This email has been scanned by the MessageLabs Email > > Security System. > > >> For more information please visit > > >> http://www.messagelabs.com/email > > >>=20 > >=20 > _____________________________________________________________________ > > >> _ > > >> > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > >=20 > >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 27 02:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7n64-0005va-1e; Thu, 27 Dec 2007 02:24:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7n61-0005m5-Ol for mext@ietf.org; Thu, 27 Dec 2007 02:24:01 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7n60-0001j3-Vi for mext@ietf.org; Thu, 27 Dec 2007 02:24:01 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lBR7NsG22061; Thu, 27 Dec 2007 07:23:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] RE: Reliability of sending BRR by the HA? Date: Thu, 27 Dec 2007 01:23:23 -0600 Message-ID: In-Reply-To: <200712271209.BDG82321.BVHULJXB@ysknet.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] RE: Reliability of sending BRR by the HA? Thread-Index: AchINhFOzgSfutgmTFecUZyKIvICIgAGLjrA References: <476C2610.3000101@gmail.com> <47729C52.7080305@gmail.com> <200712271209.BDG82321.BVHULJXB@ysknet.co.jp> From: "Ahmad Muhanna" To: "K.Kawaguchi" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Kiyoaki, Please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp]=20 > Sent: Wednesday, December 26, 2007 9:10 PM > To: alexandru.petrescu@gmail.com > Cc: mext@ietf.org > Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? >=20 > Hi, >=20 > Couldn't we understand description in RFC3775 as follows? >=20 > BRR > CN sends BRR. > - Section 9.5 described Registration of CN. > In it, section 9.5.5 described Sending BRR. >=20 > HA does not send BRR. > - Section 10.3 described Rigistration of HA. > Although section 9.5.1 and section 9.5.4 were referred=20 > to, section 9.5.5 wasn't referred to. [Ahmad] I agree. >=20 >=20 > BE > CN sends BE (status=3D1) and BE (status=3D2). > - Section 9.2 described Sending BE (status=3D2). > - Section 9.3.1 described Sending BE (status=3D1). >=20 > HA sends BE (status=3D1) and BE (status=3D2). > - Section 10.2 described Sending BE (status=3D2) by the same=20 > processing as a section 9.2. [Ahmad] I agree. > - Section 10.3.1 described Sending BE (status=3D1) by the=20 > same processing as section 9.3.1. [Ahmad] I am not sure if this applicable to the Home Agent, unless I am missing something.=20 Under section 10.3.1., it says: " o A Home Address destination option MUST be present in the message. It MUST be validated as described in Section 9.3.1 with the following additional rule. The Binding Cache entry existence test MUST NOT be done for IPsec packets when the Home Address option contains an address for which the receiving node could act as a home agent. " The above bullet clearly mentions that the Home Address destination option MUST be present. It also, says that it MUST validate the Binding Cache entry as per the rules mentioned in section 9.3.1. However, it eliminates that check in the case IPsec is used and the receiving node is a HA. i.e. if the receiving node a HA and IPsec is in used, these checks are not applicable.=20 Also as per section 9.3.1.: it says: " 9.3.1. Receiving Packets with Home Address Option Packets containing a Home Address option MUST be dropped if the given home address is not a unicast routable address. Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update. If the packet is dropped due the above tests, the correspondent node MUST send the Binding Error message as described in Section 9.3.3. The Status field in this message should be set to 1 (unknown binding for Home Address destination option). " The above three paragraphs list the following: 1. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. 2. If there is a corresponding binding cache entry, the following check is required and if failed, packet is dropped: " A corresponding Binding Cache entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. " 3. In the third paragraph is says, if the packet is dropped based on any of the above two cases (1 & 2). The correspondent node MUST send the BE as in section 9.3.3. with code 1 "unknown binding for Home Address destination option. However, the end of the second paragraph clearly says that the above two tests are clearly NOT required in case of the packet has a Home Address option and at the same time it contains a Binding Update, i.e. if the receiving node is a HA, it will NOT perform this check and consequently will not send a BE message with code 1. Best Regards, Ahmad >=20 > MN sends BE (status=3D2). MN does not send BE (status=3D1). > - Section 11.2 described Sending BE (status=3D2) by the same=20 > processing as a section 9.2. > - There is no section about Sending BE (status=3D2). >=20 >=20 > Best regards > --- > Kiyoaki KAWAGUCHI >=20 >=20 >=20 > "Alexandru Petrescu" wrote: > > marcelo bagnulo braun wrote: > > > Hi, > > >=20 > > > i am trying to understand the impact of this in rfc3775 update > > >=20 > > > I don't think that whether it is a good idea to use BRR=20 > from the HA=20 > > > is relevant for the discussion of RFC3775 update (it is of course=20 > > > relevant for the mext ml but not imho for this particular=20 > process of=20 > > > updating rfc3775) > > >=20 > > > what imho is relavnt for the discussion of updating rfc3775 is=20 > > > whether rfc3775 is clear enough about whether HAs should=20 > send BRR or=20 > > > not > > >=20 > > > From the text of rfc3775 that Alex sent in his original=20 > posting, it=20 > > > seems that only CNs should send BRR and BE and not by the=20 > HA, so, is=20 > > > there any text in rfc3775 that can possibly create=20 > confusion about=20 > > > HAs using BRR or BEs? Does anyone has interpreted rfc3775=20 > in the way=20 > > > that HAs should send BRR and BEs? > >=20 > > I will invite other implementers express whether it's clear=20 > or not who=20 > > sends BRR and BErr. > >=20 > > For my reading, there are some occurences about the=20 > possibility of HA=20 > > being a CN, for example section 10.3.1 "Primary Care-of Address=20 > > Registration" in 10.3 "Processing Bindings" in 10 "HA Operation": > >=20 > > rfc3775: > > [...] > > > To begin processing the Binding Update, the home agent=20 > MUST perform=20 > > > the following sequence of tests: > > >=20 > > > o If the node implements only correspondent node=20 > functionality, or=20 > > > has not been configured to act as a home agent,[...] > >=20 > > The 'node' (the home agent) can thus implement only CN=20 > functionality. > >=20 > > Alex > >=20 > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email=20 > Security System. > > For more information please visit http://www.messagelabs.com/email=20 > >=20 > ______________________________________________________________________ > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > >=20 > >=20 >=20 >=20 > Best regards > --- > Kiyoaki KAWAGUCHI >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Dec 27 03:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7o6W-0004fh-N7; Thu, 27 Dec 2007 03:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7o6V-0004fc-0a for mext@ietf.org; Thu, 27 Dec 2007 03:28:35 -0500 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J7o6S-0002xv-BR for mext@ietf.org; Thu, 27 Dec 2007 03:28:34 -0500 Received: (qmail 13248 invoked from network); 27 Dec 2007 17:28:29 +0900 Received: from (HELO MIP6-150) (@) by with SMTP; 27 Dec 2007 17:28:29 +0900 To: amuhanna@nortel.com Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? From: "K.Kawaguchi" References: <47729C52.7080305@gmail.com> <200712271209.BDG82321.BVHULJXB@ysknet.co.jp> In-Reply-To: Message-Id: <200712271728.EAD56233.XLJHUBBV@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 27 Dec 2007 17:28:27 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi, ""Ahmad Muhanna" " wrote: > Hi Kiyoaki, > Please see comments inline. > > Regards, > Ahmad > > > > -----Original Message----- > > From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp] > > Sent: Wednesday, December 26, 2007 9:10 PM > > To: alexandru.petrescu@gmail.com > > Cc: mext@ietf.org > > Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA? > > > > Hi, > > > > Couldn't we understand description in RFC3775 as follows? > > > > BRR > > CN sends BRR. > > - Section 9.5 described Registration of CN. > > In it, section 9.5.5 described Sending BRR. > > > > HA does not send BRR. > > - Section 10.3 described Rigistration of HA. > > Although section 9.5.1 and section 9.5.4 were referred > > to, section 9.5.5 wasn't referred to. > > [Ahmad] > I agree. > > > > > > > BE > > CN sends BE (status=1) and BE (status=2). > > - Section 9.2 described Sending BE (status=2). > > - Section 9.3.1 described Sending BE (status=1). > > > > HA sends BE (status=1) and BE (status=2). > > - Section 10.2 described Sending BE (status=2) by the same > > processing as a section 9.2. > > [Ahmad] > I agree. > > > - Section 10.3.1 described Sending BE (status=1) by the > > same processing as section 9.3.1. > > [Ahmad] > I am not sure if this applicable to the Home Agent, unless I am missing > something. > > Under section 10.3.1., it says: > " > o A Home Address destination option MUST be present in the message. > It MUST be validated as described in Section 9.3.1 with the > following additional rule. The Binding Cache entry existence test > MUST NOT be done for IPsec packets when the Home Address option > contains an address for which the receiving node could act as a > home agent. > " > > The above bullet clearly mentions that the Home Address destination > option MUST be present. It also, says that it MUST validate the Binding > Cache entry as per the rules mentioned in section 9.3.1. However, it > eliminates that check in the case IPsec is used and the receiving node > is a HA. i.e. if the receiving node a HA and IPsec is in used, these > checks are not applicable. > > Also as per section 9.3.1.: it says: > > " > 9.3.1. Receiving Packets with Home Address Option > > Packets containing a Home Address option MUST be dropped if the given > home address is not a unicast routable address. > > Mobile nodes can include a Home Address destination option in a > packet if they believe the correspondent node has a Binding Cache > entry for the home address of a mobile node. Packets containing a > Home Address option MUST be dropped if there is no corresponding > Binding Cache entry. A corresponding Binding Cache entry MUST have > the same home address as appears in the Home Address destination > option, and the currently registered care-of address MUST be equal to > the source address of the packet. These tests MUST NOT be done for > packets that contain a Home Address option and a Binding Update. > > If the packet is dropped due the above tests, the correspondent node > MUST send the Binding Error message as described in Section 9.3.3. > The Status field in this message should be set to 1 (unknown binding > for Home Address destination option). > " > > The above three paragraphs list the following: > > 1. Packets containing a Home Address option MUST be dropped if there is > no corresponding Binding Cache entry. > 2. If there is a corresponding binding cache entry, the following check > is required and if failed, packet is dropped: > " > A corresponding Binding Cache entry MUST have > the same home address as appears in the Home Address destination > option, and the currently registered care-of address MUST be equal to > the source address of the packet. > " > 3. In the third paragraph is says, if the packet is dropped based on any > of the above two cases (1 & 2). The correspondent node MUST send the BE > as in section 9.3.3. with code 1 "unknown binding for Home Address > destination option. > > However, the end of the second paragraph clearly says that the above two > tests are clearly NOT required in case of the packet has a Home Address > option and at the same time it contains a Binding Update, i.e. if the > receiving node is a HA, it will NOT perform this check and consequently > will not send a BE message with code 1. > [kiyoaki] I agree. I forgot to add one more case. It seems that this case is not clear at RFC3775. It is a case where the home address option is added to some message which HA and MN receive. A node without MIP6 function replys ICMPv6 Parameter Problem (Section 4 in RFC2460). How are HA and MN? I hope that this is described in the section of HA and MN. And I think that it refers to as same as section 9.3.1 in RFC3775. Best regards --- Kiyoaki KAWAGUCHI > Best Regards, > Ahmad > > > > > > > MN sends BE (status=2). MN does not send BE (status=1). > > - Section 11.2 described Sending BE (status=2) by the same > > processing as a section 9.2. > > - There is no section about Sending BE (status=2). > > > > > > Best regards > > --- > > Kiyoaki KAWAGUCHI > > > > > > > > "Alexandru Petrescu" wrote: > > > marcelo bagnulo braun wrote: > > > > Hi, > > > > > > > > i am trying to understand the impact of this in rfc3775 update > > > > > > > > I don't think that whether it is a good idea to use BRR > > from the HA > > > > is relevant for the discussion of RFC3775 update (it is of course > > > > relevant for the mext ml but not imho for this particular > > process of > > > > updating rfc3775) > > > > > > > > what imho is relavnt for the discussion of updating rfc3775 is > > > > whether rfc3775 is clear enough about whether HAs should > > send BRR or > > > > not > > > > > > > > From the text of rfc3775 that Alex sent in his original > > posting, it > > > > seems that only CNs should send BRR and BE and not by the > > HA, so, is > > > > there any text in rfc3775 that can possibly create > > confusion about > > > > HAs using BRR or BEs? Does anyone has interpreted rfc3775 > > in the way > > > > that HAs should send BRR and BEs? > > > > > > I will invite other implementers express whether it's clear > > or not who > > > sends BRR and BErr. > > > > > > For my reading, there are some occurences about the > > possibility of HA > > > being a CN, for example section 10.3.1 "Primary Care-of Address > > > Registration" in 10.3 "Processing Bindings" in 10 "HA Operation": > > > > > > rfc3775: > > > [...] > > > > To begin processing the Binding Update, the home agent > > MUST perform > > > > the following sequence of tests: > > > > > > > > o If the node implements only correspondent node > > functionality, or > > > > has not been configured to act as a home agent,[...] > > > > > > The 'node' (the home agent) can thus implement only CN > > functionality. > > > > > > Alex > > > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit http://www.messagelabs.com/email > > > > > ______________________________________________________________________ > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > Best regards > > --- > > Kiyoaki KAWAGUCHI > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www1.ietf.org/mailman/listinfo/mext > > > > Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From asmin-Truchel@g-pp.de Thu Dec 27 04:04:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ofB-0002Pj-DV for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 04:04:25 -0500 Received: from ppp089210200003.dsl.hol.gr ([89.210.200.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7ofA-0004Em-QC for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 04:04:25 -0500 Received: by 10.177.236.46 with SMTP id BYpfmRgBhWmgK; Thu, 27 Dec 2007 11:04:32 +0200 (GMT) Received: by 192.168.118.202 with SMTP id bpGdtZRDFwdibn.8705414787058; Thu, 27 Dec 2007 11:04:30 +0200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Dec 2007 11:04:27 +0200 To: nemo-archive@lists.ietf.org From: "asmin Truchel" Subject: neffarge Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Pleasure your lady with a huge impressive schlong! http://latiues.com/ From tequila_51@hotmail.com Thu Dec 27 04:16:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7orA-0005ZJ-A2; Thu, 27 Dec 2007 04:16:48 -0500 Received: from [85.103.78.137] (helo=[85.103.78.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7or9-0004fV-0c; Thu, 27 Dec 2007 04:16:48 -0500 Received: from [85.103.78.137] by mx1.hotmail.com; Thu, 27 Dec 2007 11:16:52 +0200 Message-ID: <01c84879$fb096a00$894e6755@tequila_51> From: "Trey Bonner" To: Subject: Re: Bonner Date: Thu, 27 Dec 2007 11:16:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db You know your girl really likes it the longer you can perform, help her and yourself out. http://www.Poehslowse.com complaint purely , and how to exploit Jennifer Gervasio and comprehensive neurobiology, cognitive resists From AngelomorelandBenson@30secondstomars.com Thu Dec 27 05:04:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7pay-0007rI-A7; Thu, 27 Dec 2007 05:04:08 -0500 Received: from [218.234.223.71] (helo=userpc.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7pax-0005o6-UC; Thu, 27 Dec 2007 05:04:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host08109366.30secondstomars.com (8.13.1/8.13.1) with SMTP id i95YyrBZ72.730636.c3P.WrL.3792714707993 for ; Thu, 27 Dec 2007 19:03:33 -0900 Message-ID: <1a74e01c8486f$cdff00b0$020aa8c0@userpc> From: "Shaun Baldwin" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_1A74A_01C8486F.CDFF00B0-- From fetahenilvcg@dist202.org Thu Dec 27 07:00:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7rPb-0006Pt-RL for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 07:00:31 -0500 Received: from athedsl-83970.home.otenet.gr ([87.203.81.80] helo=athedsl-297250.home.otenet.gr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7rPb-0000Je-2C for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 07:00:31 -0500 Received: by 10.115.203.221 with SMTP id WFGhYIkGHhZSy; Thu, 27 Dec 2007 14:00:39 +0200 (GMT) Received: by 192.168.190.76 with SMTP id mRorzDCHQGavVK.6452806697700; Thu, 27 Dec 2007 14:00:37 +0200 (GMT) Message-ID: <99EC7726.AFAF0E4A@dist202.org> Date: Thu, 27 Dec 2007 14:00:34 +0200 From: "Rich fetahen" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: puissanc Content-Type: multipart/alternative; boundary="------------050204000406040202000404" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------050204000406040202000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Real growth, real man! http://neoiuset.com/ --------------050204000406040202000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Real growth, real man! http://neoiuset.com/
--------------050204000406040202000404-- From NicoleagrarianGriggs@marketwatch.com Thu Dec 27 11:19:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7vS0-0002Z1-Bd; Thu, 27 Dec 2007 11:19:16 -0500 Received: from 190-82-246-57.adsl.cust.tie.cl ([190.82.246.57] helo=u8o7u3.belkin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J7vRz-0006xS-Ro; Thu, 27 Dec 2007 11:19:16 -0500 Received: from dyke by marketwatch.com with SMTP id Pm48iZk0ay for ; Thu, 27 Dec 2007 13:18:35 +0400 From: "Ashley Childress" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7xS2-0003dN-O1; Thu, 27 Dec 2007 13:27:26 -0500 Received: from [89.137.249.152] (helo=computer) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7xS1-0002FM-FD; Thu, 27 Dec 2007 13:27:26 -0500 Received: from [89.137.249.152] by mx1.icq.mail2world.com; Thu, 27 Dec 2007 20:27:25 +0200 From: "Sarah Armstrong" To: Subject: Doctor Approved And Recommended Date: Thu, 27 Dec 2007 20:27:25 +0200 Message-ID: <01c848c6$e43d3480$98f98959@temontanha> 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, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Score: 2.4 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Larger and Larger http://rotuebu.com From gabaca@bhaktinova.com Thu Dec 27 14:54:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7yo6-0007H8-VG for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 14:54:18 -0500 Received: from 62.174.113.235.dyn.user.ono.com ([62.174.113.235] helo=c80d4007e9f0410) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7yo5-000537-Oj for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 14:54:18 -0500 Received: from [62.174.113.235] by bhaktinova.com; Thu, 27 Dec 2007 20:59:31 +0100 From: "Wyatt Gill" To: Subject: Re: Wyatt Date: Thu, 27 Dec 2007 20:59:31 +0100 Message-ID: <01c848cb$60397b80$eb71ae3e@gabaca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 Importance: Normal X-Spam-Score: 1.7 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Perhaps your girl really likes it the longer you can go, help her and you out. http://www.Lizwestarsoo.com hear if you would own with your co-worker "In the current environment where investment advisory service used in the Java API parents and From mext-bounces@ietf.org Thu Dec 27 16:30:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J80In-0000lE-Uu; Thu, 27 Dec 2007 16:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J80Ik-0000aq-FZ; Thu, 27 Dec 2007 16:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J80Ik-0001NJ-2i; Thu, 27 Dec 2007 16:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EB48026E6E; Thu, 27 Dec 2007 21:30:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J80Ij-0003AF-S7; Thu, 27 Dec 2007 16:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Dec 2007 16:30:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aaa-ha-goals-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : AAA Goals for Mobile IPv6 Author(s) : G. Giaretta, et al. Filename : draft-ietf-mext-aaa-ha-goals-00.txt Pages : 12 Date : 2007-12-27 In commercial and enterprise deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mext-aaa-ha-goals-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mext-aaa-ha-goals-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: <2007-12-27162813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mext-aaa-ha-goals-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mext-aaa-ha-goals-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-27162813.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --NextPart-- From Krushelnicki@tjtest.com Thu Dec 27 21:43:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J85Bz-0003TP-Sx for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 21:43:23 -0500 Received: from [58.175.65.37] (helo=[58.175.65.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J85Bz-0005li-6Y for nemo-archive@lists.ietf.org; Thu, 27 Dec 2007 21:43:23 -0500 Received: from user-ec8b2889c9 by tjtest.com with ASMTP id 09F2C9BE for ; Thu, 24 Jan 2008 13:45:14 +0900 Received: from user-ec8b2889c9 ([180.174.111.81]) by tjtest.com with ESMTP id F34F96BD0810 for ; Thu, 24 Jan 2008 13:45:14 +0900 Message-ID: Date: Thu, 24 Jan 2008 13:44:49 +0900 From: "Domenick Krushelnicki" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: sperdeva Content-Type: multipart/alternative; boundary="------------060706010601060308060302" X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --------------060706010601060308060302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The journey to eternal sexual enjoyment starts here. http://cheozsal.com/ --------------060706010601060308060302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The journey to eternal sexual enjoyment starts here. http://cheozsal.com/
--------------060706010601060308060302-- From HubertslashLyons@twtelecom.com Thu Dec 27 21:54:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J85NC-0001W0-Kl; Thu, 27 Dec 2007 21:54:58 -0500 Received: from host67-141-dynamic.22-79-r.retail.telecomitalia.it ([79.22.141.67] helo=charly60cd6de6.homenet.telecomitalia.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J85NC-0005wb-2o; Thu, 27 Dec 2007 21:54:58 -0500 Received: from iambic by twtelecom.com with SMTP id 4YwDPKSATD for ; Fri, 28 Dec 2007 03:52:12 -0100 From: "Rex Baldwin" To: Subject: Our casino is for you who likes to win! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071227-0, 27/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Get to know your new casino home! Our safe, secure games will get you smiling when you start seeing dollars pouring in. When YOU WIN, we win! Travel no further than your screen and get your free $2400 http://topgoldcasino7.com/ From teqohixu@fa.org Thu Dec 27 22:23:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J85oN-0000np-OW; Thu, 27 Dec 2007 22:23:03 -0500 Received: from port0235-adf-adsl.cwjamaica.com ([72.27.39.235] helo=speedtouch.lan) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J85oM-0006eo-Ia; Thu, 27 Dec 2007 22:23:03 -0500 Received: from [72.27.39.235] by mx1.lightpath.net; Thu, 27 Dec 2007 21:23:07 -0600 Date: Thu, 27 Dec 2007 21:23:07 -0600 From: "Josef Walton" X-Mailer: The Bat! (v3.62.03) Educational Reply-To: teqohixu@fa.org X-Priority: 3 (Normal) Message-ID: <634044085.73142065925651@fa.org> To: mpls-request@lists.ietf.org Subject: Re: Walton MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Improve yourself and your women, display her a enhanced you. http://www.teopwerl.com your complaint because Best of all, in a way that won't the report says. focus for obtaining (and too short) to spend A lack of spontaneous From jkl@uskay.com Fri Dec 28 04:27:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8BUb-0004C4-Jg; Fri, 28 Dec 2007 04:27:01 -0500 Received: from [79.139.203.167] (helo=home) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8BUa-0007H8-6j; Fri, 28 Dec 2007 04:27:01 -0500 Received: from [79.139.203.167] by m1.dnsix.com; Fri, 28 Dec 2007 12:26:02 +0300 Date: Fri, 28 Dec 2007 12:26:02 +0300 From: "Louella Gregg" X-Mailer: The Bat! (v2.11) Business Reply-To: jkl@uskay.com X-Priority: 3 (Normal) Message-ID: <989984449.81931360913817@uskay.com> To: mpls-request@lists.ietf.org Subject: We have everything your looking for MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Great Gift ideas online Top Quality for Men, Women and Kids http://syoldyear.com And trumpet at his lips; nor does he cast Père and Mère Chose could be in conversation Pallid waste where no radiant fathomers, From ErickalabilityMedeiros@re-title.com Fri Dec 28 09:42:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8GPy-00040J-Bi; Fri, 28 Dec 2007 09:42:34 -0500 Received: from dxb-as66635.alshamil.net.ae ([86.97.127.87] helo=intel.domain.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8GPx-0000w0-2P; Fri, 28 Dec 2007 09:42:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host64010685.re-title.com (8.13.1/8.13.1) with SMTP id c0tWQr5q69.302905.YO9.Ige.7425635729941 for ; Fri, 28 Dec 2007 18:38:10 -0400 Message-ID: <773b701c8495f$711791f0$03fea8c0@intel> From: "Melisa Chin" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_773B3_01C8495F.711791F0-- From mext-bounces@ietf.org Fri Dec 28 10:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HQe-0005y9-Kj; Fri, 28 Dec 2007 10:47:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HQe-0005vV-1z for mext@ietf.org; Fri, 28 Dec 2007 10:47:20 -0500 Received: from fg-out-1718.google.com ([72.14.220.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8HQd-0002wX-C0 for mext@ietf.org; Fri, 28 Dec 2007 10:47:19 -0500 Received: by fg-out-1718.google.com with SMTP id 16so1876532fgg.41 for ; Fri, 28 Dec 2007 07:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wUT9q/enD42M6K8YhLDVN7EUeQwYjlw1191dPvm61Ss=; b=ZdpfDWjWDPtWONOifEl1dMr3t8XkYruUGvxLrzWcIPEMCZXzzn5iY2iDnx+IYp67bcEWirsKvVZNSRcFS1UHvFT6q/qdFUZ3G+dzXP4g+bYEPK7LB7qQWfzi7m97kl8fC9aoLeUKe6lXc+O2niu7YW2tAP+dZkVc7hinQ/e1AB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ufFQlqlpPoLlb0D7WZexMLVfPQ118dtTZ86yIxbzZj+rTTJG0naDBMhCm0bNxm5D/W3mLSehx3syO6mKub7ALYMTQ7OixwS9KrvjhHNVgyDtq5AYOpRCxm2oj9cKeH0m5fA9EsqD1CPj4k2LjrgAnaKFPTeyZszuf7cywOz3bm4= Received: by 10.86.65.11 with SMTP id n11mr299380fga.4.1198856838555; Fri, 28 Dec 2007 07:47:18 -0800 (PST) Received: by 10.86.50.5 with HTTP; Fri, 28 Dec 2007 07:47:18 -0800 (PST) Message-ID: <729b68be0712280747m19d3df50x45845e3fd5c0708a@mail.gmail.com> Date: Fri, 28 Dec 2007 16:47:18 +0100 From: "Jean-Michel Combes" To: "George Tsirtsis" Subject: Re: [MEXT] [RFC3775 changes] Use of DHAAD mechanism? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0712110521g51bde3c5wb83d8569fa170449@mail.gmail.com> <475FF84F.7000802@gmail.com> <729b68be0712171525r6caca95m98007ba76109bffc@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi George, 2007/12/18, George Tsirtsis : > Another thing to do maybe would be to add text to the security section > indicating what the security issues with DHAAD might be. Good idea :) I will submit some text when I will come back from vacations. > I see what > you are saying wrt HA scanning but that may not always be a problem > e.g., for private HAs behind firewalls. Do you mean you filter and you allow only DHAAD requests from some MNs and you block all the others requests? But in this case, how will you set up the firewalls policy (i.e. based on which IP address?)? Best regards and happy new year. JMC. > > Again my understanding of the guidelines for the revision is that "if > it is not broken, do not fix it" :-) > > Regards > George > > On Dec 17, 2007 11:25 PM, Jean-Michel Combes > wrote: > > Hi George, > > > > 2007/12/17, George Tsirtsis : > > > I agree with Alex on this. I am not sure we have good justification > > > for removing DHAAD. The feature is not broken > > > > Not broken but: > > - unsecured > > - a nice tool to scan HAs owned by a Mobility Service Provider (which > > are the points of failure of a MIPv6 based service) > > > > > and arguably the > > > additional bootstraping mechanisms being defined, do not overlap with > > > it since they are dealing with the case when the HNP is not known to > > > the MN. > > > > So, if these solutions are better, why to keep DHAAD? > > > > Best regards. > > > > JMC. > > > > > > > > > > Regards > > > George > > > > > > On Dec 12, 2007 3:03 PM, Alexandru Petrescu > > > wrote: > > > > Jean-Michel Combes wrote: > > > > > Hi, > > > > > > > > > > > > > > > Section, sub-section and paragraph involved: 5.3, 6.5, 6.6, 10.5, > > > > > 11.4.1 > > > > > > > > > > OLD TEXT: -- > > > > > > > > > > NEW TEXT: None > > > > > > > > > > Motivations: - Two proposals have been specified and adopted by the > > > > > MIP6 WG to allow a MN to get its HA (i.e. bootstrapping mechanisms > > > > > for the split and the integrated scenario). - The present DHAAD > > > > > mechanism is, more or less, a scanning tool allowing anyone to know > > > > > what/where are the HAs owned by a Mobility Service Provider. - AFAIK, > > > > > DHAAD has not a critical use in others MIPv6 based protocols > > > > > > > > > > So, I wonder if it is still useful to keep the DHAAD mechanism in the > > > > > MIPv6 specification. > > > > > > > > > > Comments are welcome. > > > > > > > > I support keeping DHAAD in the current spec. If necessary, I can > > > > suggest new clarifying text saying that DHAAD used in conjunction with > > > > MPD and a proper IPsec SA setting leads to effective HA address and Home > > > > Address bootstrapping on MN while at home and while away from home. > > > > > > > > Alex > > > > > > > > > > > > > > Best regards. > > > > > > > > > > JMC. > > > > > > > > > > _______________________________________________ MEXT mailing list > > > > > MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email Security System. > > > > For more information please visit http://www.messagelabs.com/email > > > > ______________________________________________________________________ > > > > > > > > > > > > _______________________________________________ > > > > MEXT mailing list > > > > MEXT@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mext > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From oxluafygm@boxofhammers.com Fri Dec 28 11:22:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HyY-0005d5-Ie; Fri, 28 Dec 2007 11:22:22 -0500 Received: from [88.230.208.179] (helo=dsl88.230-53427.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8HyX-0003zF-C4; Fri, 28 Dec 2007 11:22:22 -0500 Received: from [88.230.208.179] by ASPMX.L.GOOGLE.com; Fri, 28 Dec 2007 18:22:20 +0200 Date: Fri, 28 Dec 2007 18:22:20 +0200 From: "Adrienne Little" X-Mailer: The Bat! (v2.10) Personal Reply-To: oxluafygm@boxofhammers.com X-Priority: 3 (Normal) Message-ID: <848593997.34260171797330@boxofhammers.com> To: ldapbis-archive@lists.ietf.org Subject: Re: Adrienne MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Help yourself and your girl, display them a spectacular you. http://www.xiefions.com no powers at my (and too short) to spend and organized Having reviewed all of patterns with others says the report, From heqawkqcmj@brandreth.com Fri Dec 28 12:02:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Ibd-0003fB-Na; Fri, 28 Dec 2007 12:02:45 -0500 Received: from [190.8.203.32] (helo=PERSONAL) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8Ibc-0004xz-Lf; Fri, 28 Dec 2007 12:02:45 -0500 Received: from [190.8.203.32] by mxmail.register.com; Fri, 28 Dec 2007 12:02:49 -0500 Message-ID: <01c84949$90bffa80$20cb08be@heqawkqcmj> From: "Wayne Beasley" To: Subject: Re: Beasley Date: Fri, 28 Dec 2007 12:02:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2244.8 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2244.8 X-Antivirus: avast! (VPS 071227-0, 27/12/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.9 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Help yourself and your girl, show them a spectacular you. http://www.fiedoredi.com is not obliged to You want to learn about Academy against the firm and about inheritance might on the floor with From GarlandtruckRoman@everything2.com Fri Dec 28 15:55:08 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8MEV-0004hr-Sq; Fri, 28 Dec 2007 15:55:07 -0500 Received: from pd953b799.dip.t-dialin.net ([217.83.183.153] helo=felixphilipp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8MEV-0003GJ-IH; Fri, 28 Dec 2007 15:55:07 -0500 Received: from scorecard by everything2.com with SMTP id a7cXxnkDKZ for ; Fri, 28 Dec 2007 21:54:41 -0100 From: "Otto Clay" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8OiT-000334-6n; Fri, 28 Dec 2007 18:34:13 -0500 Received: from [60.54.3.86] (helo=[60.54.3.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8OiR-0003r3-Sh; Fri, 28 Dec 2007 18:34:12 -0500 Received: from [60.54.3.86] by mailin.radiant.net; Sat, 29 Dec 2007 07:34:11 +0800 From: "Dianna Lozano" To: Subject: Re: contribute to depression Date: Sat, 29 Dec 2007 07:34:11 +0800 Message-ID: <01c849ed$34161b80$5603363c@aoglyvlxq> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Importance: Normal X-Antivirus: avast! (VPS 071227-0, 12/27/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 All Med*s onsale 100% safe and fast shipping http://fellstrong.com From LorastanleyRuffin@perked.ca Fri Dec 28 23:29:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8TKP-0001pU-GB; Fri, 28 Dec 2007 23:29:41 -0500 Received: from c-67-172-55-248.hsd1.pa.comcast.net ([67.172.55.248] helo=lisaauer.hsd1.oh.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8TKO-0000vZ-OF; Fri, 28 Dec 2007 23:29:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host22239752.perked.ca (8.13.1/8.13.1) with SMTP id STgyJnWm21.603219.4lt.5TO.4031921861795 for ; Fri, 28 Dec 2007 23:28:51 +0500 Message-ID: <6f2a701c849d3$6d897070$6501a8c0@LisaAuer> From: "Estelle Fountain" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_6F2A3_01C849D3.6D897070-- From ghwjbotsecg@brandbox.com Sat Dec 29 00:03:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8TrD-0007By-FD; Sat, 29 Dec 2007 00:03:35 -0500 Received: from m00779a.citech-bd.com ([203.83.168.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8TrB-0001eO-9O; Sat, 29 Dec 2007 00:03:35 -0500 Received: from [203.83.168.18] by brandbox.com; Sat, 29 Dec 2007 11:03:32 +0600 From: "Bernie Crowe" To: Subject: Doctor Approved And Recommended Date: Sat, 29 Dec 2007 11:03:32 +0600 Message-ID: <01c84a0a$73069a00$12a853cb@ghwjbotsecg> 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, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Doctor Approved And Recommended http://rotuebu.com From JulietalgenibAlfaro@domaindrivendesign.org Sat Dec 29 03:51:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8XPM-0002GV-4I; Sat, 29 Dec 2007 03:51:04 -0500 Received: from [190.18.216.115] (helo=pc84ebb0a7b276) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8XPL-0005i5-N9; Sat, 29 Dec 2007 03:51:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host51770339.domaindrivendesign.org (8.13.1/8.13.1) with SMTP id GMrplxRL89.371694.mq0.fTg.3290554226560 for ; Sat, 29 Dec 2007 05:50:37 +0300 Message-ID: <3b83001c849f7$ef62abb0$73d812be@pc84ebb0a7b276> From: "Rosanna Mohr" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_3B82C_01C849F7.EF62ABB0-- From emirhan_Fabris@gsmromania.info Sat Dec 29 04:08:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8XgI-0000dd-7V for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 04:08:34 -0500 Received: from [189.24.185.139] (helo=18924045228.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8XgH-0006Dd-KF for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 04:08:34 -0500 Received: from labol4 ([108.160.9.108] helo=labol4) by 18924045228.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1NfcRN-000IBD-gT for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 07:09:02 -0200 Message-ID: <42670C9F.3DEF0342@gsmromania.info> Date: Sat, 29 Dec 2007 07:08:28 -0200 From: "emirhan Fabris" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: spanwijd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 That's a Major Leg you have down there, thanks for telling me the
secret! http://www.jueretu.com/
From MarcelsplutterSalinas@cauce.org Sat Dec 29 09:26:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8ceA-0003i7-3T for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 09:26:42 -0500 Received: from dslb-088-066-140-179.pools.arcor-ip.net ([88.66.140.179] helo=saban) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8ce9-0001zH-I0 for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 09:26:41 -0500 Received: from sima by cauce.org with SMTP id v8Kj1071AV for ; Sat, 29 Dec 2007 15:25:46 -0100 From: "Moises Avila" To: Subject: We know how to treat our players Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We have it all! Players from the United States and around the world! How about the best service around? $2400 welcome bonus will be deposited in your new casino account! http://topbestgambling.net/ From weruhc@bragano.com Sat Dec 29 09:53:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8d44-0007hB-NJ for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 09:53:28 -0500 Received: from [201.234.17.131] (helo=[201.234.17.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8d43-0002bc-IS for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 09:53:28 -0500 Received: from [201.234.17.131] by barrierb241.nike.com; Sat, 29 Dec 2007 11:59:00 -0300 Date: Sat, 29 Dec 2007 11:59:00 -0300 From: "Shelly Mcneill" X-Mailer: The Bat! (v2.12.00) Business Reply-To: weruhc@bragano.com X-Priority: 3 (Normal) Message-ID: <870542240.18815789422872@bragano.com> To: nemo-archive@lists.ietf.org Subject: Balloon Garden MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Help you and your woman, show her a huge you. http://www.teopwerl.com You'll easily counter with your so that you can spend From VickyhornyMcneal@foxsports.com Sat Dec 29 15:49:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8icd-0000YQ-9i for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 15:49:31 -0500 Received: from cpe-76-90-48-126.socal.res.rr.com ([76.90.48.126] helo=angel.mshome.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8icc-0002co-Kx for nemo-archive@lists.ietf.org; Sat, 29 Dec 2007 15:49:30 -0500 Received: from peru by foxsports.com with SMTP id r04a77kQiy for ; Fri, 28 Dec 2007 12:56:34 +0800 From: "Antoinette Smiley" To: Subject: If you're in the US, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We give out BONUSES to anyone who joins. Players from the United States and around the world! Your own privater Vegas! If you're in the US or anywhere else, join your new casino paradise. http://topbestgambling.net/ From IrarancidReeves@kennedy-center.org Sat Dec 29 23:59:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8qHH-0005Li-8j; Sat, 29 Dec 2007 23:59:59 -0500 Received: from pool-72-89-79-179.nycmny.fios.verizon.net ([72.89.79.179] helo=d7ndklb1.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8qHH-0003sL-00; Sat, 29 Dec 2007 23:59:59 -0500 Received: from striate by kennedy-center.org with SMTP id OQU9aNKACQ for ; Sat, 29 Dec 2007 23:59:39 +0500 From: "Grant Mann" To: Subject: Our safe, secure games Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We give out BONUSES to anyone who joins. Best offer in gambling history . Our casino is for you and everyone else who likes to win! USA players too! Download and GO! http://bonusgoldcasino.net/ From TrumaninexpensiveMiddleton@4u-binoculars.com Sun Dec 30 03:02:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8t7n-0000CE-B7; Sun, 30 Dec 2007 03:02:23 -0500 Received: from [59.182.235.198] (helo=ramesh2013c0f6) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8t7m-0006LY-Na; Sun, 30 Dec 2007 03:02:23 -0500 Received: from troll by 4u-binoculars.com with SMTP id tZ6KRKefd4 for ; Sun, 30 Dec 2007 13:31:56 -0530 From: "Sanford Sheppard" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8xZd-0007pl-GH; Sun, 30 Dec 2007 07:47:25 -0500 Received: from [58.174.202.206] (helo=laura.sa.bigpond.net.au) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8xZc-0008DM-TK; Sun, 30 Dec 2007 07:47:25 -0500 Received: from mcintosh by bigsurcalifornia.org with SMTP id Ge3OKHEeSK for ; Sun, 30 Dec 2007 23:16:42 -0930 From: "Jenny Mcclellan" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8yN8-0000TW-8w; Sun, 30 Dec 2007 08:38:34 -0500 Received: from [85.100.73.62] (helo=dsl.dynamic851007362.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8yN7-0000QM-1m; Sun, 30 Dec 2007 08:38:34 -0500 Received: from [85.100.73.62] by g.mx.mail.yahoo.com; , 30 Dec 2007 15:38:32 +0200 From: "Adolfo Stanton" To: Subject: Re: Adolfo Date: , 30 Dec 2007 15:38:32 +0200 Message-ID: <01c84afa$08348c00$3e496455@temisraquel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Improve your sex. women, love more time with you a new you. http://www.ffottrub.com this should be your You want to learn about overscheduled hear if you would Decorator is something from often is sacrificed From john@littleego.com Sun Dec 30 10:10:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8zoA-0001Ka-Ec; Sun, 30 Dec 2007 10:10:34 -0500 Received: from [196.28.255.67] (helo=SERVEUR1) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8zo9-0001i7-C8; Sun, 30 Dec 2007 10:10:34 -0500 Received: from [196.28.255.67] by mx1.biz.mail.yahoo.com; , 30 Dec 2007 16:09:33 +0100 Message-ID: <01c84afe$5db83100$43ff1cc4@john> From: "Simon Blue" To: Subject: Re: Circus Date: , 30 Dec 2007 16:09:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Med_s are all onsale today Save Time and Money, 100% safe http://fellstrong.com From AlysonharrisKeyes@digitalscrapbookplace.com Sun Dec 30 13:41:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9368-0004OY-CA; Sun, 30 Dec 2007 13:41:20 -0500 Received: from p508dc636.dip.t-dialin.net ([80.141.198.54] helo=buqe) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9367-0005P6-W1; Sun, 30 Dec 2007 13:41:20 -0500 Received: from seasonal by digitalscrapbookplace.com with SMTP id DKmtccpRr7 for ; Sun, 30 Dec 2007 19:40:57 -0100 From: "Alyson Flood" To: Subject: If you're in the US or anywhere else, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Win $$$ instead of throwing it all away at other casinos. Our safe, secure games will get you smiling when you start seeing dollars pouring in. When YOU WIN, we win! Get to know your new casino home! http://bonusgoldcasino.net/ From JamieidGarrett@dpsinfo.com Sun Dec 30 15:37:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J94ug-00038m-R8; Sun, 30 Dec 2007 15:37:38 -0500 Received: from 77-98-51-65.cable.ubr03.chwo.blueyonder.co.uk ([77.98.51.65] helo=thompson) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J94ue-0007Vi-7w; Sun, 30 Dec 2007 15:37:38 -0500 Received: from watercourse by dpsinfo.com with SMTP id qz3zS5PbZW for ; Sun, 30 Dec 2007 21:34:22 +0000 From: "Christian Fuller" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J96iU-0002PG-0k; Sun, 30 Dec 2007 17:33:10 -0500 Received: from p57aef3a9.dip.t-dialin.net ([87.174.243.169] helo=kremtz1d0dd837.speedportw700v) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J96iT-0001Gy-9Q; Sun, 30 Dec 2007 17:33:09 -0500 Received: from manchester by icannwatch.org with SMTP id c0izRIGmba for ; Mon, 31 Dec 2007 01:49:59 -0100 From: "Ramiro Owen" To: Subject: Win $$$ instead of throwing it all away at other casinos. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Come find out. Best offer in gambling history . We have it all! We know how to treat our players - how about a $2400 welcome bonmus when you join? http://bonusgoldcasino.net/ From FredricapparelBoyle@latimes.com Sun Dec 30 21:58:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9Ari-0007fG-Km; Sun, 30 Dec 2007 21:58:58 -0500 Received: from pool-151-203-83-213.bos.east.verizon.net ([151.203.83.213] helo=amanda.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9Arh-0008Bi-RY; Sun, 30 Dec 2007 21:58:58 -0500 Received: from binghamton by latimes.com with SMTP id ZOH7LWB2H1 for ; Sun, 30 Dec 2007 21:57:11 +0500 From: "Waldo Puckett" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9Boo-00016C-Bh; Sun, 30 Dec 2007 23:00:02 -0500 Received: from [58.102.205.65] (helo=133e6115b5054f4) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9Bon-0000dh-6G; Sun, 30 Dec 2007 23:00:02 -0500 Received: from [58.102.205.65] by INBOUND.SCNETWORKPARTNERS.COM.NETSOLMAIL.NET; Mon, 31 Dec 2007 12:59:00 +0900 Message-ID: <01c84bac$e9430200$41cd663a@anthony> From: "Maryanne Fischer" To: Subject: Re: Hose Date: Mon, 31 Dec 2007 12:59:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2730.2 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Spam-Score: 2.5 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Med_s are all onsale today Save Time and Money, 100% safe http://ranmiddles.com From Cloann195@delusionaires.com Mon Dec 31 06:21:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9IiJ-0000iV-GO for nemo-archive@lists.ietf.org; Mon, 31 Dec 2007 06:21:47 -0500 Received: from [196.15.56.29] (helo=[196.15.52.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9IiI-00017m-8l for nemo-archive@lists.ietf.org; Mon, 31 Dec 2007 06:21:47 -0500 Received: from KIDS ([146.116.192.170]:24116 "EHLO KIDS" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [196.15.52.100] with ESMTP id S22XSXIAKIMSPHDI (ORCPT ); Mon, 31 Dec 2007 14:20:12 +0300 Message-ID: <246E2BBB.AB9E7C18@delusionaires.com> Date: Mon, 31 Dec 2007 14:19:41 +0300 From: "Cloann gildersleeve" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nemo-archive@lists.ietf.org Subject: atliskum Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I'll do anything to get a 9 inch dick - and I have found the miracle
solution! http://www.mewituel.com/
From MichealbotanicDaniels@blitzkriegsoftware.net Mon Dec 31 07:38:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9Ju5-0007Fo-S5; Mon, 31 Dec 2007 07:38:01 -0500 Received: from [85.105.136.50] (helo=kardiyoloji2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9Ju5-0003Bl-Be; Mon, 31 Dec 2007 07:38:01 -0500 Received: from annie by blitzkriegsoftware.net with SMTP id q2BzO15Dqn for ; Mon, 31 Dec 2007 14:36:35 -0200 From: "Theodore Palmer" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9LTW-0002jf-SN; Mon, 31 Dec 2007 09:18:42 -0500 Received: from d38-245-94.home1.cgocable.net ([72.38.245.94] helo=homecxjkohrxyw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9LTW-0005uU-Hl; Mon, 31 Dec 2007 09:18:42 -0500 Received: from calcutta by tpmmuckraker.com with SMTP id XGrzP6aEmE for ; Mon, 31 Dec 2007 09:18:04 +0500 From: "Rudy Delgado" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9NF7-0001V7-Ov; Mon, 31 Dec 2007 11:11:57 -0500 Received: from 85.137.60.106.dyn.user.ono.com ([85.137.60.106] helo=aplitecs) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9NF7-0000GW-6b; Mon, 31 Dec 2007 11:11:57 -0500 Received: from edinburgh by legacyelectronics.com with SMTP id icUYR9Lpis for ; Mon, 31 Dec 2007 17:10:58 -0100 From: "Wilfredo Beasley" To: Subject: How about the best service around? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Best offer in gambling history . Download our casino in 20 seconds to get $2400 richer when you join. Play your favorite games and get $2400 welcome bonus. Players from the United States and around the world! http://worldacasino.com.cn/ From sdtxecpsh@blueglas.com Mon Dec 31 12:25:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9OOZ-0002qv-Nm; Mon, 31 Dec 2007 12:25:47 -0500 Received: from [190.68.18.193] (helo=[190.68.18.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9OOY-00027X-KC; Mon, 31 Dec 2007 12:25:47 -0500 Received: from [190.68.18.193] by mx1.mail.twtelecom.net; Mon, 31 Dec 2007 12:22:47 -0500 From: "Henrietta Dunbar" To: Subject: Re: Feather Date: Mon, 31 Dec 2007 12:22:47 -0500 Message-ID: <01c84ba7$da0d8580$c11244be@sdtxecpsh> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 2.8 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Have better sex yours and her sex life. women, love time with them at last you. http://www.chuesolk.com Electricity From qhrbqyrmde@brainwhistle.com Mon Dec 31 13:56:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9PoM-0003GD-Jx; Mon, 31 Dec 2007 13:56:30 -0500 Received: from nm-htsh-2958b.adsl.wanadoo.nl ([83.116.51.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9PoL-0003z7-CB; Mon, 31 Dec 2007 13:56:30 -0500 Received: from [83.116.51.139] by ismybrain.com; Mon, 31 Dec 2007 19:56:27 +0100 From: "Alba Otto" To: Subject: Gain 3+ Inches In Length Date: Mon, 31 Dec 2007 19:56:27 +0100 Message-ID: <01c84be7$3a6fe780$8b337453@qhrbqyrmde> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-Spam-Score: 2.3 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Doctor Approved And Recommended http://rotuebu.com From SoniacontraceptionGunter@heraldonline.com Mon Dec 31 17:05:32 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9SlH-0001sy-Jx; Mon, 31 Dec 2007 17:05:31 -0500 Received: from [190.80.226.149] (helo=carlo.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9SlH-0007jJ-4R; Mon, 31 Dec 2007 17:05:31 -0500 Received: from slight by heraldonline.com with SMTP id un2EvbTRmD for ; Mon, 31 Dec 2007 06:04:19 -0100 From: "Ramona Trent" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9Ulx-0002GX-TC; Mon, 31 Dec 2007 19:14:21 -0500 Received: from p4fd245ec.dip.t-dialin.net ([79.210.69.236] helo=olidatamjk3r.speedportw700v) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9Ulx-0001ZT-DG; Mon, 31 Dec 2007 19:14:21 -0500 Received: from livingston by choosetomove.org with SMTP id Wa5pxUBeMW for ; Tue, 1 Jan 2008 01:14:07 -0100 From: "Aida Akins" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9Wug-0003YP-EF; Mon, 31 Dec 2007 21:31:30 -0500 Received: from cpe-071-070-201-105.nc.res.rr.com ([71.70.201.105] helo=jakedasnake398) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9Wug-0003o4-53; Mon, 31 Dec 2007 21:31:30 -0500 Received: from bawd by flickr.com with SMTP id BP8H41Fgjv for ; Mon, 31 Dec 2007 21:31:08 +0500 From: "Julianne Caron" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9YyS-0005rI-Ca; Mon, 31 Dec 2007 23:43:32 -0500 Received: from chello062179038239.chello.pl ([62.179.38.239] helo=computername.chello.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9YyR-0005ku-0u; Mon, 31 Dec 2007 23:43:32 -0500 Received: from [62.179.38.239] by mx1.easycgi.com; Tue, 0 Jan 2008 05:42:29 +0100 From: "Abraham Irving" To: Subject: Alphabet Date: Tue, 0 Jan 2008 05:42:29 +0100 Message-ID: <01c4fd44$14710000$ef26b33e@mjo> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 4.0 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Med^s are all on-sale today Save Time and Money, 100% safe http://atmay.com