Re: [Mipshop] Proposed new charter

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Wed, 12 March 2008 21:13 UTC

Return-Path: <mipshop-bounces@ietf.org>
X-Original-To: ietfarch-mipshop-archive@core3.amsl.com
Delivered-To: ietfarch-mipshop-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062C43A6AF1; Wed, 12 Mar 2008 14:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.615
X-Spam-Level:
X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, DIET_1=0.083, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leGjugh51CGB; Wed, 12 Mar 2008 14:13:35 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1409E3A694B; Wed, 12 Mar 2008 14:13:35 -0700 (PDT)
X-Original-To: mipshop@core3.amsl.com
Delivered-To: mipshop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1153A694B for <mipshop@core3.amsl.com>; Wed, 12 Mar 2008 14:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8aRHAWBbJqj for <mipshop@core3.amsl.com>; Wed, 12 Mar 2008 14:13:31 -0700 (PDT)
Received: from mail2.azairenet.com (mail2.azairenet.com [207.47.15.6]) by core3.amsl.com (Postfix) with ESMTP id 5713E3A6BA7 for <mipshop@ietf.org>; Wed, 12 Mar 2008 14:13:31 -0700 (PDT)
Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 14:11:12 -0700
Message-ID: <47D846F0.4080406@azairenet.com>
Date: Wed, 12 Mar 2008 14:11:12 -0700
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Frank Xia <xiayangsong@huawei.com>
References: <47CF3864.40905@azairenet.com> <47D703C2.3040603@azairenet.com> <019001c883cf$f5e629f0$ec308182@china.huawei.com> <47D707DA.1080404@azairenet.com> <01d301c883d1$13b71bf0$ec308182@china.huawei.com> <BAY112-W19FB07CB6F82560B42B7B9B1080@phx.gbl> <F60A3CE9E807BE49B5F56BD80B894D200145B1EA@sc-exch03.marvell.com> <BAY112-W14FDB7DBE8D34E3AB81B6B1080@phx.gbl> <47D8239A.40701@azairenet.com> <00cb01c8847a$c0412330$a36512c6@china.huawei.com> <47D8268B.6010209@azairenet.com> <013401c8848c$b7890fc0$a36512c6@china.huawei.com>
In-Reply-To: <013401c8848c$b7890fc0$a36512c6@china.huawei.com>
X-OriginalArrivalTime: 12 Mar 2008 21:11:12.0750 (UTC) FILETIME=[99E508E0:01C88485]
Cc: Mipshop <mipshop@ietf.org>, christian.wietfeld@tu-dortmund.de
Subject: Re: [Mipshop] Proposed new charter
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <mipshop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org

Frank Xia wrote:
> Hi Vijay
> 
> First of all, I am supporting this rechartering item in general.
> 
> IMO, mechanism that is applicable to MIP is also possible feasible
> to PMIP  after some adaptations.
> I don't  think it is necessary to exclude the possibility of  PMIPv6 application.

If it is possible to re-use the solution we develop for
PMIPv6 also, great. But we are not going to focus on
PMIPv6 or FMIPv6 for now.

Vijay

