[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
Hi Xiansong,
On 8/31/09 10:05 PM, "Xiangsong Cui" wrote:
> Hi Vijay,
>
> I'm not saying the MN does mobility management,
> I'm saying the MN, which does the action related to mobility
> management, is involved in the mobility management.
No. Again, passing some information at L2 is not the same being "involved"
in mobility management. This is a slippery slope, trying to define when you
can say the MN is "involved" in mobility management.
I think the existing text is fine for an Informational document.
So can we please move on?
Vijay
> I think the mobility management, in this solution, is achieved by
> multiple elements, including the MN and the MAG and others.
>
> In my understanding, passing the LMA information at L2 is a
> manner of offering the LMA information.
> Passing is subset of offering, while offering is a subset of
> involvement, which conflicts with the charter.
>
> Regards
> Xiangsong
>
> ----- Original Message -----
> From: "Vijay Devarapalli" <vijay at wichorus.com>
> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>; "jouni korhonen"
> <jouni.nospam at gmail.com>
> Cc: <netlmm at ietf.org>
> Sent: Tuesday, September 01, 2009 12:34 PM
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
>
>
>> Hi Xiangsong,
>>
>> On 8/31/09 6:31 PM, "Xiangsong Cui" wrote:
>>
>>> Hi Jouni,
>>>
>>> It is not only about modification, but also involvement.
>>>
>>> In NETLMM WG charter, there is clear statement:
>>>
>>> Description of Working Group:
>>>
>>> "This working
>>> group is tasked with defining a network-based local mobility
>>> management protocol, where local IP mobility is handled without
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> involvement from the mobile node."
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>> And as I said before, in this solution, MN is involved in the
>>> mobility management.
>>>
>>> So my comment is to remove this solution from the WG draft.
>>
>> I disagree. Passing the LMA information at L2 is not the same the MN doing
>> mobility management. So this shouldn't be removed from the draft.
>>
>> Vijay
>>
>>>
>>> Thank you for your discussion.
>>>
>>> Regards
>>> Xiangsong
>>>
>>>
>>> ----- Original Message -----
>>> From: "jouni korhonen" <jouni.nospam at gmail.com>
>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>> Sent: Monday, August 31, 2009 5:25 PM
>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>
>>>
>>>> Hi Xiangsong,
>>>>
>>>>
>>>> On Aug 29, 2009, at 4:16 AM, Xiangsong Cui wrote:
>>>>
>>>>> Hi Jouni,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> Regards
>>>>> Xiangsong
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>> <jouni.nospam at gmail.com
>>>>>>
>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>> Sent: Friday, August 28, 2009 6:56 PM
>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>> discovery-01.txt
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Aug 28, 2009, at 12:19 PM, Xiangsong Cui wrote:
>>>>>>
>>>>>>> Hi Jouni,
>>>>>>>
>>>>>>>> And what's the problem with that if it is part of the normal lower
>>>>>>>> layer attach procedure? The MN has a blob of information that it
>>>>>>>> knows what to do with to get an access, but does not know/care
>>>>>>>> about
>>>>>>>> its content. Yet, we have not changed anything in the MN that it
>>>>>>>> would do normally in any case.
>>>>>>>
>>>>>>> I don't know what kind of MN or OS can achieve this operation,
>>>>>>> maybe you can give me some example.
>>>>>>
>>>>>> As I said in an earlier mail, this procedure is analogous to 3G/EPS
>>>>>> attach procedure under certain conditions. There's a bunch of such
>>>>>> MNs
>>>>>> out there.. but that is not relevant from the I-D point of view.
>>>>>>
>>>>>>>
>>>>>>> Even the MN exists, you are now designing a new container, and
>>>>>>> putting
>>>>>>
>>>>>> Hmm.. If such MN & lower layer exists then I could not possibly be
>>>>>> designing any new container as it is already there.
>>>>>
>>>>> We need some existing examples for this. The solution can not depend
>>>>> on
>>>>> any nonexistent assumption.
>>>>
>>>> If it makes folks happy, we can add a reference to one example of such
>>>> functionality.
>>>>
>>>> The solution described in this section is similar to the solution
>>>> discussed in Section 3.1. Instead of deriving the LMA FQDN from the
>>>> MN identity, the MAG receives a LMA FQDN or an IP address
>>>> information
>>>> from lower layers, for example, as a part of the normal lower layer
>>>> signaling when the MN attaches to the network. One existing example
>>>> of such lower layer functionality is the Access Point Name
>>>> Information Element (APN IE) in 3GPP radio's network access
>>>> signaling
>>>> capable of carrying a FQDN [3GPP.24.008]. However, in general this
>>>> means the MN is also the originator of the LMA information. The LMA
>>>> information content as such can be transparent to the MN, meaning
>>>> the
>>>> MN has no knowledge it being anything LMA related.
>>>>
>>>>
>>>>>>
>>>>>>> special new information block in it, the MN must read and include
>>>>>>> the
>>>>>>
>>>>>> If the information blob were transparent to the MN, the MN would not
>>>>>> see anything special in it.
>>>>>
>>>>> The precondition is a problem, another problem is that the MN does do
>>>>> the action related to mobility management.
>>>>>
>>>>> Even the action (i.e. offering LMA information ) is not in the
>>>>> consciousness of the MN, the fact does still exist,
>>>>> the action is done by the MN and the MN is involved in the mobility
>>>>> management.
>>>>>
>>>>> The principle of NETLMM WG is "MN not *involved* in the mobility
>>>>> management", but not "MN not *active* in the mobility management",
>>>>> right?
>>>>
>>>> Well.. the charter talks about "specifying any changes to mobile hosts
>>>> is
>>>> out of scope", which in most cases realizes to no host involvement or
>>>> similar that would require code changes etc. However, in this
>>>> particular
>>>> case, when we talk about MNs that have desired capabilities at lower
>>>> layers (e.g. in network access signaling), we are not changing the
>>>> mobile
>>>> host but just taking advantage of the existing functionality on the
>>>> _network_ side.
>>>>
>>>> From my side, I am done now ;)
>>>>
>>>>
>>>> Cheers,
>>>> Jouni
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>> newly-added additional information block in the signal message.
>>>>>>
>>>>>> And the MN would do the same even if PMIP was not deployed.
>>>>>>
>>>>>>> Does it not need extension or enhancement?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Jouni
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards
>>>>>>> Xiangsong
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>
>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>>>> Sent: Friday, August 28, 2009 4:44 PM
>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>> discovery-01.txt
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Aug 28, 2009, at 11:25 AM, Xiangsong Cui wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> please see inline.
>>>>>>>>>
>>>>>>>>> Regards/Xiangsong
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>>>
>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>>>>>> Sent: Friday, August 28, 2009 4:05 PM
>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>> discovery-01.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Aug 28, 2009, at 5:11 AM, Xiangsong Cui wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Jouni,
>>>>>>>>>>>
>>>>>>>>>>>> However, the LMA information content as such can be transparent
>>>>>>>>>>>> to
>>>>>>>>>>>> the MN, meaning the MN has no knowledge it being anything LMA
>>>>>>>>>>>> related.
>>>>>>>>>>>
>>>>>>>>>>> If the MN don't know what the information is, why does it
>>>>>>>>>>> include
>>>>>>>>>>> the
>>>>>>>>>>> content in the transmitted message?
>>>>>>>>>>
>>>>>>>>>> It can be part of a lower layer attach procedure and the MN does
>>>>>>>>>> what it is specified to do.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I can't understand this situation: some information content is
>>>>>>>>>>> included
>>>>>>>>>>> in the signal message, but the origin and the destination do
>>>>>>>>>>> take
>>>>>>>>>>> different
>>>>>>>>>>> comprehension on this content.
>>>>>>>>>>
>>>>>>>>>> For example, the MN has some operator provisioned information
>>>>>>>>>> that
>>>>>>>>>> the MN knows it needs to signal to the network during the attach
>>>>>>>>>> procedure
>>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>>>> In these cases, MN knows what the information is, and knows the
>>>>>>>>> information should be transimitted to the network, and then it
>>>>>>>>> does
>>>>>>>>> signal
>>>>>>>>> the information to the network.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And what's the problem with that if it is part of the normal lower
>>>>>>>> layer attach procedure? The MN has a blob of information that it
>>>>>>>> knows what to do with to get an access, but does not know/care
>>>>>>>> about
>>>>>>>> its content. Yet, we have not changed anything in the MN that it
>>>>>>>> would do normally in any case.
>>>>>>>>
>>>>>>>> Jouni
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> in order to get access & reach certain desired service. The
>>>>>>>>>> information happens to be in a FQDN format that maps to a
>>>>>>>>>> specific
>>>>>>>>>> LMA. The MAG knows this fact but the MN does not care/ know about
>>>>>>>>>> it. This is analogous to 3G/EPC attach procedure under certain
>>>>>>>>>> conditions.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jouni
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Xiangsong
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>>>>>
>>>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>; <netlmm at ietf.org>
>>>>>>>>>>> Sent: Thursday, August 27, 2009 9:12 PM
>>>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Aug 27, 2009, at 11:57 AM, Xiangsong Cui wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Jouni,
>>>>>>>>>>>>
>>>>>>>>>>>> Let's take a precise analyse on this issue.
>>>>>>>>>>>>
>>>>>>>>>>>> You said such information may come from lower layers,
>>>>>>>>>>>> but who generate this information?
>>>>>>>>>>>>
>>>>>>>>>>>> Does lower layer generate the LMA information or the
>>>>>>>>>>>> LMA information does depend on the link type?
>>>>>>>>>>>>
>>>>>>>>>>>> I think it is not.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe it is the user who configures the LMA information
>>>>>>>>>>>> in the mobile node (i.e. the device), but in the MAG
>>>>>>>>>>>> perspective,
>>>>>>>>>>>> the initiator of the message which contains the LMA
>>>>>>>>>>>> information,
>>>>>>>>>>>> the initiator is the MN, the MAG gets the LMA information from
>>>>>>>>>>>> the mobile node.
>>>>>>>>>>>>
>>>>>>>>>>>> For example, the MAG gets LMA information from AAA server,
>>>>>>>>>>>> and the LMA information in AAA server is configured by the
>>>>>>>>>>>> administrator.
>>>>>>>>>>>> We can say MAG gets LMA information from AAA server but nobody
>>>>>>>>>>>> says MAG gets LMA information from the administrator.
>>>>>>>>>>>>
>>>>>>>>>>>> So I think it is a MN-assist solution.
>>>>>>>>>>>>
>>>>>>>>>>>> The MN is only doing what it would do independent of PMIP being
>>>>>>>>>>>> deployed or not and the MAG just makes advantage of it. Some
>>>>>>>>>>>> existing systems & MNs already do this.
>>>>>>>>>>>>
>>>>>>>>>>>> Based on the discussion we have had I think it is now worth
>>>>>>>>>>>> keeping this solution in the I-D. I would, however, reword it
>>>>>>>>>>>> like:
>>>>>>>>>>>>
>>>>>>>>>>>> The solution described in this section is similar to the
>>>>>>>>>>>> solution
>>>>>>>>>>>> discussed in Section 3.1. Instead of deriving the LMA FQDN
>>>>>>>>>>>> from the
>>>>>>>>>>>> MN identity, the MAG receives explicit LMA FQDN or IP address
>>>>>>>>>>>> information from lower layers, for example, as a part of the
>>>>>>>>>>>> normal
>>>>>>>>>>>> lower layer signaling when the MN attaches to the network.
>>>>>>>>>>>> This
>>>>>>>>>>>> usually means the MN is also the originator of the LMA
>>>>>>>>>>>> information.
>>>>>>>>>>>> However, the LMA information content as such can be transparent
>>>>>>>>>>>> to
>>>>>>>>>>>> the MN, meaning the MN has no knowledge it being anything LMA
>>>>>>>>>>>> related.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jouni
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards/Xiangsong
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message ----- From: "jouni korhonen"
>>>>>>>>>>>> <jouni.nospam at gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
>>>>>>>>>>>> Cc: "Vijay Devarapalli" <vijay at wichorus.com>;
>>>>>>>>>>>> <netlmm at ietf.org>
>>>>>>>>>>>> Sent: Thursday, August 27, 2009 4:15 PM
>>>>>>>>>>>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Aug 27, 2009, at 5:11 AM, Xiangsong Cui wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Vijay,
>>>>>>>>>>>>
>>>>>>>>>>>> I think I got your point, but I still have some questions.
>>>>>>>>>>>>
>>>>>>>>>>>> 1, NETLMM WG is about mobility management, so the item
>>>>>>>>>>>> of LMA discovery is of course in scope of mobility
>>>>>>>>>>>> management,
>>>>>>>>>>>> is it right?
>>>>>>>>>>>>
>>>>>>>>>>>> ok.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2, MN provides LMA information to MAG, is a *MN-assistant*
>>>>>>>>>>>> LMA discovery, is it right?
>>>>>>>>>>>>
>>>>>>>>>>>> We are a bit on a grey area here. Like the text says such
>>>>>>>>>>>> information may come from lower layers. If such information
>>>>>>>>>>>> delivery is e.g. part of the normal L2 attach procedure
>>>>>>>>>>>> independent whether there is PMIP or not, I would not call
>>>>>>>>>>>> it
>>>>>>>>>>>> in that case MN assisted LMA discovery.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 3, MN-assistant LMA discovery means MN involves in the
>>>>>>>>>>>> mobility
>>>>>>>>>>>> management, is it right?
>>>>>>>>>>>>
>>>>>>>>>>>> Continuing from the above. If the information that MN
>>>>>>>>>>>> provides
>>>>>>>>>>>> is configured into MNs and this configuration is independent
>>>>>>>>>>>> whether there is PMIP or not, I would not say that MN is
>>>>>>>>>>>> involved in the mobility management. The content of the
>>>>>>>>>>>> configuration data might then be different depending whether
>>>>>>>>>>>> PMIP is used but that is transparent to MNs.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jouni
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Xiangsong
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message ----- From: "Vijay Devarapalli"
>>>>>>>>>>>> <vijay at wichorus.com
>>>>>>>>>>>>
>>>>>>>>>>>> To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>; "jouni
>>>>>>>>>>>> korhonen" <jouni.nospam at gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>> Cc: <netlmm at ietf.org>
>>>>>>>>>>>> Sent: Thursday, August 27, 2009 8:32 AM
>>>>>>>>>>>> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-lma-
>>>>>>>>>>>> discovery-01.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You are right. I am not disagreeing that the mobile node
>>>>>>>>>>>> knows that
>>>>>>>>>>>> PMIPv6 is being used in the network when it sends the LMA
>>>>>>>>>>>> information to
>>>>>>>>>>>> the MAG. But we have a sort of working assumption that the
>>>>>>>>>>>> MN
>>>>>>>>>>>> is able to
>>>>>>>>>>>> supply certain information to the MAG at L2, for example,
>>>>>>>>>>>> attach versus
>>>>>>>>>>>> handover indication. This would be similar to that.
>>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Xiangsong Cui [mailto:Xiangsong.Cui at huawei.com]
>>>>>>>>>>>> Sent: Monday, August 24, 2009 7:13 PM
>>>>>>>>>>>> To: Vijay Devarapalli; jouni korhonen
>>>>>>>>>>>> Cc: netlmm at ietf.org
>>>>>>>>>>>> Subject: Re: [netlmm] I-D
>>>>>>>>>>>> Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Vijay,
>>>>>>>>>>>>
>>>>>>>>>>>> In my understanding, LMA is a functional element of mobility
>>>>>>>>>>>> management, the mobile node with only simple IP stack can't
>>>>>>>>>>>> recognize the information of LMA and can't transmit it to
>>>>>>>>>>>> MAG.
>>>>>>>>>>>>
>>>>>>>>>>>> If the mobile node can't send this information to MAG,
>>>>>>>>>>>> MAG can't receive this information from mobile node.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards/Xiangsong
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message ----- From: "Vijay Devarapalli"
>>>>>>>>>>>> <vijay at wichorus.com
>>>>>>>>>>>>
>>>>>>>>>>>> To: "jouni korhonen" <jouni.nospam at gmail.com>; "Xiangsong
>>>>>>>>>>>> Cui"
>>>>>>>>>>>> <Xiangsong.Cui at huawei.com>
>>>>>>>>>>>> Cc: <netlmm at ietf.org>
>>>>>>>>>>>> Sent: Tuesday, August 25, 2009 1:47 AM
>>>>>>>>>>>> Subject: Re: [netlmm] I-D
>>>>>>>>>>>> Action:draft-ietf-netlmm-lma-discovery-01.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/24/09 1:56 AM, "jouni korhonen" wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Section 3.2,
>>>>>>>>>>>> " This usually means the MN is the
>>>>>>>>>>>> originator of the LMA information and explicitly
>>>>>>>>>>>> participates to the
>>>>>>>>>>>> mobility management signaling "
>>>>>>>>>>>>
>>>>>>>>>>>> In NETLMM, the principle is that the MN should not be
>>>>>>>>>>>> involved
>>>>>>>>>>>> in
>>>>>>>>>>>> mobility management, right?
>>>>>>>>>>>> So the solution "Receiving LMA FQDN or IP Address"
>>>>>>>>>>>> should be
>>>>>>>>>>>> deleted in the netlmm WG draft.
>>>>>>>>>>>>
>>>>>>>>>>>> I would be fine deleting this section. Others?
>>>>>>>>>>>>
>>>>>>>>>>>> I disagree. The section explicitly says the MAG receives the
>>>>>>>>>>>> LMA FQDN or IP
>>>>>>>>>>>> address from the MN in the lower layers. This is not the same
>>>>>>>>>>>> as the MN
>>>>>>>>>>>> doing mobility management.
>>>>>>>>>>>>
>>>>>>>>>>>> Vijay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>