From h.anthony.chan@huawei.com Wed Aug 1 23:39:14 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAACE21F8A11 for ; Wed, 1 Aug 2012 23:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=1.766, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fw6e8-ptpSL for ; Wed, 1 Aug 2012 23:39:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C346821F8A16 for ; Wed, 1 Aug 2012 23:39:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AII82980; Wed, 01 Aug 2012 22:39:13 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 23:35:30 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 1 Aug 2012 23:35:35 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.232]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 14:35:25 +0800 From: h chan To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] Comment on Req2 transparency for DMM Thread-Index: AQHNb3LICQryiYmy8k62nS56y0aeT5dGEbHA Date: Thu, 2 Aug 2012 06:35:25 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> References: <501867A9.8060007@gmail.com> In-Reply-To: <501867A9.8060007@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Comment on Req2 transparency for DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 06:39:15 -0000 How about changing to the following: The DMM solutions MUST provide transparency above the IP layer when needed,= such as upon change of point of attachment to the Internet, for the applic= ation flows that cannot cope with a change of IP address. Otherwise the sup= port to maintain a stable home IP address or prefix during handover may be = declined. Original was: The DMM solutions MUST provide transparency above the IP layer when needed.= Such transparency is needed, when the mobile hosts or entire mobile networ= ks [RFC3963] change their point of attachment to the Internet, for the appl= ication flows that cannot cope with a change of IP address. Otherwise the s= upport to maintain a stable home IP address or prefix during handover may b= e declined. H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Tuesday, July 31, 2012 4:18 PM To: dmm@ietf.org Subject: [DMM] Comment on Req2 transparency for DMM DMM coleagues, I would like to comment on the REQ2 "Transparency to Upper Layers when Needed". The slide 4 of slides-84-dmm-1.pptx at https://datatracker.ietf.org/meeting/84/materials.html says: > The DMM solutions MUST provide transparency above the IP layer when > needed. Such transparency is needed, when the mobile hosts or entire > mobile networks [RFC3963] change their point of attachment to the > Internet, for the application flows that cannot cope with a change > of IP address. Otherwise the support to maintain a stable home IP > address or prefix during handover may be declined. Such transparency is needed indeed. But I suggest moving the part "when the mobile hosts or entire mobile networks" outside of this paragraph - maybe as a common denominator as part somewhere earlier in the draft. Most if not all requirements of DMM would be good to deal with mobile hosts as well as groupings of computers (mobile networks). This transparency aspect we discuss here is about the stack - its effects are within the stack of a single computer. When this transparency is offered it means the existing applications which are unaware of mobility events (changes in IP address) do not need to be modified in order to deal with these mobility events. There is another transparency aspect when we discuss outside a single computer's stack - the mobility management performed by a Mobile Router on behalf of LFNs in a moving network is also transparency - the LFNs are not implementing any mobility software - the world looks fixed to them. So this would require both transparency1 and transparency2. I wonder what happens in cases when only transparency1 or only transparency2 are required and the other is relaxed - maybe a new scheme pops up. Or maybe it doesnt make any sense... Alex _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From alexandru.petrescu@gmail.com Thu Aug 2 11:39:04 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA5811E824D for ; Thu, 2 Aug 2012 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Jy15NGjyBV for ; Thu, 2 Aug 2012 11:39:03 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9060511E824B for ; Thu, 2 Aug 2012 11:39:03 -0700 (PDT) Received: by qaea16 with SMTP id a16so1491364qae.10 for ; Thu, 02 Aug 2012 11:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dlB+VujMKQPvnPYbyLNLSrjEZuQiSwU/cpKxD2MDpP0=; b=mjE1iUiwhizI/ODIASJuiwzcDv42iqn7Ped49m6slvkxVY2NWMXDcfY4YJyZgihV6E SSSej4ChNdBulI7LIo15YWA1dPLFhZ1XVTWoBMpYIpIRe+X557UC9zwsWHheKCDEODTK 1JjhtaTfiHv8zG62CBZTtV9DFLKTcF4wg4YS1b4EJp15ynpAZ/kDvvrA2k4P3L1Ma8dV MDNVI8Y9owS+/FJ8HE98SZ8VtoMYUyEy6Kg9fL75GzdPFYRP/0jK55hdA8jKToIruzcx uoTKMrzU+NwfGbGW1OgdhSD/IWU7FRNkYva777Z+s/cVyzYOazefeLdAZsgzmuDCbbVp RcwQ== Received: by 10.60.27.41 with SMTP id q9mr38719622oeg.47.1343932742936; Thu, 02 Aug 2012 11:39:02 -0700 (PDT) Received: from [130.129.54.43] (dhcp-362b.meeting.ietf.org. [130.129.54.43]) by mx.google.com with ESMTPS id th3sm6699744obb.6.2012.08.02.11.39.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 11:39:02 -0700 (PDT) Message-ID: <501AC93A.5000100@gmail.com> Date: Thu, 02 Aug 2012 11:38:50 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: h chan References: <501867A9.8060007@gmail.com> <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dmm@ietf.org" Subject: Re: [DMM] Comment on Req2 transparency for DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:39:04 -0000 H Anthony, Yes, this reflects Sri's and my suggestion about removal of MN/MR qualifier. I agree with the idea of the new text as you put it. Then, if I re-read just like that, there still seems to be some difficulty to my brain to understand: Le 01/08/2012 23:35, h chan a écrit : > The DMM solutions MUST provide transparency above the IP layer when > needed, such as upon change of point of attachment to the Internet, > for the application flows that cannot cope with a change of IP > address. Otherwise the support to maintain a stable home IP address > or prefix during handover may be declined. I don't understand the last phrase - the 'otherwise' relates to the first MUST? Or to the latter 'cannot'? But this may be just nitpicking on the use of language. I agree with the direction of the idea and thank you for having provided the modification. Alex From karagian@cs.utwente.nl Fri Aug 3 07:17:09 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC7E21F8D99 for ; Fri, 3 Aug 2012 07:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] 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 tAMAIrJ+4CDo for ; Fri, 3 Aug 2012 07:17:08 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47F21F8D95 for ; Fri, 3 Aug 2012 07:17:07 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 3 Aug 2012 16:17:05 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 3 Aug 2012 16:17:04 +0200 From: To: Thread-Topic: regarding DMM framework and draft-chan-dmm-framework-gap-analysis Thread-Index: AQHNcYKokxa/5YVnAE2oihPhzNSmYw== Date: Fri, 3 Aug 2012 14:17:04 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.181.206.247] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684DEXMBX04adutwent_" MIME-Version: 1.0 Cc: dmm@ietf.org Subject: [DMM] regarding DMM framework and draft-chan-dmm-framework-gap-analysis X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:17:09 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684DEXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anthony, I have read the draft-chan-dmm-framework-gap-analysis-02.txt. The DMM framework part description is useful. However, I have a comment! The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities. I think that the DMM framework should provide this distinction, since funct= ions/entities that are supporting the control path may not be collocated wi= th functions/entities that are supporting the data path. This comment is in my opinion valid for both: (1) mobility routing (MR) fun= ction/entity and (2) internetwork location management (LM) function/entity. This could mean that: The MR function/entity can be divided in: MRC (Mobility Routing Control path) function/entity MRD (Mobility Routing Data path) function/entity The LM function can be divided in: LMC (internetwork Location Management Control path) function/entity LMD (internetwork Location Management Data path) function/entity Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684DEXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Anthony,

 

I have read the draft-chan-dmm-framework-gap-analysis-02.txt.

 

The DMM framework part description is useful. However, I have a comment!=
The current provided DMM framework is not making any distinction between co= ntrol path and data path related functions/entities.

 

I think that the DMM framework should provide this distinction, since fu= nctions/entities that are supporting the control path may not be collocated= with functions/entities that are supporting the data path.

 

This comment is in my opinion valid for both: (1) mobility routing (MR) = function/entity and (2) internetwork location management (LM) function/enti= ty. 

 

This could mean that:

 

The MR function/entity can be divided in:
MRC (Mobility Routing Control path) function/entity
MRD (Mobility Routing Data path) function/entity

 

The LM function can be divided in:
LMC (internetwork Location Management Control path) function/entity
LMD (internetwork Location Management Data path) function/entity

 

Best regards,
Georgios

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F2CBE684DEXMBX04adutwent_-- From h.anthony.chan@huawei.com Fri Aug 3 10:09:36 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950821F8DD6 for ; Fri, 3 Aug 2012 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=1.668, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKeG48tVOZsy for ; Fri, 3 Aug 2012 10:09:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AB21F8DCC for ; Fri, 3 Aug 2012 10:09:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM48110; Fri, 03 Aug 2012 09:09:35 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 10:07:44 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 10:07:51 -0700 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.232]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Sat, 4 Aug 2012 01:07:49 +0800 From: h chan To: Alexandru Petrescu Thread-Topic: [DMM] Comment on Req2 transparency for DMM Thread-Index: AQHNcN4ZURF3Ps+J2k6Lm1G+53s36JdIUaXA Date: Fri, 3 Aug 2012 17:07:48 +0000 Message-ID: <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> References: <501867A9.8060007@gmail.com> <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> <501AC93A.5000100@gmail.com> In-Reply-To: <501AC93A.5000100@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Comment on Req2 transparency for DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:09:36 -0000 How about the following: The DMM solutions MUST provide transparency above the IP layer when needed.= Such transparency is needed, for example, upon change of point of attachme= nt to the Internet for the application flows that cannot cope with a change= of IP address. Otherwise the support to maintain a stable home IP address = or prefix during handover may be declined. Or The DMM solutions MUST enable transparency above the IP layer. Such transpa= rency is needed, for example, upon change of point of attachment to the Int= ernet for the application flows that cannot cope with a change of IP addres= s. Otherwise the support to maintain a stable home IP address or prefix dur= ing handover may be declined. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, August 02, 2012 11:39 AM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] Comment on Req2 transparency for DMM H Anthony, Yes, this reflects Sri's and my suggestion about removal of MN/MR qualifier. I agree with the idea of the new text as you put it. Then, if I re-read just like that, there still seems to be some difficulty to my brain to understand: Le 01/08/2012 23:35, h chan a =E9crit : > The DMM solutions MUST provide transparency above the IP layer when > needed, such as upon change of point of attachment to the Internet, > for the application flows that cannot cope with a change of IP > address. Otherwise the support to maintain a stable home IP address > or prefix during handover may be declined. I don't understand the last phrase - the 'otherwise' relates to the first MUST? Or to the latter 'cannot'? But this may be just nitpicking on the use of language. I agree with the direction of the idea and thank you for having provided the modification. Alex From tso@zteusa.com Mon Aug 6 17:07:37 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF1911E80A6 for ; Mon, 6 Aug 2012 17:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] 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 AkS35OgNjHk4 for ; Mon, 6 Aug 2012 17:07:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B370111E8087 for ; Mon, 6 Aug 2012 17:07:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231057192640; Tue, 7 Aug 2012 07:55:31 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 6027.3422596023; Tue, 7 Aug 2012 08:07:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7707QXj083580; Tue, 7 Aug 2012 08:07:26 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> References: <501867A9.8060007@gmail.com> <6E31144C030982429702B11D6746B98C270D0770@SZXEML505-MBS.china.huawei.com> <501AC93A.5000100@gmail.com> <6E31144C030982429702B11D6746B98C270D08FA@SZXEML505-MBS.china.huawei.com> To: h chan MIME-Version: 1.0 X-KeepSent: F6BC0AB8:C1D16137-88257A52:008300ED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Mon, 6 Aug 2012 17:07:02 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-07 08:07:24, Serialize complete at 2012-08-07 08:07:24 Content-Type: multipart/alternative; boundary="=_alternative 0000AD4B88257A53_=" X-MAIL: mse01.zte.com.cn q7707QXj083580 Cc: "dmm@ietf.org" Subject: Re: [DMM] Comment on Req2 transparency for DMM X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 00:07:37 -0000 This is a multipart message in MIME format. --=_alternative 0000AD4B88257A53_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Anthony and Alex,=20 I believe Anthony has pointed out that, maintaining IP session continuity= =20 is just "an example" of maintaining upper layer transparency. It should= =20 be fundamental to maintain the upper layer transparency even though upper= =20 layer may be able to cope with changing IP address, e.g. maintaining the=20 QoS performance or location context for the service layer. Hence, the=20 clause of the "Otherwise" portion is not very clear as Alex has pointed=20 out.=20 Hence, I would like to suggest a friendly amendment to Anthony's latest=20 proposal as follows:=20 >>>>> The DMM solutions MUST provide transparency above the IP layer when=20 needed. Such transparency is needed, for example, upon change of point of= =20 attachment to the Internet for the application flows that cannot cope with= =20 a change of IP address may trigger the application to decline the handover= =20 request. >>>>> Would this be acceptable to both of you? Thanks. Tricci=20 h chan =20 Sent by: dmm-bounces@ietf.org 08/03/2012 10:07 AM To Alexandru Petrescu cc "dmm@ietf.org" Subject Re: [DMM] Comment on Req2 transparency for DMM How about the following: The DMM solutions MUST provide transparency above the IP layer when=20 needed. Such transparency is needed, for example, upon change of point of= =20 attachment to the Internet for the application flows that cannot cope with= =20 a change of IP address. Otherwise the support to maintain a stable home IP= =20 address or prefix during handover may be declined. Or The DMM solutions MUST enable transparency above the IP layer. Such=20 transparency is needed, for example, upon change of point of attachment to= =20 the Internet for the application flows that cannot cope with a change of=20 IP address. Otherwise the support to maintain a stable home IP address or= =20 prefix during handover may be declined. H Anthony Chan -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: Thursday, August 02, 2012 11:39 AM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] Comment on Req2 transparency for DMM H Anthony, Yes, this reflects Sri's and my suggestion about removal of MN/MR qualifier. I agree with the idea of the new text as you put it. Then, if I re-read just like that, there still seems to be some difficulty to my brain to understand: Le 01/08/2012 23:35, h chan a =E9crit : > The DMM solutions MUST provide transparency above the IP layer when > needed, such as upon change of point of attachment to the Internet, > for the application flows that cannot cope with a change of IP > address. Otherwise the support to maintain a stable home IP address > or prefix during handover may be declined. I don't understand the last phrase - the 'otherwise' relates to the first MUST? Or to the latter 'cannot'? But this may be just nitpicking on the use of language. I agree with the direction of the idea and thank you for having provided the modification. Alex _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --=_alternative 0000AD4B88257A53_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Anthony and Alex,

I believe Anthony has p= ointed out that, maintaining IP session continuity is just "an example" of maintaining upper layer transparency.   It should be fundamental to maintain the upper layer transparency even though upper layer may be able to cope with changing IP address, e.g. maintaining the QoS performance or location context for the service layer.  Hence, the clause of the "Otherwise" portion is not very clear as Alex has pointed out.  

Hence, I would like to = suggest a friendly amendment to Anthony's latest proposal as follows:
>>>>>
The DMM solutions MUST provide transparency above the IP layer when needed. Such transparency is needed, for example, upon change of point of attachment to the Internet for the application flows that cannot cope with a change of IP address may trigger the application to decline the handover request.
>>>>>

Would this be acceptabl= e to both of you?  Thanks.
Tricci



h chan <h.anthony.= chan@huawei.com>
Sent by: dmm-bounces@ietf.org

08/03/2012 10:07 AM

To
Alexandru Petrescu <alexandru.pet= rescu@gmail.com>
cc
"dmm@ietf.org" <dmm@iet= f.org>
Subject
Re: [DMM] Comment on Req2 transparen= cy for DMM





How about the following:

The DMM solutions MUST provide transparency above the IP layer when needed. Such transparency is needed, for example, upon change of point of attachmen= t to the Internet for the application flows that cannot cope with a change of IP address. Otherwise the support to maintain a stable home IP address or prefix during handover may be declined.

Or

The DMM solutions MUST enable transparency above the IP layer. Such transpa= rency is needed, for example, upon change of point of attachment to the Internet for the application flows that cannot cope with a change of IP address. Otherwise the support to maintain a stable home IP address or prefix during handover may be declined.

H Anthony Chan

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com= ]
Sent: Thursday, August 02, 2012 11:39 AM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] Comment on Req2 transparency for DMM

H Anthony,

Yes, this reflects Sri's and my suggestion about removal of MN/MR
qualifier.  I agree with the idea of the new text as you put it.

Then, if I re-read just like that, there still seems to be some
difficulty to my brain to understand:

Le 01/08/2012 23:35, h chan a =E9crit :
> The DMM solutions MUST provide transparency above the IP layer when > needed, such as upon change of point of attachment to the Internet, > for the application flows that cannot cope with a change of IP
> address. Otherwise the support to maintain a stable home IP address > or prefix during handover may be declined.

I don't understand the last phrase - the 'otherwise' relates to the
first MUST?  Or to the latter 'cannot'?

But this may be just nitpicking on the use of language.  I agree with<= br> the direction of the idea and thank you for having provided the
modification.

Alex

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail (and any attachmen=
t transmitted herewith) is privileged and con=
fidential and is intended for the exclusive&n=
bsp;use of the addressee(s).  If you are=
 not an intended recipient, any disclosure,&n=