> 
> BR
> Frank
> 
> ----- Original Message ----- 
> From: "Vijay Devarapalli" <vijay.devarapalli@azairenet.com>
> To: "Frank Xia" <xiayangsong@huawei.com>
> Cc: <zfaqeer@hotmail.com>; <christian.wietfeld@tu-dortmund.de>; "Mipshop" <mipshop@ietf.org>
> Sent: Wednesday, March 12, 2008 1:52 PM
> Subject: Re: [Mipshop] Proposed new charter
> 
> 
>> Frank Xia wrote:
>>> Hi Vijay
>>>
>>> I would like to suggest that PMIPv6 is in the scope.
>> The PMIPv6 tunnel is not over the air. In addition, the PMIPv6
>> tunnel between the MAG and the LMA is used carry traffic for a
>> number of mobile nodes. There is no tunnel per mobile node.
>>
>> What kind of optimization do we need for PMIPv6?
>>
>> Vijay
>>
>>> BR
>>> Frank
>>>
>>> ----- Original Message ----- 
>>> From: "Vijay Devarapalli" <vijay.devarapalli@azairenet.com>
>>> To: <zfaqeer@hotmail.com>
>>> Cc: <christian.wietfeld@tu-dortmund.de>; "Mipshop" <mipshop@ietf.org>
>>> Sent: Wednesday, March 12, 2008 1:40 PM
>>> Subject: Re: [Mipshop] Proposed new charter
>>>
>>>
>>>> Hello Zarrar,
>>>>
>>>> I believe the current scope of work is about reducing the tunneling
>>>> overhead over the air due to protocols like MIPv6 and HMIPv6. This
>>>> work had a lot of consensus in the MEXT WG and then transferred here.
>>>>
>>>> My personal opinion is that I think we should stick to that scope
>>>> for now. Expanding the scope of the work would require more
>>>> discussions and consensus in the MIPSHOP WG. Until then we should
>>>> not expand the scope.
>>>>
>>>> Vijay
>>>>
>>>> zfaqeer@hotmail.com wrote:
>>>>> Hello Stefano,
>>>>>  
>>>>> Thanks for your comments and your feedback. I agree with your argument 
>>>>> but on the other hand, IMHO, the duration of the tunnel existence is 
>>>>> also a resource consuming phenomena in which resources are reserved on 
>>>>> both ends of the tunnel and the tunneling/de-tunneling of packets 
>>>>> (in both directions) will not only add extra overhead but also incur 
>>>>> processing delay and this will impact real time communication sessions 
>>>>> and fast moving users (with smaller dwell times) in terms of jitter and 
>>>>> delays.
>>>>> I very much agree that a holistic and across-the-board approach towards 
>>>>> optimizing the tunneling function is required (so that MIPv6 can also be 
>>>>> optimised) but I would also suggest that this aspect (of finding ways to 
>>>>> reduce tunneling duration) should also be made part of the new charter, 
>>>>> as I see FMIPv6 a good candidate for providing near-seamless handovers 
>>>>> for "fast moving users".
>>>>>  
>>>>> take care
>>>>>  
>>>>> Zarrar Yousaf
>>>>> Communication Networks Institute,
>>>>> Dortmund University of Technology (TU Dortmund)
>>>>> Germany
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     Subject: RE: [Mipshop] Proposed new charter
>>>>>     Date: Wed, 12 Mar 2008 08:01:17 -0700
>>>>>     From: smfaccin@marvell.com
>>>>>     To: zfaqeer@hotmail.com; vijay.devarapalli@azairenet.com
>>>>>     CC: mipshop@ietf.org
>>>>>
>>>>>     Dear Zarraf,
>>>>>     thanks for the email. Interesting draft. My understanding of the
>>>>>     tunnel optimization in the charter is however slightly different. In
>>>>>     fact the charter refers to "negative impact on the protocol
>>>>>     efficiency which is translated in the data packet size, bandwidth
>>>>>     usage and battery power consumption. Therefore, a mechanism which
>>>>>     enables reducing the tunneling overhead would benefit the mobile
>>>>>     node and optimize the bandwidth usage. The MIPSHOP WG will
>>>>>     standardize such a mechanism." Therefore the charter refers to
>>>>>     optimizations to the way tunneling is performed to e.g. reduce the
>>>>>     size of the packets. IMO it does not refer to the temporary tunnel
>>>>>     created in FMIPv6 between the PAR and the NAR, but to the tunneling
>>>>>     present through the whole connection.
>>>>>     Cheers,
>>>>>     Stefano
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     *From:* mipshop-bounces@ietf.org on behalf of zfaqeer@hotmail.com
>>>>>     *Sent:* Wed 3/12/2008 1:32 AM
>>>>>     *To:* Frank Xia; Vijay Devarapalli
>>>>>     *Cc:* 'Mipshop'
>>>>>     *Subject:* Re: [Mipshop] Proposed new charter
>>>>>
>>>>>     Hello,
>>>>>      
>>>>>     Regarding Tunnel optimization in FMIPv6, a draft has already been
>>>>>     submitted called "Proactive Bindings in FMIPv6"
>>>>>     (https://datatracker.ietf.org/drafts/draft-yousaf-ietf-mipshop-pbfmipv6/)
>>>>>     in which a proposal regarding the reduction of the tunnel
>>>>>     duration has already been proposed.
>>>>>      
>>>>>     At the moment we are performing simulation and measurement tests and
>>>>>     the initial results are  very encouraging, however i will be able to
>>>>>     share more details after about one month.
>>>>>      
>>>>>     BR
>>>>>      
>>>>>     Zarrar Yousaf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>      > Date: Tue, 11 Mar 2008 18:38:52 -0500
>>>>>      > From: xiayangsong@huawei.com
>>>>>      > To: vijay.devarapalli@azairenet.com
>>>>>      > CC: mipshop@ietf.org
>>>>>      > Subject: Re: [Mipshop] Proposed new charter
>>>>>      >
>>>>>      > Hi Vijay
>>>>>      >
>>>>>      > Please see my reply..
>>>>>      >
>>>>>      > BR
>>>>>      > Frank
>>>>>      > ----- Original Message -----
>>>>>      > From: "Vijay Devarapalli" <vijay.devarapalli@azairenet.com>
>>>>>      > To: "Frank Xia" <xiayangsong@huawei.com>
>>>>>      > Cc: "'Mipshop'" <mipshop@ietf.org>
>>>>>      > Sent: Tuesday, March 11, 2008 5:29 PM
>>>>>      > Subject: Re: [Mipshop] Proposed new charter
>>>>>      >
>>>>>      >
>>>>>      > > Frank Xia wrote:
>>>>>      > > > Hi Vijay
>>>>>      > > >
>>>>>      > > > For Tunnel Optimization, why should we limit in Mobile IPv6
>>>>>     and HMIP6?
>>>>>      > >
>>>>>      > > It wasn't meant to be an exhaustive list of protocols that
>>>>>      > > tunnel.
>>>>>      > Frank=>IMO, it is a little bit ambiguous. For example,
>>>>>      > why is HMIP6 is highlighted? why isn't FMIP6 highlighted?
>>>>>      > It will be helpful if you make it clearer.
>>>>>      >
>>>>>      > >
>>>>>      > > > I think it is also possible for PMIPv6 and Mobile IPv4.
>>>>>      > >
>>>>>      > > We have not taken on any work related to Mobile IPv4 so far.
>>>>>      > >
>>>>>      > > Vijay
>>>>>      > >
>>>>>      > > >
>>>>>      > > > BR
>>>>>      > > > Frank
>>>>>      > > >
>>>>>      > > >
>>>>>      > > > ----- Original Message -----
>>>>>      > > > From: "Vijay Devarapalli" <vijay.devarapalli@azairenet.com>
>>>>>      > > > To: "'Mipshop'" <mipshop@ietf.org>
>>>>>      > > > Sent: Tuesday, March 11, 2008 5:12 PM
>>>>>      > > > Subject: Re: [Mipshop] Proposed new charter
>>>>>      > > >
>>>>>      > > >
>>>>>      > > >> Hello,
>>>>>      > > >>
>>>>>      > > >> The MEXT working group has asked to take on some additional
>>>>>     work.
>>>>>      > > >> This is about a mechanism to reduce the tunneling overhead
>>>>>     due to
>>>>>      > > >> MIPv6 and HMIPv6. So we modified the charter to include this
>>>>>     work
>>>>>      > > >> too. Here is the revised charter. Please review.
>>>>>      > > >>
>>>>>      > > >>
>>>>>     ------------------------------------------------------------------------
>>>>>      > > >>
>>>>>      > > >> Mobility for IP: Performance, Signaling and Handoff
>>>>>     Optimization (MIPSHOP)
>>>>>      > > >>
>>>>>      > > >> Description of Working Group:
>>>>>      > > >>
>>>>>      > > >> Mobile IPv6 enables IPv6 mobile nodes to continue using a given
>>>>>      > > >> "home address" in spite of changes in its point of attachment to
>>>>>      > > >> the network. These changes may cause delay, packet loss, and
>>>>>     also
>>>>>      > > >> represent overhead traffic on the network. The MIPSHOP WG has so
>>>>>      > > >> far worked on two technologies to address these issues.
>>>>>      > > >> Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency
>>>>>      > > >> of signaling between a MN, its Home Agent and one or more
>>>>>      > > >> correspondent nodes. Fast Handovers for Mobile IPv6 (FMIPv6)
>>>>>      > > >> reduces packet loss by providing fast IP connectivity as soon as
>>>>>      > > >> the mobile node establishes a new point of attachment at a new
>>>>>      > > >> link.
>>>>>      > > >>
>>>>>      > > >> The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and
>>>>>      > > >> the necessary extensions to improve these protocols. The MIPSHOP
>>>>>      > > >> WG will also identify missing components that are required for
>>>>>      > > >> deploying these protocols and standardize the necessary
>>>>>     extensions.
>>>>>      > > >> The WG will also address interworking of these protocols
>>>>>     with other
>>>>>      > > >> mobility management protocols in the IETF, including
>>>>>     network-based
>>>>>      > > >> mobility management protocols.
>>>>>      > > >>
>>>>>      > > >> The IEEE 802.21 Media Independent Handoff (MIH) working
>>>>>     group aims
>>>>>      > > >> at providing services to assist with handoffs between
>>>>>     heterogeneous
>>>>>      > > >> link-layer technologies, and across IP subnet boundaries. MIH
>>>>>      > > >> services can be delivered through link-layer specific solutions
>>>>>      > > >> and/or through a "layer 3 or above" protocol. MIPSHOP will
>>>>>     define
>>>>>      > > >> the delivery of information for MIH services for this latter
>>>>>     case.
>>>>>      > > >> A L3 based mechanism to identify a valid information server
>>>>>     is also
>>>>>      > > >> required. The MIPSHOP will work on developing a protocol for
>>>>>      > > >> transport of MIH services information and mechanisms for
>>>>>     discovering
>>>>>      > > >> the MIH server. Security for the transport of MIH
>>>>>     information will
>>>>>      > > >> also be addressed.
>>>>>      > > >>
>>>>>      > > >> The widespread use of different forms of IP tunneling mechanisms
>>>>>      > > >> in mobile environment, e.g., MIPv6, HMIPv6, has a negative
>>>>>     impact
>>>>>      > > >> on the protocol efficiency which is translated in the data
>>>>>     packet
>>>>>      > > >> size, bandwidth usage and battery power consumption.
>>>>>     Therefore, a
>>>>>      > > >> mechanism which enables reducing the tunneling overhead would
>>>>>      > > >> benefit the mobile node and optimize the bandwidth usage. The
>>>>>      > > >> MIPSHOP WG will standardize such a mechanism.
>>>>>      > > >>
>>>>>      > > >> The MOBOPTS Research Group in the IRTF is chartered to work on
>>>>>      > > >> optimizations related to Mobile IPv6 and IP handoffs among other
>>>>>      > > >> things. The MIPSHOP WG will take mature proposals from the
>>>>>     MOBOPTS
>>>>>      > > >> group and standardize them in the IETF on a case-by-case basis.
>>>>>      > > >>
>>>>>      > > >> The MIPSHOP WG will also consider and standardize
>>>>>     optimizations for
>>>>>      > > >> the Mobile IPv6 protocol and IP mobility in general.
>>>>>      > > >>
>>>>>      > > >> Scope of MIPSHOP:
>>>>>      > > >>
>>>>>      > > >> The working group will:
>>>>>      > > >>
>>>>>      > > >> 1. Complete the current set of documents with the IESG
>>>>>      > > >> - HMIPv6 (draft-ietf-mipshop-4140bis)
>>>>>      > > >> - FMIPv6 (draft-ietf-mipshop-fmipv6-rfc4068bis)
>>>>>      > > >> - FMIPv6 over IEEE 802.16e (draft-ietf-mipshop-fh80216e)
>>>>>      > > >> - FMIPv6 over 3G CDMA 2000 (draft-ietf-mipshop-3gfh)
>>>>>      > > >> - MIH problem statement (draft-ietf-mipshop-mis-ps)
>>>>>      > > >>
>>>>>      > > >> 2. FMIPv6 Mobile Node - Access Router security using the AAA
>>>>>      > > >> infrastructure
>>>>>      > > >>
>>>>>      > > >> Currently MIPSHOP has produced a standards track protocol for
>>>>>      > > >> setting up security between the mobile node and access router
>>>>>      > > >> for security FMIPv6 signaling messages. However, the protocol
>>>>>      > > >> depends on SeND (Secure Neighbor Discovery) to be available on
>>>>>      > > >> the mobile node and the access router. An alternate mechanism
>>>>>      > > >> that leverages the AAA infrastructure is required. Many target
>>>>>      > > >> systems where FMIPv6 is likely to be used use a AAA
>>>>>      > > >> infrastructure to authenticate and authorize network access.
>>>>>      > > >>
>>>>>      > > >> 3. Prefix Management for point-to-point links
>>>>>      > > >>
>>>>>      > > >> Using FMIPv6 over point-to-points like requires some additional
>>>>>      > > >> considerations with respect to managing and allocating prefixes
>>>>>      > > >> for the mobile node on these point-to-point links. Therefore
>>>>>      > > >> the WG will work on a BCP to document these considerations.
>>>>>      > > >>
>>>>>      > > >> 4. Use of FMIPv6 with Proxy Mobile IPv6
>>>>>      > > >>
>>>>>      > > >> Proxy Mobile IPv6 (PMIPv6) is a network-based mobility
>>>>>      > > >> management protocol where a node in the access network, called
>>>>>      > > >> the Mobile Access Gateway (MAG) handles mobility on behalf of
>>>>>      > > >> the mobile node. It has been proposed to use FMIPv6 to
>>>>>      > > >> optimize the handover in terms of reducing the packet loss and
>>>>>      > > >> transferring relevant context from the old MAG to the new MAG.
>>>>>      > > >> The working group will work on specifying FMIPv6 extensions to
>>>>>      > > >> enable fast handovers for PMIPv6.
>>>>>      > > >>
>>>>>      > > >> 5. Work on protocols and extensions for transporting information
>>>>>      > > >> related to IEEE 802.21:
>>>>>      > > >>
>>>>>      > > >> The work includes the layer 3 protocol for transporting MIH
>>>>>      > > >> related information and DHCP and DNS extensions for discovery
>>>>>      > > >> the information servers.
>>>>>      > > >>
>>>>>      > > >> 6. IP Tunneling Optimization
>>>>>      > > >>
>>>>>      > > >> Work on a mechanism to reduce the tunneling overhead associated
>>>>>      > > >> with protocols like Mobile IPv6 and HMIPv6.
>>>>>      > > >>
>>>>>      > > >> 7. Standardize mature proposals from the MOBOPTS IRTF Group
>>>>>      > > >>
>>>>>      > > >>
>>>>>      > > >> Goals and Milestones:
>>>>>      > > >>
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt
>>>>>      > > >> Done Working Group Last Call on
>>>>>      > > >> draft-ietf-mipshop-lmm-requirements-XX.txt
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt
>>>>>      > > >> Done Discuss Last Call comments and security analyses at IETF 58
>>>>>      > > >> Done Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt
>>>>>     to IESG
>>>>>      > > >> for publication as Informational
>>>>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for
>>>>>     publication
>>>>>      > > >> as Experimental
>>>>>      > > >> Done Submit draft-ietf-mipshop-hmip-xx.txt to IESG for
>>>>>     publication
>>>>>      > > >> as Experimental
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-80211fh-xx.txt
>>>>>      > > >> for Informational
>>>>>      > > >> Done Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for
>>>>>      > > >> publication as Informational
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-cga-cba-XX.txt
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mis-ps
>>>>>      > > >> Done Submit draft-ietf-mipshop-cga-cba to the IESG for
>>>>>     publication
>>>>>      > > >> as Proposed Standard
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-fmipv6-rfc4068bis
>>>>>      > > >> Done Working Group Last Call on
>>>>>     draft-ietf-mipshop-handover-key-send
>>>>>      > > >> Done Submit draft-ietf-mipshop-mis-ps to the IESG for
>>>>>     publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-rfc4041bis
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-3gfh
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-fh80216e
>>>>>      > > >> Done Submit draft-ietf-mipshop-fmipv6-rfc4068bis to the IESG
>>>>>     for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Done Submit draft-ietf-mipshop-handover-key-send to the IESG
>>>>>     for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Done Submit draft-ietf-mipshop-3gfh to IESG for publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Submit draft-ietf-mipshop-fh80216e to IESG for
>>>>>     publication as
>>>>>      > > >> Informational RFC
>>>>>      > > >> Done Working Group Last Call on draft-ietf-mipshop-mih-support
>>>>>      > > >> Apr 2008 Submit draft-ietf-mipshop-4140bis to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Apr 2008 Submit draft-ietf-mipshop-mih-support to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> May 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-mos-dns-discovery
>>>>>      > > >> May 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-mos-dhcp-options
>>>>>      > > >> Jun 2008 Working group last call on
>>>>>     draft-ietf-mipshop-fmipv6-ptp
>>>>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dns-discovery to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Jun 2008 Submit draft-ietf-mipshop-mos-dhcp-options to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Jul 2008 Working Group Last Call on draft-ietf-mipshop-pfmipv6
>>>>>      > > >> Jul 2008 Submit draft-ietf-mipshop-fmipv6-ptp to the IESG for
>>>>>      > > >> publication as Best Current Practice
>>>>>      > > >> Aug 2008 Submit draft-ietf-mipshop-pfmipv6 to the IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Aug 2008 Working Group Last Call on
>>>>>     draft-ietf-mipshop-fmipv6-aaa-key
>>>>>      > > >> Oct 2008 Submit draft-ietf-mipshop-fmipv6-aaa-key to the
>>>>>     IESG for
>>>>>      > > >> publication as Proposed Standard
>>>>>      > > >> Nov 2008 Working Group Last call on
>>>>>      > > >> draft-ietf-mipshop-tunneling-optimization
>>>>>      > > >> Jan 2009 Submit draft-ietf-mipshop-tunneling-optimization to
>>>>>     the the
>>>>>      > > >> IESG
>>>>>      > > >>
>>>>>      > > >>
>>>>>     ---------------------------------------------------------------------------
>>>>>      > > >>
>>>>>      > > >> Vijay
>>>>>      > > >> _______________________________________________
>>>>>      > > >> Mipshop mailing list
>>>>>      > > >> Mipshop@ietf.org
>>>>>      > > >> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>      > > >>
>>>>>      > >
>>>>>      > >
>>>>>      > _______________________________________________
>>>>>      > Mipshop mailing list
>>>>>      > Mipshop@ietf.org
>>>>>      > https://www.ietf.org/mailman/listinfo/mipshop
>>>>>
>>>>>     ------------------------------------------------------------------------
>>>>>     Climb to the top of the charts! Play the word scramble challenge
>>>>>     with star power. Play now!
>>>>>     <http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Shed those extra pounds with MSN and The Biggest Loser! Learn more. 
>>>>> <http://biggestloser.msn.com/>
>>>> _______________________________________________
>>>> Mipshop mailing list
>>>> Mipshop@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>
>>

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop