From Dirk.von-Hugo@telekom.de Mon Oct 7 06:07:49 2013 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 9B20621E81B2 for ; Mon, 7 Oct 2013 06:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkr-1l+xR99r for ; Mon, 7 Oct 2013 06:07:44 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA721E80A6 for ; Mon, 7 Oct 2013 06:07:40 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 07 Oct 2013 15:07:38 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 7 Oct 2013 15:07:38 +0200 From: To: Date: Mon, 7 Oct 2013 15:07:36 +0200 Thread-Topic: Problem Statement Thread-Index: Ac6jUrbHGfLYLR2bQV+h/JhLbcTHwAgB4+Rw Message-ID: <05C81A773E48DD49B181B04BA21A342A2C72CCCE64@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C72CCCE64HE113484emea1_" MIME-Version: 1.0 Cc: sarikaya@ieee.org, mohamed.boucadair@orange.com Subject: Re: [fmc] Problem Statement 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, 07 Oct 2013 13:07:49 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C72CCCE64HE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, There is some discussion ongoing in the Design team on the PS draft which w= ill be elaborated until and hopefully be presented in Vancouver meeting amo= ng those present. A new PS draft should describe the need for a solution to unambiguously ide= ntify of a host independent of current access network (therefore being FMC = issue) and could point to both major currently discussed use cases i.e. - Address sharing and need for location resolution as required for= emergency calls in the ETSI scenario with packet flow changers (VPNs, CGN,= ...) as a mainly IPv4 issue - Prefix sharing and need for subscriber/policy/service authentica= tion & identification across BBF network boundaries e.g. via DHCPv6-PD Within SDO ETSI the issue of (IP-based) location identification for emerge= ncy calls is currently under discussion which could result in sending a cor= responding LS to stimulate and justify IETF APS activities. The richness of other use cases should not be described in detail for sake = of simplicity and clarity but will be mentioned via reference to Meds draft= below. What do you think? Please join the discussion here on the list and in Vancouver such that we m= ight come up essential documents for London meeting next year. Thanks and best regards! Dirk From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Dienstag, 27. August 2013 20:25 To: fmc@ietf.org Cc: Mohamed Boucadair; von Hugo, Dirk Subject: Problem Statement Folks, As we discussed in Berlin meeting (IETF 87) it will be good to draft a docu= ment clarifying the issues we discussed in aps Bar BoF, i.e. problem statem= ent draft. Med has kindly agreed to lead this activity and he suggested that the draft= should be based on draft-boucadair-intarea-host-identifier-scenarios with the inclusion of the prefix sharing issue. If you would like to work on the problem statement, please send a mail to M= ed and cc to me and Dirk. Regards, Behcet --_000_05C81A773E48DD49B181B04BA21A342A2C72CCCE64HE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

There is some discussion on= going in the Design team on the PS draft which will be elaborated until and= hopefully be presented in Vancouver meeting among those present.

A new PS draft should describe the need for a sol= ution to unambiguously identify of a host independent of current access net= work (therefore being FMC issue) and could point to both major currently di= scussed use cases i.e.

-      &nbs= p;   Address sharing and need for location resoluti= on as required for emergency calls in the ETSI scenario with packet flow ch= angers (VPNs, CGN, …) as a mainly IPv4 issue

= -  &n= bsp;       Prefix sharing and n= eed for subscriber/policy/service authentication & identification acros= s BBF network boundaries e.g. via DHCPv6-PD

=  Within SDO ETSI the issue of (IP-based) location identification for e= mergency calls is currently under discussion which could result in sending = a corresponding LS to stimulate and justify IETF APS activities.

The richness of other use cases sho= uld not be described in detail for sake of simplicity and clarity but will = be mentioned via reference to Meds draft below.

 

What do you think?       

 

Please join the discussion here on the list and in Van= couver such that we might come up essential documents for London meeting ne= xt year.

 =

Thanks and best regards!<= /span>

Dirk

From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent:<= /b> Dienstag, 27. August 2013 20:25
To: fmc@ietf.org
Cc: Mohamed Boucadair; von Hugo, Dirk
Subject: Problem Statement

 

Folks,<= o:p>

As = we discussed in Berlin meeting (IETF 87) it will be good to draft a documen= t clarifying the issues we discussed in aps Bar BoF, i.e. problem statement= draft.

Med has kindly agreed to l= ead this activity and he suggested that the draft should be based on
dr= aft-boucadair-intarea-host-identifier-scenarios

with the inclusion of the prefix sharing issue.

 

If you would like to work on th= e problem statement, please send a mail to Med and cc to me and Dirk.<= /o:p>

Regards,=

Behcet

 

= --_000_05C81A773E48DD49B181B04BA21A342A2C72CCCE64HE113484emea1_-- From xueli@huawei.com Mon Oct 21 18:49:48 2013 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 1238011E82F3 for ; Mon, 21 Oct 2013 18:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8k5LrjRF7MP for ; Mon, 21 Oct 2013 18:49:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD711E82B0 for ; Mon, 21 Oct 2013 18:49:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA77298; Tue, 22 Oct 2013 01:49:36 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 02:49:27 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 02:49:35 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.63]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 09:49:27 +0800 From: Xueli To: "fmc@ietf.org" Thread-Topic: New Version Notification for draft-xue-aps-service-chaining-usecase-00.txt Thread-Index: AQHOzngCHY9kG8k3Z0W5EdF4aUCCnZn/881Q Date: Tue, 22 Oct 2013 01:49:25 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448F290C4@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448F290C4nkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sarikaya2012@gmail.com" , "Dirk.von-Hugo@telekom.de" Subject: [fmc] FW: New Version Notification for draft-xue-aps-service-chaining-usecase-00.txt 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, 22 Oct 2013 01:49:48 -0000 --_000_01FE63842C181246BBE4CF183BD159B448F290C4nkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all There is a new draft which is the use case about address sharing issues in = service function chaining. The use cases are on the parental control service and offloading service. Your comments and opinions are appreciated. Regards Li On Mon, Oct 21, 2013 at 11:07 AM, > wrote: A new version of I-D, draft-xue-aps-service-chaining-usecase-00.txt has been successfully submitted by Li Xue and posted to the IETF repository. Filename: draft-xue-aps-service-chaining-usecase Revision: 00 Title: Address Sharing Problem Use Cases in Service Chaining Scen= ario Creation date: 2013-10-21 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-xue-aps-service-= chaining-usecase-00.txt Status: http://datatracker.ietf.org/doc/draft-xue-aps-service-chai= ning-usecase Htmlized: http://tools.ietf.org/html/draft-xue-aps-service-chaining-= usecase-00 Abstract: The purpose of this document is to present two use cases on problems arising from address sharing in service function chaining. The use cases are on the parental control service and offloading service. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_01FE63842C181246BBE4CF183BD159B448F290C4nkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 = ;

There is a= new draft which is the use case about address sharing issues in service fu= nction chaining.

The use ca= ses are on the parental control service and offloading service.<= /span>

Your comme= nts and opinions are appreciated.

 = ;

Regards

Li


=  

On Mon, Oct 21, 2013 at 11:07 A= M, <intern= et-drafts@ietf.org> wrote:

=
A new version of I-D, draft-xue-aps-service-chaining-usecase-00.txt
has been successfully submitted by Li Xue and posted to the
IETF repository.

Filename:        draft-xue-aps-service-chaining-usecase=
Revision:        00
Title:           Address Sharing Problem Use Cases= in Service Chaining Scenario
Creation date:   2013-10-21
Group:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-xue-aps-service-chaining-usecase-= 00.txt
Status:          http://= datatracker.ietf.org/doc/draft-xue-aps-service-chaining-usecase
Htmlized:        http://tools.i= etf.org/html/draft-xue-aps-service-chaining-usecase-00


Abstract:
   The purpose of this document is to present two use cases on pr= oblems
   arising from address sharing in service function chaining. &nb= sp;The use
   cases are on the parental control service and offloading servi= ce.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 

--_000_01FE63842C181246BBE4CF183BD159B448F290C4nkgeml504mbxchi_-- From Dirk.von-Hugo@telekom.de Fri Oct 25 08:32:28 2013 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 1EBAF11E82CB for ; Fri, 25 Oct 2013 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVykb906jdT2 for ; Fri, 25 Oct 2013 08:32:24 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id DD25F11E821D for ; Fri, 25 Oct 2013 08:32:20 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Oct 2013 17:32:12 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by he110890 ([10.134.92.131]) with mapi; Fri, 25 Oct 2013 17:32:12 +0200 From: To: Date: Fri, 25 Oct 2013 17:32:11 +0200 Thread-Topic: LS from ETSI E2NA to IETF on HOST ID standardization Thread-Index: Ac7Rkk9G9RWd48h+SA24+KAbNtQGUwAAVF/w Message-ID: <05C81A773E48DD49B181B04BA21A342A2C75719503@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A2C751DBB5B@HE113484.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C75719503HE113484emea1_" MIME-Version: 1.0 Cc: sarikaya@ieee.org Subject: Re: [fmc] LS from ETSI E2NA to IETF on HOST ID standardization 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, 25 Oct 2013 15:32:28 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C75719503HE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, This is to keep you updated on recent progress in the area of APS (aka. PAA= S/FMC): Following some lobbying activity to outline the importance of one of our us= e cases raising the address / prefix sharing (APS) topic we got a Liaison S= tatement from European ETSI SDO related to location provision in case of an= emergency call to the emergency service provider. Except that the IETF iss= ue is named Host_ID but refers to the APS challenge (and that the LS still = refers to Meds draft draft-boucadair-intarea-nat-reveal-analysis which had bec= ome RFC 6967 in June) this might give our activities some impetus. You may find the document at http://docbox.etsi.org/E2NA/E2NA/05-CONTRIBUTI= ONS/2013/E2NA(13)000150_Liaison_Statement_to_IETF_on_HOST_ID_standardizatio= n.docx Also two new use case document proposals for APS have been drafted for poli= cy control (http://tools.ietf.org/html/draft-sarikaya-aps-prefix-sharing-us= ecase) and for service (function) chaining (http://tools.ietf.org/html/draf= t-xue-aps-service-chaining-usecase) which you might find to reads and revie= w. Please as usual post your comments and discussion topics to the list. Thanks a lot! Have a nice weekend! Best regards Dirk From: ETSI E2NAsupport [mailto:E2NAsupport@etsi.org] Sent: Montag, 21. Oktober 2013 15:40 To: joelja@bogus.com; von Hugo, Dirk; sarikaya@iee= e.org Cc: Pesando Luca; bruno.chatras@ORANGE.COM= ; ETSI E2NAsupport Subject: LS from ETSI E2NA to IETF on HOST ID standardization Dear all, Please find attached a liaison from ETSI E2NA to IETF on HOST ID standardiz= ation. Please confirm reception of this email. Thank you Best regards Sonia Compans Technical Officer ETSI Tel: +33 4 92 94 43 36 Mobile: +33 6 67 15 58 49 P Please consider your Environmental Responsibility: Before printing this e= -mail or any other document, ask yourself if you need a hard copy, and if s= o, print front & back, and 2 pages on each side --_000_05C81A773E48DD49B181B04BA21A342A2C75719503HE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,=

 <= /p>

This is to keep you updated on recent progre= ss in the area of APS (aka. PAAS/FMC):

 

Foll= owing some lobbying activity to outline the importance of one of our use ca= ses raising the address / prefix sharing (APS) topic we got a Liaison State= ment from European ETSI SDO related to location provision in case of an eme= rgency call to the emergency service provider. Except that the IETF issue i= s named Host_ID but refers to the APS challenge (and that the LS still refe= rs to Meds draft draft= -boucadair-intarea-nat-reveal-analysis which had b= ecome RFC 6967 in June) this might give our activities some impetus.=

 

You may find the document at http://docbox.etsi.org/E2NA/E2= NA/05-CONTRIBUTIONS/2013/E2NA(13)000150_Liaison_Statement_to_IETF_on_HOST_I= D_standardization.docx

 

