Subject: [fmc] Fwd: fmc Digest, Vol 1, Issue 15

From: Hassnaa Moustafa <[email-masked]>
Date: Wed, 11 Apr 2012 21:09:43 +0200

Hi, 

IMO, terminals characteristics is a vey important aspect (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status). The network connectivities (WiFi, 3G, ..) supported by the terminal is important also. 
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:

> 
> From: <[email-masked]>
> Subject: Re: [fmc] List description
> Date: April 11, 2012 2:38:15 PM GMT+02:00
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> 
> 
> Dear all,
> As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protocols or adaptation and enhancement of approaches.
> 
> If that is what could be reflected within the requirements then I would add my issues here:
> 
> - beside exchange of customer identity and profile (e.g. subscription details such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to screen size and resolution) and efficient network resource usage.
> 
> Do you think that would make sense and could be translated into IETF requirements?
> 
> Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...
> 
> Best regards
> Dirk
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
> Gesendet: Mittwoch, 11. April 2012 12:16
> An: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: [fmc] List description
> 
> Hi,
> 
> I definitely agree we should elaborate first on requirements from an "FMC" standpoint. And I'd add "from and IETF standpoint" also...
> 
> Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.
> 
> Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.
> 
> Pierrick
> 
>> -----Message d'origine-----
>> De : [email-masked] [mailto:[email-masked]] De la part de
>> [email-masked]
>> Envoyé : mercredi 11 avril 2012 08:07
>> À : Donald Eastlake; David Allan I
>> Cc : Dean cheng; [email-masked]; [email-masked]
>> Objet : Re: [fmc] List description
>> 
>> Dear all,
>> 
>> There is no recommended solution for the FMC case, because there are
>> not clear requirements for that case.
>> I have suggested to Behcet to further elaborate on the requirements
>> from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:
>> 
>> * The current HOST_ID effort in INTAREA WG is restricted to the
>> analysis of potential channels which may convey the HOST_ID information
>> * A recommendation is likely to be added.but in the context of address
>> sharing (RFC6269)
>> * FMC proponents should elaborate further their requirements for the
>> HOST_ID
>> (1) Required only during session initialization?
>> (2) Required for all transport protocols?
>> (3) Host modification should be avoided or it does not harm?
>> (4) Which entity will use the HOST_ID information: proxy servers, else?
>>  (4a) Packet inspection is required? No?
>>  (4b) Performance impact
>> (5) Which entity will set the HOST_ID information?
>> 
>> BTW, I discussed this point with some colleagues and it seems using
>> port sets would be more appropriate for the FMC case (i.e.,
>> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-
>> 01#section-3.3).
>> 
>> If port sets are used, a dedicated notification channel is needed to
>> report assigned port sets. FYI, I'm working with Dean on this point.
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la
>>> part de Donald Eastlake
>>> Envoyé : mercredi 11 avril 2012 00:55
>>> À : David Allan I
>>> Cc : [email-masked]; [email-masked]
>>> Objet : Re: [fmc] List description
>>> 
>>> I think that the nat-reveal draft, while it discusses 8 different
>>> possible solutions, does not actually propose any specific solution
>>> for any specific problem, such as the FMC/NAT problem.
>>> 
>>> Thanks,
>>> Donald
>>> =============================
>>> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>> 155 Beaver Street, Milford, MA 01757 USA
>>> [email-masked]
>>> 
>>> On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
>>> <[email-masked]> wrote:
>>>> Thanks Donald.
>>>> 
>>>> So it is being addressed elsewhere. It is NOT the focus of
>>> this effort...
>>>> 
>>>> Given that clarification, this discussion is going circular.
>>> We now revert to "what IETF FMC work are we discussing?"
>>>> 
>>>> Dave
>>>> 
>>>> -----Original Message-----
>>>> From: Donald Eastlake [mailto:[email-masked]]
>>>> Sent: Tuesday, April 10, 2012 2:07 PM
>>>> To: David Allan I
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: Re: [fmc] List description
>>>> 
>>>> I think this is the draft:
>>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-
>>> analysis/
>>>> That is an INTAREA WG draft.
>>>> 
>>>> Thanks,
>>>> Donald
>>>> =============================
>>>> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>> 155 Beaver Street, Milford, MA 01757 USA
>>>> [email-masked]
>>>> 
>>>> 
>>>> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
>>> <[email-masked]> wrote:
>>>>> Hi Bechet:
>>>>> 
>>>>> You did not provide a useful answer. You simply pointed out
>>> to me things I've said (repeatedly).
>>>>> 
>>>>> I asked:
>>>>> 1) Where was the draft you referred to?
>>>>> 2) What WG is working on it?
>>>>> 3) Is it the topic of the effort represented by this list?
>>>>> 
>>>>> Can you please clarify...
>>>>> 
>>>>> Thanks
>>>>> Dave
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Behcet Sarikaya [mailto:[email-masked]]
>>>>> Sent: Tuesday, April 10, 2012 1:29 PM
>>>>> To: David Allan I
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [fmc] List description
>>>>> 
>>>>> Hi Dave,
>>>>> 
>>>>> In November 2011, 3GPP-BBF Workshop
>>>>> chaired by
>>>>> 
>>>>> Dave Allan (BBF), Balazs Bertenyi (3GPP)
>>>>> 
>>>>> issued Chairmen's Summary slides at:
>>>>> 
>>> http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104
>>>>> 6.zip
>>>>> 
>>>>> which stated on Slide 4
>>>>> 
>>>>> In case of RG with NATs additional mechanisms are needed to
>>> enable this. Jointly encourage IETF work on such mechanisms.
>>>>> 
>>>>> That's all I have to say.
>>>>> 
>>>>> I think we should concentrate on IETF work on FMC
>>> discussions on this list.
>>>>> 
>>>>> Kind regards,
>>>>> 
>>>>> Behcet
>>>>> 
>>>>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
>>> <[email-masked]> wrote:
>>>>>> Hi Bechet:
>>>>>> 
>>>>>>> Thanks for your mail.
>>>>>> 
>>>>>>> Two points.
>>>>>> 
>>>>>>> Point 1. Can you please clarify that you have expressed
>>> your personal opinion not wearing any hats?
>>>>>> 
>>>>>> Does it matter?
>>>>>> 
>>>>>> Point 2. On:
>>>>>> 
>>>>>>>> The outstanding headwound is a wifi connected UE behind a
>>> NAT, and I
>>>>>>>> believe that is already being addressed elsewhere in the IETF.
>>>>>> 
>>>>>>> Yes, there is a draft called NAT Reveal Analysis draft.
>>> It analyzes the problem and suggests very many solutions (5-6)
>>> and there are even solutions not mentioned in NAT Reveal
>>> Analysis draft.
>>>>>> 
>>>>>> A pointer to the draft would be useful. And the WG context
>>> it is being entertained in....
>>>>>> 
>>>>>>> So it is a difficult problem and maybe explains why so
>>> many people are subscribed to this list.
>>>>>> 
>>>>>> So is solving the NAT problem the purpose of this
>>> endeavour? I did not get that.
>>>>>> 
>>>>>> <snipped to end>
>>>>>> Cheers
>>>>>> Dave
>>>>>> 
>>>>>> _______________________________________________
>>>>>> fmc mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/fmc
>>>>> _______________________________________________
>>>>> fmc mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/fmc
>>> _______________________________________________
>>> fmc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/fmc
>>> 
>> _______________________________________________
>> fmc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/fmc
> _______________________________________________
> fmc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fmc

