From sarikaya2012@gmail.com Thu Oct 4 15:29:22 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 DA78521F8587 for ; Thu, 4 Oct 2012 15:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 h5yix+t4aHD4 for ; Thu, 4 Oct 2012 15:29:22 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10621F8545 for ; Thu, 4 Oct 2012 15:29:22 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2575694iec.31 for ; Thu, 04 Oct 2012 15:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=qoY6vbMS56l55oAxP3vkE+J+RhvaudJD6ZrsBz0MyXE=; b=rK4CRq1Rb90qoKF2bInAa4/U0u10vJoLVzgPfpliItTvbbql2ppp7JvqO+Sygdd7xJ os6Fcl9x72HoK8pikRmOHkDmHciEBrpIJlL72tVqY7JmFZ7cJAgtOkT/oBen+aaa2+2+ kacxLNdDpRHwc6IHvsewSknfGjjwRI7qnJHY2rVLc81nzc9ahf22SQazoWBCW7+I4hQM 89+GXnQdyQ38hx9NeF+h9XSmQTGpHZse5G+L/3BDadN01XQKCnXPJymBG1fpOUJ7EpEj 85J6B/db84f3dTsG7YorKD3+++bDZT7JWcAn5iQXoHIDCBI+RPFwyMcwdiy8IHpyeTAk /qBA== MIME-Version: 1.0 Received: by 10.42.18.193 with SMTP id y1mr5716834ica.0.1349389762046; Thu, 04 Oct 2012 15:29:22 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Thu, 4 Oct 2012 15:29:21 -0700 (PDT) Date: Thu, 4 Oct 2012 17:29:21 -0500 Message-ID: From: Behcet Sarikaya To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [fmc] BoF session in Atlanta X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:29:23 -0000 Hello folks, FMC BoF has been scheduled for: Tuesday 1700-1830 Afternoon Session III in Salon E Regards, Dirk & Behcet From dromasca@avaya.com Fri Oct 5 02:21:16 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 7DC3C21F8600 for ; Fri, 5 Oct 2012 02:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.297 X-Spam-Level: X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 V9d2e-Sz6W00 for ; Fri, 5 Oct 2012 02:21:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6425121F85AE for ; Fri, 5 Oct 2012 02:21:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH6kblCHCzI1/2dsb2JhbABFvx2BCIIgAQEBAQMBAQEPHgo0FwQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEARIIGodjC5tHnQAEiz6FKWADm2+KKoJv X-IronPort-AV: E=Sophos;i="4.80,541,1344225600"; d="scan'208";a="327423868" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Oct 2012 05:15:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Oct 2012 04:59:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 11:21:09 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] BoF session in Atlanta Thread-Index: Ac2if7WBkH42wLxfTy6zPXEDqkbxqwAWujCw References: From: "Romascanu, Dan (Dan)" To: , Subject: Re: [fmc] BoF session in Atlanta 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, 05 Oct 2012 09:21:16 -0000 Note that the agenda at this point is marked as preliminary and changes in scheduling may still happen.=20 Regards, Dan > -----Original Message----- > From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: Friday, October 05, 2012 12:29 AM > To: fmc@ietf.org > Subject: [fmc] BoF session in Atlanta >=20 > Hello folks, >=20 > FMC BoF has been scheduled for: >=20 > Tuesday 1700-1830 Afternoon Session III in Salon E >=20 > Regards, >=20 > Dirk & Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Fri Oct 5 09:22:24 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 EE4D221F87A9 for ; Fri, 5 Oct 2012 09:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, 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 N6VsnpqmzSTb for ; Fri, 5 Oct 2012 09:22:24 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA0921F87A8 for ; Fri, 5 Oct 2012 09:22:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4943474iec.31 for ; Fri, 05 Oct 2012 09:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=v+2CNQ+3xNUCszssjMgv9uMGtJL3TvRLAs0jVTc8p2c=; b=TcOd9PHaUo9RBVyKNvSflWZyT0oMfq3eS/B8pSxH5/Il3XnUUXVInHQnKRq/VYn3RI 1kCN0Xky2iaS9a+0IyB6t5wh2Sh7UAYzuuOVgMeoABnqIweCSWxJHpZvUWtMtkgE50x0 7H5c3/EWHK63le9zLIMKUWkbl0rgLj+Oc4+BSpZnDfirVwevmt7qOHI7ThxUdpjX9Pen zLuLkvQDjjQNCZmTuJSexrm4IHAAvRV9WWNnssXEJYYS85ocr9sb6qwD4J7WbjGaku9f E7TKyqTQPLDv28LvQ9PIjBA+y/b2qYzoaubgyjUiJZup59xVeWf9HgOOWSrk9Ue/f3N2 Yg5w== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr1681095igc.37.1349454144045; Fri, 05 Oct 2012 09:22:24 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Fri, 5 Oct 2012 09:22:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Oct 2012 11:22:23 -0500 Message-ID: From: Behcet Sarikaya To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Cc: fmc@ietf.org Subject: Re: [fmc] BoF session in Atlanta X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 16:22:25 -0000 Hi Dan, On Fri, Oct 5, 2012 at 4:21 AM, Romascanu, Dan (Dan) wrote: > Note that the agenda at this point is marked as preliminary and changes > in scheduling may still happen. Absolutely. Please read it as: FMC BoF has been tentatively scheduled Regards, Behcet > > Regards, > > Dan > > > > >> -----Original Message----- >> From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of >> Behcet Sarikaya >> Sent: Friday, October 05, 2012 12:29 AM >> To: fmc@ietf.org >> Subject: [fmc] BoF session in Atlanta >> >> Hello folks, >> >> FMC BoF has been scheduled for: >> >> Tuesday 1700-1830 Afternoon Session III in Salon E >> >> Regards, >> >> Dirk & Behcet >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc From mohamed.boucadair@orange.com Tue Oct 16 00:04:13 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 ABCF721F8549 for ; Tue, 16 Oct 2012 00:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.125, 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 Pk0MtvC-gKwK for ; Tue, 16 Oct 2012 00:04:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7346A21F864D for ; Tue, 16 Oct 2012 00:04:10 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6800422C5E6; Tue, 16 Oct 2012 09:04:09 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4908F35C045; Tue, 16 Oct 2012 09:04:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 16 Oct 2012 09:04:05 +0200 From: To: "sarikaya@ieee.org" , "fmc@ietf.org" , "Dirk.von-Hugo@telekom.de" Date: Tue, 16 Oct 2012 09:04:03 +0200 Thread-Topic: [fmc] BoF session in Atlanta Thread-Index: Ac2if7V2b7EP0GSsT0eFQ3gt2nn/fwI5/q4A Message-ID: <94C682931C08B048B7A8645303FDC9F36E63206B3D@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: 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.16.44249 Cc: KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , DUREL Sophie OLNC/OLN , BINET David OLNC/OLN , JACQUENET Christian OLNC/OLN Subject: Re: [fmc] BoF session in Atlanta 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, 16 Oct 2012 07:04:13 -0000 Hi Behcet, Dirk, all, I still think it is too early to ask for a BoF for this work; mainly for th= e same reasons I listed here: http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html My colleagues and myself, contributed with technical input to be challenged= by this list. These inputs were recorded in http://tools.ietf.org/html/dra= ft-schott-fmc-requirements-03. As clearly indicated in that document, it is= not voicing for creating a WG but its purpose is to be a place to analyze = points which are claimed to be issues.=20 After internal discussion with Sophie, David, Fred and Pierrick, we conclud= ed the main concern is the UE identification. Nevertheless, this issue is n= ot specific to what is called here "fmc" but it is encountered in various u= se cases. For this reason, we edited this document: http://www.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-0= 0.txt.=20 We hope that document helped to provide a big picture view of the UE Identi= fication issue. Cheers, Med=20 >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de Behcet Sarikaya >Envoy=E9 : vendredi 5 octobre 2012 00:29 >=C0 : fmc@ietf.org >Objet : [fmc] BoF session in Atlanta > >Hello folks, > >FMC BoF has been scheduled for: > >Tuesday 1700-1830 Afternoon Session III in Salon E > >Regards, > >Dirk & Behcet >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc >= From Dirk.von-Hugo@telekom.de Tue Oct 16 04:36:39 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 C3D4521F8862 for ; Tue, 16 Oct 2012 04:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YqOh0I07TtXT for ; Tue, 16 Oct 2012 04:36:39 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 014B021F8887 for ; Tue, 16 Oct 2012 04:36:38 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Oct 2012 13:36:37 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Oct 2012 13:36:37 +0200 From: To: Date: Tue, 16 Oct 2012 13:36:36 +0200 Thread-Topic: New Version Notification for draft-xue-fmc-ps-02.txt Thread-Index: Ac2rDzbz1SvelnOxS7qNnBZvM+Md5QAgo6dg Message-ID: <05C81A773E48DD49B181B04BA21A342A27CCD057B6@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [fmc] WG: New Version Notification for draft-xue-fmc-ps-02.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, 16 Oct 2012 11:36:39 -0000 Dear all, We'd like to announce the updated version of the PS draft for fmc. For details please see below. Aim is to stimulate discussion on the most pressing issues from network int= egration point of view. Of course the way to come to potential solution app= roaches is still open. Please join the Bof in Atlanta! Best regards Dirk New Version Notification for draft-xue-fmc-ps-02.txt A new version of I-D, draft-xue-fmc-ps-02.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-xue-fmc-ps Revision: 02 Title: Problem Statement for Fixed Mobile Convergence Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-02.tx= t Status: http://datatracker.ietf.org/doc/draft-xue-fmc-ps Htmlized: http://tools.ietf.org/html/draft-xue-fmc-ps-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-xue-fmc-ps-02 Abstract: The purpose of this document is to analyze the issues that have arisen so far and to propose several use cases for the Fixed Mobile Convergence. This document gives a brief overview of the assumed Fixed Mobile Convergence architecture and related works and then introduces several Intarea type of use cases based on the partnership in Fixed Mobile Convergence architecture, such as User Equipment identification, mobility consideration, such as mobility status reporting in Wi-Fi network and transporting Wi-Fi link characteristics type of considerations. The IETF Secretariat From sarikaya2012@gmail.com Tue Oct 16 20:51:13 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 B898D1F042B for ; Tue, 16 Oct 2012 20:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 dtI+Afui45w0 for ; Tue, 16 Oct 2012 20:51:13 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 057531F041F for ; Tue, 16 Oct 2012 20:51:12 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so5899726iad.31 for ; Tue, 16 Oct 2012 20:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=xiEhqL1SDSwbqyTHHlTJJpO09l+qVvJWr175o7M8Z9M=; b=KsJ8iDQ9RGhc8QBwPKOGfGDSBy2LUs2kM7n4+A8cAMPYYcmkjoo+1NZzRxahDXsM2n rcXJQqnAPTLtwM+GUITudHHyJpnBaBRkFu/gbG4ybtx2jat1dgVr47hYDumhX0wePY8t R6yxgixld15e11SjqSxnmNO+yYVSoLv90K0ljFmL/dOJ9Nc2QJkYR+GMmXWbBs5QvYpD JUcMcxzCcKM2j7ad9xVUBE7eiIhIJtP7hQ0HTfUFY9emrMA6M8Y48ea4fcLHgLjTpITs j9VmHte+QOyQtbqui/a4qG+na0YaFGYEZVTBgXR8QUPHC/GCkYSyjjldfvkcURonOVpU i0mw== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr330570igc.37.1350445872577; Tue, 16 Oct 2012 20:51:12 -0700 (PDT) Received: by 10.231.85.26 with HTTP; Tue, 16 Oct 2012 20:51:12 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E63206B3D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E63206B3D@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 16 Oct 2012 22:51:12 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DUREL Sophie OLNC/OLN , "fmc@ietf.org" , BINET David OLNC/OLN , JACQUENET Christian OLNC/OLN , KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , "Dirk.von-Hugo@telekom.de" Subject: Re: [fmc] BoF session in Atlanta X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 03:51:13 -0000 Hi Med, all, Thanks for your mail. Yes, I read your new draft, draft-boucadair-intarea-host-identifier-scenarios-00.txt, of course we know that UE identification is not specific to fmc. Who said so? The reason we have been having this use case was because the request for IETF to be involved in fmc work has first been made during November 2011 3GPP-BBF FMC Workshop, Sophie would remember it very well, in the context of UE Identification use case which is in fact a well known problem with NATs and address sharing. Can I ask you how do you evaluate the chances of Intarea WG taking up this issue? I have seen the reviews of your NAT Reveal draft. I think that Intarea people are very reluctant to work on this old problem related to mainly IPv4. I wish you good luck in this, maybe you can turn things around. fmc is a set of issues arising from 3GPP UEs accessing a fixed network. 3GPP and BBF will be busy developing standards for fmc at least next one if not two years. Afterwards, some next generation activity might be started, who knows? So fmc is here to stay. I have been reading your mails and drafts recently and noticed that you mentioned almost in every mail or two, some issues related to fmc and also I have been seeing references to fmc in your drafts. So it is fair to say that fmc has made you more productive in IETF. Correct me if I am wrong, shouldn't you give some credit to Dirk and I for carrying the fmc flag in IETF and giving some inspiration to the researchers? Coming back to the UE identification use case, I am convinced more and more that we made a mistake in presenting UE Identification as the signature use case for fmc. In fact we can easily drop this use case and we will and can still have a lot to discuss on fmc in IETF. We will still keep our FT colleagues as co-authors if they wish so but we will give them a chance to drop out. As you know, fmc BoF is scheduled already and we have no possibility of removing it from the agenda. Lastly, in our drafts any time we mention UE Identification, we put a reference to your drafts. We have created a lot of advertisement, PR for you. Is it fair to say that this effort went unnoticed? Why should we continue to do so if there is no appreciation from your side? And we won't. Regards, Behcet On Tue, Oct 16, 2012 at 2:04 AM, wrote: > Hi Behcet, Dirk, all, > > I still think it is too early to ask for a BoF for this work; mainly for = the same reasons I listed here: > http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html > > My colleagues and myself, contributed with technical input to be challeng= ed by this list. These inputs were recorded in http://tools.ietf.org/html/d= raft-schott-fmc-requirements-03. As clearly indicated in that document, it = is not voicing for creating a WG but its purpose is to be a place to analyz= e points which are claimed to be issues. > > After internal discussion with Sophie, David, Fred and Pierrick, we concl= uded the main concern is the UE identification. Nevertheless, this issue is= not specific to what is called here "fmc" but it is encountered in various= use cases. For this reason, we edited this document: > http://www.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios= -00.txt. > > We hope that document helped to provide a big picture view of the UE Iden= tification issue. > > Cheers, > Med > >>-----Message d'origine----- >>De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>part de Behcet Sarikaya >>Envoy=E9 : vendredi 5 octobre 2012 00:29 >>=C0 : fmc@ietf.org >>Objet : [fmc] BoF session in Atlanta >> >>Hello folks, >> >>FMC BoF has been scheduled for: >> >>Tuesday 1700-1830 Afternoon Session III in Salon E >> >>Regards, >> >>Dirk & Behcet >>_______________________________________________ >>fmc mailing list >>fmc@ietf.org >>https://www.ietf.org/mailman/listinfo/fmc >> From mohamed.boucadair@orange.com Tue Oct 16 22:54:28 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 E97D521F87B6 for ; Tue, 16 Oct 2012 22:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.123, 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 kL-jCzWfysjU for ; Tue, 16 Oct 2012 22:54:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5521F87A8 for ; Tue, 16 Oct 2012 22:54:26 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7F0BD22C43C; Wed, 17 Oct 2012 07:54:25 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 607AA238056; Wed, 17 Oct 2012 07:54:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 17 Oct 2012 07:54:24 +0200 From: To: "sarikaya@ieee.org" Date: Wed, 17 Oct 2012 07:54:23 +0200 Thread-Topic: Need for a technical discussion before the BoF (was RE: [fmc] BoF session in Atlanta) Thread-Index: Ac2sGqg9dWQrnAJNQo6zVcfrjyEhTwADdSlA Message-ID: <94C682931C08B048B7A8645303FDC9F36E64431852@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E63206B3D@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: 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.17.44234 Cc: DUREL Sophie OLNC/OLN , "fmc@ietf.org" , BINET David OLNC/OLN , JACQUENET Christian OLNC/OLN , KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , "Dirk.von-Hugo@telekom.de" Subject: [fmc] Need for a technical discussion before the BoF (was RE: BoF session in Atlanta) 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, 17 Oct 2012 05:54:28 -0000 Behcet, See inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : mercredi 17 octobre 2012 05:51 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : fmc@ietf.org; Dirk.von-Hugo@telekom.de; JACQUENET=20 >Christian OLNC/OLN; DUREL Sophie OLNC/OLN; KLAMM Frederic=20 >OLNC/OLN; BINET David OLNC/OLN; SEITE Pierrick OLNC/OLN >Objet : Re: [fmc] BoF session in Atlanta > >Hi Med, all, >Thanks for your mail. >Yes, I read your new draft, >draft-boucadair-intarea-host-identifier-scenarios-00.txt, of course we >know that UE identification is not specific to fmc. Who said so? Med: You missed the point. The point is this issue is encountered in severa= l use cases, the one called "fmc" is only one among others.=20 * Why the IETF should focus only on this "fmc" case?=20 * Wouldn't be more interesting to cover all UE identification use cases if = there is a room for it?=20 * If there are no other important technical issues, wouldn't be more pragma= tic to focus on the UE identification technical issues? >The reason we have been having this use case was because the request >for IETF to be involved in fmc work has first been made during >November 2011 3GPP-BBF FMC Workshop, Sophie would remember it very >well, in the context of UE Identification use case which is in fact a >well known problem with NATs and address sharing. > >Can I ask you how do you evaluate the chances of Intarea WG taking up >this issue? Med: This is not the question. We are not there at this stage. That draft i= s an input to the discussion in this list. I really think we need to have t= echnical discussion in this list and more discussion on the issues before g= oing asking for a BoF on behalf of people subscribed in this list. Going ba= ck to the minutes of the barbof organized in the last IETF meeting, there w= ere a lot of questions about the issues and use cases. I don't remember rea= ding in those minutes a GO for asking for a BoF. =20 I have seen the reviews of your NAT Reveal draft. I think >that Intarea people are very reluctant to work on this old problem >related to mainly IPv4. I wish you good luck in this, maybe you can >turn things around. Med: We need to be fair here: intarea WG accepted to document the issues (R= FC6269) and also to analyse HOST_ID solutions. Intarea WG is a candidate WG= among others to host some specification work if there is a need for it. We= need to convince if we want that to happen. This is the analysis work I as= ked for it to happen in this list and which was explicitly mentioned in htt= p://tools.ietf.org/html/draft-schott-fmc-requirements-03#section-2.=20 > >fmc is a set of issues arising from 3GPP UEs accessing a fixed >network. 3GPP and BBF will be busy developing standards for fmc at >least next one if not two years. Afterwards, some next generation >activity might be started, who knows? So fmc is here to stay. Med: Why not working on a liaison from 3GPP-BBF?=20 > >I have been reading your mails and drafts recently and noticed that >you mentioned almost in every mail or two, some issues related to fmc >and also I have been seeing references to fmc in your drafts. > >So it is fair to say that fmc has made you more productive in IETF. >Correct me if I am wrong, shouldn't you give some credit to Dirk and I >for carrying the fmc flag in IETF and giving some inspiration to the >researchers? > >Coming back to the UE identification use case, I am convinced more and >more that we made a mistake in presenting UE Identification as the >signature use case for fmc. In fact we can easily drop this use case >and we will and can still have a lot to discuss on fmc in IETF. Med: Would it be possible to initiate a technical discussion on the other = issues in the list? This will be helpful to prepare the BoF.=20 We >will still keep our FT colleagues as co-authors if they wish so but we >will give them a chance to drop out. Med: I don't remember you provided a word in the requirements draft. We wil= l see what to do with that draft. > >As you know, fmc BoF is scheduled already and we have no possibility >of removing it from the agenda. > >Lastly, in our drafts any time we mention UE Identification, we put a >reference to your drafts. We have created a lot of advertisement, PR >for you. Is it fair to say that this effort went unnoticed? Why should >we continue to do so if there is no appreciation from your side? And >we won't. Med: No comment.=20 > >Regards, > >Behcet > >On Tue, Oct 16, 2012 at 2:04 AM, wrote: >> Hi Behcet, Dirk, all, >> >> I still think it is too early to ask for a BoF for this=20 >work; mainly for the same reasons I listed here: >> http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html >> >> My colleagues and myself, contributed with technical input=20 >to be challenged by this list. These inputs were recorded in=20 >http://tools.ietf.org/html/draft-schott-fmc-requirements-03.=20 >As clearly indicated in that document, it is not voicing for=20 >creating a WG but its purpose is to be a place to analyze=20 >points which are claimed to be issues. >> >> After internal discussion with Sophie, David, Fred and=20 >Pierrick, we concluded the main concern is the UE=20 >identification. Nevertheless, this issue is not specific to=20 >what is called here "fmc" but it is encountered in various use=20 >cases. For this reason, we edited this document: >> =20 >http://www.ietf.org/id/draft-boucadair-intarea-host-identifier- >scenarios-00.txt. >> >> We hope that document helped to provide a big picture view=20 >of the UE Identification issue. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>>part de Behcet Sarikaya >>>Envoy=E9 : vendredi 5 octobre 2012 00:29 >>>=C0 : fmc@ietf.org >>>Objet : [fmc] BoF session in Atlanta >>> >>>Hello folks, >>> >>>FMC BoF has been scheduled for: >>> >>>Tuesday 1700-1830 Afternoon Session III in Salon E >>> >>>Regards, >>> >>>Dirk & Behcet >>>_______________________________________________ >>>fmc mailing list >>>fmc@ietf.org >>>https://www.ietf.org/mailman/listinfo/fmc >>> >= From tso@zteusa.com Tue Oct 16 22:55:10 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 BFB6A21F87A8 for ; Tue, 16 Oct 2012 22:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 5piaY6YWqO54 for ; Tue, 16 Oct 2012 22:55:09 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8621F8799 for ; Tue, 16 Oct 2012 22:55:08 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6504D1258F7D; Wed, 17 Oct 2012 13:55:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9H5sxOL084271; Wed, 17 Oct 2012 13:54:59 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E63206B3D@PUEXCB1B.nanterre.francetelecom.fr> To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: F68BDEFE:3321E9E1-88257A9A:001F444A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 16 Oct 2012 22:54:31 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-17 13:54:43, Serialize complete at 2012-10-17 13:54:43 Content-Type: multipart/alternative; boundary="=_alternative 00207E6188257A9A_=" X-MAIL: mse01.zte.com.cn q9H5sxOL084271 Cc: DUREL Sophie OLNC/OLN , "fmc@ietf.org" , BINET David OLNC/OLN , JACQUENET Christian OLNC/OLN , KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , "Dirk.von-Hugo@telekom.de" , mohamed.boucadair@orange.com Subject: Re: [fmc] BoF session in Atlanta 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, 17 Oct 2012 05:55:10 -0000 This is a multipart message in MIME format. --=_alternative 00207E6188257A9A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear=20Behcet,=20 Sorry=20for=20jumping=20in=20late=20to=20tap=20on=20this=20subject=20and=20= I=20could=20not=20find=20time=20 to=20pay=20enough=20attention=20on=20this=20FMC=20initiatives.=20 After=20reading=20your=20responses=20to=20Med=20even=20raised=20more=20co= ncern=20and=20doubt=20on=20 my=20part: -=20referring=20to=20IETF=20FMC=20initiative=20to=20resolve=203GPP=20and=20= BBF=20issues=20for=203GPP=20 UE=20to=20access=20fixed=20network If=20this=20is=20what=20you=20believe,=20may=20I=20ask,=20once=20again,=20= where=20are=20the=20 requirements=20from=203GPP=20and=20BBF?=20=20Could=20you=20please=20ident= ify=20if=20there=20any=20 liaison=20coming=20from=203GPP=20and/or=20from=20BBF=20to=20ask=20for=20s= uch=20initiative=20in=20 IETF?=20 I=20sincerely=20believe=20that=20this=20would=20be=20very=20helpful=20for= =20"all"=20of=20us=20to=20 understand=20the=20justification=20for=20your=20belief=20that=20this=20FM= C=20"specific"=20work=20 item=20is=20needed=20in=20IETF.=20=20=20What=20do=20you=20think?=20 Thanks.. Tricci=20 Behcet=20Sarikaya=20=20 Sent=20by:=20fmc-bounces@ietf.org 10/16/2012=2008:51=20PM Please=20respond=20to sarikaya@ieee.org To mohamed.boucadair@orange.com cc DUREL=20Sophie=20OLNC/OLN=20,=20"fmc@ietf.org"=20= ,=20BINET=20David=20OLNC/OLN=20,=20= JACQUENET=20 Christian=20OLNC/OLN=20,=20KLAMM=20Freder= ic=20 OLNC/OLN=20,=20SEITE=20Pierrick=20OLNC/OLN=20 = ,=20"Dirk.von-Hugo@telekom.de"=20 Subject Re:=20[fmc]=20BoF=20session=20in=20Atlanta Hi=20Med,=20all, Thanks=20for=20your=20mail. Yes,=20I=20read=20your=20new=20draft, draft-boucadair-intarea-host-identifier-scenarios-00.txt,=20of=20course=20= we know=20that=20UE=20identification=20is=20not=20specific=20to=20fmc.=20Who= =20said=20so? The=20reason=20we=20have=20been=20having=20this=20use=20case=20was=20beca= use=20the=20request for=20IETF=20to=20be=20involved=20in=20fmc=20work=20has=20first=20been=20= made=20during November=202011=203GPP-BBF=20FMC=20Workshop,=20Sophie=20would=20remember=20= it=20very well,=20in=20the=20context=20of=20UE=20Identification=20use=20case=20whic= h=20is=20in=20fact=20a well=20known=20problem=20with=20NATs=20and=20address=20sharing. Can=20I=20ask=20you=20how=20do=20you=20evaluate=20the=20chances=20of=20In= tarea=20WG=20taking=20up this=20issue?=20I=20have=20seen=20the=20reviews=20of=20your=20NAT=20Revea= l=20draft.=20I=20think that=20Intarea=20people=20are=20very=20reluctant=20to=20work=20on=20this=20= old=20problem related=20to=20mainly=20IPv4.=20I=20wish=20you=20good=20luck=20in=20this,= =20maybe=20you=20can turn=20things=20around. fmc=20is=20a=20set=20of=20issues=20arising=20from=203GPP=20UEs=20accessin= g=20a=20fixed network.=203GPP=20and=20BBF=20will=20be=20busy=20developing=20standards=20= for=20fmc=20at least=20next=20one=20if=20not=20two=20years.=20Afterwards,=20some=20next=20= generation activity=20might=20be=20started,=20who=20knows?=20So=20fmc=20is=20here=20= to=20stay. I=20have=20been=20reading=20your=20mails=20and=20drafts=20recently=20and=20= noticed=20that you=20mentioned=20almost=20in=20every=20mail=20or=20two,=20some=20issues=20= related=20to=20fmc and=20also=20I=20have=20been=20seeing=20references=20to=20fmc=20in=20your= =20drafts. So=20it=20is=20fair=20to=20say=20that=20fmc=20has=20made=20you=20more=20p= roductive=20in=20IETF. Correct=20me=20if=20I=20am=20wrong,=20shouldn't=20you=20give=20some=20cre= dit=20to=20Dirk=20and=20I for=20carrying=20the=20fmc=20flag=20in=20IETF=20and=20giving=20some=20ins= piration=20to=20the researchers? Coming=20back=20to=20the=20UE=20identification=20use=20case,=20I=20am=20c= onvinced=20more=20and more=20that=20we=20made=20a=20mistake=20in=20presenting=20UE=20Identifica= tion=20as=20the signature=20use=20case=20for=20fmc.=20In=20fact=20we=20can=20easily=20dro= p=20this=20use=20case and=20we=20will=20and=20can=20still=20have=20a=20lot=20to=20discuss=20on=20= fmc=20in=20IETF.=20We will=20still=20keep=20our=20FT=20colleagues=20as=20co-authors=20if=20they= =20wish=20so=20but=20we will=20give=20them=20a=20chance=20to=20drop=20out. As=20you=20know,=20fmc=20BoF=20is=20scheduled=20already=20and=20we=20have= =20no=20possibility of=20removing=20it=20from=20the=20agenda. Lastly,=20in=20our=20drafts=20any=20time=20we=20mention=20UE=20Identifica= tion,=20we=20put=20a reference=20to=20your=20drafts.=20We=20have=20created=20a=20lot=20of=20ad= vertisement,=20PR for=20you.=20Is=20it=20fair=20to=20say=20that=20this=20effort=20went=20un= noticed?=20Why=20should we=20continue=20to=20do=20so=20if=20there=20is=20no=20appreciation=20from= =20your=20side?=20And we=20won't. Regards, Behcet On=20Tue,=20Oct=2016,=202012=20at=202:04=20AM,=20=20=20wrote: >=20Hi=20Behcet,=20Dirk,=20all, > >=20I=20still=20think=20it=20is=20too=20early=20to=20ask=20for=20a=20BoF=20= for=20this=20work;=20mainly=20for=20 the=20same=20reasons=20I=20listed=20here: >=20http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html > >=20My=20colleagues=20and=20myself,=20contributed=20with=20technical=20in= put=20to=20be=20 challenged=20by=20this=20list.=20These=20inputs=20were=20recorded=20in=20= http://tools.ietf.org/html/draft-schott-fmc-requirements-03.=20As=20clear= ly=20 indicated=20in=20that=20document,=20it=20is=20not=20voicing=20for=20creat= ing=20a=20WG=20but=20its=20 purpose=20is=20to=20be=20a=20place=20to=20analyze=20points=20which=20are=20= claimed=20to=20be=20issues. > >=20After=20internal=20discussion=20with=20Sophie,=20David,=20Fred=20and=20= Pierrick,=20we=20 concluded=20the=20main=20concern=20is=20the=20UE=20identification.=20Neve= rtheless,=20this=20 issue=20is=20not=20specific=20to=20what=20is=20called=20here=20"fmc"=20bu= t=20it=20is=20encountered=20 in=20various=20use=20cases.=20For=20this=20reason,=20we=20edited=20this=20= document: >=20=20 http://www.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-= 00.txt . > >=20We=20hope=20that=20document=20helped=20to=20provide=20a=20big=20pictu= re=20view=20of=20the=20UE=20 Identification=20issue. > >=20Cheers, >=20Med > >>-----Message=20d'origine----- >>De=20:=20fmc-bounces@ietf.org=20[mailto:fmc-bounces@ietf.org]=20De=20la= >>part=20de=20Behcet=20Sarikaya >>Envoy=E9=20:=20vendredi=205=20octobre=202012=2000:29 >>=C0=20:=20fmc@ietf.org >>Objet=20:=20[fmc]=20BoF=20session=20in=20Atlanta >> >>Hello=20folks, >> >>FMC=20BoF=20has=20been=20scheduled=20for: >> >>Tuesday=201700-1830=20=20=20=20=20=20Afternoon=20Session=20III=20in=20S= alon=20E >> >>Regards, >> >>Dirk=20&=20Behcet >>_______________________________________________ >>fmc=20mailing=20list >>fmc@ietf.org >>https://www.ietf.org/mailman/listinfo/fmc >> _______________________________________________ fmc=20mailing=20list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE=20Information=20Security=20Notice:=20The=20information=20contained=20= in=20this=20mail=20(and=20any=20attachment=20transmitted=20herewith)=20is= =20privileged=20and=20confidential=20and=20is=20intended=20for=20the=20ex= clusive=20use=20of=20the=20addressee(s).=20=20If=20you=20are=20not=20an=20= intended=20recipient,=20any=20disclosure,=20reproduction,=20distribution=20= or=20other=20dissemination=20or=20use=20of=20the=20information=20containe= d=20is=20strictly=20prohibited.=20=20If=20you=20have=20received=20this=20= mail=20in=20error,=20please=20delete=20it=20and=20notify=20us=20immediate= ly. --=_alternative 00207E6188257A9A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear=20Behcet,=20

