Subject: [fmc] draft-boucadair-intarea-host-identifier-scenarios

From: <[email-masked]>
Date: Mon, 3 Dec 2012 10:07:55 +0100

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:[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

---

From: "George, Wes" <[email-masked]>
Date: Tue, 4 Dec 2012 15:09:11 -0500

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. 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?

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.

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. 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:
>
> The document does not include any solution-specific discussion. Its main
> goal is to identify the use cases and describe them.
>
> 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
>
>
> 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.

---

From: <[email-masked]>
Date: Wed, 5 Dec 2012 08:09:59 +0100

Dear Wes,

Thank you for your comments. 

Please see inline. 

Cheers,
Med 

>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
>
>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-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.

 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
>
>> If you think your use case is not included in this version, 
>please share
>> it with us.
>>
>> Comments are welcome.
>>
>> Cheers,
>> Med
>>
>>
>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.
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 7 Dec 2012 07:16:00 +0000

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]]
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

I've read this draft, and I think the use case list is
reasonably complete.

"The goal is to

Thanks,

Wes George

-----Original Message-----
From: [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,

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:

The document does not include any solution-specific
discussion. Its main
goal is to identify the use cases and describe them.

Comments are welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [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

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:

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

_______________________________________________
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

---

From: <[email-masked]>
Date: Mon, 10 Dec 2012 07:57:11 +0100

Hi Tina,

Many thanks for the comments.

Please see inline.

Cheers,
Med

________________________________
De : Tina TSOU [mailto:[email-masked]]
Envoyé : vendredi 7 décembre 2012 08:16
À : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,

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".
[Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use cases draft adopts a more generic scope in which host identification issue is encountered (this can be caused by address sharing, tunnelling, involvement of multiple administrative entities, etc.).

2.      Regarding this document, in the section of CGN use case, the stateless NAT44 case should be included.
[Med] Do you mean 1:1 NAT?

3.      For A+P section, the MAP/Lw4over6 cases may be considered.
[Med] OK. I will add a pointer to MAP and Lw4over6 as examples.

4.      In figure 6, the UE may have an interface with AF to initiate the session request, e.g., SIP.
[Med] What does that mean? The goal of fig.6 is to illustrate the case where there is a host identification issue.

Thank you,
Tina

Dear Wes,

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]<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

Thanks,

Wes George

-----Original Message-----

Dear all,

Comments are welcome.

Cheers,
Med

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

Abstract:

---

From: Tina TSOU <[email-masked]>
Date: Mon, 10 Dec 2012 19:04:04 +0000

Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tina,

Please see inline.

Cheers,
Med

Cc : George, Wes; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear Med et al,

[Tina] I meant the case in this document: http://datatracker.ietf.org/doc/draft-tsou-stateless-nat44/, did not mean to just promote my own draft though.

[Tina] In section 7, it says “The main issue is: PCEF, PCRF and AF all receive information bound to the same UE but without being able to correlate between the piece of data visible for each entity.”
In PCRF architecture, the AF receives service request from the UE for service establishment, which is one of the ways for AF to receive UE information, e.g., user ID. To make the architecture more generic, there should be an interface between AF and UE.

Thank you,
Tina

Dear Wes,

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]<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

Thanks,

Wes George

-----Original Message-----

Dear all,

Comments are welcome.

Cheers,
Med

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

Abstract:

---

From: <[email-masked]>
Date: Tue, 11 Dec 2012 10:31:58 +0100

Hi Tina,

Thank you for the clarification. I updated the draft with a pointer to SLNAT44.

I prefer to not modify fig.6 (keep it simple + we are not dealing with signalling flows issued from the UE).

Thanks for the review.

Cheers,
Med

Envoyé : lundi 10 décembre 2012 20:04

Dear Med et al,
In line...

Thank you,
Tina

Hi Tina,

Please see inline.

Cheers,
Med

Dear Med et al,

[Tina] In section 7, it says "The main issue is: PCEF, PCRF and AF all receive information bound to the same UE but without being able to correlate between the piece of data visible for each entity."
In PCRF architecture, the AF receives service request from the UE for service establishment, which is one of the ways for AF to receive UE information, e.g., user ID. To make the architecture more generic, there should be an interface between AF and UE.