Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72B03A6883 for ; Wed, 4 Feb 2009 16:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj5A1Q2FZgbA for ; Wed, 4 Feb 2009 16:56:45 -0800 (PST) Received: from n15c.bullet.mail.mud.yahoo.com (n15c.bullet.mail.mud.yahoo.com [68.142.207.203]) by core3.amsl.com (Postfix) with SMTP id B910D3A6864 for ; Wed, 4 Feb 2009 16:56:45 -0800 (PST) Received: from [68.142.200.221] by n15.bullet.mail.mud.yahoo.com with NNFMP; 05 Feb 2009 00:56:25 -0000 Received: from [68.142.201.250] by t9.bullet.mud.yahoo.com with NNFMP; 05 Feb 2009 00:56:25 -0000 Received: from [127.0.0.1] by omp411.mail.mud.yahoo.com with NNFMP; 05 Feb 2009 00:56:25 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 299453.82832.bm@omp411.mail.mud.yahoo.com Received: (qmail 94839 invoked by uid 60001); 5 Feb 2009 00:56:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=oA3hhEuk+V1qm1KAS4gguiz9sIHyyfQpXdHQRNC3sahRqVOLLtCiY1viuH/vGJclEOVOUmF+MJYMjQtua4fRn84pqI3Vqo4kt1F6hTn4XZDxfDjZyPaNiGMJ7Nsm2eFvuQJMtxnISt/VEYnlsgQA7rh1kji/szukrboIHhNg2YU=; X-YMail-OSG: KAz3BZsVM1m1R9Irx7dGZ6v.VVZz5llnqq3EnciYm1DjOUblLmqob.JqiWztlGDwA6dieYHu4.G_XgqoVsSF2NRLKfHAXeJpsJcujkAP1OHBzzzW87fnZGcSMLJMnkyPGUPtttFwmpDmZ3F3L2DD9pcwh8Yeoa9h8gPTI9g9UrsPubbNcepnK.jn0S0MHfIAMnouDTH8Zg-- Received: from [67.233.188.239] by web45916.mail.sp1.yahoo.com via HTTP; Wed, 04 Feb 2009 16:56:24 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 4 Feb 2009 16:56:24 -0800 (PST) From: John Edward To: mip4@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1919993476-1233795384=:94754" Message-ID: <628498.94754.qm@web45916.mail.sp1.yahoo.com> Subject: [Mip4] Draft paper submission deadline extended: IP Protocols X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 00:56:46 -0000 --0-1919993476-1233795384=:94754 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Draft paper submission deadline extended: IP Protocols =A0 The deadline for draft paper submission at the 2009 International Conferenc= e on High Performance Computing, Networking and Communication Systems (HPCN= CS-09) (website: http://www.PromoteResearch.org ) is extended due to numero= us requests from the authors. As a result, the deadline for paper submissio= n for the special session on IP Protocols is also extended accordingly. The= conference and the session will be held during July 13-16 2009 in Orlando,= FL, USA. We invite draft paper submissions. The conference will take place= at the same time and venue where several other international conferences a= re taking place. The other conferences include: =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Artificial Intellig= ence and Pattern Recognition (AIPR-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Automation, Robotic= s and Control Systems (ARCS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Bioinformatics, Com= putational Biology, Genomics and Chemoinformatics (BCBGC-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Enterprise Informat= ion Systems and Web Technologies (EISWT-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Information Securit= y and Privacy (ISP-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Recent Advances in = Information Technology and Applications (RAITA-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Software Engineerin= g Theory and Practice (SETP-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theory and Applicat= ions of Computational Science (TACS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theoretical and Mat= hematical Foundations of Computer Science (TMFCS-09) =A0 The website http://www.PromoteResearch.org contains more details. =A0 Sincerely John Edward Publicity committee =A0 =A0 =A0 =A0=0A=0A=0A --0-1919993476-1233795384=:94754 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Draft paper submission deadline extended: IP Protocols

 

