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

From: Hasnaa Moustafa <[email-masked]>
Date: Thu, 13 Dec 2012 10:37:36 -0800

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, <[email-masked]> 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
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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 ([email-masked])
>
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> To: Hasnaa Moustafa <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <
> [email-masked]>
> 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 :* [email-masked] [mailto:[email-masked]] *De la part de*Hasnaa Moustafa
> *Envoyé :* mardi 11 décembre 2012 20:22
> *À :* [email-masked]
> *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 <
> [email-masked]> wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>  *From: [email-masked]
>> *Subject: **fmc Digest, Vol 9, Issue 3*
>> *Date: *December 7, 2012 12:27:41 AM PST
>> *To: [email-masked]
>> *Reply-To: [email-masked]
>>
>> 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
>> [email-masked]
>>
>> 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
>> [email-masked]
>>
>> You can reach the person managing the list at
>> [email-masked]
>>
>> 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 <[email-masked]>
>> *Subject: **Re: [fmc] [Int-area]
>> draft-boucadair-intarea-host-identifier-scenarios*
>> *Date: *December 6, 2012 11:16:00 PM PST
>> *To: *"[email-masked]" <[email-masked]>
>> *Cc: *"[email-masked]"
>> <[email-masked]>, "
>> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
>> "George, Wes" <[email-masked]>
>>
>>
>>  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, "[email-masked]" <
>> [email-masked]> wrote:
>>
>>  Dear Wes,
>>
>> Thank you for your comments.
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> -----Message d'origine-----
>>
>> De : George, Wes [mailto:[email-masked]]
>>
>> Envoyé : mardi 4 décembre 2012 21:09
>>
>> À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]
>>
>> Cc : [email-masked]
>>
>> 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: [email-masked] [mailto:[email-masked]] On
>>
>>  Behalf Of [email-masked]
>>
>>  Sent: Monday, December 03, 2012 4:08 AM
>>
>>  To: [email-masked]; [email-masked]
>>
>>  Cc: [email-masked]
>>
>>  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 : [email-masked] [mailto:i-d-announce-
>>
>>  [email-masked]] De la part de [email-masked]
>>
>> Envoyé : lundi
>>
>>  3 décembre 2012 08:26 À : [email-masked] 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
>>
>>  [email-masked]
>>
>>  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
>>
>>  [email-masked]
>>
>>  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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/int-area
>>
>>
>>
>> _______________________________________________
>> 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: Fri, 14 Dec 2012 07:41:49 +0100

Dear Hasnaa,

Please see inline.

Cheers,
Med

________________________________
De : Hasnaa Moustafa [mailto:[email-masked]]
Envoyé : jeudi 13 décembre 2012 19:38
À : [email-masked]
Cc : BOUCADAIR Mohamed OLNC/OLN
Objet : Re: 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").
[Med] The current use cases described in the draft present host identification as a problem. The content adaptation case you are describing is looking on how to make use of any HOST_ID proposal to better service the device/user. This is another perspective. I prefer to restrict the scope of the draft to only cases where host identification is an issue.

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)?
[Med] SIPTO can be introduced as a new use case in its own.

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)?
[Med] The goal is to assess whether there is interest from the community to solve this problem. The problem space is not restricted to FMC but covers various cases which share the same technical problem. Today this document is still "homeless"...

Kind regards,
Hassnaa

On Wed, Dec 12, 2012 at 11:01 PM, <[email-masked]<mailto:[email-masked]>> 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

Send fmc mailing list submissions to
        [email-masked]<mailto:[email-masked]>

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
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

   1. Re: fmc Digest, Vol 9, Issue 3 ([email-masked]<mailto:[email-masked]>)

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
To: Hasnaa Moustafa <[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]>>
Date: Thu, 13 Dec 2012 08:01:21 +0100
Subject: Re: [fmc] fmc Digest, Vol 9, Issue 3
Dear Hasnaa,

Please see inline.
Cheers,
Med

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Hasnaa Moustafa
Envoyé : mardi 11 décembre 2012 20:22
À : [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: fmc Digest, Vol 9, Issue 3
Date: December 7, 2012 12:27:41 AM PST
To: [email-masked]<mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>

Send fmc mailing list submissions to
[email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
[email-masked]<mailto:[email-masked]>

  1. Re: [Int-area]

From: Tina TSOU <[email-masked]<mailto:[email-masked]>>
Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios
Date: December 6, 2012 11:16:00 PM PST
To: "[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]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "George, Wes" <[email-masked]<mailto:[email-masked]>>

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, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear Wes,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : George, Wes [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 4 décembre 2012 21:09
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: draft-boucadair-intarea-host-identifier-scenarios

"The goal is to

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.

Med: As I mentioned above, we don't want to include any solution-specific discussion to this draft. The text is shortened in purpose.

Med: Agree. A pointer to http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04#section-3 will 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.

Thanks,

Wes George

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, December 03, 2012 4:08 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear all,

Comments are welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:i-d-announce-<mailto:i-d-announce->
[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi
3 décembre 2012 08:26 À : [email-masked]<mailto:[email-masked]> Objet : I-D Action:
draft-boucadair-intarea-host-identifier-scenarios-02.txt

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

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

_______________________________________________
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