From jouni.nospam@gmail.com Mon Jan 2 02:44:55 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38EB21F8D5A for ; Mon, 2 Jan 2012 02:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqoUOS7m2mGc for ; Mon, 2 Jan 2012 02:44:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7CC21F8D54 for ; Mon, 2 Jan 2012 02:44:54 -0800 (PST) Received: by werb14 with SMTP id b14so8711141wer.31 for ; Mon, 02 Jan 2012 02:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tx/wZpVkUt/kbrVG36hbCBrlpKNIQ/cnLHpY6LC91Vs=; b=NkpGO07uUwoOLSw4Ob2Sd5ckClqsXIZHsJr+3BRqrJYKDokM9QQLKBsrje9bHwkv6e rDtFSp31zH3OKWUiebSqJbI4JMT1QHTWGHsCSSWKTnwjqXAxERR7NdB8jRlVvWIfqG+s eRZu1QaWCAxgQ6K2BP6MprMo8uj+o/DpddAi4= Received: by 10.216.139.156 with SMTP id c28mr32172160wej.34.1325501091804; Mon, 02 Jan 2012 02:44:51 -0800 (PST) Received: from [10.255.134.110] ([192.100.123.77]) by mx.google.com with ESMTPS id q5sm1304085wbo.8.2012.01.02.02.44.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 02:44:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Mon, 2 Jan 2012 12:44:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> To: liu dapeng X-Mailer: Apple Mail (2.1084) Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 10:44:55 -0000 Dapeng, Below is the charter text that was submitted to the next IESG. Does it = cover all your concerns? - JOuni Distributed Mobility Management (DMM) ------------------------------------- Charter Current Status: Active Chairs: Julien Laganier Jouni Korhonen Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: The Distributed Mobility Management (DMM) working group specifies IP mobility, access network and routing solutions, which allow for setting up IP networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to manage IP mobility sessions. The distributed mobility management solutions aim for transparency above the IP layer, including maintenance of active transport level sessions as mobile hosts or entire mobile networks change their point of attachment to the Internet. The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. Solutions may also focus specifically on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions. The distributed mobility management solutions primarily target IPv6 Deployment and should not be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. At least IPv6 is assumed to be present in both the mobile host/router and the access networks. Independent of the distributed mobility management solution, backward compatibility must be maintained. If the network or the mobile host/router do not support the distributed mobility management enabling protocol, nothing should break. Work items related to the distributed mobility management include: o Solution Requirements: Define precisely the problem of distributed mobility management and identity the requirements for a distributed mobility management solution. o Best practices: Document best practices for the deployment of = existing mobility protocols in a distributed mobility management environment. o Gap Analysis and extensions: identify the limitations in the best current practices with respect to providing the expected = functionality. o If limitations are identified as part of the above deliverable, specify extensions to existing protocols that removes these limitations within a distributed mobility management environment. Goals and Milestones: Aug 2012 - Submit I-D 'Solution Requirements' as a working group document. To be Informational RFC. Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working group document. To be Informational RFC. Nov 2012 - Evaluate the need for additional working group document(s) for extensions to fill the identified gaps. Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Jan 2013 - Submit I-D 'Best practices ' to the IESG forvconsideration as an Informational RFC. Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. Mar 2013 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group. On Dec 21, 2011, at 7:53 PM, liu dapeng wrote: > 2011/12/14, jouni korhonen : >> Folks, >>=20 >> We have been working on a charter text from DMM based on the initial = goal >> setting and the input we received during the Taipei meeting. Note = that this >> is the first draft and now we are soliciting for input. >>=20 >> - Jouni & Julien >>=20 >>=20 >> = ------------------------------------------------------------------------- >>=20 >> Distributed Mobility Management (DMM) >> ------------------------------------- >>=20 >> Charter >>=20 >> Current Status: Active >>=20 >> Chairs: >> Julien Laganier >> Jouni Korhonen >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Jari Arkko >>=20 >> Mailing Lists: >> General Discussion: mext@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/mext >> Archive: http://www.ietf.org/mail-archive/web/mext >>=20 >> Description of Working Group: >>=20 >> The Distributed Mobility Management (DMM) working group specifies IP >> mobility, access network and routing solutions, which allow for >> setting up IP networks so that traffic is distributed in an >> optimal way and does not rely on centrally deployed anchors to = manage >> IP mobility sessions. The distributed mobility management solutions >> aim for transparency above the IP layer, including maintenance of >> active transport level sessions as mobile hosts or entire mobile >> networks change their point of attachment to the Internet. >=20 > [Comment] >=20 > This point seems not specific to DMM, since all IP mobility protocol > aim for transparency above IP layer. And the point (maintenance of > active transport level sessions) contradicts with : =93it is not a > strict requirement to maintenance stable IP address=94 (later in the > charter). Or does it mean that DMM aims to develop solutions that can > maintain active transport level sessions without maintaining stable IP > address? >=20 >=20 >> The protocol solutions should be enhancements to existing IP = mobility >> protocols, either host- or network-based, such as Mobile IPv6 >> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and >> NEMO [RFC3963]. Alternatively, the distributed mobility management >> solution can be transparent to any underlying IP mobility protocol. >> Although the maintenance of stable home address(es) and/or = prefix(es) >> and upper level sessions is a desirable goal when mobile = hosts/routers >> change their point of attachment to the Internet, it is not a strict >> requirement. >=20 > [comment] > please refer the previous comment. > I think we should not exclude the solutions that can maintain stable = IP address. >=20 >=20 >=20 > Mobile hosts/routers should not assume that IP >> addressing including home address(es) and/or home network prefix(es) >> remain the same throughout the entire upper level session lifetime. >>=20 >> The distributed mobility management solutions primarily target IPv6 >> Deployment and should not be tailored specifically to support IPv4, >> in particular in situations where private IPv4 addresses and/or NATs >> are used. >=20 > [comment] Since DMM remains backward compatibility with existing IP > mobility protocol. And DSMIPv6 can support IPv4, should we also need > to keep IPv4 support in DMM? >=20 >=20 > At least IPv6 is assumed to be present in both the mobile >> host/router and the access networks. Independent of the distributed >> mobility management solution, backward compatibility must be >> maintained. If the network or the mobile host/router do not support >> the distributed mobility management enabling protocol, nothing = should >> break. >>=20 >> Work items related to the distributed mobility management include: >>=20 >> o Solution Requirements: Define precisely the problem of distributed >> mobility management and identity the requirements for a = distributed >> mobility management solution. >>=20 >> o Best practices and Gap Analysis: Document best practices for the >> deployment of existing mobility protocols in a distributed = mobility >> management environment and identify the limitations of each such >> approach with respect to fulfillment of the solution requirements. >>=20 >> o If limitations are identified as part of the above deliverable, >> specify extensions to existing protocols that removes these >> limitations within a distributed mobility management environment. >>=20 >> Goals and Milestones: >>=20 >> Aug 2012 - Submit I-D 'Solution Requirements' as a working >> group document. To be Informational RFC. >> Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working >> group document. To be Informational RFC. >> Nov 2012 - Evaluate the need for additional working group = document(s) >> for extensions to fill the identified gaps. >> Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for >> consideration as an Informational RFC. >> Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG = for >> consideration as an Informational RFC. >> Mar 2013 - Conclude the working group or re-charter. >>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu From Fred.L.Templin@boeing.com Tue Jan 3 09:43:54 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7B211E8087 for ; Tue, 3 Jan 2012 09:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbryw611AcRv for ; Tue, 3 Jan 2012 09:43:53 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8676411E808C for ; Tue, 3 Jan 2012 09:43:13 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q03HhbaU001019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Jan 2012 11:43:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q03Hh4O1020513 for ; Tue, 3 Jan 2012 09:43:04 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q03Hgs9o020010 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 3 Jan 2012 09:42:55 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 3 Jan 2012 09:42:54 -0800 From: "Templin, Fred L" To: jouni korhonen , liu dapeng Date: Tue, 3 Jan 2012 09:42:53 -0800 Thread-Topic: [MEXT] The first proposal for the DMM charter Thread-Index: AczJO5QO+3UtHKROT4WgTDLQ7butnABAt06Q Message-ID: References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> In-Reply-To: <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "julien.ietf@gmail.com Laganier" , "mext@ietf.org" Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:43:54 -0000 Hi Jouni,=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of jouni korhonen > Sent: Monday, January 02, 2012 2:45 AM > To: liu dapeng > Cc: julien.ietf@gmail.com Laganier; mext@ietf.org > Subject: Re: [MEXT] The first proposal for the DMM charter >=20 > Dapeng, >=20 > Below is the charter text that was submitted to the next=20 > IESG. Does it cover all your concerns? >=20 > - JOuni >=20 >=20 >=20 > Distributed Mobility Management (DMM) > ------------------------------------- >=20 > Charter >=20 > Current Status: Active >=20 > Chairs: > Julien Laganier > Jouni Korhonen >=20 > Internet Area Directors: > Ralph Droms > Jari Arkko >=20 > Internet Area Advisor: > Jari Arkko >=20 > Mailing Lists: > General Discussion: mext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mext > Archive: http://www.ietf.org/mail-archive/web/mext >=20 > Description of Working Group: >=20 > The Distributed Mobility Management (DMM) working group specifies IP > mobility, access network and routing solutions, which allow for > setting up IP networks so that traffic is distributed in an > optimal way and does not rely on centrally deployed anchors to manage > IP mobility sessions. The distributed mobility management solutions > aim for transparency above the IP layer, including maintenance of > active transport level sessions as mobile hosts or entire mobile > networks change their point of attachment to the Internet. >=20 > The protocol solutions should be based on existing IP mobility > protocols, either host- or network-based, such as Mobile IPv6 > [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO=20 > [RFC3963]. I don't understand the "should be based on existing IP mobility protocols". IRON for example provides an alternative mobility management solution which I believe has significant advantages over other approaches: http://tools.ietf.org/html/draft-templin-ironbis-10 Thanks - Fred fred.l.templin@boeing.com > Solutions may also focus specifically on managing the use of care-of > versus home addresses in an efficient manner for different types of > communications. > > Although the maintenance of stable home address(es) and/or prefix(es) > and upper level sessions is a desirable goal when mobile=20 > hosts/routers > change their point of attachment to the Internet, it is not a strict > requirement. Mobile hosts/routers should not assume that IP > addressing including home address(es) and/or home network prefix(es) > remain the same throughout the entire upper level session lifetime, > or that support for mobility functions is provided on the=20 > network side > in all conditions. >=20 > The distributed mobility management solutions primarily target IPv6 > Deployment and should not be tailored specifically to support IPv4, > in particular in situations where private IPv4 addresses and/or NATs > are used. At least IPv6 is assumed to be present in both the mobile > host/router and the access networks. Independent of the distributed > mobility management solution, backward compatibility must be > maintained. If the network or the mobile host/router do not support > the distributed mobility management enabling protocol, nothing should > break. >=20 > Work items related to the distributed mobility management include: >=20 > o Solution Requirements: Define precisely the problem of distributed > mobility management and identity the requirements for a distributed > mobility management solution. >=20 > o Best practices: Document best practices for the deployment=20 > of existing > mobility protocols in a distributed mobility management=20 > environment. >=20 > o Gap Analysis and extensions: identify the limitations in the best > current practices with respect to providing the expected=20 > functionality. >=20 > o If limitations are identified as part of the above deliverable, > specify extensions to existing protocols that removes these > limitations within a distributed mobility management environment. >=20 > Goals and Milestones: >=20 > Aug 2012 - Submit I-D 'Solution Requirements' as a working group > document. To be Informational RFC. > Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working > group document. To be Informational RFC. > Nov 2012 - Evaluate the need for additional working group document(s) > for extensions to fill the identified gaps. > Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for > consideration as an Informational RFC. > Jan 2013 - Submit I-D 'Best practices ' to the IESG forvconsideration > as an Informational RFC. > Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as > an Informational RFC. > Mar 2013 - Evaluate the need for further work based on the identified > gaps and revise the milestones and/or the charter of the > group. >=20 >=20 >=20 >=20 > On Dec 21, 2011, at 7:53 PM, liu dapeng wrote: >=20 > > 2011/12/14, jouni korhonen : > >> Folks, > >>=20 > >> We have been working on a charter text from DMM based on=20 > the initial goal > >> setting and the input we received during the Taipei=20 > meeting. Note that this > >> is the first draft and now we are soliciting for input. > >>=20 > >> - Jouni & Julien > >>=20 > >>=20 > >>=20 > -------------------------------------------------------------- > ----------- > >>=20 > >> Distributed Mobility Management (DMM) > >> ------------------------------------- > >>=20 > >> Charter > >>=20 > >> Current Status: Active > >>=20 > >> Chairs: > >> Julien Laganier > >> Jouni Korhonen > >>=20 > >> Internet Area Directors: > >> Ralph Droms > >> Jari Arkko > >>=20 > >> Internet Area Advisor: > >> Jari Arkko > >>=20 > >> Mailing Lists: > >> General Discussion: mext@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/mext > >> Archive: http://www.ietf.org/mail-archive/web/mext > >>=20 > >> Description of Working Group: > >>=20 > >> The Distributed Mobility Management (DMM) working group=20 > specifies IP > >> mobility, access network and routing solutions, which allow for > >> setting up IP networks so that traffic is distributed in an > >> optimal way and does not rely on centrally deployed=20 > anchors to manage > >> IP mobility sessions. The distributed mobility management=20 > solutions > >> aim for transparency above the IP layer, including maintenance of > >> active transport level sessions as mobile hosts or entire mobile > >> networks change their point of attachment to the Internet. > >=20 > > [Comment] > >=20 > > This point seems not specific to DMM, since all IP mobility protocol > > aim for transparency above IP layer. And the point (maintenance of > > active transport level sessions) contradicts with : "it is not a > > strict requirement to maintenance stable IP address" (later in the > > charter). Or does it mean that DMM aims to develop=20 > solutions that can > > maintain active transport level sessions without=20 > maintaining stable IP > > address? > >=20 > >=20 > >> The protocol solutions should be enhancements to existing=20 > IP mobility > >> protocols, either host- or network-based, such as Mobile IPv6 > >> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and > >> NEMO [RFC3963]. Alternatively, the distributed mobility management > >> solution can be transparent to any underlying IP mobility=20 > protocol. > >> Although the maintenance of stable home address(es)=20 > and/or prefix(es) > >> and upper level sessions is a desirable goal when mobile=20 > hosts/routers > >> change their point of attachment to the Internet, it is=20 > not a strict > >> requirement. > >=20 > > [comment] > > please refer the previous comment. > > I think we should not exclude the solutions that can=20 > maintain stable IP address. > >=20 > >=20 > >=20 > > Mobile hosts/routers should not assume that IP > >> addressing including home address(es) and/or home network=20 > prefix(es) > >> remain the same throughout the entire upper level session=20 > lifetime. > >>=20 > >> The distributed mobility management solutions primarily=20 > target IPv6 > >> Deployment and should not be tailored specifically to=20 > support IPv4, > >> in particular in situations where private IPv4 addresses=20 > and/or NATs > >> are used. > >=20 > > [comment] Since DMM remains backward compatibility with existing IP > > mobility protocol. And DSMIPv6 can support IPv4, should we also need > > to keep IPv4 support in DMM? > >=20 > >=20 > > At least IPv6 is assumed to be present in both the mobile > >> host/router and the access networks. Independent of the=20 > distributed > >> mobility management solution, backward compatibility must be > >> maintained. If the network or the mobile host/router do=20 > not support > >> the distributed mobility management enabling protocol,=20 > nothing should > >> break. > >>=20 > >> Work items related to the distributed mobility management include: > >>=20 > >> o Solution Requirements: Define precisely the problem of=20 > distributed > >> mobility management and identity the requirements for a=20 > distributed > >> mobility management solution. > >>=20 > >> o Best practices and Gap Analysis: Document best practices for the > >> deployment of existing mobility protocols in a=20 > distributed mobility > >> management environment and identify the limitations of each such > >> approach with respect to fulfillment of the solution=20 > requirements. > >>=20 > >> o If limitations are identified as part of the above deliverable, > >> specify extensions to existing protocols that removes these > >> limitations within a distributed mobility management=20 > environment. > >>=20 > >> Goals and Milestones: > >>=20 > >> Aug 2012 - Submit I-D 'Solution Requirements' as a working > >> group document. To be Informational RFC. > >> Aug 2012 - Submit I-D 'Best practices and Gap Analysis'=20 > as a working > >> group document. To be Informational RFC. > >> Nov 2012 - Evaluate the need for additional working group=20 > document(s) > >> for extensions to fill the identified gaps. > >> Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for > >> consideration as an Informational RFC. > >> Jan 2013 - Submit I-D 'Best practices and Gap Analysis'=20 > to the IESG for > >> consideration as an Informational RFC. > >> Mar 2013 - Conclude the working group or re-charter. > >>=20 > >>=20 > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >>=20 > >=20 > >=20 > > --=20 > >=20 > > ------ > > Best Regards, > > Dapeng Liu >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From wwwrun@rfc-editor.org Thu Jan 5 02:26:22 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1479C21F87E3 for ; Thu, 5 Jan 2012 02:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6BBTcvGYRIE for ; Thu, 5 Jan 2012 02:26:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A844221F87D8 for ; Thu, 5 Jan 2012 02:26:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4BFA8B1E003; Thu, 5 Jan 2012 02:24:05 -0800 (PST) To: rdroms@cisco.com, pthubert@cisco.com, fdupont@isc.org, Wassim.Haddad@ericsson.com, cjbc@it.uc3m.es, rdroms.ietf@gmail.com, jari.arkko@piuha.net, julien.ietf@gmail.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20120105102405.4BFA8B1E003@rfc-editor.org> Date: Thu, 5 Jan 2012 02:24:05 -0800 (PST) Cc: rfc-editor@rfc-editor.org, mext@ietf.org, sofiane.imadali@cea.fr Subject: [MEXT] [Editorial Errata Reported] RFC6276 (3078) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:26:22 -0000 The following errata report has been submitted for RFC6276, "DHCPv6 Prefix Delegation for Network Mobility (NEMO)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6276&eid=3078 -------------------------------------- Type: Editorial Reported by: Sofiane IMADALI Section: 3.2 Original Text ------------- Figure 3: Signaling sequence for the case the home agent is at home Corrected Text -------------- Figure 3: Signaling sequence for the case the Mobile Router is at home Notes ----- The figure name is not corresponding to the section's name. In addition, the home agent is always at home. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6276 (draft-ietf-mext-nemo-pd-07) -------------------------------------- Title : DHCPv6 Prefix Delegation for Network Mobility (NEMO) Publication Date : July 2011 Author(s) : R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos Category : PROPOSED STANDARD Source : Mobility EXTensions for IPv6 Area : Internet Stream : IETF Verifying Party : IESG From alexandru.petrescu@gmail.com Thu Jan 5 04:55:40 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BABE21F8826 for ; Thu, 5 Jan 2012 04:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7auNwMbGvDx for ; Thu, 5 Jan 2012 04:55:39 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 68D8721F8824 for ; Thu, 5 Jan 2012 04:55:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id q05CtbZO032571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Jan 2012 13:55:37 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q05CtbWm027262 for ; Thu, 5 Jan 2012 13:55:37 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id q05CtaLE007179 for ; Thu, 5 Jan 2012 13:55:37 +0100 Message-ID: <4F059DAF.6060407@gmail.com> Date: Thu, 05 Jan 2012 13:55:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mext@ietf.org References: <20120105102405.4BFA8B1E003@rfc-editor.org> In-Reply-To: <20120105102405.4BFA8B1E003@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] [Editorial Errata Reported] RFC6276 (3078) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 12:55:40 -0000 I agree with this Errata : the HA is always at home and the figure title should say "Signaling sequence for the case the Mobile Router is at home" (and not HA at home). Alex Le 05/01/2012 11:24, RFC Errata System a écrit : > > The following errata report has been submitted for RFC6276, > "DHCPv6 Prefix Delegation for Network Mobility (NEMO)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6276&eid=3078 > > -------------------------------------- > Type: Editorial > Reported by: Sofiane IMADALI > > Section: 3.2 > > Original Text > ------------- > Figure 3: Signaling sequence for the case the home agent is at home > > > Corrected Text > -------------- > Figure 3: Signaling sequence for the case the Mobile Router is at home > > Notes > ----- > The figure name is not corresponding to the section's name. In addition, the home agent is always at home. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6276 (draft-ietf-mext-nemo-pd-07) > -------------------------------------- > Title : DHCPv6 Prefix Delegation for Network Mobility (NEMO) > Publication Date : July 2011 > Author(s) : R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos > Category : PROPOSED STANDARD > Source : Mobility EXTensions for IPv6 > Area : Internet > Stream : IETF > Verifying Party : IESG > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From cjbc@it.uc3m.es Thu Jan 5 10:51:29 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2BD21F87ED for ; Thu, 5 Jan 2012 10:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwrHkOHY6Gr7 for ; Thu, 5 Jan 2012 10:51:28 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id A84B621F8864 for ; Thu, 5 Jan 2012 10:51:24 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 87EA075A630; Thu, 5 Jan 2012 19:51:21 +0100 (CET) Message-ID: <1325789481.3890.63.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu Date: Thu, 05 Jan 2012 19:51:21 +0100 In-Reply-To: <4F059DAF.6060407@gmail.com> References: <20120105102405.4BFA8B1E003@rfc-editor.org> <4F059DAF.6060407@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YGLxMeXfHiODGIvi+xr0" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18628.000 Cc: mext@ietf.org Subject: Re: [MEXT] [Editorial Errata Reported] RFC6276 (3078) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:51:29 -0000 --=-YGLxMeXfHiODGIvi+xr0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, I also agree, and you can blame me for not noticing it... :( Carlos On Thu, 2012-01-05 at 13:55 +0100, Alexandru Petrescu wrote: > I agree with this Errata : the HA is always at home and the figure title > should say "Signaling sequence for the case the Mobile Router is at > home" (and not HA at home). >=20 > Alex >=20 > Le 05/01/2012 11:24, RFC Errata System a =E9crit : > > > > The following errata report has been submitted for RFC6276, > > "DHCPv6 Prefix Delegation for Network Mobility (NEMO)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D6276&eid=3D3078 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Sofiane IMADALI > > > > Section: 3.2 > > > > Original Text > > ------------- > > Figure 3: Signaling sequence for the case the home agent is at home > > > > > > Corrected Text > > -------------- > > Figure 3: Signaling sequence for the case the Mobile Router is at home > > > > Notes > > ----- > > The figure name is not corresponding to the section's name. In addition= , the home agent is always at home. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6276 (draft-ietf-mext-nemo-pd-07) > > -------------------------------------- > > Title : DHCPv6 Prefix Delegation for Network Mobility (NE= MO) > > Publication Date : July 2011 > > Author(s) : R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Be= rnardos > > Category : PROPOSED STANDARD > > Source : Mobility EXTensions for IPv6 > > Area : Internet > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-YGLxMeXfHiODGIvi+xr0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8F8SkACgkQNdy6TdFwT2cAbQCfWD0RebqMe4YtuE53rZHBGyQ0 b5cAn2S7c1t1prDh6zqUMZj/Rf9ztsLF =XVjs -----END PGP SIGNATURE----- --=-YGLxMeXfHiODGIvi+xr0-- From cjbc@it.uc3m.es Thu Jan 5 10:52:09 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6E21F8603 for ; Thu, 5 Jan 2012 10:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxLCyn0F5HsL for ; Thu, 5 Jan 2012 10:52:05 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9968921F8879 for ; Thu, 5 Jan 2012 10:52:02 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 9827572C358; Thu, 5 Jan 2012 19:52:00 +0100 (CET) Message-ID: <1325789520.3890.64.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: RFC Errata System Date: Thu, 05 Jan 2012 19:52:00 +0100 In-Reply-To: <20120105102405.4BFA8B1E003@rfc-editor.org> References: <20120105102405.4BFA8B1E003@rfc-editor.org> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-wyl1FPi+7eC4qJsMugVD" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18628.000 Cc: jouni.korhonen@nsn.com, mext@ietf.org, rdroms@cisco.com, Wassim.Haddad@ericsson.com, jari.arkko@piuha.net, fdupont@isc.org, sofiane.imadali@cea.fr, julien.ietf@gmail.com Subject: Re: [MEXT] [Editorial Errata Reported] RFC6276 (3078) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:52:10 -0000 --=-wyl1FPi+7eC4qJsMugVD Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, I agree with the errata. Carlos On Thu, 2012-01-05 at 02:24 -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC6276, > "DHCPv6 Prefix Delegation for Network Mobility (NEMO)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6276&eid=3D3078 >=20 > -------------------------------------- > Type: Editorial > Reported by: Sofiane IMADALI >=20 > Section: 3.2 >=20 > Original Text > ------------- > Figure 3: Signaling sequence for the case the home agent is at home >=20 >=20 > Corrected Text > -------------- > Figure 3: Signaling sequence for the case the Mobile Router is at home >=20 > Notes > ----- > The figure name is not corresponding to the section's name. In addition, = the home agent is always at home. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6276 (draft-ietf-mext-nemo-pd-07) > -------------------------------------- > Title : DHCPv6 Prefix Delegation for Network Mobility (NEMO= ) > Publication Date : July 2011 > Author(s) : R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bern= ardos > Category : PROPOSED STANDARD > Source : Mobility EXTensions for IPv6 > Area : Internet > Stream : IETF > Verifying Party : IESG --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-wyl1FPi+7eC4qJsMugVD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8F8VAACgkQNdy6TdFwT2evcgCgtWI60bVdTuP7b+4hIcAmr6+Y HFEAn1MGAL2xJQsauuWSQh33Unlh/Bh5 =MMFV -----END PGP SIGNATURE----- --=-wyl1FPi+7eC4qJsMugVD-- From maxpassion@gmail.com Mon Jan 9 00:34:13 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125FA21F8694 for ; Mon, 9 Jan 2012 00:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiykPTo4wnCj for ; Mon, 9 Jan 2012 00:34:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2B7621F8692 for ; Mon, 9 Jan 2012 00:34:11 -0800 (PST) Received: by iabz21 with SMTP id z21so7013275iab.31 for ; Mon, 09 Jan 2012 00:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dAFR9aynRJnb3mf7+LTsY78ZkRLC4geMWB8EUXSijyw=; b=uf643kG5lGvclB+6ap/wOxnLJJBOkFczL7HULVxarMYcSvszv7Pbl69nTlAYWyA05h qBqRXyrkOr7yTHxILFL7UwUmOtM/sIn1aNhxAKvlevSmMp6zi9CWtk3u1S0sF2W1QNs1 bllQN+ro8DpffknT1a0owt1AdjlXk1yHdxldk= MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr15030312icw.50.1326098051423; Mon, 09 Jan 2012 00:34:11 -0800 (PST) Received: by 10.43.50.1 with HTTP; Mon, 9 Jan 2012 00:34:11 -0800 (PST) In-Reply-To: <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> Date: Mon, 9 Jan 2012 16:34:11 +0800 Message-ID: From: liu dapeng To: jouni korhonen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 08:34:13 -0000 Hi Jouni, This version solves the contradiction but it gives me the impression that DMM will only work on the solution that "managing the use of care-of/home addresses in an efficient manner ". Is that correct? Thanks. Dapeng Liu 2012/1/2, jouni korhonen : > Dapeng, > > Below is the charter text that was submitted to the next IESG. Does it co= ver > all your concerns? > > - JOuni > > > > Distributed Mobility Management (DMM) > ------------------------------------- > > Charter > > Current Status: Active > > Chairs: > Julien Laganier > Jouni Korhonen > > Internet Area Directors: > Ralph Droms > Jari Arkko > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: mext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/mext > Archive: http://www.ietf.org/mail-archive/web/mext > > Description of Working Group: > > The Distributed Mobility Management (DMM) working group specifies IP > mobility, access network and routing solutions, which allow for > setting up IP networks so that traffic is distributed in an > optimal way and does not rely on centrally deployed anchors to manage > IP mobility sessions. The distributed mobility management solutions > aim for transparency above the IP layer, including maintenance of > active transport level sessions as mobile hosts or entire mobile > networks change their point of attachment to the Internet. > > The protocol solutions should be based on existing IP mobility > protocols, either host- or network-based, such as Mobile IPv6 > [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. > Solutions may also focus specifically on managing the use of care-of > versus home addresses in an efficient manner for different types of > communications. > > Although the maintenance of stable home address(es) and/or prefix(es) > and upper level sessions is a desirable goal when mobile hosts/routers > change their point of attachment to the Internet, it is not a strict > requirement. Mobile hosts/routers should not assume that IP > addressing including home address(es) and/or home network prefix(es) > remain the same throughout the entire upper level session lifetime, > or that support for mobility functions is provided on the network side > in all conditions. > > The distributed mobility management solutions primarily target IPv6 > Deployment and should not be tailored specifically to support IPv4, > in particular in situations where private IPv4 addresses and/or NATs > are used. At least IPv6 is assumed to be present in both the mobile > host/router and the access networks. Independent of the distributed > mobility management solution, backward compatibility must be > maintained. If the network or the mobile host/router do not support > the distributed mobility management enabling protocol, nothing should > break. > > Work items related to the distributed mobility management include: > > o Solution Requirements: Define precisely the problem of distributed > mobility management and identity the requirements for a distributed > mobility management solution. > > o Best practices: Document best practices for the deployment of existing > mobility protocols in a distributed mobility management environment. > > o Gap Analysis and extensions: identify the limitations in the best > current practices with respect to providing the expected functionality= . > > o If limitations are identified as part of the above deliverable, > specify extensions to existing protocols that removes these > limitations within a distributed mobility management environment. > > Goals and Milestones: > > Aug 2012 - Submit I-D 'Solution Requirements' as a working group > document. To be Informational RFC. > Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working > group document. To be Informational RFC. > Nov 2012 - Evaluate the need for additional working group document(s) > for extensions to fill the identified gaps. > Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for > consideration as an Informational RFC. > Jan 2013 - Submit I-D 'Best practices ' to the IESG forvconsideration > as an Informational RFC. > Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as > an Informational RFC. > Mar 2013 - Evaluate the need for further work based on the identified > gaps and revise the milestones and/or the charter of the > group. > > > > > On Dec 21, 2011, at 7:53 PM, liu dapeng wrote: > >> 2011/12/14, jouni korhonen : >>> Folks, >>> >>> We have been working on a charter text from DMM based on the initial go= al >>> setting and the input we received during the Taipei meeting. Note that >>> this >>> is the first draft and now we are soliciting for input. >>> >>> - Jouni & Julien >>> >>> >>> -----------------------------------------------------------------------= -- >>> >>> Distributed Mobility Management (DMM) >>> ------------------------------------- >>> >>> Charter >>> >>> Current Status: Active >>> >>> Chairs: >>> Julien Laganier >>> Jouni Korhonen >>> >>> Internet Area Directors: >>> Ralph Droms >>> Jari Arkko >>> >>> Internet Area Advisor: >>> Jari Arkko >>> >>> Mailing Lists: >>> General Discussion: mext@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/mext >>> Archive: http://www.ietf.org/mail-archive/web/mext >>> >>> Description of Working Group: >>> >>> The Distributed Mobility Management (DMM) working group specifies IP >>> mobility, access network and routing solutions, which allow for >>> setting up IP networks so that traffic is distributed in an >>> optimal way and does not rely on centrally deployed anchors to manage >>> IP mobility sessions. The distributed mobility management solutions >>> aim for transparency above the IP layer, including maintenance of >>> active transport level sessions as mobile hosts or entire mobile >>> networks change their point of attachment to the Internet. >> >> [Comment] >> >> This point seems not specific to DMM, since all IP mobility protocol >> aim for transparency above IP layer. And the point (maintenance of >> active transport level sessions) contradicts with : =93it is not a >> strict requirement to maintenance stable IP address=94 (later in the >> charter). Or does it mean that DMM aims to develop solutions that can >> maintain active transport level sessions without maintaining stable IP >> address? >> >> >>> The protocol solutions should be enhancements to existing IP mobility >>> protocols, either host- or network-based, such as Mobile IPv6 >>> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and >>> NEMO [RFC3963]. Alternatively, the distributed mobility management >>> solution can be transparent to any underlying IP mobility protocol. >>> Although the maintenance of stable home address(es) and/or prefix(es) >>> and upper level sessions is a desirable goal when mobile hosts/routers >>> change their point of attachment to the Internet, it is not a strict >>> requirement. >> >> [comment] >> please refer the previous comment. >> I think we should not exclude the solutions that can maintain stable IP >> address. >> >> >> >> Mobile hosts/routers should not assume that IP >>> addressing including home address(es) and/or home network prefix(es) >>> remain the same throughout the entire upper level session lifetime. >>> >>> The distributed mobility management solutions primarily target IPv6 >>> Deployment and should not be tailored specifically to support IPv4, >>> in particular in situations where private IPv4 addresses and/or NATs >>> are used. >> >> [comment] Since DMM remains backward compatibility with existing IP >> mobility protocol. And DSMIPv6 can support IPv4, should we also need >> to keep IPv4 support in DMM? >> >> >> At least IPv6 is assumed to be present in both the mobile >>> host/router and the access networks. Independent of the distributed >>> mobility management solution, backward compatibility must be >>> maintained. If the network or the mobile host/router do not support >>> the distributed mobility management enabling protocol, nothing should >>> break. >>> >>> Work items related to the distributed mobility management include: >>> >>> o Solution Requirements: Define precisely the problem of distributed >>> mobility management and identity the requirements for a distributed >>> mobility management solution. >>> >>> o Best practices and Gap Analysis: Document best practices for the >>> deployment of existing mobility protocols in a distributed mobility >>> management environment and identify the limitations of each such >>> approach with respect to fulfillment of the solution requirements. >>> >>> o If limitations are identified as part of the above deliverable, >>> specify extensions to existing protocols that removes these >>> limitations within a distributed mobility management environment. >>> >>> Goals and Milestones: >>> >>> Aug 2012 - Submit I-D 'Solution Requirements' as a working >>> group document. To be Informational RFC. >>> Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working >>> group document. To be Informational RFC. >>> Nov 2012 - Evaluate the need for additional working group document(s) >>> for extensions to fill the identified gaps. >>> Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for >>> consideration as an Informational RFC. >>> Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG fo= r >>> consideration as an Informational RFC. >>> Mar 2013 - Conclude the working group or re-charter. >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu > > --=20 ------ Best Regards, Dapeng Liu From jouni.nospam@gmail.com Mon Jan 9 01:11:22 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D0C21F8694 for ; Mon, 9 Jan 2012 01:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MGANCs8LumN for ; Mon, 9 Jan 2012 01:11:21 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C186121F866E for ; Mon, 9 Jan 2012 01:11:20 -0800 (PST) Received: by laah2 with SMTP id h2so1484213laa.31 for ; Mon, 09 Jan 2012 01:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CmqaXkdne5d5cqCm0RRU2bB2gbkQNigAcW5UsbQfVsc=; b=bvB79aGCBr2cBBZQgsR0oPOTRltYQ80/fvJHkzfv5JbFcwDvkVbiIXKWjucBMGwP7m /e5AuVW43RKgGP6IH/ymZQATtuUMQ0kx5q2CgnT7cQZttYCFoSCk/UnwBXdSjlq5AzzM 18dBbjIetoVr/31+RsNzzryoLGOzR+cZZcr0k= Received: by 10.152.113.2 with SMTP id iu2mr6516048lab.26.1326100279699; Mon, 09 Jan 2012 01:11:19 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id nt7sm70343103lab.15.2012.01.09.01.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 01:11:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Mon, 9 Jan 2012 11:11:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FFDE10F-CF54-47AA-B018-F3C6D585A2E3@gmail.com> References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> To: liu dapeng X-Mailer: Apple Mail (2.1084) Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:11:22 -0000 Hi Dapeng, On Jan 9, 2012, at 10:34 AM, liu dapeng wrote: > Hi Jouni, >=20 > This version solves the contradiction but it gives me the impression > that DMM will only work on the solution that "managing the use of > care-of/home addresses in an efficient manner ". Is that correct? No. The beginning sentence you cited says: "Solutions may also focus specifically on managing the use of care-of address.." Current text "may also focus" does not restrict the scope only for CoA/HoA = management. - Jouni >=20 > Thanks. > Dapeng Liu >=20 >=20 > 2012/1/2, jouni korhonen : >> Dapeng, >>=20 >> Below is the charter text that was submitted to the next IESG. Does = it cover >> all your concerns? >>=20 >> - JOuni >>=20 >>=20 >>=20 >> Distributed Mobility Management (DMM) >> ------------------------------------- >>=20 >> Charter >>=20 >> Current Status: Active >>=20 >> Chairs: >> Julien Laganier >> Jouni Korhonen >>=20 >> Internet Area Directors: >> Ralph Droms >> Jari Arkko >>=20 >> Internet Area Advisor: >> Jari Arkko >>=20 >> Mailing Lists: >> General Discussion: mext@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/mext >> Archive: http://www.ietf.org/mail-archive/web/mext >>=20 >> Description of Working Group: >>=20 >> The Distributed Mobility Management (DMM) working group specifies IP >> mobility, access network and routing solutions, which allow for >> setting up IP networks so that traffic is distributed in an >> optimal way and does not rely on centrally deployed anchors to manage >> IP mobility sessions. The distributed mobility management solutions >> aim for transparency above the IP layer, including maintenance of >> active transport level sessions as mobile hosts or entire mobile >> networks change their point of attachment to the Internet. >>=20 >> The protocol solutions should be based on existing IP mobility >> protocols, either host- or network-based, such as Mobile IPv6 >> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO = [RFC3963]. >> Solutions may also focus specifically on managing the use of care-of >> versus home addresses in an efficient manner for different types of >> communications. >>=20 >> Although the maintenance of stable home address(es) and/or prefix(es) >> and upper level sessions is a desirable goal when mobile = hosts/routers >> change their point of attachment to the Internet, it is not a strict >> requirement. Mobile hosts/routers should not assume that IP >> addressing including home address(es) and/or home network prefix(es) >> remain the same throughout the entire upper level session lifetime, >> or that support for mobility functions is provided on the network = side >> in all conditions. >>=20 >> The distributed mobility management solutions primarily target IPv6 >> Deployment and should not be tailored specifically to support IPv4, >> in particular in situations where private IPv4 addresses and/or NATs >> are used. At least IPv6 is assumed to be present in both the mobile >> host/router and the access networks. Independent of the distributed >> mobility management solution, backward compatibility must be >> maintained. If the network or the mobile host/router do not support >> the distributed mobility management enabling protocol, nothing should >> break. >>=20 >> Work items related to the distributed mobility management include: >>=20 >> o Solution Requirements: Define precisely the problem of distributed >> mobility management and identity the requirements for a distributed >> mobility management solution. >>=20 >> o Best practices: Document best practices for the deployment of = existing >> mobility protocols in a distributed mobility management = environment. >>=20 >> o Gap Analysis and extensions: identify the limitations in the best >> current practices with respect to providing the expected = functionality. >>=20 >> o If limitations are identified as part of the above deliverable, >> specify extensions to existing protocols that removes these >> limitations within a distributed mobility management environment. >>=20 >> Goals and Milestones: >>=20 >> Aug 2012 - Submit I-D 'Solution Requirements' as a working group >> document. To be Informational RFC. >> Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working >> group document. To be Informational RFC. >> Nov 2012 - Evaluate the need for additional working group document(s) >> for extensions to fill the identified gaps. >> Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for >> consideration as an Informational RFC. >> Jan 2013 - Submit I-D 'Best practices ' to the IESG forvconsideration >> as an Informational RFC. >> Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as >> an Informational RFC. >> Mar 2013 - Evaluate the need for further work based on the identified >> gaps and revise the milestones and/or the charter of the >> group. >>=20 >>=20 >>=20 >>=20 >> On Dec 21, 2011, at 7:53 PM, liu dapeng wrote: >>=20 >>> 2011/12/14, jouni korhonen : >>>> Folks, >>>>=20 >>>> We have been working on a charter text from DMM based on the = initial goal >>>> setting and the input we received during the Taipei meeting. Note = that >>>> this >>>> is the first draft and now we are soliciting for input. >>>>=20 >>>> - Jouni & Julien >>>>=20 >>>>=20 >>>> = ------------------------------------------------------------------------- >>>>=20 >>>> Distributed Mobility Management (DMM) >>>> ------------------------------------- >>>>=20 >>>> Charter >>>>=20 >>>> Current Status: Active >>>>=20 >>>> Chairs: >>>> Julien Laganier >>>> Jouni Korhonen >>>>=20 >>>> Internet Area Directors: >>>> Ralph Droms >>>> Jari Arkko >>>>=20 >>>> Internet Area Advisor: >>>> Jari Arkko >>>>=20 >>>> Mailing Lists: >>>> General Discussion: mext@ietf.org >>>> To Subscribe: https://www.ietf.org/mailman/listinfo/mext >>>> Archive: http://www.ietf.org/mail-archive/web/mext >>>>=20 >>>> Description of Working Group: >>>>=20 >>>> The Distributed Mobility Management (DMM) working group specifies = IP >>>> mobility, access network and routing solutions, which allow for >>>> setting up IP networks so that traffic is distributed in an >>>> optimal way and does not rely on centrally deployed anchors to = manage >>>> IP mobility sessions. The distributed mobility management solutions >>>> aim for transparency above the IP layer, including maintenance of >>>> active transport level sessions as mobile hosts or entire mobile >>>> networks change their point of attachment to the Internet. >>>=20 >>> [Comment] >>>=20 >>> This point seems not specific to DMM, since all IP mobility protocol >>> aim for transparency above IP layer. And the point (maintenance of >>> active transport level sessions) contradicts with : =93it is not a >>> strict requirement to maintenance stable IP address=94 (later in the >>> charter). Or does it mean that DMM aims to develop solutions that = can >>> maintain active transport level sessions without maintaining stable = IP >>> address? >>>=20 >>>=20 >>>> The protocol solutions should be enhancements to existing IP = mobility >>>> protocols, either host- or network-based, such as Mobile IPv6 >>>> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and >>>> NEMO [RFC3963]. Alternatively, the distributed mobility management >>>> solution can be transparent to any underlying IP mobility protocol. >>>> Although the maintenance of stable home address(es) and/or = prefix(es) >>>> and upper level sessions is a desirable goal when mobile = hosts/routers >>>> change their point of attachment to the Internet, it is not a = strict >>>> requirement. >>>=20 >>> [comment] >>> please refer the previous comment. >>> I think we should not exclude the solutions that can maintain stable = IP >>> address. >>>=20 >>>=20 >>>=20 >>> Mobile hosts/routers should not assume that IP >>>> addressing including home address(es) and/or home network = prefix(es) >>>> remain the same throughout the entire upper level session lifetime. >>>>=20 >>>> The distributed mobility management solutions primarily target IPv6 >>>> Deployment and should not be tailored specifically to support IPv4, >>>> in particular in situations where private IPv4 addresses and/or = NATs >>>> are used. >>>=20 >>> [comment] Since DMM remains backward compatibility with existing IP >>> mobility protocol. And DSMIPv6 can support IPv4, should we also need >>> to keep IPv4 support in DMM? >>>=20 >>>=20 >>> At least IPv6 is assumed to be present in both the mobile >>>> host/router and the access networks. Independent of the distributed >>>> mobility management solution, backward compatibility must be >>>> maintained. If the network or the mobile host/router do not support >>>> the distributed mobility management enabling protocol, nothing = should >>>> break. >>>>=20 >>>> Work items related to the distributed mobility management include: >>>>=20 >>>> o Solution Requirements: Define precisely the problem of = distributed >>>> mobility management and identity the requirements for a = distributed >>>> mobility management solution. >>>>=20 >>>> o Best practices and Gap Analysis: Document best practices for the >>>> deployment of existing mobility protocols in a distributed = mobility >>>> management environment and identify the limitations of each such >>>> approach with respect to fulfillment of the solution = requirements. >>>>=20 >>>> o If limitations are identified as part of the above deliverable, >>>> specify extensions to existing protocols that removes these >>>> limitations within a distributed mobility management environment. >>>>=20 >>>> Goals and Milestones: >>>>=20 >>>> Aug 2012 - Submit I-D 'Solution Requirements' as a working >>>> group document. To be Informational RFC. >>>> Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a = working >>>> group document. To be Informational RFC. >>>> Nov 2012 - Evaluate the need for additional working group = document(s) >>>> for extensions to fill the identified gaps. >>>> Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for >>>> consideration as an Informational RFC. >>>> Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG = for >>>> consideration as an Informational RFC. >>>> Mar 2013 - Conclude the working group or re-charter. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> ------ >>> Best Regards, >>> Dapeng Liu >>=20 >>=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu From jouni.nospam@gmail.com Mon Jan 9 02:43:56 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F0E21F86EC for ; Mon, 9 Jan 2012 02:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vG820OsSWE63 for ; Mon, 9 Jan 2012 02:43:56 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3C7F21F8675 for ; Mon, 9 Jan 2012 02:43:55 -0800 (PST) Received: by laah2 with SMTP id h2so1529372laa.31 for ; Mon, 09 Jan 2012 02:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HXKdl04hz+DaCjLAYAUMR/9BYvSp9ZO+JubnOLqZTMQ=; b=hdi4HuCWAscunBJwGLV1ueFUu1EFjo93XwzC/G6ZgNGHW0bFw16p/c4k2fkkxyAIv8 Phh6XcCkle62kYsLCFHyfKHcxYtBMLmBD2C60pUxBryUTw75PwCz32KZrlhsejEWd7J/ sY3cGwhzluNTOPGOFsPoFKMEvmF79oFK2o2P4= Received: by 10.152.111.200 with SMTP id ik8mr6528019lab.43.1326105828831; Mon, 09 Jan 2012 02:43:48 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id lo13sm5028028lab.8.2012.01.09.02.43.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 02:43:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 9 Jan 2012 12:43:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: <48813412-2A2D-4611-8723-BCE1A548BD59@gmail.com> References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) Cc: "julien.ietf@gmail.com Laganier" , mext@ietf.org Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:43:56 -0000 Fred, On Jan 3, 2012, at 7:42 PM, Templin, Fred L wrote: >> >> The protocol solutions should be based on existing IP mobility >> protocols, either host- or network-based, such as Mobile IPv6 >> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO >> [RFC3963]. > > I don't understand the "should be based on existing IP > mobility protocols". IRON for example provides an > alternative mobility management solution which I believe > has significant advantages over other approaches: > > http://tools.ietf.org/html/draft-templin-ironbis-10 > > Thanks - Fred > fred.l.templin@boeing.com I admit I have not followed much of the IRON work. However, the overal idea is that if your solution needs specific bindings to existing mobility providing protocol(s), then your choices more or less are listed above (or some existing flavor/variation of those). If your solution does not depend on any specific mobility protocol i.e., does not require specification of protocol specific bindings, then you are free to deploy it on top of anything, including IRON. - Jouni From Fred.L.Templin@boeing.com Mon Jan 9 08:53:24 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5851A11E807A for ; Mon, 9 Jan 2012 08:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjfAdANZwJHi for ; Mon, 9 Jan 2012 08:53:20 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB7621F8629 for ; Mon, 9 Jan 2012 08:52:59 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q09GrTSx029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Jan 2012 10:53:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q09GqrIM024259 for ; Mon, 9 Jan 2012 08:52:53 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q09Gqn1m024159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jan 2012 08:52:49 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 9 Jan 2012 08:52:48 -0800 From: "Templin, Fred L" To: jouni korhonen Date: Mon, 9 Jan 2012 08:52:47 -0800 Thread-Topic: [MEXT] The first proposal for the DMM charter Thread-Index: AczOu5OPg10ag1KlR0K6sHrokr5DvQAMtlGg Message-ID: References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> <48813412-2A2D-4611-8723-BCE1A548BD59@gmail.com> In-Reply-To: <48813412-2A2D-4611-8723-BCE1A548BD59@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "julien.ietf@gmail.com Laganier" , "mext@ietf.org" Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:53:24 -0000 Hi Jouni,=20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, January 09, 2012 2:44 AM > To: Templin, Fred L > Cc: julien.ietf@gmail.com Laganier; mext@ietf.org > Subject: Re: [MEXT] The first proposal for the DMM charter >=20 > Fred, >=20 > On Jan 3, 2012, at 7:42 PM, Templin, Fred L wrote: > >>=20 > >> The protocol solutions should be based on existing IP mobility > >> protocols, either host- or network-based, such as Mobile IPv6 > >> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO=20 > >> [RFC3963]. > >=20 > > I don't understand the "should be based on existing IP > > mobility protocols". IRON for example provides an > > alternative mobility management solution which I believe > > has significant advantages over other approaches: > >=20 > > http://tools.ietf.org/html/draft-templin-ironbis-10 > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com >=20 >=20 > I admit I have not followed much of the IRON work. However, the=20 > overal idea is that if your solution needs specific bindings to > existing mobility providing protocol(s), then your choices more > or less are listed above (or some existing flavor/variation of > those). If your solution does not depend on any specific mobility > protocol i.e., does not require specification of protocol specific > bindings, then you are free to deploy it on top of anything, > including IRON. I'm not sure I fully understand what you are trying to say, but what I am trying to say is that IRON provides an alternative mobility management scheme that does not depend on any of the *MIP mechanisms and is, IMHO, a better mobility management system. Hence, I recommend a closer look at IRON: http://tools.ietf.org/html/draft-templin-ironbis Thanks - Fred fred.l.templin@boeing.com > - Jouni > = From jouni.nospam@gmail.com Mon Jan 9 10:21:31 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3AF11E80AD for ; Mon, 9 Jan 2012 10:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgH0H4do8+xa for ; Mon, 9 Jan 2012 10:21:29 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14711E80AB for ; Mon, 9 Jan 2012 10:21:16 -0800 (PST) Received: by laah2 with SMTP id h2so1791654laa.31 for ; Mon, 09 Jan 2012 10:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3RaVI9p4yC6y2Jy+llCliU88XRPJXGzDP4uHepC8a1I=; b=skprK8/dwzyJjyBi1pCI6aGAJ+peip1xHrLyhFoelFsppJOTP5sMasowgDxah91S4d Ejl0Oc2q1U9jQ/RZNR4KOTRZ0SC6+pnmhgwDOuk+G6Q3YjC72i8zCCICMHlSUkelvKJl 05VyN6lxvyxMMLv4d6aZ68FPxMc0FZddFUFcQ= Received: by 10.152.134.10 with SMTP id pg10mr7416578lab.3.1326133274125; Mon, 09 Jan 2012 10:21:14 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id sv10sm31552828lab.14.2012.01.09.10.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 10:21:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Mon, 9 Jan 2012 20:21:10 +0200 Content-Transfer-Encoding: 7bit Message-Id: <5792F470-2A8E-40B4-9B65-E847219C27E8@gmail.com> References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> <48813412-2A2D-4611-8723-BCE1A548BD59@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1251.1) Cc: "julien.ietf@gmail.com Laganier" , "mext@ietf.org" Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:21:31 -0000 Fred, On Jan 9, 2012, at 6:52 PM, Templin, Fred L wrote: > Hi Jouni, > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, January 09, 2012 2:44 AM >> To: Templin, Fred L >> Cc: julien.ietf@gmail.com Laganier; mext@ietf.org >> Subject: Re: [MEXT] The first proposal for the DMM charter >> >> Fred, >> >> On Jan 3, 2012, at 7:42 PM, Templin, Fred L wrote: >>>> >>>> The protocol solutions should be based on existing IP mobility >>>> protocols, either host- or network-based, such as Mobile IPv6 >>>> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO >>>> [RFC3963]. >>> >>> I don't understand the "should be based on existing IP >>> mobility protocols". IRON for example provides an >>> alternative mobility management solution which I believe >>> has significant advantages over other approaches: >>> >>> http://tools.ietf.org/html/draft-templin-ironbis-10 >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >> >> >> I admit I have not followed much of the IRON work. However, the >> overal idea is that if your solution needs specific bindings to >> existing mobility providing protocol(s), then your choices more >> or less are listed above (or some existing flavor/variation of >> those). If your solution does not depend on any specific mobility >> protocol i.e., does not require specification of protocol specific >> bindings, then you are free to deploy it on top of anything, >> including IRON. > In the above "solution" being a solution for distributed mobility management. Hope that clarifies. - Jouni > I'm not sure I fully understand what you are trying to > say, but what I am trying to say is that IRON provides > an alternative mobility management scheme that does not > depend on any of the *MIP mechanisms and is, IMHO, a > better mobility management system. Hence, I recommend > a closer look at IRON: > > http://tools.ietf.org/html/draft-templin-ironbis > > Thanks - Fred > fred.l.templin@boeing.com > >> - Jouni >> From Fred.L.Templin@boeing.com Mon Jan 9 10:24:22 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0731C11E80AB for ; Mon, 9 Jan 2012 10:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E5IcDPTVGVM for ; Mon, 9 Jan 2012 10:24:21 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2296D11E8093 for ; Mon, 9 Jan 2012 10:24:21 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q09IOIxG002125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Jan 2012 10:24:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q09IOHal015381 for ; Mon, 9 Jan 2012 10:24:18 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q09IOD4v015208 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jan 2012 10:24:14 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 9 Jan 2012 10:24:13 -0800 From: "Templin, Fred L" To: Jouni Date: Mon, 9 Jan 2012 10:24:11 -0800 Thread-Topic: [MEXT] The first proposal for the DMM charter Thread-Index: AczO+33ip8ForYdPTry7PA19TqRyNwAADD0Q Message-ID: References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <91BED5F7-FEE9-435E-80F3-5BF01421EB3B@gmail.com> <48813412-2A2D-4611-8723-BCE1A548BD59@gmail.com> <5792F470-2A8E-40B4-9B65-E847219C27E8@gmail.com> In-Reply-To: <5792F470-2A8E-40B4-9B65-E847219C27E8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "julien.ietf@gmail.com Laganier" , "mext@ietf.org" Subject: Re: [MEXT] The first proposal for the DMM charter X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:24:22 -0000 Hi Jouni,=20 > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, January 09, 2012 10:21 AM > To: Templin, Fred L > Cc: julien.ietf@gmail.com Laganier; mext@ietf.org > Subject: Re: [MEXT] The first proposal for the DMM charter >=20 >=20 > Fred, >=20 >=20 > On Jan 9, 2012, at 6:52 PM, Templin, Fred L wrote: >=20 > > Hi Jouni,=20 > >=20 > >> -----Original Message----- > >> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > >> Sent: Monday, January 09, 2012 2:44 AM > >> To: Templin, Fred L > >> Cc: julien.ietf@gmail.com Laganier; mext@ietf.org > >> Subject: Re: [MEXT] The first proposal for the DMM charter > >>=20 > >> Fred, > >>=20 > >> On Jan 3, 2012, at 7:42 PM, Templin, Fred L wrote: > >>>>=20 > >>>> The protocol solutions should be based on existing IP mobility > >>>> protocols, either host- or network-based, such as Mobile IPv6 > >>>> [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO=20 > >>>> [RFC3963]. > >>>=20 > >>> I don't understand the "should be based on existing IP > >>> mobility protocols". IRON for example provides an > >>> alternative mobility management solution which I believe > >>> has significant advantages over other approaches: > >>>=20 > >>> http://tools.ietf.org/html/draft-templin-ironbis-10 > >>>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>=20 > >>=20 > >> I admit I have not followed much of the IRON work. However, the=20 > >> overal idea is that if your solution needs specific bindings to > >> existing mobility providing protocol(s), then your choices more > >> or less are listed above (or some existing flavor/variation of > >> those). If your solution does not depend on any specific mobility > >> protocol i.e., does not require specification of protocol specific > >> bindings, then you are free to deploy it on top of anything, > >> including IRON. > >=20 >=20 > In the above "solution" being a solution for distributed mobility > management. I'm still not exactly sure what you are tring to say. Please have a look at IRON and let me know why or why not you think it addresses DMM and we can go from there. Thanks - Fred fred.l.templin@boeing.com > Hope that clarifies. >=20 > - Jouni >=20 >=20 > > I'm not sure I fully understand what you are trying to > > say, but what I am trying to say is that IRON provides > > an alternative mobility management scheme that does not > > depend on any of the *MIP mechanisms and is, IMHO, a > > better mobility management system. Hence, I recommend > > a closer look at IRON: > >=20 > > http://tools.ietf.org/html/draft-templin-ironbis > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > >> - Jouni > >>=20 >=20 > = From wwwrun@ietfa.amsl.com Tue Jan 10 09:52:54 2012 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id F357721F8644; Tue, 10 Jan 2012 09:52:53 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120110175253.F357721F8644@ietfa.amsl.com> Date: Tue, 10 Jan 2012 09:52:53 -0800 (PST) Cc: julien.ietf@gmail.com, mext@ietf.org, jouni.korhonen@nsn.com Subject: [MEXT] WG Action: RECHARTER: Distributed Mobility Management (dmm) - formerly Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:52:54 -0000 The Distributed Mobility Management (dmm) working group [formerly Mobility EXTensions for IPv6 (mext) working group] in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Distributed Mobility Management (dmm) ------------------------------------- Current Status: Active Chairs: Julien Laganier Jouni Korhonen Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: The Distributed Mobility Management (DMM) working group specifies IP mobility, access network and routing solutions, which allow for setting up IP networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to manage IP mobility sessions. The distributed mobility management solutions aim for transparency above the IP layer, including maintenance of active transport level sessions as mobile hosts or entire mobile networks change their point of attachment to the Internet. The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. Solutions may also focus specifically on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions. The distributed mobility management solutions primarily target IPv6 Deployment and should not be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. At least IPv6 is assumed to be present in both the mobile host/router and the access networks. Independent of the distributed mobility management solution, backward compatibility must be maintained. If the network or the mobile host/router do not support the distributed mobility management enabling protocol, nothing should break. Work items related to the distributed mobility management include: o Solution Requirements: Define precisely the problem of distributed mobility management and identity the requirements for a distributed mobility management solution. o Practices: Document practices for the deployment of existing mobility protocols in a distributed mobility management environment. o Gap Analysis and extensions: identify the limitations in the current practices with respect to providing the expected functionality. o If limitations are identified as part of the above deliverable, specify extensions to existing protocols that removes these limitations within a distributed mobility management environment. Goals and Milestones: Aug 2012 - Submit I-D 'Solution Requirements' as a working group document. To be Informational RFC. Aug 2012 - Submit I-D 'Practices and Gap Analysis' as a working group document. To be Informational RFC. Nov 2012 - Evaluate the need for additional working group document(s) for extensions to fill the identified gaps. Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Jan 2013 - Submit I-D 'Practices ' to the IESG for consideration as an Informational RFC. Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. Mar 2013 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group From jouni.nospam@gmail.com Mon Jan 16 06:16:23 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392F621F8517 for ; Mon, 16 Jan 2012 06:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJNgxH3nH8ik for ; Mon, 16 Jan 2012 06:16:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 789D421F8512 for ; Mon, 16 Jan 2012 06:16:22 -0800 (PST) Received: by lagv3 with SMTP id v3so1880352lag.31 for ; Mon, 16 Jan 2012 06:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=3pDDPWjPw/7d6XaNfnIIiqhCwsq8/tDt+YYF6G4vcn8=; b=DF7iYn1/8CKtORIkzU4udnWitPDosum5gvEkjuW0uklrKAbSov1qUkBkTjXncHEdiJ 155i+nuOpP7ZIg3JS3gxpptzEZwS/XVecUqIPl/n03j26q6dyZNob0DmbrbwugR2dlns BiH2E81MjJNSt2QvjFMXgw5q7nL6jTKRQTjQs= Received: by 10.112.27.65 with SMTP id r1mr3098928lbg.33.1326723381506; Mon, 16 Jan 2012 06:16:21 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id d6sm17551300lbj.2.2012.01.16.06.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 06:16:20 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Jan 2012 16:16:18 +0200 Message-Id: <03590AE7-EAFE-46A0-8FD7-E66A35E92DD2@gmail.com> To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MEXT] Paris meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:16:23 -0000 Folks, Just to let you know we have applied for 2.5h slot for the Paris DMM WG meeting. So there should be enough time for a couple of presentations and also have relevant discussions.. - Jouni & Julien From alexandru.petrescu@gmail.com Mon Jan 16 08:03:48 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCA821F8677 for ; Mon, 16 Jan 2012 08:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZTcsE1jn2ZL for ; Mon, 16 Jan 2012 08:03:47 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3621F8602 for ; Mon, 16 Jan 2012 08:03:40 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id q0GG3dOC010297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Jan 2012 17:03:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q0GG3b4L002905 for ; Mon, 16 Jan 2012 17:03:37 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id q0GG3XOk025061 for ; Mon, 16 Jan 2012 17:03:37 +0100 Message-ID: <4F144A55.7080105@gmail.com> Date: Mon, 16 Jan 2012 17:03:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <03590AE7-EAFE-46A0-8FD7-E66A35E92DD2@gmail.com> In-Reply-To: <03590AE7-EAFE-46A0-8FD7-E66A35E92DD2@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Paris meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:03:48 -0000 In communicating I need to understand whether I can say DMM WG? Is this really a WG? Alex Le 16/01/2012 15:16, jouni korhonen a écrit : > Folks, > > Just to let you know we have applied for 2.5h slot for the Paris > DMM WG meeting. So there should be enough time for a couple of > presentations and also have relevant discussions.. > > - Jouni& Julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Mon Jan 16 23:39:40 2012 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153E721F8581 for ; Mon, 16 Jan 2012 23:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aN2jME5Muz7 for ; Mon, 16 Jan 2012 23:39:39 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3565D21F857D for ; Mon, 16 Jan 2012 23:39:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id q0H7db9e020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jan 2012 08:39:37 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q0H7dbLr007447 for ; Tue, 17 Jan 2012 08:39:37 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id q0H7dYHZ014182 for ; Tue, 17 Jan 2012 08:39:36 +0100 Message-ID: <4F1525B6.3090001@gmail.com> Date: Tue, 17 Jan 2012 08:39:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <03590AE7-EAFE-46A0-8FD7-E66A35E92DD2@gmail.com> <4F144A55.7080105@gmail.com> In-Reply-To: <4F144A55.7080105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Paris meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 07:39:40 -0000 Sorry - following up on my own email. I have missed the earlier announcement of this being a WG, the DMM WG. Just some side notes. I have followed the DMM discussion and I was not persuaded the effort were clear enough. But the Charter seems to be inline with this lack of clarity. It looks to me as more of a place to develop new things whatever they may be. For example, it does not say whether Mobile IPv6 is a must or not. The email list is still mext@ietf.org although the WG is called DMM. I personally prefer the email list to be called dmm@ietf.org as well. When I invite somebody to join I say "join DMM WG by subscribing to MEXT email list, even though the MEXT WG is dead, err... re-chartered". There is a conscious action in joining a particular email list, but now all MEXT subscribers have their consciousness forced into DMM... is this right? The 6MAN WG has a similar practice where the email list is called "ipv6@ietf.org". I thought this practice not intuitive for outsiders, I still think so. Finally, there is some activities in MEXT which are automatically declared dead by this MEXT-DMM re-Chartering. One would expect see an explanation about this disappearing. Alex Le 16/01/2012 17:03, Alexandru Petrescu a écrit : > In communicating I need to understand whether I can say DMM WG? Is > this really a WG? > > Alex > > Le 16/01/2012 15:16, jouni korhonen a écrit : >> Folks, >> >> Just to let you know we have applied for 2.5h slot for the Paris >> DMM WG meeting. So there should be enough time for a couple of >> presentations and also have relevant discussions.. >> >> - Jouni& Julien _______________________________________________ >> MEXT mailing list MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >