From Roland.Schott@telekom.de Tue Jun 5 08:16: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 6E29B21F875C for ; Tue, 5 Jun 2012 08:16:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l6BaliX-ZOc for ; Tue, 5 Jun 2012 08:16:09 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7D06121F875B for ; Tue, 5 Jun 2012 08:16:09 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jun 2012 17:16:07 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Jun 2012 17:16:07 +0200 From: To: Date: Tue, 5 Jun 2012 17:16:05 +0200 Thread-Topic: New Version Notification for draft-schott-fmc-requirements-00.txt Thread-Index: Ac1DLe2E4pp7XUHEQRWKVlNRW8yWRgAABnzw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434A78358@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [fmc] WG: New Version Notification for draft-schott-fmc-requirements-00.txt X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:16:10 -0000 Dear all, please comment.... -----Urspr=FCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Gesendet: Dienstag, 5. Juni 2012 17:15 An: Schott, Roland Betreff: New Version Notification for draft-schott-fmc-requirements-00.txt A new version of I-D, draft-schott-fmc-requirements-00.txt has been success= fully submitted by Roland Schott and posted to the IETF repository. Filename: draft-schott-fmc-requirements Revision: 00 Title: Requirements on Fixed Mobile Convergence Creation date: 2012-06-05 WG ID: Individual Submission Number of pages: 9 Abstract: This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. The IETF Secretariat From Dirk.von-Hugo@telekom.de Tue Jun 5 08:19:27 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 85AB521F8762 for ; Tue, 5 Jun 2012 08:19:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjNgWuJ3uDrW for ; Tue, 5 Jun 2012 08:19:27 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id B017321F8760 for ; Tue, 5 Jun 2012 08:19:26 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 05 Jun 2012 17:19:19 +0200 Received: from HE113675.emea1.cds.t-internal.com (10.134.99.28) by HE113470.emea1.cds.t-internal.com (10.134.93.128) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 5 Jun 2012 17:19:18 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 5 Jun 2012 17:19:18 +0200 From: To: , Date: Tue, 5 Jun 2012 17:19:15 +0200 Thread-Topic: New Version Notification for draft-schott-fmc-requirements-00.txt Thread-Index: Ac1DLe2E4pp7XUHEQRWKVlNRW8yWRgAABnzwAAAYojA= Message-ID: <05C81A773E48DD49B181B04BA21A342A27A450BD45@HE113484.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434A78358@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434A78358@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-00.txt X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:19:27 -0000 Dear all, Enclosed the link to the document http://www.ietf.org/id/draft-schott-fmc-r= equirements-00.txt Thanks to Pierrick, Sophie, Med, and Hasnaa for their valuable contribution= s. Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von Scho= tt, Roland Gesendet: Dienstag, 5. Juni 2012 17:16 An: fmc@ietf.org Betreff: [fmc] WG: New Version Notification for draft-schott-fmc-requiremen= ts-00.txt Dear all, please comment.... -----Urspr=FCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Gesendet: Dienstag, 5. Juni 2012 17:15 An: Schott, Roland Betreff: New Version Notification for draft-schott-fmc-requirements-00.txt A new version of I-D, draft-schott-fmc-requirements-00.txt has been success= fully submitted by Roland Schott and posted to the IETF repository. Filename: draft-schott-fmc-requirements Revision: 00 Title: Requirements on Fixed Mobile Convergence Creation date: 2012-06-05 WG ID: Individual Submission Number of pages: 9 Abstract: This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. The IETF Secretariat _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Wed Jun 6 09:42: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 1431421F88C0 for ; Wed, 6 Jun 2012 09:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4i039ykUwYu for ; Wed, 6 Jun 2012 09:42:15 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 842D721F8892 for ; Wed, 6 Jun 2012 09:42:15 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5737885ggn.31 for ; Wed, 06 Jun 2012 09:42:15 -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=90iWEFj/GiM9JqUYNcV8wJv0Jre12xt5npOXqA/JGAk=; b=OqS2AiM0Y5hISRe9MTzoPBfMvYOjdC0M5dZEGoDhrLxfJ2e9x1H1zhBFSB7GfQ8eks 9wZn5330WhLRvkgAbjd2xPMX7Sx+B9r0ojbubRhMez/5qJUbEMhEeYN2KWfoT9BFeErY PfG0JIXwAVTZryoeIp/TA0AYq0k/f/HA2eYUz5KJbL+2wCht6Wnh8uAB1+9urMyB722y iRU7pmk9+AP0qdJ7fDivJ5vbuh3pamSyCpwACwHCqpSSPhEreRuTqx8Z9pH+POV1Pky3 x0Z9bgcbG72XjI+VXl7P3/gEgF9PYfFDFGBTR0EwgqThUg97g1ezO+TURjEx5BiDqEP+ 9Krw== MIME-Version: 1.0 Received: by 10.50.154.233 with SMTP id vr9mr7518360igb.9.1339000934837; Wed, 06 Jun 2012 09:42:14 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 6 Jun 2012 09:42:14 -0700 (PDT) In-Reply-To: <4FBD2C1E.9050706@computer.org> References: <4FBD2C1E.9050706@computer.org> Date: Wed, 6 Jun 2012 11:42:14 -0500 Message-ID: From: Behcet Sarikaya To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fmc@ietf.org" Subject: Re: [fmc] Hello out there... 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, 06 Jun 2012 16:42:16 -0000 Hi Charlie, Sorry we somehow went offlist for quite long time. Now that a requirements draft has been posted, we should discuss it on the list. Regards, Behcet On Wed, May 23, 2012 at 1:27 PM, Charles E. Perkins wrote: > > Hello folks, > > Is there anything going on with FMC these days? =A0I sent email out a cou= ple > of weeks ago. > Since then it seems to have been silent (or else I just didn't receive an= y > messages). > > What needs to be done next? > > -- > Regards, > Charlie P. > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Wed Jun 6 12:53: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 8BEA221F8551 for ; Wed, 6 Jun 2012 12:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnDynJRsPk2P for ; Wed, 6 Jun 2012 12:53:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC87921F8535 for ; Wed, 6 Jun 2012 12:53:53 -0700 (PDT) Received: by yhq56 with SMTP id 56so5881782yhq.31 for ; Wed, 06 Jun 2012 12:53:53 -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 :content-transfer-encoding; bh=c48XPEn+OhtAFjXF6Vv0/ArnqWmusHq7AjoOP70Pgos=; b=tRwnsEV9n45q9sPRLgDTjPuE9N6vtQ7xs/QOnSWjrZQ02/cW0DrYmqSRhsYJMri6Yz +V/eOyeoPU6PCLTDVwyU1CClR/pwhdrSK1LjEu2rfu507YigBdSOao+O+mxaVVgzgRXO FbfvfwAL2QsVMs2nLHxh0d8/SpaznzjXfBMYOf033MHmqlvy5hQ1DaeHPKkhEKvN8c+J dJR7zUlA0DrjxL1B1L2icXkkRuCVj/DDKkv4Il9D/o8Ptb1/UKvjqVc3HWKo1PXIL26s oh4z5QiEPkDHbnkUonBWHPDZfDBKEsLazochdnFtZC+V7JYb4vVtQz6KEAguJCha+JYy hodA== MIME-Version: 1.0 Received: by 10.50.160.198 with SMTP id xm6mr8089541igb.0.1339012433134; Wed, 06 Jun 2012 12:53:53 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 6 Jun 2012 12:53:53 -0700 (PDT) Date: Wed, 6 Jun 2012 14:53:53 -0500 Message-ID: From: Behcet Sarikaya To: fmc@ietf.org, Dirk.von-Hugo@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [fmc] New Version Notification for problem statement draft 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, 06 Jun 2012 19:53:54 -0000 Hi, Here is the link to the document: http://www.ietf.org/id/draft-xue-fmc-ps-00.txt Regards, Behcet On Tue, Jun 5, 2012 at 10:19 AM, wrote: > Dear all, > Enclosed the link to the document http://www.ietf.org/id/draft-schott-fmc= -requirements-00.txt > Thanks to Pierrick, Sophie, Med, and Hasnaa for their valuable contributi= ons. > > Best regards > Dirk > -----Urspr=FCngliche Nachricht----- > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von Sc= hott, Roland > Gesendet: Dienstag, 5. Juni 2012 17:16 > An: fmc@ietf.org > Betreff: [fmc] WG: New Version Notification for draft-schott-fmc-requirem= ents-00.txt > > > Dear all, > > please comment.... > > > -----Urspr=FCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Dienstag, 5. Juni 2012 17:15 > An: Schott, Roland > Betreff: New Version Notification for draft-schott-fmc-requirements-00.tx= t > > A new version of I-D, draft-schott-fmc-requirements-00.txt has been succe= ssfully submitted by Roland Schott and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-schott-fmc-requirements > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 Requirements on Fixed Mobile Convergence > Creation date: =A0 2012-06-05 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 9 > > Abstract: > =A0 This document provides a brief overview of the FMC (Fixed Mobile > =A0 Convergence) architecture and related works. =A0The purpose of the > =A0 document is to sketch a big picture for the FMC activity to ease > =A0 identifying whether specification effort is required within IETF. > =A0 This document identifies and analyzes some of issues that have arisen > =A0 so far and elaborates a set of requirements for the FMC system. > > > > > 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 From pierrick.seite@orange.com Thu Jun 7 01:14:37 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643C221F87B6 for ; Thu, 7 Jun 2012 01:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWOeruqbGEi7 for ; Thu, 7 Jun 2012 01:14:30 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B859B21F87B9 for ; Thu, 7 Jun 2012 01:14:29 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5104A4414A for ; Thu, 7 Jun 2012 10:16:01 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id BC029A440E3 for ; Thu, 7 Jun 2012 10:16:01 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 10:14:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jun 2012 10:14:26 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462025F9D7B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] WG: New Version Notification for draft-schott-fmc- Thread-Index: Ac1EHi6+xAoXA3iLTgSdneRusa4YKgAY8rDQ References: From: To: X-OriginalArrivalTime: 07 Jun 2012 08:14:28.0248 (UTC) FILETIME=[8EE76180:01CD4485] Subject: Re: [fmc] WG: New Version Notification for draft-schott-fmc- 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, 07 Jun 2012 08:14:37 -0000 Hi all, During discussions that led to this I-D, I pointed out the following = draft: http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-04 = v6ops draft is not FMC specific (this draft covers wi-fi operations) but = many requirements look similar. So, I'm wondering what is specific to = FMC that is not covered in vo6ops draft; content adaptation maybe.... We = could have same question regarding access selection that is covered in = MIF WG. And so on. So, I guess the next step for FMC is a gap analysis = that shall be handle in the problem statement draft, right? BR, Pierrick k > > -----Urspr=FCngliche Nachricht----- > > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag > von Schott, Roland > > Gesendet: Dienstag, 5. Juni 2012 17:16 > > An: fmc@ietf.org > > Betreff: [fmc] WG: New Version Notification for draft-schott-fmc- > requirements-00.txt > > > > > > Dear all, > > > > please comment.... > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Gesendet: Dienstag, 5. Juni 2012 17:15 > > An: Schott, Roland > > Betreff: New Version Notification for draft-schott-fmc-requirements- > 00.txt > > > > A new version of I-D, draft-schott-fmc-requirements-00.txt has been > successfully submitted by Roland Schott and posted to the IETF > repository. > > > > Filename: =A0 =A0 =A0 =A0draft-schott-fmc-requirements > > Revision: =A0 =A0 =A0 =A000 > > Title: =A0 =A0 =A0 =A0 =A0 Requirements on Fixed Mobile Convergence > > Creation date: =A0 2012-06-05 > > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > > Number of pages: 9 > > > > Abstract: > > =A0 This document provides a brief overview of the FMC (Fixed Mobile > > =A0 Convergence) architecture and related works. =A0The purpose of = the > > =A0 document is to sketch a big picture for the FMC activity to ease > > =A0 identifying whether specification effort is required within = IETF. > > =A0 This document identifies and analyzes some of issues that have > arisen > > =A0 so far and elaborates a set of requirements for the FMC system. > > > > > > > > > > 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 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Thu Jun 7 09:07: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 EE7D411E80D2 for ; Thu, 7 Jun 2012 09:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 467zNRk0QWGK for ; Thu, 7 Jun 2012 09:07:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 162FA21F85FC for ; Thu, 7 Jun 2012 09:07:39 -0700 (PDT) Received: by yenq13 with SMTP id q13so635541yen.31 for ; Thu, 07 Jun 2012 09:07:38 -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=w/WPX622eMXVTOtn6WeAwBId9zEuQW+DfcseiZI65CI=; b=uZK1PC+vFZ5lv5np7qbZEPldr5aLYbBvEK0N0p5oPzYATuwMcVbqkUimAJn69iWC2z f9zmJGygRvWQkcFJIFtYfvAGVX+W4xDayVwRsewxxyJKaGsu1BxUcgBdAfcD0bWMd3mR 27xVDkHKdfgIZpgSxHrFLlc0lBlbsewC7YeLtQAqt8A0BUHH3ikniaIOaj2jHxqQ/2lL jf5/deMMzmkOj7ZPkPCyPOeyySMMJtyPOop5CDCF0cWQhxWrf8/VrQJJkAObhUpfDYJz bMj8EqpviU90usUf2HDSLo7vdCJRXmgZnW7xzdtTr77ygUtYKVS4irVga/lUuXddzRNV hapA== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr1493352iga.9.1339085258398; Thu, 07 Jun 2012 09:07:38 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 7 Jun 2012 09:07:34 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462025F9D7B@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C462025F9D7B@ftrdmel0.rd.francetelecom.fr> Date: Thu, 7 Jun 2012 11:07:34 -0500 Message-ID: From: Behcet Sarikaya To: pierrick.seite@orange.com, fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng Subject: Re: [fmc] WG: New Version Notification for draft-schott-fmc- 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, 07 Jun 2012 16:07:40 -0000 Hi Pierrick, On Thu, Jun 7, 2012 at 3:14 AM, wrote: > Hi all, > > During discussions that led to this I-D, I pointed out the following draf= t: > > http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-04 > > v6ops draft is not FMC specific (this draft covers wi-fi operations) but = many requirements look similar. So, I'm wondering what is specific to FMC t= hat is not covered in vo6ops draft; content adaptation maybe.... We could h= ave same question regarding access selection that is covered in MIF WG. And= so on. So, I guess the next step for FMC is a gap analysis that shall be h= andle in the problem statement draft, right? > I think you made an interesting point. May be we should check with Hui as to the gaps on especially the access selection use case that we have in the requirements draft. I cc'ed this mail to Hui. Regards, Behcet From charliep@computer.org Thu Jun 7 22:29:48 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 5DF9121F8552 for ; Thu, 7 Jun 2012 22:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RBK4OCiDFrD for ; Thu, 7 Jun 2012 22:29:47 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B276821F83EF for ; Thu, 7 Jun 2012 22:29:47 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Scrlb-0005wf-3l for fmc@ietf.org; Fri, 08 Jun 2012 01:29:47 -0400 Message-ID: <4FD18DC2.1030401@computer.org> Date: Thu, 07 Jun 2012 22:29:38 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "fmc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad860a31bf74621a521d9534e5407855eea1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 05:29:48 -0000 Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request... Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range. The latter are generally anchored on a fixed residential or enterprise gateway. Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements. While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset). Other requirements might include session continuity, policy distribution, QoS management, and application mobility. The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities. -- Regards, Charlie P. From tso@zteusa.com Thu Jun 7 23:00:46 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 33F7611E80A0 for ; Thu, 7 Jun 2012 23:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoli7ClIZ8bY for ; Thu, 7 Jun 2012 23:00:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD611E8080 for ; Thu, 7 Jun 2012 23:00:44 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Fri, 8 Jun 2012 13:59:25 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.4605341425; Fri, 8 Jun 2012 14:00:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q58603jP089844; Fri, 8 Jun 2012 14:00:03 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <4FD18DC2.1030401@computer.org> References: <4FD18DC2.1030401@computer.org> To: "Charles E. Perkins" MIME-Version: 1.0 X-KeepSent: 7860C73B:E2025D3F-88257A17:001F1B47; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 7 Jun 2012 22:59:52 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-08 14:00:05, Serialize complete at 2012-06-08 14:00:05 Content-Type: multipart/alternative; boundary="=_alternative 0020F51388257A17_=" X-MAIL: mse02.zte.com.cn q58603jP089844 Cc: david.i.allan@ericsson.com, "fmc@ietf.org" Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 06:00:46 -0000 This is a multipart message in MIME format. --=_alternative 0020F51388257A17_= Content-Type: text/plain; charset="US-ASCII" Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many questions come to my mind. Could you please help me to understand better on those considerations? Please see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request... Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range. The latter are generally anchored on a fixed residential or enterprise gateway. Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address? The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues. I would not like to see the duplicate work done in different SDOs and come up with different solutions? While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA? Especially, I am sure that they already have their own definitions. So, what are the wireless end device that you have in mind that needs to be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, QoS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated. Thanks again in advance to help me to understand your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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 0020F51388257A17_= Content-Type: text/html; charset="US-ASCII" Dear Charles,

Thank you very much for your kind initiative for this work.

However, when I examine the charter that you were describing below, many questions come to my mind.

Could you please help me to understand better on those considerations?  Please see inline below..

Thanks in advance.
Tricci




"Charles E. Perkins" <charliep@computer.org>
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM

To
"fmc@ietf.org" <fmc@ietf.org>
cc
Subject
[fmc] FMC BoF at IETF 84?






Hello folks,

It's time to request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request...

Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any specific request on this work?  If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address?   The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues.  I would not like to see the duplicate work done in different SDOs and come up with different solutions?  

 While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset).  

Tricci > May I ask, why would be the IETF's role to define the wireless end device?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA?  Especially, I am sure that they already have their own definitions.  So, what are the wireless end device that you have in mind that needs to be defined by IETF?  Could you please clarify?  

Other requirements might include session continuity, policy distribution, QoS management, and application mobility.

Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF?  

The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities.

Tricci > Sorry for asking so many questions?  I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated.  Thanks again in advance to help me to understand your proposal for this BOF.  

--
Regards,
Charlie P.

_______________________________________________
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 0020F51388257A17_=-- From mohamed.boucadair@orange.com Thu Jun 7 23:32: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 CE91A21F8629 for ; Thu, 7 Jun 2012 23:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Eet2tBv808M for ; Thu, 7 Jun 2012 23:32:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB621F861E for ; Thu, 7 Jun 2012 23:32:12 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3E93222C3C3; Fri, 8 Jun 2012 08:32:12 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1A1BC27C058; Fri, 8 Jun 2012 08:32:12 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 8 Jun 2012 08:32:11 +0200 From: To: "Charles E. Perkins" , "fmc@ietf.org" Date: Fri, 8 Jun 2012 08:32:09 +0200 Thread-Topic: [fmc] FMC BoF at IETF 84? Thread-Index: Ac1FN7rcWfV8prlMTnmIa0pHrtsUnwABgcIA Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1FF1@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD18DC2.1030401@computer.org> In-Reply-To: <4FD18DC2.1030401@computer.org> 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.6.8.53333 Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 06:32:13 -0000 Dear Charlie, IMHO, it is too early to request a BoF. We are still in the process of asse= ssing whether there is a specification effort required within IETF. Even in this mailing list, there was not much discussion and several questi= ons are still to be fixed first. The current available "fmc" documents are not mature; especially the requir= ements draft is in the very early stage. We have contributed with three iss= ues to kick off the discussion but as mentioned in the Introduction of the = draft, this does not mean we are voicing for creating a WG and so. We need to focus our energy and avoid waste it in preparing a BoF which is = likely to fail in achieving its objectives.=20 Alternatively, I would invite interested people to contribute to the requir= ements document and to challenges the requirements and recommendations sket= ched in it.=20 Before requesting a formal meeting in IETF, we need IMHO to have clear idea= s about the following:=20 * Is there any remaining issues to be solved? * Why existing IETF tools do not help to solve those issues? * Are these issues specific to the "FMC" context (as understood in BBF-3GPP= )? * If there are issues specific to FMC, what are the specificities?=20 * What is the best approach to make help advancing missing specification pi= eces?: Existing WGs, New WG, etc. * Wouldn't be better to seek for liaison from BBF and 3GPP? Cheers, Med=20 >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de Charles E. Perkins >Envoy=E9 : vendredi 8 juin 2012 07:30 >=C0 : fmc@ietf.org >Objet : [fmc] FMC BoF at IETF 84? > > >Hello folks, > >It's time to request a BoF during IETF 84 on the subject of FMC. > >A suitable BoF agenda would be to agree on an effective definition >for "fixed-mobile convergence" and to identify the initial steps along >the way towards the goals. Here is some text that might be used >to make the BoF request... > >Fixed-mobile convergence, as commonly interpreted, should provide >satisfactory user experience when the user migrates between >wide-area cellular networks and WLAN networks having limited >range. The latter are generally anchored on a fixed residential >or enterprise gateway. Our understanding of the problem statement >and requirements has been derived from documents published by >the BBF and the ITU [citations here]. > >Work is needed in the IETF to meet the requirements. While there >are many possible solutions, all of them will require some >agreement on how to identify the wireless end device (e.g., >handset). Other requirements might include session continuity, >policy distribution, QoS management, and application mobility. >The initial set of goals should be strictly limited, and future >broadening is to depend both on the solutions adopted for the >initial goal set as well as the evolving needs of the user and >network operator communities. > >--=20 >Regards, >Charlie P. > >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc >= From charliep@computer.org Thu Jun 7 23:54: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 2912E11E80B7 for ; Thu, 7 Jun 2012 23:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30aB+8gC75-8 for ; Thu, 7 Jun 2012 23:54:36 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9D93211E80B1 for ; Thu, 7 Jun 2012 23:54:36 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sct5C-0000xa-7t; Fri, 08 Jun 2012 02:54:06 -0400 Message-ID: <4FD1A186.8060605@computer.org> Date: Thu, 07 Jun 2012 23:53:58 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tso@zteusa.com References: <4FD18DC2.1030401@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050707020103070200080601" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8624625891d379b8a7f70251e127911717350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: "fmc@ietf.org" , david.i.allan@ericsson.com Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 06:54:38 -0000 This is a multi-part message in MIME format. --------------050707020103070200080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated that there is work to do. I can certainly imagine that the IETF should have something to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see the need, or else see that it is already being met. If you'd like to supply some pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one or two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relevant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessarily within the jurisdiction of the IETF, but they seemed to me to be well within the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out that nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: > Dear Charles, > > Thank you very much for your kind initiative for this work. > > However, when I examine the charter that you were describing below, > many questions come to my mind. > > Could you please help me to understand better on those considerations? > Please see inline below.. > > Thanks in advance. > Tricci > > > > > *"Charles E. Perkins" * > Sent by: fmc-bounces@ietf.org > > 06/07/2012 10:29 PM > > > To > "fmc@ietf.org" > cc > > Subject > [fmc] FMC BoF at IETF 84? > > > > > > > > > > > Hello folks, > > It's time to request a BoF during IETF 84 on the subject of FMC. > > A suitable BoF agenda would be to agree on an effective definition for > "fixed-mobile convergence" and to identify the initial steps along the > way towards the goals. Here is some text that might be used to make > the BoF request... > > Fixed-mobile convergence, as commonly interpreted, should provide > satisfactory user experience when the user migrates between wide-area > cellular networks and WLAN networks having limited range. The latter > are generally anchored on a fixed residential or enterprise gateway. > Our understanding of the problem statement and requirements has been > derived from documents published by the BBF and the ITU [citations > here].Work is needed in the IETF to meet the requirements. > > Tricci > May I ask, has BBF or ITU sent any specific request on this > work? If so, what are the specific problems that BBF has asked IETF, > more specifically, this BOF, to address? The reason that I asked > this question is that, I work closely with my colleagues in BBF on > many of those FMC issues. I would not like to see the duplicate work > done in different SDOs and come up with different solutions? > > While there are many possible solutions, all of them will require > some agreement on how to identify the wireless end device (e.g., > handset). > > Tricci > May I ask, why would be the IETF's role to define the > wireless end device? Shouldn't this be the responsibility of the > 3GPP, 3GPP2, WiMAX and WFA? Especially, I am sure that they already > have their own definitions. So, what are the wireless end device that > you have in mind that needs to be defined by IETF? Could you please > clarify? > > Other requirements might include session continuity, policy > distribution, QoS management, and application mobility. > > Tricci > As the active contributors to 3GPP and BBF work, all of these > subjects have been going on in both of these SDO, could you please > clarify what are the specific aspects that are not covered by the > other SDOs that need additional work to be done in IETF? > > The initial set of goals should be strictly limited, and future > broadening is to depend both on the solutions adopted for the initial > goal set as well as the evolving needs of the user and network > operator communities. > > Tricci > Sorry for asking so many questions? I have the selfish > reason to ensure that no duplicate work is done between IETF and the > other SDOs that I am actively participated. Thanks again in advance > to help me to understand your proposal for this BOF. > > -- > Regards, > Charlie P. > > _______________________________________________ > 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. > > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. --------------050707020103070200080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated that
there is work to do.  I can certainly imagine that the IETF should have something
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.  From the BBF and ITU documents, it
seemed quite reasonable to initiate some effort.  I gather you do not see the
need, or else see that it is already being met.  If you'd like to supply some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF
people don't have to wait to be told what needs to be done.  Of course if
some other SDO does tell the IETF what needs to be done, it can be easier
to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.  I'm personally familiar with one or
two cases.  And, to some extent, duplication can be in the eyes of the
beholder.  For instance, why mess around with having NAIs or IMSIs when
we already have FQDNs??  [just kidding, no worries, I do understand]

Please also note that "identify" is not at all the same as "define".

Regarding the other points -- if you'd like to supply pointers to the relevant
work in other SDOs for "session continuity, policy distribution, QoS
management, and application mobility"  I'd be interested to take a look.
Somehow, in discussions with other interested people, I had the impression
that these things were lacking.  I don't even claim that they are necessarily
within the jurisdiction of the IETF, but they seemed to me to be well within
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to
find out what if anything needs to be done.  It's always O.K. to find out that
nothing needs to be done -- perhaps even preferable.  That was not at all
the sense I got from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 PM, tso@zteusa.com wrote:
Dear Charles,

Thank you very much for your kind initiative for this work.

However, when I examine the charter that you were describing below, many questions come to my mind.

Could you please help me to understand better on those considerations?  Please see inline below..

Thanks in advance.
Tricci




"Charles E. Perkins" <charliep@computer.org>
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM

To
 "fmc@ietf.org" <fmc@ietf.org>
cc
Subject
 [fmc] FMC BoF at IETF 84?








Hello folks,

It's time to request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request...

Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any specific request on this work?  If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address?   The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues.  I would not like to see the duplicate work done in different SDOs and come up with different solutions?  

 While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset).  

Tricci > May I ask, why would be the IETF's role to define the wireless end device?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA?  Especially, I am sure that they already have their own definitions.  So, what are the wireless end device that you have in mind that needs to be defined by IETF?  Could you please clarify?  

Other requirements might include session continuity, policy distribution, QoS management, and application mobility.

Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF?  

The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities.

Tricci > Sorry for asking so many questions?  I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated.  Thanks again in advance to help me to understand your proposal for this BOF.  

--
Regards,
Charlie P.

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




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



-- 
Regards,
Charlie P.
--------------050707020103070200080601-- From tso@zteusa.com Fri Jun 8 00:29:25 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 BCBC621F86BD for ; Fri, 8 Jun 2012 00:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8FdigDtFWhd for ; Fri, 8 Jun 2012 00:29:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A71A821F86BA for ; Fri, 8 Jun 2012 00:29:23 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Fri, 8 Jun 2012 15:26:15 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 71343.4605341425; Fri, 8 Jun 2012 15:29:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q587TBWP036147; Fri, 8 Jun 2012 15:29:11 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <4FD1A186.8060605@computer.org> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> To: "Charles E. Perkins" MIME-Version: 1.0 X-KeepSent: D5FB6711:E50A25AC-88257A17:0027B573; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 8 Jun 2012 00:28:59 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-08 15:29:13, Serialize complete at 2012-06-08 15:29:13 Content-Type: multipart/alternative; boundary="=_alternative 00291EF188257A17_=" X-MAIL: mse02.zte.com.cn q587TBWP036147 Cc: "fmc@ietf.org" , david.i.allan@ericsson.com Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 07:29:25 -0000 This is a multipart message in MIME format. --=_alternative 00291EF188257A17_= Content-Type: text/plain; charset="US-ASCII" Dear Charles, Sincerely thanks for your prompt responses. I would like to clarify that, I have not implied anything on one-way or the other that no work needs to be done in IETF. I thought that I was very clear for asking what needs to be done based on your descriptions for the BOF? Somehow, my questions are bounced back to me? May be it is my lack of understanding of IETF's culture? I would think that, when a BOF is formed, there is strong indication that some work must need and worth to be investigated in IETF. But, based on your descriptions, I can't derive what they are? Unfortunately, at this point, my questions are still remained. :) Thanks again for your timely response. Tricci "Charles E. Perkins" 06/07/2012 11:53 PM To tso@zteusa.com cc david.i.allan@ericsson.com, "fmc@ietf.org" Subject Re: [fmc] FMC BoF at IETF 84? Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated that there is work to do. I can certainly imagine that the IETF should have something to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see the need, or else see that it is already being met. If you'd like to supply some pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one or two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relevant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessarily within the jurisdiction of the IETF, but they seemed to me to be well within the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out that nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many questions come to my mind. Could you please help me to understand better on those considerations? Please see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request... Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range. The latter are generally anchored on a fixed residential or enterprise gateway. Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address? The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues. I would not like to see the duplicate work done in different SDOs and come up with different solutions? While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA? Especially, I am sure that they already have their own definitions. So, what are the wireless end device that you have in mind that needs to be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, QoS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated. Thanks again in advance to help me to understand your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. -------------------------------------------------------- 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 00291EF188257A17_= Content-Type: text/html; charset="US-ASCII" Dear Charles,

Sincerely thanks for your prompt responses.  

I would like to clarify that, I have not implied anything on one-way or the other that no work needs to be done in IETF.

I thought that I was very clear for asking what needs to be done based on your descriptions for the BOF?  Somehow, my questions are bounced back to me?

May be it is my lack of understanding of IETF's culture?  I would think that, when a BOF is formed, there is strong indication that some work must need and worth to be investigated in IETF.  But, based on your descriptions, I can't derive what they are?

Unfortunately, at this point, my questions are still remained. :)

Thanks again for your timely response.
Tricci




"Charles E. Perkins" <charliep@computer.org>

06/07/2012 11:53 PM

To
tso@zteusa.com
cc
david.i.allan@ericsson.com, "fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] FMC BoF at IETF 84?






Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated that
there is work to do.  I can certainly imagine that the IETF should have something
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.  From the BBF and ITU documents, it
seemed quite reasonable to initiate some effort.  I gather you do not see the
need, or else see that it is already being met.  If you'd like to supply some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF
people don't have to wait to be told what needs to be done.  Of course if
some other SDO does tell the IETF what needs to be done, it can be easier
to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.  I'm personally familiar with one or
two cases.  And, to some extent, duplication can be in the eyes of the
beholder.  For instance, why mess around with having NAIs or IMSIs when
we already have FQDNs??  [just kidding, no worries, I do understand]

Please also note that "identify" is not at all the same as "define".

Regarding the other points -- if you'd like to supply pointers to the relevant
work in other SDOs for "session continuity, policy distribution, QoS
management, and application mobility"  I'd be interested to take a look.
Somehow, in discussions with other interested people, I had the impression
that these things were lacking.  I don't even claim that they are necessarily
within the jurisdiction of the IETF, but they seemed to me to be well within
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to
find out what if anything needs to be done.  It's always O.K. to find out that
nothing needs to be done -- perhaps even preferable.  That was not at all
the sense I got from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 PM, tso@zteusa.com wrote:
Dear Charles,

Thank you very much for your kind initiative for this work.

However, when I examine the charter that you were describing below, many questions come to my mind.

Could you please help me to understand better on those considerations?  Please see inline below..

Thanks in advance.
Tricci



"Charles E. Perkins" <charliep@computer.org>
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM


To
"fmc@ietf.org" <fmc@ietf.org>
cc
Subject
[fmc] FMC BoF at IETF 84?








Hello folks,

It's time to request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request...

Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any specific request on this work?  If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address?   The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues.  I would not like to see the duplicate work done in different SDOs and come up with different solutions?  

While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset).  

Tricci > May I ask, why would be the IETF's role to define the wireless end device?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA?  Especially, I am sure that they already have their own definitions.  So, what are the wireless end device that you have in mind that needs to be defined by IETF?  Could you please clarify?  

Other requirements might include session continuity, policy distribution, QoS management, and application mobility.

Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF?  

The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities.

Tricci > Sorry for asking so many questions?  I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated.  Thanks again in advance to help me to understand your proposal for this BOF.  

--
Regards,
Charlie P.

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


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


--
Regards,
Charlie P. 

--------------------------------------------------------
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 00291EF188257A17_=-- From pierrick.seite@orange.com Fri Jun 8 01:09: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 BF61D21F88BD for ; Fri, 8 Jun 2012 01:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DwU9RKcBe3w for ; Fri, 8 Jun 2012 01:09:18 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93921F88B9 for ; Fri, 8 Jun 2012 01:09:17 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 08B80E3065A; Fri, 8 Jun 2012 10:10:04 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id F0D09E30659; Fri, 8 Jun 2012 10:10:03 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 10:09:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD454D.FE381DC2" Date: Fri, 8 Jun 2012 10:09:12 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4FD1A186.8060605@computer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] FMC BoF at IETF 84? Thread-Index: Ac1FQ6XTjJkAmvHARRG5OcIAeLkMfAABQkLg References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> From: To: , X-OriginalArrivalTime: 08 Jun 2012 08:09:15.0796 (UTC) FILETIME=[FF14BD40:01CD454D] Cc: david.i.allan@ericsson.com, fmc@ietf.org Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 08:09:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD454D.FE381DC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Actually, this is a good discussion. I agree that gathering requirements = for FMC is a good exercise, as long as it is done from an IETF = standpoint. Otherwise, we duplicate BBF work. It is also worth to identify existing IETF solutions , or ongoing work, = that might meet these requirements. Then gap analysis should be done: = what are the specific FMC issues that cannot be solved with current = protocols, or using other SDOs mechanisms? That's a fair question which = should be answered before going into a BoF, but the problem is that = early stage drafts do not answer above question. In other words, more = work is needed before going into a BoF. It does not mean we should stop = discussing; clearly, ongoing work in IETF/FMC is worth the effort but we = still have not shown the interest for a dedicated FMC IETF WG... In my = opinion... =20 BR, Pierrick =20 De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de = Charles E. Perkins Envoy=E9 : vendredi 8 juin 2012 08:54 =C0 : tso@zteusa.com Cc : fmc@ietf.org; david.i.allan@ericsson.com Objet : Re: [fmc] FMC BoF at IETF 84? =20 Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, = indicated that there is work to do. I can certainly imagine that the IETF should have = something to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not = see the need, or else see that it is already being met. If you'd like to supply = some pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the = IETF people don't have to wait to be told what needs to be done. Of course = if some other SDO does tell the IETF what needs to be done, it can be = easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with = one or two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the = relevant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the = impression that these things were lacking. I don't even claim that they are = necessarily within the jurisdiction of the IETF, but they seemed to me to be well = within the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be = to find out what if anything needs to be done. It's always O.K. to find = out that nothing needs to be done -- perhaps even preferable. That was not at = all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote:=20 Dear Charles,=20 Thank you very much for your kind initiative for this work.=20 However, when I examine the charter that you were describing below, many = questions come to my mind.=20 Could you please help me to understand better on those considerations? = Please see inline below..=20 Thanks in advance.=20 Tricci=20 "Charles E. Perkins" = =20 Sent by: fmc-bounces@ietf.org=20 06/07/2012 10:29 PM=20 To "fmc@ietf.org" = =20 cc =09 Subject [fmc] FMC BoF at IETF 84? =20 =09 Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for = "fixed-mobile convergence" and to identify the initial steps along the = way towards the goals. Here is some text that might be used to make the = BoF request... Fixed-mobile convergence, as commonly interpreted, should provide = satisfactory user experience when the user migrates between wide-area = cellular networks and WLAN networks having limited range. The latter = are generally anchored on a fixed residential or enterprise gateway. = Our understanding of the problem statement and requirements has been = derived from documents published by the BBF and the ITU [citations = here]. Work is needed in the IETF to meet the requirements.=20 Tricci > May I ask, has BBF or ITU sent any specific request on this = work? If so, what are the specific problems that BBF has asked IETF, = more specifically, this BOF, to address? The reason that I asked this = question is that, I work closely with my colleagues in BBF on many of = those FMC issues. I would not like to see the duplicate work done in = different SDOs and come up with different solutions? =20 While there are many possible solutions, all of them will require some = agreement on how to identify the wireless end device (e.g., handset). =20 Tricci > May I ask, why would be the IETF's role to define the wireless = end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, = WiMAX and WFA? Especially, I am sure that they already have their own = definitions. So, what are the wireless end device that you have in mind = that needs to be defined by IETF? Could you please clarify? =20 Other requirements might include session continuity, policy = distribution, QoS management, and application mobility.=20 Tricci > As the active contributors to 3GPP and BBF work, all of these = subjects have been going on in both of these SDO, could you please = clarify what are the specific aspects that are not covered by the other = SDOs that need additional work to be done in IETF? =20 The initial set of goals should be strictly limited, and future = broadening is to depend both on the solutions adopted for the initial = goal set as well as the evolving needs of the user and network operator = communities.=20 Tricci > Sorry for asking so many questions? I have the selfish reason = to ensure that no duplicate work is done between IETF and the other SDOs = that I am actively participated. Thanks again in advance to help me to = understand your proposal for this BOF. =20 --=20 Regards, Charlie P. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc = =20 -------------------------------------------------------- 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. =20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --=20 Regards, Charlie P. ------_=_NextPart_001_01CD454D.FE381DC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Actually, this is a good discussion. I agree that gathering = requirements for FMC is a good exercise, as long as it is done from an = IETF standpoint. Otherwise, we duplicate BBF work.

It is also worth to identify existing IETF solutions , or ongoing = work, that might meet these requirements. Then gap analysis should be = done: what are the specific FMC issues that cannot be solved with = current protocols, or using other SDOs mechanisms? That’s a fair = question which should be answered before going into a BoF, but the = problem is that =A0early stage drafts do not answer above question. In = other words, =A0more work is needed before going into a BoF. It does not = mean we should stop discussing; clearly, ongoing work in IETF/FMC is = worth the effort but we still have not shown the interest for a = dedicated FMC IETF WG… In my = opinion…

 

BR,

Pierrick

 

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part = de Charles E. Perkins
Envoy=E9 : vendredi 8 juin 2012 = 08:54
=C0 : tso@zteusa.com
Cc : = fmc@ietf.org; david.i.allan@ericsson.com
Objet : Re: = [fmc] FMC BoF at IETF 84?

 


Hello = Tricci,

The discussion at IETF 83 and on the mailing list had, I = thought, indicated that
there is work to do.  I can certainly = imagine that the IETF should have something
to say about managing = device identity upon movement to a new point of
attachment when NATs = are involved.  From the BBF and ITU documents, it
seemed quite = reasonable to initiate some effort.  I gather you do not see = the
need, or else see that it is already being met.  If you'd = like to supply some
pointers to relevant documents that would be = interesting to me.

Anyway I am not the liaison to BBF or ITU, and = in my experience at the IETF
people don't have to wait to be told = what needs to be done.  Of course if
some other SDO does tell = the IETF what needs to be done, it can be easier
to get = started.

I wonder if anyone has tried to quantify the number of = times that other
SDOs (not IETF) have duplicated effort.  I'm = personally familiar with one or
two cases.  And, to some extent, = duplication can be in the eyes of the
beholder.  For instance, = why mess around with having NAIs or IMSIs when
we already have = FQDNs??  [just kidding, no worries, I do understand]

Please = also note that "identify" is not at all the same as = "define".

Regarding the other points -- if you'd like = to supply pointers to the relevant
work in other SDOs for = "session continuity, policy distribution, QoS
management, and application = mobility"  I'd be interested to take a = look.
Somehow, in discussions with other interested people, I had the = impression
that these things were lacking.  I don't even claim = that they are necessarily
within the jurisdiction of the IETF, but = they seemed to me to be well within
the scope of useful discussion at = a BoF.

And, finally, as always please note that the point of the = BoF would be to
find out what if anything needs to be done.  = It's always O.K. to find out that
nothing needs to be done -- perhaps = even preferable.  That was not at all
the sense I got from = previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 = PM, tso@zteusa.com wrote: =

Dear Charles, =

Thank you very = much for your kind initiative for this work.

However, when I = examine the charter that you were describing below, many questions come = to my mind.

Could you please = help me to understand better on those considerations?  Please see = inline below..

Thanks in advance. =
Tricci =



"Charles = E. Perkins" <charliep@computer.org> =
Sent by: fmc-bounces@ietf.org =

06/07/2012 = 10:29 PM

To=

"fmc@ietf.org" <fmc@ietf.org> =

cc=

Subject=

[fmc] FMC BoF = at IETF 84?

 





Hello = folks,

It's time to request a BoF during IETF 84 on the = subject of FMC.

A suitable BoF agenda would be to agree = on an effective definition for "fixed-mobile convergence" and = to identify the initial steps along the way towards the goals. Here is = some text that might be used to make the BoF = request...

Fixed-mobile convergence, as commonly = interpreted, should provide satisfactory user experience when the user = migrates between wide-area cellular networks and WLAN networks having = limited range.  The latter are generally anchored on a fixed = residential or enterprise gateway.  Our understanding of the = problem statement and requirements has been derived from documents published by the BBF = and the ITU [citations here]. = Work is needed in the IETF to meet = the requirements.

Tricci > May I = ask, has BBF or ITU sent any specific request on this work?  If so, = what are the specific problems that BBF has asked IETF, more = specifically, this BOF, to address?   The reason that I asked this = question is that, I work closely with my colleagues in BBF on many of = those FMC issues.  I would not like to see the duplicate work done = in different SDOs and come up with different solutions? =  

 While there are many possible solutions, all of = them will require some agreement on how to identify the wireless end = device (e.g., handset).  

Tricci > May I = ask, why would be the IETF's role to define the wireless end device? =  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and = WFA?  Especially, I am sure that they already have their own = definitions.  So, what are the wireless end device that you have in = mind that needs to be defined by IETF?  Could you please clarify? =  

Other requirements might include session = continuity, policy distribution, QoS management, and application = mobility.

Tricci > As the = active contributors to 3GPP and BBF work, all of these subjects have = been going on in both of these SDO, could you please clarify what are = the specific aspects that are not covered by the other SDOs that need = additional work to be done in IETF?  

The initial set = of goals should be strictly limited, and future broadening is to depend = both on the solutions adopted for the initial goal set as well as the = evolving needs of the user and network operator communities. =

Tricci > Sorry = for asking so many questions?  I have the selfish reason to ensure = that no duplicate work is done between IETF and the other SDOs that I am = actively participated.  Thanks again in advance to help me to = understand your proposal for this BOF.  

-- =
Regards,
Charlie P.

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


----------------------------=
----------------------------
ZTE Information&nb=
sp;Security Notice: The information contained in=
 this mail (and any attachment transmitted&=
nbsp;herewith) is privileged and confidential an=
d is intended for the exclusive use of=
 the addressee(s).  If you are not&nbs=
p;an intended recipient, any disclosure, reprodu=
ction, distribution or other dissemination or&nb=
sp;use of the information contained is stri=
ctly prohibited.  If you have received =
;this mail in error, please delete it =
and notify us immediately.
 =
;




_______________________=
________________________
fmc mailing =
list
fmc@ietf.org
https://www.ietf.org/m=
ailman/listinfo/fmc




-- =

Regards,
Charlie =
P.
------_=_NextPart_001_01CD454D.FE381DC2-- From charliep@computer.org Fri Jun 8 01:11: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 0842B21F8712 for ; Fri, 8 Jun 2012 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGJ+iBN7fhTL for ; Fri, 8 Jun 2012 01:11:02 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58121F8710 for ; Fri, 8 Jun 2012 01:11:00 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ScuHZ-0007nw-Ax; Fri, 08 Jun 2012 04:10:57 -0400 Message-ID: <4FD1B389.2070708@computer.org> Date: Fri, 08 Jun 2012 01:10:49 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tso@zteusa.com References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060200000204070801010500" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8675bf027951ebb4999f6dac8368f4c528350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: david.i.allan@ericsson.com, "fmc@ietf.org" Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 08:11:06 -0000 This is a multi-part message in MIME format. --------------060200000204070801010500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Tricci, I don't exactly know how better to answer your questions, but I'll try again with fewer words. Perhaps the extra verbiage gets in the way. On 6/8/2012 12:28 AM, tso@zteusa.com wrote: > > I thought that I was very clear for asking what needs to be done based > on your descriptions for the BOF? device identity, session continuity, policy distribution, QoS management, and application mobility But please keep in mind that other people may have other ideas. This is simply a list resulting from my understanding of the problem as formulated by BBF and ITU. > Somehow, my questions are bounced back to me? No... (?) You asked me what needed to be done, I mentioned the above, and asked if you could supply pointers to related (or duplicative) work in other SDOs. That's quite different than simply reflecting back your questions. > > May be it is my lack of understanding of IETF's culture? I would > think that, when a BOF is formed, there is strong indication that some > work must need and worth to be investigated in IETF. But, based on > your descriptions, I can't derive what they are? "must" is too strong. If I could say "must", we would form a working group, not a BoF. For the last sentence, please see above. > > Unfortunately, at this point, my questions are still remained. :) I hope this helps. Regards, Charlie P. --------------060200000204070801010500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Tricci,

I don't exactly know how better to answer your questions, but I'll try again
with fewer words.  Perhaps the extra verbiage gets in the way.

On 6/8/2012 12:28 AM, tso@zteusa.com wrote:

I thought that I was very clear for asking what needs to be done based on your descriptions for the BOF?

device identity, session continuity, policy distribution,
QoS management, and application mobility

But please keep in mind that other people may have other ideas.  This
is simply a list resulting from my understanding of the problem as
formulated by BBF and ITU.

Somehow, my questions are bounced back to me?

No... (?) You asked me what needed to be done, I mentioned the above, and asked if you could supply pointers to related (or duplicative) work in other SDOs.  That's quite different than simply reflecting back your questions.



May be it is my lack of understanding of IETF's culture?  I would think that, when a BOF is formed, there is strong indication that some work must need and worth to be investigated in IETF.  But, based on your descriptions, I can't derive what they are?


"must" is too strong.  If I could say "must", we would form a working group, not a BoF.
For the last sentence, please see above.



Unfortunately, at this point, my questions are still remained. :)

I hope this helps.

Regards,
Charlie P.


--------------060200000204070801010500-- From laurent.thiebaut@alcatel-lucent.com Fri Jun 8 01:13: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 8528F21F870F for ; Fri, 8 Jun 2012 01:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ee-SXp7pYU for ; Fri, 8 Jun 2012 01:13:10 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAB221F8714 for ; Fri, 8 Jun 2012 01:13:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5889YkM002436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Jun 2012 10:12:56 +0200 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.37]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 8 Jun 2012 10:12:21 +0200 From: "THIEBAUT, LAURENT (LAURENT)" To: "pierrick.seite@orange.com" , "charliep@computer.org" , "tso@zteusa.com" Date: Fri, 8 Jun 2012 10:12:20 +0200 Thread-Topic: [fmc] FMC BoF at IETF 84? Thread-Index: Ac1FQ6XTjJkAmvHARRG5OcIAeLkMfAABQkLgAAFphSA= Message-ID: <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F0133E62960FFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "fmc@ietf.org" , "david.i.allan@ericsson.com" Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 08:13:15 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F0133E62960FFRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all I support Pierrick Best regards Laurent ALCATEL-LUCENT ________________________________ De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de pierr= ick.seite@orange.com Envoy=E9 : vendredi 8 juin 2012 10:09 =C0 : charliep@computer.org; tso@zteusa.com Cc : david.i.allan@ericsson.com; fmc@ietf.org Objet : Re: [fmc] FMC BoF at IETF 84? Hi, Actually, this is a good discussion. I agree that gathering requirements fo= r FMC is a good exercise, as long as it is done from an IETF standpoint. Ot= herwise, we duplicate BBF work. It is also worth to identify existing IETF solutions , or ongoing work, tha= t might meet these requirements. Then gap analysis should be done: what are= the specific FMC issues that cannot be solved with current protocols, or u= sing other SDOs mechanisms? That's a fair question which should be answered= before going into a BoF, but the problem is that early stage drafts do no= t answer above question. In other words, more work is needed before going = into a BoF. It does not mean we should stop discussing; clearly, ongoing wo= rk in IETF/FMC is worth the effort but we still have not shown the interest= for a dedicated FMC IETF WG... In my opinion... BR, Pierrick De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Charl= es E. Perkins Envoy=E9 : vendredi 8 juin 2012 08:54 =C0 : tso@zteusa.com Cc : fmc@ietf.org; david.i.allan@ericsson.com Objet : Re: [fmc] FMC BoF at IETF 84? Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated= that there is work to do. I can certainly imagine that the IETF should have som= ething to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see t= he need, or else see that it is already being met. If you'd like to supply so= me pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one o= r two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relev= ant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessari= ly within the jurisdiction of the IETF, but they seemed to me to be well withi= n the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out t= hat nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many qu= estions come to my mind. Could you please help me to understand better on those considerations? Ple= ase see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fix= ed-mobile convergence" and to identify the initial steps along the way towa= rds the goals. Here is some text that might be used to make the BoF request= ... Fixed-mobile convergence, as commonly interpreted, should provide satisfact= ory user experience when the user migrates between wide-area cellular netwo= rks and WLAN networks having limited range. The latter are generally ancho= red on a fixed residential or enterprise gateway. Our understanding of the= problem statement and requirements has been derived from documents publish= ed by the BBF and the ITU [citations here]. Work is needed in the IETF to m= eet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? = If so, what are the specific problems that BBF has asked IETF, more specif= ically, this BOF, to address? The reason that I asked this question is th= at, I work closely with my colleagues in BBF on many of those FMC issues. = I would not like to see the duplicate work done in different SDOs and come = up with different solutions? While there are many possible solutions, all of them will require some agr= eement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end= device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX an= d WFA? Especially, I am sure that they already have their own definitions.= So, what are the wireless end device that you have in mind that needs to = be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, Q= oS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subj= ects have been going on in both of these SDO, could you please clarify what= are the specific aspects that are not covered by the other SDOs that need = additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening = is to depend both on the solutions adopted for the initial goal set as well= as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to = ensure that no duplicate work is done between IETF and the other SDOs that = I am actively participated. Thanks again in advance to help me to understa= nd your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. --_000_170E8FCC2134BD42B539B47798ABF8F0133E62960FFRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de pierrick.seite@orange.c= om
Envoy=E9 : vendredi 8 j= uin 2012 10:09
=C0 : charliep@computer= .org; tso@zteusa.com
Cc : david.i.allan@ericsson.com; fmc@ietf.org
Objet : Re: [fmc] FMC B= oF at IETF 84?=

=  

Hi,=

 

Actually, this= is a good discussion. I agree that gathering requirements for FMC is a good exercise, as long as it is done from an IETF standpoint. Otherwise, we duplicate BBF work.

It is also wor= th to identify existing IETF solutions , or ongoing work, that might meet these requirements. Then gap analysis should be done: what are the specific FMC issues that cannot be solved with current protocols, or using other SDOs mechanisms? That’s a fair question which should be answered before go= ing into a BoF, but the problem is that  early stage drafts do not answer above question. In other words,  more work is needed before going into a BoF= . It does not mean we should stop discussing; clearly, ongoing work in IETF/FMC = is worth the effort but we still have not shown the interest for a dedicated F= MC IETF WG… In my opinion…

 

BR,=

Pierrick<= /o:p>

 

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Charles E. Perkins
Envoy=E9 : vendredi 8 j= uin 2012 08:54
=C0 : tso@zteusa.com Cc : fmc@ietf.org; david.i.allan@ericsson.com
Objet : Re: [fmc] FMC B= oF at IETF 84?

=  

=
Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated that
there is work to do.  I can certainly imagine that the IETF should hav= e something
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.  From the BBF and ITU documents, it=
seemed quite reasonable to initiate some effort.  I gather you do not = see the
need, or else see that it is already being met.  If you'd like to supp= ly some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF=
people don't have to wait to be told what needs to be done.  Of course= if
some other SDO does tell the IETF what needs to be done, it can be easier to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.  I'm personally familiar with = one or
two cases.  And, to some extent, duplication can be in the eyes of the=
beholder.  For instance, why mess around with having NAIs or IMSIs whe= n
we already have FQDNs??  [just kidding, no worries, I do understand]
Please also note that "identify" is not at all the same as "define".

Regarding the other points -- if you'd like to supply pointers to the relev= ant
work in other SDOs for "session continuity, policy distribution, QoS
management, and application mobility"  I'd be interested t= o take a look.
Somehow, in discussions with other interested people, I had the impression<= br> that these things were lacking.  I don't even claim that they are necessarily
within the jurisdiction of the IETF, but they seemed to me to be well withi= n
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done.  It's always O.K. to find = out that
nothing needs to be done -- perhaps even preferable.  That was not at = all
the sense I got from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 PM, tso@zteusa.com = wrote:

= Dear Charles,

Thank you very much for your kind initiative for this work.

However, when I examine the charter that you were describing below, many questions c= ome to my mind.

Could you please help me to understand better on those considerations?  Plea= se see inline below..

Thanks in advance.
Tricci


"Charle= s E. Perkins" <charliep@compu= ter.org> =
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM

To

"fmc@ietf.org" <fmc@ietf.org> =

cc

 

Subject

[fmc] FMC BoF at IETF 84?

 

 





Hello folks,

It's time to request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps alon= g the way towards the goals. Here is some text that might be used to make the= BoF request...

Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and W= LAN networks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  Our understanding of the pro= blem statement and requirements has been de= rived from documents published by the BBF and the ITU [citations here]. <= /span>Work is needed in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any specific request on this work? &nbs= p;If so, what are the specific problems that BBF has asked IETF, more specifical= ly, this BOF, to address?   The reason that I asked this question is that,= I work closely with my colleagues in BBF on many of those FMC issues.  I= would not like to see the duplicate work done in different SDOs and come up with different solutions?  

 While there are many possible solutions, all of them will require some agreement = on how to identify the wireless end device (e.g., handset).  

Tricci > May I ask, why would be the IETF's role to define the wireless end dev= ice?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WF= A?  Especially, I am sure that they already have their own definitions.  So, what are the wireless end device that you have in mind that needs= to be defined by IETF?  Could you please clarify?  
Ot= her requirements might include session continuity, policy distribution, QoS management, and application mobility.

Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are = the specific aspects that are not covered by the other SDOs that need additiona= l work to be done in IETF?  

Th= e initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolv= ing needs of the user and network operator communities.

Tricci > Sorry for asking so many questions?  I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that = I am actively participated.  Thanks again in advance to help me to understa= nd your proposal for this BOF.  =

--
Regards,
Charlie P.

____________________________________________= ___
fmc mailing list
fmc@ietf.org=
https://www.= ietf.org/mailman/listinfo/fmc

--------------------------------------------------------<=
/o:p>
ZTE Information Security Notice: The information=
 contained in this mail (and any attachm=
ent transmitted herewith) is privileged and c=
onfidential and is intended for the exclusive=
 use of the addressee(s).  If you a=
re not an intended recipient, any disclosure,=
 reproduction, distribution or other dissemination=
 or use of the information contained is&=
nbsp;strictly prohibited.  If you have receiv=
ed this mail in error, please delete it&=
nbsp;and notify us immediately.
 











_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mai=
lman/listinfo/fmc











-- 
Regards,
Charlie P.
--_000_170E8FCC2134BD42B539B47798ABF8F0133E62960FFRMRSSXCHMBSA_-- From John.Kaippallimalil@huawei.com Fri Jun 8 07:58: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 7CBC521F86FD for ; Fri, 8 Jun 2012 07:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YArP+aHGYdiq for ; Fri, 8 Jun 2012 07:58:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D12A21F866E for ; Fri, 8 Jun 2012 07:58:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGZ13139; Fri, 08 Jun 2012 10:58:08 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 8 Jun 2012 07:56:07 -0700 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.75]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 8 Jun 2012 07:56:08 -0700 From: John Kaippallimalil To: "THIEBAUT, LAURENT (LAURENT)" , "pierrick.seite@orange.com" , "charliep@computer.org" , "tso@zteusa.com" Thread-Topic: [fmc] FMC BoF at IETF 84? Thread-Index: AQHNRTfBnNxRs62zOEC/6dArWgsVY5bwYsAAgAAPHQCAABUFAIAAAOAA///5SbA= Date: Fri, 8 Jun 2012 14:56:08 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA11705E5E4@dfweml511-mbs.china.huawei.com> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.220] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA11705E5E4dfweml511mbschina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "david.i.allan@ericsson.com" , "fmc@ietf.org" Subject: Re: [fmc] FMC BoF at IETF 84? 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, 08 Jun 2012 14:58:13 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA11705E5E4dfweml511mbschina_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree with Pierrick that is useful to look from an IETF viewpoint. The fmc requirements draft http://www.ietf.org/id/draft-schott-fmc-requirem= ents-00.txt is a good place to start. -John From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of THIEB= AUT, LAURENT (LAURENT) Sent: Friday, June 08, 2012 3:12 AM To: pierrick.seite@orange.com; charliep@computer.org; tso@zteusa.com Cc: fmc@ietf.org; david.i.allan@ericsson.com Subject: Re: [fmc] FMC BoF at IETF 84? Hello all I support Pierrick Best regards Laurent ALCATEL-LUCENT ________________________________ De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de pierr= ick.seite@orange.com Envoy=E9 : vendredi 8 juin 2012 10:09 =C0 : charliep@computer.org; tso@zteusa.com Cc : david.i.allan@ericsson.com; fmc@ietf.org Objet : Re: [fmc] FMC BoF at IETF 84? Hi, Actually, this is a good discussion. I agree that gathering requirements fo= r FMC is a good exercise, as long as it is done from an IETF standpoint. Ot= herwise, we duplicate BBF work. It is also worth to identify existing IETF solutions , or ongoing work, tha= t might meet these requirements. Then gap analysis should be done: what are= the specific FMC issues that cannot be solved with current protocols, or u= sing other SDOs mechanisms? That's a fair question which should be answered= before going into a BoF, but the problem is that early stage drafts do no= t answer above question. In other words, more work is needed before going = into a BoF. It does not mean we should stop discussing; clearly, ongoing wo= rk in IETF/FMC is worth the effort but we still have not shown the interest= for a dedicated FMC IETF WG... In my opinion... BR, Pierrick De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Charl= es E. Perkins Envoy=E9 : vendredi 8 juin 2012 08:54 =C0 : tso@zteusa.com Cc : fmc@ietf.org; david.i.allan@ericsson.com Objet : Re: [fmc] FMC BoF at IETF 84? Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated= that there is work to do. I can certainly imagine that the IETF should have som= ething to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see t= he need, or else see that it is already being met. If you'd like to supply so= me pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one o= r two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relev= ant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessari= ly within the jurisdiction of the IETF, but they seemed to me to be well withi= n the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out t= hat nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many qu= estions come to my mind. Could you please help me to understand better on those considerations? Ple= ase see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fix= ed-mobile convergence" and to identify the initial steps along the way towa= rds the goals. Here is some text that might be used to make the BoF request= ... Fixed-mobile convergence, as commonly interpreted, should provide satisfact= ory user experience when the user migrates between wide-area cellular netwo= rks and WLAN networks having limited range. The latter are generally ancho= red on a fixed residential or enterprise gateway. Our understanding of the= problem statement and requirements has been derived from documents publish= ed by the BBF and the ITU [citations here]. Work is needed in the IETF to m= eet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? = If so, what are the specific problems that BBF has asked IETF, more specif= ically, this BOF, to address? The reason that I asked this question is th= at, I work closely with my colleagues in BBF on many of those FMC issues. = I would not like to see the duplicate work done in different SDOs and come = up with different solutions? While there are many possible solutions, all of them will require some agr= eement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end= device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX an= d WFA? Especially, I am sure that they already have their own definitions.= So, what are the wireless end device that you have in mind that needs to = be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, Q= oS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subj= ects have been going on in both of these SDO, could you please clarify what= are the specific aspects that are not covered by the other SDOs that need = additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening = is to depend both on the solutions adopted for the initial goal set as well= as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to = ensure that no duplicate work is done between IETF and the other SDOs that = I am actively participated. Thanks again in advance to help me to understa= nd your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. --_000_6561EABF52675C45BCDACA1B4D7AA11705E5E4dfweml511mbschina_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree with Pierrick that = is useful to look from an IETF viewpoint.

The fmc requirements draf= t htt= p://www.ietf.org/id/draft-schott-fmc-requirements-00.txt is a good plac= e to start.

 <= /p>

-John

 <= /p>

 <= /p>

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ] On Behalf Of THIEBAUT, LAURENT (LAURENT)
Sent: Friday, June 08, 2012 3:12 AM
To: pierrick.seite@orange.com; charliep@computer.org; tso@zteusa.com=
Cc: fmc@ietf.org; david.i.allan@ericsson.com
Subject: Re: [fmc] FMC BoF at IETF 84?

 

 =

 =

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

De = : fmc-bounces@ietf.org = [mailto:fmc-bounces@ietf.org] De la part de pierrick.seite@orange.com
Envoy=E9 : vendredi 8 juin 2012 10:09
=C0 : charliep@computer.org; tso@zteusa.com
Cc : david.i.allan@ericsson.com; fmc@ietf.org
Objet : Re: [fmc] FMC BoF at IETF 84?

 

Hi,

 

Actually, this is a good = discussion. I agree that gathering requirements for FMC is a good exercise,= as long as it is done from an IETF standpoint. Otherwise, we duplicate BBF work.<= /o:p>

It is also worth to ident= ify existing IETF solutions , or ongoing work, that might meet these requir= ements. Then gap analysis should be done: what are the specific FMC issues that cannot be solved with current protocols, or using other SD= Os mechanisms? That’s a fair question which should be answered before= going into a BoF, but the problem is that  early stage drafts do not = answer above question. In other words,  more work is needed before going into a BoF. It does not mean we should stop di= scussing; clearly, ongoing work in IETF/FMC is worth the effort but we stil= l have not shown the interest for a dedicated FMC IETF WG… In my opin= ion…

 <= /p>

BR,

Pierrick

 <= /p>

De = : fmc-bounces@ietf.org = [mailto:fmc-bounces@ietf.org] De la part de Charles E. Perkins
Envoy=E9 : vendredi 8 juin 2012 08:54
=C0 : tso@zteusa.com
Cc : fmc@ietf.org; david.i.allan@ericsson.com
Objet : Re: [fmc] FMC BoF at IETF 84?

 


Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated= that
there is work to do.  I can certainly imagine that the IETF should hav= e something
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.  From the BBF and ITU documents, it=
seemed quite reasonable to initiate some effort.  I gather you do not = see the
need, or else see that it is already being met.  If you'd like to supp= ly some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF=
people don't have to wait to be told what needs to be done.  Of course= if
some other SDO does tell the IETF what needs to be done, it can be easier to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.  I'm personally familiar with = one or
two cases.  And, to some extent, duplication can be in the eyes of the=
beholder.  For instance, why mess around with having NAIs or IMSIs whe= n
we already have FQDNs??  [just kidding, no worries, I do understand]
Please also note that "identify" is not at all the same as "= define".

Regarding the other points -- if you'd like to supply pointers to the relev= ant
work in other SDOs for "session continuity, policy distribution, QoS
management, and app= lication mobility"  I'd be interested to take a look.
Somehow, in discussions with other interested people, I had the impression<= br> that these things were lacking.  I don't even claim that they are nece= ssarily
within the jurisdiction of the IETF, but they seemed to me to be well withi= n
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done.  It's always O.K. to find = out that
nothing needs to be done -- perhaps even preferable.  That was not at = all
the sense I got from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 PM, tso@zteusa.com = wrote:

Dear= Charles,

Thank you very much for your kind initiative for th= is work.

However, when I examine the charter that you were d= escribing below, many questions come to my mind.

Could you please help me to understand better on th= ose considerations?  Please see inline below..

Thanks in advance.
Tricci

"Charles E. Perkins" <charliep@computer.org><= /span>
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM

To

"fmc@= ietf.org" <fmc@ietf.org> =

cc

 

Subject

[fmc] FMC BoF at IETF 84?

 

 

 

<= /p>




Hello folks,=

It's time to reques= t a BoF during IETF 84 on the subject of FMC.

A suitable BoF agen= da would be to agree on an effective definition for "fixed-mobile conv= ergence" and to identify the initial steps along the way towards the g= oals. Here is some text that might be used to make the BoF request...

Fixed-mobile conver= gence, as commonly interpreted, should provide satisfactory user experience= when the user migrates between wide-area cellular networks and WLAN networ= ks having limited range.  The latter are generally anchored on a fixed residential or enterprise gateway.  = ;Our understanding of the problem statement and requirements has = been derived from documents published by the BBF and the ITU [citations her= e]. Work is n= eeded in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any spec= ific request on this work?  If so, what are the specific problems that= BBF has asked IETF, more specifically, this BOF, to address?   The reason that I asked this question is that, I work closely with my coll= eagues in BBF on many of those FMC issues.  I would not like to see th= e duplicate work done in different SDOs and come up with different solution= s?  

 While there a= re many possible solutions, all of them will require some agreement on how = to identify the wireless end device (e.g., handset).  

Tricci > May I ask, why would be the IETF's role= to define the wireless end device?  Shouldn't this be the responsibil= ity of the 3GPP, 3GPP2, WiMAX and WFA?  Especially, I am sure that they already have their own definitions.  So, what are the wireless e= nd device that you have in mind that needs to be defined by IETF?  Cou= ld you please clarify?  

Other requirements = might include session continuity, policy distribution, QoS management, and = application mobility.

Tricci > As the active contributors to 3GPP and = BBF work, all of these subjects have been going on in both of these SDO, co= uld you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF= ?  

The initial set of = goals should be strictly limited, and future broadening is to depend both o= n the solutions adopted for the initial goal set as well as the evolving ne= eds of the user and network operator communities.

Tricci > Sorry for asking so many questions? &nb= sp;I have the selfish reason to ensure that no duplicate work is done betwe= en IETF and the other SDOs that I am actively participated.  Thanks again in advance to help me to understand your proposal for this BOF. &nbs= p;
--
Regards,
Charlie P.

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listi= nfo/fmc

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

 

_______________________________________________=

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

 

-- 
Regards,
Charlie P.
--_000_6561EABF52675C45BCDACA1B4D7AA11705E5E4dfweml511mbschina_-- From shares@ndzh.com Mon Jun 11 16:39:18 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3111E8087 for ; Mon, 11 Jun 2012 16:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-JxqMufHuEF for ; Mon, 11 Jun 2012 16:39:08 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.194]) by ietfa.amsl.com (Postfix) with ESMTP id AA84711E80AD for ; Mon, 11 Jun 2012 16:39:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.250.33.110; Received: from SKH2012HPLT (unverified [166.250.33.110]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3380383-1945496 for multiple; Mon, 11 Jun 2012 19:38:49 -0400 From: "Susan Hares" To: References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> In-Reply-To: Date: Mon, 11 Jun 2012 19:38:46 -0400 Message-ID: <007001cd482b$58ef3e00$0acdba00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01CD4809.D1E65090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrLI+eO3qjSWqeVNug/xrsF4K7bgFWajHSAcSsIOUA6qLwVpaZr4gg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "Charles E. Perkins" , xueli@huawei.com, david.i.allan@ericsson.com, fmc@ietf.org, 'Behcet Sarikaya' Subject: Re: [fmc] Spam:*******, Re: FMC BoF at IETF 84? 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, 11 Jun 2012 23:39:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0071_01CD4809.D1E65090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tricci: Perhaps I'm just too practical. I really see a clear problem and a set of choices as R.Schott has described in his HOST_ID portion of his document (http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt). The context of this problem is a circumstance where the LTE offloads to the WiFi which is connected to the Wired world, and has a NAT (v4/v6) translation. Will the LTE to WiFi offload happen in 2013? I believe as 802.11ac with 1G+ deploys in 2012-2013, the offload from LTE 802.11 WiFi/Wired world will increase. The 802.11ai seems to admit there will be fast handoffs between devices as people walk between sites. Based on 802.11ai discussions, it seems people feel this validation of IDs (using 802.1x, EAP, DCHP and AAA servers) will be the slow part of the system. Most of these protocols are under the IETF's control. The LTE to WiFi offload (as you indicated) arises in Big cities where the LTE has potential 1000s (in the football stadium case). R. Schott (http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt) gives good description of the UE Identifier need that we discussed at the IETF-83 side-bar meeting. The v4/v6 NAT case seems to be something that you and everyone else agreed was a problem. This problem seems to be driven by v4 NATs in the WiFi off load of LTE. Schott further suggests that: "The HOST_ID, introduced in [I-D.ietf-intarea-nat-reveal-analysis], jointly with the external IP address are necessary to uniquely identify the traffic of a given visiting UE. An implementation example would be the use of port sets as HOST_ID." He further states: o All traffic MUST be identified (including TCP, UDP and ICMP) o The UE SHOULD NOT be trusted to inject its own HOST_ID o The CPE SHOULD inject the HOST_ID o The CPE SHOULD strip any existing HOST_ID o The CPE and the service node MUST support at least one common method to convey HOST_ID. The problem is when I read the solutions suggested in ietf-intarea-nat-reveal-analysis, I see different pros/cons to each. For example, The implementation of Port sets won't scale to 1000s that might rotate by a LTE/WiFi exchange near a sports stadium. Charlie's suggested some other pros/cons. When I look at the pros/cons ietf-intarea-nat-reveal-analysis, I wonder if we should change the paradigm of the solution to get a better answer. Noting that all the solutions for mobility management already require some sort of identity management, it seems likely that we could borrow some of that work done as part of existing mobility solutions. Other SDOs ---------- In May 2012, BBF created a WT-291 that is setting these requirements. Behcet is the editor of that draft so I will ask him to comment on the status and content of WT-291. Behcet started this investigation in IETF because BBF work prior to WG-291 indicated that the IETF to specify the UE identifier solution. Goal -------- The goal here is to find an interoperable solution we agree works. Schott correctly points out WG/Non-WG is not concern. The concern is to come to a single solution or a set of solutions that work. If you think ports scales will scale to 1000s as a crowd pickups up its cell phones during or after a football/soccer game - let me know why and how. I want happy customers for the WiFi/LTE offload. What I know will make customers unhappy is when they are handle by one carrier and get dropped as they stroll between LTE and WiFi offload points. They will even want to keep up their videos and web browsing. So.. Charlie's experience leads him to suggest the impact of mobility, policy and many other things on the IETF choices. My experience leads me to suggest an interoperable solution in 2012/2013 will help allow multi-vendor support for WiFi/LTE offload. It seems like chatting about interoperable solutions in a side-bar meeting might create a set of clear choices. Tricci - has this been helpful and practical? Sue Hares shares@ndzh.com Susan.Hares@Huawei.com From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com Sent: Friday, June 08, 2012 3:29 AM To: Charles E. Perkins Cc: fmc@ietf.org; david.i.allan@ericsson.com Subject: Spam:*******, Re: [fmc] FMC BoF at IETF 84? Dear Charles, Sincerely thanks for your prompt responses. I would like to clarify that, I have not implied anything on one-way or the other that no work needs to be done in IETF. I thought that I was very clear for asking what needs to be done based on your descriptions for the BOF? Somehow, my questions are bounced back to me? May be it is my lack of understanding of IETF's culture? I would think that, when a BOF is formed, there is strong indication that some work must need and worth to be investigated in IETF. But, based on your descriptions, I can't derive what they are? Unfortunately, at this point, my questions are still remained. :) Thanks again for your timely response. Tricci "Charles E. Perkins" 06/07/2012 11:53 PM To tso@zteusa.com cc david.i.allan@ericsson.com, "fmc@ietf.org" Subject Re: [fmc] FMC BoF at IETF 84? Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated that there is work to do. I can certainly imagine that the IETF should have something to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see the need, or else see that it is already being met. If you'd like to supply some pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one or two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relevant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessarily within the jurisdiction of the IETF, but they seemed to me to be well within the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out that nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many questions come to my mind. Could you please help me to understand better on those considerations? Please see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fixed-mobile convergence" and to identify the initial steps along the way towards the goals. Here is some text that might be used to make the BoF request... Fixed-mobile convergence, as commonly interpreted, should provide satisfactory user experience when the user migrates between wide-area cellular networks and WLAN networks having limited range. The latter are generally anchored on a fixed residential or enterprise gateway. Our understanding of the problem statement and requirements has been derived from documents published by the BBF and the ITU [citations here]. Work is needed in the IETF to meet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? If so, what are the specific problems that BBF has asked IETF, more specifically, this BOF, to address? The reason that I asked this question is that, I work closely with my colleagues in BBF on many of those FMC issues. I would not like to see the duplicate work done in different SDOs and come up with different solutions? While there are many possible solutions, all of them will require some agreement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and WFA? Especially, I am sure that they already have their own definitions. So, what are the wireless end device that you have in mind that needs to be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, QoS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subjects have been going on in both of these SDO, could you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening is to depend both on the solutions adopted for the initial goal set as well as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to ensure that no duplicate work is done between IETF and the other SDOs that I am actively participated. Thanks again in advance to help me to understand your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. -------------------------------------------------------- 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. ------=_NextPart_000_0071_01CD4809.D1E65090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tricci:

 
Perhaps I’m just too practical. =

 
I really see a clear problem and a set of =
choices as R.Schott has described in his HOST_ID portion of his document =
(http=
://www.ietf.org/id/draft-schott-fmc-requirements-00.txt).
 
The context of this problem is a circumstance =
where the LTE offloads to the WiFi which is connected to the Wired =
world, and has a NAT (v4/v6) =
translation.
 
Will the LTE to WiFi offload happen in =
2013?
 
I believe as 802.11ac with 1G+ deploys in =
2012-2013, the offload from LTE 802.11 WiFi/Wired world will increase. =
The 802.11ai seems to admit there will be fast handoffs between devices =
as people walk between sites. Based on 802.11ai discussions, it seems =
people feel this  validation of IDs (using 802.1x, EAP, DCHP and =
AAA servers) will be the slow part of the system. Most of these =
protocols are under the IETF’s =
control.
 
The LTE to WiFi offload (as you indicated) =
arises in Big cities where the LTE has potential 1000s (in the football =
stadium case). 
 
 
R. Schott (http=
://www.ietf.org/id/draft-schott-fmc-requirements-00.txt)
gives good description of the UE Identifier need that we =
discussed at the IETF-83 side-bar meeting. The v4/v6 NAT case seems to =
be something that you and everyone else agreed was a problem. This =
problem seems to be driven by v4 NATs in the WiFi off load of =
LTE.
 
Schott further =
suggests that: 
 
“The HOST_ID, introduced in =
[I-D.ietf-intarea-nat-reveal-analysis], jointly with the external IP =
address are necessary to uniquely identify the traffic of a =
given
visiting UE. An =
implementation example would be the use of port sets as =
HOST_ID.”
 
He =
further states:
 
 
   o All =
traffic MUST be identified (including TCP, UDP and =
ICMP)
 
   o The =
UE SHOULD NOT be trusted to inject its own =
HOST_ID
 
   o The =
CPE SHOULD inject the HOST_ID
 
   o The =
CPE SHOULD strip any existing HOST_ID
 
   o The =
CPE and the service node MUST support at least one =
common
   method =
to convey HOST_ID.
 
The problem is when I read the solutions =
suggested in =
ietf-intarea-nat-reveal-analysis,
I see =
different pros/cons to each. For example, The implementation of Port =
sets won’t scale to 1000s that might rotate by a LTE/WiFi exchange =
near a sports stadium. Charlie’s suggested some other =
pros/cons.
 
When I look =
at the pros/cons ietf-intarea-nat-reveal-analysis, I wonder if we should =
change the paradigm of the solution to get a better answer. Noting that =
all the solutions for mobility management already require some sort of =
identity management, it seems likely that we could borrow some of that =
work done as part of existing mobility solutions. =

 
Other =
SDOs
----------
 
In May 2012, BBF created a WT-291 that is setting =
these requirements.  Behcet is the editor of that draft so I will =
ask him to comment on the status and content of WT-291.  Behcet =
started this investigation in IETF because BBF work prior to WG-291 =
indicated that the IETF to specify the UE identifier =
solution.
 
Goal
--------
The goal here is to find an interoperable solution =
we agree works. Schott correctly points out WG/Non-WG is not concern. =
The concern is to come to a single solution or a set of solutions that =
work. If you think ports scales will scale to 1000s as a crowd pickups =
up its cell phones during or after a football/soccer game – let me =
know why and how.  
 
I want happy customers for the WiFi/LTE offload. =
 What I know will make customers unhappy is when they are handle by =
one carrier and get dropped as they stroll between LTE and WiFi offload =
points.  They will even want to keep up their videos and web =
browsing. 
 
So.. Charlie’s experience leads him to suggest =
the impact of mobility, policy and many other things on the IETF =
choices. My experience leads me to suggest an interoperable solution in =
2012/2013 will help allow multi-vendor support for WiFi/LTE offload. =

 
It seems like chatting about interoperable solutions =
in a side-bar meeting might create a set of clear choices. =

 
Tricci - has this been helpful and practical?  =

 
 
Sue Hares
shares@ndzh.com
=

Susan.Hares@Huawei.com
 
 
From:=
 =
fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of =
tso@zteusa.com
Sent: Friday, June 08, 2012 3:29 =
AM
To: Charles E. Perkins
Cc: fmc@ietf.org; =
david.i.allan@ericsson.com
Subject: Spam:*******, Re: [fmc] =
FMC BoF at IETF 84?
 
Dear Charles, =


Sincerely thanks for your =
prompt responses.   

I would like to clarify that, =
I have not implied anything on one-way or the other that no work needs =
to be done in IETF. 

I thought that I was very =
clear for asking what needs to be done based on your descriptions for =
the BOF?  Somehow, my questions are bounced back to me? =


May be =
it is my lack of understanding of IETF's culture?  I would think =
that, when a BOF is formed, there is strong indication that some work =
must need and worth to be investigated in IETF.  But, based on your =
descriptions, I can't derive what they are? 

Unfortunately, at this point, =
my questions are still remained. :) 

Thanks again for your timely =
response. 
Tricci =




"Charles =
E. Perkins" <charliep@computer.org> =

06/07/2012 =
11:53 PM 
To=

tso@zteusa.com =

cc=

david.i.allan@ericsson.com=
, "fmc@ietf.org" <fmc@ietf.org> =

Subject=

Re: [fmc] FMC =
BoF at IETF 84?
 




Hello Tricci,

The =
discussion at IETF 83 and on the mailing list had, I thought, indicated =
that
there is work to do.  I can certainly imagine that the IETF =
should have something
to say about managing device identity upon =
movement to a new point of
attachment when NATs are involved. =
 From the BBF and ITU documents, it
seemed quite reasonable to =
initiate some effort.  I gather you do not see the
need, or else =
see that it is already being met.  If you'd like to supply =
some
pointers to relevant documents that would be interesting to =
me.

Anyway I am not the liaison to BBF or ITU, and in my =
experience at the IETF
people don't have to wait to be told what =
needs to be done.  Of course if
some other SDO does tell the =
IETF what needs to be done, it can be easier
to get started.

I =
wonder if anyone has tried to quantify the number of times that =
other
SDOs (not IETF) have duplicated effort.  I'm personally =
familiar with one or
two cases.  And, to some extent, =
duplication can be in the eyes of the
beholder.  For instance, =
why mess around with having NAIs or IMSIs when
we already have =
FQDNs??  [just kidding, no worries, I do understand]

Please =
also note that "identify" is not at all the same as =
"define".

Regarding the other points -- if you'd like =
to supply pointers to the relevant
work in other SDOs for =
"session continuity, policy distribution, QoS
management, and application =
mobility"  I'd be interested to take a =
look.
Somehow, in discussions with other interested people, I had the =
impression
that these things were lacking.  I don't even claim =
that they are necessarily
within the jurisdiction of the IETF, but =
they seemed to me to be well within
the scope of useful discussion at =
a BoF.

And, finally, as always please note that the point of the =
BoF would be to
find out what if anything needs to be done. =
 It's always O.K. to find out that
nothing needs to be done -- =
perhaps even preferable.  That was not at all
the sense I got =
from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 =
10:59 PM, tso@zteusa.com wrote: =

Dear =
Charles, 

Thank you very =
much for your kind initiative for this work. 

However, when =
I examine the charter that you were describing below, many questions =
come to my mind. 

Could you =
please help me to understand better on those considerations? =
 Please see inline below.. 

Thanks in =
advance. 
Tricci 


"Charles =
E. Perkins" <charliep@c=
omputer.org> 
Sent by: =
fmc-bounces@ie=
tf.org 
06/07/2012 =
10:29 PM 
 
To=

"fmc@ietf=
.org" <fmc@ietf.o=
rg> 
cc=

Subject=

[fmc] FMC BoF =
at IETF 84?
 





Hello =
folks,

It's time to request a BoF during IETF 84 on the =
subject of FMC.

A suitable BoF agenda would be to agree =
on an effective definition for "fixed-mobile convergence" and =
to identify the initial steps along the way towards the goals. Here is =
some text that might be used to make the BoF =
request...

Fixed-mobile convergence, as commonly =
interpreted, should provide satisfactory user experience when the user =
migrates between wide-area cellular networks and WLAN networks having =
limited range.  The latter are generally anchored on a fixed =
residential or enterprise gateway.  Our understanding of the =
problem statement and requirements has been =
derived from documents published by the BBF and the ITU [citations =
here]. =
Work is needed in the IETF to meet =
the requirements. 

Tricci > =
May I ask, has BBF or ITU sent any specific request on this work? =
 If so, what are the specific problems that BBF has asked IETF, =
more specifically, this BOF, to address?   The reason that I asked =
this question is that, I work closely with my colleagues in BBF on many =
of those FMC issues.  I would not like to see the duplicate work =
done in different SDOs and come up with different solutions? =
 

While =
there are many possible solutions, all of them will require some =
agreement on how to identify the wireless end device (e.g., handset). =
  

Tricci > =
May I ask, why would be the IETF's role to define the wireless end =
device?  Shouldn't this be the responsibility of the 3GPP, 3GPP2, =
WiMAX and WFA?  Especially, I am sure that they already have their =
own definitions.  So, what are the wireless end device that you =
have in mind that needs to be defined by IETF?  Could you please =
clarify?   

Other requirements might include session continuity, =
policy distribution, QoS management, and application =
mobility. 

Tricci > As =
the active contributors to 3GPP and BBF work, all of these subjects have =
been going on in both of these SDO, could you please clarify what are =
the specific aspects that are not covered by the other SDOs that need =
additional work to be done in IETF?   

The initial set of goals =
should be strictly limited, and future broadening is to depend both on =
the solutions adopted for the initial goal set as well as the evolving =
needs of the user and network operator communities. =


Tricci > =
Sorry for asking so many questions?  I have the selfish reason to =
ensure that no duplicate work is done between IETF and the other SDOs =
that I am actively participated.  Thanks again in advance to help =
me to understand your proposal for this BOF.  

-- =

Regards,
Charlie P.

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




_________________________=
______________________
fmc mailing list
fmc@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/fmc



-- 
Regards,
Charlie =
P. =

 
-------------------------=
-------------------------------
ZTE Information=
 Security Notice: The information contained =
;in this mail (and any attachment transmitt=
ed herewith) is privileged and confidential =
;and is intended for the exclusive use =
;of the addressee(s).  If you are not&=
nbsp;an intended recipient, any disclosure, repr=
oduction, distribution or other dissemination or=
 use of the information contained is s=
trictly prohibited.  If you have received&n=
bsp;this mail in error, please delete it&nb=
sp;and notify us immediately.
&n=
bsp;
------=_NextPart_000_0071_01CD4809.D1E65090-- From soohongp@gmail.com Tue Jun 12 00:42:26 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D983621F856C for ; Tue, 12 Jun 2012 00:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YzXwNPMSWLs for ; Tue, 12 Jun 2012 00:42:24 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B02D321F8549 for ; Tue, 12 Jun 2012 00:42:23 -0700 (PDT) Received: by bkty8 with SMTP id y8so4939044bkt.31 for ; Tue, 12 Jun 2012 00:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=neaiQ64Du/tLMneXGkGmcMbxu5qYO+WZumznaHMincM=; b=SFtWN5AzI7VVPz9MEESwiK/qyK55CT3k8tgowW1QgaCrzoFYJj8k2TdS1TQmG/9SzM a9aHVSw2Q+McG2cXfhkbG/Y3/5llbJq/UOATV7536VyKr5u1tgyCN0rUwbQbKDsBVQKM 8j9gHjhovn/T8d1mK9NbAZ4K41szwhb7xUaCi6pywsxoaSNCcF7c5Or3O0Km/8t4tHbg blrULpXj7h4QZbOvzw399I5T58Bg7JstJln/9sXnVJhkuOkIpNQxpx/o29m8r5tC+3Rp BPxIJNQw77UuiVKXBzClKCrXBL0M3M2L1WRZGGXbd5W2UA3MrmnO4uCMzuxnSi6XcvIs Gn+A== MIME-Version: 1.0 Received: by 10.204.155.92 with SMTP id r28mr11776542bkw.130.1339486942560; Tue, 12 Jun 2012 00:42:22 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Tue, 12 Jun 2012 00:42:22 -0700 (PDT) In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA11705E5E4@dfweml511-mbs.china.huawei.com> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <6561EABF52675C45BCDACA1B4D7AA11705E5E4@dfweml511-mbs.china.huawei.com> Date: Tue, 12 Jun 2012 16:42:22 +0900 Message-ID: From: Daniel Park To: John Kaippallimalil Content-Type: multipart/alternative; boundary=0015175cf7d664839a04c2419b08 Cc: "david.i.allan@ericsson.com" , "fmc@ietf.org" , "charliep@computer.org" , "tso@zteusa.com" , "THIEBAUT, LAURENT \(LAURENT\)" , "pierrick.seite@orange.com" Subject: Re: [fmc] FMC BoF at IETF 84? 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, 12 Jun 2012 07:42:27 -0000 --0015175cf7d664839a04c2419b08 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roland, I've briefly seen the draft. To me, it seems quite straightforward...It can be a just starting point though. Here is my rough comments for more discussion. (I am also a bit straightforward..so please don't be serious..^^) Abstract This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. [daniel] where is the sections for architecture and related works ? This document directly expresses some of requirements without any of problem statements and architectural explanation. It needs to be updated. 4. Requirements on UE Identification A popular deployment model in fixed networks is to provide a host with a single private IPv4 address at the home LAN or small business LAN. For instance, each host within the local network will be assigned a private IPv4 address, then NA(P)T function is responsible for translating the private IPv4 address to the public IPv4 address assigned to the CPE (Customer Premises Equipment). In addition, a CPE can be configured to offer a shared WiFi to visiting hosts (also called UEs (User Equipments)) which do not belong to the subscriber (owning the CPE). A visiting UE uses that shared WiFi facility to access its services. Granting access to the service is usually conditioned by an access control phase (e.g., redirection to captive portal inviting the user to authenticate). [daniel] Here, still the FMC definition is not clear to me. Are you defining them like below? or anything else ? Internet---ethernet---[CPE] is Fixed [CPE]---ethernet---[AP/BS] is Mobile or Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed [AP/BS]---air---Mobile Device is Mobile More specific, FMC means Fixed-Mobile Convergence. Another words, Convergence seems to me service and session continuity for the user who has both Fixed and Mobile subscription and access, where IETF FMC solutions have to support any of protocols to provide seamless services across Fixed and Mobile networks. It is traditionally a vertical handover in IETF in my experience. In that sense, *visiting hosts which do not belong to the subscriber* is merely taken place. Are you indicating the user who has Fixed network by A service provider and Mobile network by B service provider ? 5. Requirements for Access Selection Multiple access environment requires clever choice of the access network (cellular, mobile, VPN,...). this selection should depend on different criteria such as user's preference, user profile, network capabilities and conditions, operator policies, application QoS requirements and so on. [daniel] not sure, but it seems a bit implementation issue on the mobile device. Are there any problems or issues to be worked by IETF ? 6. Requirements on UE Mobility in Fixed Broadband Network The following are the requirements on UE Mobility in Fixed Broadband Network: o The switch from one network to another MUST exist during the session according to the network status with the change in the UE attachment. o Mechanisms and interfaces between operators SHOULD be deployed to control the mobility of the traffic flows of their users. o Mobility should be enabled even in AP overlapped area o Differentiated Services for the mobile device or the Station (STA) o Service guarantee when roaming or mobility o Resiliency in the network nodes should be provided [daniel] What you mean by mobility in Fixed Network ? In particular, *the switch from one network to another* means plug-in and pull-out from the ethernet port ? Still, FMC seems to be Wire-Wireless handover as one of vertical handover cases. In that sense, FMC has to support seamless connectivity when the user pull out his ethernet cable on the mobile node, any of available wireless networks should be provided for the handover, then the ongoing session will be kept...Isn't it a FMC use case ? 7. Requirements for Content Adaptation In this case, adaptation of content format (HD/SD, codec, .) SHOULD be possible when delivering the same content (e.g. video streaming) regardless of the access network type and of the terminal (User Equipment 'UE") characteristics. [daniel] For the adaptive streaming over heterogeneous networks, the appropriate sending rate based on the network characteristics and conditions is a fundamental function, and should be dynamically determined and exchanged between the client and the server. For that issue, there are several related internet-drafts. Just for your information. http://tools.ietf.org/html/draft-korhonen-mobopts-delivery-analysis-00 http://tools.ietf.org/html/draft-korhonen-mobopts-link-characteristics-ps-0= 1 http://tools.ietf.org/html/draft-daniel-mip-link-characteristic-01 Here, the mobile node has to obtain the network characteristics information via device API, and currently W3C is working on that matter as to define various APIs (Javascript) to get device and network information such as network type, available bandwidth, battery status, and so on...Although it is beyond scope of IETF, but needs to be discussed from the FMC architecture point of view. Regards, Daniel --=20 *Soohong Daniel Park* Samsung Electronics, Co., Ltd. On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil < John.Kaippallimalil@huawei.com> wrote: > Agree with Pierrick that is useful to look from an IETF viewpoint.**** > > The fmc requirements draft > http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt is a good > place to start.**** > > ** ** > > -John**** > > ** ** > > ** ** > > *From:* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *On Behalf Of = *THIEBAUT, > LAURENT (LAURENT) > *Sent:* Friday, June 08, 2012 3:12 AM > *To:* pierrick.seite@orange.com; charliep@computer.org; tso@zteusa.com > *Cc:* fmc@ietf.org; david.i.allan@ericsson.com > *Subject:* Re: [fmc] FMC BoF at IETF 84?**** > > ** ** > > ** ** > > ** ** > > Hello all**** > > I support Pierrick**** > > Best regards **** > > Laurent > ALCATEL-LUCENT **** > ------------------------------ > > *De :* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *De la part de* > pierrick.seite@orange.com > *Envoy=E9 :* vendredi 8 juin 2012 10:09 > *=C0 :* charliep@computer.org; tso@zteusa.com > *Cc :* david.i.allan@ericsson.com; fmc@ietf.org > *Objet :* Re: [fmc] FMC BoF at IETF 84?**** > > ** ** > > Hi,**** > > ** ** > > Actually, this is a good discussion. I agree that gathering requirements > for FMC is a good exercise, as long as it is done from an IETF standpoint= . > Otherwise, we duplicate BBF work.**** > > It is also worth to identify existing IETF solutions , or ongoing work, > that might meet these requirements. Then gap analysis should be done: wha= t > are the specific FMC issues that cannot be solved with current protocols, > or using other SDOs mechanisms? That=92s a fair question which should be > answered before going into a BoF, but the problem is that early stage > drafts do not answer above question. In other words, more work is needed > before going into a BoF. It does not mean we should stop discussing; > clearly, ongoing work in IETF/FMC is worth the effort but we still have n= ot > shown the interest for a dedicated FMC IETF WG=85 In my opinion=85**** > > ** ** > > BR,**** > > Pierrick**** > > ** ** > > *De :* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *De la part de*= Charles E. Perkins > *Envoy=E9 :* vendredi 8 juin 2012 08:54 > *=C0 :* tso@zteusa.com > *Cc :* fmc@ietf.org; david.i.allan@ericsson.com > *Objet :* Re: [fmc] FMC BoF at IETF 84?**** > > ** ** > > > Hello Tricci, > > The discussion at IETF 83 and on the mailing list had, I thought, > indicated that > there is work to do. I can certainly imagine that the IETF should have > something > to say about managing device identity upon movement to a new point of > attachment when NATs are involved. From the BBF and ITU documents, it > seemed quite reasonable to initiate some effort. I gather you do not see > the > need, or else see that it is already being met. If you'd like to supply > some > pointers to relevant documents that would be interesting to me. > > Anyway I am not the liaison to BBF or ITU, and in my experience at the IE= TF > people don't have to wait to be told what needs to be done. Of course if > some other SDO does tell the IETF what needs to be done, it can be easier > to get started. > > I wonder if anyone has tried to quantify the number of times that other > SDOs (not IETF) have duplicated effort. I'm personally familiar with one > or > two cases. And, to some extent, duplication can be in the eyes of the > beholder. For instance, why mess around with having NAIs or IMSIs when > we already have FQDNs?? [just kidding, no worries, I do understand] > > Please also note that "identify" is not at all the same as "define". > > Regarding the other points -- if you'd like to supply pointers to the > relevant > work in other SDOs for "session continuity, policy distribution, QoS > management, and application mobility" I'd be interested to take a look. > Somehow, in discussions with other interested people, I had the impressio= n > that these things were lacking. I don't even claim that they are > necessarily > within the jurisdiction of the IETF, but they seemed to me to be well > within > the scope of useful discussion at a BoF. > > And, finally, as always please note that the point of the BoF would be to > find out what if anything needs to be done. It's always O.K. to find out > that > nothing needs to be done -- perhaps even preferable. That was not at all > the sense I got from previous discussion, though. > > Regards, > Charlie P. > > > > > On 6/7/2012 10:59 PM, tso@zteusa.com wrote: ** ** > > Dear Charles, > > Thank you very much for your kind initiative for this work. > > However, when I examine the charter that you were describing below, many > questions come to my mind. > > Could you please help me to understand better on those considerations? > Please see inline below.. > > Thanks in advance. > Tricci > > **** > > *"Charles E. Perkins" * > Sent by: fmc-bounces@ietf.org **** > > 06/07/2012 10:29 PM **** > > To**** > > "fmc@ietf.org" **** > > cc**** > > ** ** > > Subject**** > > [fmc] FMC BoF at IETF 84?**** > > ** ** > > ** ** > > ** ** > > **** > > > > > > Hello folks, > > It's time to request a BoF during IETF 84 on the subject of FMC. > > A suitable BoF agenda would be to agree on an effective definition for > "fixed-mobile convergence" and to identify the initial steps along the wa= y > towards the goals. Here is some text that might be used to make the BoF > request... > > Fixed-mobile convergence, as commonly interpreted, should provide > satisfactory user experience when the user migrates between wide-area > cellular networks and WLAN networks having limited range. The latter are > generally anchored on a fixed residential or enterprise gateway. Our > understanding of the problem statement and requirements has been derived > from documents published by the BBF and the ITU [citations here]. Work is > needed in the IETF to meet the requirements. > > Tricci > May I ask, has BBF or ITU sent any specific request on this work= ? > If so, what are the specific problems that BBF has asked IETF, more > specifically, this BOF, to address? The reason that I asked this questi= on > is that, I work closely with my colleagues in BBF on many of those FMC > issues. I would not like to see the duplicate work done in different SDO= s > and come up with different solutions? > > While there are many possible solutions, all of them will require some > agreement on how to identify the wireless end device (e.g., handset). > > Tricci > May I ask, why would be the IETF's role to define the wireless > end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiM= AX > and WFA? Especially, I am sure that they already have their own > definitions. So, what are the wireless end device that you have in mind > that needs to be defined by IETF? Could you please clarify? > > Other requirements might include session continuity, policy distribution, > QoS management, and application mobility. > > Tricci > As the active contributors to 3GPP and BBF work, all of these > subjects have been going on in both of these SDO, could you please clarif= y > what are the specific aspects that are not covered by the other SDOs that > need additional work to be done in IETF? > > The initial set of goals should be strictly limited, and future broadenin= g > is to depend both on the solutions adopted for the initial goal set as we= ll > as the evolving needs of the user and network operator communities. > > Tricci > Sorry for asking so many questions? I have the selfish reason t= o > ensure that no duplicate work is done between IETF and the other SDOs tha= t > I am actively participated. Thanks again in advance to help me to > understand your proposal for this BOF. > > -- > Regards, > Charlie P. > > _______________________________________________ > 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 dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately.**** > > ** ** > > ** ** > > _______________________________________________**** > > fmc mailing list**** > > fmc@ietf.org**** > > https://www.ietf.org/mailman/listinfo/fmc**** > > ** ** > > -- **** > > Regards,**** > > Charlie P.**** > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > --0015175cf7d664839a04c2419b08 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Roland,

I've briefly seen the draft. To me,= it seems quite straightforward...It can be a just starting point though.Here is my rough comments for more discussion. (I am also a bit straight= forward..so please don't be serious..^^) 

Abstract

   This document provides a brief overview of the FMC (Fixed Mobile
   Convergence) architecture and related works.  The purpose of the
   document is to sketch a big picture for the FMC activity to ease
   identifying whether specification effort is required within IETF.
   This document identifies and analyzes some of issues that have arisen
   so far and elaborates a set of requirements for the FMC system.
[daniel] where is the sections for architecture and relate= d works ? This document directly expresses some of requirements without any= of problem statements and architectural explanation. It needs to be update= d.

4.  Requirements on UE Identification

   A popular deployment model in fixed networks is to provide a host
   with a single private IPv4 address at the home LAN or small business
   LAN.  For instance, each host within the local network will be
   assigned a private IPv4 address, then NA(P)T function is responsible
   for translating the private IPv4 address to the public IPv4 address
   assigned to the CPE (Customer Premises Equipment).

   In addition, a CPE can be configured to offer a shared WiFi to
   visiting hosts (also called UEs (User Equipments)) which do not
   belong to the subscriber (owning the CPE).  A visiting UE uses that
   shared WiFi facility to access its services.  Granting access to the
   service is usually conditioned by an access control phase (e.g.,
   redirection to captive portal inviting the user to authenticate).
[daniel] Here, still the FMC definition is not clear to me= . Are you defining them like below? or anything else ?

=
Internet---ethernet---[CPE] is Fixed
[CPE]---ethernet---[AP/= BS] is Mobile

or
Internet---ethernet---[CPE]---ethernet---[= AP/BS] is Fixed
[AP/BS]---air---Mobile Device is Mobile

More specific, FMC means Fixed-Mobile Convergence. Another = words, Convergence seems to me service and session continuity for the user = who has both Fixed and Mobile subscription and access, where IETF FMC solut= ions have to support any of protocols to provide seamless services across F= ixed and Mobile networks. It is traditionally a vertical handover in IETF i= n my experience. In that sense, *visiting hosts which do not belong to the = subscriber* is merely taken place. Are you indicating the user who has Fixe= d network by A service provider and Mobile network by B service provider ?<= /div> 

5.  Requirements for Access Selection

   Multiple access environment requires clever choice of the access
   network (cellular, mobile, VPN,...). this selection should depend on
   different criteria such as user's preference, user profile, network
   capabilities and conditions, operator policies, application QoS
   requirements and so on.
[daniel] not sure, but it seems a bit implementation issue= on the mobile device. Are there any problems or issues to be worked by IET= F ?

6.  Requirements on UE Mobility in Fixed =
Broadband Network

   The following are the requirements on UE Mobility in Fixed Broadband
   Network:
   o  The switch from one network to another MUST exist during the
      session according to the network status with the change in the UE
      attachment.
   o  Mechanisms and interfaces between operators SHOULD be deployed to
      control the mobility of the traffic flows of their users.
   o  Mobility should be enabled even in AP overlapped area
   o  Differentiated Services for the mobile device or the Station (STA)
   o  Service guarantee when roaming or mobility
   o  Resiliency in the network nodes should be provided
[d= aniel] What you mean by mobility in Fixed Network ? In particular, *the swi= tch from one network to another* means plug-in and pull-out from the ethern= et port ? Still, FMC seems to be Wire-Wireless handover as one of vertical = handover cases. In that sense, FMC has to support seamless connectivity whe= n the user pull out his ethernet cable on the mobile node, any of available= wireless networks should be provided for the handover, then the ongoing se= ssion will be kept...Isn't it a FMC use case ?

7.  Requirements for Content Adaptation

   In this case, adaptation of content format (HD/SD, codec, .)  SHOULD
   be possible when delivering the same content (e.g. video streaming)
   regardless of the access network type and of the terminal (User
   Equipment 'UE") characteristics.
[daniel] For the=A0adaptive streaming over heterogeneous= =A0networks, the appropriate sending rate based on the=A0network characteri= stics and conditions is a fundamental=A0function, and should be dynamically= determined and=A0exchanged between the client and the server. For that iss= ue, there are several related internet-drafts. Just for your information.= =A0

Here, the mobile node has to obtain the netwo= rk characteristics information via device API, and currently W3C is working= on that matter as to define various APIs (Javascript) to get device and ne= twork information such as network type, available bandwidth, battery status= , and so on...Although it is beyond scope of IETF, but needs to be discusse= d from the FMC architecture point of view.


Regards, Daniel
--=A0
= Soohong Daniel Park
Samsung Electronics, Co., Ltd.


On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil <= John.Ka= ippallimalil@huawei.com> wrote:

Agree with Pierrick that = is useful to look from an IETF viewpoint.

The fmc requirements draf= t http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt<= /a> is a good place to start.

=A0<= /p>

-John

=A0<= /p>

=A0<= /p>

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of THIEBAUT, LAURENT (LAURENT)
Sent: Friday, June 08, 2012 3:12 AM
To: p= ierrick.seite@orange.com; charliep@computer.org; tso@zteusa.com
Cc: fmc@ietf.org; david.i= .allan@ericsson.com
Subject: Re: [fmc] FMC BoF at IETF 84?

=A0

=A0=

=A0=

Hello all

I support Pierrick

Best regards

Laurent
ALCATEL-LUCENT

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ] De la part de pierrick.seite@orange.com
Envoy=E9=A0: vendredi 8 juin 2012 10:09
=C0=A0: c= harliep@computer.org; tso@zteusa.com
Cc=A0: david.i.allan@ericsson.com; fmc@ietf.org
Objet=A0: Re: [fmc] FMC BoF at IETF 84?

=A0

Hi,=

=A0=

Actually, this is a good = discussion. I agree that gathering requirements for FMC is a good exercise,= as long as it is done from an IETF standpoint. Otherwise, we duplicate BBF work.

It is also worth to ident= ify existing IETF solutions , or ongoing work, that might meet these requir= ements. Then gap analysis should be done: what are the specific FMC issues that cannot be solved with current protocols, or using other SD= Os mechanisms? That=92s a fair question which should be answered before goi= ng into a BoF, but the problem is that =A0early stage drafts do not answer = above question. In other words, =A0more work is needed before going into a BoF. It does not mean we should stop di= scussing; clearly, ongoing work in IETF/FMC is worth the effort but we stil= l have not shown the interest for a dedicated FMC IETF WG=85 In my opinion= =85

=A0<= /p>

BR,<= /p>

Pierrick

=A0<= /p>

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ] De la part de Charles E. Perkins
Envoy=E9=A0: vendredi 8 juin 2012 08:54
=C0=A0: tso@zteu= sa.com
Cc=A0: fmc@ietf.or= g; davi= d.i.allan@ericsson.com
Objet=A0: Re: [fmc] FMC BoF at IETF 84?

=A0


Hello Tricci,

The discussion at IETF 83 and on the mailing list had, I thought, indicated= that
there is work to do.=A0 I can certainly imagine that the IETF should have s= omething
to say about managing device identity upon movement to a new point of
attachment when NATs are involved.=A0 From the BBF and ITU documents, it seemed quite reasonable to initiate some effort.=A0 I gather you do not see= the
need, or else see that it is already being met.=A0 If you'd like to sup= ply some
pointers to relevant documents that would be interesting to me.

Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF=
people don't have to wait to be told what needs to be done.=A0 Of cours= e if
some other SDO does tell the IETF what needs to be done, it can be easier to get started.

I wonder if anyone has tried to quantify the number of times that other
SDOs (not IETF) have duplicated effort.=A0 I'm personally familiar with= one or
two cases.=A0 And, to some extent, duplication can be in the eyes of the beholder.=A0 For instance, why mess around with having NAIs or IMSIs when we already have FQDNs??=A0 [just kidding, no worries, I do understand]

Please also note that "identify" is not at all the same as "= define".

Regarding the other points -- if you'd like to supply pointers to the r= elevant
work in other SDOs for "session continuity, policy distribution, QoS
management, and app= lication mobility"=A0 I'd be interested to take a look.
Somehow, in discussions with other interested people, I had the impression<= br> that these things were lacking.=A0 I don't even claim that they are nec= essarily
within the jurisdiction of the IETF, but they seemed to me to be well withi= n
the scope of useful discussion at a BoF.

And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done.=A0 It's always O.K. to find= out that
nothing needs to be done -- perhaps even preferable.=A0 That was not at all=
the sense I got from previous discussion, though.

Regards,
Charlie P.




On 6/7/2012 10:59 PM, t= so@zteusa.com wrote:

Dear= Charles,

Thank you very much for your kind initiative for th= is work.

However, when I examine the charter that you were d= escribing below, many questions come to my mind.

Could you please help me to understand better on th= ose considerations? =A0Please see inline below..

Thanks in advance.
Tricci

"Charles E. Perkins" <charliep@com= puter.org>
Sent by: fmc-bounces@ietf.org

06/07/2012 10:29 PM

To

"fmc@ietf.org" <fmc@ietf.org><= /span>

cc

=A0

Subject

[fmc] FMC BoF at IETF 84?=

=A0

=A0

=A0




Hello folks,=

It's time to re= quest a BoF during IETF 84 on the subject of FMC.

A suitable BoF agen= da would be to agree on an effective definition for "fixed-mobile conv= ergence" and to identify the initial steps along the way towards the g= oals. Here is some text that might be used to make the BoF request...

Fixed-mobile conver= gence, as commonly interpreted, should provide satisfactory user experience= when the user migrates between wide-area cellular networks and WLAN networ= ks having limited range. =A0The latter are generally anchored on a fixed residential or enterprise gateway. =A0Ou= r understanding of the problem statement and requirements has = been derived from documents published by the BBF and the ITU [citations her= e]. Work is n= eeded in the IETF to meet the requirements.

Tricci > May I ask, has BBF or ITU sent any spec= ific request on this work? =A0If so, what are the specific problems that BB= F has asked IETF, more specifically, this BOF, to address? =A0 The reason that I asked this question is that, I work closely with my coll= eagues in BBF on many of those FMC issues. =A0I would not like to see the d= uplicate work done in different SDOs and come up with different solutions? = =A0<= br>
=A0While there are = many possible solutions, all of them will require some agreement on how to = identify the wireless end device (e.g., handset). =A0

Tricci > May I ask, why would be the IETF's = role to define the wireless end device? =A0Shouldn't this be the respon= sibility of the 3GPP, 3GPP2, WiMAX and WFA? =A0Especially, I am sure that they already have their own definitions. =A0So, what are the wireless end = device that you have in mind that needs to be defined by IETF? =A0Could you= please clarify? =A0

Other requirements = might include session continuity, policy distribution, QoS management, and = application mobility.

Tricci > As the active contributors to 3GPP and = BBF work, all of these subjects have been going on in both of these SDO, co= uld you please clarify what are the specific aspects that are not covered by the other SDOs that need additional work to be done in IETF= ? =A0

The initial set of = goals should be strictly limited, and future broadening is to depend both o= n the solutions adopted for the initial goal set as well as the evolving ne= eds of the user and network operator communities.

Tricci > Sorry for asking so many questions? =A0= I have the selfish reason to ensure that no duplicate work is done between = IETF and the other SDOs that I am actively participated. =A0Thanks again in advance to help me to understand your proposal for this BOF. =A0<= /span>

--
Regards,
Charlie P.

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

----------------------------------------------------=
----
ZTE=A0Information=A0Security=A0Notice:=A0The=A0infor=
mation=A0contained=A0in=A0this=A0mail=A0(and=A0any=A0attachment=A0transmitt=
ed=A0herewith)=A0is=A0privileged=A0and=A0confidential=A0and=A0is=A0intended=
=A0for=A0the=A0exclusive=A0use=A0of=A0the=A0addressee(s).=A0=A0If=A0you=A0a=
re=A0not=A0an=A0intended=A0recipient,=A0any=A0disclosure,=A0reproduction,=
=A0distribution=A0or=A0other=A0dissemination=A0or=A0use=A0of=A0the=A0inform=
ation=A0contained=A0is=A0strictly=A0prohibited.=A0=A0If=A0you=A0have=A0rece=
ived=A0this=A0mail=A0in=A0error,=A0please=A0delete=A0it=A0and=A0notify=A0us=
=A0immediately.
=A0

= =A0

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

= =A0

-- 
Regards,
Charlie P.

_______________________________________________
fmc mailing list
fmc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/fmc



--0015175cf7d664839a04c2419b08-- From Dirk.von-Hugo@telekom.de Tue Jun 12 03:21:36 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 10A7B21F8501 for ; Tue, 12 Jun 2012 03:21:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTpj-IdIY+Qq for ; Tue, 12 Jun 2012 03:21:28 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3F58621F855F for ; Tue, 12 Jun 2012 03:21:27 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2012 12:21:21 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 12 Jun 2012 12:21:20 +0200 From: To: , Date: Tue, 12 Jun 2012 12:21:27 +0200 Thread-Topic: [fmc] FMC BoF at IETF 84? Thread-Index: Ac1IbvHHkbs0V4krSZaZdi7HRlX3mAAFDYwg Message-ID: <05C81A773E48DD49B181B04BA21A342A27A45DDF7F@HE113484.emea1.cds.t-internal.com> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <6561EABF52675C45BCDACA1B4D7AA11705E5E4@dfweml511-mbs.china.huawei.com> 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_05C81A773E48DD49B181B04BA21A342A27A45DDF7FHE113484emea1_" MIME-Version: 1.0 Cc: david.i.allan@ericsson.com, fmc@ietf.org, charliep@computer.org, tso@zteusa.com, laurent.thiebaut@alcatel-lucent.com, pierrick.seite@orange.com, Roland.Schott@telekom.de Subject: Re: [fmc] FMC BoF at IETF 84? 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, 12 Jun 2012 10:21:36 -0000 --_000_05C81A773E48DD49B181B04BA21A342A27A45DDF7FHE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniel, just a quick remark: The requirements draft is accompanied by a problem sta= tement document http://www.ietf.org/id/draft-xue-fmc-ps-00.txt where architecture and so on are described.referring to your question I wou= ld say we see fixed and mobile as following Internet---ethernet---[CPE]---ethernet---[AP]---air---Device is Fixed Internet---ethernet---[EPC, mobile core]---ethernet---[BS]---air---Device i= s Mobile we will discuss the other issues in future in more detail. Best regards Dirk ________________________________ Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von Dani= el Park Gesendet: Dienstag, 12. Juni 2012 09:42 An: John Kaippallimalil Cc: david.i.allan@ericsson.com; fmc@ietf.org; charliep@computer.org; tso@zt= eusa.com; THIEBAUT, LAURENT (LAURENT); pierrick.seite@orange.com Betreff: Re: [fmc] FMC BoF at IETF 84? Hi Roland, I've briefly seen the draft. To me, it seems quite straightforward...It can= be a just starting point though. Here is my rough comments for more discussion. (I am also a bit straightfor= ward..so please don't be serious..^^) Abstract This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. [daniel] where is the sections for architecture and related works ? This do= cument directly expresses some of requirements without any of problem state= ments and architectural explanation. It needs to be updated. 4. Requirements on UE Identification A popular deployment model in fixed networks is to provide a host with a single private IPv4 address at the home LAN or small business LAN. For instance, each host within the local network will be assigned a private IPv4 address, then NA(P)T function is responsible for translating the private IPv4 address to the public IPv4 address assigned to the CPE (Customer Premises Equipment). In addition, a CPE can be configured to offer a shared WiFi to visiting hosts (also called UEs (User Equipments)) which do not belong to the subscriber (owning the CPE). A visiting UE uses that shared WiFi facility to access its services. Granting access to the service is usually conditioned by an access control phase (e.g., redirection to captive portal inviting the user to authenticate). [daniel] Here, still the FMC definition is not clear to me. Are you definin= g them like below? or anything else ? Internet---ethernet---[CPE] is Fixed [CPE]---ethernet---[AP/BS] is Mobile or Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed [AP/BS]---air---Mobile Device is Mobile More specific, FMC means Fixed-Mobile Convergence. Another words, Convergen= ce seems to me service and session continuity for the user who has both Fix= ed and Mobile subscription and access, where IETF FMC solutions have to sup= port any of protocols to provide seamless services across Fixed and Mobile = networks. It is traditionally a vertical handover in IETF in my experience.= In that sense, *visiting hosts which do not belong to the subscriber* is m= erely taken place. Are you indicating the user who has Fixed network by A s= ervice provider and Mobile network by B service provider ? 5. Requirements for Access Selection Multiple access environment requires clever choice of the access network (cellular, mobile, VPN,...). this selection should depend on different criteria such as user's preference, user profile, network capabilities and conditions, operator policies, application QoS requirements and so on. [daniel] not sure, but it seems a bit implementation issue on the mobile de= vice. Are there any problems or issues to be worked by IETF ? 6. Requirements on UE Mobility in Fixed Broadband Network The following are the requirements on UE Mobility in Fixed Broadband Network: o The switch from one network to another MUST exist during the session according to the network status with the change in the UE attachment. o Mechanisms and interfaces between operators SHOULD be deployed to control the mobility of the traffic flows of their users. o Mobility should be enabled even in AP overlapped area o Differentiated Services for the mobile device or the Station (STA) o Service guarantee when roaming or mobility o Resiliency in the network nodes should be provided [daniel] What you mean by mobility in Fixed Network ? In particular, *the s= witch from one network to another* means plug-in and pull-out from the ethe= rnet port ? Still, FMC seems to be Wire-Wireless handover as one of vertica= l handover cases. In that sense, FMC has to support seamless connectivity w= hen the user pull out his ethernet cable on the mobile node, any of availab= le wireless networks should be provided for the handover, then the ongoing = session will be kept...Isn't it a FMC use case ? 7. Requirements for Content Adaptation In this case, adaptation of content format (HD/SD, codec, .) SHOULD be possible when delivering the same content (e.g. video streaming) regardless of the access network type and of the terminal (User Equipment 'UE") characteristics. [daniel] For the adaptive streaming over heterogeneous networks, the approp= riate sending rate based on the network characteristics and conditions is a= fundamental function, and should be dynamically determined and exchanged b= etween the client and the server. For that issue, there are several related= internet-drafts. Just for your information. http://tools.ietf.org/html/draft-korhonen-mobopts-delivery-analysis-00 http://tools.ietf.org/html/draft-korhonen-mobopts-link-characteristics-ps-0= 1 http://tools.ietf.org/html/draft-daniel-mip-link-characteristic-01 Here, the mobile node has to obtain the network characteristics information= via device API, and currently W3C is working on that matter as to define v= arious APIs (Javascript) to get device and network information such as netw= ork type, available bandwidth, battery status, and so on...Although it is b= eyond scope of IETF, but needs to be discussed from the FMC architecture po= int of view. Regards, Daniel -- Soohong Daniel Park Samsung Electronics, Co., Ltd. On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil > wrote: Agree with Pierrick that is useful to look from an IETF viewpoint. The fmc requirements draft http://www.ietf.org/id/draft-schott-fmc-requirem= ents-00.txt is a good place to start. -John From: fmc-bounces@ietf.org [mailto:fmc-bounces= @ietf.org] On Behalf Of THIEBAUT, LAURENT (LAU= RENT) Sent: Friday, June 08, 2012 3:12 AM To: pierrick.seite@orange.com; charliep@c= omputer.org; tso@zteusa.com Cc: fmc@ietf.org; david.i.allan@ericsson.com Subject: Re: [fmc] FMC BoF at IETF 84? Hello all I support Pierrick Best regards Laurent ALCATEL-LUCENT ________________________________ De : fmc-bounces@ietf.org [mailto:fmc-bounces@= ietf.org] De la part de pierrick.seite@orange.= com Envoy=E9 : vendredi 8 juin 2012 10:09 =C0 : charliep@computer.org; tso@zteusa.com Cc : david.i.allan@ericsson.com; fmc@iet= f.org Objet : Re: [fmc] FMC BoF at IETF 84? Hi, Actually, this is a good discussion. I agree that gathering requirements fo= r FMC is a good exercise, as long as it is done from an IETF standpoint. Ot= herwise, we duplicate BBF work. It is also worth to identify existing IETF solutions , or ongoing work, tha= t might meet these requirements. Then gap analysis should be done: what are= the specific FMC issues that cannot be solved with current protocols, or u= sing other SDOs mechanisms? That's a fair question which should be answered= before going into a BoF, but the problem is that early stage drafts do no= t answer above question. In other words, more work is needed before going = into a BoF. It does not mean we should stop discussing; clearly, ongoing wo= rk in IETF/FMC is worth the effort but we still have not shown the interest= for a dedicated FMC IETF WG... In my opinion... BR, Pierrick De : fmc-bounces@ietf.org [mailto:fmc-bounces@= ietf.org] De la part de Charles E. Perkins Envoy=E9 : vendredi 8 juin 2012 08:54 =C0 : tso@zteusa.com Cc : fmc@ietf.org; david.i.allan@ericsson.com Objet : Re: [fmc] FMC BoF at IETF 84? Hello Tricci, The discussion at IETF 83 and on the mailing list had, I thought, indicated= that there is work to do. I can certainly imagine that the IETF should have som= ething to say about managing device identity upon movement to a new point of attachment when NATs are involved. From the BBF and ITU documents, it seemed quite reasonable to initiate some effort. I gather you do not see t= he need, or else see that it is already being met. If you'd like to supply so= me pointers to relevant documents that would be interesting to me. Anyway I am not the liaison to BBF or ITU, and in my experience at the IETF people don't have to wait to be told what needs to be done. Of course if some other SDO does tell the IETF what needs to be done, it can be easier to get started. I wonder if anyone has tried to quantify the number of times that other SDOs (not IETF) have duplicated effort. I'm personally familiar with one o= r two cases. And, to some extent, duplication can be in the eyes of the beholder. For instance, why mess around with having NAIs or IMSIs when we already have FQDNs?? [just kidding, no worries, I do understand] Please also note that "identify" is not at all the same as "define". Regarding the other points -- if you'd like to supply pointers to the relev= ant work in other SDOs for "session continuity, policy distribution, QoS management, and application mobility" I'd be interested to take a look. Somehow, in discussions with other interested people, I had the impression that these things were lacking. I don't even claim that they are necessari= ly within the jurisdiction of the IETF, but they seemed to me to be well withi= n the scope of useful discussion at a BoF. And, finally, as always please note that the point of the BoF would be to find out what if anything needs to be done. It's always O.K. to find out t= hat nothing needs to be done -- perhaps even preferable. That was not at all the sense I got from previous discussion, though. Regards, Charlie P. On 6/7/2012 10:59 PM, tso@zteusa.com wrote: Dear Charles, Thank you very much for your kind initiative for this work. However, when I examine the charter that you were describing below, many qu= estions come to my mind. Could you please help me to understand better on those considerations? Ple= ase see inline below.. Thanks in advance. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 06/07/2012 10:29 PM To "fmc@ietf.org" cc Subject [fmc] FMC BoF at IETF 84? Hello folks, It's time to request a BoF during IETF 84 on the subject of FMC. A suitable BoF agenda would be to agree on an effective definition for "fix= ed-mobile convergence" and to identify the initial steps along the way towa= rds the goals. Here is some text that might be used to make the BoF request= ... Fixed-mobile convergence, as commonly interpreted, should provide satisfact= ory user experience when the user migrates between wide-area cellular netwo= rks and WLAN networks having limited range. The latter are generally ancho= red on a fixed residential or enterprise gateway. Our understanding of the= problem statement and requirements has been derived from documents publish= ed by the BBF and the ITU [citations here]. Work is needed in the IETF to m= eet the requirements. Tricci > May I ask, has BBF or ITU sent any specific request on this work? = If so, what are the specific problems that BBF has asked IETF, more specif= ically, this BOF, to address? The reason that I asked this question is th= at, I work closely with my colleagues in BBF on many of those FMC issues. = I would not like to see the duplicate work done in different SDOs and come = up with different solutions? While there are many possible solutions, all of them will require some agr= eement on how to identify the wireless end device (e.g., handset). Tricci > May I ask, why would be the IETF's role to define the wireless end= device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX an= d WFA? Especially, I am sure that they already have their own definitions.= So, what are the wireless end device that you have in mind that needs to = be defined by IETF? Could you please clarify? Other requirements might include session continuity, policy distribution, Q= oS management, and application mobility. Tricci > As the active contributors to 3GPP and BBF work, all of these subj= ects have been going on in both of these SDO, could you please clarify what= are the specific aspects that are not covered by the other SDOs that need = additional work to be done in IETF? The initial set of goals should be strictly limited, and future broadening = is to depend both on the solutions adopted for the initial goal set as well= as the evolving needs of the user and network operator communities. Tricci > Sorry for asking so many questions? I have the selfish reason to = ensure that no duplicate work is done between IETF and the other SDOs that = I am actively participated. Thanks again in advance to help me to understa= nd your proposal for this BOF. -- Regards, Charlie P. _______________________________________________ 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. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -- Regards, Charlie P. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --_000_05C81A773E48DD49B181B04BA21A342A27A45DDF7FHE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
just a quick remark: The requirements draft is=20 accompanied by a problem statement document

http://www.ietf.org/id/draft-xue-fmc-ps-00.txt

where=20 architecture and so on are described.referring to your question I would say= we=20 see fixed and mobile as following

Internet---ethernet---[CPE]---ethernet---[AP]---air---Device i= s=20 Fixed
Internet---ethernet---[EPC, mobile=20 core]---ethernet---[BS]---air---Device is Mobile
 
we=20 will discuss the other issues in future in more=20 detail.

Best regards
Dirk

Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] Im Auftrag von Daniel=20 Park
Gesendet: Dienstag, 12. Juni 2012 09:42
An: John=20 Kaippallimalil
Cc: david.i.allan@ericsson.com; fmc@ietf.org;=20 charliep@computer.org; tso@zteusa.com; THIEBAUT, LAURENT (LAURENT);=20 pierrick.seite@orange.com
Betreff: Re: [fmc] FMC BoF at IETF=20 84?

Hi Roland,

I've brie= fly seen=20 the draft. To me, it seems quite straightforward...It can be a just startin= g=20 point though.
Here is my rough comments for more discussion. (I am also a bit=20 straightforward..so please don't be serious..^^)

Abstract

   This document provides a brief overview of the FMC (Fixed Mobile
   Convergence) architecture and related works.  The purpose of the
   document is to sketch a big picture for the FMC activity to ease
   identifying whether specification effort is required within IETF.
   This document identifies and analyzes some of issues that have arisen
   so far and elaborates a set of requirements for the FMC system.
[daniel] where is the sections for architecture and related works ? Th= is=20 document directly expresses some of requirements without any of problem=20 statements and architectural explanation. It needs to be updated.

4.  Requirements on UE Identification

   A popular deployment model in fixed networks is to provide a host
   with a single private IPv4 address at the home LAN or small business
   LAN.  For instance, each host within the local network will be
   assigned a private IPv4 address, then NA(P)T function is responsible
   for translating the private IPv4 address to the public IPv4 address
   assigned to the CPE (Customer Premises Equipment).

   In addition, a CPE can be configured to offer a shared WiFi to
   visiting hosts (also called UEs (User Equipments)) which do not
   belong to the subscriber (owning the CPE).  A visiting UE uses that
   shared WiFi facility to access its services.  Granting access to the
   service is usually conditioned by an access control phase (e.g.,
   redirection to captive portal inviting the user to authenticate).
[daniel] Here, still the FMC definition is not clear to me. Are you=20 defining them like below? or anything else ?

Internet---ethernet---[CPE] is Fixed
[CPE]---ethernet---[AP/BS] is Mobile

or
Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed
[AP/BS]---air---Mobile Device is Mobile

More specific, FMC means Fixed-Mobile Convergence. Another words,=20 Convergence seems to me service and session continuity for the user who has= both=20 Fixed and Mobile subscription and access, where IETF FMC solutions have to= =20 support any of protocols to provide seamless services across Fixed and Mobi= le=20 networks. It is traditionally a vertical handover in IETF in my experience.= In=20 that sense, *visiting hosts which do not belong to the subscriber* is merel= y=20 taken place. Are you indicating the user who has Fixed network by A service= =20 provider and Mobile network by B service provider ?

5.  Requirements for Access Selection

   Multiple access environment requires clever choice of the access
   network (cellular, mobile, VPN,...). this selection should depend on
   different criteria such as user's preference, user profile, network
   capabilities and conditions, operator policies, application QoS
   requirements and so on.
[daniel] not sure, but it seems a bit implementation issue on the mobi= le=20 device. Are there any problems or issues to be worked by IETF ?

6.  Requirements on UE Mobility in Fixed Broadband Network

   The following are the requirements on UE Mobility in Fixed Broadband
   Network:
   o  The switch from one network to another MUST exist during the
      session according to the network status with the change in the UE
      attachment.
   o  Mechanisms and interfaces between operators SHOULD be deployed to
      control the mobility of the traffic flows of their users.
   o  Mobility should be enabled even in AP overlapped area
   o  Differentiated Services for the mobile device or the Station (STA)
   o  Service guarantee when roaming or mobility
   o  Resiliency in the network nodes should be provided
[daniel] What you mean by mobility in Fixed Network ? In particular, *= the=20 switch from one network to another* means plug-in and pull-out from the eth= ernet=20 port ? Still, FMC seems to be Wire-Wireless handover as one of vertical han= dover=20 cases. In that sense, FMC has to support seamless connectivity when the use= r=20 pull out his ethernet cable on the mobile node, any of available wireless=20 networks should be provided for the handover, then the ongoing session will= be=20 kept...Isn't it a FMC use case ?

7.  Requirements for Content Adaptation

   In this case, adaptation of content format (HD/SD, codec, .)  SHOULD
   be possible when delivering the same content (e.g. video streaming)
   regardless of the access network type and of the terminal (User
   Equipment 'UE") characteristics.
[daniel] For the adaptive streaming over heterogeneous netwo= rks,=20 the appropriate sending rate based on the network characteristics and= =20 conditions is a fundamental function, and should be dynamically determ= ined=20 and exchanged between the client and the server. For that issue, there= are=20 several related internet-drafts. Just for your information. 
http://tools.ietf.org/html/draft-korhonen-mobopts-delivery-analysis-00=
http://tools.ietf.org/html/draft-korhonen-mobopts-link-character= istics-ps-01
http://tools.ietf.org/html/draft-daniel-mip-link-characteristic-01

Here, the mobile node has to obtain the network characteristics inform= ation=20 via device API, and currently W3C is working on that matter as to define va= rious=20 APIs (Javascript) to get device and network information such as network typ= e,=20 available bandwidth, battery status, and so on...Although it is beyond scop= e of=20 IETF, but needs to be discussed from the FMC architecture point of view.


Regards, Daniel
-- 
Soohong Daniel Park
Samsung Electronics, Co.,=20 Ltd.



On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimal= il=20 <John.Kaippallimalil@huawei.com> wrote:

Agree=20 with Pierrick that is useful to look from an IETF=20 viewpoint.

The=20 fmc requirements draft http://www.ietf.org/id/draft-schott-fmc-requirements-00.t= xt=20 is a good place to start.

 

-John

 

 

From:=20 fmc-bounces@ietf.= org=20 [mailto:fmc-bounces@ietf.org] On Behalf Of THIEBAUT, L= AURENT=20 (LAURENT)
Sent: Friday, June 08, 2012 3:12 AM
To: pierrick.seite@orange.com; charliep@computer.o= rg;=20 tso@zteusa.com
<= B>Cc:=20 fmc@ietf.org; david.i.allan@ericsson.com
Subject: Re: [fm= c] FMC=20 BoF at IETF 84?

 


De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ]=20 De la part de pierrick.seite@orange.com
Envoy=E9 : v= endredi 8=20 juin 2012 10:09
=C0 : charliep@computer.org; tso@zteusa.com
Cc : david.i.allan@ericsson.com; fmc@ietf.org
Objet : Re: [fmc] FMC BoF= at=20 IETF 84?

 

Hi,

 

Actually,=20 this is a good discussion. I agree that gathering requirements for FMC is= a=20 good exercise, as long as it is done from an IETF standpoint. Otherwise, = we=20 duplicate BBF work.

It=20 is also worth to identify existing IETF solutions , or ongoing work, that= =20 might meet these requirements. Then gap analysis should be done: what are= the=20 specific FMC issues that cannot be solved with current protocols, or usin= g=20 other SDOs mechanisms? That=92s a fair question which should be answered = before=20 going into a BoF, but the problem is that  early stage drafts do not= =20 answer above question. In other words,  more work is needed before g= oing=20 into a BoF. It does not mean we should stop discussing; clearly, ongoing = work=20 in IETF/FMC is worth the effort but we still have not shown the interest = for a=20 dedicated FMC IETF WG=85 In my opinion=85

 

BR,

Pierrick

 

De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ]=20 De la part de Charles E. Perkins
Envoy=E9 : vendred= i 8=20 juin 2012 08:54
=C0 : tso@zteusa.com
Cc : fmc@ietf.org; david.i.allan@ericsson.com
Objet : Re:= [fmc]=20 FMC BoF at IETF 84?

 


Hello Tricci,

The discuss= ion at=20 IETF 83 and on the mailing list had, I thought, indicated that
there i= s=20 work to do.  I can certainly imagine that the IETF should have=20 something
to say about managing device identity upon movement to a new= =20 point of
attachment when NATs are involved.  From the BBF and ITU= =20 documents, it
seemed quite reasonable to initiate some effort.  I= =20 gather you do not see the
need, or else see that it is already being=20 met.  If you'd like to supply some
pointers to relevant documents= that=20 would be interesting to me.

Anyway I am not the liaison to BBF or = ITU,=20 and in my experience at the IETF
people don't have to wait to be told = what=20 needs to be done.  Of course if
some other SDO does tell the IETF= what=20 needs to be done, it can be easier
to get started.

I wonder if= =20 anyone has tried to quantify the number of times that other
SDOs (not = IETF)=20 have duplicated effort.  I'm personally familiar with one or
two= =20 cases.  And, to some extent, duplication can be in the eyes of=20 the
beholder.  For instance, why mess around with having NAIs or = IMSIs=20 when
we already have FQDNs??  [just kidding, no worries, I do=20 understand]

Please also note that "identify" is not at all the sam= e as=20 "define".

Regarding the other points -- if you'd like to supply=20 pointers to the relevant
work in other SDOs for "session continuity, policy distributi= on,=20 QoS
manage= ment, and=20 application mobility"  I'd be interested= to=20 take a look.
Somehow, in discussions with other interested people, I h= ad=20 the impression
that these things were lacking.  I don't even clai= m=20 that they are necessarily
within the jurisdiction of the IETF, but the= y=20 seemed to me to be well within
the scope of useful discussion at a=20 BoF.

And, finally, as always please note that the point of the BoF= =20 would be to
find out what if anything needs to be done.  It's alw= ays=20 O.K. to find out that
nothing needs to be done -- perhaps even=20 preferable.  That was not at all
the sense I got from previous=20 discussion, though.

Regards,
Charlie P.




On=20 6/7/2012 10:59 PM, tso@zteusa.com wrote:

Dear C= harles,=20

Thank = you very=20 much for your kind initiative for this work.

Howeve= r, when I=20 examine the charter that you were describing below, many questions come t= o my=20 mind.

Could = you=20 please help me to understand better on those considerations?  Please= see=20 inline below..

Thanks= in=20 advance.
Tricci= =20

"Char= les E.=20 Perkins" <charliep@computer.org>=20
Sent = by: fmc-bounces@ietf.org

06/07= /2012=20 10:29 PM

To

"fmc@ietf.org" <fmc@ietf.org>=20

cc

 

Subject

[fmc]=20 FMC BoF at IETF 84?

 

 

 





Hello= =20 folks,