Sorry=20for=20jumping=20in=20l= ate=20to=20tap=20on this=20subject=20and=20I=20could=20not=20find=20time=20to=20pay=20enough=20= attention=20on=20this FMC=20initiatives.=20 

After=20reading=20your=20respo= nses=20to=20Med even=20raised=20more=20concern=20and=20doubt=20on=20my=20part:
-=20referring=20to=20IETF=20FM= C=20initiative=20to resolve=203GPP=20and=20BBF=20issues=20for=203GPP=20UE=20to=20access=20fix= ed=20network

If=20this=20is=20what=20you=20= believe,=20may=20I=20ask, once=20again,=20where=20are=20the=20requirements=20from=203GPP=20and=20BB= F?=20 Could=20you please=20identify=20if=20there=20any=20liaison=20coming=20from=203GPP=20a= nd/or=20from=20BBF=20to ask=20for=20such=20initiative=20in=20IETF?=20 

I=20sincerely=20believe=20that= =20this=20would be=20very=20helpful=20for=20"all"=20of=20us=20to=20understand=20= the=20justification for=20your=20belief=20that=20this=20FMC=20"specific"=20work=20i= tem=20is=20needed in=20IETF.=20 =20What=20do=20you=20think?=20

Thanks..
Tricci=20



Behcet=20Sari= kaya=20<sarikaya2012@gmail.com>
Sent=20by:=20fmc-bounces@ietf.= org

