From nobody Thu Aug 1 06:02:33 2019 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 829071200F9; Thu, 1 Aug 2019 06:02:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-ondemand-mobility@ietf.org, Dapeng Liu , Sri Gundavelli , dmm-chairs@ietf.org, sgundave@cisco.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2019 06:02:31 -0700 Archived-At: Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dmm-ondemand-mobility-18=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 13:02:32 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-ondemand-mobility-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss. Sorry for the long delay on my side! Here is my old comment still: Please also note that address mobility is actually more a transport question that an application layer question. For TCP session-lasting addresses will always be more efficient if available while an application using TCP will always need to cover the case where an TCP connection fails or is interrupted and therefore the application needs to reconnect. However, in contrast QUIC supports IP address mobility and will survive changing IP addresses. I think that should be also clarified in the draft and it should be double-check if the use of the word application is always correct or if it should be replaced sometimes with e.g. transport system or a more general term. From nobody Thu Aug 1 06:05:28 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375B120156; Thu, 1 Aug 2019 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 L9IW8I-9rNxd; Thu, 1 Aug 2019 06:05:22 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 6F330120151; Thu, 1 Aug 2019 06:05:22 -0700 (PDT) Received: from 200116b82c29570018d4278acba8c5ea.dip.versatel-1u1.de ([2001:16b8:2c29:5700:18d4:278a:cba8:c5ea]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1htAlb-000298-Kt; Thu, 01 Aug 2019 15:05:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 1 Aug 2019 15:05:10 +0200 Cc: The IESG , "draft-ietf-dmm-ondemand-mobility@ietf.org" , "sgundave@cisco.com" , "dmm-chairs@ietf.org" , "dmm@ietf.org" , Dapeng Liu , "Satoru Matsushima (satoru.matsushima@gmail.com)" , Suresh Krishnan Content-Transfer-Encoding: quoted-printable Message-Id: References: <155067045192.31478.5148741965914604640.idtracker@ietfa.amsl.com> <169696FF-C61C-434E-B260-6DD575C248A2@kuehlewind.net> To: "Moses, Danny" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564664722;1110b0c8; X-HE-SMSGID: 1htAlb-000298-Kt Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-ondemand-mobility-16=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 13:05:26 -0000 Hi Danny, I cleared my discuss now. However, given these are quite large changes, = I think Suresh and the chairs need to decide if they want/need to rerun = the wg last call. See further comments inline (given I know had some time to look at this = again and would like to add some thoughts). > On 31. Jul 2019, at 21:52, Moses, Danny wrote: >=20 > Hi Mirja (and all other reviewers), > Thanks for your comments. >=20 > I read once more your comments about the removal of the Socket API = definitions (from February 2019), and after more thought agree to remove = it from the normative part of the document. > I believe that the important aspect of this work is to define the = ability of applications to indicate the type of service they require in = terms of session continuity and IP address reachability. The part that = enhances the Socket APIs is our idea of implementation and not = necessarily the only one. Once the concepts are defined, Socket API = enhancements may better be defined in other forums. I have to said I wasn=E2=80=99t fully aware that RFC3493, RFC3542, and = RFC5014 specify the Socket API in such detail. I personally still think = that RFCs are not the best format to specify APIs in that detail (e.g. = using full functional c code) as usually the communities implementing = these APIs in the end may have additional considerations for what to = optimise for. However, these RFC mostly specify new structs and did not = change the actual socket functions. In this sense the change proposed in = this new drafts seems to be a much bigger change. Note that documenting = an existing implementation of an API in an informational RFC can be a = different case.=20 Anyway for this document I would still say that the best way to = implement this new API isn=E2=80=99t fully clear, and therefore it might = be better to not demand one specific way to implement. Initially when = reading the draft I didn=E2=80=99t fully think thought the blocking = case. However, I guess another option would be to do the request for a = new address during bind() if needed, however, I=E2=80=99m sure there are = more thinks to consider when to best initiate such a request. On the = other hand, acquiring an address of a specific type seems actually = independent of opening a socket and could be done any time before the = socket is created and bound. So I think removing any specifics is a good = way forward. Thanks! Still, just double-checking we do the right thing here: it would be = different if e.g. the API would be already implemented like this in the = Linux kernel. Then documenting what=E2=80=99s there could be of value. = However, my currently understanding is that this is not the case=E2=80=A6?= >=20 > So I am removing sections 3.5, 4 and 6 from the document (as you = suggested in the email from February).=20 Thanks okay. I would also be okay with having 4.2. still in the doc if = people feel such an example would be helpful (with some minor tweaks to = remove references to sockets or setsc()). >=20 > I think it could be helpful to add an appendix that provide an example = of an implementation in high-level. I reworded the text that was removed = (section 3.5) to become a description of an example (rather than a = definition of a solution) and placed it as an appendix. Yes, I think this information is good and valuable to have in the draft. = I would also be okay with moving the section as now in the appendix back = in to the main body of the doc. Thanks! Mirja >=20 > I believe this was the last open issue and that now the draft can be = published. > Please consider the new version that I have posted: = https://tools.ietf.org/pdf/draft-ietf-dmm-ondemand-mobility-18.pdf >=20 > Best regards,=20 >=20 > Danny >=20 > -----Original Message----- > From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]=20 > Sent: Monday, July 29, 2019 19:57 > To: Moses, Danny > Cc: The IESG ; = draft-ietf-dmm-ondemand-mobility@ietf.org; sgundave@cisco.com; = dmm-chairs@ietf.org; dmm@ietf.org; Dapeng Liu > Subject: Re: Mirja K=C3=BChlewind's Discuss on = draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT) >=20 > Hi Danny, >=20 > Sorry for my super late reply! Somehow your mail got sorted in the = wrong folder and I therefore overlooked it. >=20 > Did you have a chance to talk more about this with other reviewers or = other people in the working group? >=20 > I still think that it is not appropriate nor very useful to have the = Socket API specified in the body of the draft (as the Linux community = will not necessarily follow this). Therefore I still recommend to remove = it or more it to the appendix and clearly indicated that this is an = example implementation for illustrative purposes only.=20 >=20 > Further I think it would still be good to discuss pros and cons or = different approaches to realise this interface rather than trying to = impose one specific implementation (which may potentially not be adopted = in practice). >=20 > Please see further inline below. >=20 > Thanks! > Mirja >=20 >=20 >> On 22. Feb 2019, at 11:49, Moses, Danny = wrote: >>=20 >> Hi Mirja, >> Thanks for your comments. >>=20 >> I would like to start with responding to your last proposal to remove = all socket API specifications from the document. >>=20 >> Yes, we could do that. However, this is a significant modification = and I would like some sort of ruff consensus from the rest of the = reviewers for such a significant change. >>=20 >> I must admit that this idea was brought up to me after the WGLC and I = was not sure whether this could be done without a broader discussion. = During the work on this document (which has been discussed in many dmm = session over several years), people felt that the Socket API info was = important. Furthermore, there were several discussions about whether to = use additional flags in setsockopt() or add a new function (which was = added eventually). There were also discussions about whether or not to = add a pseudo code example to the document and after it was added, a = discussion about the example.=20 >>=20 >> My personal view is that the concept of introducing mobility service = types and enabling applications to request them on a per-socket basis, = is the most important aspect of this work. The socket extensions part is = there to provide guidance from IETF as to how this extension should be = designed. The multiple discussion we had about the socket extensions = prove to me that some people think they are valuable as well. >>=20 >> If the reviewers think that leaving the socket extensions = specification in the document is a show stopper, I will remove the text = as you propose, but I would like the opinions of more reviewers on that.=20= >>=20 >>=20 >> Response to the comment about the API approach: >> The comment indicates that according to section 3.2 Fixed IP address = cannot be configured on a per socket basis since the application needs = the same IP address for multiple socket connections. This, according to = the comment, contradicts the text in section 3.3 indicating that IP = address type selection is made on a per-socket granularity. >>=20 >> I would like to clarify this point. >>=20 >> IP address type selection should indeed be done on a per-socket = basis. If an application requires a socket with a Fixed address type, it = will require the same address whenever it re-opens this specific socket. = But this does not mean that the application requires the same Fixed = source IP address for other sockets it uses (if any). It can use = whatever source IP address type it needs according to the address = reachability and/or session continuity requirements for the other = sockets.=20 >=20 > This is still not clear to me because usually there is no way to = =E2=80=9Cre-open=E2=80=9D a socket. When the socket is closed you can = only open a new socket and there seems no way right now to indicate that = the same fixed IP address is needed with this new socket than was used = for an old closed socket. >>=20 >> Furthermore, when a mobile host deploys several applications with one = of them requiring a Fixed source IP address, others may require = different address types and this is supported when the address type is = selected on a per-socket basis. >=20 > This is understood. I was talking more about the other case where the = same address is required for multiple sockets. >>=20 >>=20 >> Response to the comment about adding flags to setsockopt() versus the = new function setsc(): >> The original design was to use new flags for setsockopt(). However, = during discussions in the dmm group, some people were concern with the = fact that the new functionality may cause a =E2=80=98blocking=E2=80=99 = behavior to setsockopt(). The reason for this =E2=80=98blocking=E2=80=99 = behavior, as described in section 3.5, is due to the fact that in some = cases, requesting a specific address type may trigger an interaction = between the mobile host and the network requesting a prefix for this = address. This interaction which involves exchange of packets may take = some time, and the function can return only after the exchange of = packets is completed. >>=20 >> The concern was that this changes the behavior of setsockopt() from a = function that returns immediately, to a function that may block the = invoking thread for a while, may confuse socket users. >>=20 >> Several options were presented to resolve this concern and the = alternative that was selected by dmm was to leave setsockopt() in its = non-=E2=80=98blocking=E2=80=99 nature, and introduce a new function =E2=80= =93 =E2=80=98setsc()=E2=80=99 that has no legacy usage and may block the = thread if the invocation triggers an exchange of packets between the = TCP/IP stack in the mobile host and the network (as described in section = 6.1). >>=20 >> I hope I managed to clarify this point. >=20 > I think this should further be explained in the draft. However, that = is a decision to make for OS community that will implement this. >=20 >>=20 >>=20 >> Response to the comment about mobility being a transport question = rather than an application layer question: >> I am not sure I agree with this comment .I think that it does not = take in account the extra cost and non-optimized routes used when = networks provide session-lasting source IP addresses. But nevertheless, = having a discussion about this point only strengthens the notion that = the flexibility of being able to select service types on a per-socket = basis is valuable. >=20 > This comment was also related to TAPS, as Magnus mentioned. Some of = the functionality requested here could be provided through the TAPS API = e.g. by indicating a preference. This is another reason to not specify a = concrete Socket API in this document because in future these APIs could = look very differently and you still want to make sure that the needed = functionality is supporter. Probably it would also be good to point the = TAPS group at this document and make sure its considered in their = architecture. >=20 >=20 >>=20 >> /Danny >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] >> Sent: Wednesday, February 20, 2019 15:48 >> To: The IESG >> Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; Dapeng Liu=20 >> ; Sri Gundavelli ;=20 >> dmm-chairs@ietf.org; sgundave@cisco.com; dmm@ietf.org >> Subject: Mirja K=C3=BChlewind's Discuss on=20 >> draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-dmm-ondemand-mobility-16: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all=20= >> email addresses included in the To and CC lines. (Feel free to cut=20 >> this introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> As mentioned by the TSV-ART review (Thanks Magnus!) and confirmed by = Danny Moses in his response to the TSV-ART review ("There were several = discussions as to whether this draft should specify Socket extensions or = provide guidelines for an API provided by the network stack to = applications. The decision, eventually, was that since IETF does not = specify the Socket API, we should not specify Socket extensions, but = rather, provide guidelines for such functionality. "), I don't think = this document should specify an socket API. >>=20 >> Further I don't necessarily think the API approach taken is correct. = First section 3.3. says: >>=20 >> "IP address type selection is made on a per-socket granularity. >> Different parts of the same application may have different needs. >> For example, the control-plane of an application may require a Fixed >> IP Address in order to stay reachable, whereas the data-plane of the >> same application may be satisfied with a Session-lasting IP = Address." >>=20 >> However, Fixed IP Address (as defined in section 3.2) cannot be = configured on a per socket-basis as the application needs the same IP = address for multiple socket connections. >>=20 >> Further, section 3.5. says. >>=20 >> "Extending this further by adding more flags does not work when a >> request for an address of a certain type results in requiring the IP >> stack to wait for the network to provide the desired source IP = prefix >> and hence causing the setsockopt() call to block until the prefix is >> allocated (or an error indication from the network is received)." >>=20 >> However, later on section 6.1. it says: >>=20 >> "setsc() MAY block the invoking thread if it triggers the TCP/IP = stack >> to request a new IP prefix from the network to construct the desired >> source IP address." >>=20 >> Therefore, I really don't understand why a new flag in setsockopt() = can not be used. >>=20 >> I propose to remove all socket API specifications from this document = and only discuss requirements (as indicated by Danny). That would = basically mean to remove sections 3.5, 4.1, and 6. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Please also note that address mobility is actually more a transport = question that an application layer question. For TCP session-lasting = addresses will always be more efficient if available while an = application using TCP will always need to cover the case where an TCP = connection fails or is interrupted and therefore the application needs = to reconnect. However, in contrast QUIC supports IP address mobility and = will survive changing IP addresses. I think that should be also = clarified in the draft and it should be double-check if the use of the = word application is always correct or if it should be replaced sometimes = with e.g. transport system or a more general term. >>=20 >>=20 >> --------------------------------------------------------------------- >> A member of the Intel Corporation group of companies >>=20 >> This e-mail and any attachments may contain confidential material for=20= >> the sole use of the intended recipient(s). Any review or distribution=20= >> by others is strictly prohibited. If you are not the intended=20 >> recipient, please contact the sender and delete all copies. >=20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > 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 Aug 1 10:48:53 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136D1201C5; Thu, 1 Aug 2019 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Ci3Gm6ZafLMq; Thu, 1 Aug 2019 10:48:50 -0700 (PDT) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 DBC961201B4; Thu, 1 Aug 2019 10:48:49 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2019 10:48:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,335,1559545200"; d="scan'208";a="196924063" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 01 Aug 2019 10:48:49 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 1 Aug 2019 10:48:49 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 1 Aug 2019 10:48:48 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.57]) by HASMSX105.ger.corp.intel.com ([169.254.1.231]) with mapi id 14.03.0439.000; Thu, 1 Aug 2019 20:48:46 +0300 From: "Moses, Danny" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "draft-ietf-dmm-ondemand-mobility@ietf.org" , Dapeng Liu , Sri Gundavelli , "dmm-chairs@ietf.org" , "dmm@ietf.org" , The IESG , Suresh Krishnan , "Satoru Matsushima (satoru.matsushima@gmail.com)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-dmm-ondemand-mobility-18:_(with_COMMENT)?= Thread-Index: AQHVSGlqL5yDOeP5pEiILHn/DxTCZabmifyw Date: Thu, 1 Aug 2019 17:48:45 +0000 Message-ID: References: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com> In-Reply-To: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjc0ODRkODgtMzZkZi00ODY4LWJmOTYtYWM0M2IyMjFkOGE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicGswM2RtdFcrSWhzRGdaMUc0S25kTE9ib0l4dUR0TUxIeEw0SzQzRG5HMnZ1WUdsTlR2aU9yeGpYUlRZYnJcL2cifQ== dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dmm-ondemand-mobility-18=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 17:48:52 -0000 SGkgQWdhaW4sDQpSZWdhcmRpbmcgeW91ciBjbGFyaWZpY2F0aW9uIGFib3V0IG1vYmlsaXR5IGJl aW5nIGJldHRlciBzZXJ2ZWQgYnkgdGhlIHRyYW5zcG9ydCBsYXllciB2ZXJzdXMgdGhlIGFwcGxp Y2F0aW9uIGxheWVyLg0KDQpUaGlzIHdvcmsgaXMgbm90IGFib3V0IHRyeWluZyB0byBmaW5kIGEg YmV0dGVyIG9yIG1vcmUgZWZmaWNpZW50IHdheSB0byBoYW5kbGUgbW9iaWxpdHkgd2hpbGUgcHJl c2VydmluZyB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24uIEl0IGlzIGFib3V0IGVuYWJsaW5nIGFw cGxpY2F0aW9ucyB0byBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB0aGV5IG5lZWQgdGhpcyBzZXJ2 aWNlLCB3aGljaCBpcyBwcm92aWRlZCBhdXRvbWF0aWNhbGx5IGFuZCB0cmFuc3BhcmVudGx5IGlu IHNvbWUgbW9iaWxlIG5ldHdvcmsgaW1wbGVtZW50YXRpb25zIChsaWtlIGNlbGx1bGFyIG5ldHdv cmtzKS4NCg0KVGFrZSwgZm9yIGV4YW1wbGUsIHRoZSBhIHZpZGVvIGJyb3dzZXIgYXBwLiBTaW5j ZSBpdCBpcyBidWZmZXJpbmcgcGFydHMgb2YgdGhlIHZpZGVvLCBpdCBjYW4gY2xvc2UgYW4gZXhp c3Rpbmcgc29ja2V0IGFuZCBvcGVuIGEgbmV3IG9uZSB3aXRoIGRpZmZlcmVudCBhdHRyaWJ1dGVz LCB3aXRob3V0IGFueSB1c2VyLWV4cGVyaWVuY2UgZGVncmFkYXRpb24uIFRoaXMgY291bGQgYmUg dXNlZnVsIHdoZW4sIGFzIGEgcmVzdWx0IG9mIGEgaG9zdCBtb3ZpbmcgdG8gYSBkaWZmZXJlbnQg cGxhY2UgdGhhdCBoYXMgYSBkaWZmZXJlbnQgKGNsb3NlcikgaW5zdGFuY2Ugb2YgdGhlIHZpZGVv IHNlcnZlci4gQSBzd2l0Y2ggdG8gdGhlIG5ldyB2aWRlbyBzZXJ2ZXIgaW5zdGFuY2UgcmVxdWly ZXMgdGhhdCB0aGUgdmlkZW8gYnJvd3NlciBpcyBhd2FyZSBvZiB0aGUgbW9iaWxpdHkgZXZlbnQg YW5kIGlzIGFibGUgdG8gbG9jYXRlIGEgZGlmZmVyZW50IHNlcnZlci4gSWYgdGhlIElQIGNvbm5l Y3Rpb24gaXMgcHJlc2VydmVkIChieSB0dW5uZWxpbmcgb3IgYW55IG90aGVyIHdheSksIHRoZSB2 aWRlbyBicm93c2VyIHdpbGwgc3RheSBjb25uZWN0ZWQgdG8gdGhlIG9yaWdpbmFsIHNlcnZlciBh bmQgdGhlIHF1YWxpdHktb2YtZXhwZXJpZW5jZSBtaWdodCBiZSBhZmZlY3RlZC4gVGhpcyBpcyBh biBleGFtcGxlIGZvciBhIEdyYWNlZnVsLXJlcGxhY2VtZW50IHNlcnZpY2UgdGhhdCBpcyBtb3Jl IGFwcHJvcHJpYXRlIHRoYW4gdGhlIFNlc3Npb24tbGFzdGluZyBzZXJ2aWNlLiANCg0KQW5vdGhl ciBxdWVzdGlvbiB5b3UgaGFkIHdhcyB0byB3aGV0aGVyIHRoZSB3b3JkICdhcHBsaWNhdGlvbicg aXMgYWx3YXlzIGNvcnJlY3QuIEkgY2Fubm90IGNvbW1pdCB0byAnYWx3YXlzJywgYnV0IHRoaXMg d29yayB3YXMgZGVzaWduZWQgdG8gZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBjb252ZXkgdGhlaXIg c2VydmljZSBuZWVkcy4gQSB0cmFuc3BvcnQgbGF5ZXIgY2Fubm90IGtub3cgdGhlIGFiaWxpdGll cyBvZiB0aGUgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyB0byBjb3BlIHdpdGggc291cmNlIElQIGFk ZHJlc3MgY2hhbmdlcywgb25seSBhcHBsaWNhdGlvbnMga25vdyB0aGF0LiBJbiBhZGRpdGlvbiwg c2V2ZXJhbCBhcHBsaWNhdGlvbnMgY2FuIGV4ZWN1dGUgY29uY3VycmVudGx5LCBlYWNoIHdpdGgg ZGlmZmVyZW50IG5lZWRzLiBTbyB0aGUgZmxleGliaWxpdHkgb2Ygc2VsZWN0aW5nIHRoZSBzZXJ2 aWNlIHR5cGUgc2hvdWxkIGJlIHBlci1hcHBsaWNhdGlvbiwgb3IgZXZlbiwgcGVyLXNvY2tldCwg YXMgYXBwbGljYXRpb24gbWF5IHVzZSBtb3JlIHRoYW4gb25lIHNvY2tldC4gDQoNCldlIHRyaWVk IHRvIGNvbnZleSBib3RoIHRoZXNlIHBvaW50cyBpbiB0aGUgZG9jdW1lbnQuIElmIHlvdSB0aGlu ayB0aGlzIGlzIG5vdCBjbGVhciwgcGxlYXNlIGhlbHAgdXMgaW1wcm92ZSB0aGUgd29yZGluZy4N Cg0KVGhhbmtzIGFuZCByZWdhcmRzLA0KRGFubnkgDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpu b3JlcGx5QGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDEsIDIwMTkgMTY6MDMN ClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLWRtbS1vbmRlbWFu ZC1tb2JpbGl0eUBpZXRmLm9yZzsgRGFwZW5nIExpdSA8bWF4LmxkcEBhbGliYWJhLWluYy5jb20+ OyBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPjsgZG1tLWNoYWlyc0BpZXRmLm9y Zzsgc2d1bmRhdmVAY2lzY28uY29tOyBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IE1pcmphIEvDvGhs ZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQtbW9iaWxpdHkt MTg6ICh3aXRoIENPTU1FTlQpDQoNCk1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWRtbS1vbmRlbWFuZC1tb2Jp bGl0eS0xODogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Lg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtZG1tLW9uZGVtYW5kLW1vYmlsaXR5Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVO VDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IGRpc2N1c3MuIFNv cnJ5IGZvciB0aGUgbG9uZyBkZWxheSBvbiBteSBzaWRlIQ0KDQpIZXJlIGlzIG15IG9sZCAgY29t bWVudCBzdGlsbDoNCg0KUGxlYXNlIGFsc28gbm90ZSB0aGF0IGFkZHJlc3MgbW9iaWxpdHkgaXMg YWN0dWFsbHkgbW9yZSBhIHRyYW5zcG9ydCBxdWVzdGlvbiB0aGF0IGFuIGFwcGxpY2F0aW9uIGxh eWVyIHF1ZXN0aW9uLiBGb3IgVENQIHNlc3Npb24tbGFzdGluZyBhZGRyZXNzZXMgd2lsbCBhbHdh eXMgYmUgbW9yZSBlZmZpY2llbnQgaWYgYXZhaWxhYmxlIHdoaWxlIGFuIGFwcGxpY2F0aW9uIHVz aW5nIFRDUCB3aWxsIGFsd2F5cyBuZWVkIHRvIGNvdmVyIHRoZSBjYXNlIHdoZXJlIGFuIFRDUCBj b25uZWN0aW9uIGZhaWxzIG9yIGlzIGludGVycnVwdGVkIGFuZCB0aGVyZWZvcmUgdGhlIGFwcGxp Y2F0aW9uIG5lZWRzIHRvIHJlY29ubmVjdC4gSG93ZXZlciwgaW4gY29udHJhc3QgUVVJQyBzdXBw b3J0cyBJUCBhZGRyZXNzIG1vYmlsaXR5IGFuZCB3aWxsIHN1cnZpdmUgY2hhbmdpbmcgSVAgYWRk cmVzc2VzLiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGFsc28gY2xhcmlmaWVkIGluIHRoZSBkcmFm dCBhbmQgaXQgc2hvdWxkIGJlIGRvdWJsZS1jaGVjayBpZiB0aGUgdXNlIG9mIHRoZSB3b3JkIGFw cGxpY2F0aW9uIGlzIGFsd2F5cyBjb3JyZWN0IG9yIGlmIGl0IHNob3VsZCBiZSByZXBsYWNlZCBz b21ldGltZXMgd2l0aCBlLmcuIHRyYW5zcG9ydCBzeXN0ZW0gb3IgYSBtb3JlIGdlbmVyYWwgdGVy bS4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdy b3VwIG9mIGNvbXBhbmllcwoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg== From nobody Fri Aug 2 00:23:30 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB33120144; Fri, 2 Aug 2019 00:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 7XCE7Z3_pn0c; Fri, 2 Aug 2019 00:23:18 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 EA360120137; Fri, 2 Aug 2019 00:23:17 -0700 (PDT) Received: from 200116b82ca3b800ec42108fea3dd2bf.dip.versatel-1u1.de ([2001:16b8:2ca3:b800:ec42:108f:ea3d:d2bf]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1htRu7-0006F1-FP; Fri, 02 Aug 2019 09:23:07 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 2 Aug 2019 09:23:05 +0200 Cc: "draft-ietf-dmm-ondemand-mobility@ietf.org" , Dapeng Liu , Sri Gundavelli , "dmm-chairs@ietf.org" , "dmm@ietf.org" , The IESG , Suresh Krishnan , "Satoru Matsushima (satoru.matsushima@gmail.com)" Content-Transfer-Encoding: quoted-printable Message-Id: <13AEEC59-B76E-4D25-9BBD-EE0E9DFB269C@kuehlewind.net> References: <156466455152.19187.16688460554713358200.idtracker@ietfa.amsl.com> To: "Moses, Danny" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564730598;1fe8256c; X-HE-SMSGID: 1htRu7-0006F1-FP Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dmm-ondemand-mobility-18=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 07:23:22 -0000 Hi Moses, First this was only a comment from my side and not a discuss point. So = it would be good if you can double-check the wording but there is = probably not more to do. However, let me give some more background on my point. There are also = mobility solutions in the transport layer. QUIC can migrate to a new IP = address without opening a new connection (so basically without changing = the socket); MPTCP can use multiple IP addresses and as such also = dynamically open and close TCP connections, however, for the application = this looks like one connection/it=E2=80=99s one socket.=20 As you said below this is a mainly an interface question, however, I = just wanted to make sure that you have in mind that mobility not always = means to close a socket and open a new one. Mirja > On 1. Aug 2019, at 19:48, Moses, Danny wrote: >=20 > Hi Again, > Regarding your clarification about mobility being better served by the = transport layer versus the application layer. >=20 > This work is not about trying to find a better or more efficient way = to handle mobility while preserving the transport connection. It is = about enabling applications to indicate whether or not they need this = service, which is provided automatically and transparently in some = mobile network implementations (like cellular networks). >=20 > Take, for example, the a video browser app. Since it is buffering = parts of the video, it can close an existing socket and open a new one = with different attributes, without any user-experience degradation. This = could be useful when, as a result of a host moving to a different place = that has a different (closer) instance of the video server. A switch to = the new video server instance requires that the video browser is aware = of the mobility event and is able to locate a different server. If the = IP connection is preserved (by tunneling or any other way), the video = browser will stay connected to the original server and the = quality-of-experience might be affected. This is an example for a = Graceful-replacement service that is more appropriate than the = Session-lasting service.=20 >=20 > Another question you had was to whether the word 'application' is = always correct. I cannot commit to 'always', but this work was designed = to enable applications to convey their service needs. A transport layer = cannot know the abilities of the different applications to cope with = source IP address changes, only applications know that. In addition, = several applications can execute concurrently, each with different = needs. So the flexibility of selecting the service type should be = per-application, or even, per-socket, as application may use more than = one socket.=20 >=20 > We tried to convey both these points in the document. If you think = this is not clear, please help us improve the wording. >=20 > Thanks and regards, > Danny=20 >=20 >=20 >=20 > -----Original Message----- > From: Mirja K=C3=BChlewind via Datatracker [mailto:noreply@ietf.org]=20= > Sent: Thursday, August 01, 2019 16:03 > To: The IESG > Cc: draft-ietf-dmm-ondemand-mobility@ietf.org; Dapeng Liu = ; Sri Gundavelli ; = dmm-chairs@ietf.org; sgundave@cisco.com; dmm@ietf.org > Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-dmm-ondemand-mobility-18: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dmm-ondemand-mobility-18: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for addressing my discuss. Sorry for the long delay on my side! >=20 > Here is my old comment still: >=20 > Please also note that address mobility is actually more a transport = question that an application layer question. For TCP session-lasting = addresses will always be more efficient if available while an = application using TCP will always need to cover the case where an TCP = connection fails or is interrupted and therefore the application needs = to reconnect. However, in contrast QUIC supports IP address mobility and = will survive changing IP addresses. I think that should be also = clarified in the draft and it should be double-check if the use of the = word application is always correct or if it should be replaced sometimes = with e.g. transport system or a more general term. >=20 >=20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > 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 Wed Aug 7 07:30:56 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EAF12004F; Wed, 7 Aug 2019 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y3PlQQi6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KXGRb0Ky 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 FO21npsN-1AE; Wed, 7 Aug 2019 07:30:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7489412002E; Wed, 7 Aug 2019 07:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1270; q=dns/txt; s=iport; t=1565188252; x=1566397852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=diPwaHh+93Kkrjs0R6J7r/T7GUkCnEpILk/K23QFcmE=; b=Y3PlQQi6+w1Fs6OaXIHiUOPf2kWZi1WFEe6WSxtDgemcKlt32uiQAO+b BHKS9PkUmvUHMNvpT5Who5ax6knY9u8ERpLfDuFQn7ErezWorDT5VM9Xi K/APlsHY7Pw6ZwHF3A3nRLO084WU7WQzKCvybcnnGiN0gqztEY7FIVKIp I=; IronPort-PHdr: =?us-ascii?q?9a23=3A1kPuGh+vfn2W+f9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdWKFEv3JeDnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAABx30pd/5ldJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgURQA21VIAQLKgqHWwOEUoZhmjiBLhSBEANUCQEBAQwBASM?= =?us-ascii?q?KAgEBhD8CglIjNAkOAQQBAQQBAQMBCm2FJwELhUsCAQMSLgEBNwEPAgEILQ4?= =?us-ascii?q?LMiUCBA4FIoMBgWoDHQECDKAJAoE4iGCCI4J6AQEFgUdBgwYYghQDBoE0AYt?= =?us-ascii?q?jF4FAP4ERgxI+gReBSgIDAYEYgQSFAiKVEJYgCQKCHIZdjUYbmDKNTYdakBo?= =?us-ascii?q?CBAIEBQIOAQEFgVA4gVhwFYMngkI3gzqFFIU/coEpjFwBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="scan'208";a="302797844" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 14:30:49 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x77EUmlD020646 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 14:30:49 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 09:30:48 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 09:30:48 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 09:30:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xgt5l0zOjCj5q8G9cdJWWDKrX4K7hm+0EIyRZH9FcmSNP25UGPhl4XbXYY6BtYw3TQEMpIRX6/dvA4YswrsN5hCkgUXbQeMx0tIwbg4cGo19pZVPyBY4FUvuSd2hVKwb6pA78jw8jBC3ukXrV4aWXeaEd+9Z1LugV6NgJaYONlrE486j7jbm0dioJOVXYo2NI3RajEAydVzLTJDHguRIoYOP9elJe7FjwhFg+Z70hOh28LSmcFloaA35pC58XdX1Afg6qFIP6kZPjSAYQJQnBNcPVDvBO61iTGgyvO3UpOlOdP/urILZEbqHOj41w3qhse2xG8ZNs2YYWQMYLz9Wqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i0tPRmKECbz2Aa/6/JZu7nUMKd8Gqm7t3PCKz5Gp+e8=; b=dGy1yn8iyRCnz8WzBUdP4ExHR5/GjvoWIlrnCmM3Aau7X4xvsJgG+UNca2xAfCxhMvjJc5MWkQySukaqQ5B/YTSjmwxYqOvAh/U8sDRqiSPctuYbOmmEBQU6jB2bVDtUnf2J3e8tNjowPpW/SRKXHAxPQE+58FhTXi/63C8By5TAJTq2xY+J7It1TgpHKUZOiEGeItpUvEoqRBL6/58JXRgo7e1+X99GkzIAXW1PhdFluKZ4MXxEnATkH26uLHgruq73QYzNBqfzFWtWeszPyCyIOktYPMntlz6VcLd+dIDjTuctU/eGQcnTtlgDPDfd07B01xP+MVHXdx8pe8a0hQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i0tPRmKECbz2Aa/6/JZu7nUMKd8Gqm7t3PCKz5Gp+e8=; b=KXGRb0KyFY/MNA3rVjg7BioHiosrySP9Srm5ZoAC0wxAQoL3SovMYhKCXRSG4VQeyZ1djXU5haX4OC5bg7Ng9ffz+1MwitNNQCFZvkB93ROth2tYjWUtLXQMTrIGeZpQPP05n6uVTaABdBIzERKxslOVuuWG9ev/jCqBK28Pw+c= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3605.namprd11.prod.outlook.com (20.178.206.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.14; Wed, 7 Aug 2019 14:29:29 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3d73:9b60:6c26:2d0c]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::3d73:9b60:6c26:2d0c%6]) with mapi id 15.20.2136.018; Wed, 7 Aug 2019 14:29:29 +0000 From: "Sri Gundavelli (sgundave)" To: "draft-ietf-dmm-ondemand-mobility@ietf.org" CC: "dmm@ietf.org" Thread-Topic: Document Action: 'On Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-mobility-18.txt) Thread-Index: AQHVTSyFcD719MCnq0K8JCj6WJ5sXg== Date: Wed, 7 Aug 2019 14:29:29 +0000 Message-ID: References: <156512493283.27319.10431251613678907464.idtracker@ietfa.amsl.com> In-Reply-To: <156512493283.27319.10431251613678907464.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [128.107.241.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3cf6e6c3-768b-4e79-1c92-08d71b43a81d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3605; x-ms-traffictypediagnostic: BYAPR11MB3605: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(366004)(136003)(39860400002)(346002)(189003)(199004)(81166006)(478600001)(25786009)(6246003)(71190400001)(81156014)(36756003)(71200400001)(99286004)(5660300002)(6306002)(7736002)(305945005)(8676002)(68736007)(76176011)(8936002)(66574012)(6916009)(3846002)(6116002)(2351001)(2501003)(64756008)(66446008)(66476007)(53546011)(6506007)(66556008)(66946007)(4326008)(26005)(229853002)(58126008)(186003)(476003)(6486002)(66066001)(102836004)(53936002)(2906002)(76116006)(316002)(450100002)(2616005)(6512007)(86362001)(14444005)(5640700003)(6436002)(256004)(11346002)(486006)(446003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3605; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: axAtEh89boZDbL9iTOx6CmSuxzt/fEleajn9+KrmfRW5XRmMOIJBrpDdTqmOaN3OgUKbAYej1zY+uRXWRRj07foCpRNo9BJ6IFNQhS5lXh6oaZyS9l19FNu/VyEr5fo3KW0d51VBMw8vk1v86sycoCigChjizI7rRmFaIgQMDTAHq1fA/rYDgunMaCKqy2Z6eKYpL0Tb84d3P3iPMzA0jbZQuRfVbyQQabzKAjIaSsNWrp5+4zX+RRUJhkN5CeBLrhp66ExaVqWxcNaE5QiD+Bo4BZkYuahqecqvVIrFzyfmedHeGxw1jo+oM6QL4v7RLKpDfOpQhHsyOmkGdSWu/u5ZHRV7sRhRgh0/VOOQcXJ+JcEpJ63pBvDTMV4Eusanu94aWxqkZjTQ4cMc3LTZb8XPN8tazXKs5nb+Qo4UJtU= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3cf6e6c3-768b-4e79-1c92-08d71b43a81d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 14:29:29.0914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sgundave@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3605 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [DMM] Document Action: 'On Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-mobility-18.txt) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 14:30:55 -0000 Congrats Danny, Seil and all. Thanks for all your efforts. Sri On 8/6/19, 1:55 PM, "The IESG" wrote: >The IESG has approved the following document: >- 'On Demand Mobility Management' > (draft-ietf-dmm-ondemand-mobility-18.txt) as Informational RFC > >This document is the product of the Distributed Mobility Management >Working >Group. > >The IESG contact persons are =C9ric Vyncke and Suresh Krishnan. > >A URL of this Internet Draft is: >https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ > > > > >Technical Summary > > This document describes a mechanism for taking the application needs >into account in selectively > providing IP session continuity and IP address reachability on a >per-socket basis. > >Working Group Summary > > There were some debates in the working group regarding the > defined types of IP Addresses defined in this document, but those are >now resolved. > >Document Quality > > This document has been discussed for a long time in the WG and has >received multiple reviews from within the WG as well as outside. > >Personnel > > Who is the Document Shepherd for this document? Sri Gundavelli > Responsible Area Director? Suresh Krishnan From nobody Thu Aug 8 01:15:43 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E21120024; Thu, 8 Aug 2019 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 x7amtu-zHG6g; Thu, 8 Aug 2019 01:15:39 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 92F471200E3; Thu, 8 Aug 2019 01:15:39 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2019 01:13:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,360,1559545200"; d="scan'208";a="168909649" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga008.jf.intel.com with ESMTP; 08 Aug 2019 01:13:32 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 8 Aug 2019 01:13:31 -0700 Received: from hasmsx113.ger.corp.intel.com (10.184.198.64) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 8 Aug 2019 01:13:31 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.52]) by HASMSX113.ger.corp.intel.com ([169.254.13.63]) with mapi id 14.03.0439.000; Thu, 8 Aug 2019 11:13:28 +0300 From: "Moses, Danny" To: "Sri Gundavelli (sgundave)" , "draft-ietf-dmm-ondemand-mobility@ietf.org" CC: "dmm@ietf.org" , "alper.yegin@actility.com" Thread-Topic: Document Action: 'On Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-mobility-18.txt) Thread-Index: AQHVTJlTQYUm1Tw4lkaKQmVGnz9Y4KbvjY2AgAFbC/A= Date: Thu, 8 Aug 2019 08:13:27 +0000 Message-ID: References: <156512493283.27319.10431251613678907464.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYmU4NDkwYzItODkyYy00MDE5LThiMTUtMzZjOTc1Zjk2NGI0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieTJwWnMwcEpkYU1waVUwOE15enp6QitVOWJEZzRcL2Y0MTVFYklDU2NxRWM0NXluRVwvR3J0bHZITGk5M3hWeWlSIn0= dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Document Action: 'On Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-mobility-18.txt) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 08:15:41 -0000 Hi, And also the chairs of DMM and Suresh for extensive support and useful guid= ance. Thanks and regards, Danny -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] = Sent: Wednesday, August 07, 2019 17:29 To: draft-ietf-dmm-ondemand-mobility@ietf.org Cc: dmm@ietf.org Subject: Re: Document Action: 'On Demand Mobility Management' to Informatio= nal RFC (draft-ietf-dmm-ondemand-mobility-18.txt) Congrats Danny, Seil and all. Thanks for all your efforts. Sri On 8/6/19, 1:55 PM, "The IESG" wrote: >The IESG has approved the following document: >- 'On Demand Mobility Management' > (draft-ietf-dmm-ondemand-mobility-18.txt) as Informational RFC > >This document is the product of the Distributed Mobility Management = >Working Group. > >The IESG contact persons are =C9ric Vyncke and Suresh Krishnan. > >A URL of this Internet Draft is: >https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ > > > > >Technical Summary > > This document describes a mechanism for taking the application needs = >into account in selectively > providing IP session continuity and IP address reachability on a = >per-socket basis. > >Working Group Summary > > There were some debates in the working group regarding the > defined types of IP Addresses defined in this document, but those are = >now resolved. > >Document Quality > > This document has been discussed for a long time in the WG and has = >received multiple reviews from within the WG as well as outside. > >Personnel > > Who is the Document Shepherd for this document? Sri Gundavelli > Responsible Area Director? Suresh Krishnan --------------------------------------------------------------------- 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 Aug 9 00:47:59 2019 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597831200A4 for ; Fri, 9 Aug 2019 00:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 HC7I-4W31RoT for ; Fri, 9 Aug 2019 00:47:55 -0700 (PDT) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 1D241120058 for ; Fri, 9 Aug 2019 00:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1565336874; bh=vziafDB6oebLt/3DEd+X1RLdMHA54cl6y7crHdIBqYg=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=F+H/J9nbWSn8ViRT7mGWwBT7CPGYNgJ8RPl7NP3jME+AgcuqniLIHKaAlb8QDuYtOf7StAyxsz9fpLHmiCJpndvJBmdwk3Rmd3ew3xA4W/PNZd79SCJ2FnF/9JPrKdw76I5CFb/xPTnterE75KQIyWAYRR2TLVSNTFf3i69yc2WCNu3QgcaeU+rjrOM/cyzmKH1MmyY7xCnfItC6Ut97ZlOpBGjtqupcC2rHMASL68XTUl56fNyIWowwGfWieYv/1vbMs1q9jWOIbT6A7L1kLMC6HE+9lhZwA544Om+tB5kICq1/QYFe3PlQPjQgZ1MPHwAaJ4dtqxKMUIUG9xOESQ== X-YMail-OSG: qbrO4o8VM1mjm0q9pR5t97beBA5YLhGwW61AYTKK0G4cnCYiN_OuHlHhn.bYSIb 9xv_79hjtZgEzMt_3nrnq2mBfYybDL0I6DUi9_ncmK5y6nGj1UYzW1BvsKTFl2tLWLsiuf4g5KhN 8fADaZpEtqRL6rgiCLhKG9BRsMbH1c_hohiWBySO_kXswrIgnW_Vd5VQ4ZYt8_P1Tf2c28KpGCeL EueZ9Is0PJK.hxwilh7UiwEVkypqszrbLJwfybohGNwfGUmJvTSyMmAQZCpl5J1cdYggJXD._vOu NhyIMcqoHWTqWZoEiEJuLzPz8tFvWAe3y8dmi1psXkWxi5WvJMemmb_ozKzROFQwdcxsFsFZkmTb jH2CGUl9DzaDeLVN_53Y3kEn1.W2JIjNTMwJVq3bSuRUds_3QEtob470lyk6lELc9cKXqysNvpRv E99hwWsIaR4a0WVt0OnVOvKU3Sf37J.2jzp1oi4vMG92jU2CIhYrWxoF8MuTRGWMd4kbp7NlW8_F zB2oZeq0bhere6TrcqOfO7sLG4oNWZhbkpH81FxZxssvOSaQOEB_KxBvqOLcQZGX6szuKraoMO7z J50jbbOH.Cz61msSF9VZhe9xSyrDRaD9HL4qVrMHdcDmjXCez9767twkVMpWRbRLXSUdi7LEMhVu e0DepkUuvo0cQ1AZBSaLH46DgUmB.MGRXgtxVCqEjtj1CKXwPktvoNdt7AQpCK3VR8uGcGn6GeP0 w61q4Z6KvnhNHAGxsdZhypgrvfoJ8obqDDlvtwfecVWCX4K5gLK7VRmVVqZPy8SvxAGR6j7.YtmZ LUkhsUp93cX3oD3c6_yJBKQ89ivk_LkJqvcNFBMrCtm1ISnGxHcMRUdgAvRXUH18bJZib7wLa_4I eOKOu7v5u0PAUKSAjsbYmsLmR9LXxhqqYbQSBzhP4LKjghEA9PA5w8X7vG79sZZRNmoagQrEnWCk JQdQOeflL.kV7QEmMtaWmGKsHveEvS9IWvfe81HmmBL0JtFrVVQoQn4QjNp0iCovmW.g4zTN2LhY q0OpE.0iFibbm8dCg2Z4g7znwlEeNwCOlbELlxTeO4n37cC6WBfu9.fI1LZ.kuR4uT.YBzVxgOZl L3XmKjOBs_q3Dy.PHpKrBB.bOhQvN9RBq_OvfytHx19o6gx5ytWxmR0kwfBcg.TpnQ6AZekPPOdP GHWdDc_8S6_c3f8sD4tHeSmtebcvtMVjCeQb0xe4RW87MAlJ.7A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 9 Aug 2019 07:47:54 +0000 Date: Fri, 9 Aug 2019 07:47:24 +0000 (UTC) From: Hugh Mote To: dmm@ietf.org Message-ID: <67482111.3151498.1565336844761@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3151497_1352926080.1565336844759" X-Mailer: WebService/1.1.14097 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Firefox/68.0 Archived-At: Subject: Re: [DMM] dmm Digest, Vol 102, Issue 5 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 07:47:57 -0000 ------=_Part_3151497_1352926080.1565336844759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please delete my e-mail address from all IETF activities and mailing lists= , etc. - I have retired! Many thanks - Keep up the good work! Regards, Hugh MOTE P.S. I have tried a number of times to follow your instructions to delete m= y address 'hugh.mote@aeroconsult-tls.com' from your mailing lists without a= ny success ....=C2=A0=20 On Thursday, August 8, 2019, 9:00:14 PM GMT+2, w= rote: =20 =20 Send dmm mailing list submissions to =C2=A0=C2=A0=C2=A0 dmm@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/dmm or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 dmm-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 dmm-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dmm digest..." Today's Topics: =C2=A0 1. Re: Document Action: 'On Demand Mobility Management' to =C2=A0 =C2=A0 =C2=A0 Informational RFC (draft-ietf-dmm-ondemand-mobility-18= .txt) =C2=A0 =C2=A0 =C2=A0 (Moses, Danny) Hi, And also the chairs of DMM and Suresh for extensive support and useful guid= ance. Thanks and regards, Danny -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]=20 Sent: Wednesday, August 07, 2019 17:29 To: draft-ietf-dmm-ondemand-mobility@ietf.org Cc: dmm@ietf.org Subject: Re: Document Action: 'On Demand Mobility Management' to Informatio= nal RFC (draft-ietf-dmm-ondemand-mobility-18.txt) Congrats Danny, Seil and all. Thanks for all your efforts. Sri On 8/6/19, 1:55 PM, "The IESG" wrote: >The IESG has approved the following document: >- 'On Demand Mobility Management' >=C2=A0 (draft-ietf-dmm-ondemand-mobility-18.txt) as Informational RFC > >This document is the product of the Distributed Mobility Management=20 >Working Group. > >The IESG contact persons are =C3=89ric Vyncke and Suresh Krishnan. > >A URL of this Internet Draft is: >https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ > > > > >Technical Summary > >=C2=A0 This document describes a mechanism for taking the application need= s=20 >into account in selectively >=C2=A0 providing IP session continuity and IP address reachability on a=20 >per-socket basis. > >Working Group Summary > >=C2=A0 There were some debates in the working group regarding the >=C2=A0 defined types of IP Addresses defined in this document, but those a= re=20 >now resolved. > >Document Quality > >=C2=A0 This document has been discussed for a long time in the WG and has= =20 >received multiple reviews from within the WG as well as outside. > >Personnel > >=C2=A0 Who is the Document Shepherd for this document?=C2=A0 Sri Gundavell= i >=C2=A0 Responsible Area Director?=C2=A0 Suresh Krishnan --------------------------------------------------------------------- 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm =20 ------=_Part_3151497_1352926080.1565336844759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please delete my e-mail addr= ess from all IETF activities and mailing lists, etc. - I have retired!

Many thanks - Keep up the good work!

Regard= s, Hugh MOTE

P.S. I have tried a number of times to follow your instructions to delete = my address 'hugh.mote@aeroconsult-tls.com' from your mailing lists without = any success .... 
=20
=20
On Thursday, August 8, 2019, 9:00:14 PM GMT+2, <dmm= -request@ietf.org> wrote:


Send dmm mailing list submissions to<= br>

To subscribe or unsubscribe via the World Wide= Web, visit
or, via email, send a me= ssage with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject li= ne so it is more specific
than "Re: Contents of d= mm digest..."
Today's Topics:

  1. Re: Document Actio= n: 'On Demand Mobility Management' to
      Informational= RFC (draft-ietf-dmm-ondemand-mobility-18.txt)
      (Mos= es, Danny)
Hi,
And also the chairs of DMM and Sures= h for extensive support and useful guidance.

Thanks and regards,
= Danny

-----Original Message-----
From: Sri Gundavelli (sgundave) = [mailto:sgundave@cisco.com]
Sent: Wednesday, August 07, 2019 17:29=
To: draft-ietf-dmm-ondem= and-mobility@ietf.org
Cc: dmm@ietf.org
Subject: Re: Document Action: 'On= Demand Mobility Management' to Informational RFC (draft-ietf-dmm-ondemand-= mobility-18.txt)

Congrats Danny, Seil and all. Thanks for all your e= fforts.



Sri

On 8/6/19, 1:55 PM, "The IESG" <iesg-secretary@ietf.org> wrote:

>The IESG has approve= d the following document:
>- 'On Demand Mobility Management'
>&= nbsp; (draft-ietf-dmm-ondemand-mobility-18.txt) as Informational RFC
>= ;
>This document is the product of the Distributed Mobility Managemen= t
>Working Group.
>
>The IESG contact persons are =C3=89= ric Vyncke and Suresh Krishnan.
>
>A URL of this Internet Draft= is:
>https://datatracker.ietf.org/doc/draft-ie= tf-dmm-ondemand-mobility/
>
>
>
>
>Techni= cal Summary
>
>  This document describes a mechanism for = taking the application needs
>into account in selectively
>&nb= sp; providing IP session continuity and IP address reachability on a
&= gt;per-socket basis.
>
>Working Group Summary
>
>&n= bsp; There were some debates in the working group regarding the
>&nbs= p; defined types of IP Addresses defined in this document, but those are >now resolved.
>
>Document Quality
>
>  T= his document has been discussed for a long time in the WG and has
>r= eceived multiple reviews from within the WG as well as outside.
>
= >Personnel
>
>  Who is the Document Shepherd for this = document?  Sri Gundavelli
>  Responsible Area Director?&nb= sp; Suresh Krishnan

------------------------------------------------= ---------------------
A member of the Intel Corporation group of compani= es

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


__= _____________________________________________
dmm mailing list
dmm@ietf.org<= br>= https://www.ietf.org/mailman/listinfo/dmm
------=_Part_3151497_1352926080.1565336844759--