It= 's time to=20 request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to agr= ee on an=20 effective definition for "fixed-mobile convergence" and to identify the=20 initial steps along the way towards the goals. Here is some text that mig= ht be=20 used to make the BoF request...

Fixed-mobile convergence, as commonly= =20 interpreted, should provide satisfactory user experience when the user=20 migrates between wide-area cellular networks and WLAN networks having lim= ited=20 range.  The latter are generally anchored on a fixed residential or= =20 enterprise gateway.  Our understanding of the problem statement and= =20 requirements has been derived from documents published by the BBF and the IT= U=20 [citations here].=20 Work is = needed in=20 the IETF to meet the requirements.=20

Tricci > May I ask, has BBF or ITU sent any specific request= on=20 this work?  If so, what are the specific problems that BBF has asked= =20 IETF, more specifically, this BOF, to address?   The reason that I a= sked=20 this question is that, I work closely with my colleagues in BBF on many o= f=20 those FMC issues.  I would not like to see the duplicate work done i= n=20 different SDOs and come up with different solutions?  

 While there are many possible s= olutions,=20 all of them will require some agreement on how to identify the wireless e= nd=20 device (e.g., handset).  

Tricci= > May=20 I ask, why would be the IETF's role to define the wireless end device?=20  Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and = WFA?=20  Especially, I am sure that they already have their own definitions.= =20  So, what are the wireless end device that you have in mind that nee= ds to=20 be defined by IETF?  Could you please clarify?  

Ot= her=20 requirements might include session continuity, policy distribution, QoS=20 management, and application mobility.=20

Tricci > As the active contributors to 3GPP and BBF work, al= l of=20 these subjects have been going on in both of these SDO, could you please= =20 clarify what are the specific aspects that are not covered by the other S= DOs=20 that need additional work to be done in IETF?  

The in= itial set=20 of goals should be strictly limited, and future broadening is to depend b= oth=20 on the solutions adopted for the initial goal set as well as the evolving= =20 needs of the user and network operator communities.=20

Tricci > Sorry for asking so many questions?  I have th= e=20 selfish reason to ensure that no duplicate work is done between IETF and = the=20 other SDOs that I am actively participated.  Thanks again in advance= to=20 help me to understand your proposal for this BOF.  

--
Regards,
Charlie P.

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

-------------------=
-------------------------------------
ZTE Information Security Notice: The inf=
ormation contained in this mail (and any =
;attachment transmitted herewith) is privileged an=
d confidential and is intended for the e=
xclusive use of the addressee(s).  If yo=
u are not an intended recipient, any dis=
closure, reproduction, distribution or other disse=
mination or use of the information contained&=
nbsp;is strictly prohibited.  If you have&nbs=
p;received this mail in error, please delete&=
nbsp;it and notify us immediately.=

 

 

___________=
____________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc=

 

-- <=
U>
Regards,
= 
Charlie P.

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



--_000_05C81A773E48DD49B181B04BA21A342A27A45DDF7FHE113484emea1_-- From soohongp@gmail.com Tue Jun 12 03:33:59 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9021F85DF for ; Tue, 12 Jun 2012 03:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teU-MQ1vx1UY for ; Tue, 12 Jun 2012 03:33:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9687321F858D for ; Tue, 12 Jun 2012 03:33:56 -0700 (PDT) Received: by bkty8 with SMTP id y8so5094937bkt.31 for ; Tue, 12 Jun 2012 03:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xienuy4uUwgNt/mXuS2FslBS4rQX0hTtVdhReC3d6L0=; b=C+8pJfFMDQVTRSdWagdT3dDz1cSshxiu98Tw+7y4nelkU0flH/R9CsUD0u5ma9SM0a fQMvhgwxQpleVqcbbxNntu+6+PXyyEy+scQ4lV47eu6LOGLengNI+t/5IXIj86loTHDn 6VrA0OsWnkVfRYv3csPH5VJE8DXxSyTYVQIM5ha2YrAkL40deZACHtjzM2RRXjJ4QmA6 z4V3/MH74ClSmga43+uTQWEF3KQgiXF4zmounPeaaWc6oqUWZt9xdppUPxxA9CUWPSV8 dFDeDNvHnO1KGzOBOHtM0icX5W/T93avG1gIbD0WHr43CSZUTP1pOmLKN0L6eg5S3h4q JaMA== MIME-Version: 1.0 Received: by 10.205.117.3 with SMTP id fk3mr11871992bkc.136.1339497235373; Tue, 12 Jun 2012 03:33:55 -0700 (PDT) Received: by 10.204.200.201 with HTTP; Tue, 12 Jun 2012 03:33:55 -0700 (PDT) In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27A45DDF7F@HE113484.emea1.cds.t-internal.com> References: <4FD18DC2.1030401@computer.org> <4FD1A186.8060605@computer.org> <843DA8228A1BA74CA31FB4E111A5C462025F9EF8@ftrdmel0.rd.francetelecom.fr> <170E8FCC2134BD42B539B47798ABF8F0133E62960F@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <6561EABF52675C45BCDACA1B4D7AA11705E5E4@dfweml511-mbs.china.huawei.com> <05C81A773E48DD49B181B04BA21A342A27A45DDF7F@HE113484.emea1.cds.t-internal.com> Date: Tue, 12 Jun 2012 19:33:55 +0900 Message-ID: From: Daniel Park To: Dirk.von-Hugo@telekom.de Content-Type: multipart/alternative; boundary=00151747553ee45e2d04c2440079 Cc: david.i.allan@ericsson.com, fmc@ietf.org, laurent.thiebaut@alcatel-lucent.com, charliep@computer.org, tso@zteusa.com, John.Kaippallimalil@huawei.com, pierrick.seite@orange.com, Roland.Schott@telekom.de Subject: Re: [fmc] FMC BoF at IETF 84? 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, 12 Jun 2012 10:34:00 -0000 --00151747553ee45e2d04c2440079 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dirk, Thanks for pointing the PS draft. I will go through this and get back to here with more comments. Glancing at the draft... Figure 1 shows the assumed reference architecture of Fixed Mobile Convergence Interworking for a Mobile (3GPP) Network and a fixed non- 3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as an example in document [WT203]. [daniel] ah...so you are very much leaning to the 3GPP perspective. Um. fixed network is non-3GPP access network and mobile network is 3GPP network. It seems controversial definition in IETF...In this assumption, 3GPP and Non-3GPP interworking would be clearer than FMC in my thought. Anyhow, I will take a look at the draft... Regards, Daniel. --=20 *Soohong Daniel Park* Samsung Electronics, SWC On Tue, Jun 12, 2012 at 7:21 PM, wrote: > ** > Hi Daniel, > just a quick remark: The requirements draft is accompanied by a problem > statement document > > *http://www.ietf.org/id/draft-xue-fmc-ps-00.txt* > > where architecture and so on are described.referring to your question I > would say we see fixed and mobile as following > Internet---ethernet---[CPE]---ethernet---[AP]---air---Device is Fixed > Internet---ethernet---[EPC, mobile core]---ethernet---[BS]---air---Device > is Mobile > > we will discuss the other issues in future in more detail. > > Best regards > Dirk > ------------------------------ > *Von:* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *Im Auftrag von > *Daniel Park > *Gesendet:* Dienstag, 12. Juni 2012 09:42 > *An:* John Kaippallimalil > *Cc:* david.i.allan@ericsson.com; fmc@ietf.org; charliep@computer.org; > tso@zteusa.com; THIEBAUT, LAURENT (LAURENT); pierrick.seite@orange.com > *Betreff:* Re: [fmc] FMC BoF at IETF 84? > > Hi Roland, > > I've briefly seen the draft. To me, it seems quite straightforward...It > can be a just starting point though. > Here is my rough comments for more discussion. (I am also a bit > straightforward..so please don't be serious..^^) > > Abstract > > This document provides a brief overview of the FMC (Fixed Mobile > Convergence) architecture and related works. The purpose of the > document is to sketch a big picture for the FMC activity to ease > identifying whether specification effort is required within IETF. > This document identifies and analyzes some of issues that have arisen > so far and elaborates a set of requirements for the FMC system. > > [daniel] where is the sections for architecture and related works ? This > document directly expresses some of requirements without any of problem > statements and architectural explanation. It needs to be updated. > > 4. Requirements on UE Identification > > A popular deployment model in fixed networks is to provide a host > with a single private IPv4 address at the home LAN or small business > LAN. For instance, each host within the local network will be > assigned a private IPv4 address, then NA(P)T function is responsible > for translating the private IPv4 address to the public IPv4 address > assigned to the CPE (Customer Premises Equipment). > > In addition, a CPE can be configured to offer a shared WiFi to > visiting hosts (also called UEs (User Equipments)) which do not > belong to the subscriber (owning the CPE). A visiting UE uses that > shared WiFi facility to access its services. Granting access to the > service is usually conditioned by an access control phase (e.g., > redirection to captive portal inviting the user to authenticate). > > [daniel] Here, still the FMC definition is not clear to me. Are you > defining them like below? or anything else ? > > Internet---ethernet---[CPE] is Fixed > [CPE]---ethernet---[AP/BS] is Mobile > > or > Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed > [AP/BS]---air---Mobile Device is Mobile > > More specific, FMC means Fixed-Mobile Convergence. Another words, > Convergence seems to me service and session continuity for the user who h= as > both Fixed and Mobile subscription and access, where IETF FMC solutions > have to support any of protocols to provide seamless services across Fixe= d > and Mobile networks. It is traditionally a vertical handover in IETF in m= y > experience. In that sense, *visiting hosts which do not belong to the > subscriber* is merely taken place. Are you indicating the user who has > Fixed network by A service provider and Mobile network by B service > provider ? > > 5. Requirements for Access Selection > > Multiple access environment requires clever choice of the access > network (cellular, mobile, VPN,...). this selection should depend on > different criteria such as user's preference, user profile, network > capabilities and conditions, operator policies, application QoS > requirements and so on. > > [daniel] not sure, but it seems a bit implementation issue on the mobile > device. Are there any problems or issues to be worked by IETF ? > > 6. Requirements on UE Mobility in Fixed Broadband Network > > The following are the requirements on UE Mobility in Fixed Broadband > Network: > o The switch from one network to another MUST exist during the > session according to the network status with the change in the UE > attachment. > o Mechanisms and interfaces between operators SHOULD be deployed to > control the mobility of the traffic flows of their users. > o Mobility should be enabled even in AP overlapped area > o Differentiated Services for the mobile device or the Station (STA) > o Service guarantee when roaming or mobility > o Resiliency in the network nodes should be provided > > [daniel] What you mean by mobility in Fixed Network ? In particular, *the > switch from one network to another* means plug-in and pull-out from the > ethernet port ? Still, FMC seems to be Wire-Wireless handover as one of > vertical handover cases. In that sense, FMC has to support seamless > connectivity when the user pull out his ethernet cable on the mobile node= , > any of available wireless networks should be provided for the handover, > then the ongoing session will be kept...Isn't it a FMC use case ? > > 7. Requirements for Content Adaptation > > In this case, adaptation of content format (HD/SD, codec, .) SHOULD > be possible when delivering the same content (e.g. video streaming) > regardless of the access network type and of the terminal (User > Equipment 'UE") characteristics. > > [daniel] For the adaptive streaming over heterogeneous networks, the > appropriate sending rate based on the network characteristics and > conditions is a fundamental function, and should be dynamically determine= d > and exchanged between the client and the server. For that issue, there ar= e > several related internet-drafts. Just for your information. > http://tools.ietf.org/html/draft-korhonen-mobopts-delivery-analysis-00 > > http://tools.ietf.org/html/draft-korhonen-mobopts-link-characteristics-ps= -01 > http://tools.ietf.org/html/draft-daniel-mip-link-characteristic-01 > > Here, the mobile node has to obtain the network characteristics > information via device API, and currently W3C is working on that matter a= s > to define various APIs (Javascript) to get device and network information > such as network type, available bandwidth, battery status, and so > on...Although it is beyond scope of IETF, but needs to be discussed from > the FMC architecture point of view. > > > Regards, Daniel > -- > *Soohong Daniel Park* > Samsung Electronics, Co., Ltd. > > > > On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallimalil < > John.Kaippallimalil@huawei.com> wrote: > >> Agree with Pierrick that is useful to look from an IETF viewpoint.**** >> >> The fmc requirements draft >> http://www.ietf.org/id/draft-schott-fmc-requirements-00.txt is a good >> place to start.**** >> >> **** >> >> -John**** >> >> **** >> >> **** >> >> *From:* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *On Behalf Of >> *THIEBAUT, LAURENT (LAURENT) >> *Sent:* Friday, June 08, 2012 3:12 AM >> *To:* pierrick.seite@orange.com; charliep@computer.org; tso@zteusa.com >> *Cc:* fmc@ietf.org; david.i.allan@ericsson.com >> *Subject:* Re: [fmc] FMC BoF at IETF 84?**** >> >> **** >> >> **** >> >> **** >> >> Hello all**** >> >> I support Pierrick**** >> >> Best regards **** >> >> Laurent >> ALCATEL-LUCENT **** >> ------------------------------ >> >> *De :* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *De la part de= * >> pierrick.seite@orange.com >> *Envoy=E9 :* vendredi 8 juin 2012 10:09 >> *=C0 :* charliep@computer.org; tso@zteusa.com >> *Cc :* david.i.allan@ericsson.com; fmc@ietf.org >> *Objet :* Re: [fmc] FMC BoF at IETF 84?**** >> >> **** >> >> Hi,**** >> >> **** >> >> Actually, this is a good discussion. I agree that gathering requirements >> for FMC is a good exercise, as long as it is done from an IETF standpoin= t. >> Otherwise, we duplicate BBF work.**** >> >> It is also worth to identify existing IETF solutions , or ongoing work, >> that might meet these requirements. Then gap analysis should be done: wh= at >> are the specific FMC issues that cannot be solved with current protocols= , >> or using other SDOs mechanisms? That=92s a fair question which should be >> answered before going into a BoF, but the problem is that early stage >> drafts do not answer above question. In other words, more work is neede= d >> before going into a BoF. It does not mean we should stop discussing; >> clearly, ongoing work in IETF/FMC is worth the effort but we still have = not >> shown the interest for a dedicated FMC IETF WG=85 In my opinion=85**** >> >> **** >> >> BR,**** >> >> Pierrick**** >> >> **** >> >> *De :* fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] *De la part de= *Charles E. Perkins >> *Envoy=E9 :* vendredi 8 juin 2012 08:54 >> *=C0 :* tso@zteusa.com >> *Cc :* fmc@ietf.org; david.i.allan@ericsson.com >> *Objet :* Re: [fmc] FMC BoF at IETF 84?**** >> >> **** >> >> >> Hello Tricci, >> >> The discussion at IETF 83 and on the mailing list had, I thought, >> indicated that >> there is work to do. I can certainly imagine that the IETF should have >> something >> to say about managing device identity upon movement to a new point of >> attachment when NATs are involved. From the BBF and ITU documents, it >> seemed quite reasonable to initiate some effort. I gather you do not se= e >> the >> need, or else see that it is already being met. If you'd like to supply >> some >> pointers to relevant documents that would be interesting to me. >> >> Anyway I am not the liaison to BBF or ITU, and in my experience at the >> IETF >> people don't have to wait to be told what needs to be done. Of course i= f >> some other SDO does tell the IETF what needs to be done, it can be easie= r >> to get started. >> >> I wonder if anyone has tried to quantify the number of times that other >> SDOs (not IETF) have duplicated effort. I'm personally familiar with on= e >> or >> two cases. And, to some extent, duplication can be in the eyes of the >> beholder. For instance, why mess around with having NAIs or IMSIs when >> we already have FQDNs?? [just kidding, no worries, I do understand] >> >> Please also note that "identify" is not at all the same as "define". >> >> Regarding the other points -- if you'd like to supply pointers to the >> relevant >> work in other SDOs for "session continuity, policy distribution, QoS >> management, and application mobility" I'd be interested to take a look. >> Somehow, in discussions with other interested people, I had the impressi= on >> that these things were lacking. I don't even claim that they are >> necessarily >> within the jurisdiction of the IETF, but they seemed to me to be well >> within >> the scope of useful discussion at a BoF. >> >> And, finally, as always please note that the point of the BoF would be t= o >> find out what if anything needs to be done. It's always O.K. to find ou= t >> that >> nothing needs to be done -- perhaps even preferable. That was not at al= l >> the sense I got from previous discussion, though. >> >> Regards, >> Charlie P. >> >> >> >> >> On 6/7/2012 10:59 PM, tso@zteusa.com wrote: **** >> >> Dear Charles, >> >> Thank you very much for your kind initiative for this work. >> >> However, when I examine the charter that you were describing below, many >> questions come to my mind. >> >> Could you please help me to understand better on those considerations? >> Please see inline below.. >> >> Thanks in advance. >> Tricci >> >> **** >> >> *"Charles E. Perkins" * >> Sent by: fmc-bounces@ietf.org **** >> >> 06/07/2012 10:29 PM **** >> >> To**** >> >> "fmc@ietf.org" **** >> >> cc**** >> >> **** >> >> Subject**** >> >> [fmc] FMC BoF at IETF 84?**** >> >> **** >> >> **** >> >> **** >> >> **** >> >> >> >> >> >> Hello folks, >> >> It's time to request a BoF during IETF 84 on the subject of FMC. >> >> A suitable BoF agenda would be to agree on an effective definition for >> "fixed-mobile convergence" and to identify the initial steps along the w= ay >> towards the goals. Here is some text that might be used to make the BoF >> request... >> >> Fixed-mobile convergence, as commonly interpreted, should provide >> satisfactory user experience when the user migrates between wide-area >> cellular networks and WLAN networks having limited range. The latter ar= e >> generally anchored on a fixed residential or enterprise gateway. Our >> understanding of the problem statement and requirements has been derived >> from documents published by the BBF and the ITU [citations here]. Work >> is needed in the IETF to meet the requirements. >> >> Tricci > May I ask, has BBF or ITU sent any specific request on this >> work? If so, what are the specific problems that BBF has asked IETF, mo= re >> specifically, this BOF, to address? The reason that I asked this quest= ion >> is that, I work closely with my colleagues in BBF on many of those FMC >> issues. I would not like to see the duplicate work done in different SD= Os >> and come up with different solutions? >> >> While there are many possible solutions, all of them will require some >> agreement on how to identify the wireless end device (e.g., handset). >> >> Tricci > May I ask, why would be the IETF's role to define the wireless >> end device? Shouldn't this be the responsibility of the 3GPP, 3GPP2, Wi= MAX >> and WFA? Especially, I am sure that they already have their own >> definitions. So, what are the wireless end device that you have in mind >> that needs to be defined by IETF? Could you please clarify? >> >> Other requirements might include session continuity, policy distribution= , >> QoS management, and application mobility. >> >> Tricci > As the active contributors to 3GPP and BBF work, all of these >> subjects have been going on in both of these SDO, could you please clari= fy >> what are the specific aspects that are not covered by the other SDOs tha= t >> need additional work to be done in IETF? >> >> The initial set of goals should be strictly limited, and future >> broadening is to depend both on the solutions adopted for the initial go= al >> set as well as the evolving needs of the user and network operator >> communities. >> >> Tricci > Sorry for asking so many questions? I have the selfish reason >> to ensure that no duplicate work is done between IETF and the other SDOs >> that I am actively participated. Thanks again in advance to help me to >> understand your proposal for this BOF. >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> 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 an= d is intended for the exclusive use of the addressee(s). If you are not an= intended recipient, any disclosure, reproduction, distribution or other di= ssemination or use of the information contained is strictly prohibited. If= you have received this mail in error, please delete it and notify us immed= iately.**** >> >> ** ** >> >> **** >> >> _______________________________________________**** >> >> fmc mailing list**** >> >> fmc@ietf.org**** >> >> https://www.ietf.org/mailman/listinfo/fmc**** >> >> **** >> >> -- **** >> >> Regards,**** >> >> Charlie P.**** >> >> >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc >> >> > > --00151747553ee45e2d04c2440079 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dirk,

Thanks for pointing the PS draft. I will go thr= ough this and get back to here with more comments.

Glancing at the draft...
 Figure 1 shows the assumed refere=
nce architecture of Fixed Mobile
   Convergence Interworking for a Mobile (3GPP) Network and a fixed non-
   3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as
   an example in document [WT203].
[daniel] ah...so you are very much leaning to the 3GPP perspecti= ve. Um. fixed network is non-3GPP access network and mobile network is 3GPP= network. It seems=A0controversial definition in IETF...In this assumption,= 3GPP and Non-3GPP interworking would be clearer than FMC in my thought. An= yhow, I will take a look at the draft...


Regards, Daniel.
--=A0
Soohong Daniel Park
Samsung Electronics, SWC


On Tue, Jun 12, 2012 at 7:2= 1 PM, <Dirk.von-Hugo@telekom.de> wrote:
Hi Daniel,
just a quick=A0remark: The requirements draft is=20 accompanied by a problem statement document

http://www.ietf.o= rg/id/draft-xue-fmc-ps-00.txt

where=20 architecture and so on are described.referring to your question I would say= we=20 see fixed and mobile as following

Internet---ethernet---[CPE]---e= thernet---[AP]---air---Device is=20 Fixed
Internet---ethernet---[EP= C, mobile=20 core]---ethernet---[BS]---air---Device is Mobile
=A0
we=20 will discuss the other issues in future in more=20 detail.

Best regards Dirk

Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounc= es@ietf.org] Im Auftrag von Daniel=20 Park
Gesendet: Dienstag, 12. Juni 2012 09:42
An: John= =20 Kaippallimalil
Cc: david.i.allan@ericsson.com; fmc@ietf.org;=20 charliep@compute= r.org; tso@zteusa.c= om; THIEBAUT, LAURENT (LAURENT);=20 pierrick.sei= te@orange.com
Betreff: Re: [fmc] FMC BoF at IETF=20 84?

Hi Roland,

