From nobody Tue Feb 16 14:51:39 2016 Return-Path: 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 ECA961AC3A6; Tue, 16 Feb 2016 14:51:38 -0800 (PST) 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 n0TUXs3xEOya; Tue, 16 Feb 2016 14:51:37 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 8DE3D1A9240; Tue, 16 Feb 2016 14:51:37 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id x65so112715327pfb.1; Tue, 16 Feb 2016 14:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=BgUbYJpG32gKpNl79Lpje1DZbLoZlhhZwjTZn0tEmtg=; b=Jr2/vH126PtLMjB67U37GEE5iR5RoItJ4rlM8r0yAMiRAXQdAqnASlIqnPibppmBqd Q5f9xAedBWK7PczWLCp2n5nQEfpYCWxZ0EE9JLs4eK/aEPu6eieNSGYA9xOVjqqGcGnT 31wHefCxkE5scTYdqEWkgoCxetJlg7//zMhl1SN5Qtt0UaL5rbGArKuGlIBdq90I+X0u ZllmoOsFwlC7pICBT1BaJQ1e97KSdLfadrGVnleomGzQU17r416qRF+alDuiUOVz5NvH z/q08e+yUjolcN+imD0cCoRg/WJCJA1gz5JKSV/dt6UsNiI5lYlf9yj2HU0k7Kc4L959 maFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=BgUbYJpG32gKpNl79Lpje1DZbLoZlhhZwjTZn0tEmtg=; b=bUzQcBO6+UzIlAdIXBAt6GMJTGLJ1vBNA9ngbGRdfy2O4B6s0vdN6TqOWKegiZHvsL LNAY/itJTJ+aN3/BK8hFWJifLCDudpsbUfKjViv64V/14ai51psUd2JadrGfFZC6z4EQ RZUEXwP8F1IDBbvUF1CJZW4HVTiiEdi3ueMfuBnnPUcKET8a0QXwbziiQJhnhQv6Dayy nvpkZvLySEdJzMPYhTKZrAYphOi9lIRQs0y+U+uzWT6qsnyKXbszBkrgwkdFVBRmhG0G 7DIvy5H3A5Q86O5P7sPIijV/ezGyKYLwWbSuRBhBRL5ZsVkk4ldaHW94pntsEBbGWK2h KFRw== X-Gm-Message-State: AG10YOQ8J/aMdbuYtQkntOzMxRgKHiUCCtH8Fu8rAL+kAQc9RendXy2xvBKKENjyUZaDFQ== X-Received: by 10.98.93.205 with SMTP id n74mr10170420pfj.99.1455663097143; Tue, 16 Feb 2016 14:51:37 -0800 (PST) Received: from [10.16.36.40] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id z67sm48052121pfa.71.2016.02.16.14.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 14:51:36 -0800 (PST) To: IETF Meeting Session Request Tool , session-request@ietf.org, dmm@ietf.org References: <20160216224343.9091.74100.idtracker@ietfa.amsl.com> From: Jouni Korhonen Message-ID: <56C3A7F7.9000906@gmail.com> Date: Tue, 16 Feb 2016 14:51:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160216224343.9091.74100.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmm-chairs@ietf.org Subject: Re: [DMM] dmm - Not having a session at IETF 95 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:51:39 -0000 Please ignore this mail & request not to have a session.. The new datatracker user interface just has the "not planning to meet" button quite close to to "retrieve information from previous meeting".. Sorry for bad aiming, Jouni 2/16/2016, 2:43 PM, "IETF Meeting Session Request Tool" kirjoitti: > > > Jouni Korhonen, a chair of the dmm working group, indicated that the dmm working group does not plan to hold a session at IETF 95. > > This message was generated and sent by the IETF Meeting Session Request Tool. > > From nobody Thu Feb 18 06:14:17 2016 Return-Path: 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 26E4F1A92AC for ; Thu, 18 Feb 2016 06:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 xBUxPZk6N_Fv for ; Thu, 18 Feb 2016 06:14:08 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id BDA881A924B for ; Thu, 18 Feb 2016 06:14:08 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 18 Feb 2016 06:13:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,465,1449561600"; d="scan'208";a="888682684" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 18 Feb 2016 06:14:00 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 18 Feb 2016 06:13:58 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 18 Feb 2016 06:13:58 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.202]) by HASMSX110.ger.corp.intel.com ([169.254.11.58]) with mapi id 14.03.0248.002; Thu, 18 Feb 2016 16:13:08 +0200 From: "Moses, Danny" To: Dave Dolson , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWA= Date: Thu, 18 Feb 2016 14:13:07 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTkzYzVkNGQtNzM0Yy00OWJjLWI3NGEtOWU1NzlmN2Q5ODEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkhDTmo2NU9lTFVxbTc3cnNqU053RElHSzJtcktVUlo3U0V3bkJJSFwvcVdRPSJ9 x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:14:16 -0000 Hi Dave, Sorry for the very late response. Somehow we missed the original email and = were reminded by Jouni (Thanks Jouni). Anyway, thank you for the thorough and helpful comments. We have produced a= new version and will publish it shortly. Please see further details to your comments: Dave> 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. Reply> "Nomadic" was discussed, it is not the best name but we could not find a be= tter one. What 'moves around' is the mobile host and as a result of that movement, it= s source IP address might become obsolete (when it moves from its original = LAN to another with a different prefix). An application on a mobile host re= quires a 'Nomadic' IP address when it does not care for the IP continuity g= uarantee services provided by the network. This is either because it knows = that the mobile host is not really mobile, or because it has other means of= maintaining session continuity and does not want the overhead associated w= ith network-provided IP continuity services. The term 'Ephemeral' is not associated with movement - we think it is bette= r to have a 'movement'-related name. Dave> 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC Reply> Make sense. Will be changed in the next version. Dave> 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. Reply> This is about whether to enable the application to set more than one flag o= r not per a given socket. We left that for discussion in the draft but neve= r resolved it. We prefer not to enable setting more than one flag since it add complexity.= The application can check the returned code and act upon it. For example, = if it uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns wit= h an error code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or IPV6_R= EQUEST_NOMADIC_IP (or without the flags - in case they are not supported by= the network). So we are replacing the original text: 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? With: Only one flag of these flags may be set on the same socket. If an applicati= on attempts to set more than one flag, the most recent setting will be the = one in effect. Dave> 4. Must resolve "Application of this solution to IPv4 is TBD." = - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. Reply> Actually, the charter of DMM addresses IPv6 only. So we are removing the te= xt that refers to IPv4 altogether. If we see in the future a need to addres= s IPv4, we will do so in a separate draft. Dave> 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? Reply> True. We added the following text at the end of section 3.4: The following new error codes are also defined in the document and will be = used in Socket API in compliance with the [RFC5014]: EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to req= uest that IP address type */ EAI_REQUIREIPFAILED /* The network could not assign the specific IP address= type */ Dave> 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? Reply> The addresses should be resolved before connect() or listen() in order to a= void unnecessary delay caused by the need to request the address from the n= etwork (with DHCP - for example). Furthermore, UDP should also be supported= , hence connect() or listen() may not be used. There for, they must be reso= lved at setsockopt() prior to the above calls. Do you see any problem with = that? Do you think text should be added to clarify this? Dave> 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? Reply> Both assume that a source IP address was assigned to the host. If the application invoked setsockopt() successfully prior to attempting to= send a message, the appropriate source IP address type will be used for th= e transmitted packets. If not, whatever source IP address assigned to the h= ost will be used. Dave> 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. Reply> Legacy application will not use these new flags, and as a result, will not = be able to influence the source IP address type and related mobility suppor= t. As a result, they will behave exactly as applications behave today. Clearly there will be some default behavior as to the assigned source IP ad= dress. Today, this depends on the access networks. Cellular networks usuall= y provide Fixed or Sustained source IP addresses, and WiFi networks usually= provide Nomadic source IP addresses. We do not think we should specify a strict behavior in this case, but rathe= r leave it to be implementation-specific. Once again, thanks for the good comments. Alper and Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, December 02, 2015 18:42 To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 (I haven't paid close attention to the list, so apologies if I'm raising ol= d issues.) 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. 4. Must resolve "Application of this solution to IPv4 is TBD." = - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. -Dave -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Tuesday, December 01, 2015 1:07 PM To: dmm@ietf.org; Jouni; Dapeng Liu Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Folks, This mail starts two week WGLC for the I-D: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 The WGLC ends 12/15/2015. Provide your reviews and comments to the mailing list. For the better track= ing of issues and proposed changed use the Issue Tracker to submit your iss= ues/proposals. - Jouni & Dapeng _______________________________________________ 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 --------------------------------------------------------------------- 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. From nobody Thu Feb 18 08:00:08 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 784A91B2B41; Thu, 18 Feb 2016 08:00:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218160004.31783.25463.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 08:00:04 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:00:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : On Demand Mobility Management Authors : Alper Yegin Kisuk Kweon Jinsung Lee Jungshin Park Danny Moses Filename : draft-ietf-dmm-ondemand-mobility-02.txt Pages : 11 Date : 2016-02-18 Abstract: Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 18 10:04:27 2016 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F51A9081; Tue, 16 Feb 2016 14:47:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216224700.8696.1861.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 14:47:00 -0800 Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 10:04:25 -0800 Cc: dmm-chairs@ietf.org, dmm@ietf.org, jounikor@gmail.com Subject: [DMM] dmm - Update to a Meeting Session Request for IETF 95 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:47:00 -0000 An update to a meeting session request has just been submitted by Jouni Korhonen, a Chair of the dmm working group. --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Jouni Korhonen Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dime detnet Second Priority: mif 6man v6ops Special Requests: --------------------------------------------------------- From nobody Thu Feb 18 12:46:38 2016 Return-Path: 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 BC5821A8AF7 for ; Thu, 18 Feb 2016 12:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.082 X-Spam-Level: ** X-Spam-Status: No, score=2.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 1tEzXgVaF-ne for ; Thu, 18 Feb 2016 12:46:26 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id B98FF1A8AEE for ; Thu, 18 Feb 2016 12:46:24 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Thu, 18 Feb 2016 15:46:23 -0500 From: Dave Dolson To: "Moses, Danny" , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGMnpBc4djly5kSnNVw4LIDUSJ632rDggHrNVYCAAAzEEA== Date: Thu, 18 Feb 2016 20:46:26 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 20:46:33 -0000 Danny and Alper, Thanks. I hope your helpful explanations below make it into the draft as we= ll. On the "nomadic address" question, this name really feels wrong to me. The = address doesn't move and hence isn't nomadic. You don't like "ephemeral" because it doesn't convey movement. But a question, does the host have to move for the principles of this docum= ent to apply? Couldn't a host get a new address (perhaps from a different wireless provid= er) without moving? Maybe "non-nomadic address" or "provider-local address" ? On point 6, yes I think you have to specify when the resolution occurs, sin= ce it affects which functions return error codes. I don't think the local address can be resolved before connect(), since the= choice of local address may depend on the remote address to connect. E.g.,= connections to a peer on a local LAN subnet need to use an address on that= interface. -Dave -----Original Message----- From: Moses, Danny [mailto:danny.moses@intel.com]=20 Sent: Thursday, February 18, 2016 9:13 AM To: Dave Dolson; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dave, Sorry for the very late response. Somehow we missed the original email and = were reminded by Jouni (Thanks Jouni). Anyway, thank you for the thorough and helpful comments. We have produced a= new version and will publish it shortly. Please see further details to your comments: Dave> 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. Reply> "Nomadic" was discussed, it is not the best name but we could not find a be= tter one. What 'moves around' is the mobile host and as a result of that movement, it= s source IP address might become obsolete (when it moves from its original = LAN to another with a different prefix). An application on a mobile host re= quires a 'Nomadic' IP address when it does not care for the IP continuity g= uarantee services provided by the network. This is either because it knows = that the mobile host is not really mobile, or because it has other means of= maintaining session continuity and does not want the overhead associated w= ith network-provided IP continuity services. The term 'Ephemeral' is not associated with movement - we think it is bette= r to have a 'movement'-related name. Dave> 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC Reply> Make sense. Will be changed in the next version. Dave> 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. Reply> This is about whether to enable the application to set more than one flag o= r not per a given socket. We left that for discussion in the draft but neve= r resolved it. We prefer not to enable setting more than one flag since it add complexity.= The application can check the returned code and act upon it. For example, = if it uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns wit= h an error code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or IPV6_R= EQUEST_NOMADIC_IP (or without the flags - in case they are not supported by= the network). So we are replacing the original text: 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? With: Only one flag of these flags may be set on the same socket. If an applicati= on attempts to set more than one flag, the most recent setting will be the = one in effect. Dave> 4. Must resolve "Application of this solution to IPv4 is TBD."=20 - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. Reply> Actually, the charter of DMM addresses IPv6 only. So we are removing the te= xt that refers to IPv4 altogether. If we see in the future a need to addres= s IPv4, we will do so in a separate draft. Dave> 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? Reply> True. We added the following text at the end of section 3.4: The following new error codes are also defined in the document and will be = used in Socket API in compliance with the [RFC5014]: EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to req= uest that IP address type */ EAI_REQUIREIPFAILED /* The network could not assign the specific IP address= type */ Dave> 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? Reply> The addresses should be resolved before connect() or listen() in order to a= void unnecessary delay caused by the need to request the address from the n= etwork (with DHCP - for example). Furthermore, UDP should also be supported= , hence connect() or listen() may not be used. There for, they must be reso= lved at setsockopt() prior to the above calls. Do you see any problem with = that? Do you think text should be added to clarify this? Dave> 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? Reply> Both assume that a source IP address was assigned to the host. If the application invoked setsockopt() successfully prior to attempting to= send a message, the appropriate source IP address type will be used for th= e transmitted packets. If not, whatever source IP address assigned to the h= ost will be used. Dave> 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. Reply> Legacy application will not use these new flags, and as a result, will not = be able to influence the source IP address type and related mobility suppor= t. As a result, they will behave exactly as applications behave today. Clearly there will be some default behavior as to the assigned source IP ad= dress. Today, this depends on the access networks. Cellular networks usuall= y provide Fixed or Sustained source IP addresses, and WiFi networks usually= provide Nomadic source IP addresses. We do not think we should specify a strict behavior in this case, but rathe= r leave it to be implementation-specific. Once again, thanks for the good comments. Alper and Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, December 02, 2015 18:42 To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 (I haven't paid close attention to the list, so apologies if I'm raising ol= d issues.) 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. 4. Must resolve "Application of this solution to IPv4 is TBD."=20 - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. -Dave -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Tuesday, December 01, 2015 1:07 PM To: dmm@ietf.org; Jouni; Dapeng Liu Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Folks, This mail starts two week WGLC for the I-D: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 The WGLC ends 12/15/2015. Provide your reviews and comments to the mailing list. For the better track= ing of issues and proposed changed use the Issue Tracker to submit your iss= ues/proposals. - Jouni & Dapeng _______________________________________________ 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 --------------------------------------------------------------------- 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. From nobody Fri Feb 19 07:33:47 2016 Return-Path: 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 632341B31CF for ; Fri, 19 Feb 2016 07:33:46 -0800 (PST) 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 dbDnyC0XlUl8 for ; Fri, 19 Feb 2016 07:33:44 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 D37F81B31CD for ; Fri, 19 Feb 2016 07:33:44 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id e127so52936179pfe.3 for ; Fri, 19 Feb 2016 07:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=WPIjysxQcrXDIGYRGqDbDGJLfM1q9ZYpDSCvcciHQnk=; b=tYmUQuwyQQhFBkQHz7SA5uMVAEWaf4PDMLBekoPuUv75rfI7o6am8+B17BDBWcJAld A18Ld/qmix3qMgillKVcuM//VhXILoAGF4SbDX2kKwiejwk4ptX+YAceIbIsI2yVmYmJ 6LvNOKwFnDA0PXzO5yz+3Eficvg4ZieDIBP7IqMm5WHo1CfL2+9ZRkHrNd17WzLfwzqv cUq2zRGyBokBky1xPxKOkB4JZu5xaSjw5UEv4cMU7mJ9tHeQ3ZYayjICbpZ3JYlYFDBS mM3OYvZSWzobphTN4fcgSIRl8GI62BmV5+I5irTpi0vJvf4BTs0x8KgWrMfCOC+mcMLS Xguw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=WPIjysxQcrXDIGYRGqDbDGJLfM1q9ZYpDSCvcciHQnk=; b=nLlSyWgIcOSm5qH6mFFhNWF7piYDzmGldgH2WeR0d+RRugNk9MpT/PzjZ1O2hbgYQ6 rFaVsMCp5FXivqntAsJWTzP2GfDLkJ1O1T61RnKx+3IrqSt1nc9gcfiMSQPhuVzqV409 h13n0g+/1ac0LK7ajodeicRC/60IBj4NHiTa8+RPkTi4cvTLum0UfwhKZnWCUG9mX02T yyczE2pfhfMUUUwSD9c6l8/+1/3N2Io9cctPa00qnwxgEt06b6lBC7fU0xKjVD6gsRj8 kddaa4HyqLrmJXlKGn68xcDtlZcxV8rGDvEOY/fZrG0toAyesA7hJeQNu9p26G09R4eU nL+g== X-Gm-Message-State: AG10YOTcCEJPgoBgjx5Za2dhvIRLyK0kbICMbjl+J0BLGsQQ7HkHXkoo4AIUXoDCThVdfA== X-Received: by 10.98.93.2 with SMTP id r2mr19112246pfb.64.1455896024518; Fri, 19 Feb 2016 07:33:44 -0800 (PST) Received: from [10.16.36.40] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id w9sm5025049pfa.21.2016.02.19.07.33.43 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 07:33:43 -0800 (PST) References: <5696D220.1030408@gmail.com> To: "dmm@ietf.org" From: Jouni Korhonen X-Forwarded-Message-Id: <5696D220.1030408@gmail.com> Message-ID: <56C735D6.9020206@gmail.com> Date: Fri, 19 Feb 2016 07:33:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5696D220.1030408@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [DMM] Fwd: IETF95 meeting - first call for agenda items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:33:46 -0000 A friendly reminder.. Jouni & Dapeng -------- Välitetty viesti / Fwd.Msg -------- Aihe: IETF95 meeting - first call for agenda items Päiväys: Wed, 13 Jan 2016 14:39:28 -0800 Lähettäjä: Jouni Korhonen Vastaanottaja: dmm@ietf.org Folks, IETF95 is approaching.. in order to build an agenda with appropriate time allocation we would like to collect the agenda requests as soon as possible. Working group I-Ds have a priority but won't be granted a slot unless asked by the authors explicitly. DMM topics will have priority over MIP maintenance topics. Name your I-D, requested time and if this is about a new work state also the reasoning why it deserves meeting time. Please, avoid requesting slots for I-Ds with just a "trivial" incremental update to the previous version. People should be able to do a diff themselves. Jouni & Dapeng From nobody Sun Feb 21 07:05:20 2016 Return-Path: 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 E78721B328A for ; Sun, 21 Feb 2016 07:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.081 X-Spam-Level: ** X-Spam-Status: No, score=2.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RP_MATCHES_RCVD=-0.006, 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 8YW8VCDT_1uB for ; Sun, 21 Feb 2016 07:05:16 -0800 (PST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAF71B3289 for ; Sun, 21 Feb 2016 07:05:16 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 21 Feb 2016 07:05:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,480,1449561600"; d="scan'208";a="750433884" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga003.jf.intel.com with ESMTP; 21 Feb 2016 07:05:15 -0800 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 21 Feb 2016 07:05:15 -0800 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 21 Feb 2016 07:05:14 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.202]) by LCSMSX154.ger.corp.intel.com ([169.254.7.180]) with mapi id 14.03.0248.002; Sun, 21 Feb 2016 17:05:12 +0200 From: "Moses, Danny" To: Dave Dolson , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAGoVAIAEdKFA Date: Sun, 21 Feb 2016 15:05:11 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2I1NjZhMzktYjc4Zi00NWFmLWFhZTUtOGY4ZTFlMzBlYTcxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlBrMnRrOG42Z0dBcHlaVXlzYkdBOFlFdGZWVHJNSUsydlBheDBDaTlVRFU9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 15:05:19 -0000 Hi Dave, Regarding the term "Nomadic" IP address: Actually, this draft is about enhancements to the Socket API that are usefu= l in relation with movement of the mobile host. Its intent was to notify th= e access network as to the type of IP session continuity it requires upon m= ovement between LANs. The idea is to reduce the network support for session= continuity (via PMIP, GTP, etc) when it is not needed. This draft is not d= ealing with devices migrating from one service provider to another as other= issues should be handled in such scenario. "Local" is not good as it clashes with IPv6 Local addresses. The best term in my mind would be: "An IP address without any NW guarantee = to continue to be valid after a potential host movement to a new LAN with a= different IP prefix". So far, we could not come with a good name for such = an address. May be "Guarantee-less"? Let's not forget: this is going to be used by application developers who do= not necessarily fully understand how networks allocate IP addresses and ma= intain their validity. Regarding when On-Demand resolution occurs (Point 6): How about if we say: If applications want to influence the type of IP address their generated tr= affic will use, they must do so after creating a Socket and prior to genera= ting the first transmitted packet. We do not want to be too specific since it is not a user's manual. Does this sound reasonable to you? Thanks, /Danny -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] = Sent: Thursday, February 18, 2016 22:46 To: Moses, Danny; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Danny and Alper, Thanks. I hope your helpful explanations below make it into the draft as we= ll. On the "nomadic address" question, this name really feels wrong to me. The = address doesn't move and hence isn't nomadic. You don't like "ephemeral" because it doesn't convey movement. But a question, does the host have to move for the principles of this docum= ent to apply? Couldn't a host get a new address (perhaps from a different wireless provid= er) without moving? Maybe "non-nomadic address" or "provider-local address" ? On point 6, yes I think you have to specify when the resolution occurs, sin= ce it affects which functions return error codes. I don't think the local address can be resolved before connect(), since the= choice of local address may depend on the remote address to connect. E.g.,= connections to a peer on a local LAN subnet need to use an address on that= interface. -Dave -----Original Message----- From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Thursday, February 18, 2016 9:13 AM To: Dave Dolson; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dave, Sorry for the very late response. Somehow we missed the original email and = were reminded by Jouni (Thanks Jouni). Anyway, thank you for the thorough and helpful comments. We have produced a= new version and will publish it shortly. Please see further details to your comments: Dave> 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. Reply> "Nomadic" was discussed, it is not the best name but we could not find a be= tter one. What 'moves around' is the mobile host and as a result of that movement, it= s source IP address might become obsolete (when it moves from its original = LAN to another with a different prefix). An application on a mobile host re= quires a 'Nomadic' IP address when it does not care for the IP continuity g= uarantee services provided by the network. This is either because it knows = that the mobile host is not really mobile, or because it has other means of= maintaining session continuity and does not want the overhead associated w= ith network-provided IP continuity services. The term 'Ephemeral' is not associated with movement - we think it is bette= r to have a 'movement'-related name. Dave> 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC Reply> Make sense. Will be changed in the next version. Dave> 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. Reply> This is about whether to enable the application to set more than one flag o= r not per a given socket. We left that for discussion in the draft but neve= r resolved it. We prefer not to enable setting more than one flag since it add complexity.= The application can check the returned code and act upon it. For example, = if it uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns wit= h an error code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or IPV6_R= EQUEST_NOMADIC_IP (or without the flags - in case they are not supported by= the network). So we are replacing the original text: More than one of these flags may be set on the same socket. In that case, a= n IP address compliant with any one of them shall be selected. TBD: Disallow this case? With: Only one flag of these flags may be set on the same socket. If an applicati= on attempts to set more than one flag, the most recent setting will be the = one in effect. Dave> 4. Must resolve "Application of this solution to IPv4 is TBD." = - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. Reply> Actually, the charter of DMM addresses IPv6 only. So we are removing the te= xt that refers to IPv4 altogether. If we see in the future a need to addres= s IPv4, we will do so in a separate draft. Dave> 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? Reply> True. We added the following text at the end of section 3.4: The following new error codes are also defined in the document and will be = used in Socket API in compliance with the [RFC5014]: EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to req= uest that IP address type */ EAI_REQUIREIPFAILED /* The network could not a= ssign the specific IP address type */ Dave> 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? Reply> The addresses should be resolved before connect() or listen() in order to a= void unnecessary delay caused by the need to request the address from the n= etwork (with DHCP - for example). Furthermore, UDP should also be supported= , hence connect() or listen() may not be used. There for, they must be reso= lved at setsockopt() prior to the above calls. Do you see any problem with = that? Do you think text should be added to clarify this? Dave> 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? Reply> Both assume that a source IP address was assigned to the host. If the application invoked setsockopt() successfully prior to attempting to= send a message, the appropriate source IP address type will be used for th= e transmitted packets. If not, whatever source IP address assigned to the h= ost will be used. Dave> 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. Reply> Legacy application will not use these new flags, and as a result, will not = be able to influence the source IP address type and related mobility suppor= t. As a result, they will behave exactly as applications behave today. Clearly there will be some default behavior as to the assigned source IP ad= dress. Today, this depends on the access networks. Cellular networks usuall= y provide Fixed or Sustained source IP addresses, and WiFi networks usually= provide Nomadic source IP addresses. We do not think we should specify a strict behavior in this case, but rathe= r leave it to be implementation-specific. Once again, thanks for the good comments. Alper and Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, December 02, 2015 18:42 To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 (I haven't paid close attention to the list, so apologies if I'm raising ol= d issues.) 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. 4. Must resolve "Application of this solution to IPv4 is TBD." = - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. -Dave -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Tuesday, December 01, 2015 1:07 PM To: dmm@ietf.org; Jouni; Dapeng Liu Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Folks, This mail starts two week WGLC for the I-D: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 The WGLC ends 12/15/2015. Provide your reviews and comments to the mailing list. For the better track= ing of issues and proposed changed use the Issue Tracker to submit your iss= ues/proposals. - Jouni & Dapeng _______________________________________________ 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 --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies. --------------------------------------------------------------------- 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. From nobody Sun Feb 21 18:05:59 2016 Return-Path: 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 DCD611A6FDF for ; Sun, 21 Feb 2016 18:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.082 X-Spam-Level: ** X-Spam-Status: No, score=2.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] 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 f744bBj5Y5IF for ; Sun, 21 Feb 2016 18:05:55 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 173481B29E9 for ; Sun, 21 Feb 2016 18:05:55 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 21 Feb 2016 21:05:57 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Sun, 21 Feb 2016 21:05:57 -0500 From: Dave Dolson To: "Moses, Danny" , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGMnpBc4djly5kSnNVw4LIDUSJ632rDggHrNVYCAAAzEEIAEuMeAgABi4kM= Date: Mon, 22 Feb 2016 02:05:55 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.63.53.189] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 02:05:58 -0000 >From an application developer's point of view, I don't think there should b= e a distinction about roaming between providers or with the same provider.= =0A= It should work with WiFi, mobile, even wired Ethernet.=0A= E.g., as I unplug my laptop from work, use the 3G stick on the train, WiFi = in the coffee shop and plug in wired Ethernet at home. I could have a fixed= address as well as several temporary (no guarantee) addresses.=0A= =0A= I'm not saying all of those access technologies need to have implementation= of all types of addresses.=0A= One might only get a fixed address from one of those providers, all the oth= ers being no-guarantee.=0A= =0A= -Dave=0A= =0A= ________________________________________=0A= From: Moses, Danny [danny.moses@intel.com]=0A= Sent: Sunday, February 21, 2016 10:05 AM=0A= To: Dave Dolson; dmm@ietf.org=0A= Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01=0A= =0A= Hi Dave,=0A= =0A= Regarding the term "Nomadic" IP address:=0A= Actually, this draft is about enhancements to the Socket API that are usefu= l in relation with movement of the mobile host. Its intent was to notify th= e access network as to the type of IP session continuity it requires upon m= ovement between LANs. The idea is to reduce the network support for session= continuity (via PMIP, GTP, etc) when it is not needed. This draft is not d= ealing with devices migrating from one service provider to another as other= issues should be handled in such scenario.=0A= =0A= "Local" is not good as it clashes with IPv6 Local addresses.=0A= =0A= The best term in my mind would be: "An IP address without any NW guarantee = to continue to be valid after a potential host movement to a new LAN with a= different IP prefix". So far, we could not come with a good name for such = an address. May be "Guarantee-less"?=0A= =0A= Let's not forget: this is going to be used by application developers who do= not necessarily fully understand how networks allocate IP addresses and ma= intain their validity.=0A= =0A= Regarding when On-Demand resolution occurs (Point 6):=0A= How about if we say:=0A= =0A= If applications want to influence the type of IP address their generated tr= affic will use, they must do so after creating a Socket and prior to genera= ting the first transmitted packet.=0A= =0A= We do not want to be too specific since it is not a user's manual.=0A= =0A= Does this sound reasonable to you?=0A= =0A= Thanks,=0A= /Danny=0A= =0A= -----Original Message-----=0A= From: Dave Dolson [mailto:ddolson@sandvine.com]=0A= Sent: Thursday, February 18, 2016 22:46=0A= To: Moses, Danny; dmm@ietf.org=0A= Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01=0A= =0A= Danny and Alper,=0A= Thanks. I hope your helpful explanations below make it into the draft as we= ll.=0A= =0A= =0A= On the "nomadic address" question, this name really feels wrong to me. The = address doesn't move and hence isn't nomadic.=0A= You don't like "ephemeral" because it doesn't convey movement.=0A= But a question, does the host have to move for the principles of this docum= ent to apply?=0A= Couldn't a host get a new address (perhaps from a different wireless provid= er) without moving?=0A= Maybe "non-nomadic address" or "provider-local address" ?=0A= =0A= =0A= On point 6, yes I think you have to specify when the resolution occurs, sin= ce it affects which functions return error codes.=0A= I don't think the local address can be resolved before connect(), since the= choice of local address may depend on the remote address to connect. E.g.,= connections to a peer on a local LAN subnet need to use an address on that= interface.=0A= =0A= =0A= -Dave=0A= =0A= =0A= =0A= =0A= -----Original Message-----=0A= From: Moses, Danny [mailto:danny.moses@intel.com]=0A= Sent: Thursday, February 18, 2016 9:13 AM=0A= To: Dave Dolson; dmm@ietf.org=0A= Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01=0A= =0A= Hi Dave,=0A= =0A= Sorry for the very late response. Somehow we missed the original email and = were reminded by Jouni (Thanks Jouni).=0A= =0A= Anyway, thank you for the thorough and helpful comments. We have produced a= new version and will publish it shortly.=0A= =0A= Please see further details to your comments:=0A= =0A= Dave>=0A= 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly.=0A= =0A= Reply>=0A= "Nomadic" was discussed, it is not the best name but we could not find a be= tter one.=0A= What 'moves around' is the mobile host and as a result of that movement, it= s source IP address might become obsolete (when it moves from its original = LAN to another with a different prefix). An application on a mobile host re= quires a 'Nomadic' IP address when it does not care for the IP continuity g= uarantee services provided by the network. This is either because it knows = that the mobile host is not really mobile, or because it has other means of= maintaining session continuity and does not want the overhead associated w= ith network-provided IP continuity services.=0A= =0A= The term 'Ephemeral' is not associated with movement - we think it is bette= r to have a 'movement'-related name.=0A= =0A= Dave>=0A= 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc.=0A= - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC=0A= =0A= Reply>=0A= Make sense. Will be changed in the next version.=0A= =0A= Dave>=0A= 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies.=0A= =0A= Reply>=0A= This is about whether to enable the application to set more than one flag o= r not per a given socket. We left that for discussion in the draft but neve= r resolved it.=0A= =0A= We prefer not to enable setting more than one flag since it add complexity.= The application can check the returned code and act upon it. For example, = if it uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns wit= h an error code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or IPV6_R= EQUEST_NOMADIC_IP (or without the flags - in case they are not supported by= the network).=0A= =0A= So we are replacing the original text:=0A= More than one of these flags may be set on the same socket. In that case, a= n IP address compliant with any one of them shall be selected.=0A= TBD: Disallow this case?=0A= =0A= With:=0A= Only one flag of these flags may be set on the same socket. If an applicati= on attempts to set more than one flag, the most recent setting will be the = one in effect.=0A= =0A= Dave>=0A= 4. Must resolve "Application of this solution to IPv4 is TBD."=0A= - clearly the socket option is IPV6_something, but...=0A= - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false.=0A= - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request.=0A= - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails.=0A= - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses.=0A= =0A= Reply>=0A= Actually, the charter of DMM addresses IPv6 only. So we are removing the te= xt that refers to IPv4 altogether. If we see in the future a need to addres= s IPv4, we will do so in a separate draft.=0A= =0A= Dave>=0A= 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others?=0A= =0A= Reply>=0A= True.=0A= =0A= We added the following text at the end of section 3.4:=0A= =0A= The following new error codes are also defined in the document and will be = used in Socket API in compliance with the [RFC5014]:=0A= EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to req= uest that IP address type */ EAI_REQUIREIPFAILED /* The network could not a= ssign the specific IP address type */=0A= =0A= Dave>=0A= 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required?=0A= =0A= Reply>=0A= The addresses should be resolved before connect() or listen() in order to a= void unnecessary delay caused by the need to request the address from the n= etwork (with DHCP - for example). Furthermore, UDP should also be supported= , hence connect() or listen() may not be used. There for, they must be reso= lved at setsockopt() prior to the above calls. Do you see any problem with = that?=0A= =0A= Do you think text should be added to clarify this?=0A= =0A= Dave>=0A= 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented?=0A= =0A= Reply>=0A= Both assume that a source IP address was assigned to the host.=0A= If the application invoked setsockopt() successfully prior to attempting to= send a message, the appropriate source IP address type will be used for th= e transmitted packets. If not, whatever source IP address assigned to the h= ost will be used.=0A= =0A= Dave>=0A= 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications.=0A= - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams.=0A= =0A= Reply>=0A= Legacy application will not use these new flags, and as a result, will not = be able to influence the source IP address type and related mobility suppor= t. As a result, they will behave exactly as applications behave today.=0A= =0A= Clearly there will be some default behavior as to the assigned source IP ad= dress. Today, this depends on the access networks. Cellular networks usuall= y provide Fixed or Sustained source IP addresses, and WiFi networks usually= provide Nomadic source IP addresses.=0A= =0A= We do not think we should specify a strict behavior in this case, but rathe= r leave it to be implementation-specific.=0A= =0A= Once again, thanks for the good comments.=0A= =0A= Alper and Danny=0A= =0A= -----Original Message-----=0A= From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson=0A= Sent: Wednesday, December 02, 2015 18:42=0A= To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu=0A= Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01=0A= =0A= (I haven't paid close attention to the list, so apologies if I'm raising ol= d issues.)=0A= =0A= 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly.=0A= =0A= 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc.=0A= - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC=0A= =0A= 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies.=0A= =0A= 4. Must resolve "Application of this solution to IPv4 is TBD."=0A= - clearly the socket option is IPV6_something, but...=0A= - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false.=0A= - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request.=0A= - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails.=0A= - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses.=0A= =0A= 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others?=0A= =0A= 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required?=0A= =0A= 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented?=0A= =0A= 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications.=0A= - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams.=0A= =0A= =0A= =0A= -Dave=0A= =0A= =0A= =0A= =0A= -----Original Message-----=0A= From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen=0A= Sent: Tuesday, December 01, 2015 1:07 PM=0A= To: dmm@ietf.org; Jouni; Dapeng Liu=0A= Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01=0A= =0A= Folks,=0A= =0A= This mail starts two week WGLC for the I-D:=0A= https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01=0A= =0A= The WGLC ends 12/15/2015.=0A= =0A= Provide your reviews and comments to the mailing list. For the better track= ing of issues and proposed changed use the Issue Tracker to submit your iss= ues/proposals.=0A= =0A= - Jouni & Dapeng=0A= =0A= _______________________________________________=0A= dmm mailing list=0A= dmm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dmm=0A= =0A= _______________________________________________=0A= dmm mailing list=0A= dmm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/dmm=0A= ---------------------------------------------------------------------=0A= A member of the Intel Corporation group of companies=0A= =0A= This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies.=0A= =0A= ---------------------------------------------------------------------=0A= A member of the Intel Corporation group of companies=0A= =0A= This e-mail and any attachments may contain confidential material for=0A= the sole use of the intended recipient(s). Any review or distribution=0A= by others is strictly prohibited. If you are not the intended=0A= recipient, please contact the sender and delete all copies.=0A= =0A= From nobody Tue Feb 23 01:51:04 2016 Return-Path: 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 BA4241A8789 for ; Tue, 23 Feb 2016 01:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 Dr-JpqicXL76 for ; Tue, 23 Feb 2016 01:50:59 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2841D1A6FE1 for ; Tue, 23 Feb 2016 01:50:59 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 23 Feb 2016 01:50:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,488,1449561600"; d="scan'208,223";a="657734537" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 23 Feb 2016 01:50:58 -0800 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 23 Feb 2016 01:50:58 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.202]) by hasmsx109.ger.corp.intel.com ([169.254.3.144]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 11:50:56 +0200 From: "Moses, Danny" To: Dave Dolson , "dmm@ietf.org" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAGoVAIAEdKFAgACboYCAAjOZAA== Date: Tue, 23 Feb 2016 09:50:55 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmNlOGU3YWUtOWE2Yy00YjVjLWFkZTYtYTE1YjY3ZWEzNDc4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik1lcnlOQkM1RDdTcXpGOGRjcG9wRFN6R2VNVjVTNWF4YVh3YVhMVUVzb3M9In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 09:51:03 -0000 I agree with you. This is indeed a desired user experience. But there are various other things that should also be taken in considerati= on. For example - the connection cost. The user might be in a contract that= is free (or cheap) for WiFi connection, but expensive for 3G or LTE. In th= at case, she/he might not desire a transparent continuation of service... Also, service continuity does not necessarily requires the network infrastr= ucture's support. It can also be achieved in application-level. These are important topics which, to the best of my knowledge, are discusse= d in the MIF WG. Hence they are not in the scope of this draft. But, after the work on this draft is completed, I will be very happy to wor= k with you of an extension to cover roaming between radio technologies and = service providers in MIF. /Danny -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] = Sent: Monday, February 22, 2016 04:06 To: Moses, Danny; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 >From an application developer's point of view, I don't think there should b= e a distinction about roaming between providers or with the same provider. It should work with WiFi, mobile, even wired Ethernet. E.g., as I unplug my laptop from work, use the 3G stick on the train, WiFi = in the coffee shop and plug in wired Ethernet at home. I could have a fixed= address as well as several temporary (no guarantee) addresses. I'm not saying all of those access technologies need to have implementation= of all types of addresses. One might only get a fixed address from one of those providers, all the oth= ers being no-guarantee. -Dave ________________________________________ From: Moses, Danny [danny.moses@intel.com] Sent: Sunday, February 21, 2016 10:05 AM To: Dave Dolson; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dave, Regarding the term "Nomadic" IP address: Actually, this draft is about enhancements to the Socket API that are usefu= l in relation with movement of the mobile host. Its intent was to notify th= e access network as to the type of IP session continuity it requires upon m= ovement between LANs. The idea is to reduce the network support for session= continuity (via PMIP, GTP, etc) when it is not needed. This draft is not d= ealing with devices migrating from one service provider to another as other= issues should be handled in such scenario. "Local" is not good as it clashes with IPv6 Local addresses. The best term in my mind would be: "An IP address without any NW guarantee = to continue to be valid after a potential host movement to a new LAN with a= different IP prefix". So far, we could not come with a good name for such = an address. May be "Guarantee-less"? Let's not forget: this is going to be used by application developers who do= not necessarily fully understand how networks allocate IP addresses and ma= intain their validity. Regarding when On-Demand resolution occurs (Point 6): How about if we say: If applications want to influence the type of IP address their generated tr= affic will use, they must do so after creating a Socket and prior to genera= ting the first transmitted packet. We do not want to be too specific since it is not a user's manual. Does this sound reasonable to you? Thanks, /Danny -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Thursday, February 18, 2016 22:46 To: Moses, Danny; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Danny and Alper, Thanks. I hope your helpful explanations below make it into the draft as we= ll. On the "nomadic address" question, this name really feels wrong to me. The = address doesn't move and hence isn't nomadic. You don't like "ephemeral" because it doesn't convey movement. But a question, does the host have to move for the principles of this docum= ent to apply? Couldn't a host get a new address (perhaps from a different wireless provid= er) without moving? Maybe "non-nomadic address" or "provider-local address" ? On point 6, yes I think you have to specify when the resolution occurs, sin= ce it affects which functions return error codes. I don't think the local address can be resolved before connect(), since the= choice of local address may depend on the remote address to connect. E.g.,= connections to a peer on a local LAN subnet need to use an address on that= interface. -Dave -----Original Message----- From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Thursday, February 18, 2016 9:13 AM To: Dave Dolson; dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Hi Dave, Sorry for the very late response. Somehow we missed the original email and = were reminded by Jouni (Thanks Jouni). Anyway, thank you for the thorough and helpful comments. We have produced a= new version and will publish it shortly. Please see further details to your comments: Dave> 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. Reply> "Nomadic" was discussed, it is not the best name but we could not find a be= tter one. What 'moves around' is the mobile host and as a result of that movement, it= s source IP address might become obsolete (when it moves from its original = LAN to another with a different prefix). An application on a mobile host re= quires a 'Nomadic' IP address when it does not care for the IP continuity g= uarantee services provided by the network. This is either because it knows = that the mobile host is not really mobile, or because it has other means of= maintaining session continuity and does not want the overhead associated w= ith network-provided IP continuity services. The term 'Ephemeral' is not associated with movement - we think it is bette= r to have a 'movement'-related name. Dave> 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC Reply> Make sense. Will be changed in the next version. Dave> 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. Reply> This is about whether to enable the application to set more than one flag o= r not per a given socket. We left that for discussion in the draft but neve= r resolved it. We prefer not to enable setting more than one flag since it add complexity.= The application can check the returned code and act upon it. For example, = if it uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns wit= h an error code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or IPV6_R= EQUEST_NOMADIC_IP (or without the flags - in case they are not supported by= the network). So we are replacing the original text: More than one of these flags may be set on the same socket. In that case, a= n IP address compliant with any one of them shall be selected. TBD: Disallow this case? With: Only one flag of these flags may be set on the same socket. If an applicati= on attempts to set more than one flag, the most recent setting will be the = one in effect. Dave> 4. Must resolve "Application of this solution to IPv4 is TBD." - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. Reply> Actually, the charter of DMM addresses IPv6 only. So we are removing the te= xt that refers to IPv4 altogether. If we see in the future a need to addres= s IPv4, we will do so in a separate draft. Dave> 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? Reply> True. We added the following text at the end of section 3.4: The following new error codes are also defined in the document and will be = used in Socket API in compliance with the [RFC5014]: EAI_REQUIREIPNOTSUPPORTED /*The network does not support the ability to req= uest that IP address type */ EAI_REQUIREIPFAILED /* The network could not a= ssign the specific IP address type */ Dave> 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? Reply> The addresses should be resolved before connect() or listen() in order to a= void unnecessary delay caused by the need to request the address from the n= etwork (with DHCP - for example). Furthermore, UDP should also be supported= , hence connect() or listen() may not be used. There for, they must be reso= lved at setsockopt() prior to the above calls. Do you see any problem with = that? Do you think text should be added to clarify this? Dave> 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? Reply> Both assume that a source IP address was assigned to the host. If the application invoked setsockopt() successfully prior to attempting to= send a message, the appropriate source IP address type will be used for th= e transmitted packets. If not, whatever source IP address assigned to the h= ost will be used. Dave> 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. Reply> Legacy application will not use these new flags, and as a result, will not = be able to influence the source IP address type and related mobility suppor= t. As a result, they will behave exactly as applications behave today. Clearly there will be some default behavior as to the assigned source IP ad= dress. Today, this depends on the access networks. Cellular networks usuall= y provide Fixed or Sustained source IP addresses, and WiFi networks usually= provide Nomadic source IP addresses. We do not think we should specify a strict behavior in this case, but rathe= r leave it to be implementation-specific. Once again, thanks for the good comments. Alper and Danny -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, December 02, 2015 18:42 To: Jouni Korhonen; dmm@ietf.org; Dapeng Liu Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 (I haven't paid close attention to the list, so apologies if I'm raising ol= d issues.) 1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, b= ut in this draft, Nomadic IP addresses do not move around; they are replace= d. "Ephemeral IP Address" might convey the idea more clearly. 2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE"= in IPV6_REQ_FIXED_IP etc. - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC 3. There is a "TDB" in section 3.4. "TBD: Disallow this case?" This needs = to be resolved. I suggest the most restrictive flag applies. 4. Must resolve "Application of this solution to IPv4 is TBD." - clearly the socket option is IPV6_something, but... - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (htt= ps://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6= _V6ONLY is false. - I think the goal should be that the API *does* apply to IPv4 via IPv4-ma= pped-IPv6 addresses, while acknowledging that the operating system or netwo= rk may not be able to fulfill the request. - I.e., permit the application to request constraints on IPv4, but also= expect the application to try for a relaxed address if the initial request= fails. - I see no need to support the API with AF_INET sockets, since AF_INET6 ca= n be used with IPV6_ONLY=3Dfalse and IPv4-mapped-IPv6 addresses. 5. The error codes are not clearly defined. What is the errno for failure o= f setsockopt() and others? 6. I'm unclear on when the on-demand resolution occurs? I don't think it ca= n be done at the time of setsockopt(); as I understand it, the addresses ar= e resolved later, at connect() or listen(). I'm not sure about this, but it= should be explained. If the resolution is done at connect() time, is a new= errno required? 7. Some socket interfaces are not mentioned. What about sendto(), sendmsg()= , which are not connection-oriented? 8. In section 4.1, support for legacy applications does not really say how = to support legacy applications. - my opinion: the default (lacking new socket options) should be to requir= e Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for= non-connected datagrams. -Dave -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Tuesday, December 01, 2015 1:07 PM To: dmm@ietf.org; Jouni; Dapeng Liu Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Folks, This mail starts two week WGLC for the I-D: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01 The WGLC ends 12/15/2015. Provide your reviews and comments to the mailing list. For the better track= ing of issues and proposed changed use the Issue Tracker to submit your iss= ues/proposals. - Jouni & Dapeng _______________________________________________ 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 --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies. --------------------------------------------------------------------- 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. From nobody Thu Feb 25 07:30:05 2016 Return-Path: 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 020801B2A7C for ; Thu, 25 Feb 2016 07:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] 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 JpdGqMtboSkP for ; Thu, 25 Feb 2016 07:30:02 -0800 (PST) Received: from outbound.public.mod.uk (outbound.public.mod.uk [82.110.109.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804001B2AB9 for ; Thu, 25 Feb 2016 07:30:01 -0800 (PST) Received: from outbound.earth.public.mod.uk by outbound.public.mod.uk with ESMTP id u1PFTwH0002172 ; Thu, 25 Feb 2016 15:29:58 GMT X-BT-id: baede1b4e948f8c203051f3c7cb549e3 From: "Newton, Mathew Mr" To: Dave Dolson , "Moses, Danny" Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAIudAIAKo5og Date: Thu, 25 Feb 2016 15:29:50 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Feb 2016 15:29:50.0863 (UTC) FILETIME=[5E2A99F0:01D16FE1] X-Loop-Check: public.mod.uk Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 15:30:04 -0000 A recent, and hitherto silent, lurker here so apologies for wading in unann= ounced and so late in the day... -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson > On the "nomadic address" question, this name really feels wrong to me. Th= e address doesn't move and hence isn't nomadic. > You don't like "ephemeral" because it doesn't convey movement. > But a question, does the host have to move for the principles of this doc= ument to apply? > Couldn't a host get a new address (perhaps from a different wireless prov= ider) without moving? > Maybe "non-nomadic address" or "provider-local address" ? Would something along the lines of 'Non-persistent topologically-correct' a= ddress work here? The 'topologically-correct' component reflects the fact that the address is= relevant/usable only on a specific network connection. The 'non-persistent= ' aspect indicates that this address can change (whether that be due to a c= hange of attachment or not is immaterial in this context). Granted it is a bit of a mouthful but perhaps the nuances of what is trying= to be described require it? Regards, Mathew From nobody Fri Feb 26 13:51:30 2016 Return-Path: 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 DE8FE1B315A for ; Fri, 26 Feb 2016 13:51:28 -0800 (PST) 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 TI7Yrfm7yKY5 for ; Fri, 26 Feb 2016 13:51:27 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 87D141B3129 for ; Fri, 26 Feb 2016 13:51:27 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id q63so58310318pfb.0 for ; Fri, 26 Feb 2016 13:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=B4441fxH1JibuzYVKTnvS9sV84kKbp+QS2lIwsWWNrU=; b=svl3Y8kDnP791D3qkSzXvQCTJiCDIsrGNQmH2FLY5dwm9bFjMjY0d9B+tUddGJrRCL ANUCcJNdHnAiLlg4aa01+zeezqtO6YSgobhDXSXoxZZvTKt7+CSX73tLufTaZWxD/snV wAdqqGVvb1vxetuPmRm+Kh6hTAcP8rX6NgI9lDoRhYH1XgkMf1WAYHQBef5yIjfpr3uK 913415HIGruYCmoYFDdJfB5MOzo0xSoYzEoU0CNh4jaajX/aw8pyQAEJbaPDAQIJJFH6 OdVrbrggcujVqA9L/cfNu3h8+qJEuP2NAPMSbKSHiUvd95GwaA1TQAvNzcKkjcZ+J+UL 0hAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=B4441fxH1JibuzYVKTnvS9sV84kKbp+QS2lIwsWWNrU=; b=lnOGGPwq9ZOiNKFygDIEfbjGSxiG8npwhQk5nX2Nw+HcRI1gpSoaTManOXqR7HArLE OyZ1sMhOGWDmmoyJbSrsej3yf+bGSdFgEx97J/+FkRpQVXMN3MAJvdl9W1HhFB2Pwf4t uf9lLyCfRdA9CE/A/GnbiketS6S7DOeEFF1UpJokREcDOZ/YTv9li1Qyqhstcx/RGzZI XL6ra9CK0uxWm5iUiJxfzoG6TUY4cbMRx5u4dJ0B9PG1JcMvbC8Bi5dX+g8w7UEFB7Og +8yG5rDQt+nfqjrEKKLQqM8n+dPpk+3Iz2e/3NEL66kudfic0HiOccwgWtfsNnBUKA1g TykA== X-Gm-Message-State: AD7BkJL6w22ujK5pL+/t/NbLiipAa1aCj0U8D+69sa3NWxM8veESVr69Clp2SchQrJv+zg== X-Received: by 10.98.64.26 with SMTP id n26mr5335604pfa.149.1456523487231; Fri, 26 Feb 2016 13:51:27 -0800 (PST) Received: from [10.16.75.156] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id fa3sm21458781pab.45.2016.02.26.13.51.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 13:51:26 -0800 (PST) To: "dmm@ietf.org" From: Jouni Korhonen Message-ID: <56D0C8DE.9010704@gmail.com> Date: Fri, 26 Feb 2016 13:51:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] current status X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:51:29 -0000 Folks, Just reminding you all where we are at now. Active DMM WG documents: * draft-ietf-dmm-ondemand-mobility-02 - WGLC #1 done - document revised - New WGLC to be initiated * draft-ietf-dmm-4283mnids-01 - WGLC #1 done - revised I-D needed - Jouni & Sri owe some text to Charlie Active MIP6 maintenance WG documents: * draft-ietf-dmm-hnprenum-00 * draft-ietf-dmm-lma-controlled-mag-params-00 * draft-ietf-dmm-mag-multihoming-00 Coming proposals/presentations in IETF95: * draft-moses-dmm-dhcp-ondemand-mobility-02 * draft-chan-dmm-distributed-mobility-anchoring-06 - Update coming before the meeting Currently we have agenda requests for 70~90 mins worth. - Jouni From nobody Sun Feb 28 04:17:28 2016 Return-Path: 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 C8CED1B352C for ; Sun, 28 Feb 2016 04:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.008 X-Spam-Level: X-Spam-Status: No, score=-5.008 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 H9cgov39V8AW for ; Sun, 28 Feb 2016 04:17:24 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id EF58A1B3532 for ; Sun, 28 Feb 2016 04:17:23 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 28 Feb 2016 04:17:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,514,1449561600"; d="scan'208";a="754650679" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 28 Feb 2016 04:17:22 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 28 Feb 2016 04:17:22 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 28 Feb 2016 04:17:22 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.105]) by HASMSX110.ger.corp.intel.com ([169.254.11.243]) with mapi id 14.03.0248.002; Sun, 28 Feb 2016 14:17:19 +0200 From: "Moses, Danny" To: "Newton, Mathew Mr" , Dave Dolson Thread-Topic: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 Thread-Index: AQHRLGNCmmE+d1SrqEm02pCc///KWJ63xloAgHpwIWCAAGoVAIAKp90AgAShv6A= Date: Sun, 28 Feb 2016 12:17:19 +0000 Message-ID: References: <565DE1DD.2070007@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmZhZDA4OTctNTlhYy00Y2FiLWE5NTUtZDViNTliYThkZGZlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im9LSSt0VzM4N21zNUdackw1bENjRHpReXBqZHMyYVhQQ1NRbGliYnFpQ289In0= x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 12:17:26 -0000 'Non-persistent topologically-correct' is toooooo long... But, 'non-persistent' or 'guarantee-less' might be considered. It seems like this is the only issue to e resolve. How about I present thi= s in the next Face-to-face and we can have a final vote on it. Regards, /Danny -----Original Message----- From: Newton, Mathew Mr [mailto:Mathew.Newton643@mod.uk] = Sent: Thursday, February 25, 2016 17:30 To: Dave Dolson; Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 A recent, and hitherto silent, lurker here so apologies for wading in unann= ounced and so late in the day... -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson > On the "nomadic address" question, this name really feels wrong to me. Th= e address doesn't move and hence isn't nomadic. > You don't like "ephemeral" because it doesn't convey movement. > But a question, does the host have to move for the principles of this doc= ument to apply? > Couldn't a host get a new address (perhaps from a different wireless prov= ider) without moving? > Maybe "non-nomadic address" or "provider-local address" ? Would something along the lines of 'Non-persistent topologically-correct' a= ddress work here? The 'topologically-correct' component reflects the fact that the address is= relevant/usable only on a specific network connection. The 'non-persistent= ' aspect indicates that this address can change (whether that be due to a c= hange of attachment or not is immaterial in this context). Granted it is a bit of a mouthful but perhaps the nuances of what is trying= to be described require it? Regards, Mathew --------------------------------------------------------------------- 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.