The deadline for draft paper submission at the 2009 International Conference on High Performance Computing, Networki= ng and Communication Systems (HPCNCS-09) (website: http://www.PromoteResearch.or= g ) is extended due to numerous requests= from the authors. As a result, the deadline for paper submission for the s= pecial session on IP Protocols is also exten= ded accordingly. The conference and the session will be held during July 13= -16 2009 in Orlando, FL, USA. We invite draft paper submissions. The confer= ence will take place at the same time and venue where several other interna= tional conferences are taking place. The other conferences include:

=B7         <= /FONT>

=B7         =B7         =B7         =B7         =B7         =B7         =B7         =B7          

The website http://www.PromoteResearch.org<= SPAN style=3D"mso-bookmark: OLE_LINK4"> contains more details.

 

Sincerely

John Edward

Publicity committee

 

 

 

 


=0A=0A= =0A=0A --0-1919993476-1233795384=:94754-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E3928C20B for ; Wed, 11 Feb 2009 09:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+NsyYl8I4u2 for ; Wed, 11 Feb 2009 09:04:44 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 445D828C209 for ; Wed, 11 Feb 2009 09:04:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1234371887!11142111!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 32204 invoked from network); 11 Feb 2009 17:04:47 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-11.tower-153.messagelabs.com with SMTP; 11 Feb 2009 17:04:47 -0000 Received: from il27exr01.cig.mot.com (il27exr01.mot.com [10.17.196.70]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id n1BH4l33005771 for ; Wed, 11 Feb 2009 10:04:48 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id n1BH4ln5013720 for ; Wed, 11 Feb 2009 11:04:47 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id n1BH4kCt013699 for ; Wed, 11 Feb 2009 11:04:46 -0600 (CST) 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: Wed, 11 Feb 2009 12:04:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status update & Recharter effort thread-index: AcmMatV58WVCw9LuTgSW3borcHfjJQ== From: "McCann Peter-A001034" To: X-CFilter-Loop: Reflected Cc: Henrik Levkowetz Subject: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:04:45 -0000 Hi, all, Traffic on the list has been light lately so I wanted to provide a status update on our existing work items and kick-start a discussion on where to take the working group next. Here is a list of our current work items and status: draft-ietf-mip4-generic-notification-message-07.txt New version was uploaded on 11/3, in response to comments from WGLC. On cursory examination, it appears to me that most if not all comments have been addressed. It would be nice to get confirmation of this from those who had comments back in July/August. Then we can submit for publication. draft-ietf-mip4-nemov4-dynamic-02.txt We will issue a last call on this soon, but it has lower priority than 2006bis. draft-ietf-mip4-nemov4-fa-03.txt No interest in continuing. We will drop this item from our charter. draft-ietf-mip4-rfc3344bis-07.txt Still working on the shepherd writeup. Will be submitted for publication soon. draft-ietf-mip4-udptunnel-mib-01.txt On hold waiting on 2006bis; then we will issue WGLC. draft-ietf-mip4-rfc2006bis-05.txt Ready for last call. Will issue soon. draft-ietf-mip4-dsmipv4-10.txt In RFC Editor's queue. draft-ietf-mip4-gen-ext-04.txt Ongoing discussion on whether to continue this item (see recharter discussion below). Several new work items have come to our attention over the past few meeting cycles. Here is a partial list of potential work items for mip4 going forward. Please comment on which you would like to see and which you think should be excluded. draft-deng-mip4-host-configuration-00.txt draft-chakrabarti-mip4-mcbc-03.txt These two items are related, because DHCP uses IP-layer broadcast to deliver DHCPREQUEST messages. I'd like to propose that we drop the gen-ext draft and add these two. Comments? =20 draft-gundavelli-mip4-multiple-tunnel-support-00.txt We've had some good discussion already on the mailing list and this seems like a potentially useful extension. Comments? draft-doswald-robert-mip4-btn-fmipv4-00.txt This was presented at IETF-72. Is there interest in working on it? Other comments? draft-makela-mip4-nemo-haaro-03.txt This was presented at IETF-70 and it looks like there have been a couple of revisions since. Is there interest in working on it? Other comments? draft-acee-mip4-bulk-revocation-01.txt This was presented at IETF-70. Is there interest in working on it? Other comments? draft-yegani-gre-key-extension-03.txt This was presented at IETF-70. Is there interest in working on it? Other comments? If I left anything out please speak up. -Pete Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A15C3A6ABE for ; Wed, 11 Feb 2009 14:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S0u0Y8BeVOx for ; Wed, 11 Feb 2009 14:41:56 -0800 (PST) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by core3.amsl.com (Postfix) with ESMTP id 52C1D3A6A1A for ; Wed, 11 Feb 2009 14:41:55 -0800 (PST) X-Originating-Ip: [192.194.74.130] Received: from lohi.mit.sonera.com (lohi.mit.sonera.com [192.194.74.130]) by smtp.tele.fi (Postfix) with ESMTP id D7FB714940; Thu, 12 Feb 2009 00:41:52 +0200 (EET) Received: from lohi.mit.sonera.com (localhost [127.0.0.1]) by lohi.mit.sonera.com (Postfix) with ESMTP id D3BD08DE29; Thu, 12 Feb 2009 00:26:02 +0200 (EET) Received: from suutari.mit.sonera.com (suutari.mit.sonera.com [194.142.21.7]) by lohi.mit.sonera.com (Postfix) with ESMTP id BD6058DC30; Thu, 12 Feb 2009 00:26:02 +0200 (EET) Received: from suutari.mit.sonera.com (suutari.mit.sonera.com [194.142.21.7]) by suutari.mit.sonera.com (Postfix) with ESMTP id 46CB3C2E28; Thu, 12 Feb 2009 00:41:47 +0200 (EET) Date: Thu, 12 Feb 2009 00:41:47 +0200 (EET) From: =?ISO-8859-1?Q?Antti_M=E4kel=E4?= X-X-Sender: makelan2@suutari.mit.sonera.com To: McCann Peter-A001034 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1899886827-845646971-1234392107=:2285" X-Virus-Scanned: ClamAV using ClamSMTP Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:41:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1899886827-845646971-1234392107=:2285 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Feb 2009, McCann Peter-A001034 wrote: > draft-makela-mip4-nemo-haaro-03.txt > This was presented at IETF-70 and it looks like there have been a > couple of revisions since. Is there interest in working on it? Other > comments? As the primary author :) I'll comment that I have been preparing for and will most likely (barring force majeure issues) start working towards my doctoral dissertation in the summer as soon as certain arrangements have been made. My topic will be covering the virtual operator model outlined in the first section of the draft. The work will be conducted as part of Finnish Future Internet project (http://futureinternet.fi/). Anyway, at least *I* will continue to have interest in developing this further - so I'm not just going to toss it to the WG and leave it at -00..as part of the work, there will be actual implementation coming up. Whether the draft is of interest to the IETF is of course another matter, but I do remember hearing some encouraging comments from the audience in Vancouver that this thing might actually have a business case :) -- - Antti Mäkelä | Senior Network Architect | +358 2040 21613 - - TeliaSonera Corporation - ---1899886827-845646971-1234392107=:2285-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A483A69E4 for ; Wed, 11 Feb 2009 19:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV34Vh1+Z-0G for ; Wed, 11 Feb 2009 19:28:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DAB883A677E for ; Wed, 11 Feb 2009 19:28:48 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEX00HXYOBQV6@szxga01-in.huawei.com> for mip4@ietf.org; Thu, 12 Feb 2009 11:28:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KEX008QEOBQXE@szxga01-in.huawei.com> for mip4@ietf.org; Thu, 12 Feb 2009 11:28:38 +0800 (CST) Received: from w53375a ([10.164.12.27]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KEX00IX9OBPAD@szxml04-in.huawei.com> for mip4@ietf.org; Thu, 12 Feb 2009 11:28:37 +0800 (CST) Date: Thu, 12 Feb 2009 11:28:36 +0800 From: Qin Wu To: McCann Peter-A001034 , mip4@ietf.org Message-id: <018e01c98cc1$fdeb8fe0$1b0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:28:49 -0000 > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? > Other comments? I wonder what's the status of this draft on GRE key support for mobile IPv4? Since similar work on this issue has already been specified in netlmm working group. I would like to see the work to be continued. -Qin > > > > If I left anything out please speak up. > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2AD3A68DD for ; Wed, 11 Feb 2009 23:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTBvBFnGgOZg for ; Wed, 11 Feb 2009 23:02:38 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id D50AB3A6979 for ; Wed, 11 Feb 2009 23:02:37 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so749598ywh.49 for ; Wed, 11 Feb 2009 23:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WzrgAMnXyd4QMKjlgOLuNMMiKaMlmZkVNV+mQtOKiFU=; b=p+bNlURUQzSeeKcCwdHdv9SDT1nBjIonriq+rldGyXB9gWBnjJu0P+XaWRCuDz9jXp WlgU+fOTNreymgPxJCGpicIoeF9K0mcKU4xZPknGjo0mWHpe/gvgQ2YdUlnOCMc+Qgwa 8y3uQFgEu14SN3KfD1hkcLhp30GCiVMW7apTA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=exrZHSVi0NSb5sMzMbku2H6cgI8w3Gh5z5Pp7500Ne29fgD/9Mep4/E+RMQjaXNuNw Mu+co4FDKI7p2q8kv3UJJZQ0+E0fGC7d7Hi3hUDWIjsnIwTy+ZeQJQywW7YMdDN+zxhs THVGtrjdONr2QfpBA/iHAfWf+2JyJ1R3t1Po0= MIME-Version: 1.0 Received: by 10.100.138.10 with SMTP id l10mr761299and.25.1234422161595; Wed, 11 Feb 2009 23:02:41 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 15:02:41 +0800 Message-ID: <4c5c7a6d0902112302w7a1167d9kd5b6998090910fe2@mail.gmail.com> From: Peny Yang To: McCann Peter-A001034 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:02:39 -0000 Hi, Peter: > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? [Peny] I agree. And, I am updating the draft-deng-mip4-host-configuration to include the IP layer broadcast forwarding without DHCP relay on HA. It will be published soon. BRG Peny On Thu, Feb 12, 2009 at 1:04 AM, McCann Peter-A001034 wrote: > Hi, all, > > Traffic on the list has been light lately so I wanted to > provide a status update on our existing work items and kick-start > a discussion on where to take the working group next. > > Here is a list of our current work items and status: > > > draft-ietf-mip4-generic-notification-message-07.txt > New version was uploaded on 11/3, in response to comments > from WGLC. On cursory examination, it appears to me that > most if not all comments have been addressed. It would be > nice to get confirmation of this from those who had comments > back in July/August. Then we can submit for publication. > > draft-ietf-mip4-nemov4-dynamic-02.txt > We will issue a last call on this soon, but it has lower > priority than 2006bis. > > draft-ietf-mip4-nemov4-fa-03.txt > No interest in continuing. We will drop this item from our charter. > > draft-ietf-mip4-rfc3344bis-07.txt > Still working on the shepherd writeup. Will be submitted for > publication soon. > > draft-ietf-mip4-udptunnel-mib-01.txt > On hold waiting on 2006bis; then we will issue WGLC. > > draft-ietf-mip4-rfc2006bis-05.txt > Ready for last call. Will issue soon. > > draft-ietf-mip4-dsmipv4-10.txt > In RFC Editor's queue. > > draft-ietf-mip4-gen-ext-04.txt > Ongoing discussion on whether to continue this item (see recharter > discussion below). > > > Several new work items have come to our attention over the past > few meeting cycles. Here is a partial list of potential work items > for mip4 going forward. Please comment on which you would like to > see and which you think should be excluded. > > > > draft-gundavelli-mip4-multiple-tunnel-support-00.txt > We've had some good discussion already on the mailing list and this > seems like a potentially useful extension. Comments? > > draft-doswald-robert-mip4-btn-fmipv4-00.txt > This was presented at IETF-72. Is there interest in working on it? > Other comments? > > draft-makela-mip4-nemo-haaro-03.txt > This was presented at IETF-70 and it looks like there have been a > couple > of revisions since. Is there interest in working on it? Other > comments? > > draft-acee-mip4-bulk-revocation-01.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? > > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? > > > > If I left anything out please speak up. > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7753A3A699A for ; Wed, 11 Feb 2009 23:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F+Q+DjE+nBF for ; Wed, 11 Feb 2009 23:04:23 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 00A793A68DD for ; Wed, 11 Feb 2009 23:04:22 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so750182ywh.49 for ; Wed, 11 Feb 2009 23:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GkRrLw0aZHixPAgQpI2AVGV36FzQrChwqYREHrablug=; b=wpDlrr8jgzLQcR4xiwAtJVSn+L74jlC56S/yv+4yI5czBeXzrMNkCNrV0srHB0Z4Gt iUfETc80YDxWnAHxpcOQ/tHu1/O/tsfdSj9Scy6vlmFpTBBOCB+We6tQMHbKr4o9sBy6 6AW5ceGXekwxSWd/JoTLrQJpB6OpW5+qnsxKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dS7SWTiq0OQdxOqKuxava5udh2+Mn3hxsUnKOCCmssP6Ws5zNw0UMrQy3QPqfxLBFd ZQ68HpFH+iZmHo/tGUAGp9qhpvvTY6kxfo/oMHHV1QhjFUNboRhCmgS+Or7fY4L20CTN vulRmptJGUoadg2A1upl5E9FCCN81WMlni5eg= MIME-Version: 1.0 Received: by 10.142.238.4 with SMTP id l4mr304284wfh.242.1234422266382; Wed, 11 Feb 2009 23:04:26 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 15:04:26 +0800 Message-ID: <1d38a3350902112304r5682ac52lee9aea6651a5fb7f@mail.gmail.com> From: Hui Deng To: McCann Peter-A001034 Content-Type: multipart/alternative; boundary=000e0cd2449ab0cb450462b3546f Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:04:24 -0000 --000e0cd2449ab0cb450462b3546f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Peter, 2009/2/12 McCann Peter-A001034 > Hi, all, > > Traffic on the list has been light lately so I wanted to > provide a status update on our existing work items and kick-start > a discussion on where to take the working group next. > > Here is a list of our current work items and status: > > draft-ietf-mip4-generic-notification-message-07.txt > New version was uploaded on 11/3, in response to comments > from WGLC. On cursory examination, it appears to me that > most if not all comments have been addressed. It would be > nice to get confirmation of this from those who had comments > back in July/August. Then we can submit for publication. I have talked with Ahmad Muhanna, the reply of his email as the below Sri and Kent's comments also have been replied as well thanks for your consideration. -Hui ----------------------------------------------------------------------------------------------------------- Hi Hui, Sorry for the late response, I had Monday off! When the draft was published I went over it. Based on that quick review, I can say: 1. I have not noticed anything major that needs attention. 2. As an overall comment, I believe that the current draft is written in a much better way than before. 3. The document is some what long, but I guess there is no issue there. Regards, Ahmad ----------------------------------------------------------------------------------------------------------- > > > draft-ietf-mip4-nemov4-dynamic-02.txt > We will issue a last call on this soon, but it has lower > priority than 2006bis. > > draft-ietf-mip4-nemov4-fa-03.txt > No interest in continuing. We will drop this item from our charter. > > draft-ietf-mip4-rfc3344bis-07.txt > Still working on the shepherd writeup. Will be submitted for > publication soon. > > draft-ietf-mip4-udptunnel-mib-01.txt > On hold waiting on 2006bis; then we will issue WGLC. > > draft-ietf-mip4-rfc2006bis-05.txt > Ready for last call. Will issue soon. > > draft-ietf-mip4-dsmipv4-10.txt > In RFC Editor's queue. > > draft-ietf-mip4-gen-ext-04.txt > Ongoing discussion on whether to continue this item (see recharter > discussion below). > > > Several new work items have come to our attention over the past > few meeting cycles. Here is a partial list of potential work items > for mip4 going forward. Please comment on which you would like to > see and which you think should be excluded. > > > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? > > draft-gundavelli-mip4-multiple-tunnel-support-00.txt > We've had some good discussion already on the mailing list and this > seems like a potentially useful extension. Comments? > > draft-doswald-robert-mip4-btn-fmipv4-00.txt > This was presented at IETF-72. Is there interest in working on it? > Other comments? > > draft-makela-mip4-nemo-haaro-03.txt > This was presented at IETF-70 and it looks like there have been a > couple > of revisions since. Is there interest in working on it? Other > comments? > > draft-acee-mip4-bulk-revocation-01.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? > > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? > > > > If I left anything out please speak up. > > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > --000e0cd2449ab0cb450462b3546f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Peter,

2009/2/12 McCann Peter-A001034 <pete.mccann@motorola.com>
Hi, all,

Traffic on the l= ist has been light lately so I wanted to
provide a status update on our = existing work items and kick-start
a discussion on where to take the working group next.

Here is a list= of our current work items and status:

draft-ietf-mip4-generic-notif= ication-message-07.txt
 New version was uploaded on 11/3, in respon= se to comments
 from WGLC.  On cursory examination, it appears to me that
&nb= sp;most if not all comments have been addressed.  It would be
 = ;nice to get confirmation of this from those who had comments
 back= in July/August.  Then we can submit for publication.
I have talked with Ahmad Muhanna, the reply of his email as the below<= /div>
Sri and Kent's comments also have been replied as well
 
thanks for your consideration.
 
-Hui
 
----------------------------------------------------------------------= -------------------------------------
Hi Hui,
 
Sorry for the late response, I had Monday off! 
When the draft was published I went over it. Based on that quick= review, I can say:
 
1. I have not noticed anything major that = needs attention.
2. As an overall comment, I believe that the current draft is written in a = much better way than before.
3. The document is some what long, but I gu= ess there is no issue there.
 
Regards,
Ahmad
----------= ---------------------------------------------------------------------------= ---------------------- 
 


dra= ft-ietf-mip4-nemov4-dynamic-02.txt
 We will issue a last call on th= is soon, but it has lower
 priority than 2006bis.

draft-ietf-mip4-nemov4-fa-03.txt
&nb= sp;No interest in continuing.  We will drop this item from our charter= .

draft-ietf-mip4-rfc3344bis-07.txt
 Still working on the sh= epherd writeup.  Will be submitted for
 publication soon.

draft-ietf-mip4-udptunnel-mib-01.txt
&nbs= p;On hold waiting on 2006bis; then we will issue WGLC.

draft-ietf-mi= p4-rfc2006bis-05.txt
 Ready for last call.  Will issue soon.
draft-ietf-mip4-dsmipv4-10.txt
 In RFC Editor's queue.

draft-ietf-mip4-gen-ext-04.txt
&= nbsp;Ongoing discussion on whether to continue this item (see recharter
=  discussion below).


Several new work items have come to our= attention over the past
few meeting cycles.  Here is a partial list of potential work itemsfor mip4 going forward.  Please comment on which you would like tosee and which you think should be excluded.


draft-deng-mip4-hos= t-configuration-00.txt
draft-chakrabarti-mip4-mcbc-03.txt
 These two items are related, be= cause DHCP uses IP-layer broadcast
 to deliver DHCPREQUEST messages= .  I'd like to propose that we drop
 the gen-ext draft and= add these two.  Comments?

draft-gundavelli-mip4-multiple-tunnel-support-00.txt
 We've= had some good discussion already on the mailing list and this
 see= ms like a potentially useful extension.  Comments?

draft-doswal= d-robert-mip4-btn-fmipv4-00.txt
 This was presented at IETF-72.  Is there interest in working on = it?
 Other comments?

draft-makela-mip4-nemo-haaro-03.txt
=  This was presented at IETF-70 and it looks like there have been a
= couple
 of revisions since.  Is there interest in working on i= t?  Other
comments?

draft-acee-mip4-bulk-revocation-01.txt
 This was p= resented at IETF-70.  Is there interest in working on it?
Other
=  comments?

draft-yegani-gre-key-extension-03.txt
 This = was presented at IETF-70.  Is there interest in working on it?
Other
 comments?



If I left anything out please speak= up.

-Pete
--
Mip4 mailing list: Mip4@ietf.org
   Web interface= : = https://www.ietf.org/mailman/listinfo/mip4
    Charter page: http://www.ietf.org/html.charters/mip4-c= harter.html
Supplemental site: http://www.mip4.org/

--000e0cd2449ab0cb450462b3546f-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6883A6A24 for ; Wed, 11 Feb 2009 23:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO1T+2IYSCDj for ; Wed, 11 Feb 2009 23:08:25 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by core3.amsl.com (Postfix) with ESMTP id 7A2743A699A for ; Wed, 11 Feb 2009 23:08:25 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j66so651183rne.18 for ; Wed, 11 Feb 2009 23:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VmJDM/q6qcB0xa/eqZ1nv/vjnqQgY4dIoFb1HUjsyNI=; b=L2PcNNaQeUkn2SDzGJbKAHzQ7a/sB2RFZ/EmzwXC0BtXb8doqEq64rRr/8ljCNDtwB /+u6GB0o1A+Ru/DnkkVwrOpMh/xqDE6jJgFVRLzixFBgszVaKbbR2q5D5nqckqUgk9TT VGUj7QxpxZQGGknywvtJNeYOGxUaQS5BT1AhI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N63R0osprAa64EG4SlguZmpIVG+Dcy0eAY/utvttO2Ufzgag4SfSNnCQXCrnEiy8SY ViF/kRhL0z1qOg0l6/rlvQtd4AusKZ74xx0n7Trdy88agJXV0lc0SjIcVIbb5YXlfSyT zI3yQEDgC5g/KszsdHEnNg2U68ki0g1pD2sWU= MIME-Version: 1.0 Received: by 10.143.2.20 with SMTP id e20mr305495wfi.269.1234422508304; Wed, 11 Feb 2009 23:08:28 -0800 (PST) In-Reply-To: <4c5c7a6d0902112302w7a1167d9kd5b6998090910fe2@mail.gmail.com> References: <4c5c7a6d0902112302w7a1167d9kd5b6998090910fe2@mail.gmail.com> Date: Thu, 12 Feb 2009 15:08:28 +0800 Message-ID: <1d38a3350902112308m1da87176r65c8b0b9d3b34ecc@mail.gmail.com> From: Hui Deng To: Peny Yang Content-Type: multipart/alternative; boundary=001636e90f8c1c3a900462b36317 Cc: mip4@ietf.org, McCann Peter-A001034 , Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:08:26 -0000 --001636e90f8c1c3a900462b36317 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Peter As Peny said here, he is updating to include Henrik's idea to support broadcast home forwarding, it will be finished before the submission. We support your decision. thanks -Hui 2009/2/12 Peny Yang > Hi, Peter: > > > draft-deng-mip4-host-configuration-00.txt > > draft-chakrabarti-mip4-mcbc-03.txt > > These two items are related, because DHCP uses IP-layer broadcast > > to deliver DHCPREQUEST messages. I'd like to propose that we drop > > the gen-ext draft and add these two. Comments? > [Peny] I agree. And, I am updating the > draft-deng-mip4-host-configuration to include the IP layer broadcast > forwarding without DHCP relay on HA. It will be published soon. > > BRG > Peny > > > > On Thu, Feb 12, 2009 at 1:04 AM, McCann Peter-A001034 > wrote: > > Hi, all, > > > > Traffic on the list has been light lately so I wanted to > > provide a status update on our existing work items and kick-start > > a discussion on where to take the working group next. > > > > Here is a list of our current work items and status: > > > > > > draft-ietf-mip4-generic-notification-message-07.txt > > New version was uploaded on 11/3, in response to comments > > from WGLC. On cursory examination, it appears to me that > > most if not all comments have been addressed. It would be > > nice to get confirmation of this from those who had comments > > back in July/August. Then we can submit for publication. > > > > draft-ietf-mip4-nemov4-dynamic-02.txt > > We will issue a last call on this soon, but it has lower > > priority than 2006bis. > > > > draft-ietf-mip4-nemov4-fa-03.txt > > No interest in continuing. We will drop this item from our charter. > > > > draft-ietf-mip4-rfc3344bis-07.txt > > Still working on the shepherd writeup. Will be submitted for > > publication soon. > > > > draft-ietf-mip4-udptunnel-mib-01.txt > > On hold waiting on 2006bis; then we will issue WGLC. > > > > draft-ietf-mip4-rfc2006bis-05.txt > > Ready for last call. Will issue soon. > > > > draft-ietf-mip4-dsmipv4-10.txt > > In RFC Editor's queue. > > > > draft-ietf-mip4-gen-ext-04.txt > > Ongoing discussion on whether to continue this item (see recharter > > discussion below). > > > > > > Several new work items have come to our attention over the past > > few meeting cycles. Here is a partial list of potential work items > > for mip4 going forward. Please comment on which you would like to > > see and which you think should be excluded. > > > > > > > > draft-gundavelli-mip4-multiple-tunnel-support-00.txt > > We've had some good discussion already on the mailing list and this > > seems like a potentially useful extension. Comments? > > > > draft-doswald-robert-mip4-btn-fmipv4-00.txt > > This was presented at IETF-72. Is there interest in working on it? > > Other comments? > > > > draft-makela-mip4-nemo-haaro-03.txt > > This was presented at IETF-70 and it looks like there have been a > > couple > > of revisions since. Is there interest in working on it? Other > > comments? > > > > draft-acee-mip4-bulk-revocation-01.txt > > This was presented at IETF-70. Is there interest in working on it? > > Other > > comments? > > > > draft-yegani-gre-key-extension-03.txt > > This was presented at IETF-70. Is there interest in working on it? > > Other > > comments? > > > > > > > > If I left anything out please speak up. > > > > -Pete > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > --001636e90f8c1c3a900462b36317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Peter
 
As Peny said here, he is updating to include Henrik's idea to supp= ort broadcast
home forwarding, it will be finished before the submission.
 
We support your decision.
 
thanks
 
-Hui

2009/2/12 Peny Yang <peng.yang.chn@gmail.com>=
Hi, Peter:

> draft-deng-mip4-host-configuration-00.txt> draft-chakrabarti-mip4-mcbc-03.txt
>  These two items are = related, because DHCP uses IP-layer broadcast
>  to deliver DHCP= REQUEST messages.  I'd like to propose that we drop
>  the gen-ext draft and add these two.  Comments?
[P= eny] I agree. And, I am updating the
draft-deng-mip4-host-configuration = to include the IP layer broadcast
forwarding without DHCP relay on HA. I= t will be published soon.

BRG
Peny



On Thu, Feb 12, 2009 at 1:04 AM, McCann P= eter-A001034
<pete.mccann= @motorola.com> wrote:
> Hi, all,
>
> Traffic on th= e list has been light lately so I wanted to
> provide a status update on our existing work items and kick-start
&= gt; a discussion on where to take the working group next.
>
> H= ere is a list of our current work items and status:
>
>
> draft-ietf-mip4-generic-notification-message-07.txt
>  New = version was uploaded on 11/3, in response to comments
>  from WG= LC.  On cursory examination, it appears to me that
>  most = if not all comments have been addressed.  It would be
>  nice to get confirmation of this from those who had comments
= >  back in July/August.  Then we can submit for publication.>
> draft-ietf-mip4-nemov4-dynamic-02.txt
>  We will = issue a last call on this soon, but it has lower
>  priority than 2006bis.
>
> draft-ietf-mip4-nemov4-fa= -03.txt
>  No interest in continuing.  We will drop this it= em from our charter.
>
> draft-ietf-mip4-rfc3344bis-07.txt
&= gt;  Still working on the shepherd writeup.  Will be submitted fo= r
>  publication soon.
>
> draft-ietf-mip4-udptunnel-mib-= 01.txt
>  On hold waiting on 2006bis; then we will issue WGLC.>
> draft-ietf-mip4-rfc2006bis-05.txt
>  Ready for la= st call.  Will issue soon.
>
> draft-ietf-mip4-dsmipv4-10.txt
>  In RFC Editor'= ;s queue.
>
> draft-ietf-mip4-gen-ext-04.txt
>  Ongo= ing discussion on whether to continue this item (see recharter
> &nbs= p;discussion below).
>
>
> Several new work items have come to our attention over= the past
> few meeting cycles.  Here is a partial list of poten= tial work items
> for mip4 going forward.  Please comment on whi= ch you would like to
> see and which you think should be excluded.
>
>
>
> draft-gundavelli-mip4-multiple-tunnel-support-00= .txt
>  We've had some good discussion already on the mailin= g list and this
>  seems like a potentially useful extension. &n= bsp;Comments?
>
> draft-doswald-robert-mip4-btn-fmipv4-00.txt
>  This= was presented at IETF-72.  Is there interest in working on it?
>= ;  Other comments?
>
> draft-makela-mip4-nemo-haaro-03.txt=
>  This was presented at IETF-70 and it looks like there have b= een a
> couple
>  of revisions since.  Is there interest in wo= rking on it?  Other
> comments?
>
> draft-acee-mip4-= bulk-revocation-01.txt
>  This was presented at IETF-70.  I= s there interest in working on it?
> Other
>  comments?
>
> draft-yegani-gre-key-ext= ension-03.txt
>  This was presented at IETF-70.  Is there i= nterest in working on it?
> Other
>  comments?
>
= >
>
> If I left anything out please speak up.
>
> -Pete
> = --
> Mip4 mailing list: Mip4@ietf.or= g
>    Web interface: https://www.ietf.org/mailman/listin= fo/mip4
>     Charter page: http://www.ietf.org/html.charters/m= ip4-charter.html
> Supplemental site: http://www.mip4.org/
>
--
Mip4 mailing list: Mip4@ietf= .org
   Web interface: https://www.ietf.org/mailman/listinfo= /mip4
    Charter page: http://www.ietf.org/html.charters/mip4-c= harter.html
Supplemental site: http://www.mip4.org/

--001636e90f8c1c3a900462b36317-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F373A67AD for ; Wed, 11 Feb 2009 23:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-x3nUzCpuCm for ; Wed, 11 Feb 2009 23:37:06 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F34BF3A67FD for ; Wed, 11 Feb 2009 23:37:05 -0800 (PST) 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 n1C7b6201145; Thu, 12 Feb 2009 07:37:06 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, 12 Feb 2009 01:36:47 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort Thread-Index: AcmMatV58WVCw9LuTgSW3borcHfjJQAEAmsA References: From: "Ahmad Muhanna" To: "McCann Peter-A001034" , Cc: Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:37:07 -0000 Hello, Pete, As I recall, there was also one more item related to make-before-break proposed for the rechartering discussion. Is that still part of the list? Please see more comments inline.=20 Regards, Ahmad =20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of McCann Peter-A001034 > Sent: Wednesday, February 11, 2009 11:05 AM > To: mip4@ietf.org > Cc: Henrik Levkowetz > Subject: [Mip4] Status update & Recharter effort >=20 > Hi, all, >=20 > Traffic on the list has been light lately so I wanted to=20 > provide a status update on our existing work items and=20 > kick-start a discussion on where to take the working group next. >=20 > Here is a list of our current work items and status: >=20 >=20 > draft-ietf-mip4-generic-notification-message-07.txt > New version was uploaded on 11/3, in response to comments > from WGLC. On cursory examination, it appears to me that > most if not all comments have been addressed. It would be > nice to get confirmation of this from those who had comments > back in July/August. Then we can submit for publication. [Ahmad] I agree.=20 Upon a second review, I have few straight forward comments which I will share with the authors and the wg shortly. >=20 >=20 >=20 > Several new work items have come to our attention over the=20 > past few meeting cycles. Here is a partial list of potential=20 > work items for mip4 going forward. Please comment on which=20 > you would like to see and which you think should be excluded. >=20 >=20 > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments?=20 [Ahmad] I support taking this item as a work item for the wg recharter.=20 I also support merging these two drafts as when addressing MCBC fundamentally, it will naturally include DHCP. =20 >=20 > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? [Ahmad] I support including this as a work item for the wg recharter. > Other > comments? >=20 >=20 >=20 > If I left anything out please speak up. >=20 > -Pete > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7FA28C0E7 for ; Thu, 12 Feb 2009 00:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyFz19P7NtlR for ; Thu, 12 Feb 2009 00:40:39 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E781328C0FE for ; Thu, 12 Feb 2009 00:40:38 -0800 (PST) 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 n1C8eeu12755; Thu, 12 Feb 2009 08:40:40 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, 12 Feb 2009 02:39:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on: Generic Notification Message for Mobile IPv4 Thread-Index: AcmM7U17+E1/EB9bSXycx512ejZC6g== From: "Ahmad Muhanna" To: "Hui Deng" Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Comments on: Generic Notification Message for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:40:41 -0000 Hi Hui, I reviewed the new revision and I have few comments on the latest version of the MIP GNM draft. Please see below: Regards, Ahmad ++++++++++++++++ 4.1. Generic Notification Message A generic notification message is sent by a mobility agent to inform another mobility agent, or a MN, of MIP-related information such as vendor specific extensions [RFC3115] and generic string notification [RFC4917]. These messages must use the same IP and UDP headers as any previous Registration Request or Reply message to the same entity. This would support NAT traversal and ensure same security association used for GNM/GNAM and RRQ/RRP. The generic notification message is defined as follows: IP Fields: Source Address Same as the last Registration Reply/Request message received. Destination Address Same as the last Registration Reply/Request message. UDP Fields: Source Port Same as the last Registration Reply/Request message. Destination Port Same as the last Registration Reply/Request message. [Ahmad-1] Are these information saved in the mobile node BCE? I did not check RFC3344 lately but just in case, if these IP addresses are not currently save in the MN binding, then it needs to be added. [Ahmad-end-1] .... ...... The fixed portion of the Generic Notification Message is followed by one or more extensions which may be used with this message, and by one or more authentication extensions (as defined in Section 3.5 of [RFC3344]. This document mandate the MN-HA AE when this message is sent between the MN and the HA, others are optional. This document also mandate the MN-FA AE when this message is sent between the MN and the FA, others are optional. This document mandate the FA-HA AE when this message is sent between the FA and the HA, others are optional. This could be judged based on "MD" value.). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for information on the relative order in which different extensions, when present, must be placed in a Generic Notification Message. [Ahmad-2] May be the text here is not very accurate. because it gives the impression that RFC3344 talks about the order of extension in the GNM which is NOT. What about replacing the last sentence as follows (Just a suggestion): " See Sections 3.6.1.3 and 3.7.2.2 in [RFC3344] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM. " [Ahmad-End-2] 4.2. Generic Notification Acknowledgment Message ... ... Identification A 64-bit number, constructed by the sender, used for matching Generic Notification with Generic Notification Acknowledgement, and for protecting against replay attacks of notification messages. Here is the same as Sections 5.4 and 5.7 of [RFC3344]. Timestamps is mandatory. [Ahmad-3] The text here needs to be updated. This seems a cut and paste from the GNM. I thought that the GNAM needs to copy this field from the GNM. I understand that in case of out of synch message, the receiver will include its timestamp in the upper 32 bits, but that is covered later in the draft. This should cover the successful case. IMO. [Ahmad-End-3] Extensions The fixed portion of the generic notification acknowledgement message is followed by one or more of the Extensions listed in Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for information on the relative order in which different extensions, when present, MUST be placed in a Generic Notification message. [Ahmad-4] Same comment No. 2 above. Text could be improved here too.=20 [Ahmad-End-4] 4.3.1. Receiving Generic Notification Messages The MN MUST check for the presence of an authorization-enabling extension, and perform the indicated authentication. Exactly one authorization-enabling extension MUST be present in the Registration Request,=20 [Ahmad-5] s/Registration Request/Generic Notification Message/ [Ahmad-End-5] If this notification message came from the HA, relayed by the FA, or is a Co-located CoA, the MN-HA AE MUST be checked and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the MN MUST reject the GNM and SHOULD send a GNAM to the initiator with Code 196, including an Identification field computed in accordance with the rules specified in Section 7.1.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the MN accepts the HA's GNM, it will process it according to the specific rules for that extension. After that, the MN MAY reply with a GNAM with Code 0 back to the HA based on the "A" flag in the GNM. [Ahmad-6] If I recall correctly, I believe in the case of MN-HA AE validation failure, RFC3344bis mention that the HA MAY send a RRP back. If that in the case of RRQ/RRP, I am wondering why in the case of Notification, we need a stronger mandate? [Ahmad-End-6] 4.3.2. Sending Generic Notification Acknowledgement Message Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply with a GNAM based on the "A" flag in the GNM as follows: If the GNM was initiated from the FA to the MN ("MD" value is set to 4), the ordering of the extension is: any non-authentication Extensions used only by the FA, followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. [Ahmad-7] Well, the message is between the MN and the FA and there is NO other node in between examine the GNAM, I suggest modifying the above text as follows: " If the GNM was initiated from the FA to the MN ("MD" value is set to 0), MN-FA AE MUST be the last extension in order to protect all other non-=20 authentication extensions as defined in section 3.5.3 of [RFC3344]. " [Ahmad-End-7] ... ... There are a number of reasons the MN might reject a notification such as administrative in nature returning a GNAM with a code of 193, similarly and provides the Code value 192 or 194 for the unspecified reason and insufficent resources. [Ahmad] s/insufficent/insufficient If the GNM was initiated from the HA to the MN ("MD" value is set to 0) and in the case of Co-located CoA, the ordering of the extension is: any non-authentication Extensions used only by the HA, followed by the MN-HA AE defined in section 3.5.2 of [RFC3344] [Ahmad-8] Similar comment as in 7: " If the GNM was initiated from the HA to the MN ("MD" value is set to 0) and in the case of Co-located CoA, MN-HA AE MUST be the last extension =20 in order to protect all other non-authentication extensions. " [Ahmad-End-8] 4.3.3. Sending Generic Notification Messages The MN may either send a GNM to notify the FA or HA. If the message is sent to the FA, the source address is the MN's address, and the destination address is the FA's address If the FA is the target of this notification message, then the "MD" value is set to 3, and the ordering of the extension is: the notification extension, followed by any non-authentication Extensions used only by the FA, followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. Computing Authentication Extension Value is the same as section 3.5.1 of [RFC3344]. [Ahmad-9] same as comment-8 above regarding the text of the AE order. ... ... The MN chooses the Identification field in accordance with the style of replay protection it uses with its FA or HA. =20 [Ahmad-10] s/it uses with its FA or HA/it uses with its HA/ also remove the FA in the below sentence. This is part of the mobility security association the MN shares with its FA or HA. See Section 7.1.1 for the method by which the MN computes the Identification field. 4.3.4. Receiving Generic Notification Acknowledgement Messages In the case of a FA-CoA, if the MN receives this message, and the "MD" value is set to 0, it means that the GNAM came from HA If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the MN MUST silently discard the GNAM. In addition, the low-order 32 bits of the Identification field in the GNAM MUST be compared to the low-order 32 bits of the Identification field in the most recent GNA sent to the replying agent.=20 [Ahmad-11] s/recent GNA/recent GNM/ if they do not match, the GNAM MUST be silently discarded. If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If [Ahmad-12] s/the HA MUST silently/the MN MUST silently/ 4.4. Foreign Agent Consideration The FA can not only relay generic notification message between the HA and MN, but it can also initiate a GNM to the MN or HA, and it will depends on whether there is a binding for the MN. [Ahmad-13] I suggest replacing the above paragraph as follows: " The FA may initiate a GNM to the MN or the HA. Additionally, the FA also relays GNM and GNAM messages between the MN and its HA as long as there is an active binding for the MN at the FA. " [Ahmad-End-13] 4.4.1. Receiving Generic Notification Message If the FA receives a GNM, and the "MD" value is set to 0, it means that the HA is asking the FA to relay the message to the MN. If the "MD" value is set to 1, it means that the target of the notification is the FA. If the "MD" value is set to 2, it means that the MN is asking the FA to relay the message to the HA. If the "MD" value is set to 3, it means that the notification came from the MN to the FA. if the "MD" value is set to 0, the FA MAY check the FA-HA AE and Authenticator value in the Extension. =20 [Ahmad-14] I suggest replacing the above sentence with: "If the "MD" value is set to 0, the FA MAY validate the FA-HA AE if present." If the FA validates the HA's GNM, it MUST relay the GNM to the MN's home address as specified in the Home Address field of the GNM. =20 [Ahmad-15] Why this is necessary? In this case the message is from the HA all the way to the MN. There is a possibility that the HA MAY add some other authentication which addresses the FA and then add the FA-HA AE to protect these extensions. If the FA-HA AE failed authentication, it means that the FA MUST NOT accept any information that the HA is sending in this GNM to the FA. My problem is: What happened if FA-HA AE validation failed, What the FA should do. IMO, the FA should relay the message to the MN which will eventually validate the MN-HA AE to ensure that all information sent to the MN is integrity protected. [Ahmad-End-15] The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through and MN-HA [Ahmad-16] s/and MN-HA/the MN-HA/ AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN. Furthermore, the FA MUST process and remove any Extensions following the MN-HA AE, and MAY append any of its own non-authentication Extensions of relevance to the MN if applicable, and MUST append the MN-FA AE, if the FA shares a mobility security association with the MN. [Ahmad-17] I suggest the following modification to the above sentence: " Furthermore, the FA MUST process and remove any extensions following the MN-HA AE. If the FA shares a mobility security association with the=20 MN, the FA MAY append any of its own non-authentication extensions which=20 of relevance to the MN. In this case, the FA MUST append the MN-FA AE after these non-authentication extensions. " [Ahmad-End-17] {Ahmad-18] The idea here is that if the FA does not share a mobility security association with the MN and adds a non-authentication extensions, these extensions are not protected. If we want to allow such behavior, we need to document that under the security section. [Ahmad-End-18] ... ... Furthermore, the FA MUST process and remove any Extensions following the MN-HA AE, and MAY append any of its own non-authentication Extensions of relevance to the MN if applicable, and MUST append the [Ahmad-19] s/MN/HA/ MN-FA AE, if the FA shares a mobility security association with the MN. [Ahmad-20] This message is sent from the MN to the HA. NO? I believe the above needs to be updated as follows: " FA-HA AE, if the FA shares a mobility security association with the HA. " [Ahmad-End-20] If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension which is the same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST reject the GNM and SHOULD send a GNAM to the HA [Ahmad-21] s/to the HA/to the MN. 4.4.2. Sending Generic Notification Acknowledgement Messages The FA may need to either relay a GNAM message between the MN and the HA or send one as a response to a GNM messsage that was sent to it. In both cases, the GNAM message is defined as follows: The source address is the FA address, the destination address is HA's or FA's address. [Ahmad-22] s/or FA's address/or MN home address/ The Code field of the GNAM is chosen in accordance with the rules specified in the section 4.2. When replying to an accepted notification, a FA SHOULD respond with Code 0. There are a number of reasons the FA might reject a notification such as administrative in nature returning a GNAM with a code of 65, similarly and provides the Code value 64 or 66 for the unspecified reason and insufficent resources. If the FA is only relaying this message to the HA, the FA it MUST NOT [Ahmad-23] s/the FA it MUST NOT/the FA MUST NOT/ modify any of the fields beginning with the fixed portion of the Generic Notification Acknowledgement through and including the MN-HA AE or other authentication extension supplied by the HA as an [Ahmad-24] s/HA/MN/=20 I assume (as per the text above) this message is sent from the MN to the HA. authorization-enabling extension for the MN. Furthermore, the foreign agent MUST process and remove any Extensions following the MN-HA AE and MAY append any of its own non-authentication Extensions of relevance to the HA, if applicable. It MUST also append the FA-HA AE, if the FA shares a mobility security association with the HA. [Ahmad-25] same comment as MN-FA. FA adds non-authentication extensions ONLY if it shares a mobility security association with the HA. If the notification message is from the HA to the FA then the "MD" value is set to 5 and the ordering of the extension is: any non- authentication Extensions used only by the HA, followed by The FA-HA [Ahmad-26] s/HA/FA/ AE defined in section 3.5.4 of [RFC3344]. If the notification message is from the MN to the FA then the "MD" value is set to 4 and the ordering of the extension is: any non- authentication Extensions used only by the HA, followed by The MN-FA [Ahmad-27] s/HA/FA/ AE defined in section 3.5.3 of [RFC3344]. Finally, I did not review the HA section.=20 Regards,=20 Ahmad=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A843A6833 for ; Thu, 12 Feb 2009 03:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0+mOwsrf0BH for ; Thu, 12 Feb 2009 03:11:55 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 063EF3A67A2 for ; Thu, 12 Feb 2009 03:11:54 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1CBAIhT005346; Thu, 12 Feb 2009 12:10:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1CBBxgF029760; Thu, 12 Feb 2009 12:11:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n1CBBwpc000312; Thu, 12 Feb 2009 12:11:58 +0100 Message-ID: <499403FE.90807@gmail.com> Date: Thu, 12 Feb 2009 12:11:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Antti_M=E4kel=E4?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mip4@ietf.org, McCann Peter-A001034 , Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:11:56 -0000 Antti Mäkelä a écrit : > On Wed, 11 Feb 2009, McCann Peter-A001034 wrote: > >> draft-makela-mip4-nemo-haaro-03.txt >> This was presented at IETF-70 and it looks like there have been a >> couple of revisions since. Is there interest in working on it? Other >> comments? > > As the primary author :) I'll comment that I have been preparing for > and will most likely (barring force majeure issues) start working > towards my doctoral dissertation in the summer as soon as certain > arrangements have been made. My topic will be covering the virtual > operator model outlined in the first section of the draft. The work will > be conducted as part of Finnish Future Internet project > (http://futureinternet.fi/). Anyway, at least *I* will continue to have > interest in developing this further - so I'm not just going to toss it > to the WG and leave it at -00..as part of the work, there will be actual > implementation coming up. > > Whether the draft is of interest to the IETF is of course another > matter, but I do remember hearing some encouraging comments from the > audience in Vancouver that this thing might actually have a business > case :) This is certainly a draft worth following up closely, I can provide comments on the mailing list as new versions come up. Alex > > > ------------------------------------------------------------------------ > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9063A6AAA for ; Thu, 12 Feb 2009 06:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlM6l0wY1JaI for ; Thu, 12 Feb 2009 06:11:28 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E292E3A6803 for ; Thu, 12 Feb 2009 06:11:23 -0800 (PST) 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 n1CE77J05470; Thu, 12 Feb 2009 14:07:07 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, 12 Feb 2009 08:11:09 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort Thread-Index: AcmMatV58WVCw9LuTgSW3borcHfjJQAsB2Rg References: From: "Jayshree Bharatia" To: "McCann Peter-A001034" Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:11:32 -0000 Pete, Regarding your following proposal: draft-deng-mip4-host-configuration-00.txt draft-chakrabarti-mip4-mcbc-03.txt These two items are related, because DHCP uses IP-layer broadcast to deliver DHCPREQUEST messages. I'd like to propose that we drop the gen-ext draft and add these two. Comments? =20 Per my understanding, gen-ext and draft-deng-mip4-host-configuration-00.txt are related. Gen-ext draft has been there for a while and there are implementations deployed based on the solution proposed by this draft. It is a working group draft went through multiple WG last calls in this group. I don't see technical argument from you which invalidates acceptance of this draft. I strongly oppose your suggestion on dropping gen-ext draft. Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of McCann Peter-A001034 Sent: Wednesday, February 11, 2009 11:05 AM To: mip4@ietf.org Cc: Henrik Levkowetz Subject: [Mip4] Status update & Recharter effort Hi, all, Traffic on the list has been light lately so I wanted to provide a status update on our existing work items and kick-start a discussion on where to take the working group next. Here is a list of our current work items and status: draft-ietf-mip4-generic-notification-message-07.txt New version was uploaded on 11/3, in response to comments from WGLC. On cursory examination, it appears to me that most if not all comments have been addressed. It would be nice to get confirmation of this from those who had comments back in July/August. Then we can submit for publication. draft-ietf-mip4-nemov4-dynamic-02.txt We will issue a last call on this soon, but it has lower priority than 2006bis. draft-ietf-mip4-nemov4-fa-03.txt No interest in continuing. We will drop this item from our charter. draft-ietf-mip4-rfc3344bis-07.txt Still working on the shepherd writeup. Will be submitted for publication soon. draft-ietf-mip4-udptunnel-mib-01.txt On hold waiting on 2006bis; then we will issue WGLC. draft-ietf-mip4-rfc2006bis-05.txt Ready for last call. Will issue soon. draft-ietf-mip4-dsmipv4-10.txt In RFC Editor's queue. draft-ietf-mip4-gen-ext-04.txt Ongoing discussion on whether to continue this item (see recharter discussion below). Several new work items have come to our attention over the past few meeting cycles. Here is a partial list of potential work items for mip4 going forward. Please comment on which you would like to see and which you think should be excluded. draft-deng-mip4-host-configuration-00.txt draft-chakrabarti-mip4-mcbc-03.txt These two items are related, because DHCP uses IP-layer broadcast to deliver DHCPREQUEST messages. I'd like to propose that we drop the gen-ext draft and add these two. Comments? =20 draft-gundavelli-mip4-multiple-tunnel-support-00.txt We've had some good discussion already on the mailing list and this seems like a potentially useful extension. Comments? draft-doswald-robert-mip4-btn-fmipv4-00.txt This was presented at IETF-72. Is there interest in working on it? Other comments? draft-makela-mip4-nemo-haaro-03.txt This was presented at IETF-70 and it looks like there have been a couple of revisions since. Is there interest in working on it? Other comments? draft-acee-mip4-bulk-revocation-01.txt This was presented at IETF-70. Is there interest in working on it? Other comments? draft-yegani-gre-key-extension-03.txt This was presented at IETF-70. Is there interest in working on it? Other comments? If I left anything out please speak up. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E436528C157 for ; Thu, 12 Feb 2009 11:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqPXiNM-5m-W for ; Thu, 12 Feb 2009 11:37:13 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with SMTP id A9BC128C145 for ; Thu, 12 Feb 2009 11:37:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1234467438!95175272!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 30275 invoked from network); 12 Feb 2009 19:37:18 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-8.tower-55.messagelabs.com with SMTP; 12 Feb 2009 19:37:18 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id n1CJbDes002365 for ; Thu, 12 Feb 2009 12:37:18 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n1CJbCJ0000651 for ; Thu, 12 Feb 2009 13:37:12 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n1CJbC21000638 for ; Thu, 12 Feb 2009 13:37:12 -0600 (CST) 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, 12 Feb 2009 14:37:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort thread-index: AcmMatV58WVCw9LuTgSW3borcHfjJQAsB2RgAAtxehA= References: From: "McCann Peter-A001034" To: "Jayshree Bharatia" X-CFilter-Loop: Reflected Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:37:15 -0000 Hi, Jayshree, Thanks for your input. The issue was raised during AD review that we might not want more than one protocol for configuring options on the host. Given that DHCP can be made to work over a Mobile IP tunnel, it might be the preferred option. I know that we've had the gen-ext draft as a working group document for some time and there was consensus to advance it from within the working group. However, based on the feedback we got as part of a wider review, it might be necessary to revisit the question of which approach to take. -Pete Jayshree Bharatia wrote: > Pete, >=20 > Regarding your following proposal: >=20 > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? >=20 >=20 > Per my understanding, gen-ext and > draft-deng-mip4-host-configuration-00.txt are related. Gen-ext draft > has been there for a while and there are implementations deployed > based on the solution proposed by this draft. It is a working group > draft went through multiple WG last calls in this group. I don't see > technical argument from you which invalidates acceptance of this > draft. =20 >=20 > I strongly oppose your suggestion on dropping gen-ext draft. >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf > Of McCann Peter-A001034=20 > Sent: Wednesday, February 11, 2009 11:05 AM > To: mip4@ietf.org > Cc: Henrik Levkowetz > Subject: [Mip4] Status update & Recharter effort >=20 > Hi, all, >=20 > Traffic on the list has been light lately so I wanted to provide a > status update on our existing work items and kick-start a discussion > on where to take the working group next. =20 >=20 > Here is a list of our current work items and status: >=20 >=20 > draft-ietf-mip4-generic-notification-message-07.txt > New version was uploaded on 11/3, in response to comments > from WGLC. On cursory examination, it appears to me that > most if not all comments have been addressed. It would be > nice to get confirmation of this from those who had comments > back in July/August. Then we can submit for publication. >=20 > draft-ietf-mip4-nemov4-dynamic-02.txt > We will issue a last call on this soon, but it has lower > priority than 2006bis. >=20 > draft-ietf-mip4-nemov4-fa-03.txt > No interest in continuing. We will drop this item from our charter. >=20 > draft-ietf-mip4-rfc3344bis-07.txt > Still working on the shepherd writeup. Will be submitted for > publication soon. >=20 > draft-ietf-mip4-udptunnel-mib-01.txt > On hold waiting on 2006bis; then we will issue WGLC. >=20 > draft-ietf-mip4-rfc2006bis-05.txt > Ready for last call. Will issue soon. >=20 > draft-ietf-mip4-dsmipv4-10.txt > In RFC Editor's queue. >=20 > draft-ietf-mip4-gen-ext-04.txt > Ongoing discussion on whether to continue this item (see recharter > discussion below). >=20 >=20 > Several new work items have come to our attention over the past few > meeting cycles. Here is a partial list of potential work items for > mip4 going forward. Please comment on which you would like to see > and which you think should be excluded. =20 >=20 >=20 > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? >=20 > draft-gundavelli-mip4-multiple-tunnel-support-00.txt > We've had some good discussion already on the mailing list and this > seems like a potentially useful extension. Comments? >=20 > draft-doswald-robert-mip4-btn-fmipv4-00.txt > This was presented at IETF-72. Is there interest in working on it? > Other comments? >=20 > draft-makela-mip4-nemo-haaro-03.txt > This was presented at IETF-70 and it looks like there have been a > couple of revisions since. Is there interest in working on it?=20 > Other comments?=20 >=20 > draft-acee-mip4-bulk-revocation-01.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? >=20 > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? >=20 >=20 >=20 > If I left anything out please speak up. >=20 > -Pete Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771EA28C15A for ; Thu, 12 Feb 2009 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMs0YMn7IVmH for ; Thu, 12 Feb 2009 11:39:19 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 424A528C157 for ; Thu, 12 Feb 2009 11:39:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1234467559!31563127!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27734 invoked from network); 12 Feb 2009 19:39:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-153.messagelabs.com with SMTP; 12 Feb 2009 19:39:19 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id n1CJdJNV016262 for ; Thu, 12 Feb 2009 12:39:19 -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 n1CJdJuQ026711 for ; Thu, 12 Feb 2009 13:39:19 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id n1CJdIhK026707 for ; Thu, 12 Feb 2009 13:39:18 -0600 (CST) 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, 12 Feb 2009 14:39:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort thread-index: AcmMatV58WVCw9LuTgSW3borcHfjJQAEAmsAADOdI1A= References: From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-CFilter-Loop: Reflected Cc: Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:39:20 -0000 Hi, Ahmad, As the author of that proposal, I must take my chair hat off with respect to whether it should be a WG item. Personally I would like to work with folks off-line to come back to the group with an even better proposal at a future date. -Pete Ahmad Muhanna wrote: > Hello, Pete, >=20 > As I recall, there was also one more item related to > make-before-break proposed for the rechartering discussion. Is that > still part of the list? =20 >=20 > Please see more comments inline. >=20 > Regards, > Ahmad >=20 >=20 >> -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf >> Of McCann Peter-A001034 Sent: Wednesday, February 11, 2009 11:05 AM >> To: mip4@ietf.org >> Cc: Henrik Levkowetz >> Subject: [Mip4] Status update & Recharter effort >>=20 >> Hi, all, >>=20 >> Traffic on the list has been light lately so I wanted to provide a >> status update on our existing work items and kick-start a discussion >> on where to take the working group next. >>=20 >> Here is a list of our current work items and status: >>=20 >>=20 >> draft-ietf-mip4-generic-notification-message-07.txt >> New version was uploaded on 11/3, in response to comments >> from WGLC. On cursory examination, it appears to me that >> most if not all comments have been addressed. It would be >> nice to get confirmation of this from those who had comments >> back in July/August. Then we can submit for publication. >=20 > [Ahmad] > I agree. > Upon a second review, I have few straight forward comments which I > will share with the authors and the wg shortly.=20 >=20 >>=20 >>=20 >>=20 >> Several new work items have come to our attention over the past few >> meeting cycles. Here is a partial list of potential work items for >> mip4 going forward. Please comment on which you would like to see >> and which you think should be excluded. >>=20 >>=20 >> draft-deng-mip4-host-configuration-00.txt >> draft-chakrabarti-mip4-mcbc-03.txt >> These two items are related, because DHCP uses IP-layer broadcast >> to deliver DHCPREQUEST messages. I'd like to propose that we drop >> the gen-ext draft and add these two. Comments? >=20 > [Ahmad] > I support taking this item as a work item for the wg recharter. > I also support merging these two drafts as when addressing MCBC > fundamentally, it will naturally include DHCP.=20 >=20 >>=20 >> draft-yegani-gre-key-extension-03.txt >> This was presented at IETF-70. Is there interest in working on it? >=20 > [Ahmad] > I support including this as a work item for the wg recharter. >=20 >> Other >> comments? >>=20 >>=20 >>=20 >> If I left anything out please speak up. >>=20 >> -Pete >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 >> Charter page: >> http://www.ietf.org/html.charters/mip4-charter.html Supplemental >> site: http://www.mip4.org/=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB57C3A6ABA for ; Thu, 12 Feb 2009 12:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XGXFNE8usyu for ; Thu, 12 Feb 2009 12:04:37 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8B08C3A69A8 for ; Thu, 12 Feb 2009 12:04:37 -0800 (PST) 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 n1CK4d211306; Thu, 12 Feb 2009 20:04:39 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, 12 Feb 2009 14:04:38 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort Thread-Index: AcmMatV58WVCw9LuTgSW3borcHfjJQAEAmsAADOdI1AAAOZ70A== References: From: "Ahmad Muhanna" To: "McCann Peter-A001034" , Cc: Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 20:04:38 -0000 No problem. Thanks Pete! Regards, Ahmad =20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 > Sent: Thursday, February 12, 2009 1:39 PM > To: Muhanna, Ahmad (RICH1:2H10); mip4@ietf.org > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Status update & Recharter effort >=20 > Hi, Ahmad, >=20 > As the author of that proposal, I must take my chair hat off=20 > with respect to whether it should be a WG item. Personally I=20 > would like to work with folks off-line to come back to the=20 > group with an even better proposal at a future date. >=20 > -Pete >=20 > Ahmad Muhanna wrote: > > Hello, Pete, > >=20 > > As I recall, there was also one more item related to=20 > make-before-break=20 > > proposed for the rechartering discussion. Is that still part of the=20 > > list? > >=20 > > Please see more comments inline. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > >> -----Original Message----- > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > >> Of McCann Peter-A001034 Sent: Wednesday, February 11, 2009 11:05 AM > >> To: mip4@ietf.org > >> Cc: Henrik Levkowetz > >> Subject: [Mip4] Status update & Recharter effort > >>=20 > >> Hi, all, > >>=20 > >> Traffic on the list has been light lately so I wanted to provide a=20 > >> status update on our existing work items and kick-start a=20 > discussion=20 > >> on where to take the working group next. > >>=20 > >> Here is a list of our current work items and status: > >>=20 > >>=20 > >> draft-ietf-mip4-generic-notification-message-07.txt > >> New version was uploaded on 11/3, in response to comments > >> from WGLC. On cursory examination, it appears to me that > >> most if not all comments have been addressed. It would be > >> nice to get confirmation of this from those who had comments > >> back in July/August. Then we can submit for publication. > >=20 > > [Ahmad] > > I agree. > > Upon a second review, I have few straight forward comments which I=20 > > will share with the authors and the wg shortly. > >=20 > >>=20 > >>=20 > >>=20 > >> Several new work items have come to our attention over the=20 > past few=20 > >> meeting cycles. Here is a partial list of potential work items for > >> mip4 going forward. Please comment on which you would like to see=20 > >> and which you think should be excluded. > >>=20 > >>=20 > >> draft-deng-mip4-host-configuration-00.txt > >> draft-chakrabarti-mip4-mcbc-03.txt > >> These two items are related, because DHCP uses IP-layer broadcast > >> to deliver DHCPREQUEST messages. I'd like to propose=20 > that we drop > >> the gen-ext draft and add these two. Comments? > >=20 > > [Ahmad] > > I support taking this item as a work item for the wg recharter. > > I also support merging these two drafts as when addressing MCBC=20 > > fundamentally, it will naturally include DHCP. > >=20 > >>=20 > >> draft-yegani-gre-key-extension-03.txt > >> This was presented at IETF-70. Is there interest in=20 > working on it? > >=20 > > [Ahmad] > > I support including this as a work item for the wg recharter. > >=20 > >> Other > >> comments? > >>=20 > >>=20 > >>=20 > >> If I left anything out please speak up. > >>=20 > >> -Pete > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www.ietf.org/mailman/listinfo/mip4 > >> Charter page: > >> http://www.ietf.org/html.charters/mip4-charter.html Supplemental > >> site: http://www.mip4.org/ >=20 >=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BA428C261 for ; Thu, 12 Feb 2009 12:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyqhYu5EfF9D for ; Thu, 12 Feb 2009 12:46:11 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 18FD428C25D for ; Thu, 12 Feb 2009 12:46:11 -0800 (PST) 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 n1CKkD605424; Thu, 12 Feb 2009 20:46:13 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, 12 Feb 2009 14:45:48 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort Thread-Index: AcmMatV58WVCw9LuTgSW3borcHfjJQAsB2RgAAtxehAAAmhEwA== References: From: "Jayshree Bharatia" To: "McCann Peter-A001034" Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 20:46:12 -0000 See my response inline... -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of McCann Peter-A001034 Sent: Thursday, February 12, 2009 1:37 PM To: Bharatia, Jayshree (RICH1:2H10) Cc: mip4@ietf.org; Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort Hi, Jayshree, Thanks for your input. The issue was raised during AD review that we might not want more than one protocol for configuring options on the host. Given that DHCP can be made to work over a Mobile IP tunnel, it might be the preferred option. [JB] I have always said that and also indicated in the draft from the very beginning that DHCP is one of the option. The proposal we have in this draft is an alternate solution. So again, I have failed to understand reasoning behind not adopting gen-ext draft. In fact, gen-ext was indicated as more preferred solution in WiMAX NWG at one point. We couldn't accept the proposal in that group because of the status of this draft in IETF. I know that we've had the gen-ext draft as a working group document for some time and there was consensus to advance it from within the working group. However, based on the feedback we got as part of a wider review, it might be necessary to revisit the question of which approach to take. [JB] I am surprise to see you quote as "wider review". When was that done?=20 -Pete Jayshree Bharatia wrote: > Pete, >=20 > Regarding your following proposal: >=20 > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? >=20 >=20 > Per my understanding, gen-ext and > draft-deng-mip4-host-configuration-00.txt are related. Gen-ext draft=20 > has been there for a while and there are implementations deployed=20 > based on the solution proposed by this draft. It is a working group=20 > draft went through multiple WG last calls in this group. I don't see=20 > technical argument from you which invalidates acceptance of this > draft. =20 >=20 > I strongly oppose your suggestion on dropping gen-ext draft. >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of McCann Peter-A001034 > Sent: Wednesday, February 11, 2009 11:05 AM > To: mip4@ietf.org > Cc: Henrik Levkowetz > Subject: [Mip4] Status update & Recharter effort >=20 > Hi, all, >=20 > Traffic on the list has been light lately so I wanted to provide a=20 > status update on our existing work items and kick-start a discussion=20 > on where to take the working group next. >=20 > Here is a list of our current work items and status: >=20 >=20 > draft-ietf-mip4-generic-notification-message-07.txt > New version was uploaded on 11/3, in response to comments > from WGLC. On cursory examination, it appears to me that > most if not all comments have been addressed. It would be > nice to get confirmation of this from those who had comments > back in July/August. Then we can submit for publication. >=20 > draft-ietf-mip4-nemov4-dynamic-02.txt > We will issue a last call on this soon, but it has lower > priority than 2006bis. >=20 > draft-ietf-mip4-nemov4-fa-03.txt > No interest in continuing. We will drop this item from our charter. >=20 > draft-ietf-mip4-rfc3344bis-07.txt > Still working on the shepherd writeup. Will be submitted for > publication soon. >=20 > draft-ietf-mip4-udptunnel-mib-01.txt > On hold waiting on 2006bis; then we will issue WGLC. >=20 > draft-ietf-mip4-rfc2006bis-05.txt > Ready for last call. Will issue soon. >=20 > draft-ietf-mip4-dsmipv4-10.txt > In RFC Editor's queue. >=20 > draft-ietf-mip4-gen-ext-04.txt > Ongoing discussion on whether to continue this item (see recharter > discussion below). >=20 >=20 > Several new work items have come to our attention over the past few=20 > meeting cycles. Here is a partial list of potential work items for > mip4 going forward. Please comment on which you would like to see > and which you think should be excluded. =20 >=20 >=20 > draft-deng-mip4-host-configuration-00.txt > draft-chakrabarti-mip4-mcbc-03.txt > These two items are related, because DHCP uses IP-layer broadcast > to deliver DHCPREQUEST messages. I'd like to propose that we drop > the gen-ext draft and add these two. Comments? >=20 > draft-gundavelli-mip4-multiple-tunnel-support-00.txt > We've had some good discussion already on the mailing list and this > seems like a potentially useful extension. Comments? >=20 > draft-doswald-robert-mip4-btn-fmipv4-00.txt > This was presented at IETF-72. Is there interest in working on it? > Other comments? >=20 > draft-makela-mip4-nemo-haaro-03.txt > This was presented at IETF-70 and it looks like there have been a > couple of revisions since. Is there interest in working on it?=20 > Other comments?=20 >=20 > draft-acee-mip4-bulk-revocation-01.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? >=20 > draft-yegani-gre-key-extension-03.txt > This was presented at IETF-70. Is there interest in working on it? > Other > comments? >=20 >=20 >=20 > If I left anything out please speak up. >=20 > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E4B3A67FC for ; Thu, 12 Feb 2009 14:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5gf044nVaQn for ; Thu, 12 Feb 2009 14:21:31 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with SMTP id 2004F3A67D6 for ; Thu, 12 Feb 2009 14:21:31 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1234477292!39269819!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 14738 invoked from network); 12 Feb 2009 22:21:32 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-2.tower-55.messagelabs.com with SMTP; 12 Feb 2009 22:21:32 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id n1CMLN7T014748 for ; Thu, 12 Feb 2009 15:21:32 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n1CMLNOJ023994 for ; Thu, 12 Feb 2009 16:21:23 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n1CMLNLP023989 for ; Thu, 12 Feb 2009 16:21:23 -0600 (CST) 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, 12 Feb 2009 17:21:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort thread-index: AcmMatV58WVCw9LuTgSW3borcHfjJQAsB2RgAAtxehAAAmhEwAAAfXPw References: From: "McCann Peter-A001034" To: "Jayshree Bharatia" X-CFilter-Loop: Reflected Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:21:32 -0000 Hi, Jayshree, Jayshree Bharatia wrote: > See my response inline... >=20 > -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf >> Of McCann Peter-A001034=20 >> Sent: Thursday, February 12, 2009 1:37 PM >> To: Bharatia, Jayshree (RICH1:2H10) >> Cc: mip4@ietf.org; Henrik Levkowetz >> Subject: Re: [Mip4] Status update & Recharter effort >>=20 >> Hi, Jayshree, >>=20 >> Thanks for your input. >>=20 >> The issue was raised during AD review that we might not want more >> than one protocol for configuring options on the host. Given that >> DHCP can be made to work over a Mobile IP tunnel, it might be the >> preferred option. > >[JB] I have always said that and also indicated in >the draft from the very beginning that DHCP is one of the option. The >proposal we have in this draft is an alternate solution. So again, I >have failed to understand reasoning behind not adopting gen-ext >draft. In fact, gen-ext was indicated as more preferred solution in >WiMAX NWG at one point. We couldn't accept the proposal in that group >because of the status of this draft in IETF. =20 Opinions have been expressed that we shouldn't standardize two mechanisms for doing the same thing. =20 >> I know that we've had the gen-ext draft as a working group document >> for some time and there was consensus to advance it from within the >> working group. However, based on the feedback we got as part of a >> wider review, it might be necessary to revisit the question of which >> approach to take.=20 > >[JB] I am surprise to see you quote as "wider >review". When was that done? =20 The discussion goes back to the 2007 joint last call that was done in the mip4 and dhc working groups. There have been comments on the mailing list as well as in person at IETF meetings where some individuals prefer to see a single DHCP-based alternative documented by mip4. -Pete =20 >> -Pete >>=20 >> Jayshree Bharatia wrote: >> Pete, >>=20 >> Regarding your following proposal: >>=20 >> draft-deng-mip4-host-configuration-00.txt >> draft-chakrabarti-mip4-mcbc-03.txt >> These two items are related, because DHCP uses IP-layer broadcast >> to deliver DHCPREQUEST messages. I'd like to propose that we drop >> the gen-ext draft and add these two. Comments? >>=20 >>=20 >> Per my understanding, gen-ext and >> draft-deng-mip4-host-configuration-00.txt are related. Gen-ext draft >> has been there for a while and there are implementations deployed >> based on the solution proposed by this draft. It is a working group >> draft went through multiple WG last calls in this group. I don't see >> technical argument from you which invalidates acceptance of this >> draft.=20 >>=20 >> I strongly oppose your suggestion on dropping gen-ext draft. >>=20 >> Regards, >> Jayshree >>=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486403A6A78 for ; Fri, 13 Feb 2009 06:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FphqTfox0b53 for ; Fri, 13 Feb 2009 06:25:05 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id BA1B03A6C1A for ; Fri, 13 Feb 2009 06:25:04 -0800 (PST) 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 n1DEP6M14518; Fri, 13 Feb 2009 14:25:06 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, 13 Feb 2009 08:20:41 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Status update & Recharter effort Thread-Index: AcmMatV58WVCw9LuTgSW3borcHfjJQAsB2RgAAtxehAAAmhEwAAAfXPwACQ2fCA= References: From: "Jayshree Bharatia" To: "McCann Peter-A001034" Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] Status update & Recharter effort X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:25:08 -0000 Please see my response inline.=20 -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, February 12, 2009 4:21 PM To: Bharatia, Jayshree (RICH1:2H10) Cc: mip4@ietf.org; Henrik Levkowetz Subject: RE: [Mip4] Status update & Recharter effort Hi, Jayshree, Jayshree Bharatia wrote: > See my response inline... >=20 > -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 >> Of McCann Peter-A001034 >> Sent: Thursday, February 12, 2009 1:37 PM >> To: Bharatia, Jayshree (RICH1:2H10) >> Cc: mip4@ietf.org; Henrik Levkowetz >> Subject: Re: [Mip4] Status update & Recharter effort >>=20 >> Hi, Jayshree, >>=20 >> Thanks for your input. >>=20 >> The issue was raised during AD review that we might not want more=20 >> than one protocol for configuring options on the host. Given that=20 >> DHCP can be made to work over a Mobile IP tunnel, it might be the=20 >> preferred option. > >[JB] I have always said that and also indicated in the draft from the=20 >very beginning that DHCP is one of the option. The proposal we have in=20 >this draft is an alternate solution. So again, I have failed to=20 >understand reasoning behind not adopting gen-ext draft. In fact,=20 >gen-ext was indicated as more preferred solution in WiMAX NWG at one=20 >point. We couldn't accept the proposal in that group >because of the status of this draft in IETF. =20 Opinions have been expressed that we shouldn't standardize two mechanisms for doing the same thing. [JB] IETF has standardized many mechanisms for solving same things. In fact we have developed multiple protocols and hence formed multiple WGs for doing same things. This is the solution preferred from the implementation perspective. So, I don't see this reason as a point of rejection. =20 >> I know that we've had the gen-ext draft as a working group document=20 >> for some time and there was consensus to advance it from within the=20 >> working group. However, based on the feedback we got as part of a=20 >> wider review, it might be necessary to revisit the question of which=20 >> approach to take. > >[JB] I am surprise to see you quote as "wider >review". When was that done? =20 The discussion goes back to the 2007 joint last call that was done in the mip4 and dhc working groups. There have been comments on the mailing list as well as in person at IETF meetings where some individuals prefer to see a single DHCP-based alternative documented by mip4. [JB] My track of the progress says that there was just a one call made from the process perspective with dhc. There were hardly one or two emails exchanged over this subject. I am hoping that you realize the real deployment need of this draft over other DHCP alternative rather than having biased opinion on dropping this draft. -Pete =20 >> -Pete >>=20 >> Jayshree Bharatia wrote: >> Pete, >>=20 >> Regarding your following proposal: >>=20 >> draft-deng-mip4-host-configuration-00.txt >> draft-chakrabarti-mip4-mcbc-03.txt >> These two items are related, because DHCP uses IP-layer broadcast >> to deliver DHCPREQUEST messages. I'd like to propose that we drop >> the gen-ext draft and add these two. Comments? >>=20 >>=20 >> Per my understanding, gen-ext and >> draft-deng-mip4-host-configuration-00.txt are related. Gen-ext draft=20 >> has been there for a while and there are implementations deployed=20 >> based on the solution proposed by this draft. It is a working group=20 >> draft went through multiple WG last calls in this group. I don't see=20 >> technical argument from you which invalidates acceptance of this=20 >> draft. >>=20 >> I strongly oppose your suggestion on dropping gen-ext draft. >>=20 >> Regards, >> Jayshree >>=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D673A687A for ; Sun, 15 Feb 2009 10:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDQD2ojhK+WN for ; Sun, 15 Feb 2009 10:49:48 -0800 (PST) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 66C2A3A6824 for ; Sun, 15 Feb 2009 10:49:48 -0800 (PST) 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 n1FInqw14400; Sun, 15 Feb 2009 18:49:52 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: Sun, 15 Feb 2009 12:49:44 -0600 Message-ID: In-Reply-To: <1d38a3350902142331v4651dd40r8a5b222a74a68a74@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on: Generic Notification Message for Mobile IPv4 Thread-Index: AcmPP1//Y54ReCejRSWe6jK9g2ElGwARGIvQ References: <1d38a3350902142331v4651dd40r8a5b222a74a68a74@mail.gmail.com> From: "Ahmad Muhanna" To: "Hui Deng" Cc: mip4@ietf.org, McCann Peter-A001034 Subject: Re: [Mip4] Comments on: Generic Notification Message for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:49:49 -0000 Hi Hui, looks good. I have one comment and a reply inline. Regards,=20 Ahmad ________________________________ =09 ++++++++++++++++ =09 4.1. Generic Notification Message =09 A generic notification message is sent by a mobility agent to inform another mobility agent, or a MN, of MIP-related information such as vendor specific extensions [RFC3115] and generic string notification [RFC4917]. These messages must use the same IP and UDP headers as any previous Registration Request or Reply message to the same entity. This would support NAT traversal and ensure same security association used for GNM/GNAM and RRQ/RRP. The generic notification message is defined as follows: =09 IP Fields: =09 Source Address Same as the last Registration Reply/Request message received. =09 Destination Address Same as the last Registration Reply/Request message. =09 UDP Fields: =09 Source Port Same as the last Registration Reply/Request message. =09 Destination Port Same as the last Registration Reply/Request message. =09 [Ahmad-1] Are these information saved in the mobile node BCE? I did not check RFC3344 lately but just in case, if these IP addresses are not currently save in the MN binding, then it needs to be added. =09 [Ahmad-end-1] Your recollection is correct, those information are not saved in BCE, so I add=20 one paragraph below The MN, FA, and HA MUST maintain the following information: - the IP source address of the Registration Request/Reply - the IP destination address of the Registration Request/Reply - the UDP source port of the Registration Request/Reply - the UDP destination port of the Registration Request/Reply =09 [Ahmad-1] This way looks ok but the text should be more specific to each node. In other words, what the MN needs to keep, what the FA needs to keep, etc. Especially the FA should be unique in here. IMO, the draft should not leave this information vague in order to eliminate interoperability issues.=20 Actually, after thinking about this one more time, a much easier approach should be something like the following: The sending node always sends the GNM message following the same procedure for sending Registration Request as in section 3.3 of [RFC3344] and the receiving node follows the same procedure for Registration Reply as in section 3.4. of [RFC3344] when sending GNAM. IMO, this should work fine with messages sent to the FA and HA. With respect to messages sent to the MN, it may be a little tricky. But a mobile node which will support this draft, will comply with its requirement. =09 [Ahmad-end-1] =09 =09 Finally, I did not review the HA section. If you have time, I would say thanks again if you could help to review HA section. [Ahmad] Sure. I will try to do that and share with you my comments, if I have any. Thanks for your detail review. Please feel free to let me know if you are fine with those revisions. =20 Best regards, =20 -Hui =20 =09 Regards, Ahmad =09 =09 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE1C3A693E for ; Sat, 14 Feb 2009 23:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[AWL=3.647, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykTk8ZcvQNBj for ; Sat, 14 Feb 2009 23:30:59 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id E7EC13A68D0 for ; Sat, 14 Feb 2009 23:30:58 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1121691rvb.49 for ; Sat, 14 Feb 2009 23:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IKHpUtMTY552ST7VdT8x6+1/ghTt58j8JcZAUjXSw8Y=; b=CKneYUkY/Pnr+SbH8ra8a6ZgAhV8e8S2KJrHaSbXBaZkwb+gpWZi6bdYIv36/RXRfS VkScpRAbegaciDTcOYq+hCgVw4xEif0X8G0IAmQjegt3ghoxUXqt942Sgu9PPi7ALhO/ x1BQ2g6evI5Vy1Zlu8EE3woINLOP/f4PPSYD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nXhkarpxXbniC9i6IXemt++7ISUSYiIIep/yMyFHoEAKJJLhd+tH/dsVe/iL2GEnBX 1E769OzHFE/sWuliNT2W1WT6ikWuXVWIKgVgxSWAGwACgLahEHgGozD9rYankHEeLkdY VZ8TP5HUJ0iueOhAOqKNn2wLDtsiMsOhTMZck= MIME-Version: 1.0 Received: by 10.142.230.11 with SMTP id c11mr1747771wfh.246.1234683066386; Sat, 14 Feb 2009 23:31:06 -0800 (PST) In-Reply-To: References: Date: Sun, 15 Feb 2009 15:31:06 +0800 Message-ID: <1d38a3350902142331v4651dd40r8a5b222a74a68a74@mail.gmail.com> From: Hui Deng To: Ahmad Muhanna Content-Type: multipart/alternative; boundary=000e0cd2301a9508360462f00d92 X-Mailman-Approved-At: Sun, 15 Feb 2009 11:03:54 -0800 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: Re: [Mip4] Comments on: Generic Notification Message for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 07:31:02 -0000 --000e0cd2301a9508360462f00d92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Ahmad I appreciate your review again, all your 27 comments are adopted, thanks for your detail comments, inline each below please. 2009/2/12 Ahmad Muhanna > Hi Hui, > > I reviewed the new revision and I have few comments on the latest > version of the MIP GNM draft. Please see below: > > Regards, > Ahmad > > ++++++++++++++++ > > 4.1. Generic Notification Message > > A generic notification message is sent by a mobility agent to inform > another mobility agent, or a MN, of MIP-related information such as > vendor specific extensions [RFC3115] and generic string > notification [RFC4917]. These messages must use the same IP and UDP > headers as any previous Registration Request or Reply message to the > same entity. This would support NAT traversal and ensure same > security association used for GNM/GNAM and RRQ/RRP. The generic > notification message is defined as follows: > > IP Fields: > > Source Address Same as the last Registration Reply/Request > message received. > > Destination Address Same as the last Registration Reply/Request > message. > > UDP Fields: > > Source Port Same as the last Registration Reply/Request > message. > > Destination Port Same as the last Registration Reply/Request > message. > > [Ahmad-1] > Are these information saved in the mobile node BCE? I did not check > RFC3344 lately but just in case, if these IP addresses are not currently > save in the MN binding, then it needs to be added. > > [Ahmad-end-1] Your recollection is correct, those information are not saved in BCE, so I add one paragraph below The MN, FA, and HA MUST maintain the following information: - the IP source address of the Registration Request/Reply - the IP destination address of the Registration Request/Reply - the UDP source port of the Registration Request/Reply - the UDP destination port of the Registration Request/Reply > > .... > ...... > > The fixed portion of the Generic Notification Message is followed > by one or more extensions which may be used with this message, and > by one or more authentication extensions (as defined in Section > 3.5 of [RFC3344]. This document mandate the MN-HA AE when this > message is sent between the MN and the HA, others are optional. > This document also mandate the MN-FA AE when this message is sent > between the MN and the FA, others are optional. This document > mandate the FA-HA AE when this message is sent between the FA and > the HA, others are optional. This could be judged based on "MD" > value.). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for > information on the relative order in which different extensions, > when present, must be placed in a Generic Notification Message. > > [Ahmad-2] > May be the text here is not very accurate. because it gives the > impression that RFC3344 talks about the order of extension in the GNM > which is NOT. > > What about replacing the last sentence as follows (Just a suggestion): > > " > See Sections 3.6.1.3 and 3.7.2.2 in [RFC3344] for the rules on the order > of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. > The same rules are applicable to GNM and GNAM. > " > > [Ahmad-End-2] Your suggestion has been adopted in the updated version. thanks, > > > 4.2. Generic Notification Acknowledgment Message > > ... > ... > > Identification > > A 64-bit number, constructed by the sender, used for matching > Generic Notification with Generic Notification Acknowledgement, > and for protecting against replay attacks of notification > messages. Here is the same as Sections 5.4 and 5.7 of [RFC3344]. > Timestamps is mandatory. > > [Ahmad-3] > The text here needs to be updated. This seems a cut and paste from the > GNM. I thought that the GNAM needs to copy this field from the GNM. I > understand that in case of out of synch message, the receiver will > include its timestamp in the upper 32 bits, but that is covered later in > the draft. This should cover the successful case. IMO. > [Ahmad-End-3] I updated the text here below: Identification if the timestamp of the GNM is valid, the receiver copies the entire Identification field into the GNAM it returns the GNAM message to the sender. if the timestamp of the GNM is not valid, the receiver copies only the low-order 32 bits into the GNAM, and supplies the high-order 32 bits from its own time of day. Both GNM and GNAM mandate Timestamps. > > > Extensions > > The fixed portion of the generic notification acknowledgement > message is followed by one or more of the Extensions listed in > Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of > [RFC3344] for information on the relative order in which different > extensions, when present, MUST be placed in a Generic Notification > message. > > [Ahmad-4] > Same comment No. 2 above. Text could be improved here too. > > [Ahmad-End-4] Updated below Extensions The fixed portion of the GNAM is followed by one or more of the Extensions listed in Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM. > > > 4.3.1. Receiving Generic Notification Messages > > The MN MUST check for the presence of an authorization-enabling > extension, and perform the indicated authentication. Exactly one > authorization-enabling extension MUST be present in the Registration > Request, > > [Ahmad-5] > s/Registration Request/Generic Notification Message/ > > [Ahmad-End-5] Done > > > > If this notification message came from the HA, relayed by the FA, or > is a Co-located CoA, the MN-HA AE MUST be checked and the MN MUST > check the Authenticator value in the Extension. If no MN-HA AE is > found, or if more than one MN-HA AE is found, or if the Authenticator > is invalid, the MN MUST reject the GNM and SHOULD send a GNAM to the > initiator with Code 196, including an Identification field computed > in accordance with the rules specified in Section 7.1.1. The MN MUST > do no further processing with such a notification, though it SHOULD > log the error as a security exception. If the MN accepts the HA's > GNM, it will process it according to the specific rules for that > extension. After that, the MN MAY reply with a GNAM with Code 0 back > to the HA based on the "A" flag in the GNM. > > [Ahmad-6] > If I recall correctly, I believe in the case of MN-HA AE validation > failure, RFC3344bis mention that the HA MAY send a RRP back. If that in > the case of RRQ/RRP, I am wondering why in the case of Notification, we > need a stronger mandate? > [Ahmad-End-6] You are correct here, RFC 3344bis specify MAY, here MAY also been updated. > > > 4.3.2. Sending Generic Notification Acknowledgement Message > > Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply > with a GNAM based on the "A" flag in the GNM as follows: > > If the GNM was initiated from the FA to the MN ("MD" value is set to > 4), the ordering of the extension is: any non-authentication > Extensions used only by the FA, followed by The MN-FA AE defined in > section 3.5.3 of [RFC3344]. > > [Ahmad-7] > Well, the message is between the MN and the FA and there is NO other > node in between examine the GNAM, I suggest modifying the above text as > follows: > " > If the GNM was initiated from the FA to the MN ("MD" value is set to > 0), MN-FA AE MUST be the last extension in order to protect all other > non- > authentication extensions as defined in section 3.5.3 of [RFC3344]. > " > [Ahmad-End-7] Done > > > ... > ... > There are a number of reasons the MN might reject a notification such > as administrative in nature returning a GNAM with a code of 193, > similarly and provides the Code value 192 or 194 for the unspecified > reason and insufficent resources. > > [Ahmad] > s/insufficent/insufficient Done > > > If the GNM was initiated from the HA to the MN ("MD" value is set to > 0) and in the case of Co-located CoA, the ordering of the extension > is: any non-authentication Extensions used only by the HA, followed > by the MN-HA AE defined in section 3.5.2 of [RFC3344] > > [Ahmad-8] > Similar comment as in 7: > " > If the GNM was initiated from the HA to the MN ("MD" value is set to > 0) and in the case of Co-located CoA, MN-HA AE MUST be the last > extension > in order to protect all other non-authentication extensions. > " > [Ahmad-End-8] Done > > > 4.3.3. Sending Generic Notification Messages > > The MN may either send a GNM to notify the FA or HA. > > If the message is sent to the FA, the source address is the MN's > address, and the destination address is the FA's address > > If the FA is the target of this notification message, then the "MD" > value is set to 3, and the ordering of the extension is: the > notification extension, followed by any non-authentication Extensions > used only by the FA, followed by The MN-FA AE defined in section > 3.5.3 of [RFC3344]. Computing Authentication Extension Value is the > same as section 3.5.1 of [RFC3344]. > > [Ahmad-9] > same as comment-8 above regarding the text of the AE order. Done, text updated. > > > ... > ... > The MN chooses the Identification field in accordance with the style > of replay protection it uses with its FA or HA. > > [Ahmad-10] > s/it uses with its FA or HA/it uses with its HA/ also remove the FA in > the below sentence. Correct, Done. > > > This is part of the > mobility security association the MN shares with its FA or HA. See > Section 7.1.1 for the method by which the MN computes the > Identification field. > > 4.3.4. Receiving Generic Notification Acknowledgement Messages > > In the case of a FA-CoA, if the MN receives this message, and the > "MD" value is set to 0, it means that the GNAM came from HA > > If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the > MN MUST check the Authenticator value in the Extension. If no MN-FA > AE is found, or if more than one MN-FA AE is found, or if the > Authenticator is invalid, the MN MUST silently discard the GNAM. > > In addition, the low-order 32 bits of the Identification field in the > GNAM MUST be compared to the low-order 32 bits of the Identification > field in the most recent GNA sent to the replying agent. > [Ahmad-11] > s/recent GNA/recent GNM/ Correct, done. > > > > if they do > not match, the GNAM MUST be silently discarded. > > If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the > HA MUST check the Authenticator value in the Extension. If no MN-HA > AE is found, or if more than one MN-HA AE is found, or if the > Authenticator is invalid, the HA MUST silently discard the GNAM. If > > [Ahmad-12] > s/the HA MUST silently/the MN MUST silently/ Done > > > > 4.4. Foreign Agent Consideration > > The FA can not only relay generic notification message between the HA > and MN, but it can also initiate a GNM to the MN or HA, and it will > depends on whether there is a binding for the MN. > > [Ahmad-13] > I suggest replacing the above paragraph as follows: > " > The FA may initiate a GNM to the MN or the HA. Additionally, the FA also > relays GNM and GNAM messages between the MN and its HA as long as there > is an active binding for the MN at the FA. > " > [Ahmad-End-13] Thanks, done. > > > 4.4.1. Receiving Generic Notification Message > > If the FA receives a GNM, and the "MD" value is set to 0, it means > that the HA is asking the FA to relay the message to the MN. If the > "MD" value is set to 1, it means that the target of the notification > is the FA. If the "MD" value is set to 2, it means that the MN is > asking the FA to relay the message to the HA. If the "MD" value is > set to 3, it means that the notification came from the MN to the FA. > > if the "MD" value is set to 0, the FA MAY check the FA-HA AE and > Authenticator value in the Extension. > [Ahmad-14] > I suggest replacing the above sentence with: > "If the "MD" value is set to 0, the FA MAY validate the FA-HA AE if > present." Thanks, done. > > > > If the FA validates the HA's > GNM, it MUST relay the GNM to the MN's home address as specified in > the Home Address field of the GNM. > > [Ahmad-15] > Why this is necessary? In this case the message is from the HA all the > way to the MN. There is a possibility that the HA MAY add some other > authentication which addresses the FA and then add the FA-HA AE to > protect these extensions. If the FA-HA AE failed authentication, it > means that the FA MUST NOT accept any information that the HA is sending > in this GNM to the FA. > > My problem is: What happened if FA-HA AE validation failed, What the FA > should do. IMO, the FA should relay the message to the MN which will > eventually validate the MN-HA AE to ensure that all information sent to > the MN is integrity protected. > [Ahmad-End-15] Your suggestion has been accepted. rewording below if the "MD" value is set to 0, the FA MAY validate the FA-HA AE if present. if the FA-HA AE is invalid, all non-authentication extensions between HA and FA MUST be removed, FA SHOULD relay the GNM to the MN's home address as specified in the Home Address field of the GNM, MN will eventually validate the MN-HA AE to ensure that all information sent to the MN is integrity protected. if the FA-HA AE is valid, FA MUST relay the GNM to the MN's home address as specified in the Home Address field of the GNM. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN. > > > The FA MUST NOT modify any of the > fields beginning with the fixed portion of the GNM through and MN-HA > > [Ahmad-16] > s/and MN-HA/the MN-HA/ Done > > > AE or other authentication extension supplied by the HA as an > authorization-enabling extension for the MN. > > > Furthermore, the FA MUST process and remove any Extensions following > the MN-HA AE, and MAY append any of its own non-authentication > Extensions of relevance to the MN if applicable, and MUST append the > MN-FA AE, if the FA shares a mobility security association with the > MN. > [Ahmad-17] > I suggest the following modification to the above sentence: > > " > Furthermore, the FA MUST process and remove any extensions following > the MN-HA AE. If the FA shares a mobility security association with > the > MN, the FA MAY append any of its own non-authentication extensions > which > of relevance to the MN. In this case, the FA MUST append the MN-FA AE > after these non-authentication extensions. > " > [Ahmad-End-17] Thanks done. > > > {Ahmad-18] > The idea here is that if the FA does not share a mobility security > association with the MN and adds a non-authentication extensions, these > extensions are not protected. If we want to allow such behavior, we need > to document that under the security section. > [Ahmad-End-18] One more sub-section has been added in security section below: 7.2. Non-authentication Extensions Handling in Foreign Agent When the FA is relaying the GNM message between the MN and the HA, and if the FA does not share a mobility security association with the MN or HA, all non-authentication extensions between MN and FA, or FA and HA are not protected. > > > > ... > ... > > Furthermore, the FA MUST process and remove any Extensions following > the MN-HA AE, and MAY append any of its own non-authentication > Extensions of relevance to the MN if applicable, and MUST append the > > [Ahmad-19] > s/MN/HA/ Done > > > MN-FA AE, if the FA shares a mobility security association with the > MN. > > [Ahmad-20] > This message is sent from the MN to the HA. NO? I believe the above > needs to be updated as follows: > " > FA-HA AE, if the FA shares a mobility security association with the > HA. > " > [Ahmad-End-20] Thanks, done. > > > If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the > FA MUST check the Authenticator value in the Extension which is the > same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or > if more than one MN-FA AE is found, or if the Authenticator is > invalid, the FA MUST reject the GNM and SHOULD send a GNAM to the HA > > [Ahmad-21] > s/to the HA/to the MN. Done > > > > 4.4.2. Sending Generic Notification Acknowledgement Messages > > The FA may need to either relay a GNAM message between the MN and the > HA or send one as a response to a GNM messsage that was sent to it. > In both cases, the GNAM message is defined as follows: > The source address is the FA address, the destination address is HA's > or FA's address. > > [Ahmad-22] > s/or FA's address/or MN home address/ Done > > > The Code field of the GNAM is chosen in accordance with the rules > specified in the section 4.2. When replying to an accepted > notification, a FA SHOULD respond with Code 0. > > There are a number of reasons the FA might reject a notification such > as administrative in nature returning a GNAM with a code of 65, > similarly and provides the Code value 64 or 66 for the unspecified > reason and insufficent resources. > > If the FA is only relaying this message to the HA, the FA it MUST NOT > > [Ahmad-23] > s/the FA it MUST NOT/the FA MUST NOT/ Done > > > modify any of the fields beginning with the fixed portion of the > Generic Notification Acknowledgement through and including the MN-HA > AE or other authentication extension supplied by the HA as an > > [Ahmad-24] > s/HA/MN/ > I assume (as per the text above) this message is sent from the MN to the > HA. Correct, Done > > > authorization-enabling extension for the MN. Furthermore, the > foreign agent MUST process and remove any Extensions following the > MN-HA AE and MAY append any of its own non-authentication Extensions > of relevance to the HA, if applicable. It MUST also append the FA-HA > AE, if the FA shares a mobility security association with the HA. > > [Ahmad-25] > same comment as MN-FA. FA adds non-authentication extensions ONLY if it > shares a mobility security association with the HA. Done > > > If the notification message is from the HA to the FA then the "MD" > value is set to 5 and the ordering of the extension is: any non- > authentication Extensions used only by the HA, followed by The FA-HA > > [Ahmad-26] > s/HA/FA/ > AE defined in section 3.5.4 of [RFC3344]. Done > > > If the notification message is from the MN to the FA then the "MD" > value is set to 4 and the ordering of the extension is: any non- > authentication Extensions used only by the HA, followed by The MN-FA > > [Ahmad-27] > s/HA/FA/ > AE defined in section 3.5.3 of [RFC3344]. Done > > > > Finally, I did not review the HA section. If you have time, I would say thanks again if you could help to review HA section. Thanks for your detail review. Please feel free to let me know if you are fine with those revisions. Best regards, -Hui > > Regards, > Ahmad > > --000e0cd2301a9508360462f00d92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Ahmad
 
I appreciate your review again, all your 27 comments are adopted,
thanks for your detail comments, inline each below please.
2009/2/12 Ahmad Muhanna <amuhanna@nortel.com>
Hi Hui,

I reviewed the ne= w revision and I have few comments on the latest
version of the MIP GNM = draft. Please see below:

Regards,
Ahmad

++++++++++++++++

4.1.  Generic Not= ification Message

  A generic notification message is sent by a= mobility agent to inform
  another mobility agent, or a MN, of MIP= -related information such as
  vendor specific extensions [RFC3115] and generic string
  no= tification [RFC4917].  These messages must use the same IP and UDP
=   headers as any previous Registration Request or Reply message to the=
  same entity.  This would support NAT traversal and ensure s= ame
  security association used for GNM/GNAM and RRQ/RRP.  The generi= c
  notification message is defined as follows:

  IP Fi= elds:

    Source Address         Same = as the last Registration Reply/Request
         = ;                  message rec= eived.

    Destination Address    Same as the last Registr= ation Reply/Request
              &nb= sp;            message.

  UDP Fie= lds:

    Source Port           &n= bsp;Same as the last Registration Reply/Request
      &nb= sp;                    me= ssage.

    Destination Port       Same as the last Re= gistration Reply/Request
             = ;              message.

