From mohamed.boucadair@orange.com Mon Dec 3 01:07:59 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162621F889B; Mon, 3 Dec 2012 01:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6kpXn1BbbKY; Mon, 3 Dec 2012 01:07:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7821F8892; Mon, 3 Dec 2012 01:07:58 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 97F6918C0A4; Mon, 3 Dec 2012 10:07:56 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5B0BE27C076; Mon, 3 Dec 2012 10:07:56 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 3 Dec 2012 10:07:56 +0100 From: To: "fmc@ietf.org" , "int-area@ietf.org" Date: Mon, 3 Dec 2012 10:07:55 +0100 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDg Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: [fmc] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:08:00 -0000 Dear all, We submitted an updated version of this draft to list use cases which encou= nter the issue of host identification. The following use cases are discusse= d 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 go= al is to identify the use cases and describe them.=20 If you think your use case is not included in this version, please share it= with us.=20 Comments are welcome.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-02.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-sc= enarios There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-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 From wesley.george@twcable.com Tue Dec 4 12:11:49 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87621F85E8; Tue, 4 Dec 2012 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkviYq7UfAw2; Tue, 4 Dec 2012 12:11:48 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5F21F8C70; Tue, 4 Dec 2012 12:11:47 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,217,1355115600"; d="scan'208";a="482631668" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Dec 2012 15:08:44 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 4 Dec 2012 15:08:53 -0500 From: "George, Wes" To: "mohamed.boucadair@orange.com" , "fmc@ietf.org" , "int-area@ietf.org" Date: Tue, 4 Dec 2012 15:09:11 -0500 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDgAEjqz2A= Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 04 Dec 2012 15:31:25 -0800 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [fmc] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:11:49 -0000 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 th= at end goal is not clear from the draft. The scope is deliberately very nar= row and references other drafts that discuss some of the surrounding issues= with address sharing and unique identifiers, and so there is very little t= ext 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 o= r solution drafts, one wonders how useful it is to spread this across multi= ple drafts. So why not simply incorporate this list into one of the referen= ced general drafts on host identification, such as nat-reveal-analysis and = then broaden that draft so that it considers and addresses the other use ca= ses 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 som= ehow distinct from those covered in nat-reveal-analysis so that it can serv= e 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 a= uthors need to make at least some attempt at discussing security and privac= y 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 whe= re being clear about the specific considerations for each use case is impor= tant, 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 n= umber of ways that will mean that they have unique privacy and security con= siderations. 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=E9 : lundi > 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mohamed.boucadair@orange.com Tue Dec 4 23:10:04 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2321F8C71; Tue, 4 Dec 2012 23:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd84GWu9NIA5; Tue, 4 Dec 2012 23:10:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B15F721F8C60; Tue, 4 Dec 2012 23:10:02 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BAB6C18CB61; Wed, 5 Dec 2012 08:10:00 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9A22D35C065; Wed, 5 Dec 2012 08:10:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 5 Dec 2012 08:10:00 +0100 From: To: "George, Wes" , "fmc@ietf.org" , "int-area@ietf.org" Date: Wed, 5 Dec 2012 08:09:59 +0100 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDgAEjqz2AAFxx6kA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.5.61518 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [fmc] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 07:10:04 -0000 Dear Wes, Thank you for your comments.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : George, Wes [mailto:wesley.george@twcable.com]=20 >Envoy=E9 : mardi 4 d=E9cembre 2012 21:09 >=C0 : 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=20 >reasonably complete. > >However, it's really unclear to me what the value of this=20 >draft might be in its current form, and what its intended=20 >audience might be. Cataloging use cases is not all that=20 >helpful by itself without an end goal in mind, and that end=20 >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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (this will help in designing the solution)=20 * 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 sol= ution space. The scope is deliberately=20 >very narrow and references other drafts that discuss some of=20 >the surrounding issues with address sharing and unique=20 >identifiers, and so there is very little text in each section=20 >beyond a basic description. Even when you think of this in=20 >terms of follow-on drafts such as a gap analysis or problem=20 >statement or solution drafts, one wonders how useful it is to=20 >spread this across multiple drafts. So why not simply=20 >incorporate this list into one of the referenced general=20 >drafts on host identification, such as nat-reveal-analysis and=20 >then broaden that draft so that it considers and addresses the=20 >other use cases as appropriate? Med: As I mentioned above, we don't want to include any solution-specific d= iscussion to this draft. The text is shortened in purpose. > >Otherwise, I think that the draft needs to be much clearer=20 >about the unique issues and considerations for each use case,=20 >especially those that are somehow distinct from those covered=20 >in nat-reveal-analysis so that it can serve as a better input=20 >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=20 >document, the authors need to make at least some attempt at=20 >discussing security and privacy considerations here, even if=20 >it is mainly to refer the reader to more in-depth discussions=20 >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. Th= e text will also include some discussion for use cases which are restricted= to one single administrative domain. Again, here is an area where=20 >being clear about the specific considerations for each use=20 >case is important, identifying whether the other drafts=20 >discuss things so that they are applicable to all of the use=20 >cases, or if the use cases are unique in any number of ways=20 >that will mean that they have unique privacy and security=20 >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=20 >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=20 >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,=20 >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=20 >Envoy=E9 : lundi >> 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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=20 >Cable proprietary information, which is privileged,=20 >confidential, or subject to copyright belonging to Time Warner=20 >Cable. This E-mail is intended solely for the use of the=20 >individual or entity to which it is addressed. If you are not=20 >the intended recipient of this E-mail, you are hereby notified=20 >that any dissemination, distribution, copying, or action taken=20 >in relation to the contents of and attachments to this E-mail=20 >is strictly prohibited and may be unlawful. If you have=20 >received this E-mail in error, please notify the sender=20 >immediately and permanently delete the original and any copy=20 >of this E-mail and any printout. >= From Tina.Tsou.Zouting@huawei.com Thu Dec 6 23:16:38 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5D821F84F9; Thu, 6 Dec 2012 23:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL3jfqLRh+Fn; Thu, 6 Dec 2012 23:16:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9824D21F8A90; Thu, 6 Dec 2012 23:16:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG39661; Fri, 07 Dec 2012 07:16:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 07:15:31 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 15:16:03 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 23:16:01 -0800 From: Tina TSOU To: "mohamed.boucadair@orange.com" Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DA== Date: Fri, 7 Dec 2012 07:16:00 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 07 Dec 2012 00:27:39 -0800 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" , "George, Wes" Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 07:16:38 -0000 --_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 =93draft-ietf-intarea-nat-reveal-analysis=94. Is it= correct? If it is , I suggest this document be referenced in =93nat-reveal= -analysis=94. 2. Regarding this document, in the section of CGN use case, the statel= ess 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 s= ession request, e.g., SIP. Thank you, Tina On Dec 4, 2012, at 11:10 PM, "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=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (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 sol= ution 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 d= iscussion 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. Th= e 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:i= nt-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 [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 --_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Med et al,

In general, I like the current version. Some comments = are below.

1.      From my understanding, this document provide= s the use cases for the issues and analysis in =93draft-ietf-intarea-nat-re= veal-analysis=94. Is it correct? If it is , I suggest this document be referenced in =93nat-= reveal-analysis=94.

2.      Regarding this document, in the section of C= GN 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 wi= th 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@twca= ble.com]
Envoy=E9 : mardi 4 d=E9cembre 2012 21:09
=C0 : 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-id= entifier-scenarios

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

However, it's really unclear to me what the= value of this
draft might be in its current form, and wha= t its intended
audience might be. Cataloging use cases is = not all that
helpful by itself without an end goal in mi= nd, 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 sha= re the same
  issue of host identification.

  This document does not include any solution-specific disc= ussion.
  This document can be used as a tool to design solution(s)= mitigating
  the encountered issues.  Having a generic solution w= hich would solve
  the issues encountered in these use cases is preferred ov= er designing
  a solution for each use case.  Describing the use ca= se allows to
  identify what is common between the use cases and then wo= uld help
  during the solution design phase."

Next updates of this draft will:
* include a discussion section to assess whether the issue is valid f= or 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 sam= e 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 followin= g:
(1) are these use cases valid ones?
(2) if this is a real technical problem, what the IETF can do to solv= e the issue?
(3) if there is interest in this area, how to organize the work for t= he solution space.

The scope is deliberately
very narrow and references other drafts tha= t discuss some of
the surrounding issues with address sharing= and unique
identifiers, and so there is very little te= xt in each section
beyond a basic description. Even when you t= hink of this in
terms of follow-on drafts such as a gap ana= lysis or problem
statement or solution drafts, one wonders h= ow useful it is to
spread this across multiple drafts. So why = not simply
incorporate this list into one of the refer= enced general
drafts on host identification, such as nat-= reveal-analysis and
then broaden that draft so that it consider= s and addresses the
other use cases as appropriate?

Med: As I mentioned above, we don't want to include any solution-spec= ific 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 rem= ain a standalone
document, the authors need to make at least= some attempt at
discussing security and privacy considerati= ons 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#sectio= n-3 will be added to the next rev of the draft. The text will also incl= ude some discussion for use cases which are restricted to one single admini= strative domain.


