From schmidt@informatik.haw-hamburg.de Sun Aug 2 09:23:12 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD093A6AA1; Sun, 2 Aug 2009 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] 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 8ROh6x1ac+Tu; Sun, 2 Aug 2009 09:23:11 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 327B03A688C; Sun, 2 Aug 2009 09:23:11 -0700 (PDT) Envelope-to: mobopts@irtf.org, multimob@ietf.org Received: from e178159090.adsl.alicedsl.de ([85.178.159.90] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MXdq3-0008XT-V3; Sun, 02 Aug 2009 18:23:12 +0200 Message-ID: <4A75BD5A.8000208@informatik.haw-hamburg.de> Date: Sun, 02 Aug 2009 18:22:50 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "mobopts@irtf.org" , multimob@ietf.org, Lachlan Andrew , Andrei Gurtov References: <20090802120037.5335328C0D6@core3.amsl.com> In-Reply-To: <20090802120037.5335328C0D6@core3.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "irsg@ISI.EDU" Subject: Re: [multimob] New Version Notification for draft-irtf-mobopts-mmcastv6-ps-08 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 16:23:12 -0000 Dear all, following the outcome of the IRSG review, we updated the problem statement draft on multicast mobility: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps Thanks to Andrei and Lachlan, multicast on HIP is now included, and a number of editorial and formatting issues cleared. Best regards, Thomas IETF I-D Submission Tool wrote: > A new version of I-D, draft-irtf-mobopts-mmcastv6-ps-08.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository. > > Filename: draft-irtf-mobopts-mmcastv6-ps > Revision: 08 > Title: Multicast Mobility in MIPv6: Problem Statement and Brief Survey > Creation_date: 2009-08-02 > WG ID: Independent Submission > Number_of_pages: 34 > > Abstract: > This document discusses current mobility extensions to IP layer > multicast. It describes problems arising from mobile group > communication in general, the case of multicast listener mobility, > and for mobile senders using Any Source Multicast and Source Specific > Multicast. Characteristic aspects of multicast routing and deployment > issues for fixed IPv6 networks are summarized. Specific properties > and interplays with the underlying network access are surveyed with > respect to the relevant technologies in the wireless domain. It > outlines the principal approaches to multicast mobility, together > with a comprehensive exploration of the mobile multicast problem and > solution space. This document concludes with a conceptual roadmap for > initial steps in standardization for use by future mobile multicast > protocol designers. This document is a product of the IP Mobility > Optimizations (MobOpts) Research Group. > > > > The IETF Secretariat. > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From jari.arkko@piuha.net Thu Aug 13 05:27:57 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2023A69EB for ; Thu, 13 Aug 2009 05:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1sie13ClNya for ; Thu, 13 Aug 2009 05:27:56 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 081D73A68B7 for ; Thu, 13 Aug 2009 05:27:56 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6645B19865A for ; Thu, 13 Aug 2009 15:27:57 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0BEB419863E for ; Thu, 13 Aug 2009 15:27:57 +0300 (EEST) Message-ID: <4A8406CC.1090308@piuha.net> Date: Thu, 13 Aug 2009 15:27:56 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:27:57 -0000 I have been thinking about what to do about this. My (remote) interpretation of the meeting was that people in the room felt a WG is needed and that the charter was reasonable. Due to scheduling and other reasons I don't think this is the entire picture, however. I think parts of the mobility community still feel that a working group is an overkill and/or the optimization work is unwarranted. However, I am personally quite convinced that _some_ work is needed, given, for instance, the fact that while implementing some forms of multicast in proxy MIP is easy, the word multicast doesn't appear in the specification. I think we have realistically three options: 1. Put the work in an existing WG, such as NETEXT, as a part of extensions and clarification work on proxy MIP. 2. Create a new working group, but tune the charter from the proposed one into a little bit more restrictive, mainly to remove too much optimization work. Once this work is complete, we can more confidently let the working group do the optimization work as well. 3. Creata a working group as requested. I'm leaning on alternative 2, thoughts? Here's a proposed charter: Mobility Multicast (multimob) Chairs: TBD Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: multimob@ietf.org Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob Description of Working Group The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener mobility. Work requiring modifications to mobility protocols, MLD/IGMP, and multicast routing protocols is out of scope in this first stage of this working group. Specific goals are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMP/MLD in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and will assume an unmodified mobile host. The work will employ the remote subscription model. This is mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Milestones: Nov 2009 Initial version of a document explaining the use of multicast in PMIPv6 Nov 2009 Initial version of a document on how to tune IGMP/MLD for mobility Feb 2010 Submit a document explaining the use of multicast in PMIPv6, for publication as either Informational or Best Current Practice Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for publication as either Informational or Best Current Practice Mar 2010 Recharter for additional optimization work involving extensions to PMIPv6, IGMPv3, or MLDv2 From schmidt@informatik.haw-hamburg.de Thu Aug 13 06:00:51 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35A33A693A for ; Thu, 13 Aug 2009 06:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 oYeeqR3Nl6lM for ; Thu, 13 Aug 2009 06:00:50 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id A82EB3A6877 for ; Thu, 13 Aug 2009 06:00:49 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178148007.adsl.alicedsl.de ([85.178.148.7] helo=[192.168.178.20]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1MbZsM-0000sI-JP; Thu, 13 Aug 2009 14:57:50 +0200 Message-ID: <4A840DC8.8050103@informatik.haw-hamburg.de> Date: Thu, 13 Aug 2009 14:57:44 +0200 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jari Arkko References: <4A8406CC.1090308@piuha.net> In-Reply-To: <4A8406CC.1090308@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:00:51 -0000 Dear Jari, many thanks for your thoughtful considerations. Your proposed modifications to the charter put a very nearby and narrow focus, which I believe is doable on the basis of the preliminary work that is already around. ... and yes, I can share your sensing of need for broader consensus on 'Multimob work' - given previous debates, it should be convincing to see a first outcome that is of practical value and nicely integrates into existing protocols of mobility and of multicast. So, personally I could go along well with your proposal. Btw. - there is a typo in the charter text: PMIPv6 paragraph, last sentence should be "This is *a* mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor." Thanks, Thomas Jari Arkko wrote: > I have been thinking about what to do about this. My (remote) > interpretation of the meeting was that people in the room felt a WG is > needed and that the charter was reasonable. Due to scheduling and other > reasons I don't think this is the entire picture, however. I think parts > of the mobility community still feel that a working group is an overkill > and/or the optimization work is unwarranted. However, I am personally > quite convinced that _some_ work is needed, given, for instance, the > fact that while implementing some forms of multicast in proxy MIP is > easy, the word multicast doesn't appear in the specification. > > I think we have realistically three options: > > 1. Put the work in an existing WG, such as NETEXT, as a part of > extensions and clarification work on proxy MIP. > 2. Create a new working group, but tune the charter from the proposed > one into a little bit more restrictive, mainly to remove too much > optimization work. Once this work is complete, we can more confidently > let the working group do the optimization work as well. > 3. Creata a working group as requested. > > I'm leaning on alternative 2, thoughts? Here's a proposed charter: > > Mobility Multicast (multimob) > > Chairs: > TBD > > Internet Area (int) Directors: > Jari Arkko > Ralph Droms > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: multimob@ietf.org > Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob > > Description of Working Group > > The Multicast mobility (multimob) working group provides guidance for > supporting multicast in a mobile environment. The scope of work will > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener > mobility. Work requiring modifications to mobility protocols, > MLD/IGMP, and multicast routing protocols is out of scope in this > first stage of this working group. > > Specific goals are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment > - Document the configuration of IGMP/MLD in mobile environments > > The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 > does not describe how to support multicast. Some forms of multicast > support can, however, be built in the involved nodes by using existing > capabilities of multicast protocols and the underlying mobility > protocols. The first task of the working group is to document such > solutions for PMIPv6. This work will not require any additions or > changes to message types and parameters specified in RFC 5213, and > will assume an unmodified mobile host. The work will employ the remote > subscription model. This is mechanism by which a mobile node joins a > multicast group and receives multicast data forwarded via the local > mobility anchor. > > IGMPv3/MLDv2 has been specified for wired networks with shared links. > Mobile nodes have needs that are specific to wireless networks and > mobility (e.g. entering a dormant mode to conserve battery power, > minimizing the latency for joining and leaving a group in support of > movement). > > The second task of the WG is to assess existing solutions for group > management, and determine to what extent these methods are sufficient > in a mobile environment. This will include recommending appropriate > selection of timer values and protocol parameters. > > In performing its work, the working group will work closely with both > the mobility community (NETLMM and NETEXT WGs) and the multicast > community (MBONED WG). The group will consider both source specific > multicast and any source multicast multicast models. > > Future work, subject to rechartering, may study/evaluate extensions to > support PMIPv6 optimizations to address the avalanche problem and fast > handover and extensions to IGMPv3/MLDv2 to support better operation in > mobile environments. > > Milestones: > > Nov 2009 Initial version of a document explaining the use of multicast > in PMIPv6 > Nov 2009 Initial version of a document on how to tune IGMP/MLD for > mobility > Feb 2010 Submit a document explaining the use of multicast in PMIPv6, > for publication as either Informational or Best Current Practice > Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for > publication as either Informational or Best Current Practice > Mar 2010 Recharter for additional optimization work involving > extensions to PMIPv6, IGMPv3, or MLDv2 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From xiayangsong@huawei.com Thu Aug 13 07:27:53 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EECC3A6A9C for ; Thu, 13 Aug 2009 07:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9rLKeV8ZTVf for ; Thu, 13 Aug 2009 07:27:52 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D9C0B3A6912 for ; Thu, 13 Aug 2009 07:27:50 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOB00791K3O7H@szxga02-in.huawei.com> for multimob@ietf.org; Thu, 13 Aug 2009 22:26:12 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOB0079OK3H2A@szxga02-in.huawei.com> for multimob@ietf.org; Thu, 13 Aug 2009 22:26:12 +0800 (CST) Date: Thu, 13 Aug 2009 09:26:04 -0500 From: Frank Xia To: Jari Arkko , multimob@ietf.org Message-id: <005001ca1c22$01dc21b0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A8406CC.1090308@piuha.net> Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:27:53 -0000 Hi Jari I agree with you. Alternative 2 is quite fair. BR Frank ----- Original Message ----- From: "Jari Arkko" To: Sent: Thursday, August 13, 2009 7:27 AM Subject: [multimob] MULTIMOB BOF outcome >I have been thinking about what to do about this. My (remote) > interpretation of the meeting was that people in the room felt a WG is > needed and that the charter was reasonable. Due to scheduling and other > reasons I don't think this is the entire picture, however. I think parts > of the mobility community still feel that a working group is an overkill > and/or the optimization work is unwarranted. However, I am personally > quite convinced that _some_ work is needed, given, for instance, the > fact that while implementing some forms of multicast in proxy MIP is > easy, the word multicast doesn't appear in the specification. > > I think we have realistically three options: > > 1. Put the work in an existing WG, such as NETEXT, as a part of > extensions and clarification work on proxy MIP. > 2. Create a new working group, but tune the charter from the proposed > one into a little bit more restrictive, mainly to remove too much > optimization work. Once this work is complete, we can more confidently > let the working group do the optimization work as well. > 3. Creata a working group as requested. > > I'm leaning on alternative 2, thoughts? Here's a proposed charter: > > Mobility Multicast (multimob) > > Chairs: > TBD > > Internet Area (int) Directors: > Jari Arkko > Ralph Droms > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: multimob@ietf.org > Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob > > Description of Working Group > > The Multicast mobility (multimob) working group provides guidance for > supporting multicast in a mobile environment. The scope of work will > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener > mobility. Work requiring modifications to mobility protocols, > MLD/IGMP, and multicast routing protocols is out of scope in this > first stage of this working group. > > Specific goals are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment > - Document the configuration of IGMP/MLD in mobile environments > > The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 > does not describe how to support multicast. Some forms of multicast > support can, however, be built in the involved nodes by using existing > capabilities of multicast protocols and the underlying mobility > protocols. The first task of the working group is to document such > solutions for PMIPv6. This work will not require any additions or > changes to message types and parameters specified in RFC 5213, and > will assume an unmodified mobile host. The work will employ the remote > subscription model. This is mechanism by which a mobile node joins a > multicast group and receives multicast data forwarded via the local > mobility anchor. > > IGMPv3/MLDv2 has been specified for wired networks with shared links. > Mobile nodes have needs that are specific to wireless networks and > mobility (e.g. entering a dormant mode to conserve battery power, > minimizing the latency for joining and leaving a group in support of > movement). > > The second task of the WG is to assess existing solutions for group > management, and determine to what extent these methods are sufficient > in a mobile environment. This will include recommending appropriate > selection of timer values and protocol parameters. > > In performing its work, the working group will work closely with both > the mobility community (NETLMM and NETEXT WGs) and the multicast > community (MBONED WG). The group will consider both source specific > multicast and any source multicast multicast models. > > Future work, subject to rechartering, may study/evaluate extensions to > support PMIPv6 optimizations to address the avalanche problem and fast > handover and extensions to IGMPv3/MLDv2 to support better operation in > mobile environments. > > Milestones: > > Nov 2009 Initial version of a document explaining the use of multicast > in PMIPv6 > Nov 2009 Initial version of a document on how to tune IGMP/MLD for > mobility > Feb 2010 Submit a document explaining the use of multicast in PMIPv6, > for publication as either Informational or Best Current Practice > Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for > publication as either Informational or Best Current Practice > Mar 2010 Recharter for additional optimization work involving > extensions to PMIPv6, IGMPv3, or MLDv2 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Thu Aug 13 09:54:24 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4F23A68CF for ; Thu, 13 Aug 2009 09:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 X5TW9wM+ZXSR for ; Thu, 13 Aug 2009 09:54:23 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.105]) by core3.amsl.com (Postfix) with ESMTP id 4F7F33A6B0D for ; Thu, 13 Aug 2009 09:53:58 -0700 (PDT) Received: from localhost (G045192.ppp.dion.ne.jp [210.251.45.192]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 1CEF413D06C8; Fri, 14 Aug 2009 00:54:19 +0900 (JST) Date: Fri, 14 Aug 2009 00:54:18 +0900 (JST) Message-Id: <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> To: jari.arkko@piuha.net From: Hitoshi Asaeda In-Reply-To: <4A8406CC.1090308@piuha.net> References: <4A8406CC.1090308@piuha.net> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:54:24 -0000 Hi Jari, > The Multicast mobility (multimob) working group provides guidance for > supporting multicast in a mobile environment. The scope of work will > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener > mobility. Work requiring modifications to mobility protocols, > MLD/IGMP, and multicast routing protocols is out of scope in this > first stage of this working group. IMO, it is too early to decide to eliminate the discussions of protocol modifications. And what is the expected efforts or advantages by completely eliminating the discussions of protocol modifications in this group? Without discussions of protocol modifications, what kinds of deployment scenarios do you expect? I cannot get the great benefit of eliminating such discussions, by explicitly mentioning "modifications to mobility protocols, MLD/IGMP, and multicast routing protocols is out of scope". In my sense, some of protocol modifications are not always for "optimization", but for "necessary discussion for its deployment". I'd therefore say keeping discussion space for protocol modifications is better, even with the lower priority than Info/BCP documents. Any thoughts? Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Thu Aug 13 13:47:33 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75CE3A68CF for ; Thu, 13 Aug 2009 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 J9Dl3W5vauIq for ; Thu, 13 Aug 2009 13:47:32 -0700 (PDT) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id D69DF3A6899 for ; Thu, 13 Aug 2009 13:47:32 -0700 (PDT) Received: (qmail 7214 invoked by uid 60001); 13 Aug 2009 20:45:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250196355; bh=pEQ4EdwJ3X3RGNH0pcQlXH4MuzBV1xB52W26WEhhAEY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5oj+P32oGjIZsjLjxLc0PcnSdpOkr7elfYerKzw59km6yp5HFL9GKvJy0IGnfaIQO8heBnoz9YRXcjANHI0u39Q1+zE1daQrVdzcle/mD40q+IasHyh9MK+Em/4WFqqHkwfxD7GzJ7OW2VEKwaSYR0q5JXXrL7B8nx0GIPpkRvg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZxfHgeEQn4gbUl5pIDwf28jnsAmkBQ3MqDP3tIqxehkMF2z4V+vjmdkylw/FTouarG/dFxtSUdit8uZgOgAo4GLEFYfV3u+ddNaEZVPQGHD1FQ/zGHJfSRPJteWG/Vx0yIu8AY+AnLwEGwuh2EBUvkSx+ruHpTYELAWkQ2M7cxk=; Message-ID: <355122.7113.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: S8Ogg1cVM1mDtBXbT2B3OwntMp9zKA4E4.KyzQx9K.PrFc_HqoiPazXB31qSj6x9iJjzeBk6dI4owZxYR9GN88bJwY3qw9yf7vMSCJd2L1ssLIHMrrumDKpq.uHGSO1Zdg93GgcvXvAFirmDLS0WejxwO9HHTJQkRByaQbqXi163kp7.WwiA8vWTqDTo6jje9zZienbQpyhXPgeVh52AdN76VM0oL4pGajhGG9e4OjtvqK9BBEL.sDWWNatJPANK2fiGyIg8WnWbUn791fDSLUN5TRkjxWG8RPd16OK0v21dWP613rMaXWjVa62ChcQFMHVDX5S3yYxKvzjthX9pj7c- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 13 Aug 2009 13:45:55 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <4A8406CC.1090308@piuha.net> <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> Date: Thu, 13 Aug 2009 13:45:55 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , jari.arkko@piuha.net In-Reply-To: <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:47:33 -0000 Hi Hitoshi,=0A=A0 Nobody is saying protocol modifications will not be consi= dered. The charter text is very clear as you cited below "in this first sta= ge of this working group" where no protocol modifications apply.=0A=0A=A0 C= onsidering protocol modifications a little bit later for example in 2010 in= the context of rechartering is OK, IMO.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A= ----- Original Message ----=0A> From: Hitoshi Asaeda =0A> To: jari.arkko@piuha.net=0A> Cc: multimob@ietf.org=0A> Sent: Thursday= , August 13, 2009 10:54:18 AM=0A> Subject: Re: [multimob] MULTIMOB BOF outc= ome=0A> =0A> Hi Jari,=0A> =0A> > The Multicast mobility (multimob) working = group provides guidance for=0A> > supporting multicast in a mobile environm= ent. The scope of work will=0A> > be limited to Proxy Mobile IPv6, MLD/IGMP= protocols and listener=0A> > mobility. Work requiring modifications to mob= ility protocols,=0A> > MLD/IGMP, and multicast routing protocols is out of = scope in this=0A> > first stage of this working group.=0A> =0A> IMO, it is = too early to decide to eliminate the discussions of=0A> protocol modificati= ons.=0A> And what is the expected efforts or advantages by completely=0A> e= liminating the discussions of protocol modifications in this group?=0A> Wit= hout discussions of protocol modifications, what kinds of=0A> deployment sc= enarios do you expect?=0A> =0A> I cannot get the great benefit of eliminati= ng such discussions, by=0A> explicitly mentioning "modifications to mobilit= y protocols, MLD/IGMP,=0A> and multicast routing protocols is out of scope"= .=0A> =0A> In my sense, some of protocol modifications are not always for= =0A> "optimization", but for "necessary discussion for its deployment".=0A>= =0A> I'd therefore say keeping discussion space for protocol modifications= =0A> is better, even with the lower priority than Info/BCP documents.=0A> = =0A> Any thoughts?=0A> =0A> Regards,=0A> --=0A> Hitoshi Asaeda=0A> ________= _______________________________________=0A> multimob mailing list=0A> multi= mob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multimob=0A=0A=0A=0A= From waehlisch@ieee.org Thu Aug 13 15:47:45 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0027F3A6CD5 for ; Thu, 13 Aug 2009 15:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 R+-Z4US0sB+m for ; Thu, 13 Aug 2009 15:47:44 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id F3B313A6D0A for ; Thu, 13 Aug 2009 15:47:43 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178148007.adsl.alicedsl.de ([85.178.148.7] helo=mw-thinkpad) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Mbj4p-000Oqd-MH; Fri, 14 Aug 2009 00:47:20 +0200 Date: Fri, 14 Aug 2009 00:47:12 +0200 From: Matthias Waehlisch To: Hitoshi Asaeda In-Reply-To: <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> Message-ID: References: <4A8406CC.1090308@piuha.net> <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 22:47:45 -0000 Hi Hitoshi, hi all, On Fri, 14 Aug 2009, Hitoshi Asaeda wrote: > > The Multicast mobility (multimob) working group provides guidance for > > supporting multicast in a mobile environment. The scope of work will > > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener > > mobility. Work requiring modifications to mobility protocols, > > MLD/IGMP, and multicast routing protocols is out of scope in this > > first stage of this working group. > > IMO, it is too early to decide to eliminate the discussions of protocol > modifications. [...] > that's no problem if you look on the very short-term charter. A re-chartering is scheduled for the 77th IETF ... A narrow scope with a tight schedule is fine. I vote for option two, as well - it's a good chance to start with the topic at all. Regards matthias -- Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From stig@venaas.com Thu Aug 13 16:40:35 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0818B3A6D40 for ; Thu, 13 Aug 2009 16:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqBy56wivvUC for ; Thu, 13 Aug 2009 16:40:33 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 2E3793A6BCF for ; Thu, 13 Aug 2009 16:40:33 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id D450234096; Fri, 14 Aug 2009 01:40:35 +0200 (CEST) Message-ID: <4A84A471.5090606@venaas.com> Date: Thu, 13 Aug 2009 16:40:33 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Matthias Waehlisch References: <4A8406CC.1090308@piuha.net> <20090814.005418.166941805.asaeda@sfc.wide.ad.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:40:35 -0000 Matthias Waehlisch wrote: > Hi Hitoshi, hi all, > > On Fri, 14 Aug 2009, Hitoshi Asaeda wrote: > >>> The Multicast mobility (multimob) working group provides guidance for >>> supporting multicast in a mobile environment. The scope of work will >>> be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener >>> mobility. Work requiring modifications to mobility protocols, >>> MLD/IGMP, and multicast routing protocols is out of scope in this >>> first stage of this working group. >> IMO, it is too early to decide to eliminate the discussions of protocol >> modifications. > [...] > that's no problem if you look on the very short-term charter. A > re-chartering is scheduled for the 77th IETF ... A narrow scope with a > tight schedule is fine. I vote for option two, as well - it's a good > chance to start with the topic at all. I agree. It makes sense to focus on getting those fundamental documents done first. Making the initial charter very focused is probably good, and the initial documents would be of use to any further work in the area. Stig > Regards > matthias > From liuhui47967@huawei.com Thu Aug 13 19:00:02 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739763A6B58 for ; Thu, 13 Aug 2009 19:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sAV-uW3PM25 for ; Thu, 13 Aug 2009 19:00:01 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 84BFA3A6CD2 for ; Thu, 13 Aug 2009 19:00:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC0004NG4OZ5@szxga04-in.huawei.com> for multimob@ietf.org; Fri, 14 Aug 2009 09:58:00 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC00B9YG4OBY@szxga04-in.huawei.com> for multimob@ietf.org; Fri, 14 Aug 2009 09:58:00 +0800 (CST) Received: from l47967b ([10.111.12.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOC005C0G4NNG@szxml06-in.huawei.com> for multimob@ietf.org; Fri, 14 Aug 2009 09:58:00 +0800 (CST) Date: Fri, 14 Aug 2009 09:58:00 +0800 From: Liu Hui In-reply-to: <4A84A471.5090606@venaas.com> To: 'Stig Venaas' , 'Matthias Waehlisch' Message-id: <001301ca1c82$a6f23da0$8b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: Acocb3yMO/5AS16+TB6e/K91pzY/5AADIgdQ Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:00:02 -0000 Hi all, I agree with stig that the fundemental documents are necessary to be prepared as the guidance for the future work. And option 2 proposed by Jari seems a reasonable compromise at this moment. BRs, Liu Hui > -----Original Message----- > From: multimob-bounces@ietf.org > [mailto:multimob-bounces@ietf.org] On Behalf Of Stig Venaas > Sent: Friday, August 14, 2009 7:41 AM > To: Matthias Waehlisch > Cc: multimob@ietf.org > Subject: Re: [multimob] MULTIMOB BOF outcome > > Matthias Waehlisch wrote: > > Hi Hitoshi, hi all, > > > > On Fri, 14 Aug 2009, Hitoshi Asaeda wrote: > > > >>> The Multicast mobility (multimob) working group provides guidance > >>> for supporting multicast in a mobile environment. The > scope of work > >>> will be limited to Proxy Mobile IPv6, MLD/IGMP protocols and > >>> listener mobility. Work requiring modifications to mobility > >>> protocols, MLD/IGMP, and multicast routing protocols is > out of scope > >>> in this first stage of this working group. > >> IMO, it is too early to decide to eliminate the discussions of > >> protocol modifications. > > [...] > > that's no problem if you look on the very short-term charter. A > > re-chartering is scheduled for the 77th IETF ... A narrow > scope with a > > tight schedule is fine. I vote for option two, as well - > it's a good > > chance to start with the topic at all. > > I agree. It makes sense to focus on getting those fundamental > documents done first. Making the initial charter very focused > is probably good, and the initial documents would be of use > to any further work in the area. > > Stig > > > Regards > > matthias > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Fri Aug 14 01:10:24 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90DD128C105 for ; Fri, 14 Aug 2009 01:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bXx4838+Ljp for ; Fri, 14 Aug 2009 01:10:23 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id ED1A73A6A18 for ; Fri, 14 Aug 2009 01:10:22 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 Aug 2009 10:08:48 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 10:08:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 10:08:47 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848013F4210@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] MULTIMOB BOF outcome Thread-Index: AcocaBv5MkAPuWZDSMC3AxKwuIEFswATIpuw References: <4A8406CC.1090308@piuha.net><20090814.005418.166941805.asaeda@sfc.wide.ad.jp> From: To: , X-OriginalArrivalTime: 14 Aug 2009 08:08:48.0532 (UTC) FILETIME=[73C3D540:01CA1CB6] Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 08:10:24 -0000 Hi all, =20 As we already had envisaged to focus on the BCP document w/o protocol = modifications in the first phase anyway, IMHO the actual difference is = not too large between options 2 and 3. Of course it would be nice to = have the 'complete program' for the WG in the very beginning, but as = chances to start with work at all seem to increase with the two-stage = approach, I am fine with Jari's proposal and a very concise roadmap. Once we have shown in detail the remaining open issues for deployment = the justification for work extension is even better so that = re-chartering should face no real trouble ;-) ... Thanks! Best regards, Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von Matthias Waehlisch Gesendet: Freitag, 14. August 2009 00:47 An: Hitoshi Asaeda Cc: multimob@ietf.org Betreff: Re: [multimob] MULTIMOB BOF outcome Hi Hitoshi, hi all, On Fri, 14 Aug 2009, Hitoshi Asaeda wrote: > > The Multicast mobility (multimob) working group provides guidance = for=20 > > supporting multicast in a mobile environment. The scope of work will = > > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener=20 > > mobility. Work requiring modifications to mobility protocols,=20 > > MLD/IGMP, and multicast routing protocols is out of scope in this=20 > > first stage of this working group. >=20 > IMO, it is too early to decide to eliminate the discussions of = protocol=20 > modifications. [...] > that's no problem if you look on the very short-term charter. A=20 re-chartering is scheduled for the 77th IETF ... A narrow scope with a=20 tight schedule is fine. I vote for option two, as well - it's a good=20 chance to start with the topic at all. Regards matthias --=20 Matthias Waehlisch . FU Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From fu@cs.uni-goettingen.de Fri Aug 14 14:00:49 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC403A68C5 for ; Fri, 14 Aug 2009 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 MP+1AIJRAHvQ for ; Fri, 14 Aug 2009 14:00:49 -0700 (PDT) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id BA2EF3A63CB for ; Fri, 14 Aug 2009 14:00:48 -0700 (PDT) Received: from p5b03c5eb.dip.t-dialin.net ([91.3.197.235] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mc3s0-0002NJ-5n; Fri, 14 Aug 2009 22:59:28 +0200 Message-ID: <4A85D02E.1050402@cs.uni-goettingen.de> Date: Fri, 14 Aug 2009 22:59:26 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4A8406CC.1090308@piuha.net><20090814.005418.166941805.asaeda@sfc.wide.ad.jp> <643B0A1D1A13AB498304E0BBC8027848013F4210@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848013F4210@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:00:49 -0000 +1 Xiaoming Dirk.von-Hugo@telekom.de wrote: > Hi all, > > As we already had envisaged to focus on the BCP document w/o protocol modifications in the first phase anyway, IMHO the actual difference is not too large between options 2 and 3. Of course it would be nice to have the 'complete program' for the WG in the very beginning, but as chances to start with work at all seem to increase with the two-stage approach, I am fine with Jari's proposal and a very concise roadmap. > Once we have shown in detail the remaining open issues for deployment the justification for work extension is even better so that re-chartering should face no real trouble ;-) ... > > Thanks! > > Best regards, > Dirk > > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Matthias Waehlisch > Gesendet: Freitag, 14. August 2009 00:47 > An: Hitoshi Asaeda > Cc: multimob@ietf.org > Betreff: Re: [multimob] MULTIMOB BOF outcome > > Hi Hitoshi, hi all, > > On Fri, 14 Aug 2009, Hitoshi Asaeda wrote: > >>> The Multicast mobility (multimob) working group provides guidance for >>> supporting multicast in a mobile environment. The scope of work will >>> be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener >>> mobility. Work requiring modifications to mobility protocols, >>> MLD/IGMP, and multicast routing protocols is out of scope in this >>> first stage of this working group. >> IMO, it is too early to decide to eliminate the discussions of protocol >> modifications. > [...] > that's no problem if you look on the very short-term charter. A > re-chartering is scheduled for the 77th IETF ... A narrow scope with a > tight schedule is fine. I vote for option two, as well - it's a good > chance to start with the topic at all. > > > Regards > matthias > From jouni.nospam@gmail.com Mon Aug 17 01:56:16 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7EFA28C0FF for ; Mon, 17 Aug 2009 01:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 x5Km5A8JLmlS for ; Mon, 17 Aug 2009 01:56:15 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 161D628C167 for ; Mon, 17 Aug 2009 01:56:14 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so631294eye.31 for ; Mon, 17 Aug 2009 01:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=jUA+if8+HKvYGuZngOtSXNnKYpufa/AotV7W4YKAXqc=; b=UPV/tg1rKDGenQ0nSfIBAv+y98tpmjxvDFXRLLlFLhmjiNf4e6yN23x3NsQow8fdem 2WRvHTQbemutpRscoN95ru6Rc2mtalois2FAueQTI+qiPZ6EGnEqDGlr27V+pJTUqxs3 JxJd4M5GCY/5mTp5x8FoQ9c1tXFESlS7NIDg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=giHT67Qd9mCJt98HZeZjh66ooq0Vh9Bf6jINW1GGiY/GEqAZceGtc1HRtFGrC+3Cxk HoCz1b+PNDWIrhL2FsnC3mzxKrp3SUlL6dU5CcDD2Dt8fOHNML6DYlgNYONDxXfgjtUZ mIMFQKvJT2HAAtxhjPaNCUX6CL2f2UEH4tZuo= Received: by 10.210.144.16 with SMTP id r16mr2920905ebd.22.1250499376930; Mon, 17 Aug 2009 01:56:16 -0700 (PDT) Received: from ?10.254.0.233? ([192.100.123.77]) by mx.google.com with ESMTPS id 7sm11145660eyg.7.2009.08.17.01.56.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 01:56:16 -0700 (PDT) Message-Id: <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> From: jouni korhonen To: Jari Arkko In-Reply-To: <4A8406CC.1090308@piuha.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Aug 2009 11:56:13 +0300 References: <4A8406CC.1090308@piuha.net> X-Mailer: Apple Mail (2.936) Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 08:56:16 -0000 Hi, If we go for alternative 2 (which would be ok), the proposed modified charter is now more or less what I wanted & proposed earlier. I would be even stricter scoping the first phase assumptions: > changes to message types and parameters specified in RFC 5213, and > will assume an unmodified mobile host. The work will employ the remote > subscription model. This is mechanism by which a mobile node joins a s/will assume/must assume > Mar 2010 Recharter for additional optimization work involving > extensions to PMIPv6, IGMPv3, or MLDv2 Do we need to say here also "..or close the WG" ? Cheers, Jouni On Aug 13, 2009, at 3:27 PM, Jari Arkko wrote: > I have been thinking about what to do about this. My (remote) > interpretation of the meeting was that people in the room felt a WG is > needed and that the charter was reasonable. Due to scheduling and > other > reasons I don't think this is the entire picture, however. I think > parts > of the mobility community still feel that a working group is an > overkill > and/or the optimization work is unwarranted. However, I am personally > quite convinced that _some_ work is needed, given, for instance, the > fact that while implementing some forms of multicast in proxy MIP is > easy, the word multicast doesn't appear in the specification. > > I think we have realistically three options: > > 1. Put the work in an existing WG, such as NETEXT, as a part of > extensions and clarification work on proxy MIP. > 2. Create a new working group, but tune the charter from the proposed > one into a little bit more restrictive, mainly to remove too much > optimization work. Once this work is complete, we can more confidently > let the working group do the optimization work as well. > 3. Creata a working group as requested. > > I'm leaning on alternative 2, thoughts? Here's a proposed charter: > > Mobility Multicast (multimob) > > Chairs: > TBD > > Internet Area (int) Directors: > Jari Arkko > Ralph Droms > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: multimob@ietf.org > Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob > > Description of Working Group > > The Multicast mobility (multimob) working group provides guidance for > supporting multicast in a mobile environment. The scope of work will > be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener > mobility. Work requiring modifications to mobility protocols, > MLD/IGMP, and multicast routing protocols is out of scope in this > first stage of this working group. > > Specific goals are: > - Document how multicast can be supported in a Proxy Mobile IPv6 > environment > - Document the configuration of IGMP/MLD in mobile environments > > The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 > does not describe how to support multicast. Some forms of multicast > support can, however, be built in the involved nodes by using existing > capabilities of multicast protocols and the underlying mobility > protocols. The first task of the working group is to document such > solutions for PMIPv6. This work will not require any additions or > changes to message types and parameters specified in RFC 5213, and > will assume an unmodified mobile host. The work will employ the remote > subscription model. This is mechanism by which a mobile node joins a > multicast group and receives multicast data forwarded via the local > mobility anchor. > > IGMPv3/MLDv2 has been specified for wired networks with shared links. > Mobile nodes have needs that are specific to wireless networks and > mobility (e.g. entering a dormant mode to conserve battery power, > minimizing the latency for joining and leaving a group in support of > movement). > > The second task of the WG is to assess existing solutions for group > management, and determine to what extent these methods are sufficient > in a mobile environment. This will include recommending appropriate > selection of timer values and protocol parameters. > > In performing its work, the working group will work closely with both > the mobility community (NETLMM and NETEXT WGs) and the multicast > community (MBONED WG). The group will consider both source specific > multicast and any source multicast multicast models. > > Future work, subject to rechartering, may study/evaluate extensions to > support PMIPv6 optimizations to address the avalanche problem and fast > handover and extensions to IGMPv3/MLDv2 to support better operation in > mobile environments. > > Milestones: > > Nov 2009 Initial version of a document explaining the use of > multicast > in PMIPv6 > Nov 2009 Initial version of a document on how to tune IGMP/MLD for > mobility > Feb 2010 Submit a document explaining the use of multicast in PMIPv6, > for publication as either Informational or Best Current Practice > Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for > publication as either Informational or Best Current Practice > Mar 2010 Recharter for additional optimization work involving > extensions to PMIPv6, IGMPv3, or MLDv2 > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From jari.arkko@piuha.net Mon Aug 17 02:09:41 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9793A6EC8 for ; Mon, 17 Aug 2009 02:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF0TibqbQOKT for ; Mon, 17 Aug 2009 02:09:40 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8250728C16A for ; Mon, 17 Aug 2009 02:09:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1D02C198655; Mon, 17 Aug 2009 12:09:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFMZx6x6paVW; Mon, 17 Aug 2009 12:09:41 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 106FA1985ED; Mon, 17 Aug 2009 12:09:41 +0300 (EEST) Message-ID: <4A891E54.1030706@piuha.net> Date: Mon, 17 Aug 2009 12:09:40 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: jouni korhonen References: <4A8406CC.1090308@piuha.net> <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> In-Reply-To: <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 09:09:41 -0000 Jouni, I like the suggested wording changes. Jari jouni korhonen wrote: > Hi, > > If we go for alternative 2 (which would be ok), the proposed modified > charter is now more or less what I wanted & proposed earlier. I would > be even stricter scoping the first phase assumptions: > >> changes to message types and parameters specified in RFC 5213, and >> will assume an unmodified mobile host. The work will employ the remote >> subscription model. This is mechanism by which a mobile node joins a > > > s/will assume/must assume > >> Mar 2010 Recharter for additional optimization work involving >> extensions to PMIPv6, IGMPv3, or MLDv2 > > > > Do we need to say here also "..or close the WG" ? > > > Cheers, > Jouni > > > > On Aug 13, 2009, at 3:27 PM, Jari Arkko wrote: > >> I have been thinking about what to do about this. My (remote) >> interpretation of the meeting was that people in the room felt a WG is >> needed and that the charter was reasonable. Due to scheduling and other >> reasons I don't think this is the entire picture, however. I think parts >> of the mobility community still feel that a working group is an overkill >> and/or the optimization work is unwarranted. However, I am personally >> quite convinced that _some_ work is needed, given, for instance, the >> fact that while implementing some forms of multicast in proxy MIP is >> easy, the word multicast doesn't appear in the specification. >> >> I think we have realistically three options: >> >> 1. Put the work in an existing WG, such as NETEXT, as a part of >> extensions and clarification work on proxy MIP. >> 2. Create a new working group, but tune the charter from the proposed >> one into a little bit more restrictive, mainly to remove too much >> optimization work. Once this work is complete, we can more confidently >> let the working group do the optimization work as well. >> 3. Creata a working group as requested. >> >> I'm leaning on alternative 2, thoughts? Here's a proposed charter: >> >> Mobility Multicast (multimob) >> >> Chairs: >> TBD >> >> Internet Area (int) Directors: >> Jari Arkko >> Ralph Droms >> >> Internet Area Advisor: >> Jari Arkko >> >> Mailing Lists: >> General Discussion: multimob@ietf.org >> Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob >> >> Description of Working Group >> >> The Multicast mobility (multimob) working group provides guidance for >> supporting multicast in a mobile environment. The scope of work will >> be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener >> mobility. Work requiring modifications to mobility protocols, >> MLD/IGMP, and multicast routing protocols is out of scope in this >> first stage of this working group. >> >> Specific goals are: >> - Document how multicast can be supported in a Proxy Mobile IPv6 >> environment >> - Document the configuration of IGMP/MLD in mobile environments >> >> The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 >> does not describe how to support multicast. Some forms of multicast >> support can, however, be built in the involved nodes by using existing >> capabilities of multicast protocols and the underlying mobility >> protocols. The first task of the working group is to document such >> solutions for PMIPv6. This work will not require any additions or >> changes to message types and parameters specified in RFC 5213, and >> will assume an unmodified mobile host. The work will employ the remote >> subscription model. This is mechanism by which a mobile node joins a >> multicast group and receives multicast data forwarded via the local >> mobility anchor. >> >> IGMPv3/MLDv2 has been specified for wired networks with shared links. >> Mobile nodes have needs that are specific to wireless networks and >> mobility (e.g. entering a dormant mode to conserve battery power, >> minimizing the latency for joining and leaving a group in support of >> movement). >> >> The second task of the WG is to assess existing solutions for group >> management, and determine to what extent these methods are sufficient >> in a mobile environment. This will include recommending appropriate >> selection of timer values and protocol parameters. >> >> In performing its work, the working group will work closely with both >> the mobility community (NETLMM and NETEXT WGs) and the multicast >> community (MBONED WG). The group will consider both source specific >> multicast and any source multicast multicast models. >> >> Future work, subject to rechartering, may study/evaluate extensions to >> support PMIPv6 optimizations to address the avalanche problem and fast >> handover and extensions to IGMPv3/MLDv2 to support better operation in >> mobile environments. >> >> Milestones: >> >> Nov 2009 Initial version of a document explaining the use of multicast >> in PMIPv6 >> Nov 2009 Initial version of a document on how to tune IGMP/MLD for >> mobility >> Feb 2010 Submit a document explaining the use of multicast in PMIPv6, >> for publication as either Informational or Best Current Practice >> Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for >> publication as either Informational or Best Current Practice >> Mar 2010 Recharter for additional optimization work involving >> extensions to PMIPv6, IGMPv3, or MLDv2 >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From gorry@erg.abdn.ac.uk Mon Aug 17 05:54:30 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC2D43A69FD for ; Mon, 17 Aug 2009 05:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzABeEWeaR5Z for ; Mon, 17 Aug 2009 05:54:29 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 360B528C144 for ; Mon, 17 Aug 2009 05:53:54 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n7HCrsMe023522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2009 13:53:54 +0100 (BST) Message-ID: <4A8952E2.1030903@erg.abdn.ac.uk> Date: Mon, 17 Aug 2009 13:53:54 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jari Arkko References: <4A8406CC.1090308@piuha.net> <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> <4A891E54.1030706@piuha.net> In-Reply-To: <4A891E54.1030706@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 12:54:30 -0000 OK with me too. However, I think the decision to progress the IGMP/MLD protocol changes could be made independently of the decision for PMIP extension: these changes seem less architectural and have been discussed a number of times in the past - however, I think it would also be essential to first identify the solution space and produce the BCP/INFO on this topic, before advancing any PS. Gorry Jari Arkko wrote: > Jouni, > > I like the suggested wording changes. > > Jari > > jouni korhonen wrote: >> Hi, >> >> If we go for alternative 2 (which would be ok), the proposed modified >> charter is now more or less what I wanted & proposed earlier. I would >> be even stricter scoping the first phase assumptions: >> >>> changes to message types and parameters specified in RFC 5213, and >>> will assume an unmodified mobile host. The work will employ the remote >>> subscription model. This is mechanism by which a mobile node joins a >> >> >> s/will assume/must assume >> >>> Mar 2010 Recharter for additional optimization work involving >>> extensions to PMIPv6, IGMPv3, or MLDv2 >> >> >> >> Do we need to say here also "..or close the WG" ? >> >> >> Cheers, >> Jouni >> >> >> >> On Aug 13, 2009, at 3:27 PM, Jari Arkko wrote: >> >>> I have been thinking about what to do about this. My (remote) >>> interpretation of the meeting was that people in the room felt a WG is >>> needed and that the charter was reasonable. Due to scheduling and other >>> reasons I don't think this is the entire picture, however. I think parts >>> of the mobility community still feel that a working group is an overkill >>> and/or the optimization work is unwarranted. However, I am personally >>> quite convinced that _some_ work is needed, given, for instance, the >>> fact that while implementing some forms of multicast in proxy MIP is >>> easy, the word multicast doesn't appear in the specification. >>> >>> I think we have realistically three options: >>> >>> 1. Put the work in an existing WG, such as NETEXT, as a part of >>> extensions and clarification work on proxy MIP. >>> 2. Create a new working group, but tune the charter from the proposed >>> one into a little bit more restrictive, mainly to remove too much >>> optimization work. Once this work is complete, we can more confidently >>> let the working group do the optimization work as well. >>> 3. Creata a working group as requested. >>> >>> I'm leaning on alternative 2, thoughts? Here's a proposed charter: >>> >>> Mobility Multicast (multimob) >>> >>> Chairs: >>> TBD >>> >>> Internet Area (int) Directors: >>> Jari Arkko >>> Ralph Droms >>> >>> Internet Area Advisor: >>> Jari Arkko >>> >>> Mailing Lists: >>> General Discussion: multimob@ietf.org >>> Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob >>> >>> Description of Working Group >>> >>> The Multicast mobility (multimob) working group provides guidance for >>> supporting multicast in a mobile environment. The scope of work will >>> be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener >>> mobility. Work requiring modifications to mobility protocols, >>> MLD/IGMP, and multicast routing protocols is out of scope in this >>> first stage of this working group. >>> >>> Specific goals are: >>> - Document how multicast can be supported in a Proxy Mobile IPv6 >>> environment >>> - Document the configuration of IGMP/MLD in mobile environments >>> >>> The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 >>> does not describe how to support multicast. Some forms of multicast >>> support can, however, be built in the involved nodes by using existing >>> capabilities of multicast protocols and the underlying mobility >>> protocols. The first task of the working group is to document such >>> solutions for PMIPv6. This work will not require any additions or >>> changes to message types and parameters specified in RFC 5213, and >>> will assume an unmodified mobile host. The work will employ the remote >>> subscription model. This is mechanism by which a mobile node joins a >>> multicast group and receives multicast data forwarded via the local >>> mobility anchor. >>> >>> IGMPv3/MLDv2 has been specified for wired networks with shared links. >>> Mobile nodes have needs that are specific to wireless networks and >>> mobility (e.g. entering a dormant mode to conserve battery power, >>> minimizing the latency for joining and leaving a group in support of >>> movement). >>> >>> The second task of the WG is to assess existing solutions for group >>> management, and determine to what extent these methods are sufficient >>> in a mobile environment. This will include recommending appropriate >>> selection of timer values and protocol parameters. >>> >>> In performing its work, the working group will work closely with both >>> the mobility community (NETLMM and NETEXT WGs) and the multicast >>> community (MBONED WG). The group will consider both source specific >>> multicast and any source multicast multicast models. >>> >>> Future work, subject to rechartering, may study/evaluate extensions to >>> support PMIPv6 optimizations to address the avalanche problem and fast >>> handover and extensions to IGMPv3/MLDv2 to support better operation in >>> mobile environments. >>> >>> Milestones: >>> >>> Nov 2009 Initial version of a document explaining the use of multicast >>> in PMIPv6 >>> Nov 2009 Initial version of a document on how to tune IGMP/MLD for >>> mobility >>> Feb 2010 Submit a document explaining the use of multicast in PMIPv6, >>> for publication as either Informational or Best Current Practice >>> Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for >>> publication as either Informational or Best Current Practice >>> Mar 2010 Recharter for additional optimization work involving >>> extensions to PMIPv6, IGMPv3, or MLDv2 >>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > From jari.arkko@piuha.net Mon Aug 17 06:26:21 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248D928C0D8 for ; Mon, 17 Aug 2009 06:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpennWIx1jfv for ; Mon, 17 Aug 2009 06:26:20 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 437D83A6A05 for ; Mon, 17 Aug 2009 06:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ECFAB19863D; Mon, 17 Aug 2009 16:26:24 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvPhBQiBK9tH; Mon, 17 Aug 2009 16:26:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7FFE0198639; Mon, 17 Aug 2009 16:26:24 +0300 (EEST) Message-ID: <4A895A7F.3090000@piuha.net> Date: Mon, 17 Aug 2009 16:26:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4A8406CC.1090308@piuha.net> <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> <4A891E54.1030706@piuha.net> <4A8952E2.1030903@erg.abdn.ac.uk> In-Reply-To: <4A8952E2.1030903@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 13:26:21 -0000 Gorry Fairhurst wrote: > > OK with me too. > > However, I think the decision to progress the IGMP/MLD protocol > changes could be made independently of the decision for PMIP extension: Perhaps we need two separate milestones for the two different tracks and their associated rechartering events. Jari From gorry@erg.abdn.ac.uk Mon Aug 17 07:43:48 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298D13A6F0B for ; Mon, 17 Aug 2009 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+pQgfdmW6ZD for ; Mon, 17 Aug 2009 07:43:47 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 070653A6A31 for ; Mon, 17 Aug 2009 07:43:46 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n7HEhind026415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2009 15:43:45 +0100 (BST) Message-ID: <4A896CA1.5080307@erg.abdn.ac.uk> Date: Mon, 17 Aug 2009 15:43:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jari Arkko References: <4A8406CC.1090308@piuha.net> <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> <4A891E54.1030706@piuha.net> <4A8952E2.1030903@erg.abdn.ac.uk> <4A895A7F.3090000@piuha.net> In-Reply-To: <4A895A7F.3090000@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:43:48 -0000 Jari Arkko wrote: > Gorry Fairhurst wrote: >> >> OK with me too. >> >> However, I think the decision to progress the IGMP/MLD protocol >> changes could be made independently of the decision for PMIP extension: > > Perhaps we need two separate milestones for the two different tracks and > their associated rechartering events. > > Jari > > That could work, or have one rechartering discussion, but remember there are two separate issues to be addressed and both need decisions. Gorry From behcetsarikaya@yahoo.com Mon Aug 17 08:36:06 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B093A6AA6 for ; Mon, 17 Aug 2009 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 113XYS68td+y for ; Mon, 17 Aug 2009 08:36:05 -0700 (PDT) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id AB6933A672E for ; Mon, 17 Aug 2009 08:36:05 -0700 (PDT) Received: (qmail 22968 invoked by uid 60001); 17 Aug 2009 15:36:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250523368; bh=xu7l+UghZQSJiC/YIJxuCV4PU4KsvTk7sRRV9bj2WRo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lABc0hBahj8jsbh8dnZldREO/GX2ykBnBAD/fic+cdPB9grthMmfCu7QBV2ad1BH4Lacjn8tjUU9Klsf/oR6YkfzsYoKLKsiRYtKqaQcCgKXxqVJkLILVAVx+/zYLrPRiEbp+7JChmjpd7LTlTzuXTaS7x65ljJ0+9caYpVF9O0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FU+F4N0tviOBW3ClS23O8AiAT+UguWsTf4tm6HBc7vMCeN8dM8ioDat5ov2i5J62933BzYhHi2/qvjzEOezBguL7Aoj/Ny9Cp6uxqyIVxMcACC39wYSp1uS8A4TNb1sRfOyW7XHBKQj6tDBK6EGaonuvWoAOMW8li9506oYZPRk=; Message-ID: <635527.22154.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: vRBRnekVM1mKe0lv3OiWJW_KzRmN0DHGblw4t.W7_2sqL4S_1EFMnYEg5zheChxf6Fk04hmNpW.YGCA3AvhAmjrhybMlclGG9fYxD2ODHh6p0Ki9ZlcSaNEpL628XM69i4ZclJ8mQxF4XQyB7WO4oAd70PBY1iVSorWiN1u_z2kjhdbpQ7V5TiZFvT5rZ.1o_z_v6SL4OgrDrpVADZbfxu37tdZGtxQqZ8rR9MeURzQnUGCwk4Cc7MdsMkjnUUgDTGxRXI5m6bMdczUi1plyzOSDNga3X_eQt6qxCC_.jq9XWmNKL1b7s1hyaloaboaBj6Oovxc_FCts9FAmbHW2uyVCQQ-- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Mon, 17 Aug 2009 08:36:08 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <4A8406CC.1090308@piuha.net> <75EEB94E-276D-418B-BF02-24C0CA27A305@gmail.com> <4A891E54.1030706@piuha.net> <4A8952E2.1030903@erg.abdn.ac.uk> <4A895A7F.3090000@piuha.net> <4A896CA1.5080307@erg.abdn.ac.uk> Date: Mon, 17 Aug 2009 08:36:08 -0700 (PDT) From: Behcet Sarikaya To: gorry@erg.abdn.ac.uk, Jari Arkko In-Reply-To: <4A896CA1.5080307@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] MULTIMOB BOF outcome X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:36:06 -0000 ----- Original Message ---- > From: Gorry Fairhurst > To: Jari Arkko > Cc: multimob@ietf.org > Sent: Monday, August 17, 2009 9:43:45 AM > Subject: Re: [multimob] MULTIMOB BOF outcome > > Jari Arkko wrote: > > Gorry Fairhurst wrote: > >> > >> OK with me too. > >> > >> However, I think the decision to progress the IGMP/MLD protocol changes could > be made independently of the decision for PMIP extension: > > > > Perhaps we need two separate milestones for the two different tracks and their > associated rechartering events. > > > > Jari > > > > > That could work, or have one rechartering discussion, but remember there are two > separate issues to be addressed and both need decisions. > I don't really see this as an issue that requires any charter text changes. Let's keep the charter text as is and during rechartering, make sure not to mix up the protocol changes in two very different protocols. Regards, Behcet From root@core3.amsl.com Tue Aug 18 10:30:02 2009 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F3A343A6A13; Tue, 18 Aug 2009 10:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090818173001.F3A343A6A13@core3.amsl.com> Date: Tue, 18 Aug 2009 10:30:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Aug 2009 10:51:25 -0700 Cc: multimob@ietf.org Subject: [multimob] WG Review: Mobility Multicast (multimob) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:30:02 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 25, 2009. Mobility Multicast (multimob) ------------------------------- Current Status: Proposed Working Group Last Modified: 2009-08-07 Chairs: TBD Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: multimob@ietf.org Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob Description of Working Group The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener mobility. Work requiring modifications to mobility protocols, MLD/IGMP, and multicast routing protocols is out of scope in this first stage of this working group. Specific goals are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMP/MLD in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and will assume an unmodified mobile host. The work will employ the remote subscription model. This is mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Milestones: Nov 2009 Initial version of a document explaining the use of multicast in PMIPv6 Nov 2009 Initial version of a document on how to tune IGMP/MLD for mobility Feb 2010 Submit a document explaining the use of multicast in PMIPv6, for publication as either Informational or Best Current Practice Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for publication as either Informational or Best Current Practice Mar 2010 Recharter for additional optimization work involving extensions to PMIPv6, IGMPv3, or MLDv2 From soohongp@gmail.com Thu Aug 27 02:21:33 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B9C3A6DBF for ; Thu, 27 Aug 2009 02:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 8ungdolf0YjU for ; Thu, 27 Aug 2009 02:21:32 -0700 (PDT) Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.211.177]) by core3.amsl.com (Postfix) with ESMTP id 257463A6DA6 for ; Thu, 27 Aug 2009 02:21:32 -0700 (PDT) Received: by ywh7 with SMTP id 7so1136417ywh.21 for ; Thu, 27 Aug 2009 02:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=rtanAdeSoPdatmq2NzsrPdYJCUQSkQODXVteNdbjp/8=; b=hoa48a5jOwNromMdXH+Y70yHi9DgN9KHJdVh0ZXcdQqgRVawq5KSScRL334aHCGi3W uJDz5o4uEjNYaEnZ+ulXRJuXpBfM/eE/AsPe71UDI7oLKLS3wCney7W1u2tyOGYzqTyC kUlvGlSY8c7j5U3HnHdkaA4i3l6qeRxWQHBIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EKAAglNcTBSJGKbkdrLgRRaqplarSGM0RQURBy3655xyLUR4qJRcnMjGzpyJIJv106 aAOUV6OcWrc9doyI4j5NSJ402XFEQ5uoEFzOkisff8gxJargQtFVRxURGnGZVsrKDOEW dBD1ooOFEVTCDktuTlA13gYmutZvntMk4e2Vc= MIME-Version: 1.0 Received: by 10.150.56.21 with SMTP id e21mr12595271yba.219.1251364894228; Thu, 27 Aug 2009 02:21:34 -0700 (PDT) Date: Thu, 27 Aug 2009 18:21:34 +0900 Message-ID: From: Daniel Park To: multimob@ietf.org Content-Type: multipart/alternative; boundary=000e0cd61a3401422604721c1833 Subject: [multimob] Status of BOF ? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 09:21:33 -0000 --000e0cd61a3401422604721c1833 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Anybody can do let me know the status of this BOF ? Still in progress ? due to missing over the previous sweden's IETF...:-) Thanks in advance, --=20 Soohong Daniel Park Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung Electronics, KOREA NOTE: =BA=BB =B8=DE=C0=CF=C0=BA Gmail=BF=A1=BC=AD =B9=DF=BC=DB=B5=C7=BE=FA= =BD=C0=B4=CF=B4=D9 --000e0cd61a3401422604721c1833 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Anybody can do let me know the status of this BOF ? Still in progress = ? due to missing over the previous sweden's IETF...:-)
 
 
Thanks in advance,

