Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

From: "Seil Jeon" <[email-masked]>
Date: Mon, 1 Jun 2015 14:49:34 +0100

Hi Alper,

See inline ">>>"

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Friday, May 29, 2015 9:42 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

Hello Seil,

> 
>> 
>> #49: full on-demand mobility support
>> 
>> The three proposed flags express a "type" of source IP address an
> application wants to get to the IP stack. Particularly, the sustained 
> IP address is proposed to provide on-demand IP session continuity, 
> which activates IP mobility once the terminal moves across other access
network.
>> While the terminal stays at the same network where the session is
> initiated, regular IP routing is applied.
>> 
>> The on-demand draft does not assure provide the full on-demand 
>> mobility
> for all scenarios by merely indicating the Socket API, 
> IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned  
> issue is as follows;
>> 
>> 0. The MN is configured with one or more Nomadic IP addresses.
>> 
>> 1. Once an app. requests "sustained IP address" to the IP stack, and 
>> it
> will obtain a sustained IP address through a protocol procedure 
> between  the terminal and network.
>> 
>> 2. Other app. initiated over the same access network will use the 
>> same
> sustained IP address while the terminal remains connected at the same 
> access network.
>> 
>> 3. The terminal moves to another access network and a new app. 
>> requests a
> sustained IP address with the Socket API to the IP stack. Since a  
> sustained IP address is already available in the IP stack, the 
> sustained  IP address is assigned to the new app.
>> 
> 
> Yes, that's what happens.
> You are not pointing to an issue up until this point, right? Because, 
> you continuing your email with a "Besides" gives the impression that 
> you are pointing to an issue, but I don't see any issue captured in the
above text.
> 
>>> There is an issue. Maybe, we need to be synchronized how have you 
>>> thought
> and defined the meaning of "on-demand mobility". As far as I know, 
> there are two meanings; one is that by imposing capability among IP 
> address reachability and IP session continuity, needed for an 
> application, into a source IP address, on-demand mobility could be 
> achieved; as the other meaning, it can be rephrased and detailed with 
> dynamic mobility, which should be applied in the use of sustained IP 
> address. A new application needs to have non-anchored sustained IP 
> address. This is our consistent claim. Non-optimal routing issue has 
> been raised in DMM Requirement document in RFC 7333, which should be
critically considered in the solutions.

Sorry, I don't understand what you meant here.

>>> You answer doesn't make us progress. Please specify where and what you
have understood.

>> Besides, in case sustained IP address allocation is used default, 
>> there
> may be multiple sustained IP addresses including newly obtained 
> sustained IP address over the new access network in the IP stack. 
> However, when an app. is initiated, the IP stack may not select the 
> new one in the context of the default source IP address selection
mechanism [RFC6724][RFC5014].
>> 
> 
> OK, is the issue following: When there are multiple sustained IP 
> addresses, how does the IP stack pick one among them? (*)
> 
>>> As mentioned and specified in our draft
> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, 
> if there is no additional preference, we can leave selection to the 
> default source address selection mechanism. BUT if we have specific 
> preference among multiple sustained IP addresses and an initiated 
> application wants to have non-anchored sustained IP address over 
> currently attached access network, the proposed flag is essential.
> 

I think you are meaning the same thing as I said above (*).
Do you agree?

>>> Yes.

>> For providing the full on-demand mobility, a new flag is needed, 
>> letting
> the IP stack request a new sustained IP address or choose a sustained 
> IP address not requiring IP mobility anchoring when an application is 
> initiated, among the existing ones in the IP stack.
>> 
> 
> Your flag is not a solution to what I captured above. It does 
> something
> else: Instruct the IP stack to go get a new sustained IP address 
> whether there is already one or more configured on the stack or not. 
> (**)
> 
>>> Answered in the above. 
> 

There's a discrepancy between (*) and your solution (**).

Are we talking about (*), (**), or something else?

>>> There is no discrepancy between them. I said "a new flag", just an
additional flag not intending to get a new sustained IP address all the
time. And it should not request a new sustained IP address whether there is
already one or more configured on the stack or not. It is given with the
same expression in the ticket, though our draft is saying the meaning of a
new sustained IP address, which will be revised in next update.