I've brief= ly seen=20 the draft. To me, it seems quite straightforward...It can be a just startin= g=20 point though.
Here is my rough comments for more discussion. (I am also a bit=20 straightforward..so please don't be serious..^^)

Abstract

   This document provides a brief overview of the FMC (Fixed Mobile
   Convergence) architecture and related works.  The purpose of the
   document is to sketch a big picture for the FMC activity to ease
   identifying whether specification effort is required within IETF.
   This document identifies and analyzes some of issues that have arisen
   so far and elaborates a set of requirements for the FMC system.
[daniel] where is the sections for architecture and related works ? Th= is=20 document directly expresses some of requirements without any of problem=20 statements and architectural explanation. It needs to be updated.

4.  Requirements on UE Identification

   A popular deployment model in fixed networks is to provide a host
   with a single private IPv4 address at the home LAN or small business
   LAN.  For instance, each host within the local network will be
   assigned a private IPv4 address, then NA(P)T function is responsible
   for translating the private IPv4 address to the public IPv4 address
   assigned to the CPE (Customer Premises Equipment).

   In addition, a CPE can be configured to offer a shared WiFi to
   visiting hosts (also called UEs (User Equipments)) which do not
   belong to the subscriber (owning the CPE).  A visiting UE uses that
   shared WiFi facility to access its services.  Granting access to the
   service is usually conditioned by an access control phase (e.g.,
   redirection to captive portal inviting the user to authenticate).
[daniel] Here, still the FMC definition is not clear to me. Are you=20 defining them like below? or anything else ?

Internet---ethernet---[CPE] is Fixed
[CPE]---ethernet---[AP/BS] is Mobile

or
Internet---ethernet---[CPE]---ethernet---[AP/BS] is Fixed
[AP/BS]---air---Mobile Device is Mobile

More specific, FMC means Fixed-Mobile Convergence. Another words,=20 Convergence seems to me service and session continuity for the user who has= both=20 Fixed and Mobile subscription and access, where IETF FMC solutions have to= =20 support any of protocols to provide seamless services across Fixed and Mobi= le=20 networks. It is traditionally a vertical handover in IETF in my experience.= In=20 that sense, *visiting hosts which do not belong to the subscriber* is merel= y=20 taken place. Are you indicating the user who has Fixed network by A service= =20 provider and Mobile network by B service provider ?

5.  Requirements for Access Selection

   Multiple access environment requires clever choice of the access
   network (cellular, mobile, VPN,...). this selection should depend on
   different criteria such as user's preference, user profile, network
   capabilities and conditions, operator policies, application QoS
   requirements and so on.
[daniel] not sure, but it seems a bit implementation issue on the mobi= le=20 device. Are there any problems or issues to be worked by IETF ?

6.  Requirements on UE Mobility in Fixed Broadband Network

   The following are the requirements on UE Mobility in Fixed Broadband
   Network:
   o  The switch from one network to another MUST exist during the
      session according to the network status with the change in the UE
      attachment.
   o  Mechanisms and interfaces between operators SHOULD be deployed to
      control the mobility of the traffic flows of their users.
   o  Mobility should be enabled even in AP overlapped area
   o  Differentiated Services for the mobile device or the Station (STA)
   o  Service guarantee when roaming or mobility
   o  Resiliency in the network nodes should be provided
[daniel] What you mean by mobility in Fixed Network ? In particular, *= the=20 switch from one network to another* means plug-in and pull-out from the eth= ernet=20 port ? Still, FMC seems to be Wire-Wireless handover as one of vertical han= dover=20 cases. In that sense, FMC has to support seamless connectivity when the use= r=20 pull out his ethernet cable on the mobile node, any of available wireless= =20 networks should be provided for the handover, then the ongoing session will= be=20 kept...Isn't it a FMC use case ?

7.  Requirements for Content Adaptation

   In this case, adaptation of content format (HD/SD, codec, .)  SHOULD
   be possible when delivering the same content (e.g. video streaming)
   regardless of the access network type and of the terminal (User
   Equipment 'UE") characteristics.
[daniel] For the=A0adaptive streaming over heterogeneous=A0networks,= =20 the appropriate sending rate based on the=A0network characteristics and=20 conditions is a fundamental=A0function, and should be dynamically determine= d=20 and=A0exchanged between the client and the server. For that issue, there ar= e=20 several related internet-drafts. Just for your information.=A0

Here, the mobile node has to obtain the network characteristics inform= ation=20 via device API, and currently W3C is working on that matter as to define va= rious=20 APIs (Javascript) to get device and network information such as network typ= e,=20 available bandwidth, battery status, and so on...Although it is beyond scop= e of=20 IETF, but needs to be discussed from the FMC architecture point of view.


Regards, Daniel
--=A0
Soohong Daniel Park
Samsung Electronics, Co.,=20 Ltd.



On Fri, Jun 8, 2012 at 11:56 PM, John Kaippallim= alil=20 <John.Kaippallimalil@huawei.com> wrote:

Agree=20 with Pierrick that is useful to look from an IETF=20 viewpoint.

The=20 fmc requirements draft http://www.ietf.org/id/draft-schott= -fmc-requirements-00.txt=20 is a good place to start.

=A0

-John

=A0

=A0

From:=20 fmc-bounces@iet= f.org=20 [mailto:fmc-bou= nces@ietf.org] On Behalf Of THIEBAUT, LAURENT=20 (LAURENT)
Sent: Friday, June 08, 2012 3:12 AM
To: pierrick.seite@= orange.com; = charliep@computer.org;=20 tso@zteusa.comCc:=20 fmc@ietf.org; david.i.allan@er= icsson.com
Subject: Re: [fmc] FMC=20 BoF at IETF 84?

=A0

= =A0

= =A0

Hello all=

I support= Pierrick

Best rega= rds

Laurent
ALCATEL-LUCENT <= u>

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org]=20 De la part de pierrick.seite@orange.com
Envoy=E9=A0: vendredi 8= =20 juin 2012 10:09
=C0=A0: charliep@computer.org; tso@zteusa.com
Cc=A0: david.i.allan@ericsson.com= ; fmc@ietf.org Objet=A0: Re: [fmc] FMC BoF at=20 IETF 84?

=A0

Hi,=

=A0

Actually,=20 this is a good discussion. I agree that gathering requirements for FMC is= a=20 good exercise, as long as it is done from an IETF standpoint. Otherwise, = we=20 duplicate BBF work.=

It=20 is also worth to identify existing IETF solutions , or ongoing work, that= =20 might meet these requirements. Then gap analysis should be done: what are= the=20 specific FMC issues that cannot be solved with current protocols, or usin= g=20 other SDOs mechanisms? That=92s a fair question which should be answered = before=20 going into a BoF, but the problem is that =A0early stage drafts do not=20 answer above question. In other words, =A0more work is needed before goin= g=20 into a BoF. It does not mean we should stop discussing; clearly, ongoing = work=20 in IETF/FMC is worth the effort but we still have not shown the interest = for a=20 dedicated FMC IETF WG=85 In my opinion=85

=A0

BR,

Pierrick=

=A0

De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org]=20 De la part de Charles E. Perkins
Envoy=E9=A0: vendredi 8= =20 juin 2012 08:54
=C0=A0: tso@zteusa.com
Cc=A0: fmc@ietf.org; david.i.allan@ericsson.com
Objet=A0: Re: [fmc]=20 FMC BoF at IETF 84?

=A0


Hello Tricci,

The dis= cussion at=20 IETF 83 and on the mailing list had, I thought, indicated that
there i= s=20 work to do.=A0 I can certainly imagine that the IETF should have=20 something
to say about managing device identity upon movement to a new= =20 point of
attachment when NATs are involved.=A0 From the BBF and ITU=20 documents, it
seemed quite reasonable to initiate some effort.=A0 I=20 gather you do not see the
need, or else see that it is already being= =20 met.=A0 If you'd like to supply some
pointers to relevant document= s that=20 would be interesting to me.

Anyway I am not the liaison to BBF or = ITU,=20 and in my experience at the IETF
people don't have to wait to be t= old what=20 needs to be done.=A0 Of course if
some other SDO does tell the IETF wh= at=20 needs to be done, it can be easier
to get started.

I wonder if= =20 anyone has tried to quantify the number of times that other
SDOs (not = IETF)=20 have duplicated effort.=A0 I'm personally familiar with one or
two= =20 cases.=A0 And, to some extent, duplication can be in the eyes of=20 the
beholder.=A0 For instance, why mess around with having NAIs or IMS= Is=20 when
we already have FQDNs??=A0 [just kidding, no worries, I do=20 understand]

Please also note that "identify" is not at a= ll the same as=20 "define".

Regarding the other points -- if you'd lik= e to supply=20 pointers to the relevant
work in other SDOs for "session continuity, policy distributi= on,=20 QoS
management, a= nd=20 application mobility"=A0 I'd be in= terested to=20 take a look.
Somehow, in discussions with other interested people, I h= ad=20 the impression
that these things were lacking.=A0 I don't even cla= im=20 that they are necessarily
within the jurisdiction of the IETF, but the= y=20 seemed to me to be well within
the scope of useful discussion at a=20 BoF.

And, finally, as always please note that the point of the BoF= =20 would be to
find out what if anything needs to be done.=A0 It's al= ways=20 O.K. to find out that
nothing needs to be done -- perhaps even=20 preferable.=A0 That was not at all
the sense I got from previous=20 discussion, though.

Regards,
Charlie P.




On=20 6/7/2012 10:59 PM, ts= o@zteusa.com wrote:

Dear Cha= rles,=20

Thank you very=20 much for your kind initiative for this work.
However, when I=20 examine the charter that you were describing below, many questions come t= o my=20 mind.

Could you=20 please help me to understand better on those considerations? =A0Please se= e=20 inline below..

Thank= s in=20 advance.
Tricci=20

"Charles E.=20 Perkins" <charliep@computer.org>=20
Sent by: fmc-bounces@ietf.org

06/07/2012=20 10:29 PM

To

"fmc@ietf.org" <fmc@ietf.org>=20

cc

=A0

Subject

[fmc]=20 FMC BoF at IETF 84?

=A0

=A0

=A0

<= /u>




Hello=20 folks,

It= 9;s time to=20 request a BoF during IETF 84 on the subject of FMC.

A suitable BoF agenda would be to ag= ree on an=20 effective definition for "fixed-mobile convergence" and to iden= tify the=20 initial steps along the way towards the goals. Here is some text that mig= ht be=20 used to make the BoF request...

Fixed-mobile convergence, as commonly=20 interpreted, should provide satisfactory user experience when the user=20 migrates between wide-area cellular networks and WLAN networks having lim= ited=20 range. =A0The latter are generally anchored on a fixed residential or=20 enterprise gateway. =A0Our understanding of the problem statement and=20 requirements has been derived from documents published by the BBF and the ITU= =20 [citations here].=20 Work is n= eeded in=20 the IETF to meet the requirements.=20

Tricci > May I ask, has BBF or ITU sent an= y specific request on=20 this work? =A0If so, what are the specific problems that BBF has asked=20 IETF, more specifically, this BOF, to address? =A0 The reason that I aske= d=20 this question is that, I work closely with my colleagues in BBF on many o= f=20 those FMC issues. =A0I would not like to see the duplicate work done in= =20 different SDOs and come up with different solutions? =A0

=A0While there are many possible sol= utions,=20 all of them will require some agreement on how to identify the wireless e= nd=20 device (e.g., handset). =A0

= Tricci > May=20 I ask, why would be the IETF's role to define the wireless end device= ?=20 =A0Shouldn't this be the responsibility of the 3GPP, 3GPP2, WiMAX and= WFA?=20 =A0Especially, I am sure that they already have their own definitions.=20 =A0So, what are the wireless end device that you have in mind that needs = to=20 be defined by IETF? =A0Could you please clarify? =A0

Other=20 requirements might include session continuity, policy distribution, QoS= =20 management, and application mobility.=20

Tricci > As the active contributors to 3GP= P and BBF work, all of=20 these subjects have been going on in both of these SDO, could you please= =20 clarify what are the specific aspects that are not covered by the other S= DOs=20 that need additional work to be done in IETF? =A0
=
The initial set= =20 of goals should be strictly limited, and future broadening is to depend b= oth=20 on the solutions adopted for the initial goal set as well as the evolving= =20 needs of the user and network operator communities.=20

Tricci > Sorry for asking so many question= s? =A0I have the=20 selfish reason to ensure that no duplicate work is done between IETF and = the=20 other SDOs that I am actively participated. =A0Thanks again in advance to= =20 help me to understand your proposal for this BOF. =A0

--
Regards,<= span style=3D"FONT-FAMILY:'Courier New'" lang=3D"FR">
Charlie P.

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

----------------------------------------------------=
----
ZTE=A0Information=A0S=
ecurity=A0Notice:=A0The=A0information=A0contained=A0in=A0this=A0mail=A0(and=
=A0any=A0attachment=A0transmitted=A0herewith)=A0is=A0privileged=A0and=A0con=
fidential=A0and=A0is=A0intended=A0for=A0the=A0exclusive=A0use=A0of=A0the=A0=
addressee(s).=A0=A0If=A0you=A0are=A0not=A0an=A0intended=A0recipient,=A0any=
=A0disclosure,=A0reproduction,=A0distribution=A0or=A0other=A0dissemination=
=A0or=A0use=A0of=A0the=A0information=A0contained=A0is=A0strictly=A0prohibit=
ed.=A0=A0If=A0you=A0have=A0received=A0this=A0mail=A0in=A0error,=A0please=A0=
delete=A0it=A0and=A0notify=A0us=A0immediately.
=A0

= =A0

___________________________=
____________________
fmc m=
ailing list
fm=
c@ietf.org
https://www.ie=
tf.org/mailman/listinfo/fmc

= =A0

-- 
Regards,
Charlie P.

_________________________________________= ______
fmc=20 mailing list
fmc@iet= f.org
https://www.ietf.org/mailman/listinfo/fmc






--00151747553ee45e2d04c2440079-- From Roland.Schott@telekom.de Tue Jun 12 11:28: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 A7F3D21F84D8 for ; Tue, 12 Jun 2012 11:28:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMoZjmbxN43I for ; Tue, 12 Jun 2012 11:28:17 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E15B321F84CF for ; Tue, 12 Jun 2012 11:28:16 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 12 Jun 2012 20:28:14 +0200 Received: from HE113676.emea1.cds.t-internal.com (10.134.99.29) by HE111630.emea1.cds.t-internal.com (10.134.93.22) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 12 Jun 2012 20:28:14 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 12 Jun 2012 20:28:14 +0200 From: To: Date: Tue, 12 Jun 2012 20:28:13 +0200 Thread-Topic: New Version Notification for draft-schott-fmc-requirements-01.txt Thread-Index: Ac1Ix/pR2SXksYZsRhyhBx5w0WPYHAAADsow Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434CE2B44@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: hassnaa.moustafa@orange.com, sophie.durel@orange.com, Dirk.von-Hugo@telekom.de Subject: [fmc] New Version Notification for draft-schott-fmc-requirements-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, 12 Jun 2012 18:28:17 -0000 Hi all, we have posted a new version of draft-schott-fmc-requirements-01.txt. Sophie Durel and Hasnaa Moustafa are now editors, too. We have added a section about streaming. Please use this version for further discussion on the list. Regards Roland ------- A new version of I-D, draft-schott-fmc-requirements-01.txt has been successfully submitted by Roland Schott and posted to the IETF repository. Filename: draft-schott-fmc-requirements Revision: 01 Title: Requirements on Fixed Mobile Convergence Creation date: 2012-06-12 WG ID: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-schott-fmc-requi= rements-01.txt Status: http://datatracker.ietf.org/doc/draft-schott-fmc-requireme= nts Htmlized: http://tools.ietf.org/html/submission.filename }}-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-schott-fmc-requ= irements-01 Abstract: This document provides a brief overview of the FMC (Fixed Mobile Convergence) architecture and related works. The purpose of the document is to sketch a big picture for the FMC activity to ease identifying whether specification effort is required within IETF. This document identifies and analyzes some of issues that have arisen so far and elaborates a set of requirements for the FMC system. The IETF Secretariat From charliep@computer.org Tue Jun 12 14:50:26 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94F211E8073 for ; Tue, 12 Jun 2012 14:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=1.291, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G77yq7IY7STy for ; Tue, 12 Jun 2012 14:50:24 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3321F847D for ; Tue, 12 Jun 2012 14:50:24 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SeYyk-0002VZ-SJ; Tue, 12 Jun 2012 17:50:23 -0400 Message-ID: <4FD7B99B.1050804@computer.org> Date: Tue, 12 Jun 2012 14:50:19 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roland.Schott@telekom.de References: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434CE2B44@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D1434CE2B44@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8633821d6452742307bc624018e18e9f43350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: hassnaa.moustafa@orange.com, sophie.durel@orange.com, fmc@ietf.org, Dirk.von-Hugo@telekom.de Subject: Re: [fmc] New Version Notification for draft-schott-fmc-requirements-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, 12 Jun 2012 21:50:26 -0000 Hello folks, I have some comments on the new draft. First, I think it would be better to focus on network attachment and mobility aspects of the problem. We don't need to include network discovery and selection as part of the FMC problem. For example, we could limit ourselves to making a solution that enables the desirable FMC outcomes based on the presumption that the access networks are already determined. This fits naturally with the way that a candidate access network is first discovered before the attachment (or handover) is initiated. I am also worried about bundling in content adaptation as part of the problem space. This was mentioned at the IETF 83 Bar BoF. There, it was suggested that the IETF might specify some means of transporting content adaptation commands, without specifying the commands themselves. That is much more reasonable, but I'd still suggest that we could profitably delay that part of the solution until we at least figure out how to authenticate and attach devices to the candidate access networks. Similar comments apply to streaming. Finally, I think that we should not be limited to only the solutions for HOST_ID that are enumerated in ietf-intarea-nat-reveal-analysis. Regards, Charlie P. On 6/12/2012 11:28 AM, Roland.Schott@telekom.de wrote: > Hi all, > > we have posted a new version of draft-schott-fmc-requirements-01.txt. > Sophie Durel and Hasnaa Moustafa are now editors, too. > We have added a section about streaming. > Please use this version for further discussion on the list. > > Regards > > Roland > > ------- > > > A new version of I-D, draft-schott-fmc-requirements-01.txt > has been successfully submitted by Roland Schott and posted to the > IETF repository. > > Filename: draft-schott-fmc-requirements > Revision: 01 > Title: Requirements on Fixed Mobile Convergence > Creation date: 2012-06-12 > WG ID: Individual Submission > Number of pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-schott-fmc-requirements-01.txt > Status: http://datatracker.ietf.org/doc/draft-schott-fmc-requirements > Htmlized: http://tools.ietf.org/html/submission.filename }}-01 > Diff: http://tools.ietf.org/rfcdiff?url2=draft-schott-fmc-requirements-01 > > Abstract: > This document provides a brief overview of the FMC (Fixed Mobile > Convergence) architecture and related works. The purpose of the > document is to sketch a big picture for the FMC activity to ease > identifying whether specification effort is required within IETF. > This document identifies and analyzes some of issues that have arisen > so far and elaborates a set of requirements for the FMC system. > > > > > The IETF Secretariat > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > -- Regards, Charlie P. From sarikaya2012@gmail.com Tue Jun 19 07:56: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 0A94921F8540 for ; Tue, 19 Jun 2012 07:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOPFlRRkKAm9 for ; Tue, 19 Jun 2012 07:56:27 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3621F853E for ; Tue, 19 Jun 2012 07:56:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5201409ghb.31 for ; Tue, 19 Jun 2012 07:56:27 -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:cc :content-type; bh=J6YwQLCXg60LZnzj2oLzzJKbkXxyothKfTfPjfHHA4M=; b=nqUOst7a6LLI6ACUEJ70KmAqCfgFFv9zsNwd8JNzZay2dOu1dt21coJBVZmoPu/TXg uCIsJLvwf1IkKR6meypUByaCD/uSLR9tx+T2U33WUIw5A5BY467Srh9Fz3TW0TDqk8Rr Dbn9gwnIxekY38w4B7eYV+udqaLB6fcmfY7yMTJLl/01bzpfJXjrMIj51qND04w5hgXb VgGP2zTAqxE3n1YpD2A86ZULJw+T8RTWqrhTmTSNYcVL18dWRiLfvQeqkDqiNTB8Hghs E1IzFw9BbXtpZ3Hb5lFk2Y8HxD+pqGg1oe+fcG9lgdlAVOREPqEU0/uexszSbYudfmoB 2byQ== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr1545462igc.0.1340117786737; Tue, 19 Jun 2012 07:56:26 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 19 Jun 2012 07:56:26 -0700 (PDT) Date: Tue, 19 Jun 2012 09:56:26 -0500 Message-ID: From: Behcet Sarikaya To: Daniel Park Content-Type: multipart/alternative; boundary=14dae934125ba2bc9d04c2d47cac Cc: fmc@ietf.org Subject: Re: [fmc] PS draft 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: Tue, 19 Jun 2012 14:56:28 -0000 --14dae934125ba2bc9d04c2d47cac Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, On Tue, Jun 12, 2012 at 5:33 AM, Daniel Park wrote: > Hi Dirk, > > Thanks for pointing the PS draft. I will go through this and get back to > here with more comments. > > Glancing at the draft... > > Figure 1 shows the assumed reference architecture of Fixed Mobile > Convergence Interworking for a Mobile (3GPP) Network and a fixed non- > 3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as > an example in document [WT203]. > > [daniel] ah...so you are very much leaning to the 3GPP perspective. Um. > fixed network is non-3GPP access network and mobile network is 3GPP > network. It seems controversial definition in IETF...In this assumption, > 3GPP and Non-3GPP interworking would be clearer than FMC in my thought. > You are right, the draft is too 3GPP centric. We tried to make it more like an IETF draft but we need to do more. > Anyhow, I will take a look at the draft... > Please do so. Regards, Behcet --14dae934125ba2bc9d04c2d47cac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Daniel,

On Tue, Jun 12, 2012 at 5:33 A= M, Daniel Park <soohongp@gmail.com> wrote:
Hi Dirk,

Thanks for pointing the PS draft. I will go thr= ough this and get back to here with more comments.

Glancing at the draft...
 Figure 1 shows the assumed refere=
nce architecture of Fixed Mobile
   Convergence Interworking for a Mobile (3GPP) Network and a fixed non-
   3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as
   an example in document [WT203].
[daniel] ah...so you are very much leaning to the 3GPP perspecti= ve. Um. fixed network is non-3GPP access network and mobile network is 3GPP= network. It seems=A0controversial definition in IETF...In this assumption,= 3GPP and Non-3GPP interworking would be clearer than FMC in my thought.

You are right, the draft is too 3GPP centric. W= e tried to make it more like an IETF draft but we need to do more.
=A0
Anyhow, I will take a look at the draft...

Please do so.

Regards,

Behcet

--14dae934125ba2bc9d04c2d47cac--