10/16/2012=2008:51=20PM = Please=20res= pond=20to
sarikaya@ieee.org
To mohamed.boucadair@orange.com cc DUREL=20Sophie=20OLNC/OLN=20&l= t;sophie.durel@orange.com>, "fmc@ietf.org"=20<fmc@ietf.org>,=20BINET=20David=20OLNC/O= LN=20<david.binet@orange.com>, JACQUENET=20Christian=20OLNC/OLN=20<christian.jacquenet@orange.com>= ,=20KLAMM Frederic=20OLNC/OLN=20<frederic.klamm@orange.com>,=20SEITE=20Pierri= ck=20OLNC/OLN <pierrick.seite@orange.com>,=20"Dirk.von-Hugo@telekom.de"= <Dirk.von-Hugo@telekom.de> Subject Re:=20[fmc]=20BoF=20session=20= in=20Atlanta




Hi=20Med,=20all,
Thanks=20for=20your=20mail.
Yes,=20I=20read=20your=20new=20draft,
draft-boucadair-intarea-host-identifier-scenarios-00.txt,=20of=20course=20= we
know=20that=20UE=20identification=20is=20not=20specific=20to=20fmc.=20Who= =20said=20so?
The=20reason=20we=20have=20been=20having=20this=20use=20case=20was=20beca= use=20the=20request
for=20IETF=20to=20be=20involved=20in=20fmc=20work=20has=20first=20been=20= made=20during
November=202011=203GPP-BBF=20FMC=20Workshop,=20Sophie=20would=20remember=20= it=20very
well,=20in=20the=20context=20of=20UE=20Identification=20use=20case=20whic= h=20is=20in=20fact=20a
well=20known=20problem=20with=20NATs=20and=20address=20sharing.

Can=20I=20ask=20you=20how=20do=20you=20evaluate=20the=20chances=20of=20In= tarea=20WG=20taking=20up
this=20issue?=20I=20have=20seen=20the=20reviews=20of=20your=20NAT=20Revea= l=20draft.=20I=20think
that=20Intarea=20people=20are=20very=20reluctant=20to=20work=20on=20this=20= old=20problem
related=20to=20mainly=20IPv4.=20I=20wish=20you=20good=20luck=20in=20this,= =20maybe=20you=20can
turn=20things=20around.

fmc=20is=20a=20set=20of=20issues=20arising=20from=203GPP=20UEs=20accessin= g=20a=20fixed
network.=203GPP=20and=20BBF=20will=20be=20busy=20developing=20standards=20= for=20fmc=20at
least=20next=20one=20if=20not=20two=20years.=20Afterwards,=20some=20next=20= generation
activity=20might=20be=20started,=20who=20knows?=20So=20fmc=20is=20here=20= to=20stay.

I=20have=20been=20reading=20your=20mails=20and=20drafts=20recently=20and=20= noticed=20that
you=20mentioned=20almost=20in=20every=20mail=20or=20two,=20some=20issues=20= related=20to=20fmc
and=20also=20I=20have=20been=20seeing=20references=20to=20fmc=20in=20your= =20drafts.

So=20it=20is=20fair=20to=20say=20that=20fmc=20has=20made=20you=20more=20p= roductive=20in=20IETF.
Correct=20me=20if=20I=20am=20wrong,=20shouldn't=20you=20give=20some=20cre= dit=20to=20Dirk=20and=20I
for=20carrying=20the=20fmc=20flag=20in=20IETF=20and=20giving=20some=20ins= piration=20to=20the
researchers?

Coming=20back=20to=20the=20UE=20identification=20use=20case,=20I=20am=20c= onvinced=20more=20and
more=20that=20we=20made=20a=20mistake=20in=20presenting=20UE=20Identifica= tion=20as=20the
signature=20use=20case=20for=20fmc.=20In=20fact=20we=20can=20easily=20dro= p=20this=20use=20case
and=20we=20will=20and=20can=20still=20have=20a=20lot=20to=20discuss=20on=20= fmc=20in=20IETF.=20We
will=20still=20keep=20our=20FT=20colleagues=20as=20co-authors=20if=20they= =20wish=20so=20but=20we
will=20give=20them=20a=20chance=20to=20drop=20out.

As=20you=20know,=20fmc=20BoF=20is=20scheduled=20already=20and=20we=20have= =20no=20possibility
of=20removing=20it=20from=20the=20agenda.

Lastly,=20in=20our=20drafts=20any=20time=20we=20mention=20UE=20Identifica= tion,=20we=20put=20a
reference=20to=20your=20drafts.=20We=20have=20created=20a=20lot=20of=20ad= vertisement,=20PR
for=20you.=20Is=20it=20fair=20to=20say=20that=20this=20effort=20went=20un= noticed?=20Why=20should
we=20continue=20to=20do=20so=20if=20there=20is=20no=20appreciation=20from= =20your=20side?=20And
we=20won't.

Regards,

Behcet