Also two new use = case document proposals for APS have been drafted for policy control (http://tools.ietf.org/html/draft-sarikaya-aps-prefix-sharing-usecase) = and for service (function) chaining (http://tools.ietf.org/html/draft-xu= e-aps-service-chaining-usecase) which you might find to reads and revie= w. Please as usual post your comments and discussion topics to the list.

Thanks a lot!

 

Have a nice weekend!

 

Best re= gards

Dirk

From: ETSI E2NAsupport [mailto= :E2NAsupport@etsi= .org]

Sent: Mont= ag, 21. Oktober 2013 15:40
To: joelja@bogus.com; von Hugo, Dirk; sarikaya@ieee.org
Cc: P= esando Luca; = bruno.chatras@ORANGE.COM; ETSI E2NAsupport

Subject: LS from ETSI E2NA to IETF on HOST ID standardi= zation

 

Dear all,

 

Please find a= ttached a liaison from ETSI E2NA to IETF on HOST ID standardization.

Please confirm reception of this email.

 

Thank you

Best regards

Sonia Compans

Technical Officer

ETSI

Tel: +33 4 92 94 43 36

Mobile: +33 6 67 15 58 49<= /p>

P Please consider your Environmental Responsibility: Before pr= inting this e-mail or any other document, ask yourself if you need a hard c= opy, and if so, print front & back, and 2 pages on each side<= /span>

=  

 

<= /div>

 

= --_000_05C81A773E48DD49B181B04BA21A342A2C75719503HE113484emea1_-- From Dirk.von-Hugo@telekom.de Mon Oct 28 02:35:41 2013 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 559BB21E80A3 for ; Mon, 28 Oct 2013 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUDh1j2JeGRV for ; Mon, 28 Oct 2013 02:35:36 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFB21F9FA3 for ; Mon, 28 Oct 2013 02:35:33 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 28 Oct 2013 10:34:43 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 28 Oct 2013 10:34:42 +0100 From: To: Date: Mon, 28 Oct 2013 10:34:38 +0100 Thread-Topic: LS from ETSI E2NA to IETF on HOST ID standardization Thread-Index: Ac7Rkk9G9RWd48h+SA24+KAbNtQGUwAAVF/wAIkSUVA= Message-ID: <05C81A773E48DD49B181B04BA21A342A2C7571982A@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A2C751DBB5B@HE113484.emea1.cds.t-internal.com> <05C81A773E48DD49B181B04BA21A342A2C75719503@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C75719503@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C7571982AHE113484emea1_" MIME-Version: 1.0 Cc: sarikaya@ieee.org Subject: Re: [fmc] LS from ETSI E2NA to IETF on HOST ID standardization 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, 28 Oct 2013 09:35:41 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C7571982AHE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I would like to clarify referring to my mail below that the mentioned ETSI = LS was _not_ a result of active pushing from our side - which could be dedu= ced from using the expression "lobbying". Actually we just informed ETSI E2= NA about current APS planned activities fitting into existing ETSI work. Th= e location identification problem and a reference to Meds use case draft Dr= aft-boucadair-intarea-host-identifier-scenarios-03 are already addressed in= prior versions of ETSI draft standard ES 203 178 "Functional Architecture = to Support European Requirements on Emergency Caller Location Determination= and Transport" based on EC Mandate M/493. The SDO where we tried to advance an official demand for support was BBF as= mentioned in http://www.ietf.org/mail-archive/web/fmc/current/msg00195.htm= l - an item which is still pending ... Sorry for having intermixed that and choosing a maybe confusing wording. Nevertheless I hope that with this LS there is some more justification of t= he work planned in APS on a solution to the address and prefix sharing ambi= guity occurring in some environment. Hopefully this has clarified or prevented misunderstanding. In any case of = open questions please feel free to ask for more details! Thanks and best regards Dirk From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of von H= ugo, Dirk Sent: Freitag, 25. Oktober 2013 17:32 To: fmc@ietf.org Cc: sarikaya@ieee.org Subject: Re: [fmc] LS from ETSI E2NA to IETF on HOST ID standardization Dear all, This is to keep you updated on recent progress in the area of APS (aka. PAA= S/FMC): Following some lobbying activity to outline the importance of one of our us= e cases raising the address / prefix sharing (APS) topic we got a Liaison S= tatement from European ETSI SDO related to location provision in case of an= emergency call to the emergency service provider. Except that the IETF iss= ue is named Host_ID but refers to the APS challenge (and that the LS still = refers to Meds draft draft-boucadair-intarea-nat-reveal-analysis which had bec= ome RFC 6967 in June) this might give our activities some impetus. You may find the document at http://docbox.etsi.org/E2NA/E2NA/05-CONTRIBUTI= ONS/2013/E2NA(13)000150_Liaison_Statement_to_IETF_on_HOST_ID_standardizatio= n.docx Also two new use case document proposals for APS have been drafted for poli= cy control (http://tools.ietf.org/html/draft-sarikaya-aps-prefix-sharing-us= ecase) and for service (function) chaining (http://tools.ietf.org/html/draf= t-xue-aps-service-chaining-usecase) which you might find to reads and revie= w. Please as usual post your comments and discussion topics to the list. Thanks a lot! Have a nice weekend! Best regards Dirk From: ETSI E2NAsupport [mailto:E2NAsupport@etsi.org] Sent: Montag, 21. Oktober 2013 15:40 To: joelja@bogus.com; von Hugo, Dirk; sarikaya@iee= e.org Cc: Pesando Luca; bruno.chatras@ORANGE.COM= ; ETSI E2NAsupport Subject: LS from ETSI E2NA to IETF on HOST ID standardization Dear all, Please find attached a liaison from ETSI E2NA to IETF on HOST ID standardiz= ation. Please confirm reception of this email. Thank you Best regards Sonia Compans Technical Officer ETSI Tel: +33 4 92 94 43 36 Mobile: +33 6 67 15 58 49 P Please consider your Environmental Responsibility: Before printing this e= -mail or any other document, ask yourself if you need a hard copy, and if s= o, print front & back, and 2 pages on each side --_000_05C81A773E48DD49B181B04BA21A342A2C7571982AHE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,=

I would like to clarify r= eferring to my mail below that the mentioned ETSI LS was _not_ a res= ult of active pushing from our side – which could be deduced from usi= ng the expression “lobbying”. Actually we just informed ETSI E2= NA about current APS planned activities fitting into existing ETSI work. Th= e location identification problem and a reference to Meds use case draft Dr= aft-boucadair-intarea-host-identifier-scenarios-03 are already addressed in= prior versions of ETSI draft standard ES 203 178 “Functional Archite= cture to Support European Requirements on Emergency Caller Location Determi= nation and Transport” based on EC Mandate M/493.

 

The SDO where we tried to advance an official demand for support = was BBF as mentioned in http://www.ietf.org/mail-archive/web/fmc/current/ms= g00195.html - an item which is still pending … =

 

Sorry for having intermixed that and choosing a maybe confusin= g wording.

 

Nevertheless I hope that with this= LS there is some more justification of the work planned in APS on a soluti= on to the address and prefix sharing ambiguity occurring in some environmen= t.  

 

Hopefully this has clarified or pre= vented misunderstanding. In any case of open questions please feel free to = ask for more details!

 

Thanks and best regards=

Dirk

 

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] = On Behalf Of von Hugo, Dirk
Sent: Freitag, 25. Oktober 2013 1= 7:32
To: fmc@ietf.org
Cc: sarikaya@ieee.org
Subje= ct: Re: [fmc] LS from ETSI E2NA to IETF on HOST ID standardization=

 

Dear all,

 

This is to = keep you updated on recent progress in the area of APS (aka. PAAS/FMC):

 

=

Following some lobbying activity to outline the= importance of one of our use cases raising the address / prefix sharing (A= PS) topic we got a Liaison Statement from European ETSI SDO related to loca= tion provision in case of an emergency call to the emergency service provid= er. Except that the IETF issue is named Host_ID but refers to the APS chall= enge (and that the LS still refers to Meds draft draft-boucadair-intarea-nat-reveal-analysis<= /span> which had become RFC 6967 in June) this might give our activities some impetus.

 

You may find the document at http://docbox.etsi.org/E2NA/E2NA/05-CONTRIBUTI= ONS/2013/E2NA(13)000150_Liaison_Statement_to_IETF_on_HOST_ID_standardizatio= n.docx

 

Also two new use case document pr= oposals for APS have been drafted for policy control (http://tools.ie= tf.org/html/draft-sarikaya-aps-prefix-sharing-usecase) and for service = (function) chaining (http://tools.ietf.org/html/draft-xue-aps-service-ch= aining-usecase) which you might find to reads and review. Please as usu= al post your comments and discussion topics to the list. =

Thanks a lot!

 

Have a nice weekend!

 

Best regards=

Dirk

=

From: ETSI E2NAsupport [mailto:E2NAsupport@etsi.org]

Sent: Montag, 21. Oktober = 2013 15:40
To: joelja@bogus.com; von Hugo, Dirk; sarikaya@ieee.org
Cc: Pesando Luca; bruno.chatras@OR= ANGE.COM; ETSI E2NAsupport

= Subject: LS from ETSI E2NA to IETF on HOST ID standardization

 

Dear all,

 

Please find attached a liaiso= n from ETSI E2NA to IETF on HOST ID standardization.

P= lease confirm reception of this email.

 

Thank you

Best regards

Sonia Compans

Technical Officer

ETSI

Tel: +33 4 92 94 43 36

Mobile: +33 6 67 15 58 49

P P= lease consider your Environmental Responsibility: Before printing this e-ma= il or any other document, ask yourself if you need a hard copy, and if so,&= nbsp;print front & back, and 2 pages on each side<= /o:p>

 

 

 

= --_000_05C81A773E48DD49B181B04BA21A342A2C7571982AHE113484emea1_--