---

From: [email-masked]
Date: Wed, 11 Apr 2012 18:03:14 -0700

Hmmm.... 

I must be missing something .... 

Why would IETF FMC work has anything to do with "  (screen size, battery 
level for mobile terminals and tablets, supported resolution, processing 
capacity and buffering status)  "??

Hassnaa Moustafa <[email-masked]> 
Sent by: [email-masked]
04/11/2012 12:09 PM

To
[email-masked]
cc

Subject
[fmc] Fwd: fmc Digest, Vol 1, Issue 15

Hi, 

IMO, terminals characteristics is a vey important aspect (screen size, 
battery level for mobile terminals and tablets, supported resolution, 
processing capacity and buffering status). The network connectivities 
(WiFi, 3G, ..) supported by the terminal is important also. 
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:

From: <[email-masked]>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <[email-masked]>, <[email-masked]>, <
[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

Dear all,
As far as I understand here we are all on track - we currently have to 
discuss and come hopefully to a conclusion which aspects of interoperation 
between fixed and mobile networks to provide a unified service to end 
users can be solved by means of IETF i.e. e.g. proposing a BCP of existing 
protocols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would 
add my issues here:

- beside exchange of customer identity and profile (e.g. subscription 
details such as 'silver/gold/platinum' contract and status such as e.g. 
'busy', 'available', 'be right back' etc.) and related operator policies 
also the characteristics of currently used terminals is an important 
aspect both for service provisioning (e.g. adaptation of information data 
rate to screen size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF 
requirements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation 
Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been 
published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it 
seems that detailed requirements for us cannot be derived therefrom easily 
...

Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von 
[email-masked]
Gesendet: Mittwoch, 11. April 2012 12:16
An: [email-masked]; [email-masked]; 
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "FMC" 
standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on 
a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect 
to work done in other WG (or SDOs), to see what protocol extensions are 
needed.

Pierrick

-----Message d'origine-----

Dear all,

Cheers,
Med

-----Message d'origine-----

Thanks,
Donald

Dave

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: [email-masked]; [email-masked]
Subject: Re: [fmc] List description

Thanks,
Donald

I asked:

Thanks
Dave

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: [email-masked]
Subject: Re: [fmc] List description

Hi Dave,

which stated on Slide 4

Kind regards,

Behcet

Thanks for your mail.

Two points.

Does it matter?

Point 2. On:

<snipped to end>
Cheers
Dave

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 11 Apr 2012 22:04:21 -0400

Hi,

> I must be missing something ....

I think you are missing the word "transporting" or something like that,
which is reasonable because I think it was missing from Hassnaa's message.

> capacity and buffering status)  "??

I think the IETF might have work "to do with TRANSPORTING (...)" the
various terminal characteristics listed.

Thanks,
Donald

> *Hassnaa Moustafa <[email-masked]>*
> *From: *<[email-masked]* <[email-masked]>>
> *Subject: Re: [fmc] List description*
> *Date: *April 11, 2012 2:38:15 PM GMT+02:00
> *To: *<[email-masked]* <[email-masked]>>, <*
> [email-masked]* <[email-masked]>>, <*
> [email-masked]* <[email-masked]>>, <[email-masked]*<[email-masked]>
> >
> *Cc: [email-masked]* <[email-masked]>, [email-masked]*<[email-masked]>,
> [email-masked]* <[email-masked]>
>
>
> Dear all,
> between fixed and mobile networks to provide a unified service to end users
> can be solved by means of IETF i.e. e.g. proposing a BCP of existing
> also the characteristics of currently used terminals is an important aspect
> both for service provisioning (e.g. adaptation of information data rate to
> screen size and resolution) and efficient network resource usage.
>
> published here *http://www.itu.int/rec/T-REC-Q.1762-200709-I*<http://www.itu.int/rec/T-REC-Q.1762-200709-I>- however it seems that detailed requirements for us cannot be derived
> therefrom easily ...
>
> Best regards
> Dirk
> Von: [email-masked]* <[email-masked]> [
> mailto:[email-masked] <[email-masked]>] Im Auftrag von *
> [email-masked]* <[email-masked]>
> An: [email-masked]* <[email-masked]>; *
> [email-masked]* <[email-masked]>; [email-masked]*<[email-masked]>
> Cc: [email-masked]* <[email-masked]>; [email-masked]*<[email-masked]>;
> [email-masked]* <[email-masked]>
> De : [email-masked]* <[email-masked]> [
> mailto:[email-masked] <[email-masked]>] De la part de
> [email-masked]* <[email-masked]>
> Cc : Dean cheng; [email-masked]* <[email-masked]>; [email-masked]*<[email-masked]>
> *http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-*<http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis->
> 01#section-3.3).
>
> De : [email-masked]* <[email-masked]> [
> mailto:[email-masked] <[email-masked]>] De la
> part de Donald Eastlake
> Cc : [email-masked]* <[email-masked]>; [email-masked]*<[email-masked]>
> [email-masked]* <[email-masked]>
>
> <[email-masked]* <[email-masked]>> wrote:
> Thanks Donald.
>
> From: Donald Eastlake [mailto:[email-masked] <[email-masked]>]
> Cc: [email-masked]* <[email-masked]>; [email-masked]* <[email-masked]>
> *https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-*<https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal->
> analysis/
> [email-masked]* <[email-masked]>
>
>
> <[email-masked]* <[email-masked]>> wrote:
> Hi Bechet:
>
> From: Behcet Sarikaya [mailto:[email-masked]<[email-masked]>
> ]
> Cc: [email-masked]* <[email-masked]>
> *http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104*<http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104>
> 6.zip
>
> which stated on Slide 4
>
> <[email-masked]* <[email-masked]>> wrote:
> Hi Bechet:
>
> Thanks for your mail.
>
> Two points.
>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/fmc*<https://www.ietf.org/mailman/listinfo/fmc>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/fmc*<https://www.ietf.org/mailman/listinfo/fmc>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/fmc*<https://www.ietf.org/mailman/listinfo/fmc>
>
> [email-masked]* <[email-masked]>
> *https://www.ietf.org/mailman/listinfo/fmc*<https://www.ietf.org/mailman/listinfo/fmc>
> fmc mailing list*
> [email-masked]* <[email-masked]>

---

From: Hassnaa Moustafa <[email-masked]>
Date: Thu, 12 Apr 2012 09:35:01 +0200

Yes this is what I meant ;
(how to transport these information in a dynamic
And real time manner). Sure some protocols 
Extensions would be required. And here it is the
IETF work.

Hassnaa

S

On 12 avr. 2012, at 04:04, Donald Eastlake <[email-masked]> wrote:

> I think you are missing the word "transporting" or something like that, which is reasonable because I think it was missing from Hassnaa's message. 
> 
> Why would IETF FMC work has anything to do with "  (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status)  "?? 
> 
> I think the IETF might have work "to do with TRANSPORTING (...)" the various terminal characteristics listed.
> 
> Thanks,
> Donald

---

From: [email-masked]
Date: Thu, 12 Apr 2012 09:00:11 -0700

Sorry,  I still confuse. 

Even to discuss the transport these information, why it is so specific for 
FMC scenario?  Would the transport this info in a dynamic and real-time 
manner always applies anyway for any architecture? 

FMC support should NOT and would NOT change how these info are 
transported, it is totally transparent. 

04/12/2012 12:35 AM

To
Donald Eastlake <[email-masked]>
cc
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject
Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15

Hassnaa

S

Hi,

Thanks,
Donald

To
[email-masked] 
cc

Subject

Hi, 

Hassnaa 

Begin forwarded message: 

Dear all,

Best regards
Dirk
-----Ursprüngliche Nachricht-----

Hi,

Pierrick

-----Message d'origine----- 

Dear all, 

Cheers, 
Med 

-----Message d'origine----- 

Thanks, 
Donald 

Dave 

-----Original Message----- 
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 2:07 PM 
To: David Allan I 
Cc: [email-masked]; [email-masked] 
Subject: Re: [fmc] List description 

Thanks, 
Donald 

I asked: 

Thanks 
Dave 

-----Original Message----- 
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 1:29 PM 
To: David Allan I 
Cc: [email-masked] 
Subject: Re: [fmc] List description 

Hi Dave, 

which stated on Slide 4 

Kind regards, 

Behcet 

Thanks for your mail. 

Two points. 

Does it matter? 

Point 2. On: 

<snipped to end> 
Cheers 
Dave 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: <[email-masked]>
Date: Thu, 12 Apr 2012 18:35:06 +0200

Hi,
the transport of such information may be already provided within homogeneous networks e.g. by technology (or system/operator) specific means and therefore not in scope of IETF. Further more these parameters typically do not change if you are always using the same service and network provider and technology.
But IMO in FMC scenario with various technologies (systems/operators) participating it may be vitally important to provide this information independent of the currently used technology (and terminal interface). I think that for an FMC scenario being transparent to transport of these characteristic parameters we need a common control protocol (and generally IP layer is the first common layer applying to both networks).

Best regards
Dirk
________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Donnerstag, 12. April 2012 18:00
An: Hassnaa Moustafa
Cc: Donald Eastlake; [email-masked]
Betreff: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15

Sorry,  I still confuse.

Even to discuss the transport these information, why it is so specific for FMC scenario?  Would the transport this info in a dynamic and real-time manner always applies anyway for any architecture?

FMC support should NOT and would NOT change how these info are transported, it is totally transparent.

04/12/2012 12:35 AM

To

Hassnaa

S

On 12 avr. 2012, at 04:04, Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On Wed, Apr 11, 2012 at 9:03 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hmmm....

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked]<mailto:[email-masked]>

Hassnaa Moustafa <[email-masked]<mailto:[email-masked]>>
Sent by: [email-masked]<mailto:[email-masked]>

04/11/2012 12:09 PM

To
[email-masked]<mailto:[email-masked]>
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1, Issue 15

Hi,

Hassnaa

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Dear all,

Best regards
Dirk
-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von [email-masked]<mailto:[email-masked]>
Gesendet: Mittwoch, 11. April 2012 12:16
An: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [fmc] List description

Hi,

Pierrick

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de
[email-masked]<mailto:[email-masked]>
Envoyé : mercredi 11 avril 2012 08:07
À : Donald Eastlake; David Allan I
Cc : Dean cheng; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [fmc] List description

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la
part de Donald Eastlake
Envoyé : mercredi 11 avril 2012 00:55
À : David Allan I
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [fmc] List description

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked]<mailto:[email-masked]>

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<[email-masked]<mailto:[email-masked]>> wrote:
Thanks Donald.

Dave

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [fmc] List description

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
155 Beaver Street, Milford, MA 01757 USA
[email-masked]<mailto:[email-masked]>

On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<[email-masked]<mailto:[email-masked]>> wrote:
Hi Bechet:

I asked:

Thanks
Dave

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [fmc] List description

Hi Dave,

which stated on Slide 4

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<[email-masked]<mailto:[email-masked]>> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Does it matter?

Point 2. On:

<snipped to end>
Cheers
Dave

_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc

_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc

_______________________________________________
fmc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fmc

---

From: [email-masked]
Date: Thu, 12 Apr 2012 10:15:50 -0700

Dear Dirk, 

Thank you for your kind explanation. 

I believe that the common layer (i.e. above the IP) to transport this info 
has already been done today. 

Let's put FMC scenario aside for now, today for terminal connecting to the 
fixed access network, it could be done via either Ethernet port or USB 
port. The fixed network could be DSL, Cable, Ethernet, EPON etc. etc. etc. 

Now when you consider the most wireless handset today, it supports the 
cellular interface (i.e. CDMA, GSM, HSPA, LTE etc.), WiFi interface and 
USB port. And, the cellular network infrastructure itself, could be built 
based on Ethernet, Microwave, EPON etc. etc. 

Without the FMC, all those terminal display info on the handset have 
already transported over those wireless interface (i.e. cellular and wifi) 
and wired interface (i.e. Ethernet and USB) as described above. 

The purpose of FMC is just trying to amalgamate the fixed and mobile 
infrastructure together which could be based on same or different 
transport technology in the access and the core network.  In addition, the 
FMC is also trying to consolidate the support for QoS & Policy control as 
well as charging and accounting that are traditional different between the 
two networks. 