--

Soohong Daniel Park
Standard Architect, http://blog.naver.com/natpt
DMC B= usiness, Samsung Electronics, KOREA

NOTE: =BA=BB =B8=DE=C0=CF=C0=BA = Gmail=BF=A1=BC=AD =B9=DF=BC=DB=B5=C7=BE=FA=BD=C0=B4=CF=B4=D9
--000e0cd61a3401422604721c1833-- From jari.arkko@piuha.net Thu Aug 27 03:26:20 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B86328C37A for ; Thu, 27 Aug 2009 03:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPVFfaZrsE8E for ; Thu, 27 Aug 2009 03:26:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BDD6A28C362 for ; Thu, 27 Aug 2009 03:26:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 71B90198657; Thu, 27 Aug 2009 13:26:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x86dxRVPWtKQ; Thu, 27 Aug 2009 13:26:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 86EB61985FB; Thu, 27 Aug 2009 13:26:24 +0300 (EEST) Message-ID: <4A965F4F.30905@piuha.net> Date: Thu, 27 Aug 2009 13:26:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Daniel Park References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Status of BOF ? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 10:26:20 -0000 There's a proposed charter which is in its public review period. I expect the WG to be created soon. Jari From soohongp@gmail.com Thu Aug 27 19:10:44 2009 Return-Path: X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BD13A6B47 for ; Thu, 27 Aug 2009 19:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 uOCBNdVi2Ikl for ; Thu, 27 Aug 2009 19:10:43 -0700 (PDT) Received: from mail-yw0-f186.google.com (mail-yw0-f186.google.com [209.85.211.186]) by core3.amsl.com (Postfix) with ESMTP id F1D7C3A6A21 for ; Thu, 27 Aug 2009 19:10:42 -0700 (PDT) Received: by ywh16 with SMTP id 16so922371ywh.19 for ; Thu, 27 Aug 2009 19:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=E7oQv/3nZ828zQMVq0IvN6rUtiHzT+A744mTycbfyRM=; b=gF8xppAlDy4dt32Y2thEGoFSW3Mjray9KgwlaROGXCg4I/0iMlwOO4dEXkIgy7RHM+ g+FxXdVRi9BvUL4NkH/bayJpG25pM9On2bVbQhLrALCGJB+6PeXtchCXvMIM8nUDtQzK gsOrMvXr5NNZOSugHagVot4+tNs7APiijqrZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W0ahewMDjBYvEVjXt2YllLgH9Dsui9qpX5r1QjbjOZeM4cKHTAFk02DaLFVyscxIsY XG/pfpnIhx66amiJPotkoedKfzRDvjJl1qcV+Qp1jwwDPKfNWvOPj40hhfEGImt27GCY WOYQLUpPtm+1JaS/LuPTNarck9IeppAkZMa7w= MIME-Version: 1.0 Received: by 10.150.104.2 with SMTP id b2mr1117321ybc.19.1251425447020; Thu, 27 Aug 2009 19:10:47 -0700 (PDT) In-Reply-To: <4A965F4F.30905@piuha.net> References: <4A965F4F.30905@piuha.net> Date: Fri, 28 Aug 2009 11:10:46 +0900 Message-ID: From: Daniel Park To: Jari Arkko Content-Type: multipart/alternative; boundary=000e0cd47f103b8b4404722a319a Cc: multimob@ietf.org Subject: Re: [multimob] Status of BOF ? X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:10:44 -0000 --000e0cd47f103b8b4404722a319a Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Thanks, This activity might be very helpful for me to widely deploy IPTV services over wireless environments called Mobile IPTV. Lot of multicasting channels will run in wireless and mobility happen occationally... Good news, and thanks Jari. Daniel On Thu, Aug 27, 2009 at 7:26 PM, Jari Arkko wrote: > There's a proposed charter which is in its public review period. I expect > the WG to be created soon. > > Jari > > --=20 Soohong Daniel Park Standard Architect, http://blog.naver.com/natpt DMC Business, Samsung Electronics, KOREA NOTE: =BA=BB =B8=DE=C0=CF=C0=BA Gmail=BF=A1=BC=AD =B9=DF=BC=DB=B5=C7=BE=FA= =BD=C0=B4=CF=B4=D9 --000e0cd47f103b8b4404722a319a Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Thanks,
 
This activity might be very helpful for me to widely deploy IPTV = services over wireless environments called Mobile IPTV. Lot of multicasting= channels will run in wireless and mobility happen occationally...
 
Good news, and thanks Jari.
 
Daniel

On Thu, Aug 27, 2009 at 7:26 PM, Jari Arkko <jari.arkko@piuha.= net> wrote:
There's a proposed charter w= hich is in its public review period. I expect the WG to be created soon.
Jari




--

Soohong Daniel Park
Standard Architect, http://blog.naver.com/natpt
DMC B= usiness, Samsung Electronics, KOREA

NOTE: =BA=BB =B8=DE=C0=CF=C0=BA = Gmail=BF=A1=BC=AD =B9=DF=BC=DB=B5=C7=BE=FA=BD=C0=B4=CF=B4=D9
--000e0cd47f103b8b4404722a319a--