On=20Tue,=20Oct=2016,=202012=20at=202:04=20AM,=20 <mohamed.boucad= air@orange.com> wrote:
>=20Hi=20Behcet,=20Dirk,=20all,
>
>=20I=20still=20think=20it=20is=20too=20early=20to=20ask=20for=20a=20B= oF=20for=20this=20work;=20mainly for=20the=20same=20reasons=20I=20listed=20here:
>=20http://www.ietf.org/mail-arch= ive/web/fmc/current/msg00088.html >
>=20My=20colleagues=20and=20myself,=20contributed=20with=20technical=20= input=20to=20be=20challenged by=20this=20list.=20These=20inputs=20were=20recorded=20in=20<= a=20href=3D"http://tools.ietf.org/html/draft-schott-fmc-requirements-03">= http://tools.ietf.org/html/draft-schott-fmc-requirem= ents-03. As=20clearly=20indicated=20in=20that=20document,=20it=20is=20not=20voicin= g=20for=20creating=20a WG=20but=20its=20purpose=20is=20to=20be=20a=20place=20to=20analyze=20poin= ts=20which=20are=20claimed to=20be=20issues.
>
>=20After=20internal=20discussion=20with=20Sophie,=20David,=20Fred=20a= nd=20Pierrick,=20we concluded=20the=20main=20concern=20is=20the=20UE=20identification.=20Neve= rtheless,=20this issue=20is=20not=20specific=20to=20what=20is=20called=20here=20"fmc&= quot;=20but=20it=20is encountered=20in=20various=20use=20cases.=20For=20this=20reason,=20we=20e= dited=20this=20document:
>=20 http:/= /www.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-00.txt= .
>
>=20We=20hope=20that=20document=20helped=20to=20provide=20a=20big=20pi= cture=20view=20of=20the UE=20Identification=20issue.
>
>=20Cheers,
>=20Med
>
>>-----Message=20d'origine-----
>>De=20:=20fmc-bounces@ietf.org=20[mailto:fmc-bounces@ietf.org] De=20la
>>part=20de=20Behcet=20Sarikaya
>>Envoy=E9=20:=20vendredi=205=20octobre=202012=2000:29
>>=C0=20:=20fmc@ietf.org
>>Objet=20:=20[fmc]=20BoF=20session=20in=20Atlanta
>>
>>Hello=20folks,
>>
>>FMC=20BoF=20has=20been=20scheduled=20for:
>>
>>Tuesday=201700-1830=20 =20 =20 Afternoon=20Session= =20III=20in Salon=20E
>>
>>Regards,
>>
>>Dirk=20&=20Behcet
>>_______________________________________________
>>fmc=20mailing=20list
>>fmc@ietf.org
>>https://www.ietf.org/mailman/listinfo/fmc
>>
_______________________________________________
fmc=20mailing=20list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 


--------------------------------------------------------
ZTE=20Information=20Security=20Notice:=20The=20information=20contained=20=
in=20this=20mail=20(and=20any=20attachment=20transmitted=20herewith)=20is=
=20privileged=20and=20confidential=20and=20is=20intended=20for=20the=20ex=
clusive=20use=20of=20the=20addressee(s).=20=20If=20you=20are=20not=20an=20=
intended=20recipient,=20any=20disclosure,=20reproduction,=20distribution=20=
or=20other=20dissemination=20or=20use=20of=20the=20information=20containe=
d=20is=20strictly=20prohibited.=20=20If=20you=20have=20received=20this=20=
mail=20in=20error,=20please=20delete=20it=20and=20notify=20us=20immediate=
ly.

--=_alternative 00207E6188257A9A_=-- From mohamed.boucadair@orange.com Wed Oct 17 05:30:20 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 AD93621F87A2 for ; Wed, 17 Oct 2012 05:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, 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 68g98F0bZDs3 for ; Wed, 17 Oct 2012 05:30:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DB5C621F8793 for ; Wed, 17 Oct 2012 05:30:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6F59518C087; Wed, 17 Oct 2012 14:30:17 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 415E527C071; Wed, 17 Oct 2012 14:30:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 17 Oct 2012 14:30:14 +0200 From: To: "fmc@ietf.org" Date: Wed, 17 Oct 2012 14:30:14 +0200 Thread-Topic: [fmc] Issue #1: Identification (was RE: List description) Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcAABskeACT8spZQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E64431A92@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2888CEE5@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.17.95425 Cc: KLAMM Frederic OLNC/OLN , DUREL Sophie OLNC/OLN , BINET David OLNC/OLN , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) 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, 17 Oct 2012 12:30:20 -0000 Dear all, As a follow up to this discussion thread and in order to help better unders= tand the host identification issue, we edited an I-D discussing various use= cases in which host identification is needed. This document does not discu= ss any solution. The document is available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-01 The document provides a big picture view of scenarios suffering from this t= echnical issue.=20 Contribution, comments and suggestions are more than welcome. Cheers, Med >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de mohamed.boucadair@orange.com >Envoy=E9 : jeudi 12 avril 2012 08:02 >=C0 : Xueli; Donald Eastlake; David Allan I >Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org >Objet : [fmc] Issue #1: Identification (was RE: List description) > >Dear Xue, > [SNIP] > >I'm also interested to hear from you about other scenarios=20 >which may require "explicit" HOST_ID. Would it be possible to=20 >provide answers to the questions I asked below? Thanks.=20 > >Cheers, >Med > >>-----Message d'origine----- >>De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >>part de Xueli >>Envoy=E9 : jeudi 12 avril 2012 04:54 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Donald Eastlake; David Allan I >>Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org >>Objet : Re: [fmc] List description >> >>Hi Med, >> >>Thanks a lot for your detailed information.=20 >>You raised a very good point of the work. Then I would like to=20 >>add few questions here. >> >>Why do you think that the port set solution is more=20 >>appropriate for FMC case? And do you mind to explain which=20 >>definition of FMC case you mentioned here? >>Port set solution may be one choice. But the huge=20 >>configuration works on RGs could not be avoided, additionally,=20 >>the RGs are the subscriber side, which even make=20 >>the configuration work more difficult.=20 >> >>BR >>Li >> >>> -----Original Message----- >>> From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On=20 >Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Wednesday, April 11, 2012 2:07 PM >>> To: Donald Eastlake; David Allan I >>> Cc: Dean cheng; sarikaya@ieee.org; fmc@ietf.org >>> Subject: Re: [fmc] List description >>>=20 >>> Dear all, >>>=20 >>> There is no recommended solution for the FMC case, because=20 >>there are not >>> clear requirements for that case. >>> I have suggested to Behcet to further elaborate on the=20 >>requirements from an >>> "FMC" standpoint. Below an excerpt of what I sent to Behcet: >>>=20 >>> * The current HOST_ID effort in INTAREA WG is restricted to=20 >>the analysis of >>> potential channels which may convey the HOST_ID information >>> * A recommendation is likely to be added.but in the context=20 >>of address sharing >>> (RFC6269) >>> * FMC proponents should elaborate further their requirements for the >>> HOST_ID >>> (1) Required only during session initialization? >>> (2) Required for all transport protocols? >>> (3) Host modification should be avoided or it does not harm? >>> (4) Which entity will use the HOST_ID information: proxy=20 >>servers, else? >>> (4a) Packet inspection is required? No? >>> (4b) Performance impact >>> (5) Which entity will set the HOST_ID information? >>>=20 >>> BTW, I discussed this point with some colleagues and it=20 >>seems using port sets >>> would be more appropriate for the FMC case (i.e., >>>=20 >>http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys >>is-01#section-3.3) >>> . >>>=20 >>> If port sets are used, a dedicated notification channel is=20 >>needed to report >>> assigned port sets. FYI, I'm working with Dean on this point. >>>=20 >>> Cheers, >>> Med >>>=20 >>> >-----Message d'origine----- >>> >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>> >part de Donald Eastlake >>> >Envoy=E9 : mercredi 11 avril 2012 00:55 >>> >=C0 : David Allan I >>> >Cc : sarikaya@ieee.org; fmc@ietf.org >>> >Objet : Re: [fmc] List description >>> > >>> >I think that the nat-reveal draft, while it discusses 8 different >>> >possible solutions, does not actually propose any specific solution >>> >for any specific problem, such as the FMC/NAT problem. >>> > >>> >Thanks, >>> >Donald >>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >>> >=A0155 Beaver Street,=A0Milford, MA 01757 USA >>> >=A0d3e3e3@gmail.com >>> > >>> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I >>> > wrote: >>> >> Thanks Donald. >>> >> >>> >> So it is being addressed elsewhere. It is NOT the focus of >>> >this effort... >>> >> >>> >> Given that clarification, this discussion is going circular. >>> >We now revert to "what IETF FMC work are we discussing?" >>> >> >>> >> Dave >>> >> >>> >> -----Original Message----- >>> >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >>> >> Sent: Tuesday, April 10, 2012 2:07 PM >>> >> To: David Allan I >>> >> Cc: sarikaya@ieee.org; fmc@ietf.org >>> >> Subject: Re: [fmc] List description >>> >> >>> >> I think this is the draft: >>> >> >>> >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- >>> >analysis/ >>> >> That is an INTAREA WG draft. >>> >> >>> >> Thanks, >>> >> Donald >>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>> >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >>> >> =A0155 Beaver Street,=A0Milford, MA 01757 USA >>> >> =A0d3e3e3@gmail.com >>> >> >>> >> >>> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I >>> > wrote: >>> >>> Hi Bechet: >>> >>> >>> >>> You did not provide a useful answer. You simply pointed out >>> >to me things I've said (repeatedly). >>> >>> >>> >>> I asked: >>> >>> 1) Where was the draft you referred to? >>> >>> 2) What WG is working on it? >>> >>> 3) Is it the topic of the effort represented by this list? >>> >>> >>> >>> Can you please clarify... >>> >>> >>> >>> Thanks >>> >>> Dave >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> >>> Sent: Tuesday, April 10, 2012 1:29 PM >>> >>> To: David Allan I >>> >>> Cc: fmc@ietf.org >>> >>> Subject: Re: [fmc] List description >>> >>> >>> >>> Hi Dave, >>> >>> >>> >>> In November 2011, 3GPP-BBF Workshop >>> >>> chaired by >>> >>> >>> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) >>> >>> >>> >>> issued Chairmen's Summary slides at: >>> >>> >>> >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1 >>> 104 >>> >>> 6.zip >>> >>> >>> >>> which stated on Slide 4 >>> >>> >>> >>> In case of RG with NATs additional mechanisms are needed to >>> >enable this. Jointly encourage IETF work on such mechanisms. >>> >>> >>> >>> That's all I have to say. >>> >>> >>> >>> I think we should concentrate on IETF work on FMC >>> >discussions on this list. >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Behcet >>> >>> >>> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I >>> > wrote: >>> >>>> Hi Bechet: >>> >>>> >>> >>>>> Thanks for your mail. >>> >>>> >>> >>>>> Two points. >>> >>>> >>> >>>>> Point 1. Can you please clarify that you have expressed >>> >your personal opinion not wearing any hats? >>> >>>> >>> >>>> Does it matter? >>> >>>> >>> >>>> Point 2. On: >>> >>>> >>> >>>>>>The outstanding headwound is a wifi connected UE behind a >>> >NAT, and I >>> >>>>>>believe that is already being addressed elsewhere in the IETF. >>> >>>> >>> >>>>> Yes, there is a draft called NAT Reveal Analysis draft. >>> >It analyzes the problem and suggests very many solutions (5-6) >>> >and there are even solutions not mentioned in NAT Reveal >>> >Analysis draft. >>> >>>> >>> >>>> A pointer to the draft would be useful. And the WG context >>> >it is being entertained in.... >>> >>>> >>> >>>>> So it is a difficult problem and maybe explains why so >>> >many people are subscribed to this list. >>> >>>> >>> >>>> So is solving the NAT problem the purpose of this >>> >endeavour? I did not get that. >>> >>>> >>> >>>> >>> >>>> Cheers >>> >>>> Dave >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 >>> >_______________________________________________ >>> >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 >>_______________________________________________ >>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 >= From Dirk.von-Hugo@telekom.de Wed Oct 17 08:04: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 18FA121F8499 for ; Wed, 17 Oct 2012 08:04:38 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0lzYyaxZu-YG for ; Wed, 17 Oct 2012 08:04:36 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 00F7621F8475 for ; Wed, 17 Oct 2012 08:04:35 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 17 Oct 2012 17:04:33 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 17 Oct 2012 17:04:33 +0200 From: To: , Date: Wed, 17 Oct 2012 17:04:32 +0200 Thread-Topic: [fmc] BoF session in Atlanta Thread-Index: Ac2sK/+e4utMv59VR2CJft2n64AXrQASgwBA Message-ID: <05C81A773E48DD49B181B04BA21A342A27CCD7D8E4@HE113484.emea1.cds.t-internal.com> References: <94C682931C08B048B7A8645303FDC9F36E63206B3D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A27CCD7D8E4HE113484emea1_" MIME-Version: 1.0 Cc: sophie.durel@orange.com, fmc@ietf.org, david.binet@orange.com, christian.jacquenet@orange.com, frederic.klamm@orange.com, pierrick.seite@orange.com, mohamed.boucadair@orange.com Subject: Re: [fmc] BoF session in Atlanta 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, 17 Oct 2012 15:04:38 -0000 --_000_05C81A773E48DD49B181B04BA21A342A27CCD7D8E4HE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, of course we could ask BBF and/or 3GPP for liaison statement (via AD since = we are no WG ;-)) but referring to http://www.ietf.org/liaison/ "... liaiso= n relationships are kept as informal as possible ... " so I would have said that the quote from Nov. 2011 3GPP-BBF Workshop the re= port and summary slides available at http://www.3gpp.org/ftp/workshop/2011-11-09= _3GPP_BBF_SFO/Docs/ stating among others following actions for 3GPP and BBF= : "Encourage IETF work on mechanisms to enable identifying individual UEs beh= ind NAT/RGs." could work as basis for such a liaison. Comments? Just my 2 cents ... Thanks! Best regards Dirk ________________________________ Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von tso@= zteusa.com Gesendet: Mittwoch, 17. Oktober 2012 07:55 An: sarikaya@ieee.org Cc: DUREL Sophie OLNC/OLN; fmc@ietf.org; BINET David OLNC/OLN; JACQUENET Ch= ristian OLNC/OLN; KLAMM Frederic OLNC/OLN; SEITE Pierrick OLNC/OLN; von Hug= o, Dirk; mohamed.boucadair@orange.com Betreff: Re: [fmc] BoF session in Atlanta Dear Behcet, Sorry for jumping in late to tap on this subject and I could not find time = to pay enough attention on this FMC initiatives. After reading your responses to Med even raised more concern and doubt on m= y part: - referring to IETF FMC initiative to resolve 3GPP and BBF issues for 3GPP = UE to access fixed network If this is what you believe, may I ask, once again, where are the requireme= nts from 3GPP and BBF? Could you please identify if there any liaison comi= ng from 3GPP and/or from BBF to ask for such initiative in IETF? I sincerely believe that this would be very helpful for "all" of us to unde= rstand the justification for your belief that this FMC "specific" work item= is needed in IETF. What do you think? Thanks.. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 10/16/2012 08:51 PM Please respond to sarikaya@ieee.org To mohamed.boucadair@orange.com cc DUREL Sophie OLNC/OLN , "fmc@ietf.org" , BINET David OLNC/OLN , JACQUENET Christian OLN= C/OLN , KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , "Dir= k.von-Hugo@telekom.de" Subject Re: [fmc] BoF session in Atlanta Hi Med, all, Thanks for your mail. Yes, I read your new draft, draft-boucadair-intarea-host-identifier-scenarios-00.txt, of course we know that UE identification is not specific to fmc. Who said so? The reason we have been having this use case was because the request for IETF to be involved in fmc work has first been made during November 2011 3GPP-BBF FMC Workshop, Sophie would remember it very well, in the context of UE Identification use case which is in fact a well known problem with NATs and address sharing. Can I ask you how do you evaluate the chances of Intarea WG taking up this issue? I have seen the reviews of your NAT Reveal draft. I think that Intarea people are very reluctant to work on this old problem related to mainly IPv4. I wish you good luck in this, maybe you can turn things around. fmc is a set of issues arising from 3GPP UEs accessing a fixed network. 3GPP and BBF will be busy developing standards for fmc at least next one if not two years. Afterwards, some next generation activity might be started, who knows? So fmc is here to stay. I have been reading your mails and drafts recently and noticed that you mentioned almost in every mail or two, some issues related to fmc and also I have been seeing references to fmc in your drafts. So it is fair to say that fmc has made you more productive in IETF. Correct me if I am wrong, shouldn't you give some credit to Dirk and I for carrying the fmc flag in IETF and giving some inspiration to the researchers? Coming back to the UE identification use case, I am convinced more and more that we made a mistake in presenting UE Identification as the signature use case for fmc. In fact we can easily drop this use case and we will and can still have a lot to discuss on fmc in IETF. We will still keep our FT colleagues as co-authors if they wish so but we will give them a chance to drop out. As you know, fmc BoF is scheduled already and we have no possibility of removing it from the agenda. Lastly, in our drafts any time we mention UE Identification, we put a reference to your drafts. We have created a lot of advertisement, PR for you. Is it fair to say that this effort went unnoticed? Why should we continue to do so if there is no appreciation from your side? And we won't. Regards, Behcet On Tue, Oct 16, 2012 at 2:04 AM, wrote: > Hi Behcet, Dirk, all, > > I still think it is too early to ask for a BoF for this work; mainly for = the same reasons I listed here: > http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html > > My colleagues and myself, contributed with technical input to be challeng= ed by this list. These inputs were recorded in http://tools.ietf.org/html/d= raft-schott-fmc-requirements-03. As clearly indicated in that document, it = is not voicing for creating a WG but its purpose is to be a place to analyz= e points which are claimed to be issues. > > After internal discussion with Sophie, David, Fred and Pierrick, we concl= uded the main concern is the UE identification. Nevertheless, this issue is= not specific to what is called here "fmc" but it is encountered in various= use cases. For this reason, we edited this document: > http://www.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios= -00.txt. > > We hope that document helped to provide a big picture view of the UE Iden= tification issue. > > Cheers, > Med > >>-----Message d'origine----- >>De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>part de Behcet Sarikaya >>Envoy=E9 : vendredi 5 octobre 2012 00:29 >>=C0 : fmc@ietf.org >>Objet : [fmc] BoF session in Atlanta >> >>Hello folks, >> >>FMC BoF has been scheduled for: >> >>Tuesday 1700-1830 Afternoon Session III in Salon E >> >>Regards, >> >>Dirk & Behcet >>_______________________________________________ >>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 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (an= d any attachment transmitted herewith) is privileged and confidential and i= s intended for the exclusive use of the addressee(s). If you are not an in= tended recipient, any disclosure, reproduction, distribution or other disse= mination or use of the information contained is strictly prohibited. If yo= u have received this mail in error, please delete it and notify us immediat= ely. --_000_05C81A773E48DD49B181B04BA21A342A27CCD7D8E4HE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
of course we could ask BBF and/or 3GPP for liaison st= atement=20 (via AD since we are no WG ;-)) but referring to http://www.ietf.org/liaison/ "... liaison relati= onships are=20 kept as informal as possible ... "
so I=20 would have said that the quote from Nov. 2011 3GPP-BBF = Workshop the report and summary slides available at=20 htt= p://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/=20 stating = ;among=20 others following actions for 3GPP and BBF:
"Encourage IETF work on mechanisms to en= able=20 identifying individual UEs behind NAT/RGs."

could=20 work as basis for such a liaison.

Comments? 

Just my=20 2 cents ...

Thanks!

Best regards
Dirk


Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 tso@zteusa.com
Gesendet: Mittwoch, 17. Oktober 2012=20 07:55
An: sarikaya@ieee.org
Cc: DUREL Sophie OLNC/OLN;= =20 fmc@ietf.org; BINET David OLNC/OLN; JACQUENET Christian OLNC/OLN; KLAMM Fre= deric=20 OLNC/OLN; SEITE Pierrick OLNC/OLN; von Hugo, Dirk;=20 mohamed.boucadair@orange.com
Betreff: Re: [fmc] BoF session in=20 Atlanta

Dear Behcet,

Sorry for jumping in late to tap on this subject and I co= uld not=20 find time to pay enough attention on this FMC initiatives.  =20

After reading your responses to Me= d even=20 raised more concern and doubt on my part:
- referring to IETF FMC initiative to resolve 3GPP and BB= F=20 issues for 3GPP UE to access fixed network

If this is what you believe, may I ask, once again, where= are=20 the requirements from 3GPP and BBF?  Could you please identify if ther= e any=20 liaison coming from 3GPP and/or from BBF to ask for such initiative in IETF= ?=20  

I sincerely believe = that this=20 would be very helpful for "all" of us to understand the justification for y= our=20 belief that this FMC "specific" work item is needed in IETF.   What do= you=20 think?

Thanks..
= Tricci



Behcet Sarikaya=20 <sarikaya2012@gmail.com>
Sent by: fmc-bounces@ietf.org=20

10/16/2012 08:51 PM=20
Please res= pond=20 to
sarikaya@ieee.org
To
mohamed.boucadair@orange.com= =20
cc
DUREL Sophie OLNC/OLN=20 <sophie.durel@orange.com>, "fmc@ietf.org"=20 <fmc@ietf.org>, BINET David OLNC/OLN=20 <david.binet@orange.com>, JACQUENET Christian OLNC/OLN=20 <christian.jacquenet@orange.com>, KLAMM Frederic OLNC/OLN= =20 <frederic.klamm@orange.com>, SEITE Pierrick OLNC/OLN=20 <pierrick.seite@orange.com>, "Dirk.von-Hugo@telekom.de"=20 <Dirk.von-Hugo@telekom.de>=20
Subject
Re: [fmc] BoF session in=20 Atlanta





Hi Med, all,
Thanks for your mail.
Yes, I read your new=20 draft,
draft-boucadair-intarea-host-identifier-scenarios-00.txt, of cour= se=20 we
know that UE identification is not specific to fmc. Who said so?
T= he=20 reason we have been having this use case was because the request
for IET= F to=20 be involved in fmc work has first been made during
November 2011 3GPP-BB= F FMC=20 Workshop, Sophie would remember it very
well, in the context of UE=20 Identification use case which is in fact a
well known problem with NATs = and=20 address sharing.

Can I ask you how do you evaluate the chances of In= tarea=20 WG taking up
this issue? I have seen the reviews of your NAT Reveal draf= t. I=20 think
that Intarea people are very reluctant to work on this old=20 problem
related to mainly IPv4. I wish you good luck in this, maybe you= =20 can
turn things around.

fmc is a set of issues arising from 3GPP = UEs=20 accessing a fixed
network. 3GPP and BBF will be busy developing standard= s for=20 fmc at
least next one if not two years. Afterwards, some next=20 generation
activity might be started, who knows? So fmc is here to=20 stay.

I have been reading your mails and drafts recently and noticed= =20 that
you mentioned almost in every mail or two, some issues related to=20 fmc
and also I have been seeing references to fmc in your drafts.
So=20 it is fair to say that fmc has made you more productive in IETF.
Correct= me=20 if I am wrong, shouldn't you give some credit to Dirk and I
for carrying= the=20 fmc flag in IETF and giving some inspiration to=20 the
researchers?

Coming back to the UE identification use case, I= am=20 convinced more and
more that we made a mistake in presenting UE=20 Identification as the
signature use case for fmc. In fact we can easily = drop=20 this use case
and we will and can still have a lot to discuss on fmc in = IETF.=20 We
will still keep our FT colleagues as co-authors if they wish so but=20 we
will give them a chance to drop out.

As you know, fmc BoF is=20 scheduled already and we have no possibility
of removing it from the=20 agenda.

Lastly, in our drafts any time we mention UE Identification,= we=20 put a
reference to your drafts. We have created a lot of advertisement,= =20 PR
for you. Is it fair to say that this effort went unnoticed? Why=20 should
we continue to do so if there is no appreciation from your side?= =20 And
we won't.

Regards,

Behcet

On Tue, Oct 16, 2012 = at=20 2:04 AM,  <mohamed.boucadair@orange.com> wrote:
> Hi Behce= t,=20 Dirk, all,
>
> I still think it is too early to ask for a BoF f= or=20 this work; mainly for the same reasons I listed here:
> <= A=20 href=3D"http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html">http://www.ietf.org/mail-archive/web/fmc/current/msg00088.html
>
> My colleagues and myself, contributed with techni= cal=20 input to be challenged by this list. These inputs were recorded in=20 http://tools.ietf.org/html/draft-schott-fmc-requirements-03= . As clearly indicated in that document, it is not voicing for cre= ating a=20 WG but its purpose is to be a place to analyze points which are claimed to = be=20 issues.
>
> After internal discussion with Sophie, David, Fred = and=20 Pierrick, we concluded the main concern is the UE identification. Neverthel= ess,=20 this issue is not specific to what is called here "fmc" but it is encounter= ed in=20 various use cases. For this reason, we edited this document:
>=20  http://www.ietf.org/id/draft-boucadair-intarea-host-identifier-sce= narios-00.txt.
>
> We hope that document helped to provide a big pi= cture=20 view of the UE Identification issue.
>
> Cheers,
>=20 Med
>
>>-----Message d'origine-----
>>De :=20 fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De= =20 la
>>part de Behcet Sarikaya
>>Envoy=E9 : vendredi 5 octo= bre=20 2012 00:29
>>=C0 : fmc@ietf.org
>>Objet : [fmc] BoF sessi= on in=20 Atlanta
>>
>>Hello folks,
>>
>>FMC BoF = has=20 been scheduled for:
>>
>>Tuesday 1700-1830    = =20  Afternoon Session III in Salon=20 E
>>
>>Regards,
>>
>>Dirk &=20 Behcet
>>_______________________________________________
>&g= t;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



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.

--_000_05C81A773E48DD49B181B04BA21A342A27CCD7D8E4HE113484emea1_-- From brian@innovationslab.net Thu Oct 18 12:14:20 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 ADF3F21F84FA for ; Thu, 18 Oct 2012 12:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0njDvPGzPeMM for ; Thu, 18 Oct 2012 12:14:20 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C40A21F8508 for ; Thu, 18 Oct 2012 12:14:20 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 12260880ED for ; Thu, 18 Oct 2012 12:14:18 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CD23014003A for ; Thu, 18 Oct 2012 12:14:17 -0700 (PDT) Message-ID: <50805508.7010800@innovationslab.net> Date: Thu, 18 Oct 2012 15:14:16 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [fmc] Upcoming BoF in Atlanta 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, 18 Oct 2012 19:14:20 -0000 All, It appears that there may be some confusion about the BoF scheduled for Atlanta. I want to make sure that everyone understands that the purpose of this BoF is not to form a WG at this time. The primary goal is to tighten the description of one or two key work items that could serve as the basis for a proposed WG. The original BoF proposal was too broad, covered too many areas within the IETF, and the interactions between the IETF and other SDOs were not well defined. I recommend that FMC proponents encourage their IETF colleagues to participate in the BoF so that a well-structured and coherent problem statement can be developed. Regards, Brian From tso@zteusa.com Thu Oct 18 12:53:06 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 1AD6621F84E9; Thu, 18 Oct 2012 12:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 FQ2YYZAE17Md; Thu, 18 Oct 2012 12:53:05 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BE34121F849C; Thu, 18 Oct 2012 12:53:04 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 6634D123C298; Fri, 19 Oct 2012 03:53:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9IJqv6J040366; Fri, 19 Oct 2012 03:52:57 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <50805508.7010800@innovationslab.net> References: <50805508.7010800@innovationslab.net> To: Brian Haberman MIME-Version: 1.0 X-KeepSent: 11DDC7CC:CE10DF93-88257A9B:006B3B8F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 18 Oct 2012 12:52:29 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-19 03:52:40, Serialize complete at 2012-10-19 03:52:40 Content-Type: multipart/alternative; boundary="=_alternative 006D36E688257A9B_=" X-MAIL: mse01.zte.com.cn q9IJqv6J040366 Cc: fmc-bounces@ietf.org, fmc@ietf.org Subject: Re: [fmc] Upcoming BoF in Atlanta 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, 18 Oct 2012 19:53:06 -0000 This is a multipart message in MIME format. --=_alternative 006D36E688257A9B_= Content-Type: text/plain; charset="US-ASCII" Dear Brian, Sincerely thanks for your kind clarification, and it is truly helpful for me. As myself is very actively participating in both 3GPP and BBF on the FMC related subject. One thing certainly would be very helpful to me is to understand if there is any specific requirement "directly" requested from either 3GPP or BBF or both to IETF on this specific work item because I hear the opponents for this FMC continuing advocate the need to solve the issue for 3GPP and BBF. By just referring to the presentation from other SDOs, IMHO, is kind of misleading, because we often submit technical draft to IETF to develop a solution without the need for introducing a new WG. Hence, I sincerely look for your guidance to understand better for what circumstance that a new WG is justifiable for this subject, especially when there is no direct request or LS from external SDO to request such FMC WG to address the issue, if there is any? Thanks in advance for your kind advice. Tricci Brian Haberman Sent by: fmc-bounces@ietf.org 10/18/2012 12:14 PM To fmc@ietf.org cc Subject [fmc] Upcoming BoF in Atlanta All, It appears that there may be some confusion about the BoF scheduled for Atlanta. I want to make sure that everyone understands that the purpose of this BoF is not to form a WG at this time. The primary goal is to tighten the description of one or two key work items that could serve as the basis for a proposed WG. The original BoF proposal was too broad, covered too many areas within the IETF, and the interactions between the IETF and other SDOs were not well defined. I recommend that FMC proponents encourage their IETF colleagues to participate in the BoF so that a well-structured and coherent problem statement can be developed. Regards, Brian _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 006D36E688257A9B_= Content-Type: text/html; charset="US-ASCII" Dear Brian,

Sincerely thanks for your kind clarification, and it is truly helpful for me.

As myself is very actively participating in both 3GPP and BBF on the FMC related subject.  One thing certainly would be very helpful to me is to understand if there is any specific requirement "directly" requested from either 3GPP or BBF or both to IETF on this specific work item because I hear the opponents for this FMC continuing advocate the need to solve the issue for 3GPP and BBF.  By just referring to the presentation from other SDOs, IMHO, is kind of misleading, because we often submit technical draft to IETF to develop a solution without the need for introducing a new WG.  

Hence, I sincerely look for your guidance to understand better for what circumstance that a new WG is justifiable for this subject, especially when there is no direct request or LS from external SDO to request such FMC WG to address the issue, if there is any?

Thanks in advance for your kind advice.  
Tricci




Brian Haberman <brian@innovationslab.net>
Sent by: fmc-bounces@ietf.org

10/18/2012 12:14 PM

To
fmc@ietf.org
cc
Subject
[fmc] Upcoming BoF in Atlanta





All,
     It appears that there may be some confusion about the BoF
scheduled for Atlanta.  I want to make sure that everyone understands
that the purpose of this BoF is not to form a WG at this time.  The
primary goal is to tighten the description of one or two key work items
that could serve as the basis for a proposed WG.  The original BoF
proposal was too broad, covered too many areas within the IETF, and the
interactions between the IETF and other SDOs were not well defined.

     I recommend that FMC proponents encourage their IETF colleagues to
participate in the BoF so that a well-structured and coherent problem
statement can be developed.

Regards,
Brian
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 006D36E688257A9B_=-- From brian@innovationslab.net Fri Oct 19 05:14:33 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 2391321F863F for ; Fri, 19 Oct 2012 05:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 39aOHY9GkaWq for ; Fri, 19 Oct 2012 05:14:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58521F859E for ; Fri, 19 Oct 2012 05:14:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 044518813E; Fri, 19 Oct 2012 05:14:30 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A1A6E14003A; Fri, 19 Oct 2012 05:14:29 -0700 (PDT) Message-ID: <50814424.9080408@innovationslab.net> Date: Fri, 19 Oct 2012 08:14:28 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: tso@zteusa.com References: <50805508.7010800@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fmc@ietf.org Subject: Re: [fmc] Upcoming BoF in Atlanta 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, 19 Oct 2012 12:14:33 -0000 Hi Tricci, On 10/18/12 3:52 PM, tso@zteusa.com wrote: > Dear Brian, > > Sincerely thanks for your kind clarification, and it is truly helpful for > me. > > As myself is very actively participating in both 3GPP and BBF on the FMC > related subject. One thing certainly would be very helpful to me is to > understand if there is any specific requirement "directly" requested from > either 3GPP or BBF or both to IETF on this specific work item because I > hear the opponents for this FMC continuing advocate the need to solve the > issue for 3GPP and BBF. By just referring to the presentation from other > SDOs, IMHO, is kind of misleading, because we often submit technical draft > to IETF to develop a solution without the need for introducing a new WG. There has not been a direct request, via a liaison statement, requesting the IETF to work on these issues. The justification has been with the presentation made during the 3GPP/BBF workshop. http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip > > Hence, I sincerely look for your guidance to understand better for what > circumstance that a new WG is justifiable for this subject, especially > when there is no direct request or LS from external SDO to request such > FMC WG to address the issue, if there is any? > At this point, I am trying to judge: 1) whether there is actual work to be done in this space, 2) how that potential work relates to the INT Area, 3) what constituency is going to do the work, and 4) who is the actual customer. To that end, I expect the proponents to be able to crisply define 1 or 2 key issues that can be the turned into the basis of a WG charter proposal. In addition, they should be able to clearly define how they will interact with other SDOs to ensure they are performing useful work. Regards, Brian From david.kessens@nsn.com Fri Oct 19 09:41:24 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 C1BF021F878E for ; Fri, 19 Oct 2012 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, 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 KT4z7Efu7PZ0 for ; Fri, 19 Oct 2012 09:41:24 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E8D1221F878B for ; Fri, 19 Oct 2012 09:41:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9JGfI6r015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 18:41:18 +0200 Received: from localhost.localdomain ([10.138.53.168]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9JGfBC7015380; Fri, 19 Oct 2012 18:41:16 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q9I3eRY0018904; Wed, 17 Oct 2012 20:40:27 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q9I3eMD7018902; Wed, 17 Oct 2012 20:40:22 -0700 Date: Wed, 17 Oct 2012 20:40:22 -0700 From: David Kessens To: sarikaya@ieee.org Message-ID: <20121018034022.GU19637@nsn.com> References: <94C682931C08B048B7A8645303FDC9F36E63206B3D@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 30 X-purgate-ID: 151667::1350664878-00006DFC-BF8AC1FD/2458857358-0/0-3 Cc: DUREL Sophie OLNC/OLN , "fmc@ietf.org" , BINET David OLNC/OLN , JACQUENET Christian OLNC/OLN , KLAMM Frederic OLNC/OLN , SEITE Pierrick OLNC/OLN , "Dirk.von-Hugo@telekom.de" , mohamed.boucadair@orange.com Subject: Re: [fmc] BoF session in Atlanta 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, 19 Oct 2012 16:41:24 -0000 <<< No Message Collected >>> From tso@zteusa.com Fri Oct 19 14:27: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 39FD321F8748 for ; Fri, 19 Oct 2012 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 NRO0i31lWl0P for ; Fri, 19 Oct 2012 14:27:16 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id ED63E21F8780 for ; Fri, 19 Oct 2012 14:27:11 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 82EA53D0693; Sat, 20 Oct 2012 05:27:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9JLQtrM074992; Sat, 20 Oct 2012 05:26:55 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <50814424.9080408@innovationslab.net> References: <50805508.7010800@innovationslab.net> <50814424.9080408@innovationslab.net> To: Brian Haberman MIME-Version: 1.0 X-KeepSent: 411D1343:A45C7BB4-88257A9C:00754020; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 19 Oct 2012 14:26:24 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-20 05:26:33, Serialize complete at 2012-10-20 05:26:33 Content-Type: multipart/alternative; boundary="=_alternative 0075D0B688257A9C_=" X-MAIL: mse01.zte.com.cn q9JLQtrM074992 Cc: fmc@ietf.org Subject: Re: [fmc] Upcoming BoF in Atlanta 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, 19 Oct 2012 21:27:17 -0000 This is a multipart message in MIME format. --=_alternative 0075D0B688257A9C_= Content-Type: text/plain; charset="US-ASCII" Dear Brian, Thank you for kind feedback to answer my question precisely, despite my bad English for mis-spelling "proponents" with "opponents". Your clarifications are truly great education to me to understand better of the IETF BOF process. Sincerely thanks. Tricci Brian Haberman 10/19/2012 05:14 AM To tso@zteusa.com cc fmc@ietf.org Subject Re: [fmc] Upcoming BoF in Atlanta Hi Tricci, On 10/18/12 3:52 PM, tso@zteusa.com wrote: > Dear Brian, > > Sincerely thanks for your kind clarification, and it is truly helpful for > me. > > As myself is very actively participating in both 3GPP and BBF on the FMC > related subject. One thing certainly would be very helpful to me is to > understand if there is any specific requirement "directly" requested from > either 3GPP or BBF or both to IETF on this specific work item because I > hear the opponents for this FMC continuing advocate the need to solve the > issue for 3GPP and BBF. By just referring to the presentation from other > SDOs, IMHO, is kind of misleading, because we often submit technical draft > to IETF to develop a solution without the need for introducing a new WG. There has not been a direct request, via a liaison statement, requesting the IETF to work on these issues. The justification has been with the presentation made during the 3GPP/BBF workshop. http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip > > Hence, I sincerely look for your guidance to understand better for what > circumstance that a new WG is justifiable for this subject, especially > when there is no direct request or LS from external SDO to request such > FMC WG to address the issue, if there is any? > At this point, I am trying to judge: 1) whether there is actual work to be done in this space, 2) how that potential work relates to the INT Area, 3) what constituency is going to do the work, and 4) who is the actual customer. To that end, I expect the proponents to be able to crisply define 1 or 2 key issues that can be the turned into the basis of a WG charter proposal. In addition, they should be able to clearly define how they will interact with other SDOs to ensure they are performing useful work. Regards, Brian -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0075D0B688257A9C_= Content-Type: text/html; charset="US-ASCII" Dear Brian,

Thank you for kind feedback to answer my question precisely, despite my bad English for mis-spelling "proponents" with "opponents".  

Your clarifications are truly great education to me to understand better of the IETF BOF process.  Sincerely thanks.
Tricci



Brian Haberman <brian@innovationslab.net>

10/19/2012 05:14 AM