[Ahmad-1]=
Are these information saved in the mobile node BCE? I did not check
= RFC3344 lately but just in case, if these IP addresses are not currently save in the MN binding, then it needs to be added.

[Ahmad-end-1]
Your recollection is correct, those information are not saved in BCE, = so I add
one paragraph below
   The MN, FA, and HA MUST maintain the following informatio= n:
      - the IP source address of the Registr= ation Request/Reply
      - the IP destination = address of the Registration Request/Reply
     = - the UDP source port of the Registration Request/Reply
      - the UDP destination port of the Registrati= on Request/Reply
 

..........

     The fixed portion of the Generic Notific= ation Message is followed
     by one or more extensions which may be used with this m= essage, and
     by one or more authentication extensions= (as defined in Section
     3.5 of [RFC3344].  This= document mandate the MN-HA AE when this
     message is = sent between the MN and the HA, others are optional.
     This document also mandate the MN-FA AE when this messa= ge is sent
     between the MN and the FA, others are opt= ional.  This document
     mandate the FA-HA AE when= this message is sent between the FA and
     the HA, oth= ers are optional.  This could be judged based on "MD"
     value.).  See Sections 3.6.1.3 and 3.7.2.2 of [RFC= 3344] for
     information on the relative order in which= different extensions,
     when present, must be placed = in a Generic Notification Message.

[Ahmad-2]
May be the text here is not very accurate. because it gives the
impressi= on that RFC3344 talks about the order of extension in the GNM
which is N= OT.

What about replacing the last sentence as follows (Just a sugges= tion):

"
See Sections 3.6.1.3 and 3.7.2.2 in [RFC3344] for the rules o= n the order
of these extensions as they appear in Mobile IPv4 RRQ and RR= P messages.
The same rules are applicable to GNM and GNAM.
"

[Ahmad-End-2]
Your suggestion has been adopted in the updated version. thanks,<= /div>
 


4.2= .  Generic Notification Acknowledgment Message

...
...
  Identification

     A 64-bit number, constructed by the sender, used fo= r matching
     Generic Notification with Generic Notific= ation Acknowledgement,
     and for protecting against re= play attacks of notification
     messages.  Here is= the same as Sections 5.4 and 5.7 of [RFC3344].
     Timestamps is mandatory.

[Ahmad-3]
The text h= ere needs to be updated. This seems a cut and paste from the
GNM. I thou= ght that the GNAM needs to copy this field from the GNM. I
understand th= at in case of out of synch message, the receiver will
include its timestamp in the upper 32 bits, but that is covered later inthe draft. This should cover the successful case. IMO.
[Ahmad-End-3]
I updated the text here below:
   Identification

      if t= he timestamp of the GNM is valid, the receiver copies the
  &n= bsp;   entire Identification field into the GNAM it returns the G= NAM
      message to the sender. if the timesta= mp of the GNM is not valid,
      the receiver copies only the low-order 32 bi= ts into the GNAM, and
      supplies the high-o= rder 32 bits from its own time of day.  Both
   &nbs= p;  GNM and GNAM mandate Timestamps.
 


&nb= sp; Extensions

     The fixed portion of the generic = notification acknowledgement
     message is followed by one or more of the Extensions li= sted in
     Section 3.5 of [RFC3344].  See Sections= 3.6.1.3 and 3.7.2.2 of
     [RFC3344] for information on= the relative order in which different
     extensions, w= hen present, MUST be placed in a Generic Notification
     message.

[Ahmad-4]
Same comment No. 2 above. = Text could be improved here too.

[Ahmad-End-4]
Updated below
   Extensions

      The fixe= d portion of the GNAM is followed by one or more of the
  &nbs= p;   Extensions listed in Section 3.5 of [RFC3344].  See Sec= tions
      3.6.1.3 and 3.7.2.2 of [RFC3344] fo= r the rules on the order of
      these extensions as they appear in Mobile IP= v4 RRQ and RRP
      messages.  The same r= ules are applicable to GNM and GNAM.

 


4.3= .1.  Receiving Generic Notification Messages

  The MN MUST= check for the presence of an authorization-enabling
  extension, and perform the indicated authentication.  Exactly o= ne
  authorization-enabling extension MUST be present in the Regist= ration
  Request,

[Ahmad-5]
s/Registration Request/Generi= c Notification Message/

[Ahmad-End-5]
Done
 


  If this notification message came from the HA, relayed by the FA, o= r
  is a Co-located CoA, the MN-HA AE MUST be checked and the MN MU= ST
  check the Authenticator value in the Extension.  If no MN-HA AE= is
  found, or if more than one MN-HA AE is found, or if the Authe= nticator
  is invalid, the MN MUST reject the GNM and SHOULD send a= GNAM to the
  initiator with Code 196, including an Identification field computed<= br>  in accordance with the rules specified in Section 7.1.1.  Th= e MN MUST
  do no further processing with such a notification, thou= gh it SHOULD
  log the error as a security exception.  If the MN accepts the H= A's
  GNM, it will process it according to the specific rules f= or that
  extension.  After that, the MN MAY reply with a GNAM= with Code 0 back
  to the HA based on the "A" flag in the GNM.

