From mext-bounces@ietf.org Mon Oct 01 04:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXM-0005Mc-8O; Mon, 01 Oct 2007 04:21:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcGXL-0005MX-Kh for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcGXK-0003Ff-L6 for mext@ietf.org; Mon, 01 Oct 2007 04:21:55 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 644001986B9; Mon, 1 Oct 2007 11:21:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 04009198658; Mon, 1 Oct 2007 11:21:52 +0300 (EEST) Message-ID: <4700A05C.3070905@piuha.net> Date: Mon, 01 Oct 2007 10:23:08 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni asked me to AD sponsor this document. Here's my review. I support the extension proposed in the document, but there are a number of issues relating to how these values are defaulted, tight coupling to MN-NAI, whether these options appear in the first or all messages, and a few other things. I expect a revised ID. I proposed text for some of the issues that below, in some cases you need to still work on it. Substantial: > o In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > The fact that there is no standard "default" and the proliferation of various operator conventions and policies has caused significant problems in GPRS and UMTS data access. I would not like to repeat this mistake here. One of way of avoiding this problem is to mandate that you do have a default. Suggested edit: OLD: In absence of the Service Selection option the home agent may provide, based on operator policies, a default service. For example, a plain Internet access could be an operator's default mobility service. NEW: In absence of the Service Selection option the home agent MUST act as if the default service, plain Internet access had been requested. There is no absolute requirement that this default service be allowed to all customers, but it is highly RECOMMENDED in order to avoid having normal users employ operator-specific configuration values in order to get basic service. > The Service Selection option should be used in > combination with the Mobile Node Identifier option during the initial > Binding Update at the beginning of the mobility session. I do not see a reason to make this MNID specific. Also, the concept of a mobility session isn't necessarily well-defined, if home agents can reboot, etc. Reformulated: OLD: The Service Selection option should be used in combination with the Mobile Node Identifier option during the initial Binding Update at the beginning of the mobility session. NEW: The Service Selection option should be used in every Binding Update that makes a registration to the home agent. And then you should probably add text somewhere to talk about the case where the service id suddenly changes and this no longer fits with the home address allocation, etc. > The Service Selection mobility option can be included in any Mobile > IPv6 Mobility Header message. This is inconsistent with Section 2. I'm not sure I see a need for this option to appear in other messages than the BU. Please reformulate. > This option MAY be included in the initial Binding Update message > when registering to a home agent at the beginning of the mobility > session. The MN-NAI option SHOULD be included in the Binding Update > message when the Service Selection option is used. Sending the > Service Selection option in any Binding Update message is not > prohibited. See above for tight coupling to MN-NAI option or the initial BUs. > It should be noted that sending this option to > correspondent nodes makes little or no sense unless the home agent > and the correspondent nodes share the same knowledge of provided > mobility services. Be more specific. SHOULD NOT be sent? Presumably, depending on what kind of service you got, you will or will be able to reach the CNs directly. In either case, it should be OK to attempt RO. > o Identifier: A variable length service identifier string used to > identify the requested service. The Identifier string is encoded > as a host name or a fully qualified domain name as defined in [4] > and [5]. The Identifier MAY be resolveable by DNS. > > 'internet', 'internet.example.com', 'voip.example.com' and > 'voip.companyxyz.example.com' are valid examples of Service > Selection option Identifier strings. At minimum the Identifier > must be unique among the home agents the mobile node is authorized > to register to. > Something like "internet" would not be unique among the home agents, if I the mobile node is allowed to use two different operators, for instance. Are there existing APN conventions in GPRS networks that are based on domain names? Or are you inventing a convention here? Another alternative might be to just say "UTF-8" and that the value is up to a local policy. And unique within a particular home agent. > The Service > Selection option is intended to be used with the MN-NAI option, but > it is also possible to use Home Address to identify the mobile node > as defined in [1]. See above about the coupling to MN-NAI. Editorial: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that > provides a flexible way to identify mobile nodes using other > identifiers than IPv6 addresses. Example of such identifier is a > Network Access Identifier (NAI) [2]. There are multiple ways of identifying the mobile node, and the NAI is just one of them. Suggested rewrite: OLD: Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that provides a flexible way to identify mobile nodes using other identifiers than IPv6 addresses. Example of such identifier is a Network Access Identifier (NAI) [2]. NEW: Mobile IPv6 [1] can identify mobile nodes in various ways, including home addresses [1], Network Access Identifiers (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. > The service selection may affect home > agent routing decisions and Home Address or Home Network Prefix > assignment policies. Or firewall and security policies. Suggested edit: OLD: The service selection may affect home agent routing decisions and Home Address or Home Network Prefix assignment policies. NEW: The service selection may affect home agent routing decisions, Home Address or Home Network Prefix assignment policies, firewall settings, and security policies. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 01 13:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm7-00085v-VL; Mon, 01 Oct 2007 13:09:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcOm6-000828-Dq for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcOm6-0007vd-1G for mext@ietf.org; Mon, 01 Oct 2007 13:09:42 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 10:09:41 -0700 Message-ID: <470129D4.8090403@azairenet.com> Date: Mon, 01 Oct 2007 10:09:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 17:09:41.0325 (UTC) FILETIME=[DAFFCFD0:01C8044D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, A couple of comments. Jari Arkko wrote: >> o In absence of the Service Selection option the home agent may >> provide, based on operator policies, a default service. For >> example, a plain Internet access could be an operator's default >> mobility service. >> > > The fact that there is no standard "default" and the proliferation > of various operator conventions and policies has caused significant > problems in GPRS and UMTS data access. I would not like to repeat > this mistake here. > > One of way of avoiding this problem is to mandate that you do > have a default. Suggested edit: > > OLD: > In absence of the Service Selection option the home agent may > provide, based on operator policies, a default service. For > example, a plain Internet access could be an operator's default > mobility service. > NEW: > In absence of the Service Selection option the home agent MUST > act as if the default service, plain Internet access had been > requested. There is no absolute requirement that this default service be > allowed to all customers, but it is highly RECOMMENDED in > order to avoid having normal users employ operator-specific > configuration values in order to get basic service. This is a good idea. Completely agree. >> The Service Selection mobility option can be included in any Mobile >> IPv6 Mobility Header message. > This is inconsistent with Section 2. I'm not sure I see a need > for this option to appear in other messages than the BU. > Please reformulate. We should probably not say anything here. There is no need to restrict it to the Binding Update and at the same time no need to claim that it can be used in any mobility header message. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon Oct 01 16:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCm-00057a-Bl; Mon, 01 Oct 2007 16:49:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcSCl-000579-2d for mext@ietf.org; Mon, 01 Oct 2007 16:49:27 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcSCk-0005Q5-Nj for mext@ietf.org; Mon, 01 Oct 2007 16:49:26 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1887E198677; Mon, 1 Oct 2007 23:49:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ACD91198646; Mon, 1 Oct 2007 23:49:25 +0300 (EEST) Message-ID: <47015D55.1050602@piuha.net> Date: Mon, 01 Oct 2007 23:49:25 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <470129D4.8090403@azairenet.com> In-Reply-To: <470129D4.8090403@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Vijay, >> This is inconsistent with Section 2. I'm not sure I see a need >> for this option to appear in other messages than the BU. >> Please reformulate. > > We should probably not say anything here. There is no need to restrict > it to the Binding Update and at the same time no need to claim that it > can be used in any mobility header message. I think you need to define what the behaviour should be when you receive this. I'm not sure its obvious. What should you do if you receive this in a BA or BE, for instance? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 02 04:20:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvI-0005rF-61; Tue, 02 Oct 2007 04:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IccvH-0005kD-5S for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iccv6-0001Iz-8K for mext@ietf.org; Tue, 02 Oct 2007 04:16:07 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 10:15:41 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 10:15:40 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <4700A05C.3070905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgEBCFn7W9wurwISgKpm9fN88A1ZgAvuKnQ References: <4700A05C.3070905@piuha.net> From: To: X-OriginalArrivalTime: 02 Oct 2007 08:15:41.0330 (UTC) FILETIME=[6C164F20:01C804CC] X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Hi Jari, Thanks for the extensive review. Some comments inline. > Sent: Monday, October 01, 2007 10:23 AM >=20 > Jouni asked me to AD sponsor this document. Here's my review. >=20 > I support the extension proposed in the document, but there=20 > are a number of issues relating to how these values are=20 > defaulted, tight coupling to MN-NAI, whether these options=20 > appear in the first or all messages, and a few other things. >=20 > I expect a revised ID. I proposed text for some of the issues=20 > that below, in some cases you need to still work on it. >=20 > Substantial: >=20 > > o In absence of the Service Selection option the home agent may > > provide, based on operator policies, a default service. For > > example, a plain Internet access could be an=20 > operator's default > > mobility service. > > =20 >=20 > The fact that there is no standard "default" and the=20 > proliferation of various operator conventions and policies=20 > has caused significant problems in GPRS and UMTS data access.=20 > I would not like to repeat this mistake here. Agree on this. This actually has given headache in several occasions e.g. in our services deployments. Dunno how we managed to repeat it in this I-D in the first place... > One of way of avoiding this problem is to mandate that you do=20 > have a default. Suggested edit: >=20 > OLD: > In absence of the Service Selection option the home agent may=20 > provide, based on operator policies, a default service. For=20 > example, a plain Internet access could be an operator's=20 > default mobility service. > NEW: > In absence of the Service Selection option the home agent=20 > MUST act as if the default service, plain Internet access had=20 > been requested. There is no absolute requirement that this=20 > default service be allowed to all customers, but it is highly=20 > RECOMMENDED in order to avoid having normal users employ=20 > operator-specific configuration values in order to get basic service. OK by me. > > The Service Selection option should be used in > > combination with the Mobile Node Identifier option=20 > during the initial > > Binding Update at the beginning of the mobility session. > I do not see a reason to make this MNID specific. Also, the=20 > concept of a mobility session isn't necessarily well-defined,=20 > if home agents can reboot, etc. Reformulated: Hmmm.. right. "should" is not exactly mandating the use of MNID. Agree on the mobility session ambiguity. > OLD: > The Service Selection option should be used in combination=20 > with the Mobile Node Identifier option during the initial=20 > Binding Update at the beginning of the mobility session. > NEW: > The Service Selection option should be used in every Binding=20 > Update that makes a registration to the home agent. OK. > And then you should probably add text somewhere to talk about=20 > the case where the service id suddenly changes and this no=20 > longer fits with the home address allocation, etc. Good point. I actually had some thoughts to write a bit about this scenario. My initial thinking was that if the service id changes mid session and the HA cannot agree with the new service, the HA would reject the binding and send back a BA with an error code indicating the administrative decision. > > The Service Selection mobility option can be included in=20 > any Mobile > > IPv6 Mobility Header message.=20 > This is inconsistent with Section 2. I'm not sure I see a=20 > need for this option to appear in other messages than the BU. > Please reformulate. Right. Agree. > > This option MAY be included in the initial Binding Update message > > when registering to a home agent at the beginning of the mobility > > session. The MN-NAI option SHOULD be included in the=20 > Binding Update > > message when the Service Selection option is used. Sending the > > Service Selection option in any Binding Update message is not > > prohibited.=20 >=20 > See above for tight coupling to MN-NAI option or the initial BUs. Ack. > > It should be noted that sending this option to > > correspondent nodes makes little or no sense unless the=20 > home agent > > and the correspondent nodes share the same knowledge of provided > > mobility services. > Be more specific. SHOULD NOT be sent? Presumably, depending=20 > on what kind of service you got, you will or will be able to=20 > reach the CNs directly. In either case, it should be OK to attempt RO. Yes, attempting RO should be ok in all cases. I should probably only say here: The service selection option SHOULD NOT be send to a correspondent node. The mobile node cannot assume that the correspondent node has any knowledge about a specific service selection done between the mobile node and the home agent. > > o Identifier: A variable length service identifier=20 > string used to > > identify the requested service. The Identifier=20 > string is encoded > > as a host name or a fully qualified domain name as=20 > defined in [4] > > and [5]. The Identifier MAY be resolveable by DNS. > > > > 'internet', 'internet.example.com', 'voip.example.com' and > > 'voip.companyxyz.example.com' are valid examples of Service > > Selection option Identifier strings. At minimum the=20 > Identifier > > must be unique among the home agents the mobile node=20 > is authorized > > to register to. > > =20 >=20 > Something like "internet" would not be unique among the home=20 > agents, if I the mobile node is allowed to use two different=20 > operators, for instance. IMHO that falls to roaming contract arrangement part and in that case something like "internet" can definitely be agreed on to be unique among operators the mobile node is allowed to roam with. Bad choice of example, I can change that. > Are there existing APN conventions in GPRS networks that are=20 > based on domain names? Or are you inventing a convention here? APNs are have two parts: the Netword Identified (NI) and the Operator Identifier (OI). The NI is mandatory e.g. plain "voip" in the above example and the optional OI is the domain name e.g. "example.com". Of cource GPRS APN domain name convention are more akward than in the above example. So no inventing a convention here. =20 > Another alternative might be to just say "UTF-8" and that the=20 > value is up to a local policy. And unique within a particular=20 > home agent. Hmmm.. could be ok. Need to think about this. > > The Service > > Selection option is intended to be used with the MN-NAI=20 > option, but > > it is also possible to use Home Address to identify the=20 > mobile node > > as defined in [1]. > See above about the coupling to MN-NAI. Ack. > Editorial: >=20 > > Mobile IPv6 [1] has a Mobile Node Identifier option=20 > (MN-NAI) [6] that > > provides a flexible way to identify mobile nodes using other > > identifiers than IPv6 addresses. Example of such identifier is a > > Network Access Identifier (NAI) [2]. > There are multiple ways of identifying the mobile node, and=20 > the NAI is just one of them. Suggested rewrite: >=20 > OLD: > Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI)=20 > [6] that provides a flexible way to identify mobile nodes=20 > using other identifiers than IPv6 addresses. Example of such=20 > identifier is a Network Access Identifier (NAI) [2]. > NEW: > Mobile IPv6 [1] can identify mobile nodes in various ways,=20 > including home addresses [1], Network Access Identifiers=20 > (NAIs) [2, 3], and credentials suitable for IKEv2 [RFC 4877]. Good. Thanks. > > The service selection may affect home > > agent routing decisions and Home Address or Home Network Prefix > > assignment policies.=20 > Or firewall and security policies. Suggested edit: >=20 > OLD: > The service selection may affect home > agent routing decisions and Home Address or Home Network=20 > Prefix assignment policies. > NEW: > The service selection may affect home > agent routing decisions, Home Address or Home Network Prefix=20 > assignment policies, firewall settings, and security policies. OK. Thanks, Cheers, Jouni >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 02 05:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7d-0000IH-M4; Tue, 02 Oct 2007 05:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ice7c-0000IC-FV for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ice7b-0005qX-Tr for mext@ietf.org; Tue, 02 Oct 2007 05:32:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CBBE3198677; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9675D198670; Tue, 2 Oct 2007 12:32:54 +0300 (EEST) Message-ID: <47021046.1070100@piuha.net> Date: Tue, 02 Oct 2007 12:32:54 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > Good point. I actually had some thoughts to write a bit about this > scenario. My initial thinking was that if the service id changes mid > session and the HA cannot agree with the new service, the HA > would reject the binding and send back a BA with an error code > indicating the administrative decision. > This is fine. > Yes, attempting RO should be ok in all cases. I should probably > only say here: > > The service selection option SHOULD NOT be send to a correspondent > node. The mobile node cannot assume that the correspondent node > has any knowledge about a specific service selection done between > the mobile node and the home agent. > Ok. >> Something like "internet" would not be unique among the home >> agents, if I the mobile node is allowed to use two different >> operators, for instance. >> > > IMHO that falls to roaming contract arrangement part and in that > case something like "internet" can definitely be agreed on to > be unique among operators the mobile node is allowed to roam > with. Bad choice of example, I can change that. > > >> Are there existing APN conventions in GPRS networks that are >> based on domain names? Or are you inventing a convention here? >> > > APNs are have two parts: the Netword Identified (NI) and the Operator > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above > example and the optional OI is the domain name e.g. "example.com". > Of cource GPRS APN domain name convention are more akward than in > the above example. So no inventing a convention here. > > >> Another alternative might be to just say "UTF-8" and that the >> value is up to a local policy. And unique within a particular >> home agent. >> > > Hmmm.. could be ok. Need to think about this. > It is still unclear to me what the best choice is. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 03 05:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01U-0006pR-2V; Wed, 03 Oct 2007 04:56:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id01S-0006GI-BK for mext@ietf.org; Wed, 03 Oct 2007 04:56:02 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id01J-0000tC-KY for mext@ietf.org; Wed, 03 Oct 2007 04:55:53 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 10:55:52 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2007 10:55:49 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <47021046.1070100@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgE1zbB1oqQt1HZTaenxFpveTI5AQAwq6vg References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> From: To: X-OriginalArrivalTime: 03 Oct 2007 08:55:52.0569 (UTC) FILETIME=[33B5EE90:01C8059B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] RE: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org > >> Are there existing APN conventions in GPRS networks that=20 > are based on=20 > >> domain names? Or are you inventing a convention here? > > > > APNs are have two parts: the Netword Identified (NI) and=20 > the Operator=20 > > Identifier (OI). The NI is mandatory e.g. plain "voip" in the above=20 > > example and the optional OI is the domain name e.g. "example.com". > > Of cource GPRS APN domain name convention are more akward=20 > than in the=20 > > above example. So no inventing a convention here. > > =20 > >> Another alternative might be to just say "UTF-8" and that=20 > the value=20 > >> is up to a local policy. And unique within a particular home agent. > > > > Hmmm.. could be ok. Need to think about this. > > =20 >=20 > It is still unclear to me what the best choice is. For a wider applicability, not just for one specific scenario, I think UTF-8 could be the way to go. Just like you proposed earlier. If some SDO or alikes need more specific definition they can do it within their own architecture specifications. Cheers,=09 jouni >=20 > Jari >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed Oct 03 05:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M2-0008TV-OU; Wed, 03 Oct 2007 05:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id0M0-0008Rq-Ki for mext@ietf.org; Wed, 03 Oct 2007 05:17:17 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id0Lv-0005VU-7Q for mext@ietf.org; Wed, 03 Oct 2007 05:17:16 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 360A619866A; Wed, 3 Oct 2007 12:17:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EA620198658; Wed, 3 Oct 2007 12:16:59 +0300 (EEST) Message-ID: <47035E0C.6000500@piuha.net> Date: Wed, 03 Oct 2007 12:17:00 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <4700A05C.3070905@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D260@SEHAN021MB.tcad.telia.se> <47021046.1070100@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D2D9@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org Subject: [MEXT] Re: AD review of draft-korhonen-mip6-service-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Jouni, > For a wider applicability, not just for one specific scenario, I > think UTF-8 could be the way to go. Just like you proposed earlier. > If some SDO or alikes need more specific definition they can do it > within their own architecture specifications. > > That would work for me. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri Oct 19 01:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXK-0007XY-J4; Fri, 19 Oct 2007 01:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IikXI-0007RI-C3 for mext@ietf.org; Fri, 19 Oct 2007 01:36:40 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IikX5-0007cG-IS for mext@ietf.org; Fri, 19 Oct 2007 01:36:33 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 07:35:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C81211.EDB278C4" Date: Fri, 19 Oct 2007 07:35:58 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D795@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-korhonen-mip6-service-04.txt Thread-Index: AcgRhw5RAzk6KPClRJe102w+RMSO7gAip/hw From: To: X-OriginalArrivalTime: 19 Oct 2007 05:35:59.0559 (UTC) FILETIME=[EDEDD570:01C81211] X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [MEXT] FW: I-D Action:draft-korhonen-mip6-service-04.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI.. The draft has now been updated based on Jari's comments. Cheers, Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, October 18, 2007 3:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-mip6-service-04.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Service Selection for Mobile IPv6 > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-mip6-service-04.txt > Pages : 7 > Date : 2007-10-18 >=20 > In some Mobile IPv6 deployments identifying the mobile node=20 > or the mobility service subscriber is not enough to=20 > distinguish between multiple services possibly provisioned to=20 > the said mobile node and its mobility service subscription. =20 > A capability to specify different services in addition to the=20 > mobile node identity can be leveraged to provide flexibility=20 > for mobility service providers on provisioning multiple=20 > services to one mobility service subscription. This document=20 > describes a Service Selection Mobility Option for both=20 > conventional Mobile IPv6 and Proxy Mobile IPv6 that is=20 > intended to assist home agents to make a specific service=20 > selection for the mobility service subscription during the=20 > binding registration procedure. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-04.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-mip6-service-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-mip6-service-04.txt Content-Disposition: attachment; filename="draft-korhonen-mip6-service-04.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfa29yaG9uZW5fbWlwNl9zZXJ2aWNlXzA0LlVSTCIN CkZpbHRlciBuYW1lOiAiRklMRSBGSUxURVI9IHVubmFtZWQ6ICoudXJsIg0K ------_=_NextPart_001_01C81211.EDB278C4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext ------_=_NextPart_001_01C81211.EDB278C4-- From mext-bounces@ietf.org Mon Oct 22 05:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1d-0000kY-A9; Mon, 22 Oct 2007 05:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iju1b-0000jP-J7 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iju1S-0007fT-56 for mext@ietf.org; Mon, 22 Oct 2007 05:56:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EDBFF198683; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 943D2198670; Mon, 22 Oct 2007 12:56:27 +0300 (EEST) Message-ID: <471C3B28.7020107@piuha.net> Date: Mon, 22 Oct 2007 08:54:48 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jouni Korhonen Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> In-Reply-To: <4700A05C.3070905@piuha.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org The new version addresses the concerns I had. Thanks. The document will now be moved forward. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 30 06:04:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnsq-0003Eu-MM; Tue, 30 Oct 2007 05:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imnso-0003Ek-PZ for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imnso-0004sW-8o for mext@ietf.org; Tue, 30 Oct 2007 05:59:38 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 10:59:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Date: Tue, 30 Oct 2007 10:59:35 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <471C3B28.7020107@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] AD review of draft-korhonen-mip6-service-03.txt Thread-Index: AcgUkdGD2EnIIVvDQumEffqsWfuUYAGSKLlg References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> From: To: X-OriginalArrivalTime: 30 Oct 2007 09:59:36.0504 (UTC) FILETIME=[941B5B80:01C81ADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: draft-korhonen-mip6-service@tools.ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org There was comment I received offline pointing out that description of the service selection option identifier in -04 does not mention DNS anymore. In -03 it read "The Identifier MAY be resolveable by DNS." I think it could be put back. The new text could be: " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the type of the skipable mobility option. Depending on the system deployment the Identifier MAY be resolveable by DNS." Any thoughts?=20 Cheers, Jouni > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, October 22, 2007 8:55 AM > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org > Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >=20 >=20 > The new version addresses the concerns I had. Thanks. The=20 > document will now be moved forward. >=20 > Jari >=20 >=20 >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue Oct 30 10:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4w-0002xV-NY; Tue, 30 Oct 2007 10:28:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ims4v-0002xC-0R for mext@ietf.org; Tue, 30 Oct 2007 10:28:25 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ims4u-0005Gi-Fn for mext@ietf.org; Tue, 30 Oct 2007 10:28:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5C390198677; Tue, 30 Oct 2007 16:28:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D1652198670; Tue, 30 Oct 2007 16:28:22 +0200 (EET) Message-ID: <47273F85.9000505@piuha.net> Date: Tue, 30 Oct 2007 16:28:21 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt References: <4700A05C.3070905@piuha.net> <471C3B28.7020107@piuha.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9261@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: draft-korhonen-mip6-service@tools.ietf.org, mext@ietf.org X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org I'm wary of specifying something might be found in DNS or might not. Also, do we have any evidence that we actually need the identifiers to be resolved by DNS? In any case, no one would turn on service for a particular domain without an agreement in place with that domain. So the box initiating a VPN tunnel simply has to have configuration for that domain, its not enough for the DNS query to succeed. Jari jouni.korhonen@teliasonera.com kirjoitti: > There was comment I received offline pointing out that description > of the service selection option identifier in -04 does not mention > DNS anymore. In -03 it read > "The Identifier MAY be resolveable by DNS." > I think it could be put back. The new text could be: > > " o Type: 8-bit identifier set to TBD (to be defined by IANA) of the > type of the skipable mobility option. Depending on the system > deployment the Identifier MAY be resolveable by DNS." > > Any thoughts? > > > > Cheers, > Jouni > > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Monday, October 22, 2007 8:55 AM >> To: Korhonen, Jouni /TeliaSonera Finland Oyj >> Cc: draft-korhonen-mip6-service@tools.ietf.org; mext@ietf.org >> Subject: Re: [MEXT] AD review of draft-korhonen-mip6-service-03.txt >> >> >> The new version addresses the concerns I had. Thanks. The >> document will now be moved forward. >> >> Jari >> >> >> >> > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext