From nobody Tue Mar  3 02:34:31 2015
Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB71A1B91 for <dmm@ietfa.amsl.com>; Tue,  3 Mar 2015 02:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8pFKA6865IW for <dmm@ietfa.amsl.com>; Tue,  3 Mar 2015 02:34:28 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDAE1A1B8F for <dmm@ietf.org>; Tue,  3 Mar 2015 02:34:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7AC2E10945E for <dmm@ietf.org>; Tue,  3 Mar 2015 11:34:24 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01mmOyhJeWkl for <dmm@ietf.org>; Tue,  3 Mar 2015 11:34:24 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 56E6B10945D for <dmm@ietf.org>; Tue,  3 Mar 2015 11:34:22 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.57]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 3 Mar 2015 11:34:22 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [FPSM] next WebEx call
Thread-Index: AdBVnId+0jwDZrcVT62Bt+dusdjSpg==
Date: Tue, 3 Mar 2015 10:34:21 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D999C6F50@DAPHNIS.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D999C6F50DAPHNISofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/OnZcl7i0KbI_6JpLBaGCdAbWc7o>
Subject: [DMM] [FPSM] next WebEx call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2015 10:34:30 -0000

--_000_69756203DDDDE64E987BC4F70B71A26D999C6F50DAPHNISofficehd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We'll have another WebEx call this week to discuss and resolve some open is=
sues associated with
a solution draft for DMM Forwarding Path Configuration.

The call will be on Thursday, 05th March 2015
Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in Asia)
Duration: max 90min.

Best regards,
marco




--_000_69756203DDDDE64E987BC4F70B71A26D999C6F50DAPHNISofficehd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">We&#8217;ll have another WebEx call this week to dis=
cuss and resolve some open issues associated with<br>
a solution draft for DMM Forwarding Path Configuration. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The call will be on Thursday, 05<sup>th</sup> March =
2015<o:p></o:p></p>
<p class=3D"MsoNormal">Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in A=
sia)<o:p></o:p></p>
<p class=3D"MsoNormal">Duration: max 90min.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Best regards,<o:p></o:p></p>
<p class=3D"MsoNormal">marco<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_69756203DDDDE64E987BC4F70B71A26D999C6F50DAPHNISofficehd_--


From nobody Wed Mar  4 04:03:57 2015
Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861571A0334 for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 04:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEpn9lLifZFJ for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 04:03:52 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C441A0242 for <dmm@ietf.org>; Wed,  4 Mar 2015 04:03:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E18F71093BB for <dmm@ietf.org>; Wed,  4 Mar 2015 13:03:50 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4owNSvVm3Y0 for <dmm@ietf.org>; Wed,  4 Mar 2015 13:03:50 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BC5621092CE for <dmm@ietf.org>; Wed,  4 Mar 2015 13:03:48 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.75]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 13:03:27 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [FPSM] next WebEx call
Thread-Index: AdBVnId+0jwDZrcVT62Bt+dusdjSpgA0hSMg
Date: Wed, 4 Mar 2015 12:03:26 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D999CFA90@Hydra.office.hd>
References: <69756203DDDDE64E987BC4F70B71A26D999C6F50@DAPHNIS.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D999C6F50@DAPHNIS.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/1U3Gpngi-drZxrMmA9E_E9paMSw>
Subject: Re: [DMM] [FPSM] next WebEx call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2015 12:03:55 -0000

--_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For tomorrow's discussion, please use the WebEx information below to connec=
t.

Best regards,
Marco



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


FPSM

Thursday, March 5, 2015

2:30 pm  |  Pacific Standard Time (San Francisco, GMT-08:00)  |  1 hr





Join WebEx meeting<https://cisco.webex.com/ciscosales/j.php?MTID=3Dm30abe4f=
3cd68e0713ff52368a6900220>


Meeting number:

200 642 348

Meeting password:

dmm





Join by phone

+1-408-525-6800 Call-in toll number (US/Canada)

+1-866-432-9903 Call-in toll-free number (US/Canada)

Access code: 200 642 348

Global call-in numbers<https://cisco.webex.com/ciscosales/globalcallin.php?=
serviceType=3DMC&ED=3D304228257&tollFree=3D1>  |  Toll-free calling restric=
tions<http://www.webex.com/pdf/tollfree_restrictions.pdf>





Add this meeting<https://cisco.webex.com/ciscosales/j.php?MTID=3Dm9348dab60=
263fe1d0b555ce5da0363e1> to your calendar.





Can't join the meeting? Contact support.<https://cisco.webex.com/ciscosales=
/mc>





IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe=
r information sent during the session to be recorded, which may be discover=
able in a legal matter. By joining this session, you automatically consent =
to such recordings. If you do not consent to being recorded, discuss your c=
oncerns with the host or do not join the session.








From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 3. M=E4rz 2015 11:34
To: dmm@ietf.org
Subject: [DMM] [FPSM] next WebEx call

We'll have another WebEx call this week to discuss and resolve some open is=
sues associated with
a solution draft for DMM Forwarding Path Configuration.

The call will be on Thursday, 05th March 2015
Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in Asia)
Duration: max 90min.

Best regards,
marco




--_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">For tomorrow&#8217;s d=
iscussion, please use the WebEx information below to connect.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Best regards,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Marco<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt">
<tbody>
<tr style=3D"height:15.0pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:15.0pt">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"100=
%" style=3D"width:100.0%;border-spacing: 0px;max-width: 525px !important;mi=
n-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><b><span style=3D"color=
:#4D4D4D">FPSM</span></b><span style=3D"font-size:12.0pt;color:#4D4D4D"><o:=
p></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">Thursday, March 5, 2015<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">2:30 pm&nbsp;&nbsp;|&nbsp;&nbsp;Pacific Standard Ti=
me (San Francisco, GMT-08:00)&nbsp;&nbsp;|&nbsp;&nbsp;1 hr<o:p></o:p></span=
></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr style=3D"height:15.0pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:15.0pt;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" style=3D"bor=
der-spacing: 0px;max-width: 525px !important;min-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"color:#0=
0AFF9"><a href=3D"https://cisco.webex.com/ciscosales/j.php?MTID=3Dm30abe4f3=
cd68e0713ff52368a6900220"><b><span style=3D"color:#00AFF9;text-decoration:n=
one">Join WebEx meeting</span></b></a></span><span style=3D"font-size:12.0p=
t;color:#00AFF9"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" style=3D"bor=
der-spacing: 0px;max-width: 525px !important;min-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 3.75pt 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">Meeting number:<o:p></o:p></span></p>
</td>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">200 642 348<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 3.75pt 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">Meeting password:<o:p></o:p></span></p>
</td>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">dmm<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr style=3D"height:15.0pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:15.0pt;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><b><span style=3D"color=
:#666666">Join by phone</span></b><span style=3D"font-size:12.0pt;color:#66=
6666"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><b><span style=3D"font-=
size:11.5pt;color:#666666">&#43;1-408-525-6800</span></b><span style=3D"fon=
t-size:11.5pt;color:#666666">&nbsp;Call-in toll number (US/Canada)<o:p></o:=
p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><b><span style=3D"font-=
size:11.5pt;color:#666666">&#43;1-866-432-9903</span></b><span style=3D"fon=
t-size:11.5pt;color:#666666">&nbsp;Call-in toll-free number (US/Canada)<o:p=
></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">Access code:&nbsp;200 642 348<o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666"><a href=3D"https://cisco.webex.com/ciscosales/globa=
lcallin.php?serviceType=3DMC&amp;ED=3D304228257&amp;tollFree=3D1"><span sty=
le=3D"font-size:10.0pt;color:#00AFF9;text-decoration:none">Global
 call-in numbers</span></a>&nbsp;&nbsp;|&nbsp;&nbsp;<a href=3D"http://www.w=
ebex.com/pdf/tollfree_restrictions.pdf"><span style=3D"font-size:10.0pt;col=
or:#00AFF9;text-decoration:none">Toll-free calling restrictions</span></a><=
o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr style=3D"height:15.0pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:15.0pt;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:10.0pt;color:#666666"><a href=3D"https://cisco.webex.com/ciscosales/j.php=
?MTID=3Dm9348dab60263fe1d0b555ce5da0363e1"><span style=3D"color:#00AFF9;tex=
t-decoration:none">Add this meeting</span></a>&nbsp;to
 your calendar.<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr style=3D"height:15.0pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:15.0pt;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666">&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:10.0pt;color:#666666">Can't join the meeting?&nbsp;<a href=3D"https://cis=
co.webex.com/ciscosales/mc"><span style=3D"color:#00AFF9;text-decoration:no=
ne">Contact support.</span></a><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr style=3D"height:7.5pt">
<td style=3D"padding:0cm 0cm 0cm 0cm;height:7.5pt;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"mso-line-height-alt:7.5pt"><span style=3D"f=
ont-size:11.5pt;color:#666666">&nbsp;<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"line-height:15.0pt"><span style=3D"font-siz=
e:11.5pt;color:#666666;display:none"><o:p>&nbsp;</o:p></span></p>
<table class=3D"MsoNormalTable" border=3D"0" cellpadding=3D"0" width=3D"931=
" style=3D"width:698.25pt;border-spacing: 0px;max-width: 525px !important;m=
in-width: 279px !important">
<tbody>
<tr>
<td style=3D"padding:0cm 0cm 0cm 0cm;word-wrap: break-word">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt;line-height:15.0pt"><s=
pan style=3D"font-size:9.0pt;color:#A0A0A0">IMPORTANT NOTICE: Please note t=
hat this WebEx service allows audio and other information sent during the s=
ession to be recorded, which may be discoverable
 in a legal matter. By joining this session, you automatically consent to s=
uch recordings. If you do not consent to being recorded, discuss your conce=
rns with the host or do not join the session.<br>
<br>
<br>
<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> dmm [mai=
lto:dmm-bounces@ietf.org]
<b>On Behalf Of </b>Marco Liebsch<br>
<b>Sent:</b> Dienstag, 3. M=E4rz 2015 11:34<br>
<b>To:</b> dmm@ietf.org<br>
<b>Subject:</b> [DMM] [FPSM] next WebEx call<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">We&#8217;ll have another WebEx call this week to dis=
cuss and resolve some open issues associated with<br>
a solution draft for DMM Forwarding Path Configuration. <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The call will be on Thursday, 05<sup>th</sup> March =
2015<o:p></o:p></p>
<p class=3D"MsoNormal">Time: 23:30 CET / 14:30 PST / 07:30 JST (Friday in A=
sia)<o:p></o:p></p>
<p class=3D"MsoNormal">Duration: max 90min.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Best regards,<o:p></o:p></p>
<p class=3D"MsoNormal">marco<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_69756203DDDDE64E987BC4F70B71A26D999CFA90Hydraofficehd_--


From nobody Wed Mar  4 12:12:58 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84A91A88E4 for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 12:12:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SksPvb1htDYW for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 12:12:54 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4591A88DD for <dmm@ietf.org>; Wed,  4 Mar 2015 12:12:53 -0800 (PST)
Received: from [192.168.2.49] ([88.232.220.127]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MejCI-1Y9PSt1odc-00OK7o; Wed, 04 Mar 2015 21:12:51 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <003301d051e2$63bf3b00$2b3db100$@av.it.pt>
Date: Wed, 4 Mar 2015 22:12:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org>
References: <20150226162235.24366.4232.idtracker@ietfa.amsl.com> <003301d051e2$63bf3b00$2b3db100$@av.it.pt>
To: Seil Jeon <seiljeon@av.it.pt>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:bq6yx3M+IVw9zYJcZNwC3wv+QXk8Zoy11FJ6SQbWQUxEGUXsL5I prrTZ8NRgc17bsV4WleKHbf4aVETx2EGfWOA80e5iinghanFUx9NbuYpvdzoHTT3ZdfYvOO 1RvxqeAYOmTUN+a/TNJ1hs/PKyFNEbD9zVkpw0qx34xKXiG7IjWs/732JuxsFDVsPeAFFq6 Gx6RRSoMv+7WBl+FQkN0w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/LDJDA94pJi9tqqoGnHfCcReHYck>
Cc: dmm@ietf.org
Subject: Re: [DMM] New Version Notification for draft-sijeon-dmm-use-cases-api-source-00.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2015 20:12:56 -0000

Hello Seil,

As I understand, this new flag helps apps tell the IP stack to configure =
a new/additional IP address even if the IP stack is already configured =
with there requested type address.

It'd be good to spell this out in the I-D.
And also, it'd be good to explain why this might be needed, and when =
should the apps use this flag.


Alper



On Feb 26, 2015, at 6:36 PM, Seil Jeon wrote:

> Hi DMM folks,
>=20
> We submitted a new draft that present specified use cases based on the =
on-demand draft we are based on for further steps.
> As we discussed and agreed in the previous audio conference, checking =
and investigating use cases with the three types of IP addresses, i.e. =
fixed, sustained, nomadic IP addresses. Hope to start broad discussions =
on this while trying to extend the existing address configuration =
mechanisms. Grasping and identifying more definitive requirements based =
on the IP address type will be easy and make clear our ways to go, such =
as what to extend and how.
>=20
> With the discussion, any kinds of comments on it are welcomed.
>=20
> Regards,
>=20
> Seil Jeon, Ph.D
>=20
> Advanced Telecommunications and Networks Group (ATNoG) - =
http://atnog.av.it.pt
> Instituto de Telecomunicacoes, Aveiro, Portugal - http://www.it.pt
>=20
>=20
> Seil Jeon, Ph.D
>=20
> Advanced Telecommunications and Networks Group (ATNoG) - =
http://atnog.av.it.pt
> Instituto de Telecomunicacoes, Aveiro, Portugal - http://www.it.pt
>=20
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
> Sent: Thursday, February 26, 2015 4:23 PM
> To: Young-Han Kim; Sergio Figueiredo; Seil Jeon;
> Subject: New Version Notification for =
draft-sijeon-dmm-use-cases-api-source-00.txt
>=20
>=20
> A new version of I-D, draft-sijeon-dmm-use-cases-api-source-00.txt
> has been successfully submitted by Seil Jeon and posted to the IETF =
repository.
>=20
> Name:		draft-sijeon-dmm-use-cases-api-source
> Revision:	00
> Title:		Use Cases and API Extension for Source IP =
address selection
> Document date:	2015-02-26
> Group:		Individual Submission
> Pages:		7
> URL:            =
http://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-source-=
00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-sijeon-dmm-use-cases-api-source/
> Htmlized:       =
http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00
>=20
>=20
> Abstract:
>   This draft specifies and analyzes the expected cases regarding the
>   selection of a proper source IP address and address type based on
>   the application features over a distributed mobility management
>   (DMM) network. It also provides available selection methods in the
>   specified scenarios.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Wed Mar  4 13:18:41 2015
Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CA21A891A for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 13:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J034NaY3aCag for <dmm@ietfa.amsl.com>; Wed,  4 Mar 2015 13:18:38 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59C1A890B for <dmm@ietf.org>; Wed,  4 Mar 2015 13:18:37 -0800 (PST)
Received: from [192.168.25.5] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77267669; Wed, 04 Mar 2015 21:18:36 +0000
From: "Seil Jeon" <seiljeon@av.it.pt>
To: "'Alper Yegin'" <alper.yegin@yegin.org>
References: <20150226162235.24366.4232.idtracker@ietfa.amsl.com> <003301d051e2$63bf3b00$2b3db100$@av.it.pt> <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org>
In-Reply-To: <9B756F6B-5AC3-4DC4-8455-1CD71B1600DD@yegin.org>
Date: Wed, 4 Mar 2015 21:18:44 -0000
Message-ID: <000301d056c0$cc208fe0$6461afa0$@av.it.pt>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJOJLpdTSu1Exst2WXweS+HLXBkoAH6MziAA3G4DNub5dFRcA==
Content-Language: ko
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/UdW6j5CsECnpkfMKQ1Fl8niJHcc>
Cc: dmm@ietf.org
Subject: Re: [DMM] New Version Notification for draft-sijeon-dmm-use-cases-api-source-00.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2015 21:18:40 -0000

Hi Alper,

Thanks for your interest and valuable comment.

Actually, the need of the proposed flag is being explained in Section 2.2.3
Case 2.
And the use of this flag depends on such as session duration and sensitivity
of IP address change required by apps. This will be considered in a next
update.

Regards,

Seil Jeon


-----Original Message-----
From: Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, March 04, 2015 8:13 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] New Version Notification for
draft-sijeon-dmm-use-cases-api-source-00.txt

Hello Seil,

As I understand, this new flag helps apps tell the IP stack to configure a
new/additional IP address even if the IP stack is already configured with
there requested type address.

It'd be good to spell this out in the I-D.
And also, it'd be good to explain why this might be needed, and when should
the apps use this flag.


Alper



On Feb 26, 2015, at 6:36 PM, Seil Jeon wrote:

> Hi DMM folks,
> 
> We submitted a new draft that present specified use cases based on the
on-demand draft we are based on for further steps.
> As we discussed and agreed in the previous audio conference, checking and
investigating use cases with the three types of IP addresses, i.e. fixed,
sustained, nomadic IP addresses. Hope to start broad discussions on this
while trying to extend the existing address configuration mechanisms.
Grasping and identifying more definitive requirements based on the IP
address type will be easy and make clear our ways to go, such as what to
extend and how.
> 
> With the discussion, any kinds of comments on it are welcomed.
> 
> Regards,
> 
> Seil Jeon, Ph.D
> 
> Advanced Telecommunications and Networks Group (ATNoG) - 
> http://atnog.av.it.pt Instituto de Telecomunicacoes, Aveiro, Portugal 
> - http://www.it.pt
> 
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, February 26, 2015 4:23 PM
> To: Young-Han Kim; Sergio Figueiredo; Seil Jeon;
> Subject: New Version Notification for 
> draft-sijeon-dmm-use-cases-api-source-00.txt
> 
> 
> A new version of I-D, draft-sijeon-dmm-use-cases-api-source-00.txt
> has been successfully submitted by Seil Jeon and posted to the IETF
repository.
> 
> Name:		draft-sijeon-dmm-use-cases-api-source
> Revision:	00
> Title:		Use Cases and API Extension for Source IP address
selection
> Document date:	2015-02-26
> Group:		Individual Submission
> Pages:		7
> URL:
http://www.ietf.org/internet-drafts/draft-sijeon-dmm-use-cases-api-source-00
.txt
> Status:
https://datatracker.ietf.org/doc/draft-sijeon-dmm-use-cases-api-source/
> Htmlized:
http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00
> 
> 
> Abstract:
>   This draft specifies and analyzes the expected cases regarding the
>   selection of a proper source IP address and address type based on
>   the application features over a distributed mobility management
>   (DMM) network. It also provides available selection methods in the
>   specified scenarios.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm



From nobody Sun Mar  8 18:01:52 2015
Return-Path: <aparakh@unomaha.edu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1CD1A0052 for <dmm@ietfa.amsl.com>; Sun,  8 Mar 2015 18:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqHFoa1pyd8k for <dmm@ietfa.amsl.com>; Sun,  8 Mar 2015 18:01:48 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4621A004D for <dmm@ietf.org>; Sun,  8 Mar 2015 18:01:48 -0700 (PDT)
Received: from DM2PR0701MB761.namprd07.prod.outlook.com (10.242.126.18) by DM2PR0701MB762.namprd07.prod.outlook.com (10.242.126.19) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 01:01:33 +0000
Received: from DM2PR0701MB761.namprd07.prod.outlook.com ([10.242.126.18]) by DM2PR0701MB761.namprd07.prod.outlook.com ([10.242.126.18]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 01:01:32 +0000
From: Abhishek Parakh <aparakh@unomaha.edu>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: MobiPST 2015 - Deadline March 16th (extended)
Thread-Index: AdBaAUwQ1soujoP9RuWC07aat/94PgAAIuYwAABYr3AAAEh/oAAADHUA
Date: Mon, 9 Mar 2015 01:01:32 +0000
Message-ID: <DM2PR0701MB7612AC49299DB9A8135449CB11B0@DM2PR0701MB761.namprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [137.48.184.172]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0701MB762;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(13624006)(33656002)(15975445007)(2501003)(88552001)(19617315012)(229853001)(77156002)(102836002)(19625215002)(2656002)(77096005)(450100001)(19580405001)(99286002)(62966003)(86362001)(40100003)(74316001)(75432002)(66066001)(19580395003)(46102003)(89122001)(122556002)(107886001)(16236675004)(92566002)(2351001)(87936001)(19300405004)(110136001)(76576001)(50986999)(54356999)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0701MB762; H:DM2PR0701MB761.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: <DM2PR0701MB7629B7CD8B05B14CB1D7FA4B11B0@DM2PR0701MB762.namprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR0701MB762; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR0701MB762; 
x-forefront-prvs: 05102978A2
Content-Type: multipart/alternative; boundary="_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_"
MIME-Version: 1.0
X-OriginatorOrg: unomaha.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 01:01:32.6814 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f1f4be86-d048-47e8-aa26-15b01dcdb13d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0701MB762
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/RNhfORFHE_PJBEMMKAdGKd3o5Bc>
Subject: [DMM] MobiPST 2015 - Deadline March 16th (extended)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 01:01:51 -0000

--_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The 5th International Workshop on Privacy, Security and Trust in Mobile and=
 Wireless Systems (MobiPST 2015)

Las Vegas, Nevada, USA

August 6, 2015



Important Dates

Paper submission due:  March 16, 2015 (extended)

Acceptance notification:  April 24, 2015

Camera-ready due:  May 8, 2015

Workshop: August 6, 2015



Held in conjunction with ICCCN 2015 (Aug 3-5, 2015). ICCCN is technically c=
o-sponsored by the IEEE Communications Society. The Proceedings of the ICCC=
N 2015 has already been accepted in the IEEE Conference Publication Program=
. Workshop papers will appear in the conference proceedings and will be EI =
indexed.



Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html



Special issue announced: Outstanding papers from the workshop will be invit=
ed for a special issue on "Challenges and Solutions in Mobile Systems Secur=
ity" http://www.journals.elsevier.com/computers-and-electrical-engineering/=
call-for-papers/challenges-and-solutions-in-mobile-systems-security/



***********************************************

This workshop aims to bring together the technologists and researchers who =
share interest in the area of security, privacy and trust in mobile and wir=
eless systems, as well as explore new venues of collaboration. The main pur=
pose is to promote discussions of research and relevant activities in the m=
odels and designs of secure, privacy-preserving, or trust architectures, pr=
otocols, algorithms, services, and applications, as well as analysis on cyb=
er threat in mobile and wireless systems. It also aims at increasing the sy=
nergy between academic and industry professionals working in this area. We =
plan to seek papers that address theoretical, experimental research, and wo=
rk in-progress for security, privacy and trust related issues in the contex=
t of mobile and wireless systems that include, but are not limited to, the =
following,



*    Cryptography for Mobile and Wireless Systems

*    Wireless Local Area Networks

*    Wireless Sensor Networks

*    Wireless Mesh Networks

*    Wireless Ad-hoc Networks

*    Vehicular Networks

*    Body-area Networks

*    Cellular Networks (3G, 4G, ...)

*    WiMAX Networks

*    Machine to Machine (M2M) Netwroks

*    Software Defined Networks (SDN)

*    Social Networks

*    Smart Grid

*    RFID-based Systems

*    Mobile Cloud

*    Cyber-Physical Systems (CPS)

*    Internet of Things

*    Location-based Service Systems

*    Mobile Healthcare Systems

*    Smart Building Systems

*    Big Data



Accepted and registered workshop papers will be published in proceedings of=
 the ICCCN 2015 that has already been accepted in the IEEE Conference Publi=
cation Program and EI indexed.



Submission link: http://www.easychair.org/  Please choose appropriate track=
 while submitting your paper.

Workshop webpage: http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html



Co-chairs

Abhishek Parakh and Zhiwei Wang



______________________________________________________________

IEEE Communications Society Tech. Committee on Computer Communications http=
://committees.comsoc.org/tccc/

TCCC Announce: For announcements concerning computer networking and communi=
cations.

tccc-announce@comsoc.org<mailto:tccc-announce@comsoc.org>

https://comsoc-listserv.ieee.org/


--_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><b>The 5th International Workshop on Privacy, Sec=
urity and Trust in Mobile and Wireless Systems (MobiPST 2015)
<o:p></o:p></b></p>
<p class=3D"MsoPlainText">Las Vegas, Nevada, USA <o:p></o:p></p>
<p class=3D"MsoPlainText">August 6, 2015<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Important Dates<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><b>Paper submission due:&nbsp; March 16, 2015 (ex=
tended) <o:p>
</o:p></b></p>
<p class=3D"MsoPlainText">Acceptance notification:&nbsp; April 24, 2015 <o:=
p></o:p></p>
<p class=3D"MsoPlainText">Camera-ready due:&nbsp; May 8, 2015<o:p></o:p></p=
>
<p class=3D"MsoPlainText">Workshop: August 6, 2015<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Held in conjunction with ICCCN 2015 (Aug 3-5, 201=
5). ICCCN is technically co-sponsored by the IEEE Communications Society. T=
he Proceedings of the ICCCN 2015 has already been accepted in the IEEE Conf=
erence Publication Program. Workshop
 papers will appear in the conference proceedings and will be EI indexed.<o=
:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Workshop webpage: <a href=3D"http://faculty.ist.u=
nomaha.edu/aparakh/mobipst2015.html">
http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Special issue announced: Outstanding papers from =
the workshop will be invited for a special issue on &quot;Challenges and So=
lutions in Mobile Systems Security&quot;
<a href=3D"http://www.journals.elsevier.com/computers-and-electrical-engine=
ering/call-for-papers/challenges-and-solutions-in-mobile-systems-security/"=
>
http://www.journals.elsevier.com/computers-and-electrical-engineering/call-=
for-papers/challenges-and-solutions-in-mobile-systems-security/</a><o:p></o=
:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">***********************************************<o=
:p></o:p></p>
<p class=3D"MsoPlainText">This workshop aims to bring together the technolo=
gists and researchers who share interest in the area of security, privacy a=
nd trust in mobile and wireless systems, as well as explore new venues of c=
ollaboration. The main purpose is
 to promote discussions of research and relevant activities in the models a=
nd designs of secure, privacy-preserving, or trust architectures, protocols=
, algorithms, services, and applications, as well as analysis on cyber thre=
at in mobile and wireless systems.
 It also aims at increasing the synergy between academic and industry profe=
ssionals working in this area. We plan to seek papers that address theoreti=
cal, experimental research, and work in-progress for security, privacy and =
trust related issues in the context
 of mobile and wireless systems that include, but are not limited to, the f=
ollowing,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Cryptography for Mobile and W=
ireless Systems<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Wireless Local Area Networks<=
o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Wireless Sensor Networks<o:p>=
</o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Wireless Mesh Networks<o:p></=
o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Wireless Ad-hoc Networks<o:p>=
</o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Vehicular Networks<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Body-area Networks<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Cellular Networks (3G, 4G, ..=
.)<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; WiMAX Networks<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Machine to Machine (M2M) Netw=
roks<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Software Defined Networks (SD=
N)<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp; &nbsp;&nbsp;Social Networks<o:p></o:p></p=
>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Smart Grid<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; RFID-based Systems<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Mobile Cloud<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Cyber-Physical Systems (CPS)<=
o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Internet of Things<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Location-based Service System=
s<o:p></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Mobile Healthcare Systems<o:p=
></o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Smart Building Systems<o:p></=
o:p></p>
<p class=3D"MsoPlainText">*&nbsp;&nbsp;&nbsp; Big Data<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Accepted and registered workshop papers will be p=
ublished in proceedings of the ICCCN 2015 that has already been accepted in=
 the IEEE Conference Publication Program and EI indexed.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Submission link: <a href=3D"http://www.easychair.=
org/">http://www.easychair.org/</a>&nbsp; Please choose appropriate track w=
hile submitting your paper.<o:p></o:p></p>
<p class=3D"MsoPlainText">Workshop webpage: <a href=3D"http://faculty.ist.u=
nomaha.edu/aparakh/mobipst2015.html">
http://faculty.ist.unomaha.edu/aparakh/mobipst2015.html</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Co-chairs<o:p></o:p></p>
<p class=3D"MsoPlainText">Abhishek Parakh and Zhiwei Wang<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">_________________________________________________=
_____________<o:p></o:p></p>
<p class=3D"MsoPlainText">IEEE Communications Society Tech. Committee on Co=
mputer Communications
<a href=3D"http://committees.comsoc.org/tccc/">http://committees.comsoc.org=
/tccc/</a><o:p></o:p></p>
<p class=3D"MsoPlainText">TCCC Announce: For announcements concerning compu=
ter networking and communications.<o:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"mailto:tccc-announce@comsoc.org">tccc-=
announce@comsoc.org</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><a href=3D"https://comsoc-listserv.ieee.org/">htt=
ps://comsoc-listserv.ieee.org/</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_DM2PR0701MB7612AC49299DB9A8135449CB11B0DM2PR0701MB761na_--


From nobody Tue Mar 10 06:03:15 2015
Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DD01A8862 for <dmm@ietfa.amsl.com>; Tue, 10 Mar 2015 06:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twMQpzCAMlCt for <dmm@ietfa.amsl.com>; Tue, 10 Mar 2015 06:03:06 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF01A87A8 for <dmm@ietf.org>; Tue, 10 Mar 2015 06:03:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CA70F109657 for <dmm@ietf.org>; Tue, 10 Mar 2015 14:03:04 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjJtC5rfnwHE for <dmm@ietf.org>; Tue, 10 Mar 2015 14:03:04 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AC1D8109655 for <dmm@ietf.org>; Tue, 10 Mar 2015 14:03:02 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.37]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Tue, 10 Mar 2015 13:59:15 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: FPSM work team draft
Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMg==
Date: Tue, 10 Mar 2015 12:59:15 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/Qq8F9R228vQdJIHNFksmzlnQJTc>
Subject: [DMM] FPSM work team draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 13:03:14 -0000

--_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,

the FPSM work team published a first draft about a solution and information=
 model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it's not yet complete.

It would be good to receive some feedback, constructive comments and foster=
 discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.

marco



A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su=
bmitted by Marco Liebsch and posted to the IETF repository.



Name:                  draft-wt-dmm-fpc-cpdp

Revision:              00

Title:                      Protocol for Forwarding Policy Configuration (F=
PC) in DMM

Document date:               2015-03-09

Group:                  Individual Submission

Pages:                   26

URL:            http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0=
0.txt

Status:         https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized:       http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00




--_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Folks,<br>
<br>
<o:p></o:p></p>
<p class=3D"MsoNormal">the FPSM work team published a first draft about a s=
olution and information model for DMM Forwarding Policy Configuration.<br>
The draft should pretty much convey the approach but it&#8217;s not yet com=
plete. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">It would be good to receive some feedback, construct=
ive comments and foster discussion before IETF92 meeting<br>
on this mailing list, so we can address a set of items during the meeting.<=
o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">marco<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">A new version of I-D, draft-wt-dmm-fpc-cpdp-00.tx=
t has been successfully submitted by Marco Liebsch and posted to the IETF r=
epository.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"DE">Name:&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; draft-wt-dmm-fpc-cpdp<o:p></o:p></span></p>
<p class=3D"MsoPlainText">Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<o:p></o:p></p>
<p class=3D"MsoPlainText">Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Protocol for Forwarding Policy Configuration (FPC) in DMM<o:p></o:=
p></p>
<p class=3D"MsoPlainText">Document date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2015-03-09<o:p></o:p></p>
<p class=3D"MsoPlainText">Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Subm=
ission<o:p></o:p></p>
<p class=3D"MsoPlainText">Pages:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 26<o:p></=
o:p></p>
<p class=3D"MsoPlainText">URL:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; <a href=3D"http://www.ietf.org/internet-drafts/draft-=
wt-dmm-fpc-cpdp-00.txt">
http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt</a><o:p></=
o:p></p>
<p class=3D"MsoPlainText">Status:&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp=
;&nbsp;<a href=3D"https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/">=
https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/</a><o:p></o:p></p>
<p class=3D"MsoPlainText">Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a =
href=3D"http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00">
http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_69756203DDDDE64E987BC4F70B71A26D999EA4E0PALLENEofficehd_--


From nobody Fri Mar 13 05:08:23 2015
Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789721A0419 for <dmm@ietfa.amsl.com>; Fri, 13 Mar 2015 05:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level: 
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XafiSxK1EI0N for <dmm@ietfa.amsl.com>; Fri, 13 Mar 2015 05:08:17 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4591A0122 for <dmm@ietf.org>; Fri, 13 Mar 2015 05:08:15 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 13 Mar 2015 13:08:13 +0100
X-IronPort-AV: E=Sophos;i="5.11,394,1422918000";  d="scan'208,217";a="634970329"
Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 13 Mar 2015 13:08:13 +0100
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 Mar 2015 13:08:12 +0100
From: <Dirk.von-Hugo@telekom.de>
To: <Marco.Liebsch@neclab.eu>, <dmm@ietf.org>
Date: Fri, 13 Mar 2015 13:08:11 +0100
Thread-Topic: FPSM work team draft
Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMgCUboag
Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com>
References: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/J_nMiMZrKd3qxwdbA09B327wFWY>
Subject: Re: [DMM] FPSM work team draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 12:08:21 -0000

--_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Marco and WT,
Thanks for all the work! IMO the draft is quite clearly written and covers =
many details on messages and attributes for node configuration according to=
 policies - I didn't find missing ones so far ... ;-)
I only have few comments / nits detected so far:
P.3:
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differs
   between them.
=3D>
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differ
   between them.

P.6:
or multiple DPA(s) according
=3D>  should this be DPN(s) or is the Data-Plane Anchor (DPA) meant?

P.7:
o  Build, modify or delete logical ports as needed
=3D> in Fig. 4 only messages for add and delete of ports are listed - modif=
y here refers only to the attributes i.e. properties and rules, right?

p.10:
   o  PRT_ADD - Issued by a Client to add a new logical port at an
      Agent, to which traffic can be directed.
=3D> AFAIU the port is added at the DPN (where any traffic is directed to),=
 so should it read:
   o  PRT_ADD - Issued by a Client to an Agent to add a new logical port at=
 a
      DPN, to which traffic can be directed. (?)

P.11:
The Agent receiving such message should delete the rules from its
=3D> The Agent receiving such message should delete the rule from its

p.13:
LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN
=3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN

For the Appendix I am too little of a YANG Dr. so I only detected on
P.22:
               container trafic-descriptor {
=3D>               container traffic-descriptor {




Thanks and best regards - and have a nice weekend
Dirk

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 10. M=E4rz 2015 13:59
To: dmm@ietf.org
Subject: [DMM] FPSM work team draft

Folks,
the FPSM work team published a first draft about a solution and information=
 model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it's not yet complete.

It would be good to receive some feedback, constructive comments and foster=
 discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.

marco



A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su=
bmitted by Marco Liebsch and posted to the IETF repository.



Name:                  draft-wt-dmm-fpc-cpdp

Revision:              00

Title:                      Protocol for Forwarding Policy Configuration (F=
PC) in DMM

Document date:               2015-03-09

Group:                  Individual Submission

Pages:                   26

URL:            http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0=
0.txt

Status:         https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized:       http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00




--_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:900946828;
	mso-list-type:hybrid;
	mso-list-template-ids:-2131983886 -1814008640 67698691 67698693 67698689 6=
7698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:16;
	mso-level-number-format:bullet;
	mso-level-text:\F0F0;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c=
olor:#1F497D'>Dear Marco and WT,<o:p></o:p></span></p><p class=3DMsoNormal>=
<span style=3D'color:#1F497D'>Thanks for all the work! IMO the draft is qui=
te clearly written and covers many details on messages and attributes for n=
ode configuration according to policies &#8211; I didn&#8217;t find missing=
 ones so far &#8230; ;-)<o:p></o:p></span></p><p class=3DMsoNormal><span st=
yle=3D'color:#1F497D'> I only have few comments / nits detected so far:<o:p=
></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>P.3:<o=
:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><spa=
n style=3D'font-family:"Courier New"'>These<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-family:"Cour=
ier New"'>=A0=A0 requirements are met by various transport network componen=
ts, such as<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospa=
ce:none'><span style=3D'font-family:"Courier New"'>=A0=A0 IP switches and r=
outers, though configuration semantics differ<span style=3D'color:red'>s</s=
pan><o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none=
'><span style=3D'font-family:"Courier New"'>=A0=A0 </span><span lang=3DDE s=
tyle=3D'font-family:"Courier New"'>between them.<o:p></o:p></span></p><p cl=
ass=3DMsoNormal><span style=3D'color:#1F497D'>=3D&gt; <o:p></o:p></span></p=
><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-fam=
ily:"Courier New"'>These<o:p></o:p></span></p><p class=3DMsoNormal style=3D=
'text-autospace:none'><span style=3D'font-family:"Courier New"'>=A0=A0 requ=
irements are met by various transport network components, such as<o:p></o:p=
></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=
=3D'font-family:"Courier New"'>=A0=A0 IP switches and routers, though confi=
guration semantics differ<o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'text-autospace:none'><span style=3D'font-family:"Courier New"'>=A0=A0 <=
/span><span lang=3DDE style=3D'font-family:"Courier New"'>between them.<o:p=
></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span =
lang=3DDE style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><=
p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-famil=
y:"Courier New"'>P.6:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'te=
xt-autospace:none'><span style=3D'font-family:"Courier New"'>or multiple <s=
pan style=3D'color:red'>DPA</span>(s) according<o:p></o:p></span></p><p cla=
ss=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-family:"Co=
urier New"'>=3D&gt;=A0 should this be DPN(s) or is the Data-Plane Anchor (D=
PA) meant?<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospac=
e:none'><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span><=
/p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-f=
amily:"Courier New"'>P.7:<o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'text-autospace:none'><span style=3D'font-family:"Courier New"'>o=A0 Bui=
ld, <span style=3D'color:red'>modify </span>or delete logical ports as need=
ed<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'>=
<span style=3D'font-family:"Courier New"'>=3D&gt; in Fig. 4 only messages f=
or add and delete of ports are listed &#8211; modify here refers only to th=
e attributes i.e. properties and rules, right?<o:p></o:p></span></p><p clas=
s=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>p.10:<o:p></o:p></span></p>=
<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-fami=
ly:"Courier New"'>=A0=A0 o=A0 PRT_ADD - Issued by a Client to <span style=
=3D'color:red'>add a new logical port at an<o:p></o:p></span></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Courier New";color:red'>=A0=
=A0=A0=A0=A0 Agent</span><span style=3D'font-family:"Courier New"'>, to whi=
ch traffic can be directed.<o:p></o:p></span></p><p class=3DMsoNormal><span=
 style=3D'font-family:"Courier New"'>=3D&gt; AFAIU the port is added at the=
 DPN (where any traffic is directed to), so should it read:<o:p></o:p></spa=
n></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'fon=
t-family:"Courier New"'>=A0=A0 o=A0 PRT_ADD - Issued by a Client to an Agen=
t to <span style=3D'color:red'>add a new logical port at a<o:p></o:p></span=
></span></p><p class=3DMsoNormal><span style=3D'font-family:"Courier New";c=
olor:red'>=A0=A0=A0=A0=A0 DPN</span><span style=3D'font-family:"Courier New=
"'>, to which traffic can be directed. (?)<o:p></o:p></span></p><p class=3D=
MsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p clas=
s=3DMsoNormal><span style=3D'color:#1F497D'>P.11:<o:p></o:p></span></p><p c=
lass=3DMsoNormal><span style=3D'font-family:"Courier New"'>The Agent receiv=
ing such message should delete the rule<span style=3D'color:red'>s</span> f=
rom its<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-famil=
y:"Courier New"'>=3D&gt; The Agent receiving such message should delete the=
 rule from its<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'fon=
t-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><s=
pan style=3D'font-family:"Courier New"'>p.13:<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-family:"Cour=
ier New"'>LMA Control-Plane function (<span style=3D'color:red'>LMA_C), </s=
pan>the LMA-C selects a suitable DPN<o:p></o:p></span></p><p class=3DMsoNor=
mal style=3D'text-autospace:none'><span style=3D'font-family:"Courier New"'=
>=3D&gt; LMA Control-Plane function (<span style=3D'color:red'>LMA-C), </sp=
an>the LMA-C selects a suitable DPN<o:p></o:p></span></p><p class=3DMsoNorm=
al><span style=3D'font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Courier New"'>For the Append=
ix I am too little of a YANG Dr. so I only detected on<o:p></o:p></span></p=
><p class=3DMsoNormal><span lang=3DFR style=3D'font-family:"Courier New"'>P=
.22:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none=
'><span lang=3DFR style=3D'font-family:"Courier New"'>=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 container trafic-descriptor {<o:p></o:p></span></p><p=
 class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DFR style=3D'f=
ont-family:"Courier New"'>=3D&gt;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 container traffic-descriptor {<o:p></o:p></span></p><p class=3DMsoListPara=
graph><span lang=3DFR style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><=
p class=3DMsoListParagraph><span lang=3DFR style=3D'color:#1F497D'><o:p>&nb=
sp;</o:p></span></p><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:5=
.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace:no=
ne'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:=
#1F497D'>Thanks and best regards &#8211; and have a nice weekend <br>Dirk <=
/span><span lang=3DDE style=3D'font-family:"Times New Roman","serif";color:=
#1F497D'><o:p></o:p></span></p></div><p class=3DMsoNormal><span lang=3DDE s=
tyle=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style=3D'borde=
r:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=
=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-=
serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'> dmm [mailto:dmm-bounces@ietf.org] <b>On Behalf Of </b>Marc=
o Liebsch<br><b>Sent:</b> Dienstag, 10. M=E4rz 2015 13:59<br><b>To:</b> dmm=
@ietf.org<br><b>Subject:</b> [DMM] FPSM work team draft<o:p></o:p></span></=
p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorma=
l style=3D'margin-bottom:12.0pt'>Folks,<o:p></o:p></p><p class=3DMsoNormal>=
the FPSM work team published a first draft about a solution and information=
 model for DMM Forwarding Policy Configuration.<br>The draft should pretty =
much convey the approach but it&#8217;s not yet complete. <o:p></o:p></p><p=
 class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>It would be go=
od to receive some feedback, constructive comments and foster discussion be=
fore IETF92 meeting<br>on this mailing list, so we can address a set of ite=
ms during the meeting.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p>=
</p><p class=3DMsoNormal>marco<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbs=
p;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoPlainTe=
xt>A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully=
 submitted by Marco Liebsch and posted to the IETF repository.<o:p></o:p></=
p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText><spa=
n lang=3DDE>Name:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-wt-dmm-fpc-cpdp<o:p></o:=
p></span></p><p class=3DMsoPlainText>Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<o:p></o:p></p><p class=
=3DMsoPlainText>Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; P=
rotocol for Forwarding Policy Configuration (FPC) in DMM<o:p></o:p></p><p c=
lass=3DMsoPlainText>Document date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2015-03-09<o:p></o:p></p><p cla=
ss=3DMsoPlainText>Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Submission<o=
:p></o:p></p><p class=3DMsoPlainText>Pages:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 26<o:p></o:p></p><p class=3DMsoPlainText>URL:&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"http://www.ietf.org/inter=
net-drafts/draft-wt-dmm-fpc-cpdp-00.txt">http://www.ietf.org/internet-draft=
s/draft-wt-dmm-fpc-cpdp-00.txt</a><o:p></o:p></p><p class=3DMsoPlainText>St=
atus:&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"https://da=
tatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/">https://datatracker.ietf.org=
/doc/draft-wt-dmm-fpc-cpdp/</a><o:p></o:p></p><p class=3DMsoPlainText>Htmli=
zed:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"http://tools.ietf.org/h=
tml/draft-wt-dmm-fpc-cpdp-00">http://tools.ietf.org/html/draft-wt-dmm-fpc-c=
pdp-00</a><o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p=
></div></body></html>=

--_000_05C81A773E48DD49B181B04BA21A342A2FC0344FCCHE113484emea1_--


From nobody Fri Mar 13 06:54:56 2015
Return-Path: <Marco.Liebsch@neclab.eu>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104F21A87A3 for <dmm@ietfa.amsl.com>; Fri, 13 Mar 2015 06:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q8SC0gOuQ7U for <dmm@ietfa.amsl.com>; Fri, 13 Mar 2015 06:54:51 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB39E1A8798 for <dmm@ietf.org>; Fri, 13 Mar 2015 06:54:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5DAA81096FC; Fri, 13 Mar 2015 14:54:49 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOuQgfQJhRM7; Fri, 13 Mar 2015 14:54:49 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 3A9591096F9; Fri, 13 Mar 2015 14:54:45 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.208]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Fri, 13 Mar 2015 14:54:24 +0100
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: FPSM work team draft
Thread-Index: AdBbMehEOMyhzZDaT3uvew8WpvlIMgCUboagAARON3A=
Date: Fri, 13 Mar 2015 13:54:24 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D99A0728A@PALLENE.office.hd>
References: <69756203DDDDE64E987BC4F70B71A26D999EA4E0@PALLENE.office.hd> <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC0344FCC@HE113484.emea1.cds.t-internal.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.1]
Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/fsQMrpZLpahHTPyfSakkIr_XPCE>
Subject: Re: [DMM] FPSM work team draft
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 13:54:55 -0000

--_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Dirk,

thanks a lot for the feedback and the spotted typos.
We'll take them into account for the next revision. Hope we can continue
discussion during f2f meeting in Dallas.

marco


From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de]
Sent: Freitag, 13. M=E4rz 2015 13:08
To: Marco Liebsch; dmm@ietf.org
Subject: RE: FPSM work team draft

Dear Marco and WT,
Thanks for all the work! IMO the draft is quite clearly written and covers =
many details on messages and attributes for node configuration according to=
 policies - I didn't find missing ones so far ... ;-)
I only have few comments / nits detected so far:
P.3:
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differs
   between them.
=3D>
These
   requirements are met by various transport network components, such as
   IP switches and routers, though configuration semantics differ
   between them.

P.6:
or multiple DPA(s) according
=3D>  should this be DPN(s) or is the Data-Plane Anchor (DPA) meant?

P.7:
o  Build, modify or delete logical ports as needed
=3D> in Fig. 4 only messages for add and delete of ports are listed - modif=
y here refers only to the attributes i.e. properties and rules, right?

p.10:
   o  PRT_ADD - Issued by a Client to add a new logical port at an
      Agent, to which traffic can be directed.
=3D> AFAIU the port is added at the DPN (where any traffic is directed to),=
 so should it read:
   o  PRT_ADD - Issued by a Client to an Agent to add a new logical port at=
 a
      DPN, to which traffic can be directed. (?)

P.11:
The Agent receiving such message should delete the rules from its
=3D> The Agent receiving such message should delete the rule from its

p.13:
LMA Control-Plane function (LMA_C), the LMA-C selects a suitable DPN
=3D> LMA Control-Plane function (LMA-C), the LMA-C selects a suitable DPN

For the Appendix I am too little of a YANG Dr. so I only detected on
P.22:
               container trafic-descriptor {
=3D>               container traffic-descriptor {




Thanks and best regards - and have a nice weekend
Dirk

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Dienstag, 10. M=E4rz 2015 13:59
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] FPSM work team draft

Folks,
the FPSM work team published a first draft about a solution and information=
 model for DMM Forwarding Policy Configuration.
The draft should pretty much convey the approach but it's not yet complete.

It would be good to receive some feedback, constructive comments and foster=
 discussion before IETF92 meeting
on this mailing list, so we can address a set of items during the meeting.

marco



A new version of I-D, draft-wt-dmm-fpc-cpdp-00.txt has been successfully su=
bmitted by Marco Liebsch and posted to the IETF repository.



Name:                  draft-wt-dmm-fpc-cpdp

Revision:              00

Title:                      Protocol for Forwarding Policy Configuration (F=
PC) in DMM

Document date:               2015-03-09

Group:                  Individual Submission

Pages:                   26

URL:            http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-0=
0.txt

Status:         https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/

Htmlized:       http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00




--_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Dear Dirk,<br>
<br>
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">thanks a lot for the f=
eedback and the spotted typos.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">We&#8217;ll take them =
into account for the next revision. Hope we can continue<br>
discussion during f2f meeting in Dallas.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">marco<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Dirk.von=
-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de]
<br>
<b>Sent:</b> Freitag, 13. M=E4rz 2015 13:08<br>
<b>To:</b> Marco Liebsch; dmm@ietf.org<br>
<b>Subject:</b> RE: FPSM work team draft<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Dear Marco and WT,<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for all the wor=
k! IMO the draft is quite clearly written and covers many details on messag=
es and attributes for node configuration according to policies &#8211; I di=
dn&#8217;t find missing ones so far &#8230; ;-)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I only have few commen=
ts / nits detected so far:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">P.3:<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">These<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; requirements are met by various =
transport network components, such as<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; IP switches and routers, though =
configuration semantics differ<span style=3D"color:red">s</span><o:p></o:p>=
</span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp;
</span><span lang=3D"DE" style=3D"font-family:&quot;Courier New&quot;">betw=
een them.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">=3D&gt; <o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">These<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; requirements are met by various =
transport network components, such as<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; IP switches and routers, though =
configuration semantics differ<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp;
</span><span lang=3D"DE" style=3D"font-family:&quot;Courier New&quot;">betw=
een them.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span lang=3D"DE" styl=
e=3D"font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">P.6:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">or multiple
<span style=3D"color:red">DPA</span>(s) according<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">=3D&gt;&nbsp; should this be DPN(s) or is the=
 Data-Plane Anchor (DPA) meant?<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">P.7:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">o&nbsp; Build,
<span style=3D"color:red">modify </span>or delete logical ports as needed<o=
:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">=3D&gt; in Fig. 4 only messages for add and d=
elete of ports are listed &#8211; modify here refers only to the attributes=
 i.e. properties and rules, right?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">p.10:<o:p></o:p></span=
></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; o&nbsp; PRT_ADD - Issued by a Cl=
ient to
<span style=3D"color:red">add a new logical port at an<o:p></o:p></span></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;;c=
olor:red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Agent</span><span style=3D"font-fa=
mily:&quot;Courier New&quot;">, to which traffic can be directed.<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=3D&gt; AFAIU the port is added at the DPN (where any traffic is directed t=
o), so should it read:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">&nbsp;&nbsp; o&nbsp; PRT_ADD - Issued by a Cl=
ient to an Agent to
<span style=3D"color:red">add a new logical port at a<o:p></o:p></span></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;;c=
olor:red">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DPN</span><span style=3D"font-fami=
ly:&quot;Courier New&quot;">, to which traffic can be directed. (?)<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">P.11:<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
The Agent receiving such message should delete the rule<span style=3D"color=
:red">s</span> from its<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
=3D&gt; The Agent receiving such message should delete the rule from its<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
p.13:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">LMA Control-Plane function (<span style=3D"co=
lor:red">LMA_C),
</span>the LMA-C selects a suitable DPN<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-fa=
mily:&quot;Courier New&quot;">=3D&gt; LMA Control-Plane function (<span sty=
le=3D"color:red">LMA-C),
</span>the LMA-C selects a suitable DPN<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
<o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Courier New&quot;">=
For the Appendix I am too little of a YANG Dr. so I only detected on<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"FR" style=3D"font-family:&quot;Courier=
 New&quot;">P.22:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span lang=3D"FR" styl=
e=3D"font-family:&quot;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; container trafic-descri=
ptor {<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span lang=3D"FR" styl=
e=3D"font-family:&quot;Courier New&quot;">=3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; container traffi=
c-descriptor {<o:p></o:p></span></p>
<p class=3D"MsoListParagraph"><span lang=3D"FR" style=3D"color:#1F497D"><o:=
p>&nbsp;</o:p></span></p>
<p class=3D"MsoListParagraph"><span lang=3D"FR" style=3D"color:#1F497D"><o:=
p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:5.0pt;margin-right:0cm;m=
argin-bottom:5.0pt;margin-left:0cm;text-autospace:none">
<span style=3D"font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-se=
rif&quot;;color:#1F497D">Thanks and best regards &#8211; and have a nice we=
ekend
<br>
Dirk </span><span lang=3D"DE" style=3D"font-family:&quot;Times New Roman&qu=
ot;,&quot;serif&quot;;color:#1F497D"><o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"DE" style=3D"color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> dmm [<a =
href=3D"mailto:dmm-bounces@ietf.org">mailto:dmm-bounces@ietf.org</a>]
<b>On Behalf Of </b>Marco Liebsch<br>
<b>Sent:</b> Dienstag, 10. M=E4rz 2015 13:59<br>
<b>To:</b> <a href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br>
<b>Subject:</b> [DMM] FPSM work team draft<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Folks,<o:p></o:p></p>
<p class=3D"MsoNormal">the FPSM work team published a first draft about a s=
olution and information model for DMM Forwarding Policy Configuration.<br>
The draft should pretty much convey the approach but it&#8217;s not yet com=
plete. <o:p>
</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">It would be good to receive some feedback, construct=
ive comments and foster discussion before IETF92 meeting<br>
on this mailing list, so we can address a set of items during the meeting.<=
o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">marco<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">A new version of I-D, draft-wt-dmm-fpc-cpdp-00.tx=
t has been successfully submitted by Marco Liebsch and posted to the IETF r=
epository.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"DE">Name:&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; draft-wt-dmm-fpc-cpdp<o:p></o:p></span></p>
<p class=3D"MsoPlainText">Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00<o:p></o:p></p>
<p class=3D"MsoPlainText">Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; Protocol for Forwarding Policy Configuration (FPC) in DMM<o:p></o:=
p></p>
<p class=3D"MsoPlainText">Document date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2015-03-09<o:p></o:p></p>
<p class=3D"MsoPlainText">Group:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Individual Subm=
ission<o:p></o:p></p>
<p class=3D"MsoPlainText">Pages:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 26<o:p></=
o:p></p>
<p class=3D"MsoPlainText">URL:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; <a href=3D"http://www.ietf.org/internet-drafts/draft-=
wt-dmm-fpc-cpdp-00.txt">
http://www.ietf.org/internet-drafts/draft-wt-dmm-fpc-cpdp-00.txt</a><o:p></=
o:p></p>
<p class=3D"MsoPlainText">Status:&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp=
;&nbsp;<a href=3D"https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/">=
https://datatracker.ietf.org/doc/draft-wt-dmm-fpc-cpdp/</a><o:p></o:p></p>
<p class=3D"MsoPlainText">Htmlized:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a =
href=3D"http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00">
http://tools.ietf.org/html/draft-wt-dmm-fpc-cpdp-00</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_69756203DDDDE64E987BC4F70B71A26D99A0728APALLENEofficehd_--


From nobody Wed Mar 18 02:54:34 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF74A1A8871 for <dmm@ietfa.amsl.com>; Wed, 18 Mar 2015 02:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2OSnBZT3jna for <dmm@ietfa.amsl.com>; Wed, 18 Mar 2015 02:54:31 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F060E1A8849 for <dmm@ietf.org>; Wed, 18 Mar 2015 02:54:30 -0700 (PDT)
Received: from [192.168.2.2] ([88.235.141.59]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MUWfN-1Yyo5O1j2x-00RJ5b for <dmm@ietf.org>; Wed, 18 Mar 2015 10:54:29 +0100
From: Alper Yegin <alper.yegin@yegin.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7"
Date: Wed, 18 Mar 2015 11:54:10 +0200
Message-Id: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org>
To: dmm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:UzLxLBkGuANYdyj8YY8QTwdX/dWUtDa4n8ovwcf4bwVlQLXF4Kt R96XWOVve1ZuFzvjTuQiVUeLc2rDmTt2ssHGDMB7RkxnP9o6AgeqUB0ZFve2qshT5h9O69Z qgh27+8ejubYuc+Cy+629IHir8YPJBRvgOkjL1X2RVt04ZYqSbPG1s8e6lsnqTYxs4lOVDW bh9/9Yo8pP0FgMvKlGg2w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/vQzVdXBUA_19xbsiArgYoWIM9pI>
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2015 09:54:32 -0000

--Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello DMM WG members,

As you remember, WT#1 came to an agreement to propose the following I-D =
as the baseline for the API piece:

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt

We'll be proposing its adoption in Dallas.

FYI, and here's your chance to voice any input in advance.

Cheers,

Alper




--Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello DMM WG members,</div><div><br></div><div>As you remember, WT#1 came to an agreement to propose the following I-D as the baseline for the API piece:</div><div><br></div><a href="http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt">http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt</a><div><br></div><div>We'll be proposing its adoption in Dallas.</div><div><br></div><div>FYI, and here's your chance to voice any input in advance.</div><div><br></div><div>Cheers,</div><div><br></div><div>Alper</div><div><br></div><div><br><div><br></div></div></body></html>
--Apple-Mail=_1457839B-E64E-4CF0-BF93-4ECA906403C7--


From nobody Thu Mar 19 10:09:15 2015
Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DABA1A6EE4 for <dmm@ietfa.amsl.com>; Thu, 19 Mar 2015 10:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level: 
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujWxA7oIzhsx for <dmm@ietfa.amsl.com>; Thu, 19 Mar 2015 10:09:10 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB901A1BF5 for <dmm@ietf.org>; Thu, 19 Mar 2015 10:09:03 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP; 19 Mar 2015 18:09:00 +0100
X-IronPort-AV: E=Sophos;i="5.11,430,1422918000";  d="scan'208,217";a="639011555"
Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 19 Mar 2015 18:09:00 +0100
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Mar 2015 18:09:00 +0100
From: <Dirk.von-Hugo@telekom.de>
To: <alper.yegin@yegin.org>, <dmm@ietf.org>
Date: Thu, 19 Mar 2015 18:09:00 +0100
Thread-Topic: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
Thread-Index: AdBhYfppCyhZxHdOS0a0JWSWNLl6IgA5lubQ
Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com>
References: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org>
In-Reply-To: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/kayaIU21IovFwxLBJpYbWJByPMc>
Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 17:09:14 -0000

--_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Alper and co-authors,
Thanks for your work!
IMO the draft is clearly written and ready for adoption though some questio=
ns and comments came to my mind:

In the Intro Mobile IP is referenced to both client and Proxy MIP
In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
- but in the remaining PMIP functional elements (MAG, LMA) are never mentio=
ned ... silly question: so do you propose to apply the solution only to cli=
ent MIP based approaches or do you implicitly assume for mobility unaware h=
osts/devices that the IP stack on MAG is addressed instead? I suggest to ad=
d a clarification in the beginning ...

P.4:
   A sustained IP address may be configured and maintained by using
   access network anchoring, corresponding network anchoring, or some
   other solution.
I suggest to add a reference here (RFC7429 defining Anchoring Function) or =
explain with "allocating to a mobile node an IP
       address analogous to CoA at FA in MIP by selecting an anchor router =
for relaying the traffic" or similar ...

P.5:
Applications running as servers at a published IP address require a
   Fixed IP Address.  Long-standing applications (e.g., an SSH session)
   may also require this type of address.  Those applications could use
   a Sustained IP Address, but that can produce sub-optimal results if
   the mobile host ends up far from the anchor gateway.
The latter sentence sounds to me as such sub-optimality will  not happen in=
 case of Fixed IP Address - isn't it even worse when the host already start=
s far from the centrally-located Home Network ...?

then the IP stack shall fail the associated socket request.
=3D> then the IP stack shall fail to fulfil/meet/comply with the associated=
 socket request.
P.6:
   - Determination of a default address type when an application does
   not make any explicit indication, whether it already supports the
   required API or it is just a legacy application.
Do you refer here to the below mentioned  Socket API-based interface ... [R=
FC5014]?
Otherwise I suggest to add some explanatory words on the required API.

P.7:
More than one of these flags may be set on the same socket.  In that
   case, an IP address compliant with any one of them shall be selected.
   TBD: Disallow this case?
Since here we have requirements instead of preferences unavailability of th=
e required address type would force configuration of compliant address - bu=
t some applications can accept several types (for different planes CP/DP or=
 with different priority). Question is what would be the additional effort =
for forced configuration vs. gain by 'more optimal' performance?
My guess: allow, but introduce priority for selection

In addition few nits detected:
P.2:
   despite the mobile host chaging its point of attachment within the IP
=3D>   despite the mobile host changing its point of attachment within the =
IP
P.3:
   session continuity and IP address reachability should be be provided
=3D>   session continuity and IP address reachability should be provided
P.4:
   The mobile host is configures a HoA from a centrally-located Home
=3D>   The mobile host configures a HoA from a centrally-located Home
Thanks!
Best Regards
Dirk


From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. M=E4rz 2015 10:54
To: dmm@ietf.org
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

Hello DMM WG members,

As you remember, WT#1 came to an agreement to propose the following I-D as =
the baseline for the API piece:

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt

We'll be proposing its adoption in Dallas.

FYI, and here's your chance to voice any input in advance.

Cheers,

Alper




--_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dear Alpe=
r and co-authors,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'=
font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks f=
or your work!<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font=
-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>IMO the draf=
t is clearly written and ready for adoption though some questions and comme=
nts came to my mind:<o:p></o:p></span></p><p class=3DMsoNormal><span style=
=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p=
>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Calibri","sans-serif";color:#1F497D'>In the Intro Mobile IP =
is referenced to both client and Proxy MIP <o:p></o:p></span></p><p class=
=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>In =
the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
> <o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Calibri","sans-serif";color:#1F497D'>&#8211; but in the rema=
ining PMIP functional elements (MAG, LMA) are never mentioned &#8230; silly=
 question: so do you propose to apply the solution only to client MIP based=
 approaches or do you implicitly assume for mobility unaware hosts/devices =
that the IP stack on MAG is addressed instead? I suggest to add a clarifica=
tion in the beginning &#8230;<o:p></o:p></span></p><p class=3DMsoNormal><sp=
an style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49=
7D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-si=
ze:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>P.4:<o:p></o:p>=
</span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=
=3D'font-size:11.0pt;font-family:"Courier New"'>=A0=A0 A sustained IP addre=
ss may be configured and maintained by using<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:11.0pt;=
font-family:"Courier New"'>=A0=A0 access network anchoring, corresponding n=
etwork anchoring, or some<o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-family:"Couri=
er New"'>=A0=A0 other solution.<o:p></o:p></span></p><p class=3DMsoNormal><=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>I suggest to add a reference here (RFC7429 defining Anchoring Functio=
n) or explain with &#8220;allocating to a mobile node an IP<o:p></o:p></spa=
n></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cal=
ibri","sans-serif";color:#1F497D'>=A0=A0=A0=A0=A0=A0 address analogous to C=
oA at FA in MIP by selecting an anchor router for relaying the traffic&#822=
1; or similar &#8230;<o:p></o:p></span></p><p class=3DMsoNormal><span style=
=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p=
>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Calibri","sans-serif";color:#1F497D'>P.5:<o:p></o:p></span><=
/p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-s=
ize:11.0pt;font-family:"Courier New"'>Applications running as servers at a =
published IP address require a<o:p></o:p></span></p><p class=3DMsoNormal st=
yle=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-family:"Co=
urier New"'>=A0=A0 Fixed IP Address.=A0 Long-standing applications (e.g., a=
n SSH session)<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-auto=
space:none'><span style=3D'font-size:11.0pt;font-family:"Courier New"'>=A0=
=A0 may also require this type of address.=A0 <span style=3D'color:red'>Tho=
se applications could use<o:p></o:p></span></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-family:"=
Courier New";color:red'>=A0=A0 a Sustained IP Address, but that can produce=
 sub-optimal results if<o:p></o:p></span></p><p class=3DMsoNormal><span sty=
le=3D'font-size:11.0pt;font-family:"Courier New";color:red'>=A0=A0 the mobi=
le host ends up far from the anchor gateway</span><span style=3D'font-size:=
11.0pt;font-family:"Courier New"'>.<o:p></o:p></span></p><p class=3DMsoNorm=
al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color=
:#1F497D'>The latter sentence sounds to me as such sub-optimality will =A0n=
ot happen in case of Fixed IP Address &#8211; isn&#8217;t it even worse whe=
n the host already starts far from the centrally-located Home Network &#823=
0;?<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0=
pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></spa=
n></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cou=
rier New"'>then the IP stack shall fail the associated socket request.=A0 <=
o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;f=
ont-family:"Courier New"'>=3D&gt; then the IP stack shall fail <span style=
=3D'color:red'>to fulfil/meet/comply with </span>the associated socket requ=
est.=A0 </span><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-=
serif";color:#1F497D'><o:p></o:p></span></p><div><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-le=
ft:0cm;text-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D'>P.6:<o:p></o:p></span></p><p class=3DMsoNo=
rmal style=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-fam=
ily:"Courier New"'>=A0=A0 - Determination of a default address type when an=
 application does<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-a=
utospace:none'><span style=3D'font-size:11.0pt;font-family:"Courier New"'>=
=A0=A0 not make any explicit indication, whether <span style=3D'color:red'>=
it already supports the<o:p></o:p></span></span></p><p class=3DMsoNormal st=
yle=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-family:"Co=
urier New";color:red'>=A0=A0 required API </span><span style=3D'font-size:1=
1.0pt;font-family:"Courier New"'>or it is just a legacy application.<o:p></=
o:p></span></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margi=
n-right:0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace:none'><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>D=
o you refer here to the below mentioned =A0</span><span style=3D'font-size:=
11.0pt;font-family:"Courier New"'>Socket API-based interface &#8230; [RFC50=
14]?</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"=
;color:#1F497D'><o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso-mar=
gin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0cm;text=
-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-=
serif";color:#1F497D'>Otherwise I suggest to add some explanatory words on =
the required API.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso-ma=
rgin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0cm;tex=
t-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Arial","sans=
-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal sty=
le=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-=
left:0cm;text-autospace:none'><span style=3D'font-size:10.0pt;font-family:"=
Arial","sans-serif";color:#1F497D'>P.7:<o:p></o:p></span></p><p class=3DMso=
Normal style=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-f=
amily:"Courier New"'>More than one of these flags may be set on the same so=
cket.=A0 In that<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-au=
tospace:none'><span style=3D'font-size:11.0pt;font-family:"Courier New"'>=
=A0=A0 case, an IP address compliant with any one of them shall be selected=
.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><=
span style=3D'font-size:11.0pt;font-family:"Courier New"'>=A0=A0 <span styl=
e=3D'color:red'>TBD: Disallow this case?</span><o:p></o:p></span></p><p cla=
ss=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bo=
ttom:5.0pt;margin-left:0cm;text-autospace:none'><span style=3D'font-size:10=
.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Since here we have req=
uirements instead of preferences unavailability of the required address typ=
e would force configuration of compliant address &#8211; but some applicati=
ons can accept several types (for different planes CP/DP or with different =
priority). Question is what would be the additional effort for forced confi=
guration vs. gain by &#8216;more optimal&#8217; performance? <o:p></o:p></s=
pan></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margin-right=
:0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace:none'><span style=
=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>My gue=
ss: allow, but introduce priority for selection <o:p></o:p></span></p><p cl=
ass=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-b=
ottom:5.0pt;margin-left:0cm;text-autospace:none'><span style=3D'font-size:1=
0.0pt;font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></sp=
an></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margin-right:=
0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace:none'><span style=3D=
'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>In additi=
on few nits detected: <o:p></o:p></span></p><p class=3DMsoNormal style=3D'm=
so-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0c=
m;text-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Arial",=
"sans-serif";color:#1F497D'>P.2:<o:p></o:p></span></p><p class=3DMsoNormal =
style=3D'text-autospace:none'><span style=3D'font-size:11.0pt;font-family:"=
Courier New"'>=A0=A0 despite the mobile host chaging its point of attachmen=
t within the IP<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-aut=
ospace:none'><b><span style=3D'font-size:10.0pt;font-family:"Arial","sans-s=
erif";color:#1F497D'>=3D&gt;</span></b><span style=3D'font-size:11.0pt;font=
-family:"Courier New"'>=A0=A0 despite the mobile host cha<span style=3D'col=
or:red'>n</span>ging its point of attachment within the IP<o:p></o:p></span=
></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:5.0pt;margin-right:0c=
m;margin-bottom:5.0pt;margin-left:0cm;text-autospace:none'><span style=3D'f=
ont-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>P.3:<o:p></=
o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span sty=
le=3D'font-size:11.0pt;font-family:"Courier New"'>=A0=A0 session continuity=
 and IP address reachability should <span style=3D'color:red'>be </span>be =
provided<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:=
none'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";colo=
r:#1F497D'>=3D&gt;</span><span style=3D'font-size:11.0pt;font-family:"Couri=
er New"'>=A0=A0 session continuity and IP address reachability should be pr=
ovided<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso-margin-top-al=
t:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace=
:none'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col=
or:#1F497D'>P.4:<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-au=
tospace:none'><span style=3D'font-size:11.0pt;font-family:"Courier New"'>=
=A0=A0 The mobile host <span style=3D'color:red'>is</span> configures a HoA=
 from a centrally-located Home<o:p></o:p></span></p><p class=3DMsoNormal st=
yle=3D'text-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D'>=3D&gt;</span><span style=3D'font-size:11.=
0pt;font-family:"Courier New"'>=A0=A0 The mobile host configures a HoA from=
 a centrally-located Home<o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.0pt;margin-le=
ft:0cm;text-autospace:none'><span style=3D'font-size:10.0pt;font-family:"Ar=
ial","sans-serif";color:#1F497D'>Thanks!<o:p></o:p></span></p><p class=3DMs=
oNormal style=3D'mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:5.=
0pt;margin-left:0cm;text-autospace:none'><span style=3D'font-size:10.0pt;fo=
nt-family:"Arial","sans-serif";color:#1F497D'>Best Regards<br>Dirk </span><=
span style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:black;=
text-transform:uppercase'><o:p></o:p></span></p><p class=3DMsoNormal style=
=3D'text-autospace:none'><span style=3D'font-size:11.0pt;color:#1F497D'><o:=
p>&nbsp;</o:p></span></p></div><p class=3DMsoNormal><span style=3D'font-siz=
e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;p=
adding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span style=3D'font-size:=
10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'fo=
nt-size:10.0pt;font-family:"Tahoma","sans-serif"'> dmm [mailto:dmm-bounces@=
ietf.org] <b>On Behalf Of </b>Alper Yegin<br><b>Sent:</b> Mittwoch, 18. M=
=E4rz 2015 10:54<br><b>To:</b> dmm@ietf.org<br><b>Subject:</b> [DMM] WG ado=
ption for draft-yegin-ondemand-mobility-03<o:p></o:p></span></p></div></div=
><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>Hello =
DMM WG members,<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</=
o:p></p></div><div><p class=3DMsoNormal>As you remember, WT#1 came to an ag=
reement to propose the following I-D as the baseline for the API piece:<o:p=
></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p cl=
ass=3DMsoNormal><a href=3D"http://www.ietf.org/id/draft-yegin-dmm-ondemand-=
mobility-03.txt">http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-0=
3.txt</a><o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></di=
v><div><p class=3DMsoNormal>We'll be proposing its adoption in Dallas.<o:p>=
</o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><=
p class=3DMsoNormal>FYI, and here's your chance to voice any input in advan=
ce.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></di=
v><div><p class=3DMsoNormal>Cheers,<o:p></o:p></p></div><div><p class=3DMso=
Normal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>Alper<o:p></o:p=
></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p cla=
ss=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</=
o:p></p></div></div></div></body></html>=

--_000_05C81A773E48DD49B181B04BA21A342A2FC04310EDHE113484emea1_--


From nobody Thu Mar 19 11:04:51 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C91A876B for <dmm@ietfa.amsl.com>; Thu, 19 Mar 2015 11:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1sWT06b4Ym3 for <dmm@ietfa.amsl.com>; Thu, 19 Mar 2015 11:04:47 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08E1A8743 for <dmm@ietf.org>; Thu, 19 Mar 2015 11:04:47 -0700 (PDT)
Received: from [192.168.2.2] ([88.235.141.59]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MTyy7-1Yysn30F0b-00QhwD; Thu, 19 Mar 2015 19:04:41 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com>
Date: Thu, 19 Mar 2015 20:04:23 +0200
Message-Id: <F2794365-90B2-4AD7-931C-A13C1D14AD7B@yegin.org>
References: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org> <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com>
To: <Dirk.von-Hugo@telekom.de>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:nOkZkorrNvdZswa0m295fD+O5YEkYx0lgB8VvJqaVwl4ikElYOX hhY0epmgJ6o6bPtWPwxj8gZGgyx/slIWJffgzdD44I8ydbqsx7uMsroA7XYTfV1w4CWihpO Ksumf5P/lsAwr2f9M3JX7bGTIMBLPofDni7Z6j5M5KRdtc/7Ji8M9msT5nxaE+HIkfmlSW1 2O7vXm6OJ9nEzHqZ5MIvw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/Sv1KDFi-Fv5Fzx0Ir8FlDh_s4oc>
Cc: dmm@ietf.org
Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 18:04:50 -0000

--Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello Dirk,

Thanks for the comments.
Please see below.

On Mar 19, 2015, at 7:09 PM, <Dirk.von-Hugo@telekom.de> wrote:

> Dear Alper and co-authors,
> Thanks for your work!
> IMO the draft is clearly written and ready for adoption though some =
questions and comments came to my mind:
> =20
> In the Intro Mobile IP is referenced to both client and Proxy MIP
> In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
> =96 but in the remaining PMIP functional elements (MAG, LMA) are never =
mentioned =85 silly question: so do you propose to apply the solution =
only to client MIP based approaches or do you implicitly assume for =
mobility unaware hosts/devices that the IP stack on MAG is addressed =
instead? I suggest to add a clarification in the beginning =85

API applies to both CMIP and PMIP hosts.
We don't mention MAG or LMA, as those details are not related to the =
"API".



> =20
> P.4:
>    A sustained IP address may be configured and maintained by using
>    access network anchoring, corresponding network anchoring, or some
>    other solution.
> I suggest to add a reference here (RFC7429 defining Anchoring =
Function) or explain with =93allocating to a mobile node an IP
>        address analogous to CoA at FA in MIP by selecting an anchor =
router for relaying the traffic=94 or similar =85

Very good idea, will do.

> =20
> P.5:
> Applications running as servers at a published IP address require a
>    Fixed IP Address.  Long-standing applications (e.g., an SSH =
session)
>    may also require this type of address.  Those applications could =
use
>    a Sustained IP Address, but that can produce sub-optimal results if
>    the mobile host ends up far from the anchor gateway.
> The latter sentence sounds to me as such sub-optimality will  not =
happen in case of Fixed IP Address =96 isn=92t it even worse when the =
host already starts far from the centrally-located Home Network =85?
> =20

Right, it can be=85.. But depending on the deployment, a centralized HA =
may be in a better position to serve long sessions than an AR at the =
edge (because of scalability, and also funneling traffic "in&out" may =
not suit the AR well, as its uplink may not be provisioned with enough =
capacity).=20
Anyways, we should massage the text, .. will propose something.


> then the IP stack shall fail the associated socket request.=20
> =3D> then the IP stack shall fail to fulfil/meet/comply with the =
associated socket request.=20
> P.6:
>    - Determination of a default address type when an application does
>    not make any explicit indication, whether it already supports the
>    required API or it is just a legacy application.
> Do you refer here to the below mentioned  Socket API-based interface =85=
 [RFC5014]?
> Otherwise I suggest to add some explanatory words on the required API.

We are referring to the API we are defining in this I-D. Will clarify in =
the text.


> =20
> P.7:
> More than one of these flags may be set on the same socket.  In that
>    case, an IP address compliant with any one of them shall be =
selected.
>    TBD: Disallow this case?
> Since here we have requirements instead of preferences unavailability =
of the required address type would force configuration of compliant =
address =96 but some applications can accept several types (for =
different planes CP/DP or with different priority). Question is what =
would be the additional effort for forced configuration vs. gain by =
=91more optimal=92 performance?
> My guess: allow, but introduce priority for selection
> =20
>=20

Where should the priority come from? The spec shall state it?

> In addition few nits detected:
> P.2:
>    despite the mobile host chaging its point of attachment within the =
IP
> =3D>   despite the mobile host changing its point of attachment within =
the IP
> P.3:
>    session continuity and IP address reachability should be be =
provided
> =3D>   session continuity and IP address reachability should be =
provided
> P.4:
>    The mobile host is configures a HoA from a centrally-located Home
> =3D>   The mobile host configures a HoA from a centrally-located Home
> Thanks!

Thank you!

Alper


> Best Regards
> Dirk
> =20
> =20
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
> Sent: Mittwoch, 18. M=E4rz 2015 10:54
> To: dmm@ietf.org
> Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
> =20
> Hello DMM WG members,
> =20
> As you remember, WT#1 came to an agreement to propose the following =
I-D as the baseline for the API piece:
> =20
> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt
> =20
> We'll be proposing its adoption in Dallas.
> =20
> FYI, and here's your chance to voice any input in advance.
> =20
> Cheers,
> =20
> Alper
> =20
> =20


--Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href=3D"x-msg://2448/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">Hello Dirk,<div><br></div><div>Thanks for the =
comments.</div><div>Please see below.</div><div><br><div><div>On Mar 19, =
2015, at 7:09 PM, &lt;<a =
href=3D"mailto:Dirk.von-Hugo@telekom.de">Dirk.von-Hugo@telekom.de</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Dear =
Alper and co-authors,<o:p></o:p></span></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">Thanks for your work!<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">IMO the draft is clearly written =
and ready for adoption though some questions and comments came to my =
mind:<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">In =
the Intro Mobile IP is referenced to both client and Proxy =
MIP<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: 'Courier New'; ">In the context of Mobile IP =
[RFC5563][RFC6275][RFC5213][RFC5944],</span><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">=96 but in =
the remaining PMIP functional elements (MAG, LMA) are never mentioned =85 =
silly question: so do you propose to apply the solution only to client =
MIP based approaches or do you implicitly assume for mobility unaware =
hosts/devices that the IP stack on MAG is addressed instead? I suggest =
to add a clarification in the beginning =85<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"></span></div></div></div></span></blockquote><div><br></div><div>API =
applies to both CMIP and PMIP hosts.</div><div>We don't mention MAG or =
LMA, as those details are not related to the =
"API".</div><div><br></div><div><br></div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">P.4:<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; A sustained IP address =
may be configured and maintained by using<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; access network anchoring, corresponding network =
anchoring, or some<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; other =
solution.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I =
suggest to add a reference here (RFC7429 defining Anchoring Function) or =
explain with =93allocating to a mobile node an =
IP<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; address analogous to CoA at FA in =
MIP by selecting an anchor router for relaying the traffic=94 or similar =
=85<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"></span></div></div></div></span></blockquote><div><br></div><div>Very =
good idea, will do.</div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">P.5:<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">Applications running as servers at a =
published IP address require a<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; Fixed IP Address.&nbsp; Long-standing applications =
(e.g., an SSH session)<o:p></o:p></span></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; may =
also require this type of address.&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">Those applications could use<o:p></o:p></span></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; color: red; ">&nbsp;&nbsp; a Sustained IP Address, but that can =
produce sub-optimal results if<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; color: red; ">&nbsp;&nbsp; the mobile host ends up far from the =
anchor gateway</span><span style=3D"font-size: 11pt; font-family: =
'Courier New'; ">.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">The =
latter sentence sounds to me as such sub-optimality will &nbsp;not =
happen in case of Fixed IP Address =96 isn=92t it even worse when the =
host already starts far from the centrally-located Home Network =
=85?<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div></div></div></span></blockquote><div><br><=
/div><div>Right, it can be=85.. But depending on the deployment, a =
centralized HA may be in a better position to serve long sessions than =
an AR at the edge (because of scalability, and also funneling traffic =
"in&amp;out" may not suit the AR well, as its uplink may not be =
provisioned with enough capacity).&nbsp;</div><div>Anyways, we should =
massage the text, .. will propose =
something.</div><div><br></div><div><br></div><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">then the IP stack shall fail the =
associated socket request.&nbsp;<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">=3D&gt; then the IP stack shall fail<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">to fulfil/meet/comply with<span =
class=3D"Apple-converted-space">&nbsp;</span></span>the associated =
socket request.&nbsp;</span><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p></o:p></span></div><div><p class=3D"MsoNormal" style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">P.6:<o:p></o:p></span></p><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; - Determination of a =
default address type when an application =
does<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: 'Courier New'; ">&nbsp;&nbsp; not make any explicit =
indication, whether<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">it already supports the<o:p></o:p></span></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; color: red; ">&nbsp;&nbsp; required API<span =
class=3D"Apple-converted-space">&nbsp;</span></span><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">or it is just a =
legacy application.<o:p></o:p></span></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Do you refer here to the below mentioned =
&nbsp;</span><span style=3D"font-size: 11pt; font-family: 'Courier New'; =
">Socket API-based interface =85 [RFC5014]?</span><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); "><o:p></o:p></span></p><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Otherwise I suggest to add some explanatory =
words on the required API.<o:p></o:p></span></p><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); =
"></span></p></div></div></div></span></blockquote><div><br></div><div>We =
are referring to the API we are defining in this I-D. Will clarify in =
the text.</div><div><br></div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); =
">P.7:<o:p></o:p></span></p><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: 'Courier New'; ">More than one of these flags may be set on =
the same socket.&nbsp; In that<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; case, an IP address compliant with any one of them =
shall be selected.<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">TBD: Disallow this case?</span><o:p></o:p></span></div><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); ">Since here we have =
requirements instead of preferences unavailability of the required =
address type would force configuration of compliant address =96 but some =
applications can accept several types (for different planes CP/DP or =
with different priority). Question is what would be the additional =
effort for forced configuration vs. gain by =91more optimal=92 =
performance?<o:p></o:p></span></p><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">My guess: allow, but introduce priority for =
selection<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); =
"><o:p>&nbsp;</o:p></span></p><div><br></div></div></div></div></span></bl=
ockquote><div><br></div>Where should the priority come from? The spec =
shall state it?<br><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">In addition few nits =
detected:<o:p></o:p></span></p><p class=3D"MsoNormal" style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">P.2:<o:p></o:p></span></p><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; despite the mobile host =
chaging its point of attachment within the =
IP<o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><b><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">=3D&gt;</span></b><span style=3D"font-size: 11pt; font-family: =
'Courier New'; ">&nbsp;&nbsp; despite the mobile host cha<span =
style=3D"color: red; ">n</span>ging its point of attachment within the =
IP<o:p></o:p></span></div><p class=3D"MsoNormal" style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">P.3:<o:p></o:p></span></p><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: 'Courier New'; ">&nbsp;&nbsp; session continuity and IP =
address reachability should<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">be<span class=3D"Apple-converted-space">&nbsp;</span></span>be =
provided<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">=3D&gt;</span><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; session continuity and IP address reachability =
should be provided<o:p></o:p></span></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">P.4:<o:p></o:p></span></p><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; The mobile host<span =
class=3D"Apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">is</span><span class=3D"Apple-converted-space">&nbsp;</span>configures =
a HoA from a centrally-located Home<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 10pt; font-family: Arial, =
sans-serif; color: rgb(31, 73, 125); ">=3D&gt;</span><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; The =
mobile host configures a HoA from a centrally-located =
Home<o:p></o:p></span></div><p class=3D"MsoNormal" style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">Thanks!</span></p></div></div></div></span></blockquote><div><br></div><=
div>Thank =
you!</div><div><br></div><div>Alper</div><div><br></div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); "><o:p></o:p></span></p><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Best Regards<br>Dirk</span><span =
style=3D"font-size: 8pt; font-family: Arial, sans-serif; color: black; =
text-transform: uppercase; "><o:p></o:p></span></p><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; color: rgb(31, 73, =
125); "><o:p>&nbsp;</o:p></span></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding-top: 3pt; padding-right: 0cm; =
padding-bottom: 0cm; padding-left: 0cm; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif; "><span class=3D"Apple-converted-space">&nbsp;</span>dmm =
[mailto:dmm-bounces@ietf.org]<span =
class=3D"Apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></b>Alper =
Yegin<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Mittwoch, 18. M=E4rz 2015 =
10:54<br><b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>[DMM] WG adoption for =
draft-yegin-ondemand-mobility-03<o:p></o:p></span></div></div></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">Hello DMM WG =
members,<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">As you remember, WT#1 =
came to an agreement to propose the following I-D as the baseline for =
the API piece:<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><a =
href=3D"http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt" =
style=3D"color: blue; text-decoration: underline; =
">http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt</a><o:p>=
</o:p></div><div><div style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">We'll be proposing its adoption in =
Dallas.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">FYI, and here's your =
chance to voice any input in advance.<o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">Cheers,<o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">Alper<o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; =
"></p></div></div></div></div></span></blockquote></div><br></div></body><=
/html>=

--Apple-Mail=_86FA385D-D185-4E21-A832-799ACAD5768A--


From nobody Fri Mar 20 03:13:09 2015
Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA31B2CA9 for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2015 03:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level: 
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-iNbmZBEpJu for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2015 03:13:00 -0700 (PDT)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07CC1B2C86 for <dmm@ietf.org>; Fri, 20 Mar 2015 03:12:57 -0700 (PDT)
Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail21.telekom.de with ESMTP; 20 Mar 2015 11:12:55 +0100
X-IronPort-AV: E=Sophos;i="5.11,435,1422918000";  d="scan'208,217";a="231808242"
Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 20 Mar 2015 11:12:54 +0100
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 20 Mar 2015 11:12:53 +0100
From: <Dirk.von-Hugo@telekom.de>
To: <alper.yegin@yegin.org>
Date: Fri, 20 Mar 2015 11:12:46 +0100
Thread-Topic: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
Thread-Index: AdBiby+TuG1nOvReR8+Ilz8CqgNmvAAhkipQ
Message-ID: <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com>
References: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org> <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> <F2794365-90B2-4AD7-931C-A13C1D14AD7B@yegin.org>
In-Reply-To: <F2794365-90B2-4AD7-931C-A13C1D14AD7B@yegin.org>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/hn6tiyq9tnkw7ppdGRRSev54Lks>
Cc: dmm@ietf.org
Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2015 10:13:06 -0000

--_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Alper,
Ok, thanks!
Regarding
More than one of these flags may be set on the same socket.  In that
   case, an IP address compliant with any one of them shall be selected.
   TBD: Disallow this case?
Since here we have requirements instead of preferences unavailability of th=
e required address type would force configuration of compliant address - bu=
t some applications can accept several types (for different planes CP/DP or=
 with different priority). Question is what would be the additional effort =
for forced configuration vs. gain by 'more optimal' performance?
My guess: allow, but introduce priority for selection



Where should the priority come from? The spec shall state it?

I think the application should be able to decide on the priority, and the s=
pec includes a corresponding option with values to pick from (for the time =
being only 3-level priority needed ... unless there should be room for late=
r update with more refined types)

Best Regards
Dirk

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Donnerstag, 19. M=E4rz 2015 19:04
To: von Hugo, Dirk
Cc: dmm@ietf.org
Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

Hello Dirk,

Thanks for the comments.
Please see below.

On Mar 19, 2015, at 7:09 PM, <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo=
@telekom.de>> wrote:


Dear Alper and co-authors,
Thanks for your work!
IMO the draft is clearly written and ready for adoption though some questio=
ns and comments came to my mind:

In the Intro Mobile IP is referenced to both client and Proxy MIP
In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
- but in the remaining PMIP functional elements (MAG, LMA) are never mentio=
ned ... silly question: so do you propose to apply the solution only to cli=
ent MIP based approaches or do you implicitly assume for mobility unaware h=
osts/devices that the IP stack on MAG is addressed instead? I suggest to ad=
d a clarification in the beginning ...

API applies to both CMIP and PMIP hosts.
We don't mention MAG or LMA, as those details are not related to the "API".





P.4:
   A sustained IP address may be configured and maintained by using
   access network anchoring, corresponding network anchoring, or some
   other solution.
I suggest to add a reference here (RFC7429 defining Anchoring Function) or =
explain with "allocating to a mobile node an IP
       address analogous to CoA at FA in MIP by selecting an anchor router =
for relaying the traffic" or similar ...

Very good idea, will do.



P.5:
Applications running as servers at a published IP address require a
   Fixed IP Address.  Long-standing applications (e.g., an SSH session)
   may also require this type of address.  Those applications could use
   a Sustained IP Address, but that can produce sub-optimal results if
   the mobile host ends up far from the anchor gateway.
The latter sentence sounds to me as such sub-optimality will  not happen in=
 case of Fixed IP Address - isn't it even worse when the host already start=
s far from the centrally-located Home Network ...?


Right, it can be..... But depending on the deployment, a centralized HA may=
 be in a better position to serve long sessions than an AR at the edge (bec=
ause of scalability, and also funneling traffic "in&out" may not suit the A=
R well, as its uplink may not be provisioned with enough capacity).
Anyways, we should massage the text, .. will propose something.


then the IP stack shall fail the associated socket request.
=3D> then the IP stack shall fail to fulfil/meet/comply with the associated=
 socket request.
P.6:
   - Determination of a default address type when an application does
   not make any explicit indication, whether it already supports the
   required API or it is just a legacy application.
Do you refer here to the below mentioned  Socket API-based interface ... [R=
FC5014]?
Otherwise I suggest to add some explanatory words on the required API.

We are referring to the API we are defining in this I-D. Will clarify in th=
e text.




P.7:
More than one of these flags may be set on the same socket.  In that
   case, an IP address compliant with any one of them shall be selected.
   TBD: Disallow this case?
Since here we have requirements instead of preferences unavailability of th=
e required address type would force configuration of compliant address - bu=
t some applications can accept several types (for different planes CP/DP or=
 with different priority). Question is what would be the additional effort =
for forced configuration vs. gain by 'more optimal' performance?
My guess: allow, but introduce priority for selection



Where should the priority come from? The spec shall state it?


In addition few nits detected:
P.2:
   despite the mobile host chaging its point of attachment within the IP
=3D>   despite the mobile host changing its point of attachment within the =
IP
P.3:
   session continuity and IP address reachability should be be provided
=3D>   session continuity and IP address reachability should be provided
P.4:
   The mobile host is configures a HoA from a centrally-located Home
=3D>   The mobile host configures a HoA from a centrally-located Home
Thanks!

Thank you!

Alper



Best Regards
Dirk


From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Mittwoch, 18. M=E4rz 2015 10:54
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03

Hello DMM WG members,

As you remember, WT#1 came to an agreement to propose the following I-D as =
the baseline for the API piece:

http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt

We'll be proposing its adoption in Dallas.

FYI, and here's your chance to voice any input in advance.

Cheers,

Alper




--_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 14 (filtered medium)"><base href=3D"x-msg://2448/"><style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Alper,=
<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;=
font-family:"Calibri","sans-serif";color:#1F497D'>Ok, thanks!<o:p></o:p></s=
pan></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif";color:#1F497D'>Regarding<o:p></o:p></span></p><p class=
=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>Mor=
e than one of these flags may be set on the same socket.&nbsp; In that</spa=
n><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-=
family:"Courier New"'>&nbsp;&nbsp; case, an IP address compliant with any o=
ne of them shall be selected.</span><o:p></o:p></p><p class=3DMsoNormal><sp=
an style=3D'font-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp;<span c=
lass=3Dapple-converted-space>&nbsp;</span><span style=3D'color:red'>TBD: Di=
sallow this case?</span></span><o:p></o:p></p><p class=3DMsoNormal style=3D=
'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial","=
sans-serif";color:#1F497D'>Since here we have requirements instead of prefe=
rences unavailability of the required address type would force configuratio=
n of compliant address &#8211; but some applications can accept several typ=
es (for different planes CP/DP or with different priority). Question is wha=
t would be the additional effort for forced configuration vs. gain by &#821=
6;more optimal&#8217; performance?</span><o:p></o:p></p><p class=3DMsoNorma=
l style=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-family=
:"Arial","sans-serif";color:#1F497D'>My guess: allow, but introduce priorit=
y for selection</span><o:p></o:p></p><p class=3DMsoNormal style=3D'margin-b=
ottom:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-seri=
f";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal><span st=
yle=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif"'><o:p>&nbsp;</=
o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorm=
al>Where should the priority come from? The spec shall state it?<br><br><sp=
an style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49=
7D'><o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think the applicati=
on should be able to decide on the priority, and the spec includes a corres=
ponding option with values to pick from (for the time being only 3-level pr=
iority needed &#8230; unless there should be room for later update with mor=
e refined types)<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'f=
ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbs=
p;</o:p></span></p><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:5.=
0pt;margin-right:0cm;margin-bottom:5.0pt;margin-left:0cm;text-autospace:non=
e'><span lang=3DDE style=3D'font-size:10.0pt;font-family:"Arial","sans-seri=
f";color:#1F497D'>Best Regards<br>Dirk </span><span lang=3DDE style=3D'font=
-size:11.0pt;color:#1F497D'><o:p></o:p></span></p></div><p class=3DMsoNorma=
l><span lang=3DDE style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style=3D'border:no=
ne;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMso=
Normal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"=
'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","san=
s-serif"'> Alper Yegin [mailto:alper.yegin@yegin.org] <br><b>Sent:</b> Donn=
erstag, 19. M=E4rz 2015 19:04<br><b>To:</b> von Hugo, Dirk<br><b>Cc:</b> dm=
m@ietf.org<br><b>Subject:</b> Re: [DMM] WG adoption for draft-yegin-ondeman=
d-mobility-03<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&n=
bsp;</o:p></p><p class=3DMsoNormal>Hello Dirk,<o:p></o:p></p><div><p class=
=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>Thanks fo=
r the comments.<o:p></o:p></p></div><div><p class=3DMsoNormal>Please see be=
low.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><di=
v><div><p class=3DMsoNormal>On Mar 19, 2015, at 7:09 PM, &lt;<a href=3D"mai=
lto:Dirk.von-Hugo@telekom.de">Dirk.von-Hugo@telekom.de</a>&gt; wrote:<o:p><=
/o:p></p></div><p class=3DMsoNormal><br><br><o:p></o:p></p><div><div><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-=
serif";color:#1F497D'>Dear Alper and co-authors,</span><o:p></o:p></p></div=
><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cal=
ibri","sans-serif";color:#1F497D'>Thanks for your work!</span><o:p></o:p></=
p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";color:#1F497D'>IMO the draft is clearly written a=
nd ready for adoption though some questions and comments came to my mind:</=
span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-siz=
e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:=
p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt=
;font-family:"Calibri","sans-serif";color:#1F497D'>In the Intro Mobile IP i=
s referenced to both client and Proxy MIP</span><o:p></o:p></p></div><div><=
p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier Ne=
w"'>In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],</span=
><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11=
.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&#8211; but in the r=
emaining PMIP functional elements (MAG, LMA) are never mentioned &#8230; si=
lly question: so do you propose to apply the solution only to client MIP ba=
sed approaches or do you implicitly assume for mobility unaware hosts/devic=
es that the IP stack on MAG is addressed instead? I suggest to add a clarif=
ication in the beginning &#8230;</span><o:p></o:p></p></div></div><div><p c=
lass=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>API a=
pplies to both CMIP and PMIP hosts.<o:p></o:p></p></div><div><p class=3DMso=
Normal>We don't mention MAG or LMA, as those details are not related to the=
 &quot;API&quot;.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;=
</o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p cla=
ss=3DMsoNormal><br><br><o:p></o:p></p><div><div><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>&nbsp;</span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D=
'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>P.4:</s=
pan><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-size=
:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; A sustained IP address may =
be configured and maintained by using</span><o:p></o:p></p></div><div><p cl=
ass=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>=
&nbsp;&nbsp; access network anchoring, corresponding network anchoring, or =
some</span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; other solution.</spa=
n><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-size:1=
1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I suggest to add a =
reference here (RFC7429 defining Anchoring Function) or explain with &#8220=
;allocating to a mobile node an IP</span><o:p></o:p></p></div><div><p class=
=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-se=
rif";color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; address analogous =
to CoA at FA in MIP by selecting an anchor router for relaying the traffic&=
#8221; or similar &#8230;</span><o:p></o:p></p></div></div><div><p class=3D=
MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>Very good id=
ea, will do.<o:p></o:p></p></div><p class=3DMsoNormal><br><br><o:p></o:p></=
p><div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil=
y:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p></div><=
div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calib=
ri","sans-serif";color:#1F497D'>P.5:</span><o:p></o:p></p></div><div><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>A=
pplications running as servers at a published IP address require a</span><o=
:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Courier New"'>&nbsp;&nbsp; Fixed IP Address.&nbsp; Long-stan=
ding applications (e.g., an SSH session)</span><o:p></o:p></p></div><div><p=
 class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New=
"'>&nbsp;&nbsp; may also require this type of address.&nbsp;<span class=3Da=
pple-converted-space>&nbsp;</span><span style=3D'color:red'>Those applicati=
ons could use</span></span><o:p></o:p></p></div><div><p class=3DMsoNormal><=
span style=3D'font-size:11.0pt;font-family:"Courier New";color:red'>&nbsp;&=
nbsp; a Sustained IP Address, but that can produce sub-optimal results if</=
span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'font-siz=
e:11.0pt;font-family:"Courier New";color:red'>&nbsp;&nbsp; the mobile host =
ends up far from the anchor gateway</span><span style=3D'font-size:11.0pt;f=
ont-family:"Courier New"'>.</span><o:p></o:p></p></div><div><p class=3DMsoN=
ormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";co=
lor:#1F497D'>The latter sentence sounds to me as such sub-optimality will &=
nbsp;not happen in case of Fixed IP Address &#8211; isn&#8217;t it even wor=
se when the host already starts far from the centrally-located Home Network=
 &#8230;?</span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=
=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbs=
p;</span><o:p></o:p></p></div></div><div><p class=3DMsoNormal><o:p>&nbsp;</=
o:p></p></div><div><p class=3DMsoNormal>Right, it can be&#8230;.. But depen=
ding on the deployment, a centralized HA may be in a better position to ser=
ve long sessions than an AR at the edge (because of scalability, and also f=
unneling traffic &quot;in&amp;out&quot; may not suit the AR well, as its up=
link may not be provisioned with enough capacity).&nbsp;<o:p></o:p></p></di=
v><div><p class=3DMsoNormal>Anyways, we should massage the text, .. will pr=
opose something.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;<=
/o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><blockq=
uote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>then the=
 IP stack shall fail the associated socket request.&nbsp;</span><o:p></o:p>=
</p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fa=
mily:"Courier New"'>=3D&gt; then the IP stack shall fail<span class=3Dapple=
-converted-space>&nbsp;</span><span style=3D'color:red'>to fulfil/meet/comp=
ly with<span class=3Dapple-converted-space>&nbsp;</span></span>the associat=
ed socket request.&nbsp;</span><o:p></o:p></p></div><div><p class=3DMsoNorm=
al style=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-famil=
y:"Arial","sans-serif";color:#1F497D'>P.6:</span><o:p></o:p></p><div><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>&=
nbsp;&nbsp; - Determination of a default address type when an application d=
oes</span><o:p></o:p></p></div><div><p class=3DMsoNormal><span style=3D'fon=
t-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; not make any explicit=
 indication, whether<span class=3Dapple-converted-space>&nbsp;</span><span =
style=3D'color:red'>it already supports the</span></span><o:p></o:p></p></d=
iv><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"C=
ourier New";color:red'>&nbsp;&nbsp; required API<span class=3Dapple-convert=
ed-space>&nbsp;</span></span><span style=3D'font-size:11.0pt;font-family:"C=
ourier New"'>or it is just a legacy application.</span><o:p></o:p></p></div=
><p class=3DMsoNormal style=3D'margin-bottom:5.0pt'><span style=3D'font-siz=
e:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Do you refer here =
to the below mentioned &nbsp;</span><span style=3D'font-size:11.0pt;font-fa=
mily:"Courier New"'>Socket API-based interface &#8230; [RFC5014]?</span><o:=
p></o:p></p><p class=3DMsoNormal style=3D'margin-bottom:5.0pt'><span style=
=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Otherw=
ise I suggest to add some explanatory words on the required API.</span><o:p=
></o:p></p></div></div></blockquote><div><p class=3DMsoNormal><o:p>&nbsp;</=
o:p></p></div><div><p class=3DMsoNormal>We are referring to the API we are =
defining in this I-D. Will clarify in the text.<o:p></o:p></p></div><div><p=
 class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p class=3DMsoNormal><br><br>=
<o:p></o:p></p><div><div><p class=3DMsoNormal style=3D'margin-bottom:5.0pt'=
><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F=
497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal style=3D'margin-bott=
om:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";=
color:#1F497D'>P.7:</span><o:p></o:p></p><div><p class=3DMsoNormal><span st=
yle=3D'font-size:11.0pt;font-family:"Courier New"'>More than one of these f=
lags may be set on the same socket.&nbsp; In that</span><o:p></o:p></p></di=
v><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Co=
urier New"'>&nbsp;&nbsp; case, an IP address compliant with any one of them=
 shall be selected.</span><o:p></o:p></p></div><div><p class=3DMsoNormal><s=
pan style=3D'font-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp;<span =
class=3Dapple-converted-space>&nbsp;</span><span style=3D'color:red'>TBD: D=
isallow this case?</span></span><o:p></o:p></p></div><p class=3DMsoNormal s=
tyle=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-family:"A=
rial","sans-serif";color:#1F497D'>Since here we have requirements instead o=
f preferences unavailability of the required address type would force confi=
guration of compliant address &#8211; but some applications can accept seve=
ral types (for different planes CP/DP or with different priority). Question=
 is what would be the additional effort for forced configuration vs. gain b=
y &#8216;more optimal&#8217; performance?</span><o:p></o:p></p><p class=3DM=
soNormal style=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font=
-family:"Arial","sans-serif";color:#1F497D'>My guess: allow, but introduce =
priority for selection</span><o:p></o:p></p><p class=3DMsoNormal style=3D'm=
argin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial","sa=
ns-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><div><p class=3DMsoNor=
mal><span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif"'><=
o:p>&nbsp;</o:p></span></p></div></div></div><div><p class=3DMsoNormal><o:p=
>&nbsp;</o:p></p></div><p class=3DMsoNormal>Where should the priority come =
from? The spec shall state it?<br><br><br><o:p></o:p></p><div><div><p class=
=3DMsoNormal style=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;=
font-family:"Arial","sans-serif";color:#1F497D'>In addition few nits detect=
ed:</span><o:p></o:p></p><p class=3DMsoNormal style=3D'margin-bottom:5.0pt'=
><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F=
497D'>P.2:</span><o:p></o:p></p><div><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; despite the mobile h=
ost chaging its point of attachment within the IP</span><o:p></o:p></p></di=
v><div><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:=
"Arial","sans-serif";color:#1F497D'>=3D&gt;</span></b><span style=3D'font-s=
ize:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; despite the mobile host =
cha<span style=3D'color:red'>n</span>ging its point of attachment within th=
e IP</span><o:p></o:p></p></div><p class=3DMsoNormal style=3D'margin-bottom=
:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";co=
lor:#1F497D'>P.3:</span><o:p></o:p></p><div><p class=3DMsoNormal><span styl=
e=3D'font-size:11.0pt;font-family:"Courier New"'>&nbsp;&nbsp; session conti=
nuity and IP address reachability should<span class=3Dapple-converted-space=
>&nbsp;</span><span style=3D'color:red'>be<span class=3Dapple-converted-spa=
ce>&nbsp;</span></span>be provided</span><o:p></o:p></p></div><div><p class=
=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","sans-seri=
f";color:#1F497D'>=3D&gt;</span><span style=3D'font-size:11.0pt;font-family=
:"Courier New"'>&nbsp;&nbsp; session continuity and IP address reachability=
 should be provided</span><o:p></o:p></p></div><p class=3DMsoNormal style=
=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-family:"Arial=
","sans-serif";color:#1F497D'>P.4:</span><o:p></o:p></p><div><p class=3DMso=
Normal><span style=3D'font-size:11.0pt;font-family:"Courier New"'>&nbsp;&nb=
sp; The mobile host<span class=3Dapple-converted-space>&nbsp;</span><span s=
tyle=3D'color:red'>is</span><span class=3Dapple-converted-space>&nbsp;</spa=
n>configures a HoA from a centrally-located Home</span><o:p></o:p></p></div=
><div><p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Ari=
al","sans-serif";color:#1F497D'>=3D&gt;</span><span style=3D'font-size:11.0=
pt;font-family:"Courier New"'>&nbsp;&nbsp; The mobile host configures a HoA=
 from a centrally-located Home</span><o:p></o:p></p></div><p class=3DMsoNor=
mal style=3D'margin-bottom:5.0pt'><span style=3D'font-size:10.0pt;font-fami=
ly:"Arial","sans-serif";color:#1F497D'>Thanks!</span><o:p></o:p></p></div><=
/div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DM=
soNormal>Thank you!<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbs=
p;</o:p></p></div><div><p class=3DMsoNormal>Alper<o:p></o:p></p></div><div>=
<p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p class=3DMsoNormal><br><b=
r><o:p></o:p></p><div><div><p class=3DMsoNormal style=3D'margin-bottom:5.0p=
t'><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#=
1F497D'>Best Regards<br>Dirk</span><o:p></o:p></p><div><p class=3DMsoNormal=
><span style=3D'font-size:11.0pt;color:#1F497D'>&nbsp;</span><o:p></o:p></p=
></div></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font=
-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><=
/div><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:=
3.0pt 0cm 0cm 0cm;border-width:initial;border-color:initial'><div><p class=
=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-=
serif"'>From:</span></b><span class=3Dapple-converted-space><span style=3D'=
font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><sp=
an style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>dmm [<a hre=
f=3D"mailto:dmm-bounces@ietf.org">mailto:dmm-bounces@ietf.org</a>]<span cla=
ss=3Dapple-converted-space>&nbsp;</span><b>On Behalf Of<span class=3Dapple-=
converted-space>&nbsp;</span></b>Alper Yegin<br><b>Sent:</b><span class=3Da=
pple-converted-space>&nbsp;</span>Mittwoch, 18. M=E4rz 2015 10:54<br><b>To:=
</b><span class=3Dapple-converted-space>&nbsp;</span><a href=3D"mailto:dmm@=
ietf.org">dmm@ietf.org</a><br><b>Subject:</b><span class=3Dapple-converted-=
space>&nbsp;</span>[DMM] WG adoption for draft-yegin-ondemand-mobility-03</=
span><o:p></o:p></p></div></div></div><div><p class=3DMsoNormal>&nbsp;<o:p>=
</o:p></p></div><div><div><p class=3DMsoNormal>Hello DMM WG members,<o:p></=
o:p></p></div></div><div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></d=
iv></div><div><div><p class=3DMsoNormal>As you remember, WT#1 came to an ag=
reement to propose the following I-D as the baseline for the API piece:<o:p=
></o:p></p></div></div><div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p>=
</div></div><div><p class=3DMsoNormal><a href=3D"http://www.ietf.org/id/dra=
ft-yegin-dmm-ondemand-mobility-03.txt">http://www.ietf.org/id/draft-yegin-d=
mm-ondemand-mobility-03.txt</a><o:p></o:p></p></div><div><div><p class=3DMs=
oNormal>&nbsp;<o:p></o:p></p></div></div><div><div><p class=3DMsoNormal>We'=
ll be proposing its adoption in Dallas.<o:p></o:p></p></div></div><div><div=
><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div></div><div><div><p class=
=3DMsoNormal>FYI, and here's your chance to voice any input in advance.<o:p=
></o:p></p></div></div><div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p>=
</div></div><div><div><p class=3DMsoNormal>Cheers,<o:p></o:p></p></div></di=
v><div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div></div><div><div=
><p class=3DMsoNormal>Alper<o:p></o:p></p></div></div><div><div><p class=3D=
MsoNormal>&nbsp;<o:p></o:p></p></div></div><div><div><p class=3DMsoNormal>&=
nbsp;<o:p></o:p></p></div></div></div></div><p class=3DMsoNormal><o:p>&nbsp=
;</o:p></p></div></div></body></html>=

--_000_05C81A773E48DD49B181B04BA21A342A2FC04EDDA0HE113484emea1_--


From nobody Fri Mar 20 06:54:12 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2A1B2DBA for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2015 06:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-qkMmYptmc7 for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2015 06:54:05 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2B21B2DB2 for <dmm@ietf.org>; Fri, 20 Mar 2015 06:54:05 -0700 (PDT)
Received: from [10.119.24.3] ([173.245.80.44]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MbQwc-1YpWHh2sAG-00Iof0; Fri, 20 Mar 2015 14:54:00 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com>
Date: Fri, 20 Mar 2015 15:53:54 +0200
Message-Id: <E2C95F6C-54D4-4BEB-99F5-95D4FD3653EB@yegin.org>
References: <F123AD9E-36C8-4C27-9FC3-AAFC34AE628B@yegin.org> <05C81A773E48DD49B181B04BA21A342A2FC04310ED@HE113484.emea1.cds.t-internal.com> <F2794365-90B2-4AD7-931C-A13C1D14AD7B@yegin.org> <05C81A773E48DD49B181B04BA21A342A2FC04EDDA0@HE113484.emea1.cds.t-internal.com>
To: <Dirk.von-Hugo@telekom.de>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:VrSyEXC3CpHylk2l5HXO3yVlMmiWOSJ/4nscjm5M9iVCs4wUzCE Ln6SsHpUoVgZ2QmQOzcLarzvAQKOSIa1AZcz8AzLi1JlVadf8AWmDu/r1/EUlTJtROiUDZV 9p22zTb0d3ptwpvAUyC7taccPkPx7BJsHBFde8C4btSdfpRbt5j0UiLrEeetLQFCJz7QJyR Y6ng0OhZhB9Rem/EBWjPw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/5KiRewnkTDfdasQPMUn0kM5qzLU>
Cc: dmm@ietf.org
Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2015 13:54:09 -0000

--Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi Dirk,

I think we need to look at some example scenarios to see how common this =
case would be.
If this additional logic is used rarely, then it may not be worth =
burdening the API with it.

Alper



On Mar 20, 2015, at 12:12 PM, <Dirk.von-Hugo@telekom.de> wrote:

> Hi Alper,
> Ok, thanks!
> Regarding
> More than one of these flags may be set on the same socket.  In that
>    case, an IP address compliant with any one of them shall be =
selected.
>    TBD: Disallow this case?
> Since here we have requirements instead of preferences unavailability =
of the required address type would force configuration of compliant =
address =96 but some applications can accept several types (for =
different planes CP/DP or with different priority). Question is what =
would be the additional effort for forced configuration vs. gain by =
=91more optimal=92 performance?
> My guess: allow, but introduce priority for selection
> =20
> =20
> =20
> Where should the priority come from? The spec shall state it?
>=20
> I think the application should be able to decide on the priority, and =
the spec includes a corresponding option with values to pick from (for =
the time being only 3-level priority needed =85 unless there should be =
room for later update with more refined types)
> =20
> Best Regards
> Dirk
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Donnerstag, 19. M=E4rz 2015 19:04
> To: von Hugo, Dirk
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
> =20
> Hello Dirk,
> =20
> Thanks for the comments.
> Please see below.
> =20
> On Mar 19, 2015, at 7:09 PM, <Dirk.von-Hugo@telekom.de> wrote:
>=20
>=20
> Dear Alper and co-authors,
> Thanks for your work!
> IMO the draft is clearly written and ready for adoption though some =
questions and comments came to my mind:
> =20
> In the Intro Mobile IP is referenced to both client and Proxy MIP
> In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944],
> =96 but in the remaining PMIP functional elements (MAG, LMA) are never =
mentioned =85 silly question: so do you propose to apply the solution =
only to client MIP based approaches or do you implicitly assume for =
mobility unaware hosts/devices that the IP stack on MAG is addressed =
instead? I suggest to add a clarification in the beginning =85
> =20
> API applies to both CMIP and PMIP hosts.
> We don't mention MAG or LMA, as those details are not related to the =
"API".
> =20
> =20
>=20
>=20
> =20
> P.4:
>    A sustained IP address may be configured and maintained by using
>    access network anchoring, corresponding network anchoring, or some
>    other solution.
> I suggest to add a reference here (RFC7429 defining Anchoring =
Function) or explain with =93allocating to a mobile node an IP
>        address analogous to CoA at FA in MIP by selecting an anchor =
router for relaying the traffic=94 or similar =85
> =20
> Very good idea, will do.
>=20
>=20
> =20
> P.5:
> Applications running as servers at a published IP address require a
>    Fixed IP Address.  Long-standing applications (e.g., an SSH =
session)
>    may also require this type of address.  Those applications could =
use
>    a Sustained IP Address, but that can produce sub-optimal results if
>    the mobile host ends up far from the anchor gateway.
> The latter sentence sounds to me as such sub-optimality will  not =
happen in case of Fixed IP Address =96 isn=92t it even worse when the =
host already starts far from the centrally-located Home Network =85?
> =20
> =20
> Right, it can be=85.. But depending on the deployment, a centralized =
HA may be in a better position to serve long sessions than an AR at the =
edge (because of scalability, and also funneling traffic "in&out" may =
not suit the AR well, as its uplink may not be provisioned with enough =
capacity).=20
> Anyways, we should massage the text, .. will propose something.
> =20
> =20
> then the IP stack shall fail the associated socket request.=20
> =3D> then the IP stack shall fail to fulfil/meet/comply with the =
associated socket request.=20
> P.6:
>    - Determination of a default address type when an application does
>    not make any explicit indication, whether it already supports the
>    required API or it is just a legacy application.
> Do you refer here to the below mentioned  Socket API-based interface =85=
 [RFC5014]?
> Otherwise I suggest to add some explanatory words on the required API.
> =20
> We are referring to the API we are defining in this I-D. Will clarify =
in the text.
> =20
>=20
>=20
> =20
> P.7:
> More than one of these flags may be set on the same socket.  In that
>    case, an IP address compliant with any one of them shall be =
selected.
>    TBD: Disallow this case?
> Since here we have requirements instead of preferences unavailability =
of the required address type would force configuration of compliant =
address =96 but some applications can accept several types (for =
different planes CP/DP or with different priority). Question is what =
would be the additional effort for forced configuration vs. gain by =
=91more optimal=92 performance?
> My guess: allow, but introduce priority for selection
> =20
> =20
> =20
> Where should the priority come from? The spec shall state it?
>=20
>=20
> In addition few nits detected:
> P.2:
>    despite the mobile host chaging its point of attachment within the =
IP
> =3D>   despite the mobile host changing its point of attachment within =
the IP
> P.3:
>    session continuity and IP address reachability should be be =
provided
> =3D>   session continuity and IP address reachability should be =
provided
> P.4:
>    The mobile host is configures a HoA from a centrally-located Home
> =3D>   The mobile host configures a HoA from a centrally-located Home
> Thanks!
> =20
> Thank you!
> =20
> Alper
> =20
>=20
>=20
> Best Regards
> Dirk
> =20
> =20
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
> Sent: Mittwoch, 18. M=E4rz 2015 10:54
> To: dmm@ietf.org
> Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03
> =20
> Hello DMM WG members,
> =20
> As you remember, WT#1 came to an agreement to propose the following =
I-D as the baseline for the API piece:
> =20
> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt
> =20
> We'll be proposing its adoption in Dallas.
> =20
> FYI, and here's your chance to voice any input in advance.
> =20
> Cheers,
> =20
> Alper
> =20
> =20


--Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href=3D"x-msg://2448/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">Hi Dirk,<div><br></div><div>I think we need to look =
at some example scenarios to see how common this case would =
be.</div><div>If this additional logic is used rarely, then it may not =
be worth burdening the API with =
it.</div><div><br></div><div>Alper</div><div><br></div><div><br></div><div=
><br><div><div>On Mar 20, 2015, at 12:12 PM, &lt;<a =
href=3D"mailto:Dirk.von-Hugo@telekom.de">Dirk.von-Hugo@telekom.de</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" =
style=3D"page: WordSection1; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Hi =
Alper,<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Ok, =
thanks!<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">Regarding<o:p></o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">More than one of these flags may be =
set on the same socket.&nbsp; In that</span><o:p></o:p></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; case, an IP address compliant with any one of them =
shall be selected.</span><o:p></o:p></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp;<span =
class=3D"apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">TBD: Disallow this case?</span></span><o:p></o:p></div><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); ">Since here we have =
requirements instead of preferences unavailability of the required =
address type would force configuration of compliant address =96 but some =
applications can accept several types (for different planes CP/DP or =
with different priority). Question is what would be the additional =
effort for forced configuration vs. gain by =91more optimal=92 =
performance?</span><o:p></o:p></p><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">My guess: allow, but introduce priority for =
selection</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">&nbsp;</span><o:p></o:p></p><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
13.5pt; font-family: Helvetica, sans-serif; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">Where should the priority come =
from? The spec shall state it?<br><br><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p></o:p></span></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I think the =
application should be able to decide on the priority, and the spec =
includes a corresponding option with values to pick from (for the time =
being only 3-level priority needed =85 unless there should be room for =
later update with more refined types)<o:p></o:p></span></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span lang=3D"DE" style=3D"font-size: 10pt; font-family: Arial, =
sans-serif; color: rgb(31, 73, 125); ">Best Regards<br>Dirk</span><span =
lang=3D"DE" style=3D"font-size: 11pt; color: rgb(31, 73, 125); =
"><o:p></o:p></span></p></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span lang=3D"DE" =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding-top: 3pt; padding-right: 0cm; =
padding-bottom: 0cm; padding-left: 0cm; "><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif; "><span class=3D"Apple-converted-space">&nbsp;</span>Alper =
Yegin [mailto:alper.yegin@yegin.org]<span =
class=3D"Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Donnerstag, 19. M=E4rz 2015 =
19:04<br><b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span>von =
Hugo, Dirk<br><b>Cc:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [DMM] WG adoption for =
draft-yegin-ondemand-mobility-03<o:p></o:p></span></div></div></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Hello =
Dirk,<o:p></o:p></div><div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Thanks for the =
comments.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Please see =
below.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">On Mar 19, 2015, at 7:09 =
PM, &lt;<a href=3D"mailto:Dirk.von-Hugo@telekom.de" style=3D"color: =
blue; text-decoration: underline; ">Dirk.von-Hugo@telekom.de</a>&gt; =
wrote:<o:p></o:p></div></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><br><br><o:p></o:p></div><div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Dear =
Alper and co-authors,</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">Thanks for your =
work!</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">IMO =
the draft is clearly written and ready for adoption though some =
questions and comments came to my =
mind:</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">In the Intro Mobile IP is referenced to both client =
and Proxy MIP</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">In the context =
of Mobile IP =
[RFC5563][RFC6275][RFC5213][RFC5944],</span><o:p></o:p></div></div><div><d=
iv style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">=96 but in the remaining PMIP =
functional elements (MAG, LMA) are never mentioned =85 silly question: =
so do you propose to apply the solution only to client MIP based =
approaches or do you implicitly assume for mobility unaware =
hosts/devices that the IP stack on MAG is addressed instead? I suggest =
to add a clarification in the beginning =
=85</span><o:p></o:p></div></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">API applies to both CMIP =
and PMIP hosts.<o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">We don't =
mention MAG or LMA, as those details are not related to the =
"API".<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><br><br><o:p></o:p></div><div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">P.4:</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; A sustained IP address may be configured and =
maintained by using</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; access network anchoring, corresponding network =
anchoring, or some</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; other =
solution.</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">I suggest to add a reference here (RFC7429 defining =
Anchoring Function) or explain with =93allocating to a mobile node an =
IP</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; address analogous to CoA at FA in =
MIP by selecting an anchor router for relaying the traffic=94 or similar =
=85</span><o:p></o:p></div></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Very good idea, will =
do.<o:p></o:p></div></div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; =
"><br><br><o:p></o:p></div><div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">P.5:</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">Applications running as servers at a published IP address =
require a</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
Fixed IP Address.&nbsp; Long-standing applications (e.g., an SSH =
session)</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; may =
also require this type of address.&nbsp;<span =
class=3D"apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">Those applications could =
use</span></span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; color: red; =
">&nbsp;&nbsp; a Sustained IP Address, but that can produce sub-optimal =
results if</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; color: red; =
">&nbsp;&nbsp; the mobile host ends up far from the anchor =
gateway</span><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">.</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">The latter sentence sounds to me as such =
sub-optimality will &nbsp;not happen in case of Fixed IP Address =96 =
isn=92t it even worse when the host already starts far from the =
centrally-located Home Network =85?</span><o:p></o:p></div></div><div><div=
 style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></div></div></div><div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Right, it can be=85.. But =
depending on the deployment, a centralized HA may be in a better =
position to serve long sessions than an AR at the edge (because of =
scalability, and also funneling traffic "in&amp;out" may not suit the AR =
well, as its uplink may not be provisioned with enough =
capacity).&nbsp;<o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">Anyways, we =
should massage the text, .. will propose =
something.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><blockquote style=3D"margin-top: 5pt; =
margin-bottom: 5pt; "><div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">then the IP stack shall fail the =
associated socket request.&nbsp;</span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">=3D&gt; then the IP stack shall fail<span =
class=3D"apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">to fulfil/meet/comply with<span =
class=3D"apple-converted-space">&nbsp;</span></span>the associated =
socket request.&nbsp;</span><o:p></o:p></div></div><div><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); =
">P.6:</span><o:p></o:p></p><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; - Determination of a =
default address type when an application =
does</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; not make any explicit =
indication, whether<span =
class=3D"apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">it already supports the</span></span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; color: red; ">&nbsp;&nbsp; required API<span =
class=3D"apple-converted-space">&nbsp;</span></span><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">or it is just a =
legacy application.</span><o:p></o:p></div></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Do you refer here to the below mentioned =
&nbsp;</span><span style=3D"font-size: 11pt; font-family: 'Courier New'; =
">Socket API-based interface =85 [RFC5014]?</span><o:p></o:p></p><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); ">Otherwise I suggest to add =
some explanatory words on the required =
API.</span><o:p></o:p></p></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">We are referring to the API we are defining in this =
I-D. Will clarify in the text.<o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><br><br><o:p></o:p></div><div><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">&nbsp;</span><o:p></o:p></p><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); =
">P.7:</span><o:p></o:p></p><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">More than one of these flags may be =
set on the same socket.&nbsp; In =
that</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; case, an IP address =
compliant with any one of them shall be =
selected.</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; =
">&nbsp;&nbsp;<span class=3D"apple-converted-space">&nbsp;</span><span =
style=3D"color: red; ">TBD: Disallow this =
case?</span></span><o:p></o:p></div></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Since here we have requirements instead of =
preferences unavailability of the required address type would force =
configuration of compliant address =96 but some applications can accept =
several types (for different planes CP/DP or with different priority). =
Question is what would be the additional effort for forced configuration =
vs. gain by =91more optimal=92 performance?</span><o:p></o:p></p><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); ">My guess: allow, but =
introduce priority for selection</span><o:p></o:p></p><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></p><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
13.5pt; font-family: Helvetica, sans-serif; =
"><o:p>&nbsp;</o:p></span></div></div></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">Where should =
the priority come from? The spec shall state =
it?<br><br><br><o:p></o:p></div><div><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">In addition few nits =
detected:</span><o:p></o:p></p><p class=3D"MsoNormal" style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 5pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">P.2:</span><o:p></o:p></p><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
despite the mobile host chaging its point of attachment within the =
IP</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">=3D&gt;</span></b><span style=3D"font-size: 11pt; =
font-family: 'Courier New'; ">&nbsp;&nbsp; despite the mobile host =
cha<span style=3D"color: red; ">n</span>ging its point of attachment =
within the IP</span><o:p></o:p></div></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">P.3:</span><o:p></o:p></p><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; session continuity and IP address reachability =
should<span class=3D"apple-converted-space">&nbsp;</span><span =
style=3D"color: red; ">be<span =
class=3D"apple-converted-space">&nbsp;</span></span>be =
provided</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(31, =
73, 125); ">=3D&gt;</span><span style=3D"font-size: 11pt; font-family: =
'Courier New'; ">&nbsp;&nbsp; session continuity and IP address =
reachability should be provided</span><o:p></o:p></div></div><p =
class=3D"MsoNormal" style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 5pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><span style=3D"font-size: 10pt; font-family: =
Arial, sans-serif; color: rgb(31, 73, 125); =
">P.4:</span><o:p></o:p></p><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: 'Courier New'; ">&nbsp;&nbsp; The mobile host<span =
class=3D"apple-converted-space">&nbsp;</span><span style=3D"color: red; =
">is</span><span class=3D"apple-converted-space">&nbsp;</span>configures =
a HoA from a centrally-located =
Home</span><o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">=3D&gt;</span><span style=3D"font-size: 11pt; font-family: 'Courier =
New'; ">&nbsp;&nbsp; The mobile host configures a HoA from a =
centrally-located Home</span><o:p></o:p></div></div><p class=3D"MsoNormal"=
 style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); =
">Thanks!</span><o:p></o:p></p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; ">Thank =
you!<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
">Alper<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><br><br><o:p></o:p></div><div><div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 5pt; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; font-family: Arial, sans-serif; =
color: rgb(31, 73, 125); ">Best =
Regards<br>Dirk</span><o:p></o:p></p><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; color: rgb(31, 73, 125); =
">&nbsp;</span><o:p></o:p></div></div></div><div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">&nbsp;</span><o:p></o:p></div></div><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; padding-top: 3pt; padding-right: 0cm; =
padding-bottom: 0cm; padding-left: 0cm; border-width: initial; =
border-color: initial; "><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">From:</span></b><span class=3D"apple-converted-space"><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">&nbsp;</span></span><span style=3D"font-size: 10pt; font-family: =
Tahoma, sans-serif; ">dmm [<a href=3D"mailto:dmm-bounces@ietf.org" =
style=3D"color: blue; text-decoration: underline; =
">mailto:dmm-bounces@ietf.org</a>]<span =
class=3D"apple-converted-space">&nbsp;</span><b>On Behalf Of<span =
class=3D"apple-converted-space">&nbsp;</span></b>Alper =
Yegin<br><b>Sent:</b><span =
class=3D"apple-converted-space">&nbsp;</span>Mittwoch, 18. M=E4rz 2015 =
10:54<br><b>To:</b><span class=3D"apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org" style=3D"color: blue; text-decoration: =
underline; ">dmm@ietf.org</a><br><b>Subject:</b><span =
class=3D"apple-converted-space">&nbsp;</span>[DMM] WG adoption for =
draft-yegin-ondemand-mobility-03</span><o:p></o:p></div></div></div></div>=
<div><div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">&nbsp;<o:p></o:p></div></div><div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">Hello DMM WG =
members,<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">As you =
remember, WT#1 came to an agreement to propose the following I-D as the =
baseline for the API piece:<o:p></o:p></div></div></div><div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; ">&nbsp;<o:p></o:p></div></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><a =
href=3D"http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt" =
style=3D"color: blue; text-decoration: underline; =
">http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt</a><o:p>=
</o:p></div></div><div><div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">We'll be =
proposing its adoption in =
Dallas.<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; ">FYI, and =
here's your chance to voice any input in =
advance.<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">Cheers,<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">Alper<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div></div></div><p class=3D"MsoNormal" =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; =
"></p></div></div></div></span></blockquote></div><br></div></body></html>=

--Apple-Mail=_631C609D-0BEB-45EC-90A4-5FB349680C73--


From nobody Tue Mar 24 09:25:19 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2721A8F3D for <dmm@ietfa.amsl.com>; Tue, 24 Mar 2015 09:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuMV3yGF4vua for <dmm@ietfa.amsl.com>; Tue, 24 Mar 2015 09:25:15 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142931A903F for <dmm@ietf.org>; Tue, 24 Mar 2015 09:25:13 -0700 (PDT)
Received: by wibgn9 with SMTP id gn9so2091407wib.1 for <dmm@ietf.org>; Tue, 24 Mar 2015 09:25:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:message-id:subject:mime-version:content-type; bh=BpOb+/TdwPb4MOhjZcUgc8VY/lS+R8dFZSgJxsSFEUU=; b=ceHfgsjHN6PUUb3N8sMH6j0rDAhwxOv0ZC6NI6oeIAOOhnUz6wT44mFPxuKra1QyHv mXUXKt2/YqYFD42iRX6ZEKtPjkNnavjuWTtnHMyosyiIRKsrsxCWRVEQHUkcyGyi3u50 w3+pqcwp/JKmhENfJ2xUVHk4X2FrhjqLuan9Ir1yuwXFG11vNUOuBgjyqxgxqkcFo0/u 09mAh8x5f8uKZLAFI/MU+1xW0liW1gVefdkoV4kXxDSEwDVE0ab1bW310IBRwN4oGvpu 3qFVAV8mMrNhf9YisygpLwtnfFMs0ShuVXqinsfMtvDMBu5af+bJ7XS0SiBZor7OsatR WkeQ==
X-Received: by 10.194.88.131 with SMTP id bg3mr9477647wjb.119.1427214311864; Tue, 24 Mar 2015 09:25:11 -0700 (PDT)
Received: from [2001:67c:370:160::] ([2001:67c:370:160:80bd:1cae:1156:410e]) by mx.google.com with ESMTPSA id a13sm6758183wjx.30.2015.03.24.09.25.10 for <dmm@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Mar 2015 09:25:11 -0700 (PDT)
Date: Tue, 24 Mar 2015 11:25:09 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: "=?utf-8?Q?dmm=40ietf.org?=" <dmm@ietf.org>
Message-ID: <E89A05BDAD134F42ABC941DE6D310BFD@gmail.com>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55118fe5_62a5d5bd_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/_zgoeysMdiJS2poBO5PrbRqUzWk>
Subject: [DMM] IETF92 agenda
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 16:25:17 -0000

--55118fe5_62a5d5bd_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Please note that the chairs have updated the agenda for Thursday session: https://www.ietf.org/proceedings/92/agenda/agenda-92-dmm

Thanks,
-- 
Dapeng Liu


--55118fe5_62a5d5bd_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>Please note that the chairs have updated the agenda =
for&nbsp;<span style=3D=22white-space: pre-wrap;=22>Thursday session</spa=
n>:&nbsp;<a href=3D=22https://www.ietf.org/proceedings/92/agenda/agenda-9=
2-dmm=22>https://www.ietf.org/proceedings/92/agenda/agenda-92-dmm</a></di=
v>
                <div><div><br></div><div>Thanks,</div><div>--&nbsp;</div>=
<div>Dapeng Liu</div><div><br></div><div></div></div>
            
--55118fe5_62a5d5bd_a9e--


From lyleb551144@gmail.com  Wed Mar 25 05:40:51 2015
Return-Path: <lyleb551144@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7531A8A79 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 05:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKSRwmHekpIk for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 05:40:50 -0700 (PDT)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F6E1ACEC5 for <dmm@ietf.org>; Wed, 25 Mar 2015 05:39:03 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so17985376obc.2 for <dmm@ietf.org>; Wed, 25 Mar 2015 05:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=dM2TRdNA1hVPLNfyEWYLc7OSj3hRWgksoBa4srcdyis=; b=GeU3a18Rq943Ad2CobpJ0eEE8muCtnlrfaxRhAqjEpXxkWWgR21Ey1PivrMtzwTF9i rApP67fkWiZV5UkWCioqWdvtlUqONkfWy70FiXu3fI3VGCaudl4fCeXdiAJrdwcW73h+ 7pFjPNUdaGzXcVoNMftRsWyfz2VM8gJ1uTacTsgwQTcn171RzIvryk0q88NxnRgEv0LQ uPMNklkNlLd2pKpqY1UF1a4wMA9gpve7CKgAsrqQpLOYvifIdCD42YjEpssbNzmv7PhV +NC1t5Usnv/mK3GeLXvl2OMSkMrnvjmi1fFeayDOc7rhVpqjmxMhciapd0t3tITCpCPb VYBw==
MIME-Version: 1.0
X-Received: by 10.60.63.39 with SMTP id d7mr7290250oes.72.1427287142764; Wed, 25 Mar 2015 05:39:02 -0700 (PDT)
Received: by 10.60.161.109 with HTTP; Wed, 25 Mar 2015 05:39:02 -0700 (PDT)
Date: Wed, 25 Mar 2015 07:39:02 -0500
Message-ID: <CAC5bAiYtGA3EOH4exXLeTtTatjdvUk10JHw09BjbeZN1eJ5ugw@mail.gmail.com>
From: Lyle Bertz <lyleb551144@gmail.com>
To: dmm@ietf.org
Content-Type: multipart/alternative; boundary=001a11c21ff023140c05121c2fa2
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/C83R8wHPVPZRD7658B95L98tlm4>
Subject: [DMM] Developer Usage of Socket Types as described in draft-yegin-dmm-ondemand-mobility
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 12:42:42 -0000

--001a11c21ff023140c05121c2fa2
Content-Type: text/plain; charset=UTF-8

A question was raised during the dmm session regarding whether a developer
would use the Socket options specified in the draft or even be aware of
them.  Mobile developers (Android and other OSes) are quite aware of not
only the network type but also the 'features' that can be requested.

Using Android as an example -
The basic networking tutorial exposes the developer to ways to check
connections and their types (
http://developer.android.com/training/basics/network-ops/managing.html).
The developer is also made aware of permissions requests and features of
the connection type during this and many other 'Getting Started' tutorials
one may find on the Internet.

The Android API permits a developer to request a feature using the
requestNetwork( request, operation) method.  The method is described
as "Request
a network to satisfy a set of NetworkCapabilities " which can be found here
-
http://developer.android.com/reference/android/net/NetworkCapabilities.html

Although many of these capabilities are merely network types you'll note a
few are sub-features or 'qualities' such as NOT_RESTRICTED (general use) or
NOT_METERED.

It is reasonable to assume that for Android the options specified in the
draft would be enumerated here if the developer wishes to manipulate it at
the application level or pass as socket options in the Android Socket API
which likely, in turn, calls the ConnectivityManager first and, upon
success, attempts to open the Socket.   Other operating systems in the
mobile space have similar features.

If security is an issue the OS provider can use their respective
application permissions frameworks to restrict the application's request.

I think the OSes have very good methods to accommodate the options as
described in the draft and developers have a good idea of how to or
discover how to use them.

Lyle

--001a11c21ff023140c05121c2fa2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">A question was raised during the dmm sess=
ion regarding whether a developer would use the Socket options specified in=
 the draft or even be aware of them.=C2=A0 Mobile developers (Android and o=
ther OSes) are quite aware of not only the network type but also the &#39;f=
eatures&#39; that can be requested. =C2=A0=C2=A0<div><br></div><div>Using A=
ndroid as an example -=C2=A0</div><div>The basic networking tutorial expose=
s the developer to ways to check connections and their types (<a href=3D"ht=
tp://developer.android.com/training/basics/network-ops/managing.html" targe=
t=3D"_blank">http://developer.android.com/training/basics/network-ops/manag=
ing.html</a>).=C2=A0 The developer is also made aware of permissions reques=
ts and features of the connection type during this and many other &#39;Gett=
ing Started&#39; tutorials one may find on the Internet.</div><div><br></di=
v><div>The Android API permits a developer to request a feature using the r=
equestNetwork( request, operation) method.=C2=A0 The method is described as=
 &quot;<span style=3D"font-family:Roboto,sans-serif;font-size:14px;line-hei=
ght:19px;background-color:rgb(249,249,249)">Request a network to satisfy a =
set of=C2=A0</span><span style=3D"line-height:14px;background-color:rgb(249=
,249,249)"><font face=3D"monospace">NetworkCapabilities</font></span><span =
style=3D"font-family:Roboto,sans-serif;font-size:14px;line-height:19px;back=
ground-color:rgb(249,249,249)">=C2=A0</span>&quot; which can be found here =
-=C2=A0<a href=3D"http://developer.android.com/reference/android/net/Networ=
kCapabilities.html" target=3D"_blank">http://developer.android.com/referenc=
e/android/net/NetworkCapabilities.html</a></div><div><br></div><div>Althoug=
h many of these capabilities are merely network types you&#39;ll note a few=
 are sub-features or &#39;qualities&#39; such as NOT_RESTRICTED (general us=
e) or NOT_METERED. =C2=A0</div><div><br></div><div>It is reasonable to assu=
me that for Android the options specified in the draft would be enumerated =
here if the developer wishes to manipulate it at the application level or p=
ass as socket options in the Android Socket API which likely, in turn, call=
s the ConnectivityManager first and, upon success, attempts to open the Soc=
ket. =C2=A0 Other operating systems in the mobile space have similar featur=
es. =C2=A0=C2=A0</div><div><br></div><div>If security is an issue the OS pr=
ovider can use their respective application permissions frameworks to restr=
ict the application&#39;s request.</div><div><br></div><div>I think the OSe=
s have very good methods to accommodate the options as described in the dra=
ft and developers have a good idea of how to or discover how to use them.</=
div><span><font color=3D"#888888"><div><br></div><div>Lyle</div><div><br></=
div></font></span></div></div>

--001a11c21ff023140c05121c2fa2--


From nobody Wed Mar 25 12:03:00 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15641A8999 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 12:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMJoDoN_WBgb for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 12:02:57 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EC81B2B63 for <dmm@ietf.org>; Wed, 25 Mar 2015 12:02:38 -0700 (PDT)
Received: from [10.119.8.8] ([67.230.161.148]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MThig-1Z1LeW2HXk-00QU0s; Wed, 25 Mar 2015 20:02:36 +0100
From: Alper Yegin <alper.yegin@yegin.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Mar 2015 21:02:35 +0200
Message-Id: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org>
To: Dapeng Liu <maxpassion@gmail.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:ucfA0XzJBG1n5t7H2M39+9TnVXpYkjWUuB31hL0GMV7CKD1eC9X 1exkIAFasdQ+spJ/7ZZI0X1tqC01xKKUTF+/CktjSDQ1XwqI/OKVmwgC+asrnYqueNg04bK BqoBaMuFrFjxStZ4WSu9Syw8fZOuPeP+a+3pw7h/G3J2MLpYEl/Iqo9PdCylP7i/onzoRYo b+LsYgs3Xyt3O1vky0cyg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/SY5k-TVXavNlISwGhHxbFU6v6no>
Cc: dmm@ietf.org
Subject: [DMM] DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 19:02:58 -0000

Hello Dapeng and Alex,

I hope you had a chance to digest our responses to your comments and =
questions about the API work.
If you have any remaining issues, please let us know over the email at =
your earliest convenience.
It'd be good if you can articulate them in detail.


Thanks.

Alper


From nobody Wed Mar 25 14:02:05 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7731A1B34 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 14:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level: 
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnYDoic4AmIK for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 14:02:02 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A21A8A9E for <dmm@ietf.org>; Wed, 25 Mar 2015 14:01:56 -0700 (PDT)
Received: by pdnc3 with SMTP id c3so40338630pdn.0 for <dmm@ietf.org>; Wed, 25 Mar 2015 14:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=NWw6WTUxXcYTUI0alHDtT+e+VQhePA1VjKmYur2JADc=; b=y/0fL9tL76ZlHsFcI1GAvptmZOucDDtxjaE65K/QMH/iZClVoFRQ20VNRovqUPBZuc OInW/hAWKV53rsK0r+3x+vxiZWsB2+ssCd0N9tDP++Vg0wk9oOXBC2O0QI40dBbmTRIS nFciT/mvzkGy2OZrUfNcGdM9QVkRREcFJ8PtaL4fYdLBOXz5FrDVMYo+n2eNSq36ksLi /IoXTpJHTCIRoarvBhUfAfGAgYsiPzcD5zRuaOVWF0FB1jczPfrTehA0lW3+N29ANCXq nmg/HC9nNnfmuaujXQ/a7nRCuMinoV625FoZFWMdlxCIn9y+TbhVDWd+ojMa2+meMJLD eDVg==
X-Received: by 10.66.141.109 with SMTP id rn13mr20223041pab.113.1427317316586;  Wed, 25 Mar 2015 14:01:56 -0700 (PDT)
Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id jy9sm3344394pbc.31.2015.03.25.14.01.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 14:01:52 -0700 (PDT)
Date: Wed, 25 Mar 2015 16:01:45 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com>
In-Reply-To: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55132239_2357e574_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/16eWTJU8GRXXXd3wfVOBJTN-izw>
Cc: dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 21:02:04 -0000

--55132239_2357e574_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Alper, =20

I still have the following comments:

1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in the =
draft:

  =E2=80=9C- =46ixed IP Address
This is what standard Mobile IP provides with a Home Address (HoA). The m=
obile host is configures a HoA from a centrally-located Home Network. Bot=
h IP session continuity and IP address reachability are provided to the m=
obile host with the help of a router in the Home Network (Home Agent, HA)=
. This router acts as an anchor for the IP =20
address of the mobile host.=E2=80=9D =20

If this is equal to HoA, then R=46C5014 already cover that. We do not nee=
d to repeat it here with another name.

2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in =
the draft:

=22- Sustained IP Address This type of IP address provides IP session con=
tinuity but not IP address reachability. It is achieved by ensuring that =
the IP address used at the beginning of the session remains usable despit=
e the movement of the mobile host. The IP address may change after the te=
rmination of the IP session(s), therefore it does not exhibit persistence=
. =22 =20
There is no clear dividing line between fixed IP address and sustained IP=
 address. Whether the IP address is used for reachability is not determin=
ed by the IP address itself. =46or example, even when the MN get a HoA, a=
fter it moves to another location of the network, it may decide to releas=
e current HoA and get another HoA, in this case the =22fixed IP address=22=
 becomes a =22sustained IP address=22.

=46urther more, the reachability normally is implemented by domain name i=
nstead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80=9D by=
 its domain name, never by it=E2=80=99s server=E2=80=99s IP address. =20

Using temporary private IP address we can also achieve the goal of =E2=80=
=9Creachability=E2=80=9D. =46or example, using dynamic DNS, as shown in  =
http://hsk.oray.com/ , it can  provide reachability even the host get a p=
rivate IP address.

3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:

=E2=80=9C- Nomadic IP Address
This type of IP address provides neither IP session continuity nor IP add=
ress reachability. The IP address is obtained from the serving IP gateway=
 and it is not maintained across gateway changes. In other words, the IP =
address may be released and replaced by a new IP address when the IP gate=
way changes due to the movement of the mobile =20
host.=E2=80=9D

Seems this IP address is the IP address that we normally used in most cas=
es. If this is the case, why we need a new name for it=3F


-- =20
Dapeng Liu


=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=
=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> Hello Dapeng and Alex,
> =20
> I hope you had a chance to digest our responses to your comments and qu=
estions about the API work.
> If you have any remaining issues, please let us know over the email at =
your earliest convenience.
> It'd be good if you can articulate them in detail.
> =20
> =20
> Thanks.
> =20
> Alper =20


--55132239_2357e574_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>
                    Hello Alper,
                </div><div><br></div><div>I still have the following comm=
ents:</div><div><br></div><div>1. Regarding the definition of =E2=80=9Cfi=
xed IP address=E2=80=9D in the draft:</div><div><br></div><div>&nbsp; =E2=
=80=9C<span style=3D=22font-size: 1em; white-space: pre-wrap; widows: 1;=22=
>- =46ixed IP Address</span></div><pre class=3D=22newpage=22 style=3D=22f=
ont-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: al=
ways; widows: 1;=22>   This is what standard Mobile IP provides with a Ho=
me Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nb=
sp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; wid=
ows: 1;=22>   address of the mobile host.</span>=E2=80=9D&nbsp;</div><div=
><br></div><div>If this is equal to HoA, then R=46C5014 already cover tha=
t. We do not need to repeat it here with another name.</div><div><br></di=
v><div>2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=
=9D in the draft:</div><div><br></div><div><pre class=3D=22newpage=22 sty=
le=3D=22font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-b=
efore: always; widows: 1;=22>=22- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
=22</pre></div>
                <div><div>There is no clear dividing line between fixed I=
P address and sustained IP address. Whether the IP address is used for re=
achability is not determined by the IP address itself. =46or example, eve=
n when the MN get a HoA, after it moves to another location of the networ=
k, it may decide to release current HoA and get another HoA, in this case=
 the =22fixed IP address=22 becomes a =22sustained IP address=22.</div><d=
iv><br></div><div>=46urther more, the reachability normally is implemente=
d by domain name instead of IP address. =46or example, we reach =E2=80=9C=
Google=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99=
s IP address.&nbsp;</div><div><br></div><div>Using&nbsp;temporary private=
 IP address we can also achieve the goal of =E2=80=9Creachability=E2=80=9D=
. =46or example, using dynamic DNS, as shown in &nbsp;<a href=3D=22http:/=
/hsk.oray.com/=22>http://hsk.oray.com/</a>&nbsp;, it can &nbsp;provide re=
achability even the host get a private IP address.</div><div><br></div><d=
iv>3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:</=
div><div><br></div><div>=E2=80=9C<span style=3D=22font-size: 1em; white-s=
pace: pre-wrap; widows: 1;=22>- Nomadic IP Address</span></div><pre class=
=3D=22newpage=22 style=3D=22font-size: 1em; margin-top: 0px; margin-botto=
m: 0px; page-break-before: always; widows: 1;=22>   This type of IP addre=
ss provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&=
nbsp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; w=
idows: 1;=22>   host.</span>=E2=80=9D</div><div><br></div><div>Seems this=
 IP address is the IP address that we normally used in most cases. If thi=
s is the case, why we need a new name for it=3F</div><div><br></div><div>=
<br></div><div>--&nbsp;</div><div>Dapeng Liu</div><div><br></div><div></d=
iv></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=
=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div>Hello Dapeng and Alex,</div><div=
><br></div><div>I hope you had a chance to digest our responses to your c=
omments and questions about the API work.</div><div>If you have any remai=
ning issues, please let us know over the email at your earliest convenien=
ce.</div><div>It'd be good if you can articulate them in detail.</div><di=
v><br></div><div><br></div><div>Thanks.</div><div><br></div><div>Alper</d=
iv></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--55132239_2357e574_a9e--


From nobody Wed Mar 25 14:43:55 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CFA1A03C7 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 14:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC7LtVqUek3l for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 14:43:52 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3657A1A00D8 for <dmm@ietf.org>; Wed, 25 Mar 2015 14:43:52 -0700 (PDT)
Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lkyod-1ZB2qu09I5-00ad73; Wed, 25 Mar 2015 22:43:50 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <46D0D566CDBB4F7A8538B5346C84080B@gmail.com>
Date: Wed, 25 Mar 2015 23:43:46 +0200
Message-Id: <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com>
To: Dapeng Liu <maxpassion@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:sU7rgA7Mo+Q/L1Lfoyr36e6YtT8SHcSwo/n7wbsNuNdpCF6I6ef yV0xzChdAipaVpmyr3Lyky7g2a+QyT90aIz3TByBNjAad33peq8E7t2Q96jMz1ojtaNDqem n5U5l3xOQeNO2JP/Dbk6DVwCqqRUNoRcG7gE7k/uku3vSftV/0yOb9Eu+ixCcFG+WUikqZ+ skoONsEsfMNFyMtpEeG9Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/oUlD6hNtdrhwceSAC46RWmeC2OI>
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 21:43:54 -0000

--Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Dapeng,


On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote:

> Hello Alper,
>=20
> I still have the following comments:
>=20
> 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in =
the draft:
>=20
>   =E2=80=9C- Fixed IP Address
>    This is what standard Mobile IP provides with a Home Address (HoA).
>    The mobile host is configures a HoA from a centrally-located Home
>    Network.  Both IP session continuity and IP address reachability =
are
>    provided to the mobile host with the help of a router in the Home
>    Network (Home Agent, HA).  This router acts as an anchor for the IP=20=

>    address of the mobile host.=E2=80=9D=20
>=20
> If this is equal to HoA, then RFC5014 already cover that. We do not =
need to repeat it here with another name.
>=20


This is not equal to "HoA".
This is equal to "HoA permanently allocated on a HA in the core network"
(as opposed to "HoA temporarily allocated on a HA in the access =
network")


> 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D =
in the draft:
>=20
> "- Sustained IP Address
>=20
>    This type of IP address provides IP session continuity but not IP
>    address reachability.  It is achieved by ensuring that the IP =
address
>    used at the beginning of the session remains usable despite the
>    movement of the mobile host.  The IP address may change after the
>    termination of the IP session(s), therefore it does not exhibit
>    persistence.
> "
> There is no clear dividing line between fixed IP address and sustained =
IP address. Whether the IP address is used for reachability is not =
determined by the IP address itself. For example, even when the MN get a =
HoA, after it moves to another location of the network, it may decide to =
release current HoA and get another HoA, in this case the "fixed IP =
address" becomes a "sustained IP address".
>=20

If the IP stack on the host releases the IP address, then of course it's =
not a "fixed IP address".=20
Please see the definitions of these terms in the I-D.


> Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D by =
its domain name, never by it=E2=80=99s server=E2=80=99s IP address.=20
>=20
> Using temporary private IP address we can also achieve the goal of =
=E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as shown =
in  http://hsk.oray.com/ , it can  provide reachability even the host =
get a private IP address.
>=20

You had said this before, and I had explained it.
Nevertheless, let me recap:
You cannot ensure an ongoing IP flow continues w/o interruption if you =
simply rely on dynamic DNS. Ongoing flows break even if you update the =
DNS.
Furthermore, even if you ignore the ongoing flows, also note that DNS =
clients have a cache, hence a dynamic DNS update cannot be =
instantaneously reflected on the hosts.=20
So, you cannot provide full mobility solution by relying on dynamic DNS.


> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:
>=20
> =E2=80=9C- Nomadic IP Address
>    This type of IP address provides neither IP session continuity nor =
IP
>    address reachability.  The IP address is obtained from the serving =
IP
>    gateway and it is not maintained across gateway changes.  In other
>    words, the IP address may be released and replaced by a new IP
>    address when the IP gateway changes due to the movement of the =
mobile=20
>    host.=E2=80=9D
>=20
> Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?
>=20


If you don't name it, how would you refer to it in this context?


Alper


>=20
> --=20
> Dapeng Liu
>=20
> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =
=E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper =
Yegin =E5=86=99=E9=81=93=EF=BC=9A
>=20
>> Hello Dapeng and Alex,
>>=20
>> I hope you had a chance to digest our responses to your comments and =
questions about the API work.
>> If you have any remaining issues, please let us know over the email =
at your earliest convenience.
>> It'd be good if you can articulate them in detail.
>>=20
>>=20
>> Thanks.
>>=20
>> Alper
>=20


--Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello =
Dapeng,<div><br></div><div><br><div><div>On Mar 25, 2015, at 11:01 PM, =
Dapeng Liu wrote:</div><br class=3D"Apple-interchange-newline"><blockquote=
 type=3D"cite">
                <div>
                    Hello Alper,
                </div><div><br></div><div>I still have the following =
comments:</div><div><br></div><div>1. Regarding the definition of =
=E2=80=9Cfixed IP address=E2=80=9D in the =
draft:</div><div><br></div><div>&nbsp; =E2=80=9C<span style=3D"font-size: =
1em; white-space: pre-wrap; widows: 1;">- Fixed IP =
Address</span></div><pre class=3D"newpage" style=3D"font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always; widows: =
1;">   This is what standard Mobile IP provides with a Home Address =
(HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the =
IP&nbsp;</pre><div><span style=3D"font-size: 1em; white-space: pre-wrap; =
widows: 1;">   address of the mobile =
host.</span>=E2=80=9D&nbsp;</div><div><br></div><div>If this is equal to =
HoA, then RFC5014 already cover that. We do not need to repeat it here =
with another =
name.</div><div><br></div></blockquote><div><br></div><div><br></div><div>=
This is not equal to "HoA".</div><div>This is equal to "HoA permanently =
allocated on a HA in the core network"</div><div>(as opposed to "HoA =
temporarily allocated on a HA in the access =
network")</div><div><br></div><br><blockquote type=3D"cite"><div>2. =
Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in =
the draft:</div><div><br></div><div><pre class=3D"newpage" =
style=3D"font-size: 1em; margin-top: 0px; margin-bottom: 0px; =
page-break-before: always; widows: 1;">"- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
"</pre></div>
                <div><div>There is no clear dividing line between fixed =
IP address and sustained IP address. Whether the IP address is used for =
reachability is not determined by the IP address itself. For example, =
even when the MN get a HoA, after it moves to another location of the =
network, it may decide to release current HoA and get another HoA, in =
this case the "fixed IP address" becomes a "sustained IP =
address".</div><div><br></div></div></blockquote><div><br></div><div>If =
the IP stack on the host releases the IP address, then of course it's =
not a "fixed IP address".&nbsp;</div><div>Please see the definitions of =
these terms in the I-D.</div><div><br></div><div><br></div><blockquote =
type=3D"cite"><div><div>Further more, the reachability normally is =
implemented by domain name instead of IP address. For example, we reach =
=E2=80=9CGoogle=E2=80=9D by its domain name, never by it=E2=80=99s =
server=E2=80=99s IP =
address.&nbsp;</div><div><br></div></div></blockquote><blockquote =
type=3D"cite"><div><div>Using&nbsp;temporary private IP address we can =
also achieve the goal of =E2=80=9Creachability=E2=80=9D. For example, =
using dynamic DNS, as shown in &nbsp;<a =
href=3D"http://hsk.oray.com/">http://hsk.oray.com/</a>&nbsp;, it can =
&nbsp;provide reachability even the host get a private IP =
address.</div><div><br></div></div></blockquote><div><br></div><div>You =
had said this before, and I had explained it.</div><div>Nevertheless, =
let me recap:</div><div>You cannot ensure an ongoing IP flow continues =
w/o interruption if you simply rely on dynamic DNS. Ongoing flows break =
even if you update the DNS.</div><div>Furthermore, even if you ignore =
the ongoing flows, also note that DNS clients have a cache, hence a =
dynamic DNS update cannot be instantaneously reflected on the =
hosts.&nbsp;</div><div>So, you cannot provide full mobility solution by =
relying on dynamic DNS.</div><div><br></div><br><blockquote =
type=3D"cite"><div><div>3. Regarding the definition of =E2=80=9Cnomadic =
IP address=E2=80=9D:</div><div><br></div><div>=E2=80=9C<span =
style=3D"font-size: 1em; white-space: pre-wrap; widows: 1;">- Nomadic IP =
Address</span></div><pre class=3D"newpage" style=3D"font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always; widows: =
1;">   This type of IP address provides neither IP session continuity =
nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"font-size: 1em; white-space: =
pre-wrap; widows: 1;">   host.</span>=E2=80=9D</div><div><br></div><div>Se=
ems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for =
it?</div><div><br></div></div></blockquote><div><br></div><div><br></div><=
div>If you don't name it, how would you refer to it in this =
context?</div><div><br></div><div><br></div><div>Alper</div><div><br></div=
><br><blockquote =
type=3D"cite"><div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div><div></div></div><p style=3D"color: =
#A0A0A8;">=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =
=E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper =
Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;">
                    <span><div><div><div>Hello Dapeng and =
Alex,</div><div><br></div><div>I hope you had a chance to digest our =
responses to your comments and questions about the API =
work.</div><div>If you have any remaining issues, please let us know =
over the email at your earliest convenience.</div><div>It'd be good if =
you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            </blockquote></div><br></div></body></html>=

--Apple-Mail=_CE699CFF-3090-4B1A-8220-7EB1758B3AF8--


From nobody Wed Mar 25 15:27:28 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0CA1A1A72 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 15:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level: 
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSMj6L9mXL1w for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 15:27:24 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0E21A1A94 for <dmm@ietf.org>; Wed, 25 Mar 2015 15:27:22 -0700 (PDT)
Received: by wgs2 with SMTP id 2so44265552wgs.1 for <dmm@ietf.org>; Wed, 25 Mar 2015 15:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=dpyUaiK3T+6yOzsvVUnU0TRXxywgOpSSWurAVos/syo=; b=qIFpnfbwacY6Y5538yDXMD7NratS+V4jcqxLkymXx/iNumHoRt0iaCRKUbpO1u/cqi Y5/Gxj9Ed98HCy3s2uIs9sHaEHAEXevdnGs/CmSEPjU758NHUodf1liFHXaccAaHVWwR bkCs28hDO6QNtKVPEpsbUcuHudiVLIu+r9QoNJIwlsCOTQ3zdDt7k4KNgZaw0dzep0c4 v0/k4Z+aqCqQv1ZSGc5t3VHZPyKrdEQ1FwyrNglPs7q1eCbRwcBULA//et9Ja/mixDwT n0udzA2vYoPsiYXOoHX5Drq6QJZTm4t1VoHSIfDLtaxPYePRn8kW8AjHpp47G4FdeMlD zW7g==
X-Received: by 10.180.85.97 with SMTP id g1mr41353182wiz.17.1427322440945; Wed, 25 Mar 2015 15:27:20 -0700 (PDT)
Received: from [2001:67c:370:160::] ([2001:67c:370:160:f0fd:13ae:b935:34e8]) by mx.google.com with ESMTPSA id gj16sm6176921wic.24.2015.03.25.15.27.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 15:27:20 -0700 (PDT)
Date: Wed, 25 Mar 2015 17:27:16 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <16D77D43C73143B9A76C580ECBA39A87@gmail.com>
In-Reply-To: <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55133644_69dffc_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/NZTnAxsfbTHS_56uQBOeQtNWtFY>
Cc: dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 22:27:26 -0000

--55133644_69dffc_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=
=BC=8C=E4=B8=8B=E5=8D=884:43=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> Hello Dapeng,
> =20
> =20
> On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote:
> > Hello Alper, =20
> > =20
> > I still have the following comments:
> > =20
> > 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in =
the draft:
> > =20
> >   =E2=80=9C- =46ixed IP Address
> > This is what standard Mobile IP provides with a Home Address (HoA). T=
he mobile host is configures a HoA from a centrally-located Home Network.=
 Both IP session continuity and IP address reachability are provided to t=
he mobile host with the help of a router in the Home Network (Home Agent,=
 HA). This router acts as an anchor for the IP =20
> > address of the mobile host.=E2=80=9D =20
> > =20
> > If this is equal to HoA, then R=46C5014 already cover that. We do not=
 need to repeat it here with another name.
> > =20
> =20
> =20
> This is not equal to =22HoA=22.
> This is equal to =22HoA permanently allocated on a HA in the core netwo=
rk=22
> (as opposed to =22HoA temporarily allocated on a HA in the access netwo=
rk=22)
> =20
The draft says: =E2=80=9CThis is what standard Mobile IP provides with a =
Home Address (HoA)...=E2=80=9D  If it is not equal to HoA, need clarifica=
tion in the draft.
> =20
> =20
> > 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D=
 in the draft:
> > =20
> > =22- Sustained IP Address This type of IP address provides IP session=
 continuity but not IP address reachability. It is achieved by ensuring t=
hat the IP address used at the beginning of the session remains usable de=
spite the movement of the mobile host. The IP address may change after th=
e termination of the IP session(s), therefore it does not exhibit persist=
ence. =22 =20
> > There is no clear dividing line between fixed IP address and sustaine=
d IP address. Whether the IP address is used for reachability is not dete=
rmined by the IP address itself. =46or example, even when the MN get a Ho=
A, after it moves to another location of the network, it may decide to re=
lease current HoA and get another HoA, in this case the =22fixed IP addre=
ss=22 becomes a =22sustained IP address=22.
> > =20
> =20
> If the IP stack on the host releases the IP address, then of course it'=
s not a =22fixed IP address=22. =20
> Please see the definitions of these terms in the I-D.
> =20
> =20
> > =46urther more, the reachability normally is implemented by domain na=
me instead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80=9D=
 by its domain name, never by it=E2=80=99s server=E2=80=99s IP address. =20
> > =20
> > Using temporary private IP address we can also achieve the goal of =E2=
=80=9Creachability=E2=80=9D. =46or example, using dynamic DNS, as shown i=
n  http://hsk.oray.com/ , it can  provide reachability even the host get =
a private IP address.
> > =20
> =20
> You had said this before, and I had explained it.
> Nevertheless, let me recap:
> You cannot ensure an ongoing IP flow continues w/o interruption if you =
simply rely on dynamic DNS. Ongoing flows break even if you update the DN=
S.
> =46urthermore, even if you ignore the ongoing flows, also note that DNS=
 clients have a cache, hence a dynamic DNS update cannot be instantaneous=
ly reflected on the hosts. =20
> So, you cannot provide full mobility solution by relying on dynamic DNS=
.
> =20
> =20
The point here is =E2=80=9Creachability=E2=80=9D instead of =E2=80=9Cmobi=
lity=E2=80=9D. =20
=46urther more, even mobile IP may lost some packet during handover. =20
> > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:
> > =20
> > =E2=80=9C- Nomadic IP Address
> > This type of IP address provides neither IP session continuity nor IP=
 address reachability. The IP address is obtained from the serving IP gat=
eway and it is not maintained across gateway changes. In other words, the=
 IP address may be released and replaced by a new IP address when the IP =
gateway changes due to the movement of the mobile =20
> > host.=E2=80=9D
> > =20
> > Seems this IP address is the IP address that we normally used in most=
 cases. If this is the case, why we need a new name for it=3F
> > =20
> =20
> =20
> If you don't name it, how would you refer to it in this context=3F
If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D a=
nd =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not necessar=
y need a new name for normal IP address.


Dapeng =20
> =20
> =20
> Alper
> =20
> =20
> > =20
> > -- =20
> > Dapeng Liu
> > =20
> > =20
> > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=
=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=
=EF=BC=9A
> > =20
> > > Hello Dapeng and Alex,
> > > =20
> > > I hope you had a chance to digest our responses to your comments an=
d questions about the API work.
> > > If you have any remaining issues, please let us know over the email=
 at your earliest convenience.
> > > It'd be good if you can articulate them in detail.
> > > =20
> > > =20
> > > Thanks.
> > > =20
> > > Alper =20
> > =20
> =20


--55133644_69dffc_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><br></div><div><div></div></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=
=884:43=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span>Hello Dapeng,<div><br></div><div><br><div><div>=
On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote:</div><br><blockquote type=
=3D=22cite=22><div>
                <div>
                    Hello Alper,
                </div><div><br></div><div>I still have the following comm=
ents:</div><div><br></div><div>1. Regarding the definition of =E2=80=9Cfi=
xed IP address=E2=80=9D in the draft:</div><div><br></div><div>&nbsp; =E2=
=80=9C<span style=3D=22font-size: 1em; white-space: pre-wrap; widows: 1;=22=
>- =46ixed IP Address</span></div><pre style=3D=22font-size: 1em; margin-=
top: 0px; margin-bottom: 0px; page-break-before: always; widows: 1;=22>  =
 This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nb=
sp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; wid=
ows: 1;=22>   address of the mobile host.</span>=E2=80=9D&nbsp;</div><div=
><br></div><div>If this is equal to HoA, then R=46C5014 already cover tha=
t. We do not need to repeat it here with another name.</div><div><br></di=
v></div></blockquote><div><br></div><div><br></div><div>This is not equal=
 to =22HoA=22.</div><div>This is equal to =22HoA permanently allocated on=
 a HA in the core network=22</div><div>(as opposed to =22HoA temporarily =
allocated on a HA in the access network=22)</div><div><br></div></div></d=
iv></span></blockquote><div>The draft says: =E2=80=9C<span style=3D=22fon=
t-size: 1em; white-space: pre-wrap; widows: 1;=22>This is what standard M=
obile IP provides with a Home Address (HoA)...</span>=E2=80=9D &nbsp;If i=
t is not equal to HoA, need clarification in the draft.</div><blockquote =
type=3D=22cite=22 style=3D=22border-left-style:solid;border-width:1px;mar=
gin-left:0px;padding-left:10px;=22><span><div><div><div></div><br><blockq=
uote type=3D=22cite=22><div><div>2. Regarding the definition of =E2=80=9C=
sustained IP address=E2=80=9D in the draft:</div><div><br></div><div><pre=
 style=3D=22font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-bre=
ak-before: always; widows: 1;=22>=22- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
=22</pre></div>
                <div><div>There is no clear dividing line between fixed I=
P address and sustained IP address. Whether the IP address is used for re=
achability is not determined by the IP address itself. =46or example, eve=
n when the MN get a HoA, after it moves to another location of the networ=
k, it may decide to release current HoA and get another HoA, in this case=
 the =22fixed IP address=22 becomes a =22sustained IP address=22.</div><d=
iv><br></div></div></div></blockquote><div><br></div><div>If the IP stack=
 on the host releases the IP address, then of course it's not a =22fixed =
IP address=22.&nbsp;</div><div>Please see the definitions of these terms =
in the I-D.</div><div><br></div><div><br></div><blockquote type=3D=22cite=
=22><div><div>=46urther more, the reachability normally is implemented by=
 domain name instead of IP address. =46or example, we reach =E2=80=9CGoog=
le=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99s IP=
 address.&nbsp;</div><div><br></div></div><div><div>Using&nbsp;temporary =
private IP address we can also achieve the goal of =E2=80=9Creachability=E2=
=80=9D. =46or example, using dynamic DNS, as shown in &nbsp;<a href=3D=22=
http://hsk.oray.com/=22>http://hsk.oray.com/</a>&nbsp;, it can &nbsp;prov=
ide reachability even the host get a private IP address.</div><div><br></=
div></div></blockquote><div><br></div><div>You had said this before, and =
I had explained it.</div><div>Nevertheless, let me recap:</div><div>You c=
annot ensure an ongoing IP flow continues w/o interruption if you simply =
rely on dynamic DNS. Ongoing flows break even if you update the DNS.</div=
><div>=46urthermore, even if you ignore the ongoing flows, also note that=
 DNS clients have a cache, hence a dynamic DNS update cannot be instantan=
eously reflected on the hosts.&nbsp;</div><div>So, you cannot provide ful=
l mobility solution by relying on dynamic DNS.</div><div><br></div><br></=
div></div></span></blockquote><div>The point here is =E2=80=9Creachabilit=
y=E2=80=9D instead of =E2=80=9Cmobility=E2=80=9D.&nbsp;</div><div>=46urth=
er more, even mobile IP may lost some packet during handover.&nbsp;</div>=
<blockquote type=3D=22cite=22 style=3D=22border-left-style:solid;border-w=
idth:1px;margin-left:0px;padding-left:10px;=22><span><div><div><blockquot=
e type=3D=22cite=22><div><div>3. Regarding the definition of =E2=80=9Cnom=
adic IP address=E2=80=9D:</div><div><br></div><div>=E2=80=9C<span style=3D=
=22font-size: 1em; white-space: pre-wrap; widows: 1;=22>- Nomadic IP Addr=
ess</span></div><pre style=3D=22font-size: 1em; margin-top: 0px; margin-b=
ottom: 0px; page-break-before: always; widows: 1;=22>   This type of IP a=
ddress provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&=
nbsp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; w=
idows: 1;=22>   host.</span>=E2=80=9D</div><div><br></div><div>Seems this=
 IP address is the IP address that we normally used in most cases. If thi=
s is the case, why we need a new name for it=3F</div><div><br></div></div=
></blockquote><div><br></div><div><br></div><div>If you don't name it, ho=
w would you refer to it in this context=3F</div></div></div></span></bloc=
kquote><div>If the justification of naming IP address as =E2=80=9Cfixed I=
P=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may =
not necessary need a new name for normal IP address.</div><div><br></div>=
<div><br></div><div>Dapeng&nbsp;</div><blockquote type=3D=22cite=22 style=
=3D=22border-left-style:solid;border-width:1px;margin-left:0px;padding-le=
ft:10px;=22><span><div><div><div><br></div><div><br></div><div>Alper</div=
><div><br></div><br><blockquote type=3D=22cite=22><div><div><div><br></di=
v><div>--&nbsp;</div><div>Dapeng Liu</div><div><br></div></div><p style=3D=
=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=
=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =
=E5=86=99=E9=81=93=EF=BC=9A</p><blockquote type=3D=22cite=22><div>
                    <span><div><div><div>Hello Dapeng and Alex,</div><div=
><br></div><div>I hope you had a chance to digest our responses to your c=
omments and questions about the API work.</div><div>If you have any remai=
ning issues, please let us know over the email at your earliest convenien=
ce.</div><div>It'd be good if you can articulate them in detail.</div><di=
v><br></div><div><br></div><div>Thanks.</div><div><br></div><div>Alper</d=
iv></div></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--55133644_69dffc_a9e--


From nobody Wed Mar 25 16:18:40 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DAE1A1B8F for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level: 
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nit_mJBsz64k for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:18:35 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302031A6F39 for <dmm@ietf.org>; Wed, 25 Mar 2015 16:18:35 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNIWjv002461; Thu, 26 Mar 2015 00:18:33 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EDEAF2035DB; Thu, 26 Mar 2015 00:19:16 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDF7D200BEB; Thu, 26 Mar 2015 00:19:16 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.99]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNISeI012277; Thu, 26 Mar 2015 00:18:32 +0100
Message-ID: <55134244.602@gmail.com>
Date: Wed, 25 Mar 2015 18:18:28 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>, Dapeng Liu <maxpassion@gmail.com>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org>
In-Reply-To: <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/07GHOQORL8jThChlb2sFweS2Oc4>
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 23:18:38 -0000

Hi, Alper,

Sorry for interfering but I have a few points where I agree with Dapeng.

Le 25/03/2015 16:43, Alper Yegin a écrit :
> Hello Dapeng,
>
>
> On Mar 25, 2015, at 11:01 PM, Dapeng Liu wrote:
>
>> Hello Alper,
>>
>> I still have the following comments:
>>
>> 1. Regarding the definition of “fixed IP address� in the draft:
>>
>>   “- Fixed IP Address
>>     This is what standard Mobile IP provides with a Home Address (HoA).
>>     The mobile host is configures a HoA from a centrally-located Home
>>     Network.  Both IP session continuity and IP address reachability are
>>     provided to the mobile host with the help of a router in the Home
>>     Network (Home Agent, HA).  This router acts as an anchor for the IP
>> address of the mobile host.�
>>
>> If this is equal to HoA, then RFC5014 already cover that. We do not
>> need to repeat it here with another name.
>>
>
>
> This is not equal to "HoA".
> This is equal to "HoA permanently allocated on a HA in the core network"
> (as opposed to "HoA temporarily allocated on a HA in the access network")

So that's a HoA, and RFC5014 already covers that, right?

>> 2. Regarding the definition of “sustained IP address� in the draft:
>>
>> "- Sustained IP Address
>>
>>     This type of IP address provides IP session continuity but not IP
>>     address reachability.  It is achieved by ensuring that the IP address
>>     used at the beginning of the session remains usable despite the
>>     movement of the mobile host.  The IP address may change after the
>>     termination of the IP session(s), therefore it does not exhibit
>>     persistence.
>> "
>> There is no clear dividing line between fixed IP address and sustained
>> IP address. Whether the IP address is used for reachability is not
>> determined by the IP address itself. For example, even when the MN get
>> a HoA, after it moves to another location of the network, it may
>> decide to release current HoA and get another HoA, in this case the
>> "fixed IP address" becomes a "sustained IP address".
>>
>
> If the IP stack on the host releases the IP address, then of course it's
> not a "fixed IP address".
> Please see the definitions of these terms in the I-D.
>
>
>> Further more, the reachability normally is implemented by domain name
>> instead of IP address. For example, we reach “Google� by its domain
>> name, never by it’s server’s IP address.
>>
>> Using temporary private IP address we can also achieve the goal of
>> “reachability�. For example, using dynamic DNS, as shown in
>> http://hsk.oray.com/ , it can  provide reachability even the host get
>> a private IP address.
>>
>
> You had said this before, and I had explained it.
> Nevertheless, let me recap:
> You cannot ensure an ongoing IP flow continues w/o interruption if you
> simply rely on dynamic DNS. Ongoing flows break even if you update the DNS.

But Dapeng talks about reachability, not about session continuity.  In 
that sense he's right, no? (DNS updates ensure reachability upon address 
change).

Even I would go as far as to say that _some_ application flows will 
resist to changes in that IP address and get restarted with the new 
address if that DNS update process was performed.

This is because the concept of 'flow' is very much ambiguous.  Very 
rarely a read in packet dump can show 'flows' as we talk commonly about 
them in the DMM discussions.  It is for this reason that there is no 
option in Wireshark that groups packets in 'flows', like a mail reader 
would group messages into 'conversations' or 'threads'.

It is for this reason too that firewall rules trying to be smart and 
identify 'flows' before blocking them very often fail, even if we do 
Deep Packet Inspection.  People always find ways to 'drill' through 
these rules.

> Furthermore, even if you ignore the ongoing flows, also note that DNS
> clients have a cache, hence a dynamic DNS update cannot be
> instantaneously reflected on the hosts.

I can agree to that.  I guess though there may be forced updates on 
these caches, or that the timers can be configured shorter in domains 
supporting mobility.

> So, you cannot provide full mobility solution by relying on dynamic DNS.

We dont know what full mobility is, and DNS updates is a good tool to 
provide reachability and session continuity, in some cases.

Alex

>
>
>> 3. Regarding the definition of “nomadic IP address�:
>>
>> “- Nomadic IP Address
>>     This type of IP address provides neither IP session continuity nor IP
>>     address reachability.  The IP address is obtained from the serving IP
>>     gateway and it is not maintained across gateway changes.  In other
>>     words, the IP address may be released and replaced by a new IP
>>     address when the IP gateway changes due to the movement of the mobile
>> host.�
>>
>> Seems this IP address is the IP address that we normally used in most
>> cases. If this is the case, why we need a new name for it?
>>
>
>
> If you don't name it, how would you refer to it in this context?
>
>
> Alper
>
>
>>
>> --
>> Dapeng Liu
>>
>> 在 2015年3月25日 星期三，下�2:02，Alper Yegin 写�：
>>
>>> Hello Dapeng and Alex,
>>>
>>> I hope you had a chance to digest our responses to your comments and
>>> questions about the API work.
>>> If you have any remaining issues, please let us know over the email
>>> at your earliest convenience.
>>> It'd be good if you can articulate them in detail.
>>>
>>>
>>> Thanks.
>>>
>>> Alper
>>
>



From nobody Wed Mar 25 16:27:54 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C8C1AC3B0 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBWDogXsnnJF for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:27:49 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016F51ACCDC for <dmm@ietf.org>; Wed, 25 Mar 2015 16:27:44 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNRg0u007722 for <dmm@ietf.org>; Thu, 26 Mar 2015 00:27:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E376E2035DB for <dmm@ietf.org>; Thu, 26 Mar 2015 00:28:26 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF98820350B for <dmm@ietf.org>; Thu, 26 Mar 2015 00:28:26 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.99]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNRdwO028603 for <dmm@ietf.org>; Thu, 26 Mar 2015 00:27:42 +0100
Message-ID: <5513446A.4060307@gmail.com>
Date: Wed, 25 Mar 2015 18:27:38 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "dmm@ietf.org" <dmm@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/zwEpK0-DGifHzk6bRQtA94Ner8k>
Subject: [DMM] SUSTAINED, NOMADIC, FIXED: existing kinds, lifetimes
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 23:27:51 -0000

Alper, authors of draft-yegin-dmm-ondemand-mobility-03,

I would like to ask how do you see the relationships between
other kinds of addresses (HoW, CoA, LL, GUA, ULA, NATTed, privacy,
multicast) and the SUSTAINED, NOMADIC, FIXED addresses.

In addition, I think there may be a relationship with the lifetimes of
the addresses generated by existing address configuration mechanisms.

Alex



From nobody Wed Mar 25 16:41:43 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832761A8A43 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce4OoVTu5E_j for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:41:40 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A281A899C for <dmm@ietf.org>; Wed, 25 Mar 2015 16:41:39 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2PNfbCB010428 for <dmm@ietf.org>; Thu, 26 Mar 2015 00:41:37 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2AA620373B for <dmm@ietf.org>; Thu, 26 Mar 2015 00:42:21 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A9DFF20373A for <dmm@ietf.org>; Thu, 26 Mar 2015 00:42:21 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.99]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2PNfYEI029105 for <dmm@ietf.org>; Thu, 26 Mar 2015 00:41:37 +0100
Message-ID: <551347AE.6030208@gmail.com>
Date: Wed, 25 Mar 2015 18:41:34 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "dmm@ietf.org" <dmm@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/NOh7BFNk0Gj4Ldmtui5Fp6blw10>
Subject: [DMM] clarifications on draft-chan-dmm-distributed-mobility-anchoring-01 - and 2 questions
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 23:41:41 -0000

Hello,

During yesterday's DMM meeting there were several clarification
questions on draft-chan-dmm-distributed-mobility-anchoring-01.

I talked this morning to Anthony, and I think there is a case.

The IP Anchor - we all know what is.  It typically anchors the HoA of
Mobile IPv6 protocol.  It is a Border Router or a Home Agent, or so.

The "Session IP" Anchor is new and deserves clarification.

The "Session IP Anchor" is actually a "Session Anchor".  If a session is
identified by an IP address (i.e. a brief web browsing session to the IP
address of a web server) then that's the Care-of Address; that is a
"Session IP Anchor" and it is typically an Access Router where that IP
address (CoA) is topologically correct.

On another hand, Sessions can be identified by something else than an IP
address.  For example, a TCP session is identified by a quad
IPsrc/IPdst/srcport/srcdst.  The anchor of this session may be something
else than the Access Router.  It could be for example an Application
Layer Gateway (ALG) like for example a HTTP proxy.

So we end up with two anchors: the "Address Anchor" and the "HTTP Proxy
Anchor".

A session can be identified by a SIP identifier as well (SIP - Session
Initiation Protocol).  In that case the "Session Anchor" would be a SIP
Server.

Following this presumably locator-identifier split, we can think about
this session to be for HIP, for SHIM6 and even DNS.  Each time there is
a different Session Anchor.

And this draft proposes to offer a double-level mobility which allows
changing the IP anchor or the session anchor without interrupting the
sessions.

That said, I wonder whether the IP Anchor of this draft supports
SUSTAINED, NOMADIC, FIXED kinds of addresses.

I also wonder whether the Alper's API draft supports SUSTAINED, NOMADIC,
FIXED attributes of IP addresses in the DNS.

Alex


From nobody Wed Mar 25 16:54:27 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E01A8AF6 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7_zzpMOaaN1 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 16:54:24 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC4C1A8892 for <dmm@ietf.org>; Wed, 25 Mar 2015 16:54:24 -0700 (PDT)
Received: from [10.119.16.2] ([81.17.21.69]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0LnzHq-1Z841O3sBk-00g293; Thu, 26 Mar 2015 00:54:23 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <16D77D43C73143B9A76C580ECBA39A87@gmail.com>
Date: Thu, 26 Mar 2015 01:54:19 +0200
Message-Id: <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <16D77D43C73143B9A76C580ECBA39A87@gmail.com>
To: Dapeng Liu <maxpassion@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:bZN/mG9xHXpRDJ1GKB4I+gXZ8V0c1+3tvMq9ItuubuAxf5zomPX HsDDp88Rx99TmLq91AOUWu3TZCsOuZsWzMt357KMnEjYaO/ZPLBPFXelC2+V2+0kkTw/4Zv kCdT8RJNF+E29vlTVtz2OhAs1uyci56/H0654AC/2IwS7ZCRUW/EpIJJkVTbqv4GNRskGWa 1SukV6JGRMBlsIxahBi6Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/gsfkJjzUPtHSxDapIaIuJAASiSo>
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 23:54:27 -0000

--Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>>>=20
>>> 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in =
the draft:
>>>=20
>>>   =E2=80=9C- Fixed IP Address
>>>    This is what standard Mobile IP provides with a Home Address =
(HoA).
>>>    The mobile host is configures a HoA from a centrally-located Home
>>>    Network.  Both IP session continuity and IP address reachability =
are
>>>    provided to the mobile host with the help of a router in the Home
>>>    Network (Home Agent, HA).  This router acts as an anchor for the =
IP=20
>>>    address of the mobile host.=E2=80=9D=20
>>>=20
>>> If this is equal to HoA, then RFC5014 already cover that. We do not =
need to repeat it here with another name.
>>>=20
>>=20
>>=20
>> This is not equal to "HoA".
>> This is equal to "HoA permanently allocated on a HA in the core =
network"
>> (as opposed to "HoA temporarily allocated on a HA in the access =
network")
>>=20
> The draft says: =E2=80=9CThis is what standard Mobile IP provides with =
a Home Address (HoA)...=E2=80=9D  If it is not equal to HoA, need =
clarification in the draft.
>>=20

Draft says "This is what standard Mobile IP provides with a Home Address =
(HoA). The mobile host is configures a HoA from a centrally-located Home =
  Network. "

If this is not clear enough, we can certainly elaborate more on that in =
the I-D.


>>> 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D =
in the draft:
>>>=20
>>> "- Sustained IP Address
>>>=20
>>>    This type of IP address provides IP session continuity but not IP
>>>    address reachability.  It is achieved by ensuring that the IP =
address
>>>    used at the beginning of the session remains usable despite the
>>>    movement of the mobile host.  The IP address may change after the
>>>    termination of the IP session(s), therefore it does not exhibit
>>>    persistence.
>>> "
>>> There is no clear dividing line between fixed IP address and =
sustained IP address. Whether the IP address is used for reachability is =
not determined by the IP address itself. For example, even when the MN =
get a HoA, after it moves to another location of the network, it may =
decide to release current HoA and get another HoA, in this case the =
"fixed IP address" becomes a "sustained IP address".
>>>=20
>>=20
>> If the IP stack on the host releases the IP address, then of course =
it's not a "fixed IP address".=20
>> Please see the definitions of these terms in the I-D.
>>=20
>>=20
>>> Further more, the reachability normally is implemented by domain =
name instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D=
 by its domain name, never by it=E2=80=99s server=E2=80=99s IP address.=20=

>>>=20
>>> Using temporary private IP address we can also achieve the goal of =
=E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as shown =
in  http://hsk.oray.com/ , it can  provide reachability even the host =
get a private IP address.
>>>=20
>>=20
>> You had said this before, and I had explained it.
>> Nevertheless, let me recap:
>> You cannot ensure an ongoing IP flow continues w/o interruption if =
you simply rely on dynamic DNS. Ongoing flows break even if you update =
the DNS.
>> Furthermore, even if you ignore the ongoing flows, also note that DNS =
clients have a cache, hence a dynamic DNS update cannot be =
instantaneously reflected on the hosts.=20
>> So, you cannot provide full mobility solution by relying on dynamic =
DNS.
>>=20
>>=20
> The point here is =E2=80=9Creachability=E2=80=9D instead of =
=E2=80=9Cmobility=E2=80=9D.=20
> Further more, even mobile IP may lost some packet during handover.=20

Not sure if this point has any impact on the discussion.


>>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:
>>>=20
>>> =E2=80=9C- Nomadic IP Address
>>>    This type of IP address provides neither IP session continuity =
nor IP
>>>    address reachability.  The IP address is obtained from the =
serving IP
>>>    gateway and it is not maintained across gateway changes.  In =
other
>>>    words, the IP address may be released and replaced by a new IP
>>>    address when the IP gateway changes due to the movement of the =
mobile=20
>>>    host.=E2=80=9D
>>>=20
>>> Seems this IP address is the IP address that we normally used in =
most cases. If this is the case, why we need a new name for it?
>>>=20
>>=20
>>=20
>> If you don't name it, how would you refer to it in this context?
> If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D =
and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not =
necessary need a new name for normal IP address.
>=20

I and the WT#1 believe that justification is valid.
If you believe otherwise, please elaborate.

Alper



>=20
> Dapeng=20
>>=20
>>=20
>> Alper
>>=20
>>=20
>>>=20
>>> --=20
>>> Dapeng Liu
>>>=20
>>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =
=E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper =
Yegin =E5=86=99=E9=81=93=EF=BC=9A
>>>=20
>>>> Hello Dapeng and Alex,
>>>>=20
>>>> I hope you had a chance to digest our responses to your comments =
and questions about the API work.
>>>> If you have any remaining issues, please let us know over the email =
at your earliest convenience.
>>>> It'd be good if you can articulate them in detail.
>>>>=20
>>>>=20
>>>> Thanks.
>>>>=20
>>>> Alper
>>>=20
>>=20
>=20


--Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite"><blockquote type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><blockquote =
type=3D"cite"><div><div><br></div><div>1. Regarding the definition of =
=E2=80=9Cfixed IP address=E2=80=9D in the =
draft:</div><div><br></div><div>&nbsp; =E2=80=9C<span style=3D"font-size: =
1em; white-space: pre-wrap; widows: 1;">- Fixed IP =
Address</span></div><pre style=3D"font-size: 1em; margin-top: 0px; =
margin-bottom: 0px; page-break-before: always; widows: 1;">   This is =
what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the =
IP&nbsp;</pre><div><span style=3D"font-size: 1em; white-space: pre-wrap; =
widows: 1;">   address of the mobile =
host.</span>=E2=80=9D&nbsp;</div><div><br></div><div>If this is equal to =
HoA, then RFC5014 already cover that. We do not need to repeat it here =
with another =
name.</div><div><br></div></div></blockquote><div><br></div><div><br></div=
><div>This is not equal to "HoA".</div><div>This is equal to "HoA =
permanently allocated on a HA in the core network"</div><div>(as opposed =
to "HoA temporarily allocated on a HA in the access =
network")</div><div><br></div></div></div></span></blockquote><div>The =
draft says: =E2=80=9C<span style=3D"font-size: 1em; white-space: =
pre-wrap; widows: 1;">This is what standard Mobile IP provides with a =
Home Address (HoA)...</span>=E2=80=9D &nbsp;If it is not equal to HoA, =
need clarification in the draft.</div><blockquote type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><div></div><br></div></div></span></blockquote=
></blockquote><div><br></div><div>Draft says "<span =
class=3D"Apple-style-span" style=3D"font-family: monospace; white-space: =
pre-wrap; ">This is what standard Mobile IP provides with a Home Address =
(HoA).</span><span class=3D"Apple-style-span" style=3D"font-family: =
monospace; white-space: pre-wrap; "> The mobile host is configures a HoA =
from a centrally-located Home</span><span class=3D"Apple-style-span" =
style=3D"font-family: monospace; white-space: pre-wrap; ">   Network. =
<span class=3D"Apple-style-span" style=3D"font-family: Helvetica; =
white-space: normal; ">"</span></span></div><div><br></div><div>If this =
is not clear enough, we can certainly elaborate more on that in the =
I-D.</div><div><br></div><br><blockquote type=3D"cite"><blockquote =
type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><blockquote type=3D"cite"><div><div>2. =
Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D in =
the draft:</div><div><br></div><div><pre style=3D"font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always; widows: =
1;">"- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
"</pre></div>
                <div><div>There is no clear dividing line between fixed =
IP address and sustained IP address. Whether the IP address is used for =
reachability is not determined by the IP address itself. For example, =
even when the MN get a HoA, after it moves to another location of the =
network, it may decide to release current HoA and get another HoA, in =
this case the "fixed IP address" becomes a "sustained IP =
address".</div><div><br></div></div></div></blockquote><div><br></div><div=
>If the IP stack on the host releases the IP address, then of course =
it's not a "fixed IP address".&nbsp;</div><div>Please see the =
definitions of these terms in the =
I-D.</div><div><br></div><div><br></div><blockquote =
type=3D"cite"><div><div>Further more, the reachability normally is =
implemented by domain name instead of IP address. For example, we reach =
=E2=80=9CGoogle=E2=80=9D by its domain name, never by it=E2=80=99s =
server=E2=80=99s IP =
address.&nbsp;</div><div><br></div></div><div><div>Using&nbsp;temporary =
private IP address we can also achieve the goal of =E2=80=9Creachability=E2=
=80=9D. For example, using dynamic DNS, as shown in &nbsp;<a =
href=3D"http://hsk.oray.com/">http://hsk.oray.com/</a>&nbsp;, it can =
&nbsp;provide reachability even the host get a private IP =
address.</div><div><br></div></div></blockquote><div><br></div><div>You =
had said this before, and I had explained it.</div><div>Nevertheless, =
let me recap:</div><div>You cannot ensure an ongoing IP flow continues =
w/o interruption if you simply rely on dynamic DNS. Ongoing flows break =
even if you update the DNS.</div><div>Furthermore, even if you ignore =
the ongoing flows, also note that DNS clients have a cache, hence a =
dynamic DNS update cannot be instantaneously reflected on the =
hosts.&nbsp;</div><div>So, you cannot provide full mobility solution by =
relying on dynamic =
DNS.</div><div><br></div><br></div></div></span></blockquote><div>The =
point here is =E2=80=9Creachability=E2=80=9D instead of =
=E2=80=9Cmobility=E2=80=9D.&nbsp;</div><div>Further more, even mobile IP =
may lost some packet during =
handover.&nbsp;</div></blockquote><div><br></div><div>Not sure if this =
point has any impact on the =
discussion.</div><div><br></div><br><blockquote type=3D"cite"><blockquote =
type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><blockquote type=3D"cite"><div><div>3. =
Regarding the definition of =E2=80=9Cnomadic IP =
address=E2=80=9D:</div><div><br></div><div>=E2=80=9C<span =
style=3D"font-size: 1em; white-space: pre-wrap; widows: 1;">- Nomadic IP =
Address</span></div><pre style=3D"font-size: 1em; margin-top: 0px; =
margin-bottom: 0px; page-break-before: always; widows: 1;">   This type =
of IP address provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"font-size: 1em; white-space: =
pre-wrap; widows: 1;">   host.</span>=E2=80=9D</div><div><br></div><div>Se=
ems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for =
it?</div><div><br></div></div></blockquote><div><br></div><div><br></div><=
div>If you don't name it, how would you refer to it in this =
context?</div></div></div></span></blockquote><div>If the justification =
of naming IP address as =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C =
sustained IP=E2=80=9D is not valid, then we may not necessary need a new =
name for normal IP =
address.</div><div><br></div></blockquote><div><br></div><div>I and the =
WT#1 believe that justification is valid.</div><div>If you believe =
otherwise, please =
elaborate.</div><div><br></div><div>Alper</div><div><br></div><div><br></d=
iv><br><blockquote =
type=3D"cite"><div><br></div><div>Dapeng&nbsp;</div><blockquote =
type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><div><br></div><div><br></div><div>Alper</div>=
<div><br></div><br><blockquote =
type=3D"cite"><div><div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div></div><p style=3D"color: #A0A0A8;">=E5=9C=A8 =
2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=
=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p><bl=
ockquote type=3D"cite"><div>
                    <span><div><div><div>Hello Dapeng and =
Alex,</div><div><br></div><div>I hope you had a chance to digest our =
responses to your comments and questions about the API =
work.</div><div>If you have any remaining issues, please let us know =
over the email at your earliest convenience.</div><div>It'd be good if =
you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            </blockquote></div><br></body></html>=

--Apple-Mail=_4E9050FF-A42C-43B3-A4A5-30AE9C727F17--


From nobody Wed Mar 25 18:32:43 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AC91A8880 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 18:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level: 
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFU0SZdoE3dK for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 18:32:39 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D581D1A1B76 for <dmm@ietf.org>; Wed, 25 Mar 2015 18:32:38 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so34303510obc.2 for <dmm@ietf.org>; Wed, 25 Mar 2015 18:32:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=zLL2B605vCLoclJjwyGo2EvwGnSE30sVzlDMlOHBZHo=; b=NdJLoTJjuM0p2HmFebwgkylpN5PzAOQBcJNXVbPG/UM0hh2gtMkH54el8ukQZ9NVUl FbZEL4LfIoj/SdHTlEiSrr2P9eVj/gn8vSVy5o8KOEaBy1GJ/VoRzMQOWC1R/6e1iGyt 0OOPCbxe6dCRCDR5bTpi/nak3sjsPnmSIj2GgaOTjjPYFDLMnogIjwpKSoDxWoT9E89Y 7W5YQ/tnH6SwPdbCsSQ1yFrR/hXxRrW6cjz/xh0PUpK7hmGL8wTdfMAaLCvJZOdTPikW aYsyZ6nF3PsXlch6K2I8LFGUwwrrnGBMzkj441r8MASFrkE2naEeYzhRF0kmpHpW8w7+ 2PSw==
X-Received: by 10.182.72.225 with SMTP id g1mr10109472obv.80.1427333558355; Wed, 25 Mar 2015 18:32:38 -0700 (PDT)
Received: from [10.1.213.204] ([38.96.210.190]) by mx.google.com with ESMTPSA id h8sm3411907obe.2.2015.03.25.18.32.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Mar 2015 18:32:36 -0700 (PDT)
Date: Wed, 25 Mar 2015 20:32:33 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <52AC56D3ADC0481CBF02BAADF720991B@gmail.com>
In-Reply-To: <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="551361b1_55c3594c_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/DPmOHKWZXZHxQH4qaXzPmK_jfyo>
Cc: dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 01:32:42 -0000

--551361b1_55c3594c_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=
=BC=8C=E4=B8=8B=E5=8D=886:54=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> > > > =20
> > > > 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D=
 in the draft:
> > > > =20
> > > >   =E2=80=9C- =46ixed IP Address
> > > > This is what standard Mobile IP provides with a Home Address (HoA=
). The mobile host is configures a HoA from a centrally-located Home Netw=
ork. Both IP session continuity and IP address reachability are provided =
to the mobile host with the help of a router in the Home Network (Home Ag=
ent, HA). This router acts as an anchor for the IP =20
> > > > address of the mobile host.=E2=80=9D =20
> > > > =20
> > > > If this is equal to HoA, then R=46C5014 already cover that. We do=
 not need to repeat it here with another name.
> > > > =20
> > > =20
> > > =20
> > > This is not equal to =22HoA=22.
> > > This is equal to =22HoA permanently allocated on a HA in the core n=
etwork=22
> > > (as opposed to =22HoA temporarily allocated on a HA in the access n=
etwork=22)
> > > =20
> > The draft says: =E2=80=9CThis is what standard Mobile IP provides wit=
h a Home Address (HoA)...=E2=80=9D  If it is not equal to HoA, need clari=
fication in the draft.
> > > =20
> =20
> Draft says =22This is what standard Mobile IP provides with a Home Addr=
ess (HoA). The mobile host is configures a HoA from a centrally-located H=
ome Network. =22
> =20
> If this is not clear enough, we can certainly elaborate more on that in=
 the I-D.
> =20
Yes. It needs more elaboration. =20
> =20
> =20
> > > > 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=
=9D in the draft:
> > > > =20
> > > > =22- Sustained IP Address This type of IP address provides IP ses=
sion continuity but not IP address reachability. It is achieved by ensuri=
ng that the IP address used at the beginning of the session remains usabl=
e despite the movement of the mobile host. The IP address may change afte=
r the termination of the IP session(s), therefore it does not exhibit per=
sistence. =22 =20
> > > > There is no clear dividing line between fixed IP address and sust=
ained IP address. Whether the IP address is used for reachability is not =
determined by the IP address itself. =46or example, even when the MN get =
a HoA, after it moves to another location of the network, it may decide t=
o release current HoA and get another HoA, in this case the =22fixed IP a=
ddress=22 becomes a =22sustained IP address=22.
> > > > =20
> > > =20
> > > If the IP stack on the host releases the IP address, then of course=
 it's not a =22fixed IP address=22. =20
> > > Please see the definitions of these terms in the I-D.
> > > =20
> > > =20
> > > > =46urther more, the reachability normally is implemented by domai=
n name instead of IP address. =46or example, we reach =E2=80=9CGoogle=E2=80=
=9D by its domain name, never by it=E2=80=99s server=E2=80=99s IP address=
. =20
> > > > =20
> > > > Using temporary private IP address we can also achieve the goal o=
f =E2=80=9Creachability=E2=80=9D. =46or example, using dynamic DNS, as sh=
own in  http://hsk.oray.com/ , it can  provide reachability even the host=
 get a private IP address.
> > > > =20
> > > =20
> > > You had said this before, and I had explained it.
> > > Nevertheless, let me recap:
> > > You cannot ensure an ongoing IP flow continues w/o interruption if =
you simply rely on dynamic DNS. Ongoing flows break even if you update th=
e DNS.
> > > =46urthermore, even if you ignore the ongoing flows, also note that=
 DNS clients have a cache, hence a dynamic DNS update cannot be instantan=
eously reflected on the hosts. =20
> > > So, you cannot provide full mobility solution by relying on dynamic=
 DNS.
> > > =20
> > > =20
> > The point here is =E2=80=9Creachability=E2=80=9D instead of =E2=80=9C=
mobility=E2=80=9D. =20
> > =46urther more, even mobile IP may lost some packet during handover. =
=20
> > =20
> =20
> =20
> Not sure if this point has any impact on the discussion.
> =20
> =20
The point is: in the draft,  whether support =E2=80=9Creachability=E2=80=9D=
 is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sust=
ained IP=E2=80=9D, but the truth is any type of IP address can provide =E2=
=80=9Creachability=E2=80=9D. So there is no clear dividing line between  =
=E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in the def=
inition. That is why the definition of the IP types is not valid.
> > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D=
:
> > > > =20
> > > > =E2=80=9C- Nomadic IP Address
> > > > This type of IP address provides neither IP session continuity no=
r IP address reachability. The IP address is obtained from the serving IP=
 gateway and it is not maintained across gateway changes. In other words,=
 the IP address may be released and replaced by a new IP address when the=
 IP gateway changes due to the movement of the mobile =20
> > > > host.=E2=80=9D
> > > > =20
> > > > Seems this IP address is the IP address that we normally used in =
most cases. If this is the case, why we need a new name for it=3F
> > > > =20
> > > =20
> > > =20
> > > If you don't name it, how would you refer to it in this context=3F
> > If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D=
 and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not necess=
ary need a new name for normal IP address.
> > =20
> =20
> I and the WT=231 believe that justification is valid.
> If you believe otherwise, please elaborate.
> =20
> =20
> =20

Pls see above comment.

Dapeng =20
> =20
> Alper
> =20
> =20
> =20
> > =20
> > Dapeng =20
> > > =20
> > > =20
> > > Alper
> > > =20
> > > =20
> > > > =20
> > > > -- =20
> > > > Dapeng Liu
> > > > =20
> > > > =20
> > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=
=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=
=93=EF=BC=9A
> > > > =20
> > > > > Hello Dapeng and Alex,
> > > > > =20
> > > > > I hope you had a chance to digest our responses to your comment=
s and questions about the API work.
> > > > > If you have any remaining issues, please let us know over the e=
mail at your earliest convenience.
> > > > > It'd be good if you can articulate them in detail.
> > > > > =20
> > > > > =20
> > > > > Thanks.
> > > > > =20
> > > > > Alper =20
> > > > =20
> > > =20
> > =20
> =20


--551361b1_55c3594c_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><br></div><div><div></div></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=
=886:54=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div><blockquote type=3D=22cite=22><d=
iv><blockquote type=3D=22cite=22><div><span><div><div><blockquote type=3D=
=22cite=22><div><div><br></div><div>1. Regarding the definition of =E2=80=
=9Cfixed IP address=E2=80=9D in the draft:</div><div><br></div><div>&nbsp=
; =E2=80=9C<span style=3D=22font-size: 1em; white-space: pre-wrap; widows=
: 1;=22>- =46ixed IP Address</span></div><pre style=3D=22font-size: 1em; =
margin-top: 0px; margin-bottom: 0px; page-break-before: always; widows: 1=
;=22>   This is what standard Mobile IP provides with a Home Address (HoA=
).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nb=
sp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; wid=
ows: 1;=22>   address of the mobile host.</span>=E2=80=9D&nbsp;</div><div=
><br></div><div>If this is equal to HoA, then R=46C5014 already cover tha=
t. We do not need to repeat it here with another name.</div><div><br></di=
v></div></blockquote><div><br></div><div><br></div><div>This is not equal=
 to =22HoA=22.</div><div>This is equal to =22HoA permanently allocated on=
 a HA in the core network=22</div><div>(as opposed to =22HoA temporarily =
allocated on a HA in the access network=22)</div><div><br></div></div></d=
iv></span></div></blockquote><div>The draft says: =E2=80=9C<span style=3D=
=22font-size: 1em; white-space: pre-wrap; widows: 1;=22>This is what stan=
dard Mobile IP provides with a Home Address (HoA)...</span>=E2=80=9D &nbs=
p;If it is not equal to HoA, need clarification in the draft.</div><block=
quote type=3D=22cite=22><div><span><div><div><br></div></div></span></div=
></blockquote></div></blockquote><div><br></div><div>Draft says =22<span =
style=3D=22font-family: monospace; white-space: pre-wrap; =22>This is wha=
t standard Mobile IP provides with a Home Address (HoA).</span><span styl=
e=3D=22font-family: monospace; white-space: pre-wrap; =22> The mobile hos=
t is configures a HoA from a centrally-located Home</span><span style=3D=22=
font-family: monospace; white-space: pre-wrap; =22>   Network. <span styl=
e=3D=22font-family: Helvetica; white-space: normal; =22>=22</span></span>=
</div><div><br></div><div>If this is not clear enough, we can certainly e=
laborate more on that in the I-D.</div><div><br></div></div></div></div><=
/span></blockquote><div>Yes. It needs more elaboration.&nbsp;</div><block=
quote type=3D=22cite=22 style=3D=22border-left-style:solid;border-width:1=
px;margin-left:0px;padding-left:10px;=22><span><div><div><div><div></div>=
<br><blockquote type=3D=22cite=22><div><blockquote type=3D=22cite=22><div=
><span><div><div><blockquote type=3D=22cite=22><div><div>2. Regarding the=
 definition of =E2=80=9Csustained IP address=E2=80=9D in the draft:</div>=
<div><br></div><div><pre style=3D=22font-size: 1em; margin-top: 0px; marg=
in-bottom: 0px; page-break-before: always; widows: 1;=22>=22- Sustained I=
P Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
=22</pre></div>
                <div><div>There is no clear dividing line between fixed I=
P address and sustained IP address. Whether the IP address is used for re=
achability is not determined by the IP address itself. =46or example, eve=
n when the MN get a HoA, after it moves to another location of the networ=
k, it may decide to release current HoA and get another HoA, in this case=
 the =22fixed IP address=22 becomes a =22sustained IP address=22.</div><d=
iv><br></div></div></div></blockquote><div><br></div><div>If the IP stack=
 on the host releases the IP address, then of course it's not a =22fixed =
IP address=22.&nbsp;</div><div>Please see the definitions of these terms =
in the I-D.</div><div><br></div><div><br></div><blockquote type=3D=22cite=
=22><div><div><div>=46urther more, the reachability normally is implement=
ed by domain name instead of IP address. =46or example, we reach =E2=80=9C=
Google=E2=80=9D by its domain name, never by it=E2=80=99s server=E2=80=99=
s IP address.&nbsp;</div><div><br></div></div><div><div>Using&nbsp;tempor=
ary private IP address we can also achieve the goal of =E2=80=9Creachabil=
ity=E2=80=9D. =46or example, using dynamic DNS, as shown in &nbsp;<a href=
=3D=22http://hsk.oray.com/=22>http://hsk.oray.com/</a>&nbsp;, it can &nbs=
p;provide reachability even the host get a private IP address.</div><div>=
<br></div></div></div></blockquote><div><br></div><div>You had said this =
before, and I had explained it.</div><div>Nevertheless, let me recap:</di=
v><div>You cannot ensure an ongoing IP flow continues w/o interruption if=
 you simply rely on dynamic DNS. Ongoing flows break even if you update t=
he DNS.</div><div>=46urthermore, even if you ignore the ongoing flows, al=
so note that DNS clients have a cache, hence a dynamic DNS update cannot =
be instantaneously reflected on the hosts.&nbsp;</div><div>So, you cannot=
 provide full mobility solution by relying on dynamic DNS.</div><div><br>=
</div><br></div></div></span></div></blockquote><div>The point here is =E2=
=80=9Creachability=E2=80=9D instead of =E2=80=9Cmobility=E2=80=9D.&nbsp;<=
/div><div>=46urther more, even mobile IP may lost some packet during hand=
over.&nbsp;</div></div></blockquote><div><br></div><div>Not sure if this =
point has any impact on the discussion.</div><div><br></div><br></div></d=
iv></div></span></blockquote><div>The point is: in the draft, &nbsp;wheth=
er support =E2=80=9Creachability=E2=80=9D is the distinction between =E2=80=
=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D, but the truth i=
s any type of IP address can provide =E2=80=9Creachability=E2=80=9D. So t=
here is no clear dividing line between &nbsp;=E2=80=9Cfixed IP=E2=80=9D a=
nd =E2=80=9C sustained IP=E2=80=9D in the definition. That is why the def=
inition of the IP types is not valid.</div><blockquote type=3D=22cite=22 =
style=3D=22border-left-style:solid;border-width:1px;margin-left:0px;paddi=
ng-left:10px;=22><span><div><div><div><blockquote type=3D=22cite=22><div>=
<blockquote type=3D=22cite=22><div><span><div><div><blockquote type=3D=22=
cite=22><div><div>3. Regarding the definition of =E2=80=9Cnomadic IP addr=
ess=E2=80=9D:</div><div><br></div><div>=E2=80=9C<span style=3D=22font-siz=
e: 1em; white-space: pre-wrap; widows: 1;=22>- Nomadic IP Address</span><=
/div><pre style=3D=22font-size: 1em; margin-top: 0px; margin-bottom: 0px;=
 page-break-before: always; widows: 1;=22>   This type of IP address prov=
ides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&=
nbsp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; w=
idows: 1;=22>   host.</span>=E2=80=9D</div><div><br></div><div>Seems this=
 IP address is the IP address that we normally used in most cases. If thi=
s is the case, why we need a new name for it=3F</div><div><br></div></div=
></blockquote><div><br></div><div><br></div><div>If you don't name it, ho=
w would you refer to it in this context=3F</div></div></div></span></div>=
</blockquote><div>If the justification of naming IP address as =E2=80=9Cf=
ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w=
e may not necessary need a new name for normal IP address.</div><div><br>=
</div></div></blockquote><div><br></div><div>I and the WT=231 believe tha=
t justification is valid.</div><div>If you believe otherwise, please elab=
orate.</div></div></div></div></span></blockquote><div>Pls see above comm=
ent.</div><div><br></div><div>Dapeng&nbsp;</div><blockquote type=3D=22cit=
e=22 style=3D=22border-left-style:solid;border-width:1px;margin-left:0px;=
padding-left:10px;=22><span><div><div><div><div><br></div><div>Alper</div=
><div><br></div><div><br></div><br><blockquote type=3D=22cite=22><div><di=
v><br></div><div>Dapeng&nbsp;</div><blockquote type=3D=22cite=22><div><sp=
an><div><div><div><br></div><div><br></div><div>Alper</div><div><br></div=
><br><blockquote type=3D=22cite=22><div><div><div><br></div><div>--&nbsp;=
</div><div>Dapeng Liu</div><div><br></div></div><p style=3D=22color: =23A=
0A0A8;=22>=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=
=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=
=81=93=EF=BC=9A</p><blockquote type=3D=22cite=22><div>
                    <span><div><div><div>Hello Dapeng and Alex,</div><div=
><br></div><div>I hope you had a chance to digest our responses to your c=
omments and questions about the API work.</div><div>If you have any remai=
ning issues, please let us know over the email at your earliest convenien=
ce.</div><div>It'd be good if you can articulate them in detail.</div><di=
v><br></div><div><br></div><div>Thanks.</div><div><br></div><div>Alper</d=
iv></div></div></span>
                  =20
                  =20
                  =20
                  =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--551361b1_55c3594c_a9e--


From nobody Wed Mar 25 21:26:16 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4665D1A90A1 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4VZdOTHdbrc for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:26:12 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE61A9080 for <dmm@ietf.org>; Wed, 25 Mar 2015 21:26:12 -0700 (PDT)
Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MUWvt-1Z0fDd0kJH-00RGSR; Thu, 26 Mar 2015 05:26:10 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=utf-8
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <55134244.602@gmail.com>
Date: Thu, 26 Mar 2015 06:26:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F067406-0687-40AF-A2EB-65CAD8005B69@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <55134244.602@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:Qhlzr2OWdkbqXqYDbGwiMt0gXZY+l7lpX7Rc4RsfOCumGm6XG7J y2+z92hSTQuh8UpcT+48f+SZOB9wopPulbljP0jYrP6C0P3+yhwaTzHboyqjj0gyft56vP6 XQJBbvqbhh8rl21LwcqIvVkwsA/vvTOU1Yx/Cw43vvKR6JC8MIzlaEcjzh5X65k9DUuz9X8 UzzeElMrcZ96tSnFxqd3g==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/ZC0SBYlky3UrpnrayIUnYZrwuw4>
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 04:26:14 -0000

>>> I still have the following comments:
>>>=20
>>> 1. Regarding the definition of =E2=80=9Cfixed IP address=E2=80=9D in =
the draft:
>>>=20
>>>  =E2=80=9C- Fixed IP Address
>>>    This is what standard Mobile IP provides with a Home Address =
(HoA).
>>>    The mobile host is configures a HoA from a centrally-located Home
>>>    Network.  Both IP session continuity and IP address reachability =
are
>>>    provided to the mobile host with the help of a router in the Home
>>>    Network (Home Agent, HA).  This router acts as an anchor for the =
IP
>>> address of the mobile host.=E2=80=9D
>>>=20
>>> If this is equal to HoA, then RFC5014 already cover that. We do not
>>> need to repeat it here with another name.
>>>=20
>>=20
>>=20
>> This is not equal to "HoA".
>> This is equal to "HoA permanently allocated on a HA in the core =
network" [1]
>> (as opposed to "HoA temporarily allocated on a HA in the access =
network") [2]
>=20
> So that's a HoA, and RFC5014 already covers that, right?

No. I tried to explain it below, that it's not just "HoA".
[1] provides a fixed IP address,
[2] provides a sustained IP address.

That distinction is not captured when you call it "HoA".


>=20
>>> 2. Regarding the definition of =E2=80=9Csustained IP address=E2=80=9D =
in the draft:
>>>=20
>>> "- Sustained IP Address
>>>=20
>>>    This type of IP address provides IP session continuity but not IP
>>>    address reachability.  It is achieved by ensuring that the IP =
address
>>>    used at the beginning of the session remains usable despite the
>>>    movement of the mobile host.  The IP address may change after the
>>>    termination of the IP session(s), therefore it does not exhibit
>>>    persistence.
>>> "
>>> There is no clear dividing line between fixed IP address and =
sustained
>>> IP address. Whether the IP address is used for reachability is not
>>> determined by the IP address itself. For example, even when the MN =
get
>>> a HoA, after it moves to another location of the network, it may
>>> decide to release current HoA and get another HoA, in this case the
>>> "fixed IP address" becomes a "sustained IP address".
>>>=20
>>=20
>> If the IP stack on the host releases the IP address, then of course =
it's
>> not a "fixed IP address".
>> Please see the definitions of these terms in the I-D.
>>=20
>>=20
>>> Further more, the reachability normally is implemented by domain =
name
>>> instead of IP address. For example, we reach =E2=80=9CGoogle=E2=80=9D =
by its domain
>>> name, never by it=E2=80=99s server=E2=80=99s IP address.
>>>=20
>>> Using temporary private IP address we can also achieve the goal of
>>> =E2=80=9Creachability=E2=80=9D. For example, using dynamic DNS, as =
shown in
>>> http://hsk.oray.com/ , it can  provide reachability even the host =
get
>>> a private IP address.
>>>=20
>>=20
>> You had said this before, and I had explained it.
>> Nevertheless, let me recap:
>> You cannot ensure an ongoing IP flow continues w/o interruption if =
you
>> simply rely on dynamic DNS. Ongoing flows break even if you update =
the DNS.
>=20
> But Dapeng talks about reachability, not about session continuity.  In =
that sense he's right, no? (DNS updates ensure reachability upon address =
change).

it's not "IP address" reachability. When the host releases its IP =
address, that IP address is no longer reachable.=20

>=20
> Even I would go as far as to say that _some_ application flows will =
resist to changes in that IP address and get restarted with the new =
address if that DNS update process was performed.
>=20
> This is because the concept of 'flow' is very much ambiguous.  Very =
rarely a read in packet dump can show 'flows' as we talk commonly about =
them in the DMM discussions.  It is for this reason that there is no =
option in Wireshark that groups packets in 'flows', like a mail reader =
would group messages into 'conversations' or 'threads'.
>=20
> It is for this reason too that firewall rules trying to be smart and =
identify 'flows' before blocking them very often fail, even if we do =
Deep Packet Inspection.  People always find ways to 'drill' through =
these rules.
>=20
>> Furthermore, even if you ignore the ongoing flows, also note that DNS
>> clients have a cache, hence a dynamic DNS update cannot be
>> instantaneously reflected on the hosts.
>=20
> I can agree to that.  I guess though there may be forced updates on =
these caches, or that the timers can be configured shorter in domains =
supporting mobility.


Nope, not practical. You need to enforce that on all possible hosts that =
may be in comm. with the MN across the Internet. Can't do that.
>=20
>> So, you cannot provide full mobility solution by relying on dynamic =
DNS.
>=20
> We dont know what full mobility is, and DNS updates is a good tool to =
provide reachability and session continuity, in some cases.
>=20

Full mobility is what you get out of Mobile IP.
You cannot achieve the same effect using dynamic DNS.

Alper




> Alex
>=20
>>=20
>>=20
>>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:
>>>=20
>>> =E2=80=9C- Nomadic IP Address
>>>    This type of IP address provides neither IP session continuity =
nor IP
>>>    address reachability.  The IP address is obtained from the =
serving IP
>>>    gateway and it is not maintained across gateway changes.  In =
other
>>>    words, the IP address may be released and replaced by a new IP
>>>    address when the IP gateway changes due to the movement of the =
mobile
>>> host.=E2=80=9D
>>>=20
>>> Seems this IP address is the IP address that we normally used in =
most
>>> cases. If this is the case, why we need a new name for it?
>>>=20
>>=20
>>=20
>> If you don't name it, how would you refer to it in this context?
>>=20
>>=20
>> Alper
>>=20
>>=20
>>>=20
>>> --
>>> Dapeng Liu
>>>=20
>>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =
=E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper =
Yegin =E5=86=99=E9=81=93=EF=BC=9A
>>>=20
>>>> Hello Dapeng and Alex,
>>>>=20
>>>> I hope you had a chance to digest our responses to your comments =
and
>>>> questions about the API work.
>>>> If you have any remaining issues, please let us know over the email
>>>> at your earliest convenience.
>>>> It'd be good if you can articulate them in detail.
>>>>=20
>>>>=20
>>>> Thanks.
>>>>=20
>>>> Alper
>>>=20
>>=20
>=20
>=20


From nobody Wed Mar 25 21:29:33 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E381A90A8 for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85IAsazGVNGk for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:29:27 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA16E1A90B4 for <dmm@ietf.org>; Wed, 25 Mar 2015 21:29:26 -0700 (PDT)
Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MJDJ6-1Ycd361RVa-002pVM; Thu, 26 Mar 2015 05:29:26 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <5513446A.4060307@gmail.com>
Date: Thu, 26 Mar 2015 06:29:25 +0200
Message-Id: <1706A923-62A2-4964-90B1-8FBDE63C51D1@yegin.org>
References: <5513446A.4060307@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:GuYf2yTTQSD4NN7A92TT++DoysyH3pWcIr91dqJCyjCGZtugGOa 8jPdavVaWZY6E+fQxrNtY+Vw8Ocgmfk2rB89+wQ5ifmEU7fyjQGhco6Iwv3Z4nnoKunnCkC xwB0p+AhbS1gbZNUf48n+e6J5V+LcrPeLaHn5u3G6qbgR+KSI8G1LvKBQ8OB8zmO354IYGQ m3jTcQ5T5UvznUHGA9+FA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/R7x2cDozHks3JhhdmWjZLTuH6f8>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] SUSTAINED, NOMADIC, FIXED: existing kinds, lifetimes
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 04:29:31 -0000

--Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On Mar 26, 2015, at 1:27 AM, Alexandru Petrescu wrote:

> Alper, authors of draft-yegin-dmm-ondemand-mobility-03,
> 
> I would like to ask how do you see the relationships between
> other kinds of addresses (HoW, CoA, LL, GUA, ULA, NATTed, privacy,
> multicast) and the SUSTAINED, NOMADIC, FIXED addresses.
> 

Alex, do you remember you had asked that question, and I had answered it?
Here: http://www.ietf.org/mail-archive/web/dmm/current/msg01814.html

> In addition, I think there may be a relationship with the lifetimes of
> the addresses generated by existing address configuration mechanisms.
> 

Please explain the relationship.

Alper





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


--Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Mar 26, 2015, at 1:27 AM, Alexandru Petrescu =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Alper, authors of =
draft-yegin-dmm-ondemand-mobility-03,<br><br>I would like to ask how do =
you see the relationships between<br>other kinds of addresses (HoW, CoA, =
LL, GUA, ULA, NATTed, privacy,<br>multicast) and the SUSTAINED, NOMADIC, =
FIXED addresses.<br><br></div></blockquote><div><br></div><div>Alex, do =
you remember you had asked that question, and I had answered =
it?</div><div>Here:&nbsp;<a =
href=3D"http://www.ietf.org/mail-archive/web/dmm/current/msg01814.html">ht=
tp://www.ietf.org/mail-archive/web/dmm/current/msg01814.html</a></div><br>=
<blockquote type=3D"cite"><div>In addition, I think there may be a =
relationship with the lifetimes of<br>the addresses generated by =
existing address configuration =
mechanisms.<br><br></div></blockquote><div><br></div><div>Please explain =
the =
relationship.</div><div><br></div><div>Alper</div><div><br></div><div><br>=
</div><div><br></div><div><br></div><br><blockquote =
type=3D"cite"><div>Alex<br><br><br>_______________________________________=
________<br>dmm mailing list<br><a =
href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/dmm<br></div></blockquote></div><br></body></html>=

--Apple-Mail=_5EF4A945-10D0-44CC-B72E-F31B5A52810C--


From nobody Wed Mar 25 21:43:24 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA91A89FD for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MkH0LOSLqIW for <dmm@ietfa.amsl.com>; Wed, 25 Mar 2015 21:43:21 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C761A9141 for <dmm@ietf.org>; Wed, 25 Mar 2015 21:43:20 -0700 (PDT)
Received: from [192.168.0.66] ([50.84.137.11]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0MT99c-1Z22Q42Mbe-00SHIv; Thu, 26 Mar 2015 05:43:19 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <52AC56D3ADC0481CBF02BAADF720991B@gmail.com>
Date: Thu, 26 Mar 2015 06:42:33 +0200
Message-Id: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com>
To: Dapeng Liu <maxpassion@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:eWXuox4hEkJkrcjZpuTOPrGOdiCfoK8OcMu8tBdVSPwsoZX3f65 uYqrw49LNAWCtjByYRPlTZW8RYFdAw9XGKMyAL3LI47dtKoeu5oHgrMy0k1kIvih5BcC9S+ QyVGA9VYNA8839ClPRLOh8yMqxRumMuN2JaE4Z9njLERzBgAlp9mUEDV99tMth+Kg3FcqWk LiJzAO9nym4gjI1FOXdbg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/-idATh3X8xLOF0OMrP-OyO13f0Y>
Cc: dmm@ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBBUEk=?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 04:43:22 -0000

--Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> The point is: in the draft,  whether support =E2=80=9Creachability=E2=80=
=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C =
sustained IP=E2=80=9D, but the truth is any type of IP address can =
provide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing =
line between  =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D=
 in the definition. That is why the definition of the IP types is not =
valid.


"IP address reachability" is about ability to reach the host at a =
specific "IP address" even when the host changes its point of =
attachment.
You seem to interpret it as if it said "IP reachability" (ability to =
reach the host using IP protocol), but that's not the case.

That term is already defined in the I-D:

   IP address reachability: The ability to maintain the same IP address
   for an extended period of time.  The IP address stays the same across
   independent IP sessions, and even in the absence of any IP session.
   The IP address may be published in a long-term registry (e.g., DNS),
   and it is made available for serving incoming (e.g., TCP)
   connections.  IP address reachability is essential for mobile hosts
   to use specific/published IP addresses.


>>>>> 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D:=

>>>>>=20
>>>>> =E2=80=9C- Nomadic IP Address
>>>>>    This type of IP address provides neither IP session continuity =
nor IP
>>>>>    address reachability.  The IP address is obtained from the =
serving IP
>>>>>    gateway and it is not maintained across gateway changes.  In =
other
>>>>>    words, the IP address may be released and replaced by a new IP
>>>>>    address when the IP gateway changes due to the movement of the =
mobile=20
>>>>>    host.=E2=80=9D
>>>>>=20
>>>>> Seems this IP address is the IP address that we normally used in =
most cases. If this is the case, why we need a new name for it?
>>>>>=20
>>>>=20
>>>>=20
>>>> If you don't name it, how would you refer to it in this context?
>>> If the justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D=
 and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not =
necessary need a new name for normal IP address.
>>>=20
>>=20
>> I and the WT#1 believe that justification is valid.
>> If you believe otherwise, please elaborate.
> Pls see above comment.
>=20
> Dapeng=20
>>=20
>> Alper
>>=20
>>=20
>>=20
>>>=20
>>> Dapeng=20
>>>>=20
>>>>=20
>>>> Alper
>>>>=20
>>>>=20
>>>>>=20
>>>>> --=20
>>>>> Dapeng Liu
>>>>>=20
>>>>> =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =
=E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper =
Yegin =E5=86=99=E9=81=93=EF=BC=9A
>>>>>=20
>>>>>> Hello Dapeng and Alex,
>>>>>>=20
>>>>>> I hope you had a chance to digest our responses to your comments =
and questions about the API work.
>>>>>> If you have any remaining issues, please let us know over the =
email at your earliest convenience.
>>>>>> It'd be good if you can articulate them in detail.
>>>>>>=20
>>>>>>=20
>>>>>> Thanks.
>>>>>>=20
>>>>>> Alper
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite"><div>The point is: in the draft, =
&nbsp;whether support =E2=80=9Creachability=E2=80=9D is the distinction =
between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D, =
but the truth is any type of IP address can provide =E2=80=9Creachability=E2=
=80=9D. So there is no clear dividing line between &nbsp;=E2=80=9Cfixed =
IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in the definition. That =
is why the definition of the IP types is not =
valid.</div></blockquote><div><br></div><div><br></div><div>"IP address =
reachability" is about ability to reach the host at a specific "IP =
address" even when the host changes its point of =
attachment.</div><div>You seem to interpret it as if it said "IP =
reachability" (ability to reach the host using IP protocol), but that's =
not the case.</div><div><br></div><div>That term is already defined in =
the I-D:</div><div><br></div><div><pre style=3D"color: rgb(0, 0, 0); =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: =
0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: =
pre-wrap;">   IP address reachability: The ability to maintain the same =
IP address
   for an extended period of time.  The IP address stays the same across
   independent IP sessions, and even in the absence of any IP session.
   The IP address may be published in a long-term registry (e.g., DNS),
   and it is made available for serving incoming (e.g., TCP)
   connections.  IP address reachability is essential for mobile hosts
   to use specific/published IP =
addresses.</pre><div><br></div></div><div><br></div><blockquote =
type=3D"cite"><blockquote type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><div><blockquote =
type=3D"cite"><div><blockquote =
type=3D"cite"><div><span><div><div><blockquote type=3D"cite"><div><div>3. =
Regarding the definition of =E2=80=9Cnomadic IP =
address=E2=80=9D:</div><div><br></div><div>=E2=80=9C<span =
style=3D"font-size: 1em; white-space: pre-wrap; widows: 1;">- Nomadic IP =
Address</span></div><pre style=3D"font-size: 1em; margin-top: 0px; =
margin-bottom: 0px; page-break-before: always; widows: 1;">   This type =
of IP address provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"font-size: 1em; white-space: =
pre-wrap; widows: 1;">   host.</span>=E2=80=9D</div><div><br></div><div>Se=
ems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for =
it?</div><div><br></div></div></blockquote><div><br></div><div><br></div><=
div>If you don't name it, how would you refer to it in this =
context?</div></div></div></span></div></blockquote><div>If the =
justification of naming IP address as =E2=80=9Cfixed IP=E2=80=9D and =E2=80=
=9C sustained IP=E2=80=9D is not valid, then we may not necessary need a =
new name for normal IP =
address.</div><div><br></div></div></blockquote><div><br></div><div>I =
and the WT#1 believe that justification is valid.</div><div>If you =
believe otherwise, please =
elaborate.</div></div></div></div></span></blockquote><div>Pls see above =
comment.</div><div><br></div><div>Dapeng&nbsp;</div><blockquote =
type=3D"cite" =
style=3D"border-left-style:solid;border-width:1px;margin-left:0px;padding-=
left:10px;"><span><div><div><div><div><br></div><div>Alper</div><div><br><=
/div><div><br></div><br><blockquote =
type=3D"cite"><div><div><br></div><div>Dapeng&nbsp;</div><blockquote =
type=3D"cite"><div><span><div><div><div><br></div><div><br></div><div>Alpe=
r</div><div><br></div><br><blockquote =
type=3D"cite"><div><div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div></div><p style=3D"color: #A0A0A8;">=E5=9C=A8 =
2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=
=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p><bl=
ockquote type=3D"cite"><div>
                    <span><div><div><div>Hello Dapeng and =
Alex,</div><div><br></div><div>I hope you had a chance to digest our =
responses to your comments and questions about the API =
work.</div><div>If you have any remaining issues, please let us know =
over the email at your earliest convenience.</div><div>It'd be good if =
you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span>
                  =20
                  =20
                  =20
                  =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            </blockquote></div><br></body></html>=

--Apple-Mail=_02FA2D98-7970-4515-962C-2B80DF6C0C6A--


From nobody Thu Mar 26 10:39:22 2015
Return-Path: <weixinpeng@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC531A8F37 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2WSGEYqQl2V for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:39:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31E81A8F4D for <dmm@ietf.org>; Thu, 26 Mar 2015 10:39:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT03315; Thu, 26 Mar 2015 17:39:16 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 17:39:15 +0000
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 01:39:11 +0800
From: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
To: Dapeng Liu <maxpassion@gmail.com>, Alper Yegin <alper.yegin@yegin.org>
Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?=
Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPg==
Date: Thu, 26 Mar 2015 17:39:10 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.156.153]
Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/N2mlfXD0648JTVsbovuLtJGbKA8>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] =?gb2312?b?UmWjuiBETU0gQVBJ?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 17:39:21 -0000

--_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxwZXINCg0KTXkgdW5kZXJzdGFuZGluZyBhYm91dCB0aGUgcmVhc29uIHdoeSB0aGVyZSBu
ZWVkcyB0byBkZWZpbmUgc2VydmFsIHR5cGVzIG9mIElQIHByZWZpeGVzIGlzIHRoYXQsICBpZiB0
aGUgYXBwbGljYXRpb24gaXRzZWxmIGNvdWxkIGRlYWwgd2l0aCB0aGUgY2hhbmdlIG9mIElQIGFk
ZHJlc3MsIGkuZS4gdGhlIGFwcGxpY2F0aW9uIGl0c2VsZiBjb3VsZCBkZWFsIHdpdGggc2Vzc2lv
biBjb250aW51dHkgaW4gY2FzZSBvZiBJUCBhZGRyZXNzIGNoYW5nZSwgc28gdGhlIGhvc3Qgd291
bGQgY2hvb3NlIGEgbm9ybWFkaWMgYWRkcmVzcyBvdGhlcndpc2UgdGhlIGhvc3Qgc2hvdWxkIGNo
b29zZSBhIHN1c3RhaW5lZCBhZGRyZXNzLg0KDQpCdXQgbXkgcXVlc3Rpb24gaXMgdGhhdCwgaWYg
dGhlIGFwcGxpY2F0aW9uIGNvdWxkIGRlYWwgd2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpdHNlbGYs
IGRvZXMgdGhhdCBtZWFuIHRoZSBhcHBsaWNhdGlvbiBpcyB3aWxsaW5nIHRvIGNoYW5nZSBpdHMg
SVAgYWRkcmVzcz8gQmVjYXVzZSBldmVuIHRob3VnaCBhIG5ldyBhZGRyZXNzIG1pZ2h0IGJyaW5n
IHNvbWUga2luZHMgb2YgYmVuZWZpdCwgYnV0IGl0IHdpbGwgYWxzbw0KDQpicmluZyBhZGRpdGlv
bmFsIGNvc3QgZm9yIGFwcGxpY2F0aW9uIHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZS4N
Cg0KVGhhbmtzLg0KDQoNCg0KWGlucGVuZw0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQq3orz+yMs6IGRtbSBbZG1tLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gRGFw
ZW5nIExpdSBbbWF4cGFzc2lvbkBnbWFpbC5jb21dDQq3osvNyrG85DogMjAxNcTqM9TCMjbI1SA1
OjAxDQrK1bz+yMs6IEFscGVyIFllZ2luDQqzrcvNOiBkbW1AaWV0Zi5vcmcNCtb3zOI6IFtETU1d
ILvYuLSjuiBETU0gQVBJDQoNCkhlbGxvIEFscGVyLA0KDQpJIHN0aWxsIGhhdmUgdGhlIGZvbGxv
d2luZyBjb21tZW50czoNCg0KMS4gUmVnYXJkaW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwZml4ZWQg
SVAgYWRkcmVzc6GxIGluIHRoZSBkcmFmdDoNCg0KICChsC0gRml4ZWQgSVAgQWRkcmVzcw0KDQog
ICBUaGlzIGlzIHdoYXQgc3RhbmRhcmQgTW9iaWxlIElQIHByb3ZpZGVzIHdpdGggYSBIb21lIEFk
ZHJlc3MgKEhvQSkuDQogICBUaGUgbW9iaWxlIGhvc3QgaXMgY29uZmlndXJlcyBhIEhvQSBmcm9t
IGEgY2VudHJhbGx5LWxvY2F0ZWQgSG9tZQ0KICAgTmV0d29yay4gIEJvdGggSVAgc2Vzc2lvbiBj
b250aW51aXR5IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSBhcmUNCiAgIHByb3ZpZGVkIHRv
IHRoZSBtb2JpbGUgaG9zdCB3aXRoIHRoZSBoZWxwIG9mIGEgcm91dGVyIGluIHRoZSBIb21lDQog
ICBOZXR3b3JrIChIb21lIEFnZW50LCBIQSkuICBUaGlzIHJvdXRlciBhY3RzIGFzIGFuIGFuY2hv
ciBmb3IgdGhlIElQDQoNCmFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBob3N0LqGxDQoNCklmIHRoaXMg
aXMgZXF1YWwgdG8gSG9BLCB0aGVuIFJGQzUwMTQgYWxyZWFkeSBjb3ZlciB0aGF0LiBXZSBkbyBu
b3QgbmVlZCB0byByZXBlYXQgaXQgaGVyZSB3aXRoIGFub3RoZXIgbmFtZS4NCg0KMi4gUmVnYXJk
aW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwc3VzdGFpbmVkIElQIGFkZHJlc3OhsSBpbiB0aGUgZHJh
ZnQ6DQoNCg0KIi0gU3VzdGFpbmVkIElQIEFkZHJlc3MNCg0KICAgVGhpcyB0eXBlIG9mIElQIGFk
ZHJlc3MgcHJvdmlkZXMgSVAgc2Vzc2lvbiBjb250aW51aXR5IGJ1dCBub3QgSVANCiAgIGFkZHJl
c3MgcmVhY2hhYmlsaXR5LiAgSXQgaXMgYWNoaWV2ZWQgYnkgZW5zdXJpbmcgdGhhdCB0aGUgSVAg
YWRkcmVzcw0KICAgdXNlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uIHJlbWFpbnMg
dXNhYmxlIGRlc3BpdGUgdGhlDQogICBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QuICBUaGUg
SVAgYWRkcmVzcyBtYXkgY2hhbmdlIGFmdGVyIHRoZQ0KICAgdGVybWluYXRpb24gb2YgdGhlIElQ
IHNlc3Npb24ocyksIHRoZXJlZm9yZSBpdCBkb2VzIG5vdCBleGhpYml0DQogICBwZXJzaXN0ZW5j
ZS4NCiINCg0KVGhlcmUgaXMgbm8gY2xlYXIgZGl2aWRpbmcgbGluZSBiZXR3ZWVuIGZpeGVkIElQ
IGFkZHJlc3MgYW5kIHN1c3RhaW5lZCBJUCBhZGRyZXNzLiBXaGV0aGVyIHRoZSBJUCBhZGRyZXNz
IGlzIHVzZWQgZm9yIHJlYWNoYWJpbGl0eSBpcyBub3QgZGV0ZXJtaW5lZCBieSB0aGUgSVAgYWRk
cmVzcyBpdHNlbGYuIEZvciBleGFtcGxlLCBldmVuIHdoZW4gdGhlIE1OIGdldCBhIEhvQSwgYWZ0
ZXIgaXQgbW92ZXMgdG8gYW5vdGhlciBsb2NhdGlvbiBvZiB0aGUgbmV0d29yaywgaXQgbWF5IGRl
Y2lkZSB0byByZWxlYXNlIGN1cnJlbnQgSG9BIGFuZCBnZXQgYW5vdGhlciBIb0EsIGluIHRoaXMg
Y2FzZSB0aGUgImZpeGVkIElQIGFkZHJlc3MiIGJlY29tZXMgYSAic3VzdGFpbmVkIElQIGFkZHJl
c3MiLg0KDQpGdXJ0aGVyIG1vcmUsIHRoZSByZWFjaGFiaWxpdHkgbm9ybWFsbHkgaXMgaW1wbGVt
ZW50ZWQgYnkgZG9tYWluIG5hbWUgaW5zdGVhZCBvZiBJUCBhZGRyZXNzLiBGb3IgZXhhbXBsZSwg
d2UgcmVhY2ggobBHb29nbGWhsSBieSBpdHMgZG9tYWluIG5hbWUsIG5ldmVyIGJ5IGl0oa9zIHNl
cnZlcqGvcyBJUCBhZGRyZXNzLg0KDQpVc2luZyB0ZW1wb3JhcnkgcHJpdmF0ZSBJUCBhZGRyZXNz
IHdlIGNhbiBhbHNvIGFjaGlldmUgdGhlIGdvYWwgb2YgobByZWFjaGFiaWxpdHmhsS4gRm9yIGV4
YW1wbGUsIHVzaW5nIGR5bmFtaWMgRE5TLCBhcyBzaG93biBpbiAgaHR0cDovL2hzay5vcmF5LmNv
bS8gLCBpdCBjYW4gIHByb3ZpZGUgcmVhY2hhYmlsaXR5IGV2ZW4gdGhlIGhvc3QgZ2V0IGEgcHJp
dmF0ZSBJUCBhZGRyZXNzLg0KDQozLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBub21h
ZGljIElQIGFkZHJlc3OhsToNCg0KobAtIE5vbWFkaWMgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5
cGUgb2YgSVAgYWRkcmVzcyBwcm92aWRlcyBuZWl0aGVyIElQIHNlc3Npb24gY29udGludWl0eSBu
b3IgSVANCiAgIGFkZHJlc3MgcmVhY2hhYmlsaXR5LiAgVGhlIElQIGFkZHJlc3MgaXMgb2J0YWlu
ZWQgZnJvbSB0aGUgc2VydmluZyBJUA0KICAgZ2F0ZXdheSBhbmQgaXQgaXMgbm90IG1haW50YWlu
ZWQgYWNyb3NzIGdhdGV3YXkgY2hhbmdlcy4gIEluIG90aGVyDQogICB3b3JkcywgdGhlIElQIGFk
ZHJlc3MgbWF5IGJlIHJlbGVhc2VkIGFuZCByZXBsYWNlZCBieSBhIG5ldyBJUA0KICAgYWRkcmVz
cyB3aGVuIHRoZSBJUCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3ZlbWVudCBvZiB0aGUg
bW9iaWxlDQoNCmhvc3QuobENCg0KU2VlbXMgdGhpcyBJUCBhZGRyZXNzIGlzIHRoZSBJUCBhZGRy
ZXNzIHRoYXQgd2Ugbm9ybWFsbHkgdXNlZCBpbiBtb3N0IGNhc2VzLiBJZiB0aGlzIGlzIHRoZSBj
YXNlLCB3aHkgd2UgbmVlZCBhIG5ldyBuYW1lIGZvciBpdD8NCg0KDQotLQ0KRGFwZW5nIExpdQ0K
DQoNCtTaIDIwMTXE6jPUwjI1yNUg0MfG2sj9o6zPws7nMjowMqOsQWxwZXIgWWVnaW4g0LS1wKO6
DQoNCkhlbGxvIERhcGVuZyBhbmQgQWxleCwNCg0KSSBob3BlIHlvdSBoYWQgYSBjaGFuY2UgdG8g
ZGlnZXN0IG91ciByZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGFib3V0
IHRoZSBBUEkgd29yay4NCklmIHlvdSBoYXZlIGFueSByZW1haW5pbmcgaXNzdWVzLCBwbGVhc2Ug
bGV0IHVzIGtub3cgb3ZlciB0aGUgZW1haWwgYXQgeW91ciBlYXJsaWVzdCBjb252ZW5pZW5jZS4N
Ckl0J2QgYmUgZ29vZCBpZiB5b3UgY2FuIGFydGljdWxhdGUgdGhlbSBpbiBkZXRhaWwuDQoNCg0K
VGhhbmtzLg0KDQpBbHBlcg0KDQo=

--_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<p>Hi Alper</p>
<p>My understanding about the reason why there needs to define&nbsp;serval =
types&nbsp;of IP prefixes is that, &nbsp;if the application itself could de=
al with the change of IP address, i.e. the application itself could deal wi=
th session continuty in case of IP address change,
 so the host would choose a normadic address otherwise the host should choo=
se a sustained address.</p>
<p>But my question is that, if the application could deal with session cont=
inuty itself, does that mean the application is willing to change its IP ad=
dress? Because even though a new address might bring some kinds of benefit,=
 but it will also</p>
<p>bring additional cost for application to deal with IP address change.</p=
>
<p>Thanks.</p>
<p>&nbsp;</p>
<p>Xinpeng</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF991546"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b> dmm [dmm-bounces@ietf.=
org] =B4=FA=B1=ED Dapeng Liu [maxpassion@gmail.com]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b> 2015=C4=EA3=D4=C226=C8=D5 5:01<br>
<b>=CA=D5=BC=FE=C8=CB:</b> Alper Yegin<br>
<b>=B3=AD=CB=CD:</b> dmm@ietf.org<br>
<b>=D6=F7=CC=E2:</b> [DMM] =BB=D8=B8=B4=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>
<div>Hello Alper, </div>
<div><br>
</div>
<div>I still have the following comments:</div>
<div><br>
</div>
<div>1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra=
ft:</div>
<div><br>
</div>
<div>&nbsp; =A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZ=
E: 1em">- Fixed IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This is what standard Mo=
bile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nbsp=
;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">addre=
ss of the mobile host.</span>=A1=B1&nbsp;</div>
<div><br>
</div>
<div>If this is equal to HoA, then RFC5014 already cover that. We do not ne=
ed to repeat it here with another name.</div>
<div><br>
</div>
<div>2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the=
 draft:</div>
<div><br>
</div>
<div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">&quot;- Sustained IP Addres=
s

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
&quot;</pre>
</div>
<div>
<div>There is no clear dividing line between fixed IP address and sustained=
 IP address. Whether the IP address is used for reachability is not determi=
ned by the IP address itself. For example, even when the MN get a HoA, afte=
r it moves to another location of
 the network, it may decide to release current HoA and get another HoA, in =
this case the &quot;fixed IP address&quot; becomes a &quot;sustained IP add=
ress&quot;.</div>
<div><br>
</div>
<div>Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma=
in name, never by it=A1=AFs server=A1=AFs IP address.&nbsp;</div>
<div><br>
</div>
<div>Using&nbsp;temporary private IP address we can also achieve the goal o=
f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb=
sp;<a href=3D"http://hsk.oray.com/" target=3D"_blank">http://hsk.oray.com/<=
/a>&nbsp;, it can &nbsp;provide reachability even the host get a private
 IP address.</div>
<div><br>
</div>
<div>3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:</div>
<div><br>
</div>
<div>=A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em"=
>- Nomadic IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This type of IP address =
provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&nb=
sp;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">host.=
</span>=A1=B1</div>
<div><br>
</div>
<div>Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?</div>
<div><br>
</div>
<div><br>
</div>
<div>--&nbsp;</div>
<div>Dapeng Liu</div>
<div><br>
</div>
<div></div>
</div>
<p style=3D"COLOR: #a0a0a8">=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=
=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA</p>
<blockquote style=3D"BORDER-LEFT: 1px solid; BORDER-RIGHT-WIDTH: 1px; PADDI=
NG-LEFT: 10px; BORDER-TOP-WIDTH: 1px; BORDER-BOTTOM-WIDTH: 1px; MARGIN-LEFT=
: 0px" type=3D"cite">
<span>
<div>
<div>
<div>Hello Dapeng and Alex,</div>
<div><br>
</div>
<div>I hope you had a chance to digest our responses to your comments and q=
uestions about the API work.</div>
<div>If you have any remaining issues, please let us know over the email at=
 your earliest convenience.</div>
<div>It'd be good if you can articulate them in detail.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>Alper</div>
</div>
</div>
</span></blockquote>
<div><br>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_C5C3BB522B1DDF478AA09545169155B46E331EE0nkgeml507mbxchi_--


From nobody Thu Mar 26 10:53:23 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CD41A8AED for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level: 
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdTSSF_URbLG for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:53:20 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2F81A8F3A for <dmm@ietf.org>; Thu, 26 Mar 2015 10:53:08 -0700 (PDT)
Received: by wibbg6 with SMTP id bg6so73981392wib.0 for <dmm@ietf.org>; Thu, 26 Mar 2015 10:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=kcI/OyCfumQbvTOTVt9wA55XirBkzu6wXL2TGJYDiHc=; b=SyIS32T7obBgTCWgPT7oFcma4yWBjaEDXP6mOYw9wZ4j+qeqcsy5Wjn5V8QGwjrnio W6jzqYRUQZri6BhJqRsuA9ebv96kKUeQO+wooUlB64ljKuNPExj0s4ONHkwACCvEN10v oNECm+Ifh2DysChZAYQ5EV/4Z8BcDnRRhCXs6ckEz0eDVLXCYq3O4XeEKuRZxMNQYJo1 qpZR2gVa/6SA2qo80wxtgbXa3pmVYjA0RZRyOc9DNMUYsbSaeVKhi9AZKqDwEhGkUEip qCd9XlLgNoy3rzPT2RaKGPHOnowg3VvRQW4h5x0s5KEGqESdQnjpGMiztxREOiIDF67L N4/g==
X-Received: by 10.180.75.73 with SMTP id a9mr49961880wiw.45.1427392387384; Thu, 26 Mar 2015 10:53:07 -0700 (PDT)
Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id e18sm9369202wjz.27.2015.03.26.10.53.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:53:06 -0700 (PDT)
Date: Thu, 26 Mar 2015 12:52:04 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <4CE129E555DF4375A64796B658BB6098@gmail.com>
In-Reply-To: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55144744_4f93aad5_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/fe-bz-BW-BifJb_b57R-wrBf2Vg>
Cc: dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 17:53:22 -0000

--55144744_4f93aad5_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=
=BC=8C=E4=B8=8B=E5=8D=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> > The point is: in the draft,  whether support =E2=80=9Creachability=E2=
=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C=
 sustained IP=E2=80=9D, but the truth is any type of IP address can provi=
de =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line bet=
ween  =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in t=
he definition. That is why the definition of the IP types is not valid.
> =20
> =20
> =20
> =22IP address reachability=22 is about ability to reach the host at a s=
pecific =22IP address=22 even when the host changes its point of attachme=
nt.
> You seem to interpret it as if it said =22IP reachability=22 (ability t=
o reach the host using IP protocol), but that's not the case.
> =20
No, I guess we have the same understanding regarding  what is =E2=80=9C r=
eachability=E2=80=9D here and still my question is: if we use =E2=80=9C r=
eachability=E2=80=9D as characteristic to distinguish  =E2=80=9Cfixed IP =
address=E2=80=9D and =E2=80=9Csustained IP  address=E2=80=9D, there will =
be no clear dividing line between them.


Dapeng
 =20
> =20
> That term is already defined in the I-D:
> =20
> IP address reachability: The ability to maintain the same IP address fo=
r an extended period of time. The IP address stays the same across indepe=
ndent IP sessions, and even in the absence of any IP session. The IP addr=
ess may be published in a long-term registry (e.g., DNS), and it is made =
available for serving incoming (e.g., TCP) connections. IP address reacha=
bility is essential for mobile hosts to use specific/published IP address=
es.
> =20
> =20
> > > > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=
=80=9D:
> > > > > > =20
> > > > > > =E2=80=9C- Nomadic IP Address
> > > > > > This type of IP address provides neither IP session continuit=
y nor IP address reachability. The IP address is obtained from the servin=
g IP gateway and it is not maintained across gateway changes. In other wo=
rds, the IP address may be released and replaced by a new IP address when=
 the IP gateway changes due to the movement of the mobile =20
> > > > > > host.=E2=80=9D
> > > > > > =20
> > > > > > Seems this IP address is the IP address that we normally used=
 in most cases. If this is the case, why we need a new name for it=3F
> > > > > > =20
> > > > > =20
> > > > > =20
> > > > > If you don't name it, how would you refer to it in this context=
=3F
> > > > If the justification of naming IP address as =E2=80=9Cfixed IP=E2=
=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not =
necessary need a new name for normal IP address.
> > > > =20
> > > =20
> > > I and the WT=231 believe that justification is valid.
> > > If you believe otherwise, please elaborate.
> > > =20
> > > =20
> > > =20
> > > =20
> > =20
> > Pls see above comment.
> > =20
> > Dapeng =20
> > > =20
> > > Alper
> > > =20
> > > =20
> > > =20
> > > > =20
> > > > Dapeng =20
> > > > > =20
> > > > > =20
> > > > > Alper
> > > > > =20
> > > > > =20
> > > > > > =20
> > > > > > -- =20
> > > > > > Dapeng Liu
> > > > > > =20
> > > > > > =20
> > > > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=
=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=
=81=93=EF=BC=9A
> > > > > > =20
> > > > > > > Hello Dapeng and Alex,
> > > > > > > =20
> > > > > > > I hope you had a chance to digest our responses to your com=
ments and questions about the API work.
> > > > > > > If you have any remaining issues, please let us know over t=
he email at your earliest convenience.
> > > > > > > It'd be good if you can articulate them in detail.
> > > > > > > =20
> > > > > > > =20
> > > > > > > Thanks.
> > > > > > > =20
> > > > > > > Alper =20
> > > > > > =20
> > > > > =20
> > > > =20
> > > =20
> > =20
> =20


--55144744_4f93aad5_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><br></div><div><div></div></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=
=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div><blockquote type=3D=22cite=22><d=
iv>The point is: in the draft, &nbsp;whether support =E2=80=9Creachabilit=
y=E2=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=
=9C sustained IP=E2=80=9D, but the truth is any type of IP address can pr=
ovide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line =
between &nbsp;=E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=
=9D in the definition. That is why the definition of the IP types is not =
valid.</div></blockquote><div><br></div><div><br></div><div>=22IP address=
 reachability=22 is about ability to reach the host at a specific =22IP a=
ddress=22 even when the host changes its point of attachment.</div><div>Y=
ou seem to interpret it as if it said =22IP reachability=22 (ability to r=
each the host using IP protocol), but that's not the case.</div><div><br>=
</div></div></div></div></span></blockquote><div>No, I guess we have the =
same understanding regarding &nbsp;what is =E2=80=9C reachability=E2=80=9D=
 here and still my question is: if we use =E2=80=9C reachability=E2=80=9D=
 as characteristic to distinguish &nbsp;=E2=80=9Cfixed IP address=E2=80=9D=
 and =E2=80=9Csustained IP &nbsp;address=E2=80=9D, there will be no clear=
 dividing line between them.</div><div><br></div><div><br></div><div>Dape=
ng</div><div>&nbsp;</div><blockquote type=3D=22cite=22 style=3D=22border-=
left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;=22><=
span><div><div><div><div></div><div>That term is already defined in the I=
-D:</div><div><br></div><div><pre style=3D=22color: rgb(0, 0, 0); font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-s=
troke-width: 0px; word-wrap: break-word; white-space: pre-wrap;=22>   IP =
address reachability: The ability to maintain the same IP address
   for an extended period of time.  The IP address stays the same across
   independent IP sessions, and even in the absence of any IP session.
   The IP address may be published in a long-term registry (e.g., DNS),
   and it is made available for serving incoming (e.g., TCP)
   connections.  IP address reachability is essential for mobile hosts
   to use specific/published IP addresses.</pre><div><br></div></div><div=
><br></div><blockquote type=3D=22cite=22><div><blockquote type=3D=22cite=22=
><div><span><div><div><div><blockquote type=3D=22cite=22><div><blockquote=
 type=3D=22cite=22><div><span><div><div><blockquote type=3D=22cite=22><di=
v><div>3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D=
:</div><div><br></div><div>=E2=80=9C<span style=3D=22font-size: 1em; whit=
e-space: pre-wrap; widows: 1;=22>- Nomadic IP Address</span></div><pre st=
yle=3D=22font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-=
before: always; widows: 1;=22>   This type of IP address provides neither=
 IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&=
nbsp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; w=
idows: 1;=22>   host.</span>=E2=80=9D</div><div><br></div><div>Seems this=
 IP address is the IP address that we normally used in most cases. If thi=
s is the case, why we need a new name for it=3F</div><div><br></div></div=
></blockquote><div><br></div><div><br></div><div>If you don't name it, ho=
w would you refer to it in this context=3F</div></div></div></span></div>=
</blockquote><div>If the justification of naming IP address as =E2=80=9Cf=
ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w=
e may not necessary need a new name for normal IP address.</div><div><br>=
</div></div></blockquote><div><br></div><div>I and the WT=231 believe tha=
t justification is valid.</div><div>If you believe otherwise, please elab=
orate.</div></div></div></div></span></div></blockquote><div>Pls see abov=
e comment.</div><div><br></div><div>Dapeng&nbsp;</div><blockquote type=3D=
=22cite=22><div><span><div><div><div><div><br></div><div>Alper</div><div>=
<br></div><div><br></div><br><blockquote type=3D=22cite=22><div><div><br>=
</div><div>Dapeng&nbsp;</div><blockquote type=3D=22cite=22><div><span><di=
v><div><div><br></div><div><br></div><div>Alper</div><div><br></div><br><=
blockquote type=3D=22cite=22><div><div><div><br></div><div>--&nbsp;</div>=
<div>Dapeng Liu</div><div><br></div></div><p style=3D=22color: =23A0A0A8;=
=22>=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=
=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=
=EF=BC=9A</p><blockquote type=3D=22cite=22><div>
                    <span><div><div><div>Hello Dapeng and Alex,</div><div=
><br></div><div>I hope you had a chance to digest our responses to your c=
omments and questions about the API work.</div><div>If you have any remai=
ning issues, please let us know over the email at your earliest convenien=
ce.</div><div>It'd be good if you can articulate them in detail.</div><di=
v><br></div><div><br></div><div>Thanks.</div><div><br></div><div>Alper</d=
iv></div></div></span>
                   =20
                   =20
                   =20
                   =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                  =20
                  =20
                  =20
                  =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--55144744_4f93aad5_a9e--


From nobody Thu Mar 26 10:54:14 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DD1A87B9 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.193
X-Spam-Level: 
X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjauQGkQ3Puz for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:54:11 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9D71A8F37 for <dmm@ietf.org>; Thu, 26 Mar 2015 10:54:11 -0700 (PDT)
Received: by wibgn9 with SMTP id gn9so96603040wib.1 for <dmm@ietf.org>; Thu, 26 Mar 2015 10:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=tlBWMTX/BFL/nXJYcGCrBkZx8i1XTL2wIM+rnX40w9g=; b=ElFOjGSPcUK1BFDq4epBHBV4ttPEpbu85ZdOwuphwhA5giFSwdu1L6JwW/FJM1pKjq 42HOId2K+1zV9GgdbwwrhDcjSu+BTg5fsSYUpH5eW+AZPaXiR1eUfB2bVnW6m1i5LzLC S0XsQfg4cVnD/PMG8W23WbwlQCgTFnbpaezFuX2/5qZLNgNevkp5lfzH/+B/QjWEz0yR mwpfuDj2kGCnU7uM0w9QmBGxXJvt9HA1fAzhJRBnGtnH/b7Xnlqag9E1ny4jvgONhsG5 ilmVX/Y9VjgiI1ijQvFR19zWS4OYGkrZrKREmlgln5u4CRvLUlfL7tVRkKASUJ+/8amU b3xA==
X-Received: by 10.180.187.171 with SMTP id ft11mr50658451wic.0.1427392450107;  Thu, 26 Mar 2015 10:54:10 -0700 (PDT)
Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id hl15sm26314160wib.3.2015.03.26.10.54.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 10:54:09 -0700 (PDT)
Date: Thu, 26 Mar 2015 12:52:54 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <272F5CDBAEC1453EA530EC284E8FEBC9@gmail.com>
In-Reply-To: <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org>
References: <BF647181-237B-434A-BD94-8149DF68F992@yegin.org> <46D0D566CDBB4F7A8538B5346C84080B@gmail.com> <BDD2319E-33F8-4564-82B6-DA5F2252719D@yegin.org> <16D77D43C73143B9A76C580ECBA39A87@gmail.com> <D65B1CD1-4A1F-4C27-B55B-49CDA0EA8D86@yegin.org> <52AC56D3ADC0481CBF02BAADF720991B@gmail.com> <9C71D4B7-21BA-429E-A901-0CB4C32FA970@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55144783_7b6c7dc6_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/AUTu0X2pd69BXN_IPDxMmNJ5yz0>
Cc: dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 17:54:13 -0000

--55144783_7b6c7dc6_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=
=BC=8C=E4=B8=8B=E5=8D=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> > The point is: in the draft,  whether support =E2=80=9Creachability=E2=
=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C=
 sustained IP=E2=80=9D, but the truth is any type of IP address can provi=
de =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line bet=
ween  =E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D in t=
he definition. That is why the definition of the IP types is not valid.
> =20
> =20
> =20
> =22IP address reachability=22 is about ability to reach the host at a s=
pecific =22IP address=22 even when the host changes its point of attachme=
nt.
> You seem to interpret it as if it said =22IP reachability=22 (ability t=
o reach the host using IP protocol), but that's not the case.
> =20
No, I guess we have the same understanding regarding  what is =E2=80=9C r=
eachability=E2=80=9D here and still my question is: if we use =E2=80=9C r=
eachability=E2=80=9D as characteristic to distinguish  =E2=80=9Cfixed IP =
address=E2=80=9D and =E2=80=9Csustained IP  address=E2=80=9D, there will =
be no clear dividing line between them.


Dapeng
 =20
> That term is already defined in the I-D:
> =20
> IP address reachability: The ability to maintain the same IP address fo=
r an extended period of time. The IP address stays the same across indepe=
ndent IP sessions, and even in the absence of any IP session. The IP addr=
ess may be published in a long-term registry (e.g., DNS), and it is made =
available for serving incoming (e.g., TCP) connections. IP address reacha=
bility is essential for mobile hosts to use specific/published IP address=
es.
> =20
> =20
> > > > > > 3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=
=80=9D:
> > > > > > =20
> > > > > > =E2=80=9C- Nomadic IP Address
> > > > > > This type of IP address provides neither IP session continuit=
y nor IP address reachability. The IP address is obtained from the servin=
g IP gateway and it is not maintained across gateway changes. In other wo=
rds, the IP address may be released and replaced by a new IP address when=
 the IP gateway changes due to the movement of the mobile =20
> > > > > > host.=E2=80=9D
> > > > > > =20
> > > > > > Seems this IP address is the IP address that we normally used=
 in most cases. If this is the case, why we need a new name for it=3F
> > > > > > =20
> > > > > =20
> > > > > =20
> > > > > If you don't name it, how would you refer to it in this context=
=3F
> > > > If the justification of naming IP address as =E2=80=9Cfixed IP=E2=
=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then we may not =
necessary need a new name for normal IP address.
> > > > =20
> > > =20
> > > I and the WT=231 believe that justification is valid.
> > > If you believe otherwise, please elaborate.
> > > =20
> > > =20
> > > =20
> > > =20
> > =20
> > Pls see above comment.
> > =20
> > Dapeng =20
> > > =20
> > > Alper
> > > =20
> > > =20
> > > =20
> > > > =20
> > > > Dapeng =20
> > > > > =20
> > > > > =20
> > > > > Alper
> > > > > =20
> > > > > =20
> > > > > > =20
> > > > > > -- =20
> > > > > > Dapeng Liu
> > > > > > =20
> > > > > > =20
> > > > > > =E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=
=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=
=81=93=EF=BC=9A
> > > > > > =20
> > > > > > > Hello Dapeng and Alex,
> > > > > > > =20
> > > > > > > I hope you had a chance to digest our responses to your com=
ments and questions about the API work.
> > > > > > > If you have any remaining issues, please let us know over t=
he email at your earliest convenience.
> > > > > > > It'd be good if you can articulate them in detail.
> > > > > > > =20
> > > > > > > =20
> > > > > > > Thanks.
> > > > > > > =20
> > > > > > > Alper =20
> > > > > > =20
> > > > > =20
> > > > =20
> > > =20
> > =20
> =20


--55144783_7b6c7dc6_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><br></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C=E4=B8=8B=E5=8D=
=8811:42=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p><blockquote t=
ype=3D=22cite=22><div>
                    <span><div><div><div><blockquote type=3D=22cite=22><d=
iv>The point is: in the draft, &nbsp;whether support =E2=80=9Creachabilit=
y=E2=80=9D is the distinction between =E2=80=9Cfixed IP=E2=80=9D and =E2=80=
=9C sustained IP=E2=80=9D, but the truth is any type of IP address can pr=
ovide =E2=80=9Creachability=E2=80=9D. So there is no clear dividing line =
between &nbsp;=E2=80=9Cfixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=
=9D in the definition. That is why the definition of the IP types is not =
valid.</div></blockquote><div><br></div><div><br></div><div>=22IP address=
 reachability=22 is about ability to reach the host at a specific =22IP a=
ddress=22 even when the host changes its point of attachment.</div><div>Y=
ou seem to interpret it as if it said =22IP reachability=22 (ability to r=
each the host using IP protocol), but that's not the case.</div><div><br>=
</div></div></div></div></span></div></blockquote><div>No, I guess we hav=
e the same understanding regarding &nbsp;what is =E2=80=9C reachability=E2=
=80=9D here and still my question is: if we use =E2=80=9C reachability=E2=
=80=9D as characteristic to distinguish &nbsp;=E2=80=9Cfixed IP address=E2=
=80=9D and =E2=80=9Csustained IP &nbsp;address=E2=80=9D, there will be no=
 clear dividing line between them.</div><div><br></div><div><br></div><di=
v>Dapeng</div><div>&nbsp;</div><blockquote type=3D=22cite=22><div><span><=
div><div><div><div>That term is already defined in the I-D:</div><div><br=
></div><div><pre style=3D=22color: rgb(0, 0, 0); font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
 word-wrap: break-word; white-space: pre-wrap;=22>   IP address reachabil=
ity: The ability to maintain the same IP address
   for an extended period of time.  The IP address stays the same across
   independent IP sessions, and even in the absence of any IP session.
   The IP address may be published in a long-term registry (e.g., DNS),
   and it is made available for serving incoming (e.g., TCP)
   connections.  IP address reachability is essential for mobile hosts
   to use specific/published IP addresses.</pre><div><br></div></div><div=
><br></div><blockquote type=3D=22cite=22><div><blockquote type=3D=22cite=22=
><div><span><div><div><div><blockquote type=3D=22cite=22><div><blockquote=
 type=3D=22cite=22><div><span><div><div><blockquote type=3D=22cite=22><di=
v><div>3. Regarding the definition of =E2=80=9Cnomadic IP address=E2=80=9D=
:</div><div><br></div><div>=E2=80=9C<span style=3D=22font-size: 1em; whit=
e-space: pre-wrap; widows: 1;=22>- Nomadic IP Address</span></div><pre st=
yle=3D=22font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-=
before: always; widows: 1;=22>   This type of IP address provides neither=
 IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&=
nbsp;</pre><div><span style=3D=22font-size: 1em; white-space: pre-wrap; w=
idows: 1;=22>   host.</span>=E2=80=9D</div><div><br></div><div>Seems this=
 IP address is the IP address that we normally used in most cases. If thi=
s is the case, why we need a new name for it=3F</div><div><br></div></div=
></blockquote><div><br></div><div><br></div><div>If you don't name it, ho=
w would you refer to it in this context=3F</div></div></div></span></div>=
</blockquote><div>If the justification of naming IP address as =E2=80=9Cf=
ixed IP=E2=80=9D and =E2=80=9C sustained IP=E2=80=9D is not valid, then w=
e may not necessary need a new name for normal IP address.</div><div><br>=
</div></div></blockquote><div><br></div><div>I and the WT=231 believe tha=
t justification is valid.</div><div>If you believe otherwise, please elab=
orate.</div></div></div></div></span></div></blockquote><div>Pls see abov=
e comment.</div><div><br></div><div>Dapeng&nbsp;</div><blockquote type=3D=
=22cite=22><div><span><div><div><div><div><br></div><div>Alper</div><div>=
<br></div><div><br></div><br><blockquote type=3D=22cite=22><div><div><br>=
</div><div>Dapeng&nbsp;</div><blockquote type=3D=22cite=22><div><span><di=
v><div><div><br></div><div><br></div><div>Alper</div><div><br></div><br><=
blockquote type=3D=22cite=22><div><div><div><br></div><div>--&nbsp;</div>=
<div>Dapeng Liu</div><div><br></div></div><p style=3D=22color: =23A0A0A8;=
=22>=E5=9C=A8 2015=E5=B9=B43=E6=9C=8825=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=
=89=EF=BC=8C=E4=B8=8B=E5=8D=882:02=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=
=EF=BC=9A</p><blockquote type=3D=22cite=22><div>
                    <span><div><div><div>Hello Dapeng and Alex,</div><div=
><br></div><div>I hope you had a chance to digest our responses to your c=
omments and questions about the API work.</div><div>If you have any remai=
ning issues, please let us know over the email at your earliest convenien=
ce.</div><div>It'd be good if you can articulate them in detail.</div><di=
v><br></div><div><br></div><div>Thanks.</div><div><br></div><div>Alper</d=
iv></div></div></span>
                   =20
                   =20
                   =20
                   =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></span>
                  =20
                  =20
                  =20
                  =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                 =20
                 =20
                 =20
                 =20
                </div></blockquote><div>
                    <br>
                </div>
            </div></blockquote></div><br></div></div></span>
                =20
                =20
                =20
                =20
                </div></blockquote><div>
                    <br>
                </div>
            
--55144783_7b6c7dc6_a9e--


From nobody Thu Mar 26 10:54:54 2015
Return-Path: <h.anthony.chan@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DEC1A8F4A for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuFfWrJODGNZ for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 10:54:51 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA51A8A44 for <dmm@ietf.org>; Thu, 26 Mar 2015 10:54:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUE25169; Thu, 26 Mar 2015 17:54:39 +0000 (GMT)
Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 17:54:39 +0000
Received: from szxeml557-mbx.china.huawei.com ([169.254.5.158]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 01:54:33 +0800
From: h chan <h.anthony.chan@huawei.com>
To: "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Enhanced mobility anchoring
Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KA
Date: Thu, 26 Mar 2015 17:54:32 +0000
Message-ID: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.145.73]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/xZz2NnAC81Ry0N8hTxtCYmKBbdM>
Subject: [DMM] Enhanced mobility anchoring
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 17:54:53 -0000

--_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB3YXMgYXNrZWQgdG8gcHJvdmlkZSBtb3JlIGV4cGxhbmF0aW9uIGFib3V0IGFuY2hvcmluZy4N
Cg0KRGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBtYXkgaGF2ZSBhbmNob3JpbmcgZnVu
Y3Rpb25hbGl0eSBpbiBkaWZmZXJlbnQgbmV0d29ya3Mgc28gdGhhdCByb3V0ZXMgZG8gbm90IG5l
ZWQgdG8gdHJhdmVyc2UgYSBjZW50cmFsaXplZCBhbmNob3IuDQoNCllldCwgdGhlIGRlZmluaXRp
b24gb2YgImFuY2hvcmluZyBmdW5jdGlvbiIgKEFGKSBpbiBSRkMgNzMzMyBpcyBpbiB0ZXJtcyBv
ZiByb3V0ZSBhZHZlcnRpc2VtZW50IGZvciB0aGUgSVAgYWRkcmVzcyBvbmx5LCBhbmQgc3VjaCBm
dW5jdGlvbiBpcyBhdmFpbGFibGUgaW4gbXVsdGlwbGUgbmV0d29yay4NCg0KU28gd2hhdCBhcmUg
dGhlIHJlc3Qgb2YgdGhlIGZ1bmN0aW9ucz8NCg0KU3VjaCBmdW5jdGlvbnMgbWF5IHRlbmQgdG8g
Y2F1c2UgdGhlIHBhY2tldHMgdG8gdHJhdmVyc2UgY2VydGFpbiBub2Rlcy4NCg0KQ29uc2lkZXIg
YSB0eXBpY2FsIGhhbmRvdmVyIHNjZW5hcmlvOiBNTiBtb3ZlcyBmcm9tIE5ldDEgbW92ZXMgdG8g
TmV0MiwgYW5kIENOIGlzIGluIE5ldDMNCg0KVGhlIG9sZCBBUiAoQVIxKSBvZiBNTiBpbiBOZXQx
IHBlcmZvcm1zIFJBIGZvciBJUDE7IHRoZSBuZXcgQVIgKEFSMikgb2YgTU4gaW4gTmV0MiBwZXJm
b3JtcyBSQSBmb3IgSVAyOyB0aGUgQVIgKEFSMykgb2YgQ04gaW4gTmV0MyBwZXJmb3JtcyBSQSBm
b3IgSVAzLg0KDQpUaGUgYWRkaXRpb25hbCBmdW5jdGlvbnMgYXQgQVIxIGFuZCBBUjIgYm90aCB0
cnkgdG8gY2F1c2UgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gdHJhdmVyc2UgdGhlbS4gSWYg
d2UgY2FsbCB0aGVzZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBwYXJ0IG9mIGRpc3RyaWJ1dGVkIGFu
Y2hvcmluZyBmdW5jdGlvbiwgdGhlIHF1ZXN0aW9uIGlzIHdoYXQgdGhleSBhcmUgYW5jaG9yaW5n
Lg0KDQpTbyBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRpb24gb2YgQUYsIEFSMSBwZXJmb3JtcyBB
RiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQMiAobm90IElQMSk7IGFuZCBBUjMgcGVy
Zm9ybXMgQUYgZm9yIElQMy4NCg0KT25lIGFwcHJvYWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBr
bm93biBjb25jZXB0IG9mIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRp
bmcgYWRkcmVzcy4gVGhlcmUgYXJlIHRvbnMgb2YgcGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBh
cmF0aW9uLCBhbmQgdGhlIGxhY2sgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIGNvbnNpZGVyZWQgdGhl
IGZ1bmRhbWVudGFsIHByb2JsZW0gb2YgYnJlYWtpbmcgc2Vzc2lvbiBhcyBhbiBJUCBhZGRyZXNz
IGNoYW5nZXMgZHVyaW5nIGhhbmRvdmVyLg0KDQpJbiBsaW5lIHdpdGggdGhpcyBzZXBhcmF0aW9u
LCB0aGUgZnVuY3Rpb24gb2YgYW5jaG9yaW5nIG9mIGEgc2Vzc2lvbi9mbG93IGNhbiBiZSBzZXBh
cmF0ZWQgZnJvbSB0aGF0IG9mIGFuY2hvcmluZyBhbiBJUCBhZGRyZXNzLg0KDQpUaGUgc2VwYXJh
dGlvbiBvZiBzZXNzaW9uIElEIGFuZCByb3V0aW5nIGFkZHJlc3MgY2FuIGJlIGNvbnNpZGVyZWQg
YSBnZW5lcmFsaXphdGlvbiwgYmVjYXVzZSB0aGUgc2Vzc2lvbiBJRCBjYW4gYmUgYW55dGhpbmcu
IEFuIGV4YW1wbGUgaXMgSElUIGluIHRoZSBJRVRGIHByb3RvY29sIEhJUC4NCg0KVGhlIHVzZSBv
ZiBIb0EgYW5kIENvQSBjYW4gYmUgY29uc2lkZXJlZCBhIHBhcnRpY3VsYXIgY2FzZSBvZiBTSUQg
YW5kIHJvdXRpbmcgYWRkcmVzcyBzZXBhcmF0aW9uLiBJbiB1c2luZyBpbmRpcmVjdGlvbiwgb25l
IElQIGFkZHJlc3MgKENvQSkgaXMgdXNlZCBmb3Igcm91dGluZywgd2hlcmVhcyBhbm90aGVyIElQ
IGFkZHJlc3MgKEhvQSkgaXMgdXNlZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBp
ZGVudGlmaWNhdGlvbi4NCg0KQW5vdGhlciBJRVRGIHByb3RvY29sIG9mIHN1Y2ggc2VwYXJhdGlv
biBpcyBMSVNQLg0KDQpJbiBvbmUgZXhhbXBsZSBvZiBoYW5kb3ZlciBzY2VuYXJpbyB0aGUgZGVz
aXJlZCBwYXRoIGNhbiBiZToNCg0KcGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRv
IHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCg0KaXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2gg
SVAxIGlzIGFuY2hvcmVkLg0KDQppdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMg
YW5jaG9yZWQuDQoNCldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdvIHRo
aXMgd2F5IG1heSBiZToNCg0KQVIyIGhhcyB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb246IHRoZSBi
aW5kaW5nIG9mIFNJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4gSXQg
c2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEuDQoNClN1Y2ggYWRkaXRpb25hbCBmdW5jdGlv
biBiYXNpY2FsbHkgdHJpZXMgdG8gY2F1c2UgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgKElQMSkg
dG8gdHJhdmVyc2UgQVIxIGFuZCBBUjIuDQoNCkluIGFub3RoZXIgZXhhbXBsZSBvZiB0aGlzIHNh
bWUgc2NlbmFyaW8sIHRoZSBkZXNpcmVkIHBhdGggaXM6DQoNCnBhY2tldCBmcm9tIENOIGZpcnN0
IGdvZXMgdG8gQVIzLCB0byB3aGljaCBJUDMgaXMgYW5jaG9yZWQuDQoNCml0IHRoZW4gZ29lcyBk
aXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC4NCg0KV2hhdCBjYXVzZXMg
dGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gZ28gdGhpcyB3YXkgbWF5IGJlOg0KDQpBUjMgaGFz
IHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbjogdGhlIGJpbmRpbmcgb2YgU0lEIG9mIHRoZSBmbG93
IChJUDEpIHRvIElQIGFkZHJlc3Mgb2YgQVIyLg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgYW55
IG9mIHRoZXNlIGlzIG5vdCBjbGVhciBlbm91Z2guIFRoYW5rIHlvdS4NCg0KSCBBbnRob255IENo
YW4NCg0KDQoNCg0KDQoNCg==

--_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g
MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkkgd2FzIGFza2VkIHRvIHByb3ZpZGUgbW9yZSBleHBsYW5hdGlvbiBhYm91dCBhbmNo
b3Jpbmc8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgbWF5IGhhdmUgYW5jaG9yaW5nIGZ1bmN0
aW9uYWxpdHkgaW4gZGlmZmVyZW50IG5ldHdvcmtzIHNvIHRoYXQgcm91dGVzIGRvIG5vdCBuZWVk
IHRvIHRyYXZlcnNlIGEgY2VudHJhbGl6ZWQgYW5jaG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WWV0LCB0
aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDthbmNob3JpbmcgZnVuY3Rpb24mcXVvdDsgKEFGKSZuYnNw
O2luIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlzZW1lbnQgZm9yIHRoZSBJ
UCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoJm5ic3A7ZnVuY3Rpb24gaXMgYXZhaWxhYmxlIGluIG11
bHRpcGxlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyB3aGF0IGFyZSB0aGUgcmVzdCBvZiB0
aGUgZnVuY3Rpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0
byBjYXVzZSB0aGUgcGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Db25zaWRlciBhIHR5cGljYWwgaGFuZG92ZXImbmJzcDtzY2VuYXJpbzogTU4gbW92
ZXMgZnJvbSBOZXQxIG1vdmVzIHRvIE5ldDIsIGFuZCBDTiBpcyBpbiBOZXQzPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5UaGUgb2xkIEFSIChBUjEpIG9mIE1OJm5ic3A7aW4gTmV0MSBwZXJmb3JtcyBSQSBmb3Ig
SVAxOyB0aGUgbmV3IEFSIChBUjIpIG9mIE1OIGluIE5ldDIgcGVyZm9ybXMgUkEgZm9yIElQMjsg
dGhlIEFSIChBUjMpIG9mIENOIGluIE5ldDMgcGVyZm9ybXMgUkEgZm9yIElQMy48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPlRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0
byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBj
YWxsIHRoZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9y
aW5nIGZ1bmN0aW9uLCB0aGUgcXVlc3Rpb24NCiBpcyB3aGF0IHRoZXkgYXJlIGFuY2hvcmluZy4g
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gYWNjb3JkaW5nIHRvIHRoZSZuYnNwO2RlZmluaXRp
b24gb2YgQUYsIEFSMSBwZXJmb3JtcyBBRiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQ
MiAobm90IElQMSk7IGFuZCBBUjMgcGVyZm9ybXMgQUYgZm9yIElQMy4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+T25lIGFwcHJvYWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBrbm93biBjb25jZXB0IG9mIHNl
cGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRpbmcgYWRkcmVzcy4gVGhlcmUg
YXJlIHRvbnMgb2YgcGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBhcmF0aW9uLCBhbmQgdGhlIGxh
Y2sgb2Ygc3VjaCBzZXBhcmF0aW9uDQogaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJv
YmxlbSBvZiBicmVha2luZyBzZXNzaW9uJm5ic3A7YXMgYW4gSVAgYWRkcmVzcyBjaGFuZ2VzIGR1
cmluZyBoYW5kb3Zlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gbGluZSB3aXRoIHRoaXMgc2VwYXJh
dGlvbiwgdGhlIGZ1bmN0aW9uIG9mIGFuY2hvcmluZyBvZiBhIHNlc3Npb24vZmxvdyBjYW4gYmUg
c2VwYXJhdGVkIGZyb20gdGhhdCBvZiBhbmNob3JpbmcgYW4gSVAgYWRkcmVzcy4NCjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+VGhlIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJRCBhbmQgcm91dGluZyBhZGRyZXNz
IGNhbiBiZSBjb25zaWRlcmVkIGEgZ2VuZXJhbGl6YXRpb24sIGJlY2F1c2UgdGhlIHNlc3Npb24g
SUQgY2FuIGJlIGFueXRoaW5nLiBBbiBleGFtcGxlIGlzIEhJVCBpbiB0aGUgSUVURiBwcm90b2Nv
bCBISVAuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSB1c2Ugb2YgSG9BIGFuZCBDb0EgY2FuIGJlIGNv
bnNpZGVyZWQgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgU0lEIGFuZCByb3V0aW5nIGFkZHJlc3Mgc2Vw
YXJhdGlvbi4gSW4gdXNpbmcgaW5kaXJlY3Rpb24sIG9uZSBJUCBhZGRyZXNzIChDb0EpIGlzIHVz
ZWQgZm9yIHJvdXRpbmcsIHdoZXJlYXMgYW5vdGhlciBJUCBhZGRyZXNzDQogKEhvQSkgaXMgdXNl
ZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBpZGVudGlmaWNhdGlvbi4gPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5Bbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJ
U1AuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlv
IHRoZSBkZXNpcmVkIHBhdGggY2FuIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZyb20gQ04g
Zmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+aXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2ggSVAxIGlzIGFuY2hvcmVkLg0KPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5pdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMgYW5jaG9y
ZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93
IHRvIGdvIHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMiBoYXMgdGhlIGxvY2F0
aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAx
KSB0byBJUCBhZGRyZXNzIG9mIEFSMi4gSXQgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5TdWNoIGFkZGl0aW9uYWwgZnVuY3Rpb24gYmFzaWNhbGx5IHRyaWVz
IHRvIGNhdXNlIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IChJUDEpIHRvIHRyYXZlcnNlIEFSMSBh
bmQgQVIyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiBhbm90aGVyIGV4YW1wbGUgb2YgdGhpcyBzYW1l
IHNjZW5hcmlvLCB0aGUgZGVzaXJlZCBwYXRoIGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGFja2V0IGZy
b20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPml0IHRoZW4gZ29lcyBkaXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBh
bmNob3JlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBm
bG93IHRvIGdvIHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFSMyBoYXMgdGhlIGxv
Y2F0aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAo
SVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxlYXNlIGxldCBt
ZSBrbm93IGlmIGFueSBvZiB0aGVzZSBpcyBub3QgY2xlYXIgZW5vdWdoLiBUaGFuayB5b3UuDQo8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6E31144C030982429702B11D6746B98C521EFCA4szxeml557mbxchi_--


From nobody Thu Mar 26 11:01:03 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB581AD36E for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QY_SSrMZp3u for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:00:59 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E0E1A9053 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:00:59 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QI0sZs016105 for <dmm@ietf.org>; Thu, 26 Mar 2015 19:00:54 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 815F4204E70 for <dmm@ietf.org>; Thu, 26 Mar 2015 19:01:39 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7996C200CD8 for <dmm@ietf.org>; Thu, 26 Mar 2015 19:01:39 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.136]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QI0pOZ024701 for <dmm@ietf.org>; Thu, 26 Mar 2015 19:00:53 +0100
Message-ID: <55144953.8070104@gmail.com>
Date: Thu, 26 Mar 2015 13:00:51 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <A730EA79-F6CF-49CD-9933-9FDA4AA75541@yegin.org> <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com>
In-Reply-To: <54E60579.5090401@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/TzZAtLrxjxra5d6CDwQBhhR4EaE>
Subject: Re: [DMM] Mobility Exposure and Selection WT call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:01:02 -0000

Le 19/02/2015 10:47, Alexandru Petrescu a écrit :
> Le 19/02/2015 16:30, Alper Yegin a écrit :
>>>>
>>>> This is source address selection, hence multicast address is out-of
>>>> picture. Unicast vs anycast distinction is orthogonal to mobility
>>>> type of the address.
>>>>
>>>>> - MAC-based, random-based (RFC7217).
>>>>
>>>> Orthogonal.
>>>
>>> ?  One wouldn't want her 'fixed' address (not the 'sustained', not
>>> the 'nomadic') be a random-based address RFC7217.  That RFC's abstract
>>> says:
>>>> This document specifies a method for generating IPv6 Interface
>>>> Identifiers to be used with IPv6 Stateless Address Autoconfiguration
>>>> (SLAAC), such that an IPv6 address configured using this method is
>>>> stable within each subnet, but the corresponding Interface
>>>> Identifier changes when the host moves from one network to another.
>>>
>>>
>>
>> When using the "fixed" IP address, the host stays connected to the same
>> (logical/home) network at all times, anyways.
>> Hence, by the above definition, there's no reason to change the
>> interface ID.
>
> I thought by "fixed" you meant it stays the same wherever the Host goes
> (something like the Home Address).

Alper - I think a LL address can also be qualified as 'fixed' - it never 
changes.

I think it's hard to disagree with that, no?

Alex

>
> So, I guess, I should have referred to the "nomadic" address to mean the
> one that is constant, wherever the Host goes.
>
> As such, my suggestion is that a "nomadic" address can never be an
> RFC7217 address.
>
> In practice that would mean that if you configure an address to be
> "nomadic" you must also tell the kernel to not run RFC7217 on it.
>
> But ok, one might think that these two aspects ("nomadic" and RFC7217)
> are orthogonal at this point in time.
>
> Alex
>
>>
>> I don't know if it makes sense to request a fixed and random-based IP
>> address. But if someone does it, it works.
>
>
>>
>> Alper
>>
>>
>>
>>
>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
>>>>> 6775).
>>>>>
>>>>
>>>> Orthogonal.
>>>>
>>>>
>>>>> E.g. a nomadic address could never be a link-local address.
>>>>>
>>>>>> #2. Describe how IP address type information is conveyed from
>>>>>> network to MN.
>>>>>
>>>>> If one designs a protocol to convey address type information from
>>>>> the network to the end node, then one could also add the other
>>>>> types mentioned above.
>>>>>
>>>>> SLAAC could never 'convey' the address type to the end-node,
>>>>> because SLAAC is an operation happening with as heavy weight from
>>>>> the Server (router) as from the Client (Host): the Router decides
>>>>> the prefix but the Client decides the Interface ID.
>>>>>
>>>>
>>>> Still, the network can convey the type of IP address to the host.
>>>> Also, one can imagine augmenting Router Solicitation to let the host
>>>> convey its requested type.
>>>
>>> I agree.
>>>
>>> Alex
>>>
>>>
>>>>> Address Registration Option of 6lo and BTLE would have the Host
>>>>> conveying this information to the Router (and not vice-versa).
>>>>>
>>>>
>>>> OK.
>>>>
>>>> Alper
>>>>
>>>>
>>>>> Yours,
>>>>>
>>>>> Alex
>>>>>
>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
>>>>>> baseline for item#1 (the API). A revision of the draft will also
>>>>>> include a new section to cover backward compatibility (Danny will
>>>>>> provide the draft text). Comments on the draft are welcome.
>>>>>>
>>>>>> The next call will be about items #2/#3 (IP address
>>>>>> configuration enhancements associated with the API). We intend to
>>>>>> schedule that one in about 2 weeks.
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> See below for the Webex details. Remember, the call is on Tue,
>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
>>>>>>> the reading list prior to the call.
>>>>>>>
>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>
>>>>>>>> 1.
>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>
>>>>>>>>
>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>> 3.
>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>
>>>>>>>>
>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alper
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
>>>>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
>>>>>>>
>>>>>>>> *Join WebEx meeting*
>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>> Meeting number:641 085 326
>>>>>>>> Meeting password:dmm1911
>>>>>>>>
>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions
>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>>>>
>>>>>>>> Add this meeting
>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>>>>>
>>>>>>>> to your calendar.
>>>>>>>>
>>>>>>>> Can't join the meeting? Contact support.
>>>>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>>>>
>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
>>>>>>>> audio and other information sent during the session to be
>>>>>>>> recorded, which may be discoverable in a legal matter. By
>>>>>>>> joining this session, you automatically consent to such
>>>>>>>> recordings. If you do not consent to being recorded, discuss
>>>>>>>> your concerns with the host or do not join the session.
>>>>>>>>
>>>>>>> <WebEx_Meeting.ics>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>>>>
>>>>>>>> Poll is closed, and majority selected the following date for
>>>>>>>> the call:
>>>>>>>>
>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>>>>
>>>>>>>> Please mark your calendars.
>>>>>>>>
>>>>>>>> In this call, we'll aim making progress on the I-D for item#1
>>>>>>>> (an API for source address selection).
>>>>>>>>
>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>
>>>>>>>> 1.
>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>
>>>>>>>>
>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>> 3.
>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>
>>>>>>>>
>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
>>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> Please mark your availability on the following doodle for
>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
>>>>>>>>>
>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>>>>
>>>>>>>>> Register your availability no later than the end of Monday
>>>>>>>>> (Jan 26).
>>>>>>>>>
>>>>>>>>> Alper
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ dmm mailing list
>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ dmm mailing list
>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>



From nobody Thu Mar 26 11:01:32 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1B1B29CA for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Cj3HytvO1Uw for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:01:27 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7EA1AD36E for <dmm@ietf.org>; Thu, 26 Mar 2015 11:01:25 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QI1OWt016327; Thu, 26 Mar 2015 19:01:24 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 32D3D204E70; Thu, 26 Mar 2015 19:02:09 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26492200CD8; Thu, 26 Mar 2015 19:02:09 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.136]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QI1MY5025560; Thu, 26 Mar 2015 19:01:23 +0100
Message-ID: <55144971.5080208@gmail.com>
Date: Thu, 26 Mar 2015 13:01:21 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <A730EA79-F6CF-49CD-9933-9FDA4AA75541@yegin.org> <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org>
In-Reply-To: <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/MQltlxAjcJ_KBqFKkju-h0DKMhE>
Cc: dmm@ietf.org
Subject: Re: [DMM] Mobility Exposure and Selection WT call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:01:31 -0000

Le 13/02/2015 03:09, Alper Yegin a écrit :
> Hello Alex,
>
>> I looked at the slides.  I think I understand the concept of type
>> of IP address from a mobility perspective: fixed, sustained,
>> nomadic.
>>
>> I have remarks: - could an aquired prefix (DHCPv6 PD) also be
>> qualified as fixed, sustained, nomadic?
>
> Yes.
>
>> - how would a mobility address type relate to other address
>> 'types'? - link-local, ULA, global.
>
> Link-local can only be nomadic.

I disagree.  A LL can also be 'fixed', because it's fixed.

> Global can be any type.

Ok.

> We cannot assure a ULA address stays the same
> (considering border crossings), hence it can only be nomadic.

But it can also be sustained.

>> - unicast, anycast, multicast.
>
> This is source address selection, hence multicast address is out-of
> picture. Unicast vs anycast distinction is orthogonal to mobility
> type of the address.

So all SUSTAINED, NOMADIC, FIXED addresses can only be unicast, right?

>> - MAC-based, random-based (RFC7217).
>
> Orthogonal.

What does that mean?  orthogonal?

Alex


>
>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
>> 6775).
>>
>
> Orthogonal.
>
>
>> E.g. a nomadic address could never be a link-local address.
>>
>>> #2. Describe how IP address type information is conveyed from
>>> network to MN.
>>
>> If one designs a protocol to convey address type information from
>> the network to the end node, then one could also add the other
>> types mentioned above.
>>
>> SLAAC could never 'convey' the address type to the end-node,
>> because SLAAC is an operation happening with as heavy weight from
>> the Server (router) as from the Client (Host): the Router decides
>> the prefix but the Client decides the Interface ID.
>>
>
> Still, the network can convey the type of IP address to the host.
> Also, one can imagine augmenting Router Solicitation to let the host
> convey its requested type.
>
>
>> Address Registration Option of 6lo and BTLE would have the Host
>> conveying this information to the Router (and not vice-versa).
>>
>
> OK.
>
> Alper
>
>
>> Yours,
>>
>> Alex
>>
>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
>>> baseline for item#1 (the API). A revision of the draft will also
>>> include a new section to cover backward compatibility (Danny will
>>> provide the draft text). Comments on the draft are welcome.
>>>
>>> The next call will be about items #2/#3 (IP address
>>> configuration enhancements associated with the API). We intend to
>>> schedule that one in about 2 weeks.
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>
>>>> Folks,
>>>>
>>>> See below for the Webex details. Remember, the call is on Tue,
>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
>>>> the reading list prior to the call.
>>>>
>>>>> Attendees _shall read _the following material before the call
>>>>> so that we can directly jump to the discussions:
>>>>>
>>>>> 1.
>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>
>>>>>
2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>> 3.
>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>
>>>>>
4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>
>>>>
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
>>>>
>>>>> *Join WebEx meeting*
>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>
>>>>>
>>>>>
Meeting number:	641 085 326
>>>>> Meeting password:	dmm1911
>>>>>
>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
>>>>> Access code: 641 085 326 Toll-free calling restrictions
>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>
>>>>> Add this meeting
>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>> to your calendar.
>>>>>
>>>>> Can't join the meeting? Contact support.
>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>
>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
>>>>> audio and other information sent during the session to be
>>>>> recorded, which may be discoverable in a legal matter. By
>>>>> joining this session, you automatically consent to such
>>>>> recordings. If you do not consent to being recorded, discuss
>>>>> your concerns with the host or do not join the session.
>>>>>
>>>> <WebEx_Meeting.ics>
>>>>
>>>>
>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>
>>>>> Poll is closed, and majority selected the following date for
>>>>> the call:
>>>>>
>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>
>>>>> Please mark your calendars.
>>>>>
>>>>> In this call, we'll aim making progress on the I-D for item#1
>>>>> (an API for source address selection).
>>>>>
>>>>> Attendees _shall read _the following material before the call
>>>>> so that we can directly jump to the discussions:
>>>>>
>>>>> 1.
>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>
>>>>>
2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>> 3.
>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>
>>>>>
4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>
>>>>>
>>>>> Alper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> Please mark your availability on the following doodle for
>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
>>>>>>
>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>
>>>>>> Register your availability no later than the end of Monday
>>>>>> (Jan 26).
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________ dmm mailing list
>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>> _______________________________________________ dmm mailing list
>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>
>
>



From nobody Thu Mar 26 11:13:39 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562511A88F3 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.85
X-Spam-Level: 
X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34v6iAp2I6de for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:13:36 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555681A9086 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:13:35 -0700 (PDT)
Received: from [10.119.8.1] ([31.7.59.44]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0Lvj4s-1ZXbL83Imi-017UbP; Thu, 26 Mar 2015 19:13:27 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>
Date: Thu, 26 Mar 2015 20:13:22 +0200
Message-Id: <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org>
References: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>
To: Weixinpeng (Jackie) <weixinpeng@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:Obnhh1d/HMimrqRQBynqZkW3Wft81z4DMdq1QpC8+i+5w9khI/H B635uCOj7NrzM3eGUOLmuTixhcRYobsXAkTSEMttx5EJUV6ckjLq1dwXuZwPPkOIUhy3XbZ /mN7YJyx15Lvs4i/QxBNaB/tt0bcJDqNhzg1Qv81+tcqXPnrjhbo70qQMIGOvZrFA6egzXF OuoXPbYU88oGjQHTr2+3w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/uNGPDnCil9nQge-KRxE0_GaCb8w>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:13:38 -0000

--Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Hi Xinpeng,

If your app knows how to deal with IP address changes, then it's better =
if we give it a chance to do so, because (as the I-D explains):

   Achieving IP session continuity and IP address reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when needed.


Alper

On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:

> Hi Alper
> My understanding about the reason why there needs to define serval =
types of IP prefixes is that,  if the application itself could deal with =
the change of IP address, i.e. the application itself could deal with =
session continuty in case of IP address change, so the host would choose =
a normadic address otherwise the host should choose a sustained address.
> But my question is that, if the application could deal with session =
continuty itself, does that mean the application is willing to change =
its IP address? Because even though a new address might bring some kinds =
of benefit, but it will also
> bring additional cost for application to deal with IP address change.
> Thanks.
> =20
> Xinpeng
> =20
> =20
> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng Liu =
[maxpassion@gmail.com]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01
> =CA=D5=BC=FE=C8=CB: Alper Yegin
> =B3=AD=CB=CD: dmm@ietf.org
> =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API
>=20
> Hello Alper,
>=20
> I still have the following comments:
>=20
> 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the =
draft:
>=20
>   =A1=B0- Fixed IP Address
>    This is what standard Mobile IP provides with a Home Address (HoA).
>    The mobile host is configures a HoA from a centrally-located Home
>    Network.  Both IP session continuity and IP address reachability =
are
>    provided to the mobile host with the help of a router in the Home
>    Network (Home Agent, HA).  This router acts as an anchor for the IP=20=

> address of the mobile host.=A1=B1=20
>=20
> If this is equal to HoA, then RFC5014 already cover that. We do not =
need to repeat it here with another name.
>=20
> 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the =
draft:
>=20
> "- Sustained IP Address
>=20
>    This type of IP address provides IP session continuity but not IP
>    address reachability.  It is achieved by ensuring that the IP =
address
>    used at the beginning of the session remains usable despite the
>    movement of the mobile host.  The IP address may change after the
>    termination of the IP session(s), therefore it does not exhibit
>    persistence.
> "
> There is no clear dividing line between fixed IP address and sustained =
IP address. Whether the IP address is used for reachability is not =
determined by the IP address itself. For example, even when the MN get a =
HoA, after it moves to another location of the network, it may decide to =
release current HoA and get another HoA, in this case the "fixed IP =
address" becomes a "sustained IP address".
>=20
> Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its =
domain name, never by it=A1=AFs server=A1=AFs IP address.=20
>=20
> Using temporary private IP address we can also achieve the goal of =
=A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in  =
http://hsk.oray.com/ , it can  provide reachability even the host get a =
private IP address.
>=20
> 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:
>=20
> =A1=B0- Nomadic IP Address
>    This type of IP address provides neither IP session continuity nor =
IP
>    address reachability.  The IP address is obtained from the serving =
IP
>    gateway and it is not maintained across gateway changes.  In other
>    words, the IP address may be released and replaced by a new IP
>    address when the IP gateway changes due to the movement of the =
mobile=20
> host.=A1=B1
>=20
> Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?
>=20
>=20
> --=20
> Dapeng Liu
>=20
> =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:0=
2=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA
>> Hello Dapeng and Alex,
>>=20
>> I hope you had a chance to digest our responses to your comments and =
questions about the API work.
>> If you have any remaining issues, please let us know over the email =
at your earliest convenience.
>> It'd be good if you can articulate them in detail.
>>=20
>>=20
>> Thanks.
>>=20
>> Alper
>=20
>=20


--Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

<html><head><base href=3D"x-msg://667/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">Hi Xinpeng,<div><br></div><div>If your app knows =
how to deal with IP address changes, then it's better if we give it a =
chance to do so, because (as the I-D =
explains):</div><div><br></div><div><pre style=3D"color: rgb(0, 0, 0); =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: =
0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: =
pre-wrap;">   Achieving IP session continuity and IP address =
reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when =
needed.</pre><div><br></div><div><br></div><div>Alper</div><div><br></div>=
<div><div>On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div fpstyle=3D"1" ocsi=3D"0"><div style=3D"direction: =
ltr; font-family: Tahoma; color: rgb(0, 0, 0); font-size: 10pt; "><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">Hi Alper</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">My understanding about =
the reason why there needs to define&nbsp;serval types&nbsp;of IP =
prefixes is that, &nbsp;if the application itself could deal with the =
change of IP address, i.e. the application itself could deal with =
session continuty in case of IP address change, so the host would choose =
a normadic address otherwise the host should choose a sustained =
address.</div><div style=3D"margin-top: 0px; margin-bottom: 0px; ">But =
my question is that, if the application could deal with session =
continuty itself, does that mean the application is willing to change =
its IP address? Because even though a new address might bring some kinds =
of benefit, but it will also</div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">bring additional cost for application to deal with =
IP address change.</div><div style=3D"margin-top: 0px; margin-bottom: =
0px; ">Thanks.</div><p style=3D"margin-top: 0px; margin-bottom: 0px; =
">&nbsp;</p><div style=3D"margin-top: 0px; margin-bottom: 0px; =
">Xinpeng</div><p style=3D"margin-top: 0px; margin-bottom: 0px; =
">&nbsp;</p><p style=3D"margin-top: 0px; margin-bottom: 0px; =
">&nbsp;</p><div style=3D"font-family: 'Times New Roman'; color: rgb(0, =
0, 0); font-size: 16px; "><hr tabindex=3D"-1"><div id=3D"divRpF991546" =
style=3D"direction: ltr; "><font color=3D"#000000" size=3D"2" =
face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>dmm [<a =
href=3D"mailto:dmm-bounces@ietf.org">dmm-bounces@ietf.org</a>] =B4=FA=B1=ED=
 Dapeng Liu [<a =
href=3D"mailto:maxpassion@gmail.com">maxpassion@gmail.com</a>]<br><b>=B7=A2=
=CB=CD=CA=B1=BC=E4:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>2015=C4=EA3=D4=C226=C8=D5 =
5:01<br><b>=CA=D5=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Alper =
Yegin<br><b>=B3=AD=CB=CD:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br><b>=D6=F7=CC=E2:</b><span=
 class=3D"Apple-converted-space">&nbsp;</span>[DMM] =BB=D8=B8=B4=A3=BA =
DMM API<br></font><br></div><div></div><div><div>Hello =
Alper,</div><div><br></div><div>I still have the following =
comments:</div><div><br></div><div>1. Regarding the definition of =
=A1=B0fixed IP address=A1=B1 in the =
draft:</div><div><br></div><div>&nbsp; =A1=B0<span style=3D"widows: 1; =
white-space: pre-wrap; font-size: 1em; ">- Fixed IP =
Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the =
IP&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">address of the mobile =
host.</span>=A1=B1&nbsp;</div><div><br></div><div>If this is equal to =
HoA, then RFC5014 already cover that. We do not need to repeat it here =
with another name.</div><div><br></div><div>2. Regarding the definition =
of =A1=B0sustained IP address=A1=B1 in the =
draft:</div><div><br></div><div><pre class=3D"newpage" =
style=3D"page-break-before: always; widows: 1; margin-top: 0px; =
margin-bottom: 0px; font-size: 1em; ">"- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
"</pre></div><div><div>There is no clear dividing line between fixed IP =
address and sustained IP address. Whether the IP address is used for =
reachability is not determined by the IP address itself. For example, =
even when the MN get a HoA, after it moves to another location of the =
network, it may decide to release current HoA and get another HoA, in =
this case the "fixed IP address" becomes a "sustained IP =
address".</div><div><br></div><div>Further more, the reachability =
normally is implemented by domain name instead of IP address. For =
example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF=
s server=A1=AFs IP =
address.&nbsp;</div><div><br></div><div>Using&nbsp;temporary private IP =
address we can also achieve the goal of =A1=B0reachability=A1=B1. For =
example, using dynamic DNS, as shown in &nbsp;<a =
href=3D"http://hsk.oray.com/" =
target=3D"_blank">http://hsk.oray.com/</a>&nbsp;, it can &nbsp;provide =
reachability even the host get a private IP =
address.</div><div><br></div><div>3. Regarding the definition of =
=A1=B0nomadic IP address=A1=B1:</div><div><br></div><div>=A1=B0<span =
style=3D"widows: 1; white-space: pre-wrap; font-size: 1em; ">- Nomadic =
IP Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This type of IP address provides neither IP session continuity nor =
IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">host.</span>=A1=B1</div><div><br></div><div>Seems this =
IP address is the IP address that we normally used in most cases. If =
this is the case, why we need a new name for =
it?</div><div><br></div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div><div></div></div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; color: rgb(160, 160, 168); ">=D4=DA 2015=C4=EA3=D4=C22=
5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin =
=D0=B4=B5=C0=A3=BA</div><blockquote type=3D"cite" =
style=3D"border-left-width: 1px; border-left-style: solid; =
border-left-color: initial; border-right-width: 1px; padding-left: 10px; =
border-top-width: 1px; border-bottom-width: 1px; margin-left: 0px; =
"><span><div><div><div>Hello Dapeng and Alex,</div><div><br></div><div>I =
hope you had a chance to digest our responses to your comments and =
questions about the API work.</div><div>If you have any remaining =
issues, please let us know over the email at your earliest =
convenience.</div><div>It'd be good if you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span></blockquote><div><br></div></div></d=
iv></div></div><br =
class=3D"Apple-interchange-newline"></blockquote></div><br></div></body></=
html>=

--Apple-Mail=_DCCC73CA-F585-49FD-BD14-C3E981D54324--


From nobody Thu Mar 26 11:17:51 2015
Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F71A90B0 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlHWeOKr-eOg for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:17:47 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CF41A9087 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:17:47 -0700 (PDT)
Received: by wgbcc7 with SMTP id cc7so72929643wgb.0 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:17:46 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MxtOZaSDshTiujt5vioG7mpYO10NaS5AYBRvGm9T2kw=; b=EQIevEA35VDqt6HrKR68p4FJFBJYQO4uOcJjQFGylydL8dqIYX/muuz2F1uTN7qj3K MwnHjAN4N0bwnmIxAcGUSBm1l8fapoLGmB2bybyaBjdrK67PKegi4YzcXEJSY5iI6HzJ KRi2wVJZswBAgEF+aMFftVSxBIiBMiVJFSvoUFpn0GZNWUkV/FLAIS2DNKH4EBUeiqiF rJtjD+a8XCV5wyopXjXSYSnWh7T57vRVH0ND0w9ccq55C45B3vSwYNNVz71nfYlf+zaa gOz+tTVUDnjbRslNrj/aacWJUKPX9XTecEX/cxT7pZqoTuPguaC1D4UamEbWXqhzcMbz Igiw==
X-Received: by 10.180.79.65 with SMTP id h1mr50149064wix.59.1427393865925; Thu, 26 Mar 2015 11:17:45 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:9860:4b20:ac20:5e7a? ([2001:67c:370:160:9860:4b20:ac20:5e7a]) by mx.google.com with ESMTPSA id ev7sm9441477wjb.47.2015.03.26.11.17.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 11:17:45 -0700 (PDT)
Message-ID: <55144D3F.2030002@gmail.com>
Date: Thu, 26 Mar 2015 11:17:35 -0700
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, dmm@ietf.org
References: <A730EA79-F6CF-49CD-9933-9FDA4AA75541@yegin.org> <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com>
In-Reply-To: <55144953.8070104@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/T146B7ym1W-AMTgZc6ug-jCwGPM>
Subject: Re: [DMM] Mobility Exposure and Selection WT call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:17:50 -0000

Alex,

3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:

[snip]

>> I thought by "fixed" you meant it stays the same wherever the Host goes
>> (something like the Home Address).
>
> Alper - I think a LL address can also be qualified as 'fixed' - it never
> changes.

Does LL here mean link-local or link-layer? If it is the former one, 
then the above assertion is not correct.

- Jouni

>
> I think it's hard to disagree with that, no?
>
> Alex
>
>>
>> So, I guess, I should have referred to the "nomadic" address to mean the
>> one that is constant, wherever the Host goes.
>>
>> As such, my suggestion is that a "nomadic" address can never be an
>> RFC7217 address.
>>
>> In practice that would mean that if you configure an address to be
>> "nomadic" you must also tell the kernel to not run RFC7217 on it.
>>
>> But ok, one might think that these two aspects ("nomadic" and RFC7217)
>> are orthogonal at this point in time.
>>
>> Alex
>>
>>>
>>> I don't know if it makes sense to request a fixed and random-based IP
>>> address. But if someone does it, it works.
>>
>>
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
>>>>>> 6775).
>>>>>>
>>>>>
>>>>> Orthogonal.
>>>>>
>>>>>
>>>>>> E.g. a nomadic address could never be a link-local address.
>>>>>>
>>>>>>> #2. Describe how IP address type information is conveyed from
>>>>>>> network to MN.
>>>>>>
>>>>>> If one designs a protocol to convey address type information from
>>>>>> the network to the end node, then one could also add the other
>>>>>> types mentioned above.
>>>>>>
>>>>>> SLAAC could never 'convey' the address type to the end-node,
>>>>>> because SLAAC is an operation happening with as heavy weight from
>>>>>> the Server (router) as from the Client (Host): the Router decides
>>>>>> the prefix but the Client decides the Interface ID.
>>>>>>
>>>>>
>>>>> Still, the network can convey the type of IP address to the host.
>>>>> Also, one can imagine augmenting Router Solicitation to let the host
>>>>> convey its requested type.
>>>>
>>>> I agree.
>>>>
>>>> Alex
>>>>
>>>>
>>>>>> Address Registration Option of 6lo and BTLE would have the Host
>>>>>> conveying this information to the Router (and not vice-versa).
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>> Alper
>>>>>
>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
>>>>>>> baseline for item#1 (the API). A revision of the draft will also
>>>>>>> include a new section to cover backward compatibility (Danny will
>>>>>>> provide the draft text). Comments on the draft are welcome.
>>>>>>>
>>>>>>> The next call will be about items #2/#3 (IP address
>>>>>>> configuration enhancements associated with the API). We intend to
>>>>>>> schedule that one in about 2 weeks.
>>>>>>>
>>>>>>> Alper
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> See below for the Webex details. Remember, the call is on Tue,
>>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
>>>>>>>> the reading list prior to the call.
>>>>>>>>
>>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>>
>>>>>>>>> 1.
>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>
>>>>>>>>>
>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>> 3.
>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
>>>>>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
>>>>>>>>
>>>>>>>>> *Join WebEx meeting*
>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> Meeting number:641 085 326
>>>>>>>>> Meeting password:dmm1911
>>>>>>>>>
>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
>>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
>>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions
>>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>>>>>
>>>>>>>>> Add this meeting
>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> to your calendar.
>>>>>>>>>
>>>>>>>>> Can't join the meeting? Contact support.
>>>>>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>>>>>
>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
>>>>>>>>> audio and other information sent during the session to be
>>>>>>>>> recorded, which may be discoverable in a legal matter. By
>>>>>>>>> joining this session, you automatically consent to such
>>>>>>>>> recordings. If you do not consent to being recorded, discuss
>>>>>>>>> your concerns with the host or do not join the session.
>>>>>>>>>
>>>>>>>> <WebEx_Meeting.ics>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>>>>>
>>>>>>>>> Poll is closed, and majority selected the following date for
>>>>>>>>> the call:
>>>>>>>>>
>>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>>>>>
>>>>>>>>> Please mark your calendars.
>>>>>>>>>
>>>>>>>>> In this call, we'll aim making progress on the I-D for item#1
>>>>>>>>> (an API for source address selection).
>>>>>>>>>
>>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>>
>>>>>>>>> 1.
>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>
>>>>>>>>>
>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>> 3.
>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alper
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
>>>>>>>>>
>>>>>>>>>> Folks,
>>>>>>>>>>
>>>>>>>>>> Please mark your availability on the following doodle for
>>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
>>>>>>>>>>
>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>>>>>
>>>>>>>>>> Register your availability no later than the end of Monday
>>>>>>>>>> (Jan 26).
>>>>>>>>>>
>>>>>>>>>> Alper
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ dmm mailing list
>>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ dmm mailing list
>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Thu Mar 26 11:53:39 2015
Return-Path: <brian@innovationslab.net>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D08B1A9037 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJfhNydAsq7q for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 11:53:37 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C901A89FF for <dmm@ietf.org>; Thu, 26 Mar 2015 11:53:33 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 32D15880D1 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:53:33 -0700 (PDT)
Received: from dhcp-89de.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:ad30:fc8a:e969:4436]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4244471B0001 for <dmm@ietf.org>; Thu, 26 Mar 2015 11:53:28 -0700 (PDT)
Message-ID: <551455AB.80600@innovationslab.net>
Date: Thu, 26 Mar 2015 13:53:31 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dmm@ietf.org
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/BLhydzCU11C_81MHtlbLj74-gKE>
Subject: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 18:53:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

DMM WG,
     I want to, once again, clarify the guiding principles for the DMM
work teams. Hopefully, this will make it clear to all participants how
the work teams will influence the WG.  The guiding principles are:

1. All work teams are open to input from anyone

2. Any work team holding a meeting will announce that meeting to the WG

3. Any document produced by a work team is treated as any individual draf=
t

4. Anyone can publish alternative proposals and ask the WG to consider th=
em

5. WG consensus will drive the adoption of any solutions drafts (work
team generated or otherwise).

If you have any questions about the above, please contact me.

Regards,
Brian



--hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVFFWrAAoJEBOZRqCi7goqkbsH/jmyhida8NVsNbLoJOlFlXPM
jGJJCq1tWyZhk0w3Gi+U662etKQX9+ANILysIDV6clJG8tF5GPI3FhcXk8tMT/fi
VWovbIRBpYCK9jnGHBA+hPFUjcnhZFjJzgCf9Cb9omtnu1Yd6m1248/Nly7lvGLz
Uy6ggx+Z0T22XYsP87TAf73AeY8HS3k4dGIDwy1JAFBib+AiET5z+abuf1o6xAnV
DnnRqUhtsz/tsauFbxnIvjuCSaf5Bu+98yBUVyMWg4ox1pjnt+E50S1VBDPhOwe+
e6xeqCp+gCzBM0DCXhhkUZsRkvJ04NdKZnJaN3WJ0/coLm3Hm6QxPtMaxVt9isY=
=5lEb
-----END PGP SIGNATURE-----

--hgUgSCcpDIbfD4MiHERb9oilORS3F2GaV--


From nobody Thu Mar 26 12:02:45 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E81B2A9C for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 12:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BDzxBKWXK70 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 12:02:41 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D941B2A8E for <dmm@ietf.org>; Thu, 26 Mar 2015 12:01:46 -0700 (PDT)
Received: from [10.119.8.1] ([31.7.59.44]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0M1pgC-1ZUpYg0rjG-00tg2q; Thu, 26 Mar 2015 20:01:44 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <551455AB.80600@innovationslab.net>
Date: Thu, 26 Mar 2015 21:01:41 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org>
References: <551455AB.80600@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:L9wmCLQjv0t4KzOvUp8bu4SnFHrhpYJJCPPMzR3ti2+ulWylG1f uGnVxc2SQaVFN0OHI77LQbJcdIc6Zrp6RXWBFzzMhItmlBify2YCq/zQCeFBfbJs6RFjZ/V L7fQtSabRGL4F3XHUS2WMpn9OCB5UOR37MlWBMDYgGHKfrumhHjoo+qkX9UncXzb6baFVJo krr1g46f2Ld7JYTZ3nhKg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/9JPb7QF7I1FliyYkd0b8AShQ5JE>
Cc: dmm@ietf.org
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 19:02:43 -0000

Brian,

This is exactly how WTs have been operating.

Anyone thinking otherwise is not closely following the work.

Alper


On Mar 26, 2015, at 8:53 PM, Brian Haberman wrote:

> DMM WG,
>     I want to, once again, clarify the guiding principles for the DMM
> work teams. Hopefully, this will make it clear to all participants how
> the work teams will influence the WG.  The guiding principles are:
> 
> 1. All work teams are open to input from anyone
> 
> 2. Any work team holding a meeting will announce that meeting to the WG
> 
> 3. Any document produced by a work team is treated as any individual draft
> 
> 4. Anyone can publish alternative proposals and ask the WG to consider them
> 
> 5. WG consensus will drive the adoption of any solutions drafts (work
> team generated or otherwise).
> 
> If you have any questions about the above, please contact me.
> 
> Regards,
> Brian
> 
> 
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Thu Mar 26 12:05:30 2015
Return-Path: <brian@innovationslab.net>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20B1B2DA2 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 12:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59BsuzZwEIve for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 12:05:25 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875A11B2D9F for <dmm@ietf.org>; Thu, 26 Mar 2015 12:03:36 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6DD1C880E2; Thu, 26 Mar 2015 12:03:36 -0700 (PDT)
Received: from dhcp-89de.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:ad30:fc8a:e969:4436]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 88FAD71B0001; Thu, 26 Mar 2015 12:03:31 -0700 (PDT)
Message-ID: <55145807.1010302@innovationslab.net>
Date: Thu, 26 Mar 2015 14:03:35 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <551455AB.80600@innovationslab.net> <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org>
In-Reply-To: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/_E9RGViLaxC815wNSehjLYmNclI>
Cc: dmm@ietf.org
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 19:05:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Alper,

On 3/26/15 2:01 PM, Alper Yegin wrote:
> Brian,
>=20
> This is exactly how WTs have been operating.

I agree.

>=20
> Anyone thinking otherwise is not closely following the work.
>=20

I agree, but I have had people complain and just wanted to re-iterate my
message from several months ago.

Regards,
Brian


--jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVFFgHAAoJEBOZRqCi7goqWkUH/0HTeO6vRhliZNd8tEOx8dWC
hmw6UzSL+fylh4qclRYfgS91JAs720vZhQjsEMvAJWSApYxE6pZnZR9nMYKpCQgx
vPUagkubJXjJq71ogN6SFzp3AI37j+1IG0rzxjRdscFNbLEwDYpcBJ03uQ89STe7
DHQPIHPv7eSkQQBSoxPxQouWl23rV5d/nADsQxRn5k38voZ//oEef1/GpHPgd1qu
Rrs721GS+Q1+X8RTIoAUN4m0vnadfiF6y96EpGZaGjx5oyEXWXQL8Ltsqy80/eZZ
NtO4NIQMoYLRex838vByd6uv4J2L4fiz1McJNwHcKFZqHqkEj/IrtC8s3zrOOJY=
=8Ki6
-----END PGP SIGNATURE-----

--jWn2oCq0fsAPn4m3Mq6OGNqvCs9cDqNVa--


From nobody Thu Mar 26 13:08:16 2015
Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6C1A8A4E for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Level: 
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIIQAMMFBolW for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:08:12 -0700 (PDT)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 149311A89C7 for <dmm@ietf.org>; Thu, 26 Mar 2015 13:08:11 -0700 (PDT)
Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77405288 for dmm@ietf.org; Thu, 26 Mar 2015 20:08:10 +0000
From: "Seil Jeon" <seiljeon@av.it.pt>
To: <dmm@ietf.org>
Date: Thu, 26 Mar 2015 20:08:12 -0000
Message-ID: <006701d06800$96a57960$c3f06c20$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01D06800.96A7C350"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYg==
Content-Language: ko
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/PvLPsYkWApNlKOTvxVCHjTa0G-c>
Subject: [DMM] Answer on raised questions for the proposed API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 20:08:15 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0068_01D06800.96A7C350
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someone. Here goes
answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED IP address case in
the draft. On receiving this API with the SUSTAINED IP address type at the
IP stack, it will try to get a new SUSTAINED IP address if there is no
available in the currently attached access network. So, actual obtaining of
the IP address will be tried one time while attached at a specific access
network. Even some applications put this API after, the already obtained
SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not needed because the
host can get a new SUSTAINED IP address, right?

If the question is right, I don't understand what the question is meant,
that is how the host can get a new SUSTAINED IP address?

Based on the definition of three types of IP address, an application should
show its requirement with an API among them. If it is the SUSTAINED IP
address, how do we expect the IP stack will try to get a new SUSTAINED IP
address?

 

Besides, the propsoed API is not used alone but with the three type APIs. 

 

 

 

Regards,

 

Seil Jeon

 

 


------=_NextPart_000_0068_01D06800.96A7C350
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:"\@Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Arial","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:3.0cm 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Hi,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could attend DMM Thursday meeting via MeetEcho.<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could also hear some raised comments by Danny and Someone. Here goes =
answers to the raised questions.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>First, regarding the need of =
the proposed API (IPV6_PREFER_SRC_NEW),<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>The =
use of the proposed API is suggested in the SUSTAINED IP address case in =
the draft. On receiving this API with the SUSTAINED IP address type at =
the IP stack, it will try to get a new SUSTAINED IP address if there is =
no available in the currently attached access network. So, actual =
obtaining of the IP address will be tried one time while attached at a =
specific access network. Even some applications put this API after, the =
already obtained SUSTAINED IP will be used. So, no worries about =
abuse.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Second question sounded to me =
like that this API is not needed because the host can get a new =
SUSTAINED IP address, right?<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>If =
the question is right, I don&#8217;t understand what the question is =
meant, that is how the host can get a new SUSTAINED IP =
address?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Based on the definition of =
three types of IP address, an application should show its requirement =
with an API among them. If it is the SUSTAINED IP address, how do we =
expect the IP stack will try to get a new </span><span =
style=3D'font-family:"Arial","sans-serif"'>SUSTAINED IP =
address?</span><span =
style=3D'font-family:"Arial","sans-serif"'><o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Besides, the propsoed API is =
not used alone but with the three type APIs. <o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Regards,<o:p></o:p></span></p>=
<p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
Jeon<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_0068_01D06800.96A7C350--


From nobody Thu Mar 26 13:42:52 2015
Return-Path: <weixinpeng@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357F1A8AA1 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9kHRpHES8vO for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:42:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07221A8941 for <dmm@ietf.org>; Thu, 26 Mar 2015 13:42:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUE33435; Thu, 26 Mar 2015 20:42:45 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 20:42:44 +0000
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 04:42:38 +0800
From: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
To: Alper Yegin <alper.yegin@yegin.org>
Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?=
Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPp0uiyIAgACqUpM=
Date: Thu, 26 Mar 2015 20:42:38 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B46E332048@nkgeml507-mbx.china.huawei.com>
References: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>,  <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org>
In-Reply-To: <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.148.34]
Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/r9k3CY7IVqmjMOVHwviK4VXaPKQ>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] =?gb2312?b?tPC4tDogUmWjuiBETU0gQVBJ?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 20:42:50 -0000

--_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQWxwZXIsDQoNCkZvciBhbiBhcHBsaWNhdGlvbiBkZXZlbG9wZXIsIGlmIHRoZXJlIGFyZSB0
aHJlZSBraW5kcyBvZiBhZGRyZXNzZXMgdG8gdXNlIHdoaWNoIGFyZSAiRml4ZWQgSVAgQWRkcmVz
cyIsICJTdXN0YWluZWQgSVAgQWRkcmVzcyIgYW5kICJOb21hZGljIElQIEFkZHJlc3MiLA0KDQp0
aGVuIEkgYmVsaWV2ZSB0aGUgZGV2ZWxvcGVyIHdvdWxkIGFsd2F5cyB3YW50cyB0byB1c2UgdGhl
ICJGaXhlZCBJUCBhZGRyZXNzIiwgcmF0aGVyIHRoYW4gdGhlIG90aGVyIG9uZXMuIEJlY2F1c2Ug
ZXZlbiB0aG91Z2ggdGhlIGFwcGxpY2F0aW9uIGNvdWxkIGNvcGUgd2l0aCBJUCBhZGRyZXNzDQoN
CmNoYW5nZSwgYnV0IHRoZSBJUCBhZGRyZXNzIGNoYW5nZSBpcyBub3Qgd2hhdCB0aGUgYXBwbGlj
YXRpb24gd2FudC4NCg0KDQoNCi1YaW5wZW5nDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCreivP7IyzogQWxwZXIgWWVnaW4gW2FscGVyLnllZ2luQHllZ2luLm9y
Z10NCreiy83KsbzkOiAyMDE1xOoz1MIyN8jVIDI6MTMNCsrVvP7IyzogV2VpeGlucGVuZyAoSmFj
a2llKQ0Ks63LzTogRGFwZW5nIExpdTsgZG1tQGlldGYub3JnDQrW98ziOiBSZTogUmWjuiBETU0g
QVBJDQoNCkhpIFhpbnBlbmcsDQoNCklmIHlvdXIgYXBwIGtub3dzIGhvdyB0byBkZWFsIHdpdGgg
SVAgYWRkcmVzcyBjaGFuZ2VzLCB0aGVuIGl0J3MgYmV0dGVyIGlmIHdlIGdpdmUgaXQgYSBjaGFu
Y2UgdG8gZG8gc28sIGJlY2F1c2UgKGFzIHRoZSBJLUQgZXhwbGFpbnMpOg0KDQoNCiAgIEFjaGll
dmluZyBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGJ5
IHVzaW5nDQogICBNb2JpbGUgSVAgaW5jdXJzIHNvbWUgY29zdC4gIE1vYmlsZSBJUCBwcm90b2Nv
bCBmb3JjZXMgdGhlIG1vYmlsZQ0KICAgaG9zdCdzIElQIHRyYWZmaWMgdG8gdHJhdmVyc2UgYSBj
ZW50cmFsbHktbG9jYXRlZCByb3V0ZXIgKEhvbWUgQWdlbnQsDQogICBIQSksIHdoaWNoIGluY3Vy
cyBhZGRpdGlvbmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YNCiAgIGFkZGl0aW9u
YWwgbmV0d29yayByZXNvdXJjZXMsIGFkZHMgdG8gdGhlIG5ldHdvcmsgQ0FQRVggYW5kIE9QRVgs
IGFuZA0KICAgZGVjcmVhc2VzIHRoZSByZWxpYWJpbGl0eSBvZiB0aGUgbmV0d29yayBkdWUgdG8g
dGhlIGludHJvZHVjdGlvbiBvZiBhDQogICBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZSBbSS1ELmll
dGYtZG1tLXJlcXVpcmVtZW50c10uICBUaGVyZWZvcmUsIElQDQogICBzZXNzaW9uIGNvbnRpbnVp
dHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IHNob3VsZCBiZSBiZSBwcm92aWRlZA0KICAg
b25seSB3aGVuIG5lZWRlZC4NCg0KDQpBbHBlcg0KDQpPbiBNYXIgMjYsIDIwMTUsIGF0IDc6Mzkg
UE0sIFdlaXhpbnBlbmcgKEphY2tpZSkgd3JvdGU6DQoNCkhpIEFscGVyDQpNeSB1bmRlcnN0YW5k
aW5nIGFib3V0IHRoZSByZWFzb24gd2h5IHRoZXJlIG5lZWRzIHRvIGRlZmluZSBzZXJ2YWwgdHlw
ZXMgb2YgSVAgcHJlZml4ZXMgaXMgdGhhdCwgIGlmIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgY291
bGQgZGVhbCB3aXRoIHRoZSBjaGFuZ2Ugb2YgSVAgYWRkcmVzcywgaS5lLiB0aGUgYXBwbGljYXRp
b24gaXRzZWxmIGNvdWxkIGRlYWwgd2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpbiBjYXNlIG9mIElQ
IGFkZHJlc3MgY2hhbmdlLCBzbyB0aGUgaG9zdCB3b3VsZCBjaG9vc2UgYSBub3JtYWRpYyBhZGRy
ZXNzIG90aGVyd2lzZSB0aGUgaG9zdCBzaG91bGQgY2hvb3NlIGEgc3VzdGFpbmVkIGFkZHJlc3Mu
DQpCdXQgbXkgcXVlc3Rpb24gaXMgdGhhdCwgaWYgdGhlIGFwcGxpY2F0aW9uIGNvdWxkIGRlYWwg
d2l0aCBzZXNzaW9uIGNvbnRpbnV0eSBpdHNlbGYsIGRvZXMgdGhhdCBtZWFuIHRoZSBhcHBsaWNh
dGlvbiBpcyB3aWxsaW5nIHRvIGNoYW5nZSBpdHMgSVAgYWRkcmVzcz8gQmVjYXVzZSBldmVuIHRo
b3VnaCBhIG5ldyBhZGRyZXNzIG1pZ2h0IGJyaW5nIHNvbWUga2luZHMgb2YgYmVuZWZpdCwgYnV0
IGl0IHdpbGwgYWxzbw0KYnJpbmcgYWRkaXRpb25hbCBjb3N0IGZvciBhcHBsaWNhdGlvbiB0byBk
ZWFsIHdpdGggSVAgYWRkcmVzcyBjaGFuZ2UuDQpUaGFua3MuDQoNCg0KDQpYaW5wZW5nDQoNCg0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogZG1tIFtkbW0t
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIERhcGVu
ZyBMaXUgW21heHBhc3Npb25AZ21haWwuY29tPG1haWx0bzptYXhwYXNzaW9uQGdtYWlsLmNvbT5d
DQq3osvNyrG85DogMjAxNcTqM9TCMjbI1SA1OjAxDQrK1bz+yMs6IEFscGVyIFllZ2luDQqzrcvN
OiBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCtb3zOI6IFtETU1dILvYuLSjuiBE
TU0gQVBJDQoNCkhlbGxvIEFscGVyLA0KDQpJIHN0aWxsIGhhdmUgdGhlIGZvbGxvd2luZyBjb21t
ZW50czoNCg0KMS4gUmVnYXJkaW5nIHRoZSBkZWZpbml0aW9uIG9mIKGwZml4ZWQgSVAgYWRkcmVz
c6GxIGluIHRoZSBkcmFmdDoNCg0KICChsC0gRml4ZWQgSVAgQWRkcmVzcw0KDQogICBUaGlzIGlz
IHdoYXQgc3RhbmRhcmQgTW9iaWxlIElQIHByb3ZpZGVzIHdpdGggYSBIb21lIEFkZHJlc3MgKEhv
QSkuDQogICBUaGUgbW9iaWxlIGhvc3QgaXMgY29uZmlndXJlcyBhIEhvQSBmcm9tIGEgY2VudHJh
bGx5LWxvY2F0ZWQgSG9tZQ0KICAgTmV0d29yay4gIEJvdGggSVAgc2Vzc2lvbiBjb250aW51aXR5
IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSBhcmUNCiAgIHByb3ZpZGVkIHRvIHRoZSBtb2Jp
bGUgaG9zdCB3aXRoIHRoZSBoZWxwIG9mIGEgcm91dGVyIGluIHRoZSBIb21lDQogICBOZXR3b3Jr
IChIb21lIEFnZW50LCBIQSkuICBUaGlzIHJvdXRlciBhY3RzIGFzIGFuIGFuY2hvciBmb3IgdGhl
IElQDQoNCmFkZHJlc3Mgb2YgdGhlIG1vYmlsZSBob3N0LqGxDQoNCklmIHRoaXMgaXMgZXF1YWwg
dG8gSG9BLCB0aGVuIFJGQzUwMTQgYWxyZWFkeSBjb3ZlciB0aGF0LiBXZSBkbyBub3QgbmVlZCB0
byByZXBlYXQgaXQgaGVyZSB3aXRoIGFub3RoZXIgbmFtZS4NCg0KMi4gUmVnYXJkaW5nIHRoZSBk
ZWZpbml0aW9uIG9mIKGwc3VzdGFpbmVkIElQIGFkZHJlc3OhsSBpbiB0aGUgZHJhZnQ6DQoNCg0K
Ii0gU3VzdGFpbmVkIElQIEFkZHJlc3MNCg0KICAgVGhpcyB0eXBlIG9mIElQIGFkZHJlc3MgcHJv
dmlkZXMgSVAgc2Vzc2lvbiBjb250aW51aXR5IGJ1dCBub3QgSVANCiAgIGFkZHJlc3MgcmVhY2hh
YmlsaXR5LiAgSXQgaXMgYWNoaWV2ZWQgYnkgZW5zdXJpbmcgdGhhdCB0aGUgSVAgYWRkcmVzcw0K
ICAgdXNlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uIHJlbWFpbnMgdXNhYmxlIGRl
c3BpdGUgdGhlDQogICBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QuICBUaGUgSVAgYWRkcmVz
cyBtYXkgY2hhbmdlIGFmdGVyIHRoZQ0KICAgdGVybWluYXRpb24gb2YgdGhlIElQIHNlc3Npb24o
cyksIHRoZXJlZm9yZSBpdCBkb2VzIG5vdCBleGhpYml0DQogICBwZXJzaXN0ZW5jZS4NCiINCg0K
VGhlcmUgaXMgbm8gY2xlYXIgZGl2aWRpbmcgbGluZSBiZXR3ZWVuIGZpeGVkIElQIGFkZHJlc3Mg
YW5kIHN1c3RhaW5lZCBJUCBhZGRyZXNzLiBXaGV0aGVyIHRoZSBJUCBhZGRyZXNzIGlzIHVzZWQg
Zm9yIHJlYWNoYWJpbGl0eSBpcyBub3QgZGV0ZXJtaW5lZCBieSB0aGUgSVAgYWRkcmVzcyBpdHNl
bGYuIEZvciBleGFtcGxlLCBldmVuIHdoZW4gdGhlIE1OIGdldCBhIEhvQSwgYWZ0ZXIgaXQgbW92
ZXMgdG8gYW5vdGhlciBsb2NhdGlvbiBvZiB0aGUgbmV0d29yaywgaXQgbWF5IGRlY2lkZSB0byBy
ZWxlYXNlIGN1cnJlbnQgSG9BIGFuZCBnZXQgYW5vdGhlciBIb0EsIGluIHRoaXMgY2FzZSB0aGUg
ImZpeGVkIElQIGFkZHJlc3MiIGJlY29tZXMgYSAic3VzdGFpbmVkIElQIGFkZHJlc3MiLg0KDQpG
dXJ0aGVyIG1vcmUsIHRoZSByZWFjaGFiaWxpdHkgbm9ybWFsbHkgaXMgaW1wbGVtZW50ZWQgYnkg
ZG9tYWluIG5hbWUgaW5zdGVhZCBvZiBJUCBhZGRyZXNzLiBGb3IgZXhhbXBsZSwgd2UgcmVhY2gg
obBHb29nbGWhsSBieSBpdHMgZG9tYWluIG5hbWUsIG5ldmVyIGJ5IGl0oa9zIHNlcnZlcqGvcyBJ
UCBhZGRyZXNzLg0KDQpVc2luZyB0ZW1wb3JhcnkgcHJpdmF0ZSBJUCBhZGRyZXNzIHdlIGNhbiBh
bHNvIGFjaGlldmUgdGhlIGdvYWwgb2YgobByZWFjaGFiaWxpdHmhsS4gRm9yIGV4YW1wbGUsIHVz
aW5nIGR5bmFtaWMgRE5TLCBhcyBzaG93biBpbiAgaHR0cDovL2hzay5vcmF5LmNvbS8gLCBpdCBj
YW4gIHByb3ZpZGUgcmVhY2hhYmlsaXR5IGV2ZW4gdGhlIGhvc3QgZ2V0IGEgcHJpdmF0ZSBJUCBh
ZGRyZXNzLg0KDQozLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBub21hZGljIElQIGFk
ZHJlc3OhsToNCg0KobAtIE5vbWFkaWMgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5cGUgb2YgSVAg
YWRkcmVzcyBwcm92aWRlcyBuZWl0aGVyIElQIHNlc3Npb24gY29udGludWl0eSBub3IgSVANCiAg
IGFkZHJlc3MgcmVhY2hhYmlsaXR5LiAgVGhlIElQIGFkZHJlc3MgaXMgb2J0YWluZWQgZnJvbSB0
aGUgc2VydmluZyBJUA0KICAgZ2F0ZXdheSBhbmQgaXQgaXMgbm90IG1haW50YWluZWQgYWNyb3Nz
IGdhdGV3YXkgY2hhbmdlcy4gIEluIG90aGVyDQogICB3b3JkcywgdGhlIElQIGFkZHJlc3MgbWF5
IGJlIHJlbGVhc2VkIGFuZCByZXBsYWNlZCBieSBhIG5ldyBJUA0KICAgYWRkcmVzcyB3aGVuIHRo
ZSBJUCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlDQoN
Cmhvc3QuobENCg0KU2VlbXMgdGhpcyBJUCBhZGRyZXNzIGlzIHRoZSBJUCBhZGRyZXNzIHRoYXQg
d2Ugbm9ybWFsbHkgdXNlZCBpbiBtb3N0IGNhc2VzLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB3aHkg
d2UgbmVlZCBhIG5ldyBuYW1lIGZvciBpdD8NCg0KDQotLQ0KRGFwZW5nIExpdQ0KDQrU2iAyMDE1
xOoz1MIyNcjVINDHxtrI/aOsz8LO5zI6MDKjrEFscGVyIFllZ2luINC0tcCjug0KSGVsbG8gRGFw
ZW5nIGFuZCBBbGV4LA0KDQpJIGhvcGUgeW91IGhhZCBhIGNoYW5jZSB0byBkaWdlc3Qgb3VyIHJl
c3BvbnNlcyB0byB5b3VyIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgYWJvdXQgdGhlIEFQSSB3b3Jr
Lg0KSWYgeW91IGhhdmUgYW55IHJlbWFpbmluZyBpc3N1ZXMsIHBsZWFzZSBsZXQgdXMga25vdyBv
dmVyIHRoZSBlbWFpbCBhdCB5b3VyIGVhcmxpZXN0IGNvbnZlbmllbmNlLg0KSXQnZCBiZSBnb29k
IGlmIHlvdSBjYW4gYXJ0aWN1bGF0ZSB0aGVtIGluIGRldGFpbC4NCg0KDQpUaGFua3MuDQoNCkFs
cGVyDQoNCg0KDQo=

--_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body style=3D"WORD-WRAP: break-word" fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<p>Hi Alper,</p>
<p>For&nbsp;an application developer, if there are three kinds of addresses=
 to use which are &quot;Fixed IP Address&quot;, &quot;Sustained IP Address&=
quot; and &quot;Nomadic IP Address&quot;,</p>
<p>then I believe the developer would always wants to use the &quot;Fixed I=
P address&quot;, rather than the other ones. Because even though the applic=
ation could cope with IP address</p>
<p>change, but the IP address change is not what the application&nbsp;want.=
</p>
<p>&nbsp;</p>
<p>-Xinpeng</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF676504"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b> Alper Yegin [alper.yeg=
in@yegin.org]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b> 2015=C4=EA3=D4=C227=C8=D5 2:13<br>
<b>=CA=D5=BC=FE=C8=CB:</b> Weixinpeng (Jackie)<br>
<b>=B3=AD=CB=CD:</b> Dapeng Liu; dmm@ietf.org<br>
<b>=D6=F7=CC=E2:</b> Re: Re=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>Hi Xinpeng,
<div><br>
</div>
<div>If your app knows how to deal with IP address changes, then it's bette=
r if we give it a chance to do so, because (as the I-D explains):</div>
<div><br>
</div>
<div>
<pre style=3D"LINE-HEIGHT: normal; WIDOWS: 1; TEXT-TRANSFORM: none; FONT-VA=
RIANT: normal; FONT-STYLE: normal; TEXT-INDENT: 0px; WORD-WRAP: break-word;=
 WHITE-SPACE: pre-wrap; LETTER-SPACING: normal; COLOR: rgb(0,0,0); FONT-WEI=
GHT: normal; WORD-SPACING: 0px">   Achieving IP session continuity and IP a=
ddress reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when needed.</pre>
<div><br>
</div>
<div><br>
</div>
<div>Alper</div>
<div><br>
</div>
<div>
<div>On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div>
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: rgb(0,0,0); FONT-=
SIZE: 10pt">
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Hi Alper</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">My understanding about t=
he reason why there needs to define&nbsp;serval types&nbsp;of IP prefixes i=
s that, &nbsp;if the application itself could deal with the change of IP ad=
dress, i.e. the application itself could deal with
 session continuty in case of IP address change, so the host would choose a=
 normadic address otherwise the host should choose a sustained address.</di=
v>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">But my question is that,=
 if the application could deal with session continuty itself, does that mea=
n the application is willing to change its IP address? Because even though =
a new address might bring some kinds
 of benefit, but it will also</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">bring additional cost fo=
r application to deal with IP address change.</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Thanks.</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Xinpeng</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: rgb(0,0,0); FONT-SIZE:=
 16px">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF991546"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span class=3D"Apple-co=
nverted-space">&nbsp;</span>dmm [<a href=3D"mailto:dmm-bounces@ietf.org" ta=
rget=3D"_blank">dmm-bounces@ietf.org</a>] =B4=FA=B1=ED Dapeng Liu [<a href=
=3D"mailto:maxpassion@gmail.com" target=3D"_blank">maxpassion@gmail.com</a>=
]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b><span class=3D"Apple-converted-space">&nbsp=
;</span>2015=C4=EA3=D4=C226=C8=D5 5:01<br>
<b>=CA=D5=BC=FE=C8=CB:</b><span class=3D"Apple-converted-space">&nbsp;</spa=
n>Alper Yegin<br>
<b>=B3=AD=CB=CD:</b><span class=3D"Apple-converted-space">&nbsp;</span><a h=
ref=3D"mailto:dmm@ietf.org" target=3D"_blank">dmm@ietf.org</a><br>
<b>=D6=F7=CC=E2:</b><span class=3D"Apple-converted-space">&nbsp;</span>[DMM=
] =BB=D8=B8=B4=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>
<div>Hello Alper,</div>
<div><br>
</div>
<div>I still have the following comments:</div>
<div><br>
</div>
<div>1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra=
ft:</div>
<div><br>
</div>
<div>&nbsp; =A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZ=
E: 1em">- Fixed IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This is what standard Mo=
bile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nbsp=
;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">addre=
ss of the mobile host.</span>=A1=B1&nbsp;</div>
<div><br>
</div>
<div>If this is equal to HoA, then RFC5014 already cover that. We do not ne=
ed to repeat it here with another name.</div>
<div><br>
</div>
<div>2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the=
 draft:</div>
<div><br>
</div>
<div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">&quot;- Sustained IP Addres=
s

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
&quot;</pre>
</div>
<div>
<div>There is no clear dividing line between fixed IP address and sustained=
 IP address. Whether the IP address is used for reachability is not determi=
ned by the IP address itself. For example, even when the MN get a HoA, afte=
r it moves to another location of
 the network, it may decide to release current HoA and get another HoA, in =
this case the &quot;fixed IP address&quot; becomes a &quot;sustained IP add=
ress&quot;.</div>
<div><br>
</div>
<div>Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma=
in name, never by it=A1=AFs server=A1=AFs IP address.&nbsp;</div>
<div><br>
</div>
<div>Using&nbsp;temporary private IP address we can also achieve the goal o=
f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb=
sp;<a href=3D"http://hsk.oray.com/" target=3D"_blank">http://hsk.oray.com/<=
/a>&nbsp;, it can &nbsp;provide reachability even the host get a private
 IP address.</div>
<div><br>
</div>
<div>3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:</div>
<div><br>
</div>
<div>=A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em"=
>- Nomadic IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This type of IP address =
provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&nb=
sp;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">host.=
</span>=A1=B1</div>
<div><br>
</div>
<div>Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?</div>
<div><br>
</div>
<div><br>
</div>
<div>--&nbsp;</div>
<div>Dapeng Liu</div>
<div><br>
</div>
<div></div>
</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; COLOR: rgb(160,160,168)"=
>=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=
=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA</div>
<blockquote style=3D"BORDER-LEFT: 1px solid; BORDER-RIGHT-WIDTH: 1px; PADDI=
NG-LEFT: 10px; BORDER-TOP-WIDTH: 1px; BORDER-BOTTOM-WIDTH: 1px; MARGIN-LEFT=
: 0px" type=3D"cite">
<span>
<div>
<div>
<div>Hello Dapeng and Alex,</div>
<div><br>
</div>
<div>I hope you had a chance to digest our responses to your comments and q=
uestions about the API work.</div>
<div>If you have any remaining issues, please let us know over the email at=
 your earliest convenience.</div>
<div>It'd be good if you can articulate them in detail.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>Alper</div>
</div>
</div>
</span></blockquote>
<div><br>
</div>
</div>
</div>
</div>
</div>
<br class=3D"Apple-interchange-newline">
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_C5C3BB522B1DDF478AA09545169155B46E332048nkgeml507mbxchi_--


From nobody Thu Mar 26 13:49:58 2015
Return-Path: <weixinpeng@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D623C1B2A0D for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Level: 
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzrC772CrBei for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 13:49:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BDC1A89B4 for <dmm@ietf.org>; Thu, 26 Mar 2015 13:49:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT12537; Thu, 26 Mar 2015 20:49:53 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 20:49:52 +0000
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 04:49:48 +0800
From: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
To: Brian Haberman <brian@innovationslab.net>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] DMM work teams
Thread-Index: AQHQZ/YxwkkOmm0xTEWTBzE9oeA+O50vOw2y
Date: Thu, 26 Mar 2015 20:49:48 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B46E33205B@nkgeml507-mbx.china.huawei.com>
References: <551455AB.80600@innovationslab.net>
In-Reply-To: <551455AB.80600@innovationslab.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.148.34]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/BljpcH-T341fXmrzVMlzg56sY7E>
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 20:49:57 -0000

SSB0aGluayBpdCdzIGdvb2QgdG8gc3RhcnQgc2VydmFsIHdvcmsgdGVhbXMgdG8gcHJvY2VzcyB0
aGUgd29yay4NCklmIHRoZXJlIGFyZSBzb21lIHBlb3BsZSBjb21wbGFpbiBhYm91dCB0aGlzLCBJ
IHRoaW5rIHRoZSByZWFzb24gd291bGQgYmUgdGhhdCBpdA0KbWlnaHQgYmUgbm90IGNvbnZpZW50
IGZvciB0aGVtIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBvbmxpbmUgaW50ZXJpbSBtZWV0aW5nIGZv
ciByZWFzb25zIHN1Y2ggYXMgdGltZXpvbmUgZXRjLg0KDQpNeSBhbm90aGVyIGZlZWxpbmcgaXMg
dGhhdCBhZnRlciB0aGUgZm9ybWluZyBvZiB0ZWFtcyB0aGVyZSBpcyByZWFsbHkgcmFyZSBkaXNj
dXNzaW9uIGluIHRoZSBtYWlsbGlzdCB3aGVyZSBzaG91bGQgDQpiZSB0aGUgbWFpbiBkaXNjdXNz
aW5nIHBsYWNlIG9mIElFVEYuIFNvIG15IHN1Z2dlc3Rpb24gaXMgdGhhdCBldmVuIHRob3VnaCB0
aGVyZSBhcmUgd29yayB0ZWFtcywgcGxlYXNlIGFsc28NCmJyaW5nIHRoZSBkaXNjdXNzaW9uIHRv
IG1haWxsaXN0Lg0KDQpUaGFua3MuDQoNCi1YaW5wZW5nDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCreivP7IyzogZG1tIFtkbW0tYm91bmNlc0BpZXRmLm9yZ10g
tPqx7SBCcmlhbiBIYWJlcm1hbiBbYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0XQ0Kt6LLzcqxvOQ6
IDIwMTXE6jPUwjI3yNUgMjo1Mw0KytW8/sjLOiBkbW1AaWV0Zi5vcmcNCtb3zOI6IFtETU1dIERN
TSB3b3JrIHRlYW1zDQoNCkRNTSBXRywNCiAgICAgSSB3YW50IHRvLCBvbmNlIGFnYWluLCBjbGFy
aWZ5IHRoZSBndWlkaW5nIHByaW5jaXBsZXMgZm9yIHRoZSBETU0NCndvcmsgdGVhbXMuIEhvcGVm
dWxseSwgdGhpcyB3aWxsIG1ha2UgaXQgY2xlYXIgdG8gYWxsIHBhcnRpY2lwYW50cyBob3cNCnRo
ZSB3b3JrIHRlYW1zIHdpbGwgaW5mbHVlbmNlIHRoZSBXRy4gIFRoZSBndWlkaW5nIHByaW5jaXBs
ZXMgYXJlOg0KDQoxLiBBbGwgd29yayB0ZWFtcyBhcmUgb3BlbiB0byBpbnB1dCBmcm9tIGFueW9u
ZQ0KDQoyLiBBbnkgd29yayB0ZWFtIGhvbGRpbmcgYSBtZWV0aW5nIHdpbGwgYW5ub3VuY2UgdGhh
dCBtZWV0aW5nIHRvIHRoZSBXRw0KDQozLiBBbnkgZG9jdW1lbnQgcHJvZHVjZWQgYnkgYSB3b3Jr
IHRlYW0gaXMgdHJlYXRlZCBhcyBhbnkgaW5kaXZpZHVhbCBkcmFmdA0KDQo0LiBBbnlvbmUgY2Fu
IHB1Ymxpc2ggYWx0ZXJuYXRpdmUgcHJvcG9zYWxzIGFuZCBhc2sgdGhlIFdHIHRvIGNvbnNpZGVy
IHRoZW0NCg0KNS4gV0cgY29uc2Vuc3VzIHdpbGwgZHJpdmUgdGhlIGFkb3B0aW9uIG9mIGFueSBz
b2x1dGlvbnMgZHJhZnRzICh3b3JrDQp0ZWFtIGdlbmVyYXRlZCBvciBvdGhlcndpc2UpLg0KDQpJ
ZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGFib3V0IHRoZSBhYm92ZSwgcGxlYXNlIGNvbnRhY3Qg
bWUuDQoNClJlZ2FyZHMsDQpCcmlhbg==


From nobody Thu Mar 26 14:19:58 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B61B2F2F for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.549
X-Spam-Level: 
X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSJnjk1hLLQz for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:19:55 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E028E1B2F30 for <dmm@ietf.org>; Thu, 26 Mar 2015 14:19:52 -0700 (PDT)
Received: from [10.119.8.4] ([46.19.140.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0Lp5Pe-1Z53cy2tz2-00ejeA; Thu, 26 Mar 2015 22:19:47 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=GB2312
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <C5C3BB522B1DDF478AA09545169155B46E33205B@nkgeml507-mbx.china.huawei.com>
Date: Thu, 26 Mar 2015 23:19:41 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC3FB7FF-ED00-471C-8FF1-A83FD337E4B1@yegin.org>
References: <551455AB.80600@innovationslab.net> <C5C3BB522B1DDF478AA09545169155B46E33205B@nkgeml507-mbx.china.huawei.com>
To: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:XsMMbpEb0eLXWSU6TyYFNOx1bB0kqeWmybzGp1fDXEW/9QKUz4L Szq6gymm5RE1u/hxsyeKLIP1nTk/rRFey8dD+RKNdZyqBmLNBFUkwz6khs1Bk9+V3pQpINR hGeXJgPCouYv80oyu0cOBtc5XCX+SYxkdPD6U4uG4NYRhANTJdbkfDVGuj0Nt5mwYRJYVBT +DuG0kXmqL2jaNb7MLKQg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/vIDW7m4HwPwed9SK64i4l6yd0FA>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 21:19:57 -0000

Hi Xinpeng,

On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:

> I think it's good to start serval work teams to process the work.
> If there are some people complain about this, I think the reason would =
be that it
> might be not convient for them to participate in the online interim =
meeting for reasons such as timezone etc.
>=20

It's always a challenge to find timeslots that works for everyone, =
considering the around-the-world participation in DMM (in a way, that's =
true :-)

> My another feeling is that after the forming of teams there is really =
rare discussion in the maillist where should=20
> be the main discussing place of IETF. So my suggestion is that even =
though there are work teams, please also
> bring the discussion to mail list.

That's why we, WT leaders, publish meeting notes, so that people who =
were not at the meeting can join the discussion on the mailing list,
and this is, again, why WT leaders present the status at each IETF =
meeting.

My issue is=A1=AD.. some people don't read the meeting notes.. they =
don't read the I-D. they don't follow the email discussions. They don't =
even remember what we presented at the previous IETF and established as =
common understanding across the WG. They don't bring up any discussion =
for things that has been out there at least 2 IETF meeting cycles=A1=AD =
And then! ask questions as if this is the first time we are presenting =
it (for very specific example: need for 3 distinct types of IP =
addresses). And then, this causing us significant amount of productivity =
loss=A1=AD.=20

Alper


>=20

> Thanks.
>=20
> -Xinpeng
>=20
> ________________________________________
> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian =
Haberman [brian@innovationslab.net]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53
> =CA=D5=BC=FE=C8=CB: dmm@ietf.org
> =D6=F7=CC=E2: [DMM] DMM work teams
>=20
> DMM WG,
>     I want to, once again, clarify the guiding principles for the DMM
> work teams. Hopefully, this will make it clear to all participants how
> the work teams will influence the WG.  The guiding principles are:
>=20
> 1. All work teams are open to input from anyone
>=20
> 2. Any work team holding a meeting will announce that meeting to the =
WG
>=20
> 3. Any document produced by a work team is treated as any individual =
draft
>=20
> 4. Anyone can publish alternative proposals and ask the WG to consider =
them
>=20
> 5. WG consensus will drive the adoption of any solutions drafts (work
> team generated or otherwise).
>=20
> If you have any questions about the above, please contact me.
>=20
> Regards,
> Brian
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Thu Mar 26 14:26:53 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD61B2EFA for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.85
X-Spam-Level: 
X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn2c8Gi9Dr70 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:26:49 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DD81B2AF7 for <dmm@ietf.org>; Thu, 26 Mar 2015 14:26:49 -0700 (PDT)
Received: from [10.119.8.4] ([46.19.140.68]) by mrelay.perfora.net (mreueus001) with ESMTPA (Nemesis) id 0LyCFX-1ZVdaE1kY9-015RKw; Thu, 26 Mar 2015 22:26:41 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <C5C3BB522B1DDF478AA09545169155B46E332048@nkgeml507-mbx.china.huawei.com>
Date: Thu, 26 Mar 2015 23:26:36 +0200
Message-Id: <DCBFFB95-180A-4109-91B1-95CF5155A80B@yegin.org>
References: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>,  <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org> <C5C3BB522B1DDF478AA09545169155B46E332048@nkgeml507-mbx.china.huawei.com>
To: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:33T67Nzx8IS1tAkDaKIdgUzh48yDP2VqyVJDUURtkSiEsWyyjYN UhyXLqhrjzj4inNF20DGqpNvbylUgiVEOlFrDsBlIkW+2O4RAS+tqVk9QkwAmy8RYkuFQu7 ZPpH2BEF9OC4rYxEkQyYz0q9a18vttX2mEeGugy3SapZtReBhPv8CIJllRIAIx8+s2EfGYm TBEcQOXX2uCz9sND32ssw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/vSdUvIh_u-ghAhIYyyCKhhzOvDE>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 21:26:52 -0000

--Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Xinpeng,

I'll give you a counter example to what you are claiming.

Imagine you are developing a chat (IM) client.
Because your app will be running on terminals that'd connect to both =
cellular and WiFi networks, you don't have any other option but to =
implement app-layer mobility management (because otherwise your chat =
sessions will break when the terminal moves in and out of WiFi =
hotspots).

Now, given that you already implemented app-layer mobility, it's to your =
advantage to use it even when you are on cellular network, if there was =
a way to tell the network to provide you a nomadic IP address (as =
opposed to fixed/mobile IP address that it'd normally do). Because that =
way, you ensure your IP packets take the shortest path, which reduces =
the end2end latency.

Besides, we also expect that the mobile network operators will promote =
"proper use" of these flags, because that ensures efficient use of their =
network resources. Letting an app use a fixed IP address when it could =
very well use a nomadic IP address is waste of network resources (back =
hauling, PGW capacity, etc.)

As a future thing, we can even envision mobile operators charging =
differently based on the type of traffic -- after all each type is =
consuming different amounts of network resources.=20

Alper


On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote:

> Hi Alper,
> For an application developer, if there are three kinds of addresses to =
use which are "Fixed IP Address", "Sustained IP Address" and "Nomadic IP =
Address",
> then I believe the developer would always wants to use the "Fixed IP =
address", rather than the other ones. Because even though the =
application could cope with IP address
> change, but the IP address change is not what the application want.
> =20
> -Xinpeng
> =20
> =20
> =B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:13
> =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
> =B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
> =D6=F7=CC=E2: Re: Re=A3=BA DMM API
>=20
> Hi Xinpeng,
>=20
> If your app knows how to deal with IP address changes, then it's =
better if we give it a chance to do so, because (as the I-D explains):
>=20
>    Achieving IP session continuity and IP address reachability by =
using
>    Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
>    host's IP traffic to traverse a centrally-located router (Home =
Agent,
>    HA), which incurs additional transmission latency and use of
>    additional network resources, adds to the network CAPEX and OPEX, =
and
>    decreases the reliability of the network due to the introduction of =
a
>    single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
>    session continuity and IP address reachability should be be =
provided
>    only when needed.
>=20
>=20
> Alper
>=20
> On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:
>=20
>> Hi Alper
>> My understanding about the reason why there needs to define serval =
types of IP prefixes is that,  if the application itself could deal with =
the change of IP address, i.e. the application itself could deal with =
session continuty in case of IP address change, so the host would choose =
a normadic address otherwise the host should choose a sustained address.
>> But my question is that, if the application could deal with session =
continuty itself, does that mean the application is willing to change =
its IP address? Because even though a new address might bring some kinds =
of benefit, but it will also
>> bring additional cost for application to deal with IP address change.
>> Thanks.
>> =20
>> Xinpeng
>> =20
>> =20
>> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng =
Liu [maxpassion@gmail.com]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01
>> =CA=D5=BC=FE=C8=CB: Alper Yegin
>> =B3=AD=CB=CD: dmm@ietf.org
>> =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API
>>=20
>> Hello Alper,
>>=20
>> I still have the following comments:
>>=20
>> 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the =
draft:
>>=20
>>   =A1=B0- Fixed IP Address
>>    This is what standard Mobile IP provides with a Home Address =
(HoA).
>>    The mobile host is configures a HoA from a centrally-located Home
>>    Network.  Both IP session continuity and IP address reachability =
are
>>    provided to the mobile host with the help of a router in the Home
>>    Network (Home Agent, HA).  This router acts as an anchor for the =
IP=20
>> address of the mobile host.=A1=B1=20
>>=20
>> If this is equal to HoA, then RFC5014 already cover that. We do not =
need to repeat it here with another name.
>>=20
>> 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in =
the draft:
>>=20
>> "- Sustained IP Address
>>=20
>>    This type of IP address provides IP session continuity but not IP
>>    address reachability.  It is achieved by ensuring that the IP =
address
>>    used at the beginning of the session remains usable despite the
>>    movement of the mobile host.  The IP address may change after the
>>    termination of the IP session(s), therefore it does not exhibit
>>    persistence.
>> "
>> There is no clear dividing line between fixed IP address and =
sustained IP address. Whether the IP address is used for reachability is =
not determined by the IP address itself. For example, even when the MN =
get a HoA, after it moves to another location of the network, it may =
decide to release current HoA and get another HoA, in this case the =
"fixed IP address" becomes a "sustained IP address".
>>=20
>> Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its =
domain name, never by it=A1=AFs server=A1=AFs IP address.=20
>>=20
>> Using temporary private IP address we can also achieve the goal of =
=A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in  =
http://hsk.oray.com/ , it can  provide reachability even the host get a =
private IP address.
>>=20
>> 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:
>>=20
>> =A1=B0- Nomadic IP Address
>>    This type of IP address provides neither IP session continuity nor =
IP
>>    address reachability.  The IP address is obtained from the serving =
IP
>>    gateway and it is not maintained across gateway changes.  In other
>>    words, the IP address may be released and replaced by a new IP
>>    address when the IP gateway changes due to the movement of the =
mobile=20
>> host.=A1=B1
>>=20
>> Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?
>>=20
>>=20
>> --=20
>> Dapeng Liu
>>=20
>> =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:=
02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA
>>> Hello Dapeng and Alex,
>>>=20
>>> I hope you had a chance to digest our responses to your comments and =
questions about the API work.
>>> If you have any remaining issues, please let us know over the email =
at your earliest convenience.
>>> It'd be good if you can articulate them in detail.
>>>=20
>>>=20
>>> Thanks.
>>>=20
>>> Alper


--Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

<html><head><base href=3D"x-msg://972/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">Xinpeng,<div><br></div><div>I'll give you a counter =
example to what you are claiming.</div><div><br></div><div>Imagine you =
are developing a chat (IM) client.</div><div>Because your app will be =
running on terminals that'd connect to both cellular and WiFi networks, =
you don't have any other option but to implement app-layer mobility =
management (because otherwise your chat sessions will break when the =
terminal moves in and out of WiFi =
hotspots).</div><div><br></div><div>Now, given that you already =
implemented app-layer mobility, it's to your advantage to use it even =
when you are on cellular network, if there was a way to tell the network =
to provide you a nomadic IP address (as opposed to fixed/mobile IP =
address that it'd normally do). Because that way, you ensure your IP =
packets take the shortest path, which reduces the end2end =
latency.</div><div><br></div><div>Besides, we also expect that the =
mobile network operators will promote "proper use" of these flags, =
because that ensures efficient use of their network resources. Letting =
an app use a fixed IP address when it could very well use a nomadic IP =
address is waste of network resources (back hauling, PGW capacity, =
etc.)</div><div><br></div><div>As a future thing, we can even envision =
mobile operators charging differently based on the type of traffic -- =
after all each type is consuming different amounts of network =
resources.&nbsp;</div><div><br></div><div>Alper</div><div><br></div><div><=
br><div><div>On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"margin-top: 0px; margin-bottom: 0px; =
">Hi Alper,</div><div style=3D"margin-top: 0px; margin-bottom: 0px; =
">For&nbsp;an application developer, if there are three kinds of =
addresses to use which are "Fixed IP Address", "Sustained IP Address" =
and "Nomadic IP Address",</div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">then I believe the developer would always wants to =
use the "Fixed IP address", rather than the other ones. Because even =
though the application could cope with IP address</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">change, but the IP =
address change is not what the application&nbsp;want.</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">-Xinpeng</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"font-family: 'Times New Roman'; color: rgb(0, 0, 0); font-size: =
16px; "><hr tabindex=3D"-1"><div id=3D"divRpF676504" style=3D"direction: =
ltr; "><font color=3D"#000000" size=3D"2" =
face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Alper Yegin [<a =
href=3D"mailto:alper.yegin@yegin.org">alper.yegin@yegin.org</a>]<br><b>=B7=
=A2=CB=CD=CA=B1=BC=E4:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>2015=C4=EA3=D4=C227=C8=D5 =
2:13<br><b>=CA=D5=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Weixinpeng =
(Jackie)<br><b>=B3=AD=CB=CD:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Dapeng Liu; <a =
href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br><b>=D6=F7=CC=E2:</b><span=
 class=3D"Apple-converted-space">&nbsp;</span>Re: Re=A3=BA DMM =
API<br></font><br></div><div></div><div>Hi =
Xinpeng,<div><br></div><div>If your app knows how to deal with IP =
address changes, then it's better if we give it a chance to do so, =
because (as the I-D explains):</div><div><br></div><div><pre =
style=3D"line-height: normal; widows: 1; text-transform: none; =
font-variant: normal; font-style: normal; text-indent: 0px; word-wrap: =
break-word; white-space: pre-wrap; letter-spacing: normal; color: rgb(0, =
0, 0); font-weight: normal; word-spacing: 0px; ">   Achieving IP session =
continuity and IP address reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when =
needed.</pre><div><br></div><div><br></div><div>Alper</div><div><br></div>=
<div><div>On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><div style=3D"font-family: Tahoma; direction: ltr; =
color: rgb(0, 0, 0); font-size: 10pt; "><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">Hi Alper</div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">My understanding about the reason why there needs =
to define&nbsp;serval types&nbsp;of IP prefixes is that, &nbsp;if the =
application itself could deal with the change of IP address, i.e. the =
application itself could deal with session continuty in case of IP =
address change, so the host would choose a normadic address otherwise =
the host should choose a sustained address.</div><div style=3D"margin-top:=
 0px; margin-bottom: 0px; ">But my question is that, if the application =
could deal with session continuty itself, does that mean the application =
is willing to change its IP address? Because even though a new address =
might bring some kinds of benefit, but it will also</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">bring additional cost =
for application to deal with IP address change.</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">Thanks.</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">Xinpeng</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"font-family: 'Times New Roman'; color: rgb(0, 0, 0); font-size: =
16px; "><hr tabindex=3D"-1"><div id=3D"divRpF991546" style=3D"direction: =
ltr; "><font color=3D"#000000" size=3D"2" =
face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>dmm [<a =
href=3D"mailto:dmm-bounces@ietf.org" =
target=3D"_blank">dmm-bounces@ietf.org</a>] =B4=FA=B1=ED Dapeng Liu [<a =
href=3D"mailto:maxpassion@gmail.com" =
target=3D"_blank">maxpassion@gmail.com</a>]<br><b>=B7=A2=CB=CD=CA=B1=BC=E4=
:</b><span class=3D"Apple-converted-space">&nbsp;</span>2015=C4=EA3=D4=C22=
6=C8=D5 5:01<br><b>=CA=D5=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Alper =
Yegin<br><b>=B3=AD=CB=CD:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org" =
target=3D"_blank">dmm@ietf.org</a><br><b>=D6=F7=CC=E2:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>[DMM] =BB=D8=B8=B4=A3=BA =
DMM API<br></font><br></div><div></div><div><div>Hello =
Alper,</div><div><br></div><div>I still have the following =
comments:</div><div><br></div><div>1. Regarding the definition of =
=A1=B0fixed IP address=A1=B1 in the =
draft:</div><div><br></div><div>&nbsp; =A1=B0<span style=3D"widows: 1; =
white-space: pre-wrap; font-size: 1em; ">- Fixed IP =
Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the =
IP&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">address of the mobile =
host.</span>=A1=B1&nbsp;</div><div><br></div><div>If this is equal to =
HoA, then RFC5014 already cover that. We do not need to repeat it here =
with another name.</div><div><br></div><div>2. Regarding the definition =
of =A1=B0sustained IP address=A1=B1 in the =
draft:</div><div><br></div><div><pre class=3D"newpage" =
style=3D"page-break-before: always; widows: 1; margin-top: 0px; =
margin-bottom: 0px; font-size: 1em; ">"- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
"</pre></div><div><div>There is no clear dividing line between fixed IP =
address and sustained IP address. Whether the IP address is used for =
reachability is not determined by the IP address itself. For example, =
even when the MN get a HoA, after it moves to another location of the =
network, it may decide to release current HoA and get another HoA, in =
this case the "fixed IP address" becomes a "sustained IP =
address".</div><div><br></div><div>Further more, the reachability =
normally is implemented by domain name instead of IP address. For =
example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF=
s server=A1=AFs IP =
address.&nbsp;</div><div><br></div><div>Using&nbsp;temporary private IP =
address we can also achieve the goal of =A1=B0reachability=A1=B1. For =
example, using dynamic DNS, as shown in &nbsp;<a =
href=3D"http://hsk.oray.com/" =
target=3D"_blank">http://hsk.oray.com/</a>&nbsp;, it can &nbsp;provide =
reachability even the host get a private IP =
address.</div><div><br></div><div>3. Regarding the definition of =
=A1=B0nomadic IP address=A1=B1:</div><div><br></div><div>=A1=B0<span =
style=3D"widows: 1; white-space: pre-wrap; font-size: 1em; ">- Nomadic =
IP Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This type of IP address provides neither IP session continuity nor =
IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">host.</span>=A1=B1</div><div><br></div><div>Seems this =
IP address is the IP address that we normally used in most cases. If =
this is the case, why we need a new name for =
it?</div><div><br></div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div><div></div></div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; color: rgb(160, 160, 168); ">=D4=DA 2015=C4=EA3=D4=C22=
5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin =
=D0=B4=B5=C0=A3=BA</div><blockquote type=3D"cite" =
style=3D"border-left-width: 1px; border-left-style: solid; =
border-left-color: initial; border-right-width: 1px; padding-left: 10px; =
border-top-width: 1px; border-bottom-width: 1px; margin-left: 0px; =
"><span><div><div><div>Hello Dapeng and Alex,</div><div><br></div><div>I =
hope you had a chance to digest our responses to your comments and =
questions about the API work.</div><div>If you have any remaining =
issues, please let us know over the email at your earliest =
convenience.</div><div>It'd be good if you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span></blockquote></div></div></div></div>=
</blockquote></div></div></div></div></div></div></span></blockquote></div=
><br></div></body></html>=

--Apple-Mail=_FFD0C010-73BB-4046-B198-A46EA691305F--


From nobody Thu Mar 26 14:49:54 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D61B2F96 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TN18AGGkHxw for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 14:49:51 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F42C1B2F97 for <dmm@ietf.org>; Thu, 26 Mar 2015 14:49:50 -0700 (PDT)
Received: by wgdm6 with SMTP id m6so79592053wgd.2 for <dmm@ietf.org>; Thu, 26 Mar 2015 14:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=zgZY8jPi+j2sUwZIWulVPV2yBmHovr6E3pU3n0JLkdE=; b=lFOPxXVkDiXw36ugdVyeTEh8tuq7gtq/+P3b730RtIZxt5bvxZ8ZMBhNDRkBwN0AD6 9qPQdDRCcTkjmV3xAA1cpfbjItSN8+WCu2x6fpQnIxGVcr7wDWlM3UU3FAhgN3mrWCBe gtuESo3wGTJsJfnwPz3o2oyg82tJOr1cStIYEk2e3/rfNgBOvTxDc9PYZBpTXpeo2kAp TL3pgb//rr/rU5vU3/QnfgRLzFS9cqsgP1RMiY5EemhYuIUXVi4wFnU3hcBrbjjF8qpO fSbeFcAxAh6dnyCziDm6D6BDR15uQtLvF8w423019ordwN74Kbfxfo294p5nixcSH//W 08/g==
X-Received: by 10.194.60.203 with SMTP id j11mr32682210wjr.5.1427406589429; Thu, 26 Mar 2015 14:49:49 -0700 (PDT)
Received: from [2001:67c:370:160::] ([2001:67c:370:160:5d4e:b872:71ef:5c35]) by mx.google.com with ESMTPSA id dc9sm684133wib.9.2015.03.26.14.49.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 14:49:48 -0700 (PDT)
Date: Thu, 26 Mar 2015 16:49:46 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <BBFF77C7C8964BE084346F1F1FD63923@gmail.com>
In-Reply-To: <AC3FB7FF-ED00-471C-8FF1-A83FD337E4B1@yegin.org>
References: <551455AB.80600@innovationslab.net> <C5C3BB522B1DDF478AA09545169155B46E33205B@nkgeml507-mbx.china.huawei.com> <AC3FB7FF-ED00-471C-8FF1-A83FD337E4B1@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55147efa_c0a92d4_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/rD4-m88S3Gb8JoLprx2TQD9-u-0>
Cc: "Weixinpeng \(Jackie\)" <weixinpeng@huawei.com>, "=?utf-8?Q?dmm=40ietf.org?=" <dmm@ietf.org>
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 21:49:53 -0000

--55147efa_c0a92d4_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Alper, =20

Please note that we still need mailing list confirmation for call for ado=
ption of the API document. So even now we can not say that we have =E2=80=
=9Ccommon udnerstadning=E2=80=9C from the group. Your claim of  =E2=80=9C=
common understanding across the WG=E2=80=9D is not exist.  As Brian menti=
oned, agreement within WT or among draft authors does not mean it is the =
consensus of the group.  The group should always keep open and welcome an=
yone to ask any question. =20

-- =20
Dapeng Liu


=E5=9C=A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=
=BC=8C=E4=B8=8B=E5=8D=884:19=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A

> Hi Xinpeng,
> =20
> On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:
> =20
> > I think it's good to start serval work teams to process the work.
> > If there are some people complain about this, I think the reason woul=
d be that it
> > might be not convient for them to participate in the online interim m=
eeting for reasons such as timezone etc.
> > =20
> =20
> =20
> It's always a challenge to find timeslots that works for everyone, cons=
idering the around-the-world participation in DMM (in a way, that's true =
:-)
> =20
> > My another feeling is that after the forming of teams there is really=
 rare discussion in the maillist where should =20
> > be the main discussing place of IET=46. So my suggestion is that even=
 though there are work teams, please also
> > bring the discussion to mail list.
> > =20
> =20
> =20
> That's why we, WT leaders, publish meeting notes, so that people who we=
re not at the meeting can join the discussion on the mailing list,
> and this is, again, why WT leaders present the status at each IET=46 me=
eting.
> =20
> My issue is=E2=80=A6.. some people don't read the meeting notes.. they =
don't read the I-D. they don't follow the email discussions. They don't e=
ven remember what we presented at the previous IET=46 and established as =
common understanding across the WG. They don't bring up any discussion fo=
r things that has been out there at least 2 IET=46 meeting cycles=E2=80=A6=
 And then=21 ask questions as if this is the first time we are presenting=
 it (for very specific example: need for 3 distinct types of IP addresses=
). And then, this causing us significant amount of productivity loss=E2=80=
=A6. =20
> =20
> Alper
> =20
> =20
> =20
> > Thanks.
> > =20
> > -Xinpeng
> > =20
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org (mailto:dm=
m-bounces=40ietf.org)=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =5Bbrian=40inn=
ovationslab.net (mailto:brian=40innovationslab.net)=5D
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=
=A5 2:53
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm=40ietf.org (mailto:dmm=40ietf.org)
> > =E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams
> > =20
> > DMM WG,
> > I want to, once again, clarify the guiding principles for the DMM
> > work teams. Hopefully, this will make it clear to all participants ho=
w
> > the work teams will influence the WG. The guiding principles are:
> > =20
> > 1. All work teams are open to input from anyone
> > =20
> > 2. Any work team holding a meeting will announce that meeting to the =
WG
> > =20
> > 3. Any document produced by a work team is treated as any individual =
draft
> > =20
> > 4. Anyone can publish alternative proposals and ask the WG to conside=
r them
> > =20
> > 5. WG consensus will drive the adoption of any solutions drafts (work=

> > team generated or otherwise).
> > =20
> > If you have any questions about the above, please contact me.
> > =20
> > Regards,
> > Brian
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > dmm mailing list
> > dmm=40ietf.org (mailto:dmm=40ietf.org)
> > https://www.ietf.org/mailman/listinfo/dmm
> > =20
> =20
> =20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> dmm mailing list
> dmm=40ietf.org (mailto:dmm=40ietf.org)
> https://www.ietf.org/mailman/listinfo/dmm
> =20
> =20



--55147efa_c0a92d4_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>Hi Alper,
                </div><div><br></div><div>Please note that we still need =
mailing list confirmation for call for adoption of the API document. So e=
ven now we can not say that we have =E2=80=9Ccommon udnerstadning=E2=80=9C=
 from the group. Your claim of &nbsp;=E2=80=9Ccommon understanding across=
 the WG=E2=80=9D is not exist. &nbsp;As Brian mentioned, agreement within=
 WT or among draft authors does not mean it is the consensus of the group=
. &nbsp;The group should always keep open and welcome anyone to ask any q=
uestion.&nbsp;</div><div><div><br></div><div>--&nbsp;</div><div>Dapeng Li=
u</div><div><br></div><div></div></div>
                =20
                <p style=3D=22color: =23A0A0A8;=22>=E5=9C=A8 2015=E5=B9=B4=
3=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C=E4=B8=8B=E5=8D=
=884:19=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</p>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div>Hi Xinpeng,</div><div><br></div>=
<div>On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:</div><div><=
br></div><blockquote type=3D=22cite=22><div><div>I think it's good to sta=
rt serval work teams to process the work.</div><div>If there are some peo=
ple complain about this, I think the reason would be that it</div><div>mi=
ght be not convient for them to participate in the online interim meeting=
 for reasons such as timezone etc.</div></div></blockquote><div><br></div=
><div>It's always a challenge to find timeslots that works for everyone, =
considering the around-the-world participation in DMM (in a way, that's t=
rue :-)</div><div><br></div><blockquote type=3D=22cite=22><div><div>My an=
other feeling is that after the forming of teams there is really rare dis=
cussion in the maillist where should </div><div>be the main discussing pl=
ace of IET=46. So my suggestion is that even though there are work teams,=
 please also</div><div>bring the discussion to mail list.</div></div></bl=
ockquote><div><br></div><div>That's why we, WT leaders, publish meeting n=
otes, so that people who were not at the meeting can join the discussion =
on the mailing list,</div><div>and this is, again, why WT leaders present=
 the status at each IET=46 meeting.</div><div><br></div><div>My issue is=E2=
=80=A6.. some people don't read the meeting notes.. they don't read the I=
-D. they don't follow the email discussions. They don't even remember wha=
t we presented at the previous IET=46 and established as common understan=
ding across the WG. They don't bring up any discussion for things that ha=
s been out there at least 2 IET=46 meeting cycles=E2=80=A6 And then=21 as=
k questions as if this is the first time we are presenting it (for very s=
pecific example: need for 3 distinct types of IP addresses). And then, th=
is causing us significant amount of productivity loss=E2=80=A6. </div><di=
v><br></div><div>Alper</div><div><br></div><div><br></div><blockquote typ=
e=3D=22cite=22><div></div></blockquote><div><br></div><blockquote type=3D=
=22cite=22><div><div>Thanks.</div><div><br></div><div>-Xinpeng</div><div>=
<br></div><div>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F</div><div>=E5=
=8F=91=E4=BB=B6=E4=BA=BA: dmm =5B<a href=3D=22mailto:dmm-bounces=40ietf.o=
rg=22>dmm-bounces=40ietf.org</a>=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =5B=
<a href=3D=22mailto:brian=40innovationslab.net=22>brian=40innovationslab.=
net</a>=5D</div><div>=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=
=E6=9C=8827=E6=97=A5 2:53</div><div>=E6=94=B6=E4=BB=B6=E4=BA=BA: <a href=3D=
=22mailto:dmm=40ietf.org=22>dmm=40ietf.org</a></div><div>=E4=B8=BB=E9=A2=98=
: =5BDMM=5D DMM work teams</div><div><br></div><div>DMM WG,</div><div>   =
 I want to, once again, clarify the guiding principles for the DMM</div><=
div>work teams. Hopefully, this will make it clear to all participants ho=
w</div><div>the work teams will influence the WG.  The guiding principles=
 are:</div><div><br></div><div>1. All work teams are open to input from a=
nyone</div><div><br></div><div>2. Any work team holding a meeting will an=
nounce that meeting to the WG</div><div><br></div><div>3. Any document pr=
oduced by a work team is treated as any individual draft</div><div><br></=
div><div>4. Anyone can publish alternative proposals and ask the WG to co=
nsider them</div><div><br></div><div>5. WG consensus will drive the adopt=
ion of any solutions drafts (work</div><div>team generated or otherwise).=
</div><div><br></div><div>If you have any questions about the above, plea=
se contact me.</div><div><br></div><div>Regards,</div><div>Brian</div><di=
v>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F</di=
v><div>dmm mailing list</div><div><a href=3D=22mailto:dmm=40ietf.org=22>d=
mm=40ietf.org</a></div><div><a href=3D=22https://www.ietf.org/mailman/lis=
tinfo/dmm=22>https://www.ietf.org/mailman/listinfo/dmm</a></div></div></b=
lockquote><div><br></div><div>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F</div><div>dmm mailing list</div><div><a href=3D=22m=
ailto:dmm=40ietf.org=22>dmm=40ietf.org</a></div><div><a href=3D=22https:/=
/www.ietf.org/mailman/listinfo/dmm=22>https://www.ietf.org/mailman/listin=
fo/dmm</a></div></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--55147efa_c0a92d4_a9e--


From nobody Thu Mar 26 15:02:53 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55381B2F9C for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwT72_YEePwo for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:02:43 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6C1B2DC9 for <dmm@ietf.org>; Thu, 26 Mar 2015 15:02:41 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QM2cux028062; Thu, 26 Mar 2015 23:02:38 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4FDAD2051D6; Thu, 26 Mar 2015 23:03:24 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 43A0F2050EE; Thu, 26 Mar 2015 23:03:24 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QM2Wcx009953; Thu, 26 Mar 2015 23:02:38 +0100
Message-ID: <551481F8.9090507@gmail.com>
Date: Thu, 26 Mar 2015 17:02:32 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jouni Korhonen <jouni.nospam@gmail.com>, dmm@ietf.org
References: <A730EA79-F6CF-49CD-9933-9FDA4AA75541@yegin.org> <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com>
In-Reply-To: <55144D3F.2030002@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/8sCyBlfdhwpBpywlgtpm25QD2PI>
Subject: Re: [DMM] Mobility Exposure and Selection WT call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 22:02:47 -0000

Le 26/03/2015 13:17, Jouni Korhonen a écrit :
> Alex,
>
> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:
>
> [snip]
>
>>> I thought by "fixed" you meant it stays the same wherever the Host goes
>>> (something like the Home Address).
>>
>> Alper - I think a LL address can also be qualified as 'fixed' - it never
>> changes.
>
> Does LL here mean link-local or link-layer? If it is the former one,
> then the above assertion is not correct.

Link-local.

And you seem to say a link-local address is not fixed?  I think 
link-local addresses _are_ fixed set in stone.  They are formed locally 
without need of help from router.

Alex

>
> - Jouni
>
>>
>> I think it's hard to disagree with that, no?
>>
>> Alex
>>
>>>
>>> So, I guess, I should have referred to the "nomadic" address to mean the
>>> one that is constant, wherever the Host goes.
>>>
>>> As such, my suggestion is that a "nomadic" address can never be an
>>> RFC7217 address.
>>>
>>> In practice that would mean that if you configure an address to be
>>> "nomadic" you must also tell the kernel to not run RFC7217 on it.
>>>
>>> But ok, one might think that these two aspects ("nomadic" and RFC7217)
>>> are orthogonal at this point in time.
>>>
>>> Alex
>>>
>>>>
>>>> I don't know if it makes sense to request a fixed and random-based IP
>>>> address. But if someone does it, it works.
>>>
>>>
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
>>>>>>> 6775).
>>>>>>>
>>>>>>
>>>>>> Orthogonal.
>>>>>>
>>>>>>
>>>>>>> E.g. a nomadic address could never be a link-local address.
>>>>>>>
>>>>>>>> #2. Describe how IP address type information is conveyed from
>>>>>>>> network to MN.
>>>>>>>
>>>>>>> If one designs a protocol to convey address type information from
>>>>>>> the network to the end node, then one could also add the other
>>>>>>> types mentioned above.
>>>>>>>
>>>>>>> SLAAC could never 'convey' the address type to the end-node,
>>>>>>> because SLAAC is an operation happening with as heavy weight from
>>>>>>> the Server (router) as from the Client (Host): the Router decides
>>>>>>> the prefix but the Client decides the Interface ID.
>>>>>>>
>>>>>>
>>>>>> Still, the network can convey the type of IP address to the host.
>>>>>> Also, one can imagine augmenting Router Solicitation to let the host
>>>>>> convey its requested type.
>>>>>
>>>>> I agree.
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>>> Address Registration Option of 6lo and BTLE would have the Host
>>>>>>> conveying this information to the Router (and not vice-versa).
>>>>>>>
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>> Yours,
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
>>>>>>>> baseline for item#1 (the API). A revision of the draft will also
>>>>>>>> include a new section to cover backward compatibility (Danny will
>>>>>>>> provide the draft text). Comments on the draft are welcome.
>>>>>>>>
>>>>>>>> The next call will be about items #2/#3 (IP address
>>>>>>>> configuration enhancements associated with the API). We intend to
>>>>>>>> schedule that one in about 2 weeks.
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> See below for the Webex details. Remember, the call is on Tue,
>>>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
>>>>>>>>> the reading list prior to the call.
>>>>>>>>>
>>>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>>>
>>>>>>>>>> 1.
>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>
>>>>>>>>>>
>>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>> 3.
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alper
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
>>>>>>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
>>>>>>>>>
>>>>>>>>>> *Join WebEx meeting*
>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>> Meeting number:641 085 326
>>>>>>>>>> Meeting password:dmm1911
>>>>>>>>>>
>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
>>>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
>>>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions
>>>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>>>>>>
>>>>>>>>>> Add this meeting
>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> to your calendar.
>>>>>>>>>>
>>>>>>>>>> Can't join the meeting? Contact support.
>>>>>>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>>>>>>
>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
>>>>>>>>>> audio and other information sent during the session to be
>>>>>>>>>> recorded, which may be discoverable in a legal matter. By
>>>>>>>>>> joining this session, you automatically consent to such
>>>>>>>>>> recordings. If you do not consent to being recorded, discuss
>>>>>>>>>> your concerns with the host or do not join the session.
>>>>>>>>>>
>>>>>>>>> <WebEx_Meeting.ics>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>>>>>>
>>>>>>>>>> Poll is closed, and majority selected the following date for
>>>>>>>>>> the call:
>>>>>>>>>>
>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>>>>>>
>>>>>>>>>> Please mark your calendars.
>>>>>>>>>>
>>>>>>>>>> In this call, we'll aim making progress on the I-D for item#1
>>>>>>>>>> (an API for source address selection).
>>>>>>>>>>
>>>>>>>>>> Attendees _shall read _the following material before the call
>>>>>>>>>> so that we can directly jump to the discussions:
>>>>>>>>>>
>>>>>>>>>> 1.
>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>
>>>>>>>>>>
>>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>> 3.
>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Alper
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
>>>>>>>>>>
>>>>>>>>>>> Folks,
>>>>>>>>>>>
>>>>>>>>>>> Please mark your availability on the following doodle for
>>>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
>>>>>>>>>>>
>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>>>>>>
>>>>>>>>>>> Register your availability no later than the end of Monday
>>>>>>>>>>> (Jan 26).
>>>>>>>>>>>
>>>>>>>>>>> Alper
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ dmm mailing list
>>>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ dmm mailing list
>>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>>>
>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>



From nobody Thu Mar 26 15:04:49 2015
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF01B2F9A for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SUjiVPdDVDB for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:04:45 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE6D1B2DC9 for <dmm@ietf.org>; Thu, 26 Mar 2015 15:04:45 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t2QM4hEW032305 for <dmm@ietf.org>; Thu, 26 Mar 2015 23:04:43 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F21C20515B for <dmm@ietf.org>; Thu, 26 Mar 2015 23:05:28 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8BF432050EE for <dmm@ietf.org>; Thu, 26 Mar 2015 23:05:28 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t2QM4fkn011529 for <dmm@ietf.org>; Thu, 26 Mar 2015 23:04:42 +0100
Message-ID: <55148279.4090608@gmail.com>
Date: Thu, 26 Mar 2015 17:04:41 -0500
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <551455AB.80600@innovationslab.net> <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org>
In-Reply-To: <73CC9B03-BA40-41F8-B124-022E053B0E1F@yegin.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/0Heeh7sv2xzezxNtt0a-rtCpCDc>
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 22:04:47 -0000

Le 26/03/2015 14:01, Alper Yegin a écrit :
> Brian,
>
> This is exactly how WTs have been operating.
>
> Anyone thinking otherwise is not closely following the work.

Alper,

I agree.  Just one little comment: some times it is difficult to 
participate to audioconferences.

Alex

>
> Alper
>
>
> On Mar 26, 2015, at 8:53 PM, Brian Haberman wrote:
>
>> DMM WG,
>>      I want to, once again, clarify the guiding principles for the DMM
>> work teams. Hopefully, this will make it clear to all participants how
>> the work teams will influence the WG.  The guiding principles are:
>>
>> 1. All work teams are open to input from anyone
>>
>> 2. Any work team holding a meeting will announce that meeting to the WG
>>
>> 3. Any document produced by a work team is treated as any individual draft
>>
>> 4. Anyone can publish alternative proposals and ask the WG to consider them
>>
>> 5. WG consensus will drive the adoption of any solutions drafts (work
>> team generated or otherwise).
>>
>> If you have any questions about the above, please contact me.
>>
>> Regards,
>> Brian
>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>



From nobody Thu Mar 26 15:17:47 2015
Return-Path: <weixinpeng@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD841A011D for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.74
X-Spam-Level: *
X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR43WfTYsDwi for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 15:17:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68341A01D8 for <dmm@ietf.org>; Thu, 26 Mar 2015 15:17:38 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQT16444; Thu, 26 Mar 2015 22:17:37 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 22:17:35 +0000
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.79]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 06:17:29 +0800
From: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
To: Alper Yegin <alper.yegin@yegin.org>
Thread-Topic: =?gb2312?B?UmWjuiBETU0gQVBJ?=
Thread-Index: AQHQZ+vETXUKkoT1hkqe8nT0z2URPp0uiyIAgACqUpP//4urAIAAivUQ
Date: Thu, 26 Mar 2015 22:17:28 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B46E3320DF@nkgeml507-mbx.china.huawei.com>
References: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>,  <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org> <C5C3BB522B1DDF478AA09545169155B46E332048@nkgeml507-mbx.china.huawei.com>, <DCBFFB95-180A-4109-91B1-95CF5155A80B@yegin.org>
In-Reply-To: <DCBFFB95-180A-4109-91B1-95CF5155A80B@yegin.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.148.34]
Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/TNZTND4ForBj4CljNT1XJa3Jx3U>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] =?gb2312?b?tPC4tDogUmWjuiBETU0gQVBJ?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 22:17:45 -0000

--_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

QWxwZXIsDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbi4gQW5kIHRoZXJlIGFy
ZSBzb21lIG9mIG15IHJlcGxpZXMgaW5saW5lLg0KDQoNCg0KVGhhbmtzLg0KDQotWGlucGVuZw0K
DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEFscGVy
IFllZ2luIFthbHBlci55ZWdpbkB5ZWdpbi5vcmddDQq3osvNyrG85DogMjAxNcTqM9TCMjfI1SA1
OjI2DQrK1bz+yMs6IFdlaXhpbnBlbmcgKEphY2tpZSkNCrOty806IERhcGVuZyBMaXU7IGRtbUBp
ZXRmLm9yZw0K1vfM4jogUmU6IFJlo7ogRE1NIEFQSQ0KDQpYaW5wZW5nLA0KDQpJJ2xsIGdpdmUg
eW91IGEgY291bnRlciBleGFtcGxlIHRvIHdoYXQgeW91IGFyZSBjbGFpbWluZy4NCg0KSW1hZ2lu
ZSB5b3UgYXJlIGRldmVsb3BpbmcgYSBjaGF0IChJTSkgY2xpZW50Lg0KQmVjYXVzZSB5b3VyIGFw
cCB3aWxsIGJlIHJ1bm5pbmcgb24gdGVybWluYWxzIHRoYXQnZCBjb25uZWN0IHRvIGJvdGggY2Vs
bHVsYXIgYW5kIFdpRmkgbmV0d29ya3MsIHlvdSBkb24ndCBoYXZlIGFueSBvdGhlciBvcHRpb24g
YnV0IHRvIGltcGxlbWVudCBhcHAtbGF5ZXIgbW9iaWxpdHkgbWFuYWdlbWVudCAoYmVjYXVzZSBv
dGhlcndpc2UgeW91ciBjaGF0IHNlc3Npb25zIHdpbGwgYnJlYWsgd2hlbiB0aGUgdGVybWluYWwg
bW92ZXMgaW4gYW5kIG91dCBvZiBXaUZpIGhvdHNwb3RzKS4NCg0KW1dlaV0gTXkgdW5kZXJzdGFu
ZGluZyBhYm91dGggdGhlIHJlYXNvbiB3aHkgYXBwbGljYXRpb24gZGV2ZWxvcGVyIGltcGxlbWVu
dHMgYXBwbGljYXRpb24gbGF5ZXIgc3VwcG9ydCBpcyB0aGF0IHRoZSBob3N0J3MgSVAgYWRkcmVz
cyBtaWdodCBjaGFuZ2Ugd2hlbiB0aGVpciBhcHBsaWNhdGlvbiBpcyBydW5uaW5nLCBzbyB0aGV5
ICoqaGF2ZSB0byoqIHByb3ZpZGUNCg0KbWVjaGFuaXNtIHRvIGNvcGUgd2l0aCB0aGUgc2l0dWF0
aW9uLCBidXQgaXQncyBub3QgdGhlaXIgd2lsbGluZyB0byBjaGFuZ2UgdGhlIElQIGFkZHJlc3Mu
IEFkZGl0aW9uYWwsIFRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgbWlnaHQgYmUgYSBiaXQgb2Yg
Y29uZnVzZWQgd2l0aCB0aGUgbmFtZSBvZiAiTm9tYWRpYyBhZGRyZXNzIiwgdGhleXdvdWxkIGp1
c3QgdGhpbmsgdGhlIG5vbWFkaWMgYWRkcmVzcyBpcyBhIGtpbmQgb2YgYWRkcmVzcyB0aGF0IHdv
dWxkIGJlIGNoYW5nZWQuDQoNCk5vdywgZ2l2ZW4gdGhhdCB5b3UgYWxyZWFkeSBpbXBsZW1lbnRl
ZCBhcHAtbGF5ZXIgbW9iaWxpdHksIGl0J3MgdG8geW91ciBhZHZhbnRhZ2UgdG8gdXNlIGl0IGV2
ZW4gd2hlbiB5b3UgYXJlIG9uIGNlbGx1bGFyIG5ldHdvcmssIGlmIHRoZXJlIHdhcyBhIHdheSB0
byB0ZWxsIHRoZSBuZXR3b3JrIHRvIHByb3ZpZGUgeW91IGEgbm9tYWRpYyBJUCBhZGRyZXNzIChh
cyBvcHBvc2VkIHRvIGZpeGVkL21vYmlsZSBJUCBhZGRyZXNzIHRoYXQgaXQnZCBub3JtYWxseSBk
bykuIEJlY2F1c2UgdGhhdCB3YXksIHlvdSBlbnN1cmUgeW91ciBJUCBwYWNrZXRzIHRha2UgdGhl
IHNob3J0ZXN0IHBhdGgsIHdoaWNoIHJlZHVjZXMgdGhlIGVuZDJlbmQgbGF0ZW5jeS4NCg0KW1dl
aV0gVGhlIGFwcGxpY2F0aW9uIGxheWVyIG1vYmlsaXR5IG1hbmFnZW1lbnQgYW5kIHRoZSByZWR1
bmRhbnQgcm91dGluZyBwYXRoIGJvdGggYnJpbmcgYWRkaXRpb25hbCBjb3N0ZXMsIGJ1dCBpdHMg
aGFyZCBmb3IgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0byBoYXZlIGFuIGlkZWEgd2hpY2ggb25l
IGhhcyBhIG1vcmUgbG93ZXIgY29zdC4NCg0KQmVzaWRlcywgd2UgYWxzbyBleHBlY3QgdGhhdCB0
aGUgbW9iaWxlIG5ldHdvcmsgb3BlcmF0b3JzIHdpbGwgcHJvbW90ZSAicHJvcGVyIHVzZSIgb2Yg
dGhlc2UgZmxhZ3MsIGJlY2F1c2UgdGhhdCBlbnN1cmVzIGVmZmljaWVudCB1c2Ugb2YgdGhlaXIg
bmV0d29yayByZXNvdXJjZXMuIExldHRpbmcgYW4gYXBwIHVzZSBhIGZpeGVkIElQIGFkZHJlc3Mg
d2hlbiBpdCBjb3VsZCB2ZXJ5IHdlbGwgdXNlIGEgbm9tYWRpYyBJUCBhZGRyZXNzIGlzIHdhc3Rl
IG9mIG5ldHdvcmsgcmVzb3VyY2VzIChiYWNrIGhhdWxpbmcsIFBHVyBjYXBhY2l0eSwgZXRjLikN
Cg0KW1dlaV0gQWdyZWUgdGhhdCBuZXR3b3JrIG9wZXJhdG9yIHdhbnRzIHRvIHJlZHVjZSB0aGVp
ciBuZXR3b3JrIGNvc3QsIGJ1dCB3ZSBjYW5ub3QgbWFrZSBzdXJlIHRoZSBhcHBsaWNhdGlvbiBk
ZXZlbG9wZXIgd2lsbCBiZWNhcmUgYWJvdXQgdG9vIG11Y2ggZm9yIHRoZSBvcGVyYXRvcnMuLi4N
Cg0KQXMgYSBmdXR1cmUgdGhpbmcsIHdlIGNhbiBldmVuIGVudmlzaW9uIG1vYmlsZSBvcGVyYXRv
cnMgY2hhcmdpbmcgZGlmZmVyZW50bHkgYmFzZWQgb24gdGhlIHR5cGUgb2YgdHJhZmZpYyAtLSBh
ZnRlciBhbGwgZWFjaCB0eXBlIGlzIGNvbnN1bWluZyBkaWZmZXJlbnQgYW1vdW50cyBvZiBuZXR3
b3JrIHJlc291cmNlcy4NCg0KQWxwZXINCg0KDQpPbiBNYXIgMjYsIDIwMTUsIGF0IDEwOjQyIFBN
LCBXZWl4aW5wZW5nIChKYWNraWUpIHdyb3RlOg0KDQpIaSBBbHBlciwNCkZvciBhbiBhcHBsaWNh
dGlvbiBkZXZlbG9wZXIsIGlmIHRoZXJlIGFyZSB0aHJlZSBraW5kcyBvZiBhZGRyZXNzZXMgdG8g
dXNlIHdoaWNoIGFyZSAiRml4ZWQgSVAgQWRkcmVzcyIsICJTdXN0YWluZWQgSVAgQWRkcmVzcyIg
YW5kICJOb21hZGljIElQIEFkZHJlc3MiLA0KdGhlbiBJIGJlbGlldmUgdGhlIGRldmVsb3BlciB3
b3VsZCBhbHdheXMgd2FudHMgdG8gdXNlIHRoZSAiRml4ZWQgSVAgYWRkcmVzcyIsIHJhdGhlciB0
aGFuIHRoZSBvdGhlciBvbmVzLiBCZWNhdXNlIGV2ZW4gdGhvdWdoIHRoZSBhcHBsaWNhdGlvbiBj
b3VsZCBjb3BlIHdpdGggSVAgYWRkcmVzcw0KY2hhbmdlLCBidXQgdGhlIElQIGFkZHJlc3MgY2hh
bmdlIGlzIG5vdCB3aGF0IHRoZSBhcHBsaWNhdGlvbiB3YW50Lg0KDQoNCg0KLVhpbnBlbmcNCg0K
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBBbHBlciBZ
ZWdpbiBbYWxwZXIueWVnaW5AeWVnaW4ub3JnPG1haWx0bzphbHBlci55ZWdpbkB5ZWdpbi5vcmc+
XQ0Kt6LLzcqxvOQ6IDIwMTXE6jPUwjI3yNUgMjoxMw0KytW8/sjLOiBXZWl4aW5wZW5nIChKYWNr
aWUpDQqzrcvNOiBEYXBlbmcgTGl1OyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4N
Ctb3zOI6IFJlOiBSZaO6IERNTSBBUEkNCg0KSGkgWGlucGVuZywNCg0KSWYgeW91ciBhcHAga25v
d3MgaG93IHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZXMsIHRoZW4gaXQncyBiZXR0ZXIg
aWYgd2UgZ2l2ZSBpdCBhIGNoYW5jZSB0byBkbyBzbywgYmVjYXVzZSAoYXMgdGhlIEktRCBleHBs
YWlucyk6DQoNCg0KICAgQWNoaWV2aW5nIElQIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAgYWRk
cmVzcyByZWFjaGFiaWxpdHkgYnkgdXNpbmcNCiAgIE1vYmlsZSBJUCBpbmN1cnMgc29tZSBjb3N0
LiAgTW9iaWxlIElQIHByb3RvY29sIGZvcmNlcyB0aGUgbW9iaWxlDQogICBob3N0J3MgSVAgdHJh
ZmZpYyB0byB0cmF2ZXJzZSBhIGNlbnRyYWxseS1sb2NhdGVkIHJvdXRlciAoSG9tZSBBZ2VudCwN
CiAgIEhBKSwgd2hpY2ggaW5jdXJzIGFkZGl0aW9uYWwgdHJhbnNtaXNzaW9uIGxhdGVuY3kgYW5k
IHVzZSBvZg0KICAgYWRkaXRpb25hbCBuZXR3b3JrIHJlc291cmNlcywgYWRkcyB0byB0aGUgbmV0
d29yayBDQVBFWCBhbmQgT1BFWCwgYW5kDQogICBkZWNyZWFzZXMgdGhlIHJlbGlhYmlsaXR5IG9m
IHRoZSBuZXR3b3JrIGR1ZSB0byB0aGUgaW50cm9kdWN0aW9uIG9mIGENCiAgIHNpbmdsZSBwb2lu
dCBvZiBmYWlsdXJlIFtJLUQuaWV0Zi1kbW0tcmVxdWlyZW1lbnRzXS4gIFRoZXJlZm9yZSwgSVAN
CiAgIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAgYWRkcmVzcyByZWFjaGFiaWxpdHkgc2hvdWxk
IGJlIGJlIHByb3ZpZGVkDQogICBvbmx5IHdoZW4gbmVlZGVkLg0KDQoNCkFscGVyDQoNCk9uIE1h
ciAyNiwgMjAxNSwgYXQgNzozOSBQTSwgV2VpeGlucGVuZyAoSmFja2llKSB3cm90ZToNCg0KSGkg
QWxwZXINCk15IHVuZGVyc3RhbmRpbmcgYWJvdXQgdGhlIHJlYXNvbiB3aHkgdGhlcmUgbmVlZHMg
dG8gZGVmaW5lIHNlcnZhbCB0eXBlcyBvZiBJUCBwcmVmaXhlcyBpcyB0aGF0LCAgaWYgdGhlIGFw
cGxpY2F0aW9uIGl0c2VsZiBjb3VsZCBkZWFsIHdpdGggdGhlIGNoYW5nZSBvZiBJUCBhZGRyZXNz
LCBpLmUuIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgY291bGQgZGVhbCB3aXRoIHNlc3Npb24gY29u
dGludXR5IGluIGNhc2Ugb2YgSVAgYWRkcmVzcyBjaGFuZ2UsIHNvIHRoZSBob3N0IHdvdWxkIGNo
b29zZSBhIG5vcm1hZGljIGFkZHJlc3Mgb3RoZXJ3aXNlIHRoZSBob3N0IHNob3VsZCBjaG9vc2Ug
YSBzdXN0YWluZWQgYWRkcmVzcy4NCkJ1dCBteSBxdWVzdGlvbiBpcyB0aGF0LCBpZiB0aGUgYXBw
bGljYXRpb24gY291bGQgZGVhbCB3aXRoIHNlc3Npb24gY29udGludXR5IGl0c2VsZiwgZG9lcyB0
aGF0IG1lYW4gdGhlIGFwcGxpY2F0aW9uIGlzIHdpbGxpbmcgdG8gY2hhbmdlIGl0cyBJUCBhZGRy
ZXNzPyBCZWNhdXNlIGV2ZW4gdGhvdWdoIGEgbmV3IGFkZHJlc3MgbWlnaHQgYnJpbmcgc29tZSBr
aW5kcyBvZiBiZW5lZml0LCBidXQgaXQgd2lsbCBhbHNvDQpicmluZyBhZGRpdGlvbmFsIGNvc3Qg
Zm9yIGFwcGxpY2F0aW9uIHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzIGNoYW5nZS4NClRoYW5rcy4N
Cg0KDQoNClhpbnBlbmcNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0Kt6K8/sjLOiBkbW0gW2RtbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkbW0tYm91bmNlc0Bp
ZXRmLm9yZz5dILT6se0gRGFwZW5nIExpdSBbbWF4cGFzc2lvbkBnbWFpbC5jb208bWFpbHRvOm1h
eHBhc3Npb25AZ21haWwuY29tPl0NCreiy83KsbzkOiAyMDE1xOoz1MIyNsjVIDU6MDENCsrVvP7I
yzogQWxwZXIgWWVnaW4NCrOty806IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0K
1vfM4jogW0RNTV0gu9i4tKO6IERNTSBBUEkNCg0KSGVsbG8gQWxwZXIsDQoNCkkgc3RpbGwgaGF2
ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQoxLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24g
b2YgobBmaXhlZCBJUCBhZGRyZXNzobEgaW4gdGhlIGRyYWZ0Og0KDQogIKGwLSBGaXhlZCBJUCBB
ZGRyZXNzDQoNCiAgIFRoaXMgaXMgd2hhdCBzdGFuZGFyZCBNb2JpbGUgSVAgcHJvdmlkZXMgd2l0
aCBhIEhvbWUgQWRkcmVzcyAoSG9BKS4NCiAgIFRoZSBtb2JpbGUgaG9zdCBpcyBjb25maWd1cmVz
IGEgSG9BIGZyb20gYSBjZW50cmFsbHktbG9jYXRlZCBIb21lDQogICBOZXR3b3JrLiAgQm90aCBJ
UCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGFyZQ0KICAg
cHJvdmlkZWQgdG8gdGhlIG1vYmlsZSBob3N0IHdpdGggdGhlIGhlbHAgb2YgYSByb3V0ZXIgaW4g
dGhlIEhvbWUNCiAgIE5ldHdvcmsgKEhvbWUgQWdlbnQsIEhBKS4gIFRoaXMgcm91dGVyIGFjdHMg
YXMgYW4gYW5jaG9yIGZvciB0aGUgSVANCg0KYWRkcmVzcyBvZiB0aGUgbW9iaWxlIGhvc3QuobEN
Cg0KSWYgdGhpcyBpcyBlcXVhbCB0byBIb0EsIHRoZW4gUkZDNTAxNCBhbHJlYWR5IGNvdmVyIHRo
YXQuIFdlIGRvIG5vdCBuZWVkIHRvIHJlcGVhdCBpdCBoZXJlIHdpdGggYW5vdGhlciBuYW1lLg0K
DQoyLiBSZWdhcmRpbmcgdGhlIGRlZmluaXRpb24gb2YgobBzdXN0YWluZWQgSVAgYWRkcmVzc6Gx
IGluIHRoZSBkcmFmdDoNCg0KDQoiLSBTdXN0YWluZWQgSVAgQWRkcmVzcw0KDQogICBUaGlzIHR5
cGUgb2YgSVAgYWRkcmVzcyBwcm92aWRlcyBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgYnV0IG5vdCBJ
UA0KICAgYWRkcmVzcyByZWFjaGFiaWxpdHkuICBJdCBpcyBhY2hpZXZlZCBieSBlbnN1cmluZyB0
aGF0IHRoZSBJUCBhZGRyZXNzDQogICB1c2VkIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlc3Np
b24gcmVtYWlucyB1c2FibGUgZGVzcGl0ZSB0aGUNCiAgIG1vdmVtZW50IG9mIHRoZSBtb2JpbGUg
aG9zdC4gIFRoZSBJUCBhZGRyZXNzIG1heSBjaGFuZ2UgYWZ0ZXIgdGhlDQogICB0ZXJtaW5hdGlv
biBvZiB0aGUgSVAgc2Vzc2lvbihzKSwgdGhlcmVmb3JlIGl0IGRvZXMgbm90IGV4aGliaXQNCiAg
IHBlcnNpc3RlbmNlLg0KIg0KDQpUaGVyZSBpcyBubyBjbGVhciBkaXZpZGluZyBsaW5lIGJldHdl
ZW4gZml4ZWQgSVAgYWRkcmVzcyBhbmQgc3VzdGFpbmVkIElQIGFkZHJlc3MuIFdoZXRoZXIgdGhl
IElQIGFkZHJlc3MgaXMgdXNlZCBmb3IgcmVhY2hhYmlsaXR5IGlzIG5vdCBkZXRlcm1pbmVkIGJ5
IHRoZSBJUCBhZGRyZXNzIGl0c2VsZi4gRm9yIGV4YW1wbGUsIGV2ZW4gd2hlbiB0aGUgTU4gZ2V0
IGEgSG9BLCBhZnRlciBpdCBtb3ZlcyB0byBhbm90aGVyIGxvY2F0aW9uIG9mIHRoZSBuZXR3b3Jr
LCBpdCBtYXkgZGVjaWRlIHRvIHJlbGVhc2UgY3VycmVudCBIb0EgYW5kIGdldCBhbm90aGVyIEhv
QSwgaW4gdGhpcyBjYXNlIHRoZSAiZml4ZWQgSVAgYWRkcmVzcyIgYmVjb21lcyBhICJzdXN0YWlu
ZWQgSVAgYWRkcmVzcyIuDQoNCkZ1cnRoZXIgbW9yZSwgdGhlIHJlYWNoYWJpbGl0eSBub3JtYWxs
eSBpcyBpbXBsZW1lbnRlZCBieSBkb21haW4gbmFtZSBpbnN0ZWFkIG9mIElQIGFkZHJlc3MuIEZv
ciBleGFtcGxlLCB3ZSByZWFjaCChsEdvb2dsZaGxIGJ5IGl0cyBkb21haW4gbmFtZSwgbmV2ZXIg
YnkgaXShr3Mgc2VydmVyoa9zIElQIGFkZHJlc3MuDQoNClVzaW5nIHRlbXBvcmFyeSBwcml2YXRl
IElQIGFkZHJlc3Mgd2UgY2FuIGFsc28gYWNoaWV2ZSB0aGUgZ29hbCBvZiChsHJlYWNoYWJpbGl0
eaGxLiBGb3IgZXhhbXBsZSwgdXNpbmcgZHluYW1pYyBETlMsIGFzIHNob3duIGluICBodHRwOi8v
aHNrLm9yYXkuY29tLyAsIGl0IGNhbiAgcHJvdmlkZSByZWFjaGFiaWxpdHkgZXZlbiB0aGUgaG9z
dCBnZXQgYSBwcml2YXRlIElQIGFkZHJlc3MuDQoNCjMuIFJlZ2FyZGluZyB0aGUgZGVmaW5pdGlv
biBvZiChsG5vbWFkaWMgSVAgYWRkcmVzc6GxOg0KDQqhsC0gTm9tYWRpYyBJUCBBZGRyZXNzDQoN
CiAgIFRoaXMgdHlwZSBvZiBJUCBhZGRyZXNzIHByb3ZpZGVzIG5laXRoZXIgSVAgc2Vzc2lvbiBj
b250aW51aXR5IG5vciBJUA0KICAgYWRkcmVzcyByZWFjaGFiaWxpdHkuICBUaGUgSVAgYWRkcmVz
cyBpcyBvYnRhaW5lZCBmcm9tIHRoZSBzZXJ2aW5nIElQDQogICBnYXRld2F5IGFuZCBpdCBpcyBu
b3QgbWFpbnRhaW5lZCBhY3Jvc3MgZ2F0ZXdheSBjaGFuZ2VzLiAgSW4gb3RoZXINCiAgIHdvcmRz
LCB0aGUgSVAgYWRkcmVzcyBtYXkgYmUgcmVsZWFzZWQgYW5kIHJlcGxhY2VkIGJ5IGEgbmV3IElQ
DQogICBhZGRyZXNzIHdoZW4gdGhlIElQIGdhdGV3YXkgY2hhbmdlcyBkdWUgdG8gdGhlIG1vdmVt
ZW50IG9mIHRoZSBtb2JpbGUNCg0KaG9zdC6hsQ0KDQpTZWVtcyB0aGlzIElQIGFkZHJlc3MgaXMg
dGhlIElQIGFkZHJlc3MgdGhhdCB3ZSBub3JtYWxseSB1c2VkIGluIG1vc3QgY2FzZXMuIElmIHRo
aXMgaXMgdGhlIGNhc2UsIHdoeSB3ZSBuZWVkIGEgbmV3IG5hbWUgZm9yIGl0Pw0KDQoNCi0tDQpE
YXBlbmcgTGl1DQoNCtTaIDIwMTXE6jPUwjI1yNUg0MfG2sj9o6zPws7nMjowMqOsQWxwZXIgWWVn
aW4g0LS1wKO6DQpIZWxsbyBEYXBlbmcgYW5kIEFsZXgsDQoNCkkgaG9wZSB5b3UgaGFkIGEgY2hh
bmNlIHRvIGRpZ2VzdCBvdXIgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHMgYW5kIHF1ZXN0aW9u
cyBhYm91dCB0aGUgQVBJIHdvcmsuDQpJZiB5b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGlzc3Vlcywg
cGxlYXNlIGxldCB1cyBrbm93IG92ZXIgdGhlIGVtYWlsIGF0IHlvdXIgZWFybGllc3QgY29udmVu
aWVuY2UuDQpJdCdkIGJlIGdvb2QgaWYgeW91IGNhbiBhcnRpY3VsYXRlIHRoZW0gaW4gZGV0YWls
Lg0KDQoNClRoYW5rcy4NCg0KQWxwZXINCg0K

--_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body style=3D"WORD-WRAP: break-word" fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<p>Alper,</p>
<p>&nbsp;</p>
<p>Thanks for your clarification. And there are some of my replies inline.<=
/p>
<p>&nbsp;</p>
<p>Thanks.</p>
<p>-Xinpeng</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF358589"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b> Alper Yegin [alper.yeg=
in@yegin.org]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b> 2015=C4=EA3=D4=C227=C8=D5 5:26<br>
<b>=CA=D5=BC=FE=C8=CB:</b> Weixinpeng (Jackie)<br>
<b>=B3=AD=CB=CD:</b> Dapeng Liu; dmm@ietf.org<br>
<b>=D6=F7=CC=E2:</b> Re: Re=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>Xinpeng,
<div><br>
</div>
<div>I'll give you a counter example to what you are claiming.</div>
<div><br>
</div>
<div>Imagine you are developing a chat (IM) client.</div>
<div>Because your app will be running on terminals that'd connect to both c=
ellular and WiFi networks, you don't have any other option but to implement=
 app-layer mobility management (because otherwise your chat sessions will b=
reak when the terminal moves in
 and out of WiFi hotspots).</div>
<div>&nbsp;</div>
<div><font color=3D"#ff0000">[Wei] My understanding abouth the reason why a=
pplication developer implements application layer support is that the host'=
s IP address might change when their application is running, so they **have=
 to** provide</font>
<p><font color=3D"#ff0000">mechanism to cope with the situation, but it's n=
ot their willing to change the IP address. Additional, The&nbsp;application=
 developer&nbsp;might be a bit of confused with the name of &quot;Nomadic a=
ddress&quot;, theywould just think the nomadic address
 is a kind of address that would be changed.</p>
</font></div>
<div><br>
</div>
<div>Now, given that you already implemented app-layer mobility, it's to yo=
ur advantage to use it even when you are on cellular network, if there was =
a way to tell the network to provide you a nomadic IP address (as opposed t=
o fixed/mobile IP address that it'd
 normally do). Because that way, you ensure your IP packets take the shorte=
st path, which reduces the end2end latency.</div>
<div>&nbsp;</div>
<div><font color=3D"#ff0000">[Wei] The application layer mobility managemen=
t and the redundant routing path both bring additional costes, but its hard=
 for application developers to have an idea which one has a more lower cost=
.</font></div>
<div><br>
</div>
<div>Besides, we also expect that the mobile network operators will promote=
 &quot;proper use&quot; of these flags, because that ensures efficient use =
of their network resources. Letting an app use a fixed IP address when it c=
ould very well use a nomadic IP address is
 waste of network resources (back hauling, PGW capacity, etc.)</div>
<div>&nbsp;</div>
<div><font color=3D"#ff0000">[Wei] Agree that&nbsp;network operator wants t=
o reduce&nbsp;their network cost, but&nbsp;we cannot make sure the applicat=
ion developer will becare about too much for the operators...</font></div>
<div><br>
</div>
<div>As a future thing, we can even envision mobile operators charging diff=
erently based on the type of traffic -- after all each type is consuming di=
fferent amounts of network resources.&nbsp;</div>
<div><br>
</div>
<div>Alper</div>
<div><br>
</div>
<div><br>
<div>
<div>On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite"><span style=3D"WIDOWS: 2; TEXT-TRANSFORM: none; T=
EXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-S=
PACE: normal; ORPHANS: 2; LETTER-SPACING: normal; WORD-SPACING: 0px" class=
=3D"Apple-style-span">
<div style=3D"WORD-WRAP: break-word">
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: rgb(0,0,0); FONT-=
SIZE: 10pt">
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Hi Alper,</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">For&nbsp;an application =
developer, if there are three kinds of addresses to use which are &quot;Fix=
ed IP Address&quot;, &quot;Sustained IP Address&quot; and &quot;Nomadic IP =
Address&quot;,</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">then I believe the devel=
oper would always wants to use the &quot;Fixed IP address&quot;, rather tha=
n the other ones. Because even though the application could cope with IP ad=
dress</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">change, but the IP addre=
ss change is not what the application&nbsp;want.</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">-Xinpeng</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: rgb(0,0,0); FONT-SIZE:=
 16px">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF676504"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span class=3D"Apple-co=
nverted-space">&nbsp;</span>Alper Yegin [<a href=3D"mailto:alper.yegin@yegi=
n.org" target=3D"_blank">alper.yegin@yegin.org</a>]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b><span class=3D"Apple-converted-space">&nbsp=
;</span>2015=C4=EA3=D4=C227=C8=D5 2:13<br>
<b>=CA=D5=BC=FE=C8=CB:</b><span class=3D"Apple-converted-space">&nbsp;</spa=
n>Weixinpeng (Jackie)<br>
<b>=B3=AD=CB=CD:</b><span class=3D"Apple-converted-space">&nbsp;</span>Dape=
ng Liu; <a href=3D"mailto:dmm@ietf.org" target=3D"_blank">
dmm@ietf.org</a><br>
<b>=D6=F7=CC=E2:</b><span class=3D"Apple-converted-space">&nbsp;</span>Re: =
Re=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>Hi Xinpeng,
<div><br>
</div>
<div>If your app knows how to deal with IP address changes, then it's bette=
r if we give it a chance to do so, because (as the I-D explains):</div>
<div><br>
</div>
<div>
<pre style=3D"LINE-HEIGHT: normal; WIDOWS: 1; TEXT-TRANSFORM: none; FONT-VA=
RIANT: normal; FONT-STYLE: normal; TEXT-INDENT: 0px; WORD-WRAP: break-word;=
 WHITE-SPACE: pre-wrap; LETTER-SPACING: normal; COLOR: rgb(0,0,0); FONT-WEI=
GHT: normal; WORD-SPACING: 0px">   Achieving IP session continuity and IP a=
ddress reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when needed.</pre>
<div><br>
</div>
<div><br>
</div>
<div>Alper</div>
<div><br>
</div>
<div>
<div>On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div>
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: rgb(0,0,0); FONT-=
SIZE: 10pt">
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Hi Alper</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">My understanding about t=
he reason why there needs to define&nbsp;serval types&nbsp;of IP prefixes i=
s that, &nbsp;if the application itself could deal with the change of IP ad=
dress, i.e. the application itself could deal with
 session continuty in case of IP address change, so the host would choose a=
 normadic address otherwise the host should choose a sustained address.</di=
v>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">But my question is that,=
 if the application could deal with session continuty itself, does that mea=
n the application is willing to change its IP address? Because even though =
a new address might bring some kinds
 of benefit, but it will also</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">bring additional cost fo=
r application to deal with IP address change.</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Thanks.</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">Xinpeng</div>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<p style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px">&nbsp;</p>
<div style=3D"FONT-FAMILY: 'Times New Roman'; COLOR: rgb(0,0,0); FONT-SIZE:=
 16px">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF991546"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span class=3D"Apple-co=
nverted-space">&nbsp;</span>dmm [<a href=3D"mailto:dmm-bounces@ietf.org" ta=
rget=3D"_blank">dmm-bounces@ietf.org</a>] =B4=FA=B1=ED Dapeng Liu [<a href=
=3D"mailto:maxpassion@gmail.com" target=3D"_blank">maxpassion@gmail.com</a>=
]<br>
<b>=B7=A2=CB=CD=CA=B1=BC=E4:</b><span class=3D"Apple-converted-space">&nbsp=
;</span>2015=C4=EA3=D4=C226=C8=D5 5:01<br>
<b>=CA=D5=BC=FE=C8=CB:</b><span class=3D"Apple-converted-space">&nbsp;</spa=
n>Alper Yegin<br>
<b>=B3=AD=CB=CD:</b><span class=3D"Apple-converted-space">&nbsp;</span><a h=
ref=3D"mailto:dmm@ietf.org" target=3D"_blank">dmm@ietf.org</a><br>
<b>=D6=F7=CC=E2:</b><span class=3D"Apple-converted-space">&nbsp;</span>[DMM=
] =BB=D8=B8=B4=A3=BA DMM API<br>
</font><br>
</div>
<div></div>
<div>
<div>Hello Alper,</div>
<div><br>
</div>
<div>I still have the following comments:</div>
<div><br>
</div>
<div>1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the dra=
ft:</div>
<div><br>
</div>
<div>&nbsp; =A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZ=
E: 1em">- Fixed IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This is what standard Mo=
bile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the IP&nbsp=
;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">addre=
ss of the mobile host.</span>=A1=B1&nbsp;</div>
<div><br>
</div>
<div>If this is equal to HoA, then RFC5014 already cover that. We do not ne=
ed to repeat it here with another name.</div>
<div><br>
</div>
<div>2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in the=
 draft:</div>
<div><br>
</div>
<div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">&quot;- Sustained IP Addres=
s

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
&quot;</pre>
</div>
<div>
<div>There is no clear dividing line between fixed IP address and sustained=
 IP address. Whether the IP address is used for reachability is not determi=
ned by the IP address itself. For example, even when the MN get a HoA, afte=
r it moves to another location of
 the network, it may decide to release current HoA and get another HoA, in =
this case the &quot;fixed IP address&quot; becomes a &quot;sustained IP add=
ress&quot;.</div>
<div><br>
</div>
<div>Further more, the reachability normally is implemented by domain name =
instead of IP address. For example, we reach =A1=B0Google=A1=B1 by its doma=
in name, never by it=A1=AFs server=A1=AFs IP address.&nbsp;</div>
<div><br>
</div>
<div>Using&nbsp;temporary private IP address we can also achieve the goal o=
f =A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in &nb=
sp;<a href=3D"http://hsk.oray.com/" target=3D"_blank">http://hsk.oray.com/<=
/a>&nbsp;, it can &nbsp;provide reachability even the host get a private
 IP address.</div>
<div><br>
</div>
<div>3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:</div>
<div><br>
</div>
<div>=A1=B0<span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em"=
>- Nomadic IP Address</span></div>
<pre style=3D"PAGE-BREAK-BEFORE: always; WIDOWS: 1; MARGIN-TOP: 0px; MARGIN=
-BOTTOM: 0px; FONT-SIZE: 1em" class=3D"newpage">   This type of IP address =
provides neither IP session continuity nor IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the mobile&nb=
sp;</pre>
<div><span style=3D"WIDOWS: 1; WHITE-SPACE: pre-wrap; FONT-SIZE: 1em">host.=
</span>=A1=B1</div>
<div><br>
</div>
<div>Seems this IP address is the IP address that we normally used in most =
cases. If this is the case, why we need a new name for it?</div>
<div><br>
</div>
<div><br>
</div>
<div>--&nbsp;</div>
<div>Dapeng Liu</div>
<div><br>
</div>
<div></div>
</div>
<div style=3D"MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; COLOR: rgb(160,160,168)"=
>=D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=
=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA</div>
<blockquote style=3D"BORDER-LEFT: 1px solid; BORDER-RIGHT-WIDTH: 1px; PADDI=
NG-LEFT: 10px; BORDER-TOP-WIDTH: 1px; BORDER-BOTTOM-WIDTH: 1px; MARGIN-LEFT=
: 0px" type=3D"cite">
<span>
<div>
<div>
<div>Hello Dapeng and Alex,</div>
<div><br>
</div>
<div>I hope you had a chance to digest our responses to your comments and q=
uestions about the API work.</div>
<div>If you have any remaining issues, please let us know over the email at=
 your earliest convenience.</div>
<div>It'd be good if you can articulate them in detail.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>Alper</div>
</div>
</div>
</span></blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</span></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_C5C3BB522B1DDF478AA09545169155B46E3320DFnkgeml507mbxchi_--


From nobody Thu Mar 26 16:10:12 2015
Return-Path: <cmccvic@outlook.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A61A1B7A for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.89
X-Spam-Level: 
X-Spam-Status: No, score=0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0hAqHPdCLG1 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:10:09 -0700 (PDT)
Received: from SNT004-OMC2S23.hotmail.com (snt004-omc2s23.hotmail.com [65.55.90.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD041A1B8D for <dmm@ietf.org>; Thu, 26 Mar 2015 16:10:07 -0700 (PDT)
Received: from SNT407-EAS190 ([65.55.90.71]) by SNT004-OMC2S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Thu, 26 Mar 2015 16:10:07 -0700
X-TMN: [0/w1Ih61SkRBAYRKX1C7b626wEEDLofZ]
X-Originating-Email: [cmccvic@outlook.com]
Message-ID: <SNT407-EAS190D125AFFB637D4C1A89F5AE080@phx.gbl>
From: "Vic Liu(CMCC)" <cmccvic@outlook.com>
To: "'Alper Yegin'" <alper.yegin@yegin.org>, "'Weixinpeng \(Jackie\)'" <weixinpeng@huawei.com>
Date: Fri, 27 Mar 2015 07:12:28 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdBoGeLai0uxqfxKRT6IkR/irdXhVw==
Content-Language: zh-cn
X-OriginalArrivalTime: 26 Mar 2015 23:10:07.0127 (UTC) FILETIME=[FFF21270:01D06819]
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/f8wNFrOy9m6KvXJz-GvdC3btIak>
Cc: dmm@ietf.org
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 23:10:11 -0000

Hi Alper

You can't claim that anyone who disagree with your proposal as =A1=B0do =
not read
the meeting notes etc. ...=A1=B1, it is kind of misleading and not fair.
Furthermore, IETF attendees should always have the right to challenge =
any
proposal that they think have technical flaw. It is the correct process =
that
fair to everyone and not  "causing productivity loss=A1=B1 as you =
claimed.

Thank you!
All the Best
Vic


-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED Alper =
Yegin
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, =D0=C7=C6=DA=CE=E5 =
5:20
=CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
=B3=AD=CB=CD: dmm@ietf.org
=D6=F7=CC=E2: Re: [DMM] DMM work teams

Hi Xinpeng,

On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:

> I think it's good to start serval work teams to process the work.
> If there are some people complain about this, I think the reason would =

> be that it might be not convient for them to participate in the online
interim meeting for reasons such as timezone etc.
>=20

It's always a challenge to find timeslots that works for everyone,
considering the around-the-world participation in DMM (in a way, that's =
true
:-)

> My another feeling is that after the forming of teams there is really=20
> rare discussion in the maillist where should be the main discussing=20
> place of IETF. So my suggestion is that even though there are work =
teams,
please also bring the discussion to mail list.

That's why we, WT leaders, publish meeting notes, so that people who =
were
not at the meeting can join the discussion on the mailing list, and this =
is,
again, why WT leaders present the status at each IETF meeting.

My issue is=A1=AD.. some people don't read the meeting notes.. they =
don't read
the I-D. they don't follow the email discussions. They don't even =
remember
what we presented at the previous IETF and established as common
understanding across the WG. They don't bring up any discussion for =
things
that has been out there at least 2 IETF meeting cycles=A1=AD And then! =
ask
questions as if this is the first time we are presenting it (for very
specific example: need for 3 distinct types of IP addresses). And then, =
this
causing us significant amount of productivity loss=A1=AD.=20



Alper


>=20

> Thanks.
>=20
> -Xinpeng
>=20
> ________________________________________
> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian =
Haberman=20
> [brian@innovationslab.net]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53
> =CA=D5=BC=FE=C8=CB: dmm@ietf.org
> =D6=F7=CC=E2: [DMM] DMM work teams
>=20
> DMM WG,
>     I want to, once again, clarify the guiding principles for the DMM=20
> work teams. Hopefully, this will make it clear to all participants how =

> the work teams will influence the WG.  The guiding principles are:
>=20
> 1. All work teams are open to input from anyone
>=20
> 2. Any work team holding a meeting will announce that meeting to the=20
> WG
>=20
> 3. Any document produced by a work team is treated as any individual=20
> draft
>=20
> 4. Anyone can publish alternative proposals and ask the WG to consider =

> them
>=20
> 5. WG consensus will drive the adoption of any solutions drafts (work=20
> team generated or otherwise).
>=20
> If you have any questions about the above, please contact me.
>=20
> Regards,
> Brian
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

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


From nobody Thu Mar 26 16:33:31 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8EA1A1EF7 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.888
X-Spam-Level: 
X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpky53fGaqaI for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:33:25 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9D71A1B88 for <dmm@ietf.org>; Thu, 26 Mar 2015 16:33:25 -0700 (PDT)
Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0MRmqV-1Z4GGO4AI5-00SwvJ; Fri, 27 Mar 2015 00:33:22 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=GB2312
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <SNT407-EAS190D125AFFB637D4C1A89F5AE080@phx.gbl>
Date: Fri, 27 Mar 2015 01:33:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org>
References: <SNT407-EAS190D125AFFB637D4C1A89F5AE080@phx.gbl>
To: "Vic Liu(CMCC)" <cmccvic@outlook.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:S/wNjF/BIkS0JwjG88EiDQiZlLpEYVJVPTOg588joz8kMgV/JTH XJS8iOxLj03AlQLdl+jb/f1pYNQmbkSPX9skofR1iUWPnfoCySO2421fscO2bNaHPs3ooGL T6G44wYyoABumL8wwxrKbpPRwWbpKjuqBv9FwkUK+7UQ68irUZOnSxb7jGevbqtXqq0xKG5 VJCXZYDXSbG3PBLy9/lpw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/y6t-mwUSef7umYdTulNdcZixMJM>
Cc: "'Weixinpeng \(Jackie\)'" <weixinpeng@huawei.com>, dmm@ietf.org
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 23:33:27 -0000

Let's see:

The so-called "challenges" that Dapeng is raising are based on the =
points that:

- WT captured and sent out as notes on the DMM ML before IETF 91,
- Later presented  to DMM WG in IETF 91.

Oh, btw, they were even presented as individual contribution twice =
before in the WG!

So, if one does not say anything all along, and stay mute until IETF 92, =
do you think this is a productive way of contributing to the WG effort?=20=


WG chairs shall seriously discourage this kind of behavior in the WG. =
It's unfair and discouraging for numerous people who are spending cycles =
on this work.


So, "anyone who disagrees" is not an accurate characterization of what =
is going on in here.


=20






On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote:

> Hi Alper
>=20
> You can't claim that anyone who disagree with your proposal as =A1=B0do =
not read
> the meeting notes etc. ...=A1=B1, it is kind of misleading and not =
fair.
> Furthermore, IETF attendees should always have the right to challenge =
any
> proposal that they think have technical flaw. It is the correct =
process that
> fair to everyone and not  "causing productivity loss=A1=B1 as you =
claimed.
>=20
> Thank you!
> All the Best
> Vic
>=20
>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED =
Alper Yegin
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, =D0=C7=C6=DA=CE=E5 =
5:20
> =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
> =B3=AD=CB=CD: dmm@ietf.org
> =D6=F7=CC=E2: Re: [DMM] DMM work teams
>=20
> Hi Xinpeng,
>=20
> On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:
>=20
>> I think it's good to start serval work teams to process the work.
>> If there are some people complain about this, I think the reason =
would=20
>> be that it might be not convient for them to participate in the =
online
> interim meeting for reasons such as timezone etc.
>>=20
>=20
> It's always a challenge to find timeslots that works for everyone,
> considering the around-the-world participation in DMM (in a way, =
that's true
> :-)
>=20
>> My another feeling is that after the forming of teams there is really=20=

>> rare discussion in the maillist where should be the main discussing=20=

>> place of IETF. So my suggestion is that even though there are work =
teams,
> please also bring the discussion to mail list.
>=20
> That's why we, WT leaders, publish meeting notes, so that people who =
were
> not at the meeting can join the discussion on the mailing list, and =
this is,
> again, why WT leaders present the status at each IETF meeting.
>=20
> My issue is=A1=AD.. some people don't read the meeting notes.. they =
don't read
> the I-D. they don't follow the email discussions. They don't even =
remember
> what we presented at the previous IETF and established as common
> understanding across the WG. They don't bring up any discussion for =
things
> that has been out there at least 2 IETF meeting cycles=A1=AD And then! =
ask
> questions as if this is the first time we are presenting it (for very
> specific example: need for 3 distinct types of IP addresses). And =
then, this
> causing us significant amount of productivity loss=A1=AD.=20
>=20
>=20
>=20
> Alper
>=20
>=20
>>=20
>=20
>> Thanks.
>>=20
>> -Xinpeng
>>=20
>> ________________________________________
>> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian =
Haberman=20
>> [brian@innovationslab.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53
>> =CA=D5=BC=FE=C8=CB: dmm@ietf.org
>> =D6=F7=CC=E2: [DMM] DMM work teams
>>=20
>> DMM WG,
>>    I want to, once again, clarify the guiding principles for the DMM=20=

>> work teams. Hopefully, this will make it clear to all participants =
how=20
>> the work teams will influence the WG.  The guiding principles are:
>>=20
>> 1. All work teams are open to input from anyone
>>=20
>> 2. Any work team holding a meeting will announce that meeting to the=20=

>> WG
>>=20
>> 3. Any document produced by a work team is treated as any individual=20=

>> draft
>>=20
>> 4. Anyone can publish alternative proposals and ask the WG to =
consider=20
>> them
>>=20
>> 5. WG consensus will drive the adoption of any solutions drafts (work=20=

>> team generated or otherwise).
>>=20
>> If you have any questions about the above, please contact me.
>>=20
>> Regards,
>> Brian
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Thu Mar 26 16:46:29 2015
Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723D31A6F2A for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.85
X-Spam-Level: 
X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcgyAeh89G17 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 16:46:25 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB801A702C for <dmm@ietf.org>; Thu, 26 Mar 2015 16:46:25 -0700 (PDT)
Received: from [10.119.8.5] ([81.17.21.68]) by mrelay.perfora.net (mreueus003) with ESMTPA (Nemesis) id 0MLhDB-1Yc6Yb3NmV-000tqc; Fri, 27 Mar 2015 00:46:20 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <C5C3BB522B1DDF478AA09545169155B46E3320DF@nkgeml507-mbx.china.huawei.com>
Date: Fri, 27 Mar 2015 01:46:16 +0200
Message-Id: <7CFF12C5-C0F3-4A71-B38E-DE24A2E8DAA0@yegin.org>
References: <C5C3BB522B1DDF478AA09545169155B46E331EE0@nkgeml507-mbx.china.huawei.com>,  <B9D0620B-0566-496F-90B1-7E0A3FAAA022@yegin.org> <C5C3BB522B1DDF478AA09545169155B46E332048@nkgeml507-mbx.china.huawei.com>, <DCBFFB95-180A-4109-91B1-95CF5155A80B@yegin.org> <C5C3BB522B1DDF478AA09545169155B46E3320DF@nkgeml507-mbx.china.huawei.com>
To: "Weixinpeng (Jackie)" <weixinpeng@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V03:K0:XgCk5lXSHyVCPTFLtlzclY3UdTFGdqcBnWvNlKcddVOkUb4gbt8 ibbguIAiFPWmoHBoXJsiXOcQfMxYiKSgvFcz/NlIUnM1+jc2plt7CasW2TNv9hSdxSMrt25 c0KYLbxecZLl/Vqp1UmofbldKWHNxNJCRegu2kyKtaCEYWLXMmLahqMIW1+YhIbM06wxImg fvgbq78yNWWzCBdhutX2A==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/X4ZJX9IlcuTT8oHgIwp10d5BlD8>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] =?utf-8?q?Re=EF=BC=9A_DMM_API?=
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2015 23:46:28 -0000

--Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

Hi Xinpeng,

> Imagine you are developing a chat (IM) client.
> Because your app will be running on terminals that'd connect to both =
cellular and WiFi networks, you don't have any other option but to =
implement app-layer mobility management (because otherwise your chat =
sessions will break when the terminal moves in and out of WiFi =
hotspots).
> =20
> [Wei] My understanding abouth the reason why application developer =
implements application layer support is that the host's IP address might =
change when their application is running, so they **have to** provide
> mechanism to cope with the situation,


That's what I'm saying too.

> but it's not their willing to change the IP address.


Sure. My point is, they know how to deal with it. And the code already =
handles it. So, what we are suggesting does not cause any new code =
development from that perspective.

> Additional, The application developer might be a bit of confused with =
the name of "Nomadic address", theywould just think the nomadic address =
is a kind of address that would be changed.
>=20

Well, if you are not liking the name, please suggest a better one. We =
are obviously open to improvements.


> Now, given that you already implemented app-layer mobility, it's to =
your advantage to use it even when you are on cellular network, if there =
was a way to tell the network to provide you a nomadic IP address (as =
opposed to fixed/mobile IP address that it'd normally do). Because that =
way, you ensure your IP packets take the shortest path, which reduces =
the end2end latency.
> =20
> [Wei] The application layer mobility management and the redundant =
routing path both bring additional costes, but its hard for application =
developers to have an idea which one has a more lower cost.
>=20

For the IM app developer, the gain is the reduced latency.
What is the cost?

> Besides, we also expect that the mobile network operators will promote =
"proper use" of these flags, because that ensures efficient use of their =
network resources. Letting an app use a fixed IP address when it could =
very well use a nomadic IP address is waste of network resources (back =
hauling, PGW capacity, etc.)
> =20
> [Wei] Agree that network operator wants to reduce their network cost, =
but we cannot make sure the application developer will becare about too =
much for the operators...
>=20

Operators know how to make the app developers care about things that the =
operators care.


> As a future thing, we can even envision mobile operators charging =
differently based on the type of traffic -- after all each type is =
consuming different amounts of network resources.=20
>=20

Alper




> Alper
>=20
>=20
> On Mar 26, 2015, at 10:42 PM, Weixinpeng (Jackie) wrote:
>=20
>> Hi Alper,
>> For an application developer, if there are three kinds of addresses =
to use which are "Fixed IP Address", "Sustained IP Address" and "Nomadic =
IP Address",
>> then I believe the developer would always wants to use the "Fixed IP =
address", rather than the other ones. Because even though the =
application could cope with IP address
>> change, but the IP address change is not what the application want.
>> =20
>> -Xinpeng
>> =20
>> =20
>> =B7=A2=BC=FE=C8=CB: Alper Yegin [alper.yegin@yegin.org]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:13
>> =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
>> =B3=AD=CB=CD: Dapeng Liu; dmm@ietf.org
>> =D6=F7=CC=E2: Re: Re=A3=BA DMM API
>>=20
>> Hi Xinpeng,
>>=20
>> If your app knows how to deal with IP address changes, then it's =
better if we give it a chance to do so, because (as the I-D explains):
>>=20
>>    Achieving IP session continuity and IP address reachability by =
using
>>    Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
>>    host's IP traffic to traverse a centrally-located router (Home =
Agent,
>>    HA), which incurs additional transmission latency and use of
>>    additional network resources, adds to the network CAPEX and OPEX, =
and
>>    decreases the reliability of the network due to the introduction =
of a
>>    single point of failure [I-D.ietf-dmm-requirements].  Therefore, =
IP
>>    session continuity and IP address reachability should be be =
provided
>>    only when needed.
>>=20
>>=20
>> Alper
>>=20
>> On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) wrote:
>>=20
>>> Hi Alper
>>> My understanding about the reason why there needs to define serval =
types of IP prefixes is that,  if the application itself could deal with =
the change of IP address, i.e. the application itself could deal with =
session continuty in case of IP address change, so the host would choose =
a normadic address otherwise the host should choose a sustained address.
>>> But my question is that, if the application could deal with session =
continuty itself, does that mean the application is willing to change =
its IP address? Because even though a new address might bring some kinds =
of benefit, but it will also
>>> bring additional cost for application to deal with IP address =
change.
>>> Thanks.
>>> =20
>>> Xinpeng
>>> =20
>>> =20
>>> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Dapeng =
Liu [maxpassion@gmail.com]
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5 5:01
>>> =CA=D5=BC=FE=C8=CB: Alper Yegin
>>> =B3=AD=CB=CD: dmm@ietf.org
>>> =D6=F7=CC=E2: [DMM] =BB=D8=B8=B4=A3=BA DMM API
>>>=20
>>> Hello Alper,
>>>=20
>>> I still have the following comments:
>>>=20
>>> 1. Regarding the definition of =A1=B0fixed IP address=A1=B1 in the =
draft:
>>>=20
>>>   =A1=B0- Fixed IP Address
>>>    This is what standard Mobile IP provides with a Home Address =
(HoA).
>>>    The mobile host is configures a HoA from a centrally-located Home
>>>    Network.  Both IP session continuity and IP address reachability =
are
>>>    provided to the mobile host with the help of a router in the Home
>>>    Network (Home Agent, HA).  This router acts as an anchor for the =
IP=20
>>> address of the mobile host.=A1=B1=20
>>>=20
>>> If this is equal to HoA, then RFC5014 already cover that. We do not =
need to repeat it here with another name.
>>>=20
>>> 2. Regarding the definition of =A1=B0sustained IP address=A1=B1 in =
the draft:
>>>=20
>>> "- Sustained IP Address
>>>=20
>>>    This type of IP address provides IP session continuity but not IP
>>>    address reachability.  It is achieved by ensuring that the IP =
address
>>>    used at the beginning of the session remains usable despite the
>>>    movement of the mobile host.  The IP address may change after the
>>>    termination of the IP session(s), therefore it does not exhibit
>>>    persistence.
>>> "
>>> There is no clear dividing line between fixed IP address and =
sustained IP address. Whether the IP address is used for reachability is =
not determined by the IP address itself. For example, even when the MN =
get a HoA, after it moves to another location of the network, it may =
decide to release current HoA and get another HoA, in this case the =
"fixed IP address" becomes a "sustained IP address".
>>>=20
>>> Further more, the reachability normally is implemented by domain =
name instead of IP address. For example, we reach =A1=B0Google=A1=B1 by =
its domain name, never by it=A1=AFs server=A1=AFs IP address.=20
>>>=20
>>> Using temporary private IP address we can also achieve the goal of =
=A1=B0reachability=A1=B1. For example, using dynamic DNS, as shown in  =
http://hsk.oray.com/ , it can  provide reachability even the host get a =
private IP address.
>>>=20
>>> 3. Regarding the definition of =A1=B0nomadic IP address=A1=B1:
>>>=20
>>> =A1=B0- Nomadic IP Address
>>>    This type of IP address provides neither IP session continuity =
nor IP
>>>    address reachability.  The IP address is obtained from the =
serving IP
>>>    gateway and it is not maintained across gateway changes.  In =
other
>>>    words, the IP address may be released and replaced by a new IP
>>>    address when the IP gateway changes due to the movement of the =
mobile=20
>>> host.=A1=B1
>>>=20
>>> Seems this IP address is the IP address that we normally used in =
most cases. If this is the case, why we need a new name for it?
>>>=20
>>>=20
>>> --=20
>>> Dapeng Liu
>>>=20
>>> =D4=DA 2015=C4=EA3=D4=C225=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72=
:02=A3=ACAlper Yegin =D0=B4=B5=C0=A3=BA
>>>> Hello Dapeng and Alex,
>>>>=20
>>>> I hope you had a chance to digest our responses to your comments =
and questions about the API work.
>>>> If you have any remaining issues, please let us know over the email =
at your earliest convenience.
>>>> It'd be good if you can articulate them in detail.
>>>>=20
>>>>=20
>>>> Thanks.
>>>>=20
>>>> Alper


--Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

<html><head><base href=3D"x-msg://1247/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">Hi Xinpeng,<div><br><div><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div>Imagine you are developing a =
chat (IM) client.</div><div>Because your app will be running on =
terminals that'd connect to both cellular and WiFi networks, you don't =
have any other option but to implement app-layer mobility management =
(because otherwise your chat sessions will break when the terminal moves =
in and out of WiFi hotspots).</div><div>&nbsp;</div><div><font =
color=3D"#ff0000">[Wei] My understanding abouth the reason why =
application developer implements application layer support is that the =
host's IP address might change when their application is running, so =
they **have to** provide</font><div style=3D"margin-top: 0px; =
margin-bottom: 0px; "><font color=3D"#ff0000">mechanism to cope with the =
situation, =
</font></div></div></div></div></div></div></span></blockquote><div><br></=
div><div><br></div><div>That's what I'm saying too.</div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div><div style=3D"margin-top: =
0px; margin-bottom: 0px; "><font color=3D"#ff0000">but it's not their =
willing to change the IP address. =
</font></div></div></div></div></div></div></span></blockquote><div><br></=
div><div><br></div><div>Sure. My point is, they know how to deal with =
it. And the code already handles it. So, what we are suggesting does not =
cause any new code development from that =
perspective.</div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div><div style=3D"margin-top: =
0px; margin-bottom: 0px; "><font color=3D"#ff0000">Additional, =
The&nbsp;application developer&nbsp;might be a bit of confused with the =
name of "Nomadic address", theywould just think the nomadic address is a =
kind of address that would be changed.</font></div><font =
color=3D"#ff0000"></font></div><div><br></div></div></div></div></div></sp=
an></blockquote><div><br></div><div>Well, if you are not liking the =
name, please suggest a better one. We are obviously open to =
improvements.</div><div><br></div><div><br></div><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div>Now, given that you already =
implemented app-layer mobility, it's to your advantage to use it even =
when you are on cellular network, if there was a way to tell the network =
to provide you a nomadic IP address (as opposed to fixed/mobile IP =
address that it'd normally do). Because that way, you ensure your IP =
packets take the shortest path, which reduces the end2end =
latency.</div><div>&nbsp;</div><div><font color=3D"#ff0000">[Wei] The =
application layer mobility management and the redundant routing path =
both bring additional costes, but its hard for application developers to =
have an idea which one has a more lower =
cost.</font></div><div><br></div></div></div></div></div></span></blockquo=
te><div><br></div><div>For the IM app developer, the gain is the reduced =
latency.</div><div>What is the cost?</div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div>Besides, we also expect that =
the mobile network operators will promote "proper use" of these flags, =
because that ensures efficient use of their network resources. Letting =
an app use a fixed IP address when it could very well use a nomadic IP =
address is waste of network resources (back hauling, PGW capacity, =
etc.)</div><div>&nbsp;</div><div><font color=3D"#ff0000">[Wei] Agree =
that&nbsp;network operator wants to reduce&nbsp;their network cost, =
but&nbsp;we cannot make sure the application developer will becare about =
too much for the =
operators...</font></div><div><br></div></div></div></div></div></span></b=
lockquote><div><br></div><div>Operators know how to make the app =
developers care about things that the operators =
care.</div><div><br></div><div><br></div><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; "><div><div>As a future thing, we can =
even envision mobile operators charging differently based on the type of =
traffic -- after all each type is consuming different amounts of network =
resources.&nbsp;</div><div><br></div></div></div></div></div></span></bloc=
kquote><div><br></div><div>Alper</div><div><br></div><div><br></div><div><=
br></div><br><blockquote type=3D"cite"><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div =
fpstyle=3D"1" ocsi=3D"0" style=3D"word-wrap: break-word; "><div =
style=3D"direction: ltr; font-family: Tahoma; color: rgb(0, 0, 0); =
font-size: 10pt; "><div style=3D"font-family: 'Times New Roman'; color: =
rgb(0, 0, 0); font-size: 16px; =
"><div><div>Alper</div><div><br></div><div><br><div><div>On Mar 26, =
2015, at 10:42 PM, Weixinpeng (Jackie) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"widows: 2; text-transform: none; =
text-indent: 0px; border-collapse: separate; font: normal normal normal =
medium/normal Helvetica; white-space: normal; orphans: 2; =
letter-spacing: normal; word-spacing: 0px; "><div style=3D"word-wrap: =
break-word; "><div style=3D"font-family: Tahoma; direction: ltr; color: =
rgb(0, 0, 0); font-size: 10pt; "><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">Hi Alper,</div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">For&nbsp;an application developer, if there are =
three kinds of addresses to use which are "Fixed IP Address", "Sustained =
IP Address" and "Nomadic IP Address",</div><div style=3D"margin-top: =
0px; margin-bottom: 0px; ">then I believe the developer would always =
wants to use the "Fixed IP address", rather than the other ones. Because =
even though the application could cope with IP address</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">change, but the IP =
address change is not what the application&nbsp;want.</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">-Xinpeng</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"font-family: 'Times New Roman'; color: rgb(0, 0, 0); font-size: =
16px; "><hr tabindex=3D"-1"><div id=3D"divRpF676504" style=3D"direction: =
ltr; "><font color=3D"#000000" size=3D"2" =
face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Alper Yegin [<a =
href=3D"mailto:alper.yegin@yegin.org" =
target=3D"_blank">alper.yegin@yegin.org</a>]<br><b>=B7=A2=CB=CD=CA=B1=BC=E4=
:</b><span class=3D"Apple-converted-space">&nbsp;</span>2015=C4=EA3=D4=C22=
7=C8=D5 2:13<br><b>=CA=D5=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Weixinpeng =
(Jackie)<br><b>=B3=AD=CB=CD:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Dapeng Liu;<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org" =
target=3D"_blank">dmm@ietf.org</a><br><b>=D6=F7=CC=E2:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: Re=A3=BA DMM =
API<br></font><br></div><div></div><div>Hi =
Xinpeng,<div><br></div><div>If your app knows how to deal with IP =
address changes, then it's better if we give it a chance to do so, =
because (as the I-D explains):</div><div><br></div><div><pre =
style=3D"line-height: normal; widows: 1; text-transform: none; =
font-variant: normal; font-style: normal; text-indent: 0px; word-wrap: =
break-word; white-space: pre-wrap; letter-spacing: normal; color: rgb(0, =
0, 0); font-weight: normal; word-spacing: 0px; ">   Achieving IP session =
continuity and IP address reachability by using
   Mobile IP incurs some cost.  Mobile IP protocol forces the mobile
   host's IP traffic to traverse a centrally-located router (Home Agent,
   HA), which incurs additional transmission latency and use of
   additional network resources, adds to the network CAPEX and OPEX, and
   decreases the reliability of the network due to the introduction of a
   single point of failure [I-D.ietf-dmm-requirements].  Therefore, IP
   session continuity and IP address reachability should be be provided
   only when =
needed.</pre><div><br></div><div><br></div><div>Alper</div><div><br></div>=
<div><div>On Mar 26, 2015, at 7:39 PM, Weixinpeng (Jackie) =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><div style=3D"font-family: Tahoma; direction: ltr; =
color: rgb(0, 0, 0); font-size: 10pt; "><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">Hi Alper</div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; ">My understanding about the reason why there needs =
to define&nbsp;serval types&nbsp;of IP prefixes is that, &nbsp;if the =
application itself could deal with the change of IP address, i.e. the =
application itself could deal with session continuty in case of IP =
address change, so the host would choose a normadic address otherwise =
the host should choose a sustained address.</div><div style=3D"margin-top:=
 0px; margin-bottom: 0px; ">But my question is that, if the application =
could deal with session continuty itself, does that mean the application =
is willing to change its IP address? Because even though a new address =
might bring some kinds of benefit, but it will also</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">bring additional cost =
for application to deal with IP address change.</div><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">Thanks.</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"margin-top: 0px; margin-bottom: 0px; ">Xinpeng</div><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><p =
style=3D"margin-top: 0px; margin-bottom: 0px; ">&nbsp;</p><div =
style=3D"font-family: 'Times New Roman'; color: rgb(0, 0, 0); font-size: =
16px; "><hr tabindex=3D"-1"><div id=3D"divRpF991546" style=3D"direction: =
ltr; "><font color=3D"#000000" size=3D"2" =
face=3D"Tahoma"><b>=B7=A2=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>dmm [<a =
href=3D"mailto:dmm-bounces@ietf.org" =
target=3D"_blank">dmm-bounces@ietf.org</a>] =B4=FA=B1=ED Dapeng Liu [<a =
href=3D"mailto:maxpassion@gmail.com" =
target=3D"_blank">maxpassion@gmail.com</a>]<br><b>=B7=A2=CB=CD=CA=B1=BC=E4=
:</b><span class=3D"Apple-converted-space">&nbsp;</span>2015=C4=EA3=D4=C22=
6=C8=D5 5:01<br><b>=CA=D5=BC=FE=C8=CB:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Alper =
Yegin<br><b>=B3=AD=CB=CD:</b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:dmm@ietf.org" =
target=3D"_blank">dmm@ietf.org</a><br><b>=D6=F7=CC=E2:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>[DMM] =BB=D8=B8=B4=A3=BA =
DMM API<br></font><br></div><div></div><div><div>Hello =
Alper,</div><div><br></div><div>I still have the following =
comments:</div><div><br></div><div>1. Regarding the definition of =
=A1=B0fixed IP address=A1=B1 in the =
draft:</div><div><br></div><div>&nbsp; =A1=B0<span style=3D"widows: 1; =
white-space: pre-wrap; font-size: 1em; ">- Fixed IP =
Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This is what standard Mobile IP provides with a Home Address (HoA).
   The mobile host is configures a HoA from a centrally-located Home
   Network.  Both IP session continuity and IP address reachability are
   provided to the mobile host with the help of a router in the Home
   Network (Home Agent, HA).  This router acts as an anchor for the =
IP&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">address of the mobile =
host.</span>=A1=B1&nbsp;</div><div><br></div><div>If this is equal to =
HoA, then RFC5014 already cover that. We do not need to repeat it here =
with another name.</div><div><br></div><div>2. Regarding the definition =
of =A1=B0sustained IP address=A1=B1 in the =
draft:</div><div><br></div><div><pre class=3D"newpage" =
style=3D"page-break-before: always; widows: 1; margin-top: 0px; =
margin-bottom: 0px; font-size: 1em; ">"- Sustained IP Address

   This type of IP address provides IP session continuity but not IP
   address reachability.  It is achieved by ensuring that the IP address
   used at the beginning of the session remains usable despite the
   movement of the mobile host.  The IP address may change after the
   termination of the IP session(s), therefore it does not exhibit
   persistence.
"</pre></div><div><div>There is no clear dividing line between fixed IP =
address and sustained IP address. Whether the IP address is used for =
reachability is not determined by the IP address itself. For example, =
even when the MN get a HoA, after it moves to another location of the =
network, it may decide to release current HoA and get another HoA, in =
this case the "fixed IP address" becomes a "sustained IP =
address".</div><div><br></div><div>Further more, the reachability =
normally is implemented by domain name instead of IP address. For =
example, we reach =A1=B0Google=A1=B1 by its domain name, never by it=A1=AF=
s server=A1=AFs IP =
address.&nbsp;</div><div><br></div><div>Using&nbsp;temporary private IP =
address we can also achieve the goal of =A1=B0reachability=A1=B1. For =
example, using dynamic DNS, as shown in &nbsp;<a =
href=3D"http://hsk.oray.com/" =
target=3D"_blank">http://hsk.oray.com/</a>&nbsp;, it can &nbsp;provide =
reachability even the host get a private IP =
address.</div><div><br></div><div>3. Regarding the definition of =
=A1=B0nomadic IP address=A1=B1:</div><div><br></div><div>=A1=B0<span =
style=3D"widows: 1; white-space: pre-wrap; font-size: 1em; ">- Nomadic =
IP Address</span></div><pre class=3D"newpage" style=3D"page-break-before: =
always; widows: 1; margin-top: 0px; margin-bottom: 0px; font-size: 1em; =
">   This type of IP address provides neither IP session continuity nor =
IP
   address reachability.  The IP address is obtained from the serving IP
   gateway and it is not maintained across gateway changes.  In other
   words, the IP address may be released and replaced by a new IP
   address when the IP gateway changes due to the movement of the =
mobile&nbsp;</pre><div><span style=3D"widows: 1; white-space: pre-wrap; =
font-size: 1em; ">host.</span>=A1=B1</div><div><br></div><div>Seems this =
IP address is the IP address that we normally used in most cases. If =
this is the case, why we need a new name for =
it?</div><div><br></div><div><br></div><div>--&nbsp;</div><div>Dapeng =
Liu</div><div><br></div><div></div></div><div style=3D"margin-top: 0px; =
margin-bottom: 0px; color: rgb(160, 160, 168); ">=D4=DA 2015=C4=EA3=D4=C22=
5=C8=D5 =D0=C7=C6=DA=C8=FD=A3=AC=CF=C2=CE=E72:02=A3=ACAlper Yegin =
=D0=B4=B5=C0=A3=BA</div><blockquote type=3D"cite" =
style=3D"border-left-width: 1px; border-left-style: solid; =
border-left-color: initial; border-right-width: 1px; padding-left: 10px; =
border-top-width: 1px; border-bottom-width: 1px; margin-left: 0px; =
"><span><div><div><div>Hello Dapeng and Alex,</div><div><br></div><div>I =
hope you had a chance to digest our responses to your comments and =
questions about the API work.</div><div>If you have any remaining =
issues, please let us know over the email at your earliest =
convenience.</div><div>It'd be good if you can articulate them in =
detail.</div><div><br></div><div><br></div><div>Thanks.</div><div><br></di=
v><div>Alper</div></div></div></span></blockquote></div></div></div></div>=
</blockquote></div></div></div></div></div></div></span></blockquote></div=
></div></div></div></div></div></span></blockquote></div><br></div></body>=
</html>=

--Apple-Mail=_FE76840B-8DA6-4DC3-AA41-96F884D4C1F0--


From nobody Thu Mar 26 17:10:34 2015
Return-Path: <cmccvic@outlook.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCE21A8775 for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 17:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.89
X-Spam-Level: 
X-Spam-Status: No, score=0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4kYGVYVJdaM for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 17:10:31 -0700 (PDT)
Received: from SNT004-OMC4S29.hotmail.com (snt004-omc4s29.hotmail.com [65.55.90.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5091A8768 for <dmm@ietf.org>; Thu, 26 Mar 2015 17:10:30 -0700 (PDT)
Received: from SNT407-EAS201 ([65.55.90.199]) by SNT004-OMC4S29.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);  Thu, 26 Mar 2015 17:10:30 -0700
X-TMN: [crZ/xGN7nkrORAvFuMKcQ9w48nPXf2hj]
X-Originating-Email: [cmccvic@outlook.com]
Message-ID: <SNT407-EAS2017B488908A98164967D25AE090@phx.gbl>
From: "Vic Liu(CMCC)" <cmccvic@outlook.com>
To: "'Alper Yegin'" <alper.yegin@yegin.org>
Date: Thu, 26 Mar 2015 19:12:51 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdBoIoVsuIgmYWWCQxO6T3oAnzIG6w==
Content-Language: zh-cn
X-OriginalArrivalTime: 27 Mar 2015 00:10:30.0305 (UTC) FILETIME=[6F872910:01D06822]
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/aRwe8fBQIz9mtT78aVMZ-IzJPvk>
Cc: "'Weixinpeng \(Jackie\)'" <weixinpeng@huawei.com>, dmm@ietf.org
Subject: Re: [DMM] DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2015 00:10:33 -0000

Hi Alper

I think Dapeng is not the only one who challenge your proposal and =
please
don't be personal. Working group chair should prevent anyone who use the =
WT
to push their own draft. That's working group and AD should really care
about.

Thank you=20
All the best!=20
Vic



-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Alper Yegin [mailto:alper.yegin@yegin.org]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C226=C8=D5, =D0=C7=C6=DA=CB=C4 =
18:33
=CA=D5=BC=FE=C8=CB: Vic Liu(CMCC)
=B3=AD=CB=CD: 'Weixinpeng (Jackie)'; dmm@ietf.org
=D6=F7=CC=E2: Re: [DMM] DMM work teams


Let's see:

The so-called "challenges" that Dapeng is raising are based on the =
points
that:

- WT captured and sent out as notes on the DMM ML before IETF 91,
- Later presented  to DMM WG in IETF 91.

Oh, btw, they were even presented as individual contribution twice =
before in
the WG!

So, if one does not say anything all along, and stay mute until IETF 92, =
do
you think this is a productive way of contributing to the WG effort?=20

WG chairs shall seriously discourage this kind of behavior in the WG. =
It's
unfair and discouraging for numerous people who are spending cycles on =
this
work.


So, "anyone who disagrees" is not an accurate characterization of what =
is
going on in here.


=20






On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote:

> Hi Alper
>=20
> You can't claim that anyone who disagree with your proposal as =
=A1=B0do not=20
> read the meeting notes etc. ...=A1=B1, it is kind of misleading and =
not fair.
> Furthermore, IETF attendees should always have the right to challenge=20
> any proposal that they think have technical flaw. It is the correct=20
> process that fair to everyone and not  "causing productivity =
loss=A1=B1 as you
claimed.
>=20
> Thank you!
> All the Best
> Vic
>=20
>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: dmm [mailto:dmm-bounces@ietf.org] =B4=FA=B1=ED =
Alper Yegin
> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5, =
=D0=C7=C6=DA=CE=E5 5:20
> =CA=D5=BC=FE=C8=CB: Weixinpeng (Jackie)
> =B3=AD=CB=CD: dmm@ietf.org
> =D6=F7=CC=E2: Re: [DMM] DMM work teams
>=20
> Hi Xinpeng,
>=20
> On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:
>=20
>> I think it's good to start serval work teams to process the work.
>> If there are some people complain about this, I think the reason=20
>> would be that it might be not convient for them to participate in the =

>> online
> interim meeting for reasons such as timezone etc.
>>=20
>=20
> It's always a challenge to find timeslots that works for everyone,=20
> considering the around-the-world participation in DMM (in a way,=20
> that's true
> :-)
>=20
>> My another feeling is that after the forming of teams there is really =

>> rare discussion in the maillist where should be the main discussing=20
>> place of IETF. So my suggestion is that even though there are work=20
>> teams,
> please also bring the discussion to mail list.
>=20
> That's why we, WT leaders, publish meeting notes, so that people who=20
> were not at the meeting can join the discussion on the mailing list,=20
> and this is, again, why WT leaders present the status at each IETF
meeting.
>=20
> My issue is=A1=AD.. some people don't read the meeting notes.. they =
don't=20
> read the I-D. they don't follow the email discussions. They don't even =

> remember what we presented at the previous IETF and established as=20
> common understanding across the WG. They don't bring up any discussion =

> for things that has been out there at least 2 IETF meeting =
cycles=A1=AD And=20
> then! ask questions as if this is the first time we are presenting it=20
> (for very specific example: need for 3 distinct types of IP=20
> addresses). And then, this causing us significant amount of =
productivity
loss=A1=AD.
>=20
>=20
>=20
> Alper
>=20
>=20
>>=20
>=20
>> Thanks.
>>=20
>> -Xinpeng
>>=20
>> ________________________________________
>> =B7=A2=BC=FE=C8=CB: dmm [dmm-bounces@ietf.org] =B4=FA=B1=ED Brian =
Haberman=20
>> [brian@innovationslab.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA3=D4=C227=C8=D5 2:53
>> =CA=D5=BC=FE=C8=CB: dmm@ietf.org
>> =D6=F7=CC=E2: [DMM] DMM work teams
>>=20
>> DMM WG,
>>    I want to, once again, clarify the guiding principles for the DMM=20
>> work teams. Hopefully, this will make it clear to all participants=20
>> how the work teams will influence the WG.  The guiding principles =
are:
>>=20
>> 1. All work teams are open to input from anyone
>>=20
>> 2. Any work team holding a meeting will announce that meeting to the=20
>> WG
>>=20
>> 3. Any document produced by a work team is treated as any individual=20
>> draft
>>=20
>> 4. Anyone can publish alternative proposals and ask the WG to=20
>> consider them
>>=20
>> 5. WG consensus will drive the adoption of any solutions drafts (work =

>> team generated or otherwise).
>>=20
>> If you have any questions about the above, please contact me.
>>=20
>> Regards,
>> Brian
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Thu Mar 26 17:19:50 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2B1A877C for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 17:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3XkQHWUm71L for <dmm@ietfa.amsl.com>; Thu, 26 Mar 2015 17:19:46 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8573C1A8747 for <dmm@ietf.org>; Thu, 26 Mar 2015 17:19:45 -0700 (PDT)
Received: by wgbcc7 with SMTP id cc7so81566624wgb.0 for <dmm@ietf.org>; Thu, 26 Mar 2015 17:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=398xsV4FZMv1YpKUfbd+ijuFCgSj7/XxC2JUwuB6U3E=; b=zMoE400ZfImykyUnzqElAJcVAIKCkZE7qpKt6As2OWeftBH1NWqmEyj+fZyZlT7g1y yT0Fuy4/XbVpgG7rKhFBtuElOXKSzCjZHwX9lngoUBpMtZfdS3Zoe7GIAYVuhoMSuneo lSp/RITIE6n82QYKmVgowKqPGwZ8pojN2yBKBuE8Nh+y/ZrdTF1HXfdJUUPxS+TE4Mvu 0jlEVHL5wpSW3mxV7AE5jadMTsqm8yyHd/+SIU9z9z9Vh13mkHMDa/PpB3zkXDGzLcNJ cwB2xWbJMV6fZhJf24bEK8C3k2rK39HsECXmZX3oaabbVx++1P9pmqLEqIYzkbGGXH1A TP1w==
X-Received: by 10.194.133.101 with SMTP id pb5mr33706989wjb.40.1427415584284;  Thu, 26 Mar 2015 17:19:44 -0700 (PDT)
Received: from [31.133.166.135] (dhcp-a687.meeting.ietf.org. [31.133.166.135]) by mx.google.com with ESMTPSA id o10sm1076822wiy.18.2015.03.26.17.19.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 17:19:43 -0700 (PDT)
Date: Thu, 26 Mar 2015 19:18:41 -0500
From: Dapeng Liu <maxpassion@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Message-ID: <D0E3F3FCC0274D83BF16D76F6C0D01D0@gmail.com>
In-Reply-To: <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org>
References: <SNT407-EAS190D125AFFB637D4C1A89F5AE080@phx.gbl> <1C34DE30-4682-402E-A5DE-67BD56B2BD0F@yegin.org>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5514a1e1_1313c32b_a9e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/L3OXCn32U_yvcDb6igP15oTKWIk>
Cc: "Weixinpeng \(Jackie\)" <weixinpeng@huawei.com>, dmm@ietf.org
Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= DMM work teams
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2015 00:19:48 -0000

--5514a1e1_1313c32b_a9e
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=E5=9C=A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=
=BC=8C=E4=B8=8B=E5=8D=886:33=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=
=9A
> =20
> Let's see:
> =20
> The so-called =22challenges=22 that Dapeng is raising are based on the =
points that:
> =20
> - WT captured and sent out as notes on the DMM ML before IET=46 91,
> - Later presented to DMM WG in IET=46 91.
> =20
> Oh, btw, they were even presented as individual contribution twice befo=
re in the WG=21
Hi Alper,

You are misleading.

As you may remember, I have raised concerns several times regarding this =
proposal even during the offline discussion with you. And the proposal is=
 not improved to address my concern. There is no much changing of the pro=
posal since you present the first time and my concerns still remain. =20

> =20
> So, if one does not say anything all along, and stay mute until IET=46 =
92, do you think this is a productive way of contributing to the WG effor=
t=3F =20
> =20
> WG chairs shall seriously discourage this kind of behavior in the WG. I=
t's unfair and discouraging for numerous people who are spending cycles o=
n this work.
The chairs should guarantee the process is open and fair to others. Unfor=
tunately, our AD have got complains of this WT.


-Dapeng =20
> =20
> =20
> So, =22anyone who disagrees=22 is not an accurate characterization of w=
hat is going on in here.
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote:
> =20
> > Hi Alper
> > =20
> > You can't claim that anyone who disagree with your proposal as =E2=80=
=9Cdo not read
> > the meeting notes etc. ...=E2=80=9D, it is kind of misleading and not=
 fair.
> > =46urthermore, IET=46 attendees should always have the right to chall=
enge any
> > proposal that they think have technical flaw. It is the correct proce=
ss that
> > fair to everyone and not =22causing productivity loss=E2=80=9D as you=
 claimed.
> > =20
> > Thank you=21
> > All the Best
> > Vic
> > =20
> > =20
> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bmailto:dmm-bounces=40ietf.org=5D =
=E4=BB=A3=E8=A1=A8 Alper Yegin
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=
=A5, =E6=98=9F=E6=9C=9F=E4=BA=94 5:20
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: Weixinpeng (Jackie)
> > =E6=8A=84=E9=80=81: dmm=40ietf.org (mailto:dmm=40ietf.org)
> > =E4=B8=BB=E9=A2=98: Re: =5BDMM=5D DMM work teams
> > =20
> > Hi Xinpeng,
> > =20
> > On Mar 26, 2015, at 10:49 PM, Weixinpeng (Jackie) wrote:
> > =20
> > > I think it's good to start serval work teams to process the work.
> > > If there are some people complain about this, I think the reason wo=
uld =20
> > > be that it might be not convient for them to participate in the onl=
ine
> > > =20
> > =20
> > interim meeting for reasons such as timezone etc.
> > > =20
> > =20
> > =20
> > It's always a challenge to find timeslots that works for everyone,
> > considering the around-the-world participation in DMM (in a way, that=
's true
> > :-)
> > =20
> > > My another feeling is that after the forming of teams there is real=
ly =20
> > > rare discussion in the maillist where should be the main discussing=
 =20
> > > place of IET=46. So my suggestion is that even though there are wor=
k teams,
> > > =20
> > =20
> > please also bring the discussion to mail list.
> > =20
> > That's why we, WT leaders, publish meeting notes, so that people who =
were
> > not at the meeting can join the discussion on the mailing list, and t=
his is,
> > again, why WT leaders present the status at each IET=46 meeting.
> > =20
> > My issue is=E2=80=A6.. some people don't read the meeting notes.. the=
y don't read
> > the I-D. they don't follow the email discussions. They don't even rem=
ember
> > what we presented at the previous IET=46 and established as common
> > understanding across the WG. They don't bring up any discussion for t=
hings
> > that has been out there at least 2 IET=46 meeting cycles=E2=80=A6 And=
 then=21 ask
> > questions as if this is the first time we are presenting it (for very=

> > specific example: need for 3 distinct types of IP addresses). And the=
n, this
> > causing us significant amount of productivity loss=E2=80=A6. =20
> > =20
> > =20
> > =20
> > Alper
> > =20
> > =20
> > =20
> > > Thanks.
> > > =20
> > > -Xinpeng
> > > =20
> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > > =E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5Bdmm-bounces=40ietf.org (mailto:=
dmm-bounces=40ietf.org)=5D =E4=BB=A3=E8=A1=A8 Brian Haberman =20
> > > =5Bbrian=40innovationslab.net (mailto:brian=40innovationslab.net)=5D=

> > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=
=A5 2:53
> > > =E6=94=B6=E4=BB=B6=E4=BA=BA: dmm=40ietf.org (mailto:dmm=40ietf.org)=

> > > =E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams
> > > =20
> > > DMM WG,
> > > I want to, once again, clarify the guiding principles for the DMM =20
> > > work teams. Hopefully, this will make it clear to all participants =
how =20
> > > the work teams will influence the WG. The guiding principles are:
> > > =20
> > > 1. All work teams are open to input from anyone
> > > =20
> > > 2. Any work team holding a meeting will announce that meeting to th=
e =20
> > > WG
> > > =20
> > > 3. Any document produced by a work team is treated as any individua=
l =20
> > > draft
> > > =20
> > > 4. Anyone can publish alternative proposals and ask the WG to consi=
der =20
> > > them
> > > =20
> > > 5. WG consensus will drive the adoption of any solutions drafts (wo=
rk =20
> > > team generated or otherwise).
> > > =20
> > > If you have any questions about the above, please contact me.
> > > =20
> > > Regards,
> > > Brian
> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > > dmm mailing list
> > > dmm=40ietf.org (mailto:dmm=40ietf.org)
> > > https://www.ietf.org/mailman/listinfo/dmm
> > > =20
> > =20
> > =20
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > dmm mailing list
> > dmm=40ietf.org (mailto:dmm=40ietf.org)
> > https://www.ietf.org/mailman/listinfo/dmm
> > =20
> =20
> =20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> dmm mailing list
> dmm=40ietf.org (mailto:dmm=40ietf.org)
> https://www.ietf.org/mailman/listinfo/dmm
> =20
> =20



--5514a1e1_1313c32b_a9e
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><span style=3D=22color: rgb(160, 160, 168);=22>=E5=9C=
=A8 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C=
=E4=B8=8B=E5=8D=886:33=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC=9A</s=
pan></div>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div><div><br></div><div>Let's see:</div><=
div><br></div><div>The so-called =22challenges=22 that Dapeng is raising =
are based on the points that:</div><div><br></div><div>- WT captured and =
sent out as notes on the DMM ML before IET=46 91,</div><div>- Later prese=
nted  to DMM WG in IET=46 91.</div><div><br></div><div>Oh, btw, they were=
 even presented as individual contribution twice before in the WG=21</div=
></div></div></span></blockquote><div>Hi Alper,</div><div><br></div><div>=
You are misleading.</div><div><br></div><div>As you may remember, I have =
raised concerns several times regarding this proposal even during the off=
line discussion with you. And the proposal is not improved to address my =
concern. There is no much changing of the proposal since you present the =
first time and my concerns still remain.&nbsp;</div><div><br></div><block=
quote type=3D=22cite=22 style=3D=22border-left-style:solid;border-width:1=
px;margin-left:0px;padding-left:10px;=22><span><div><div><div><br></div><=
div>So, if one does not say anything all along, and stay mute until IET=46=
 92, do you think this is a productive way of contributing to the WG effo=
rt=3F </div><div><br></div><div>WG chairs shall seriously discourage this=
 kind of behavior in the WG. It's unfair and discouraging for numerous pe=
ople who are spending cycles on this work.</div></div></div></span></bloc=
kquote><div>The chairs should guarantee the process is open and fair to o=
thers. Unfortunately, our AD have got complains of this WT.</div><div><br=
></div><div><br></div><div>-Dapeng&nbsp;</div><blockquote type=3D=22cite=22=
 style=3D=22border-left-style:solid;border-width:1px;margin-left:0px;padd=
ing-left:10px;=22><span><div><div><div><br></div><div><br></div><div>So, =
=22anyone who disagrees=22 is not an accurate characterization of what is=
 going on in here.</div><div><br></div><div><br></div><div> </div><div><b=
r></div><div><br></div><div><br></div><div><br></div><div><br></div><div>=
<br></div><div>On Mar 27, 2015, at 1:12 AM, Vic Liu(CMCC) wrote:</div><di=
v><br></div><blockquote type=3D=22cite=22><div><div>Hi Alper</div><div><b=
r></div><div>You can't claim that anyone who disagree with your proposal =
as =E2=80=9Cdo not read</div><div>the meeting notes etc. ...=E2=80=9D, it=
 is kind of misleading and not fair.</div><div>=46urthermore, IET=46 atte=
ndees should always have the right to challenge any</div><div>proposal th=
at they think have technical flaw. It is the correct process that</div><d=
iv>fair to everyone and not  =22causing productivity loss=E2=80=9D as you=
 claimed.</div><div><br></div><div>Thank you=21</div><div>All the Best</d=
iv><div>Vic</div><div><br></div><div><br></div><div>-----=E9=82=AE=E4=BB=B6=
=E5=8E=9F=E4=BB=B6-----</div><div>=E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5B<a =
href=3D=22mailto:dmm-bounces=40ietf.org=22>mailto:dmm-bounces=40ietf.org<=
/a>=5D =E4=BB=A3=E8=A1=A8 Alper Yegin</div><div>=E5=8F=91=E9=80=81=E6=97=B6=
=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=A5, =E6=98=9F=E6=9C=9F=E4=BA=94=
 5:20</div><div>=E6=94=B6=E4=BB=B6=E4=BA=BA: Weixinpeng (Jackie)</div><di=
v>=E6=8A=84=E9=80=81: <a href=3D=22mailto:dmm=40ietf.org=22>dmm=40ietf.or=
g</a></div><div>=E4=B8=BB=E9=A2=98: Re: =5BDMM=5D DMM work teams</div><di=
v><br></div><div>Hi Xinpeng,</div><div><br></div><div>On Mar 26, 2015, at=
 10:49 PM, Weixinpeng (Jackie) wrote:</div><div><br></div><blockquote typ=
e=3D=22cite=22><div><div>I think it's good to start serval work teams to =
process the work.</div><div>If there are some people complain about this,=
 I think the reason would </div><div>be that it might be not convient for=
 them to participate in the online</div></div></blockquote><div>interim m=
eeting for reasons such as timezone etc.</div><blockquote type=3D=22cite=22=
><div></div></blockquote><div><br></div><div>It's always a challenge to f=
ind timeslots that works for everyone,</div><div>considering the around-t=
he-world participation in DMM (in a way, that's true</div><div>:-)</div><=
div><br></div><blockquote type=3D=22cite=22><div><div>My another feeling =
is that after the forming of teams there is really </div><div>rare discus=
sion in the maillist where should be the main discussing </div><div>place=
 of IET=46. So my suggestion is that even though there are work teams,</d=
iv></div></blockquote><div>please also bring the discussion to mail list.=
</div><div><br></div><div>That's why we, WT leaders, publish meeting note=
s, so that people who were</div><div>not at the meeting can join the disc=
ussion on the mailing list, and this is,</div><div>again, why WT leaders =
present the status at each IET=46 meeting.</div><div><br></div><div>My is=
sue is=E2=80=A6.. some people don't read the meeting notes.. they don't r=
ead</div><div>the I-D. they don't follow the email discussions. They don'=
t even remember</div><div>what we presented at the previous IET=46 and es=
tablished as common</div><div>understanding across the WG. They don't bri=
ng up any discussion for things</div><div>that has been out there at leas=
t 2 IET=46 meeting cycles=E2=80=A6 And then=21 ask</div><div>questions as=
 if this is the first time we are presenting it (for very</div><div>speci=
fic example: need for 3 distinct types of IP addresses). And then, this</=
div><div>causing us significant amount of productivity loss=E2=80=A6. </d=
iv><div><br></div><div><br></div><div><br></div><div>Alper</div><div><br>=
</div><div><br></div><blockquote type=3D=22cite=22><div></div></blockquot=
e><div><br></div><blockquote type=3D=22cite=22><div><div>Thanks.</div><di=
v><br></div><div>-Xinpeng</div><div><br></div><div>=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F</div><div>=E5=8F=91=E4=BB=B6=E4=BA=BA: dmm =5B<a hr=
ef=3D=22mailto:dmm-bounces=40ietf.org=22>dmm-bounces=40ietf.org</a>=5D =E4=
=BB=A3=E8=A1=A8 Brian Haberman </div><div>=5B<a href=3D=22mailto:brian=40=
innovationslab.net=22>brian=40innovationslab.net</a>=5D</div><div>=E5=8F=91=
=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B43=E6=9C=8827=E6=97=A5 2:53</div=
><div>=E6=94=B6=E4=BB=B6=E4=BA=BA: <a href=3D=22mailto:dmm=40ietf.org=22>=
dmm=40ietf.org</a></div><div>=E4=B8=BB=E9=A2=98: =5BDMM=5D DMM work teams=
</div><div><br></div><div>DMM WG,</div><div>   I want to, once again, cla=
rify the guiding principles for the DMM </div><div>work teams. Hopefully,=
 this will make it clear to all participants how </div><div>the work team=
s will influence the WG.  The guiding principles are:</div><div><br></div=
><div>1. All work teams are open to input from anyone</div><div><br></div=
><div>2. Any work team holding a meeting will announce that meeting to th=
e </div><div>WG</div><div><br></div><div>3. Any document produced by a wo=
rk team is treated as any individual </div><div>draft</div><div><br></div=
><div>4. Anyone can publish alternative proposals and ask the WG to consi=
der </div><div>them</div><div><br></div><div>5. WG consensus will drive t=
he adoption of any solutions drafts (work </div><div>team generated or ot=
herwise).</div><div><br></div><div>If you have any questions about the ab=
ove, please contact me.</div><div><br></div><div>Regards,</div><div>Brian=
</div><div>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F</div><div>dmm mailing list</div><div><a href=3D=22mailto:dmm=40ietf.o=
rg=22>dmm=40ietf.org</a></div><div><a href=3D=22https://www.ietf.org/mail=
man/listinfo/dmm=22>https://www.ietf.org/mailman/listinfo/dmm</a></div></=
div></blockquote><div><br></div><div>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F</div><div>dmm mailing list</div><div><a hr=
ef=3D=22mailto:dmm=40ietf.org=22>dmm=40ietf.org</a></div><div><a href=3D=22=
https://www.ietf.org/mailman/listinfo/dmm=22>https://www.ietf.org/mailman=
/listinfo/dmm</a></div></div></blockquote><div><br></div><div>=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F</div><div>dmm mail=
ing list</div><div><a href=3D=22mailto:dmm=40ietf.org=22>dmm=40ietf.org</=
a></div><div><a href=3D=22https://www.ietf.org/mailman/listinfo/dmm=22>ht=
tps://www.ietf.org/mailman/listinfo/dmm</a></div></div></div></span>
                =20
                =20
                =20
                =20
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--5514a1e1_1313c32b_a9e--


From nobody Mon Mar 30 07:08:15 2015
Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B148D1ACEF6 for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 07:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Level: 
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWMCl6zop5n4 for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 07:08:11 -0700 (PDT)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 277FD1ACE08 for <dmm@ietf.org>; Mon, 30 Mar 2015 07:08:09 -0700 (PDT)
Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77419399; Mon, 30 Mar 2015 15:08:08 +0100
From: "Seil Jeon" <seiljeon@av.it.pt>
To: <danny.moses@intel.com>
References: <006701d06800$96a57960$c3f06c20$@av.it.pt>
In-Reply-To: <006701d06800$96a57960$c3f06c20$@av.it.pt>
Date: Mon, 30 Mar 2015 15:08:07 +0100
Message-ID: <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01D06AFB.547B59D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/5uK9A1Q
Content-Language: ko
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/HAY1oSm21R1i_QbpakCjLYeTUxA>
Cc: dmm@ietf.org
Subject: [DMM] FW:  Answer on raised questions for the proposed API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2015 14:08:14 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000E_01D06AFB.547B59D0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000F_01D06AFB.547B59D0"


------=_NextPart_001_000F_01D06AFB.547B59D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Danny,

 

Any comments?

 

Regards,

Seil Jeon

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API

 

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someone. Here goes
answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED IP address case in
the draft. On receiving this API with the SUSTAINED IP address type at the
IP stack, it will try to get a new SUSTAINED IP address if there is no
available in the currently attached access network. So, actual obtaining of
the IP address will be tried one time while attached at a specific access
network. Even some applications put this API after, the already obtained
SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not needed because the
host can get a new SUSTAINED IP address, right?

If the question is right, I don't understand what the question is meant,
that is how the host can get a new SUSTAINED IP address?

Based on the definition of three types of IP address, an application should
show its requirement with an API among them. If it is the SUSTAINED IP
address, how do we expect the IP stack will try to get a new SUSTAINED IP
address?

 

Besides, the propsoed API is not used alone but with the three type APIs. 

 

 

 

Regards,

 

Seil Jeon

 

 


------=_NextPart_001_000F_01D06AFB.547B59D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:"\@Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Arial","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:3.0cm 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Hi =
Danny,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Any =
comments?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Regards,<o:p></o=
:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Seil =
Jeon<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
dmm [mailto:dmm-bounces@ietf.org] <b>On Behalf Of </b>Seil =
Jeon<br><b>Sent:</b> Thursday, March 26, 2015 8:08 PM<br><b>To:</b> =
dmm@ietf.org<br><b>Subject:</b> [DMM] Answer on raised questions for the =
proposed API<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Hi,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could attend DMM Thursday meeting via MeetEcho.<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could also hear some raised comments by Danny and Someone. Here goes =
answers to the raised questions.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>First, regarding the need of =
the proposed API (IPV6_PREFER_SRC_NEW),<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>The =
use of the proposed API is suggested in the SUSTAINED IP address case in =
the draft. On receiving this API with the SUSTAINED IP address type at =
the IP stack, it will try to get a new SUSTAINED IP address if there is =
no available in the currently attached access network. So, actual =
obtaining of the IP address will be tried one time while attached at a =
specific access network. Even some applications put this API after, the =
already obtained SUSTAINED IP will be used. So, no worries about =
abuse.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Second question sounded to me =
like that this API is not needed because the host can get a new =
SUSTAINED IP address, right?<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>If =
the question is right, I don&#8217;t understand what the question is =
meant, that is how the host can get a new SUSTAINED IP =
address?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Based on the definition of =
three types of IP address, an application should show its requirement =
with an API among them. If it is the SUSTAINED IP address, how do we =
expect the IP stack will try to get a new SUSTAINED IP =
address?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Besides, the propsoed API is =
not used alone but with the three type APIs. <o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Regards,<o:p></o:p></span></p>=
<p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
Jeon<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_001_000F_01D06AFB.547B59D0--

------=_NextPart_000_000E_01D06AFB.547B59D0
Content-Type: text/plain;
	name="Untitled attachment 00120.sdx"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Untitled attachment 00120.sdx"

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

------=_NextPart_000_000E_01D06AFB.547B59D0--


From nobody Mon Mar 30 08:44:07 2015
Return-Path: <danny.moses@intel.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4D1A0113 for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 08:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tyJoc9Udp5b for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 08:44:01 -0700 (PDT)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id B05BC1A00E4 for <dmm@ietf.org>; Mon, 30 Mar 2015 08:44:01 -0700 (PDT)
Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 30 Mar 2015 08:44:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,494,1422950400";  d="scan'208,217";a="548418578"
Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga003.jf.intel.com with ESMTP; 30 Mar 2015 08:43:59 -0700
Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 30 Mar 2015 16:43:57 +0100
Received: from hasmsx106.ger.corp.intel.com ([169.254.2.247]) by LCSMSX154.ger.corp.intel.com ([169.254.7.140]) with mapi id 14.03.0224.002; Mon, 30 Mar 2015 18:43:56 +0300
From: "Moses, Danny" <danny.moses@intel.com>
To: Seil Jeon <seiljeon@av.it.pt>
Thread-Topic: [DMM] Answer on raised questions for the proposed API
Thread-Index: AdBn/8/iETX0T5LxQyGIw0K89P0aYgC2fzqAAAjVfcA=
Date: Mon, 30 Mar 2015 15:43:55 +0000
Message-ID: <F0CF5715D3D1884BAC731EA1103AC28134908F15@HASMSX106.ger.corp.intel.com>
References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt>
In-Reply-To: <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.184.70.11]
Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/Zu5Bd9jx3JzHlPNwOP-YsXPSbXM>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Answer on raised questions for the proposed API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2015 15:44:05 -0000

--_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hi Seil,

As to the potential of abuse:
Yes, I see your point and you are correct. If the IP stack will not request=
 a sustained IP address more than once after each movement to a new LAN (wi=
th a different prefix), than there will be no abuse.

As to the second comment, please let me elaborate:
One potential implementation of the IP stack in the host, can be to request=
 a Nomadic IP address and a  Sustained IP address whenever connecting to a =
network, and whenever moving to a new LAN, regardless if there are any appl=
ications requesting any addresses. This way, whenever an application is lau=
nched and requests either a Nomadic or Sustained IP address, the stack can =
provide one without having to issue a request to the network. In this case,=
 there is no need for this flag from the application.

Another potential implementation of the IP stack in the host is not to requ=
est IP addresses in advance. In that case, it will issue a request for a No=
madic IP address or a Sustained IP address the first time an application re=
quests one and use it for subsequent requests as long as it is not moving t=
o a different LAN. Once it moves, it will again request a new IP address (N=
omadic or Sustained - according to what is required) after receiving the fi=
rst request from any application. In this case as well, there is no need fo=
r this flag.

As a matter of fact, if such a flag is defined, I cannot think of an exampl=
e where it will not be used. It seems to me that applications will always r=
equest a refreshed Sustained IP address (when requesting a Sustained IP add=
ress). If this is correct, the flag is redundant.

Can you provide a scenario in which an application will not request to refr=
esh the Sustained IP address?

Regards,
                /Danny
From: Seil Jeon [mailto:seiljeon@av.it.pt]
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc: dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

Hi Danny,

Any comments?

Regards,
Seil Jeon


From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] Answer on raised questions for the proposed API

Hi,

I could attend DMM Thursday meeting via MeetEcho.
I could also hear some raised comments by Danny and Someone. Here goes answ=
ers to the raised questions.


First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),

The use of the proposed API is suggested in the SUSTAINED IP address case i=
n the draft. On receiving this API with the SUSTAINED IP address type at th=
e IP stack, it will try to get a new SUSTAINED IP address if there is no av=
ailable in the currently attached access network. So, actual obtaining of t=
he IP address will be tried one time while attached at a specific access ne=
twork. Even some applications put this API after, the already obtained SUST=
AINED IP will be used. So, no worries about abuse.

Second question sounded to me like that this API is not needed because the =
host can get a new SUSTAINED IP address, right?
If the question is right, I don't understand what the question is meant, th=
at is how the host can get a new SUSTAINED IP address?
Based on the definition of three types of IP address, an application should=
 show its requirement with an API among them. If it is the SUSTAINED IP add=
ress, how do we expect the IP stack will try to get a new SUSTAINED IP addr=
ess?

Besides, the propsoed API is not used alone but with the three type APIs.



Regards,

Seil Jeon


---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:85.05pt 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Seil,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">As to the potential of=
 abuse:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Yes, I see your point =
and you are correct. If the IP stack will not request a sustained IP addres=
s more than once after each movement to a new LAN (with a different prefix)=
, than there will be no abuse.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">As to the second comme=
nt, please let me elaborate:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">One potential implemen=
tation of the IP stack in the host, can be to request a Nomadic IP address =
and a &nbsp;Sustained IP address whenever connecting to a network, and when=
ever moving to a new LAN, regardless if there
 are any applications requesting any addresses. This way, whenever an appli=
cation is launched and requests either a Nomadic or Sustained IP address, t=
he stack can provide one without having to issue a request to the network. =
In this case, there is no need for
 this flag from the application.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Another potential impl=
ementation of the IP stack in the host is not to request IP addresses in ad=
vance. In that case, it will issue a request for a Nomadic IP address or a =
Sustained IP address the first time
 an application requests one and use it for subsequent requests as long as =
it is not moving to a different LAN. Once it moves, it will again request a=
 new IP address (Nomadic or Sustained &#8211; according to what is required=
) after receiving the first request from
 any application. In this case as well, there is no need for this flag.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">As a matter of fact, i=
f such a flag is defined, I cannot think of an example where it will not be=
 used. It seems to me that applications will always request a refreshed Sus=
tained IP address (when requesting a
 Sustained IP address). If this is correct, the flag is redundant.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Can you provide a scen=
ario in which an application will not request to refresh the Sustained IP a=
ddress?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Regards,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /Danny=
<o:p></o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Seil Jeo=
n [mailto:seiljeon@av.it.pt]
<br>
<b>Sent:</b> Monday, March 30, 2015 17:08<br>
<b>To:</b> Moses, Danny<br>
<b>Cc:</b> dmm@ietf.org<br>
<b>Subject:</b> FW: [DMM] Answer on raised questions for the proposed API<o=
:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D">Hi Danny,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D">Any comments?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D">Seil Jeon<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> dmm [<a =
href=3D"mailto:dmm-bounces@ietf.org">mailto:dmm-bounces@ietf.org</a>]
<b>On Behalf Of </b>Seil Jeon<br>
<b>Sent:</b> Thursday, March 26, 2015 8:08 PM<br>
<b>To:</b> <a href=3D"mailto:dmm@ietf.org">dmm@ietf.org</a><br>
<b>Subject:</b> [DMM] Answer on raised questions for the proposed API<o:p><=
/o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Hi,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">I could attend DMM Thursday meeting via MeetEcho.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">I could also hear some raised comments by Danny and Someon=
e. Here goes answers to the raised questions.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">First, regarding the need of the proposed API (IPV6_PREFER=
_SRC_NEW),<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">The use of the proposed API is suggested in the SUSTAINED =
IP address case in the draft. On receiving this API with the SUSTAINED IP a=
ddress type at the IP stack, it will try to get a new SUSTAINED
 IP address if there is no available in the currently attached access netwo=
rk. So, actual obtaining of the IP address will be tried one time while att=
ached at a specific access network. Even some applications put this API aft=
er, the already obtained SUSTAINED
 IP will be used. So, no worries about abuse.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Second question sounded to me like that this API is not ne=
eded because the host can get a new SUSTAINED IP address, right?<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">If the question is right, I don&#8217;t understand what th=
e question is meant, that is how the host can get a new SUSTAINED IP addres=
s?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Based on the definition of three types of IP address, an a=
pplication should show its requirement with an API among them. If it is the=
 SUSTAINED IP address, how do we expect the IP stack will
 try to get a new SUSTAINED IP address?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Besides, the propsoed API is not used alone but with the t=
hree type APIs.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;">Seil Jeon<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p>---------------------------------------------------------------------<br>
A member of the Intel Corporation group of companies</p>

<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>

--_000_F0CF5715D3D1884BAC731EA1103AC28134908F15HASMSX106gercor_--


From nobody Mon Mar 30 15:42:52 2015
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259731A6FED for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 15:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDLfPUuRYcPv for <dmm@ietfa.amsl.com>; Mon, 30 Mar 2015 15:42:48 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFE21A6F7B for <dmm@ietf.org>; Mon, 30 Mar 2015 15:42:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2UMgmvJ009576; Mon, 30 Mar 2015 15:42:48 -0700
Received: from XCH-BLV-201.nw.nos.boeing.com (xch-blv-201.nw.nos.boeing.com [10.57.37.66]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2UMgeo4009437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 30 Mar 2015 15:42:40 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.181]) with mapi id 14.03.0210.002; Mon, 30 Mar 2015 15:42:39 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, Jouni Korhonen <jouni.nospam@gmail.com>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] Mobility Exposure and Selection WT call
Thread-Index: AQHQaBCuHeg12xmiXkGwZvQpxTNtk501pKnA
Date: Mon, 30 Mar 2015 22:42:39 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E2E10A@XCH-BLV-504.nw.nos.boeing.com>
References: <A730EA79-F6CF-49CD-9933-9FDA4AA75541@yegin.org> <556A06B1-A71C-45DC-A5FB-66CC8ECF47B8@yegin.org> <223129BA-541E-4C56-9364-6C2B8A5A1D3B@yegin.org> <29DDE580-C9A3-4825-8C0B-CF6844438BEC@yegin.org> <54DB49BF.9090702@gmail.com> <4238F47D-1284-46D3-AF61-F173E4A3BDBE@yegin.org> <54E5A34C.2030106@gmail.com> <75DD1093-4761-4E0C-A5B9-1A1A96D850CE@yegin.org> <54E60579.5090401@gmail.com> <55144953.8070104@gmail.com> <55144D3F.2030002@gmail.com> <551481F8.9090507@gmail.com>
In-Reply-To: <551481F8.9090507@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/grq5QkWC1xWMtRj2sya6mvAbkrQ>
Subject: Re: [DMM] Mobility Exposure and Selection WT call
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2015 22:42:51 -0000

Hi Alex,

> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu
> Sent: Thursday, March 26, 2015 3:03 PM
> To: Jouni Korhonen; dmm@ietf.org
> Subject: Re: [DMM] Mobility Exposure and Selection WT call
>=20
> Le 26/03/2015 13:17, Jouni Korhonen a =E9crit :
> > Alex,
> >
> > 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:
> >
> > [snip]
> >
> >>> I thought by "fixed" you meant it stays the same wherever the Host go=
es
> >>> (something like the Home Address).
> >>
> >> Alper - I think a LL address can also be qualified as 'fixed' - it nev=
er
> >> changes.
> >
> > Does LL here mean link-local or link-layer? If it is the former one,
> > then the above assertion is not correct.
>=20
> Link-local.
>=20
> And you seem to say a link-local address is not fixed?  I think
> link-local addresses _are_ fixed set in stone.  They are formed locally
> without need of help from router.

AERO provides a fixed link-local address that is formed from a prefix
received by DHCPv6 Prefix Delegation (PD). Once the AERO Client is
given a PD (either IPv6 or IPv4) it can form an AERO link-local address
that stays the same wherever the Client moves and with no need to
perform Duplicate Address Detection (DAD). It makes IPv6 ND
simple and seamless.

Thanks - Fred
fred.l.templin@boeing.com

> Alex
>=20
> >
> > - Jouni
> >
> >>
> >> I think it's hard to disagree with that, no?
> >>
> >> Alex
> >>
> >>>
> >>> So, I guess, I should have referred to the "nomadic" address to mean =
the
> >>> one that is constant, wherever the Host goes.
> >>>
> >>> As such, my suggestion is that a "nomadic" address can never be an
> >>> RFC7217 address.
> >>>
> >>> In practice that would mean that if you configure an address to be
> >>> "nomadic" you must also tell the kernel to not run RFC7217 on it.
> >>>
> >>> But ok, one might think that these two aspects ("nomadic" and RFC7217=
)
> >>> are orthogonal at this point in time.
> >>>
> >>> Alex
> >>>
> >>>>
> >>>> I don't know if it makes sense to request a fixed and random-based I=
P
> >>>> address. But if someone does it, it works.
> >>>
> >>>
> >>>>
> >>>> Alper
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or registered (RFC
> >>>>>>> 6775).
> >>>>>>>
> >>>>>>
> >>>>>> Orthogonal.
> >>>>>>
> >>>>>>
> >>>>>>> E.g. a nomadic address could never be a link-local address.
> >>>>>>>
> >>>>>>>> #2. Describe how IP address type information is conveyed from
> >>>>>>>> network to MN.
> >>>>>>>
> >>>>>>> If one designs a protocol to convey address type information from
> >>>>>>> the network to the end node, then one could also add the other
> >>>>>>> types mentioned above.
> >>>>>>>
> >>>>>>> SLAAC could never 'convey' the address type to the end-node,
> >>>>>>> because SLAAC is an operation happening with as heavy weight from
> >>>>>>> the Server (router) as from the Client (Host): the Router decides
> >>>>>>> the prefix but the Client decides the Interface ID.
> >>>>>>>
> >>>>>>
> >>>>>> Still, the network can convey the type of IP address to the host.
> >>>>>> Also, one can imagine augmenting Router Solicitation to let the ho=
st
> >>>>>> convey its requested type.
> >>>>>
> >>>>> I agree.
> >>>>>
> >>>>> Alex
> >>>>>
> >>>>>
> >>>>>>> Address Registration Option of 6lo and BTLE would have the Host
> >>>>>>> conveying this information to the Router (and not vice-versa).
> >>>>>>>
> >>>>>>
> >>>>>> OK.
> >>>>>>
> >>>>>> Alper
> >>>>>>
> >>>>>>
> >>>>>>> Yours,
> >>>>>>>
> >>>>>>> Alex
> >>>>>>>
> >>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility as the
> >>>>>>>> baseline for item#1 (the API). A revision of the draft will also
> >>>>>>>> include a new section to cover backward compatibility (Danny wil=
l
> >>>>>>>> provide the draft text). Comments on the draft are welcome.
> >>>>>>>>
> >>>>>>>> The next call will be about items #2/#3 (IP address
> >>>>>>>> configuration enhancements associated with the API). We intend t=
o
> >>>>>>>> schedule that one in about 2 weeks.
> >>>>>>>>
> >>>>>>>> Alper
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
> >>>>>>>>
> >>>>>>>>> Folks,
> >>>>>>>>>
> >>>>>>>>> See below for the Webex details. Remember, the call is on Tue,
> >>>>>>>>> Feb 10, at 4pm CET. And don't forget to read the documents in
> >>>>>>>>> the reading list prior to the call.
> >>>>>>>>>
> >>>>>>>>>> Attendees _shall read _the following material before the call
> >>>>>>>>>> so that we can directly jump to the discussions:
> >>>>>>>>>>
> >>>>>>>>>> 1.
> >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
> >>>>>>>>>> 3.
> >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobi=
lity/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
> >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Alper
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *DMM - Mobility Exposure and Selection WT* Tuesday 10 February
> >>>>>>>>> 2015 16:00  |  Europe Time (Paris, GMT+01:00)  |  1 hr 30 min
> >>>>>>>>>
> >>>>>>>>>> *Join WebEx meeting*
> >>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=3Dm1dad9871a277ff2ab14=
2ae8ff4b77ad3>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> Meeting number:641 085 326
> >>>>>>>>>> Meeting password:dmm1911
> >>>>>>>>>>
> >>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll free number
> >>>>>>>>>> (US/Canada) *1-650-479-3208* Call-in toll number (US/Canada)
> >>>>>>>>>> Access code: 641 085 326 Toll-free calling restrictions
> >>>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
> >>>>>>>>>>
> >>>>>>>>>> Add this meeting
> >>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=3Dm0855d524ccb7239248d=
0ce34e19f38c8>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> to your calendar.
> >>>>>>>>>>
> >>>>>>>>>> Can't join the meeting? Contact support.
> >>>>>>>>>> <https://ietf.webex.com/ietf/mc>
> >>>>>>>>>>
> >>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx service allows
> >>>>>>>>>> audio and other information sent during the session to be
> >>>>>>>>>> recorded, which may be discoverable in a legal matter. By
> >>>>>>>>>> joining this session, you automatically consent to such
> >>>>>>>>>> recordings. If you do not consent to being recorded, discuss
> >>>>>>>>>> your concerns with the host or do not join the session.
> >>>>>>>>>>
> >>>>>>>>> <WebEx_Meeting.ics>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
> >>>>>>>>>
> >>>>>>>>>> Poll is closed, and majority selected the following date for
> >>>>>>>>>> the call:
> >>>>>>>>>>
> >>>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
> >>>>>>>>>>
> >>>>>>>>>> Please mark your calendars.
> >>>>>>>>>>
> >>>>>>>>>> In this call, we'll aim making progress on the I-D for item#1
> >>>>>>>>>> (an API for source address selection).
> >>>>>>>>>>
> >>>>>>>>>> Attendees _shall read _the following material before the call
> >>>>>>>>>> so that we can directly jump to the discussions:
> >>>>>>>>>>
> >>>>>>>>>> 1.
> >>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
> >>>>>>>>>> 3.
> >>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobi=
lity/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
> >>>>>>>>>> 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Alper
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Folks,
> >>>>>>>>>>>
> >>>>>>>>>>> Please mark your availability on the following doodle for
> >>>>>>>>>>> our next DMM WG Mobility Exposure and Selection WT call:
> >>>>>>>>>>>
> >>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
> >>>>>>>>>>>
> >>>>>>>>>>> Register your availability no later than the end of Monday
> >>>>>>>>>>> (Jan 26).
> >>>>>>>>>>>
> >>>>>>>>>>> Alper
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________ dmm mailing list
> >>>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
> >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________ dmm mailing list
> >>>>>>> dmm@ietf.org <mailto:dmm@ietf.org>
> >>>>>>> https://www.ietf.org/mailman/listinfo/dmm
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dmm mailing list
> >>> dmm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dmm
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm
> >
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Tue Mar 31 02:52:04 2015
Return-Path: <maxpassion@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9B1A896D for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 02:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAMJJX7yUcOf for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 02:52:02 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC601A896C for <dmm@ietf.org>; Tue, 31 Mar 2015 02:52:01 -0700 (PDT)
Received: by patj18 with SMTP id j18so14875281pat.2 for <dmm@ietf.org>; Tue, 31 Mar 2015 02:52:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:cc:message-id:subject:mime-version:content-type;  bh=V4ppmNeb2Ln1ZZcVQUcRcBu9YSaFq9zG8Zy6lq0cI4M=; b=Hg56bxdJi4xerlHKtJddbpSHeo9UQOpvsA3S9HdWPpIyMsqVDQhQ+thjlbLJdZ9awB kcPxbYlSdSbeNKjrJFJ65dfCBu5AYFzFm3paIfnsynBFDnkO++jED8vTGDSQgMZ8wXtw 7jpH1VNIe2vjrrwQyglHD8OC0Vz+9JiPf0WWUSJ6SlUPJXy/lhTZ5EtTFgX3LzDWenqp R7kRr4y7s5mCrMZ75ebqzwzOyFxaoIlfAU6Oi2LV9YegCv3t/r04leeMQTozUrqHiImi /0hmiO6y/NwhNxl+TtFTlTlRYHax51ZHwxDgYt/BEIn5lbYuF6mEcPj8QXqtcVN3nMWA LiyQ==
X-Received: by 10.67.7.195 with SMTP id de3mr66208727pad.79.1427795521475; Tue, 31 Mar 2015 02:52:01 -0700 (PDT)
Received: from [10.62.54.24] ([202.55.20.10]) by mx.google.com with ESMTPSA id pa6sm12731146pac.45.2015.03.31.02.51.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 31 Mar 2015 02:52:00 -0700 (PDT)
Date: Tue, 31 Mar 2015 17:51:49 +0800
From: Dapeng Liu <maxpassion@gmail.com>
To: "=?utf-8?Q?dmm=40ietf.org?=" <dmm@ietf.org>
Message-ID: <0FE6D2CA737841BD992AABCDE74C5ACB@gmail.com>
X-Mailer: sparrow 1.6.4 (build 1176)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="551a6e35_7e0c57b1_8d8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/xowiyrcWE3eEK1ryyLJZHbG5WJg>
Cc: weixinpeng@huawei.com
Subject: [DMM] DMM API: http://tools.ietf.org/html/draft-yegin-dmm-ondemand-mobility-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 09:52:03 -0000

--551a6e35_7e0c57b1_8d8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=46olks,

I would like to reaffirm that the technical comments that I made is indiv=
idual opinion (without co-chair=E2=80=99s hat). =20

To facilitate the discussion, I have the following suggestions:

1. If you are OK with the DMM API approach in general, but you have comme=
nts to this specific proposal:

1.1 If you think the proposal can be improved:
      Then please suggest the changes that you think can improve the prop=
osal (providing text changes)

1.2 If you think we need a new proposal:
You can provide the reason why this proposal does not work. and probably =
new idea that works.

2. Provide other comments if it not belongs to the above case.


Thanks,
-- =20
Dapeng Liu





--551a6e35_7e0c57b1_8d8
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>
                    <div>=46olks,</div><div><br></div><div>I would like t=
o reaffirm that the technical comments that I made is individual opinion =
(without co-chair=E2=80=99s hat).&nbsp;</div><div><br></div><div>To facil=
itate the discussion, I have the following suggestions:</div><div><br></d=
iv><div>1. If you are OK with the DMM API approach in general, but you ha=
ve comments to this specific proposal:</div><div><span class=3D=22Apple-t=
ab-span=22 style=3D=22white-space:pre=22>	</span></div><div><span class=3D=
=22Apple-tab-span=22 style=3D=22white-space:pre=22>	</span>1.1 If you thi=
nk the proposal can be improved:</div><div>&nbsp; &nbsp; &nbsp; <span cla=
ss=3D=22Apple-tab-span=22 style=3D=22white-space:pre=22>		</span>Then ple=
ase suggest the changes that you think can improve the proposal (providin=
g text changes)</div><div><span class=3D=22Apple-tab-span=22 style=3D=22w=
hite-space:pre=22>	</span></div><div><span class=3D=22Apple-tab-span=22 s=
tyle=3D=22white-space:pre=22>	</span>1.2 If you think we need a new propo=
sal:</div><div><span class=3D=22Apple-tab-span=22 style=3D=22white-space:=
pre=22>		</span>You can provide the reason why this proposal does not wor=
k. and probably new idea that works.</div><div><span class=3D=22Apple-tab=
-span=22 style=3D=22white-space:pre=22>	</span></div><div>2. Provide othe=
r comments if it not belongs to the above case.</div><div><br></div><div>=
<br></div><div>Thanks,</div><div><div>--&nbsp;</div><div>Dapeng Liu</div>=
</div></div><div><div></div></div>
            
--551a6e35_7e0c57b1_8d8--


From nobody Tue Mar 31 05:23:23 2015
Return-Path: <seiljeon@av.it.pt>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762581A9234 for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 05:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHlsDr6wk5-a for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 05:23:17 -0700 (PDT)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 247C01A9154 for <dmm@ietf.org>; Tue, 31 Mar 2015 05:23:13 -0700 (PDT)
Received: from [192.168.26.107] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 6.0.10) with ESMTPSA id 77424836; Tue, 31 Mar 2015 13:23:12 +0100
From: "Seil Jeon" <seiljeon@av.it.pt>
To: "'Moses, Danny'" <danny.moses@intel.com>
References: <006701d06800$96a57960$c3f06c20$@av.it.pt> <000d01d06af2$f2b6f1d0$d824d570$@av.it.pt> <F0CF5715D3D1884BAC731EA1103AC28134908F15@HASMSX106.ger.corp.intel.com>
In-Reply-To: <F0CF5715D3D1884BAC731EA1103AC28134908F15@HASMSX106.ger.corp.intel.com>
Date: Tue, 31 Mar 2015 13:23:12 +0100
Message-ID: <003901d06bad$75307a90$5f916fb0$@av.it.pt>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D06BB5.D6FC0E80"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKleNSwrf74lKEdePuzUFh/TOol/wIJAtYDAlqa+uabZ/LtgA==
Content-Language: ko
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/Waj9RwIRSDEsPzrvrubxoLKULcs>
Cc: dmm@ietf.org
Subject: Re: [DMM] Answer on raised questions for the proposed API
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 12:23:22 -0000

This is a multipart message in MIME format.

------=_NextPart_000_003A_01D06BB5.D6FC0E80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Danny,

 

See the inline please.

 

 

Seil Jeon 

 

 

 

From: Moses, Danny [mailto:danny.moses@intel.com] 
Sent: Monday, March 30, 2015 4:44 PM
To: Seil Jeon
Cc: dmm@ietf.org
Subject: RE: [DMM] Answer on raised questions for the proposed API

 

Hi Seil,

 

As to the potential of abuse:

Yes, I see your point and you are correct. If the IP stack will not request
a sustained IP address more than once after each movement to a new LAN (with
a different prefix), than there will be no abuse.

 

Seil -> Yes, it's true. Thanks for correction.

 

As to the second comment, please let me elaborate:

One potential implementation of the IP stack in the host, can be to request
a Nomadic IP address and a  Sustained IP address whenever connecting to a
network, and whenever moving to a new LAN, regardless if there are any
applications requesting any addresses. This way, whenever an application is
launched and requests either a Nomadic or Sustained IP address, the stack
can provide one without having to issue a request to the network. In this
case, there is no need for this flag from the application.

 

Seil -> Decision of which type of IP address by default will be depending on
the IP pool management policy by operators. You case may correspond to one
of them. What if only the Nomadic IP address is basically allocated upon a
network attachment? That is, a lot of applications require mere Internet
connectivity without session continuity support. So, the Sustained IP
address will be requested on demand, and the proposed flag will be used to
get a new Sustained IP address by expressing the explicit request by an
application.

 

Another potential implementation of the IP stack in the host is not to
request IP addresses in advance. In that case, it will issue a request for a
Nomadic IP address or a Sustained IP address the first time an application
requests one and use it for subsequent requests as long as it is not moving
to a different LAN. Once it moves, it will again request a new IP address
(Nomadic or Sustained - according to what is required) after receiving the
first request from any application. In this case as well, there is no need
for this flag.

 

Seil -> Another application requested just Sustained IP address while the IP
stack has already a Sustained IP address. Why should the IP stack try to get
a new one, though the application indicated simply "Sustained IP address
type"? You case took a step towards a solution where you want to draw. I
don't expect the action is generic when a Sustained IP address type is
requested.

 

Besides, you assumption on IP address allocation seems not valid. A mobile
host would get an IP address whatever the allocated IP address type is when
it attaches at a network, regardless of an application's IP address request.

 

As a matter of fact, if such a flag is defined, I cannot think of an example
where it will not be used. It seems to me that applications will always
request a refreshed Sustained IP address (when requesting a Sustained IP
address). If this is correct, the flag is redundant.

 

Seil -> Some applications, e.g. email, that are not relatively restricted
from optimal routing would consider a Sustained IP address without issuing
the new flag. More applications based on such network characteristic can be
thought more than expected.

And such use of existing Sustained IP address is not extraordinary, since IP
address is a resource, even in the consideration of IPv6 deployment. If as
many as applications require new Sustained IP address, it will end up in a
lot of network resource consumption in the mobility routers where the
Sustained IP addresses are anchored as the terminal moves.

 

Can you provide a scenario in which an application will not request to
refresh the Sustained IP address?

 

It was mentioned in the former comments.

 

 

Regards,

                /Danny

From: Seil Jeon [ <mailto:seiljeon@av.it.pt> mailto:seiljeon@av.it.pt] 
Sent: Monday, March 30, 2015 17:08
To: Moses, Danny
Cc:  <mailto:dmm@ietf.org> dmm@ietf.org
Subject: FW: [DMM] Answer on raised questions for the proposed API

 

Hi Danny,

 

Any comments?

 

Regards,

Seil Jeon

 

 

From: dmm [ <mailto:dmm-bounces@ietf.org> mailto:dmm-bounces@ietf.org] On
Behalf Of Seil Jeon
Sent: Thursday, March 26, 2015 8:08 PM
To:  <mailto:dmm@ietf.org> dmm@ietf.org
Subject: [DMM] Answer on raised questions for the proposed API

 

Hi,

 

I could attend DMM Thursday meeting via MeetEcho.

I could also hear some raised comments by Danny and Someone. Here goes
answers to the raised questions.

 

 

First, regarding the need of the proposed API (IPV6_PREFER_SRC_NEW),

 

The use of the proposed API is suggested in the SUSTAINED IP address case in
the draft. On receiving this API with the SUSTAINED IP address type at the
IP stack, it will try to get a new SUSTAINED IP address if there is no
available in the currently attached access network. So, actual obtaining of
the IP address will be tried one time while attached at a specific access
network. Even some applications put this API after, the already obtained
SUSTAINED IP will be used. So, no worries about abuse.

 

Second question sounded to me like that this API is not needed because the
host can get a new SUSTAINED IP address, right?

If the question is right, I don't understand what the question is meant,
that is how the host can get a new SUSTAINED IP address?

Based on the definition of three types of IP address, an application should
show its requirement with an API among them. If it is the SUSTAINED IP
address, how do we expect the IP stack will try to get a new SUSTAINED IP
address?

 

Besides, the propsoed API is not used alone but with the three type APIs. 

 

 

 

Regards,

 

Seil Jeon

 

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


------=_NextPart_000_003A_01D06BB5.D6FC0E80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Malgun Gothic";
	panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
	{font-family:"\@Arial Unicode MS";
	panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Arial","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:3.0cm 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Hi =
Danny,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>See the inline =
please.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><div><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Seil Jeon =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p></div><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Moses, Danny [mailto:danny.moses@intel.com] <br><b>Sent:</b> Monday, =
March 30, 2015 4:44 PM<br><b>To:</b> Seil Jeon<br><b>Cc:</b> =
dmm@ietf.org<br><b>Subject:</b> RE: [DMM] Answer on raised questions for =
the proposed API<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Hi Seil,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>As to the potential of =
abuse:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Yes, I see your point and you are correct. If =
the IP stack will not request a sustained IP address more than once =
after each movement to a new LAN (with a different prefix), than there =
will be no abuse.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
-&gt; Yes, it&#8217;s true. Thanks for =
correction.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>As to the =
second comment, please let me elaborate:<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>One potential =
implementation of the IP stack in the host, can be to request a Nomadic =
IP address and a &nbsp;Sustained IP address whenever connecting to a =
network, and whenever moving to a new LAN, regardless if there are any =
applications requesting any addresses. This way, whenever an application =
is launched and requests either a Nomadic or Sustained IP address, the =
stack can provide one without having to issue a request to the network. =
In this case, there is no need for this flag from the =
application.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
-&gt; Decision of which type of IP address by default will be depending =
on the IP pool management policy by operators. You case may correspond =
to one of them. What if only the Nomadic IP address is basically =
allocated upon a network attachment? That is, a lot of applications =
require mere Internet connectivity without session continuity support. =
So, the Sustained IP address will be requested on demand, and the =
proposed flag will be used to get a new Sustained IP address by =
expressing the explicit request by an =
application.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>Another =
potential implementation of the IP stack in the host is not to request =
IP addresses in advance. In that case, it will issue a request for a =
Nomadic IP address or a Sustained IP address the first time an =
application requests one and use it for subsequent requests as long as =
it is not moving to a different LAN. Once it moves, it will again =
request a new IP address (Nomadic or Sustained &#8211; according to what =
is required) after receiving the first request from any application. In =
this case as well, there is no need for this =
flag.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
-&gt; Another application requested just Sustained IP address while the =
IP stack has already a Sustained IP address. Why should the IP stack try =
to get a new one, though the application indicated simply =
&#8220;Sustained IP address type&#8221;? You case took a step towards a =
solution where you want to draw. I don&#8217;t expect the action is =
generic when a Sustained IP address type is =
requested.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Besides, you assumption on IP =
address allocation seems not valid. A mobile host would get an IP =
address whatever the allocated IP address type is when it attaches at a =
network, regardless of an application&#8217;s IP address request.<span =
style=3D'color:#1F497D'><o:p></o:p></span></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>As a =
matter of fact, if such a flag is defined, I cannot think of an example =
where it will not be used. It seems to me that applications will always =
request a refreshed Sustained IP address (when requesting a Sustained IP =
address). If this is correct, the flag is =
redundant.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
-&gt; Some applications, e.g. email, that are not relatively restricted =
from optimal routing would consider a Sustained IP address without =
issuing the new flag. More applications based on such network =
characteristic can be thought more than =
expected.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>And such use of existing =
Sustained IP address is not extraordinary, since IP address is a =
resource, even in the consideration of IPv6 deployment. If as many as =
applications require new Sustained IP address, it will end up in a lot =
of network resource consumption in the mobility routers where the =
Sustained IP addresses are anchored as the terminal =
moves.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>Can you =
provide a scenario in which an application will not request to refresh =
the Sustained IP address?<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>It was mentioned in the =
former comments.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Regards,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/Danny<o:p></o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Seil Jeon [</span><a href=3D"mailto:seiljeon@av.it.pt"><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>mailto:seilj=
eon@av.it.pt</span></a><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>] =
<br><b>Sent:</b> Monday, March 30, 2015 17:08<br><b>To:</b> Moses, =
Danny<br><b>Cc:</b> </span><a href=3D"mailto:dmm@ietf.org"><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>dmm@ietf.org=
</span></a><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br><b>Subje=
ct:</b> FW: [DMM] Answer on raised questions for the proposed =
API<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Hi =
Danny,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Any =
comments?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Regards,<o:p></o=
:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'>Seil =
Jeon<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
dmm [</span><a href=3D"mailto:dmm-bounces@ietf.org"><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>mailto:dmm-b=
ounces@ietf.org</span></a><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>] <b>On =
Behalf Of </b>Seil Jeon<br><b>Sent:</b> Thursday, March 26, 2015 8:08 =
PM<br><b>To:</b> </span><a href=3D"mailto:dmm@ietf.org"><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>dmm@ietf.org=
</span></a><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br><b>Subje=
ct:</b> [DMM] Answer on raised questions for the proposed =
API<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Hi,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could attend DMM Thursday meeting via MeetEcho.<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>I =
could also hear some raised comments by Danny and Someone. Here goes =
answers to the raised questions.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>First, regarding the need of =
the proposed API (IPV6_PREFER_SRC_NEW),<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>The =
use of the proposed API is suggested in the SUSTAINED IP address case in =
the draft. On receiving this API with the SUSTAINED IP address type at =
the IP stack, it will try to get a new SUSTAINED IP address if there is =
no available in the currently attached access network. So, actual =
obtaining of the IP address will be tried one time while attached at a =
specific access network. Even some applications put this API after, the =
already obtained SUSTAINED IP will be used. So, no worries about =
abuse.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Second question sounded to me =
like that this API is not needed because the host can get a new =
SUSTAINED IP address, right?<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>If =
the question is right, I don&#8217;t understand what the question is =
meant, that is how the host can get a new SUSTAINED IP =
address?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Based on the definition of =
three types of IP address, an application should show its requirement =
with an API among them. If it is the SUSTAINED IP address, how do we =
expect the IP stack will try to get a new SUSTAINED IP =
address?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Besides, the propsoed API is =
not used alone but with the three type APIs. <o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'>Regards,<o:p></o:p></span></p>=
<p class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span style=3D'font-family:"Arial","sans-serif"'>Seil =
Jeon<o:p></o:p></span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p>-------------------------------=
--------------------------------------<br>A member of the Intel =
Corporation group of companies<o:p></o:p></p><p>This e-mail and any =
attachments may contain confidential material for<br>the sole use of the =
intended recipient(s). Any review or distribution<br>by others is =
strictly prohibited. If you are not the intended<br>recipient, please =
contact the sender and delete all =
copies.<o:p></o:p></p></div></body></html>
------=_NextPart_000_003A_01D06BB5.D6FC0E80--


From nobody Tue Mar 31 10:08:04 2015
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1821A00BF for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 10:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XCbUxj1c_CI for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 10:08:00 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73AD31A1A70 for <dmm@ietf.org>; Tue, 31 Mar 2015 10:08:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t2VH7xQB025957; Tue, 31 Mar 2015 12:07:59 -0500
Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t2VH7nbR025837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 31 Mar 2015 12:07:50 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.229]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.21]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 10:07:49 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: h chan <h.anthony.chan@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Enhanced mobility anchoring
Thread-Index: AQHQZ+2Q2EAkZ5QP+UmZfjSKm6JQuZ0vC9KAgAfMsQA=
Date: Tue, 31 Mar 2015 17:07:48 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E2E9D3@XCH-BLV-504.nw.nos.boeing.com>
References: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C521EFCA4@szxeml557-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/acbUtJpAFDURqHeKsD4xfpIYKCw>
Subject: Re: [DMM] Enhanced mobility anchoring
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 17:08:03 -0000

--_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQW50aG9ueSwNCg0KV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgd2VsbCBhZGRyZXNzZWQg
YnkgQUVSTy4gQUVSTyBhbHNvIGFkZHJlc3Nlcw0Kc29tZSBnYXBzIGxpc3RlZCBpbiBSRkM3NDI5
IGJldHRlciB0aGFuIG90aGVyIGFwcHJvYWNoZXMsIGFuZCBJTUhPIGhhcw0KYSBtdWNoIGNsZWFu
ZXIgbW9iaWxpdHkgYXJjaGl0ZWN0dXJlLiBQbGVhc2UgaW5jbHVkZSBBRVJPIGluIHlvdXIgbGlz
dC4NCg0KVGhhbmtzIOKAkyBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206
IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaCBjaGFuDQpT
ZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTA6NTUgQU0NClRvOiBkbW1AaWV0Zi5vcmcN
ClN1YmplY3Q6IFtETU1dIEVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZw0KDQpJIHdhcyBhc2tl
ZCB0byBwcm92aWRlIG1vcmUgZXhwbGFuYXRpb24gYWJvdXQgYW5jaG9yaW5nLg0KDQpEaXN0cmli
dXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IG1heSBoYXZlIGFuY2hvcmluZyBmdW5jdGlvbmFsaXR5
IGluIGRpZmZlcmVudCBuZXR3b3JrcyBzbyB0aGF0IHJvdXRlcyBkbyBub3QgbmVlZCB0byB0cmF2
ZXJzZSBhIGNlbnRyYWxpemVkIGFuY2hvci4NCg0KWWV0LCB0aGUgZGVmaW5pdGlvbiBvZiAiYW5j
aG9yaW5nIGZ1bmN0aW9uIiAoQUYpIGluIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFk
dmVydGlzZW1lbnQgZm9yIHRoZSBJUCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoIGZ1bmN0aW9uIGlz
IGF2YWlsYWJsZSBpbiBtdWx0aXBsZSBuZXR3b3JrLg0KDQpTbyB3aGF0IGFyZSB0aGUgcmVzdCBv
ZiB0aGUgZnVuY3Rpb25zPw0KDQpTdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0aGUg
cGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KDQpDb25zaWRlciBhIHR5cGljYWwg
aGFuZG92ZXIgc2NlbmFyaW86IE1OIG1vdmVzIGZyb20gTmV0MSBtb3ZlcyB0byBOZXQyLCBhbmQg
Q04gaXMgaW4gTmV0Mw0KDQpUaGUgb2xkIEFSIChBUjEpIG9mIE1OIGluIE5ldDEgcGVyZm9ybXMg
UkEgZm9yIElQMTsgdGhlIG5ldyBBUiAoQVIyKSBvZiBNTiBpbiBOZXQyIHBlcmZvcm1zIFJBIGZv
ciBJUDI7IHRoZSBBUiAoQVIzKSBvZiBDTiBpbiBOZXQzIHBlcmZvcm1zIFJBIGZvciBJUDMuDQoN
ClRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFSMiBib3RoIHRyeSB0byBjYXVz
ZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0aGVtLiBJZiB3ZSBjYWxsIHRo
ZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJpYnV0ZWQgYW5jaG9yaW5nIGZ1
bmN0aW9uLCB0aGUgcXVlc3Rpb24gaXMgd2hhdCB0aGV5IGFyZSBhbmNob3JpbmcuDQoNClNvIGFj
Y29yZGluZyB0byB0aGUgZGVmaW5pdGlvbiBvZiBBRiwgQVIxIHBlcmZvcm1zIEFGIGZvciBJUDE7
IEFSMiBwZXJmb3JtcyBBRiBmb3IgSVAyIChub3QgSVAxKTsgYW5kIEFSMyBwZXJmb3JtcyBBRiBm
b3IgSVAzLg0KDQpPbmUgYXBwcm9hY2ggaXMgdG8gYm9ycm93IHRoZSB3ZWxsIGtub3duIGNvbmNl
cHQgb2Ygc2VwYXJhdGlvbiBvZiBzZXNzaW9uIElEIChTSUQpIGZyb20gcm91dGluZyBhZGRyZXNz
LiBUaGVyZSBhcmUgdG9ucyBvZiBwYXBlcnMgYWRkcmVzc2luZyBzdWNoIHNlcGFyYXRpb24sIGFu
ZCB0aGUgbGFjayBvZiBzdWNoIHNlcGFyYXRpb24gaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50
YWwgcHJvYmxlbSBvZiBicmVha2luZyBzZXNzaW9uIGFzIGFuIElQIGFkZHJlc3MgY2hhbmdlcyBk
dXJpbmcgaGFuZG92ZXIuDQoNCkluIGxpbmUgd2l0aCB0aGlzIHNlcGFyYXRpb24sIHRoZSBmdW5j
dGlvbiBvZiBhbmNob3Jpbmcgb2YgYSBzZXNzaW9uL2Zsb3cgY2FuIGJlIHNlcGFyYXRlZCBmcm9t
IHRoYXQgb2YgYW5jaG9yaW5nIGFuIElQIGFkZHJlc3MuDQoNClRoZSBzZXBhcmF0aW9uIG9mIHNl
c3Npb24gSUQgYW5kIHJvdXRpbmcgYWRkcmVzcyBjYW4gYmUgY29uc2lkZXJlZCBhIGdlbmVyYWxp
emF0aW9uLCBiZWNhdXNlIHRoZSBzZXNzaW9uIElEIGNhbiBiZSBhbnl0aGluZy4gQW4gZXhhbXBs
ZSBpcyBISVQgaW4gdGhlIElFVEYgcHJvdG9jb2wgSElQLg0KDQpUaGUgdXNlIG9mIEhvQSBhbmQg
Q29BIGNhbiBiZSBjb25zaWRlcmVkIGEgcGFydGljdWxhciBjYXNlIG9mIFNJRCBhbmQgcm91dGlu
ZyBhZGRyZXNzIHNlcGFyYXRpb24uIEluIHVzaW5nIGluZGlyZWN0aW9uLCBvbmUgSVAgYWRkcmVz
cyAoQ29BKSBpcyB1c2VkIGZvciByb3V0aW5nLCB3aGVyZWFzIGFub3RoZXIgSVAgYWRkcmVzcyAo
SG9BKSBpcyB1c2VkIGluIHRoZSBzb2NrZXQgYXMgcGFydCBvZiB0aGUgU0lEIGlkZW50aWZpY2F0
aW9uLg0KDQpBbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1Au
DQoNCkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNpcmVkIHBhdGgg
Y2FuIGJlOg0KDQpwYWNrZXQgZnJvbSBDTiBmaXJzdCBnb2VzIHRvIEFSMywgdG8gd2hpY2ggSVAz
IGlzIGFuY2hvcmVkLg0KDQppdCB0aGVuIGdvZXMgdG8gQVIxLCB0byB3aGljaCBJUDEgaXMgYW5j
aG9yZWQuDQoNCml0IHRoZW4gZ29lcyB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC4N
Cg0KV2hhdCBjYXVzZXMgdGhlIHBhY2tldHMgb2YgdGhlIGZsb3cgdG8gZ28gdGhpcyB3YXkgbWF5
IGJlOg0KDQpBUjIgaGFzIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbjogdGhlIGJpbmRpbmcgb2Yg
U0lEIG9mIHRoZSBmbG93IChJUDEpIHRvIElQIGFkZHJlc3Mgb2YgQVIyLiBJdCBzZW5kcyB0aGlz
IGluZm9ybWF0aW9uIHRvIEFSMS4NCg0KU3VjaCBhZGRpdGlvbmFsIGZ1bmN0aW9uIGJhc2ljYWxs
eSB0cmllcyB0byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyAoSVAxKSB0byB0cmF2ZXJz
ZSBBUjEgYW5kIEFSMi4NCg0KSW4gYW5vdGhlciBleGFtcGxlIG9mIHRoaXMgc2FtZSBzY2VuYXJp
bywgdGhlIGRlc2lyZWQgcGF0aCBpczoNCg0KcGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBB
UjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC4NCg0KaXQgdGhlbiBnb2VzIGRpcmVjdGx5IHRv
IEFSMiwgdG8gd2hpY2ggSVAyIGlzIGFuY2hvcmVkLg0KDQpXaGF0IGNhdXNlcyB0aGUgcGFja2V0
cyBvZiB0aGUgZmxvdyB0byBnbyB0aGlzIHdheSBtYXkgYmU6DQoNCkFSMyBoYXMgdGhlIGxvY2F0
aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBvZiBTSUQgb2YgdGhlIGZsb3cgKElQMSkgdG8g
SVAgYWRkcmVzcyBvZiBBUjIuDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBhbnkgb2YgdGhlc2Ug
aXMgbm90IGNsZWFyIGVub3VnaC4gVGhhbmsgeW91Lg0KDQpIIEFudGhvbnkgQ2hhbg0KDQoNCg0K
DQoNCg0K

--_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5IaSBBbnRob255LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
V2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgd2VsbCBhZGRyZXNzZWQgYnkgQUVSTy4gQUVSTyBh
bHNvIGFkZHJlc3NlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zb21lIGdhcHMgbGlzdGVkIGluIFJGQzc0
MjkgYmV0dGVyIHRoYW4gb3RoZXIgYXBwcm9hY2hlcywgYW5kIElNSE8gaGFzPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPmEgbXVjaCBjbGVhbmVyIG1vYmlsaXR5IGFyY2hpdGVjdHVyZS4gUGxlYXNlIGluY2x1
ZGUgQUVSTyBpbiB5b3VyIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5UaGFua3Mg4oCTIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZnJlZC5sLnRlbXBsaW5A
Ym9laW5nLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5oIGNoYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1h
cmNoIDI2LCAyMDE1IDEwOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBkbW1AaWV0Zi5vcmc8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gW0RNTV0gRW5oYW5jZWQgbW9iaWxpdHkgYW5jaG9yaW5nPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGFza2Vk
IHRvIHByb3ZpZGUgbW9yZSBleHBsYW5hdGlvbiBhYm91dCBhbmNob3Jpbmc8c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1l
bnQgbWF5IGhhdmUgYW5jaG9yaW5nIGZ1bmN0aW9uYWxpdHkgaW4gZGlmZmVyZW50IG5ldHdvcmtz
IHNvIHRoYXQgcm91dGVzIGRvIG5vdCBuZWVkIHRvIHRyYXZlcnNlIGEgY2VudHJhbGl6ZWQgYW5j
aG9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+WWV0LCB0aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDthbmNob3JpbmcgZnVuY3Rpb24m
cXVvdDsgKEFGKSZuYnNwO2luIFJGQyA3MzMzIGlzIGluIHRlcm1zIG9mIHJvdXRlIGFkdmVydGlz
ZW1lbnQgZm9yIHRoZSBJUCBhZGRyZXNzIG9ubHksIGFuZCBzdWNoJm5ic3A7ZnVuY3Rpb24gaXMg
YXZhaWxhYmxlIGluIG11bHRpcGxlIG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyB3aGF0IGFyZSB0aGUgcmVzdCBv
ZiB0aGUgZnVuY3Rpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWNoIGZ1bmN0aW9ucyBtYXkgdGVuZCB0byBjYXVzZSB0
aGUgcGFja2V0cyB0byB0cmF2ZXJzZSBjZXJ0YWluIG5vZGVzLg0KPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db25zaWRlciBhIHR5
cGljYWwgaGFuZG92ZXImbmJzcDtzY2VuYXJpbzogTU4gbW92ZXMgZnJvbSBOZXQxIG1vdmVzIHRv
IE5ldDIsIGFuZCBDTiBpcyBpbiBOZXQzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb2xkIEFSIChBUjEpIG9mIE1OJm5ic3A7
aW4gTmV0MSBwZXJmb3JtcyBSQSBmb3IgSVAxOyB0aGUgbmV3IEFSIChBUjIpIG9mIE1OIGluIE5l
dDIgcGVyZm9ybXMgUkEgZm9yIElQMjsgdGhlIEFSIChBUjMpIG9mIENOIGluIE5ldDMgcGVyZm9y
bXMgUkEgZm9yIElQMy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhZGRpdGlvbmFsIGZ1bmN0aW9ucyBhdCBBUjEgYW5kIEFS
MiBib3RoIHRyeSB0byBjYXVzZSB0aGUgcGFja2V0cyBvZiB0aGUgZmxvdyB0byB0cmF2ZXJzZSB0
aGVtLiBJZiB3ZSBjYWxsIHRoZXNlIGFkZGl0aW9uYWwgZnVuY3Rpb25zIHBhcnQgb2YgZGlzdHJp
YnV0ZWQgYW5jaG9yaW5nIGZ1bmN0aW9uLCB0aGUgcXVlc3Rpb24NCiBpcyB3aGF0IHRoZXkgYXJl
IGFuY2hvcmluZy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28gYWNjb3JkaW5nIHRvIHRoZSZuYnNwO2RlZmluaXRp
b24gb2YgQUYsIEFSMSBwZXJmb3JtcyBBRiBmb3IgSVAxOyBBUjIgcGVyZm9ybXMgQUYgZm9yIElQ
MiAobm90IElQMSk7IGFuZCBBUjMgcGVyZm9ybXMgQUYgZm9yIElQMy4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T25lIGFwcHJv
YWNoIGlzIHRvIGJvcnJvdyB0aGUgd2VsbCBrbm93biBjb25jZXB0IG9mIHNlcGFyYXRpb24gb2Yg
c2Vzc2lvbiBJRCAoU0lEKSBmcm9tIHJvdXRpbmcgYWRkcmVzcy4gVGhlcmUgYXJlIHRvbnMgb2Yg
cGFwZXJzIGFkZHJlc3Npbmcgc3VjaCBzZXBhcmF0aW9uLCBhbmQgdGhlIGxhY2sgb2Ygc3VjaCBz
ZXBhcmF0aW9uDQogaXMgY29uc2lkZXJlZCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbSBvZiBicmVh
a2luZyBzZXNzaW9uJm5ic3A7YXMgYW4gSVAgYWRkcmVzcyBjaGFuZ2VzIGR1cmluZyBoYW5kb3Zl
ci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+SW4gbGluZSB3aXRoIHRoaXMgc2VwYXJhdGlvbiwgdGhlIGZ1bmN0aW9uIG9mIGFu
Y2hvcmluZyBvZiBhIHNlc3Npb24vZmxvdyBjYW4gYmUgc2VwYXJhdGVkIGZyb20gdGhhdCBvZiBh
bmNob3JpbmcgYW4gSVAgYWRkcmVzcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbiBJ
RCBhbmQgcm91dGluZyBhZGRyZXNzIGNhbiBiZSBjb25zaWRlcmVkIGEgZ2VuZXJhbGl6YXRpb24s
IGJlY2F1c2UgdGhlIHNlc3Npb24gSUQgY2FuIGJlIGFueXRoaW5nLiBBbiBleGFtcGxlIGlzIEhJ
VCBpbiB0aGUgSUVURiBwcm90b2NvbCBISVAuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB1c2Ugb2YgSG9BIGFuZCBDb0Eg
Y2FuIGJlIGNvbnNpZGVyZWQgYSBwYXJ0aWN1bGFyIGNhc2Ugb2YgU0lEIGFuZCByb3V0aW5nIGFk
ZHJlc3Mgc2VwYXJhdGlvbi4gSW4gdXNpbmcgaW5kaXJlY3Rpb24sIG9uZSBJUCBhZGRyZXNzIChD
b0EpIGlzIHVzZWQgZm9yIHJvdXRpbmcsIHdoZXJlYXMgYW5vdGhlciBJUCBhZGRyZXNzDQogKEhv
QSkgaXMgdXNlZCBpbiB0aGUgc29ja2V0IGFzIHBhcnQgb2YgdGhlIFNJRCBpZGVudGlmaWNhdGlv
bi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Bbm90aGVyIElFVEYgcHJvdG9jb2wgb2Ygc3VjaCBzZXBhcmF0aW9uIGlzIExJU1Au
DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkluIG9uZSBleGFtcGxlIG9mIGhhbmRvdmVyIHNjZW5hcmlvIHRoZSBkZXNpcmVkIHBh
dGggY2FuIGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+cGFja2V0IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNo
IElQMyBpcyBhbmNob3JlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXQgdGhlbiBnb2VzIHRvIEFSMSwgdG8gd2hpY2ggSVAx
IGlzIGFuY2hvcmVkLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5pdCB0aGVuIGdvZXMgdG8gQVIyLCB0byB3aGljaCBJUDIgaXMg
YW5jaG9yZWQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdv
IHRoaXMgd2F5IG1heSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFSMiBoYXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uOiB0
aGUgYmluZGluZyBvZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9m
IEFSMi4gSXQgc2VuZHMgdGhpcyBpbmZvcm1hdGlvbiB0byBBUjEuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWNoIGFkZGl0aW9u
YWwgZnVuY3Rpb24gYmFzaWNhbGx5IHRyaWVzIHRvIGNhdXNlIHRoZSBwYWNrZXRzIG9mIHRoZSBm
bG93IChJUDEpIHRvIHRyYXZlcnNlIEFSMSBhbmQgQVIyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiBhbm90aGVyIGV4YW1w
bGUgb2YgdGhpcyBzYW1lIHNjZW5hcmlvLCB0aGUgZGVzaXJlZCBwYXRoIGlzOjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cGFja2V0
IGZyb20gQ04gZmlyc3QgZ29lcyB0byBBUjMsIHRvIHdoaWNoIElQMyBpcyBhbmNob3JlZC48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
Pml0IHRoZW4gZ29lcyBkaXJlY3RseSB0byBBUjIsIHRvIHdoaWNoIElQMiBpcyBhbmNob3JlZC48
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPldoYXQgY2F1c2VzIHRoZSBwYWNrZXRzIG9mIHRoZSBmbG93IHRvIGdvIHRoaXMgd2F5IG1h
eSBiZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkFSMyBoYXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uOiB0aGUgYmluZGluZyBv
ZiZuYnNwO1NJRCBvZiB0aGUgZmxvdyAoSVAxKSB0byBJUCBhZGRyZXNzIG9mIEFSMi4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
UGxlYXNlIGxldCBtZSBrbm93IGlmIGFueSBvZiB0aGVzZSBpcyBub3QgY2xlYXIgZW5vdWdoLiBU
aGFuayB5b3UuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkggQW50aG9ueSBDaGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_2134F8430051B64F815C691A62D9831832E2E9D3XCHBLV504nwnosb_--


From nobody Tue Mar 31 22:04:59 2015
Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77FA1A886A for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 22:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeI-D4rVkjsg for <dmm@ietfa.amsl.com>; Tue, 31 Mar 2015 22:04:56 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC971A8866 for <dmm@ietf.org>; Tue, 31 Mar 2015 22:04:56 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so62405481obc.2 for <dmm@ietf.org>; Tue, 31 Mar 2015 22:04:55 -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:subject :content-type:content-transfer-encoding; bh=aDlS9Dybi4am0rm+z9Z19f817003lvTDUTgzMxGuIK8=; b=yhlhT9U4WKP96dZ5WEf5E17MWn83RcXpuXHTNK2refuhLZBxpaCqDgTwqdvsXGwZq3 bXh31qeR4vgQgBQQvC4nXtULOssHsRM7nHA7pfGT9R+CCo8i74nntcdXauMwsMoRr5gF Y5w1tsGqRrUWHy+GeFYBRC8QFj58jdZ/UaLh9704i9SATpI4gtIHS9Pi+WkpkQQGwz9e FEp/cm7rwtrFnBLobGERNV4Qm375oigUxKJSUTmvpu2eHEnGIQqjMbtcG8biAX0BY8vf Iif4iNxJVLkUEnOJv9VRo7C27RsVNtyzlE5NRa4xprZa4XahOFvIcz/tsCKSt7EStN7p JvBQ==
X-Received: by 10.60.158.202 with SMTP id ww10mr38431610oeb.18.1427864695671;  Tue, 31 Mar 2015 22:04:55 -0700 (PDT)
Received: from [198.18.119.64] ([12.190.128.2]) by mx.google.com with ESMTPSA id vj2sm902527obb.10.2015.03.31.22.04.53 for <dmm@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 22:04:54 -0700 (PDT)
Message-ID: <551B7C73.4080500@gmail.com>
Date: Tue, 31 Mar 2015 22:04:51 -0700
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "dmm@ietf.org" <dmm@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/TJp9hLrTcBk-Y9tDoCmUyLEbscg>
Subject: [DMM] IETF#92 meeting minutes available
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 05:04:57 -0000

The minutes are here:
http://tools.ietf.org/wg/dmm/minutes?item=minutes-92-dmm.html

Thanks to John for taking extensive minutes.

- Jouni & dapeng