[Ahmad-= 6]
If I recall correctly, I believe in the case of MN-HA AE validationfailure, RFC3344bis mention that the HA MAY send a RRP back. If that in the case of RRQ/RRP, I am wondering why in the case of Notification, we
= need a stronger mandate?
[Ahmad-End-6]
You are correct here, RFC 3344bis specify MAY,
here MAY also been updated.
 


4.3= .2.  Sending Generic Notification Acknowledgement Message

 = ; Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply
  with a GNAM based on the "A" flag in the GNM as follows:
  If the GNM was initiated from the FA to the MN ("MD"= value is set to
  4), the ordering of the extension is: any non-au= thentication
  Extensions used only by the FA, followed by The MN-FA AE defined in<= br>  section 3.5.3 of [RFC3344].

[Ahmad-7]
Well, the message= is between the MN and the FA and there is NO other
node in between exam= ine the GNAM, I suggest modifying the above text as
follows:
"
  If the GNM was initiated from the FA to the MN= ("MD" value is set to
  0), MN-FA AE MUST be the last ex= tension in order to protect all other
non-
  authentication exte= nsions as defined in section 3.5.3 of [RFC3344].
"
[Ahmad-End-7]
Done
 


...=
...
  There are a number of reasons the MN might reject a notif= ication such
  as administrative in nature returning a GNAM with a code of 193,
=   similarly and provides the Code value 192 or 194 for the unspecified=
  reason and insufficent resources.

[Ahmad]
s/insufficen= t/insufficient
Done
 


&nb= sp; If the GNM was initiated from the HA to the MN ("MD" value is= set to
  0) and in the case of Co-located CoA, the ordering of the extension<= br>  is: any non-authentication Extensions used only by the HA, follow= ed
  by the MN-HA AE defined in section 3.5.2 of [RFC3344]

[= Ahmad-8]
Similar comment as in 7:
"
  If the GNM was initiated from = the HA to the MN ("MD" value is set to
  0) and in the ca= se of Co-located CoA, MN-HA AE MUST be the last
extension
  in o= rder to protect all other non-authentication extensions.
"
[Ahmad-End-8]
Done
 


4.3= .3.  Sending Generic Notification Messages

  The MN may ei= ther send a GNM to notify the FA or HA.

  If the message is sent to the FA, the source address is the MN&#= 39;s
  address, and the destination address is the FA's address=

  If the FA is the target of this notification message, then t= he "MD"
  value is set to 3, and the ordering of the extension is: the
&nbs= p; notification extension, followed by any non-authentication Extensions  used only by the FA, followed by The MN-FA AE defined in section  3.5.3 of [RFC3344].  Computing Authentication Extension Value = is the
  same as section 3.5.1 of [RFC3344].

[Ahmad-9]
same as comm= ent-8 above regarding the text of the AE order.
Done, text updated.
 


...=
...
  The MN chooses the Identification field in accordance wit= h the style
  of replay protection it uses with its FA or HA.

[Ahmad-10]s/it uses with its FA or HA/it uses with its HA/ also remove the FA in
= the below sentence.
Correct, Done.
 


&nb= sp; This is part of the
  mobility security association the MN shar= es with its FA or HA.  See
  Section 7.1.1 for the method by which the MN computes the
  = Identification field.

4.3.4.  Receiving Generic Notification Ac= knowledgement Messages

  In the case of a FA-CoA, if the MN rec= eives this message, and the
  "MD" value is set to 0, it means that the GNAM came from H= A

  If the "MD" value is set to 4, the MN-FA AE MUST = be checked, and the
  MN MUST check the Authenticator value in the = Extension.  If no MN-FA
  AE is found, or if more than one MN-FA AE is found, or if the
&nb= sp; Authenticator is invalid, the MN MUST silently discard the GNAM.
  In addition, the low-order 32 bits of the Identification field in t= he
  GNAM MUST be compared to the low-order 32 bits of the Identifi= cation
  field in the most recent GNA sent to the replying agent.
[Ahmad-1= 1]
s/recent GNA/recent GNM/
Correct, done.
 


  if they do
  not match, the GNAM MUST be silently discarded= .

  If the "MD" value is set to 0, the MN-HA AE MUST = be checked, and the
  HA MUST check the Authenticator value in the Extension.  If no = MN-HA
  AE is found, or if more than one MN-HA AE is found, or if t= he
  Authenticator is invalid, the HA MUST silently discard the GNA= M.  If

[Ahmad-12]
s/the HA MUST silently/the MN MUST silently/
Done
 


4.4.  Foreign Agent Consideration

  The FA can not only r= elay generic notification message between the HA
  and MN, but it can also initiate a GNM to the MN or HA, and it will<= br>  depends on whether there is a binding for the MN.

[Ahmad-1= 3]
I suggest replacing the above paragraph as follows:
"
The = FA may initiate a GNM to the MN or the HA. Additionally, the FA also
relays GNM and GNAM messages between the MN and its HA as long as there
= is an active binding for the MN at the FA.
"
[Ahmad-End-13]
Thanks, done.
 


4.4= .1.  Receiving Generic Notification Message

  If the FA re= ceives a GNM, and the "MD" value is set to 0, it means
  that the HA is asking the FA to relay the message to the MN.  I= f the
  "MD" value is set to 1, it means that the target = of the notification
  is the FA.  If the "MD" value = is set to 2, it means that the MN is
  asking the FA to relay the message to the HA.  If the "MD&= quot; value is
  set to 3, it means that the notification came from= the MN to the FA.

  if the "MD" value is set to 0, t= he FA MAY check the FA-HA AE and
  Authenticator value in the Extension.
[Ahmad-14]
I suggest rep= lacing the above sentence with:
"If the "MD" value is set= to 0, the FA MAY validate the FA-HA AE if
present."
Thanks, done.
 


  If the FA validates the HA's
  GNM, it MUST relay the G= NM to the MN's home address as specified in
  the Home Address field of the GNM.

[Ahmad-15]
Why this is = necessary? In this case the message is from the HA all the
way to the MN= . There is a possibility that the HA MAY add some other
authentication w= hich addresses the FA and then add the FA-HA AE to
protect these extensions. If the FA-HA AE failed authentication, it
mean= s that the FA MUST NOT accept any information that the HA is sending
in = this GNM to the FA.

My problem is: What happened if FA-HA AE validat= ion failed, What the FA
should do. IMO, the FA should relay the message to the MN which will
eve= ntually validate the MN-HA AE to ensure that all information sent to
the= MN is integrity protected.
[Ahmad-End-15]
Your suggestion has been accepted. rewording below
   if the "MD" value is set to 0, the FA MAY valid= ate the FA-HA AE if
   present. if the FA-HA AE is invalid, al= l non-authentication
   extensions between HA and FA MUST be r= emoved, FA SHOULD relay the GNM
   to the MN's home address as specified in the Home Address = field of
   the GNM, MN will eventually validate the MN-HA AE = to ensure that all
   information sent to the MN is integrity = protected. if the FA-HA AE is
   valid, FA MUST relay the GNM to the MN's home address as s= pecified in
   the Home Address field of the GNM.  The FA= MUST NOT modify any of the
   fields beginning with the fixed= portion of the GNM through the MN-HA
   AE or other authentication extension supplied by the HA as an<= br>   authorization-enabling extension for the MN.
 


&nb= sp; The FA MUST NOT modify any of the
  fields beginning with the f= ixed portion of the GNM through and MN-HA

[Ahmad-16]
s/and MN-HA/the MN-HA/
Done
 


&nb= sp; AE or other authentication extension supplied by the HA as an
 = authorization-enabling extension for the MN.


  Furthermore, the FA MUST process and remove any Extensions f= ollowing
  the MN-HA AE, and MAY append any of its own non-authenti= cation
  Extensions of relevance to the MN if applicable, and MUST = append the
  MN-FA AE, if the FA shares a mobility security association with the<= br>  MN.
[Ahmad-17]
I suggest the following modification to the = above sentence:

"
  Furthermore, the FA MUST process an= d remove any extensions following
  the MN-HA AE. If the FA shares a mobility security association with<= br>the
  MN, the FA MAY append any of its own non-authentication ex= tensions
which
  of relevance to the MN. In this case, the FA MU= ST append the MN-FA AE
after these non-authentication extensions.
"
[Ahmad-End-17]
Thanks done.


{Ah= mad-18]
The idea here is that if the FA does not share a mobility securi= ty
association with the MN and adds a non-authentication extensions, these
= extensions are not protected. If we want to allow such behavior, we needto document that under the security section.
[Ahmad-End-18]
One more sub-section has been added in security section below:
7.2.  Non-authentication Extensions Handling in Foreign Agent
=
   When the FA is relaying the GNM message between the MN and= the HA,
   and if the FA does not share a mobility security a= ssociation with the
   MN or HA, all non-authentication extensions between MN and FA,= or FA
   and HA are not protected.
 


...
...

  Furthermore, the FA MUST process and remove any E= xtensions following
  the MN-HA AE, and MAY append any of its own non-authentication
&n= bsp; Extensions of relevance to the MN if applicable, and MUST append the
[Ahmad-19]
s/MN/HA/
Done
 


&nb= sp; MN-FA AE, if the FA shares a mobility security association with the
=   MN.

[Ahmad-20]
This message is sent from the MN to the HA. NO? I believe= the above
needs to be updated as follows:
"
  FA-HA AE,= if the FA shares a mobility security association with the
  HA."
[Ahmad-End-20]
Thanks, done.
 


&nb= sp; If the "MD" value is set to 3, the MN-FA AE MUST be checked, = and the
  FA MUST check the Authenticator value in the Extension which is the<= br>  same as the section 3.7.2.1 of RFC 3344.  If no MN-FA AE is = found, or
  if more than one MN-FA AE is found, or if the Authentic= ator is
  invalid, the FA MUST reject the GNM and SHOULD send a GNA= M to the HA

[Ahmad-21]
s/to the HA/to the MN.
Done
 


4.4.2.  Sending Generic Notification Acknowledgement Messages

=   The FA may need to either relay a GNAM message between the MN and th= e
  HA or send one as a response to a GNM messsage that was sent to it.<= br>  In both cases, the GNAM message is defined as follows:
  = The source address is the FA address, the destination address is HA's  or FA's address.

[Ahmad-22]
s/or FA's address/or MN home address/
Done
 


&nb= sp; The Code field of the GNAM is chosen in accordance with the rules
&n= bsp; specified in the section 4.2.  When replying to an accepted
  notification, a FA SHOULD respond with Code 0.

  There a= re a number of reasons the FA might reject a notification such
  as= administrative in nature returning a GNAM with a code of 65,
  sim= ilarly and provides the Code value 64 or 66 for the unspecified
  reason and insufficent resources.

  If the FA is only re= laying this message to the HA, the FA it MUST NOT

[Ahmad-23]
s/th= e FA it MUST NOT/the FA MUST NOT/
Done
 


&nb= sp; modify any of the fields beginning with the fixed portion of the
&nb= sp; Generic Notification Acknowledgement through and including the MN-HA   AE or other authentication extension supplied by the HA as an
[Ahmad-24]
s/HA/MN/
I assume (as per the text above) this message is= sent from the MN to the
HA.
Correct, Done
 


&nb= sp; authorization-enabling extension for the MN.  Furthermore, the
=   foreign agent MUST process and remove any Extensions following the   MN-HA AE and MAY append any of its own non-authentication Extensions=
  of relevance to the HA, if applicable.  It MUST also append= the FA-HA
  AE, if the FA shares a mobility security association w= ith the HA.

[Ahmad-25]
same comment as MN-FA. FA adds non-authentication extensions = ONLY if it
shares a mobility security association with the HA.
Done
 


&nb= sp; If the notification message is from the HA to the FA then the "MD&= quot;
  value is set to 5 and the ordering of the extension is: any non-
=   authentication Extensions used only by the HA, followed by The FA-HA=

[Ahmad-26]
s/HA/FA/
  AE defined in section 3.5.4 of [RF= C3344].
Done
 


&nb= sp; If the notification message is from the MN to the FA then the "MD&= quot;
  value is set to 4 and the ordering of the extension is: any non-
=   authentication Extensions used only by the HA, followed by The MN-FA=

[Ahmad-27]
s/HA/FA/
  AE defined in section 3.5.3 of [RF= C3344].
Done
 


Finally, I did not review the HA section.
If you have time, I would say thanks again if you could help to review= HA section.
 
Thanks for your detail review.
Please feel free to let me know if you are fine with those revisions.<= /div>
 
Best regards,
 
-Hui
 

Regards= ,
Ahmad


