From mext-bounces@ietf.org Mon Jul 02 08:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LIl-0006EL-Ah; Mon, 02 Jul 2007 08:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LIk-00065F-8A for mext@ietf.org; Mon, 02 Jul 2007 08:46:46 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5LIG-0000Ag-4R for mext@ietf.org; Mon, 02 Jul 2007 08:46:46 -0400 Received: by an-out-0708.google.com with SMTP id c17so331629anc for ; Mon, 02 Jul 2007 05:46:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WeROWQjk5kY4XB4bBWbvSShZy8dZskX04/RdJj4ZNOc5ByeU3R+rVR4Z59pKRb/uyETz1EHZ9Qcf31k1WKFw4sWCbQ+TXsUlHBDMHSaa3daT1lLO2tZDnb09Z1cGfQ32F5+ULe+Q9aSaZQkaXCjNm/m557el4oC8bGR3fncxxlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sskmz/7Z0KmBXEstZry7d7qfNrG/H29KoSV9CHOgQImG0zc5ml+RyBTYzjLsTJAXNuSVzPxJb8tJVdaN6ENUDSxWgOQ484y6iwJWlkOrR80ISO3X285GLSOrSGM5/hbpG2ewKjoW53++KOSIv/QxkpGBLNw3IG8a0EKy5TZxgtk= Received: by 10.100.126.2 with SMTP id y2mr3607942anc.1183380375834; Mon, 02 Jul 2007 05:46:15 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Mon, 2 Jul 2007 05:46:15 -0700 (PDT) Message-ID: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Date: Mon, 2 Jul 2007 14:46:15 +0200 From: "Jean-Michel Combes" To: "Behcet Sarikaya" Subject: Re: [MEXT] new charter version In-Reply-To: <84929.44768.qm@web84106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84929.44768.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Behcet, 2007/6/30, Behcet Sarikaya : > > Hi Jari, > In fact HA reliability work is almost over. I think the current draft is > expected to go for WGLC soon and the subteam is almost closed. I don't think > it would take Aug 08 to complete this work. HA reliability could be > completely removed from this charter. IMHO, I am not so sure. That depends whether you want, concerning the IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare work) included the draft. > > Kind regards, > > Behcet > [snip] Best regards. JMC. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Jul 02 09:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Lfo-0000Bs-5K; Mon, 02 Jul 2007 09:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Lfm-0000Bn-U0 for mext@ietf.org; Mon, 02 Jul 2007 09:10:34 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Lf3-0006Bu-NV for mext@ietf.org; Mon, 02 Jul 2007 09:10:34 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 66233C260 for ; Mon, 2 Jul 2007 09:09:48 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9l4B029463; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9lBS005638; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 8UJEXmWtiGbc; Mon, 2 Jul 2007 09:09:47 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l62D9gcp005617;Mon, 2 Jul 2007 09:09:42 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 7B9E94FDE7; Mon, 2 Jul 2007 09:06:27 -0400 (EDT) Date: Mon, 2 Jul 2007 09:06:27 -0400 From: Wesley Eddy To: Jean-Michel Combes Subject: Re: [MEXT] new charter version Message-ID: <20070702130627.GD6234@grc.nasa.gov> References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org On Mon, Jul 02, 2007 at 02:46:15PM +0200, Jean-Michel Combes wrote: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : > > > >Hi Jari, > > In fact HA reliability work is almost over. I think the current draft is > >expected to go for WGLC soon and the subteam is almost closed. I don't > >think > >it would take Aug 08 to complete this work. HA reliability could be > >completely removed from this charter. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. > I agree. When I read it last, it seemed like to meet all of its stated capabilities, the HA reliability work would need to block on the IFARE work, but perhaps it was just unclear and my understanding was wrong. Other than this part, it did seem mostly complete to me. Specifically, there didn't seem to be detailed enough information on the IPsec state synchronization mechanism within the hareliability draft itself to implement both interoperable, and fully-functional solutions. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 05 13:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Uuy-0005tK-WF; Thu, 05 Jul 2007 13:15:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TGg-0004nh-Hf; Thu, 05 Jul 2007 11:29:18 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6TGg-0006HG-B2; Thu, 05 Jul 2007 11:29:18 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41B774A3E; Thu, 5 Jul 2007 11:28:45 -0400 (EDT) From: Sam Hartman To: iesg@ietf.org References: Date: Thu, 05 Jul 2007 11:28:45 -0400 In-Reply-To: (IESG Secretary's message of "Tue, 26 Jun 2007 16:00:01 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Thu, 05 Jul 2007 13:14:59 -0400 Cc: mext@ietf.org Subject: [MEXT] Re: WG Review: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi. Sorry for how late these comments are. It has come up in another discussion that there is ambiguity about to what extent it is appropriate for mext to be changing the IPsec protocols as a user of those protocols. I have no problem with mext defining new payloads to use IKE to configure some mobile IPV6 paramaters. I'm concerned though about basically any changes beyond that. I think this should be clarified in the charter. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu Jul 05 13:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UvF-00061E-IU; Thu, 05 Jul 2007 13:15:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UvE-0005yw-33; Thu, 05 Jul 2007 13:15:16 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6UvD-0001sy-QY; Thu, 05 Jul 2007 13:15:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 200A1198666; Thu, 5 Jul 2007 20:14:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0EBA8198646; Thu, 5 Jul 2007 20:14:40 +0300 (EEST) Message-ID: <468D26FC.3000307@piuha.net> Date: Thu, 05 Jul 2007 19:14:36 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iesg@ietf.org, mext@ietf.org Subject: [MEXT] Re: WG Review: Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Yes, I agree that this should be clarified. Sam, let me work on text with you and then we can post the suggestion to the list. Jari Sam Hartman kirjoitti: > Hi. > Sorry for how late these comments are. > > It has come up in another discussion that there is ambiguity about to > what extent it is appropriate for mext to be changing the IPsec > protocols as a user of those protocols. > > I have no problem with mext defining new payloads to use IKE to > configure some mobile IPV6 paramaters. I'm concerned though about > basically any changes beyond that. > > > I think this should be clarified in the charter. > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 21 16:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLfI-00028r-FC; Sat, 21 Jul 2007 16:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLfH-00028m-Qn for mext@ietf.org; Sat, 21 Jul 2007 16:34:59 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICLfG-00084f-D7 for mext@ietf.org; Sat, 21 Jul 2007 16:34:59 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 034DE19867D for ; Sat, 21 Jul 2007 23:34:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7B709198667 for ; Sat, 21 Jul 2007 23:34:56 +0300 (EEST) Message-ID: <46A26DF0.6000108@piuha.net> Date: Sat, 21 Jul 2007 15:34:56 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [MEXT] Status of MEXT WG and chairs X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Folks, This is a status update about the merged working group. The IESG has approved the charter pending a few edits from me (Sam's issue among other things). However, I have run out of time to get the WG setup before this meeting. The one thing missing is deciding who the chairs are. As a result, I have asked the current chairs to run the three slots we have in IETF-69. I also plan to use the week to talk to the potential candidates for chairs, from both the set of current chairs as well as new candidates. I have a some names in mind and some have contacted me about this. If there is anyone who feels they are interested, please contact me so that we can talk during the week. I plan to make the decision right after the IETF. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 21 16:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLi7-0003fe-QZ; Sat, 21 Jul 2007 16:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLi6-0003cM-Pw for mext@ietf.org; Sat, 21 Jul 2007 16:37:54 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICLi6-00089o-GS for mext@ietf.org; Sat, 21 Jul 2007 16:37:54 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E213919867D; Sat, 21 Jul 2007 23:37:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 11513198667; Sat, 21 Jul 2007 23:37:52 +0300 (EEST) Message-ID: <46A26EA0.4010804@piuha.net> Date: Sat, 21 Jul 2007 15:37:52 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [MEXT] new charter version References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org If we still need to do the WGLC, I think we should include the item in the charter. Jari Jean-Michel Combes kirjoitti: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : >> >> Hi Jari, >> In fact HA reliability work is almost over. I think the current >> draft is >> expected to go for WGLC soon and the subteam is almost closed. I >> don't think >> it would take Aug 08 to complete this work. HA reliability could be >> completely removed from this charter. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. > >> >> Kind regards, >> >> Behcet >> > > [snip] > > Best regards. > > JMC. > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat Jul 21 17:50:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICMqB-0007ez-Mx; Sat, 21 Jul 2007 17:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICMqB-0007ep-1A for mext@ietf.org; Sat, 21 Jul 2007 17:50:19 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICMq9-0001Iv-Jm for mext@ietf.org; Sat, 21 Jul 2007 17:50:19 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 29AAB19867D; Sun, 22 Jul 2007 00:50:16 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CCBF21985FB; Sun, 22 Jul 2007 00:50:14 +0300 (EEST) Message-ID: <46A27F96.1030005@piuha.net> Date: Sat, 21 Jul 2007 16:50:14 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [MEXT] new charter version References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> <20070702130627.GD6234@grc.nasa.gov> In-Reply-To: <20070702130627.GD6234@grc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Wesley, > I agree. When I read it last, it seemed like to meet all of its stated > capabilities, the HA reliability work would need to block on the IFARE > work, but perhaps it was just unclear and my understanding was wrong. > Other than this part, it did seem mostly complete to me. Specifically, > there didn't seem to be detailed enough information on the IPsec state > synchronization mechanism within the hareliability draft itself to > implement both interoperable, and fully-functional solutions. > The IPsec sync is outside the charter. The next revision of the charter text tries to make this clear (and at the same time address the issue that Sam raised). (But its another question of whether the WG wants to normatively refer to an IPsec sync specification. If so, at this time they would be referring to work that has not even been chartered yet, so you'd want to be careful that you don't insert such a dependency lightly.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jul 22 18:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICkMP-0002yX-Tn; Sun, 22 Jul 2007 18:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICkMP-0002yR-9R for mext@ietf.org; Sun, 22 Jul 2007 18:57:09 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICkMO-0006je-TY for mext@ietf.org; Sun, 22 Jul 2007 18:57:09 -0400 Received: by py-out-1112.google.com with SMTP id f31so4908326pyh for ; Sun, 22 Jul 2007 15:57:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=bGHB2cEnv4U0wpPbX+3eCuIorLRnl0/mxMhf5hz1iYoy5yCFYIAdJ6ubamc6eFs9h0axqgZlVdYNocjfl305D37UwSR914Y3QXLOUdWdKVvoJKo6V/U7SqLREl3gXSfp9vN4LjIz1oO2g3/CZPa/yzgFNxRqqa2KswYNVO6kT2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=JPSF+mUMAF7gVnQ4BKsGbvd0blb5RpYUXwoWaknDRmQHXV1R6J9mKxo2ZTwvLNwa6EWUGKoEUbI0dm7LjfSS8OFEBkvup2Q9TUZsrM7+ieIL38aHlYQ7aNjb038kyw3nqQSKwCwlySIVxZURnFUCa4sgN0dwm/TOU3O9/OfL2kw= Received: by 10.35.14.18 with SMTP id r18mr4856656pyi.1185145028327; Sun, 22 Jul 2007 15:57:08 -0700 (PDT) Received: from ?172.28.170.128? ( [67.97.210.2]) by mx.google.com with ESMTPS id x72sm5684761pyg.2007.07.22.15.57.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jul 2007 15:57:07 -0700 (PDT) In-Reply-To: <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> References: <84929.44768.qm@web84106.mail.mud.yahoo.com> <729b68be0707020546i27e6f377s2f60b9ec1032582f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [MEXT] new charter version Date: Mon, 23 Jul 2007 07:57:00 +0900 To: Jean-Michel Combes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jean-Michel On 2007/07/02, at 21:46, Jean-Michel Combes wrote: > Hi Behcet, > > 2007/6/30, Behcet Sarikaya : >> >> Hi Jari, >> In fact HA reliability work is almost over. I think the current >> draft is >> expected to go for WGLC soon and the subteam is almost closed. I >> don't think >> it would take Aug 08 to complete this work. HA reliability could be >> completely removed from this charter. > > IMHO, I am not so sure. That depends whether you want, concerning the > IPsec failover, a MIP6 WG based solution or a general one (i.e. IFare > work) included the draft. IPsec failover is assumed only for the HA virtual switch case. There is no mechanism available so far in IETF. And we don't think the MIP6 WG is the right place to specify the ipsec failover. We already had consensus on this point in MIP6 WG. As soon as solution(IFARE?) are available, we can update the HA reliability to support that. regards, ryuji >> >> Kind regards, >> >> Behcet >> > > [snip] > > Best regards. > > JMC. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jul 22 21:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnD7-0005n1-M5; Sun, 22 Jul 2007 21:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnD5-0005li-7q for mext@ietf.org; Sun, 22 Jul 2007 21:59:43 -0400 Received: from static-ip-174-194-65-202.rev.dyxnet.com ([202.65.194.174] helo=hitachihk8.hitachi.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICnD2-0001Gi-OA for mext@ietf.org; Sun, 22 Jul 2007 21:59:43 -0400 Received: (qmail 25767 invoked from network); 23 Jul 2007 01:59:36 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;1818b4ef6a0190b21cfdc55dfdb91e8b; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1) by 170.95.94.11 with SMTP; 23 Jul 2007 01:59:35 -0000 Received: (qmail 11176 invoked from network); 23 Jul 2007 01:59:30 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;c28b2feb752d8bd5032571a78a84e3af; Received: from hchidc401.hitachi-china.com (HELO hchidc401.hitachi.cn) (170.95.94.69) by 172.16.10.9 with SMTP; 23 Jul 2007 01:59:30 -0000 Received: from hchidc204.hitachi.cn ([170.95.82.6]) by hchidc401.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:48:27 +0800 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:48:26 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [MEXT] new charter version Date: Mon, 23 Jul 2007 09:48:24 +0800 Message-ID: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] new charter version Thread-Index: AcfMtF+/aTW6+bguTHK3IMLW4kKsbAAFr41T From: "DENG, HUI -HCHBJ" To: "RYUJI WAKIKAWA" , "Jean-Michel Combes" , X-OriginalArrivalTime: 23 Jul 2007 01:48:26.0183 (UTC) FILETIME=[8F87FD70:01C7CCCB] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1185155970.261-11163-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.07/0.51 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1185155976.260-25742-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.05/0.08 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002655154==" Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1002655154== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CCCB.8E8CF40E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CCCB.8E8CF40E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWF5IEkgIGNvbmZvcm0gb25lIHRoaW5nIGhlcmU6IChwbGVhc2UgYWxsb3cgbWUgY2MgaWZhcmUp DQpJRkFSRSB3aWxsIGNvbnNpZGVyIGRpZmZlcmVudCBJUCBhZGRyZXNzIGZvciBHVywgaXMgdGhp cyBjb3JyZWN0Pw0KaWYgdGhpcyBpcyB0cnVlICwgaXQgbWF5IG5vdCBzeW5jIHdpdGggdmlydHVh bCBzd2l0Y2htb2RlLg0KIA0KLUh1aQ0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g DQoJRnJvbTogUllVSkkgV0FLSUtBV0EgW21haWx0bzpyeXVqaS53YWtpa2F3YUBnbWFpbC5jb21d IA0KCVNlbnQ6IDIwMDctNy0yMyAo5pif5pyf5LiAKSA2OjU3IA0KCVRvOiBKZWFuLU1pY2hlbCBD b21iZXMgDQoJQ2M6IG1leHRAaWV0Zi5vcmcgDQoJU3ViamVjdDogUmU6IFtNRVhUXSBuZXcgY2hh cnRlciB2ZXJzaW9uDQoJDQoJDQoNCglIaSBKZWFuLU1pY2hlbA0KCQ0KCU9uIDIwMDcvMDcvMDIs IGF0IDIxOjQ2LCBKZWFuLU1pY2hlbCBDb21iZXMgd3JvdGU6DQoJDQoJPiBIaSBCZWhjZXQsDQoJ Pg0KCT4gMjAwNy82LzMwLCBCZWhjZXQgU2FyaWtheWEgPGJlaGNldHNhcmlrYXlhQHlhaG9vLmNv bT46DQoJPj4NCgk+PiBIaSBKYXJpLA0KCT4+ICAgSW4gZmFjdCBIQSByZWxpYWJpbGl0eSB3b3Jr IGlzIGFsbW9zdCBvdmVyLiBJIHRoaW5rIHRoZSBjdXJyZW50IA0KCT4+IGRyYWZ0IGlzDQoJPj4g ZXhwZWN0ZWQgdG8gZ28gZm9yIFdHTEMgc29vbiBhbmQgdGhlIHN1YnRlYW0gaXMgYWxtb3N0IGNs b3NlZC4gSSANCgk+PiBkb24ndCB0aGluaw0KCT4+IGl0IHdvdWxkIHRha2UgQXVnIDA4IHRvIGNv bXBsZXRlIHRoaXMgd29yay4gSEEgcmVsaWFiaWxpdHkgY291bGQgYmUNCgk+PiBjb21wbGV0ZWx5 IHJlbW92ZWQgZnJvbSB0aGlzIGNoYXJ0ZXIuDQoJPg0KCT4gSU1ITywgSSBhbSBub3Qgc28gc3Vy ZS4gVGhhdCBkZXBlbmRzIHdoZXRoZXIgeW91IHdhbnQsIGNvbmNlcm5pbmcgdGhlDQoJPiBJUHNl YyBmYWlsb3ZlciwgYSBNSVA2IFdHIGJhc2VkIHNvbHV0aW9uIG9yIGEgZ2VuZXJhbCBvbmUgKGku ZS4gSUZhcmUNCgk+IHdvcmspIGluY2x1ZGVkIHRoZSBkcmFmdC4NCgkNCglJUHNlYyBmYWlsb3Zl ciBpcyBhc3N1bWVkIG9ubHkgZm9yIHRoZSBIQSB2aXJ0dWFsIHN3aXRjaCBjYXNlLg0KCVRoZXJl IGlzIG5vIG1lY2hhbmlzbSBhdmFpbGFibGUgc28gZmFyIGluIElFVEYuDQoJQW5kIHdlIGRvbid0 IHRoaW5rIHRoZSBNSVA2IFdHIGlzIHRoZSByaWdodCBwbGFjZSB0byBzcGVjaWZ5IHRoZSANCglp cHNlYyBmYWlsb3Zlci4NCglXZSBhbHJlYWR5IGhhZCBjb25zZW5zdXMgb24gdGhpcyBwb2ludCBp biBNSVA2IFdHLg0KCUFzIHNvb24gYXMgc29sdXRpb24oSUZBUkU/KSBhcmUgYXZhaWxhYmxlLCB3 ZSBjYW4gdXBkYXRlIHRoZSBIQSANCglyZWxpYWJpbGl0eSB0byBzdXBwb3J0IHRoYXQuDQoJDQoJ cmVnYXJkcywNCglyeXVqaQ0KCQ0KCQ0KCT4+DQoJPj4gS2luZCByZWdhcmRzLA0KCT4+DQoJPj4g QmVoY2V0DQoJPj4NCgk+DQoJPiBbc25pcF0NCgk+DQoJPiBCZXN0IHJlZ2FyZHMuDQoJPg0KCT4g Sk1DLg0KCT4NCgk+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoJPiBNRVhUIG1haWxpbmcgbGlzdA0KCT4gTUVYVEBpZXRmLm9yZw0KCT4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KCQ0KCQ0KCV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJTUVYVCBtYWlsaW5nIGxpc3QNCglN RVhUQGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4 dA0KCQ0KDQo= ------_=_NextPart_001_01C7CCCB.8E8CF40E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY2MDMuMCI+CjxUSVRMRT5SZTogW01FWFRdIG5ldyBj aGFydGVyIHZlcnNpb248L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+TWF5IEkm bmJzcDsgY29uZm9ybSBvbmUgdGhpbmcgaGVyZTogKHBsZWFzZSBhbGxvdyBtZSBjYyBpZmFyZSk8 L0RJVj4KPERJVj5JRkFSRSB3aWxsIGNvbnNpZGVyIGRpZmZlcmVudCBJUCBhZGRyZXNzIGZvciBH VywgaXMgdGhpcyBjb3JyZWN0PzwvRElWPgo8RElWPmlmIHRoaXMgaXMgdHJ1ZSAsIGl0IG1heSZu YnNwO25vdCBzeW5jIHdpdGgmbmJzcDt2aXJ0dWFsIHN3aXRjaG1vZGUuPC9ESVY+CjxESVY+Jm5i c3A7PC9ESVY+CjxESVY+LUh1aTwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBk aXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiBSWVVKSSBXQUtJS0FXQSAK ICBbbWFpbHRvOnJ5dWppLndha2lrYXdhQGdtYWlsLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiAyMDA3 LTctMjMgKOaYn+acn+S4gCkgNjo1NyAKICA8QlI+PEI+VG86PC9CPiBKZWFuLU1pY2hlbCBDb21i ZXMgPEJSPjxCPkNjOjwvQj4gbWV4dEBpZXRmLm9yZyAKICA8QlI+PEI+U3ViamVjdDo8L0I+IFJl OiBbTUVYVF0gbmV3IGNoYXJ0ZXIgdmVyc2lvbjxCUj48QlI+PC9GT05UPjwvRElWPgogIDxQPjxG T05UIHNpemU9Mj5IaSBKZWFuLU1pY2hlbDxCUj48QlI+T24gMjAwNy8wNy8wMiwgYXQgMjE6NDYs IEplYW4tTWljaGVsIAogIENvbWJlcyB3cm90ZTo8QlI+PEJSPiZndDsgSGkgQmVoY2V0LDxCUj4m Z3Q7PEJSPiZndDsgMjAwNy82LzMwLCBCZWhjZXQgCiAgU2FyaWtheWEgJmx0O2JlaGNldHNhcmlr YXlhQHlhaG9vLmNvbSZndDs6PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IEhpIAogIEphcmksPEJS PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEluIGZhY3QgSEEgcmVsaWFiaWxpdHkgd29yayBpcyBhbG1v c3Qgb3Zlci4gSSAKICB0aGluayB0aGUgY3VycmVudCZuYnNwOzxCUj4mZ3Q7Jmd0OyBkcmFmdCBp czxCUj4mZ3Q7Jmd0OyBleHBlY3RlZCB0byBnbyBmb3IgCiAgV0dMQyBzb29uIGFuZCB0aGUgc3Vi dGVhbSBpcyBhbG1vc3QgY2xvc2VkLiBJJm5ic3A7PEJSPiZndDsmZ3Q7IGRvbid0IAogIHRoaW5r PEJSPiZndDsmZ3Q7IGl0IHdvdWxkIHRha2UgQXVnIDA4IHRvIGNvbXBsZXRlIHRoaXMgd29yay4g SEEgcmVsaWFiaWxpdHkgCiAgY291bGQgYmU8QlI+Jmd0OyZndDsgY29tcGxldGVseSByZW1vdmVk IGZyb20gdGhpcyBjaGFydGVyLjxCUj4mZ3Q7PEJSPiZndDsgCiAgSU1ITywgSSBhbSBub3Qgc28g c3VyZS4gVGhhdCBkZXBlbmRzIHdoZXRoZXIgeW91IHdhbnQsIGNvbmNlcm5pbmcgdGhlPEJSPiZn dDsgCiAgSVBzZWMgZmFpbG92ZXIsIGEgTUlQNiBXRyBiYXNlZCBzb2x1dGlvbiBvciBhIGdlbmVy YWwgb25lIChpLmUuIElGYXJlPEJSPiZndDsgCiAgd29yaykgaW5jbHVkZWQgdGhlIGRyYWZ0LjxC Uj48QlI+SVBzZWMgZmFpbG92ZXIgaXMgYXNzdW1lZCBvbmx5IGZvciB0aGUgSEEgCiAgdmlydHVh bCBzd2l0Y2ggY2FzZS48QlI+VGhlcmUgaXMgbm8gbWVjaGFuaXNtIGF2YWlsYWJsZSBzbyBmYXIg aW4gSUVURi48QlI+QW5kIAogIHdlIGRvbid0IHRoaW5rIHRoZSBNSVA2IFdHIGlzIHRoZSByaWdo dCBwbGFjZSB0byBzcGVjaWZ5IHRoZSZuYnNwOzxCUj5pcHNlYyAKICBmYWlsb3Zlci48QlI+V2Ug YWxyZWFkeSBoYWQgY29uc2Vuc3VzIG9uIHRoaXMgcG9pbnQgaW4gTUlQNiBXRy48QlI+QXMgc29v biBhcyAKICBzb2x1dGlvbihJRkFSRT8pIGFyZSBhdmFpbGFibGUsIHdlIGNhbiB1cGRhdGUgdGhl IEhBJm5ic3A7PEJSPnJlbGlhYmlsaXR5IHRvIAogIHN1cHBvcnQgdGhhdC48QlI+PEJSPnJlZ2Fy ZHMsPEJSPnJ5dWppPEJSPjxCUj48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgS2luZCAKICByZWdh cmRzLDxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBCZWhjZXQ8QlI+Jmd0OyZndDs8QlI+Jmd0OzxC Uj4mZ3Q7IAogIFtzbmlwXTxCUj4mZ3Q7PEJSPiZndDsgQmVzdCByZWdhcmRzLjxCUj4mZ3Q7PEJS PiZndDsgSk1DLjxCUj4mZ3Q7PEJSPiZndDsgCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBNRVhUIG1haWxpbmcgCiAgbGlzdDxCUj4mZ3Q7 IE1FWFRAaWV0Zi5vcmc8QlI+Jmd0OyA8QSAKICBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tZXh0Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0PC9BPjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPk1FWFQgCiAgbWFpbGluZyBsaXN0PEJSPk1FWFRAaWV0Zi5vcmc8 QlI+PEEgCiAgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4 dCI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDwvQT48QlI+PC9G T05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C7CCCB.8E8CF40E-- --===============1002655154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext --===============1002655154==-- From mext-bounces@ietf.org Tue Jul 24 11:09:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM0i-0000tU-0S; Tue, 24 Jul 2007 11:09:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM0h-0000tF-6h for mext@ietf.org; Tue, 24 Jul 2007 11:09:15 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDM0g-0004MO-Rt for mext@ietf.org; Tue, 24 Jul 2007 11:09:15 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 16B8D198683; Tue, 24 Jul 2007 18:09:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3B405198667; Tue, 24 Jul 2007 18:09:13 +0300 (EEST) Message-ID: <46A6160B.8000309@piuha.net> Date: Tue, 24 Jul 2007 10:08:59 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "DENG, HUI -HCHBJ" Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> In-Reply-To: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hui, > May I conform one thing here: (please allow me cc ifare) > IFARE will consider different IP address for GW, is this correct? I think that was the goal of IFARE. Then again, we don't have an IFARE WG at the moment, so we are speculating. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 12:27:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNEG-0003t5-5j; Tue, 24 Jul 2007 12:27:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN74-0000Dn-62 for mext@ietf.org; Tue, 24 Jul 2007 12:19:54 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDN6t-0007U1-9P for mext@ietf.org; Tue, 24 Jul 2007 12:19:53 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A8EED198680 for ; Tue, 24 Jul 2007 19:19:41 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id AB4AD19867D for ; Tue, 24 Jul 2007 19:19:40 +0300 (EEST) Message-ID: <46A6268E.2020003@piuha.net> Date: Tue, 24 Jul 2007 11:19:26 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Subject: [MEXT] charter - final version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I believe this version has all the edits that I needed to get in. Sam was OK with this as well. ---- Mobility EXTensions for IPv6 (MEXT) Chair(s): TBD Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: https://www1.ietf.org/mailman/listinfo/mext http://www1.ietf.org/mail-archive/web/mext/current/index.html Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, NEMO network mobility mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 o RFC 3963 o RFC 4877 The MEXT Working Group continues the work of the MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, and (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping. Work items related to large scale deployment include: (A.1) A Solution for MIP6 session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for MIP6 capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the ADs before it can be accepted as a part of a work item. Goals and Milestones: Aug 2007 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Aug 2007 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Aug 2007 Submit Multiple CoA Registration to IESG Sep 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Oct 2007 Submit -00 draft on Route Optimization needs for Personal Mobile Router Nov 2007 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Nov 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Dec 2007 Submit -00 draft for solution to aircraft/spacecraft problem Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. Dec 2007 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Jan 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Jan 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational Feb 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Feb 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Mar 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Mar 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Apr 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Apr 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Apr 2008 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard. May 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard May 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Jul 2008 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Jul 2008 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Aug 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Aug 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 13:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOXZ-0006qY-Dl; Tue, 24 Jul 2007 13:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOXX-0006qL-VQ for mext@ietf.org; Tue, 24 Jul 2007 13:51:19 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOXV-00075h-1K for mext@ietf.org; Tue, 24 Jul 2007 13:51:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l6OHpCWa002234; Tue, 24 Jul 2007 19:51:12 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id l6OHp7ih002225; Tue, 24 Jul 2007 19:51:07 +0200 Received: from [130.129.21.215] (dhcp-15d7.ietf69.org [130.129.21.215]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l6OHp5Td028645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2007 19:51:06 +0200 Message-ID: <46A63C07.6080505@enst-bretagne.fr> Date: Tue, 24 Jul 2007 19:51:03 +0200 From: Nicolas Montavont User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> In-Reply-To: <46A6160B.8000309@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari and all, I am sorry I should have commented the charter earlier, but here are some thoughts. We will take some time at the monami6 meeting on Wednesday to discuss those. - I was wondering how multiple HA addresses is linked to multiple home addresses allocated to mobile hosts. When talking about multiple interfaces (item A.3), the charter mainly talks about multiple CoAs and multiple HA addresses. However, in the current documents that we have in the Monami6 WG, we focus more on multiple CoAs and multiple HoAs. For example, the current working group document draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind multiple CoAs to a single HoA, not a single HA address as written in the MEXT charter ("A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track].") However, I think that multiple HA addresses do not imply that the node will have multiple HoAs, and vice versa (multiple HoAs do not imply that we have multiple HA addresses) (please correct me if I am wrong). I think that to fully consider the problem of multihomed MN in MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, and multiple HA addresses. So I propose the following changes to the charter: * 2nd paragraph in (A.3) Use of multiple interfaces. from When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. to When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs) or multiple home addresses. In addition, the Home Agent might be attached to multiple networks through multiple interfaces, or receive multiple IPv6 prefixes on a single network interface, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. * deliverable 2: from - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. To An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses, Home Agent addresses and Home addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. * Deliverable 3: from A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. TO A protocol extension to support the registration of multiple Care-of Addresses to a single home address [Standard Track]. - I have another issue with the fourth deliverable of this section A3. The current charter says in A3: A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. I think this goal is not very clear and would need to be clarified. I can read here three different goals, which are: (1) Exchange policies to influence the choice of the CoA (2) Exchange policies to influence the choice of the HA address (3) Specify a generic format to describe the policies I think that (1) should be re-written to "Policies enforcement from the mobile host/routerto the HA to influence the choice of the CoA." I suggest that because the mobile host/router is the only one to know the addresses that are mapped to its interfaces. What we need, is a protocol to indicate to the HA which CoA to use at the HA for a specific flow. The policies set up (e.g., I want VoIP over your Wifi interface) was always out of scope of the work in monami6. (2) isn't it HA switching work? (3) Can't we add an additional item to make clear that we will have 2 documents? _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 14:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPEk-0001dW-2U; Tue, 24 Jul 2007 14:35:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPEi-0001dK-Ey for mext@ietf.org; Tue, 24 Jul 2007 14:35:56 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPEh-0003IB-PQ for mext@ietf.org; Tue, 24 Jul 2007 14:35:56 -0400 Received: from iseran.local (dhcp-118e.ietf69.org [130.129.17.142]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6OIZqUp013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 20:35:54 +0200 Date: Tue, 24 Jul 2007 20:35:53 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] charter - final version Message-Id: <20070724203553.4ce9be07.thierry.ernst@inria.fr> In-Reply-To: <46A6268E.2020003@piuha.net> References: <46A6268E.2020003@piuha.net> Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 46A64688.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Please find inline a couple more comments before it is published. >Mobility EXTensions for IPv6 (MEXT) >Description of Working Group: > >Mobile IPv6 specifies routing support which permits an IPv6 host to The charter is alternatively using Mobile IPv6 / MIP6. I would suggest adding the abbreviation the first time it is mentioned: "Mobile IPb6 (MIP6). >continue using its home address as it moves around the Internet, >enabling continuity of sessions. Mobile IPv6 supports transparency >above the IP layer, including maintenance of active transport level >sessions. In addition, NEMO network mobility mechanisms built on top >of Mobile IPv6 allow managing the mobility of an entire network, as it NEMO + network mobility = pleonasm. Change "NEMO network mobility mechanisms" to "Network mobility (NEMO) mechanisms I would also remove "built on top of Mobile IPv6" as it would suggest there is a dependance between MIPv6 and NEMO, which is not the case. Both protocols are based on the same concepts and use the same mechanisms. >o RFC 3775 >o RFC 3963 >o RFC 4877 I would add the title of the RFC, not only the number. What about RFC 3776 ? Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 to RFC 4889 as the newbie wouldn't have any hint they exist ? These are important informational documents to justify the work being done and the direction of the WG (something that is always missing in WG charters). >The MEXT Working Group continues the work of the MIP6, NEMO, and >MONAMI6 Working Groups. I would add "former" before MIP6, NEMO & MONANI6 WGs >Deployment considerations call for (A.1) solutions to enable >dual-stack operation, (A.2) mechanisms to support high-availability >home agents, (A.3) allowing the use of multiple interfaces in mobile >nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, Mobile IPv6 => Mobile IPv6/NEMO >(A.5) address the specific needs of automotive and aviation >communities for route optimisation in network mobility, and (A.6) >support for AAA is needed as a continuation of earlier work on >bootstrapping. > >Work items related to large scale deployment include: > >(A.1) A Solution for MIP6 session continuity for dual stack hosts which MIP6 session => MIP6/NEMO session > attach to IPv4 access networks. Additionally provide a mechanism > for carrying IPv4 packets via the Home agent for MIP6 capable > dual-stack hosts. MIP6/NEMO capable > >(A.2) A protocol based solution for enhancing the reliability of home > agents and a method to force a host to switch home agents. host => host/router > A mechanism to force an MN to switch the HA that is currently > serving it. This is required in deployments where the HA needs to > be taken offline for maintenance. No more comments on the remaining text. Thanks, Thierry _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 16:32:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDR36-0007Pm-PP; Tue, 24 Jul 2007 16:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDR35-0007Ph-4r for mext@ietf.org; Tue, 24 Jul 2007 16:32:03 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDR34-0002Nd-8t for mext@ietf.org; Tue, 24 Jul 2007 16:32:03 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7607E198680; Tue, 24 Jul 2007 23:32:01 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9415019867D; Tue, 24 Jul 2007 23:32:00 +0300 (EEST) Message-ID: <46A661B2.4070601@piuha.net> Date: Tue, 24 Jul 2007 15:31:46 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Nicolas Montavont Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> In-Reply-To: <46A63C07.6080505@enst-bretagne.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Nicolas, I have not sent this forward yet, so there is time to make edits. However, as I recall the Monami6 chartering process, the decision to not focus on multiple home addresses was done deliberately. That is, the use of multiple home addresses is very close to the generic multihoming problem and it seemed inappropriate to try to address that in a mobility working group. So, while I agree that the current text is not the best possible one, I'm not sure the new text is right either... Jari > I am sorry I should have commented the charter earlier, but here are > some thoughts. We will take some time at the monami6 meeting on > Wednesday to discuss those. > > - I was wondering how multiple HA addresses is linked to multiple > home addresses allocated to mobile hosts. When talking about multiple > interfaces (item A.3), the charter mainly talks about multiple CoAs > and multiple HA addresses. However, in the current documents that we > have in the Monami6 WG, we focus more on multiple CoAs and multiple > HoAs. For example, the current working group document > draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind > multiple CoAs to a single HoA, not a single HA address as written in > the MEXT charter ("A protocol extension to support the registration of > multiple Care-of Addresses at a given Home Agent address [Standard > Track].") > > However, I think that multiple HA addresses do not imply that the node > will have multiple HoAs, and vice versa (multiple HoAs do not imply > that we have multiple HA addresses) (please correct me if I am wrong). > I think that to fully consider the problem of multihomed MN in > MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, > and multiple HA addresses. So I propose the following changes to the > charter: > > * 2nd paragraph in (A.3) Use of multiple interfaces. > from > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a single > network interface, the mobile host/router would end up with multiple > Care-of Addresses (CoAs). In addition, the Home Agent might be > attached to multiple network interfaces, or to a single network > interface with multiple prefixes, hence resulting in the option to use > multiple IP addresses for the Home Agent. This could result in the > possibility of using a multitude > of bi-directional tunnels between pairs of {Home Agent address, CoA} > and a number of associated issues: establishment, selection and > modification of multiple simultaneous tunnels. > > to > > When a mobile host/router uses multiple network interfaces > simultaneously, or when multiple prefixes are available on a single > network interface, the mobile host/router would end up with multiple > Care-of Addresses (CoAs) or multiple home addresses. > In addition, the Home Agent might be attached to multiple networks > through multiple interfaces, or receive multiple IPv6 prefixes on a > single network interface, hence resulting in the option to use > multiple IP addresses for the Home Agent. This could result in the > possibility of using a multitude of bi-directional tunnels between > pairs of {Home Agent address, CoA} and a number of associated issues: > establishment, selection and modification of multiple simultaneous > tunnels. > > * deliverable 2: > from > - An analysis document explaining what are the limitations for > mobile hosts using multiple simultaneous Care-of Addresses and Home > Agent addresses using Mobile IPv6, whether issues are specific to > Mobile IPv6 or not [Informational]. > > To > An analysis document explaining what are the limitations for mobile > hosts using multiple simultaneous Care-of Addresses, Home Agent > addresses and Home addresses using Mobile IPv6, whether issues are > specific to Mobile IPv6 or not [Informational]. > > * Deliverable 3: > from > A protocol extension to support the registration of multiple Care-of > Addresses at a given Home Agent address [Standard Track]. > TO > A protocol extension to support the registration of multiple Care-of > Addresses to a single home address [Standard Track]. > > - I have another issue with the fourth deliverable of this section > A3. The current charter says in A3: > > A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > I think this goal is not very clear and would need to be clarified. I > can read here three different goals, which are: > (1) Exchange policies to influence the choice of the CoA > (2) Exchange policies to influence the choice of the HA address > (3) Specify a generic format to describe the policies > > I think that (1) should be re-written to "Policies enforcement from > the mobile host/routerto the HA to influence the choice of the CoA." I > suggest that because the mobile host/router is the only one to know > the addresses that are mapped to its interfaces. What we need, is a > protocol to indicate to the HA which CoA to use at the HA for a > specific flow. The policies set up (e.g., I want VoIP over your Wifi > interface) was always out of scope of the work in monami6. > > (2) isn't it HA switching work? > > (3) Can't we add an additional item to make clear that we will have 2 > documents? > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 17:30:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRxw-00029p-0R; Tue, 24 Jul 2007 17:30:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRxt-00029f-RJ for mext@ietf.org; Tue, 24 Jul 2007 17:30:45 -0400 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRxs-0007H4-HM for mext@ietf.org; Tue, 24 Jul 2007 17:30:45 -0400 Received: from wanynb1 ([129.254.1.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 06:36:20 +0900 From: "Taewan You" To: "'Jari Arkko'" References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2><46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> Subject: RE: [MEXT] new charter version Date: Wed, 25 Jul 2007 06:30:36 +0900 Message-ID: <002201c7ce39$e1ac1f40$3f168182@wanynb1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46A661B2.4070601@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfOMt+xDG6/biYRS3CXPwptYHJ6bQABrhEw X-OriginalArrivalTime: 24 Jul 2007 21:36:20.0563 (UTC) FILETIME=[ACC90A30:01C7CE3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Dear Jari, I fully agree with Nicolas opinion about the multiple HoAs. We will assume a general situation in where a mobile node with three heterogeneous interfaces such as 802.11, CDMA, and 802.16e. In this situation, we will also assume that each technology is provided in different service provider. Then each interface has own home address for supporting connectivity to own subscribers. Therefore, there are so several issues to clarify in this situation as like according to the draft of "mip6 analysis" such as registration to given home agent, synchronizations between multiple home agents, and so on. Regarding a position of Administrators for each different L2 technologies, the issues of multiple home agents and addresses should be handled. And I think that the issues are belonging to mobility extension work. Regarding Taewan. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, July 25, 2007 5:32 AM > To: Nicolas Montavont > Cc: mext@ietf.org > Subject: Re: [MEXT] new charter version > > > Nicolas, > > I have not sent this forward yet, so there is time to make > edits. > > However, as I recall the Monami6 chartering process, the > decision to not focus on multiple home addresses was done > deliberately. That is, the use of multiple home addresses > is very close to the generic multihoming problem and it > seemed inappropriate to try to address that in a mobility > working group. > > So, while I agree that the current text is not the best > possible one, I'm not sure the new text is right either... > > Jari > > > I am sorry I should have commented the charter earlier, but here are > > some thoughts. We will take some time at the monami6 meeting on > > Wednesday to discuss those. > > > > - I was wondering how multiple HA addresses is linked to multiple > > home addresses allocated to mobile hosts. When talking about multiple > > interfaces (item A.3), the charter mainly talks about multiple CoAs > > and multiple HA addresses. However, in the current documents that we > > have in the Monami6 WG, we focus more on multiple CoAs and multiple > > HoAs. For example, the current working group document > > draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind > > multiple CoAs to a single HoA, not a single HA address as written in > > the MEXT charter ("A protocol extension to support the registration of > > multiple Care-of Addresses at a given Home Agent address [Standard > > Track].") > > > > However, I think that multiple HA addresses do not imply that the node > > will have multiple HoAs, and vice versa (multiple HoAs do not imply > > that we have multiple HA addresses) (please correct me if I am wrong). > > I think that to fully consider the problem of multihomed MN in > > MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, > > and multiple HA addresses. So I propose the following changes to the > > charter: > > > > * 2nd paragraph in (A.3) Use of multiple interfaces. > > from > > When a mobile host/router uses multiple network interfaces > > simultaneously, or when multiple prefixes are available on a single > > network interface, the mobile host/router would end up with multiple > > Care-of Addresses (CoAs). In addition, the Home Agent might be > > attached to multiple network interfaces, or to a single network > > interface with multiple prefixes, hence resulting in the option to use > > multiple IP addresses for the Home Agent. This could result in the > > possibility of using a multitude > > of bi-directional tunnels between pairs of {Home Agent address, CoA} > > and a number of associated issues: establishment, selection and > > modification of multiple simultaneous tunnels. > > > > to > > > > When a mobile host/router uses multiple network interfaces > > simultaneously, or when multiple prefixes are available on a single > > network interface, the mobile host/router would end up with multiple > > Care-of Addresses (CoAs) or multiple home addresses. > > In addition, the Home Agent might be attached to multiple networks > > through multiple interfaces, or receive multiple IPv6 prefixes on a > > single network interface, hence resulting in the option to use > > multiple IP addresses for the Home Agent. This could result in the > > possibility of using a multitude of bi-directional tunnels between > > pairs of {Home Agent address, CoA} and a number of associated issues: > > establishment, selection and modification of multiple simultaneous > > tunnels. > > > > * deliverable 2: > > from > > - An analysis document explaining what are the limitations for > > mobile hosts using multiple simultaneous Care-of Addresses and Home > > Agent addresses using Mobile IPv6, whether issues are specific to > > Mobile IPv6 or not [Informational]. > > > > To > > An analysis document explaining what are the limitations for mobile > > hosts using multiple simultaneous Care-of Addresses, Home Agent > > addresses and Home addresses using Mobile IPv6, whether issues are > > specific to Mobile IPv6 or not [Informational]. > > > > * Deliverable 3: > > from > > A protocol extension to support the registration of multiple Care-of > > Addresses at a given Home Agent address [Standard Track]. > > TO > > A protocol extension to support the registration of multiple Care-of > > Addresses to a single home address [Standard Track]. > > > > - I have another issue with the fourth deliverable of this section > > A3. The current charter says in A3: > > > > A "Flow/binding policies exchange" solution for an exchange of > > policies from the mobile host/router to the Home Agent and from the > > Home Agent to the mobile host/router influencing the choice of the > > Care-of Address and Home Agent address. The solution involves two > > specifications, one for the policy format and another for its > > transport [both Standard Track]. > > > > I think this goal is not very clear and would need to be clarified. I > > can read here three different goals, which are: > > (1) Exchange policies to influence the choice of the CoA > > (2) Exchange policies to influence the choice of the HA address > > (3) Specify a generic format to describe the policies > > > > I think that (1) should be re-written to "Policies enforcement from > > the mobile host/routerto the HA to influence the choice of the CoA." I > > suggest that because the mobile host/router is the only one to know > > the addresses that are mapped to its interfaces. What we need, is a > > protocol to indicate to the HA which CoA to use at the HA for a > > specific flow. The policies set up (e.g., I want VoIP over your Wifi > > interface) was always out of scope of the work in monami6. > > > > (2) isn't it HA switching work? > > > > (3) Can't we add an additional item to make clear that we will have 2 > > documents? > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 17:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSC9-0006SW-6G; Tue, 24 Jul 2007 17:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSC7-0006SM-81 for mext@ietf.org; Tue, 24 Jul 2007 17:45:27 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDSC6-0007dX-5n for mext@ietf.org; Tue, 24 Jul 2007 17:45:27 -0400 Received: from iseran.local (dhcp-118e.ietf69.org [130.129.17.142]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6OLjNmT017012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 23:45:25 +0200 Date: Tue, 24 Jul 2007 23:45:23 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] new charter version Message-Id: <20070724234523.b76c6ed9.thierry.ernst@inria.fr> In-Reply-To: <46A661B2.4070601@piuha.net> References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 46A672F3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >I have not sent this forward yet, so there is time to make >edits. > >However, as I recall the Monami6 chartering process, the >decision to not focus on multiple home addresses was done >deliberately. That is, the use of multiple home addresses >is very close to the generic multihoming problem and it >seemed inappropriate to try to address that in a mobility >working group. > >So, while I agree that the current text is not the best >possible one, I'm not sure the new text is right either... You are right, this is resulting from the MonAmi6 chartering process. The problem is that a CoA is bound to a particular HoA, not the HA address, so we cannot skip dealing with the HoA. Not dealing with all of the cases bring inconsistancy between the charter and the documents. I'm in favor of clarity in the charter and the problem statements. Regarding the solutions, I think everyone will understand that the group is not going to work on issues dealt with Shim6 or other groups. Thierry >Jari > >> I am sorry I should have commented the charter earlier, but here are >> some thoughts. We will take some time at the monami6 meeting on >> Wednesday to discuss those. >> >> - I was wondering how multiple HA addresses is linked to multiple >> home addresses allocated to mobile hosts. When talking about multiple >> interfaces (item A.3), the charter mainly talks about multiple CoAs >> and multiple HA addresses. However, in the current documents that we >> have in the Monami6 WG, we focus more on multiple CoAs and multiple >> HoAs. For example, the current working group document >> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >> multiple CoAs to a single HoA, not a single HA address as written in >> the MEXT charter ("A protocol extension to support the registration of >> multiple Care-of Addresses at a given Home Agent address [Standard >> Track].") >> >> However, I think that multiple HA addresses do not imply that the node >> will have multiple HoAs, and vice versa (multiple HoAs do not imply >> that we have multiple HA addresses) (please correct me if I am wrong). >> I think that to fully consider the problem of multihomed MN in >> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >> and multiple HA addresses. So I propose the following changes to the >> charter: >> >> * 2nd paragraph in (A.3) Use of multiple interfaces. >> from >> When a mobile host/router uses multiple network interfaces >> simultaneously, or when multiple prefixes are available on a single >> network interface, the mobile host/router would end up with multiple >> Care-of Addresses (CoAs). In addition, the Home Agent might be >> attached to multiple network interfaces, or to a single network >> interface with multiple prefixes, hence resulting in the option to use >> multiple IP addresses for the Home Agent. This could result in the >> possibility of using a multitude >> of bi-directional tunnels between pairs of {Home Agent address, CoA} >> and a number of associated issues: establishment, selection and >> modification of multiple simultaneous tunnels. >> >> to >> >> When a mobile host/router uses multiple network interfaces >> simultaneously, or when multiple prefixes are available on a single >> network interface, the mobile host/router would end up with multiple >> Care-of Addresses (CoAs) or multiple home addresses. >> In addition, the Home Agent might be attached to multiple networks >> through multiple interfaces, or receive multiple IPv6 prefixes on a >> single network interface, hence resulting in the option to use >> multiple IP addresses for the Home Agent. This could result in the >> possibility of using a multitude of bi-directional tunnels between >> pairs of {Home Agent address, CoA} and a number of associated issues: >> establishment, selection and modification of multiple simultaneous >> tunnels. >> >> * deliverable 2: >> from >> - An analysis document explaining what are the limitations for >> mobile hosts using multiple simultaneous Care-of Addresses and Home >> Agent addresses using Mobile IPv6, whether issues are specific to >> Mobile IPv6 or not [Informational]. >> >> To >> An analysis document explaining what are the limitations for mobile >> hosts using multiple simultaneous Care-of Addresses, Home Agent >> addresses and Home addresses using Mobile IPv6, whether issues are >> specific to Mobile IPv6 or not [Informational]. >> >> * Deliverable 3: >> from >> A protocol extension to support the registration of multiple Care-of >> Addresses at a given Home Agent address [Standard Track]. >> TO >> A protocol extension to support the registration of multiple Care-of >> Addresses to a single home address [Standard Track]. >> >> - I have another issue with the fourth deliverable of this section >> A3. The current charter says in A3: >> >> A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> I think this goal is not very clear and would need to be clarified. I >> can read here three different goals, which are: >> (1) Exchange policies to influence the choice of the CoA >> (2) Exchange policies to influence the choice of the HA address >> (3) Specify a generic format to describe the policies >> >> I think that (1) should be re-written to "Policies enforcement from >> the mobile host/routerto the HA to influence the choice of the CoA." I >> suggest that because the mobile host/router is the only one to know >> the addresses that are mapped to its interfaces. What we need, is a >> protocol to indicate to the HA which CoA to use at the HA for a >> specific flow. The policies set up (e.g., I want VoIP over your Wifi >> interface) was always out of scope of the work in monami6. >> >> (2) isn't it HA switching work? >> >> (3) Can't we add an additional item to make clear that we will have 2 >> documents? >> >> > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www1.ietf.org/mailman/listinfo/mext > -- Thierry ERNST, PhD INRIA Rocquencourt France Project-Team IMARA / JRU LARA http://www.lara.prd.fr +33 1 39 63 59 30 (office) -- The coming end of the IPv4 world: http://penrose.uk6x.com _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 18:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSXi-0006TR-HZ; Tue, 24 Jul 2007 18:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSXh-0006TH-Dv for mext@ietf.org; Tue, 24 Jul 2007 18:07:45 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDSXg-0004Bw-1K for mext@ietf.org; Tue, 24 Jul 2007 18:07:45 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3DBDC198680; Wed, 25 Jul 2007 01:07:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8B57619867D; Wed, 25 Jul 2007 01:07:41 +0300 (EEST) Message-ID: <46A6781E.2050109@piuha.net> Date: Tue, 24 Jul 2007 17:07:26 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Taewan You Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2><46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> <002201c7ce39$e1ac1f40$3f168182@wanynb1> In-Reply-To: <002201c7ce39$e1ac1f40$3f168182@wanynb1> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org There is no question that the issues exist. The argument was that this is not the right place to deal with them. Jari Taewan You kirjoitti: > Dear Jari, > > I fully agree with Nicolas opinion about the multiple HoAs. > > We will assume a general situation in where a mobile node with three > heterogeneous interfaces such as 802.11, CDMA, and 802.16e. In this > situation, we will also assume that each technology is provided in different > service provider. Then each interface has own home address for supporting > connectivity to own subscribers. > > Therefore, there are so several issues to clarify in this situation as like > according to the draft of "mip6 analysis" such as registration to given home > agent, synchronizations between multiple home agents, and so on. > > Regarding a position of Administrators for each different L2 technologies, > the issues of multiple home agents and addresses should be handled. And I > think that the issues are belonging to mobility extension work. > > Regarding > Taewan. > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Wednesday, July 25, 2007 5:32 AM >> To: Nicolas Montavont >> Cc: mext@ietf.org >> Subject: Re: [MEXT] new charter version >> >> >> Nicolas, >> >> I have not sent this forward yet, so there is time to make >> edits. >> >> However, as I recall the Monami6 chartering process, the >> decision to not focus on multiple home addresses was done >> deliberately. That is, the use of multiple home addresses >> is very close to the generic multihoming problem and it >> seemed inappropriate to try to address that in a mobility >> working group. >> >> So, while I agree that the current text is not the best >> possible one, I'm not sure the new text is right either... >> >> Jari >> >> >>> I am sorry I should have commented the charter earlier, but here are >>> some thoughts. We will take some time at the monami6 meeting on >>> Wednesday to discuss those. >>> >>> - I was wondering how multiple HA addresses is linked to multiple >>> home addresses allocated to mobile hosts. When talking about multiple >>> interfaces (item A.3), the charter mainly talks about multiple CoAs >>> and multiple HA addresses. However, in the current documents that we >>> have in the Monami6 WG, we focus more on multiple CoAs and multiple >>> HoAs. For example, the current working group document >>> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >>> multiple CoAs to a single HoA, not a single HA address as written in >>> the MEXT charter ("A protocol extension to support the registration of >>> multiple Care-of Addresses at a given Home Agent address [Standard >>> Track].") >>> >>> However, I think that multiple HA addresses do not imply that the node >>> will have multiple HoAs, and vice versa (multiple HoAs do not imply >>> that we have multiple HA addresses) (please correct me if I am wrong). >>> I think that to fully consider the problem of multihomed MN in >>> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >>> and multiple HA addresses. So I propose the following changes to the >>> charter: >>> >>> * 2nd paragraph in (A.3) Use of multiple interfaces. >>> from >>> When a mobile host/router uses multiple network interfaces >>> simultaneously, or when multiple prefixes are available on a single >>> network interface, the mobile host/router would end up with multiple >>> Care-of Addresses (CoAs). In addition, the Home Agent might be >>> attached to multiple network interfaces, or to a single network >>> interface with multiple prefixes, hence resulting in the option to use >>> multiple IP addresses for the Home Agent. This could result in the >>> possibility of using a multitude >>> of bi-directional tunnels between pairs of {Home Agent address, CoA} >>> and a number of associated issues: establishment, selection and >>> modification of multiple simultaneous tunnels. >>> >>> to >>> >>> When a mobile host/router uses multiple network interfaces >>> simultaneously, or when multiple prefixes are available on a single >>> network interface, the mobile host/router would end up with multiple >>> Care-of Addresses (CoAs) or multiple home addresses. >>> In addition, the Home Agent might be attached to multiple networks >>> through multiple interfaces, or receive multiple IPv6 prefixes on a >>> single network interface, hence resulting in the option to use >>> multiple IP addresses for the Home Agent. This could result in the >>> possibility of using a multitude of bi-directional tunnels between >>> pairs of {Home Agent address, CoA} and a number of associated issues: >>> establishment, selection and modification of multiple simultaneous >>> tunnels. >>> >>> * deliverable 2: >>> from >>> - An analysis document explaining what are the limitations for >>> mobile hosts using multiple simultaneous Care-of Addresses and Home >>> Agent addresses using Mobile IPv6, whether issues are specific to >>> Mobile IPv6 or not [Informational]. >>> >>> To >>> An analysis document explaining what are the limitations for mobile >>> hosts using multiple simultaneous Care-of Addresses, Home Agent >>> addresses and Home addresses using Mobile IPv6, whether issues are >>> specific to Mobile IPv6 or not [Informational]. >>> >>> * Deliverable 3: >>> from >>> A protocol extension to support the registration of multiple Care-of >>> Addresses at a given Home Agent address [Standard Track]. >>> TO >>> A protocol extension to support the registration of multiple Care-of >>> Addresses to a single home address [Standard Track]. >>> >>> - I have another issue with the fourth deliverable of this section >>> A3. The current charter says in A3: >>> >>> A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>> >>> I think this goal is not very clear and would need to be clarified. I >>> can read here three different goals, which are: >>> (1) Exchange policies to influence the choice of the CoA >>> (2) Exchange policies to influence the choice of the HA address >>> (3) Specify a generic format to describe the policies >>> >>> I think that (1) should be re-written to "Policies enforcement from >>> the mobile host/routerto the HA to influence the choice of the CoA." I >>> suggest that because the mobile host/router is the only one to know >>> the addresses that are mapped to its interfaces. What we need, is a >>> protocol to indicate to the HA which CoA to use at the HA for a >>> specific flow. The policies set up (e.g., I want VoIP over your Wifi >>> interface) was always out of scope of the work in monami6. >>> >>> (2) isn't it HA switching work? >>> >>> (3) Can't we add an additional item to make clear that we will have 2 >>> documents? >>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext >> > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Jul 24 20:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUJR-0000mt-FT; Tue, 24 Jul 2007 20:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUJQ-0000mo-TB for mext@ietf.org; Tue, 24 Jul 2007 20:01:08 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDUJP-0006CN-0w for mext@ietf.org; Tue, 24 Jul 2007 20:01:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id l6P00mG7025654; Wed, 25 Jul 2007 02:00:48 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.7/8.13.7/2007.03.20) with ESMTP id l6P00hIt025644; Wed, 25 Jul 2007 02:00:43 +0200 Received: from [130.129.23.203] (dhcp-17cb.ietf69.org [130.129.23.203]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id l6P00aB7031780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 02:00:42 +0200 Message-ID: <46A692A1.3060005@enst-bretagne.fr> Date: Wed, 25 Jul 2007 02:00:33 +0200 From: Nicolas Montavont User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] new charter version References: <8386EDF347730C46BA47710F87AE1FE9303B73@hcbjdc2> <46A6160B.8000309@piuha.net> <46A63C07.6080505@enst-bretagne.fr> <46A661B2.4070601@piuha.net> In-Reply-To: <46A661B2.4070601@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, Jari Arkko wrote: > Nicolas, > > I have not sent this forward yet, so there is time to make > edits. > > However, as I recall the Monami6 chartering process, the > decision to not focus on multiple home addresses was done > deliberately. That is, the use of multiple home addresses > is very close to the generic multihoming problem and it > seemed inappropriate to try to address that in a mobility > working group. > I remember and still agree. I think that it is not the job of monami6 (and MEXT) to propose solutions for multiple HoA management. > So, while I agree that the current text is not the best > possible one, I'm not sure the new text is right either... > However I think that we can (and should) enhance the text, without proposing more work that we are actually doing in Monami6 (and follow in MEXT). For example, the item 3 (registration of multiple CoA) is definitely the registration of multiple CoA to a single home address, and not for a single HA address as we have now in the charter. The other changes I proposed (on the multiple HoAs issue) mainly concerns the problem statement document and does not suggest to deal with the problem in this working group. Indeed, in the problem statement document we suggest either to use other multihoming protocol (such as shim6), or to be able to register a HoA as a CoA in specific configuration. Regards, Nicolas > Jari > > >> I am sorry I should have commented the charter earlier, but here are >> some thoughts. We will take some time at the monami6 meeting on >> Wednesday to discuss those. >> >> - I was wondering how multiple HA addresses is linked to multiple >> home addresses allocated to mobile hosts. When talking about multiple >> interfaces (item A.3), the charter mainly talks about multiple CoAs >> and multiple HA addresses. However, in the current documents that we >> have in the Monami6 WG, we focus more on multiple CoAs and multiple >> HoAs. For example, the current working group document >> draft-ietf-monami6-multiplecoa-03.txt proposes a mechanism to bind >> multiple CoAs to a single HoA, not a single HA address as written in >> the MEXT charter ("A protocol extension to support the registration of >> multiple Care-of Addresses at a given Home Agent address [Standard >> Track].") >> >> However, I think that multiple HA addresses do not imply that the node >> will have multiple HoAs, and vice versa (multiple HoAs do not imply >> that we have multiple HA addresses) (please correct me if I am wrong). >> I think that to fully consider the problem of multihomed MN in >> MobileIPv6 / NEMO, we should consider multiple CoAs, multiple HoAs, >> and multiple HA addresses. So I propose the following changes to the >> charter: >> >> * 2nd paragraph in (A.3) Use of multiple interfaces. >> from >> When a mobile host/router uses multiple network interfaces >> simultaneously, or when multiple prefixes are available on a single >> network interface, the mobile host/router would end up with multiple >> Care-of Addresses (CoAs). In addition, the Home Agent might be >> attached to multiple network interfaces, or to a single network >> interface with multiple prefixes, hence resulting in the option to use >> multiple IP addresses for the Home Agent. This could result in the >> possibility of using a multitude >> of bi-directional tunnels between pairs of {Home Agent address, CoA} >> and a number of associated issues: establishment, selection and >> modification of multiple simultaneous tunnels. >> >> to >> >> When a mobile host/router uses multiple network interfaces >> simultaneously, or when multiple prefixes are available on a single >> network interface, the mobile host/router would end up with multiple >> Care-of Addresses (CoAs) or multiple home addresses. >> In addition, the Home Agent might be attached to multiple networks >> through multiple interfaces, or receive multiple IPv6 prefixes on a >> single network interface, hence resulting in the option to use >> multiple IP addresses for the Home Agent. This could result in the >> possibility of using a multitude of bi-directional tunnels between >> pairs of {Home Agent address, CoA} and a number of associated issues: >> establishment, selection and modification of multiple simultaneous >> tunnels. >> >> * deliverable 2: >> from >> - An analysis document explaining what are the limitations for >> mobile hosts using multiple simultaneous Care-of Addresses and Home >> Agent addresses using Mobile IPv6, whether issues are specific to >> Mobile IPv6 or not [Informational]. >> >> To >> An analysis document explaining what are the limitations for mobile >> hosts using multiple simultaneous Care-of Addresses, Home Agent >> addresses and Home addresses using Mobile IPv6, whether issues are >> specific to Mobile IPv6 or not [Informational]. >> >> * Deliverable 3: >> from >> A protocol extension to support the registration of multiple Care-of >> Addresses at a given Home Agent address [Standard Track]. >> TO >> A protocol extension to support the registration of multiple Care-of >> Addresses to a single home address [Standard Track]. >> >> - I have another issue with the fourth deliverable of this section >> A3. The current charter says in A3: >> >> A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> I think this goal is not very clear and would need to be clarified. I >> can read here three different goals, which are: >> (1) Exchange policies to influence the choice of the CoA >> (2) Exchange policies to influence the choice of the HA address >> (3) Specify a generic format to describe the policies >> >> I think that (1) should be re-written to "Policies enforcement from >> the mobile host/routerto the HA to influence the choice of the CoA." I >> suggest that because the mobile host/router is the only one to know >> the addresses that are mapped to its interfaces. What we need, is a >> protocol to indicate to the HA which CoA to use at the HA for a >> specific flow. The policies set up (e.g., I want VoIP over your Wifi >> interface) was always out of scope of the work in monami6. >> >> (2) isn't it HA switching work? >> >> (3) Can't we add an additional item to make clear that we will have 2 >> documents? >> >> >> _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 25 13:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkPy-0002Dw-Qm; Wed, 25 Jul 2007 13:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDkPw-0002Ct-DN for mext@ietf.org; Wed, 25 Jul 2007 13:12:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDkPu-0005UA-Lv for mext@ietf.org; Wed, 25 Jul 2007 13:12:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BDE7198680; Wed, 25 Jul 2007 20:12:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8D5E619867D; Wed, 25 Jul 2007 20:12:52 +0300 (EEST) Message-ID: <46A78493.4050703@piuha.net> Date: Wed, 25 Jul 2007 12:12:51 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [MEXT] charter - final version References: <46A6268E.2020003@piuha.net> <20070724203553.4ce9be07.thierry.ernst@inria.fr> In-Reply-To: <20070724203553.4ce9be07.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Thierry, Thanks for your comments. Inline: > The charter is alternatively using Mobile IPv6 / MIP6. I would suggest > adding the abbreviation the first time it is mentioned: "Mobile IPb6 > (MIP6). > Yes. Needs fixing. >> continue using its home address as it moves around the Internet, >> enabling continuity of sessions. Mobile IPv6 supports transparency >> above the IP layer, including maintenance of active transport level >> sessions. In addition, NEMO network mobility mechanisms built on top >> of Mobile IPv6 allow managing the mobility of an entire network, as it >> > > NEMO + network mobility = pleonasm. Change "NEMO network mobility > mechanisms" to "Network mobility (NEMO) mechanisms > Ok. > I would also remove "built on top of Mobile IPv6" as it would suggest > there is a dependance between MIPv6 and NEMO, which is not the case. > Both protocols are based on the same concepts and use the same > mechanisms. > Now I lost you. Here's what RFC 3963 says in the abstract: "The protocol is an extension of Mobile IPv6 and ..." >> o RFC 3775 >> o RFC 3963 >> o RFC 4877 >> > > I would add the title of the RFC, not only the number. OK. > What about RFC > 3776 ? > Taken over by 4877, or at least that is imho the one that we should focus on. > Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 > to RFC 4889 as the newbie wouldn't have any hint they exist ? These are > important informational documents to justify the work being done and > the direction of the WG (something that is always missing in WG > charters). > The list is not intended to be exhaustive but point to the main documents. > > >> The MEXT Working Group continues the work of the MIP6, NEMO, and >> MONAMI6 Working Groups. >> > > I would add "former" before MIP6, NEMO & MONANI6 WGs > Ok. > >> Deployment considerations call for (A.1) solutions to enable >> dual-stack operation, (A.2) mechanisms to support high-availability >> home agents, (A.3) allowing the use of multiple interfaces in mobile >> nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, >> > > Mobile IPv6 => Mobile IPv6/NEMO > OK. >> (A.5) address the specific needs of automotive and aviation >> communities for route optimisation in network mobility, and (A.6) >> support for AAA is needed as a continuation of earlier work on >> bootstrapping. >> >> Work items related to large scale deployment include: >> >> (A.1) A Solution for MIP6 session continuity for dual stack hosts which >> > > MIP6 session => MIP6/NEMO session > OK. > > >> attach to IPv4 access networks. Additionally provide a mechanism >> for carrying IPv4 packets via the Home agent for MIP6 capable >> dual-stack hosts. >> > > MIP6/NEMO capable > OK... > >> (A.2) A protocol based solution for enhancing the reliability of home >> agents and a method to force a host to switch home agents. >> > > host => host/router > OK. > >> A mechanism to force an MN to switch the HA that is currently >> serving it. This is required in deployments where the HA needs to >> be taken offline for maintenance. >> > > > No more comments on the remaining text. > Thanks. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Jul 25 18:30:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpMq-00041R-GZ; Wed, 25 Jul 2007 18:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpMo-00041M-Rh for mext@ietf.org; Wed, 25 Jul 2007 18:30:02 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDpMo-0006AE-CX for mext@ietf.org; Wed, 25 Jul 2007 18:30:02 -0400 Received: from dhcp-15f9.ietf69.org (dhcp-15f9.ietf69.org [130.129.21.249]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l6PMTwi9008180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 00:30:01 +0200 Date: Thu, 26 Jul 2007 00:29:58 +0200 From: Thierry Ernst To: mext@ietf.org Subject: Re: [MEXT] charter - final version Message-Id: <20070726002958.c0b9e1e5.thierry.ernst@inria.fr> In-Reply-To: <46A78493.4050703@piuha.net> References: <46A6268E.2020003@piuha.net> <20070724203553.4ce9be07.thierry.ernst@inria.fr> <46A78493.4050703@piuha.net> Organization: INRIA X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.10.6; powerpc-apple-darwin8.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46A7CEE7.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org >> I would also remove "built on top of Mobile IPv6" as it would suggest >> there is a dependance between MIPv6 and NEMO, which is not the case. >> Both protocols are based on the same concepts and use the same >> mechanisms. >> > >Now I lost you. Here's what RFC 3963 says in the abstract: "The protocol is >an extension of Mobile IPv6 and ..." OK, but I wasn't the one who wrote it otherwise this sentence would have been turned in a different way ;-) >> What about RFC >> 3776 ? >> > >Taken over by 4877, or at least that is imho the one that >we should focus on. OK > >> Regarding NEMO, shouldn't we also add somewhere on the charter RFC 4885 >> to RFC 4889 as the newbie wouldn't have any hint they exist ? These are >> important informational documents to justify the work being done and >> the direction of the WG (something that is always missing in WG >> charters). >> > >The list is not intended to be exhaustive but point to the main documents. Sure, but RFC 3963 was published long time before the other documents, so one reading RFC 3963 won't have a clue about the other RFCs if one haven't follow the history behind MEXT. This is were IETF WG charter pages are lacking (reference to prior published work when it was not published but the same group. Since MEXT is new, all the history behind MIP6 and NEMP WGs will be unknown to the newbie. How to improve this ? May be one way is to keep the NEMO, MIP6 and MONAMI6 WG chartes for historical purposes, and have a pointer from the new charter. But this is something we don't do currently, so I don't expect the MEXT charter to do it as it would have to be discussed with the IETF secretariat or whowever. To conclude, I would like to thank Jari who has done most of the work of merging the 3 charters into 1. Thanks also for having kicked us up many times to meet deadlines ;-) Thierry. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext