From sarikaya2012@gmail.com Tue Nov 1 12:12:25 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E161F11E80F6 for ; Tue, 1 Nov 2011 12:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz+3OX0JS2Df for ; Tue, 1 Nov 2011 12:12:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 541BD11E80F4 for ; Tue, 1 Nov 2011 12:12:25 -0700 (PDT) Received: by ggnv1 with SMTP id v1so8752993ggn.31 for ; Tue, 01 Nov 2011 12:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=BbSk3SU5wg/slwxNARpcHdnshsmEq6nHo8RmvsR7U1M=; b=ryN8+sYcsHr8XkfVB4FyuoP/31BvoOKwnGa+EiqbFXQ4LE4BMjQJwqduv9GS9MD23z rHAcBYInh8SasLidSrv3+NBvFj3ROtP2y/vwvOjJJviJSktLEQ8HN0NPSLbdCN6ULNEJ 9yXM3fm38EKOqX27JPp7HUlcwNosDAfxoeppM= MIME-Version: 1.0 Received: by 10.236.175.4 with SMTP id y4mr905095yhl.128.1320174708535; Tue, 01 Nov 2011 12:11:48 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Tue, 1 Nov 2011 12:11:48 -0700 (PDT) Date: Tue, 1 Nov 2011 14:11:48 -0500 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf305b0a568b30b704b0b12016 Subject: [multimob] Final agenda posted X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:12:26 -0000 --20cf305b0a568b30b704b0b12016 Content-Type: text/plain; charset=ISO-8859-1 Folks, The finalized agenda is now online. Presenters: please send your slides to the chairs. Note takers, Jabber scribes: please volunteer. Regards, Behcet --20cf305b0a568b30b704b0b12016 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,
=A0 The finalized agenda is now online.

Presenters: pleas= e send your slides to the chairs.

Note takers, Jabber scribes: pleas= e volunteer.

Regards,