--000e0cd2301a9508360462f00d92-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6633A6B03; Wed, 4 Feb 2009 03:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SORTED_RECIPS=1.125] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clLaYIuxpMuv; Wed, 4 Feb 2009 03:44:43 -0800 (PST) Received: from mail2.di.uniroma1.it (mail2.di.uniroma1.it [151.100.17.20]) by core3.amsl.com (Postfix) with ESMTP id 33E1B3A69C3; Wed, 4 Feb 2009 03:44:42 -0800 (PST) Received: from [151.100.17.90] (maselli.di.uniroma1.it [151.100.17.90]) by mail2.di.uniroma1.it (Postfix) with ESMTP id B29C12E02B; Wed, 4 Feb 2009 12:44:53 +0100 (CET) Message-ID: <49897F8E.5040508@di.uniroma1.it> Date: Wed, 04 Feb 2009 12:44:14 +0100 From: Gaia Maselli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 15 Feb 2009 11:05:45 -0800 Cc: thad@cc.gatech.edu, wireless@lists.samba.org, mycolleagues@grid.lrg.ufsc.br, smac-users@mailman.isi.edu, p2prg@ietf.org, wisents@prz.tu-berlin.de Subject: [Mip4] CFP: IEEE Workshop on Wireless Mesh Networks (WiMesh) 2009 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:44:44 -0000 [Apologies for multiple copies of this announcement] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Fourth IEEE Workshop on Wireless Mesh Networks (WiMesh) Rome, Italy, June 22, 2009 co-located with IEEE SECON 2009 http://www.ieee-secon.org/wimesh/wimesh-index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important dates: Abstract registration: March 21, 2009 Paper submission: March 27, 2009 Notification: April 30, 2009 Camera Ready: May 9, 2009 Call for Papers Wireless mesh networking is attracting significant interest as a low-cost networking platform to support ubiquitous broadband access in the context of home networking, enterprise networking, or a larger, community or metro-scale networking. Many universities, as well as industrial labs have on-going research projects on various aspects of mesh networking, including architectures, protocols, services and applications. Several startups are building mesh networking platforms and deploying services. WiMesh 2009 will be a one-day forum for meeting, presenting and discussing core technical issues and current research problems in wireless mesh networking. Starting from 2008, WiMesh includes in the program papers submitted through an open Call for Papers. Given its one-day, highly interactive format, papers presenting innovative ideas, although possibly not fully mature, are very welcome. Papers must be formatted according to IEEE conference proceedings style (see here for detailed instructions and styles), and must not exceed 6 pages . Topics include, but are not limited to: * Experiences with the deployment of wireless mesh networks * Wireless mesh network performance * Unique challenges found in wireless mesh networks * Co-existence of wireless mesh networks with existing 802.11 infrastructure and solutions * Experimental validation of wireless mesh network algorithms * Architectures, protocols, and algorithms for wireless mesh networks * Localization and mobility in wireless mesh networks * Security, privacy, and trustworthiness * Integration of wireless mesh networks with other wired and wireless networks * Protocols exploiting novel technologies such as UWB, MIMO, directional antennas, and software radios * Wireless mesh network testbeds Workshop chairs: Paolo Santi, Istituto di Informatica e Telematica del CNR, Pisa, Italy Karthik Sundaresan, NEC Labs USA, Princeton Technical Program Committee (partial list) ¶ * Douglas Blough, Georgia Tech, US * Christian Bonnet, EURECOM, France * Ranveer Chandra, Microsoft Research, US * Samir Das, Stony Brook Univ., US * Stephan Eidenbenz, Los Alamos National Labs, US * SJ Lee, HP Labs, US * Luciano Lenzini, Univ. of Pisa, Italy * C. Lindemann, Univ. Leipzig, Germany * Thyaga Nandagopal, Alcatel-Lucent, US * Xavier Perez Costa, NEC Labs, Germany * Ram Ramanathan, BBN Technologies, US * Michele Zorzi, Univ. of Padova, Italy Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4842B3A6A99; Fri, 20 Feb 2009 03:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVZMEBTJMGKD; Fri, 20 Feb 2009 03:02:37 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 524033A68C7; Fri, 20 Feb 2009 03:02:36 -0800 (PST) Received: from tmnt04.transmode.se (tmnt04.transmode.se [192.168.46.15]) by gw1.transmode.se (Postfix) with ESMTP id A163B611C8; Fri, 20 Feb 2009 12:02:48 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 12:02:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mib root ? Thread-Index: AcmTSsN5w1e+QuqfQ66TrSbvoWg8yw== From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: Cc: mip4@ietf.org Subject: [Mip4] mib root ? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:02:38 -0000 Hi, In the mip4 group we are adding mib support for the RFC3519 "Mobile IP = Traversal of Network Address Translation (NAT) Devices" to the mip mib. = We decided not to extend the RFC2006bis with it, but instead write a = extension mib, = http://tools.ietf.org/html/draft-ietf-mip4-udptunnel-mib-01 The question is where this mib is best rooted. The intention was to root = it under the assigned mipMIB OID { mib-2 44 } and then hand over the = administration of that OID to IANA. Somewhat like it was done in MPLS , = ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) in = http://www.iana.org/assignments/smi-numbers But this seams not to be the most common way to take, more common is to = root also extensions of existing wg mibs directly under mib-2.=20 The questions are;=20 - What are the advantages and disadvantages with the two approaches ?=20 - Which is your recommendation (Or is there even a preferred third = variant) ?=20 Best regards /// Hasse Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF47028C146 for ; Fri, 20 Feb 2009 08:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN6Rr1ZyO7LP for ; Fri, 20 Feb 2009 08:49:40 -0800 (PST) Received: from n62a.bullet.mail.sp1.yahoo.com (n62a.bullet.mail.sp1.yahoo.com [98.136.45.9]) by core3.amsl.com (Postfix) with SMTP id 566F73A6949 for ; Fri, 20 Feb 2009 08:49:22 -0800 (PST) Received: from [69.147.84.145] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 20 Feb 2009 16:49:36 -0000 Received: from [69.147.65.162] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 20 Feb 2009 16:49:36 -0000 Received: from [127.0.0.1] by omp407.mail.sp1.yahoo.com with NNFMP; 20 Feb 2009 16:49:36 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 634421.50984.bm@omp407.mail.sp1.yahoo.com Received: (qmail 45015 invoked by uid 60001); 20 Feb 2009 16:49:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=p2GQ+fIzwsmX62X2VAv65jz9Fv2ouvLGdqQOaeFrCXUZaaIIy/umxO6OTknuU/SoKV3wxIAcID6dWSZGIKGbuzGqwHvn/TMz+jeYtIUGzpKdt0uxkYxWbx9EiqB/gQb+fWFHhLlcMohwPdQuT6TOSSK6sBD3ChMCT3aJuikxugs=; X-YMail-OSG: _LNeiFoVM1lkxz0rywbSi4bvmuSapJehCt2po7GmMz_m4eqnAyD8UkJpzDj9gucMA_HUSyJH1LfNweskEWjYuywCm8e0uOrx87n96ykN3_EECgjKWRmg9looF9rV6ZxhE7JCz.TsnxqchHlMcJG5_9KZbS09dPpSXpWMtoXHdWhsQxgcFf.4S5UwQhCOrsJ3rTpb75tgLw-- Received: from [67.233.188.239] by web45902.mail.sp1.yahoo.com via HTTP; Fri, 20 Feb 2009 08:49:36 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Fri, 20 Feb 2009 08:49:36 -0800 (PST) From: John Edward To: mip4@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-685724051-1235148576=:44941" Message-ID: <547377.44941.qm@web45902.mail.sp1.yahoo.com> Subject: [Mip4] Draft paper submission deadline extended: HPCNCS-09 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:49:41 -0000 --0-685724051-1235148576=:44941 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Draft paper submission deadline extended: HPCNCS-09 =A0 The deadline for draft paper submission at the 2009 International Conferenc= e on High Performance Computing, Networking and Communication Systems (HPCN= CS-09) (website: http://www.PromoteResearch.org ) is extended due to numero= us requests from the authors. The conference will be held during July 13-16= 2009 in Orlando, FL, USA. We invite draft paper submissions. The conferenc= e will take place at the same time and venue where several other internatio= nal conferences are taking place. The other conferences include: =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Artificial Intellig= ence and Pattern Recognition (AIPR-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Automation, Robotic= s and Control Systems (ARCS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Bioinformatics, Com= putational Biology, Genomics and Chemoinformatics (BCBGC-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Enterprise Informat= ion Systems and Web Technologies (EISWT-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Information Securit= y and Privacy (ISP-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Recent Advances in = Information Technology and Applications (RAITA-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Software Engineerin= g Theory and Practice (SETP-09)=20 =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theory and Applicat= ions of Computational Science (TACS-09) =B7=A0=A0=A0=A0=A0=A0=A0=A0 International Conference on Theoretical and Mat= hematical Foundations of Computer Science (TMFCS-09) =A0 The website http://www.PromoteResearch.org contains more details. =A0 Sincerely John=A0 Edward Publicity committee=0A=0A=0A --0-685724051-1235148576=:44941 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Draft paper submission deadline extend= ed: HPCNCS-09

 

The deadline for draft paper submission at the 2009 International Conference on High Performance Computing, Networki= ng and Communication Systems (HPCNCS-09) (website: http://www.PromoteResearch.or= g ) is extended due to numerous requests= from the authors. The conference will be held during July 13-16 2009 in Or= lando, FL, USA. We invite draft paper submissions. The conference will take place at the same time and ven= ue where several other international conferences are taking place. The othe= r conferences include:

=B7         <= /FONT>

=B7         =B7         =B7         =B7         =B7         =B7         =B7         =B7          

The website http://www.PromoteResearch.org<= SPAN style=3D"mso-bookmark: OLE_LINK4"> contains more details.

 

Sincerely

John  Edward<= /FONT>

Publicity committee


=0A= =0A --0-685724051-1235148576=:44941-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65963A6AC3; Sun, 22 Feb 2009 06:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQckgJfeXo7Y; Sun, 22 Feb 2009 06:16:21 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 88BE43A6AB4; Sun, 22 Feb 2009 06:16:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,249,1233550800"; d="scan'208";a="153107265" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Feb 2009 09:16:37 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Feb 2009 09:16:37 -0500 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 Date: Sun, 22 Feb 2009 15:16:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IETFMIBS] mib root ? Thread-Index: AcmTSsN5w1e+QuqfQ66TrSbvoWg8ywBrB1Mg References: From: "Romascanu, Dan (Dan)" To: =?iso-8859-1?Q?Hans_Sj=F6strand?= , X-Mailman-Approved-At: Sun, 22 Feb 2009 07:15:00 -0800 Cc: mip4@ietf.org Subject: Re: [Mip4] [IETFMIBS] mib root ? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 14:16:23 -0000 Hi Hasse, As you are undertaking the task of writing a new MIB module we strongly = recommend that you read carefully RFC 4181 and try to implement as much = of its recommendations.=20 In section 4.5 of RFC 4181 you will find the following text:=20 - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. So the recommendation in RFC 4181 is for direct allocation under mib-2 = (this is not a media specific module). Some of the reasons for this = recommendation are simplifying the IANA task, creating a standard layout = for management applications to work with and not delegating such = allocations for future work in the Working Groups which could lead to = different kinds of mistakes or inconsistencies.=20 My recommendation is to follow this unless you plan to revise the whole = mipMIB.=20 Other recommendations in RFC 4181 are also worth following.=20 I hope this helps.=20 Regards, Dan > -----Original Message----- > From: ietfmibs-bounces@ietf.org=20 > [mailto:ietfmibs-bounces@ietf.org] On Behalf Of Hans Sj?strand > Sent: Friday, February 20, 2009 1:03 PM > To: ietfmibs@ietf.org > Cc: mip4@ietf.org > Subject: [IETFMIBS] mib root ? >=20 > Hi, >=20 > In the mip4 group we are adding mib support for the RFC3519=20 > "Mobile IP Traversal of Network Address Translation (NAT)=20 > Devices" to the mip mib. We decided not to extend the=20 > RFC2006bis with it, but instead write a extension mib,=20 > http://tools.ietf.org/html/draft-ietf-mip4-udptunnel-mib-01 >=20 > The question is where this mib is best rooted. The intention=20 > was to root it under the assigned mipMIB OID { mib-2 44 } and=20 > then hand over the administration of that OID to IANA.=20 > Somewhat like it was done in MPLS ,=20 > ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) in=20 > http://www.iana.org/assignments/smi-numbers >=20 > But this seams not to be the most common way to take, more=20 > common is to root also extensions of existing wg mibs=20 > directly under mib-2.=20 >=20 > The questions are; > - What are the advantages and disadvantages with the two approaches ?=20 > - Which is your recommendation (Or is there even a preferred=20 > third variant) ?=20 >=20 > Best regards > /// Hasse >=20 > _______________________________________________ > IETFMIBS mailing list > IETFMIBS@ietf.org > https://www.ietf.org/mailman/listinfo/ietfmibs >=20 Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96503A6992 for ; Sun, 22 Feb 2009 21:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW2uh3qSt0r6 for ; Sun, 22 Feb 2009 21:05:35 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id D97EB3A6908 for ; Sun, 22 Feb 2009 21:05:34 -0800 (PST) Received: by gxk22 with SMTP id 22so4797147gxk.13 for ; Sun, 22 Feb 2009 21:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=tb77PEHJ8BL6s1jw3Gi/P/CIT3PhjKj0GHQKmI9I9L0=; b=TzbJUK+NIJLJwOYLMLt4L5+WEm4T9o1hBaccP/vV2XFC28nPD3BocLvqLyfJQOq/cD K18/pgrTScFMhVzXWYdaIGI+x6QENwbwvyV46/yy8vUN8+Gn/HeEsz/kyCudX+wfZ59G kk9ck4yoX4BAtV6LY2ZmixqfJLtdrgdK+GOg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XBlxookvLrJR5x8qUFhDUpEpbE6HSIOjuPB7U02JE0spwT759NChJ06CF8yuGz/5Eo trZhxX2ywshLvtNt/VCdQnlrgwebDMBplwb4XH3EQcgFeHjGMMNnN1xTR0aHhAUggWIH 4ouj/GVnTDpX8VEwBg9sP/Cy+FKfadnToTL18= MIME-Version: 1.0 Received: by 10.100.96.9 with SMTP id t9mr3483166anb.109.1235365551450; Sun, 22 Feb 2009 21:05:51 -0800 (PST) In-Reply-To: <022101c99563$ab6b59d0$2302600a@hitachichina.com> References: <022101c99563$ab6b59d0$2302600a@hitachichina.com> Date: Mon, 23 Feb 2009 13:05:51 +0800 Message-ID: <4c5c7a6d0902222105u403d0f65uc57ada9e8d411464@mail.gmail.com> From: Peny Yang To: mip4@ietf.org Content-Type: multipart/mixed; boundary=0016e644cdd6dcac1f04638ef44b Subject: [Mip4] Fwd: I-D Action:draft-deng-mip4-host-configuration-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 05:05:35 -0000 --0016e644cdd6dcac1f04638ef44b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all: The draft of "DHCP Based Configuration of Mobile Node from Home Network" has been updated to 01 version. Compared with 00 version, another case is added, wherein HA has NO DHCP-relay function and DHCP server is unknown in client. DHCPINFORM/DHCPARCK are used in this case as well. And, some small items are modified for clarification. Please review the draft. Comments are more than welcome. Thanks Peny > >-----Original Message----- > >From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > >On Behalf Of Internet-Drafts@ietf.org > >Sent: Monday, February 23, 2009 11:00 AM > >To: i-d-announce@ietf.org > >Subject: I-D Action:draft-deng-mip4-host-configuration-01.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : DHCP Based Configuration of Mobile Node from Home > >Network > > Author(s) : H. Deng, P. Yang > > Filename : draft-deng-mip4-host-configuration-01.txt > > Pages : 29 > > Date : 2009-02-22 > > > >This document describes the mechanism for providing the host > >configuration parameters needed for network service from home network > >based on DHCPINFORM. DHCPINFORM message has been widely used by > >client to obtain other configuration information and could be sent to > >local broadcast address or server unicast address. Mobile IP > >specification could support DHCPINFORM broadcast or unicast message > >straightfully without any revision. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-deng-mip4-host-configuration- 01 > >.txt > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. --0016e644cdd6dcac1f04638ef44b Content-Type: text/plain; charset=US-ASCII; name="ATT00543.txt" Content-Disposition: attachment; filename="ATT00543.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 0.2 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQK --0016e644cdd6dcac1f04638ef44b-- Return-Path: X-Original-To: mip4@ietf.org Delivered-To: mip4@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AF9EF3A687E; Mon, 23 Feb 2009 03:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090223114501.AF9EF3A687E@core3.amsl.com> Date: Mon, 23 Feb 2009 03:45:01 -0800 (PST) Cc: mip4@ietf.org Subject: [Mip4] I-D Action:draft-ietf-mip4-udptunnel-mib-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : The Definitions of Managed Objects for Mobile IP UDP Tunneling Author(s) : H. Sjostrand Filename : draft-ietf-mip4-udptunnel-mib-02.txt Pages : 14 Date : 2009-02-23 This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of Network Address Translation (NAT) Devices are used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-udptunnel-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mip4-udptunnel-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-23033725.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: mip4@core3.amsl.com Delivered-To: mip4@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E033A6AC7 for ; Wed, 25 Feb 2009 08:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT5dmKWjPSAl for ; Wed, 25 Feb 2009 08:32:33 -0800 (PST) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) by core3.amsl.com (Postfix) with ESMTP id D54693A67B5 for ; Wed, 25 Feb 2009 08:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=univie.ac.at; s=rev1; h=Message-ID:Date:From:MIME-Version:To: Subject:Content-Type:Content-Transfer-Encoding; bh=5u0n7e9pwGxiU sIAQpUt+xXswrGEI165MyvFzifWcp4=; b=7Ze+B9odmiogUi+5JiSKY/XaRhsqy CDpkhgNbK0aZK3t2omi7qktN+apwRQE0B4mfigB/oeN4Cs0hQsdNOh/WEYlWsDT3 wsNNCncTGWVh72rqdeMB80qtNHQkbGt0VH38oP+ss8hvvmGKDkV0P3L6qeMm5FpG O4xyS4jd6f1XTc= Received: from justin.univie.ac.at ([131.130.3.111] helo=justin.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1LcMgl-0004bX-VE for mip4@ietf.org; Wed, 25 Feb 2009 17:32:52 +0100 Received: from login.univie.ac.at ([131.130.1.18] helo=login.univie.ac.at) by justin.univie.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1LcMgl-0000uT-RB; Wed, 25 Feb 2009 17:32:51 +0100 Received: from [131.130.32.86] (pocketcoffee.ani.univie.ac.at [131.130.32.86]) by login.univie.ac.at (8.13.8/8.13.8) with ESMTP id n1PGWpMo079500; Wed, 25 Feb 2009 17:32:51 +0100 Message-ID: <49A572B3.3040107@univie.ac.at> Date: Wed, 25 Feb 2009 17:32:51 +0100 From: karin anna hummel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: [Mip4] CfP: Future Internet Architectures: New Trends in Service Architectures (2nd Euro-NF Workshop) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 16:32:33 -0000 (Apologies if you receive this CfP more than once.) =========================================================== PRELIMINARY CALL FOR PAPERS SUBMISSION DEADLINE: April 13, 2009 Future Internet Architectures: New Trends in Service Architectures (2nd Euro-NF Workshop), Open Workshop http://www.net.fim.uni-passau.de/future2009/ Co-located with EU ICT MobileSummit 9th June 2009, Santander, Spain http://www.ict-mobilesummit.eu/2009/ Limitations and shortcomings of current network architectures are adressed by the Future Internet research area. Emerging network paradigms are expected to provide solutions for novel challenges such as security, scalability, resilience, interoperability, and adaptability. The workshop provides a visionary forum for novel research challenges in the design and evaluation of network paradigms for the Future Internet with a particular focus on access networks. Topics of interest include, but are not limited to: * Wireless mesh networks * Self-organization * Internet of things * Virtualization * Delay-tolerant networks and satellite communications * Opportunistic networks * Context awareness Submissions to the workshop should be either full papers (up to twelve pages, Springer LNCS style) or extended abstracts (up to four pages) presenting original research in the workshop scope. Selected high- quality contributions will be asked for full paper submissions (post workshop proceedings), to be published, e.g., in Springer LNCS or a journal special issue (to be announced soon). DATES * Submission Deadline: April 13, 2009 * Notification of Acceptance: April 20, 2009 * Workshop: June 9, 2009 CHAIRS * Hermann de Meer, University of Passau, Germany * Jens O. Oberender, University of Passau, Germany * Karin Anna Hummel, University of Vienna, Austria LOCAL ORGANIZATION * Klaus Hackbarth, University of Cantabria, Spain TECHNICAL PROGRAM COMMITTEE (to be extended) * Claudio Casetti, Politecnico di Torino, Italy * Matteo Cesana, Politecnico di Milano, Italy * Piotr Cholda, AGH University of Science and Technology, Poland * Xiaoming Fu, University of Göttingen, Germany * Alex Galis, University College London, United Kingdom * Günter Haring, University of Vienna, Austria * Helmut Hlavacs, University of Vienna, Austria * Amine M. Houyou, Siemens AG, Germany * Paul Müller, University of Kaiserslautern, Germany * Ilkka Norros, VTT Technical Research Centre of Finland * Adrian Popescu, Blekinge Institue of Technology, Sweden * Bernd Reuther, University of Kaiserslautern, Germany * Susana Sargento, University of Aveiro, Portugal * Kurt Tutschku, University of Vienna, Austria * Bernd Wolfinger, University of Hamburg, Germany * Patrick Wüchner, University of Passau, Germany CONTACT (extended abstract submissions, general questions) * future2009@fim.uni-passau.de ===========================================================