bsp;reproduction, distribution or other dissemination&n=
bsp;or use of the information contained is&nb=
sp;strictly prohibited.  If you have received=
 this mail in error, please delete it&nb=
sp;and notify us immediately.
--=_alternative 0000AD4B88257A53_=-- From jouni.nospam@gmail.com Mon Aug 20 03:20:36 2012 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1767921F8713 for ; Mon, 20 Aug 2012 03:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+HylZNyJr7j for ; Mon, 20 Aug 2012 03:20:35 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBAF21F870F for ; Mon, 20 Aug 2012 03:20:35 -0700 (PDT) Received: by eekb45 with SMTP id b45so1556719eek.31 for ; Mon, 20 Aug 2012 03:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=p2UW91ef3GSzrPO0rQt1FcqtI4ZGnGktYl4NIgiopVk=; b=ndiioJk7IMjUhGJVeko9f+yGQvppLGU8MoB9NRjZYM6Wf0b6gOYdb+lQI83pPGUgEw gfCwyTW9zbXdoHRSMJwMvzTiHBbVkKQmiFLtF5Wn7YgDZwhR0nZMKFfJ6Ha3BSDhInzg O+GNEeNgTZPo/XbHdyKRvGnm6qmyZ8n4hN+1+jZuZsMNP1/TqnxmF2FBfaYiI9YeQlF2 OrBpQpmhf8btFvBYholaXMQl8VleiN+YMF72BkHB2P6JfyhG/0eedOdxJ2o7uoSxYAI+ G4jdJmjNfPXW3lkceU2Xq1wM17dnow2xYUw8jDQGh3c35+e5cyAymFzPfW11N/GK2xyS 6kKQ== Received: by 10.14.204.72 with SMTP id g48mr8123972eeo.45.1345458034484; Mon, 20 Aug 2012 03:20:34 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:4589:2d8a:c23a:751f? ([2001:1bc8:101:f101:4589:2d8a:c23a:751f]) by mx.google.com with ESMTPS id e7sm40609914eep.2.2012.08.20.03.20.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 03:20:31 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2012 13:20:26 +0300 Message-Id: <0BD132F0-A9A2-44E3-9FC7-174539747E18@gmail.com> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: dmm-chairs@tools.ietf.org Subject: [DMM] Draft IETF#84 meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 10:20:36 -0000 Folks, The draft meeting minutes have been uploaded. Thanks to Pete and Charles = for _extensive_ meeting minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-dmm There are still few missed persons in there, so if you recognize = yourself, let me know that I can fix the meeting minutes. - Jouni & Julien