Behcet
--20cf305b0a568b30b704b0b12016-- From asaeda@sfc.wide.ad.jp Mon Nov 7 23:30:05 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447EE21F8CE1 for ; Mon, 7 Nov 2011 23:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.847 X-Spam-Level: X-Spam-Status: No, score=-100.847 tagged_above=-999 required=5 tests=[AWL=1.752, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYw58C3W97PN for ; Mon, 7 Nov 2011 23:30:04 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id C23B021F8CD6 for ; Mon, 7 Nov 2011 23:29:49 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1320927807F for ; Tue, 8 Nov 2011 16:29:48 +0900 (JST) Date: Tue, 08 Nov 2011 16:29:47 +0900 (JST) Message-Id: <20111108.162947.166997496.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [multimob] comments for draft-contreras-multimob-rams-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 07:30:05 -0000 Hi, I have reviewed draft-contreras-multimob-rams-03 and have some comments. In this draft the authors propose "proactive" handover and "reactive" handover, but it was difficult to understand the benefit of the extension for reactive handover, or how the proposed reactive handover accelerates handover. Regarding the reactive handover, sect.4.2.1 says; "After receiving the PBU message from the nMAG, the LMA will take the decision of interrogating or not the pMAG regarding any existing multicast subscription for that MN. Once the multicast subscription information is retrieved from the pMAG, the LMA encapsulates it in the PBA message by using the TLV option "Active Multicast Subscription", and forwards the PBA message to the nMAG. Then, the nMAG can subscribe the multicast flow on behalf of the MN, if there is no other MN receiving it already at the nMAG." However, the reactive handover explained in section 4 requires exchanging many messages and complex procedures, and I cannot find the big advantage of providing such extension. In fact, when we tune Startup Query Interval to a shorter period (see sect.4.4 in draft-ietf-multimob-igmp-mld-tuning-02.txt), nMAG scarcely triggers MLD general query and obtains the current state record from the MN when the MN attaches to the new PtoP link. This is simple and does not require LMA's involvement. Moreover, the proposed reactive handover requires new messages called "Subscription Query" and "Subscription Response". But usually the procedures to recognize multicast subscription status are done by the standard MLD and we don't need these new messages if we use the regular MLD. Other comment. For both proactive and reactive handover, "Active Multicast Subscription" option is used with PBU/PBA. But this option format is not congruent with RFC3810. A multicast record must include filter more and must be capable of including multiple source addresses for one group record. (If you ignore the exclude filter mode operations, you must explicitly say so and provide the procedure how you ignore the explicit filter mode operations.) Null source address must be also allowed. Although I didn't know the fact, our PMIPv6 extension draft includes similar message extension. You may want to refer the format in PBU-M and PBA-M proposed in our PMIPv6 extension draft. And at last, the name of "RAMS" may not be appropriate, as RAMS is already well known as Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RFC6285) and some of AVT drafts have been using this term. Regards, -- Hitoshi Asaeda From sarikaya2012@gmail.com Wed Nov 9 16:01:03 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149711E809A for ; Wed, 9 Nov 2011 16:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRq70yCj2rmA for ; Wed, 9 Nov 2011 16:01:03 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4344C11E8080 for ; Wed, 9 Nov 2011 16:01:03 -0800 (PST) Received: by ywt34 with SMTP id 34so26482ywt.31 for ; Wed, 09 Nov 2011 16:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=DjQ7q7nz/WnRCE4FXGTWYMN4Gs8KoENVbmJmWw4Dw1s=; b=cV5iK6Q7GGt+iBVhB1W8ndik28BppxG/uwZb6yovnz1qMJUTWR07lZwE8+MLrRYdzW FTSsIAEufeMvEfDdbvf4XuWN6TPVn7EbXMLDNQOu1uNZVfRI262yT776soysR/fcGtAS mxYi/205Z96Ndt3MaVbQTAYuVuUnrU0qepdoU= MIME-Version: 1.0 Received: by 10.101.137.38 with SMTP id p38mr2209179ann.33.1320883262617; Wed, 09 Nov 2011 16:01:02 -0800 (PST) Received: by 10.236.95.9 with HTTP; Wed, 9 Nov 2011 16:01:02 -0800 (PST) Date: Wed, 9 Nov 2011 18:01:02 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=0016e68ea0a9a879fd04b1561957 Subject: [multimob] Presentations X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:01:03 -0000 --0016e68ea0a9a879fd04b1561957 Content-Type: text/plain; charset=ISO-8859-1 Even though there are only a few days left, we have received no presentations so far. Please send your presentations to the chairs ASAP. Behcet --0016e68ea0a9a879fd04b1561957 Content-Type: text/html; charset=ISO-8859-1 Even though there are only a few days left, we have received no presentations so far.

Please send your presentations to the chairs ASAP.

Behcet
--0016e68ea0a9a879fd04b1561957-- From contreras.uc3m@gmail.com Thu Nov 10 12:49:37 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0856121F8AB9 for ; Thu, 10 Nov 2011 12:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Buxpd2KhNC for ; Thu, 10 Nov 2011 12:49:35 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0F21F8A7E for ; Thu, 10 Nov 2011 12:49:35 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so3237172vcb.31 for ; Thu, 10 Nov 2011 12:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kJ2TKz8iWDQfHiE1N7c0fNX1ZXR755q3lbUoHI8ZcY4=; b=bdEtMbajTWcnvCCKO0NO6XoWubvSQvpBl8Kf3jksmGfhOeoK7RjIJH6Mu+tSUgtHwy O8mKlAMcOXSJRYwDNR+LPDEM4BQ7E64jIZ0lAFd5VRDnaqcQieFLjN2NZh2JuKqPJM4m XU06sqpZOFEh2UWkZf5QILLA9bw39y4h2tMJc= MIME-Version: 1.0 Received: by 10.52.88.231 with SMTP id bj7mr15791179vdb.81.1320958174868; Thu, 10 Nov 2011 12:49:34 -0800 (PST) Received: by 10.52.109.4 with HTTP; Thu, 10 Nov 2011 12:49:34 -0800 (PST) In-Reply-To: <20111108.162947.166997496.asaeda@sfc.wide.ad.jp> References: <20111108.162947.166997496.asaeda@sfc.wide.ad.jp> Date: Thu, 10 Nov 2011 21:49:34 +0100 Message-ID: From: "Luis M. Contreras" To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=20cf3071c880c6b47a04b1678a8e Cc: multimob@ietf.org Subject: Re: [multimob] comments for draft-contreras-multimob-rams-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:49:37 -0000 --20cf3071c880c6b47a04b1678a8e Content-Type: text/plain; charset=ISO-8859-1 Hi Hitoshi, thank you very much for your comments, and apologies for my late response. I try to answer your comments in line: 2011/11/8 Hitoshi Asaeda > Hi, > > I have reviewed draft-contreras-multimob-rams-03 and have some > comments. > > In this draft the authors propose "proactive" handover and "reactive" > handover, but it was difficult to understand the benefit of the > extension for reactive handover, or how the proposed reactive handover > accelerates handover. > The comparisson has to be done with the reactive case in RFC6224.There the nMAG is aware of the entering MN subscription once it receives the MLD Report from the MN, as a reply of the MLD Query sent by the nMAG once the link was set up. The time considered in the MLD Query transfer in the radio link (including framing, radio access delay, ...), plus the time taken by the MN to process and answer the MLD Query (conditioned by the Query Response interval), plus the MLD Report going back through the radio channel to the nMAG, is higher than the time taken on asking the pMAG, which maintains the multicast subscription of the MN because we are in the reactive case. We have try to model this in the following paper: http://isyou.info/jowua/papers/jowua-v2n2-5.pdf The savings due to RAMS apply not only to RFC6224, but to any other solution which could depend on the answer of the MN to the MLD Query sent by the nMAG. > > Regarding the reactive handover, sect.4.2.1 says; > "After receiving the PBU message from the nMAG, the LMA will take the > decision of interrogating or not the pMAG regarding any existing > multicast subscription for that MN. > Once the multicast subscription information is retrieved from the > pMAG, the LMA encapsulates it in the PBA message by using the TLV > option "Active Multicast Subscription", and forwards the PBA message > to the nMAG. Then, the nMAG can subscribe the multicast flow on > behalf of the MN, if there is no other MN receiving it already at the > nMAG." > However, the reactive handover explained in section 4 requires > exchanging many messages and complex procedures, and I cannot find the > big advantage of providing such extension. > Let me explain in few words. Two are the processes involved: 1/ When an MN maintains an active subscription, a flag is maintained in the LMA indicating that (it is not relevant the channel subscribed, because this is dynimic; it is only relevant that the MN has an active subscription) 2/ When the MN moves to a new access network, as consequence of the registration process at the nMAG, the LMA checks the flag, and in case the flag is set, it request to the pMAG the subscription information (IP addresses of the source and the multicast group) to be passed to the nMAG, completing the registration. (In case th flag is not set up, meaning that there is no active subscription, the registration process is done as in RFC5213) Hopefully now is better understood. > > In fact, when we tune Startup Query Interval to a shorter period (see > sect.4.4 in draft-ietf-multimob-igmp-mld-tuning-02.txt), nMAG scarcely > triggers MLD general query and obtains the current state record from > the MN when the MN attaches to the new PtoP link. This is simple and > does not require LMA's involvement. > As I mentioned above, there are a number of delay sources affecting such procedure. Furthermore, such delay depends on the underlying radio technology (wifi, 3gpp, LTE), so no uniform customer experience could be expected. If you avoid the wireless-related procedures, you eliminate both problems. > Moreover, the proposed reactive handover requires new messages called > "Subscription Query" and "Subscription Response". But usually the > procedures to recognize multicast subscription status are done by the > standard MLD and we don't need these new messages if we use the > regular MLD. > This is applicable only by the MAG where the MN is attached, but it suffers from the problems declared above. > > Other comment. > For both proactive and reactive handover, "Active Multicast > Subscription" option is used with PBU/PBA. > But this option format is not congruent with RFC3810. A multicast > record must include filter more and must be capable of including > multiple source addresses for one group record. (If you ignore the > exclude filter mode operations, you must explicitly say so and provide > the procedure how you ignore the explicit filter mode operations.) > Null source address must be also allowed. > Although I didn't know the fact, our PMIPv6 extension draft includes > similar message extension. You may want to refer the format in PBU-M > and PBA-M proposed in our PMIPv6 extension draft. > Thanks for pointin out this fact (I was not aware of). I will check accodingly. > > And at last, the name of "RAMS" may not be appropriate, as RAMS is > already well known as Unicast-Based Rapid Acquisition of Multicast RTP > Sessions (RFC6285) and some of AVT drafts have been using this term. > Thanks again for rising this. We will modify it to avoid any confussion. Best regards, Luis > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --20cf3071c880c6b47a04b1678a8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hitoshi,

thank you very much for your comments, and apologies for= my late response.

I try to answer your comments in line:

2011/11/8 Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
Hi,

I have reviewed draft-contreras-multimob-rams-03 and have some
comments.

In this draft the authors propose "proactive" handover and "= reactive"
handover, but it was difficult to understand the benefit of the
extension for reactive handover, or how the proposed reactive handover
accelerates handover.

The comparisson has to be do= ne with the reactive case in RFC6224.There the nMAG is aware of the enterin= g MN subscription once it receives the MLD Report from the MN, as a reply o= f the MLD Query sent by the nMAG once the link was set up.

The time considered in the MLD Query transfer in the radio link (includ= ing framing, radio access delay, ...), plus the time taken by the MN to pro= cess and answer the MLD Query (conditioned by the Query Response interval),= plus the MLD Report going back through the radio channel to the nMAG, is h= igher than the time taken on asking the pMAG, which maintains the multicast= subscription of the MN because we are in the reactive case.

We have try to model this in the following paper:
http://isyou.info/jowua/papers/jo= wua-v2n2-5.pdf

The savings due to RAMS apply not only to RFC6224= , but to any other solution which could depend on the answer of the MN to t= he MLD Query sent by the nMAG.

Regarding the reactive handover, sect.4.2.1 says;
=A0"After receiving the PBU message from the nMAG, the LMA will take = the
=A0 decision of interrogating or not the pMAG regarding any existing
=A0 multicast subscription for that MN.
=A0 Once the multicast subscription information is retrieved from the
=A0 pMAG, the LMA encapsulates it in the PBA message by using the TLV
=A0 option "Active Multicast Subscription", and forwards the PBA= message
=A0 to the nMAG. Then, the nMAG can subscribe the multicast flow on
=A0 behalf of the MN, if there is no other MN receiving it already at the<= br> =A0 nMAG."
However, the reactive handover explained in section 4 requires
exchanging many messages and complex procedures, and I cannot find the
big advantage of providing such extension.

Let me = explain in few words. Two are the processes involved:

1/ When an MN = maintains an active subscription, a flag is maintained in the LMA indicatin= g that (it is not relevant the channel subscribed, because this is dynimic;= it is only relevant that the MN has an active subscription)

2/ When the MN moves to a new access network, as consequence of the reg= istration process at the nMAG, the LMA checks the flag, and in case the fla= g is set, it request to the pMAG the subscription information (IP addresses= of the source and the multicast group) to be passed to the nMAG, completin= g the registration. (In case th flag is not set up, meaning that there is n= o active subscription, the registration process is done as in RFC5213)

Hopefully now is better understood.
=A0

In fact, when we tune Startup Query Interval to a shorter period (see
sect.4.4 in draft-ietf-multimob-igmp-mld-tuning-02.txt), nMAG scarcely
triggers MLD general query and obtains the current state record from
the MN when the MN attaches to the new PtoP link. This is simple and
does not require LMA's involvement.

As I menti= oned above, there are a number of delay sources affecting such procedure. F= urthermore, such delay depends on the underlying radio technology (wifi, 3g= pp, LTE), so no uniform customer experience could be expected. If you avoid= the wireless-related procedures, you eliminate both problems.
=A0
Moreover, the proposed reactive handover requires new messages called
"Subscription Query" and "Subscription Response". But u= sually the
procedures to recognize multicast subscription status are done by the
standard MLD and we don't need these new messages if we use the
regular MLD.

This is applicable only by the MAG wh= ere the MN is attached, but it suffers from the problems declared above.=A0

Other comment.
For both proactive and reactive handover, "Active Multicast
Subscription" option is used with PBU/PBA.
But this option format is not congruent with RFC3810. A multicast
record must include filter more and must be capable of including
multiple source addresses for one group record. (If you ignore the
exclude filter mode operations, you must explicitly say so and provide
the procedure how you ignore the explicit filter mode operations.)
Null source address must be also allowed.
Although I didn't know the fact, our PMIPv6 extension draft includes similar message extension. You may want to refer the format in PBU-M
and PBA-M proposed in our PMIPv6 extension draft.

= Thanks for pointin out this fact (I was not aware of). I will check accodin= gly.
=A0

And at last, the name of "RAMS" may not be appropriate, as RAMS i= s
already well known as Unicast-Based Rapid Acquisition of Multicast RTP
Sessions (RFC6285) and some of AVT drafts have been using this term.

Thanks again for rising this. We will modify it to avoid= any confussion.


Best regards,
Luis
=A0

Regards,
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--20cf3071c880c6b47a04b1678a8e-- From asaeda@sfc.wide.ad.jp Fri Nov 11 02:23:40 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3120A21F8876 for ; Fri, 11 Nov 2011 02:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.198 X-Spam-Level: X-Spam-Status: No, score=-101.198 tagged_above=-999 required=5 tests=[AWL=1.401, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS1bxEWSuVYi for ; Fri, 11 Nov 2011 02:23:35 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1D21F886A for ; Fri, 11 Nov 2011 02:23:30 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5B0FA2780A9; Fri, 11 Nov 2011 19:23:22 +0900 (JST) Date: Fri, 11 Nov 2011 19:23:21 +0900 (JST) Message-Id: <20111111.192321.79370633.asaeda@sfc.wide.ad.jp> To: contreras.uc3m@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20111108.162947.166997496.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 6.3 on Emacs 22.3 / 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] comments for draft-contreras-multimob-rams-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 10:23:40 -0000 Hi Luis, Thank you for your reply. Can I continue the discussion a little more? >> In this draft the authors propose "proactive" handover and "reactive" >> handover, but it was difficult to understand the benefit of the >> extension for reactive handover, or how the proposed reactive handover >> accelerates handover. > > The comparisson has to be done with the reactive case in RFC6224.There the > nMAG is aware of the entering MN subscription once it receives the MLD > Report from the MN, as a reply of the MLD Query sent by the nMAG once the > link was set up. MLD Query is *not always* triggered by MLD Report. It depends on the Report type and the state maintained by the router. But it is not the point of our current discussion, so skip this. > The time considered in the MLD Query transfer in the radio link (including > framing, radio access delay, ...), plus the time taken by the MN to process > and answer the MLD Query (conditioned by the Query Response interval), plus > the MLD Report going back through the radio channel to the nMAG, is higher > than the time taken on asking the pMAG, which maintains the multicast > subscription of the MN because we are in the reactive case. > > We have try to model this in the following paper: > http://isyou.info/jowua/papers/jowua-v2n2-5.pdf I took a look at this paper. Comparing with Fig.7 (proactive) and 8 (reactive), the time difference is with "Tacq". The time for reactive handover always adds Tacq time to the one for proactive handover, hence it's always longer, isn't it? > The savings due to RAMS apply not only to RFC6224, but to any other > solution which could depend on the answer of the MN to the MLD Query sent > by the nMAG. Maybe. But my question is, in what kind of situation (or what is the use case that) your reactive handover is useful, or faster than proactive handover? >> Regarding the reactive handover, sect.4.2.1 says; >> "After receiving the PBU message from the nMAG, the LMA will take the >> decision of interrogating or not the pMAG regarding any existing >> multicast subscription for that MN. >> Once the multicast subscription information is retrieved from the >> pMAG, the LMA encapsulates it in the PBA message by using the TLV >> option "Active Multicast Subscription", and forwards the PBA message >> to the nMAG. Then, the nMAG can subscribe the multicast flow on >> behalf of the MN, if there is no other MN receiving it already at the >> nMAG." >> However, the reactive handover explained in section 4 requires >> exchanging many messages and complex procedures, and I cannot find the >> big advantage of providing such extension. > > Let me explain in few words. Two are the processes involved: > > 1/ When an MN maintains an active subscription, a flag is maintained in the > LMA indicating that (it is not relevant the channel subscribed, because > this is dynimic; it is only relevant that the MN has an active subscription) I may not understand this. Whenever MN subscribes some channels, pMAG sends DeReg PBU including the subscription information (*) to LMA, and LMA transfers it to nMAG via PBA including the subscription information (*). Then nMAG operates to forward data to the MN if needed. Why another "active" flag and message transmission is needed? (*) This message extension is needed. In my PMIPv6 extension draft, PBU-M and PBA-M are defined for each. > 2/ When the MN moves to a new access network, as consequence of the > registration process at the nMAG, the LMA checks the flag, and in case the > flag is set, it request to the pMAG the subscription information (IP > addresses of the source and the multicast group) to be passed to the nMAG, > completing the registration. (In case th flag is not set up, meaning that > there is no active subscription, the registration process is done as in > RFC5213) Whether the MN subscribes some channel or not, LMA gets DeReg PBU. If DeReg PBU includes MN's subscription info, LMA does not need to newly ask the MN's subscription information. Why additional message for transmitting the subscription info must be defined? > Hopefully now is better understood. I think I understand the procedure you defined. But I don't understand why your reactive handover procedure should be defined as well as the proactive handover. Is there any technical reason? Or there is some configuration or policy requirement I missed? Regards, -- Hitoshi Asaeda From sarikaya2012@gmail.com Sun Nov 13 17:35:46 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821021F86A0 for ; Sun, 13 Nov 2011 17:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfsdgMzRF9kT for ; Sun, 13 Nov 2011 17:35:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F357321F8888 for ; Sun, 13 Nov 2011 17:35:45 -0800 (PST) Received: by ggnr5 with SMTP id r5so419445ggn.31 for ; Sun, 13 Nov 2011 17:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=jNajNDgEIwpriTpCFt7zBdz4+IsCWe003NKKL2p87tk=; b=jeYdhkDSgpnQBESIW1xeks7VY7CTy2k5NaW20doID5S6l8lmgk1qmSBFevwtwLQCL+ schT0+zfzklUDnm5KjHhv2awnTvhHiShJ106GD7t9eUUVnco5h3lRDoWFDMzuavYf7Dz hTxLw7Q8xNyxTiXfSSK9UkQ+f/eLqE7ygkgYY= MIME-Version: 1.0 Received: by 10.236.155.2 with SMTP id i2mr10994817yhk.115.1321234545434; Sun, 13 Nov 2011 17:35:45 -0800 (PST) Received: by 10.236.191.228 with HTTP; Sun, 13 Nov 2011 17:35:45 -0800 (PST) Date: Sun, 13 Nov 2011 19:35:45 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=20cf30363adbbee0d004b1a7e3f7 Subject: [multimob] Session logistics X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:35:46 -0000 --20cf30363adbbee0d004b1a7e3f7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We are still missing a few presentations. We suggest these to volunteer: Minutes: Akbar, Jabber: Matthias Thanks, Behcet --20cf30363adbbee0d004b1a7e3f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
=A0 We are still missing a few presentations.

We suggest = these to volunteer:

Minutes: Akbar,
Jabber: Matthias

Thank= s,

Behcet
--20cf30363adbbee0d004b1a7e3f7-- From prvs=2922b7522=schmidt@informatik.haw-hamburg.de Sun Nov 13 17:42:57 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE611E80DA for ; Sun, 13 Nov 2011 17:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RECV_SPAM_DOMN0b=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQtnai2XVm4r for ; Sun, 13 Nov 2011 17:42:57 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id B0F0011E80DD for ; Sun, 13 Nov 2011 17:42:55 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 14 Nov 2011 02:42:54 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id C7E9C102A1DA for ; Mon, 14 Nov 2011 02:42:54 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18025-06 for ; Mon, 14 Nov 2011 02:42:54 +0100 (CET) Received: from [192.168.11.62] (111-248-69-128.dynamic.hinet.net [111.248.69.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id BB2E6102A1D9 for ; Mon, 14 Nov 2011 02:42:53 +0100 (CET) Message-ID: <4EC0721B.50707@informatik.haw-hamburg.de> Date: Mon, 14 Nov 2011 09:42:51 +0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "multimob@ietf.org" References: <20111114003040.21272.13532.idtracker@ietfa.amsl.com> In-Reply-To: <20111114003040.21272.13532.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111114003040.21272.13532.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [multimob] Fwd: New Version Notification for draft-schmidt-multimob-fmipv6-pfmipv6-multicast-05.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:42:57 -0000 Hi all, we've just updated the fast handover draft: http://tools.ietf.org/html/draft-schmidt-multimob-fmipv6-pfmipv6-multicast-05 ... sorry for being late. Following the discussion initiated by Marco et al., this now includes a two-sided forwarding option between PAR (PMAG) and NAR (NMAG): Either access router can decide on its contribution to the data plane. Cheers, Thomas -------- Original Message -------- Subject: New Version Notification for draft-schmidt-multimob-fmipv6-pfmipv6-multicast-05.txt Date: Sun, 13 Nov 2011 16:30:40 -0800 From: internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: gorry@erg.abdn.ac.uk, rkoodli@cisco.com, schmidt@informatik.haw-hamburg.de, mw@link-lab.net A new version of I-D, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-05.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-fmipv6-pfmipv6-multicast Revision: 05 Title: Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers Creation date: 2011-11-13 WG ID: Individual Submission Number of pages: 27 Abstract: Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and will benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that MAY include buffering. The IETF Secretariat From prvs=2922b7522=schmidt@informatik.haw-hamburg.de Mon Nov 14 09:35:43 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8811F0CC2 for ; Mon, 14 Nov 2011 09:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RECV_SPAM_DOMN0b=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThScOfuS47GQ for ; Mon, 14 Nov 2011 09:35:43 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3BE1F0C9C for ; Mon, 14 Nov 2011 09:35:42 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 14 Nov 2011 18:35:27 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 4D324102A1D9 for ; Mon, 14 Nov 2011 18:35:27 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30235-07 for ; Mon, 14 Nov 2011 18:35:26 +0100 (CET) Received: from [192.168.11.62] (111-248-69-128.dynamic.hinet.net [111.248.69.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 1D4CA102A1D3 for ; Mon, 14 Nov 2011 18:35:25 +0100 (CET) Message-ID: <4EC1515D.6040106@informatik.haw-hamburg.de> Date: Tue, 15 Nov 2011 01:35:25 +0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "multimob@ietf.org" References: <20111114172240.10556.99588.idtracker@ietfa.amsl.com> In-Reply-To: <20111114172240.10556.99588.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111114172240.10556.99588.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [multimob] Fwd: New Version Notification for draft-schmidt-multimob-pmipv6-source-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:35:43 -0000 Dear all, we have prepared a first draft of the merged version on PMIP multicast sources: http://tools.ietf.org/html/draft-schmidt-multimob-pmipv6-source-00 Best regards, Thomas -------- Original Message -------- Subject: New Version Notification for draft-schmidt-multimob-pmipv6-source-00.txt Date: Mon, 14 Nov 2011 09:22:40 -0800 From: internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: shgao@bjtu.edu.cn, hkzhang@bjtu.edu.cn, schmidt@informatik.haw-hamburg.de, mw@link-lab.net A new version of I-D, draft-schmidt-multimob-pmipv6-source-00.txt has been successfully submitted by Thomas Schmidt and posted to the IETF repository. Filename: draft-schmidt-multimob-pmipv6-source Revision: 00 Title: Mobile Multicast Sender Support in PMIPv6 Domains Creation date: 2011-11-14 WG ID: Individual Submission Number of pages: 13 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains by deploying MLD Proxy functions at Mobile Access Gateways and multicast routing functions at Local Mobility Anchors, or by additional route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario, as well as in settings of further optimization. Mobile sources remain agnostic of multicast mobility operations. The IETF Secretariat From sarikaya2012@gmail.com Thu Nov 17 19:14:20 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700431F0C85 for ; Thu, 17 Nov 2011 19:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC56AI0af6qm for ; Thu, 17 Nov 2011 19:14:20 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E77FE1F0C80 for ; Thu, 17 Nov 2011 19:14:19 -0800 (PST) Received: by ywt34 with SMTP id 34so2337496ywt.31 for ; Thu, 17 Nov 2011 19:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=c0oU8V9eRRo7fzjR81C50ayG/IdA0ZfXyO5gC+tsoDI=; b=Lu7FteS5WdLjiSqDpXsEM05wet7xn6DG1qEZOCirdDBNU4lCVAzTXr3Mc1FGsODAJz J5rgc3c0M2JsD7A2P/oK9f7xBf2S2dai8oyblsei9fQj4txegCnh7J9OUbEMo65JyuAe +k8+6VuyP/NQ7fKA86167Gy97NN2+x4JGJZpY= MIME-Version: 1.0 Received: by 10.236.116.9 with SMTP id f9mr2015704yhh.0.1321586059513; Thu, 17 Nov 2011 19:14:19 -0800 (PST) Received: by 10.236.191.228 with HTTP; Thu, 17 Nov 2011 19:14:19 -0800 (PST) Date: Thu, 17 Nov 2011 21:14:19 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=485b397dccfb9e0ffb04b1f9bbc5 Subject: [multimob] IETF 82 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 03:14:20 -0000 --485b397dccfb9e0ffb04b1f9bbc5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The minutes are posted at http://www.ietf.org/proceedings/82/minutes/multimob.txt Please take a look and let us know if any corrections are needed. Next time we hope to use Etherpad, the electronic note taking system. Many thanks to Akbar! Regards, Behcet & Stig --485b397dccfb9e0ffb04b1f9bbc5 Content-Type: text/html; charset=ISO-8859-1 Hi all,

The minutes are posted at

http://www.ietf.org/proceedings/82/minutes/multimob.txt

Please take a look and let us know if any corrections are needed.

Next time we hope to use Etherpad, the electronic note taking system.


Many thanks to Akbar!

Regards,

Behcet & Stig
--485b397dccfb9e0ffb04b1f9bbc5-- From seiljeon@gmail.com Mon Nov 21 18:37:25 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD671F0C84 for ; Mon, 21 Nov 2011 18:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH+4B8CsbVUn for ; Mon, 21 Nov 2011 18:37:21 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECAA1F0C4C for ; Mon, 21 Nov 2011 18:37:17 -0800 (PST) Received: by yenm7 with SMTP id m7so3340788yen.31 for ; Mon, 21 Nov 2011 18:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VIzjDKMe8FJH7XlKTbFk6ivQ3SI7RdDlNs4QCqaKyjo=; b=rNZZA8rVr8+vaTHn15XiXlEujRkQxGFFn8/9dZzci06N2qECxyoVJgxmjhNYVuxWgW m0DzXQhH12qQs7KfwhyG12ug8cN7AyrckcriEeQmdt16NAXqO5dKnSoPEwrOqZq9J15T e9w5Udw1OSr1SNH3caGDkWxJRQ+OGZLZEAeO0= MIME-Version: 1.0 Received: by 10.68.36.72 with SMTP id o8mr36285823pbj.115.1321929436155; Mon, 21 Nov 2011 18:37:16 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.41.129 with HTTP; Mon, 21 Nov 2011 18:37:16 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Nov 2011 11:37:16 +0900 X-Google-Sender-Auth: Wi4pga6tRzpYvHIN34ZH9iIfW5w Message-ID: From: seil jeon To: sarikaya@ieee.org Content-Type: multipart/mixed; boundary=bcaec520eb1375ce4c04b249ae4d Cc: multimob@ietf.org Subject: Re: [multimob] IETF 82 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 02:37:25 -0000 --bcaec520eb1375ce4c04b249ae4d Content-Type: multipart/alternative; boundary=bcaec520eb1375ce4804b249ae4b --bcaec520eb1375ce4804b249ae4b Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet and all, Additionally, I added a couple of my comments said in multimob meeting. Thanks to taking a note, Akbar. Best Regards, Seil Jeon 2011/11/18 Behcet Sarikaya > Hi all, > > The minutes are posted at > > http://www.ietf.org/proceedings/82/minutes/multimob.txt > > Please take a look and let us know if any corrections are needed. > > Next time we hope to use Etherpad, the electronic note taking system. > > > Many thanks to Akbar! > > Regards, > > Behcet & Stig > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > --bcaec520eb1375ce4804b249ae4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Behcet and all,
=A0
Additionally, I added a couple of my comments said in multimob meeting= .
=A0
Thanks to taking a note, Akbar.
=A0
=A0
Best Regards,
=A0
Seil Jeon

2011/11/18 Behcet Sarikaya <= ;sarikaya2012@gmail.com>
Hi all,

The minutes are p= osted at

http://www.ietf.org/proceedings/82/minutes/mult= imob.txt

Please take a look and let us know if any corrections are needed.
Next time we hope to use Etherpad, the electronic note taking system.
=

Many thanks to Akbar!

Regards,

Behcet & Stig

_______________________________________________
multimob mailing lis= t
multimob@ietf.org
https= ://www.ietf.org/mailman/listinfo/multimob


--bcaec520eb1375ce4804b249ae4b-- --bcaec520eb1375ce4c04b249ae4d Content-Type: text/plain; charset=US-ASCII; name="multimob.txt" Content-Disposition: attachment; filename="multimob.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvaan7040 TVVMVElNT0IgTm90ZXMgKFRoYW5rcyB0byBBa2JhciBSYWhtYW4pDQoNCkNoYWlycwlBZG1pbmlz dHJhdGl2aWENCg0KLQlDYXJsb3MgLSBBc2tlZCB0aGF0IGFsbCBkcmFmdHMgYmUgc3VibWl0dGVk IGFjY29yZGluZyB0byBJRVRGIGN1dG9mZiBzdWJtaXNzaW9uIGd1aWRlbGluZXMgaW4gdGhlIGZ1 dHVyZQ0KLQlCZWNoZXQgLSBHYXZlIHN0YXR1cyBvZiBXRyBkcmFmdHMuICBTYWlkIHRoYXQgSGl0 b3NoaSdzIGRyYWZ0IHdvdWxkIHNvb24gZW50ZXIgV0dMQw0KDQoNCkhpdG9zaGkJV0cgZHJhZnQg dXBkYXRlDQoNCi0JSGl0b3NoaSAtIEdhdmUgc3VtbWFyeSBvZiBjaGFuZ2VzLiAgTm8gbWFqb3Ig Y2hhbmdlcy4NCi0JSGl0b3NoaSAtIEdhdmUgYSAgc3VtbWFyeSBvZiB2YXJpb3VzIHRpbWVyIHZh bHVlcyBmb3Igd2lyZWxlc3MgbGlua3MNCi0JVGhlcmUgd2VyZSB2YXJpb3VzIGNvbW1lbnRzL3F1 ZXN0aW9ucyBkdXJpbmcgdGhlIHByZXNlbnRhdGlvbiBpbmNsdWRpbmcgdGhlIGZvbGxvd2luZzoN Cm8JU3RpZyAtIE5vdGVkIHRoYXQgdGhlIHF1ZXJ5IGludGVydmFsIG51bWJlcnMgaGF2ZSBzbWFs bCB2YXJpYXRpb24gYW5kIGFza2VkIGlmIHRoZXkgc2hvdWxkbid0IGJlIGxhcmdlciB2YXJpYXRp b24/DQpvCUJlY2hldCAtIEFza2VkIHdoaWNoIHZhbHVlIHdhcyBmb3IgV2lGaSBhbmQgd2hpY2gg d2FzIGZvciBjZWxsdWxhcg0KbwlUaG9tYXMgLSBBc2tlZCB3aGV0aGVyIHRoZSByb2J1c3RuZXNz IHZhcmlhYmxlIHNob3VsZCBiZSBpbmNyZWFzZWQgcmF0aGVyIHRoYW4gZGVjcmVhc2VkPw0KbwlT dGlnIC0gU2FpZCB0aGF0IGhlIGFncmVlZCB3aXRoIFRob21hcycgc3VnZ2VzdGlvbiBmb3IgaW5j cmVhc2luZyByb2J1c3RuZXNzIHZhcmlhYmxlDQotCUhpdG9zaGkgLSBTYWlkIGhlIHdpbGwgZm9s bG93IHVwIG9uIGFsbCB0aGUgcXVlc3Rpb25zIGFib3ZlIGFuZCBhc2tlZCBmb3IgcGVvcGxlJ3Mg b3BpbmlvbnMgb24gdGhlIG1haWxpbmcgbGlzdC4NCi0JQmVjaGV0IC0gUmUtYWZmaXJtZWQgdGhh dCBoZSB3b3VsZCBsaWtlIHRoZSBJLUQgdG8gZ28gdG8gV0dMQyBhZnRlciB0aGlzIG1lZXRpbmcN Cg0KDQpTaHVhaSAJU291cmNlIG1vYmlsaXR5IGRyYWZ0IA0KDQotCVNodWFpIC0gVGhpcyBpcyBh IG1lcmdlZCBkcmFmdCB3aXRoIGhpbSBhbmQgVGhvbWFzDQotCVNodWFpIC0gR2F2ZSBkZXNjcmlw dGlvbiBvZiBwcm9wb3NhbCBhbmQgZGlzY3Vzc2VkIHNvbWUgb3BlbiBpc3N1ZXMNCi0JVGhlcmUg d2VyZSB2YXJpb3VzIGNvbW1lbnRzL3F1ZXN0aW9ucyBkdXJpbmcgdGhlIHByZXNlbnRhdGlvbiBp bmNsdWRpbmcgdGhlIGZvbGxvd2luZzoNCm8JSmVmZnJleSAtIFBJTSBXRyBpcyBjb25zaWRlcmlu ZyBtb3ZpbmcgdGhlIERSIHdoaWNoIG1heSBoZWxwIHNvbHZlIG9uZSBvZiB0aGUgb3BlbiBpc3N1 ZXMNCm8JSGl0b3NoaSAtIEFza2VkIGZvciBjbGFyaWZpY2F0aW9uIGFib3V0IE1BRyBhY3Rpbmcg YXMgUElNIHJvdXRlciB2cyBEUg0KbwlUaG9tYXMgLSBTYWlkIHRoYXQgc2V2ZXJhbCBkZXBsb3lt ZW50IHNjZW5hcmlvcyBhcmUgYmVpbmcgY292ZXJlZCBhbmQgb25lIGhhcyBNQUcgYWN0aW5nIGFz IERSDQpvCVNyaSAtIEFza2VkIHdoeSBNQUcgY291bGQgbm90IGRvIGZvcndhcmRpbmcgaW4gdGhl IGV4cGVyaW1lbnRzIHRoYXQgU2h1YWkgZGVzY3JpYmVkDQpvCUhpdG9zaGkgLSBNZW50aW9uZWQg dGhhdCB0aGVyZSBpcyBubyBzb3VyY2Utc3RvcCBzY2hlbWUgDQpvCVN0aWcgLSBJbiBQSU0tU00g IHRoZXJlIGlzIG5vIHNvdXJjZS1zdG9wIHByb2JsZW0NCi0JU2h1YWkgLSBTYWlkIGhlIHdpbGwg Zm9sbG93IG9uIGFueSByZXF1aXJlZCB1cGRhdGVzIHRvIHRoZSBxdWVzdGlvbnMgYWJvdmUNCi0J QmVjaGV0IC0gVGhhbmtlZCBhdXRob3JzIGZvciBtZXJnaW5nIHRoZWlyIGRyYWZ0cy4gIFdpbGwg YXNrIGZvciBtYWlsaW5nIGxpc3QgY29tbWVudHMgYW5kIHdpbGwgYXNrIGZvciBXRyBhZG9wdGlv biBvbiBtYWlsaW5nIGxpc3QNCg0KDQpDYXJsb3MJSGFuZG92ZXIgSQ0KDQpDYXJsb3MgLSBHYXZl IHN1bW1hcnkgb2Ygc3RhdHVzLCBjaGFuZ2VzLCBtb3RpdmF0aW9uIGFuZCBhZHZhbnRhZ2VzDQot CVRoZXJlIHdlcmUgdmFyaW91cyBjb21tZW50cy9xdWVzdGlvbnMgZHVyaW5nIHRoZSBwcmVzZW50 YXRpb24gaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmc6DQpvCVRob21hcyAtIElzIG11bHRpY2FzdCBo YW5kb3ZlciBoYW5kbGVkIGluZGVwZW5kZW50bHkgb2YgdW5pY2FzdCBoYW5kb3Zlcj8NCm8JVGhv bWFzIC0gQXNrZWQgZm9yIGNsYXJpZmljYXRpb24gYWJvdXQgcmVhY3RpdmUgbW9kZSBoYW5kb3Zl ciBtZWNoYW5pc20/DQpvCU1hcmNvIC0gV2h5IGRvIHlvdSBub3QgaGF2ZSBNQUdzIHRyYW5zZmVy cmluZyBjb250ZXh0PyAgV2hhdCBpcyB0aGUgbmVlZCBmb3Igc3luY2hyb25pemluZyBtdWx0aWNh c3QgYW5kIHVuaWNhc3QgaGFuZG92ZXJzPw0KbwlIaXRvc2hpIC0gV2hhdCBpcyBkaWZmZXJlbmNl IGJldHdlZW4gcHJvYWN0aXZlIGFuZCByZWFjdGl2ZSBoYW5kb3ZlcnM/DQpvCVNyaSAtIEFza2Vk IHRvIGNsYXJpZnkgTDIgdHJpZ2dlcnMgYW5kIHVzZQ0KLQlDYXJsb3MgLSBTYWlkIGhlIHdpbGwg Zm9sbG93IG9uIGFueSByZXF1aXJlZCB1cGRhdGVzIHRvIHRoZSBxdWVzdGlvbnMgYWJvdmUNCg0K VGhvbWFzCUhhbmRvdmVyIElJDQoNCi0JVGhvbWFzIC0gR2F2ZSBhbiBvdmVydmlldyBvZiB0aGUg ZmxvdywgZGVzaWduIG9iamVjdGl2ZXMsIGFuZCB2YXJpb3VzIHF1ZXN0aW9ucyBhc2tlZCBvbiB0 aGUgbWFpbGluZyBsaXN0DQotCVRoZXJlIHdlcmUgdmFyaW91cyBjb21tZW50cy9xdWVzdGlvbnMg ZHVyaW5nIHRoZSBwcmVzZW50YXRpb24gaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmc6DQpvCUNhcmxv cyAtIEFyZSBNTiBtb2RpZmljYXRpb25zIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGNoYXJ0ZXI/ DQpvCU1hcmNvIC0gQXNrZWQgd2hhdCBkaXJlY3Rpb24gb2YgdHJhbnNmZXIgZ2F2ZSB0aGUgbW9z dCBhZHZhbnRhZ2VzPw0KLQlUaG9tYXMgIC0gU2FpZCBoZSB3aWxsIGZvbGxvdyB1cCBvbiBhbnkg cmVxdWlyZWQgdXBkYXRlcyB0byB0aGUgcXVlc3Rpb25zIGFib3ZlDQoNCk1hcmNvCUlzc3VlcyBp biBGYXN0IEhhbmRvdmVyIFNvbHV0aW9ucw0KDQotCU1hcmNvIC0gR2F2ZSAgaW5wdXQgdG8gdGhl IGRpc2N1c3Npb24gdG93YXJkcyBmaW5kaW5nIGEgZ29vZCBjaG9pY2UgZm9yIGZhc3QgaGFuZG92 ZXIgc29sdXRpb25zDQotCVRoZXJlIHdlcmUgdmFyaW91cyBjb21tZW50cy9xdWVzdGlvbnMgZHVy aW5nIHRoZSBwcmVzZW50YXRpb24gaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmc6DQpvCVRob21hcyAt IERpZCBub3QgYWdyZWUgd2l0aCB0aGUgbWVjaGFuaXNtIGlsbHVzdHJhdGVkIGZvciBidWZmZXIg bWFuYWdlbWVudCBpbiB0aGUgbmV0d29yaw0KLQlNYXJjbyAgLSBTYWlkIGhlIHdpbGwgZm9sbG93 IHVwIG9uIGFueSByZXF1aXJlZCB1cGRhdGVzIHRvIHRoZSBxdWVzdGlvbnMgYWJvdmUNCi0JQmVj aGV0IC0gQXNrZWQgTWFyY28gZm9yIGEgbGlzdCBvZiB0aGluZyB0aGF0IHdlIGNhbiBhZ3JlZSBv biBhbmQgdG8gcG9zdCB0aGF0IG9uIHRoZSBsaXN0DQoNCg0KSGl0b3NoaSAJVHVubmVsIGNvbnZl cmdlbmNlIGRyYWZ0DQoNCi0JSGl0b3NoaSAtICBHYXZlIGJhY2tncm91bmQsIGNoYW5nZXMsDQot CVRoZXJlIHdlcmUgdmFyaW91cyBjb21tZW50cy9xdWVzdGlvbnMgZHVyaW5nIHRoZSBwcmVzZW50 YXRpb24gaW5jbHVkaW5nIHRoZSBmb2xsb3dpbmc6DQpvCSBUaG9tYXMgLSBhc2tlZCB3aGF0IHdh cyBiZWluZyBjb3BpZWQgdG8gdGhlIE1SSUI/ICBZb3UgY2Fubm90IGV4cHJlc3MgUE1JUCByb3V0 aW5nIGluIG9uZSBNUklCLg0KbwlTcmkgLSBQcm94eSBNSVAgcm91dGluZyBpcyBwb2xpY3kgYmFz ZWQgcm91dGluZw0KbwlTdGlnIC0gRG9lcyBub3Qgc2VlIGhvdyB0byBkbyBwb2xpY3kgYmFzZWQg cm91dGluZyB3aXRoIFBJTQ0KbwlCZWNoZXQgLSBUaGlzIGlzc3VlIHNlZW1zIG9wZW4gaW4gdGhl IGRyYWZ0IChpLmUuIFBNSVAgdmlzIFBJTSByb3V0aW5nKQ0KbwlTZWlsIC0gTWF5IGJlIGRpZmZp Y3VsdCBmb3Igcm9hbWluZyBjYXNlLiAgUElNLVNNIG1heSBub3QgYmUgc3VwcG9ydGVkIGJ5IGFs bCBvcGVyYXRvcnMuIFdoYXQgYWJvdXQgdGhlIG9wZXJhdG9yIG5vdCBkZXBsb3lpbmcgUElNLVNN PyBUaHJvdWdoIHNldmVyYWwgbWVldGluZyBhbmQgbWFpbGluZyBkaXNjdXNzaW9ucywgd2UndmUg a25vd24gdGhhdCBubyBzb2x1dGlvbnMgY2FuIHNhdGlzZnkgYWxsIHRoZSByZXF1aXJlbWVudHMu IFdlIG5lZWQgdG8gY29uc2lkZXIgUElNLVNNIGNhc2UgImFzIG9uZSBvZiB0aGVtIiBidXQgdHVu bmVsIGNvbnZlcmdlbmNlIHNvbHV0aW9uIHNob3VsZCBub3QgYmUgZGVwZW5kYW50IG9uIHRoZSBh bGdvcml0aG0gdXNlZCBpbiBzcGVjaWZpYyBtdWx0aWNhc3Qgcm91dGluZyBwcm90b2NvbC4NCi0J SGl0b3NoaSAgLSBTYWlkIGhlIHdpbGwgZm9sbG93IHVwIG9uIGFueSByZXF1aXJlZCB1cGRhdGVz IHRvIHRoZSBxdWVzdGlvbnMgYWJvdmUNCg0KDQpKdWFuIENhcmxvcyAJUHJvdmlkaW5nIG11bHRp Y2FzdCBzZXJ2aWNlIGRyYWZ0IA0KDQotCUp1YW4gQ2FybG9zIC0gR2F2ZSBvdmVydmlldyBvZiB0 aGUgbWVyZ2VyIG9mIHR3byBleGlzdGluZyBkcmFmdHMgKERpcmVjdCByb3V0aW5nIGFuZCBNVE1B IGNvbmNlcHRzKQ0KLQlUaGVyZSB3ZXJlIHZhcmlvdXMgY29tbWVudHMvcXVlc3Rpb25zIGR1cmlu ZyB0aGUgcHJlc2VudGF0aW9uIGluY2x1ZGluZyB0aGUgZm9sbG93aW5nOg0KbwlUaG9tYXMgLSBE aWQgeW91IHNvbHZlIGhvdyB0byBnZXQgdGhlIG11bHRpY2FzdCBncm91cCBpZGVudGlmaWNhdGlv biBpc3N1ZQ0KbwlCZWNoZXQgLSBUaGlzIGRyYWZ0IHNvbHZlcyB0aGUgdHVubmVsIGNvbnZlcmdl bmNlLiAgVGhpcyBkcmFmdCBpcyByZWFkeSB0byBiZWNvbWUgV0cgZHJhZnQuDQpvCVN0aWcgLSBB c2sgb24gdGhlIG1haWxpbmcgbGlzdCB0byBnaXZlIGNvbW1lbnRzIGFuZCBpbiBvbmUgbW9udGgg dG8gYXNrIGZvciBXRyBhZG9wdGlvbi4NCg== --bcaec520eb1375ce4c04b249ae4d-- From sarikaya2012@gmail.com Mon Nov 28 10:32:30 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02BF21F8463 for ; Mon, 28 Nov 2011 10:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0-X6NURZwSX for ; Mon, 28 Nov 2011 10:32:30 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 257CB21F8C3D for ; Mon, 28 Nov 2011 10:32:30 -0800 (PST) Received: by ywm13 with SMTP id 13so4226178ywm.31 for ; Mon, 28 Nov 2011 10:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cHC1pb68qxXujEBGBPj2HhqPwK6wxJo9z1u/3vILsXk=; b=jjksAHzm2YXyPmpnn3PuVr909swDk9bzctx0Mzxkxui84NMSflAmCTwXMKuUOe961t Kvd2WN49ywvoxtSzfEO7xKKRxgMo75BxOcNpxxhC3mcvwU+wSiz6lIOSIOI2kZZZ/WBK 4BTshdeyRpnJksvh1Wp73E0DdsjSPfNFj1NWE= MIME-Version: 1.0 Received: by 10.236.193.68 with SMTP id j44mr63834678yhn.97.1322505149616; Mon, 28 Nov 2011 10:32:29 -0800 (PST) Received: by 10.236.191.228 with HTTP; Mon, 28 Nov 2011 10:32:29 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Nov 2011 12:32:29 -0600 Message-ID: From: Behcet Sarikaya To: seil jeon Content-Type: multipart/alternative; boundary=20cf305b0c64a8138704b2cfb91c Cc: multimob@ietf.org Subject: Re: [multimob] IETF 82 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:32:30 -0000 --20cf305b0c64a8138704b2cfb91c Content-Type: text/plain; charset=ISO-8859-1 Thanks Seil. The minutes have been updated at http://www.ietf.org/proceedings/82/minutes/multimob.txt Regards, Behcet On Mon, Nov 21, 2011 at 8:37 PM, seil jeon wrote: > Hi Behcet and all, > > Additionally, I added a couple of my comments said in multimob meeting. > > Thanks to taking a note, Akbar. > > > Best Regards, > > Seil Jeon > > 2011/11/18 Behcet Sarikaya > >> Hi all, >> >> The minutes are posted at >> >> http://www.ietf.org/proceedings/82/minutes/multimob.txt >> >> Please take a look and let us know if any corrections are needed. >> >> Next time we hope to use Etherpad, the electronic note taking system. >> >> >> Many thanks to Akbar! >> >> Regards, >> >> Behcet & Stig >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >> > --20cf305b0c64a8138704b2cfb91c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Seil.
The minutes have been updated at http://www.ietf.org/proceedings/8= 2/minutes/multimob.txt

Regards,

Behcet

On Mon, Nov 21, 2011 at 8:37 PM, seil jeon <sijeon79@gmail.com> wrote:
Hi Behcet and all,
=A0
Additionally, I added a couple of my comments said in multimob meeting= .
=A0
Thanks to taking a note, Akbar.
=A0
=A0
Best Regards,
=A0
Seil Jeon

2011/11/18 Behcet Sarikaya <= ;sarikaya2012@g= mail.com>
Hi all,
The minutes are posted at

http://www.ietf.org/proceedin= gs/82/minutes/multimob.txt

Please take a look and let us know if any corrections are needed.
Next time we hope to use Etherpad, the electronic note taking system.
=

Many thanks to Akbar!

Regards,

Behcet & Stig

_______________________________________________
multimob= mailing list
mul= timob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob<= br>


--20cf305b0c64a8138704b2cfb91c--