Again, here is an area where
being clear about the specific consideratio= ns 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 an= y number of ways
that will mean that they have unique privac= y 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@iet= f.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 dra= ft to list use cases which
encounter the issue of host identification.= The following
use cases are
discussed in the draft:

  (1)  Carrier Grade NAT (CG= N)
  (2)  A+P (e.g., MAP )<= /span>
  (3)  Application Proxies
  (4)  Provider Wi-Fi=
  (5)  Policy and Charging A= rchitectures
  (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 descr= ibe 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=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available from the = on-line Internet-Drafts
directories.


     Title  &= nbsp;        : Host Identification:= Use Cases
     Author(s) &nb= sp;     : Mohamed Boucadair
       &= nbsp;           &nbs= p;     David Binet
       &= nbsp;           &nbs= p;     Sophie Durel
       &= nbsp;           &nbs= p;     Tirumaleswar Reddy
       &= nbsp;           &nbs= p;     Brandon Williams
     Filename &nbs= p;      : draft-boucadair-intarea-host-identi= fier-
scenarios-02.txt
     Pages  &= nbsp;        : 14
     Date  &n= bsp;         : 2012-12-02

Abstract:
  This document describes a set o= f scenarios in which host
  identification is required.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/draft-bouc= adair-intarea-host-
identifier-scenarios

There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-bouca= dair-intarea-host-identifier-
scenarios-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= boucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also available by anony= mous 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<= /span>
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___________________________________________= ____
Int-area mailing list
Int-ar= ea@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 pri= vileged,
confidential, or subject to copyright belon= ging to Time Warner
Cable. This E-mail is intended solely for t= he use of the
individual or entity to which it is address= ed. If you are not
the intended recipient of this E-mail, you = are hereby notified
that any dissemination, distribution, copyi= ng, or action taken
in relation to the contents of and attachme= nts to this E-mail
is strictly prohibited and may be unlawful.= If you have
received this E-mail in error, please notif= y the sender
immediately and permanently delete the orig= inal and any copy
of this E-mail and any printout.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://ww= w.ietf.org/mailman/listinfo/int-area
--_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_-- From mohamed.boucadair@orange.com Sun Dec 9 22:57:18 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271C021F8E35; Sun, 9 Dec 2012 22:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbbmNjzU7KGA; Sun, 9 Dec 2012 22:57:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 92CBE21F8DA9; Sun, 9 Dec 2012 22:57:15 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E017918C25C; Mon, 10 Dec 2012 07:57:13 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BF32035C061; Mon, 10 Dec 2012 07:57:13 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 10 Dec 2012 07:57:13 +0100 From: To: Tina TSOU Date: Mon, 10 Dec 2012 07:57:11 +0100 Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DJgRmtZA Message-ID: <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9B6B67B2PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.10.52415 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" , "George, Wes" Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 06:57:18 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9B6B67B2PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tina, Many thanks for the comments. Please see inline. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 08:16 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-= host-identifier-scenarios@tools.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios 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 cor= rect? If it is , I suggest this document be referenced in "nat-reveal-analy= sis". [Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use ca= ses draft adopts a more generic scope in which host identification issue is= encountered (this can be caused by address sharing, tunnelling, involvemen= t of multiple administrative entities, etc.). 2. Regarding this document, in the section of CGN use case, the statel= ess 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 s= ession request, e.g., SIP. [Med] What does that mean? The goal of fig.6 is to illustrate the case wher= e there is a host identification issue. Thank you, Tina On Dec 4, 2012, at 11:10 PM, "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=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (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 sol= ution 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 d= iscussion 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. Th= e 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:i= nt-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 [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 --_000_94C682931C08B048B7A8645303FDC9F36E9B6B67B2PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
Many thanks for the comments. <= /DIV>
 
Please see inline.
 
Cheers,
Med

De : Tina TSOU=20 [mailto:Tina.Tsou.Zouting@huawei.com]
Envoy=E9 : vendredi= 7=20 d=E9cembre 2012 08:16
=C0 : BOUCADAIR Mohamed=20 OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org= ;=20 draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
Ob= jet :=20 Re: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,

In = general, I=20 like the current version. Some comments are below.

1.      = ;From my understanding, this document provides the use cases = for the=20 issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis=94. Is i= t=20 correct? If it is , I suggest this document be referenced in=20 =93nat-reveal-analysis=94.
[Med] nat-reveal-analysis draft=20 inherits its scope from RFC6269. The use cases=20 draft adopts a more generic scope in which host identification issue= is=20 encountered (this can be caused by address sharing,=20 tunnelling, involvement of multiple administrative entities,=20 etc.). 

 

2.      = ;Regarding this document, in the section of CGN use case, the= =20 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 Lw4ov= er6 as=20 examples.

 

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


Thank you,
Tina

On Dec 4, 2012, at 11:10 PM, "mohamed.boucadair@orange.com= "=20 <mohamed.boucadair@orange.com= >=20 wrote:

Dear Wes,

Thank you for you= r=20 comments.

Please see inline.=20

Cheers,
Med=20

-----Message=20 d'origine-----
De : George, Wes=20 [mailto:wesley.george@twcable.com]
Envoy=E9 : mardi 4 d=E9cembre 2012=20 21:09
=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.or= g
Objet : RE:=20 draft-boucadair-intarea-host-identifier-scenarios

I've read this draft, and I think the u= se=20 case list is
reasonably complete.

However, it's really unclear to me what= the=20 value of this
draft might be in its current form, and= what=20 its intended
audience might be. Cataloging use cases= is=20 not all that
helpful by itself without an end goal i= n=20 mind, and that end
goal is not clear from the=20 draft.

Med: The goal of t= his=20 draft is what is described in Section=20 2:

"The goal is=20 to
  identify scenarios the authors are aware= of=20 and which share the same
  issue of host=20 identification.

  This docum= ent=20 does not include any solution-specific=20 discussion.
  This document can be used as a = tool=20 to design solution(s) mitigating
  the encoun= tered=20 issues.  Having a generic solution which would=20 solve
  the issues encountered in these use c= ases=20 is preferred over designing
  a solution for = each=20 use case.  Describing the use case allows=20 to
  identify what is common between the use = cases=20 and then would help
  during the solution des= ign=20 phase."

Next updates of this draft=20 will:
* include a discussion section to assess whether = the=20 issue is valid for IPv4-only or it applies also for IPv6
*=20 include a discussion text to clarify whether each use case is valid wit= hin=20 one single administrative domain or not
* include a=20 discussion text to identify use cases which share the same requirements= =20 (this will help in designing the solution)
* add addit= ional=20 use cases if any

At given point in tim= e we=20 need to draw conclusions about the following:
(1) are t= hese=20 use cases valid ones?
(2) if this is a real technical=20 problem, what the IETF can do to solve the issue?
(3) i= f=20 there is interest in this area, how to organize the work for the soluti= on=20 space.

The scope is deliberately=20
very narrow and references other drafts= that=20 discuss some of
the surrounding issues with address sha= ring=20 and unique
identifiers, and so there is very littl= e=20 text in each section
beyond a basic description. Even when y= ou=20 think of this in
terms of follow-on drafts such as a gap= =20 analysis or problem
statement or solution drafts, one wonde= rs=20 how useful it is to
spread this across multiple drafts. So = why=20 not simply
incorporate this list into one of the=20 referenced general
drafts on host identification, such as= =20 nat-reveal-analysis and
then broaden that draft so that it cons= iders=20 and addresses the
other use cases as=20 appropriate?

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


Otherwise, I think that the draft needs= to=20 be much clearer
about the unique issues and considerati= ons=20 for each use case,
especially those that are somehow disti= nct=20 from those covered
in nat-reveal-analysis so that it can s= erve=20 as a better input
to any potential solutions addressing t= his=20 problem.

Med: Fully agr= eed.=20 This will be added to the next rev of the draft.


I also believe that if this draft is to= =20 remain a standalone
document, the authors need to make at l= east=20 some attempt at
discussing security and privacy=20 considerations here, even if
it is mainly to refer the reader to mor= e=20 in-depth discussions
of the matter in other=20 drafts.

Med: Agree. A poi= nter=20 to http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-a= nalysis-04#section-3=20 will be added to the next rev of the draft. The text will also include = some=20 discussion for use cases which are restricted to one single administrat= ive=20 domain.


Again, here i= s an=20 area where
being clear about the specific=20 considerations for each use
case is important, identifying whether = the=20 other drafts
discuss things so that they are applica= ble=20 to all of the use
cases, or if the use cases are unique i= n any=20 number of ways
that will mean that they have unique pr= ivacy=20 and security
considerations.

Thanks,

Wes George

-----Original=20 Message-----
From: int-area-bounces@ietf.org= =20 [mailto:int-area-bounces@ietf.org] On
Behalf Of mohamed.boucadair@oran= ge.com
Sent: Monday, December 03, 2012 4:08= =20 AM
To: fmc@ietf.org; int-area@ietf.org
<= /BLOCKQUOTE>
Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.= org
Subject: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear all,

We submitted an updated version of th= is=20 draft to list use cases which
encounter the issue of host=20 identification. The following
use cases are
discussed in the=20 draft:

  (1)  Carrier Grade N= AT=20 (CGN)
  (2)  A+P (e.g., MAP= =20 )
  (3)  Application=20 Proxies
  (4)  Provider=20 Wi-Fi
  (5)  Policy and Char= ging=20 Architectures
  (6)  Cellular=20 Networks
  (7)=20  Femtocells
  (8)  Overlay Network= s=20 (e.g., CDNs)

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

If you think your use case is not inc= luded=20 in this version,
please share
it with=20 us.

Comments are=20 welcome.

Cheers,
Med


-----Message=20 d'origine-----
De : i-d-announce-bounces@= ietf.org=20 [mailto:i-d-announce-
bounces@ietf.org] De la part d= e internet-drafts@ietf.org=20
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Obj= et :=20 I-D Action:
draft-boucadair-intarea-host-identifier-scenari= os-02.txt


A New Internet-Draft is available fro= m the=20 on-line Internet-Drafts
directories.


     Title=20           : Host= =20 Identification: Use Cases
     Author(= s)=20       : Mohamed=20 Boucadair
        = ;            &n= bsp;    David=20 Binet
        = ;            &n= bsp;    Sophie=20 Durel
        = ;            &n= bsp;    Tirumaleswar=20 Reddy
        = ;            &n= bsp;    Brandon=20 Williams
     Filenam= e=20        :=20 draft-boucadair-intarea-host-identifier-
scenarios-02.txt
     Pages=20           :=20 14
     Date=20            := =20 2012-12-02

Abstract:
  This document describes a= set=20 of scenarios in which host
  identification is=20 required.


The IETF datatracker status page for = this=20 draft is:
https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-
identifier-scenarios

There's also a htmlized version avail= able=20 at:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifie= r-
scenarios-02

A diff from the previous version is=20 available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host-=
identifier-scenarios-02


Internet-Drafts are also available by= =20 anonymous FTP at:
ftp://ftp.ietf.org/int= ernet-drafts/

_______________________________________________=
I-D-Announce mailing=20 list
I-D-Announce@ietf.org
https:/= /www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow= .html=20 or
ftp://ftp.ietf.o= rg/ietf/1shadow-sites.txt
_______________________________________________=
Int-area mailing=20 list
Int-area@ietf.org
<= /BLOCKQUOTE>
https://www= .ietf.org/mailman/listinfo/int-area

This E-mail and any of its attachments = may=20 contain Time Warner
Cable proprietary information, which is= =20 privileged,
confidential, or subject to copyright=20 belonging to Time Warner
Cable. This E-mail is intended solely f= or=20 the use of the
individual or entity to which it is=20 addressed. If you are not
the intended recipient of this E-mail, = you=20 are hereby notified
that any dissemination, distribution,=20 copying, or action taken
in relation to the contents of and=20 attachments to this E-mail
is strictly prohibited and may be unlaw= ful.=20 If you have
received this E-mail in error, please n= otify=20 the sender
immediately and permanently delete the= =20 original and any copy
of this E-mail and any=20 printout.

_____________________= __________________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.iet= f.org/mailman/listinfo/int-area
--_000_94C682931C08B048B7A8645303FDC9F36E9B6B67B2PUEXCB1Bnante_-- From Tina.Tsou.Zouting@huawei.com Mon Dec 10 11:04:37 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5C821F8612; Mon, 10 Dec 2012 11:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7TPL1h1+4if; Mon, 10 Dec 2012 11:04:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0B21F85E8; Mon, 10 Dec 2012 11:04:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANR04932; Mon, 10 Dec 2012 19:04:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Dec 2012 19:03:38 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 03:04:07 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 10 Dec 2012 11:04:06 -0800 From: Tina TSOU To: "mohamed.boucadair@orange.com" Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DJgRmtZAgADO0+Y= Date: Mon, 10 Dec 2012 19:04:04 +0000 Message-ID: <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38E2142379724EFEA233B2CB37448B7Bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 10 Dec 2012 11:15:52 -0800 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" , "George, Wes" Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:04:37 -0000 --_000_38E2142379724EFEA233B2CB37448B7Bhuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Med et al, In line... Thank you, Tina On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com" > wrote: Hi Tina, Many thanks for the comments. Please see inline. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 08:16 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@to= ols.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios 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 =93draft-ietf-intarea-nat-reveal-analysis=94. Is it= correct? If it is , I suggest this document be referenced in =93nat-reveal= -analysis=94. [Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use ca= ses draft adopts a more generic scope in which host identification issue is= encountered (this can be caused by address sharing, tunnelling, involvemen= t of multiple administrative entities, etc.). 2. Regarding this document, in the section of CGN use case, the statel= ess NAT44 case should be included. [Med] Do you mean 1:1 NAT? [Tina] I meant the case in this document: http://datatracker.ietf.org/doc/d= raft-tsou-stateless-nat44/, did not mean to just promote my own draft thoug= h. 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 s= ession request, e.g., SIP. [Med] What does that mean? The goal of fig.6 is to illustrate the case wher= e there is a host identification issue. [Tina] In section 7, it says =93The main issue is: PCEF, PCRF and AF all re= ceive information bound to the same UE but without being able to correlate = between the piece of data visible for each entity.=94 In PCRF architecture, the AF receives service request from the UE for servi= ce 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 On Dec 4, 2012, at 11:10 PM, "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=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (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 sol= ution 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 d= iscussion 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. Th= e 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:i= nt-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 [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 --_000_38E2142379724EFEA233B2CB37448B7Bhuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

Hi Tina,
 
Many thanks for the comment= s.
 
Please see inline.
 
Cheers,
Med

De : Tina TSOU [mailto:Tina.Ts= ou.Zouting@huawei.com]
Envoy=E9 : vendredi 7 d=E9cembre 2012 08:16
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; fmc@ietf.org<= /a>; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-= scenarios

Dear Med et al,

I= n general, I like the current version. Some comments are below.<= /span>

1.      From my understanding, this document provides the use cases for the issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis=94. I= s it correct? If it is , I suggest this document be referenced in =93nat-re= veal-analysis=94.
[Med] nat-reveal-analysis draft inherits its&nbs= p;scope from RFC6269. The use cases draft adopts a more generic s= cope in which host identification issue is encountered (this can be caused by address sharing, tunnelling, involvement of multiple admini= strative entities, etc.). 

 

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

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

 

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 th= e 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 identifica= tion issue.

[Tina] In section 7, it says =93The main issue is= : PCEF, PCRF and AF all receive information bound to the same UE but withou= t being able to correlate between the piece of data visible for each entity.=94 
In PCRF architecture, the AF receives service request from the UE for service establishment, which is o= ne 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

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@twca= ble.com]
Envoy=E9 : mardi 4 d=E9cembre 2012 21:09
=C0 : 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-id= entifier-scenarios

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

However, it's really unclear to me what the= value of this
draft might be in its current form, and wha= t its intended
audience might be. Cataloging use cases is = not all that
helpful by itself without an end goal in mi= nd, 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 sha= re the same
  issue of host identification.

  This document does not include any solution-specific disc= ussion.
  This document can be used as a tool to design solution(s)= mitigating
  the encountered issues.  Having a generic solution w= hich would solve
  the issues encountered in these use cases is preferred ov= er designing
  a solution for each use case.  Describing the use ca= se allows to
  identify what is common between the use cases and then wo= uld help
  during the solution design phase."

Next updates of this draft will:
* include a discussion section to assess whether the issue is valid f= or 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 sam= e 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 followin= g:
(1) are these use cases valid ones?
(2) if this is a real technical problem, what the IETF can do to solv= e the issue?
(3) if there is interest in this area, how to organize the work for t= he solution space.

The scope is deliberately
very narrow and references other drafts tha= t discuss some of
the surrounding issues with address sharing= and unique
identifiers, and so there is very little te= xt in each section
beyond a basic description. Even when you t= hink of this in
terms of follow-on drafts such as a gap ana= lysis or problem
statement or solution drafts, one wonders h= ow useful it is to
spread this across multiple drafts. So why = not simply
incorporate this list into one of the refer= enced general
drafts on host identification, such as nat-= reveal-analysis and
then broaden that draft so that it consider= s and addresses the
other use cases as appropriate?

Med: As I mentioned above, we don't want to include any solution-spec= ific 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 rem= ain a standalone
document, the authors need to make at least= some attempt at
discussing security and privacy considerati= ons 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#sectio= n-3 will be added to the next rev of the draft. The text will also incl= ude some discussion for use cases which are restricted to one single admini= strative domain.


Again, here is an area where
being clear about the specific consideratio= ns 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 an= y number of ways
that will mean that they have unique privac= y 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@iet= f.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 dra= ft to list use cases which
encounter the issue of host identification.= The following
use cases are
discussed in the draft:

  (1)  Carrier Grade NAT (CG= N)
  (2)  A+P (e.g., MAP )<= /span>
  (3)  Application Proxies
  (4)  Provider Wi-Fi=
  (5)  Policy and Charging A= rchitectures
  (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 descr= ibe 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=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available from the = on-line Internet-Drafts
directories.


     Title  &= nbsp;        : Host Identification:= Use Cases
     Author(s) &nb= sp;     : Mohamed Boucadair
       &= nbsp;           &nbs= p;     David Binet
       &= nbsp;           &nbs= p;     Sophie Durel
       &= nbsp;           &nbs= p;     Tirumaleswar Reddy
       &= nbsp;           &nbs= p;     Brandon Williams
     Filename &nbs= p;      : draft-boucadair-intarea-host-identi= fier-
scenarios-02.txt
     Pages  &= nbsp;        : 14
     Date  &n= bsp;         : 2012-12-02

Abstract:
  This document describes a set o= f scenarios in which host
  identification is required.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/draft-bouc= adair-intarea-host-
identifier-scenarios

There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-bouca= dair-intarea-host-identifier-
scenarios-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= boucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also available by anony= mous 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<= /span>
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___________________________________________= ____
Int-area mailing list
Int-ar= ea@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 pri= vileged,
confidential, or subject to copyright belon= ging to Time Warner
Cable. This E-mail is intended solely for t= he use of the
individual or entity to which it is address= ed. If you are not
the intended recipient of this E-mail, you = are hereby notified
that any dissemination, distribution, copyi= ng, or action taken
in relation to the contents of and attachme= nts to this E-mail
is strictly prohibited and may be unlawful.= If you have
received this E-mail in error, please notif= y the sender
immediately and permanently delete the orig= inal and any copy
of this E-mail and any printout.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://ww= w.ietf.org/mailman/listinfo/int-area
--_000_38E2142379724EFEA233B2CB37448B7Bhuaweicom_-- From mohamed.boucadair@orange.com Tue Dec 11 01:32:03 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F094C21F87A2; Tue, 11 Dec 2012 01:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Guh9eKEQgyCc; Tue, 11 Dec 2012 01:32:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8419F21F878B; Tue, 11 Dec 2012 01:32:01 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3AD193245C4; Tue, 11 Dec 2012 10:32:00 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1560627C06E; Tue, 11 Dec 2012 10:32:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 11 Dec 2012 10:31:59 +0100 From: To: Tina TSOU Date: Tue, 11 Dec 2012 10:31:58 +0100 Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DJgRmtZAgADO0+aAAMn8oA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E9B6B6D91@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com> In-Reply-To: <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.11.90324 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" , "George, Wes" Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 09:32:03 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tina, Thank you for the clarification. I updated the draft with a pointer to SLNA= T44. I prefer to not modify fig.6 (keep it simple + we are not dealing with sign= alling flows issued from the UE). Thanks for the review. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : lundi 10 d=E9cembre 2012 20:04 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-= host-identifier-scenarios@tools.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Dear Med et al, In line... Thank you, Tina On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com" > wrote: Hi Tina, Many thanks for the comments. Please see inline. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 08:16 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@to= ols.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios 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 cor= rect? If it is , I suggest this document be referenced in "nat-reveal-analy= sis". [Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use ca= ses draft adopts a more generic scope in which host identification issue is= encountered (this can be caused by address sharing, tunnelling, involvemen= t of multiple administrative entities, etc.). 2. Regarding this document, in the section of CGN use case, the statel= ess NAT44 case should be included. [Med] Do you mean 1:1 NAT? [Tina] I meant the case in this document: http://datatracker.ietf.org/doc/d= raft-tsou-stateless-nat44/, did not mean to just promote my own draft thoug= h. 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 s= ession request, e.g., SIP. [Med] What does that mean? The goal of fig.6 is to illustrate the case wher= e there is a host identification issue. [Tina] In section 7, it says "The main issue is: PCEF, PCRF and AF all rece= ive information bound to the same UE but without being able to correlate be= tween the piece of data visible for each entity." In PCRF architecture, the AF receives service request from the UE for servi= ce 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. --_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
Thank you for the clarification. I updated the d= raft=20 with a pointer to SLNAT44.
 
I prefer to not modify fig.6 (keep it simple + <= SPAN=20 class=3D177000707-11122012>we are not dealing with signalling flows issued = from=20 the UE).
 
Thanks for the review.
 
Cheers,
Med

De : Tina TSOU=20 [mailto:Tina.Tsou.Zouting@huawei.com]
Envoy=E9 : lundi 10= =20 d=E9cembre 2012 20:04
=C0 : BOUCADAIR Mohamed=20 OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org= ;=20 draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
Ob= jet :=20 Re: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com= "=20 <mohamed.boucadair@orange.com= >=20 wrote:

Hi Tina,
 
Many thanks for the comments.
 
Please see inline.
 
Cheers,
Med

De : Tina TSOU=20 [mailto:Tina.Tsou.Zouting@huawei.com]
Envoy=E9 : vend= redi 7=20 d=E9cembre 2012 08:16
=C0 : BOUCADAIR Mohamed=20 OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.or= g
Objet :=20 Re: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,

In=20 general, I like the current version. Some comments are=20 below.

1.     &= nbsp;From my understanding, this document provides the use ca= ses for=20 the issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis= =94. Is it=20 correct? If it is , I suggest this document be referenced in=20 =93nat-reveal-analysis=94.
[Med] nat-reveal-a= nalysis=20 draft inherits its scope from RFC6269. The use cases=20 draft adopts a more generic scope in which host identification i= ssue=20 is encountered (this can be caused by address sharing,=20 tunnelling, involvement of multiple administrative entities= ,=20 etc.). 

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

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

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

4.     &= nbsp;In figure 6, the UE may have an interface with AF to ini= tiate=20 the session request, e.g., SIP.
<= FONT=20 color=3D#0000ff size=3D2 face=3D"Courier New">[Med] What does=20 that mean? The goal of fig.6 is to illustrat= e the=20 case where there is a host identification issue.=20

[Tina]=  In section 7, it says =93The main issue is: PCEF, PCRF= and AF=20 all receive information bound to the same UE but without being able to=20 correlate between the piece of data visible for each entity.=94 
In PCRF architecture, the AF receives service re= quest=20 from the UE for service establishment, which is one of the ways for AF to= =20 receive UE information, e.g., user ID. To make the architecture more gene= ric,=20 there should be an interface between AF and UE.=20
 
--_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_-- From hasnaa.moustafa@gmail.com Tue Dec 11 11:22:17 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92BB21F882B for ; Tue, 11 Dec 2012 11:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e91LtI58UWsP for ; Tue, 11 Dec 2012 11:22:15 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2621F8825 for ; Tue, 11 Dec 2012 11:22:15 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4371544vbb.31 for ; Tue, 11 Dec 2012 11:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KxVQ0zUvM17/Yw6pYSxEmWpe2kJ5IOu14jNgWuX4qBs=; b=HTPwLxGNaNykLfpYcbRyonoBRyNfYKzisLdDvyZWZ6PfZrgsasJg9L33zTxF1Hs3Nb j38GyaezNSdUfb75S/Zc7j2LS2hHmUqov3t7vMSZNt9DPSClTzxg7hOOCez4F5Iq6cra 1C+Q+rg+P8mmZv2GWQKIUJau1+VzbYzQ98vGQS2m1JisSyg0ilepRktEHnvSKRnHVJUT oLVx38V8zpJZpu4Im9yCqAUp8/m1wC3oupFPETgeAD2d+B+EjQPeZ3QxxaXKEb96w2yZ 94UDAEC7PUJnrbqiHQ1tKt8xyHrzG/PGdv8bw/2rf60+b4Pq3c/S9oTsK7P65hU5xrIP FKpQ== MIME-Version: 1.0 Received: by 10.58.187.84 with SMTP id fq20mr12294675vec.25.1355253734644; Tue, 11 Dec 2012 11:22:14 -0800 (PST) Received: by 10.58.252.37 with HTTP; Tue, 11 Dec 2012 11:22:14 -0800 (PST) In-Reply-To: <2F5ACECE-17DE-4088-8CF6-CBBD115CD4EF@gmail.com> References: <2F5ACECE-17DE-4088-8CF6-CBBD115CD4EF@gmail.com> Date: Tue, 11 Dec 2012 11:22:14 -0800 Message-ID: From: Hasnaa Moustafa To: fmc@ietf.org Content-Type: multipart/alternative; boundary=047d7b6d80626f19dd04d0989987 Subject: Re: [fmc] fmc Digest, Vol 9, Issue 3 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:22:17 -0000 --047d7b6d80626f19dd04d0989987 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. 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 ? I thought to share thes epoints with you and with all the list for more feedback. Kind regards, Hassnaa On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Moustafa 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 > *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" > *Cc: *"draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" = < > draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>, " > int-area@ietf.org" , "fmc@ietf.org" , > "George, Wes" > > > 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 =93draft-ietf-intarea-nat-reveal-analysis=94. = Is it > correct? If it is , I suggest this document be referenced in > =93nat-reveal-analysis=94.**** > 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=E9 : mardi 4 d=E9cembre 2012 21:09 > > =C0 : 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 th= e > 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#sect= ion-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 administrativ= e > 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=E9 : lundi > > 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 > > > --047d7b6d80626f19dd04d0989987 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
=A0=20

Dear Med,

=A0

I read the draft and have some issues to discuss on the use-cases.<= /p>

I think that Host-ID would be useful for the case of Home Networks in a sc= enario as follows:

-=A0 Several hosts exist in the home network that = can belong to the same or multiple users

-=A0 The NAT functionality could be carried out either in the = RG or in another Border node

-=A0 The host access could be through WiFi AP, FAP or even Eth= ernet (e.g. connected TV)

-=A0 Video streaming is the popular application/traffic in hom= e network through the different hosts

-=A0 Each host is considered as a device with different charac= teristics (i.e. requiring the end server to=A0 distingui= sh each device to provide the adequate content for each host) for better Qo= E

- Each host has a private IPv4 address while there is one shar= ed public IPv4 address by all the Home Network

-=A0 Consequently, a HostID solution is beneficial in this use= case

=A0

I am not sure if the motivation for Host-ID need in such scena= rio matches the objective of Host-ID in your draft and if this scenario=A0i= s implicitly covered in some of the use-cases mentioned in the draft.

= =A0

= Another case that could be checked maybe is the HetNets scenario. According= to 3GPP definition for HetNets/small cells: Small cells are lower power no= des working in the same frequency as the macro cell nodes, and the heteroge= neity of the network comes from the varying power levels within the deploye= d nodes.

= A host could be attached to one or more small cells and could be simultaneo= usly attached to a small cell and a macro cell at the same time. Private IP= v4 addresses are assigned in each cell (macro or pico), and there could be = =A0several scenarios as follows:

<= span style=3D"LINE-HEIGHT:115%;FONT-SIZE:10pt">-=A0=A0=A0= =A0=A0=A0=A0=A0 host attached to= only the macro cell: similar HostID issue to the cellular network use-case=

= -=A0=A0= =A0=A0=A0=A0=A0=A0 host attached= to only a small cell: similar HostID issue to the case of cellular network= use-case

<= span style=3D"LINE-HEIGHT:115%;FONT-SIZE:10pt">-=A0=A0=A0= =A0=A0=A0=A0=A0 host attached to= both the=A0 macro cell=A0 and a smal= l cell: Selected IP Traffic Offload is enabled by NAT based on operator pol= icies (e.g. per IP address) [3GPP TR 23.829]. Here there might be a new iss= ue ?

=A0

=A0

I thought to share thes epoints with you and with all the list= for more feedback.

=A0

Kind regards,

Hassnaa

=A0


=A0
On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Moustafa= <hasnaa.moustafa@gmail.com> wrote:


Begin forwarded message:

Subject: fmc Digest, Vol 9, Issue 3
Date: December 7, 2012 12:27:41 AM PST
Reply-To: fmc@ietf.org

If you have received this digest without all the indi= vidual message
attachments you will need to update your digest options i= n your list
subscription. =A0To do so, go to

https://www.ietf.org/m= ailman/listinfo/fmc

Click the 'Unsubscribe or edit options' button, log in, and set= "Get
MIME or Plain Text Digests?" to MIME. =A0You can set thi= s 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, vis= it
https://www.ietf.org/mailman/listi= nfo/fmc
or, via email, send a message with subject or body 'help= ' to
fmc-request@ietf.org

You can reach th= e person managing the list at
fmc-owner@ietf.or= g

When replying, please edit your Subject line so it is more specific
= than "Re: Contents of fmc digest..."
Today's T= opics:

=A0=A01. Re: [Int-area]
=A0=A0=A0=A0=A0draft-boucadair-int= area-host-identifier-scenarios (Tina TSOU)

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Subject: Re: [fmc] [Int-area] draft-boucadair-intare= a-host-identifier-scenarios
Date: December 6, 2012 11:16:00 PM PST


Dear Med et al,
In general, I like t= he current version. Some comments are below.
1.=A0=A0=A0=A0=A0= =A0From my understanding, this do= cument provides the use cases for the issues and analysis in =93draft-ietf-= intarea-nat-reveal-analysis=94. Is it correct? If it is , I suggest this do= cument be referenced in =93nat-reveal-analysis=94.
2.=A0=A0=A0=A0=A0= =A0Regarding this document, in th= e section of CGN use case, the stateless NAT44 case should be included.<= /u>
3.=A0=A0=A0=A0=A0= =A0For A+P section, the MAP/Lw4ov= er6 cases may be considered.
4.=A0=A0=A0=A0=A0= =A0In figure 6, the UE may have a= n 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" &= lt;mohame= d.boucadair@orange.com> wrote:

Dear Wes,

Thank you for your co= mments.

Please see inline.

Cheers,
Med
-----Message d'origine-----
<= /blockquote>
De : George, Wes [mailto:wesley.george@twcable.com]=
Envoy=E9 : mardi 4 d=E9cembre 2012 21:09
=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org
Cc : draft-bouca= dair-intarea-host-identifier-scenarios@tools.ietf.org
Objet : RE: draft-boucadair-intarea-host-id= entifier-scenarios

I've read this draft, and I think the u= se 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 wha= t its intended
audience might be. Cataloging use cases is = not all that
helpful by itself without an end goal in mi= nd, 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
=A0=A0identify scenarios the authors are aware of and which share the= same
=A0=A0issue of host identification.
<= /span>
=A0=A0This document does not include any solution-specific = discussion.
=A0=A0This document can be used as a tool to design solution(s) mitig= ating
=A0=A0the encountered issues. =A0Having a generic sol= ution which would solve
=A0=A0the issues encountered in the= se use cases is preferred over designing
=A0=A0a solution for each use case. =A0Describing the use case allows= to
=A0=A0identify what is common between the use cases and= then would help
=A0=A0during the solution design phase.&qu= ot;

Next updates of this draft will:
* i= nclude a discussion section to assess whether the issue is valid for IPv4-o= nly 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 sam= e 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 t= he solution space.

The scope is deliberately
very narrow and references other drafts tha= t discuss some of
the surrounding issues with address sharing= and unique
identifiers, and so there is very little te= xt in each section
beyond a basic description. Even when you t= hink of this in
terms of follow-on drafts such as a gap ana= lysis or problem
statement or solution drafts, one wonders h= ow useful it is to
spread this across multiple drafts. So why = not simply
incorporate this list into one of the refer= enced general
drafts on host identification, such as nat-= reveal-analysis and
then broaden that draft so that it consider= s and addresses the
other use cases as appropriate?
<= /blockquote>
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. T= his will be added to the next rev of the draft.


I also believe that if this draft is to rem= ain a standalone
document, the authors need to make at least= some attempt at
discussing security and privacy considerati= ons 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 t= ext 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 consideratio= ns 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 an= y number of ways
that will mean that they have unique privac= y and security
considerations.

Thanks,

Wes George

-----Original Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.o= rg] 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-boucad= air-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 dra= ft to list use cases which
encounter the issue of host identification.= The following
use cases are
discussed in the draft:

=A0=A0(1) =A0Carrier Grade NAT (CGN)=
=A0=A0(2) =A0A+P (e.g., MAP )
=A0=A0(3) =A0Application Proxies
=
=A0=A0(4) =A0Provider Wi-Fi
=A0=A0(5) =A0Policy and Charging Architectu= res
=A0=A0(6) =A0Cellular Networks
=A0=A0(7) =A0Femtocells
=A0=A0(8) =A0Overlay Networks (e.g., CDNs)<= /span>

The document does not include any solution-= specific
discussion. Its main
goal is to identify the use cases and descr= ibe 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-----
<= /blockquote>
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-
=
bounces@ietf.org] De la part de internet-drafts@ietf.org
=
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Obj= et : I-D Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available from the = on-line Internet-Drafts
directories.


=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: Host Identification: Use Cases
=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0= : Mohamed Boucadair
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0David Binet
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Sophie Durel
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Tirumaleswar Reddy
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Brandon Williams
=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0= =A0: draft-boucadair-intarea-host-identifier-
scenarios-02.txt
=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 14
=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0: 2012-12-02

Abstract:
=A0=A0This document describes a set of scen= arios in which host
=A0=A0identification is required.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.= org/doc/draft-boucadair-intarea-host-
identifier-scenarios

There's also a htmlized version availab= le at:
http://tools.ietf.or= g/html/draft-boucadair-intarea-host-identifier-
=
scenarios-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfc= diff?url2=3Ddraft-boucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also available by anony= mous 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.h= tml or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= /span>
___________________________________________= ____
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 pri= vileged,
confidential, or subject to copyright belon= ging to Time Warner
Cable. This E-mail is intended solely for t= he use of the
individual or entity to which it is address= ed. If you are not
the intended recipient of this E-mail, you = are hereby notified
that any dissemination, distribution, copyi= ng, or action taken
in relation to the contents of and attachme= nts to this E-mail
is strictly prohibited and may be unlawful.= If you have
received this E-mail in error, please notif= y the sender
immediately and permanently delete the orig= inal and any copy
of this E-mail and any printout.
=

_____________= __________________________________
Int-area mailing list
Int-ar= ea@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
=


_______________________________________________<= br> fmc mailing list
fmc@i= etf.org
https://www.ietf.org/mailman/listinfo/fmc
<= /div>

--047d7b6d80626f19dd04d0989987-- From mohamed.boucadair@orange.com Wed Dec 12 23:01:26 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E03421F8A8F for ; Wed, 12 Dec 2012 23:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP9naLlCkCN4 for ; Wed, 12 Dec 2012 23:01:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9804821F8A9E for ; Wed, 12 Dec 2012 23:01:23 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7FD6922C1FF; Thu, 13 Dec 2012 08:01:22 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5F33835C058; Thu, 13 Dec 2012 08:01:22 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 13 Dec 2012 08:01:22 +0100 From: To: Hasnaa Moustafa , "fmc@ietf.org" Date: Thu, 13 Dec 2012 08:01:21 +0100 Thread-Topic: [fmc] fmc Digest, Vol 9, Issue 3 Thread-Index: Ac3X1Nj+cLzTgsZCSAa/Ma34iENeRgBKLaCw Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D16DAF3@PUEXCB1B.nanterre.francetelecom.fr> References: <2F5ACECE-17DE-4088-8CF6-CBBD115CD4EF@gmail.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9D16DAF3PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.13.50327 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [fmc] fmc Digest, Vol 9, Issue 3 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:01:26 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9D16DAF3PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Hasna= a Moustafa Envoy=E9 : mardi 11 d=E9cembre 2012 20:22 =C0 : 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 sce= nario as follows: - Several hosts exist in the home network that can belong to the same or m= ultiple users - The NAT functionality could be carried out either in the RG or in anothe= r Border node - The host access could be through WiFi AP, FAP or even Ethernet (e.g. con= nected TV) - Video streaming is the popular application/traffic in home network throu= gh 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 adequa= te content for each host) for better QoE - Each host has a private IPv4 address while there is one shared public IPv= 4 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 t= he objective of Host-ID in your draft and if this scenario is implicitly co= vered 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 ser= ver 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 no= des working in the same frequency as the macro cell nodes, and the heteroge= neity of the network comes from the varying power levels within the deploye= d nodes. A host could be attached to one or more small cells and could be simultaneo= usly attached to a small cell and a macro cell at the same time. Private IP= v4 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 c= ase 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 s= ub-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 fo= r both IPv4 and IPv6. I thought to share thes epoints with you and with all the list for more fe= edback. [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 > 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 > Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scena= rios Date: December 6, 2012 11:16:00 PM PST To: "mohamed.boucadair@orange.com" > Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" >, "int-area@ietf.= org" = >, "fmc@ietf.org" >,= "George, Wes" = > 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 cor= rect? If it is , I suggest this document be referenced in "nat-reveal-analy= sis". 2. Regarding this document, in the section of CGN use case, the statel= ess 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 s= ession request, e.g., SIP. Thank you, Tina On Dec 4, 2012, at 11:10 PM, "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=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (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 sol= ution 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 d= iscussion 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. Th= e 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:i= nt-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 [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 --_000_94C682931C08B048B7A8645303FDC9F36E9D16DAF3PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Hasnaa,
 
Thank you for reading the draft.
 
Please see inline.
Cheers,
Med

De : fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] De la part de Hasnaa=20 Moustafa
Envoy=E9 : mardi 11 d=E9cembre 2012=20 20:22
=C0 : fmc@ietf.org
Objet : Re: [fmc] = fmc=20 Digest, Vol 9, Issue 3

 =20

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt">Dear=20 Med,

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt"> = ;

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt">I read the d= raft=20 and have some issues to discuss on the use-cases.

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt">I think that= =20 Host-ID would be useful for the case of Home Networks in a scenario as=20 follows:

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt">- =20

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">- =20 The NAT functionality could be carried out either in the RG or in another= =20 Border node

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">- =20 The host access could be through WiFi AP, FAP or even Ethernet (e.g. conn= ected=20 TV)

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">- =20 Video streaming is the popular application/traffic in home network throug= h the=20 different hosts

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">- =20 Each host is considered as a device with different characteristics (i.e.= =20 requiring the end server to  distinguish each device to= =20 provide the adequate content for each host) for better QoE

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">-=20 Each host has a private IPv4 address while there is one shared public IPv= 4=20 address by all the Home Network

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">- =20 Consequently, a HostID solution is beneficial in this use case

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt"> = ;

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">I am=20 not sure if the motivation for Host-ID need in such scenario matches the= =20 objective of Host-ID in your draft and if this scenario is implicitl= y=20 covered in some of the use-cases mentioned in the draft.

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">[Med] Wouldn't this be achieved at the=20 application level? announce/discover the device capabilities an= d=20 then the server will adapt the way it will server the=20 device? 

 

Another=20 case that could be checked maybe is the HetNets scenario. According to 3G= PP=20 definition for HetNets/small cells: Small cells are lower power nodes wor= king=20 in the same frequency as the macro cell nodes, and the heterogeneity of t= he=20 network comes from the varying power levels within the deployed=20 nodes.

A=20 host could be attached to one or more small cells and could be simultaneo= usly=20 attached to a small cell and a macro cell at the same time. Private IPv4= =20 addresses are assigned in each cell (macro or pico), and there could be=20  several scenarios as follows:

= -      = ;  =20 host=20 attached to only the macro cell: similar HostID issue to the cellular net= work=20 use-case

-      = ;  =20 host=20 attached to only a small cell: similar HostID issue to the case of cellul= ar=20 network use-case

= -      = ;  =20 host=20 attached to both the  macro cell  and= a=20 small cell: Selected IP Traffic Offload is enabled by NAT based on operat= or=20 policies (e.g. per IP address) [3GPP TR 23.829]. Here there might be a ne= w=20 issue ?

<= SPAN=20 class=3D995204606-13122012>[Med] Thank you for sharing this use case. From= an IP=20 perspective, the way cells are engineered isn't orthogonal to identificat= ion=20 issues? The SIPTO sub-case is IMHO important to consider not only for the= =20 small cell case but in for mobile networks in general. The SIPTO case may= =20 induce some issues for both IPv4 and IPv6.

<= SPAN=20 class=3D995204606-13122012> 

<= SPAN=20 class=3D995204606-13122012> 

<= SPAN=20 class=3D995204606-13122012> I thought to share thes epoints w= ith you=20 and with all the list for more feedback.
[Med] Many thanks for sharing your=20 thoughts. I will be more than please to integrate you text on the SI= PTO=20 case.  

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt"> = ;

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">Kind=20 regards,

<= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'; COLOR: black; FONT-SIZE: 10pt= ">Hassnaa

&= nbsp;


 
On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Moustafa= <hasnaa.moustafa@gmail.com> wrote:


Begin forwarded message:

From:=20 fmc-request@ietf.org
Subject:=20 fmc Digest, = Vol 9,=20 Issue 3
Date:=20 December 7, 201= 2=20 12:27:41 AM PST
To:=20 fmc@ietf.org
Reply-To:=20 fmc@ietf.org

If you have received this digest without all the= =20 individual message
attachments you will need to update your digest= =20 options in your list
subscription.  To do so, go to

<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/fmc"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/fmc

= Click=20 the 'Unsubscribe or edit options' button, log in, and set "Get
MIM= E or=20 Plain Text Digests?" to MIME.  You can set this option
global= ly=20 for all the list digests you receive at this point.



Se= nd=20 fmc mailing list submissions to
fmc@ietf.org

To subscribe or unsubscribe v= ia the=20 World Wide Web, visit
https://www.ietf.org/mailman/listinfo/fmc
or, = via=20 email, send a message with subject or body 'help' to
fmc-request@ietf.org

You can reach the per= son=20 managing the list at
= fmc-owner@ietf.org

When replying, please e= dit=20 your Subject line so it is more specific
than "Re: Contents of fmc= =20 digest..."
Today's Topics:

  1. Re:=20 [Int-area]
     draft-boucadair-intarea-h= ost-identifier-scenarios=20 (Tina TSOU)

From:=20 Tina.Tsou.Zouting@huawei.com>
Subject:=20 Re: [fmc]=20 [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios
Date:=20 December 6, 201= 2=20 11:16:00 PM PST
To:=20 mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Cc:=20 draft-boucadair-intarea-host-identifier-scenarios@too= ls.ietf.org"=20 <draft-boucadair-intarea-host-identifier-scenarios@too= ls.ietf.org>,=20 "int-area@ietf.o= rg"=20 <int-area@ietf.org>, "fmc@ietf.org" <fmc@ietf.org>, "George, Wes" <wesley.george@twcable.com>

Dear Med et al,
In general, I l= ike the=20 current version. Some comments are below.
1.     &= nbsp;From my understanding, this document provides the use ca= ses for=20 the issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis= =94. Is it=20 correct? If it is , I suggest this document be referenced in=20 =93nat-reveal-analysis=94.
2.     &= nbsp;Regarding this document, in the section of CGN use case,= the=20 stateless NAT44 case should be included.
3.     &= nbsp;For A+P section, the MAP/Lw4over6 cases may be=20 considered.
4.     &= nbsp;In figure 6, the UE may have an interface with AF to ini= tiate=20 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=20 comments.

Please see inline.=20

Cheers,
Med=20

-----Message=20 d'origine-----
De : George, Wes [mailto:wesley.george@twcable.com]
Envoy=E9 : mardi 4 d=E9cembre 2012= =20 21:09
=C0 : BOUCADAIR Mohamed OLNC/OLN; <= A=20 href=3D"mailto:fmc@ietf.org" target=3D_blank>fmc@ietf.org; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scenarios= @tools.ietf.org
Objet : RE:=20 draft-boucadair-intarea-host-identifier-scenarios

I've read this draft, and I think t= he=20 use case list is
reasonably=20 complete.

However, it's really unclear to me = what=20 the value of this
draft might be in its current form,= and=20 what its intended
audience might be. Cataloging use c= ases=20 is not all that
helpful by itself without an end go= al in=20 mind, and that end
goal is not clear from the=20 draft.

Med: The goa= l of=20 this draft is what is described in Section=20 2:

"The goal is=20 to
  identify scenarios the authors are a= ware=20 of and which share the same
  issue of ho= st=20 identification.

  This=20 document does not include any solution-specific=20 discussion.
  This document can be used a= s a=20 tool to design solution(s) mitigating
  t= he=20 encountered issues.  Having a generic solution which would=20 solve
  the issues encountered in these u= se=20 cases is preferred over designing
  a sol= ution=20 for each use case.  Describing the use case allows=20 to
  identify what is common between the = use=20 cases and then would help
  during the=20 solution design phase."

Next updat= es of=20 this draft will:
* include a discussion section to= =20 assess whether the issue is valid for IPv4-only or it applies also = for=20 IPv6
* include a discussion text to clarify whether= each=20 use case is valid within one single administrative domain or=20 not
* include a discussion text to identify use cas= es=20 which share the same requirements (this will help in designing the= =20 solution)
* add additional use cases if=20 any

At given point in time we need= to=20 draw conclusions about the following:
(1) are these= use=20 cases valid ones?
(2) if this is a real technical=20 problem, what the IETF can do to solve the issue?
(= 3) if=20 there is interest in this area, how to organize the work for the=20 solution space.

The scope is=20 deliberately
very narrow and references other dr= afts=20 that discuss some of
the surrounding issues with address= =20 sharing and unique
identifiers, and so there is very l= ittle=20 text in each section
beyond a basic description. Even wh= en=20 you think of this in
terms of follow-on drafts such as a= gap=20 analysis or problem
statement or solution drafts, one=20 wonders how useful it is to
spread this across multiple drafts.= So=20 why not simply
incorporate this list into one of t= he=20 referenced general
drafts on host identification, such= as=20 nat-reveal-analysis and
then broaden that draft so that it= =20 considers and addresses the
other use cases as=20 appropriate?

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


Otherwise, I think that the draft n= eeds=20 to be much clearer
about the unique issues and=20 considerations for each use case,
especially those that are somehow=20 distinct from those covered
in nat-reveal-analysis so that it c= an=20 serve as a better input
to any potential solutions addressi= ng=20 this problem.

Med: = Fully=20 agreed. This will be added to the next rev of the=20 draft.


I also believe that if this draft i= s to=20 remain a standalone
document, the authors need to make = at=20 least some attempt at
discussing security and privacy=20 considerations here, even if
it is mainly to refer the reader to= more=20 in-depth discussions
of the matter in other=20 drafts.

Med: Agree. A= =20 pointer to http://tools.ietf.org/html/draft-ietf-intarea-nat-r= eveal-analysis-04#section-3=20 will be added to the next rev of the draft. The text will also incl= ude=20 some discussion for use cases which are restricted to one single=20 administrative=20 domain.


Again, he= re is=20 an area where
being clear about the specific=20 considerations for each use
case is important, identifying whet= her=20 the other drafts
discuss things so that they are=20 applicable to all of the use
cases, or if the use cases are uniq= ue in=20 any number of ways
that will mean that they have uniqu= e=20 privacy and security
considerations.

Thanks,

Wes George

-----Original=20 Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org]=20 On
Behalf Of mohamed.boucadair@orange.com
Sent: Monday, December 03, 2012 4= :08=20 AM
To: fmc@ietf.org; int-area@ietf.org
Cc: draft-boucadair-intarea-host-identifier-scenari= os@tools.ietf.org
Subject: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear=20 all,

We submitted an updated version o= f=20 this draft to list use cases which
encounter the issue of host=20 identification. The following
use cases are
discussed in the=20 draft:

  (1)  Carrier Gra= de=20 NAT (CGN)
  (2)  A+P (e.g., = MAP=20 )
  (3)  Application= =20 Proxies
  (4)  Provider=20 Wi-Fi
  (5)  Policy and= =20 Charging Architectures
  (6)  Cellular=20 Networks
  (7)=20  Femtocells
  (8)  Overlay Net= works=20 (e.g., CDNs)

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

If you think your use case is not= =20 included in this version,
please share
it with=20 us.

Comments are=20 welcome.

Cheers,
Med


-----Message=20 d'origine-----
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-
bounces@ietf.org] De la part de internet-drafts@ietf.org=20
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D=20 Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available= from=20 the on-line Internet-Drafts
directories.


     Tit= le=20           : H= ost=20 Identification: Use Cases
     Author(s)=20       : Mohamed=20 Boucadair
       &= nbsp;           &nbs= p;     David=20 Binet
       &= nbsp;           &nbs= p;     Sophie=20 Durel
       &= nbsp;           &nbs= p;     Tirumaleswar=20 Reddy
       &= nbsp;           &nbs= p;     Brandon=20 Williams
     Fil= ename=20        :=20 draft-boucadair-intarea-host-identifier-
scenarios-02.txt
     Pag= es=20           :=20 14
     Dat= e=20           &nb= sp;:=20 2012-12-02

Abstract:
  This document describ= es a=20 set of scenarios in which host
  identification is=20 required.


The IETF datatracker status page = for=20 this draft is:
https://datatracker.ietf.org/doc/draft-boucadai= r-intarea-host-
identifier-scenarios
<= /BLOCKQUOTE>

There's also a htmlized version=20 available at:
http://tools.ietf.org/html/draft-boucadair-inta= rea-host-identifier-
scenarios-02

A diff from the previous version = is=20 available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-boucad= air-intarea-host-
identifier-scenarios-02


Internet-Drafts are also availabl= e by=20 anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<= BR>

___________________________________________= ____
I-D-Announce mailing=20 list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-annou= nce
Internet-Draft directories: http://www.ietf.org/shadow.html=20 or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___________________________________________= ____
Int-area mailing=20 list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area<= /A>

This E-mail and any of its attachme= nts=20 may contain Time Warner
Cable proprietary information, whic= h is=20 privileged,
confidential, or subject to copyrig= ht=20 belonging to Time Warner
Cable. This E-mail is intended sole= ly=20 for the use of the
individual or entity to which it is= =20 addressed. If you are not
the intended recipient of this E-ma= il,=20 you are hereby notified
that any dissemination, distributio= n,=20 copying, or action taken
in relation to the contents of and= =20 attachments to this E-mail
is strictly prohibited and may be=20 unlawful. If you have
received this E-mail in error, plea= se=20 notify the sender
immediately and permanently delete = the=20 original and any copy
of this E-mail and any=20 printout.

_________________= ______________________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area<= /SPAN>


________________________________= _______________
fmc=20 mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc


--_000_94C682931C08B048B7A8645303FDC9F36E9D16DAF3PUEXCB1Bnante_-- From hasnaa.moustafa@gmail.com Thu Dec 13 10:37:41 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E589521F897E for ; Thu, 13 Dec 2012 10:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkiuDt7qhQkk for ; Thu, 13 Dec 2012 10:37:38 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3321F89C6 for ; Thu, 13 Dec 2012 10:37:37 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2745897vbb.31 for ; Thu, 13 Dec 2012 10:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=64JKv/dBodw19g0r/ITkwTRCSGmzdZxOSNcuM/u1JTo=; b=Ibv2bPlSk7//Pv30FSn0CGvEf/Eb5b1aSpXfSU9QVrTRFU8AVuW7yQDnI1WWWjX+YE pDFW4A8G3XHPX/YuuysjSry9fZriFe2dChpXfdS1E91KtWh6+OuSnj0hsFQM0L5JTEhU nSRb4/ijt+h+ICAGSB+hruvM9N9VC7NJTurevwe1DxeMzycz8Kz2QQnMcK1O79rvMcGZ uqjt/IDmqY4QiTuJ6qKgfNbJSHHasysn6eTM6ACnbLgBZsn7Bznirv3VVtHgodYa1dPx bAlYjsyxzULTuheuu1KeIbo5TRMOZPEf6gPZamPJA8MI+V93EKj4De5eeWYcDehMzp55 Z2Fg== MIME-Version: 1.0 Received: by 10.52.35.84 with SMTP id f20mr4393015vdj.95.1355423856880; Thu, 13 Dec 2012 10:37:36 -0800 (PST) Received: by 10.58.252.37 with HTTP; Thu, 13 Dec 2012 10:37:36 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 10:37:36 -0800 Message-ID: From: Hasnaa Moustafa To: fmc@ietf.org Content-Type: multipart/alternative; boundary=20cf3079b75e826afe04d0c035e0 Cc: mohamed.boucadair@orange.com Subject: Re: [fmc] fmc Digest, Vol 9, Issue 7 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 18:37:41 -0000 --20cf3079b75e826afe04d0c035e0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, 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: > To: Hasnaa Moustafa , "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=E9 :* mardi 11 d=E9cembre 2012 20:22 > *=C0 :* 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 low= er > power nodes working in the same frequency as the macro cell nodes, and th= e > heterogeneity of the network comes from the varying power levels within t= he > 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 the= re > 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 wa= y > 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 b= ut > 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 t= o > 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 >> *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" >> *Cc: *"draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" >> , " >> int-area@ietf.org" , "fmc@ietf.org" , >> "George, Wes" >> >> >> 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 =93draft-ietf-intarea-nat-reveal-analysis=94.= Is it >> correct? If it is , I suggest this document be referenced in >> =93nat-reveal-analysis=94.**** >> 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=E9 : mardi 4 d=E9cembre 2012 21:09 >> >> =C0 : 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-specifi= c >> 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#sec= tion-3will be added to the next rev of the draft. The text will also includ= e some >> discussion for use cases which are restricted to one single administrati= ve >> 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=E9 : lundi >> >> 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 > > --20cf3079b75e826afe04d0c035e0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks Med for your clarification.
For yur first question ([Med]=A0Wouldn't this be=A0achieved at the application level?= =A0announce/discover the device capabilities=A0and then the server will ada= pt=A0the way it will server the device?) ---> YES s= ure this is taken care by the application level (as HAS and DASH cases), bu= t the question is: Would doing so by lower layers through the host-ID be be= neficial 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 thoug= ht 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 l= east - but with no strong sureness").
=A0
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)?
=A0
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 dra= ft be a discussion base for FMC (or would be under one of the existing WGs)= ?
=A0
Thanks for this exchange.
=A0
Kind regards,
Hassnaa

On Wed, Dec 12, 2012 at 11:01 PM, <fmc-reque= st@ietf.org> wrote:
If you have received this digest with= out all the individual message
attachments you will need to update your = digest options in your list
subscription. =A0To 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. =A0You can set this option
gl= obally for all the list digests you receive at this point.



S= end fmc mailing list submissions to
=A0 =A0 =A0 =A0 fmc@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 = =A0 =A0 https://www.ietf.org/mailman/listinfo/fmc
or, via email, send a= message with subject or body 'help' to
=A0 =A0 =A0 =A0 fmc-request@ietf.or= g

You can reach the person managing the list at
=A0 =A0 =A0 = =A0 fmc-owner@ietf.org

Whe= n replying, please edit your Subject line so it is more specific
than "Re: Contents of fmc digest..."

Today's Topics:
=A0 =A01. Re: fmc Digest, Vol 9, Issue 3 (mohamed.boucadair@orange.com)


---------= - Forwarded message ----------
From:=A0<mohamed.boucada= ir@orange.com>
To:=A0Hasnaa Moustafa <hasnaa.moustafa@gmail.com>, "fmc@ietf.org" <fmc@ietf.org>
Cc:=A0"draft-boucadair-intarea-host-identifier-scenarios@tool= s.ietf.org" <draft-boucadair-intarea-host-identifier-s= cenarios@tools.ietf.org>
Date:=A0Thu, 13 Dec 2012 08:01:21 +0100
Subject:=A0Re: [fmc] fmc Digest,= Vol 9, Issue 3
Dear Hasnaa,
=A0
Thank you for reading the draft.
=A0
Please see inline.
Cheers,
Med

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part = de Hasnaa Moustafa
Envoy=E9=A0: mardi 11 d=E9cembre 2012 20:22
=C0=A0: fmc@ietf.org
Objet=A0= : Re: [fmc] fmc Digest, Vol 9, Issue 3

=A0=20

Dear Med,

=A0

I read the draft and have some issues to discuss on the use-cases.<= /p>

I think that Host-ID would be useful for the case of Home Networks in a sc= enario as follows:

-=A0 Several hosts exist in the home network that can belong t= o the same or multiple users

-=A0 The NAT functionality could be carried out either in the RG or in ano= ther Border node

-=A0 The host access could be through WiFi AP, FAP or even Ethernet (e.g. = connected TV)

-=A0 Video streaming is the popular application/traffic in home network th= rough the different hosts

-=A0 Each host is considered as a device with different characteristics (i= .e. requiring the end server to=A0 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 IP= v4 address by all the Home Network

-=A0 Consequently, a HostID solution is beneficial in this use case=

=A0

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=A0is implicitly= covered in some of the use-cases mentioned in the draft.

[Med]=A0Wouldn't th= is be=A0achieved at the application level?=A0announce/discover the device c= apabilities=A0and then the server will adapt=A0the way it will server the d= evice?=A0

= =A0

= Another case that could be checked maybe is the HetNets scenario. According= to 3GPP definition for HetNets/small cells: Small cells are lower power no= des working in the same frequency as the macro cell nodes, and the heteroge= neity of the network comes from the varying power levels within the deploye= d nodes.

= A host could be attached to one or more small cells and could be simultaneo= usly attached to a small cell and a macro cell at the same time. Private IP= v4 addresses are assigned in each cell (macro or pico), and there could be = =A0several scenarios as follows:

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to only the macro cell: similar HostID issue= to the cellular network use-case

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to only a small cell: similar HostID issue t= o the case of cellular network use-case

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to both the=A0 macro cell=A0 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 th= ere might be a new issue ?

[Med]=A0Thank you for sharin= g this use case. From an IP perspective, the way cells are engineered isn&#= 39;t orthogonal to identification issues? The SIPTO sub-case is IMHO import= ant 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. =

=A0

=A0

=A0I thought to share thes epoints with you and with all the list = for more feedback.
[M= ed]=A0Many thanks for sharing=A0your thoughts.=A0I will be more than please= to integrate you text on the SIPTO case. =A0

=A0

Kind regards,

Hassnaa

=A0


=A0
On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Moustafa= <hasnaa.moustafa@gmail.com> wrote:


Begin forwarded message:

Subject: fmc Digest, Vol 9, Issue 3
Date: December 7, 2012 12:27:41 AM PST
Reply-To: fmc@ietf.org

If you have received this digest without all the individual messag= e
attachments you will need to update your digest options in your listsubscription. =A0To do so, go to

https://www.ietf.org/mailman/listin= fo/fmc

Click the 'Unsubscribe or edit options' button, log in, and set= "Get
MIME or Plain Text Digests?" to MIME. =A0You can set thi= s 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, vis= it
https://www.ietf.org/mailman/listi= nfo/fmc
or, via email, send a message with subject or body 'help= ' to
fmc-request@ietf.org

You can reach th= e person managing the list at
fmc-owner@ietf.or= g

When replying, please edit your Subject line so it is more specific
= than "Re: Contents of fmc digest..."
Today's T= opics:

=A0=A01. Re: [Int-area]
=A0=A0=A0=A0=A0draft-boucadair-int= area-host-identifier-scenarios (Tina TSOU)

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Subject: Re: [fmc] [Int-area] draft-boucadair-intare= a-host-identifier-scenarios
Date: December 6, 2012 11:16:00 PM PST


Dear Med et al,
In general, I like t= he current version. Some comments are below.
1.=A0=A0=A0=A0=A0= =A0From my understanding, this do= cument provides the use cases for the issues and analysis in =93draft-ietf-= intarea-nat-reveal-analysis=94. Is it correct? If it is , I suggest this do= cument be referenced in =93nat-reveal-analysis=94.
2.=A0=A0=A0=A0=A0= =A0Regarding this document, in th= e section of CGN use case, the stateless NAT44 case should be included.<= /u>
3.=A0=A0=A0=A0=A0= =A0For A+P section, the MAP/Lw4ov= er6 cases may be considered.
4.=A0=A0=A0=A0=A0= =A0In figure 6, the UE may have a= n 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" &= lt;mohame= d.boucadair@orange.com> wrote:

Dear Wes,

Thank you for your co= mments.

Please see inline.

Cheers,
Med
-----Message d'origine-----
<= /blockquote>
De : George, Wes [mailto:wesley.george@twcable.com]=
Envoy=E9 : mardi 4 d=E9cembre 2012 21:09
=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org
Cc : draft-bouca= dair-intarea-host-identifier-scenarios@tools.ietf.org
Objet : RE: draft-boucadair-intarea-host-id= entifier-scenarios

I've read this draft, and I think the u= se 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 wha= t its intended
audience might be. Cataloging use cases is = not all that
helpful by itself without an end goal in mi= nd, 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
=A0=A0identify scenarios the authors are aware of and which share the= same
=A0=A0issue of host identification.
<= /span>
=A0=A0This document does not include any solution-specific = discussion.
=A0=A0This document can be used as a tool to design solution(s) mitig= ating
=A0=A0the encountered issues. =A0Having a generic sol= ution which would solve
=A0=A0the issues encountered in the= se use cases is preferred over designing
=A0=A0a solution for each use case. =A0Describing the use case allows= to
=A0=A0identify what is common between the use cases and= then would help
=A0=A0during the solution design phase.&qu= ot;

Next updates of this draft will:
* i= nclude a discussion section to assess whether the issue is valid for IPv4-o= nly 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 sam= e 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 t= he solution space.

The scope is deliberately
very narrow and references other drafts tha= t discuss some of
the surrounding issues with address sharing= and unique
identifiers, and so there is very little te= xt in each section
beyond a basic description. Even when you t= hink of this in
terms of follow-on drafts such as a gap ana= lysis or problem
statement or solution drafts, one wonders h= ow useful it is to
spread this across multiple drafts. So why = not simply
incorporate this list into one of the refer= enced general
drafts on host identification, such as nat-= reveal-analysis and
then broaden that draft so that it consider= s and addresses the
other use cases as appropriate?
<= /blockquote>
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. T= his will be added to the next rev of the draft.


I also believe that if this draft is to rem= ain a standalone
document, the authors need to make at least= some attempt at
discussing security and privacy considerati= ons 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 t= ext 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 consideratio= ns 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 an= y number of ways
that will mean that they have unique privac= y and security
considerations.

Thanks,

Wes George

-----Original Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.o= rg] 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-boucad= air-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 dra= ft to list use cases which
encounter the issue of host identification.= The following
use cases are
discussed in the draft:

=A0=A0(1) =A0Carrier Grade NAT (CGN)=
=A0=A0(2) =A0A+P (e.g., MAP )
=A0=A0(3) =A0Application Proxies
=
=A0=A0(4) =A0Provider Wi-Fi
=A0=A0(5) =A0Policy and Charging Architectu= res
=A0=A0(6) =A0Cellular Networks
=A0=A0(7) =A0Femtocells
=A0=A0(8) =A0Overlay Networks (e.g., CDNs)<= /span>

The document does not include any solution-= specific
discussion. Its main
goal is to identify the use cases and descr= ibe 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-----
<= /blockquote>
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-
=
bounces@ietf.org] De la part de internet-drafts@ietf.org
=
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Obj= et : I-D Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available from the = on-line Internet-Drafts
directories.


=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: Host Identification: Use Cases
=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0= : Mohamed Boucadair
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0David Binet
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Sophie Durel
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Tirumaleswar Reddy
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Brandon Williams
=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0= =A0: draft-boucadair-intarea-host-identifier-
scenarios-02.txt
=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 14
=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0: 2012-12-02

Abstract:
=A0=A0This document describes a set of scen= arios in which host
=A0=A0identification is required.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.= org/doc/draft-boucadair-intarea-host-
identifier-scenarios

There's also a htmlized version availab= le at:
http://tools.ietf.or= g/html/draft-boucadair-intarea-host-identifier-
=
scenarios-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfc= diff?url2=3Ddraft-boucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also available by anony= mous 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.h= tml or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= /span>
___________________________________________= ____
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 pri= vileged,
confidential, or subject to copyright belon= ging to Time Warner
Cable. This E-mail is intended solely for t= he use of the
individual or entity to which it is address= ed. If you are not
the intended recipient of this E-mail, you = are hereby notified
that any dissemination, distribution, copyi= ng, or action taken
in relation to the contents of and attachme= nts to this E-mail
is strictly prohibited and may be unlawful.= If you have
received this E-mail in error, please notif= y the sender
immediately and permanently delete the orig= inal and any copy
of this E-mail and any printout.
=

_____________= __________________________________
Int-area mailing list
Int-ar= ea@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
=


_______________________________________________<= br> fmc mailing list
fmc@i= etf.org
https://www.ietf.org/mailman/listinfo/fmc
<= /div>


___________________= ____________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc


--20cf3079b75e826afe04d0c035e0-- From mohamed.boucadair@orange.com Thu Dec 13 22:41:55 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0621F8835 for ; Thu, 13 Dec 2012 22:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2jYMjF2Xxte for ; Thu, 13 Dec 2012 22:41:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 44CEA21F880F for ; Thu, 13 Dec 2012 22:41:52 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 03885324304; Fri, 14 Dec 2012 07:41:51 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B6D7623806F; Fri, 14 Dec 2012 07:41:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 14 Dec 2012 07:41:50 +0100 From: To: Hasnaa Moustafa , "fmc@ietf.org" Date: Fri, 14 Dec 2012 07:41:49 +0100 Thread-Topic: fmc Digest, Vol 9, Issue 7 Thread-Index: Ac3ZYO4Jx9yGUxcuRlmFkON8GVc6OAAY+s+w Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D16DF7C@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.14.53317 Subject: Re: [fmc] fmc Digest, Vol 9, Issue 7 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:41:55 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Hasnaa, Please see inline. Cheers, Med ________________________________ De : Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Envoy=E9 : jeudi 13 d=E9cembre 2012 19:38 =C0 : fmc@ietf.org 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 a= dapt the way it will server the device?) ---> YES sure this is taken care b= y 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 g= eneric standardized solution to any application on top? would there be a ag= in? would this way of doing it help? Here, I really have a question rather than a proposal for this I thought sh= aring this point with you and with the mailing list (since the Host-ID issu= e 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 identificat= ion 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/us= er. This is another perspective. I prefer to restrict the scope of the draf= t to only cases where host identification is an issue. For the second point on the SIPTO, I understood that it fits under the Cell= ular 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 emai= ls 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 i= s still "homeless"... Thanks for this exchange. Kind regards, Hassnaa On Wed, Dec 12, 2012 at 11:01 PM, > 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: > To: Hasnaa Moustafa >, "fmc@ietf.org" > Cc: "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=E9 : mardi 11 d=E9cembre 2012 20:22 =C0 : 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 sce= nario as follows: - Several hosts exist in the home network that can belong to the same or m= ultiple users - The NAT functionality could be carried out either in the RG or in anothe= r Border node - The host access could be through WiFi AP, FAP or even Ethernet (e.g. con= nected TV) - Video streaming is the popular application/traffic in home network throu= gh 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 adequa= te content for each host) for better QoE - Each host has a private IPv4 address while there is one shared public IPv= 4 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 t= he objective of Host-ID in your draft and if this scenario is implicitly co= vered 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 ser= ver 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 no= des working in the same frequency as the macro cell nodes, and the heteroge= neity of the network comes from the varying power levels within the deploye= d nodes. A host could be attached to one or more small cells and could be simultaneo= usly attached to a small cell and a macro cell at the same time. Private IP= v4 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 c= ase 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 s= ub-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 fo= r both IPv4 and IPv6. I thought to share thes epoints with you and with all the list for more fe= edback. [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 > 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 > Subject: Re: [fmc] [Int-area] draft-boucadair-intarea-host-identifier-scena= rios Date: December 6, 2012 11:16:00 PM PST To: "mohamed.boucadair@orange.com" > Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" >, "int-area@ietf.= org" = >, "fmc@ietf.org" >,= "George, Wes" = > 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 cor= rect? If it is , I suggest this document be referenced in "nat-reveal-analy= sis". 2. Regarding this document, in the section of CGN use case, the statel= ess 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 s= ession request, e.g., SIP. Thank you, Tina On Dec 4, 2012, at 11:10 PM, "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=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@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 IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (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 sol= ution 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 d= iscussion 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. Th= e 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:i= nt-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 [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : 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=3Ddraft-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 --_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Hasnaa,
 
Please see inline.
 
Cheers,
Med

De : Hasnaa Moustafa=20 [mailto:hasnaa.moustafa@gmail.com]
Envoy=E9 : jeudi 13 d= =E9cembre=20 2012 19:38
=C0 : fmc@ietf.org
Cc : BOUCADAI= R=20 Mohamed OLNC/OLN
Objet : Re: fmc Digest, Vol 9, Issue=20 7

Thanks Med for your clarification.
For yur first question ([Med] Wouldn't this be ach= ieved at=20 the application level? announce/discover the device capabilities&nbs= p;and=20 then the server will adapt the way it will server the=20 device?) ---> YES sure this is taken care by the= =20 application level (as HAS and DASH cases), but the question is: Would doi= ng so=20 by lower layers through the host-ID be beneficial and provide a generic=20 standardized solution to any application on top? would there be a agin? w= ould=20 this way of doing it help?
Here, I really have a question rather than a proposal for this I tho= ught=20 sharing this point with you and with the mailing list (since the Host-ID = issue=20 in the way you describe could help "this is what I thought at least - but= with=20 no strong sureness").
[Med] The current use cases described in the draft p= resent=20 host identification as a problem. The content adaptation case you are=20 describing is looking on how to make use of any HOST_ID proposal to bette= r=20 service the device/user. This is another perspective. I prefer to restric= t the=20 scope of the draft to only cases where host identification is an issue.=20
 
For the second point on the SIPTO, I understood that it fits under t= he=20 Cellular Network use-case in the draft (with no need to include a new use= -case=20 for Heterogeneous networks/Small cells)?
[Med] SIPTO can be introduced as a new use case= in its=20 own.
 
A last question (which was asked before I think in one of the previo= us=20 emails commenting the draft): Would the Host-ID issue mentioned in the dr= aft=20 be a discussion base for FMC (or would be under one of the existing=20 WGs)?
[Med] The goal is to assess whether there is in= terest=20 from the community to solve this problem. The problem space is not restri= cted=20 to FMC but covers various cases which share the same technical=20 problem. Today this document is still "homeless"...
 
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=20 individual message
attachments you will need to update your digest=20 options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/fmc

Cl= ick the=20 'Unsubscribe or edit options' button, log in, and set "Get
MIME or P= lain=20 Text Digests?" to MIME.  You can set this option
globally for a= ll=20 the list digests you receive at this point.



Send fmc mai= ling=20 list submissions to
        fmc@ietf.org

To subscribe or=20 unsubscribe via the World Wide Web, visit
       = ; https://www.ietf.org/mailman/listinfo/fmc
or, vi= a=20 email, send a message with subject or body 'help' to
    &= nbsp;=20   fmc-request@ietf.org

Yo= u can=20 reach the person managing the list at
        fmc-owner@ietf.org

When=20 replying, please edit your Subject line so it is more specific
than = "Re:=20 Contents of fmc digest..."

Today's Topics:

   1= . Re:=20 fmc Digest, Vol 9, Issue 3 (mohamed.boucadair@orange.c= om)


----------=20 Forwarded message ----------
From: <mohamed.boucadair@orange.c= om>
To: Hasnaa=20 Moustafa <hasnaa.moustafa@gmail.com= >,=20 "fmc@ietf.org" <fmc@ietf.org>
Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org<= /A>"=20 <draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org<= /A>>
Date: Thu,=20 13 Dec 2012 08:01:21 +0100
Subject: Re: [fmc] fmc Digest, Vol 9= ,=20 Issue 3
Dear=20 Hasnaa,
 
Thank=20 you for reading the draft.
 
Please=20 see inline.
Cheers,
Med

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf= .org]=20 De la part de Hasnaa Moustafa
Envoy=E9 : mardi = 11=20 d=E9cembre 2012 20:22
=C0 : fmc@ietf.org
Objet : Re: [fmc] fmc= =20 Digest, Vol 9, Issue 3

 =20

Dear=20 Med,

&= nbsp;

I read t= he=20 draft and have some issues to discuss on the use-cases.

I think = that=20 Host-ID would be useful for the case of Home Networks in a scenario a= s=20 follows:

- = =20 Several = hosts=20 exist in the home network that can belong to the same or multiple use= rs=20 <= /P>

-  = The NAT=20 functionality could be carried out either in the RG or in another Bor= der=20 node<= /P>

-  = The=20 host access could be through WiFi AP, FAP or even Ethernet (e.g. conn= ected=20 TV) <= /P>

-  = Video=20 streaming is the popular application/traffic in home network through = the=20 different hosts <= /P>

-  = Each=20 host is considered as a device with different characteristics (i.e.=20 requiring the end server to  distinguish each devic= e to=20 provide the adequate content for each host) for better QoE<= /P>

- Each h= ost has=20 a private IPv4 address while there is one shared public IPv4 address = by=20 all the Home Network<= /P>

- = =20 Consequently, a HostID solution is beneficial in this use case=

&= nbsp;

I am not= sure=20 if the motivation for Host-ID need in such scenario matches the objec= tive=20 of Host-ID in your draft and if this scenario is implicitly cove= red=20 in some of the use-cases mentioned in the draft.

[Med] Wouldn't this be = ;achieved=20 at the application level? announce/discover the device=20 capabilities and then the server will adapt the way it will= =20 server the device? 

 

Another=20 case that could be checked maybe is the HetNets scenario. According t= o=20 3GPP definition for HetNets/small cells: Small cells are lower power = nodes=20 working in the same frequency as the macro cell nodes, and the=20 heterogeneity of the network comes from the varying power levels with= in=20 the deployed nodes.

A=20 host could be attached to one or more small cells and could be=20 simultaneously attached to a small cell and a macro cell at the same = time.=20 Private IPv4 addresses are assigned in each cell (macro or pico), and= =20 there could be  several scenarios as follows:

-     &= nbsp;  =20 host=20 attached to only the macro cell: similar HostID issue to the cellular= =20 network use-case

-     &= nbsp;  =20 host=20 attached to only a small cell: similar HostID issue to the case of=20 cellular network use-case

-     &= nbsp;  =20 host=20 attached to both the  macro cell  and=20 a small cell: Selected IP Traffic Offload is enabled by NAT based on= =20 operator policies (e.g. per IP address) [3GPP TR 23.829]. Here there = might=20 be a new issue ?

[Med] Thank you for sharing this use case. = >From an=20 IP perspective, the way cells are engineered isn't orthogonal to=20 identification issues? The SIPTO sub-case is IMHO important to consid= er=20 not only for the small cell case but in for mobile networks in genera= l.=20 The SIPTO case may induce some issues for both IPv4 and IPv6.=20

 

 

 I thought to share thes epoints = with=20 you and with all the list for more feedback.
[Med] Many thanks for sharing your=20 thoughts. I will be more than please to integrate you text on th= e=20 SIPTO case.  

&= nbsp;

Kind=20 regards,<= /P>

Hassnaa<= /SPAN><= /P> 



 
On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa Mous= tafa=20 <hasnaa.moustafa@gmail.com> wrote:


Begin forwarded message:

From:=20 fmc-request@ietf.org
Subject:= =20 fmc Dige= st, Vol=20 9, Issue 3
Date:=20 December 7,= 2012=20 12:27:41 AM PST
To:=20 fmc@ietf.org
Reply-To= :=20 fmc@ietf.org

If you have received this digest without all the individ= ual=20 message
attachments you will need to update your digest option= s in=20 your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/fmc
=
Click=20 the 'Unsubscribe or edit options' button, log in, and set "GetMIME=20 or Plain Text Digests?" to MIME.  You can set this=20 option
globally for all the list digests you receive at this=20 point.



Send fmc mailing list submissions to
fmc@ietf.org

To subscribe or unsubscri= be via=20 the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/fmc
= or, via=20 email, send a message with subject or body 'help' to
fmc-request@ietf.org

You can reach the= person=20 managing the list at
fmc-owner@ietf.org

When replying, plea= se edit=20 your Subject line so it is more specific
than "Re: Contents of= fmc=20 digest..."
Today's Topics:

  1. R= e:=20 [Int-area]
     draft-boucadair-intar= ea-host-identifier-scenarios=20 (Tina TSOU)

From:=20 Tina TSOU &= lt;Tina.Tsou.Zouting@huawei.com>
Subject:= =20 Re: [fmc= ]=20 [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios
<= /DIV>
Date:=20 December 6,= 2012=20 11:16:00 PM PST
To:=20 "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Cc:=20 "draft-boucadair-intarea-host-identifier-scenarios= @tools.ietf.org"=20 <draft-boucadair-intarea-host-identifier-scenarios= @tools.ietf.org>,=20 "int-area@ietf.org" <int-area@ietf.org>, "fmc@ietf.org" &l= t;fmc@ietf.org>= ,=20 "George, Wes" <wesley.george@twcable.com>


Dear Med et al,
In general,= I like=20 the current version. Some comments are=20 below.
1.    &nb= sp; From my understanding, this document provides the us= e cases=20 for the issues and analysis in=20 =93draft-ietf-intarea-nat-reveal-analysis=94. Is it correct? If i= t is , I=20 suggest this document be referenced in=20 =93nat-reveal-analysis=94.
2.    &nb= sp; Regarding this document, in the section of CGN use c= ase,=20 the stateless NAT44 case should be=20 included.
3.    &nb= sp; For A+P section, the MAP/Lw4over6 cases may be=20 considered.
4.    &nb= sp; In figure 6, the UE may have an interface with AF to= =20 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>=20 wrote:

Dear Wes,

Thank you= for=20 your comments.

Please see inl= ine.=20

Cheers,
Med=20

-----Message=20 d'origine-----
De : George, Wes [mailto:wesley.george@twcable.com]=20
Envoy=E9 : mardi 4 d=E9cembre 2= 012=20 21:09
=C0 : BOUCADAIR Mohamed OLNC/OL= N; fmc@ietf.org= ; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scena= rios@tools.ietf.org
Objet : RE:=20 draft-boucadair-intarea-host-identifier-scenarios
<= /BLOCKQUOTE>

I've read this draft, and I thi= nk=20 the use case list is
reasonably=20 complete.

However, it's really unclear to= me=20 what the value of this
draft might be in its current f= orm,=20 and what its intended
audience might be. Cataloging u= se=20 cases is not all that
helpful by itself without an en= d=20 goal in mind, and that end
goal is not clear from the=20 draft.

Med: The= goal=20 of this draft is what is described in Section=20 2:

"The goal is=20 to
  identify scenarios the authors a= re=20 aware of and which share the same
  i= ssue=20 of host=20 identification.

  Th= is=20 document does not include any solution-specific=20 discussion.
  This document can be us= ed as=20 a tool to design solution(s)=20 mitigating
  the encountered issues.= =20  Having a generic solution which would=20 solve
  the issues encountered in the= se=20 use cases is preferred over designing
 &nb= sp;a=20 solution for each use case.  Describing the use case allow= s=20 to
  identify what is common between = the=20 use cases and then would help
  durin= g the=20 solution design phase."

Next=20 updates of this draft will:
* include a discuss= ion=20 section to assess whether the issue is valid for IPv4-only or i= t=20 applies also for IPv6
* include a discussion te= xt to=20 clarify whether each use case is valid within one single=20 administrative domain or not
* include a discus= sion=20 text to identify use cases which share the same requirements (t= his=20 will help in designing the solution)
* add=20 additional use cases if any

At= =20 given point in time we need to draw conclusions about the=20 following:
(1) are these use cases valid=20 ones?
(2) if this is a real technical problem, = what=20 the IETF can do to solve the issue?
(3) if ther= e is=20 interest in this area, how to organize the work for the solutio= n=20 space.

The scope is deliberate= ly=20
very narrow and references othe= r=20 drafts that discuss some of
the surrounding issues with add= ress=20 sharing and unique
identifiers, and so there is ve= ry=20 little text in each section
beyond a basic description. Eve= n=20 when you think of this in
terms of follow-on drafts such = as a=20 gap analysis or problem
statement or solution drafts, o= ne=20 wonders how useful it is to
spread this across multiple dra= fts.=20 So why not simply
incorporate this list into one = of=20 the referenced general
drafts on host identification, = such=20 as nat-reveal-analysis and
then broaden that draft so that= it=20 considers and addresses the
other use cases as=20 appropriate?

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


Otherwise, I think that the dra= ft=20 needs to be much clearer
about the unique issues and=20 considerations for each use case,
especially those that are someh= ow=20 distinct from those covered
in nat-reveal-analysis so that = it=20 can serve as a better input
to any potential solutions=20 addressing this=20 problem.

Med: Ful= ly=20 agreed. This will be added to the next rev of the=20 draft.


I also believe that if this dra= ft is=20 to remain a standalone
document, the authors need to m= ake=20 at least some attempt at
discussing security and privacy= =20 considerations here, even if
it is mainly to refer the reade= r to=20 more in-depth discussions
of the matter in other=20 drafts.

Med: Ag= ree. A=20 pointer to http://tools.ietf.org/html/draft-ietf-intarea-n= at-reveal-analysis-04#section-3=20 will be added to the next rev of the draft. The text will also= =20 include some discussion for use cases which are restricted to o= ne=20 single administrative=20 domain.


Again= ,=20 here is an area where
being clear about the specific= =20 considerations for each use
case is important, identifying= =20 whether the other drafts
discuss things so that they are= =20 applicable to all of the use
cases, or if the use cases are= =20 unique in any number of ways
that will mean that they have u= nique=20 privacy and security
considerations.

Thanks,

Wes George

-----Original=20 Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org]=20 On
Behalf Of mohamed.boucadair@orange.com
=
Sent: Monday, December 03, 20= 12=20 4:08 AM
To: fmc@ietf.org; int-area@ietf.org
Cc: draft-boucadair-intarea-host-identifier-sce= narios@tools.ietf.org
Subject: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear=20 all,

We submitted an updated versi= on of=20 this draft to list use cases=20 which
encounter the issue of host=20 identification. The following
use cases are
discussed in the=20 draft:

  (1)  Carrier= =20 Grade NAT (CGN)
  (2)  A+P (e.= g.,=20 MAP )
  (3)  Applica= tion=20 Proxies
  (4)  Provide= r=20 Wi-Fi
  (5)  Policy = and=20 Charging Architectures
  (6)  Cellula= r=20 Networks
  (7)=20  Femtocells
  (8)  Overlay= =20 Networks (e.g., CDNs)

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

If you think your use case is= not=20 included in this version,
please share
it with=20 us.

Comments are=20 welcome.

Cheers,
Med


-----Message=20 d'origine-----
De : i-d-announce-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:i-d-announce-"=20 target=3D_blank>i-d-announce-
bounces@ietf.org] De la part de internet-drafts@ietf.org=20
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 := i-d-announce@ietf.org Objet : I-D=20 Action:
draft-boucadair-intarea-host-identifier= -scenarios-02.txt


A New Internet-Draft is avail= able=20 from the on-line=20 Internet-Drafts
directories.


     Title=20           = ;:=20 Host Identification: Use Cases
     Author(s)= =20       : Mohamed=20 Boucadair
      &nb= sp;            =       David=20 Binet
      &nb= sp;            =       Sophie=20 Durel
      &nb= sp;            =       Tirumaleswar=20 Reddy
      &nb= sp;            =       Brandon=20 Williams
     Filename= =20        :=20 draft-boucadair-intarea-host-identifier-
scenarios-02.txt
<= /BLOCKQUOTE>
     Pages=20           = ;:=20 14
     = ;Date=20           = ; :=20 2012-12-02

Abstract:
  This document=20 describes a set of scenarios in which=20 host
  identification is= =20 required.


The IETF datatracker status p= age=20 for this draft is:
https://datatracker.ietf.org/doc/draft-bouc= adair-intarea-host-
identifier-scenarios

There's also a htmlized versi= on=20 available at:
http://tools.ietf.org/html/draft-boucadair-= intarea-host-identifier-
scenarios-02

A diff from the previous vers= ion=20 is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bo= ucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also avai= lable=20 by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________= ________
I-D-Announce mailing=20 list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-a= nnounce
Internet-Draft directories: <= A=20 href=3D"http://www.ietf.org/shadow.html"=20 target=3D_blank>http://www.ietf.org/shadow.html=20 or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________= ________
Int-area mailing=20 list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-a= rea

This E-mail and any of its=20 attachments may contain Time Warner
Cable proprietary information, = which=20 is privileged,
confidential, or subject to=20 copyright belonging to Time Warner
Cable. This E-mail is intended= =20 solely for the use of the
individual or entity to which i= t is=20 addressed. If you are not
the intended recipient of this= =20 E-mail, you are hereby notified
that any dissemination,=20 distribution, copying, or action taken
in relation to the contents of = and=20 attachments to this E-mail
is strictly prohibited and may = be=20 unlawful. If you have
received this E-mail in error,= =20 please notify the sender
immediately and permanently del= ete=20 the original and any copy
of this E-mail and any=20 printout.

_____________= __________________________________
Int-area=20 mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area<= /A>


____________________________= ___________________
fmc=20 mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
=



= _______________________________________________
fmc=20 mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc


--_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnante_-- From hasnaa.moustafa@gmail.com Fri Dec 14 09:51:45 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CE21F8A91 for ; Fri, 14 Dec 2012 09:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.902 X-Spam-Level: ** X-Spam-Status: No, score=2.902 tagged_above=-999 required=5 tests=[AWL=-6.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_35=0.6, MANGLED_DELETE=2.3, MANGLED_FORM=2.3, MANGLED_MEDS=2.3, MANGLED_PLEASE=2.3, MANGLED_TEXT=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCk-7-OC3+st for ; Fri, 14 Dec 2012 09:51:36 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7500F21F8A8E for ; Fri, 14 Dec 2012 09:51:35 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so4413375vcb.31 for ; Fri, 14 Dec 2012 09:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ic/YoTK00ZdPLX/NG+rCF2OQw1EOWd9rw6SXJZd+8ws=; b=bOmNOST2sM3aZQXmQRba73vgFAx98AR53kzSusFoaZBoGooRbkx6e0g87ggecYWD1y 2kGsy2IFWjw4JoBLwFq+LShp2PcX23JmaTxPIBGrs+SbkXtd1Mdu5erZoSThMZmQ4lz2 id62GxH7IzsmoNBFr6b/8lR1pQjLSMRvFOG7/tKOW9L8UDETJYP0JHNgHkzxbyFwqwlq HB67rhZYI2ASgefKyfzbpBRyRkfmF64RKyiIuOB8A3vJgbDvIjKT6B5Lsm0RZCTO5+2B /5em0JU0RJDOJ21Txtd3d0z8W/QyTkUmI79qOVptKOzMQK5SpSCYkyKD/bYp3kpnAvH4 EUlQ== MIME-Version: 1.0 Received: by 10.52.155.205 with SMTP id vy13mr6517992vdb.119.1355507494828; Fri, 14 Dec 2012 09:51:34 -0800 (PST) Received: by 10.58.252.37 with HTTP; Fri, 14 Dec 2012 09:51:34 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Dec 2012 09:51:34 -0800 Message-ID: From: Hasnaa Moustafa To: fmc@ietf.org Content-Type: multipart/alternative; boundary=bcaec53aecceb83a2104d0d3ae05 Cc: mohamed.boucadair@orange.com Subject: Re: [fmc] fmc Digest, Vol 9, Issue 9 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:51:50 -0000 --bcaec53aecceb83a2104d0d3ae05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Med, Thanks for the clarification. Yes I agree with your feedback on the video streaming case. Your reply makes things clearer for me, yes this is more situated under "a solution approacg" and I think that it's nearly covered by the different use'cases mentioned in the draft. For the SIPTO case, I understood that you confirm the interest of including a use-case for it. And so I will provide you shortly with some text proposal seeing if it meets the scope for Host-ID use-cases. Kind regards, Hassnaa On Thu, Dec 13, 2012 at 10:41 PM, 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 7 (mohamed.boucadair@orange.com) > 2. (no subject) > > > ---------- Forwarded message ---------- > From: > To: Hasnaa Moustafa , "fmc@ietf.org" < > fmc@ietf.org> > Cc: > Date: Fri, 14 Dec 2012 07:41:49 +0100 > Subject: Re: [fmc] fmc Digest, Vol 9, Issue 7 > ** > Dear Hasnaa, > > Please see inline. > > Cheers, > Med > > ------------------------------ > *De :* Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] > *Envoy=E9 :* jeudi 13 d=E9cembre 2012 19:38 > *=C0 :* fmc@ietf.org > *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 describi= ng > is looking on how to make use of any HOST_ID proposal to better service t= he > 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"... > > Thanks for this exchange. > > Kind regards, > Hassnaa > > On Wed, Dec 12, 2012 at 11:01 PM, 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: >> To: Hasnaa Moustafa , "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=E9 :* mardi 11 d=E9cembre 2012 20:22 >> *=C0 :* 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 matche= s >> the objective of Host-ID in your draft and if this scenario is implicitl= y >> 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 wil= l >> 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 lo= wer >> power nodes working in the same frequency as the macro cell nodes, and t= he >> 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 tim= e. >> Private IPv4 addresses are assigned in each cell (macro or pico), and th= ere >> 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. >> >> > > ---------- Forwarded message ---------- > From: > To: > Cc: > Date: > Subject: > er=3D20 > not only for the small cell case but in for mobile networks in > genera=3D > l.=3D20 > The SIPTO case may induce some issues for both IPv4 and IPv6.=3D20 >

>

class=3D3DMsoNormal> face=3D3D"Courier New"> 

>

class=3D3DMsoNormal> face=3D3D"Courier New"> 

>

class=3D3DMsoNormal> I thought to share thes epoi= nts > =3D > with=3D20 > you and with all the list for more feedback.
color=3D3D#=3D > 0000ff=3D20 > face=3D3D"Courier New">[Med] Many thanks for sharing your= =3D20 > thoughts. I will be more than please to integrate you text on > th=3D > e=3D20 > SIPTO case.  

style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt"> >

class=3D3DMsoNorm=3D > al> style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: > 10pt">&=3D > nbsp;

>

class=3D3DMsoNorm=3D > al> style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt">Kind= =3D20 > regards, style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: > 10pt"><=3D > /P> >

class=3D3DMsoNorm=3D > al> style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: > 10pt">Hassnaa<=3D > /SPAN> style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZE: > 10pt"><=3D > /P> 

>


 
>
On Fri, Dec 7, 2012 at 7:17 AM, Hassnaa > Mous=3D > tafa=3D20 > < target=3D3D_blank>hasnaa.moustafa@gmail.com> wrote: > style=3D3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; > PADD=3D > ING-LEFT: 1ex"=3D20 > class=3D3Dgmail_quote> >

>

>
Begin forwarded message:

>
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">From= :=3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"> href=3D3D"mailto:fmc-request@ietf.org"=3D20 > target=3D3D_blank>fmc-request@ietf.org
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: > medium">Subject:=3D > =3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">fmc > Dige=3D > st, Vol=3D20 > 9, Issue 3
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Date= :=3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Decembe= r > 7,=3D > 2012=3D20 > 12:27:41 AM PST
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">To:= =3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"> href=3D3D"mailto:fmc@ietf.org"=3D20 > target=3D3D_blank>fmc@ietf.org
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: > medium">Reply-To=3D > :=3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"> href=3D3D"mailto:fmc@ietf.org"=3D20 > target=3D3D_blank>fmc@ietf.org
>
>

If you have received this digest without all the > individ=3D > ual=3D20 > message
attachments you will need to update your digest > option=3D > s in=3D20 > your list
subscription.  To do so, go to

href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20 > target=3D3D_blank>https://www.ietf.org/mailman/listinfo/fmc >
=3D >
Click=3D20 > the 'Unsubscribe or edit options' button, log in, and set > "Get >MIME=3D20 > or Plain Text Digests?" to MIME.  You can set this=3D20 > option
globally for all the list digests you receive at > this=3D20 > point.



Send fmc mailing list submissions > to
AN=3D20 > style=3D3D"WHITE-SPACE: pre-wrap"> fmc@ietf=3D > .org"=3D20 > target=3D3D_blank>fmc@ietf.org

To subscribe or > unsubscri=3D > be via=3D20 > the World Wide Web, visit
style=3D3D"WHITE-SPACE: pre-wrap"> href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20 > target=3D3D_blank>https://www.ietf.org/mailman/listinfo/fmc >
=3D > or, via=3D20 > email, send a message with subject or body 'help' to
style=3D3D"WHITE-SPACE: pre-wrap"> href=3D3D"mailto:fmc-request@ietf.org"=3D20 > target=3D3D_blank>fmc-request@ietf.org

You can reach > the=3D > person=3D20 > managing the list at
pre-wrap"> PAN> href=3D3D"mailto:fmc-owner@ietf.org"=3D20 > target=3D3D_blank>fmc-owner@ietf.org

When replying, > plea=3D > se edit=3D20 > your Subject line so it is more specific
than "Re: Contents > of=3D > fmc=3D20 > digest..."
Today's Topics:

  1. > R=3D > e:=3D20 > > [Int-area]
     draft-boucadair-intar=3D > ea-host-identifier-scenarios=3D20 > (Tina TSOU)

>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">From= :=3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Tina TS= OU > &=3D > lt; href=3D3D"mailto:Tina.Tsou.Zouting@huawei.com"=3D20 > target=3D3D_blank>Tina.Tsou.Zouting@huawei.com > >
DIV> >
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: > medium">Subject:=3D > =3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Re: > [fmc=3D > ]=3D20 > [Int-area]=3D20 > > draft-boucadair-intarea-host-identifier-scenarios
<=3D > /DIV> >
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Date= :=3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Decembe= r > 6,=3D > 2012=3D20 > 11:16:00 PM PST
>
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">To:= =3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">" href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20 > target=3D3D_blank>mohamed.boucadair@orange.com" < href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20 > target=3D3D_blank>mohamed.boucadair@orange.com > >
DIV> >
style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">Cc:= =3D20 > style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium">" href=3D3D"mailto: > draft-boucadair-intarea-host-identifier-scenarios@=3D > tools.ietf.org"=3D20 > > target=3D3D_blank>draft-boucadair-intarea-host-identifier-scenarios=3D > @tools.ietf.org"=3D20 > < href=3D3D"mailto: > draft-boucadair-intarea-host-identifier-scenarios@=3D > tools.ietf.org"=3D20 > > target=3D3D_blank>draft-boucadair-intarea-host-identifier-scenarios=3D > @tools.ietf.org>,=3D20 > " target=3D3D_blank>int-area@ietf.org" < href=3D3D"mailto:int-area@ietf.org"=3D20 > target=3D3D_blank>int-area@ietf.org>, " href=3D3D"mailto:fmc@ietf.org" target=3D3D_blank>fmc@ietf.org" > &l=3D > t; href=3D3D"mailto:fmc@ietf.org" target=3D3D_blank>fmc@ietf.org > >=3D > ,=3D20 > "George, Wes" < "=3D20 > target=3D3D_blank>wesley.george@twcable.com > >
>

>
>
Dear Med et al,
>
>
In > general,=3D > I like=3D20 > the current version. Some comments are=3D20 > below.
>
18pt"> lang=3D3DEN-US>1. style=3D3D"FONT: 7pt 'Times New > Roman'">    &nb=3D > sp;  lang=3D3DEN-US>From my understanding, this document provides th= e > us=3D > e cases=3D20 > for the issues and analysis in=3D20 > =3D93draft-ietf-intarea-nat-reveal-analysis=3D94. Is it correct= ? If > i=3D > t is , I=3D20 > suggest this document be referenced in=3D20 > =3D93nat-reveal-analysis=3D94.
>
18pt"> lang=3D3DEN-US>2. style=3D3D"FONT: 7pt 'Times New > Roman'">    &nb=3D > sp;  lang=3D3DEN-US>Regarding this document, in the section of CGN u= se > c=3D > ase,=3D20 > the stateless NAT44 case should be=3D20 > included.
>
18pt"> lang=3D3DEN-US>3. style=3D3D"FONT: 7pt 'Times New > Roman'">    &nb=3D > sp;  lang=3D3DEN-US>For A+P section, the MAP/Lw4over6 cases may be= =3D20 > considered.
>
18pt"> lang=3D3DEN-US>4. style=3D3D"FONT: 7pt 'Times New > Roman'">    &nb=3D > sp;  lang=3D3DEN-US>In figure 6, the UE may have an interface with A= F > to=3D > =3D20 > initiate the session request, e.g., SIP.
>

>
Thank you,
Tina
>

On Dec 4, 2012, at 11:10 PM, " href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20 > target=3D3D_blank>mohamed.boucadair@orange.com" < href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20 > target=3D3D_blank>mohamed.boucadair@orange.com>=3D20 > wrote:

>
>
>
Dear Wes,

Thank > you=3D > for=3D20 > your comments.

Please see > inl=3D > ine.=3D20 > >

Cheers,
Med=3D20 >

>
-----Message=3D20 > d'origine-----
>
De : George, Wes [mailto: href=3D3D"mailto:wesley.george@twcable.com"=3D20 > target=3D3D_blank>wesley.george@twcable.com]=3D20 >
>
Envoy=3DE9 : mardi 4 d=3DE9= cembre > 2=3D > 012=3D20 > 21:09
>
=3DC0 : BOUCADAIR Mohamed > OLNC/OL=3D > N; href=3D3D"mailto:fmc@ietf.org" target=3D3D_blank>fmc@ietf.o= rg > =3D > ; href=3D3D"mailto:int-area@ietf.org"=3D20 > target=3D3D_blank>int-area@ietf.org >
>
Cc : href=3D3D"mailto: > draft-boucadair-intarea-host-identifier-scenar=3D > ios@tools.ietf.org"=3D20 > > target=3D3D_blank>draft-boucadair-intarea-host-identifier-scena=3D > rios@tools.ietf.org
>
Objet : RE:=3D20 > > draft-boucadair-intarea-host-identifier-scenarios
<=3D > /BLOCKQUOTE> >

>
I've read this draft, and I > thi=3D > nk=3D20 > the use case list is
>
reasonably=3D20 > complete.
>

>
However, it's really unclea= r > to=3D > me=3D20 > what the value of this
>
draft might be in its curre= nt > f=3D > orm,=3D20 > and what its intended
>
audience might be. Catalogi= ng > u=3D > se=3D20 > cases is not all that
>
helpful by itself without a= n > en=3D > d=3D20 > goal in mind, and that end
>
goal is not clear from the= =3D20 > draft.

Med: > The=3D > goal=3D20 > of this draft is what is described in Section=3D20 > 2:

"The goal is=3D20 > to
  identify scenarios the authors > a=3D > re=3D20 > aware of and which share the > same
  i=3D > ssue=3D20 > of host=3D20 > > identification.

  Th=3D > is=3D20 > document does not include any solution-specific=3D20 > discussion.
  This document can be > us=3D > ed as=3D20 > a tool to design solution(s)=3D20 > mitigating
  the encountered issues= .=3D > =3D20 >  Having a generic solution which would=3D20 > solve
  the issues encountered in > the=3D > se=3D20 > use cases is preferred over > designing
 &nb=3D > sp;a=3D20 > solution for each use case.  Describing the use case > allow=3D > s=3D20 > to
  identify what is common betwee= n > =3D > the=3D20 > use cases and then would > help
  durin=3D > g the=3D20 > solution design > phase."

Next=3D20 > updates of this draft will:
* include a > discuss=3D > ion=3D20 > section to assess whether the issue is valid for IPv4-only or > i=3D > t=3D20 > applies also for IPv6
* include a discussion > te=3D > xt to=3D20 > clarify whether each use case is valid within one single=3D20 > administrative domain or not
* include a > discus=3D > sion=3D20 > text to identify use cases which share the same requirements > (t=3D > his=3D20 > will help in designing the solution)
* add= =3D20 > additional use cases if > any

At=3D > =3D20 > given point in time we need to draw conclusions about the=3D2= 0 > following:
(1) are these use cases valid=3D20 > ones?
(2) if this is a real technical problem= , > =3D > what=3D20 > the IETF can do to solve the issue?
(3) if > ther=3D > e is=3D20 > interest in this area, how to organize the work for the > solutio=3D > n=3D20 > space.

The scope is > deliberate=3D > ly=3D20 >
>
very narrow and references > othe=3D > r=3D20 > drafts that discuss some of
>
the surrounding issues with > add=3D > ress=3D20 > sharing and unique
>
identifiers, and so there i= s > ve=3D > ry=3D20 > little text in each section
>
beyond a basic description. > Eve=3D > n=3D20 > when you think of this in
>
terms of follow-on drafts s= uch > =3D > as a=3D20 > gap analysis or problem
>
statement or solution draft= s, > o=3D > ne=3D20 > wonders how useful it is to
>
spread this across multiple > dra=3D > fts.=3D20 > So why not simply
>
incorporate this list into = one > =3D > of=3D20 > the referenced general
>
drafts on host identificati= on, > =3D > such=3D20 > as nat-reveal-analysis and
>
then broaden that draft so > that=3D > it=3D20 > considers and addresses the
>
other use cases as=3D20 > > appropriate?

Me=3D > d: As I=3D20 > mentioned above, we don't want to include any > solution-specific=3D > =3D20 > discussion to this draft. The text is shortened in=3D20 > purpose.

>

>
Otherwise, I think that the > dra=3D > ft=3D20 > needs to be much clearer
>
about the unique issues and= =3D20 > considerations for each use case,
>
especially those that are > someh=3D > ow=3D20 > distinct from those covered
>
in nat-reveal-analysis so t= hat > =3D > it=3D20 > can serve as a better input
>
to any potential solutions= =3D20 > addressing this=3D20 > problem.

Med: > Ful=3D > ly=3D20 > agreed. This will be added to the next rev of the=3D20 > draft.

>

>
I also believe that if this > dra=3D > ft is=3D20 > to remain a standalone
>
document, the authors need = to > m=3D > ake=3D20 > at least some attempt at
>
discussing security and > privacy=3D > =3D20 > considerations here, even if
>
it is mainly to refer the > reade=3D > r to=3D20 > more in-depth discussions
>
of the matter in other=3D20 > drafts.

Med: > Ag=3D > ree. A=3D20 > pointer to href=3D3D" > http://tools.ietf.org/html/draft-ietf-intarea-nat-revea=3D > l-analysis-04#section-3"=3D20 > target=3D3D_blank> > http://tools.ietf.org/html/draft-ietf-intarea-n=3D > at-reveal-analysis-04#section-3=3D20 > will be added to the next rev of the draft. The text will als= o=3D > =3D20 > include some discussion for use cases which are restricted to > o=3D > ne=3D20 > single administrative=3D20 > > domain.


Again=3D > ,=3D20 > here is an area where
>
being clear about the speci= fic=3D > =3D20 > considerations for each use
>
case is important, identify= ing=3D > =3D20 > whether the other drafts
>
discuss things so that they > are=3D > =3D20 > applicable to all of the use
>
cases, or if the use cases = are=3D > =3D20 > unique in any number of ways
>
that will mean that they ha= ve > u=3D > nique=3D20 > privacy and security
> type=3D3D"cite">considerations.
>

>
Thanks,
>

>
Wes > George
TE> >

>
>
-----Original=3D20 > Message-----
>
>
From: href=3D3D"mailto:int-area-bounces@ietf.org"=3D20 > target=3D3D_blank>int-area-bounces@ietf.org [mailto: > href=3D3D"mailto:int-area-bounces@ietf.org"=3D20 > target=3D3D_blank>int-area-bounces@ietf.org]=3D20 > On
>
>
Behalf Of href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20 > target=3D3D_blank>mohamed.boucadair@orange.com >
=3D >
>
>
Sent: Monday, December 03= , > 20=3D > 12=3D20 > 4:08 AM
>
>
To: fmc@iet=3D > f.org"=3D20 > target=3D3D_blank>fmc@ietf.org; href=3D3D"mailto:int-area@ietf.org"=3D20 > target=3D3D_blank>int-area@ietf.org >
E>
>
>
Cc: href=3D3D"mailto: > draft-boucadair-intarea-host-identifier-scen=3D > arios@tools.ietf.org"=3D20 > > target=3D3D_blank>draft-boucadair-intarea-host-identifier-sce=3D > narios@tools.ietf.org
>
>
Subject: [Int-area]=3D20 > > draft-boucadair-intarea-host-identifier-scenarios >
>
>
type=3D3D"cite">
CKQUOTE> >
>
Dear=3D20 > all,
>
>
type=3D3D"cite">
CKQUOTE> >
>
We submitted an updated > versi=3D > on of=3D20 > this draft to list use cases=3D20 > which
>
>
encounter the issue of > host=3D20 > identification. The following >
CKQUOTE> >
use cases > are
QUOTE> >
>
discussed in the=3D20 > draft:
>
>
type=3D3D"cite">
CKQUOTE> >
>
  (1) >  Carrier=3D > =3D20 > Grade NAT (CGN)
>
>
  (2)  A+P > (e.=3D > g.,=3D20 > MAP )
>
>
  (3) >  Applica=3D > tion=3D20 > Proxies
>
>
  (4) >  Provide=3D > r=3D20 > Wi-Fi
>
>
  (5)  Pol= icy > =3D > and=3D20 > Charging Architectures
>
>
  (6) >  Cellula=3D > r=3D20 > Networks
>
>
  (7)=3D20 >  Femtocells
>
>
  (8) >  Overlay=3D > =3D20 > Networks (e.g., CDNs)
>
>
type=3D3D"cite">
CKQUOTE> >
>
The document does not > include=3D > any=3D20 > solution-specific
>
discussion. Its=3D20 > main
>
>
goal is to identify the u= se > c=3D > ases=3D20 > and describe them.
>
>
type=3D3D"cite">
CKQUOTE> >
>
If you think your use cas= e > is=3D > not=3D20 > included in this version, >
OTE> >
please > share
UOTE> >
>
it with=3D20 > us.
>
>
type=3D3D"cite">
CKQUOTE> >
>
Comments are=3D20 > welcome.
>
>
type=3D3D"cite">
CKQUOTE> >
> > type=3D3D"cite">Cheers,
> >
> type=3D3D"cite">Med
>
>
type=3D3D"cite">
CKQUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
-----Message=3D20 > d'origine-----
>
>
De : href=3D3D"mailto:i-d-announce-bounces@ietf.org"=3D20 > target=3D3D_blank>i-d-announce-bounces@ietf.org [mail= to: > <=3D > A=3D20 > href=3D3D"mailto:i-d-announce-"=3D20 > > target=3D3D_blank>i-d-announce-
BLOCKQUOTE> >
>
bounces@iet=3D > f.org"=3D20 > target=3D3D_blank>bounces@ietf.org] De la part de href=3D3D"mailto:internet-drafts@ietf.org"=3D20 > target=3D3D_blank>internet-drafts@ietf.org=3D20 >
>
Envoy=3DE9 : > lundi
OCKQUOTE> >
>
3 d=3DE9cembre 2012 08:26= =3DC0 > :=3D > href=3D3D"mailto:i-d-announce@ietf.org"=3D20 > target=3D3D_blank>i-d-announce@ietf.org Objet : I-D= =3D20 > Action:
>
> > type=3D3D"cite">draft-boucadair-intarea-host-identifier=3D > -scenarios-02.txt
>
>
type=3D3D"cite">
CKQUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
A New Internet-Draft is > avail=3D > able=3D20 > from the on-line=3D20 > Internet-Drafts
>
> > type=3D3D"cite">directories.
QUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
> type=3D3D"cite">     Title= =3D20 > >           =3D > ;:=3D20 > Host Identification: Use > Cases
CKQUOTE> >
> > type=3D3D"cite">     Author(s)=3D > =3D20 >       : Mohamed=3D20 > Boucadair
>
> > type=3D3D"cite">      &nb=3D > > sp;           &nbs= p;=3D >       David=3D20 > Binet
>
> > type=3D3D"cite">      &nb=3D > > sp;           &nbs= p;=3D >       Sophie=3D20 > Durel
>
> > type=3D3D"cite">      &nb=3D > > sp;           &nbs= p;=3D >       Tirumaleswar=3D20 > Reddy
>
> > type=3D3D"cite">      &nb=3D > > sp;           &nbs= p;=3D >       Brandon=3D20 > Williams
>
> type=3D3D"cite">     Filen= ame=3D > =3D20 >        :=3D20 > > draft-boucadair-intarea-host-identifier-
UOTE>
>
> > type=3D3D"cite">scenarios-02.txt
<=3D > /BLOCKQUOTE> >
> type=3D3D"cite">     Pages= =3D20 > >           =3D > ;:=3D20 > 14
>
>
type=3D3D"cite">     =3D > ;Date=3D20 > >           =3D > ; :=3D20 > 2012-12-02
>
>
type=3D3D"cite">
CKQUOTE> >
> > type=3D3D"cite">Abstract:
TE> >
>
  This document= =3D20 > describes a set of scenarios in which=3D20 > host
>
>
  identificatio= n > is=3D > =3D20 > required.
>
>
type=3D3D"cite">
CKQUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
The IETF datatracker stat= us > p=3D > age=3D20 > for this draft is:
>
>
href=3D3D" > https://datatracker.ietf.org/doc/draft-boucadair-in=3D > tarea-host-"=3D20 > target=3D3D_blank> > https://datatracker.ietf.org/doc/draft-bouc=3D > adair-intarea-host-
>
> > type=3D3D"cite">identifier-scenarios
TE>
>
>
type=3D3D"cite">
CKQUOTE> >
>
There's also a htmlized > versi=3D > on=3D20 > available at:
>
>
href=3D3D" > http://tools.ietf.org/html/draft-boucadair-intarea-=3D > host-identifier-"=3D20 > target=3D3D_blank> > http://tools.ietf.org/html/draft-boucadair-=3D > intarea-host-identifier-
>
> > type=3D3D"cite">scenarios-02
QUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
A diff from the previous > vers=3D > ion=3D20 > is available at:
>
>
href=3D3D" > http://www.ietf.org/rfcdiff?url2=3D3Ddraft-boucadair-=3D > intarea-host-"=3D20 > target=3D3D_blank> > http://www.ietf.org/rfcdiff?url2=3D3Ddraft-bo=3D > ucadair-intarea-host-
>
> > type=3D3D"cite">identifier-scenarios-02
QUOTE>
>
>
type=3D3D"cite">
CKQUOTE> >
>
type=3D3D"cite">
CKQUOTE> >
>
Internet-Drafts are also > avai=3D > lable=3D20 > by anonymous FTP at:
>
>
href=3D3D"ftp://ftp.ietf.org/internet-drafts/"=3D20 > target=3D3D_blank>ftp://ftp.ietf.org/internet-drafts/ > AN>
>
>
type=3D3D"cite">
CKQUOTE> >
> > type=3D3D"cite">_______________________________________=3D > ________
>
>
I-D-Announce mailing=3D20 > list
>
>
href=3D3D"mailto:I-D-Announce@ietf.org"=3D20 > target=3D3D_blank>I-D-Announce@ietf.org >
QUOTE>
>
>
href=3D3D"https://www.ietf.org/mailman/listinfo/i-d-annou= nce > "=3D > =3D20 > target=3D3D_blank> > https://www.ietf.org/mailman/listinfo/i-d-a=3D > nnounce
>
>
Internet-Draft directorie= s: > <=3D > A=3D20 > href=3D3D"http://www.ietf.org/shadow.html"=3D20 > target=3D3D_blank>http://www.ietf.org/shadow.html=3D2= 0 > or
>
>
href=3D3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"=3D20 > target=3D3D_blank>ftp://ftp.ietf.org/ietf/1shadow-sites.t= xt > A>
>
> > type=3D3D"cite">_______________________________________=3D > ________
>
>
Int-area mailing=3D20 > list
>
>
Int-area@ie=3D > tf.org"=3D20 > target=3D3D_blank>Int-area@ietf.org >
E>
>
>
href=3D3D"https://www.ietf.org/mailman/listinfo/int-area"= =3D20 > target=3D3D_blank> > https://www.ietf.org/mailman/listinfo/int-a=3D > rea
>

>
This E-mail and any of its= =3D20 > attachments may contain Time Warner
>
Cable proprietary informati= on, > =3D > which=3D20 > is privileged,
>
confidential, or subject to= =3D20 > copyright belonging to Time Warner
>
Cable. This E-mail is inten= ded=3D > =3D20 > solely for the use of the
>
individual or entity to whi= ch > i=3D > t is=3D20 > addressed. If you are not
>
the intended recipient of t= his=3D > =3D20 > E-mail, you are hereby notified
>
that any dissemination,=3D2= 0 > distribution, copying, or action taken >
E> >
in relation to the contents= of > =3D > and=3D20 > attachments to this E-mail
>
is strictly prohibited and = may > =3D > be=3D20 > unlawful. If you have
>
received this E-mail in err= or,=3D > =3D20 > please notify the sender
>
immediately and permanently > del=3D > ete=3D20 > the original and any copy
>
of this E-mail and any=3D20 > printout.
> > type=3D3D"cite">
_____________=3D > __________________________________
Int-area=3D20 > mailing list
Int-area@ietf.or=3D > g"=3D20 > target=3D3D_blank>Int-area@ietf.org
href=3D3D"https://www.ietf.org/mailman/listinfo/int-area"=3D2= 0 > target=3D3D_blank>https://www.ietf.org/mailman/listinfo/int-a= rea > <=3D > > /A>


__________________________= __=3D > ___________________
fmc=3D20 > mailing list
target=3D3D_blank>fmc@ietf.org
href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20 > target=3D3D_blank>https://www.ietf.org/mailman/listinfo/fmc >
=3D > >


=3D > _______________________________________________
fmc=3D20 > mailing list
fmc@ietf.org >
=3D20 > href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20 > target=3D3D_blank>https://www.ietf.org/mailman/listinfo/fmc >

BLOCKQUOTE>

> > --_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnante_-- > > > ... > > [Message clipped] --bcaec53aecceb83a2104d0d3ae05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Med,
=A0
Thanks for the clarification.
Yes I agree with your feedback on the video streaming case. Your reply= makes things clearer for me, yes this is more situated under "a solut= ion approacg" and I think that it's nearly covered by the differen= t use'cases mentioned in the draft.
=A0
For the SIPTO case, I understood that you confirm the interest of incl= uding a use-case for it. And so I will provide you shortly with some text p= roposal seeing if it meets the scope for Host-ID use-cases.
=A0
Kind regards,
Hassnaa
=A0
=A0
=A0

=A0
On Thu, Dec 13, 2012 at 10:41 PM, <fmc-reque= st@ietf.org> wrote:
If you have received this digest with= out all the individual message
attachments you will need to update your = digest options in your list
subscription. =A0To 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. =A0You can set this option
gl= obally for all the list digests you receive at this point.



S= end fmc mailing list submissions to
=A0 =A0 =A0 =A0 fmc@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 = =A0 =A0 https://www.ietf.org/mailman/listinfo/fmc
or, via email, send a= message with subject or body 'help' to
=A0 =A0 =A0 =A0 fmc-request@ietf.or= g

You can reach the person managing the list at
=A0 =A0 =A0 = =A0 fmc-owner@ietf.org

Whe= n replying, please edit your Subject line so it is more specific
than "Re: Contents of fmc digest..."

Today's Topics:
=A0 =A01. Re: fmc Digest, Vol 9, Issue 7 (mohamed.boucadair@orange.com)
=A0 =A02. (no sub= ject)


---------- Forwarded message ----------
From:=A0<mohamed.boucadair@orange.com>To:=A0Hasnaa Moustafa <has= naa.moustafa@gmail.com>, "fmc@i= etf.org" <fmc@ietf.org><= br> Cc:=A0
Date:=A0Fri, 14 Dec 2012 07:41:49 +0100
Subject:=A0Re: [fmc] f= mc Digest, Vol 9, Issue 7
Dear Hasnaa,
=A0
Please see inline.
=A0
Cheers,
Med

De=A0: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Envoy=E9=A0: jeudi 13 d=E9cembre 2012 19:38
=C0=A0: fmc@ietf.org
Cc=A0: BOUCADAIR Mohamed OLNC/OLN
Objet=A0: Re: fmc Digest= , Vol 9, Issue 7

Thanks Med for your clarification.
For yur first question ([Med]=A0Wouldn't this be=A0achieved at the application level?= =A0announce/discover the device capabilities=A0and then the server will ada= pt=A0the way it will server the device?) ---> YES s= ure this is taken care by the application level (as HAS and DASH cases), bu= t the question is: Would doing so by lower layers through the host-ID be be= neficial 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 thoug= ht 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 l= east - but with no strong sureness").
[Med] The current u= se cases described in the draft present host identification as a problem. T= he 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 whe= re host identification is an issue.
=A0
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]=A0SIPTO can b= e introduced as a new use case in its own.
=A0
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 dra= ft be a discussion base for FMC (or would be under one of the existing WGs)= ?
[Med]=A0The goal is= to assess whether there is interest from the community to solve this probl= em. The problem space is not restricted to FMC but covers various cases whi= ch share the same technical problem.=A0Today this document is still "h= omeless"...
=A0
Thanks for this exchange.
=A0
Kind regards,
Hassnaa

On Wed, Dec 12, 2012 at 11:01 PM, <fmc-reque= st@ietf.org> wrote:
If you have received this digest with= out all the individual message
attachments you will need to update your = digest options in your list
subscription. =A0To 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. =A0You can set this option
gl= obally for all the list digests you receive at this point.



S= end fmc mailing list submissions to
=A0 =A0 =A0 =A0 fmc@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 = =A0 =A0 https://www.ietf.org/mailman/listinfo/fmc
or, via email, send a= message with subject or body 'help' to
=A0 =A0 =A0 =A0 f= mc-request@ietf.org

You can reach the person managing the list a= t
=A0 =A0 =A0 =A0 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:
=A0 =A01. Re: fmc Digest, Vol 9, Issue 3 (mohamed.boucadair@orange.com)

---------- Forwarded message ----------
From:=A0<mohamed.boucadair@ora= nge.com>
To:=A0Hasnaa Moustafa <hasnaa.moustafa@gmail.com>, "<= a href=3D"mailto:fmc@ietf.org" target=3D"_blank">fmc@ietf.org" <= ;fmc@ietf.org>
Cc:=A0"draft-boucadair-intarea-host-identif= ier-scenarios@tools.ietf.org" <draft= -boucadair-intarea-host-identifier-scenarios@tools.ietf.org>
Date:=A0Thu, 13 Dec 2012 08:01:21 +0100
Subject:=A0Re: [fmc] fmc Digest,= Vol 9, Issue 3
Dear Hasnaa,
=A0
Thank you for reading the draft.
=A0
Please see inline.
Cheers,
Med

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part = de Hasnaa Moustafa
Envoy=E9=A0: mardi 11 d=E9cembre 2012 20:22
=C0=A0: fmc@ietf.org
Objet=A0= : Re: [fmc] fmc Digest, Vol 9, Issue 3

=A0=20

Dear Med,

=A0

I read the draft and have some issues to discuss on the use-cases.<= /p>

I think that Host-ID would be useful for the case of Home Networks in a sc= enario as follows:

-=A0 Several hosts exist in the home network that can belong t= o the same or multiple users

-=A0 The NAT functionality could be carried out either in the RG or in ano= ther Border node

-=A0 The host access could be through WiFi AP, FAP or even Ethernet (e.g. = connected TV)

-=A0 Video streaming is the popular application/traffic in home network th= rough the different hosts

-=A0 Each host is considered as a device with different characteristics (i= .e. requiring the end server to=A0 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 IP= v4 address by all the Home Network

-=A0 Consequently, a HostID solution is beneficial in this use case=

=A0

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=A0is implicitly= covered in some of the use-cases mentioned in the draft.

[Med]=A0Wouldn't th= is be=A0achieved at the application level?=A0announce/discover the device c= apabilities=A0and then the server will adapt=A0the way it will server the d= evice?=A0

= =A0

= Another case that could be checked maybe is the HetNets scenario. According= to 3GPP definition for HetNets/small cells: Small cells are lower power no= des working in the same frequency as the macro cell nodes, and the heteroge= neity of the network comes from the varying power levels within the deploye= d nodes.

= A host could be attached to one or more small cells and could be simultaneo= usly attached to a small cell and a macro cell at the same time. Private IP= v4 addresses are assigned in each cell (macro or pico), and there could be = =A0several scenarios as follows:

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to only the macro cell: similar HostID issue= to the cellular network use-case

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to only a small cell: similar HostID issue t= o the case of cellular network use-case

-=A0=A0=A0=A0=A0=A0=A0=A0 host attached to both the=A0 macro cell=A0 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 th= ere might be a new issue ?

[Med]=A0Thank you for sharin= g this use case.



---------- Forwarded message ----------From:=A0
To:=A0
Cc:=A0
Date:=A0
Subject:=A0
er=3D20
=A0 = =A0 =A0 not only for the small cell case but in for mobile networks in gene= ra=3D
l.=3D20
=A0 =A0 =A0 The SIPTO case may induce some issues for both IPv4 and IPv6.= =3D20
=A0 =A0 =A0 </FONT></SPAN></P>
=A0 =A0 =A0 &l= t;P style=3D3D"LINE-HEIGHT: normal; MARGIN: 0in 0in 0pt"=3D20
= =A0 =A0 =A0 class=3D3DMsoNormal><SPAN><FONT color=3D3D#0000ff= =3D20
=A0 =A0 =A0 face=3D3D"Courier New"></FONT></SPAN>&= amp;nbsp;</P>
=A0 =A0 =A0 <P style=3D3D"LINE-HEIGHT: norma= l; MARGIN: 0in 0in 0pt"=3D20
=A0 =A0 =A0 class=3D3DMsoNormal><= ;SPAN><FONT color=3D3D#0000ff=3D20
=A0 =A0 =A0 face=3D3D"Courier New"></FONT></SPAN>&= amp;nbsp;</P>
=A0 =A0 =A0 <P style=3D3D"LINE-HEIGHT: norma= l; MARGIN: 0in 0in 0pt"=3D20
=A0 =A0 =A0 class=3D3DMsoNormal><= ;SPAN>&nbsp;</SPAN>I thought to share thes epoints =3D
with=3D20
=A0 =A0 =A0 you and with all the list for more feedback.<BR= ><SPAN><FONT color=3D3D#=3D
0000ff=3D20
=A0 =A0 =A0 face= =3D3D"Courier New">[Med]&nbsp;Many thanks for sharing&= nbsp;your=3D20
=A0 =A0 =A0 thoughts.&nbsp;I will be more than please= to integrate you text on th=3D
e=3D20
=A0 =A0 =A0 SIPTO case. &nbsp;</FONT></SPAN></= P></SPAN><SPAN=3D20
=A0 =A0 =A0 style=3D3D"FONT-FAMILY:= 'Arial','sans-serif'; FONT-SIZE: 10pt"></SPAN&g= t;
=A0 =A0 =A0 <P style=3D3D"LINE-HEIGHT: normal; MARGIN: 0in 0i= n 0pt" class=3D3DMsoNorm=3D
al><SPAN=3D20
=A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Arial&= #39;,'sans-serif'; FONT-SIZE: 10pt"></SPAN>&=3Dnbsp;</P>
=A0 =A0 =A0 <P style=3D3D"LINE-HEIGHT: normal;= MARGIN: 0in 0in 0pt" class=3D3DMsoNorm=3D
al><SPAN=3D20
=A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Arial&= #39;,'sans-serif'; FONT-SIZE: 10pt">Kind=3D20
=A0 =A0 = =A0 regards,</SPAN><SPAN=3D20
=A0 =A0 =A0 style=3D3D"FONT-= FAMILY: 'Arial','sans-serif'; FONT-SIZE: 10pt"><= /SPAN><=3D
/P>
=A0 =A0 =A0 <P style=3D3D"LINE-HEIGHT: normal; MARGIN: 0i= n 0in 6pt" class=3D3DMsoNorm=3D
al><SPAN=3D20
=A0 =A0 =A0 = style=3D3D"FONT-FAMILY: 'Arial','sans-serif'; FONT-SIZ= E: 10pt">Hassnaa<=3D
/SPAN><SPAN=3D20
=A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Ari= al','sans-serif'; FONT-SIZE: 10pt"></SPAN><=3D=
/P>&nbsp;</DIV>
=A0 =A0 =A0 <DIV><BR><BR= >&nbsp;</DIV>
=A0 =A0 =A0 <DIV class=3D3Dgmail_quote>On Fri, Dec 7, 2012 at 7:17 AM= , Hassnaa Mous=3D
tafa=3D20
=A0 =A0 =A0 <SPAN dir=3D3Dltr>&= lt;<A href=3D3D"mailto:hasnaa.moustafa@gmail.com"=3D20
=A0 =A0 =A0 target=3D3D_blank>hasnaa.moustafa@gmail.com</A>&gt;</SPAN> wrote:<B= R>
=A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 style=3D3D"BOR= DER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADD=3D
ING-LEFT: 1ex"=3D20
=A0 =A0 =A0 class=3D3Dgmail_quote>
=A0 = =A0 =A0 =A0 <DIV style=3D3D"WORD-WRAP: break-word"><BR&g= t;
=A0 =A0 =A0 =A0 <DIV><BR>
=A0 =A0 =A0 =A0 <DIV>B= egin forwarded message:</DIV><BR>
=A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0= =A0 =A0 <DIV style=3D3D"MARGIN: 0px"><SPAN=3D20
=A0 = =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE= : medium"><B>From:=3D20
=A0 =A0 =A0 =A0 =A0 </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0= =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium&qu= ot;><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:fmc-request@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc-request@ietf.org</A><BR></SPAN></DIV>=
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px"><SP= AN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica&= #39;; FONT-SIZE: medium"><B>Subject:=3D
=3D20
=A0 =A0 =A0 =A0 =A0 </B></SPAN><SPAN=3D20
=A0 = =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE= : medium"><B>fmc Dige=3D
st, Vol=3D20
=A0 =A0 =A0 =A0 = =A0 9, Issue 3</B><BR></SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px"><SPAN= =3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica= 9;; FONT-SIZE: medium"><B>Date:=3D20
=A0 =A0 =A0 =A0 =A0 &= lt;/B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-= SIZE: medium">December 7,=3D
=A02012=3D20
=A0 =A0 =A0 =A0 =A0= 12:27:41 AM PST<BR></SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 = <DIV style=3D3D"MARGIN: 0px"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-= SIZE: medium"><B>To:=3D20
=A0 =A0 =A0 =A0 =A0 </B>&l= t;/SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY= : 'Helvetica'; FONT-SIZE: medium"><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:f= mc@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc@ietf.org</A><BR></SPAN&g= t;</DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px&q= uot;><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-= SIZE: medium"><B>Reply-To=3D
:=3D20
=A0 =A0 =A0 =A0 =A0= </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D&quo= t;FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><A=3D20 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:f= mc@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc@ietf.org</A><BR></SPAN&g= t;</DIV>
=A0 =A0 =A0 =A0 =A0 <DIV>
=A0 =A0 =A0 =A0 =A0 <DIV><BR>If you have received this digest w= ithout all the individ=3D
ual=3D20
=A0 =A0 =A0 =A0 =A0 message<BR&= gt;attachments you will need to update your digest option=3D
s in=3D20=A0 =A0 =A0 =A0 =A0 your list<BR>subscription. &nbsp;To do so, = go to <BR><BR><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www.ietf.org= /mailman/listinfo/fmc</A><BR>=3D
<BR>Click=3D20
=A0 =A0 =A0 =A0 =A0 the 'Unsubscribe or edit op= tions' button, log in, and set "Get<BR=3D
>MIME=3D20
= =A0 =A0 =A0 =A0 =A0 or Plain Text Digests?" to MIME. &nbsp;You can= set this=3D20
=A0 =A0 =A0 =A0 =A0 option<BR>globally for all the = list digests you receive at this=3D20
=A0 =A0 =A0 =A0 =A0 point.<BR><BR><BR><BR>Send fmc = mailing list submissions to<BR><SP=3D
AN=3D20
=A0 =A0 =A0 = =A0 =A0 style=3D3D"WHITE-SPACE: pre-wrap"></SPAN><A h= ref=3D3D"mailto:fmc@ietf=3D
.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc@ietf.org</A><BR><BR>To subscribe= or unsubscri=3D
be via=3D20
=A0 =A0 =A0 =A0 =A0 the World Wide Web, = visit<BR><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"WHITE-SPACE: pre-wrap"></SPA= N><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"https://www.ietf.org/mai= lman/listinfo/fmc"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www.ietf.org/mailman/listinfo= /fmc</A><BR>=3D
or, via=3D20
=A0 =A0 =A0 =A0 =A0 emai= l, send a message with subject or body 'help' to<BR><SPAN= =3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"WHITE-SPACE: pre-wrap"></SPA= N><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:fmc-request@ietf.org"=3D20
=A0 =A0 = =A0 =A0 =A0 target=3D3D_blank>fm= c-request@ietf.org</A><BR><BR>You can reach the=3D =A0person=3D20
=A0 =A0 =A0 =A0 =A0 managing the list at<BR><SPA= N style=3D3D"WHITE-SPACE: pre-wrap"></S=3D
PAN><A= =3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:fmc-owner@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc-owner@ietf.org</A><BR><BR>When replying, plea= =3D
se edit=3D20
=A0 =A0 =A0 =A0 =A0 your Subject line so it is more = specific<BR>than "Re: Contents of=3D
=A0fmc=3D20
=A0 =A0 =A0 =A0 =A0 digest..."<BR></DIV><= ;/DIV>Today's Topics:<BR><BR>&nbsp;&nbsp;1. R=3D=
e:=3D20
=A0 =A0 =A0 =A0 =A0 [Int-area]<BR>&nbsp;&nbsp;= &nbsp;&nbsp;&nbsp;draft-boucadair-intar=3D
ea-host-identifier-scenarios=3D20
=A0 =A0 =A0 =A0 =A0 (Tina TSOU)<BR&= gt;<BR>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px&qu= ot;><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: &#= 39;Helvetica'; FONT-SIZE: medium"><B>From:=3D20
=A0 =A0 =A0 =A0 =A0 </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0= =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium&qu= ot;>Tina TSOU &=3D
lt;<A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D= "mailto:Tina.Tsou.Zout= ing@huawei.com"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>Tina.Tsou.Zouting@huawei.com</A>&gt;<BR>&= lt;/SPAN></=3D
DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D&q= uot;MARGIN: 0px"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-= SIZE: medium"><B>Subject:=3D
=3D20
=A0 =A0 =A0 =A0 =A0 = </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"= ;FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium"><B>Re: = [fmc=3D
]=3D20
=A0 =A0 =A0 =A0 =A0 [Int-area]=3D20
=A0 =A0 =A0 =A0 =A0 draft-= boucadair-intarea-host-identifier-scenarios</B><BR></SPAN>= ;<=3D
/DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN:= 0px"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAM= ILY: 'Helvetica'; FONT-SIZE: medium"><B>Date:=3D20 =A0 =A0 =A0 =A0 =A0 </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0= =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-SIZE: medium&qu= ot;>December 6,=3D
=A02012=3D20
=A0 =A0 =A0 =A0 =A0 11:16:00 PM PS= T<BR></SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px"><SPAN= =3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica= 9;; FONT-SIZE: medium"><B>To:=3D20
=A0 =A0 =A0 =A0 =A0 <= ;/B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FO= NT-FAMILY: 'Helvetica'; FONT-SIZE: medium">"<A=3D20=
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20
=A0 =A0 =A0 = =A0 =A0 target=3D3D_blank>mohamed.boucadair@orange.com</A>" &lt;<A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20
=A0 =A0 =A0 = =A0 =A0 target=3D3D_blank>mohamed.boucadair@orange.com</A>&gt;<BR></SPAN>= </=3D
DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"MARGIN: 0px">= ;<SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Hel= vetica'; FONT-SIZE: medium"><B>Cc:=3D20
=A0 =A0 =A0 = =A0 =A0 </B></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT-FAMILY: 'Helvetica'; FONT-= SIZE: medium">"<A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D&quo= t;mailto:draft-boucadair-intarea-host-identifier-scenarios@=3D
tools.ietf.org&quo= t;=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>draft-boucadair-intarea= -host-identifier-scenarios=3D
@tools.ietf.org</A>"=3D20
=A0 =A0 =A0 =A0 =A0 &lt;<A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D&quo= t;mailto:draft-boucadair-intarea-host-identifier-scenarios@=3D
tools.ietf.org"=3D20 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>draft-boucadair-intarea-host-ident= ifier-scenarios=3D
@tools.ietf.org</A>&gt;,=3D20
=A0 =A0 =A0 =A0 =A0 "&l= t;A href=3D3D"mailto:int-area@iet= f.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>int-area@ietf.org</A>" &lt;<A=3D20
=A0 =A0 =A0 = =A0 =A0 href=3D3D"mailto:int-area= @ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>int-area@ietf.org</A>&gt;, "<A=3D20
=A0 =A0 =A0= =A0 =A0 href=3D3D"mailto:fmc@ietf.org= " target=3D3D_blank>fmc@ietf.or= g</A>" &l=3D
t;<A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:fmc@ietf.org" target=3D3D_blank>fmc@ietf.org</A>&gt;=3D
,=3D20
=A0 =A0 = =A0 =A0 =A0 "George, Wes" &lt;<A href=3D3D"mailto:wesley.george@twcable.com&quo= t;=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>wesley.george@twcable.com</A>&gt;<BR></SP= AN></DIV=3D
><BR><BR>
=A0 =A0 =A0 =A0 =A0 <DI= V bgcolor=3D3D"#FFFFFF">
=A0 =A0 =A0 =A0 =A0 <DIV><SPAN>Dear Med et al,</SPAN><= /DIV>
=A0 =A0 =A0 =A0 =A0 <DIV>
=A0 =A0 =A0 =A0 =A0 <DIV = style=3D3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3D3DEN-US>In = general,=3D
=A0I like=3D20
=A0 =A0 =A0 =A0 =A0 the current version. S= ome comments are=3D20
=A0 =A0 =A0 =A0 =A0 below.<U></U><U></U></SPAN&g= t;</DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"TEXT-INDENT: = 0px; MARGIN: 0cm 0cm 0pt 18pt"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0= lang=3D3DEN-US><SPAN>1.<SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT: 7pt 'Times New Roman'&quo= t;>&nbsp;&nbsp;&nbsp;&nbsp;&nb=3D
sp;&nbsp;&l= t;/SPAN></SPAN></SPAN><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 l= ang=3D3DEN-US>From my understanding, this document provides the us=3D e cases=3D20
=A0 =A0 =A0 =A0 =A0 for the issues and analysis in=3D20
= =A0 =A0 =A0 =A0 =A0 =3D93draft-ietf-intarea-nat-reveal-analysis=3D94. Is it= correct? If i=3D
t is , I=3D20
=A0 =A0 =A0 =A0 =A0 suggest this docu= ment be referenced in=3D20
=A0 =A0 =A0 =A0 =A0 =3D93nat-reveal-analysis= =3D94.<U></U><U></U></SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"TEXT-INDENT: 0px; MARGIN: 0cm 0= cm 0pt 18pt"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 lang=3D3DEN-US>= ;<SPAN>2.<SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT: 7= pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nb= sp;&nb=3D
sp;&nbsp;</SPAN></SPAN></SPAN><SPAN=3D20
=A0 = =A0 =A0 =A0 =A0 lang=3D3DEN-US>Regarding this document, in the section o= f CGN use c=3D
ase,=3D20
=A0 =A0 =A0 =A0 =A0 the stateless NAT44 case= should be=3D20
included.<U></U><U></U></SPAN= ></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"TEXT-INDENT: 0px; MARGIN: 0cm 0= cm 0pt 18pt"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 lang=3D3DEN-US>= ;<SPAN>3.<SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT: 7= pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nb= sp;&nb=3D
sp;&nbsp;</SPAN></SPAN></SPAN><SPAN=3D20
=A0 = =A0 =A0 =A0 =A0 lang=3D3DEN-US>For A+P section, the MAP/Lw4over6 cases m= ay be=3D20
=A0 =A0 =A0 =A0 =A0 considered.<U></U><U>&l= t;/U></SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV style=3D3D"TEXT-INDENT: 0px; MARGIN: 0cm 0= cm 0pt 18pt"><SPAN=3D20
=A0 =A0 =A0 =A0 =A0 lang=3D3DEN-US>= ;<SPAN>4.<SPAN=3D20
=A0 =A0 =A0 =A0 =A0 style=3D3D"FONT: 7= pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nb= sp;&nb=3D
sp;&nbsp;</SPAN></SPAN></SPAN><SPAN=3D20
=A0 = =A0 =A0 =A0 =A0 lang=3D3DEN-US>In figure 6, the UE may have an interface= with AF to=3D
=3D20
=A0 =A0 =A0 =A0 =A0 initiate the session request= , e.g., SIP.</SPAN></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV><BR></DIV>
=A0 =A0 =A0 =A0 = =A0 <DIV>Thank you,</DIV>Tina</DIV>
=A0 =A0 =A0 =A0 = =A0 <DIV><BR>On Dec 4, 2012, at 11:10 PM, "<A=3D20
= =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>mohamed.boucadair@orange.com</A>" &lt;<= A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>mohamed.boucadair@orange.com</A>&gt;=3D20
wr= ote:<BR><BR></DIV>
=A0 =A0 =A0 =A0 =A0 <DIV><= /DIV>
=A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">= ;
=A0 =A0 =A0 =A0 =A0 =A0 <DIV><SPAN>Dear Wes,</SPAN><BR= ><SPAN></SPAN><BR><SPAN>Thank you=3D
=A0for= =3D20
=A0 =A0 =A0 =A0 =A0 =A0 your comments. </SPAN><BR><= SPAN></SPAN><BR><SPAN>Please see inl=3D
ine.=3D20
=A0 =A0 =A0 =A0 =A0 =A0 </SPAN><BR><SPAN><= ;/SPAN><BR><SPAN>Cheers,</SPAN><BR><SPAN>M= ed=3D20
=A0 =A0 =A0 =A0 =A0 =A0 </SPAN><BR><SPAN></= SPAN><BR>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"= ;cite"><SPAN>-----Message=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 d'origine-----</SPAN><BR></B= LOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite= "><SPAN>De : George, Wes [mailto:<A=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 href=3D3D"mailto:wesley.george@twcable.com"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>wesley.george@twcable.com</A>]=3D20
</SP= AN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUO= TE type=3D3D"cite"><SPAN>Envoy=3DE9 : mardi 4 d=3DE9cemb= re 2=3D
012=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 21:09</SPAN><BR></BL= OCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>=3DC0 : BOUCADAIR Mohamed OLNC/OL=3D
N; <A=3D20<= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:fmc@ietf.org" target=3D3D_blank>fmc@ietf.org</A>=3D
; <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:int-area@ietf.org"=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>int-area@ietf.org</A></SPAN><BR></BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>Cc : <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:<= a href=3D"mailto:draft-boucadair-intarea-host-identifier-scenar">draft-bouc= adair-intarea-host-identifier-scenar=3D
ios@tools.ietf.org"=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>draft-boucadair-intarea-ho= st-identifier-scena=3D
rios@tools= .ietf.org</A></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>Objet : RE:=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-boucadair-intare= a-host-identifier-scenarios</SPAN><BR><=3D
/BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">&l= t;SPAN></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>I've read this draft, and I thi=3D
nk=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 the use case list is </SPAN><BR></BLOCKQUOTE>=
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>reasonably=3D20
=A0 =A0 =A0 =A0 =A0 =A0 complete.</SPAN><BR></BLOCKQUOTE>=
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 = =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN>However, it'= ;s really unclear to=3D
=A0me=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 what the value of this </SPAN&= gt;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE = type=3D3D"cite"><SPAN>draft might be in its current f=3D=
orm,=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 and what its intended </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>audience might be. Cataloging u=3D
se=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 cases is not all that </SPAN><BR></BLOCKQUOTE>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>helpful by itself without an en=3D
d=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 goal in mind, and that end </SPAN&= gt;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE = type=3D3D"cite"><SPAN>goal is not clear from the=3D20=A0 =A0 =A0 =A0 =A0 =A0 =A0 draft.</SPAN><BR></BLOCKQUOTE&g= t;<SPAN></SPAN><BR><SPAN>Med: The=3D
=A0goal=3D20
=A0 =A0 =A0 =A0 =A0 =A0 of this draft is what is described = in Section=3D20
=A0 =A0 =A0 =A0 =A0 =A0 2:</SPAN><BR><SPA= N></SPAN><BR><SPAN>"The goal is=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 to</SPAN><BR><SPAN>&nbsp;&nbsp;id= entify scenarios the authors a=3D
re=3D20
=A0 =A0 =A0 =A0 =A0 =A0 aware of and which share the same</SP= AN><BR><SPAN>&nbsp;&nbsp;i=3D
ssue=3D20
=A0 = =A0 =A0 =A0 =A0 =A0 of host=3D20
=A0 =A0 =A0 =A0 =A0 =A0 identification.= </SPAN><BR><SPAN></SPAN><BR><SPAN>&= nbsp;&nbsp;Th=3D
is=3D20
=A0 =A0 =A0 =A0 =A0 =A0 document does not include any solution-s= pecific=3D20
=A0 =A0 =A0 =A0 =A0 =A0 discussion.</SPAN><BR>&= lt;SPAN>&nbsp;&nbsp;This document can be us=3D
ed as=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 a tool to design solution(s)=3D20
=A0 =A0 =A0 =A0 =A0 =A0 mitigating</SPAN><BR><SPAN>&n= bsp;&nbsp;the encountered issues.=3D
=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 &nbsp;Having a generic solution which would=3D20
=A0 =A0 =A0 =A0= =A0 =A0 solve</SPAN><BR><SPAN>&nbsp;&nbsp;the is= sues encountered in the=3D
se=3D20
=A0 =A0 =A0 =A0 =A0 =A0 use cases is preferred over designing<= ;/SPAN><BR><SPAN>&nbsp;&nb=3D
sp;a=3D20
=A0 = =A0 =A0 =A0 =A0 =A0 solution for each use case. &nbsp;Describing the us= e case allow=3D
s=3D20
=A0 =A0 =A0 =A0 =A0 =A0 to</SPAN><BR&= gt;<SPAN>&nbsp;&nbsp;identify what is common between =3D
the=3D20
=A0 =A0 =A0 =A0 =A0 =A0 use cases and then would help</SPAN&= gt;<BR><SPAN>&nbsp;&nbsp;durin=3D
g the=3D20
=A0 = =A0 =A0 =A0 =A0 =A0 solution design phase."</SPAN><BR><= SPAN></SPAN><BR><SPAN>Next=3D20
=A0 =A0 =A0 =A0 =A0 =A0 updates of this draft will:</SPAN><BR>&= lt;SPAN>* include a discuss=3D
ion=3D20
=A0 =A0 =A0 =A0 =A0 =A0 se= ction to assess whether the issue is valid for IPv4-only or i=3D
t=3D20<= br>=A0 =A0 =A0 =A0 =A0 =A0 applies also for IPv6</SPAN><BR><= SPAN>* include a discussion te=3D
xt to=3D20
=A0 =A0 =A0 =A0 =A0 =A0 clarify whether each use case is vali= d within one single=3D20
=A0 =A0 =A0 =A0 =A0 =A0 administrative domain o= r not</SPAN><BR><SPAN>* include a discus=3D
sion=3D20<= br>=A0 =A0 =A0 =A0 =A0 =A0 text to identify use cases which share the same = requirements (t=3D
his=3D20
=A0 =A0 =A0 =A0 =A0 =A0 will help in designing the solution) &l= t;/SPAN><BR><SPAN>* add=3D20
=A0 =A0 =A0 =A0 =A0 =A0 addi= tional use cases if any</SPAN><BR><SPAN></SPAN><= BR><SPAN>At=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 given point in time we need to draw conclu= sions about the=3D20
=A0 =A0 =A0 =A0 =A0 =A0 following:</SPAN><= BR><SPAN>(1) are these use cases valid=3D20
=A0 =A0 =A0 =A0 =A0= =A0 ones?</SPAN><BR><SPAN>(2) if this is a real technica= l problem, =3D
what=3D20
=A0 =A0 =A0 =A0 =A0 =A0 the IETF can do to solve the issue?<= ;/SPAN><BR><SPAN>(3) if ther=3D
e is=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 interest in this area, how to organize the work for the solutio= =3D
n=3D20
=A0 =A0 =A0 =A0 =A0 =A0 space.</SPAN><BR><S= PAN></SPAN><BR><SPAN>The scope is deliberate=3D
ly=3D20
=A0 =A0 =A0 =A0 =A0 =A0 </SPAN><BR>
=A0 =A0 =A0 = =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN>very na= rrow and references othe=3D
r=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 drafts= that discuss some of </SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>the surrounding issues with add=3D
ress=3D20
=A0 =A0 =A0 =A0 =A0= =A0 =A0 sharing and unique </SPAN><BR></BLOCKQUOTE>
= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>identifiers, and so there is ve=3D
ry=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 little text in each section </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOT= E type=3D3D"cite"><SPAN>beyond a basic description. Eve= =3D
n=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 when you think of this in <= /SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>terms of follow-on drafts such =3D
as a=3D20
=A0 =A0 =A0 =A0 =A0= =A0 =A0 gap analysis or problem </SPAN><BR></BLOCKQUOTE>=
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>statement or solution drafts, o=3D
ne=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 wonders how useful it is to </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOT= E type=3D3D"cite"><SPAN>spread this across multiple dra= =3D
fts.=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 So why not simply </SPAN= ><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>incorporate this list into one =3D
of=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 the referenced general </SPAN><BR></BLOCKQUOTE>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><S= PAN>drafts on host identification, =3D
such=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 as nat-reveal-analysis and </SP= AN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUO= TE type=3D3D"cite"><SPAN>then broaden that draft so that= =3D
=A0it=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 considers and addresses th= e </SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>other use cases as=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 appropriate?<= ;/SPAN><BR></BLOCKQUOTE><SPAN></SPAN><BR>&= lt;SPAN>Me=3D
d: As I=3D20
=A0 =A0 =A0 =A0 =A0 =A0 mentioned above, we don't want to include any s= olution-specific=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 discussion to this = draft. The text is shortened in=3D20
=A0 =A0 =A0 =A0 =A0 =A0 purpose.<= ;/SPAN><BR><SPAN></SPAN><BR>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite"><SPAN>Otherwise, I think = that the dra=3D
ft=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 needs to be much clearer </SPAN><BR>= ;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&qu= ot;cite"><SPAN>about the unique issues and=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 considerations for each use case, </SPAN><BR&g= t;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>especially those that are someh=3D
ow=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 distinct from those covered </SPAN><BR></BLOCKQUOTE&= gt;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">= <SPAN>in nat-reveal-analysis so that =3D
it=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 can serve as a better input </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOT= E type=3D3D"cite"><SPAN>to any potential solutions=3D20<= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 addressing this=3D20
=A0 =A0 =A0 =A0 =A0 =A0 problem.</SPAN><BR></BLOCKQUOTE>&= lt;SPAN></SPAN><BR><SPAN>Med: Ful=3D
ly=3D20
=A0= =A0 =A0 =A0 =A0 =A0 agreed. This will be added to the next rev of the=3D20=
=A0 =A0 =A0 =A0 =A0 =A0 draft.</SPAN><BR><SPAN></S= PAN><BR>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite"><SPAN>I also believe that= if this dra=3D
ft is=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 to remain a standalone </SPAN><BR>&= lt;/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"= ;cite"><SPAN>document, the authors need to m=3D
ake=3D20=A0 =A0 =A0 =A0 =A0 =A0 =A0 at least some attempt at </SPAN><BR&= gt;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>discussing security and privacy=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0= =A0 considerations here, even if </SPAN><BR></BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">&l= t;SPAN>it is mainly to refer the reade=3D
r to=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 more in-depth discussions </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOT= E type=3D3D"cite"><SPAN>of the matter in other=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 drafts.</SPAN><BR></BLOCKQUOTE&g= t;<SPAN></SPAN><BR><SPAN>Med: Ag=3D
ree. A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 pointer to <A=3D20
=A0 =A0 =A0= =A0 =A0 =A0 href=3D3D"http://too= ls.ietf.org/html/draft-ietf-intarea-nat-revea=3D
l-analysis-04#section-3"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 target=3D= 3D_blank>http://tools.ietf.org/html= /draft-ietf-intarea-n=3D
at-reveal-analysis-04#section-3</A>=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 will be added to the next rev of the draft. The text will also=3D
= =3D20
=A0 =A0 =A0 =A0 =A0 =A0 include some discussion for use cases whic= h are restricted to o=3D
ne=3D20
=A0 =A0 =A0 =A0 =A0 =A0 single administrative=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 domain.</SPAN><BR><SPAN></SPAN><BR><SP= AN></SPAN><BR><SPAN>Again=3D
,=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 here is an area where </SPAN><BR>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>being clear about the specific=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 considerations for each use </SPAN><BR></BLOCKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= SPAN>case is important, identifying=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 whether the other drafts </SPAN>= <BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE typ= e=3D3D"cite"><SPAN>discuss things so that they are=3D=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 applicable to all of the use </SPA= N><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>cases, or if the use cases are=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 unique in any number of ways </SPAN><BR></BLOCKQUOTE>=
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>that will mean that they have u=3D
nique=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 privacy and security </SPAN>= ;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D= 20
type=3D3D"cite"><SPAN>considerations.</SPAN>= <BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite"><SPAN>Thanks,</SPAN>= ;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite"><SPAN>Wes George</SPAN= ><BR></BLOCKQUO=3D
TE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"&= gt;<SPAN></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 = =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0= =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN>-----O= riginal=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Message-----</SPAN><BR></BLO= CKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE ty= pe=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE t= ype=3D3D"cite"><SPAN>From: <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:int-area-bounces@ietf.org"=3D20
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>int-area-bounces@ietf.org</A> [mailto:<A=3D20<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:int-area-bounces@ietf.org"=3D20
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>int-area-bounces@ietf.org</A>]=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 On</SPAN><BR></BLOCKQUOTE><= ;/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"c= ite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"= cite"><SPAN>Behalf Of <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:mohamed.boucadair@orange.com"=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>mohamed.boucadair@orange.com</A></SP= AN><BR>=3D
</BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCK= QUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOC= KQUOTE type=3D3D"cite"><SPAN>Sent: Monday, December 03, = 20=3D
12=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4:08 AM</SPAN><= ;BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>To: <A href=3D3D"mailto:fmc@iet=3D
f.org"=3D20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc@ietf.org</A>; <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 href=3D3D"mailto:int-are= a@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_bl= ank>int-area@ietf.org</A>= </SPAN><BR></BLOCKQUOT=3D
E></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3= D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D= 3D"cite"><SPAN>Cc: <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 href=3D3D"mailto:draft-boucadair-intarea-host-identifier-scen=3D
arios@tools.ietf.org"=3D20=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>draft-boucadair-in= tarea-host-identifier-sce=3D
na= rios@tools.ietf.org</A></SPAN><BR></BLOCKQUOTE>= </BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>Subject: [Int-area]=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-bou= cadair-intarea-host-identifier-scenarios</SPAN><BR=3D
></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <B= LOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <= BLOCKQUOTE type=3D3D"cite"><SPAN></SPAN><BR>= </BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>Dear=3D20
=A0 =A0 =A0 =A0 =A0 =A0 all,</SPAN>= <BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>We submitted an updated versi=3D
on of=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 this draft to list use cases=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 which</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>encounter the issue of host=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i= dentification. The following </SPAN><BR></BLOCKQUOTE><= /BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;><SPAN>use cases are</SPAN><BR></BLOCK=3D
QU= OTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"= ;><SPAN>discussed in the=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 draft:</SPAN><BR></BLOCKQUOTE>= ;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&qu= ot;cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&q= uot;cite"><SPAN></SPAN><BR></BLOCKQUOTE><= ;/BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>&nbsp;&nbsp;(1) &nbsp;Carrier=3D
=3D20<= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Grade NAT (CGN)</SPAN><BR>&l= t;/BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(2) &nbsp;A+P (e.=3D
g.,=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 MAP )</SPAN><BR></BLOCKQUOTE><= /BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(3) &nbsp;Applica=3D
tion=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Proxies</SPAN><BR></BLOCKQUOTE>&l= t;/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(4) &nbsp;Provide=3D
r=3D20
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Wi-Fi</SPAN><BR></BLOCKQUOTE></BL= OCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(5) &nbsp;Policy =3D
and=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Charging Architectures</SPAN><BR></B= LOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(6) &nbsp;Cellula=3D
r=3D20
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Networks</SPAN><BR></BLOCKQUOTE><= /BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(7)=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &= nbsp;Femtocells</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>&nbsp;&nbsp;(8) &nbsp;Overlay=3D
=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Networks (e.g., CDNs)</SPAN><BR></BLOCKQ= UOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>The document does not include=3D
=A0any=3D20
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 solution-specific </SPAN><BR></BLOCKQUOTE&g= t;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&q= uot;cite"><SPAN>discussion. Its=3D20
=A0 =A0 =A0 =A0 =A0 =A0 main</SPAN><BR></BLOCKQUOTE>
= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>goal is to identify the use c=3D
ases=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and describe them.</SPAN>= ;<BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 = =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0= =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN></SPAN>&= lt;BR></BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>If you think your use case is=3D
=A0not=3D20
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 included in this version, </SPAN><BR&= gt;</BLOCKQUOTE></BLOCKQU=3D
OTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"= ><SPAN>please share</SPAN><BR></BLOCKQ=3D
UOTE&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">= <SPAN>it with=3D20
=A0 =A0 =A0 =A0 =A0 =A0 us.</SPAN><BR></BLOCKQUOTE></B= LOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite= ">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cit= e"><SPAN></SPAN><BR></BLOCKQUOTE></BLO= =3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>Comments are=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 welco= me.</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = type=3D3D"cite"><SPAN>Cheers,</SPAN><BR><= /BLOCKQUOTE></BLOCKQUOTE=3D
>
=A0 =A0 =A0 =A0 =A0 =A0 <BL= OCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = type=3D3D"cite"><SPAN>Med</SPAN><BR></BLO= CKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE ty= pe=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE t= ype=3D3D"cite"><SPAN></SPAN><BR></BLOCKQU= OTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D<= br>CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cit= e">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>-----Message=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 d'origine= -----</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 = =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>De : <A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"= mailto:i-d-announce-bounce= s@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_bl= ank>i-d-announce-bounce= s@ietf.org</A> [mailto:<=3D
A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:i-d-announce-"=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 target=3D3D_blank>i-d-announce-</A></SPAN><BR= ></BLOCKQUOTE></=3D
BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN><A href=3D3D"mailto:bounces@ie= t=3D
f.org"=3D2= 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>bounces@ietf.org</A>] De la part de <A=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:internet-drafts@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>internet-drafts@ietf.org</A>=3D20
=A0 = =A0 =A0 =A0 =A0 =A0 </SPAN><BR></BLOCKQUOTE></BLOCKQUO= TE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"&= gt;<SPAN>Envoy=3DE9 : lundi</SPAN><BR></BL=3D
OCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite= "><SPAN>3 d=3DE9cembre 2012 08:26 =3DC0 :=3D
=A0<A=3D20=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:i-d-announce@ietf.org"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>i-d-announce@ietf.org</A> Objet : I-D=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Action:</SPAN><BR></BLOCKQUO= TE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D= 3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 type=3D3D"cite"><SPAN>draft-boucadair-intarea-ho= st-identifier=3D
-scenarios-02.txt</SPAN><BR></BLOCKQUOTE= ></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D= "cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">= <SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN>A New Internet-Draft is avail=3D
able=3D20
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 from the on-line=3D20
Internet-Drafts</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 type=3D3D"cite"><SPAN>directories.</SPAN><B= R></BLOCKQUOTE></BLOCK=3D
QUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&quo= t;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&qu= ot;><SPAN></SPAN><BR></BLOCKQUOTE></BLO=3DCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type=3D3D"cite"><SPAN>&a= mp;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Title=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp=3D
;:=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Host Identification: Use Cases&l= t;/SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 = =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0= =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= type=3D3D"cite"><SPAN>&nbsp;&nbsp;&nbsp;&am= p;nbsp;&nbsp;Author(s)=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;: Mohamed=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Boucadair</SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>
= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 type=3D3D"cite"><SPAN>&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;&nbsp;&nb=3D
sp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;=3D
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;David=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Binet</SPAN><BR></BLOCKQUOTE= ></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D= "cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type=3D3D"cite"><SPAN>&a= mp;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=3D
sp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=3D
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sophie=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Durel</SPAN><BR></BLOCKQUOTE= ></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D= "cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type=3D3D"cite"><SPAN>&a= mp;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=3D
sp;= &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=3D
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tirumaleswar=3D= 20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Reddy</SPAN><BR></BLOC= KQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE typ= e=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 type=3D3D"cite"><SPAN>&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;&nbsp;&nb=3D
sp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;=3D
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Brandon=3D20=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Williams</SPAN><BR></BLOCKQ= UOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type= =3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 type=3D3D"cite"><SPAN>&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;Filename=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= :=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-boucadair-intarea-host-identifier-<= ;/SPAN><BR></BLOCKQ=3D
UOTE></BLOCKQUOTE>
=A0 = =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0= =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 typ= e=3D3D"cite"><SPAN>scenarios-02.txt</SPAN><BR&g= t;</BLOCKQUOTE><=3D
/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"ci= te">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 type=3D3D"cite"><SPAN>&nbsp;= &nbsp;&nbsp;&nbsp;&nbsp;Pages=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &nbsp;&nbsp;&nbsp;&nbsp;&am= p;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=3D
;:=3D20
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 14</SPAN><BR></BLOCKQUOTE>= ;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&qu= ot;cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=3D
;Date=3D20=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=3D
;&nbsp;:=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012-12-02</SPAN>= ;<BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 = =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0= =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN></SPAN>&= lt;BR></BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 type=3D3D"cite"><SPAN>Abstract:</SPAN>= <BR></BLOCKQUOTE></BLOCKQUO=3D
TE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"&= gt;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"= ><SPAN>&nbsp;&nbsp;This document=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 describes a set of scenarios in which=3D20
=A0 =A0 =A0 =A0 =A0 =A0 host</SPAN><BR></BLOCKQUOTE></= BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cit= e">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"ci= te"><SPAN>&nbsp;&nbsp;identification is=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 required.</SPAN><BR>&l= t;/BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQU= OTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQ= UOTE type=3D3D"cite"><SPAN></SPAN><BR></B= LOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&= quot;><SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D<= br>CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cit= e">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>The IETF datatracker status p=3D
age=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 for this draft is:</SPAN><BR></BLOCKQUOTE>= ;</BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D&qu= ot;cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"https://datatracker.ietf.org/doc/draft-boucadair-in=3D
tarea-host-"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_b= lank>https://datatracker.ietf.org/doc/draft-bouc=3D=
adair-intarea-host-</A></SPAN><BR></BLOCKQUOTE= ></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0= type=3D3D"cite"><SPAN>identifier-scenarios</SPAN>= <BR></BLOCKQUO=3D
TE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>There's also a htmlized versi=3D
on=3D20
=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 available at:</SPAN><BR></BLOCKQUOTE><= ;/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"c= ite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"http://tools.ietf.org/html/draft-boucadair-intarea-=3D=
host-identifier-"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target= =3D3D_blank>http://tools.ietf.org/html/draft-b= oucadair-=3D
intarea-host-identifier-</A></SPAN><BR&g= t;</BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 typ= e=3D3D"cite"><SPAN>scenarios-02</SPAN><BR>&l= t;/BLOCKQUOTE></BLOCK=3D
QUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN>A diff from the previous vers=3D
ion=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 is available at:</SPAN><BR></BLOCKQUOTE>&= lt;/BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"= ;cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"http://www.ietf.org/rfcdiff?url2=3D3Ddraft-boucadair-= =3D
intarea-host-"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D= _blank>http://www.ietf.org/rfcdiff?url2=3D3Ddra= ft-bo=3D
ucadair-intarea-host-</A></SPAN><BR></= BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0= type=3D3D"cite"><SPAN>identifier-scenarios-02</SPAN&= gt;<BR></BLOCK=3D
QUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE><= br>=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN></SPAN><BR></BLOCKQUOTE></BLO=3D
CKQUOTE&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">= <SPAN>Internet-Drafts are also avai=3D
lable=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 by anonymous FTP at:</SPAN= ><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0= =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN><A=3D20<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"ftp://ftp.ietf.org/internet-drafts/"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>ftp://ftp.ietf= .org/internet-drafts/</A></SP=3D
AN><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 = =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0= =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPAN></SPAN&= gt;<BR></BLOCKQUOTE></BLO=3D
CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 type=3D3D"cite"><SPAN>______________= _________________________=3D
________</SPAN><BR></BLOCKQU= OTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>I-D-Announce mailing=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list<= /SPAN><BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"mailto:<= a href=3D"mailto:I-D-Announce@ietf.org">I-D-Announce@ietf.org"=3D2= 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>I-D-Announce@ietf.org</A></SPAN><BR&g= t;</BLOCK=3D
QUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"https://www.ietf.org/mailman/listinfo/i-d-announce"=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www= .ietf.org/mailman/listinfo/i-d-a=3D
nnounce</A></SPAN>&l= t;BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>Internet-Draft directories: <=3D
A=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 href=3D3D"http://www.ietf.org/shadow.html"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>http://www.ietf.org/shadow.html= </A>=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 or</SPAN><BR><= ;/BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"ftp://ftp.= ietf.org/ietf/1shadow-sites.txt"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>ftp://ftp.ietf.org/ietf/1= shadow-sites.txt</=3D
A></SPAN><BR></BLOCKQUOTE= ></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 type=3D3D"cite"><SPAN>_____________________________= __________=3D
________</SPAN><BR></BLOCKQUOTE></BLO= CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN>Int-area mailing=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 list</SPAN>= ;<BR></BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">
=A0= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SP= AN><A href=3D3D"mailto:Int-area@i= e=3D
tf.org"= =3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>Int-area@ietf.org</A></SPAN><BR></B= LOCKQUOT=3D
E></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOC= KQUOTE type=3D3D"cite">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><= ;SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"htt= ps://www.ietf.org/mailman/listinfo/int-area"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www.ietf.org= /mailman/listinfo/int-a=3D
rea</A></SPAN><BR></= BLOCKQUOTE></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N></SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 = <BLOCKQUOTE type=3D3D"cite"><SPAN>This E-mail and any= of its=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 attachments may contain Time Wa= rner </SPAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>Cable proprietary information, =3D
which=3D20
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 is privileged, </SPAN><BR></BLOCKQUOTE>
= =A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>confidential, or subject to=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 copyright belonging to Time Warner </SPAN>= ;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE ty= pe=3D3D"cite"><SPAN>Cable. This E-mail is intended=3D=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 solely for the use of the </SPAN&g= t;<BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>individual or entity to which i=3D
t is=3D20
=A0 =A0 =A0 =A0 =A0= =A0 =A0 addressed. If you are not </SPAN><BR></BLOCKQUOTE&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">&= lt;SPAN>the intended recipient of this=3D
=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 E-mail, you are hereby notified </S= PAN><BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQU= OTE type=3D3D"cite"><SPAN>that any dissemination,=3D20=A0 =A0 =A0 =A0 =A0 =A0 =A0 distribution, copying, or action taken </S= PAN><BR></BLOCKQUOT=3D
E>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"&g= t;<SPAN>in relation to the contents of =3D
and=3D20
=A0 =A0 =A0= =A0 =A0 =A0 =A0 attachments to this E-mail </SPAN><BR></BLO= CKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite&q= uot;><SPAN>is strictly prohibited and may =3D
be=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 unlawful. If you have </SPAN>&= lt;BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type= =3D3D"cite"><SPAN>received this E-mail in error,=3D
= =3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 please notify the sender </SPAN>= <BR></BLOCKQUOTE>
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite"><SPA= N>immediately and permanently del=3D
ete=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 the original and any copy </SPAN><BR></BLOCKQUOTE>= ;
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE type=3D3D"cite">&l= t;SPAN>of this E-mail and any=3D20
=A0 =A0 =A0 =A0 =A0 =A0 =A0 printout.</SPAN><BR></BLOCKQUOTE= >
=A0 =A0 =A0 =A0 =A0 =A0 <BLOCKQUOTE=3D20
=A0 =A0 =A0 =A0 =A0 = =A0 type=3D3D"cite"><SPAN></SPAN><BR></BL= OCKQUOTE><SPAN>_____________=3D
__________________________________</SPAN><BR><SPAN>Int-ar= ea=3D20
=A0 =A0 =A0 =A0 =A0 =A0 mailing list</SPAN><BR><S= PAN><A href=3D3D"mailto:Int-= area@ietf.or=3D
g"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>Int-area@ietf.org</A></SPAN><BR&g= t;<SPAN><A=3D20
=A0 =A0 =A0 =A0 =A0 =A0 href=3D3D"https= ://www.ietf.org/mailman/listinfo/int-area"=3D20
=A0 =A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www.ietf.org/mailman= /listinfo/int-area<=3D
/A></SPAN><BR></DIV>&= lt;/BLOCKQUOTE></DIV><BR><BR>_________________________= ___=3D
___________________<BR>fmc=3D20
=A0 =A0 =A0 =A0 =A0 mailing list&l= t;BR><A href=3D3D"mailto:fmc@iet= f.org"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>fmc@ietf.org</A><BR><A=3D20
=A0 =A0 =A0 =A0 =A0 href=3D3D"https://www.ietf.org/mailman/listinfo/fmc"=3D20
=A0 =A0 =A0 =A0 =A0 target=3D3D_blank>https://www.ietf.org= /mailman/listinfo/fmc</A><BR>=3D
</BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE><= ;/DIV><BR></BLOCKQUOTE></DIV><BR>=3D
________= _______________________________________<BR>fmc=3D20
=A0 =A0 mailin= g list<BR><A href=3D3D"mailto:fmc@ietf.org">fmc@ietf.org= </A><BR><A=3D
=3D20
=A0 =A0 href=3D3D"https://www.ietf.org/mailman/listinfo/fmc&= quot;=3D20
=A0 =A0 target=3D3D_blank>https://www.ietf.org/mailman/listin= fo/fmc</A><BR><BR></=3D
BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HT= ML>

--_000_94C682931C08B048B7A8645303FDC9F36E9D16DF7CPUEXCB1Bnant= e_--


...

[Message clipped]=A0=A0

--bcaec53aecceb83a2104d0d3ae05--