Hence, FMC has nothing to do with the terminal display info which is 
already supported today over its existing interface. 

Thanks.
Tricci 

<[email-masked]> 
Sent by: [email-masked]
04/12/2012 09:35 AM

To
<[email-masked]>, <[email-masked]>
cc
[email-masked], [email-masked]
Subject
Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15

Hi,
the transport of such information may be already provided within 
homogeneous networks e.g. by technology (or system/operator) specific 
means and therefore not in scope of IETF. Further more these parameters 
typically do not change if you are always using the same service and 
network provider and technology.
But IMO in FMC scenario with various technologies (systems/operators) 
participating it may be vitally important to provide this information 
independent of the currently used technology (and terminal interface). I 
think that for an FMC scenario being transparent to transport of these 
characteristic parameters we need a common control protocol (and generally 
IP layer is the first common layer applying to both networks).
 
Best regards 
Dirk 
[email-masked]

Sorry,  I still confuse. 

To

Hassnaa

S 

Hi,

Thanks,
Donald

To
[email-masked] 
cc

Subject

Hi, 

Hassnaa 

Begin forwarded message: 

Dear all,

Best regards
Dirk
-----Ursprüngliche Nachricht-----

Hi,

Pierrick

-----Message d'origine----- 

Dear all, 

Cheers, 
Med 

-----Message d'origine----- 

Thanks, 
Donald 

Dave 

-----Original Message----- 
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 2:07 PM 
To: David Allan I 
Cc: [email-masked]; [email-masked] 
Subject: Re: [fmc] List description 

Thanks, 
Donald 

I asked: 

Thanks 
Dave 

-----Original Message----- 
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Tuesday, April 10, 2012 1:29 PM 
To: David Allan I 
Cc: [email-masked] 
Subject: Re: [fmc] List description 

Hi Dave, 

which stated on Slide 4 

Kind regards, 

Behcet 

Thanks for your mail. 

Two points. 

Does it matter? 

Point 2. On: 

<snipped to end> 
Cheers 
Dave