Re: [fmc] fmc Digest, Vol 9, Issue 7

Thanks Med for your clarification.
For yur first question ([Med] Wouldn't this be achieved at the application
level? announce/discover the device capabilities and then the server will
adapt the way it will server the device?) ---> YES sure this is taken care
by the application level (as HAS and DASH cases), but the question is:
Would doing so by lower layers through the host-ID be beneficial and
provide a generic standardized solution to any application on top? would
there be a agin? would this way of doing it help?
Here, I really have a question rather than a proposal for this I thought
sharing this point with you and with the mailing list (since the Host-ID
issue in the way you describe could help "this is what I thought at least -
but with no strong sureness").

For the second point on the SIPTO, I understood that it fits under the
Cellular Network use-case in the draft (with no need to include a new
use-case for Heterogeneous networks/Small cells)?

A last question (which was asked before I think in one of the previous
emails commenting the draft): Would the Host-ID issue mentioned in the
draft be a discussion base for FMC (or would be under one of the existing
WGs)?

Thanks for this exchange.

Kind regards,
Hassnaa

On Wed, Dec 12, 2012 at 11:01 PM, <fmc-request@ietf.org> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/fmc
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send fmc mailing list submissions to
>         fmc@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/fmc
> or, via email, send a message with subject or body 'help' to
>         fmc-request@ietf.org
>
> You can reach the person managing the list at
>         fmc-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fmc digest..."
>
> Today's Topics:
>
>    1. Re: fmc Digest, Vol 9, Issue 3 (mohamed.boucadair@orange.com)
>
>
> ---------- Forwarded message ----------
> From: <mohamed.boucadair@orange.com>
> To: Hasnaa Moustafa <hasnaa.moustafa@gmail.com>, "fmc@ietf.org" <
> fmc@ietf.org>
> Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" <
> draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>
> Date: Thu, 13 Dec 2012 08:01:21 +0100
> Subject: Re: [fmc] fmc Digest, Vol 9, Issue 3
> **
> Dear Hasnaa,
>
> Thank you for reading the draft.
>
> Please see inline.
> Cheers,
> Med
>
>  ------------------------------
> *De :* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *De la part de*Hasnaa Moustafa
> *Envoyé :* mardi 11 décembre 2012 20:22
> *À :* fmc@ietf.org
> *Objet :* Re: [fmc] fmc Digest, Vol 9, Issue 3
>
>
>
> Dear Med,
>
>
>
> I read the draft and have some issues to discuss on the use-cases.
>
> I think that Host-ID would be useful for the case of Home Networks in a
> scenario as follows:
>
> -  Several hosts exist in the home network that can belong to the same or
> multiple users
>
> -  The NAT functionality could be carried out either in the RG or in
> another Border node
>
> -  The host access could be through WiFi AP, FAP or even Ethernet (e.g.
> connected TV)
>
> -  Video streaming is the popular application/traffic in home network
> through the different hosts
>
> -  Each host is considered as a device with different characteristics
> (i.e. requiring the end server to  distinguish each device to provide the
> adequate content for each host) for better QoE
>
> - Each host has a private IPv4 address while there is one shared public
> IPv4 address by all the Home Network
>
> -  Consequently, a HostID solution is beneficial in this use case
>
>
>
> I am not sure if the motivation for Host-ID need in such scenario matches
> the objective of Host-ID in your draft and if this scenario is implicitly
> covered in some of the use-cases mentioned in the draft.
>
> [Med] Wouldn't this be achieved at the application
> level? announce/discover the device capabilities and then the server will
> adapt the way it will server the device?
>
>
>
> Another case that could be checked maybe is the HetNets scenario.
> According to 3GPP definition for HetNets/small cells: Small cells are lower
> power nodes working in the same frequency as the macro cell nodes, and the
> heterogeneity of the network comes from the varying power levels within the
> deployed nodes.
>
> A host could be attached to one or more small cells and could be
> simultaneously attached to a small cell and a macro cell at the same time.
> Private IPv4 addresses are assigned in each cell (macro or pico), and there
> could be  several scenarios as follows:
>
> -         host attached to only the macro cell: similar HostID issue to
> the cellular network use-case
>
> -         host attached to only a small cell: similar HostID issue to the
> case of cellular network use-case
>
> -         host attached to both the  macro cell  and a small cell:
> Selected IP Traffic Offload is enabled by NAT based on operator policies
> (e.g. per IP address) [3GPP TR 23.829]. Here there might be a new issue ?
>
> [Med] Thank you for sharing this use case. From an IP perspective, the way
> cells are engineered isn't orthogonal to identification issues? The SIPTO
> sub-case is IMHO important to consider not only for the small cell case but
> in for mobile networks in general. The SIPTO case may induce some issues
> for both IPv4 and IPv6.
>
>
>
>
>
>  I thought to share thes epoints with you and with all the list for more
> feedback.
> [Med] Many thanks for sharing your thoughts. I will be more than please to
> integrate you text on the SIPTO case.
>
>
>
> Kind regards,
>
> Hassnaa
>
>
>
>
> On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Moustafa <
> hasnaa.moustafa@gmail.com> wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>  *From: *fmc-request@ietf.org
>> *Subject: **fmc Digest, Vol 9, Issue 3*
>> *Date: *December 7, 2012 12:27:41 AM PST
>> *To: *fmc@ietf.org
>> *Reply-To: *fmc@ietf.org
>>
>> If you have received this digest without all the individual message
>> attachments you will need to update your digest options in your list
>> subscription.  To do so, go to
>>
>> https://www.ietf.org/mailman/listinfo/fmc
>>
>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>> MIME or Plain Text Digests?" to MIME.  You can set this option
>> globally for all the list digests you receive at this point.
>>
>>
>>
>> Send fmc mailing list submissions to
>> fmc@ietf.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.ietf.org/mailman/listinfo/fmc
>> or, via email, send a message with subject or body 'help' to
>> fmc-request@ietf.org
>>
>> You can reach the person managing the list at
>> fmc-owner@ietf.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of fmc digest..."
>> Today's Topics:
>>
>>   1. Re: [Int-area]
>>      draft-boucadair-intarea-host-identifier-scenarios (Tina TSOU)
>>
>> *From: *Tina TSOU <Tina.Tsou.Zouting@huawei.com>
>> *Subject: **Re: [fmc] [Int-area]
>> draft-boucadair-intarea-host-identifier-scenarios*
>> *Date: *December 6, 2012 11:16:00 PM PST
>> *To: *"mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
>> *Cc: *"draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org"
>> <draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>, "
>> int-area@ietf.org" <int-area@ietf.org>, "fmc@ietf.org" <fmc@ietf.org>,
>> "George, Wes" <wesley.george@twcable.com>
>>
>>
>>  Dear Med et al,
>>  In general, I like the current version. Some comments are below.****
>> 1.      From my understanding, this document provides the use cases for
>> the issues and analysis in “draft-ietf-intarea-nat-reveal-analysis”. Is it
>> correct? If it is , I suggest this document be referenced in
>> “nat-reveal-analysis”.****
>> 2.      Regarding this document, in the section of CGN use case, the
>> stateless NAT44 case should be included.****
>> 3.      For A+P section, the MAP/Lw4over6 cases may be considered.****
>> 4.      In figure 6, the UE may have an interface with AF to initiate
>> the session request, e.g., SIP.
>>
>> Thank you,
>> Tina
>>
>> On Dec 4, 2012, at 11:10 PM, "mohamed.boucadair@orange.com" <
>> mohamed.boucadair@orange.com> wrote:
>>
>>  Dear Wes,
>>
>> Thank you for your comments.
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> -----Message d'origine-----
>>
>> De : George, Wes [mailto:wesley.george@twcable.com]
>>
>> Envoyé : mardi 4 décembre 2012 21:09
>>
>> À : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org
>>
>> Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
>>
>> Objet : RE: draft-boucadair-intarea-host-identifier-scenarios
>>
>>
>> I've read this draft, and I think the use case list is
>>
>> reasonably complete.
>>
>>
>> However, it's really unclear to me what the value of this
>>
>> draft might be in its current form, and what its intended
>>
>> audience might be. Cataloging use cases is not all that
>>
>> helpful by itself without an end goal in mind, and that end
>>
>> goal is not clear from the draft.
>>
>>
>> Med: The goal of this draft is what is described in Section 2:
>>
>> "The goal is to
>>   identify scenarios the authors are aware of and which share the same
>>   issue of host identification.
>>
>>   This document does not include any solution-specific discussion.
>>   This document can be used as a tool to design solution(s) mitigating
>>   the encountered issues.  Having a generic solution which would solve
>>   the issues encountered in these use cases is preferred over designing
>>   a solution for each use case.  Describing the use case allows to
>>   identify what is common between the use cases and then would help
>>   during the solution design phase."
>>
>> Next updates of this draft will:
>> * include a discussion section to assess whether the issue is valid for
>> IPv4-only or it applies also for IPv6
>> * include a discussion text to clarify whether each use case is valid
>> within one single administrative domain or not
>> * include a discussion text to identify use cases which share the same
>> requirements (this will help in designing the solution)
>> * add additional use cases if any
>>
>> At given point in time we need to draw conclusions about the following:
>> (1) are these use cases valid ones?
>> (2) if this is a real technical problem, what the IETF can do to solve
>> the issue?
>> (3) if there is interest in this area, how to organize the work for the
>> solution space.
>>
>> The scope is deliberately
>>
>> very narrow and references other drafts that discuss some of
>>
>> the surrounding issues with address sharing and unique
>>
>> identifiers, and so there is very little text in each section
>>
>> beyond a basic description. Even when you think of this in
>>
>> terms of follow-on drafts such as a gap analysis or problem
>>
>> statement or solution drafts, one wonders how useful it is to
>>
>> spread this across multiple drafts. So why not simply
>>
>> incorporate this list into one of the referenced general
>>
>> drafts on host identification, such as nat-reveal-analysis and
>>
>> then broaden that draft so that it considers and addresses the
>>
>> other use cases as appropriate?
>>
>>
>> Med: As I mentioned above, we don't want to include any solution-specific
>> discussion to this draft. The text is shortened in purpose.
>>
>>
>> Otherwise, I think that the draft needs to be much clearer
>>
>> about the unique issues and considerations for each use case,
>>
>> especially those that are somehow distinct from those covered
>>
>> in nat-reveal-analysis so that it can serve as a better input
>>
>> to any potential solutions addressing this problem.
>>
>>
>> Med: Fully agreed. This will be added to the next rev of the draft.
>>
>>
>> I also believe that if this draft is to remain a standalone
>>
>> document, the authors need to make at least some attempt at
>>
>> discussing security and privacy considerations here, even if
>>
>> it is mainly to refer the reader to more in-depth discussions
>>
>> of the matter in other drafts.
>>
>>
>> Med: Agree. A pointer to
>> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04#section-3will be added to the next rev of the draft. The text will also include some
>> discussion for use cases which are restricted to one single administrative
>> domain.
>>
>>
>> Again, here is an area where
>>
>> being clear about the specific considerations for each use
>>
>> case is important, identifying whether the other drafts
>>
>> discuss things so that they are applicable to all of the use
>>
>> cases, or if the use cases are unique in any number of ways
>>
>> that will mean that they have unique privacy and security
>>
>> considerations.
>>
>>
>> Thanks,
>>
>>
>> Wes George
>>
>>
>>  -----Original Message-----
>>
>>  From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On
>>
>>  Behalf Of mohamed.boucadair@orange.com
>>
>>  Sent: Monday, December 03, 2012 4:08 AM
>>
>>  To: fmc@ietf.org; int-area@ietf.org
>>
>>  Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
>>
>>  Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios
>>
>>
>>  Dear all,
>>
>>
>>  We submitted an updated version of this draft to list use cases which
>>
>>  encounter the issue of host identification. The following
>>
>> use cases are
>>
>>  discussed in the draft:
>>
>>
>>    (1)  Carrier Grade NAT (CGN)
>>
>>    (2)  A+P (e.g., MAP )
>>
>>    (3)  Application Proxies
>>
>>    (4)  Provider Wi-Fi
>>
>>    (5)  Policy and Charging Architectures
>>
>>    (6)  Cellular Networks
>>
>>    (7)  Femtocells
>>
>>    (8)  Overlay Networks (e.g., CDNs)
>>
>>
>>  The document does not include any solution-specific
>>
>> discussion. Its main
>>
>>  goal is to identify the use cases and describe them.
>>
>>
>>  If you think your use case is not included in this version,
>>
>> please share
>>
>>  it with us.
>>
>>
>>  Comments are welcome.
>>
>>
>>  Cheers,
>>
>>  Med
>>
>>
>>
>>  -----Message d'origine-----
>>
>>  De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-
>>
>>  bounces@ietf.org] De la part de internet-drafts@ietf.org
>>
>> Envoyé : lundi
>>
>>  3 décembre 2012 08:26 À : i-d-announce@ietf.org Objet : I-D Action:
>>
>>  draft-boucadair-intarea-host-identifier-scenarios-02.txt
>>
>>
>>
>>  A New Internet-Draft is available from the on-line Internet-Drafts
>>
>>  directories.
>>
>>
>>
>>       Title           : Host Identification: Use Cases
>>
>>       Author(s)       : Mohamed Boucadair
>>
>>                           David Binet
>>
>>                           Sophie Durel
>>
>>                           Tirumaleswar Reddy
>>
>>                           Brandon Williams
>>
>>       Filename        : draft-boucadair-intarea-host-identifier-
>>
>>  scenarios-02.txt
>>
>>       Pages           : 14
>>
>>       Date            : 2012-12-02
>>
>>
>>  Abstract:
>>
>>    This document describes a set of scenarios in which host
>>
>>    identification is required.
>>
>>
>>
>>  The IETF datatracker status page for this draft is:
>>
>>  https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-
>>
>>  identifier-scenarios
>>
>>
>>  There's also a htmlized version available at:
>>
>>  http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
>>
>>  scenarios-02
>>
>>
>>  A diff from the previous version is available at:
>>
>>  http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-
>>
>>  identifier-scenarios-02
>>
>>
>>
>>  Internet-Drafts are also available by anonymous FTP at:
>>
>>  ftp://ftp.ietf.org/internet-drafts/
>>
>>
>>  _______________________________________________
>>
>>  I-D-Announce mailing list
>>
>>  I-D-Announce@ietf.org
>>
>>  https://www.ietf.org/mailman/listinfo/i-d-announce
>>
>>  Internet-Draft directories: http://www.ietf.org/shadow.html or
>>
>>  ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>  _______________________________________________
>>
>>  Int-area mailing list
>>
>>  Int-area@ietf.org
>>
>>  https://www.ietf.org/mailman/listinfo/int-area
>>
>>
>> This E-mail and any of its attachments may contain Time Warner
>>
>> Cable proprietary information, which is privileged,
>>
>> confidential, or subject to copyright belonging to Time Warner
>>
>> Cable. This E-mail is intended solely for the use of the
>>
>> individual or entity to which it is addressed. If you are not
>>
>> the intended recipient of this E-mail, you are hereby notified
>>
>> that any dissemination, distribution, copying, or action taken
>>
>> in relation to the contents of and attachments to this E-mail
>>
>> is strictly prohibited and may be unlawful. If you have
>>
>> received this E-mail in error, please notify the sender
>>
>> immediately and permanently delete the original and any copy
>>
>> of this E-mail and any printout.
>>
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>>
>>
>> _______________________________________________
>> fmc mailing list
>> fmc@ietf.org
>> https://www.ietf.org/mailman/listinfo/fmc
>>
>>
>>
>
> _______________________________________________
> fmc mailing list
> fmc@ietf.org
> https://www.ietf.org/mailman/listinfo/fmc
>
>