To
tso@zteusa.com
cc
fmc@ietf.org
Subject
Re: [fmc] Upcoming BoF in Atlanta





Hi Tricci,

On 10/18/12 3:52 PM, tso@zteusa.com wrote:
> Dear Brian,
>
> Sincerely thanks for your kind clarification, and it is truly helpful for
> me.
>
> As myself is very actively participating in both 3GPP and BBF on the FMC
> related subject.  One thing certainly would be very helpful to me is to
> understand if there is any specific requirement "directly" requested from
> either 3GPP or BBF or both to IETF on this specific work item because I
> hear the opponents for this FMC continuing advocate the need to solve the
> issue for 3GPP and BBF.  By just referring to the presentation from other
> SDOs, IMHO, is kind of misleading, because we often submit technical draft
> to IETF to develop a solution without the need for introducing a new WG.

There has not been a direct request, via a liaison statement, requesting
the IETF to work on these issues.  The justification has been with the
presentation made during the 3GPP/BBF workshop.

http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip

>
> Hence, I sincerely look for your guidance to understand better for what
> circumstance that a new WG is justifiable for this subject, especially
> when there is no direct request or LS from external SDO to request such
> FMC WG to address the issue, if there is any?
>

At this point, I am trying to judge: 1) whether there is actual work to
be done in this space, 2) how that potential work relates to the INT
Area, 3) what constituency is going to do the work, and 4) who is the
actual customer.

To that end, I expect the proponents to be able to crisply define 1 or 2
key issues that can be the turned into the basis of a WG charter
proposal.  In addition, they should be able to clearly define how they
will interact with other SDOs to ensure they are performing useful work.

Regards,
Brian

 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0075D0B688257A9C_=-- From Dirk.von-Hugo@telekom.de Mon Oct 22 08:21:51 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 4036521F8C21 for ; Mon, 22 Oct 2012 08:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 l-FKJQtmDkZW for ; Mon, 22 Oct 2012 08:21:50 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id E2DAD21F8C1C for ; Mon, 22 Oct 2012 08:21:49 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 17:21:48 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 22 Oct 2012 17:21:47 +0200 From: To: Date: Mon, 22 Oct 2012 17:21:45 +0200 Thread-Topic: New Version Notification for draft-xue-fmc-ps-03.txt Thread-Index: Ac2wZ5MhiKJPKQ+TTT+4FrPoMRPT7QAAG9Fw Message-ID: <05C81A773E48DD49B181B04BA21A342A27CCDE9BBD@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sarikaya@ieee.org, xueli@huawei.com Subject: [fmc] WG: New Version Notification for draft-xue-fmc-ps-03.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: Mon, 22 Oct 2012 15:21:51 -0000 Dear all, For the FMC BoF in Atlanta we have submitted a new version for PS draft whe= re we have focussed on two use cases which should be specific for operators= use case to provide fixed mobile converged services via interworking of th= eir heterogeneous access networks. Group Id handling (for a subscriber owning multiple UE devices) and UE mobi= lity within fixed networks are described as potential FMC use cases. Please= don't hesitate to send your comments to the list! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Gesendet: Montag, 22. Oktober 2012 17:12 An: von Hugo, Dirk Cc: sarikaya@ieee.org; xueli@huawei.com Betreff: New Version Notification for draft-xue-fmc-ps-03.txt A new version of I-D, draft-xue-fmc-ps-03.txt has been successfully submitted by Dirk von Hugo and posted to the IETF repository. Filename: draft-xue-fmc-ps Revision: 03 Title: Problem Statement for Fixed Mobile Convergence Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-03.tx= t Status: http://datatracker.ietf.org/doc/draft-xue-fmc-ps Htmlized: http://tools.ietf.org/html/draft-xue-fmc-ps-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-xue-fmc-ps-03 Abstract: The purpose of this document is to analyze the issues that have arisen so far and to propose several use cases for the Fixed Mobile Convergence. This document gives a brief overview of the assumed Fixed Mobile Convergence architecture and related works and then introduces several Intarea type of use cases based on the partnership in Fixed Mobile Convergence architecture, such as group identification, mobility consideration, such as mobility status reporting in Wi-Fi network. The IETF Secretariat From Roland.Schott@telekom.de Mon Oct 22 12:20:35 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 2DD7811E8097 for ; Mon, 22 Oct 2012 12:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 HERXS39rRfAM for ; Mon, 22 Oct 2012 12:20:34 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 046E911E808D for ; Mon, 22 Oct 2012 12:20:33 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 22 Oct 2012 21:20:32 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 22 Oct 2012 21:20:32 +0200 From: To: Date: Mon, 22 Oct 2012 21:20:31 +0200 Thread-Topic: New Version Notification for draft-schott-fmc-requirements-04.txt Thread-Index: Ac2wiS8bJmbe3QwwRdaOdN7saDM6ygAAG8Lg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AC87AA27@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sophie.durel@orange.com, hassnaa.moustafa@intel.com Subject: [fmc] WG: New Version Notification for draft-schott-fmc-requirements-04.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: Mon, 22 Oct 2012 19:20:35 -0000 Dear all, I have posted a new version of draft-schott-fmc-requirements-04.txt. Regarding the BoF the idea was to reduce the requirements to a few use case= s. Depending on the feedback in Atlanta we are open to detail the use cases and add other requirements. Best Regards Roland A new version of I-D, draft-schott-fmc-requirements-04.txt has been successfully submitted by Roland Schott and posted to the IETF repository. Filename: draft-schott-fmc-requirements Revision: 04 Title: Requirements in Fixed Mobile Convergence Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-schott-fmc-requi= rements-04.txt Status: http://datatracker.ietf.org/doc/draft-schott-fmc-requireme= nts Htmlized: http://tools.ietf.org/html/draft-schott-fmc-requirements-0= 4 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schott-fmc-requir= ements-04 Abstract: This document provides provides technical requirements in Fixed Mobile Convergence for the two use cases of group identification and user equipment mobility in fixed network. The IETF Secretariat From mohamed.boucadair@orange.com Tue Oct 23 01:03:15 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 5A12B21F8692 for ; Tue, 23 Oct 2012 01:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.106, 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 YQLSTpKHr2nX for ; Tue, 23 Oct 2012 01:03:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0221F868F for ; Tue, 23 Oct 2012 01:03:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0B07C264248; Tue, 23 Oct 2012 10:03:13 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E168835C045; Tue, 23 Oct 2012 10:03:12 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 23 Oct 2012 10:03:12 +0200 From: To: "Dirk.von-Hugo@telekom.de" , "fmc@ietf.org" Date: Tue, 23 Oct 2012 10:03:11 +0200 Thread-Topic: New Version Notification for draft-xue-fmc-ps-03.txt Thread-Index: Ac2wZ5MhiKJPKQ+TTT+4FrPoMRPT7QAAG9FwAB+yXMA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E66AD86B5@PUEXCB1B.nanterre.francetelecom.fr> References: <05C81A773E48DD49B181B04BA21A342A27CCDE9BBD@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27CCDE9BBD@HE113484.emea1.cds.t-internal.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.10.23.61221 Cc: "sarikaya@ieee.org" , "xueli@huawei.com" Subject: Re: [fmc] New Version Notification for draft-xue-fmc-ps-03.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, 23 Oct 2012 08:03:15 -0000 Hi Dirk, I read the new version you submitted. I have some questions for clarificati= on: (1) You introduced two new identifiers: Group ID and Subscriber ID. What is= the difference between these two identifiers? (2) The document says: " There are many standardization issues related to FMC and protocol extension work needed. If these issues are fixed, the advantages brought out will be: 1. Optimize traffic management (per-UE granularity in the fixed broadband network)"=20 (2.1) Isn't this the purpose of "host identification"?=20 (2.2) Is this really possible if you introduce the concept of GroupID and n= ot "host identifier"? (3) The text says: "The subscriber ID must be contained in the traffic packet of the subscriber in order to achieve policy enforcement in the device node in the network." (3.1) Why a subscriber identifier is needed to be leaked into IP packets? (3.2) Who is responsible for injecting this information in IP packets? (3.3) How a device will discover/learn/"be provisioned" with this informati= on? (3.4) How to trust this information? Is the device injecting this informati= on a trusted device? (3.5) Solution examples you listed are bound to IP, do you have in mind exa= mples which would not be similar to a "host identifier"? (4) Several parts of the GorupID text are close to the host identification = issue. Could you please explain the difference? (5) The text does not summarize the technical issues; for instance:=20 (5.1) What are the technical issues in Section 4? (5.2) Why these issues are specific to FMC?=20 (5.3) Is inter-operator policy exchange in scope? (5.4) Why existing IETF tools do not solve encountered issues? Thanks. Cheers, Med =20 >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de Dirk.von-Hugo@telekom.de >Envoy=E9 : lundi 22 octobre 2012 17:22 >=C0 : fmc@ietf.org >Cc : sarikaya@ieee.org; xueli@huawei.com >Objet : [fmc] WG: New Version Notification for draft-xue-fmc-ps-03.txt > > >Dear all, >For the FMC BoF in Atlanta we have submitted a new version for=20 >PS draft where we have focussed on two use cases which should=20 >be specific for operators use case to provide fixed mobile=20 >converged services via interworking of their heterogeneous=20 >access networks. >Group Id handling (for a subscriber owning multiple UE=20 >devices) and UE mobility within fixed networks are described=20 >as potential FMC use cases. Please don't hesitate to send your=20 >comments to the list! > >Best regards >Dirk > >-----Urspr=FCngliche Nachricht----- >Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Gesendet: Montag, 22. Oktober 2012 17:12 >An: von Hugo, Dirk >Cc: sarikaya@ieee.org; xueli@huawei.com >Betreff: New Version Notification for draft-xue-fmc-ps-03.txt > > >A new version of I-D, draft-xue-fmc-ps-03.txt >has been successfully submitted by Dirk von Hugo and posted to the >IETF repository. > >Filename: draft-xue-fmc-ps >Revision: 03 >Title: Problem Statement for Fixed Mobile Convergence >Creation date: 2012-10-22 >WG ID: Individual Submission >Number of pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-03.txt >Status: http://datatracker.ietf.org/doc/draft-xue-fmc-ps >Htmlized: http://tools.ietf.org/html/draft-xue-fmc-ps-03 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-xue-fmc-ps-03 > >Abstract: > The purpose of this document is to analyze the issues that have > arisen so far and to propose several use cases for the Fixed Mobile > Convergence. This document gives a brief overview of the assumed > Fixed Mobile Convergence architecture and related works and then > introduces several Intarea type of use cases based on the=20 >partnership > in Fixed Mobile Convergence architecture, such as group > identification, mobility consideration, such as mobility status > reporting in Wi-Fi network. > > > > >The IETF Secretariat > >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc >= From sophie.durel@orange.com Tue Oct 23 01:41:15 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 3A9AD21F86C1 for ; Tue, 23 Oct 2012 01:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.226, 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 DfAiiOrNzxT8 for ; Tue, 23 Oct 2012 01:41:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1D21F86B5 for ; Tue, 23 Oct 2012 01:41:14 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 71E5D2DC367; Tue, 23 Oct 2012 10:41:13 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4EDD04C024; Tue, 23 Oct 2012 10:41:13 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 23 Oct 2012 10:41:13 +0200 From: To: "Roland.Schott@telekom.de" , "fmc@ietf.org" Date: Tue, 23 Oct 2012 10:41:12 +0200 Thread-Topic: New Version Notification for draft-schott-fmc-requirements-04.txt Thread-Index: Ac2wiS8bJmbe3QwwRdaOdN7saDM6ygAAG8LgABv+MXA= Message-ID: <24685_1350981673_50865829_24685_1347_3_769F0CFAE7A1B44A84DD4376649D4A3127C31949B2@PUEXCB1C.nanterre.francetelecom.fr> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AC87AA27@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AC87AA27@HE111648.emea1.cds.t-internal.com> Accept-Language: fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" 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.6.19.115414 Cc: "hassnaa.moustafa@intel.com" Subject: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-04.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, 23 Oct 2012 08:41:15 -0000 Dear all, I have not participated to the rewording of this new draft. It is not relev= ant to keep my name in the list of the authors. Best regards Sophie -----Original Message----- From: Roland.Schott@telekom.de [mailto:Roland.Schott@telekom.de]=20 Sent: lundi 22 octobre 2012 21:21 To: fmc@ietf.org Cc: hassnaa.moustafa@intel.com; DUREL Sophie OLNC/OLN Subject: WG: New Version Notification for draft-schott-fmc-requirements-04.= txt Dear all, I have posted a new version of draft-schott-fmc-requirements-04.txt. Regarding the BoF the idea was to reduce the requirements to a few use case= s. Depending on the feedback in Atlanta we are open to detail the use cases and add other requirements. Best Regards Roland A new version of I-D, draft-schott-fmc-requirements-04.txt has been successfully submitted by Roland Schott and posted to the IETF repository. Filename: draft-schott-fmc-requirements Revision: 04 Title: Requirements in Fixed Mobile Convergence Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-schott-fmc-requi= rements-04.txt Status: http://datatracker.ietf.org/doc/draft-schott-fmc-requireme= nts Htmlized: http://tools.ietf.org/html/draft-schott-fmc-requirements-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schott-fmc-requir= ements-04 Abstract: This document provides provides technical requirements in Fixed Mobile Convergence for the two use cases of group identification and user equipment mobility in fixed network. The IETF Secretariat ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bingxuere@gmail.com Tue Oct 23 02:34:09 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 213A121F85C8 for ; Tue, 23 Oct 2012 02:34:09 -0700 (PDT) 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 HWovK6skuGYU for ; Tue, 23 Oct 2012 02:34:08 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 786AF21F85AC for ; Tue, 23 Oct 2012 02:34:08 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so5837073iec.31 for ; Tue, 23 Oct 2012 02:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=0r8geqavvkGifHgtt1t2BPjD6nsUPle9CPBdyES3tRA=; b=A5F+TZC/K1zxM6cC47EavTpmDIMTwPnYqCbNMgvmHFs0NJ+MmJZR6WqEJWxu56T8BO QgbC4mNeOF6FlA8+JN5KCdWuS9dMbkycRW6zgaHNigxlPJ/RdGpVwAQjtWtoBjNBS2VC roa8iCAvrqLj5chgCumJIbFbzvUsL3OitEwEMTx16tJy3Vc51rhbMNhfNywCUkY1KenM pb/Sf3yFfvs6b65nYWfPBCGfQfd/5J8m5klwe2mzn0F02XINR2uvpn/GTIlZh4WhnlIf K4oGvWm2BjCKNv2fzszLZKGvGXHroeFNYz/7BSpk+OLCrt74eVVKdZd/mcNY0nkSXPhh 0BmA== Received: by 10.50.36.200 with SMTP id s8mr7343889igj.25.1350984848000; Tue, 23 Oct 2012 02:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Tue, 23 Oct 2012 02:33:27 -0700 (PDT) From: Qiong Date: Tue, 23 Oct 2012 17:33:27 +0800 Message-ID: To: fmc@ietf.org Content-Type: multipart/alternative; boundary=14dae9340827f646e804ccb6ab7e Subject: [fmc] WG: New Version Notification for draft-sun-fmc-use-case-01.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, 23 Oct 2012 09:34:09 -0000 --14dae9340827f646e804ccb6ab7e Content-Type: text/plain; charset=UTF-8 Dear all, We have updated draft-sun-fmc-use-case-01.txt, reflecting the feedback from the last IETF meeting. Your comments are appreciated :) Best wishes Qiong ============================================== A new version of I-D, draft-sun-fmc-use-case-01.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: draft-sun-fmc-use-case Revision: 01 Title: Use Cases and Requirements in Fixed Mobile Convergence Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-sun-fmc-use-case-01.txt Status: http://datatracker.ietf.org/doc/draft-sun-fmc-use-case Htmlized: http://tools.ietf.org/html/draft-sun-fmc-use-case-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-sun-fmc-use-case-01 Abstract: This document provides a brief review of use cases in FMC (Fixed Mobile Convergence) architecture from operational point of view. It also provides technical requirements and problems which need be resolved in IETF. It is complementary to the existing problem statement and requirements documents. -- --14dae9340827f646e804ccb6ab7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have updated draft-sun-fmc-use-case-01.txt, reflecting = the feedback from the last IETF meeting. Your comments are appreciated :)
Best wishes
Qiong


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-sun-fmc-use-case-= 01.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Qiong=C2= =A0Sun=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-fmc-use-case
Revision: =C2=A001
Title: =C2=A0Use=C2=A0Cases=C2=A0and=C2=A0Requirements=C2=A0in=C2=A0Fi= xed=C2=A0Mobile=C2=A0Convergence
Creation=C2=A0date: =C2=A02012-10-22
WG=C2=A0ID: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A010
Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-sun-fmc-use-case-01
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0This=C2=A0document=C2=A0provides=C2=A0a=C2=A0brief= =C2=A0review=C2=A0of=C2=A0use=C2=A0cases=C2=A0in=C2=A0FMC=C2=A0(Fixed
=C2=A0=C2=A0=C2=A0Mobile=C2=A0Convergence)=C2=A0architecture=C2=A0from= =C2=A0operational=C2=A0point=C2=A0of=C2=A0view.=C2=A0=C2=A0It
=C2=A0=C2=A0=C2=A0also=C2=A0provides=C2=A0technical=C2=A0requirements= =C2=A0and=C2=A0problems=C2=A0which=C2=A0need=C2=A0be
=C2=A0=C2=A0=C2=A0resolved=C2=A0in=C2=A0IETF.=C2=A0=C2=A0It=C2=A0is=C2= =A0complementary=C2=A0to=C2=A0the=C2=A0existing=C2=A0problem
=C2=A0=C2=A0=C2=A0statement=C2=A0and=C2=A0requirements=C2=A0documents.=


--

--14dae9340827f646e804ccb6ab7e-- From Dirk.von-Hugo@telekom.de Tue Oct 23 09:19:54 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 4232321F8568 for ; Tue, 23 Oct 2012 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MzpjOS+T8SVZ for ; Tue, 23 Oct 2012 09:19:53 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9522021F859D for ; Tue, 23 Oct 2012 09:19:52 -0700 (PDT) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 23 Oct 2012 18:19:50 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 23 Oct 2012 18:19:50 +0200 From: To: , Date: Tue, 23 Oct 2012 18:19:48 +0200 Thread-Topic: New Version Notification for draft-xue-fmc-ps-03.txt Thread-Index: Ac2wZ5MhiKJPKQ+TTT+4FrPoMRPT7QAAG9FwAB+yXMAAC+QtIA== Message-ID: <05C81A773E48DD49B181B04BA21A342A27CCE6BF04@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A27CCDE9BBD@HE113484.emea1.cds.t-internal.com> <94C682931C08B048B7A8645303FDC9F36E66AD86B5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E66AD86B5@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sarikaya@ieee.org, xueli@huawei.com Subject: Re: [fmc] New Version Notification for draft-xue-fmc-ps-03.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, 23 Oct 2012 16:19:54 -0000 Hi Med, Thank you for the detailed questions. I hope to have fully understood them = and try to answer as far as what is my thinking: (1) In fact the Group Id shall denote the group of all devices belonging to= one subscriber so in the document the expression Group Id is identical to = Subscriber Id. Sorry for the confusion. (2) As is well known in the mobile network sessions are established on a pe= r contract/SIM card/UE basis whereas in a fixed network the identification = is based on the access level (e.g. residential site owner) which with sever= al (e.g. own and visiting) devices within a local network may cover differe= nt UEs. To resolve this ambiguity in the fixed mobile scenario where UEs ma= y belong to the same or different customers the Group Id can help to addres= s the 'right' UE or UEs. So perhaps in addition to Group Id identification = we may need further mechanisms to achieve true per-UE granularity (e.g. inc= luding device capabilities, service preference, policies, etc.). It may be = true that in other scenarios per-UE granularity is achieved by using a prop= er 'host identifier' alone, but here we will focus on FMC scenario. (3) The group id concept shall denote the destination address of IP traffic= for all devices of a subscriber to be able to receive the information (and= the operator may decide on the most useful access technology). How to achi= eve the Group Id to show up in the IP packet is out of scope but a possible= mechanism may be either deployed in the UE or in a central network entity = to map IP addresses of all UEs within a subscribers group to the Group Id a= nd use this, perhaps similar to the logical interface concept described in = http://www.ietf.org/id/draft-ietf-netext-logical-interface-support-06.txt. = Implementation details are not yet defined but the mapping would be part of= the contract bewteen customer and operator. Since not a single host but a = group of devices are addressed here I don't see the similarity to a "host i= dentifier". (4) Difference between group_id and host_id are IMO the fact that with grou= p_id an operator can address, account, authorise, and authenticate differen= t physical devices and access interfaces via a single subscription as is re= quired for FMC scenario. Further potential applications may be service diff= erentiation according to device capabilities but here similar aspects as fo= r host_id issue come into consideration - thus there is indeed some overlap= between both use cases. (5) Some of the technical issues of this draft have been explained above su= ch as for sect. 4 on group_id the unambiguous identification of any device = in the ownership of a customer/subscriber which is especially an issue in f= ixed networks. Furthermore the synchronization of different devices under the same group_i= d may be a technical issue to be solved. Additional issue should be brought= up and discussed on this list ... The issues are specific for 'seamless' service access via multiple devices = or devices with multiple interfaces to such heterogeneous access domains as= mobile and fixed networks administrated by different operators but might p= erhaps also apply to different WiFi hotspot providers. I think that as discussed in the BarBOF in Vancouver "if there is no relati= onship between fixed network and mobile network, UE is not going to be able= to make use of operator services" so a relationship which may include kind= of policy exchange is assumed. AFAIK there is no IETF activity solving those issues right now but of cours= e that will be task for the list and the upcoming session to discuss and fi= nd out. Thanks and I hope to have helped for clarification and that my co-authors w= ill correct me if I was wrong on some parts. Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von moha= med.boucadair@orange.com Gesendet: Dienstag, 23. Oktober 2012 10:03 An: von Hugo, Dirk; fmc@ietf.org Cc: sarikaya@ieee.org; xueli@huawei.com Betreff: Re: [fmc] New Version Notification for draft-xue-fmc-ps-03.txt Hi Dirk, I read the new version you submitted. I have some questions for clarificati= on: (1) You introduced two new identifiers: Group ID and Subscriber ID. What is= the difference between these two identifiers? (2) The document says: " There are many standardization issues related to FMC and protocol extension work needed. If these issues are fixed, the advantages brought out will be: 1. Optimize traffic management (per-UE granularity in the fixed broadband network)" (2.1) Isn't this the purpose of "host identification"? (2.2) Is this really possible if you introduce the concept of GroupID and n= ot "host identifier"? (3) The text says: "The subscriber ID must be contained in the traffic packet of the subscriber in order to achieve policy enforcement in the device node in the network." (3.1) Why a subscriber identifier is needed to be leaked into IP packets? (3.2) Who is responsible for injecting this information in IP packets? (3.3) How a device will discover/learn/"be provisioned" with this informati= on? (3.4) How to trust this information? Is the device injecting this informati= on a trusted device? (3.5) Solution examples you listed are bound to IP, do you have in mind exa= mples which would not be similar to a "host identifier"? (4) Several parts of the GorupID text are close to the host identification = issue. Could you please explain the difference? (5) The text does not summarize the technical issues; for instance: (5.1) What are the technical issues in Section 4? (5.2) Why these issues are specific to FMC? (5.3) Is inter-operator policy exchange in scope? (5.4) Why existing IETF tools do not solve encountered issues? Thanks. Cheers, Med >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >part de Dirk.von-Hugo@telekom.de >Envoy=E9 : lundi 22 octobre 2012 17:22 >=C0 : fmc@ietf.org >Cc : sarikaya@ieee.org; xueli@huawei.com >Objet : [fmc] WG: New Version Notification for draft-xue-fmc-ps-03.txt > > >Dear all, >For the FMC BoF in Atlanta we have submitted a new version for >PS draft where we have focussed on two use cases which should >be specific for operators use case to provide fixed mobile >converged services via interworking of their heterogeneous >access networks. >Group Id handling (for a subscriber owning multiple UE >devices) and UE mobility within fixed networks are described >as potential FMC use cases. Please don't hesitate to send your >comments to the list! > >Best regards >Dirk > >-----Urspr=FCngliche Nachricht----- >Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Gesendet: Montag, 22. Oktober 2012 17:12 >An: von Hugo, Dirk >Cc: sarikaya@ieee.org; xueli@huawei.com >Betreff: New Version Notification for draft-xue-fmc-ps-03.txt > > >A new version of I-D, draft-xue-fmc-ps-03.txt >has been successfully submitted by Dirk von Hugo and posted to the >IETF repository. > >Filename: draft-xue-fmc-ps >Revision: 03 >Title: Problem Statement for Fixed Mobile Convergence >Creation date: 2012-10-22 >WG ID: Individual Submission >Number of pages: 14 >URL: >http://www.ietf.org/internet-drafts/draft-xue-fmc-ps-03.txt >Status: http://datatracker.ietf.org/doc/draft-xue-fmc-ps >Htmlized: http://tools.ietf.org/html/draft-xue-fmc-ps-03 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-xue-fmc-ps-03 > >Abstract: > The purpose of this document is to analyze the issues that have > arisen so far and to propose several use cases for the Fixed Mobile > Convergence. This document gives a brief overview of the assumed > Fixed Mobile Convergence architecture and related works and then > introduces several Intarea type of use cases based on the >partnership > in Fixed Mobile Convergence architecture, such as group > identification, mobility consideration, such as mobility status > reporting in Wi-Fi network. > > > > >The IETF Secretariat > >_______________________________________________ >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