The point is that when the IP stack receives a flag with sustained IP
address flag, it will check it has a sustained IP address, and if it has one
or more, one that does not activate IP mobility will be selected. If not,
the MN will be triggered to get a new IP sustained address not activing IP
mobility.

Seil Jeon

> Alper
> 
> 
> 
>> --
>> -------------------------+-------------------------------------------
>> -------------------------+---
>> -------------------------+---
>> Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
>> [email-masked]      |  [email-masked]
>>    Type:  defect       |     Status:  new
>> Priority:  critical     |  Milestone:
>> Component:  ondemand-    |    Version:
>> mobility               |   Keywords:  on-demand mobility
>> Severity:  Submitted    |
>> WG Document            |
>> -------------------------+-------------------------------------------
>> -------------------------+---
>> -------------------------+---
>> 
>> Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>
>> dmm <http://tools.ietf.org/dmm/>
>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 1 Jun 2015 22:49:38 +0300

> the MN will be triggered to get a new IP sustained address not activing IP

So, the idea is, when this flag is set along with a Sustained IP address request from the app:
- if the host stack is already configured with a Sustained IP address allocated from the serving network, then it gets selected (irrespective of the presence or absence of any other Sustained IP address).
- if the host stack is not already configured with a Sustained IP address allocated from the serving network (irrespective of the presence or absence of any Sustained IP address from any other network), then the host makes an attempt to configure one with the serving network. 
-- if the configuration succeeds, then the newly configured IP address is selected.
-- if the configuration fails. then the call fails (?? or some other behavior -- you can define here).

Alper

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 2 Jun 2015 00:11:54 +0100

Hi Alper,

Regards,

Seil

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

> address flag, it will check it has a sustained IP address, and if it 

> has one or more, one that does not activate IP mobility will be 

> selected. If not, the MN will be triggered to get a new IP sustained 

> address not activing IP mobility.

So, the idea is, when this flag is set along with a Sustained IP address
request from the app:

- if the host stack is already configured with a Sustained IP address
allocated from the serving network, then it gets selected (irrespective of
the presence or absence of any other Sustained IP address).

>> No. I said "one that does not activate IP mobility" over the serving
network, among the existing ones in the IP stack, gets selected. If no one
in the IP stack is not matched, it will make an attempt to get a new
sustained IP address from the serving network.

- if the host stack is not already configured with a Sustained IP address
allocated from the serving network (irrespective of the presence or absence
of any Sustained IP address from any other network), then the host makes an
attempt to configure one with the serving network. 

>> Yes.

-- if the configuration succeeds, then the newly configured IP address is
selected.

>> Yes.

-- if the configuration fails. then the call fails (?? or some other
behavior -- you can define here).

>> You mean the configuration fails when there is no sustained IP address,
right?

In my opinion, this issue belongs to address configuration mechanism based
on definition of the three DMM APIs. Those jobs are/will be asked on each
configuration mechanism, according to discussion of the previous
teleconference in the WT you're leading. At that time, if I see any
something related to our proposal, we will raise our voice.

 

Alper

 

>> which activates IP mobility once the terminal moves across other 

>> access

>> you are pointing to an issue, but I don't see any issue captured in 

>> the

>>>> You answer doesn't make us progress. Please specify where and what 

>>>> you

>>  <http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00>

> additional flag not intending to get a new sustained IP address all 

> the time. And it should not request a new sustained IP address whether 

> there is already one or more configured on the stack or not. It is 

> given with the same expression in the ticket, though our draft is 

> saying the meaning of a new sustained IP address, which will be revised in
next update.

> address flag, it will check it has a sustained IP address, and if it 

> has one or more, one that does not activate IP mobility will be 

> selected. If not, the MN will be triggered to get a new IP sustained 

> address not activing IP mobility.

>>> -------------------------+------------------------------------------

>>> -------------------------+-

>>>  <mailto:[email-masked]> [email-masked]      |
<mailto:[email-masked]> [email-masked]

>>> -------------------------+------------------------------------------

>>> -------------------------+-

>>> Ticket URL: < <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>
http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>

>>> dmm < <http://tools.ietf.org/dmm/> http://tools.ietf.org/dmm/>

>>>  <mailto:[email-masked]> [email-masked]

>>>  <https://www.ietf.org/mailman/listinfo/dmm>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 3 Jun 2015 09:02:54 +0300

> >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network.

What exactly is "(an IP address) that does not activate IP mobility"? Please elaborate.

Is it
- A nomadic IP address?
- A Sustained IP address that just got allocated from the currently serving network (hence the "mobility is not activated" until the MN moves off link)?
- something else?

Alper

On Jun 2, 2015, at 2:11 AM, Seil Jeon wrote:

> Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support
>  
> >> No. I said "one that does not activate IP mobility" over the serving network, among the existing ones in the IP stack, gets selected. If no one in the IP stack is not matched, it will make an attempt to get a new sustained IP address from the serving network.
>  
> >> You mean the configuration fails when there is no sustained IP address, right?
> In my opinion, this issue belongs to address configuration mechanism based on definition of the three DMM APIs. Those jobs are/will be asked on each configuration mechanism, according to discussion of the previous teleconference in the WT you’re leading. At that time, if I see any something related to our proposal, we will raise our voice.
>  
>  
>  
>  
> Alper
>  
>  
>  
>  
>  
>  
> > saying the meaning of a new sustained IP address, which will be revised in next update.
> >

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 3 Jun 2015 11:12:53 +0100

- A Sustained IP address that just got allocated from the currently serving
network (hence the "mobility is not activated" until the MN moves off link)?

> Yes. Thanks for your elaboration.

Regards,

Seil

From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 7:03 AM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

 

What exactly is "(an IP address) that does not activate IP mobility"? Please
elaborate.

Is it

- A nomadic IP address?

- A Sustained IP address that just got allocated from the currently serving
network (hence the "mobility is not activated" until the MN moves off link)?

- something else?

Alper

 

Hi Alper,

Regards,

Seil

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

right?

 

Alper

 

next update.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 3 Jun 2015 13:34:20 +0300

OK, so now at least I fully understand what this is.

My recommendation is:
- Please refine the issue definition in the tracker, so that people can understand this the same way,
- And then let's ask the WG members their opinion about the issue (whether it's something worth tackling or not),
- And if they agree to the issue, then we move to the solution space discussion.

Alper

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 3 Jun 2015 11:59:33 +0100

OK, Alper.

I agree on your suggested way.

Regards,

Seil

From: Alper Yegin [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 11:34 AM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

My recommendation is:

- Please refine the issue definition in the tracker, so that people can
understand this the same way,

- And then let's ask the WG members their opinion about the issue (whether
it's something worth tackling or not),

- And if they agree to the issue, then we move to the solution space
discussion.

Alper

 

Regards,

Seil

 

Is it

- A nomadic IP address?

- something else?

Alper

 

Hi Alper,

Regards,

Seil

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

right?

 

Alper

 

next update.

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 8 Jun 2015 16:56:45 +0100

Hi Chairs,

We want to elaborate the issue created in the tracker for clarity. What
Action should I take in "Modify Ticket"?

- leave as new

- resolve as .

- reassign to .

Regards,

Seil

My recommendation is:

Alper

 

Regards,

Seil

 

Is it

- A nomadic IP address?

- something else?

Alper

 

Hi Alper,

Regards,

Seil

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

right?

 

Alper

 

next update.

---

From: Dapeng Liu <[email-masked]>
Date: Tue, 9 Jun 2015 22:43:33 +0800

Hi Seil,  

You can refer to this: http://trac.tools.ietf.org/wg/dmm/trac/wiki/TracTickets  

A simple way would be adding comment to the existing ticket.

--  
Dapeng Liu

在 2015年6月8日 星期一，下午11:56，Seil Jeon 写道：

> Hi Chairs,
>   
> We want to elaborate the issue created in the tracker for clarity. What Action should I take in “Modify Ticket”?
>   
> - leave as new
> - resolve as …
> - reassign to …
>   
>   
> Regards,
> Seil
>   
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])
> Cc: [email-masked] (mailto:[email-masked])
> >>> [email-masked] (mailto:[email-masked])      |  [email-masked] (mailto:[email-masked])
>  
>  
> >>> [email-masked] (mailto:[email-masked])
>  
>  
> [email-masked] (mailto:[email-masked])

---

From: "dmm issue tracker" <[email-masked]>
Date: Tue, 09 Jun 2015 15:34:13 -0000

#49: observation of on-demand mobility

Changes (by [email-masked]):

 * cc: [email-masked] (added)

Comment:

 The on-demand draft proposed three source IP address types, enabling
 applications to configure the required type in the IP stack, according to
 IP mobility requirements. Particularly, the sustained IP address is
 proposed to provide on-demand IP mobility, which aims at activating IP
 mobility support operation upon an MN's movement.

 Delivering the defined flag, IPV6_REQ_SUSTAINED_IP, from an application to
 the IP stack through the socket API does not ensure the observation of on-
 demand mobility principle where IP mobility is provided upon an MN’s
 movement, because an initiated application may be served with IP mobility
 even though the MN has not moved from the current serving network where
 the IP prefix/address was assigned for the application. As a result, IP
 mobility is activated before needed.

 An example scenario raising the aforementioned issue is as follows;

 1. The MN is configured with one or more Nomadic IP addresses.
 2. Once an application requests “sustained IP address” to the IP stack, it
 will obtain a sustained IP address through a protocol procedure between
 the MN and network.
 3. Other application initiated over the same serving network will use the
 same sustained IP address while the MN remains connected at the same
 serving network.
 4. The MN moves to another access network, and the previous (mobile)
 sessions are working. A new application requests a sustained IP address.
 The existing sustained IP address is assigned to the new application as a
 sustained IP address is already available in the IP stack.
 5. As a consequence, the new session is served by a remote IP mobility
 anchor with necessary management functions, though the MN has not moved
 yet.

 Moreover, we can suppose an example over a different address assignment
 strategy, where each network assigns sustained IP addresses, i.e.
 sustained IP address assignment by default, enables an MN to have multiple
 sustained IP addresses. When a new application is initiated and needs a
 sustained IP address, the IP stack may or not select the locally assigned
 one in the context of the default source IP address selection mechanism
 [RFC6724][RFC5014], as the application has no means to explicitly request
 such a demand to the IP stack.

 For providing the full on-demand mobility when using sustained IP address,
 a new address preference flag will be needed, letting the IP stack select
 a sustained IP address assigned from the current serving network. If not
 available, it should request a sustained IP address from the serving
 network.

-- 
-------------------------+-------------------------------------------------
  mobility               |  Resolution:
 Severity:  Submitted    |
  WG Document            |
 Keywords:  on-demand    |
  mobility               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49#comment:1>
dmm <http://tools.ietf.org/dmm/>

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 9 Jun 2015 16:39:16 +0100

Hi Alper and DMM folks,

We have tried to refine the issue in the on-demand WG draft as forwarded. I hope the issue has been clearly defined through the elaborated texts.
I'd like to get opinions on it.

Regards,
Seil

-----Original Message-----
From: dmm issue tracker [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2015 4:34 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dmm] #49 (ondemand-mobility): observation of on-demand mobility (was: full on-demand mobility support)

Comment:

 The on-demand draft proposed three source IP address types, enabling  applications to configure the required type in the IP stack, according to  IP mobility requirements. Particularly, the sustained IP address is  proposed to provide on-demand IP mobility, which aims at activating IP  mobility support operation upon an MN's movement.

 Delivering the defined flag, IPV6_REQ_SUSTAINED_IP, from an application to  the IP stack through the socket API does not ensure the observation of on-  demand mobility principle where IP mobility is provided upon an MN’s  movement, because an initiated application may be served with IP mobility  even though the MN has not moved from the current serving network where  the IP prefix/address was assigned for the application. As a result, IP  mobility is activated before needed.

 1. The MN is configured with one or more Nomadic IP addresses.
 2. Once an application requests “sustained IP address” to the IP stack, it  will obtain a sustained IP address through a protocol procedure between  the MN and network.
 3. Other application initiated over the same serving network will use the  same sustained IP address while the MN remains connected at the same  serving network.
 4. The MN moves to another access network, and the previous (mobile)  sessions are working. A new application requests a sustained IP address.
 The existing sustained IP address is assigned to the new application as a  sustained IP address is already available in the IP stack.
 5. As a consequence, the new session is served by a remote IP mobility  anchor with necessary management functions, though the MN has not moved  yet.

 Moreover, we can suppose an example over a different address assignment  strategy, where each network assigns sustained IP addresses, i.e.
 sustained IP address assignment by default, enables an MN to have multiple  sustained IP addresses. When a new application is initiated and needs a  sustained IP address, the IP stack may or not select the locally assigned  one in the context of the default source IP address selection mechanism  [RFC6724][RFC5014], as the application has no means to explicitly request  such a demand to the IP stack.

 For providing the full on-demand mobility when using sustained IP address,  a new address preference flag will be needed, letting the IP stack select  a sustained IP address assigned from the current serving network. If not  available, it should request a sustained IP address from the serving  network.

-- 
-------------------------+----------------------------------------------
-------------------------+----------------------------------------------

---

From: "Seil Jeon" <[email-masked]>
Date: Tue, 9 Jun 2015 16:54:33 +0100

Hi Dapeng,

Thanks to your advice, we’ve tried to update the issue description.

Regards,

Seil Jeon

From: Dapeng Liu [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2015 3:44 PM
To: Seil Jeon
Cc: [email-masked]; Dapeng Liu; [email-masked]
Subject: 回复： [DMM] FW: [dmm] #49 (ondemand-mobility): full on-demand mobility support

Hi Seil, 

-- 

Dapeng Liu

Hi Chairs,

- leave as new

- resolve as …

- reassign to …

Regards,

Seil

My recommendation is:

Alper

 

Regards,

Seil

 

Is it

- A nomadic IP address?

- something else?

Alper

 

Hi Alper,

Regards,

Seil

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Monday, June 01, 2015 8:50 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

 

Alper

 

>>  <http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00> http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00,

>>>  <mailto:[email-masked]> [email-masked]      |   <mailto:[email-masked]> [email-masked]

>>> Ticket URL: < <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49> http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>

>>>  <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm

dmm mailing list

[email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Jun 2015 08:45:04 -0700

Add your comments/modifiactions to "add a comment" box and modify ticket 
"leave as new".

- Jouni

6/8/2015, 8:56 AM, Seil Jeon kirjoitti:
> Action should I take in “Modify Ticket”?
>
> - leave as new
>
> - resolve as …
>
> - reassign to …
>
> Regards,
>
> Seil
>
> *From:*Alper Yegin [mailto:[email-masked]]
> *Sent:* Wednesday, June 03, 2015 11:34 AM
> *To:* Seil Jeon
> *Cc:* [email-masked]
> *Subject:* Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand
> mobility support
>
> - And then let's ask the WG members their opinion about the issue
> (whether it's something worth tackling or not),
>
> - A Sustained IP address that just got allocated from the currently
> serving network (hence the "mobility is not activated" until the MN
> moves off link)?
>
> *From:*Alper Yegin [mailto:[email-masked]]
> *Sent:*Wednesday, June 03, 2015 7:03 AM
> *To:*Seil Jeon
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand
> mobility support
>
>     - if the host stack is already configured with a Sustained IP
>     address allocated from the serving network, then it gets selected
>     (irrespective of the presence or absence of any other Sustained IP
>     address).
>
> - A Sustained IP address that just got allocated from the currently
> serving network (hence the "mobility is not activated" until the MN
> moves off link)?
>
> - something else?
>
> Alper
>
> Cc:[email-masked] <mailto:[email-masked]>
> allocated from the serving network, then it gets selected (irrespective
> of the presence or absence of any other Sustained IP address).
>
> - if the host stack is not already configured with a Sustained IP
> address allocated from the serving network (irrespective of the presence
> or absence of any Sustained IP address from any other network), then the
> host makes an attempt to configure one with the serving network.
>
>>> Yes.
>
> In my opinion, this issue belongs to address configuration mechanism
> based on definition of the three DMM APIs. Those jobs are/will be asked
> on each configuration mechanism, according to discussion of the previous
> teleconference in the WT you’re leading. At that time, if I see any
>>>>[email-masked] <mailto:[email-masked]>      |
> [email-masked] <mailto:[email-masked]>
>
>>>>[email-masked] <mailto:[email-masked]>
>