From ietf-secretariat@ietf.org Tue Apr 3 14:57:44 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 7FE5B21F84C9; Tue, 3 Apr 2012 14:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 7-nZ617G0Omr; Tue, 3 Apr 2012 14:57:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C821F84C8; Tue, 3 Apr 2012 14:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List Cc: sarikaya2012@gmail.com, Dirk.von-Hugo@telekom.de, fmc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120403215743.6261.84481.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2012 14:57:43 -0700 Subject: [fmc] New Non-WG Mailing List: fmc -- Fixed Mobile Convergence 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, 03 Apr 2012 21:57:44 -0000 A new IETF non-working group email list has been created. List address: fmc@ietf.org Archive: http://www.ietf.org/mail-archive/web/fmc/ To subscribe: https://www.ietf.org/mailman/listinfo/fmc Purpose: The purpose of this list is the focused discussion on the issues s= urrounding the interactions of fixed and mobile networks. Of specific inter= est are issues with serving access to multi-interface terminals that requir= es the sharing of subscribers' policies between the fixed and mobile networ= ks. = For additional information, please contact the list administrators. From bi.yifeng@zte.com.cn Wed Apr 4 17:51:20 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87611E8086 for ; Wed, 4 Apr 2012 17:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 myE6eIXkRF1w for ; Wed, 4 Apr 2012 17:51:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5311E8074 for ; Wed, 4 Apr 2012 17:51:15 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Thu, 5 Apr 2012 08:51:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 70481.1166107848; Thu, 5 Apr 2012 08:36:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q350p76v032426 for ; Thu, 5 Apr 2012 08:51:07 +0800 (GMT-8) (envelope-from bi.yifeng@zte.com.cn) To: fmc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: bi.yifeng@zte.com.cn Date: Thu, 5 Apr 2012 08:50:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-05 08:51:08, Serialize complete at 2012-04-05 08:51:08 Content-Type: multipart/alternative; boundary="=_alternative 0004AD3D482579D7_=" X-MAIL: mse02.zte.com.cn q350p76v032426 X-Mailman-Approved-At: Thu, 05 Apr 2012 07:50:28 -0700 Subject: [fmc] to subscribe FMC discussion. thanks! 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, 05 Apr 2012 00:51:20 -0000 This is a multipart message in MIME format. --=_alternative 0004AD3D482579D7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ICBCUiENCg0KPT09PT09PT09PT09PT09PT09PQ0KIFlpRmVuZyBCaSAvILHP0tS35Q0KIFpURSBD b3Jwb3JhdGlvbg0KPT09PT09PT09PT09PT09PT09PQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0004AD3D482579D7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDtCUiE8YnI+ DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PGJyPg0KIFlpRmVuZyBCaSAvILHP0tS35Txicj4N CiBaVEUgQ29ycG9yYXRpb248YnI+DQo9PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0004AD3D482579D7_=-- From sarikaya2012@gmail.com Thu Apr 5 09:08:02 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 5977721F86D4 for ; Thu, 5 Apr 2012 09:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 jKBV1oW0Kdby for ; Thu, 5 Apr 2012 09:08:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA35421F85AD for ; Thu, 5 Apr 2012 09:08:01 -0700 (PDT) Received: by ggmi1 with SMTP id i1so881527ggm.31 for ; Thu, 05 Apr 2012 09:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=Yvqf/n6PJa4drdYoYVzGdv6dgHMVkwqlZyxuIhQrfxs=; b=pz0+9d20ugA1cs5GFUDAM/3HS1d0kzZVVZbesw+ze/mtY3lZxgajQwWXzVMxSO+CmU uy7vsfIcRE0oewKL/XiCDZlFs2sMVZpSHYzbY0RehDTJft4kELbAZ4h8euYZC4je4Wbq pWKo7k2Avp1bv5ZF7w188R8gnKANiw10trxlGspcJNb+R2NMrcbSIwc0wDOLi/tPz53Q lGWrZ2/pSDIfsJBqB091r5gSBEq2GPCMz21NJgkUr7tuaOphZDnpRQ0ca820JPxNzyfm fE8RVVVbLUNrD0A7OV1Lg1Cf0UexPUGCKB95sletmKPL2HT1iKHVhJMpGIdSPmqoXiJ/ bRVA== MIME-Version: 1.0 Received: by 10.50.85.232 with SMTP id k8mr5464305igz.16.1333642080980; Thu, 05 Apr 2012 09:08:00 -0700 (PDT) Received: by 10.231.141.146 with HTTP; Thu, 5 Apr 2012 09:08:00 -0700 (PDT) Date: Thu, 5 Apr 2012 11:08:00 -0500 Message-ID: From: Behcet Sarikaya To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [fmc] Call for drafts 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, 05 Apr 2012 16:08:02 -0000 Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet From tso@zteusa.com Thu Apr 5 14:31: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 8921021F859A; Thu, 5 Apr 2012 14:31: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 bP2+mhvkPatE; Thu, 5 Apr 2012 14:31: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 0B14A21F8596; Thu, 5 Apr 2012 14:31:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 04:54:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74260.3857953315; Fri, 6 Apr 2012 05:31:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q35LVYmq069681; Fri, 6 Apr 2012 05:31:34 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: 9978E9C2:6103B550-882579D7:0075E3B5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 14:31:19 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 05:31:34, Serialize complete at 2012-04-06 05:31:34 Content-Type: multipart/alternative; boundary="=_alternative 00763D7A882579D7_=" X-MAIL: mse02.zte.com.cn q35LVYmq069681 Cc: David Allan I , fmc-bounces@ietf.org, fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 21:31:46 -0000 This is a multipart message in MIME format. --=_alternative 00763D7A882579D7_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, Please allow me to repeat my comment before on the wrong DMM mailing list. :) My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF? At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF? I sincerely believe that this is way too immature to ask for a draft for "FMC". I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF. Thanks. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/05/2012 09:08 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] Call for drafts Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00763D7A882579D7_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list.  :)

My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF.  

Thanks.
Tricci




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

04/05/2012 09:08 AM
Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts





Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00763D7A882579D7_=-- From sarikaya2012@gmail.com Thu Apr 5 14:48:35 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7850A21F86A0 for ; Thu, 5 Apr 2012 14:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 5b9uj1ZX90Gq for ; Thu, 5 Apr 2012 14:48:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7001A21F861E for ; Thu, 5 Apr 2012 14:48:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so2778209iaz.31 for ; Thu, 05 Apr 2012 14:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JVXdK/JB7QWgsdg2AGg+PssF+uXwHc+fOdF6zINMOAg=; b=STkBbJ1rhCsqPIvDDM/LO0CRy8PFb9GmXiHRuH7UuN9L78VBFqtxm32/BTXlnZnY5g JO26h4VK/QT9aupJ/bzqSy3PR3nhacpxH0tL/45m559Bz1Gk7USE8jTluEEUbA+Fs1mt 5wsOhYUbmxt9PXWwzWsPuTntztd8VEiyc+Z4gJcBDmCQ9rmHC2bXMUVDRxsG67Jw46us n8Vb3rV2nIVG46NCX12PKA0D7p8m88rRDi7zPyFFZPspkvfBQ1x8URSOxOceNflRyETm K2zsYK5EhoWPTHvwMKrAMZFV7FQAHXO+9yvBbYBR+YSaKTZSJOdd3FQj0Du2iBSpmWjb aTZQ== MIME-Version: 1.0 Received: by 10.50.189.129 with SMTP id gi1mr3472847igc.16.1333662513946; Thu, 05 Apr 2012 14:48:33 -0700 (PDT) Received: by 10.231.141.146 with HTTP; Thu, 5 Apr 2012 14:48:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Apr 2012 16:48:33 -0500 Message-ID: From: Behcet Sarikaya To: tso@zteusa.com Content-Type: multipart/alternative; boundary=14dae9340a8364e0da04bcf58069 Cc: fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 21:48:35 -0000 --14dae9340a8364e0da04bcf58069 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tricci, In IETF discussions are based on the drafts. I think you and I are saying the same thing. Behcet On Thu, Apr 5, 2012 at 4:31 PM, wrote: > Dear Behcet, > > Please allow me to repeat my comment before on the wrong DMM mailing list= . > :) > > My understanding for the objective of this mailing list discussion is to > determine if there is any IETF specific issue that needs to be resolved > based on the FMC network solution that has been defined by 3GPP and BBF? > > At this point, there is no understanding or agreement on what the problem > statement is for FMC in the context of IETF? I sincerely believe that th= is > is way too immature to ask for a draft for "FMC". > > I believe the agreement from last IETF meeting discussion was to continue > to research on what is the problem statement before we can determine our > next step on this work in IETF. > > Thanks. > Tricci > > > > > *Behcet Sarikaya * > Sent by: fmc-bounces@ietf.org > > 04/05/2012 09:08 AM > Please respond to > sarikaya@ieee.org > > To > fmc@ietf.org > cc > Subject > [fmc] Call for drafts > > > > > Hello, > > We would like to solicit drafts on fmc to be submitted in the form: > > draft-name-fmc-topic > > Please submit your draft and get them discussed on this list. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --14dae9340a8364e0da04bcf58069 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tricci,

In IETF discussions are based on the drafts.

I thi= nk you and I are saying the same thing.

Behcet

On Thu, Apr 5, 2012 at 4:31 PM, <tso@zteusa.com> wrote:
Dear Be= hcet,

Please allow me to repeat my comme= nt before on the wrong DMM mailing list. =A0:)

My understanding for the objective= of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF? =A0

At this point, there is no underst= anding or agreement on what the problem statement is for FMC in the context of IETF? =A0I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last = IETF meeting discussion was to continue to research on what is the problem state= ment before we can determine our next step on this work in IETF. =A0

Thanks.
Tricci




Behcet Sarikaya &= lt;sarikaya2012= @gmail.com>
Sent by: fmc-bounces@ietf.org

04/05/2012 09:08 AM

Please respond t= o
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts<= /td>





Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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

 

--------------------------------------------------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

--14dae9340a8364e0da04bcf58069-- From tso@zteusa.com Thu Apr 5 15:01: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 D632C21F868A for ; Thu, 5 Apr 2012 15:01:10 -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 cYXO3LuHdTwe for ; Thu, 5 Apr 2012 15:01:10 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2065B21F85C2 for ; Thu, 5 Apr 2012 15:01:03 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Fri, 6 Apr 2012 05:24:15 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.3334674061; Fri, 6 Apr 2012 06:00:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q35M0u2V033301; Fri, 6 Apr 2012 06:00:56 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: F1AEF4F8:9B74894B-882579D7:00780E8F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 15:00:40 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 06:00:56, Serialize complete at 2012-04-06 06:00:56 Content-Type: multipart/alternative; boundary="=_alternative 0078ED6D882579D7_=" X-MAIL: mse01.zte.com.cn q35M0u2V033301 Cc: David Allan I , fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 22:01:11 -0000 This is a multipart message in MIME format. --=_alternative 0078ED6D882579D7_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, Thank you for your kind and prompt response. Actually, my interpretation from last week IETF offline discussion is that, we will try to identify FMC issue in the context of IETF on the mailing list first and then we can discuss them topic-by-topic. I agree with you that, in order to capture those issues, we will need a draft in IETF. However, I sincerely believe that, it is way to early at this point to ask for a draft. Could you please help us to identify any issue that you have in mind, if any, that we should discuss at this point? As for the last week list that you have kindly prepared, we see no major work is needed yet from IETF. I sincerely hope that the purpose of this mailing list is not to use to come out with a draft unless we have issue that needs to be resolved by IETF, correct? Thanks in advance. Tricci Behcet Sarikaya 04/05/2012 02:48 PM Please respond to sarikaya@ieee.org To tso@zteusa.com cc fmc@ietf.org Subject Re: [fmc] Call for drafts Hi Tricci, In IETF discussions are based on the drafts. I think you and I are saying the same thing. Behcet On Thu, Apr 5, 2012 at 4:31 PM, wrote: Dear Behcet, Please allow me to repeat my comment before on the wrong DMM mailing list. :) My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF? At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF? I sincerely believe that this is way too immature to ask for a draft for "FMC". I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF. Thanks. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/05/2012 09:08 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] Call for drafts Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0078ED6D882579D7_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

Thank you for your kind and prompt response.

Actually, my interpretation from last week IETF offline discussion is that, we will try to identify FMC issue in the context of IETF on the mailing list first and then we can discuss them topic-by-topic.  

I agree with you that, in order to capture those issues, we will need a draft in IETF.  

However, I sincerely believe that, it is way to early at this point to ask for a draft.  Could you please help us to identify any issue that you have in mind, if any, that we should discuss at this point?  As for the last week list that you have kindly prepared, we see no major work is needed yet from IETF.  

I sincerely hope that the purpose of this mailing list is not to use to come out with a draft unless we have issue that needs to be resolved by IETF, correct?

Thanks in advance.  
Tricci




Behcet Sarikaya <sarikaya2012@gmail.com>

04/05/2012 02:48 PM
Please respond to
sarikaya@ieee.org
To
tso@zteusa.com
cc
fmc@ietf.org
Subject
Re: [fmc] Call for drafts





Hi Tricci,

In IETF discussions are based on the drafts.

I think you and I are saying the same thing.

Behcet
On Thu, Apr 5, 2012 at 4:31 PM, <tso@zteusa.com> wrote:
Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list.  :)

My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF.  

Thanks.
Tricci



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

04/05/2012 09:08 AM


Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts
Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0078ED6D882579D7_=-- From marc.blanchet@viagenie.ca Thu Apr 5 15:14:14 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 60C1621F86B0; Thu, 5 Apr 2012 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 qE-e1xQ4yRcm; Thu, 5 Apr 2012 15:14:13 -0700 (PDT) Received: from blues.viagenie.ca (blues.viagenie.ca [66.228.45.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA4121F85D4; Thu, 5 Apr 2012 15:14:13 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by blues.viagenie.ca (Postfix) with ESMTPSA id 2A3EC1C269; Thu, 5 Apr 2012 18:14:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1FF95092-2025-4C86-81D9-931668905928" From: Marc Blanchet In-Reply-To: Date: Thu, 5 Apr 2012 18:14:11 -0400 Message-Id: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> References: To: tso@zteusa.com X-Mailer: Apple Mail (2.1257) Cc: fmc@ietf.org, sarikaya@ieee.org, fmc-bounces@ietf.org, David Allan I Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 22:14:14 -0000 --Apple-Mail=_1FF95092-2025-4C86-81D9-931668905928 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 to me, the vehicle is not so important: mailing list, draft, blog, web = page, tracker, .... But as Behcet is saying, IETF practice is based on = drafts, which have a few good properties. So make your point using = whatever method, and don't forget that draft is probably the preferred = way. Marc. Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit : > Dear Behcet,=20 >=20 > Please allow me to repeat my comment before on the wrong DMM mailing = list. :)=20 >=20 > My understanding for the objective of this mailing list discussion is = to determine if there is any IETF specific issue that needs to be = resolved based on the FMC network solution that has been defined by 3GPP = and BBF? =20 >=20 > At this point, there is no understanding or agreement on what the = problem statement is for FMC in the context of IETF? I sincerely = believe that this is way too immature to ask for a draft for "FMC".=20 >=20 > I believe the agreement from last IETF meeting discussion was to = continue to research on what is the problem statement before we can = determine our next step on this work in IETF. =20 >=20 > Thanks.=20 > Tricci=20 >=20 >=20 >=20 >=20 > Behcet Sarikaya =20 > Sent by: fmc-bounces@ietf.org > 04/05/2012 09:08 AM > Please respond to > sarikaya@ieee.org >=20 > To > fmc@ietf.org > cc > Subject > [fmc] Call for drafts >=20 >=20 >=20 >=20 >=20 > Hello, >=20 > We would like to solicit drafts on fmc to be submitted in the form: >=20 > draft-name-fmc-topic >=20 > Please submit your draft and get them discussed on this list. >=20 > Regards, >=20 > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc --Apple-Mail=_1FF95092-2025-4C86-81D9-931668905928 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 to = me, the vehicle is not so important: mailing list, draft, blog, web = page, tracker, .... But as Behcet is saying, IETF practice is based on = drafts, which have a few good properties. So make your point using = whatever method, and don't forget that draft is probably the preferred = way.

Marc.

Le 2012-04-05 =E0 = 17:31, tso@zteusa.com a =E9crit = :

Dear Behcet,

Please allow me to repeat my = comment before on the wrong DMM mailing list.  :)

My understanding for the = objective of this mailing list discussion is to determine if there is any IETF = specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no = understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from = last IETF meeting discussion was to continue to research on what is the problem = statement before we can determine our next step on this work in IETF. =  

Thanks.
Tricci




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

04/05/2012 09:08 AM <= /tr>
Please = respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] Call for = drafts





Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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

 

--------------------------------------------------------
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
_______________________________________________
fmc mailing = list
fmc@ietf.org
https://www.ietf.org/mail= man/listinfo/fmc

= --Apple-Mail=_1FF95092-2025-4C86-81D9-931668905928-- From tso@zteusa.com Thu Apr 5 15:36: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 8623121F8685; Thu, 5 Apr 2012 15:36:13 -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 koJUhTzQpPF7; Thu, 5 Apr 2012 15:36:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C166E21F863E; Thu, 5 Apr 2012 15:36:11 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 05:59:23 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74260.4077022689; Fri, 6 Apr 2012 06:35:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q35MV3pT076164; Fri, 6 Apr 2012 06:31:03 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> To: Marc Blanchet MIME-Version: 1.0 X-KeepSent: 90CE2207:E93E6852-882579D7:007AEAC9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 15:30:48 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 06:31:03, Serialize complete at 2012-04-06 06:31:03 Content-Type: multipart/alternative; boundary="=_alternative 007BAF82882579D7_=" X-MAIL: mse02.zte.com.cn q35MV3pT076164 Cc: fmc-bounces@ietf.org, sarikaya@ieee.org, fmc@ietf.org, David Allan I Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 22:36:13 -0000 This is a multipart message in MIME format. --=_alternative 007BAF82882579D7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marc,=20 Not trying to challenge IETF approach to support discussions for=20 addressing issue.=20 However, the context of the discussion last week which I try to refer for= =20 this mailing list NOW to propose a draft is that - we have NOT even agreed= =20 on what, if any, FMC issue in the context of the IETF that we need to=20 address.=20 To blindly go ahead to propose a draft without any basic discussions and=20 understanding among ourselves, IMHO, this is immature. Hoping that you=20 can understand where am I coming from. Thanks. Cheers. Tricci=20 Marc Blanchet =20 04/05/2012 03:14 PM To tso@zteusa.com cc sarikaya@ieee.org, David Allan I ,=20 fmc-bounces@ietf.org, fmc@ietf.org Subject Re: [fmc] Call for drafts to me, the vehicle is not so important: mailing list, draft, blog, web=20 page, tracker, .... But as Behcet is saying, IETF practice is based on=20 drafts, which have a few good properties. So make your point using=20 whatever method, and don't forget that draft is probably the preferred=20 way. Marc. Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit : Dear Behcet,=20 Please allow me to repeat my comment before on the wrong DMM mailing list.= =20 :)=20 My understanding for the objective of this mailing list discussion is to=20 determine if there is any IETF specific issue that needs to be resolved=20 based on the FMC network solution that has been defined by 3GPP and BBF? = =20 At this point, there is no understanding or agreement on what the problem= =20 statement is for FMC in the context of IETF? I sincerely believe that=20 this is way too immature to ask for a draft for "FMC".=20 I believe the agreement from last IETF meeting discussion was to continue= =20 to research on what is the problem statement before we can determine our=20 next step on this work in IETF. =20 Thanks.=20 Tricci=20 Behcet Sarikaya =20 Sent by: fmc-bounces@ietf.org 04/05/2012 09:08 AM=20 Please respond to sarikaya@ieee.org To fmc@ietf.org=20 cc Subject [fmc] Call for drafts Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 007BAF82882579D7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Marc,

Not trying to challenge IETF approac= h to support discussions for addressing issue.

However, the context of the discussi= on last week which I try to refer for this mailing list NOW to propose a draft is that - we have NOT even agreed on what, if any, FMC issue in the context of the IETF that we need to address.  

To blindly go ahead to propose a dra= ft without any basic discussions and understanding among ourselves, IMHO, this is immature.  Hoping that you can understand where am I coming from. Thanks.

Cheers.
Tricci



Marc Blanchet <mar= c.blanchet@viagenie.ca>

04/05/2012 03:14 PM

To
tso@zteusa.com
cc
sarikaya@ieee.org, David Allan I <= ;david.i.allan@ericsson.com>, fmc-bounces@ietf.org, fmc@ietf.org
Subject
Re: [fmc] Call for drafts




to me, the vehicle is not so important: mailing list, draft, blog, web page, tracker, .... But as Behcet is saying, IETF practice is based on drafts, which have a few good properties. So make your point using whatever method, and don't forget that draft is probably the preferre= d way.

Marc.

Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit :

Dear Behcet, <= br>
Please allow me to repeat my comment before on the wrong DMM mailing list.  :)

My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF.  

Thanks. Tricci



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

04/05/2012 09:08 AM
Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts







Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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



----------------------------------------------------= ----
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

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


--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 007BAF82882579D7_=-- From charliep@computer.org Thu Apr 5 16:05: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 2E6D321F86DF for ; Thu, 5 Apr 2012 16:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 gKlzirWOJ+Ku for ; Thu, 5 Apr 2012 16:05:37 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id E9FA021F8694 for ; Thu, 5 Apr 2012 16:05:36 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.70]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SFvkG-0000hD-Ez for fmc@ietf.org; Thu, 05 Apr 2012 19:05:36 -0400 Message-ID: <4F7E2549.9030404@computer.org> Date: Thu, 05 Apr 2012 16:05:45 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: fmc@ietf.org References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86cece089c5c6ca8d4778e7d2540aeae4c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [fmc] Call for drafts X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 23:05:37 -0000 Hello folks, I wonder if the terminology is, in itself, confusing. A long time ago, "FMC" meant something about having the Internet serve fixed hosts and mobile hosts in a uniform manner, so that applications could provide a uniform user experience. In some recent discussion, "fixed" meant either WLAN or "femtocell". "Convergence" meant "conformant distribution of policy controls". And, indeed, the proposed outlines of the solution space are quite restrictive [e.g., only to LTE subscribers], not including most of the traditional problems associated with "FMC". It wasn't obvious to me before I read the draft -- maybe it isn't obvious to other people what the intention is for this use of "FMC". Regards, Charlie P. From tso@zteusa.com Thu Apr 5 16:18:01 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 8C74321F8723; Thu, 5 Apr 2012 16:18:01 -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 4rg91-v422WN; Thu, 5 Apr 2012 16:18:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1C31721F8616; Thu, 5 Apr 2012 16:17:59 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 06:41:11 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74260.5128620679; Fri, 6 Apr 2012 07:17:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q35NCmXn080275; Fri, 6 Apr 2012 07:12:48 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <4F7E2549.9030404@computer.org> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> To: charliep@computer.org MIME-Version: 1.0 X-KeepSent: 0BB02AD9:7AA0B0A4-882579D7:007EFCF9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 16:12:33 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 07:12:48, Serialize complete at 2012-04-06 07:12:48 Content-Type: multipart/alternative; boundary="=_alternative 007F8213882579D7_=" X-MAIL: mse02.zte.com.cn q35NCmXn080275 Cc: David Allan I , fmc-bounces@ietf.org, fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 05 Apr 2012 23:18:01 -0000 This is a multipart message in MIME format. --=_alternative 007F8213882579D7_= Content-Type: text/plain; charset="US-ASCII" Dear Charlie, Thank you for raising the question from a non-3GPP and non-Broadband Forum perspectives. Actually, for today, the term "FMC", the "fixed" is referring to the Fixed Broadband Network which is NOT specific to WLAN or Femto, although it is often the major access technology that the device is attached to in order to connect to the Fixed Broadband Network. And, "Convergence" does NOT apply ONLY to policy control, although, policy control is one of the major aspects of the convergence requirement. If the purpose is to determine if there is any requirement in the context of IETF, I would like to suggest to keep the term "FMC" so that to make it easier to associate with the work that has been done in other SDOs. Thanks. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 04/05/2012 04:05 PM Please respond to charliep@computer.org To fmc@ietf.org cc Subject Re: [fmc] Call for drafts Hello folks, I wonder if the terminology is, in itself, confusing. A long time ago, "FMC" meant something about having the Internet serve fixed hosts and mobile hosts in a uniform manner, so that applications could provide a uniform user experience. In some recent discussion, "fixed" meant either WLAN or "femtocell". "Convergence" meant "conformant distribution of policy controls". And, indeed, the proposed outlines of the solution space are quite restrictive [e.g., only to LTE subscribers], not including most of the traditional problems associated with "FMC". It wasn't obvious to me before I read the draft -- maybe it isn't obvious to other people what the intention is for this use of "FMC". 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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 007F8213882579D7_= Content-Type: text/html; charset="US-ASCII" Dear Charlie,

Thank you for raising the question from a non-3GPP and non-Broadband Forum perspectives.

Actually, for today, the term "FMC", the "fixed" is referring to the Fixed Broadband Network which is NOT specific to WLAN or Femto, although it is often the major access technology that the device is attached to in order to connect to the Fixed Broadband Network.  

And, "Convergence" does NOT apply ONLY to policy control, although, policy control is one of the major aspects of the convergence requirement.

If the purpose is to determine if there is any requirement in the context of IETF, I would like to suggest to keep the term "FMC" so that to make it easier to associate with the work that has been done in other SDOs.  

Thanks.
Tricci



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

04/05/2012 04:05 PM
Please respond to
charliep@computer.org
To
fmc@ietf.org
cc
Subject
Re: [fmc] Call for drafts






Hello folks,

I wonder if the terminology is, in itself, confusing.
A long time ago, "FMC" meant something about having the
Internet serve fixed hosts and mobile hosts in a uniform
manner, so that applications could provide a uniform
user experience.

In some recent discussion, "fixed" meant either WLAN
or "femtocell".   "Convergence" meant "conformant
distribution of policy controls".  And, indeed, the
proposed outlines of the solution space are quite
restrictive [e.g., only to LTE subscribers], not
including most of the traditional problems associated
with "FMC".

It wasn't obvious to me before I read the draft --
maybe it isn't obvious to other people what the
intention is for this use of "FMC".

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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 007F8213882579D7_=-- From xueli@huawei.com Thu Apr 5 19:09:12 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 48F7B11E808E; Thu, 5 Apr 2012 19:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUpmKzGmto+X; Thu, 5 Apr 2012 19:09:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 041DF21F8564; Thu, 5 Apr 2012 19:09:10 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER74212; Thu, 05 Apr 2012 22:09:10 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:08:46 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:08:51 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.19]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 10:08:47 +0800 From: Xueli To: "tso@zteusa.com" , Marc Blanchet Thread-Topic: [fmc] Call for drafts Thread-Index: AQHNE0ZWUxaOITRCbkO4fwJ3lFw6K5aMOjeAgAAL+oCAAASlAIAAv+sA Date: Fri, 6 Apr 2012 02:09:37 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B41E6606A5@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B41E6606A5szxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: David Allan I , "sarikaya@ieee.org" , "fmc@ietf.org" , "fmc-bounces@ietf.org" Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 02:09:12 -0000 --_000_01FE63842C181246BBE4CF183BD159B41E6606A5szxeml528mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear, Tricci, I totally agree with Marc here . The work is promoted via many vehicles in = IETF, and draft is probably the preferred one. I am confused, why the draft work is against here. BR Li From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@z= teusa.com Sent: Friday, April 06, 2012 6:31 AM To: Marc Blanchet Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I Subject: Re: [fmc] Call for drafts Dear Marc, Not trying to challenge IETF approach to support discussions for addressing= issue. However, the context of the discussion last week which I try to refer for t= his mailing list NOW to propose a draft is that - we have NOT even agreed o= n what, if any, FMC issue in the context of the IETF that we need to addres= s. To blindly go ahead to propose a draft without any basic discussions and un= derstanding among ourselves, IMHO, this is immature. Hoping that you can u= nderstand where am I coming from. Thanks. Cheers. Tricci Marc Blanchet 04/05/2012 03:14 PM To tso@zteusa.com cc sarikaya@ieee.org, David Allan I , fmc-bounces@= ietf.org, fmc@ietf.org Subject Re: [fmc] Call for drafts to me, the vehicle is not so important: mailing list, draft, blog, web page= , tracker, .... But as Behcet is saying, IETF practice is based on drafts, = which have a few good properties. So make your point using whatever method,= and don't forget that draft is probably the preferred way. Marc. Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit : Dear Behcet, Please allow me to repeat my comment before on the wrong DMM mailing list. = :) My understanding for the objective of this mailing list discussion is to de= termine if there is any IETF specific issue that needs to be resolved based= on the FMC network solution that has been defined by 3GPP and BBF? At this point, there is no understanding or agreement on what the problem s= tatement is for FMC in the context of IETF? I sincerely believe that this = is way too immature to ask for a draft for "FMC". I believe the agreement from last IETF meeting discussion was to continue t= o research on what is the problem statement before we can determine our nex= t step on this work in IETF. Thanks. Tricci Behcet Sarikaya > Sent by: fmc-bounces@ietf.org 04/05/2012 09:08 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] Call for drafts Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_01FE63842C181246BBE4CF183BD159B41E6606A5szxeml528mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear, Tric= ci,

 = ;

I totally = agree with Marc here . The work is promoted via many vehicles in IETF,

and draft = is probably the preferred one.

I am confu= sed, why the draft work is against here.

 = ;

BR

Li

 = ;

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 6:31 AM
To: Marc Blanchet
Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David All= an I
Subject: Re: [fmc] Call for drafts

 

Dear Marc,

Not trying to challenge IETF approach to support discussion= s for addressing issue.

However, the context of the discussion last week which I tr= y to refer for this mailing list NOW to propose a draft is that - we have N= OT even agreed on what, if any, FMC issue in the context of the IETF that we need to address.  
To blindly go ahead to propose a draft without any basic di= scussions and understanding among ourselves, IMHO, this is immature.  = Hoping that you can understand where am I coming from. Thanks.

Cheers.
Tricci


Marc Blanchet <marc.b= lanchet@viagenie.ca>

04/05/2012 03:14 PM

To

tso@zteusa.com

cc

sarikaya@ieee.org, David Al= lan I <david.i.allan@ericsson.com>, fmc-bounces@ietf.org, fmc@ietf.or= g

Subject

Re: [fmc] Call for drafts

 

=


to me, the vehicle is not so important: mailing list, draft, blog, web page= , tracker, .... But as Behcet is saying, IETF practice is based on drafts, = which have a few good properties. So make your point using whatever method,= and don't forget that draft is probably the preferred way.

Marc.

Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit :

Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list. =  :)

My understanding for the objective of this mailing list discussion is to de= termine if there is any IETF specific issue that needs to be resolved based= on the FMC network solution that has been defined by 3GPP and BBF?  <= /span>

At this point, there is no understanding or agreement on what the problem s= tatement is for FMC in the context of IETF?  I sincerely believe that = this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue t= o research on what is the problem statement before we can determine our nex= t step on this work in IETF.  

Thanks.
Tricci


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

04/05/2012 09:08 AM

Please respond to
sarikaya@ieee.org

 

To

fmc@ietf.org

cc

Subject

[fmc] Call for drafts

=  

=



Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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



-------------------------------------------= -------------
ZTE Information Security Notice: The information contained in this mail= is solely property of the sender's organization. This mail communication i= s confidential. Recipients named above are obligated to maintain secrecy an= d are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and inten= ded solely for the use of the individual or entity to whom they are address= ed. If you have received this email in error please notify the originator o= f the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam sys= tem.

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

 
-------------------------------------------------=
-------
ZTE Information Security Notice:&n=
bsp;The information contained in this mail is=
 solely property of the sender's organization=
. This mail communication is confidential. Re=
cipients named above are obligated to maintai=
n secrecy and are not permitted to discl=
ose the contents of this communication to&nbs=
p;others.
This email and any files =
;transmitted with it are confidential and int=
ended solely for the use of the individu=
al or entity to whom they are addressed.=
 If you have received this email in =
;error please notify the originator of the&nb=
sp;message. Any views expressed in this messa=
ge are those of the individual sender.
This message has been scanned=
 for viruses and Spam by ZTE Anti-Spam&n=
bsp;system.
--_000_01FE63842C181246BBE4CF183BD159B41E6606A5szxeml528mbschi_-- From xueli@huawei.com Thu Apr 5 19:21:11 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 BE4A111E808E; Thu, 5 Apr 2012 19:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHUVdQK+vR9X; Thu, 5 Apr 2012 19:21:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AB87211E8086; Thu, 5 Apr 2012 19:21:10 -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 AEZ73039; Thu, 05 Apr 2012 22:21:10 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:19:46 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:19:52 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.19]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 10:19:46 +0800 From: Xueli To: "tso@zteusa.com" , "charliep@computer.org" Thread-Topic: [fmc] Call for drafts Thread-Index: AQHNE0ZWUxaOITRCbkO4fwJ3lFw6K5aMOjeAgAAL+oCAAASlAIAACcSAgAAB5oCAALfIYA== Date: Fri, 6 Apr 2012 02:20:35 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B41E6606B7@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B41E6606B7szxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "fmc@ietf.org" , "fmc-bounces@ietf.org" , David Allan I Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 02:21:11 -0000 --_000_01FE63842C181246BBE4CF183BD159B41E6606B7szxeml528mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Charlie and Tricci, Nowadays, actually, FMC is the fixed and mobile network convergence. Here, the fixed broadband network, which could be used as the transport ne= twork for WLAN or Femtocell access technology. In the FMC scenario, the coordination is required between the fixed transpo= rt network and the mobile network, such as policy control, QoS etc. BR Li From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@z= teusa.com Sent: Friday, April 06, 2012 7:13 AM To: charliep@computer.org Cc: David Allan I; fmc-bounces@ietf.org; fmc@ietf.org Subject: Re: [fmc] Call for drafts Dear Charlie, Thank you for raising the question from a non-3GPP and non-Broadband Forum = perspectives. Actually, for today, the term "FMC", the "fixed" is referring to the Fixed = Broadband Network which is NOT specific to WLAN or Femto, although it is of= ten the major access technology that the device is attached to in order to = connect to the Fixed Broadband Network. And, "Convergence" does NOT apply ONLY to policy control, although, policy = control is one of the major aspects of the convergence requirement. If the purpose is to determine if there is any requirement in the context o= f IETF, I would like to suggest to keep the term "FMC" so that to make it e= asier to associate with the work that has been done in other SDOs. Thanks. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 04/05/2012 04:05 PM Please respond to charliep@computer.org To fmc@ietf.org cc Subject Re: [fmc] Call for drafts Hello folks, I wonder if the terminology is, in itself, confusing. A long time ago, "FMC" meant something about having the Internet serve fixed hosts and mobile hosts in a uniform manner, so that applications could provide a uniform user experience. In some recent discussion, "fixed" meant either WLAN or "femtocell". "Convergence" meant "conformant distribution of policy controls". And, indeed, the proposed outlines of the solution space are quite restrictive [e.g., only to LTE subscribers], not including most of the traditional problems associated with "FMC". It wasn't obvious to me before I read the draft -- maybe it isn't obvious to other people what the intention is for this use of "FMC". 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 is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_01FE63842C181246BBE4CF183BD159B41E6606B7szxeml528mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Charl= ie and Tricci,

 = ;

Nowadays, = actually, FMC is the fixed and mobile network convergence.

Here, &nbs= p;the fixed broadband network, which could be used as the transport network= for WLAN or Femtocell access technology.

In the FMC= scenario, the coordination is required between the fixed transport network= and the mobile network, such as policy control, QoS etc.=

 = ;

BR

Li

 = ;

 = ;

From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 7:13 AM
To: charliep@computer.org
Cc: David Allan I; fmc-bounces@ietf.org; fmc@ietf.org
Subject: Re: [fmc] Call for drafts

 

Dear Charlie= ,

Thank you for raising the question from a non-3GPP and non-= Broadband Forum perspectives.

Actually, for today, the term "FMC", the "fi= xed" is referring to the Fixed Broadband Network which is NOT specific= to WLAN or Femto, although it is often the major access technology that th= e device is attached to in order to connect to the Fixed Broadband Network. =  

And, "Convergence" does NOT apply ONLY to policy = control, although, policy control is one of the major aspects of the conver= gence requirement.

If the purpose is to determine if there is any requirement = in the context of IETF, I would like to suggest to keep the term "FMC&= quot; so that to make it easier to associate with the work that has been done in other SDOs.  

Thanks.
Tricci


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

04/05/2012 04:05 PM

Please respond to
charliep@computer.org

To

fmc@ietf.org

cc

Subject

Re: [fmc] Call for drafts

 

=



Hello folks,

I wonder if the terminology is, in itself, confusing.
A long time ago, "FMC" meant something about having the<= br> Internet serve fixed hosts and mobile hosts in a uniform
manner, so that applications could provide a uniform
user experience.

In some recent discussion, "fixed" meant either WLAN
or "femtocell".   "Convergence" meant "co= nformant
distribution of policy controls".  And, indeed, the
proposed outlines of the solution space are quite
restrictive [e.g., only to LTE subscribers], not
including most of the traditional problems associated
with "FMC".

It wasn't obvious to me before I read the draft --
maybe it isn't obvious to other people what the
intention is for this use of "FMC".

Regards,
Charlie P.

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


 
-------------------------------------------------=
-------
ZTE Information Security Notice:&n=
bsp;The information contained in this mail is=
 solely property of the sender's organization=
. This mail communication is confidential. Re=
cipients named above are obligated to maintai=
n secrecy and are not permitted to discl=
ose the contents of this communication to&nbs=
p;others.
This email and any files =
;transmitted with it are confidential and int=
ended solely for the use of the individu=
al or entity to whom they are addressed.=
 If you have received this email in =
;error please notify the originator of the&nb=
sp;message. Any views expressed in this messa=
ge are those of the individual sender.
This message has been scanned=
 for viruses and Spam by ZTE Anti-Spam&n=
bsp;system.
--_000_01FE63842C181246BBE4CF183BD159B41E6606B7szxeml528mbschi_-- From tso@zteusa.com Thu Apr 5 19:30:05 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 E9E5B11E8086; Thu, 5 Apr 2012 19:30:05 -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 QCcuNmSlRPcm; Thu, 5 Apr 2012 19:30:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E953411E8073; Thu, 5 Apr 2012 19:30:03 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 09:53:01 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74260.5936926284; Fri, 6 Apr 2012 10:29:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q362QOY7047069; Fri, 6 Apr 2012 10:26:24 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <01FE63842C181246BBE4CF183BD159B41E6606A5@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <01FE63842C181246BBE4CF183BD159B41E6606A5@szxeml528-mbs.china.huawei.com> To: Xueli MIME-Version: 1.0 X-KeepSent: 5C7904D0:34E4278E-882579D8:000CF6B6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 19:26:09 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 10:26:25, Serialize complete at 2012-04-06 10:26:25 Content-Type: multipart/alternative; boundary="=_alternative 000D6586882579D8_=" X-MAIL: mse02.zte.com.cn q362QOY7047069 Cc: "fmc-bounces@ietf.org" , "sarikaya@ieee.org" , "fmc@ietf.org" , David Allan I , Marc Blanchet Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 02:30:06 -0000 This is a multipart message in MIME format. --=_alternative 000D6586882579D8_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Li,=20 I believe you have totally mistaken what was discussed. No one against to= =20 have a draft if there is something to write about? May I ask, what are the FMC issues that you have in mind that needs IETF=20 to address? Could you please share with us on this mailing list?=20 Thanks. Tricci=20 Xueli =20 04/05/2012 07:09 PM To "tso@zteusa.com" , Marc Blanchet=20 cc "fmc-bounces@ietf.org" , "sarikaya@ieee.org"=20 , "fmc@ietf.org" , David Allan I=20 Subject RE: [fmc] Call for drafts Dear, Tricci, =20 I totally agree with Marc here . The work is promoted via many vehicles in= =20 IETF,=20 and draft is probably the preferred one. I am confused, why the draft work is against here.=20 =20 BR Li =20 From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of=20 tso@zteusa.com Sent: Friday, April 06, 2012 6:31 AM To: Marc Blanchet Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I Subject: Re: [fmc] Call for drafts =20 Dear Marc,=20 Not trying to challenge IETF approach to support discussions for=20 addressing issue.=20 However, the context of the discussion last week which I try to refer for= =20 this mailing list NOW to propose a draft is that - we have NOT even agreed= =20 on what, if any, FMC issue in the context of the IETF that we need to=20 address. =20 To blindly go ahead to propose a draft without any basic discussions and=20 understanding among ourselves, IMHO, this is immature. Hoping that you=20 can understand where am I coming from. Thanks.=20 Cheers.=20 Tricci=20 Marc Blanchet =20 04/05/2012 03:14 PM=20 To tso@zteusa.com=20 cc sarikaya@ieee.org, David Allan I ,=20 fmc-bounces@ietf.org, fmc@ietf.org=20 Subject Re: [fmc] Call for drafts =20 to me, the vehicle is not so important: mailing list, draft, blog, web=20 page, tracker, .... But as Behcet is saying, IETF practice is based on=20 drafts, which have a few good properties. So make your point using=20 whatever method, and don't forget that draft is probably the preferred=20 way.=20 Marc.=20 Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit :=20 Dear Behcet,=20 Please allow me to repeat my comment before on the wrong DMM mailing list.= =20 :)=20 My understanding for the objective of this mailing list discussion is to=20 determine if there is any IETF specific issue that needs to be resolved=20 based on the FMC network solution that has been defined by 3GPP and BBF? = =20 At this point, there is no understanding or agreement on what the problem= =20 statement is for FMC in the context of IETF? I sincerely believe that=20 this is way too immature to ask for a draft for "FMC".=20 I believe the agreement from last IETF meeting discussion was to continue= =20 to research on what is the problem statement before we can determine our=20 next step on this work in IETF. =20 Thanks.=20 Tricci=20 Behcet Sarikaya =20 Sent by: fmc-bounces@ietf.org=20 04/05/2012 09:08 AM=20 Please respond to sarikaya@ieee.org =20 To fmc@ietf.org=20 cc Subject [fmc] Call for drafts =20 Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000D6586882579D8_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Li,

I believe you have totally mistaken what was discussed.  No one against to have a draft if there is someth= ing to write about?

May I ask, what are the FMC issues t= hat you have in mind that needs IETF to address?  Could you please share with us on this mailing list?

Thanks.
Tricci




Xueli <xueli@huawe= i.com>

04/05/2012 07:09 PM

To
"tso@zteusa.com" <tso@z= teusa.com>, Marc Blanchet <marc.blanchet@viagenie.ca>
cc
"fmc-bounces@ietf.org" <= ;fmc-bounces@ietf.org>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "fmc@ietf.org= " <fmc@ietf.org>, David Allan I <david.i.allan@ericsson.com>
Subject
RE: [fmc] Call for drafts




Dear, Tricci,
 
I totally agree with Ma= rc here . The work is promoted via many vehicles in IETF,
and draft is probably t= he preferred one.
I am confused, why the = draft work is against here.
 
BR
Li
 
From: fmc-bounces@ietf.org [ma= ilto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 6:31 AM
To: Marc Blanchet
Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I
Subject: Re: [fmc] Call for drafts
 
Dear Marc,

Not trying to challenge IETF approach to support discussions for addressing issue.

However, the context of the discussion last week which I try to refer for this mailing list NOW to propose a draft is that - we have NOT even agreed on what, if any, FMC issue in the context of the IETF that we need to addre= ss.  

To blindly go ahead to propose a draft without any basic discussions and understanding among ourselves, IMHO, this is immature.  Hoping that you can understand where am I coming from. Thanks.

Cheers.
Tricci

Marc Blanchet <marc.bla= nchet@viagenie.ca>

04/05/2012 03:14 PM


To
tso@zteusa.com
cc
sarikaya@ieee.org, David Allan I <davi= d.i.allan@ericsson.com>, fmc-bounces@ietf.org, fmc@ietf.org
Subject
Re: [fmc] Call for drafts

 







to me, the vehicle is not so important: mailing list, draft, blog, web page, tracker, .... But as Behcet is saying, IETF practice is based on drafts, which have a few good properties. So make your point using whatever method, and don't forget that draft is probably the preferred way.

Marc.

Le 2012-04-05 =E0 17:31, tso@zteusa.com= a =E9crit :

Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list.  :)

My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF.  

Thanks.
Tricci

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

04/05/2012 09:08 AM


Please respond to<= font size=3D3 color=3Dblue face=3D"Times New Roman">
sarikaya@ieee.org

 


To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts

 








Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

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

 
-----------------------------------= ---------------------
ZTE Information Security Notice: Th= e information contained in this mail is solely property of the sender's organ= ization. This mail communication is confidential. Recipients named above are obligat= ed to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitte= d with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for v= iruses and Spam by ZTE Anti-Spam system. 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 000D6586882579D8_=-- From xueli@huawei.com Thu Apr 5 19:57:24 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584D411E8099; Thu, 5 Apr 2012 19:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yb-SviaMAV9; Thu, 5 Apr 2012 19:57:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC87311E8073; Thu, 5 Apr 2012 19:57:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ74427; Thu, 05 Apr 2012 22:57:22 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:56:13 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 19:56:11 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.19]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 10:56:07 +0800 From: Xueli To: "tso@zteusa.com" Thread-Topic: [fmc] Call for drafts Thread-Index: AQHNE50te1LBBNnBqE2BpuuGQ7BhAJaNGSUQ Date: Fri, 6 Apr 2012 02:56:58 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B41E66073B@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <01FE63842C181246BBE4CF183BD159B41E6606A5@szxeml528-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B41E66073Bszxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "fmc-bounces@ietf.org" , "sarikaya@ieee.org" , "fmc@ietf.org" , David Allan I , Marc Blanchet Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 02:57:24 -0000 --_000_01FE63842C181246BBE4CF183BD159B41E66073Bszxeml528mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tricci, I should say no one makes a mistake, we are talking the same thing. The dra= fts of fmc are preferred to submitted about this discussion. BR Li From: tso@zteusa.com [mailto:tso@zteusa.com] Sent: Friday, April 06, 2012 10:26 AM To: Xueli Cc: David Allan I; fmc@ietf.org; fmc-bounces@ietf.org; Marc Blanchet; sarik= aya@ieee.org Subject: RE: [fmc] Call for drafts Dear Li, I believe you have totally mistaken what was discussed. No one against to = have a draft if there is something to write about? May I ask, what are the FMC issues that you have in mind that needs IETF to= address? Could you please share with us on this mailing list? Thanks. Tricci Xueli 04/05/2012 07:09 PM To "tso@zteusa.com" , Marc Blanchet cc "fmc-bounces@ietf.org" , "sarikaya@ieee.org" , "fmc@ietf.org" , David Allan I Subject RE: [fmc] Call for drafts Dear, Tricci, I totally agree with Marc here . The work is promoted via many vehicles in = IETF, and draft is probably the preferred one. I am confused, why the draft work is against here. BR Li From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@z= teusa.com Sent: Friday, April 06, 2012 6:31 AM To: Marc Blanchet Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I Subject: Re: [fmc] Call for drafts Dear Marc, Not trying to challenge IETF approach to support discussions for addressing= issue. However, the context of the discussion last week which I try to refer for t= his mailing list NOW to propose a draft is that - we have NOT even agreed o= n what, if any, FMC issue in the context of the IETF that we need to addres= s. To blindly go ahead to propose a draft without any basic discussions and un= derstanding among ourselves, IMHO, this is immature. Hoping that you can u= nderstand where am I coming from. Thanks. Cheers. Tricci Marc Blanchet 04/05/2012 03:14 PM To tso@zteusa.com cc sarikaya@ieee.org, David Allan I , fmc-bounces@= ietf.org, fmc@ietf.org Subject Re: [fmc] Call for drafts to me, the vehicle is not so important: mailing list, draft, blog, web page= , tracker, .... But as Behcet is saying, IETF practice is based on drafts, = which have a few good properties. So make your point using whatever method,= and don't forget that draft is probably the preferred way. Marc. Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit : Dear Behcet, Please allow me to repeat my comment before on the wrong DMM mailing list. = :) My understanding for the objective of this mailing list discussion is to de= termine if there is any IETF specific issue that needs to be resolved based= on the FMC network solution that has been defined by 3GPP and BBF? At this point, there is no understanding or agreement on what the problem s= tatement is for FMC in the context of IETF? I sincerely believe that this = is way too immature to ask for a draft for "FMC". I believe the agreement from last IETF meeting discussion was to continue t= o research on what is the problem statement before we can determine our nex= t step on this work in IETF. Thanks. Tricci Behcet Sarikaya > Sent by: fmc-bounces@ietf.org 04/05/2012 09:08 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] Call for drafts Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_01FE63842C181246BBE4CF183BD159B41E66073Bszxeml528mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Tricc= i,

 = ;

I should s= ay no one makes a mistake, we are talking the same thing. The drafts of fmc= are preferred to submitted about this discussion.

 = ;

BR

Li

 = ;

From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Friday, April 06, 2012 10:26 AM
To: Xueli
Cc: David Allan I; fmc@ietf.org; fmc-bounces@ietf.org; Marc Blanchet= ; sarikaya@ieee.org
Subject: RE: [fmc] Call for drafts

 

Dear Li,

I believe you have totally mistaken what was discussed. &nb= sp;No one against to have a draft if there is something to write about?

May I ask, what are the FMC issues that you have in mind th= at needs IETF to address?  Could you please share with us on this mail= ing list?

Thanks.
Tricci



Xueli <xueli@huawei.c= om>

04/05/2012 07:09 PM

To

"tso@zteusa.com" = <tso@zteusa.com>, Marc Blanchet <marc.blanchet@viagenie.ca>

cc

"fmc-bounces@ietf.org&= quot; <fmc-bounces@ietf.org>, "sarikaya@ieee.org" <sarik= aya@ieee.org>, "fmc@ietf.org" <fmc@ietf.org>, David Alla= n I <david.i.allan@ericsson.com>

Subject

RE: [fmc] Call for drafts

 

=


Dear, Tricci,
 
I totally agree with Marc = here . The work is promoted via many vehicles in IETF,
and draft is probably the = preferred one.
I am confused, why the dra= ft work is against here.
 
BR
Li
 
From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 6:31 AM
To: Marc Blanchet
Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan = I
Subject: Re: [fmc] Call for drafts
 
Dear Marc,

Not trying to challenge IETF approach to support discussions for addressing= issue.

However, the context of the discussion last week which I try to refer for t= his mailing list NOW to propose a draft is that - we have NOT even agreed o= n what, if any, FMC issue in the context of the IETF that we need to addres= s.  

To blindly go ahead to propose a draft without any basic discussions and un= derstanding among ourselves, IMHO, this is immature.  Hoping that you = can understand where am I coming from. Thanks.

Cheers.
Tricci

Marc Blanchet <marc.b= lanchet@viagenie.ca>

04/05/2012 03:14 PM

 

To

tso@zteusa.com

cc

sarikaya@ieee.org, David Al= lan I <david.i.allan@ericsson.com>, fmc-bounces@ietf.org, fmc@ietf.or= g

Subject

Re: [fmc] Call for drafts


 

 





to me, the vehicle is not so important: mailing list, draft, blog, web page= , tracker, .... But as Behcet is saying, IETF practice is based on drafts, = which have a few good properties. So make your point using whatever method,= and don't forget that draft is probably the preferred way.

Marc.

Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit :

Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list. =  :)

My understanding for the objective of this mailing list discussion is to de= termine if there is any IETF specific issue that needs to be resolved based= on the FMC network solution that has been defined by 3GPP and BBF?  <= /span>

At this point, there is no understanding or agreement on what the problem s= tatement is for FMC in the context of IETF?  I sincerely believe that = this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue t= o research on what is the problem statement before we can determine our nex= t step on this work in IETF.  

Thanks.
Tricci

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

04/05/2012 09:08 AM

 

Please respond to
sarikaya@ieee.org

 

 

To

fmc@ietf.org

cc

Subject

[fmc] Call for drafts


 

 






Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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


<= br> --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

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

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained = in this mail is solely property of the sender's organization. This mail com= munication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the co= ntents of this communication to others.
This email and any files transmitted with it are confidenti= al and intended solely for the use of the individual or entity to whom they= are addressed. If you have received this email in error please notify the originator of the message. Any views expressed = in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE A= nti-Spam system. 

 
-------------------------------------------------=
-------
ZTE Information Security Notice:&n=
bsp;The information contained in this mail is=
 solely property of the sender's organization=
. This mail communication is confidential. Re=
cipients named above are obligated to maintai=
n secrecy and are not permitted to discl=
ose the contents of this communication to&nbs=
p;others.
This email and any files =
;transmitted with it are confidential and int=
ended solely for the use of the individu=
al or entity to whom they are addressed.=
 If you have received this email in =
;error please notify the originator of the&nb=
sp;message. Any views expressed in this messa=
ge are those of the individual sender.
This message has been scanned=
 for viruses and Spam by ZTE Anti-Spam&n=
bsp;system.
--_000_01FE63842C181246BBE4CF183BD159B41E66073Bszxeml528mbschi_-- From tso@zteusa.com Thu Apr 5 20:14:56 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 38A5511E8073; Thu, 5 Apr 2012 20:14:56 -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=[AWL=0.000, 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 GmEEIzTfXuDf; Thu, 5 Apr 2012 20:14:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 084E711E8081; Thu, 5 Apr 2012 20:14:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 10:37:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74260.5936926284; Fri, 6 Apr 2012 11:14:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3637bQO099279; Fri, 6 Apr 2012 11:07:37 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <01FE63842C181246BBE4CF183BD159B41E66073B@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <01FE63842C181246BBE4CF183BD159B41E6606A5@szxeml528-mbs.china.huawei.com> <01FE63842C181246BBE4CF183BD159B41E66073B@szxeml528-mbs.china.huawei.com> To: Xueli MIME-Version: 1.0 X-KeepSent: 057F2081:126D2153-882579D8:00112032; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 20:07:22 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 11:07:38, Serialize complete at 2012-04-06 11:07:38 Content-Type: multipart/alternative; boundary="=_alternative 00112B6E882579D8_=" X-MAIL: mse02.zte.com.cn q3637bQO099279 Cc: "fmc-bounces@ietf.org" , "sarikaya@ieee.org" , "fmc@ietf.org" , David Allan I , Marc Blanchet Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 03:14:56 -0000 This is a multipart message in MIME format. --=_alternative 00112B6E882579D8_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Li,=20 Thanks. I look forward to see your draft.=20 Cheers. Tricci=20 Xueli =20 Sent by: fmc-bounces@ietf.org 04/05/2012 07:56 PM To "tso@zteusa.com" cc "fmc-bounces@ietf.org" , "sarikaya@ieee.org"=20 , "fmc@ietf.org" , David Allan I=20 , Marc Blanchet Subject Re: [fmc] Call for drafts Dear Tricci, =20 I should say no one makes a mistake, we are talking the same thing. The=20 drafts of fmc are preferred to submitted about this discussion.=20 =20 BR Li =20 From: tso@zteusa.com [mailto:tso@zteusa.com]=20 Sent: Friday, April 06, 2012 10:26 AM To: Xueli Cc: David Allan I; fmc@ietf.org; fmc-bounces@ietf.org; Marc Blanchet;=20 sarikaya@ieee.org Subject: RE: [fmc] Call for drafts =20 Dear Li,=20 I believe you have totally mistaken what was discussed. No one against to= =20 have a draft if there is something to write about?=20 May I ask, what are the FMC issues that you have in mind that needs IETF=20 to address? Could you please share with us on this mailing list?=20 Thanks.=20 Tricci=20 Xueli =20 04/05/2012 07:09 PM=20 To "tso@zteusa.com" , Marc Blanchet=20 =20 cc "fmc-bounces@ietf.org" , "sarikaya@ieee.org"=20 , "fmc@ietf.org" , David Allan I=20 =20 Subject RE: [fmc] Call for drafts =20 Dear, Tricci,=20 =20 I totally agree with Marc here . The work is promoted via many vehicles in= =20 IETF,=20 and draft is probably the preferred one.=20 I am confused, why the draft work is against here.=20 =20 BR=20 Li=20 =20 From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of=20 tso@zteusa.com Sent: Friday, April 06, 2012 6:31 AM To: Marc Blanchet Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I Subject: Re: [fmc] Call for drafts=20 =20 Dear Marc,=20 Not trying to challenge IETF approach to support discussions for=20 addressing issue.=20 However, the context of the discussion last week which I try to refer for= =20 this mailing list NOW to propose a draft is that - we have NOT even agreed= =20 on what, if any, FMC issue in the context of the IETF that we need to=20 address. =20 To blindly go ahead to propose a draft without any basic discussions and=20 understanding among ourselves, IMHO, this is immature. Hoping that you=20 can understand where am I coming from. Thanks.=20 Cheers.=20 Tricci=20 Marc Blanchet =20 04/05/2012 03:14 PM=20 =20 To tso@zteusa.com=20 cc sarikaya@ieee.org, David Allan I ,=20 fmc-bounces@ietf.org, fmc@ietf.org=20 Subject Re: [fmc] Call for drafts =20 =20 to me, the vehicle is not so important: mailing list, draft, blog, web=20 page, tracker, .... But as Behcet is saying, IETF practice is based on=20 drafts, which have a few good properties. So make your point using=20 whatever method, and don't forget that draft is probably the preferred=20 way.=20 Marc.=20 Le 2012-04-05 =E0 17:31, tso@zteusa.com a =E9crit :=20 Dear Behcet,=20 Please allow me to repeat my comment before on the wrong DMM mailing list.= =20 :)=20 My understanding for the objective of this mailing list discussion is to=20 determine if there is any IETF specific issue that needs to be resolved=20 based on the FMC network solution that has been defined by 3GPP and BBF? = =20 At this point, there is no understanding or agreement on what the problem= =20 statement is for FMC in the context of IETF? I sincerely believe that=20 this is way too immature to ask for a draft for "FMC".=20 I believe the agreement from last IETF meeting discussion was to continue= =20 to research on what is the problem statement before we can determine our=20 next step on this work in IETF. =20 Thanks.=20 Tricci=20 Behcet Sarikaya =20 Sent by: fmc-bounces@ietf.org=20 04/05/2012 09:08 AM=20 =20 Please respond to sarikaya@ieee.org =20 =20 To fmc@ietf.org=20 cc Subject [fmc] Call for drafts =20 =20 Hello, We would like to solicit drafts on fmc to be submitted in the form: draft-name-fmc-topic Please submit your draft and get them discussed on this list. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc=20 =20 --------------------------------------------------------=20 ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others.=20 This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender.=20 This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system.=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system._______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00112B6E882579D8_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Li,

Thanks.  I look forward to see your draft.  

Cheers.
Tricci



Xueli <xueli@huawe= i.com>
Sent by: fmc-bounces@ietf.org

04/05/2012 07:56 PM

To
"tso@zteusa.com" <tso@z= teusa.com>
cc
"fmc-bounces@ietf.org" <= ;fmc-bounces@ietf.org>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "fmc@ietf.org= " <fmc@ietf.org>, David Allan I <david.i.allan@ericsson.com>, Marc Blanchet <marc.blanchet@viagenie.ca>
Subject
Re: [fmc] Call for drafts




Dear Tricci,
 
I should say no one mak= es a mistake, we are talking the same thing. The drafts of fmc are preferred to submitted about this discussion.
 
BR
Li
 
From: tso@zteusa.com [mailto:tso@zteus= a.com]
Sent: Friday, April 06, 2012 10:26 AM
To: Xueli
Cc: David Allan I; fmc@ietf.org; fmc-bounces@ietf.org; Marc Blanchet; sarikaya@ieee.org
Subject: RE: [fmc] Call for drafts
 
Dear Li,

I believe you have totally mistaken what was discussed.  No one agains= t to have a draft if there is something to write about?

May I ask, what are the FMC issues that you have in mind that needs IETF to address?  Could you please share with us on this mailing list?

Thanks.
Tricci


Xueli <xueli@huawei.com= >

04/05/2012 07:09 PM


To
"tso@zteusa.com" &l= t;tso@zteusa.com>, Marc Blanchet <marc.blanchet@viagenie.ca>
cc
"fmc-bounces@ietf.org" <fmc-= bounces@ietf.org>, "sarikaya@ieee.org" <sarikaya@ieee.org>, "fmc@ietf.org= " <fmc@ietf.org>, David Allan I <david.i.allan@ericsson.com>
Subject
RE: [fmc] Call for drafts

 







Dear, Tricci,
 
I totally agree with Marc here . The work is promoted via many vehicles in IETF,
and draft is probably the preferred one.
I am confused, why the draft work is against here.
 
BR
Li
 
From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.= org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 6:31 AM
To: Marc Blanchet
Cc: fmc-bounces@ietf.org; sarikaya@ieee.org; fmc@ietf.org; David Allan I
Subject: Re: [fmc] Call for drafts
 
Dear Marc,

Not trying to challenge IETF approach to support discussions for addressing issue.

However, the context of the discussion last week which I try to refer for this mailing list NOW to propose a draft is that - we have NOT even agreed on what, if any, FMC issue in the context of the IETF that we need to addre= ss.  

To blindly go ahead to propose a draft without any basic discussions and understanding among ourselves, IMHO, this is immature.  Hoping that you can understand where am I coming from. Thanks.

Cheers.
Tricci

Marc Blanchet <marc.bla= nchet@viagenie.ca>

04/05/2012 03:14 PM

 


To
tso@zteusa.com
cc
sarikaya@ieee.org, David Allan I <davi= d.i.allan@ericsson.com>, fmc-bounces@ietf.org, fmc@ietf.org
Subject
Re: [fmc] Call for drafts


 

 







to me, the vehicle is not so important: mailing list, draft, blog, web page, tracker, .... But as Behcet is saying, IETF practice is based on drafts, which have a few good properties. So make your point using whatever method, and don't forget that draft is probably the preferred way.

Marc.

Le 2012-04-05 =E0 17:31, tso@zteusa.com= a =E9crit :

Dear Behcet,

Please allow me to repeat my comment before on the wrong DMM mailing list.  :)

My understanding for the objective of this mailing list discussion is to determine if there is any IETF specific issue that needs to be resolved based on the FMC network solution that has been defined by 3GPP and BBF?  

At this point, there is no understanding or agreement on what the problem statement is for FMC in the context of IETF?  I sincerely believe that this is way too immature to ask for a draft for "FMC".

I believe the agreement from last IETF meeting discussion was to continue to research on what is the problem statement before we can determine our next step on this work in IETF.  

Thanks.
Tricci

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

04/05/2012 09:08 AM

 


Please respond to<= font size=3D3 color=3Dblue face=3D"Times New Roman">
sarikaya@ieee.org

 

 


To
fmc@ietf.org
cc
Subject
[fmc] Call for drafts


 

 








Hello,

We would like to solicit drafts on fmc to be submitted in the form:

draft-name-fmc-topic

Please submit your draft and get them discussed on this list.

Regards,

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



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

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

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=
 
-----------------------------------= ---------------------
ZTE Information Security Notice: Th= e information contained in this mail is solely property of the sender's organ= ization. This mail communication is confidential. Recipients named above are obligat= ed to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitte= d with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for v= iruses and Spam by ZTE Anti-Spam system.________________= _______________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 00112B6E882579D8_=-- From tso@zteusa.com Thu Apr 5 20:30:24 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719A411E8081; Thu, 5 Apr 2012 20:30:24 -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 OY7zcOd5yhNN; Thu, 5 Apr 2012 20:30:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 27E5411E8073; Thu, 5 Apr 2012 20:30:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Fri, 6 Apr 2012 10:53:18 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.6988524274; Fri, 6 Apr 2012 10:28:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q362SkNM006761; Fri, 6 Apr 2012 10:28:47 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <01FE63842C181246BBE4CF183BD159B41E6606B7@szxeml528-mbs.china.huawei.com> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> <01FE63842C181246BBE4CF183BD159B41E6606B7@szxeml528-mbs.china.huawei.com> To: Xueli MIME-Version: 1.0 X-KeepSent: 86FEEBFE:4C180E5C-882579D8:000D76D0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 5 Apr 2012 19:28:32 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-06 10:28:47, Serialize complete at 2012-04-06 10:28:47 Content-Type: multipart/alternative; boundary="=_alternative 000D9D53882579D8_=" X-MAIL: mse01.zte.com.cn q362SkNM006761 Cc: "charliep@computer.org" , "fmc-bounces@ietf.org" , "fmc@ietf.org" , David Allan I Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 03:30:24 -0000 This is a multipart message in MIME format. --=_alternative 000D9D53882579D8_= Content-Type: text/plain; charset="US-ASCII" Dear Li, Yes, indeed. The FMC mailing list is about Fixed Mobile Convergence discussions. I sincerely hope so... :) Thanks. Tricci Xueli 04/05/2012 07:20 PM To "tso@zteusa.com" , "charliep@computer.org" cc David Allan I , "fmc-bounces@ietf.org" , "fmc@ietf.org" Subject RE: [fmc] Call for drafts Dear Charlie and Tricci, Nowadays, actually, FMC is the fixed and mobile network convergence. Here, the fixed broadband network, which could be used as the transport network for WLAN or Femtocell access technology. In the FMC scenario, the coordination is required between the fixed transport network and the mobile network, such as policy control, QoS etc. BR Li From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com Sent: Friday, April 06, 2012 7:13 AM To: charliep@computer.org Cc: David Allan I; fmc-bounces@ietf.org; fmc@ietf.org Subject: Re: [fmc] Call for drafts Dear Charlie, Thank you for raising the question from a non-3GPP and non-Broadband Forum perspectives. Actually, for today, the term "FMC", the "fixed" is referring to the Fixed Broadband Network which is NOT specific to WLAN or Femto, although it is often the major access technology that the device is attached to in order to connect to the Fixed Broadband Network. And, "Convergence" does NOT apply ONLY to policy control, although, policy control is one of the major aspects of the convergence requirement. If the purpose is to determine if there is any requirement in the context of IETF, I would like to suggest to keep the term "FMC" so that to make it easier to associate with the work that has been done in other SDOs. Thanks. Tricci "Charles E. Perkins" Sent by: fmc-bounces@ietf.org 04/05/2012 04:05 PM Please respond to charliep@computer.org To fmc@ietf.org cc Subject Re: [fmc] Call for drafts Hello folks, I wonder if the terminology is, in itself, confusing. A long time ago, "FMC" meant something about having the Internet serve fixed hosts and mobile hosts in a uniform manner, so that applications could provide a uniform user experience. In some recent discussion, "fixed" meant either WLAN or "femtocell". "Convergence" meant "conformant distribution of policy controls". And, indeed, the proposed outlines of the solution space are quite restrictive [e.g., only to LTE subscribers], not including most of the traditional problems associated with "FMC". It wasn't obvious to me before I read the draft -- maybe it isn't obvious to other people what the intention is for this use of "FMC". 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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000D9D53882579D8_= Content-Type: text/html; charset="US-ASCII" Dear Li,

Yes, indeed.  The FMC mailing list is about Fixed Mobile Convergence discussions.  I sincerely hope so...  :)

Thanks.
Tricci



Xueli <xueli@huawei.com>

04/05/2012 07:20 PM

To
"tso@zteusa.com" <tso@zteusa.com>, "charliep@computer.org" <charliep@computer.org>
cc
David Allan I <david.i.allan@ericsson.com>, "fmc-bounces@ietf.org" <fmc-bounces@ietf.org>, "fmc@ietf.org" <fmc@ietf.org>
Subject
RE: [fmc] Call for drafts





Dear Charlie and Tricci,
 
Nowadays, actually, FMC is the fixed and mobile network convergence.
Here,  the fixed broadband network, which could be used as the transport network for WLAN or Femtocell access technology.
In the FMC scenario, the coordination is required between the fixed transport network and the mobile network, such as policy control, QoS etc.
 
BR
Li
 
 
From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of tso@zteusa.com
Sent: Friday, April 06, 2012 7:13 AM
To: charliep@computer.org
Cc: David Allan I; fmc-bounces@ietf.org; fmc@ietf.org
Subject: Re: [fmc] Call for drafts
 
Dear Charlie,

Thank you for raising the question from a non-3GPP and non-Broadband Forum perspectives.

Actually, for today, the term "FMC", the "fixed" is referring to the Fixed Broadband Network which is NOT specific to WLAN or Femto, although it is often the major access technology that the device is attached to in order to connect to the Fixed Broadband Network.  

And, "Convergence" does NOT apply ONLY to policy control, although, policy control is one of the major aspects of the convergence requirement.

If the purpose is to determine if there is any requirement in the context of IETF, I would like to suggest to keep the term "FMC" so that to make it easier to associate with the work that has been done in other SDOs.  

Thanks.
Tricci

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

04/05/2012 04:05 PM


Please respond to
charliep@computer.org
To
fmc@ietf.org
cc
Subject
Re: [fmc] Call for drafts

 








Hello folks,

I wonder if the terminology is, in itself, confusing.
A long time ago, "FMC" meant something about having the
Internet serve fixed hosts and mobile hosts in a uniform
manner, so that applications could provide a uniform
user experience.

In some recent discussion, "fixed" meant either WLAN
or "femtocell".   "Convergence" meant "conformant
distribution of policy controls".  And, indeed, the
proposed outlines of the solution space are quite
restrictive [e.g., only to LTE subscribers], not
including most of the traditional problems associated
with "FMC".

It wasn't obvious to me before I read the draft --
maybe it isn't obvious to other people what the
intention is for this use of "FMC".

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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000D9D53882579D8_=-- From charliep@computer.org Thu Apr 5 21:34:01 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 DDA7F21F85DA for ; Thu, 5 Apr 2012 21:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 D5lfmgB-R-Fz for ; Thu, 5 Apr 2012 21:33:58 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD3A21F85DB for ; Thu, 5 Apr 2012 21:33:51 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.70]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SG0rq-00062q-8s; Fri, 06 Apr 2012 00:33:46 -0400 Message-ID: <4F7E7230.3080406@computer.org> Date: Thu, 05 Apr 2012 21:33:52 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: tso@zteusa.com, fmc@ietf.org References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d6fa3c98f1083c9e5163f57f361bb246350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Subject: Re: [fmc] Call for drafts X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 04:34:01 -0000 Hello Tricci, If the IETF is doing the work for some other SDO, then presumably the other SDO has written up the problem description and identified the requirements. Can you send a pointer to the document from the other SDO? Is it BBF? I am under the impression that some of the terms that are being used in the discussion (for example, "FMC") are actually referring to something specific defined elsewhere. It would be nice if we didn't have to guess about the meaning, but instead could read the relevant documents already existing on the topic. If we have to try out various sets of requirements until finally one set of them matches some unstated expectations from the other SDOs, we could be doing that for a while without success. To my way of understanding, the RAN is no less "fixed" than the WLAN access network. Regards, Charlie P. On 4/5/2012 4:12 PM, tso@zteusa.com wrote: > Dear Charlie, > > Thank you for raising the question from a non-3GPP and non-Broadband > Forum perspectives. > > Actually, for today, the term "FMC", the "fixed" is referring to the > Fixed Broadband Network which is NOT specific to WLAN or Femto, although > it is often the major access technology that the device is attached to > in order to connect to the Fixed Broadband Network. > > And, "Convergence" does NOT apply ONLY to policy control, although, > policy control is one of the major aspects of the convergence requirement. > > If the purpose is to determine if there is any requirement in the > context of IETF, I would like to suggest to keep the term "FMC" so that > to make it easier to associate with the work that has been done in other > SDOs. > > Thanks. > Tricci > > > > *"Charles E. Perkins" * > Sent by: fmc-bounces@ietf.org > > 04/05/2012 04:05 PM > Please respond to > charliep@computer.org > > > > To > fmc@ietf.org > cc > > Subject > Re: [fmc] Call for drafts > > > > > > > > > > Hello folks, > > I wonder if the terminology is, in itself, confusing. > A long time ago, "FMC" meant something about having the > Internet serve fixed hosts and mobile hosts in a uniform > manner, so that applications could provide a uniform > user experience. > > In some recent discussion, "fixed" meant either WLAN > or "femtocell". "Convergence" meant "conformant > distribution of policy controls". And, indeed, the > proposed outlines of the solution space are quite > restrictive [e.g., only to LTE subscribers], not > including most of the traditional problems associated > with "FMC". > > It wasn't obvious to me before I read the draft -- > maybe it isn't obvious to other people what the > intention is for this use of "FMC". > > 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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From soohongp@gmail.com Thu Apr 5 22:07:47 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 65D0F11E80A0 for ; Thu, 5 Apr 2012 22:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Gk6imnrMrrmw for ; Thu, 5 Apr 2012 22:07:46 -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 2B9A311E809F for ; Thu, 5 Apr 2012 22:07:45 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1967101bku.31 for ; Thu, 05 Apr 2012 22:07:45 -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:content-transfer-encoding; bh=lvotSny6GdJTGMHWlCavGDl8ronzFCKGv8Aq1NWRWt0=; b=SScOy0+QHBLQMhD11ewQfI+PeUiUOJjaYXv3fZsMubQP2FgPx3G4n9MRKOSm1YW2R8 PGYi92uc2L23NhEldHNEOKRcYNz7FJCFT1TR2lte41e5QrzxhouxOzvQHcZh8nIOSyak TMx4fs4Gy//hKGv/Z5DgJFSdez20FjyAF0PUW4J+bMRx7FwJ6nppump5oK4NN2WOnVzN BEx5hXrH9WzWAjfcUy8Rk0MeTdirypVuBBxR9nSrXvQyxbURDPqE+IN6fDF0lpu1tnaq 0qY9YjOX4/bRpVBmh8BFK7m+rNIwDAFcLhCAXK6xPRHM638eMsmD8LIanaJSPyUHJgM3 lOtA== MIME-Version: 1.0 Received: by 10.204.157.7 with SMTP id z7mr1095646bkw.49.1333688865175; Thu, 05 Apr 2012 22:07:45 -0700 (PDT) Received: by 10.205.35.133 with HTTP; Thu, 5 Apr 2012 22:07:45 -0700 (PDT) In-Reply-To: <4F7E7230.3080406@computer.org> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> <4F7E7230.3080406@computer.org> Date: Fri, 6 Apr 2012 14:07:45 +0900 Message-ID: From: Daniel Park To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tso@zteusa.com, fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 05:07:47 -0000 To me, best way for us to clearly make up the definition of FMC here. FMC (Fixed Mobile Convergence) means several meaning and different interpretation can arise due to different understanding in several domains. What the definition of FMC here ? Once getting the clear definition, then we can borader thoughts of problem statements, requirements as well as in-scope items or even out-of scope... Hope this helps. Daniel --=20 Soohong Daniel Park Samsung Electronics, SWC On Fri, Apr 6, 2012 at 1:33 PM, Charles E. Perkins wrote: > > Hello Tricci, > > If the IETF is doing the work for some other SDO, then presumably the > other SDO has written up the problem description and identified the > requirements. =A0Can you send a pointer to the document from the other > SDO? =A0Is it BBF? > > I am under the impression that some of the terms that are being > used in the discussion (for example, "FMC") are actually referring > to something specific defined elsewhere. =A0It would be nice if we > didn't have to guess about the meaning, but instead could read the > relevant documents already existing on the topic. > > If we have to try out various sets of requirements until finally > one set of them matches some unstated expectations from the other > SDOs, we could be doing that for a while without success. > > To my way of understanding, the RAN is no less "fixed" than the > WLAN access network. > > Regards, > Charlie P. > > > > On 4/5/2012 4:12 PM, tso@zteusa.com wrote: >> >> Dear Charlie, >> >> Thank you for raising the question from a non-3GPP and non-Broadband >> Forum perspectives. >> >> Actually, for today, the term "FMC", the "fixed" is referring to the >> Fixed Broadband Network which is NOT specific to WLAN or Femto, although >> it is often the major access technology that the device is attached to >> in order to connect to the Fixed Broadband Network. >> >> And, "Convergence" does NOT apply ONLY to policy control, although, >> policy control is one of the major aspects of the convergence requiremen= t. >> >> If the purpose is to determine if there is any requirement in the >> context of IETF, I would like to suggest to keep the term "FMC" so that >> to make it easier to associate with the work that has been done in other >> SDOs. >> >> Thanks. >> Tricci >> >> >> >> *"Charles E. Perkins" * >> >> Sent by: fmc-bounces@ietf.org >> >> 04/05/2012 04:05 PM >> Please respond to >> charliep@computer.org >> >> >> >> To >> =A0 =A0 =A0 =A0fmc@ietf.org >> cc >> >> Subject >> =A0 =A0 =A0 =A0Re: [fmc] Call for drafts >> >> >> >> >> >> >> >> >> >> Hello folks, >> >> I wonder if the terminology is, in itself, confusing. >> A long time ago, "FMC" meant something about having the >> Internet serve fixed hosts and mobile hosts in a uniform >> manner, so that applications could provide a uniform >> user experience. >> >> In some recent discussion, "fixed" meant either WLAN >> or "femtocell". "Convergence" meant "conformant >> distribution of policy controls". And, indeed, the >> proposed outlines of the solution space are quite >> restrictive [e.g., only to LTE subscribers], not >> including most of the traditional problems associated >> with "FMC". >> >> It wasn't obvious to me before I read the draft -- >> maybe it isn't obvious to other people what the >> intention is for this use of "FMC". >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc >> >> >> >> -------------------------------------------------------- >> ZTE =A0Information =A0Security =A0Notice: =A0The =A0information =A0conta= ined =A0in =A0this >> =A0mail =A0is =A0solely =A0property =A0of =A0the =A0sender's =A0organiza= tion. =A0This =A0mail >> =A0communication =A0is =A0confidential. =A0Recipients =A0named =A0above = =A0are =A0obligated >> =A0to =A0maintain =A0secrecy =A0and =A0are =A0not =A0permitted =A0to =A0= disclose =A0the >> =A0contents =A0of =A0this =A0communication =A0to =A0others. >> This =A0email =A0and =A0any =A0files =A0transmitted =A0with =A0it =A0are= =A0confidential >> =A0and =A0intended =A0solely =A0for =A0the =A0use =A0of =A0the =A0indivi= dual =A0or =A0entity =A0to >> =A0whom =A0they =A0are =A0addressed. =A0If =A0you =A0have =A0received = =A0this =A0email =A0in >> =A0error =A0please =A0notify =A0the =A0originator =A0of =A0the =A0messag= e. =A0Any =A0views >> =A0expressed =A0in =A0this =A0message =A0are =A0those =A0of =A0the =A0in= dividual =A0sender. >> This =A0message =A0has =A0been =A0scanned =A0for =A0viruses =A0and =A0Sp= am =A0by =A0ZTE >> =A0Anti-Spam =A0system. >> > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Fri Apr 6 08:52:21 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 359F721F8546 for ; Fri, 6 Apr 2012 08:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 7z10jF6jCTNd for ; Fri, 6 Apr 2012 08:52:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A241C21F853C for ; Fri, 6 Apr 2012 08:52:20 -0700 (PDT) Received: by iazz13 with SMTP id z13so3905647iaz.31 for ; Fri, 06 Apr 2012 08:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=a4v6HigKC7LzrEivKlua4upK3/UjPRt/OnByoB4xafk=; b=ra4BLtPohWMe/TcklJ6Q+1FF5niQE8mq+2gLlDUhe4aWmEyO8H3O4nJXj+YqsQlPsm hnH5I+SZD6RncoEK47D9fd1RRaMpl30U/xJoxMVMHczc2qTESOHEiOTW224hPAJCUl8U wWsN4RttzxlnQ3jIvVckeMGQBy54/dQ39kLDVSsBXww13HPXupHdTdkixfH3d48UJsRT G91cEKxzAK6tcb4JkTgnRF/Z/rk3b5a0HtgsSDXXY6+rrUCv97sJj87EsdhgUHjQjvVa byNAgl6DecdMWKdO4uRkHzo2FUv9B8DU2L+6rdMGzgW7cERluyFTbigHmCj8Kh3kcIUO WZtA== MIME-Version: 1.0 Received: by 10.42.166.135 with SMTP id o7mr4341797icy.53.1333727540236; Fri, 06 Apr 2012 08:52:20 -0700 (PDT) Received: by 10.231.141.146 with HTTP; Fri, 6 Apr 2012 08:52:20 -0700 (PDT) Date: Fri, 6 Apr 2012 10:52:20 -0500 Message-ID: From: Behcet Sarikaya To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:52:21 -0000 Hi all, This is the text Dirk and I submitted to IESG when they asked 2-3 paragraph list description: The purpose of this list on Fixed Mobile Convergence (fmc) is to be a forum to discuss and analyze all the issues that have arisen so far or to likely come up in the future regarding aspects the Fixed Mobile Convergence that requires some action in IETF Intarea or closely related areas. The scope of Fixed Mobile Convergence is limited to pure interworking between fixed and mobile networks in serving access for multi-interface terminals or mobile hosts like todays' smartphones. In the interworking scenario, the mobile network passes on the mobile subscribers policies to an IP network which happens to be fixed, in order to maintain the end-to-end service level agreement and to support remote terminal and access network management. Explicitly, the fixed IP network must have partnership with the mobile network in Fixed Mobile Convergence interworking scenario. Currently identified issues to be discussed on the list include User Equipment identification and authentication, Femto Access Point management, device type identification, Carrier-Grade Network Address Translation (CGN) related problems and mobility considerations including IP flow mobility and status tracking of IP host. It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols. Regards, Behcet From tso@zteusa.com Fri Apr 6 10:50:20 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF9821F8610; Fri, 6 Apr 2012 10:50:19 -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=[AWL=0.000, 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 zuWztmfPJbL9; Fri, 6 Apr 2012 10:50:19 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CECEA21F860B; Fri, 6 Apr 2012 10:50:17 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Sat, 7 Apr 2012 01:13:18 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 30949.3857953315; Sat, 7 Apr 2012 01:49:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q36Ho1uR005693; Sat, 7 Apr 2012 01:50:01 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: C9F5C5FC:72CDBA45-882579D8:00608D0D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 6 Apr 2012 10:49:50 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-07 01:50:05, Serialize complete at 2012-04-07 01:50:05 Content-Type: multipart/alternative; boundary="=_alternative 0061F687882579D8_=" X-MAIL: mse02.zte.com.cn q36Ho1uR005693 Cc: David Allan I , fmc-bounces@ietf.org, fmc@ietf.org Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:50:20 -0000 This is a multipart message in MIME format. --=_alternative 0061F687882579D8_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, Thank you very much for sharing this descriptions submitted to IESG. But I am so confused by the descriptions because the same set of issues that were described in the text were also discussed last week with the presentation that you have kindly prepared. I remember the outcome of our discussions were that we have "no" agreement to justify those are issues that need to be addressed by IETF. In fact, some of them have already resolved by 3GPP and/or Broadband Forum. If I have missed something between our last week discussions at the IETF and now, could you please clarify what exactly are the problems on those issues, because, as it is written, I could not understand what are the problem descriptions that you have newly found needed to be addressed? In your text, you said... >>>>> Currently identified issues to be discussed on the list include: User Equipment identification and authentication, Femto Access Point management, device type identification, Carrier-Grade Network Address Translation (CGN) related problems and mobility considerations including IP flow mobility and status tracking of IP host. It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols. >>>>> Many Thanks in advance. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/06/2012 08:52 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] List description Hi all, This is the text Dirk and I submitted to IESG when they asked 2-3 paragraph list description: The purpose of this list on Fixed Mobile Convergence (fmc) is to be a forum to discuss and analyze all the issues that have arisen so far or to likely come up in the future regarding aspects the Fixed Mobile Convergence that requires some action in IETF Intarea or closely related areas. The scope of Fixed Mobile Convergence is limited to pure interworking between fixed and mobile networks in serving access for multi-interface terminals or mobile hosts like todays' smartphones. In the interworking scenario, the mobile network passes on the mobile subscribers policies to an IP network which happens to be fixed, in order to maintain the end-to-end service level agreement and to support remote terminal and access network management. Explicitly, the fixed IP network must have partnership with the mobile network in Fixed Mobile Convergence interworking scenario. Currently identified issues to be discussed on the list include User Equipment identification and authentication, Femto Access Point management, device type identification, Carrier-Grade Network Address Translation (CGN) related problems and mobility considerations including IP flow mobility and status tracking of IP host. It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0061F687882579D8_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

Thank you very much for sharing this descriptions submitted to IESG.

But I am so confused by the descriptions because the same set of issues that were described in the text were also discussed last week with the presentation that you have kindly prepared.   I remember the outcome of our discussions were that we have "no" agreement to justify those are issues that need to be addressed by IETF.   In fact, some of them have already resolved by 3GPP and/or Broadband Forum.

If I have missed something between our last week discussions at the IETF and now, could you please clarify what exactly are the problems on those issues, because, as it is written, I could not understand what are the problem descriptions that you have newly found needed to be addressed?

In your text, you said...
>>>>>
Currently identified issues to be discussed on the list include:
  • User Equipment identification and authentication,
  • Femto Access Point management,
  • device type identification,
  • Carrier-Grade Network Address Translation (CGN) related problems and
    mobility considerations including IP flow mobility and
  • status tracking of IP host.
It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols.
>>>>>

Many Thanks in advance.
Tricci




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

04/06/2012 08:52 AM
Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] List description





Hi all,

This is the text Dirk and I submitted to IESG when they asked 2-3
paragraph list description:

The purpose of this list on Fixed Mobile Convergence (fmc)  is to be a forum to
discuss and analyze all the issues that have
  arisen so far or to likely come up in the future
   regarding aspects the Fixed
  Mobile Convergence that requires some action in IETF Intarea or
closely related areas.

   The scope of Fixed Mobile Convergence is limited to pure
interworking between
   fixed and mobile networks in
  serving access for multi-interface terminals or mobile hosts like todays'
  smartphones.  In the interworking scenario, the mobile network passes
  on the mobile subscribers policies to an IP network which happens
to be fixed,
  in order to maintain the end-to-end service level agreement and to
  support remote terminal and access network management.
  Explicitly, the fixed IP network must have partnership with the mobile
  network in Fixed Mobile Convergence interworking scenario.

  Currently identified issues to be discussed on the list include
  User Equipment identification and
  authentication, Femto Access Point management, device type
  identification, Carrier-Grade Network Address Translation (CGN)
related problems and
  mobility considerations including IP flow mobility and status
tracking of IP host.
  It is expected that related issues will arise that will also be
discussed on the list
  that require some protocol work to be done, probably not
  necessarily requiring to develop a new protocol but rather
requiring extensions to the existing protocols.

Regards,

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0061F687882579D8_=-- From tso@zteusa.com Fri Apr 6 11:00:08 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 A0B1A21F8623 for ; Fri, 6 Apr 2012 11:00:08 -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 4UAm-aZS1i+X for ; Fri, 6 Apr 2012 11:00:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B231021F85DB for ; Fri, 6 Apr 2012 11:00:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Sat, 7 Apr 2012 01:59:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.4605341425; Sat, 7 Apr 2012 02:00:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q36Hxwc9091116; Sat, 7 Apr 2012 01:59:58 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <4F7E7230.3080406@computer.org> References: <02BF7B5D-5099-4AAB-AD67-17115BEAF70F@viagenie.ca> <4F7E2549.9030404@computer.org> <4F7E7230.3080406@computer.org> To: charliep@computer.org MIME-Version: 1.0 X-KeepSent: A7275329:D5BF8AC7-882579D8:006232EE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 6 Apr 2012 10:59:46 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-07 02:00:00, Serialize complete at 2012-04-07 02:00:00 Content-Type: multipart/alternative; boundary="=_alternative 0062DF2C882579D8_=" X-MAIL: mse01.zte.com.cn q36Hxwc9091116 Cc: David Allan I , fmc@ietf.org Subject: Re: [fmc] Call for drafts 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, 06 Apr 2012 18:00:08 -0000 This is a multipart message in MIME format. --=_alternative 0062DF2C882579D8_= Content-Type: text/plain; charset="US-ASCII" Dear Charlie, You have raised a very excellent point. If IETF is doing the work for some other SDO (e.g. 3GPP, BBF), then, we should refer to those problem descriptions and identify those requirements that needs to be addressed by IETF. At this moment, I am not aware either 3GPP or BBF has sent official statement to IETF to start the FMC BOF to focus on the FMC related issue. May be someone on this list is aware of such official request from 3GPP and/or from BBF so that we can refer to such official request to obtain those reference document to obtain the requirements and definitions, instead of us starting from the scratch to derive them on our own. May I ask, if anyone know if such official request exists? Thanks in advance for your kind pointers. Tricci "Charles E. Perkins" 04/05/2012 09:33 PM Please respond to charliep@computer.org To tso@zteusa.com, fmc@ietf.org cc Subject Re: [fmc] Call for drafts Hello Tricci, If the IETF is doing the work for some other SDO, then presumably the other SDO has written up the problem description and identified the requirements. Can you send a pointer to the document from the other SDO? Is it BBF? I am under the impression that some of the terms that are being used in the discussion (for example, "FMC") are actually referring to something specific defined elsewhere. It would be nice if we didn't have to guess about the meaning, but instead could read the relevant documents already existing on the topic. If we have to try out various sets of requirements until finally one set of them matches some unstated expectations from the other SDOs, we could be doing that for a while without success. To my way of understanding, the RAN is no less "fixed" than the WLAN access network. Regards, Charlie P. On 4/5/2012 4:12 PM, tso@zteusa.com wrote: > Dear Charlie, > > Thank you for raising the question from a non-3GPP and non-Broadband > Forum perspectives. > > Actually, for today, the term "FMC", the "fixed" is referring to the > Fixed Broadband Network which is NOT specific to WLAN or Femto, although > it is often the major access technology that the device is attached to > in order to connect to the Fixed Broadband Network. > > And, "Convergence" does NOT apply ONLY to policy control, although, > policy control is one of the major aspects of the convergence requirement. > > If the purpose is to determine if there is any requirement in the > context of IETF, I would like to suggest to keep the term "FMC" so that > to make it easier to associate with the work that has been done in other > SDOs. > > Thanks. > Tricci > > > > *"Charles E. Perkins" * > Sent by: fmc-bounces@ietf.org > > 04/05/2012 04:05 PM > Please respond to > charliep@computer.org > > > > To > fmc@ietf.org > cc > > Subject > Re: [fmc] Call for drafts > > > > > > > > > > Hello folks, > > I wonder if the terminology is, in itself, confusing. > A long time ago, "FMC" meant something about having the > Internet serve fixed hosts and mobile hosts in a uniform > manner, so that applications could provide a uniform > user experience. > > In some recent discussion, "fixed" meant either WLAN > or "femtocell". "Convergence" meant "conformant > distribution of policy controls". And, indeed, the > proposed outlines of the solution space are quite > restrictive [e.g., only to LTE subscribers], not > including most of the traditional problems associated > with "FMC". > > It wasn't obvious to me before I read the draft -- > maybe it isn't obvious to other people what the > intention is for this use of "FMC". > > 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 is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0062DF2C882579D8_= Content-Type: text/html; charset="US-ASCII" Dear Charlie,

You have raised a very excellent point.  

If IETF is doing the work for some other SDO (e.g. 3GPP, BBF), then, we should refer to those problem descriptions and identify those requirements that needs to be addressed by IETF.  

At this moment, I am not aware either 3GPP or BBF has sent official statement to IETF to start the FMC BOF to focus on the FMC related issue.  

May be someone on this list is aware of such official request from 3GPP and/or from BBF so that we can refer to such official request to obtain those reference document to obtain the requirements and definitions, instead of us starting from the scratch to derive them on our own.

May I ask, if anyone know if such official request exists?  

Thanks in advance for your kind pointers.
Tricci




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

04/05/2012 09:33 PM
Please respond to
charliep@computer.org
To
tso@zteusa.com, fmc@ietf.org
cc
Subject
Re: [fmc] Call for drafts






Hello Tricci,

If the IETF is doing the work for some other SDO, then presumably the
other SDO has written up the problem description and identified the
requirements.  Can you send a pointer to the document from the other
SDO?  Is it BBF?

I am under the impression that some of the terms that are being
used in the discussion (for example, "FMC") are actually referring
to something specific defined elsewhere.  It would be nice if we
didn't have to guess about the meaning, but instead could read the
relevant documents already existing on the topic.

If we have to try out various sets of requirements until finally
one set of them matches some unstated expectations from the other
SDOs, we could be doing that for a while without success.

To my way of understanding, the RAN is no less "fixed" than the
WLAN access network.

Regards,
Charlie P.


On 4/5/2012 4:12 PM, tso@zteusa.com wrote:
> Dear Charlie,
>
> Thank you for raising the question from a non-3GPP and non-Broadband
> Forum perspectives.
>
> Actually, for today, the term "FMC", the "fixed" is referring to the
> Fixed Broadband Network which is NOT specific to WLAN or Femto, although
> it is often the major access technology that the device is attached to
> in order to connect to the Fixed Broadband Network.
>
> And, "Convergence" does NOT apply ONLY to policy control, although,
> policy control is one of the major aspects of the convergence requirement.
>
> If the purpose is to determine if there is any requirement in the
> context of IETF, I would like to suggest to keep the term "FMC" so that
> to make it easier to associate with the work that has been done in other
> SDOs.
>
> Thanks.
> Tricci
>
>
>
> *"Charles E. Perkins" <charliep@computer.org>*
> Sent by: fmc-bounces@ietf.org
>
> 04/05/2012 04:05 PM
> Please respond to
> charliep@computer.org
>
>
>                  
> To
>                  fmc@ietf.org
> cc
>                  
> Subject
>                  Re: [fmc] Call for drafts
>
>
>                  
>
>
>
>
>
>
> Hello folks,
>
> I wonder if the terminology is, in itself, confusing.
> A long time ago, "FMC" meant something about having the
> Internet serve fixed hosts and mobile hosts in a uniform
> manner, so that applications could provide a uniform
> user experience.
>
> In some recent discussion, "fixed" meant either WLAN
> or "femtocell". "Convergence" meant "conformant
> distribution of policy controls". And, indeed, the
> proposed outlines of the solution space are quite
> restrictive [e.g., only to LTE subscribers], not
> including most of the traditional problems associated
> with "FMC".
>
> It wasn't obvious to me before I read the draft --
> maybe it isn't obvious to other people what the
> intention is for this use of "FMC".
>
> 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  is  solely  property  of  the  sender's  organization.  This  mail  communication  is  confidential.  Recipients  named  above  are  obligated  to  maintain  secrecy  and  are  not  permitted  to  disclose  the  contents  of  this  communication  to  others.
> This  email  and  any  files  transmitted  with  it  are  confidential  and  intended  solely  for  the  use  of  the  individual  or  entity  to  whom  they  are  addressed.  If  you  have  received  this  email  in  error  please  notify  the  originator  of  the  message.  Any  views  expressed  in  this  message  are  those  of  the  individual  sender.
> This  message  has  been  scanned  for  viruses  and  Spam  by  ZTE  Anti-Spam  system.
>


 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0062DF2C882579D8_=-- From pierrick.seite@orange.com Fri Apr 6 15:46:14 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 D9F3A11E80AD for ; Fri, 6 Apr 2012 15:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 UgtNeFTRxgHs for ; Fri, 6 Apr 2012 15:46:14 -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 F252911E80AB for ; Fri, 6 Apr 2012 15:46:13 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0015E1074007; Sat, 7 Apr 2012 00:47:54 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id ECAAA1074004; Sat, 7 Apr 2012 00:47:54 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Apr 2012 00:46:13 +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: Sat, 7 Apr 2012 00:46:10 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] List description Thread-Index: Ac0UDULQP73DNeCjSeescF141qs7swAM3c7A References: From: To: , X-OriginalArrivalTime: 06 Apr 2012 22:46:13.0868 (UTC) FILETIME=[11DF1AC0:01CD1447] Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 22:46:15 -0000 Hi, I've read this description, but I didn't really get the problem you want = to address, from the IETF standpoint. Typically, I'm surprised to not = see reference to 3GPP and BBF which are specifying FMC architectures. = What are the use-cases from these SDOs, do these SDOs have expressed = needs for protocol extensions, is there liaison statements? What do = "fix" and "mobile" mean from an IETF standpoint? And so on... I think = this description raises fundamental questions regarding the problem = (again, from the IETF standpoint). So, before calling for drafts = (referring to your previous mail), the problem should be clarified = first. Otherwise there is a risk to redo 3GPP/BBF work... Typically, you = are referring to "Femto access point management"... Do you really think = it is in the IETF scope?=20 Pierrick =20 > -----Message d'origine----- > De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part = de > Behcet Sarikaya > Envoy=E9=A0: vendredi 6 avril 2012 17:52 > =C0=A0: fmc@ietf.org > Objet=A0: [fmc] List description >=20 > Hi all, >=20 > This is the text Dirk and I submitted to IESG when they asked 2-3 > paragraph list description: >=20 > The purpose of this list on Fixed Mobile Convergence (fmc) is to be a > forum to > discuss and analyze all the issues that have > arisen so far or to likely come up in the future > regarding aspects the Fixed > Mobile Convergence that requires some action in IETF Intarea or > closely related areas. >=20 > The scope of Fixed Mobile Convergence is limited to pure > interworking between > fixed and mobile networks in > serving access for multi-interface terminals or mobile hosts like > todays' > smartphones. In the interworking scenario, the mobile network > passes > on the mobile subscribers policies to an IP network which happens > to be fixed, > in order to maintain the end-to-end service level agreement and to > support remote terminal and access network management. > Explicitly, the fixed IP network must have partnership with the > mobile > network in Fixed Mobile Convergence interworking scenario. >=20 > Currently identified issues to be discussed on the list include > User Equipment identification and > authentication, Femto Access Point management, device type > identification, Carrier-Grade Network Address Translation (CGN) > related problems and > mobility considerations including IP flow mobility and status > tracking of IP host. > It is expected that related issues will arise that will also be > discussed on the list > that require some protocol work to be done, probably not > necessarily requiring to develop a new protocol but rather > requiring extensions to the existing protocols. >=20 > Regards, >=20 > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From david.i.allan@ericsson.com Fri Apr 6 15:55: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 7580221F854B for ; Fri, 6 Apr 2012 15:55:17 -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=[BAYES_00=-2.599, 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 K-DfZd5q+HVV for ; Fri, 6 Apr 2012 15:55:16 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BD4B721F8549 for ; Fri, 6 Apr 2012 15:55:16 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q36Mt9gD007740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Apr 2012 17:55:09 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 6 Apr 2012 18:55:08 -0400 From: David Allan I To: "pierrick.seite@orange.com" , "sarikaya@ieee.org" , "fmc@ietf.org" Date: Fri, 6 Apr 2012 18:55:06 -0400 Thread-Topic: [fmc] List description Thread-Index: Ac0UDULQP73DNeCjSeescF141qs7swAM3c7AAAGs5SA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 22:55:17 -0000 HI Another party heard from (Me). The IETF is a protocol specification body, and I do not see any protocol sp= ecification here. Further this is not a greenfield problem, s much of this is already done an= d dusted, and simply needs implementation agreements. As noted it is 3GPP a= nd BBF networks working together, which is a project well underway in the r= espective SDOs. The outstanding headwound is a wifi connected UE behind a NAT, and I believ= e that is already being addressed elsewhere in the IETF. What am I missing? Dave=20 -----Original Message----- From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of pierr= ick.seite@orange.com Sent: Friday, April 06, 2012 3:46 PM To: sarikaya@ieee.org; fmc@ietf.org Subject: Re: [fmc] List description Hi, I've read this description, but I didn't really get the problem you want to= address, from the IETF standpoint. Typically, I'm surprised to not see ref= erence to 3GPP and BBF which are specifying FMC architectures. What are the= use-cases from these SDOs, do these SDOs have expressed needs for protocol= extensions, is there liaison statements? What do "fix" and "mobile" mean f= rom an IETF standpoint? And so on... I think this description raises fundam= ental questions regarding the problem (again, from the IETF standpoint). So= , before calling for drafts (referring to your previous mail), the problem = should be clarified first. Otherwise there is a risk to redo 3GPP/BBF work.= .. Typically, you are referring to "Femto access point management"... Do yo= u really think it is in the IETF scope?=20 Pierrick =20 > -----Message d'origine----- > De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de=20 > Behcet Sarikaya Envoy=E9=A0: vendredi 6 avril 2012 17:52 =C0=A0: fmc@ietf= .org=20 > Objet=A0: [fmc] List description >=20 > Hi all, >=20 > This is the text Dirk and I submitted to IESG when they asked 2-3=20 > paragraph list description: >=20 > The purpose of this list on Fixed Mobile Convergence (fmc) is to be a=20 > forum to discuss and analyze all the issues that have > arisen so far or to likely come up in the future > regarding aspects the Fixed > Mobile Convergence that requires some action in IETF Intarea or=20 > closely related areas. >=20 > The scope of Fixed Mobile Convergence is limited to pure=20 > interworking between > fixed and mobile networks in > serving access for multi-interface terminals or mobile hosts like=20 > todays' > smartphones. In the interworking scenario, the mobile network=20 > passes > on the mobile subscribers policies to an IP network which happens=20 > to be fixed, > in order to maintain the end-to-end service level agreement and to > support remote terminal and access network management. > Explicitly, the fixed IP network must have partnership with the=20 > mobile > network in Fixed Mobile Convergence interworking scenario. >=20 > Currently identified issues to be discussed on the list include > User Equipment identification and > authentication, Femto Access Point management, device type > identification, Carrier-Grade Network Address Translation (CGN)=20 > related problems and > mobility considerations including IP flow mobility and status=20 > tracking of IP host. > It is expected that related issues will arise that will also be=20 > discussed on the list > that require some protocol work to be done, probably not > necessarily requiring to develop a new protocol but rather=20 > requiring extensions to the existing protocols. >=20 > Regards, >=20 > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc From sarikaya2012@gmail.com Mon Apr 9 08:32:31 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 BC7B121F86B1 for ; Mon, 9 Apr 2012 08:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_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 zxGJWZkiOj+D for ; Mon, 9 Apr 2012 08:32:30 -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 EDFD021F84F9 for ; Mon, 9 Apr 2012 08:32:28 -0700 (PDT) Received: by yenm5 with SMTP id m5so2087509yen.31 for ; Mon, 09 Apr 2012 08:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=c0Ma0AI/Y1IzhXN7bW1v+4njj6gLqSxYg25OeGZNn90=; b=cuc9RhqNW+TvMEoxVPRtfuku88Td5gguEKQ41Rok6J1Mxcflwogc/yVjXyUB8d82E5 q4tTAoICgH6Go1XdXCtBFe3Y4MyjGKh6h92zvJohXL4yI1ayMVnWOIw2daXPD3kjPRw8 UMEv6Sbi5r2HaGEr9Z9jtDws7EhvVk+2pKl+j3z/jpZ8MU08YkrtKFvDKvmFZggI120S wdUQHU+ghzhHVlyb/w3k7AedVuiy9iMskOFTS9i0TYWhy/3Jqvyl1kaY0THDJfa7G+we vygat5qIv6H6uFsV9HZynosp0sfzDwzHYvfDDifwamASXFXmYMMpDvPyS2BAjSL8vsBb rh/g== MIME-Version: 1.0 Received: by 10.50.203.99 with SMTP id kp3mr5379294igc.16.1333985546952; Mon, 09 Apr 2012 08:32:26 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Mon, 9 Apr 2012 08:32:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Apr 2012 10:32:26 -0500 Message-ID: From: Behcet Sarikaya To: tso@zteusa.com Content-Type: multipart/alternative; boundary=14dae934078fa95fbf04bd40b6c1 Cc: fmc@ietf.org Subject: Re: [fmc] List description 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: Mon, 09 Apr 2012 15:32:31 -0000 --14dae934078fa95fbf04bd40b6c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tricci, Firstly, please stop cc'ing to fmc-bounces. The issues that require IETF protocol work (as explained at the end of the list description) are the issues this mailing list I think should concentrate In case the problem can be solved with existing means, the SDOs, e.g. Broadband Forum can go ahead and develop requirements. .Yes, some of the issues listed may not survive. CGN Issue is an example. Maybe there are other issues as well. This list of issues are given as an example because they were discussed in IETF 83 FMC side meeting. Hope it is clear now? Behcet On Fri, Apr 6, 2012 at 12:49 PM, wrote: > Dear Behcet, > > Thank you very much for sharing this descriptions submitted to IESG. > > But I am so confused by the descriptions because the same set of issues > that were described in the text were also discussed last week with the > presentation that you have kindly prepared. I remember the outcome of o= ur > discussions were that we have "no" agreement to justify those are issues > that need to be addressed by IETF. In fact, some of them have already > resolved by 3GPP and/or Broadband Forum. > > If I have missed something between our last week discussions at the IETF > and now, could you please clarify what exactly are the problems on those > issues, because, as it is written, I could not understand what are the > problem descriptions that you have newly found needed to be addressed? > In your text, you said... > >>>>> > Currently identified issues to be discussed on the list include: > > - User Equipment identification and authentication, > - Femto Access Point management, > - device type identification, > - Carrier-Grade Network Address Translation (CGN) related problems and > mobility considerations including IP flow mobility and > - status tracking of IP host. > > It is expected that related issues will arise that will also be discussed > on the list that require some protocol work to be done, probably not > necessarily requiring to develop a new protocol but rather requiring > extensions to the existing protocols. > >>>>> > > Many Thanks in advance. > Tricci > > > > > *Behcet Sarikaya * > Sent by: fmc-bounces@ietf.org > > 04/06/2012 08:52 AM > Please respond to > sarikaya@ieee.org > > To > fmc@ietf.org > cc > Subject > [fmc] List description > > > > > Hi all, > > This is the text Dirk and I submitted to IESG when they asked 2-3 > paragraph list description: > > The purpose of this list on Fixed Mobile Convergence (fmc) is to be a > forum to > discuss and analyze all the issues that have > arisen so far or to likely come up in the future > regarding aspects the Fixed > Mobile Convergence that requires some action in IETF Intarea or > closely related areas. > > The scope of Fixed Mobile Convergence is limited to pure > interworking between > fixed and mobile networks in > serving access for multi-interface terminals or mobile hosts like today= s' > smartphones. In the interworking scenario, the mobile network passes > on the mobile subscribers policies to an IP network which happens > to be fixed, > in order to maintain the end-to-end service level agreement and to > support remote terminal and access network management. > Explicitly, the fixed IP network must have partnership with the mobile > network in Fixed Mobile Convergence interworking scenario. > > Currently identified issues to be discussed on the list include > User Equipment identification and > authentication, Femto Access Point management, device type > identification, Carrier-Grade Network Address Translation (CGN) > related problems and > mobility considerations including IP flow mobility and status > tracking of IP host. > It is expected that related issues will arise that will also be > discussed on the list > that require some protocol work to be done, probably not > necessarily requiring to develop a new protocol but rather > requiring extensions to the existing protocols. > > Regards, > > Behcet > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --14dae934078fa95fbf04bd40b6c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tricci,

Firstly, please stop cc'ing to fmc-bounces.

Th= e issues that require IETF protocol work (as explained at the end of the li= st description) are the issues this mailing list I think should concentrate= In case the problem can be solved with existing means, the SDOs, e.g. Broa= dband Forum can go ahead and develop requirements.

.Yes, some of the issues listed may not survive. CGN Issue is an exampl= e. Maybe there are other issues as well.

This list of issues are giv= en as an example because they were discussed in IETF 83 FMC side meeting. <= br>
Hope it is clear now?

Behcet

O= n Fri, Apr 6, 2012 at 12:49 PM, <tso@zteusa.com> wrote:
Dear Behcet,

Thank you very much= for sharing this descriptions submitted to IESG.

But I am so confuse= d by the descriptions because the same set of issues that were described in the text were also discussed last week with the presentation that you have kindly prepared. =A0 I remember the outcome of our discussions were that we have "no" agreement to justify those are issues that need to be addressed by IETF. =A0 In fact, some of them have already resolved by 3GPP and/or Broadband Forum.

If I have missed so= mething between our last week discussions at the IETF and now, could you please clarify what exactly are the problems on those issues, because, as it is written, I could not understand what are the problem descriptions that you have newly found needed to be addressed?
=A0
In your text, you said...
&= gt;>>>>
Currently identified issues to be discussed on the list include:
  • User Equipment identification and authentication,
  • Femto Access Point management,
  • device type identification,
  • Carrier-Grade Network Address Translation (CG= N) related problems and
    mobility considerations including IP flow mobility and
  • status tracking of IP host.
It is expected that related issu= es will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protoc= ol but rather requiring extensions to the existing protocols.
>>>>>

Many Thanks in a= dvance.
Tricci




Behcet Sarikaya &= lt;sarikaya2012= @gmail.com>
Sent by: fmc-bounces@ietf.org

04/06/2012 08:52 AM

Please respond t= o
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] List description=





Hi all,

This is the text Dirk and I submitted to IESG when they asked 2-3
paragraph list description:

The purpose of this list on Fixed Mobile Convergence (fmc) =A0is to be a forum to
discuss and analyze all the issues that have
=A0 arisen so far or to likely come up in the future
=A0 =A0regarding aspects the Fixed
=A0 Mobile Convergence that requires some action in IETF Intarea or
closely related areas.

=A0 =A0The scope of Fixed Mobile Convergence is limited to pure
interworking between
=A0 =A0fixed and mobile networks in
=A0 serving access for multi-interface terminals or mobile hosts like todays'
=A0 smartphones. =A0In the interworking scenario, the mobile network passes
=A0 on the mobile subscribers policies to an IP network which happens
to be fixed,
=A0 in order to maintain the end-to-end service level agreement and to
=A0 support remote terminal and access network management.
=A0 Explicitly, the fixed IP network must have partnership with the mobile
=A0 network in Fixed Mobile Convergence interworking scenario.

=A0 Currently identified issues to be discussed on the list include
=A0 User Equipment identification and
=A0 authentication, Femto Access Point management, device type
=A0 identification, Carrier-Grade Network Address Translation (CGN)
related problems and
=A0 mobility considerations including IP flow mobility and status
tracking of IP host.
=A0 It is expected that related issues will arise that will also be
discussed on the list
=A0 that require some protocol work to be done, probably not
=A0 necessarily requiring to develop a new protocol but rather
requiring extensions to the existing protocols.

Regards,

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

 

--------------------------------------------------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

--14dae934078fa95fbf04bd40b6c1-- From sarikaya2012@gmail.com Mon Apr 9 08:47:08 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 8183621F872D for ; Mon, 9 Apr 2012 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rWuzAl6I2vBc for ; Mon, 9 Apr 2012 08:47:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB421F86C9 for ; Mon, 9 Apr 2012 08:47:07 -0700 (PDT) Received: by iazz13 with SMTP id z13so7293149iaz.31 for ; Mon, 09 Apr 2012 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fOXDjijf0La+XTB5jOsTWWzYBcd7DSPuSvyUpOX3vm4=; b=UMO7FT24aEJFfkMZS/fvZHuIxmJsFT5q+R58jTIyEq6oNEOnUrggEbJb5EwRcZ/+Wf FaW+OVotVJcg4CYiG0iof35KkzP7TayNMR0EgshK4y239GcVFkGMt1m2kCwy5RTwMpFI C2mBT8EZGU1mmBWVgbl8C3rJJ1XBh5f0tXgHsSIRjQCgLmcP2YyofKxXXUMnXIxT4OWK lxC28w5HFAIFuxg0YRyECsq3OpAjY/GD11lE7WELmv0L1jPs0A75lbcH+H5CIUlqprpG +CtKZbl5TGhQjDGODnOeAWj93Bbz4OYgwilyF4+YiI9ss0pdkaAcjvu5cJwuSWmCgsM1 QUUw== MIME-Version: 1.0 Received: by 10.42.147.69 with SMTP id m5mr2923819icv.53.1333986427234; Mon, 09 Apr 2012 08:47:07 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Mon, 9 Apr 2012 08:47:07 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> Date: Mon, 9 Apr 2012 10:47:07 -0500 Message-ID: From: Behcet Sarikaya To: pierrick.seite@orange.com Content-Type: text/plain; charset=ISO-8859-1 Cc: fmc@ietf.org Subject: Re: [fmc] List description 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: Mon, 09 Apr 2012 15:47:08 -0000 Hi Pierrick, On Fri, Apr 6, 2012 at 5:46 PM, wrote: > Hi, > > I've read this description, but I didn't really get the problem you want to >address, from the IETF standpoint. Typically, I'm surprised to not see > reference to 3GPP and BBF which are specifying FMC architectures. Yes, there is reference, it is implicitly there. >What are the use-cases from these SDOs, do these SDOs have expressed >needs for protocol extensions, is there liaison statements? Well, I would say, there is, maybe not in the form of an official liaison statement. Please kindly take a look at this report of 3GPP-BBF Workshop in San Francisco in November 2010 page 42 has this text: In case of RG with NATs additional mechanisms are needed to enable this. Jointly encourage IETF work on such mechanisms. The report is at this link: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Report/ which is public. The above is mentioned as Issue 1 in the list description.. > What do "fix" and "mobile" mean from an IETF standpoint? This is a good point. We said an IP network which happens to be fixed. You may wish to add some more text. > And so on... I think this description raises fundamental questions regarding >the problem (again, from the IETF standpoint). So, before calling for drafts >(referring to your previous mail), the problem should be clarified first. > Otherwise there is a risk to redo 3GPP/BBF work. No, if the issue requires new IETF protocol work, shouldn't we assume that SDOs did not have it done before? >.. Typically, you are referring to "Femto access point management"... Do you > >really think it is in the IETF scope? Please see above. Regards, Behcet From tso@zteusa.com Mon Apr 9 13:07: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 99A0621F87F4 for ; Mon, 9 Apr 2012 13:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 tCNSG00R+OPM for ; Mon, 9 Apr 2012 13:07: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 A42B621F87BF for ; Mon, 9 Apr 2012 13:07:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Tue, 10 Apr 2012 03:30:13 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 58488.1779289015; Tue, 10 Apr 2012 04:07:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q39K7URS011065; Tue, 10 Apr 2012 04:07:30 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: F0A7E76B:8CA8EB10-882579DB:006B4FEC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Mon, 9 Apr 2012 13:07:30 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-10 04:07:35, Serialize complete at 2012-04-10 04:07:35 Content-Type: multipart/alternative; boundary="=_alternative 006E8DFE882579DB_=" X-MAIL: mse02.zte.com.cn q39K7URS011065 Cc: fmc@ietf.org Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:07:46 -0000 This is a multipart message in MIME format. --=_alternative 006E8DFE882579DB_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, Thank you for your kind reminder on how should use the IETF mailing list. I will pay attention on this one. Regarding to you clarification, I am still confused. If we have not agreed on the issues that need to be addressed by this mailing list, and some of them have been addressed by other IETF working groups already (e.g. CGN, NAT), why they are the issues presented to IESG for this FMC mailing list? Anyway, I am hoping that, from now on, we should focus on the actual FMC issue that needs to be addressed by IETF, if any, and not on the non-issue. Thanks. Tricci Behcet Sarikaya 04/09/2012 08:32 AM Please respond to sarikaya@ieee.org To tso@zteusa.com cc fmc@ietf.org Subject Re: [fmc] List description Hi Tricci, Firstly, please stop cc'ing to fmc-bounces. The issues that require IETF protocol work (as explained at the end of the list description) are the issues this mailing list I think should concentrate In case the problem can be solved with existing means, the SDOs, e.g. Broadband Forum can go ahead and develop requirements. .Yes, some of the issues listed may not survive. CGN Issue is an example. Maybe there are other issues as well. This list of issues are given as an example because they were discussed in IETF 83 FMC side meeting. Hope it is clear now? Behcet On Fri, Apr 6, 2012 at 12:49 PM, wrote: Dear Behcet, Thank you very much for sharing this descriptions submitted to IESG. But I am so confused by the descriptions because the same set of issues that were described in the text were also discussed last week with the presentation that you have kindly prepared. I remember the outcome of our discussions were that we have "no" agreement to justify those are issues that need to be addressed by IETF. In fact, some of them have already resolved by 3GPP and/or Broadband Forum. If I have missed something between our last week discussions at the IETF and now, could you please clarify what exactly are the problems on those issues, because, as it is written, I could not understand what are the problem descriptions that you have newly found needed to be addressed? In your text, you said... >>>>> Currently identified issues to be discussed on the list include: User Equipment identification and authentication, Femto Access Point management, device type identification, Carrier-Grade Network Address Translation (CGN) related problems and mobility considerations including IP flow mobility and status tracking of IP host. It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols. >>>>> Many Thanks in advance. Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/06/2012 08:52 AM Please respond to sarikaya@ieee.org To fmc@ietf.org cc Subject [fmc] List description Hi all, This is the text Dirk and I submitted to IESG when they asked 2-3 paragraph list description: The purpose of this list on Fixed Mobile Convergence (fmc) is to be a forum to discuss and analyze all the issues that have arisen so far or to likely come up in the future regarding aspects the Fixed Mobile Convergence that requires some action in IETF Intarea or closely related areas. The scope of Fixed Mobile Convergence is limited to pure interworking between fixed and mobile networks in serving access for multi-interface terminals or mobile hosts like todays' smartphones. In the interworking scenario, the mobile network passes on the mobile subscribers policies to an IP network which happens to be fixed, in order to maintain the end-to-end service level agreement and to support remote terminal and access network management. Explicitly, the fixed IP network must have partnership with the mobile network in Fixed Mobile Convergence interworking scenario. Currently identified issues to be discussed on the list include User Equipment identification and authentication, Femto Access Point management, device type identification, Carrier-Grade Network Address Translation (CGN) related problems and mobility considerations including IP flow mobility and status tracking of IP host. It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols. Regards, Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 006E8DFE882579DB_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

Thank you for your kind reminder on how should use the IETF mailing list.  I will pay attention on this one.

Regarding to you clarification, I am still confused.  If we have not agreed on the issues that need to be addressed by this mailing list, and some of them have been addressed by other IETF working groups already (e.g. CGN, NAT), why they are the issues presented to IESG for this FMC mailing list?

Anyway, I am hoping that, from now on, we should focus on the actual FMC issue that needs to be addressed by IETF, if any, and not on the non-issue.

Thanks.
Tricci



Behcet Sarikaya <sarikaya2012@gmail.com>

04/09/2012 08:32 AM
Please respond to
sarikaya@ieee.org
To
tso@zteusa.com
cc
fmc@ietf.org
Subject
Re: [fmc] List description





Hi Tricci,

Firstly, please stop cc'ing to fmc-bounces.

The issues that require IETF protocol work (as explained at the end of the list description) are the issues this mailing list I think should concentrate In case the problem can be solved with existing means, the SDOs, e.g. Broadband Forum can go ahead and develop requirements.

.Yes, some of the issues listed may not survive. CGN Issue is an example. Maybe there are other issues as well.

This list of issues are given as an example because they were discussed in IETF 83 FMC side meeting.

Hope it is clear now?

Behcet
On Fri, Apr 6, 2012 at 12:49 PM, <tso@zteusa.com> wrote:
Dear Behcet,

Thank you very much for sharing this descriptions submitted to IESG.

But I am so confused by the descriptions because the same set of issues that were described in the text were also discussed last week with the presentation that you have kindly prepared.   I remember the outcome of our discussions were that we have "no" agreement to justify those are issues that need to be addressed by IETF.   In fact, some of them have already resolved by 3GPP and/or Broadband Forum.

If I have missed something between our last week discussions at the IETF and now, could you please clarify what exactly are the problems on those issues, because, as it is written, I could not understand what are the problem descriptions that you have newly found needed to be addressed?
 
In your text, you said...
>>>>>
Currently identified issues to be discussed on the list include:
  • User Equipment identification and authentication,
  • Femto Access Point management,
  • device type identification,
  • Carrier-Grade Network Address Translation (CGN) related problems and
    mobility considerations including IP flow mobility and
  • status tracking of IP host.
It is expected that related issues will arise that will also be discussed on the list that require some protocol work to be done, probably not necessarily requiring to develop a new protocol but rather requiring extensions to the existing protocols.
>>>>>

Many Thanks in advance.
Tricci



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

04/06/2012 08:52 AM


Please respond to
sarikaya@ieee.org
To
fmc@ietf.org
cc
Subject
[fmc] List description
Hi all,

This is the text Dirk and I submitted to IESG when they asked 2-3
paragraph list description:

The purpose of this list on Fixed Mobile Convergence (fmc)  is to be a forum to
discuss and analyze all the issues that have
  arisen so far or to likely come up in the future
   regarding aspects the Fixed
  Mobile Convergence that requires some action in IETF Intarea or
closely related areas.

   The scope of Fixed Mobile Convergence is limited to pure
interworking between
   fixed and mobile networks in
  serving access for multi-interface terminals or mobile hosts like todays'
  smartphones.  In the interworking scenario, the mobile network passes
  on the mobile subscribers policies to an IP network which happens
to be fixed,
  in order to maintain the end-to-end service level agreement and to
  support remote terminal and access network management.
  Explicitly, the fixed IP network must have partnership with the mobile
  network in Fixed Mobile Convergence interworking scenario.

  Currently identified issues to be discussed on the list include
  User Equipment identification and
  authentication, Femto Access Point management, device type
  identification, Carrier-Grade Network Address Translation (CGN)
related problems and
  mobility considerations including IP flow mobility and status
tracking of IP host.
  It is expected that related issues will arise that will also be
discussed on the list
  that require some protocol work to be done, probably not
  necessarily requiring to develop a new protocol but rather
requiring extensions to the existing protocols.

Regards,

Behcet
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 006E8DFE882579DB_=-- From sarikaya2012@gmail.com Tue Apr 10 09:21: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 D66CF11E8110 for ; Tue, 10 Apr 2012 09:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 RHKAEfBxkjlC for ; Tue, 10 Apr 2012 09:21:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED22411E80F3 for ; Tue, 10 Apr 2012 09:21:23 -0700 (PDT) Received: by iazz13 with SMTP id z13so9146710iaz.31 for ; Tue, 10 Apr 2012 09:21:23 -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=0NXwE5DPervce0db7pYCx6DvQIKb/59Uwol5v//qYKY=; b=nbmddxaSC9aELfjbiYgimUzPZD0L6Jql1NCuE/5u5TYH35MitLbNsuq2e0d2SVK9cG 4zqfKi0JSTJbjhIzeR3hMwZ841GJbvFf/utJD2pl5/0mAYho1TqwlkpcBUMSA/vqLa3q 0Z4fbZCup7e1axM77a0v4F1d5rqiD2VssiStURwIkczHFhMinmJnFovyHQBrGWWd7418 q1XWKR7rlwee52H/F2OPsvsOXjwxhkdzoWsHRg8d+GXxswYef+9TzTd3qJhcr67m6hGm PNuRA1V+ZLzsLgqw9TcPDM5kfnmMh9LiQ5PkylcLfmd5BXtKH5KuerPHhGFcGD+flHsY A8Xw== MIME-Version: 1.0 Received: by 10.42.147.69 with SMTP id m5mr5724786icv.53.1334074883175; Tue, 10 Apr 2012 09:21:23 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 10 Apr 2012 09:21:23 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 10 Apr 2012 11:21:23 -0500 Message-ID: From: Behcet Sarikaya To: David Allan I Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fmc@ietf.org" Subject: Re: [fmc] List description 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, 10 Apr 2012 16:21:28 -0000 Hi Dave, Thanks for your mail. Two points. Point 1. Can you please clarify that you have expressed your personal opinion not wearing any hats? Point 2. On: >The outstanding headwound is a wifi connected UE behind a NAT, and I >believe that is already being addressed elsewhere in the IETF. Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the problem and suggests very many solutions (5-6) and there are even solutions not mentioned in NAT Reveal Analysis draft. So it is a difficult problem and maybe explains why so many people are subscribed to this list. Regards, Behcet On Fri, Apr 6, 2012 at 5:55 PM, David Allan I wrote: > HI > > Another party heard from (Me). > > The IETF is a protocol specification body, and I do not see any protocol = specification here. > > Further this is not a greenfield problem, s much of this is already done = and dusted, and simply needs implementation agreements. As noted it is 3GPP= and BBF networks working together, which is a project well underway in the= respective SDOs. > > The outstanding headwound is a wifi connected UE behind a NAT, and I beli= eve that is already being addressed elsewhere in the IETF. > > What am I missing? > Dave > > -----Original Message----- > From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of pie= rrick.seite@orange.com > Sent: Friday, April 06, 2012 3:46 PM > To: sarikaya@ieee.org; fmc@ietf.org > Subject: Re: [fmc] List description > > Hi, > > I've read this description, but I didn't really get the problem you want = to address, from the IETF standpoint. Typically, I'm surprised to not see r= eference to 3GPP and BBF which are specifying FMC architectures. What are t= he use-cases from these SDOs, do these SDOs have expressed needs for protoc= ol extensions, is there liaison statements? What do "fix" and "mobile" mean= from an IETF standpoint? And so on... I think this description raises fund= amental questions regarding the problem (again, from the IETF standpoint). = So, before calling for drafts (referring to your previous mail), the proble= m should be clarified first. Otherwise there is a risk to redo 3GPP/BBF wor= k... Typically, you are referring to "Femto access point management"... Do = you really think it is in the IETF scope? > > Pierrick > >> -----Message d'origine----- >> De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de >> Behcet Sarikaya Envoy=E9=A0: vendredi 6 avril 2012 17:52 =C0=A0: fmc@iet= f.org >> Objet=A0: [fmc] List description >> >> Hi all, >> >> This is the text Dirk and I submitted to IESG when they asked 2-3 >> paragraph list description: >> >> The purpose of this list on Fixed Mobile Convergence (fmc) =A0is to be a >> forum to discuss and analyze all the issues that have >> =A0 =A0arisen so far or to likely come up in the future >> =A0 =A0 regarding aspects the Fixed >> =A0 =A0Mobile Convergence that requires some action in IETF Intarea or >> closely related areas. >> >> =A0 =A0 The scope of Fixed Mobile Convergence is limited to pure >> interworking between >> =A0 =A0 fixed and mobile networks in >> =A0 =A0serving access for multi-interface terminals or mobile hosts like >> todays' >> =A0 =A0smartphones. =A0In the interworking scenario, the mobile network >> passes >> =A0 =A0on the mobile subscribers policies to an IP network which happens >> to be fixed, >> =A0 =A0in order to maintain the end-to-end service level agreement and t= o >> =A0 =A0support remote terminal and access network management. >> =A0 =A0Explicitly, the fixed IP network must have partnership with the >> mobile >> =A0 =A0network in Fixed Mobile Convergence interworking scenario. >> >> =A0 =A0Currently identified issues to be discussed on the list include >> =A0 =A0User Equipment identification and >> =A0 =A0authentication, Femto Access Point management, device type >> =A0 =A0identification, Carrier-Grade Network Address Translation (CGN) >> related problems and >> =A0 =A0mobility considerations including IP flow mobility and status >> tracking of IP host. >> =A0 =A0It is expected that related issues will arise that will also be >> discussed on the list >> =A0 =A0that require some protocol work to be done, probably not >> =A0 =A0necessarily requiring to develop a new protocol but rather >> requiring extensions to the existing protocols. >> >> Regards, >> >> Behcet >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From david.i.allan@ericsson.com Tue Apr 10 11:33:01 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 CE03811E80FD for ; Tue, 10 Apr 2012 11:33:01 -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=[BAYES_00=-2.599, 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 G1sWdjw5EolA for ; Tue, 10 Apr 2012 11:33:01 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C375221F84D4 for ; Tue, 10 Apr 2012 11:33:00 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3AIWuNK030233; Tue, 10 Apr 2012 13:32:59 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 10 Apr 2012 14:32:55 -0400 From: David Allan I To: "sarikaya@ieee.org" Date: Tue, 10 Apr 2012 14:32:54 -0400 Thread-Topic: [fmc] List description Thread-Index: Ac0XNf3s85r/UMdFTwmEBdnxOdCztwAEgKgw Message-ID: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:33:02 -0000 Hi Bechet: > Thanks for your mail. > Two points. > Point 1. Can you please clarify that you have expressed your personal opi= nion not wearing any hats? Does it matter? Point 2. On: >>The outstanding headwound is a wifi connected UE behind a NAT, and I=20 >>believe that is already being addressed elsewhere in the IETF. > Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the p= roblem and suggests very many solutions (5-6) and there are even solutions = not mentioned in NAT Reveal Analysis draft. A pointer to the draft would be useful. And the WG context it is being ente= rtained in.... > So it is a difficult problem and maybe explains why so many people are su= bscribed to this list. So is solving the NAT problem the purpose of this endeavour? I did not get = that. Cheers Dave From sarikaya2012@gmail.com Tue Apr 10 13:28: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 9AF3921F8663 for ; Tue, 10 Apr 2012 13:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 jQshxefRi2A0 for ; Tue, 10 Apr 2012 13:28:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAD7A21F865E for ; Tue, 10 Apr 2012 13:28:36 -0700 (PDT) Received: by iazz13 with SMTP id z13so264400iaz.31 for ; Tue, 10 Apr 2012 13:28:36 -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=l7409BkzjrjCnUq/5bz50B+impisrdavV35HtRcpAKU=; b=aIt2HWhuLE4RDdiFsUq1TH6NKo5FKFQvgGBG8CFTi9Nf20TKtGFkCDzq3B1j1PeiBY ShQty9eJVXN5EN3lNPEJDQfP3kU/AwY+ZJNSwbkJ+ojX4nDJHFqwuGzWjXHQqkPPSGP6 OLr2gw+FOgAFEeQJRXbkWgHa43NceWB05nOrFX+UA8T9tn2m/rpEHhxaDchwTQWoPP/U zFLQuDaYLmQPPjUQ/IZVWizr0USu0pQVxtluO2Kff0IOBd32+MN9nL9JYHLzLGv/m/gx slK9Td+FL7601Abb98xopCNi/EKPq+6FIW5eVaXUiFOSkQytOai/P8Ky7QNdIZezN+Xc SYKw== MIME-Version: 1.0 Received: by 10.50.159.202 with SMTP id xe10mr3598080igb.66.1334089716382; Tue, 10 Apr 2012 13:28:36 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 10 Apr 2012 13:28:36 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 10 Apr 2012 15:28:36 -0500 Message-ID: From: Behcet Sarikaya To: David Allan I Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "fmc@ietf.org" Subject: Re: [fmc] List description 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, 10 Apr 2012 20:28:37 -0000 Hi Dave, In November 2011, 3GPP-BBF Workshop chaired by Dave Allan (BBF), Balazs Bertenyi (3GPP) issued Chairmen=92s Summary slides at: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip which stated on Slide 4 In case of RG with NATs additional mechanisms are needed to enable this. Jointly encourage IETF work on such mechanisms. That's all I have to say. I think we should concentrate on IETF work on FMC discussions on this list. Kind regards, Behcet On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: > Hi Bechet: > >> Thanks for your mail. > >> Two points. > >> Point 1. Can you please clarify that you have expressed your personal op= inion not wearing any hats? > > Does it matter? > > Point 2. On: > >>>The outstanding headwound is a wifi connected UE behind a NAT, and I >>>believe that is already being addressed elsewhere in the IETF. > >> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the = problem and suggests very many solutions (5-6) and there are even solutions= not mentioned in NAT Reveal Analysis draft. > > A pointer to the draft would be useful. And the WG context it is being en= tertained in.... > >> So it is a difficult problem and maybe explains why so many people are s= ubscribed to this list. > > So is solving the NAT problem the purpose of this endeavour? I did not ge= t that. > > > Cheers > Dave > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From david.i.allan@ericsson.com Tue Apr 10 13:32: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 AE67A11E810C for ; Tue, 10 Apr 2012 13:32:37 -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=[BAYES_00=-2.599, 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 FdV+--zpobkJ for ; Tue, 10 Apr 2012 13:32:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CF11E80F4 for ; Tue, 10 Apr 2012 13:32:36 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3AKWWBd026428; Tue, 10 Apr 2012 15:32:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 10 Apr 2012 16:32:28 -0400 From: David Allan I To: "sarikaya@ieee.org" Date: Tue, 10 Apr 2012 16:32:27 -0400 Thread-Topic: [fmc] List description Thread-Index: Ac0XWIgo+M7K1o63Q8S1R7NJK6+0FAAAB0NQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:32:37 -0000 Hi Bechet: You did not provide a useful answer. You simply pointed out to me things I'= ve said (repeatedly). I asked: 1) Where was the draft you referred to? 2) What WG is working on it? 3) Is it the topic of the effort represented by this list? Can you please clarify... Thanks Dave =20 -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Tuesday, April 10, 2012 1:29 PM To: David Allan I Cc: fmc@ietf.org Subject: Re: [fmc] List description Hi Dave, In November 2011, 3GPP-BBF Workshop chaired by Dave Allan (BBF), Balazs Bertenyi (3GPP) issued Chairmen's Summary slides at: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip which stated on Slide 4 In case of RG with NATs additional mechanisms are needed to enable this. Jo= intly encourage IETF work on such mechanisms. That's all I have to say. I think we should concentrate on IETF work on FMC discussions on this list. Kind regards, Behcet On Tue, Apr 10, 2012 at 1:32 PM, David Allan I = wrote: > Hi Bechet: > >> Thanks for your mail. > >> Two points. > >> Point 1. Can you please clarify that you have expressed your personal op= inion not wearing any hats? > > Does it matter? > > Point 2. On: > >>>The outstanding headwound is a wifi connected UE behind a NAT, and I=20 >>>believe that is already being addressed elsewhere in the IETF. > >> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the = problem and suggests very many solutions (5-6) and there are even solutions= not mentioned in NAT Reveal Analysis draft. > > A pointer to the draft would be useful. And the WG context it is being en= tertained in.... > >> So it is a difficult problem and maybe explains why so many people are s= ubscribed to this list. > > So is solving the NAT problem the purpose of this endeavour? I did not ge= t that. > > > Cheers > Dave > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From d3e3e3@gmail.com Tue Apr 10 14:07: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 B368521F8658 for ; Tue, 10 Apr 2012 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.254 X-Spam-Level: X-Spam-Status: No, score=-104.254 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 wjAJcjQlulYP for ; Tue, 10 Apr 2012 14:07:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B130321F8657 for ; Tue, 10 Apr 2012 14:07:16 -0700 (PDT) Received: by lagj5 with SMTP id j5so200129lag.31 for ; Tue, 10 Apr 2012 14:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UORBsMVwG2M4fFahdtXGnCq74WgxbCsqElwr7Sy0itQ=; b=JHymbNAon3H7NVHqo0dARi9cZx0DsvxRHFVxeXVwr0MfHDH/J5UvRk73vmdcruag2w Zp5WIJl3VMGS93+H1EBPz+JRY3IETBqBuwmRxswI+NwA7x9w/2QsXeSCIZM0bSL04098 d6Qzppf3iS19dkYv3MvN6ASfzCnDATKMCLUo/dGvuwNqJqD1NpQKjSA5KhX2b3H6raf5 BpUiCY+LobVDG7GiIL9KBNCDmqcI6lS1qEw4M8VWst/hGBVPEd2TQVf2z+WLzjJQqFij 7sx2a6P4jtLIG67O9ZaCzL0TCVy2IlFMFed+RELldTHB7W0sA/3BSuq6zkCsQhtgMMXH hRog== Received: by 10.152.133.144 with SMTP id pc16mr16262879lab.0.1334092035570; Tue, 10 Apr 2012 14:07:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Tue, 10 Apr 2012 14:06:55 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> From: Donald Eastlake Date: Tue, 10 Apr 2012 17:06:55 -0400 Message-ID: To: David Allan I Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:07:17 -0000 I think this is the draft: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ That is an INTAREA WG draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Apr 10, 2012 at 4:32 PM, David Allan I wrote: > Hi Bechet: > > You did not provide a useful answer. You simply pointed out to me things = I've said (repeatedly). > > I asked: > 1) Where was the draft you referred to? > 2) What WG is working on it? > 3) Is it the topic of the effort represented by this list? > > Can you please clarify... > > Thanks > Dave > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Tuesday, April 10, 2012 1:29 PM > To: David Allan I > Cc: fmc@ietf.org > Subject: Re: [fmc] List description > > Hi Dave, > > In November 2011, 3GPP-BBF Workshop > chaired by > > Dave Allan (BBF), Balazs Bertenyi (3GPP) > > issued Chairmen's Summary slides at: > http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.z= ip > > which stated on Slide 4 > > In case of RG with NATs additional mechanisms are needed to enable this. = Jointly encourage IETF work on such mechanisms. > > That's all I have to say. > > I think we should concentrate on IETF work on FMC discussions on this lis= t. > > Kind regards, > > Behcet > > On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: >> Hi Bechet: >> >>> Thanks for your mail. >> >>> Two points. >> >>> Point 1. Can you please clarify that you have expressed your personal o= pinion not wearing any hats? >> >> Does it matter? >> >> Point 2. On: >> >>>>The outstanding headwound is a wifi connected UE behind a NAT, and I >>>>believe that is already being addressed elsewhere in the IETF. >> >>> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the= problem and suggests very many solutions (5-6) and there are even solution= s not mentioned in NAT Reveal Analysis draft. >> >> A pointer to the draft would be useful. And the WG context it is being e= ntertained in.... >> >>> So it is a difficult problem and maybe explains why so many people are = subscribed to this list. >> >> So is solving the NAT problem the purpose of this endeavour? I did not g= et that. >> >> >> Cheers >> Dave >> >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From david.i.allan@ericsson.com Tue Apr 10 14:17:42 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 58C0F21F85A8 for ; Tue, 10 Apr 2012 14:17:42 -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=[BAYES_00=-2.599, 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 WRjVE+eQC0iF for ; Tue, 10 Apr 2012 14:17:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8021F85A3 for ; Tue, 10 Apr 2012 14:17:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3ALHYlP017242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Apr 2012 16:17:38 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 17:17:36 -0400 From: David Allan I To: Donald Eastlake Date: Tue, 10 Apr 2012 17:17:36 -0400 Thread-Topic: [fmc] List description Thread-Index: Ac0XXewm3ffqwNJhRxSSNOkENpo5HQAAEz8w Message-ID: <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:17:42 -0000 Thanks Donald.=20 So it is being addressed elsewhere. It is NOT the focus of this effort... Given that clarification, this discussion is going circular. We now revert = to "what IETF FMC work are we discussing?" Dave -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, April 10, 2012 2:07 PM To: David Allan I Cc: sarikaya@ieee.org; fmc@ietf.org Subject: Re: [fmc] List description I think this is the draft: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ That is an INTAREA WG draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Apr 10, 2012 at 4:32 PM, David Allan I = wrote: > Hi Bechet: > > You did not provide a useful answer. You simply pointed out to me things = I've said (repeatedly). > > I asked: > 1) Where was the draft you referred to? > 2) What WG is working on it? > 3) Is it the topic of the effort represented by this list? > > Can you please clarify... > > Thanks > Dave > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Tuesday, April 10, 2012 1:29 PM > To: David Allan I > Cc: fmc@ietf.org > Subject: Re: [fmc] List description > > Hi Dave, > > In November 2011, 3GPP-BBF Workshop > chaired by > > Dave Allan (BBF), Balazs Bertenyi (3GPP) > > issued Chairmen's Summary slides at: > http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > 6.zip > > which stated on Slide 4 > > In case of RG with NATs additional mechanisms are needed to enable this. = Jointly encourage IETF work on such mechanisms. > > That's all I have to say. > > I think we should concentrate on IETF work on FMC discussions on this lis= t. > > Kind regards, > > Behcet > > On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: >> Hi Bechet: >> >>> Thanks for your mail. >> >>> Two points. >> >>> Point 1. Can you please clarify that you have expressed your personal o= pinion not wearing any hats? >> >> Does it matter? >> >> Point 2. On: >> >>>>The outstanding headwound is a wifi connected UE behind a NAT, and I=20 >>>>believe that is already being addressed elsewhere in the IETF. >> >>> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the= problem and suggests very many solutions (5-6) and there are even solution= s not mentioned in NAT Reveal Analysis draft. >> >> A pointer to the draft would be useful. And the WG context it is being e= ntertained in.... >> >>> So it is a difficult problem and maybe explains why so many people are = subscribed to this list. >> >> So is solving the NAT problem the purpose of this endeavour? I did not g= et that. >> >> >> Cheers >> Dave >> >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From d3e3e3@gmail.com Tue Apr 10 15:55: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 D4AD211E80F4 for ; Tue, 10 Apr 2012 15:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 BeW7VAIagord for ; Tue, 10 Apr 2012 15:55:16 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AED8C11E8081 for ; Tue, 10 Apr 2012 15:55:12 -0700 (PDT) Received: by lbok13 with SMTP id k13so269172lbo.31 for ; Tue, 10 Apr 2012 15:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OZNbLCBPEm3XrvMbcybpgMwYGyWhOq7z5e/9f3VihJg=; b=Ci5vJzsAVrlVbkzm2cgkEVPZB2u89mZSySTk5oXJlgL/siy5yD4gOpVcjYdGSl2t1w U7c0+KQURm36v3K6eUCyHFGshHoOsryK0Cw2kHCltsImm+OHVwWyF9aiaBMp+vcrSEl6 xmtCrmKc6XlYjijKRY48mGcXKkc9nqTkIdDtBVt0A94BuUecPREiqp9Lcw/liZ2L102D mYPPY/4bgYhGGyPhcdgWe8a0ej6i1CxnCRFZohkt1O22wFWK9V7NrgWPAPVk4GS+fBvk mqk+4TyqUrfxYJwTKPhDj7oSdWn1Ta/SX+S/R6YRzgKVDVfZxvBr+nyjBwzLkAKbOArO wcWQ== Received: by 10.112.103.196 with SMTP id fy4mr2041588lbb.18.1334098511464; Tue, 10 Apr 2012 15:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Tue, 10 Apr 2012 15:54:51 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> From: Donald Eastlake Date: Tue, 10 Apr 2012 18:54:51 -0400 Message-ID: To: David Allan I Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:55:17 -0000 I think that the nat-reveal draft, while it discusses 8 different possible solutions, does not actually propose any specific solution for any specific problem, such as the FMC/NAT problem. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Apr 10, 2012 at 5:17 PM, David Allan I wrote: > Thanks Donald. > > So it is being addressed elsewhere. It is NOT the focus of this effort... > > Given that clarification, this discussion is going circular. We now rever= t to "what IETF FMC work are we discussing?" > > Dave > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, April 10, 2012 2:07 PM > To: David Allan I > Cc: sarikaya@ieee.org; fmc@ietf.org > Subject: Re: [fmc] List description > > I think this is the draft: > https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ > That is an INTAREA WG draft. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > > On Tue, Apr 10, 2012 at 4:32 PM, David Allan I wrote: >> Hi Bechet: >> >> You did not provide a useful answer. You simply pointed out to me things= I've said (repeatedly). >> >> I asked: >> 1) Where was the draft you referred to? >> 2) What WG is working on it? >> 3) Is it the topic of the effort represented by this list? >> >> Can you please clarify... >> >> Thanks >> Dave >> >> >> >> >> -----Original Message----- >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Sent: Tuesday, April 10, 2012 1:29 PM >> To: David Allan I >> Cc: fmc@ietf.org >> Subject: Re: [fmc] List description >> >> Hi Dave, >> >> In November 2011, 3GPP-BBF Workshop >> chaired by >> >> Dave Allan (BBF), Balazs Bertenyi (3GPP) >> >> issued Chairmen's Summary slides at: >> http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 >> 6.zip >> >> which stated on Slide 4 >> >> In case of RG with NATs additional mechanisms are needed to enable this.= Jointly encourage IETF work on such mechanisms. >> >> That's all I have to say. >> >> I think we should concentrate on IETF work on FMC discussions on this li= st. >> >> Kind regards, >> >> Behcet >> >> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: >>> Hi Bechet: >>> >>>> Thanks for your mail. >>> >>>> Two points. >>> >>>> Point 1. Can you please clarify that you have expressed your personal = opinion not wearing any hats? >>> >>> Does it matter? >>> >>> Point 2. On: >>> >>>>>The outstanding headwound is a wifi connected UE behind a NAT, and I >>>>>believe that is already being addressed elsewhere in the IETF. >>> >>>> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes th= e problem and suggests very many solutions (5-6) and there are even solutio= ns not mentioned in NAT Reveal Analysis draft. >>> >>> A pointer to the draft would be useful. And the WG context it is being = entertained in.... >>> >>>> So it is a difficult problem and maybe explains why so many people are= subscribed to this list. >>> >>> So is solving the NAT problem the purpose of this endeavour? I did not = get that. >>> >>> >>> Cheers >>> Dave >>> >>> _______________________________________________ >>> fmc mailing list >>> fmc@ietf.org >>> https://www.ietf.org/mailman/listinfo/fmc >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc From david.i.allan@ericsson.com Tue Apr 10 16:00:21 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 3AEE011E80F4 for ; Tue, 10 Apr 2012 16:00:21 -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=[BAYES_00=-2.599, 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 CThN6wL+x4PQ for ; Tue, 10 Apr 2012 16:00:20 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 473A511E8081 for ; Tue, 10 Apr 2012 16:00:20 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3AN05bA024313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Apr 2012 18:00:14 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 10 Apr 2012 19:00:08 -0400 From: David Allan I To: Donald Eastlake Date: Tue, 10 Apr 2012 19:00:07 -0400 Thread-Topic: [fmc] List description Thread-Index: Ac0XbPyx76ICiK37RpS8Sv96saU2/wAACXIg Message-ID: <60C093A41B5E45409A19D42CF7786DFD522EC71619@EUSAACMS0703.eamcs.ericsson.se> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:00:21 -0000 Understood, But there is also the stateless-NAT work going forward, that also looks eas= ily adapted to this role. Once a UE identity is associated with a port rang= e, the traffic self identifies. It seems to me that a common criteria of goodness could be applied. One cor= relation between identity and flows is via management, one is transactional= (initial identification/authentication), the rest of the implementation an= d application of policy could be pretty much the same classification steps. Cheers Dave=20 -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, April 10, 2012 3:55 PM To: David Allan I Cc: sarikaya@ieee.org; fmc@ietf.org Subject: Re: [fmc] List description I think that the nat-reveal draft, while it discusses 8 different possible = solutions, does not actually propose any specific solution for any specific= problem, such as the FMC/NAT problem. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Apr 10, 2012 at 5:17 PM, David Allan I = wrote: > Thanks Donald. > > So it is being addressed elsewhere. It is NOT the focus of this effort... > > Given that clarification, this discussion is going circular. We now rever= t to "what IETF FMC work are we discussing?" > > Dave > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, April 10, 2012 2:07 PM > To: David Allan I > Cc: sarikaya@ieee.org; fmc@ietf.org > Subject: Re: [fmc] List description > > I think this is the draft: > https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysi > s/ > That is an INTAREA WG draft. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > > On Tue, Apr 10, 2012 at 4:32 PM, David Allan I wrote: >> Hi Bechet: >> >> You did not provide a useful answer. You simply pointed out to me things= I've said (repeatedly). >> >> I asked: >> 1) Where was the draft you referred to? >> 2) What WG is working on it? >> 3) Is it the topic of the effort represented by this list? >> >> Can you please clarify... >> >> Thanks >> Dave >> >> >> >> >> -----Original Message----- >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Sent: Tuesday, April 10, 2012 1:29 PM >> To: David Allan I >> Cc: fmc@ietf.org >> Subject: Re: [fmc] List description >> >> Hi Dave, >> >> In November 2011, 3GPP-BBF Workshop >> chaired by >> >> Dave Allan (BBF), Balazs Bertenyi (3GPP) >> >> issued Chairmen's Summary slides at: >> http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-110 >> 4 >> 6.zip >> >> which stated on Slide 4 >> >> In case of RG with NATs additional mechanisms are needed to enable this.= Jointly encourage IETF work on such mechanisms. >> >> That's all I have to say. >> >> I think we should concentrate on IETF work on FMC discussions on this li= st. >> >> Kind regards, >> >> Behcet >> >> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: >>> Hi Bechet: >>> >>>> Thanks for your mail. >>> >>>> Two points. >>> >>>> Point 1. Can you please clarify that you have expressed your personal = opinion not wearing any hats? >>> >>> Does it matter? >>> >>> Point 2. On: >>> >>>>>The outstanding headwound is a wifi connected UE behind a NAT, and=20 >>>>>I believe that is already being addressed elsewhere in the IETF. >>> >>>> Yes, there is a draft called NAT Reveal Analysis draft. It analyzes th= e problem and suggests very many solutions (5-6) and there are even solutio= ns not mentioned in NAT Reveal Analysis draft. >>> >>> A pointer to the draft would be useful. And the WG context it is being = entertained in.... >>> >>>> So it is a difficult problem and maybe explains why so many people are= subscribed to this list. >>> >>> So is solving the NAT problem the purpose of this endeavour? I did not = get that. >>> >>> >>> Cheers >>> Dave >>> >>> _______________________________________________ >>> fmc mailing list >>> fmc@ietf.org >>> https://www.ietf.org/mailman/listinfo/fmc >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc From mohamed.boucadair@orange.com Tue Apr 10 23:06:41 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AFC21F848F for ; Tue, 10 Apr 2012 23:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, 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 l97qZgygNEea for ; Tue, 10 Apr 2012 23:06:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3821F8483 for ; Tue, 10 Apr 2012 23:06:39 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 54F3A264313; Wed, 11 Apr 2012 08:06:38 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 395814C027; Wed, 11 Apr 2012 08:06:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 11 Apr 2012 08:06:38 +0200 From: To: Donald Eastlake , David Allan I Date: Wed, 11 Apr 2012 08:06:37 +0200 Thread-Topic: [fmc] List description Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtA Message-ID: <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.11.35418 Cc: Dean cheng , "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 06:06:41 -0000 Dear all, There is no recommended solution for the FMC case, because there are not cl= ear requirements for that case.=20 I have suggested to Behcet to further elaborate on the requirements from an= "FMC" standpoint. Below an excerpt of what I sent to Behcet: * The current HOST_ID effort in INTAREA WG is restricted to the analysis of= potential channels which may convey the HOST_ID information * A recommendation is likely to be added.but in the context of address shar= ing (RFC6269) * FMC proponents should elaborate further their requirements for the HOST_I= D (1) Required only during session initialization? (2) Required for all transport protocols? (3) Host modification should be avoided or it does not harm? (4) Which entity will use the HOST_ID information: proxy servers, else? (4a) Packet inspection is required? No? (4b) Performance impact (5) Which entity will set the HOST_ID information? BTW, I discussed this point with some colleagues and it seems using port se= ts would be more appropriate for the FMC case (i.e., http://tools.ietf.org/= html/draft-ietf-intarea-nat-reveal-analysis-01#section-3.3).=20 If port sets are used, a dedicated notification channel is needed to report= assigned port sets. FYI, I'm working with Dean on this point.=20 Cheers, Med=20 >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de Donald Eastlake >Envoy=E9 : mercredi 11 avril 2012 00:55 >=C0 : David Allan I >Cc : sarikaya@ieee.org; fmc@ietf.org >Objet : Re: [fmc] List description > >I think that the nat-reveal draft, while it discusses 8 different >possible solutions, does not actually propose any specific solution >for any specific problem, such as the FMC/NAT problem. > >Thanks, >Donald >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >=A0155 Beaver Street,=A0Milford, MA 01757 USA >=A0d3e3e3@gmail.com > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > wrote: >> Thanks Donald. >> >> So it is being addressed elsewhere. It is NOT the focus of=20 >this effort... >> >> Given that clarification, this discussion is going circular.=20 >We now revert to "what IETF FMC work are we discussing?" >> >> Dave >> >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: Tuesday, April 10, 2012 2:07 PM >> To: David Allan I >> Cc: sarikaya@ieee.org; fmc@ietf.org >> Subject: Re: [fmc] List description >> >> I think this is the draft: >>=20 >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- >analysis/ >> That is an INTAREA WG draft. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >> =A0155 Beaver Street,=A0Milford, MA 01757 USA >> =A0d3e3e3@gmail.com >> >> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I=20 > wrote: >>> Hi Bechet: >>> >>> You did not provide a useful answer. You simply pointed out=20 >to me things I've said (repeatedly). >>> >>> I asked: >>> 1) Where was the draft you referred to? >>> 2) What WG is working on it? >>> 3) Is it the topic of the effort represented by this list? >>> >>> Can you please clarify... >>> >>> Thanks >>> Dave >>> >>> >>> >>> >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> Sent: Tuesday, April 10, 2012 1:29 PM >>> To: David Allan I >>> Cc: fmc@ietf.org >>> Subject: Re: [fmc] List description >>> >>> Hi Dave, >>> >>> In November 2011, 3GPP-BBF Workshop >>> chaired by >>> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) >>> >>> issued Chairmen's Summary slides at: >>>=20 >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 >>> 6.zip >>> >>> which stated on Slide 4 >>> >>> In case of RG with NATs additional mechanisms are needed to=20 >enable this. Jointly encourage IETF work on such mechanisms. >>> >>> That's all I have to say. >>> >>> I think we should concentrate on IETF work on FMC=20 >discussions on this list. >>> >>> Kind regards, >>> >>> Behcet >>> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I=20 > wrote: >>>> Hi Bechet: >>>> >>>>> Thanks for your mail. >>>> >>>>> Two points. >>>> >>>>> Point 1. Can you please clarify that you have expressed=20 >your personal opinion not wearing any hats? >>>> >>>> Does it matter? >>>> >>>> Point 2. On: >>>> >>>>>>The outstanding headwound is a wifi connected UE behind a=20 >NAT, and I >>>>>>believe that is already being addressed elsewhere in the IETF. >>>> >>>>> Yes, there is a draft called NAT Reveal Analysis draft.=20 >It analyzes the problem and suggests very many solutions (5-6)=20 >and there are even solutions not mentioned in NAT Reveal=20 >Analysis draft. >>>> >>>> A pointer to the draft would be useful. And the WG context=20 >it is being entertained in.... >>>> >>>>> So it is a difficult problem and maybe explains why so=20 >many people are subscribed to this list. >>>> >>>> So is solving the NAT problem the purpose of this=20 >endeavour? I did not get that. >>>> >>>> >>>> Cheers >>>> Dave >>>> >>>> _______________________________________________ >>>> fmc mailing list >>>> fmc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fmc >>> _______________________________________________ >>> fmc mailing list >>> fmc@ietf.org >>> https://www.ietf.org/mailman/listinfo/fmc >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc >= From pierrick.seite@orange.com Wed Apr 11 04:13:11 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 216A511E80A3 for ; Wed, 11 Apr 2012 04:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=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 eEKEiBslSTmR for ; Wed, 11 Apr 2012 04:13:10 -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 374A211E808F for ; Wed, 11 Apr 2012 04:13:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D19F9DE401D; Wed, 11 Apr 2012 13:14:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 5686BDE401B; Wed, 11 Apr 2012 12:18:04 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:15:32 +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: Wed, 11 Apr 2012 12:15:32 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] List description Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAAAinzKA= References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr><60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> From: To: , , X-OriginalArrivalTime: 11 Apr 2012 10:15:32.0837 (UTC) FILETIME=[0763F150:01CD17CC] Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:13:11 -0000 Hi, I definitely agree we should elaborate first on requirements from an = "FMC" standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus = on a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with = respect to work done in other WG (or SDOs), to see what protocol = extensions are needed. Pierrick > -----Message d'origine----- > De=A0: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part = de > mohamed.boucadair@orange.com > Envoy=E9=A0: mercredi 11 avril 2012 08:07 > =C0=A0: Donald Eastlake; David Allan I > Cc=A0: Dean cheng; sarikaya@ieee.org; fmc@ietf.org > Objet=A0: Re: [fmc] List description >=20 > Dear all, >=20 > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: >=20 > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID = information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, = else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? >=20 > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > 01#section-3.3). >=20 > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > >=A0155 Beaver Street,=A0Milford, MA 01757 USA > >=A0d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > >> =A0155 Beaver Street,=A0Milford, MA 01757 USA > >> =A0d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > = >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From jonghyouk@gmail.com Wed Apr 11 04:42:56 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 D843F21F8663 for ; Wed, 11 Apr 2012 04:42:56 -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_53=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 ClF6lhR9BqTA for ; Wed, 11 Apr 2012 04:42:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2421F865F for ; Wed, 11 Apr 2012 04:42:55 -0700 (PDT) Received: by iazz13 with SMTP id z13so1418315iaz.31 for ; Wed, 11 Apr 2012 04:42: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=AOeS6y7zBUNU8IhomOgQR0Qr9uXJGS5/7ZIrcordAaI=; b=yol48hk/kmBAtCTbBBESrtvfSXMhkEU4Sj8kouv+U+PL9eMqP1D3nFzZHvTR52nYnq aGZc+AvO5IibmchbfMFKYF/UzDpWfoaHQ1RZy5viiPDm+iW7mh/hCoeS+1vVzyXrh0yX ElIhQVN+cOualyrofjaj/NWbGcCw3NgNCabRvmCZ0J+afyxr9YAi7p24NJRmkby9k16y N5jjqhKCcKLtdwC1FYVnYEedVeBVff1lBvwyziJy1WNaNFWvgHL9PloGpqxSdnRjNazY u6Vr+wtAHb8ksnUuVDM4WikJIkCn6XxiC1NSIwpW/PTX/fOTb+Mo/lqwJRvH3OWOxHPR HVvQ== MIME-Version: 1.0 Received: by 10.50.194.194 with SMTP id hy2mr1608555igc.52.1334144574786; Wed, 11 Apr 2012 04:42:54 -0700 (PDT) Received: by 10.64.32.72 with HTTP; Wed, 11 Apr 2012 04:42:54 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> Date: Wed, 11 Apr 2012 13:42:54 +0200 Message-ID: From: Jong-Hyouk Lee To: pierrick.seite@orange.com Content-Type: multipart/alternative; boundary=14dae934067d758ad304bd65bd88 Cc: david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, sarikaya@ieee.org, d3e3e3@gmail.com, mohamed.boucadair@orange.com Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:42:57 -0000 --14dae934067d758ad304bd65bd88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fully agree with his words. On Wed, Apr 11, 2012 at 12:15 PM, wrote: > Hi, > > I definitely agree we should elaborate first on requirements from an "FMC= " > standpoint. And I'd add "from and IETF standpoint" also... > > Before talking about solutions, I think we should try to get consensus on > a list of clear requirements with their Motivation/use-case. > > Then, we could talk about solutions and go to a gap analysis, with respec= t > to work done in other WG (or SDOs), to see what protocol extensions are > needed. > > Pierrick > > > -----Message d'origine----- > > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com > > Envoy=C3=A9 : mercredi 11 avril 2012 08:07 > > =C3=80 : Donald Eastlake; David Allan I > > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org > > Objet : Re: [fmc] List description > > > > Dear all, > > > > There is no recommended solution for the FMC case, because there are > > not clear requirements for that case. > > I have suggested to Behcet to further elaborate on the requirements > > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > > > * The current HOST_ID effort in INTAREA WG is restricted to the > > analysis of potential channels which may convey the HOST_ID information > > * A recommendation is likely to be added.but in the context of address > > sharing (RFC6269) > > * FMC proponents should elaborate further their requirements for the > > HOST_ID > > (1) Required only during session initialization? > > (2) Required for all transport protocols? > > (3) Host modification should be avoided or it does not harm? > > (4) Which entity will use the HOST_ID information: proxy servers, else? > > (4a) Packet inspection is required? No? > > (4b) Performance impact > > (5) Which entity will set the HOST_ID information? > > > > BTW, I discussed this point with some colleagues and it seems using > > port sets would be more appropriate for the FMC case (i.e., > > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > > 01#section-3.3). > > > > If port sets are used, a dedicated notification channel is needed to > > report assigned port sets. FYI, I'm working with Dean on this point. > > > > Cheers, > > Med > > > > >-----Message d'origine----- > > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > > >part de Donald Eastlake > > >Envoy=C3=A9 : mercredi 11 avril 2012 00:55 > > >=C3=80 : David Allan I > > >Cc : sarikaya@ieee.org; fmc@ietf.org > > >Objet : Re: [fmc] List description > > > > > >I think that the nat-reveal draft, while it discusses 8 different > > >possible solutions, does not actually propose any specific solution > > >for any specific problem, such as the FMC/NAT problem. > > > > > >Thanks, > > >Donald > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > 155 Beaver Street, Milford, MA 01757 USA > > > d3e3e3@gmail.com > > > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > > wrote: > > >> Thanks Donald. > > >> > > >> So it is being addressed elsewhere. It is NOT the focus of > > >this effort... > > >> > > >> Given that clarification, this discussion is going circular. > > >We now revert to "what IETF FMC work are we discussing?" > > >> > > >> Dave > > >> > > >> -----Original Message----- > > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > > >> Sent: Tuesday, April 10, 2012 2:07 PM > > >> To: David Allan I > > >> Cc: sarikaya@ieee.org; fmc@ietf.org > > >> Subject: Re: [fmc] List description > > >> > > >> I think this is the draft: > > >> > > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > > >analysis/ > > >> That is an INTAREA WG draft. > > >> > > >> Thanks, > > >> Donald > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > >> 155 Beaver Street, Milford, MA 01757 USA > > >> d3e3e3@gmail.com > > >> > > >> > > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > > wrote: > > >>> Hi Bechet: > > >>> > > >>> You did not provide a useful answer. You simply pointed out > > >to me things I've said (repeatedly). > > >>> > > >>> I asked: > > >>> 1) Where was the draft you referred to? > > >>> 2) What WG is working on it? > > >>> 3) Is it the topic of the effort represented by this list? > > >>> > > >>> Can you please clarify... > > >>> > > >>> Thanks > > >>> Dave > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > > >>> Sent: Tuesday, April 10, 2012 1:29 PM > > >>> To: David Allan I > > >>> Cc: fmc@ietf.org > > >>> Subject: Re: [fmc] List description > > >>> > > >>> Hi Dave, > > >>> > > >>> In November 2011, 3GPP-BBF Workshop > > >>> chaired by > > >>> > > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > > >>> > > >>> issued Chairmen's Summary slides at: > > >>> > > >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > > >>> 6.zip > > >>> > > >>> which stated on Slide 4 > > >>> > > >>> In case of RG with NATs additional mechanisms are needed to > > >enable this. Jointly encourage IETF work on such mechanisms. > > >>> > > >>> That's all I have to say. > > >>> > > >>> I think we should concentrate on IETF work on FMC > > >discussions on this list. > > >>> > > >>> Kind regards, > > >>> > > >>> Behcet > > >>> > > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > > wrote: > > >>>> Hi Bechet: > > >>>> > > >>>>> Thanks for your mail. > > >>>> > > >>>>> Two points. > > >>>> > > >>>>> Point 1. Can you please clarify that you have expressed > > >your personal opinion not wearing any hats? > > >>>> > > >>>> Does it matter? > > >>>> > > >>>> Point 2. On: > > >>>> > > >>>>>>The outstanding headwound is a wifi connected UE behind a > > >NAT, and I > > >>>>>>believe that is already being addressed elsewhere in the IETF. > > >>>> > > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > > >It analyzes the problem and suggests very many solutions (5-6) > > >and there are even solutions not mentioned in NAT Reveal > > >Analysis draft. > > >>>> > > >>>> A pointer to the draft would be useful. And the WG context > > >it is being entertained in.... > > >>>> > > >>>>> So it is a difficult problem and maybe explains why so > > >many people are subscribed to this list. > > >>>> > > >>>> So is solving the NAT problem the purpose of this > > >endeavour? I did not get that. > > >>>> > > >>>> > > >>>> Cheers > > >>>> Dave > > >>>> > > >>>> _______________________________________________ > > >>>> fmc mailing list > > >>>> fmc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/fmc > > >>> _______________________________________________ > > >>> fmc mailing list > > >>> fmc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/fmc > > >_______________________________________________ > > >fmc mailing list > > >fmc@ietf.org > > >https://www.ietf.org/mailman/listinfo/fmc > > > > > _______________________________________________ > > fmc mailing list > > fmc@ietf.org > > https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --14dae934067d758ad304bd65bd88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fully agree with his words.

On Wed, Apr 1= 1, 2012 at 12:15 PM, <pierrick.seite@orange.com> wrote:
Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" = also...

Before talking about solutions, I think we should try to get consensus on a= list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect = to work done in other WG (or SDOs), to see what protocol extensions are nee= ded.

Pierrick

> -----Message d'origine-----
> De=C2=A0: fmc-bounces@ietf.org= [mailto:fmc-bounces@ietf.org] De la part de
> mohamed.boucadai= r@orange.com
> Envoy=C3=A9=C2=A0: mercredi 11 avril 2012 08:07
> =C3=80=C2=A0: Donald Eastlake; David Allan I
> Cc=C2=A0: Dean cheng; sarikaya@ie= ee.org; fmc@ietf.org
> Objet=C2=A0: Re: [fmc] List description
>
> Dear all,
>
> There is no recommended solution for the FMC case, because there are > not clear requirements for that case.
> I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to= Behcet:
>
> * The current HOST_ID effort in INTAREA WG is restricted to the
> analysis of potential channels which may convey the HOST_ID informatio= n
> * A recommendation is likely to be added.but in the context of address=
> sharing (RFC6269)
> * FMC proponents should elaborate further their requirements for the > HOST_ID
> (1) Required only during session initialization?
> (2) Required for all transport protocols?
> (3) Host modification should be avoided or it does not harm?
> (4) Which entity will use the HOST_ID information: proxy servers, else= ?
> =C2=A0 (4a) Packet inspection is required? No?
> =C2=A0 (4b) Performance impact
> (5) Which entity will set the HOST_ID information?
>
> BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e.,
> http://tools.ietf.org/html/draft-ietf-intarea-na= t-reveal-analysis-
> 01#section-3.3).
>
> If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this poin= t.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : fmc-bounces@ietf.org<= /a> [mailto:fmc-bounces@ietf.org] De la
> >part de Donald Eastlake
> >Envoy=C3=A9 : mercredi 11 avril 2012 00:55
> >=C3=80 : David Allan I
> >Cc : sarikaya@ieee.org; <= a href=3D"mailto:fmc@ietf.org">fmc@ietf.org
> >Objet : Re: [fmc] List description
> >
> >I think that the nat-reveal draft, while it discusses 8 different<= br> > >possible solutions, does not actually propose any specific solutio= n
> >for any specific problem, such as the FMC/NAT problem.
> >
> >Thanks,
> >Donald
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> >=C2=A0Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508-333-2270 (cell)
> >=C2=A0155 Beaver Street,=C2=A0Milford, MA 01757 USA
> >=C2=A0d3e3e3@gmail.com
> >
> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
> ><david.i.allan@er= icsson.com> wrote:
> >> Thanks Donald.
> >>
> >> So it is being addressed elsewhere. It is NOT the focus of > >this effort...
> >>
> >> Given that clarification, this discussion is going circular.<= br> > >We now revert to "what IETF FMC work are we discussing?"=
> >>
> >> Dave
> >>
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> >> Sent: Tuesday, April 10, 2012 2:07 PM
> >> To: David Allan I
> >> Cc: sarikaya@ieee.org; fmc@ietf.org
> >> Subject: Re: [fmc] List description
> >>
> >> I think this is the draft:
> >>
> >https://datatracker.ietf.org/doc/draft-ietf-int= area-nat-reveal-
> >analysis/
> >> That is an INTAREA WG draft.
> >>
> >> Thanks,
> >> Donald
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> =C2=A0Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508-333-2270 (cell)
> >> =C2=A0155 Beaver Street,=C2=A0Milford, MA 01757 USA
> >> =C2=A0d3e3e3@gmail.com
> >>
> >>
> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
> ><david.i.allan@er= icsson.com> wrote:
> >>> Hi Bechet:
> >>>
> >>> You did not provide a useful answer. You simply pointed o= ut
> >to me things I've said (repeatedly).
> >>>
> >>> I asked:
> >>> 1) Where was the draft you referred to?
> >>> 2) What WG is working on it?
> >>> 3) Is it the topic of the effort represented by this list= ?
> >>>
> >>> Can you please clarify...
> >>>
> >>> Thanks
> >>> Dave
> >>>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
> >>> Sent: Tuesday, April 10, 2012 1:29 PM
> >>> To: David Allan I
> >>> Cc: fmc@ietf.org
> >>> Subject: Re: [fmc] List description
> >>>
> >>> Hi Dave,
> >>>
> >>> In November 2011, 3GPP-BBF Workshop
> >>> chaired by
> >>>
> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP)
> >>>
> >>> issued Chairmen's Summary slides at:
> >>>
> >http://www.3gpp.org/ftp/workshop/2011-11= -09_3GPP_BBF_SFO/Docs/3BF-1104
> >>> 6.zip
> >>>
> >>> which stated on Slide 4
> >>>
> >>> In case of RG with NATs additional mechanisms are needed = to
> >enable this. Jointly encourage IETF work on such mechanisms.
> >>>
> >>> That's all I have to say.
> >>>
> >>> I think we should concentrate on IETF work on FMC
> >discussions on this list.
> >>>
> >>> Kind regards,
> >>>
> >>> Behcet
> >>>
> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
> ><david.i.allan@er= icsson.com> wrote:
> >>>> Hi Bechet:
> >>>>
> >>>>> Thanks for your mail.
> >>>>
> >>>>> Two points.
> >>>>
> >>>>> Point 1. Can you please clarify that you have exp= ressed
> >your personal opinion not wearing any hats?
> >>>>
> >>>> Does it matter?
> >>>>
> >>>> Point 2. On:
> >>>>
> >>>>>>The outstanding headwound is a wifi connected = UE behind a
> >NAT, and I
> >>>>>>believe that is already being addressed elsewh= ere in the IETF.
> >>>>
> >>>>> Yes, there is a draft called NAT Reveal Analysis = draft.
> >It analyzes the problem and suggests very many solutions (5-6)
> >and there are even solutions not mentioned in NAT Reveal
> >Analysis draft.
> >>>>
> >>>> A pointer to the draft would be useful. And the WG co= ntext
> >it is being entertained in....
> >>>>
> >>>>> So it is a difficult problem and maybe explains w= hy so
> >many people are subscribed to this list.
> >>>>
> >>>> So is solving the NAT problem the purpose of this
> >endeavour? I did not get that.
> >>>>
> >>>> <snipped to end>
> >>>> Cheers
> >>>> Dave
> >>>>
> >>>> _______________________________________________
> >>>> fmc mailing list
> >>>> fmc@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/fmc
> >>> _______________________________________________
> >>> fmc mailing list
> >>> fmc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/fmc
> >_______________________________________________
> >fmc mailing list
> >fmc@ietf.org
> >https://www.ietf.org/mailman/listinfo/fmc
> >
> _______________________________________________
> fmc mailing list
> fmc@ietf.org
> https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
fmc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/fmc



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com

--14dae934067d758ad304bd65bd88-- From Dirk.von-Hugo@telekom.de Wed Apr 11 05:38: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 3262221F853A for ; Wed, 11 Apr 2012 05:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6] 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 dmCr5jBGOer5 for ; Wed, 11 Apr 2012 05:38:21 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7F19E21F84DE for ; Wed, 11 Apr 2012 05:38:20 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 11 Apr 2012 14:38:17 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.36]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 11 Apr 2012 14:38:16 +0200 From: To: , , , Date: Wed, 11 Apr 2012 14:38:15 +0200 Thread-Topic: [fmc] List description Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAAAinzKAAA3hBAA== Message-ID: <05C81A773E48DD49B181B04BA21A342A2796F6C4D7@HE113484.emea1.cds.t-internal.com> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr><60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462024D6634@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:38:22 -0000 Dear all, As far as I understand here we are all on track - we currently have to disc= uss and come hopefully to a conclusion which aspects of interoperation betw= een fixed and mobile networks to provide a unified service to end users can= be solved by means of IETF i.e. e.g. proposing a BCP of existing protocols= or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would add= my issues here: - beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', = 'available', 'be right back' etc.) and related operator policies also the c= haracteristics of currently used terminals is an important aspect both for = service provisioning (e.g. adaptation of information data rate to screen si= ze and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF requir= ements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been published here= http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detai= led requirements for us cannot be derived therefrom easily ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pier= rick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.= com Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC" = standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on a= list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect = to work done in other WG (or SDOs), to see what protocol extensions are nee= ded. Pierrick > -----Message d'origine----- > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9 : mercredi 11 avril 2012 08:07 > =C0 : Donald Eastlake; David Allan I > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org > Objet : Re: [fmc] List description > > Dear all, > > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? > > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > 01#section-3.3). > > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. > > Cheers, > Med > > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc From hasnaa.moustafa@gmail.com Wed Apr 11 07:33: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 D612421F8510 for ; Wed, 11 Apr 2012 07:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 G+iaVFI0LOzH for ; Wed, 11 Apr 2012 07:33:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8703921F850C for ; Wed, 11 Apr 2012 07:33:25 -0700 (PDT) Received: by lagj5 with SMTP id j5so818465lag.31 for ; Wed, 11 Apr 2012 07:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5SdeF4CLQq9VFXvlbKyfAgv5KIs2ILZwEjAiaL+YgC0=; b=ZkI1p060CfT7IlO9J2mYpj6nQi5wuxc2Rx85d/zu5EsX2VanfHBHDX0KuYGW5JpdUt ellmzTiQqje5joO4wZtwppZK6ilxVjdnoiuknleukreKMKbKwn/jIx6vqIRC05uqexdy VxUKaBMnMBcKG9Ppr6weWSM+fLyQl/F5mw36NaqxoVlW+oBMH/b2AhOPFzJizdCAw1Fk Y3xE7BPu6QBJuhWUx1cqD8s+/gU5v739yTSNJ8TCQnXHM7Jq9R4CrV2Oy0OwcWYPDhXU AXroDEkGVrgrMsL+pK0XCsVYDhYzqb3zOAsNkIA2xU2sJS4jvQmbA2tZQBSeahxP6cLX Gglw== MIME-Version: 1.0 Received: by 10.152.113.229 with SMTP id jb5mr18277893lab.45.1334154804397; Wed, 11 Apr 2012 07:33:24 -0700 (PDT) Received: by 10.152.6.168 with HTTP; Wed, 11 Apr 2012 07:33:24 -0700 (PDT) Date: Wed, 11 Apr 2012 16:33:24 +0200 Message-ID: From: Hasnaa Moustafa To: fmc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [fmc] List Description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:33:26 -0000 Hi, I agree that we need to start by explaining the motivation and use-cases then do a list of requirements and see what needs to be done at the ietf (which is not done in other SDOs) to satisfy these requirements. So, I do not know Behcet, what would be the shape of the progress under this topic. - update the problem statement? or split the problem statement into several topics (motivation/use-cases, requirements, what exists outside the ietf and what's missing? Regards, Hassnaa ---------- Forwarded message ---------- From: To: , , Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org Date: Wed, 11 Apr 2012 12:15:32 +0200 Subject: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC" standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed. Pierrick From hasnaa.moustafa@gmail.com Wed Apr 11 12:09:53 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 716ED21F848C for ; Wed, 11 Apr 2012 12:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, 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 uBMbCdI2AWAt for ; Wed, 11 Apr 2012 12:09:50 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C0FB421F848B for ; Wed, 11 Apr 2012 12:09:49 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4291408wib.1 for ; Wed, 11 Apr 2012 12:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=n6/k2V0QX6AZ2gIDsucFJmK8PXGB+MxDlngdkcJBkpU=; b=qJJF/UwfD2KU1l/J+BDZaozrbIoSTzKcAPh9VM80YmKnnjR37rAkEbvBszhi32h4uH z8Kbxu2EGSph2kUrmyNTnR/141LpuhooLPEiJm3KmxldxWmHfQPsLlV9Zn3yz7ExupcN XWfC0dNVL7esuT95sOX83SvVjmjAuxKYrLfgPP3bmDx/N88Mmofv7HTva4c4wyT3U1IV sOs5bdj0GN/7lBHzVpJlc0fkufo+UWC83DxL8JTjCaBW2ujS85Tq2y31Virm1AUKeqKn BK4wKwpOxj0IxMuzAfTOnzWRMAGQbr/RlZC4ZAIoy9i4DKGIHSF2YPfzhwwqHRxKDlAd IzvA== Received: by 10.180.91.10 with SMTP id ca10mr9108435wib.17.1334171387188; Wed, 11 Apr 2012 12:09:47 -0700 (PDT) Received: from new-host-2.home (APuteaux-155-1-108-229.w90-44.abo.wanadoo.fr. [90.44.83.229]) by mx.google.com with ESMTPS id fz9sm46833222wib.3.2012.04.11.12.09.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 12:09:45 -0700 (PDT) From: Hassnaa Moustafa Content-Type: multipart/alternative; boundary="Apple-Mail=_2B47F807-0B88-464B-A86F-635D4689A240" Date: Wed, 11 Apr 2012 21:09:43 +0200 References: To: fmc@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:09:53 -0000 --Apple-Mail=_2B47F807-0B88-464B-A86F-635D4689A240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi,=20 IMO, terminals characteristics is a vey important aspect (screen size, = battery level for mobile terminals and tablets, supported resolution, = processing capacity and buffering status). The network connectivities = (WiFi, 3G, ..) supported by the terminal is important also.=20 Yes, these need to be transformed into requirements. Hassnaa Begin forwarded message: >=20 > From: > Subject: Re: [fmc] List description > Date: April 11, 2012 2:38:15 PM GMT+02:00 > To: , , = , > Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org >=20 >=20 > Dear all, > As far as I understand here we are all on track - we currently have to = discuss and come hopefully to a conclusion which aspects of = interoperation between fixed and mobile networks to provide a unified = service to end users can be solved by means of IETF i.e. e.g. proposing = a BCP of existing protocols or adaptation and enhancement of approaches. >=20 > If that is what could be reflected within the requirements then I = would add my issues here: >=20 > - beside exchange of customer identity and profile (e.g. subscription = details such as 'silver/gold/platinum' contract and status such as e.g. = 'busy', 'available', 'be right back' etc.) and related operator policies = also the characteristics of currently used terminals is an important = aspect both for service provisioning (e.g. adaptation of information = data rate to screen size and resolution) and efficient network resource = usage. >=20 > Do you think that would make sense and could be translated into IETF = requirements? >=20 > Furthermore beside 3GPP and BBF also from ITU-T a Recommendation = Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been = published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it = seems that detailed requirements for us cannot be derived therefrom = easily ... >=20 > Best regards > Dirk > -----Urspr=FCngliche Nachricht----- > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von = pierrick.seite@orange.com > Gesendet: Mittwoch, 11. April 2012 12:16 > An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; = david.i.allan@ericsson.com > Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org > Betreff: Re: [fmc] List description >=20 > Hi, >=20 > I definitely agree we should elaborate first on requirements from an = "FMC" standpoint. And I'd add "from and IETF standpoint" also... >=20 > Before talking about solutions, I think we should try to get consensus = on a list of clear requirements with their Motivation/use-case. >=20 > Then, we could talk about solutions and go to a gap analysis, with = respect to work done in other WG (or SDOs), to see what protocol = extensions are needed. >=20 > Pierrick >=20 >> -----Message d'origine----- >> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de >> mohamed.boucadair@orange.com >> Envoy=E9 : mercredi 11 avril 2012 08:07 >> =C0 : Donald Eastlake; David Allan I >> Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org >> Objet : Re: [fmc] List description >>=20 >> Dear all, >>=20 >> There is no recommended solution for the FMC case, because there are >> not clear requirements for that case. >> I have suggested to Behcet to further elaborate on the requirements >> from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: >>=20 >> * The current HOST_ID effort in INTAREA WG is restricted to the >> analysis of potential channels which may convey the HOST_ID = information >> * A recommendation is likely to be added.but in the context of = address >> sharing (RFC6269) >> * FMC proponents should elaborate further their requirements for the >> HOST_ID >> (1) Required only during session initialization? >> (2) Required for all transport protocols? >> (3) Host modification should be avoided or it does not harm? >> (4) Which entity will use the HOST_ID information: proxy servers, = else? >> (4a) Packet inspection is required? No? >> (4b) Performance impact >> (5) Which entity will set the HOST_ID information? >>=20 >> BTW, I discussed this point with some colleagues and it seems using >> port sets would be more appropriate for the FMC case (i.e., >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- >> 01#section-3.3). >>=20 >> If port sets are used, a dedicated notification channel is needed to >> report assigned port sets. FYI, I'm working with Dean on this point. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >>> part de Donald Eastlake >>> Envoy=E9 : mercredi 11 avril 2012 00:55 >>> =C0 : David Allan I >>> Cc : sarikaya@ieee.org; fmc@ietf.org >>> Objet : Re: [fmc] List description >>>=20 >>> I think that the nat-reveal draft, while it discusses 8 different >>> possible solutions, does not actually propose any specific solution >>> for any specific problem, such as the FMC/NAT problem. >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>>=20 >>> On Tue, Apr 10, 2012 at 5:17 PM, David Allan I >>> wrote: >>>> Thanks Donald. >>>>=20 >>>> So it is being addressed elsewhere. It is NOT the focus of >>> this effort... >>>>=20 >>>> Given that clarification, this discussion is going circular. >>> We now revert to "what IETF FMC work are we discussing?" >>>>=20 >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >>>> Sent: Tuesday, April 10, 2012 2:07 PM >>>> To: David Allan I >>>> Cc: sarikaya@ieee.org; fmc@ietf.org >>>> Subject: Re: [fmc] List description >>>>=20 >>>> I think this is the draft: >>>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- >>> analysis/ >>>> That is an INTAREA WG draft. >>>>=20 >>>> Thanks, >>>> Donald >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA >>>> d3e3e3@gmail.com >>>>=20 >>>>=20 >>>> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I >>> wrote: >>>>> Hi Bechet: >>>>>=20 >>>>> You did not provide a useful answer. You simply pointed out >>> to me things I've said (repeatedly). >>>>>=20 >>>>> I asked: >>>>> 1) Where was the draft you referred to? >>>>> 2) What WG is working on it? >>>>> 3) Is it the topic of the effort represented by this list? >>>>>=20 >>>>> Can you please clarify... >>>>>=20 >>>>> Thanks >>>>> Dave >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> Sent: Tuesday, April 10, 2012 1:29 PM >>>>> To: David Allan I >>>>> Cc: fmc@ietf.org >>>>> Subject: Re: [fmc] List description >>>>>=20 >>>>> Hi Dave, >>>>>=20 >>>>> In November 2011, 3GPP-BBF Workshop >>>>> chaired by >>>>>=20 >>>>> Dave Allan (BBF), Balazs Bertenyi (3GPP) >>>>>=20 >>>>> issued Chairmen's Summary slides at: >>>>>=20 >>> = http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 >>>>> 6.zip >>>>>=20 >>>>> which stated on Slide 4 >>>>>=20 >>>>> In case of RG with NATs additional mechanisms are needed to >>> enable this. Jointly encourage IETF work on such mechanisms. >>>>>=20 >>>>> That's all I have to say. >>>>>=20 >>>>> I think we should concentrate on IETF work on FMC >>> discussions on this list. >>>>>=20 >>>>> Kind regards, >>>>>=20 >>>>> Behcet >>>>>=20 >>>>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I >>> wrote: >>>>>> Hi Bechet: >>>>>>=20 >>>>>>> Thanks for your mail. >>>>>>=20 >>>>>>> Two points. >>>>>>=20 >>>>>>> Point 1. Can you please clarify that you have expressed >>> your personal opinion not wearing any hats? >>>>>>=20 >>>>>> Does it matter? >>>>>>=20 >>>>>> Point 2. On: >>>>>>=20 >>>>>>>> The outstanding headwound is a wifi connected UE behind a >>> NAT, and I >>>>>>>> believe that is already being addressed elsewhere in the IETF. >>>>>>=20 >>>>>>> Yes, there is a draft called NAT Reveal Analysis draft. >>> It analyzes the problem and suggests very many solutions (5-6) >>> and there are even solutions not mentioned in NAT Reveal >>> Analysis draft. >>>>>>=20 >>>>>> A pointer to the draft would be useful. And the WG context >>> it is being entertained in.... >>>>>>=20 >>>>>>> So it is a difficult problem and maybe explains why so >>> many people are subscribed to this list. >>>>>>=20 >>>>>> So is solving the NAT problem the purpose of this >>> endeavour? I did not get that. >>>>>>=20 >>>>>> >>>>>> Cheers >>>>>> Dave >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >> _______________________________________________ >> 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 --Apple-Mail=_2B47F807-0B88-464B-A86F-635D4689A240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Subject: Re: [fmc] List = description
Date: April 11, 2012 2:38:15 PM = GMT+02:00


Dear= all,
As far as I understand here we are all on track - we currently = have to discuss and come hopefully to a conclusion which aspects of = interoperation between fixed and mobile networks to provide a unified = service to end users can be solved by means of IETF i.e. e.g. proposing = a BCP of existing protocols or adaptation and enhancement of = approaches.

If that is what could be reflected within the = requirements then I would add my issues here:

- beside exchange = of customer identity and profile (e.g. subscription details such as = 'silver/gold/platinum' contract and status such as e.g. 'busy', = 'available', 'be right back' etc.) and related operator policies also = the characteristics of currently used terminals is an important aspect = both for service provisioning (e.g. adaptation of information data rate = to screen size and resolution) and efficient network resource = usage.

Do you think that would make sense and could be translated = into IETF requirements?

Furthermore beside 3GPP and BBF also from = ITU-T a Recommendation Q.1762/Y.2802 "Fixed-mobile convergence general = requirements" has been published here http://www.itu.int/r= ec/T-REC-Q.1762-200709-I - however it seems that detailed = requirements for us cannot be derived therefrom easily ...

Best = regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org = [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.comGesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com<= /a>; d3e3e3@gmail.com; david.i.allan@ericsson.com<= br>Cc: dean.cheng@huawei.com;= sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List = description

Hi,

I definitely agree we should elaborate = first on requirements from an "FMC" standpoint. And I'd add "from and = IETF standpoint" also...

Before talking about solutions, I think = we should try to get consensus on a list of clear requirements with = their Motivation/use-case.

Then, we could talk about solutions = and go to a gap analysis, with respect to work done in other WG (or = SDOs), to see what protocol extensions are = needed.

Pierrick

-----Message = d'origine-----
De : fmc-bounces@ietf.org = [mailto:fmc-bounces@ietf.org] De la part de
mohamed.boucadair@orange.com<= /a>
Envoy=E9 : mercredi 11 = avril 2012 08:07
=C0 : Donald = Eastlake; David Allan I
Cc : = Dean cheng; sarikaya@ieee.org; = fmc@ietf.org
Objet : Re: [fmc] List = description

Dear = all,

There is no = recommended solution for the FMC case, because there = are
not clear requirements for = that case.
I have suggested to = Behcet to further elaborate on the = requirements
from an "FMC" = standpoint. Below an excerpt of what I sent to = Behcet:

* The current = HOST_ID effort in INTAREA WG is restricted to = the
analysis of potential = channels which may convey the HOST_ID = information
* A recommendation = is likely to be added.but in the context of = address
sharing = (RFC6269)
* FMC proponents = should elaborate further their requirements for = the
HOST_ID
(1) = Required only during session initialization?
(2) Required for all transport = protocols?
(3) Host = modification should be avoided or it does not = harm?
(4) Which entity will = use the HOST_ID information: proxy servers, = else?
 (4a) Packet = inspection is required? No?
=  (4b) Performance impact
(5) Which entity will set the HOST_ID = information?

BTW, I = discussed this point with some colleagues and it seems = using
port sets would be more = appropriate for the FMC case (i.e.,
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets = are used, a dedicated notification channel is needed = to
report assigned port sets. = FYI, I'm working with Dean on this point.

Cheers,
Med

-----Message = d'origine-----
De : fmc-bounces@ietf.org = [mailto:fmc-bounces@ietf.org] De = la
part de Donald = Eastlake
Envoy=E9 : mercredi 11 avril = 2012 00:55
=C0 : David Allan = I
Cc : sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] = List description

I think that the nat-reveal = draft, while it discusses 8 = different
possible solutions, does not = actually propose any specific = solution
for any specific problem, such = as the FMC/NAT problem.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =   +1-508-333-2270 = (cell)
155 Beaver Street, Milford, MA 01757 = USA
d3e3e3@gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, = David Allan I
<david.i.allan@ericsson.com&= gt; wrote:
Thanks = Donald.

So it = is being addressed elsewhere. It is NOT the focus = of
this = effort...

Given = that clarification, this discussion is going = circular.
We now revert to "what IETF FMC = work are we discussing?"

Dave

-----Original = Message-----
From: = Donald Eastlake = [mailto:d3e3e3@gmail.com]
Sent: Tuesday, April 10, 2012 2:07 = PM
To: = David Allan I
Cc: sarikaya@ieee.org; fmc@ietf.org
Subject: Re: [fmc] List = description

I = think this is the = draft:

h= ttps://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-
analysis/
That = is an INTAREA WG = draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
= Donald E. Eastlake 3rd   +1-508-333-2270 = (cell)
155 = Beaver Street, Milford, MA 01757 = USA
d3e3e3@gmail.com


On = Tue, Apr 10, 2012 at 4:32 PM, David Allan = I
<david.i.allan@ericsson.com&= gt; wrote:
Hi = Bechet:

You did not provide a useful = answer. You simply pointed = out
to me things I've said = (repeatedly).

I = asked:
1) Where was the draft you = referred = to?
2) What WG is working on = it?
3) Is it the topic of the effort = represented by this = list?

Can you please = clarify...

Thanks
Dave
=




-----Original = Message-----
From: Behcet Sarikaya = [mailto:sarikaya2012@gmail.com]
=
Sent: = Tuesday, April 10, 2012 1:29 = PM
To: David Allan = I
Cc: fmc@ietf.org
Subject:= Re: [fmc] List = description

Hi = Dave,

In November 2011, 3GPP-BBF = Workshop
chaired = by

Dave Allan (BBF), Balazs = Bertenyi = (3GPP)

issued Chairmen's Summary slides = at:

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

which stated on Slide = 4

In case of RG with NATs = additional mechanisms are needed = to
enable this. Jointly encourage = IETF work on such mechanisms.

That's all I have to = say.

I think we should concentrate on = IETF work on = FMC
discussions on this = list.

Kind = regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, = David Allan = I
<david.i.allan@ericsson.com&= gt; wrote:
Hi = Bechet:

Thanks for your = mail.
=

Two = points.

Point 1. Can you please clarify = that you have = expressed
your = personal opinion not wearing any = hats?

Does = it = matter?

Point = 2. = On:

The = outstanding headwound is a wifi connected UE behind = a
NAT, and I
believe = that is already being addressed elsewhere in the = IETF.
=

Yes, there is a draft called NAT = Reveal Analysis = draft.
It = analyzes the problem and suggests very many solutions = (5-6)
and there are even solutions not mentioned in NAT = Reveal
Analysis draft.

A = pointer to the draft would be useful. And the WG = context
it is being = entertained in....

So it is a difficult problem and = maybe explains why = so
many = people are subscribed to this = list.

So is = solving the NAT problem the purpose of = this
<= blockquote type=3D"cite">
endeavour? I did not = get that.

<snipped to = end>
Cheers
Dave
=

_______________________________________________
fmc = mailing = list
<= blockquote type=3D"cite">
fmc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/fmc
_______________________________________________
fmc mailing = list
fmc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/fmc
_______________________________________________
fmc = mailing list
fmc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/fmc

_______________________________________________
fmc mailing = list
fmc@ietf.org
https://www.ietf.org/ma= ilman/listinfo/fmc
___________________________________= ____________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mail= man/listinfo/fmc

= --Apple-Mail=_2B47F807-0B88-464B-A86F-635D4689A240-- From tso@zteusa.com Wed Apr 11 18:03:43 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 7942E11E8114; Wed, 11 Apr 2012 18:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 yjqhG5p2W2-D; Wed, 11 Apr 2012 18:03:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5C111E80FD; Wed, 11 Apr 2012 18:03:34 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291689387102; Thu, 12 Apr 2012 09:02:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 65635.2249060555; Thu, 12 Apr 2012 08:48:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3C13PLL088229; Thu, 12 Apr 2012 09:03:25 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: Hassnaa Moustafa MIME-Version: 1.0 X-KeepSent: 58D3C558:DD8F8B10-882579DE:00058BD2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Wed, 11 Apr 2012 18:03:14 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-12 09:03:26, Serialize complete at 2012-04-12 09:03:26 Content-Type: multipart/alternative; boundary="=_alternative 0005CC29882579DE_=" X-MAIL: mse02.zte.com.cn q3C13PLL088229 Cc: fmc-bounces@ietf.org, fmc@ietf.org Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 01:03:43 -0000 This is a multipart message in MIME format. --=_alternative 0005CC29882579DE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hmmm....=20 I must be missing something ....=20 Why would IETF FMC work has anything to do with " (screen size, battery=20 level for mobile terminals and tablets, supported resolution, processing=20 capacity and buffering status) "?? Hassnaa Moustafa =20 Sent by: fmc-bounces@ietf.org 04/11/2012 12:09 PM To fmc@ietf.org cc Subject [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Hi,=20 IMO, terminals characteristics is a vey important aspect (screen size,=20 battery level for mobile terminals and tablets, supported resolution,=20 processing capacity and buffering status). The network connectivities=20 (WiFi, 3G, ..) supported by the terminal is important also.=20 Yes, these need to be transformed into requirements. Hassnaa Begin forwarded message: From: Subject: Re: [fmc] List description Date: April 11, 2012 2:38:15 PM GMT+02:00 To: , , < d3e3e3@gmail.com>, Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org Dear all, As far as I understand here we are all on track - we currently have to=20 discuss and come hopefully to a conclusion which aspects of interoperation= =20 between fixed and mobile networks to provide a unified service to end=20 users can be solved by means of IETF i.e. e.g. proposing a BCP of existing= =20 protocols or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would=20 add my issues here: - beside exchange of customer identity and profile (e.g. subscription=20 details such as 'silver/gold/platinum' contract and status such as e.g.=20 'busy', 'available', 'be right back' etc.) and related operator policies=20 also the characteristics of currently used terminals is an important=20 aspect both for service provisioning (e.g. adaptation of information data= =20 rate to screen size and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF=20 requirements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation=20 Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been=20 published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it=20 seems that detailed requirements for us cannot be derived therefrom easily= =20 ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 pierrick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3e3@gmail.com;=20 david.i.allan@ericsson.com Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC"= =20 standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on= =20 a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect= =20 to work done in other WG (or SDOs), to see what protocol extensions are=20 needed. Pierrick -----Message d'origine----- De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : mercredi 11 avril 2012 08:07 =C0 : Donald Eastlake; David Allan I Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org Objet : Re: [fmc] List description Dear all, There is no recommended solution for the FMC case, because there are not clear requirements for that case. I have suggested to Behcet to further elaborate on the requirements from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: * The current HOST_ID effort in INTAREA WG is restricted to the analysis of potential channels which may convey the HOST_ID information * A recommendation is likely to be added.but in the context of address sharing (RFC6269) * FMC proponents should elaborate further their requirements for the HOST_ID (1) Required only during session initialization? (2) Required for all transport protocols? (3) Host modification should be avoided or it does not harm? (4) Which entity will use the HOST_ID information: proxy servers, else? (4a) Packet inspection is required? No? (4b) Performance impact (5) Which entity will set the HOST_ID information? BTW, I discussed this point with some colleagues and it seems using port sets would be more appropriate for the FMC case (i.e., http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- 01#section-3.3). If port sets are used, a dedicated notification channel is needed to report assigned port sets. FYI, I'm working with Dean on this point. Cheers, Med -----Message d'origine----- De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de Donald Eastlake Envoy=E9 : mercredi 11 avril 2012 00:55 =C0 : David Allan I Cc : sarikaya@ieee.org; fmc@ietf.org Objet : Re: [fmc] List description I think that the nat-reveal draft, while it discusses 8 different possible solutions, does not actually propose any specific solution for any specific problem, such as the FMC/NAT problem. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 10, 2012 at 5:17 PM, David Allan I wrote: Thanks Donald. So it is being addressed elsewhere. It is NOT the focus of this effort... Given that clarification, this discussion is going circular. We now revert to "what IETF FMC work are we discussing?" Dave -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com] Sent: Tuesday, April 10, 2012 2:07 PM To: David Allan I Cc: sarikaya@ieee.org; fmc@ietf.org Subject: Re: [fmc] List description I think this is the draft: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- analysis/ That is an INTAREA WG draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 10, 2012 at 4:32 PM, David Allan I wrote: Hi Bechet: You did not provide a useful answer. You simply pointed out to me things I've said (repeatedly). I asked: 1) Where was the draft you referred to? 2) What WG is working on it? 3) Is it the topic of the effort represented by this list? Can you please clarify... Thanks Dave -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Tuesday, April 10, 2012 1:29 PM To: David Allan I Cc: fmc@ietf.org Subject: Re: [fmc] List description Hi Dave, In November 2011, 3GPP-BBF Workshop chaired by Dave Allan (BBF), Balazs Bertenyi (3GPP) issued Chairmen's Summary slides at: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 6.zip which stated on Slide 4 In case of RG with NATs additional mechanisms are needed to enable this. Jointly encourage IETF work on such mechanisms. That's all I have to say. I think we should concentrate on IETF work on FMC discussions on this list. Kind regards, Behcet On Tue, Apr 10, 2012 at 1:32 PM, David Allan I wrote: Hi Bechet: Thanks for your mail. Two points. Point 1. Can you please clarify that you have expressed your personal opinion not wearing any hats? Does it matter? Point 2. On: The outstanding headwound is a wifi connected UE behind a NAT, and I believe that is already being addressed elsewhere in the IETF. Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the problem and suggests very many solutions (5-6) and there are even solutions not mentioned in NAT Reveal Analysis draft. A pointer to the draft would be useful. And the WG context it is being entertained in.... So it is a difficult problem and maybe explains why so many people are subscribed to this list. So is solving the NAT problem the purpose of this endeavour? I did not get that. Cheers Dave _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0005CC29882579DE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hmmm....

I must be missing something ....

Why would IETF FMC work has anything to do with "  (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status)  "= ;??




Hassnaa Moustafa <= hasnaa.moustafa@gmail.com>
Sent by: fmc-bounces@ietf.org

04/11/2012 12:09 PM

To
fmc@ietf.org
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1, Issue 15





Hi,

IMO, terminals characteristics is a vey important aspect (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status). The network connecti= vities (WiFi, 3G, ..) supported by the terminal is important also.
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:


From: <Dirk.von-Hugo@telekom.de>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <pierrick.seite@orange.com>, <mohamed.boucadair@orange.com>= , <d3e3e3@gmail.com>, <david.i.allan@ericsson.com>
Cc: dean.cheng@huawei.com, sa= rikaya@ieee.org, fmc@iet= f.org


Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoc= ols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to scree= n size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF requir= ements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been publishe= d here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-b= ounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e= 3e3@gmail.com; david.i.allan@ericsson.com
Cc: dean.cheng@huawei.com; sa= rikaya@ieee.org; fmc@iet= f.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick
-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-b= ounces@ietf.org] De la part de
mohamed.boucadair@orange.com
Envoy=E9 : mercredi 11 avril 2012 08:07
=C0 : Donald Eastlake; David Allan I
Cc : Dean cheng; sarikaya@ieee.org; fmc@iet= f.org
Objet : Re: [fmc] List description

Dear all,

There is no recommended solution for the FMC case, becau= se there are
not clear requirements for that case.
I have suggested to Behcet to further elaborate on the requirements
from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:

* The current HOST_ID effort in INTAREA WG is restricted to the
analysis of potential channels which may convey the HOST= _ID information
* A recommendation is likely to be added.but in the cont= ext of address
sharing (RFC6269)
* FMC proponents should elaborate further their requirem= ents for the
HOST_ID
(1) Required only during session initialization?
(2) Required for all transport protocols?
(3) Host modification should be avoided or it does not harm?
(4) Which entity will use the HOST_ID information: proxy servers, else?
 (4a) Packet inspection is required? No?
 (4b) Performance impact
(5) Which entity will set the HOST_ID information?

BTW, I discussed this point with some colleagues and it seems using
port sets would be more appropriate for the FMC case (i.= e.,
http://tools.ietf.org/html/draft-iet= f-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets are used, a dedicated notification channel is needed to
report assigned port sets. FYI, I'm working with Dean on this point.

Cheers,
Med

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-b= ounces@ietf.org] De la
part de Donald Eastlake
Envoy=E9 : mercredi 11 avril 2012 00:55
=C0 : David Allan I
Cc : sarikaya@ieee.org; fmc@iet= f.org
Objet : Re: [fmc] List description

I think that the nat-reveal draft, while it discusses 8 different
possible solutions, does not actually propose any specif= ic solution
for any specific problem, such as the FMC/NAT problem.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3= @gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<<= font size=3D3 color=3Dblue>david.i.allan@ericsson.com> wrote:
Thanks Donald.

So it is being addressed elsewhere. It is NOT the focus of
this effort...

Given that clarification, this discussion is going circu= lar.
We now revert to "what IETF FMC work are we discuss= ing?"

Dave

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org; fmc@iet= f.org
Subject: Re: [fmc] List description

I think this is the draft:

https://datatracker.ietf.org/doc/draft-= ietf-intarea-nat-reveal-
analysis/
That is an INTAREA WG draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3= @gmail.com


On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<<= font size=3D3 color=3Dblue>david.i.allan@ericsson.com> wrote:
Hi Bechet:

You did not provide a useful answer. You simply pointed out
to me things I've said (repeatedly).

I asked:
1) Where was the draft you referred to?
2) What WG is working on it?
3) Is it the topic of the effort represented by this lis= t?

Can you please clarify...

Thanks
Dave




-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fmc] List description

Hi Dave,

In November 2011, 3GPP-BBF Workshop
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

issued Chairmen's Summary slides at:

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

which stated on Slide 4

In case of RG with NATs additional mechanisms are needed to
enable this. Jointly encourage IETF work on such mechani= sms.

That's all I have to say.

I think we should concentrate on IETF work on FMC
discussions on this list.

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<<= font size=3D3 color=3Dblue>david.i.allan@ericsson.com> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expressed<= /font>
your personal opinion not wearing any hats?

Does it matter?

Point 2. On:

The outstanding headwound is a wifi connected UE behind a
NAT, and I
believe that is already being addressed elsewhere in the IETF.

Yes, there is a draft called NAT Reveal Analysis draft.<= /font>
It analyzes the problem and suggests very many solutions (5-6)
and there are even solutions not mentioned in NAT Reveal=
Analysis draft.

A pointer to the draft would be useful. And the WG conte= xt
it is being entertained in....

So it is a difficult problem and maybe explains why so
many people are subscribed to this list.

So is solving the NAT problem the purpose of this
endeavour? I did not get that.

<snipped to end>
Cheers
Dave

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

_______________________________________________
fmc mailing list
fmc@ietf.o= rg
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
fmc= @ietf.org
h= ttps://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 0005CC29882579DE_=-- From tso@zteusa.com Wed Apr 11 18:07: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 824E421F8470 for ; Wed, 11 Apr 2012 18:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, SORTED_RECIPS=1.125] 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 Nrz1tSGMjrci for ; Wed, 11 Apr 2012 18:07:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id F29D421F846A for ; Wed, 11 Apr 2012 18:07:19 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Thu, 12 Apr 2012 09:06:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 65635.8225144323; Thu, 12 Apr 2012 08:51:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3C17Cij093628; Thu, 12 Apr 2012 09:07:12 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2796F6C4D7@HE113484.emea1.cds.t-internal.com> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se><60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <843DA <05C81A773E48DD49B181B04BA21A342A2796F6C4D7@HE113484.emea1.cds.t-internal.com> To: MIME-Version: 1.0 X-KeepSent: 835055CC:971E0E44-882579DE:00060111; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Wed, 11 Apr 2012 18:07:03 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-12 09:07:13, Serialize complete at 2012-04-12 09:07:13 Content-Type: multipart/alternative; boundary="=_alternative 000625C5882579DE_=" X-MAIL: mse02.zte.com.cn q3C17Cij093628 Cc: david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, sarikaya@ieee.org, pierrick.seite@orange.com, d3e3e3@gmail.com, mohamed.boucadair@orange.com Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 01:07:22 -0000 This is a multipart message in MIME format. --=_alternative 000625C5882579DE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dirk,=20 I am wondering the aspects that you raised, do you think that they are=20 belonged to the domain of 3GPP and BBF, and NOT IETF?=20 Thanks. Tricci=20 =20 Sent by: fmc-bounces@ietf.org 04/11/2012 05:38 AM To , ,=20 , cc dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org Subject Re: [fmc] List description Dear all, As far as I understand here we are all on track - we currently have to=20 discuss and come hopefully to a conclusion which aspects of interoperation= =20 between fixed and mobile networks to provide a unified service to end=20 users can be solved by means of IETF i.e. e.g. proposing a BCP of existing= =20 protocols or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would=20 add my issues here: - beside exchange of customer identity and profile (e.g. subscription=20 details such as 'silver/gold/platinum' contract and status such as e.g.=20 'busy', 'available', 'be right back' etc.) and related operator policies=20 also the characteristics of currently used terminals is an important=20 aspect both for service provisioning (e.g. adaptation of information data= =20 rate to screen size and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF=20 requirements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation=20 Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been=20 published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it=20 seems that detailed requirements for us cannot be derived therefrom easily= =20 ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 pierrick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3e3@gmail.com;=20 david.i.allan@ericsson.com Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC"= =20 standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on= =20 a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect= =20 to work done in other WG (or SDOs), to see what protocol extensions are=20 needed. Pierrick > -----Message d'origine----- > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9 : mercredi 11 avril 2012 08:07 > =C0 : Donald Eastlake; David Allan I > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org > Objet : Re: [fmc] List description > > Dear all, > > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? > > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > 01#section-3.3). > > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. > > Cheers, > Med > > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --=3D_alternative 000625C5882579DE_=FF -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000625C5882579DE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dirk,

I am wondering the aspects that you raised, do you think that they are belonged to the domain of 3GPP and BBF, and NOT IETF?

Thanks.
Tricci



<Dirk.von-Hugo@tel= ekom.de>
Sent by: fmc-bounces@ietf.org

04/11/2012 05:38 AM

To
<pierrick.seite@orange.com>, &= lt;mohamed.boucadair@orange.com>, <d3e3e3@gmail.com>, <david.i.allan@ericsson.com>
cc
dean.cheng@huawei.com, sarikaya@ieee= .org, fmc@ietf.org
Subject
Re: [fmc] List description




Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoc= ols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to scree= n size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF requir= ements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been publishe= d here <= tt>http://www.itu.int/rec/T-REC-Q.1762-200709-I<= /a> - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.= com
Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick

> -----Message d'origine-----
> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ] De la part de
> mohamed.boucadair@orange.com
> Envoy=E9 : mercredi 11 avril 2012 08:07
> =C0 : Donald Eastlake; David Allan I
> Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org
> Objet : Re: [fmc] List description
>
> Dear all,
>
> There is no recommended solution for the FMC case, because there are > not clear requirements for that case.
> I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:
>
> * The current HOST_ID effort in INTAREA WG is restricted to the
> analysis of potential channels which may convey the HOST_ID informatio= n
> * A recommendation is likely to be added.but in the context of address=
> sharing (RFC6269)
> * FMC proponents should elaborate further their requirements for the > HOST_ID
> (1) Required only during session initialization?
> (2) Required for all transport protocols?
> (3) Host modification should be avoided or it does not harm?
> (4) Which entity will use the HOST_ID information: proxy servers, else?
>   (4a) Packet inspection is required? No?
>   (4b) Performance impact
> (5) Which entity will set the HOST_ID information?
>
> BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e.,
> http://tools.ietf.org/html/draft-ie= tf-intarea-nat-reveal-analysis-
> 01#section-3.3).
>
> If port sets are used, a dedicated notification channel is needed to
> report assigned port sets. FYI, I'm working with Dean on this point. >
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org= ] De la
> >part de Donald Eastlake
> >Envoy=E9 : mercredi 11 avril 2012 00:55
> >=C0 : David Allan I
> >Cc : sarikaya@ieee.org; fmc@ietf.org
> >Objet : Re: [fmc] List description
> >
> >I think that the nat-reveal draft, while it discusses 8 different<= br> > >possible solutions, does not actually propose any specific solutio= n
> >for any specific problem, such as the FMC/NAT problem.
> >
> >Thanks,
> >Donald
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > d3e3e3@gmail.com
> >
> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >> Thanks Donald.
> >>
> >> So it is being addressed elsewhere. It is NOT the focus of > >this effort...
> >>
> >> Given that clarification, this discussion is going circular.<= br> > >We now revert to "what IETF FMC work are we discussing?"=
> >>
> >> Dave
> >>
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> >> Sent: Tuesday, April 10, 2012 2:07 PM
> >> To: David Allan I
> >> Cc: sarikaya@ieee.org; fmc@ietf.org
> >> Subject: Re: [fmc] List description
> >>
> >> I think this is the draft:
> >>
> >https://datatracker.ietf.org/doc/d= raft-ietf-intarea-nat-reveal-
> >analysis/
> >> That is an INTAREA WG draft.
> >>
> >> Thanks,
> >> Donald
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell) > >>  155 Beaver Street, Milford, MA 01757 USA
> >>  d3e3e3@gmail.com
> >>
> >>
> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >>> Hi Bechet:
> >>>
> >>> You did not provide a useful answer. You simply pointed out
> >to me things I've said (repeatedly).
> >>>
> >>> I asked:
> >>> 1) Where was the draft you referred to?
> >>> 2) What WG is working on it?
> >>> 3) Is it the topic of the effort represented by this list?
> >>>
> >>> Can you please clarify...
> >>>
> >>> Thanks
> >>> Dave
> >>>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
> >>> Sent: Tuesday, April 10, 2012 1:29 PM
> >>> To: David Allan I
> >>> Cc: fmc@ietf.org
> >>> Subject: Re: [fmc] List description
> >>>
> >>> Hi Dave,
> >>>
> >>> In November 2011, 3GPP-BBF Workshop
> >>> chaired by
> >>>
> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP)
> >>>
> >>> issued Chairmen's Summary slides at:
> >>>
> >http://www.3gpp.org/ftp/wor= kshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104
> >>> 6.zip
> >>>
> >>> which stated on Slide 4
> >>>
> >>> In case of RG with NATs additional mechanisms are needed to
> >enable this. Jointly encourage IETF work on such mechanisms.
> >>>
> >>> That's all I have to say.
> >>>
> >>> I think we should concentrate on IETF work on FMC
> >discussions on this list.
> >>>
> >>> Kind regards,
> >>>
> >>> Behcet
> >>>
> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >>>> Hi Bechet:
> >>>>
> >>>>> Thanks for your mail.
> >>>>
> >>>>> Two points.
> >>>>
> >>>>> Point 1. Can you please clarify that you have expressed
> >your personal opinion not wearing any hats?
> >>>>
> >>>> Does it matter?
> >>>>
> >>>> Point 2. On:
> >>>>
> >>>>>>The outstanding headwound is a wifi connected UE behind a
> >NAT, and I
> >>>>>>believe that is already being addressed elsewh= ere in the IETF.
> >>>>
> >>>>> Yes, there is a draft called NAT Reveal Analysis draft.
> >It analyzes the problem and suggests very many solutions (5-6)
> >and there are even solutions not mentioned in NAT Reveal
> >Analysis draft.
> >>>>
> >>>> A pointer to the draft would be useful. And the WG context
> >it is being entertained in....
> >>>>
> >>>>> So it is a difficult problem and maybe explains why so
> >many people are subscribed to this list.
> >>>>
> >>>> So is solving the NAT problem the purpose of this
> >endeavour? I did not get that.
> >>>>
> >>>> <snipped to end>
> >>>> Cheers
> >>>> Dave
> >>>>
> >>>> _______________________________________________
> >>>> fmc mailing list
> >>>> fmc@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/fmc
> >>> _______________________________________________
> >>> fmc mailing list
> >>> fmc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/fmc<= /tt>
> >_______________________________________________
> >fmc mailing list
> >fmc@ietf.org
> >https://www.ietf.org/mailman/listinfo/fmc<= tt>
> >
> _______________________________________________
> fmc mailing list
> fmc@ietf.org
> https://www.ietf.org/mailman/listinfo/fmc<= font size=3D2>
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc

 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 000625C5882579DE_=-- From tso@zteusa.com Wed Apr 11 18:14:35 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E311E8116 for ; Wed, 11 Apr 2012 18:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 CmynJH9v4Zdc for ; Wed, 11 Apr 2012 18:14:33 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9711E80FD for ; Wed, 11 Apr 2012 18:14:32 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Thu, 12 Apr 2012 08:36:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 21215.7891346479; Thu, 12 Apr 2012 09:14:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3C1EJdh094751; Thu, 12 Apr 2012 09:14:19 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f To: Jong-Hyouk Lee MIME-Version: 1.0 X-KeepSent: 1E7DB871:F80A962A-882579DE:00065483; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Wed, 11 Apr 2012 18:14:10 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-12 09:14:20, Serialize complete at 2012-04-12 09:14:20 Content-Type: multipart/alternative; boundary="=_alternative 0006CC42882579DE_=" X-MAIL: mse01.zte.com.cn q3C1EJdh094751 Cc: david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, sarikaya@ieee.org, pierrick.seite@orange.com, d3e3e3@gmail.com, mohamed.boucadair@orange.com Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 01:14:35 -0000 This is a multipart message in MIME format. --=_alternative 0006CC42882579DE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Pierrick,=20 You have raised the excellent point that we all need to figure out what=20 are the requirements from "FMC" standpoint.=20 But I am wondering, since 3GPP and BBF have been working on this FMC work= =20 for so long, wouldn't they have done the gap analysis already? I.e. if=20 they need work to be done in IETF, should they have asked us to work on=20 them already?=20 Why should we start from scratch to do our own analysis? What do you=20 think?=20 Thanks. Tricci=20 Jong-Hyouk Lee =20 Sent by: fmc-bounces@ietf.org 04/11/2012 04:42 AM To pierrick.seite@orange.com cc david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com,=20 sarikaya@ieee.org, d3e3e3@gmail.com, mohamed.boucadair@orange.com Subject Re: [fmc] List description Fully agree with his words. On Wed, Apr 11, 2012 at 12:15 PM, wrote: Hi, I definitely agree we should elaborate first on requirements from an "FMC"= =20 standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on= =20 a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect= =20 to work done in other WG (or SDOs), to see what protocol extensions are=20 needed. Pierrick > -----Message d'origine----- > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9 : mercredi 11 avril 2012 08:07 > =C0 : Donald Eastlake; David Allan I > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org > Objet : Re: [fmc] List description > > Dear all, > > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? > > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > 01#section-3.3). > > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. > > Cheers, > Med > > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0006CC42882579DE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Pierrick,

You have raised the excellent point that we all need to figure out what are the requirements from "FMC&quo= t; standpoint.  

But I am wondering, since 3GPP and B= BF have been working on this FMC work for so long, wouldn't they have done the gap analysis already?  I.e. if they need work to be done in IETF, should they have asked us to work on them already?

Why should we start from scratch to do our own analysis?    What do you think?

Thanks.
Tricci




Jong-Hyouk Lee <jo= nghyouk@gmail.com>
Sent by: fmc-bounces@ietf.org

04/11/2012 04:42 AM

To
pierrick.seite@orange.com
cc
david.i.allan@ericsson.com, fmc@ietf= .org, dean.cheng@huawei.com, sarikaya@ieee.org, d3e3e3@gmail.com, mohamed.boucada= ir@orange.com
Subject
Re: [fmc] List description




Fully agree with his words.
On Wed, Apr 11, 2012 at 12:15 PM, <pierrick.sei= te@orange.com> wrote:
Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick

> -----Message d'origine-----
> De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoy=E9 : mercredi 11 avril 2012 08:07
> =C0 : Donald Eastlake; David Allan I
> Cc : Dean cheng; sarikaya@ieee.org; fmc@iet= f.org
> Objet : Re: [fmc] List description
>
> Dear all,
>
> There is no recommended solution for the FMC case, because there are > not clear requirements for that case.
> I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:
>
> * The current HOST_ID effort in INTAREA WG is restricted to the
> analysis of potential channels which may convey the HOST_ID informatio= n
> * A recommendation is likely to be added.but in the context of address=
> sharing (RFC6269)
> * FMC proponents should elaborate further their requirements for the > HOST_ID
> (1) Required only during session initialization?
> (2) Required for all transport protocols?
> (3) Host modification should be avoided or it does not harm?
> (4) Which entity will use the HOST_ID information: proxy servers, else?
>   (4a) Packet inspection is required? No?
>   (4b) Performance impact
> (5) Which entity will set the HOST_ID information?
>
> BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e.,
> http://tools= .ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-
> 01#section-3.3).
>
> If port sets are used, a dedicated notification channel is needed to
> report assigned port sets. FYI, I'm working with Dean on this point. >
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la
> >part de Donald Eastlake
> >Envoy=E9 : mercredi 11 avril 2012 00:55
> >=C0 : David Allan I
> >Cc : sarikaya@ieee.org; fmc@iet= f.org
> >Objet : Re: [fmc] List description
> >
> >I think that the nat-reveal draft, while it discusses 8 different<= br> > >possible solutions, does not actually propose any specific solutio= n
> >for any specific problem, such as the FMC/NAT problem.
> >
> >Thanks,
> >Donald
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > d3e3e3@gmail.com
> >
> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >> Thanks Donald.
> >>
> >> So it is being addressed elsewhere. It is NOT the focus of > >this effort...
> >>
> >> Given that clarification, this discussion is going circular.<= br> > >We now revert to "what IETF FMC work are we discussing?"=
> >>
> >> Dave
> >>
> >> -----Original Message-----
> >> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> >> Sent: Tuesday, April 10, 2012 2:07 PM
> >> To: David Allan I
> >> Cc: sarikaya@ieee.org; fmc@iet= f.org
> >> Subject: Re: [fmc] List description
> >>
> >> I think this is the draft:
> >>
> >https://dat= atracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-
> >analysis/
> >> That is an INTAREA WG draft.
> >>
> >> Thanks,
> >> Donald
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >>  155 Beaver Street, Milford, MA 01757 USA
> >>  d3e3e3@gmail.com
> >>
> >>
> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >>> Hi Bechet:
> >>>
> >>> You did not provide a useful answer. You simply pointed out
> >to me things I've said (repeatedly).
> >>>
> >>> I asked:
> >>> 1) Where was the draft you referred to?
> >>> 2) What WG is working on it?
> >>> 3) Is it the topic of the effort represented by this list?
> >>>
> >>> Can you please clarify...
> >>>
> >>> Thanks
> >>> Dave
> >>>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
> >>> Sent: Tuesday, April 10, 2012 1:29 PM
> >>> To: David Allan I
> >>> Cc: fmc@ietf.org
> >>> Subject: Re: [fmc] List description
> >>>
> >>> Hi Dave,
> >>>
> >>> In November 2011, 3GPP-BBF Workshop
> >>> chaired by
> >>>
> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP)
> >>>
> >>> issued Chairmen's Summary slides at:
> >>>
> >http= ://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104
> >>> 6.zip
> >>>
> >>> which stated on Slide 4
> >>>
> >>> In case of RG with NATs additional mechanisms are needed to
> >enable this. Jointly encourage IETF work on such mechanisms.
> >>>
> >>> That's all I have to say.
> >>>
> >>> I think we should concentrate on IETF work on FMC
> >discussions on this list.
> >>>
> >>> Kind regards,
> >>>
> >>> Behcet
> >>>
> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
> ><david.i.allan@ericsson.com> wrote:
> >>>> Hi Bechet:
> >>>>
> >>>>> Thanks for your mail.
> >>>>
> >>>>> Two points.
> >>>>
> >>>>> Point 1. Can you please clarify that you have expressed
> >your personal opinion not wearing any hats?
> >>>>
> >>>> Does it matter?
> >>>>
> >>>> Point 2. On:
> >>>>
> >>>>>>The outstanding headwound is a wifi connected UE behind a
> >NAT, and I
> >>>>>>believe that is already being addressed elsewh= ere in the IETF.
> >>>>
> >>>>> Yes, there is a draft called NAT Reveal Analysis draft.
> >It analyzes the problem and suggests very many solutions (5-6)
> >and there are even solutions not mentioned in NAT Reveal
> >Analysis draft.
> >>>>
> >>>> A pointer to the draft would be useful. And the WG context
> >it is being entertained in....
> >>>>
> >>>>> So it is a difficult problem and maybe explains why so
> >many people are subscribed to this list.
> >>>>
> >>>> So is solving the NAT problem the purpose of this
> >endeavour? I did not get that.
> >>>>
> >>>> <snipped to end>
> >>>> Cheers
> >>>> Dave
> >>>>
> >>>> _______________________________________________
> >>>> fmc mailing list
> >>>> fmc@ietf.org
> >>>> https://www.ietf.org/m= ailman/listinfo/fmc
> >>> _______________________________________________
> >>> fmc mailing list
> >>> fmc@ietf.org
> >>> https://www.ietf.org/mailm= an/listinfo/fmc
> >_______________________________________________
> >fmc mailing list
> ><= u>fmc@ietf.org
> >https://www.ietf.org/mailman/listi= nfo/fmc
> >
> _______________________________________________
> fmc mailing list
> fm= c@ietf.org
> https://www.ietf.org/mailman/listinfo/f= mc
_______________________________________________
fmc mailing list
fmc= @ietf.org
https://www.ietf.org/mailman/listinfo/fm= c



--
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google= .com/site/hurryon/
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 0006CC42882579DE_=-- From d3e3e3@gmail.com Wed Apr 11 19:04:50 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 7528611E812B for ; Wed, 11 Apr 2012 19:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.979 X-Spam-Level: X-Spam-Status: No, score=-103.979 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 t7Fel0nFo83b for ; Wed, 11 Apr 2012 19:04:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B100811E812C for ; Wed, 11 Apr 2012 19:04:46 -0700 (PDT) Received: by lbok13 with SMTP id k13so1295971lbo.31 for ; Wed, 11 Apr 2012 19:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Nyx/MIl1ActKGeRHTrJouQVzxq5OKO1uzGr4YRmQ6GA=; b=Pc5rJJM3YK9KZE8qUwWrO6741z1yHfCjtIQLsOQ4c/52bxJVJS/qMBpn/UXR4IG//z xojTBDcFQirF7cz8BXpnXbLvjAY+NvHTXbx/zveAmW/4wXQpVYz8bYJtNnh3FYNTO7mj TMRuVbDCs/2EIuXLlbScbZRGwJA8U6J2t6xlgKUHOYuISNP0AyHcBA2hck6K5DU7h+EF Su7x5Tp1nQXl6YHN2Mmz3NaVzbwvez4llQlUL3R2r5PiG+FKre7s326nBGlcMMQL7fNW 4PzC3gbNtVmdQaTUiDAKsNbTVQMVVC8+Ahe0xAlYqjP06QeDSkQUC+v4xGmrNb6ppEw6 XVwg== Received: by 10.152.113.229 with SMTP id jb5mr449592lab.45.1334196281880; Wed, 11 Apr 2012 19:04:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Wed, 11 Apr 2012 19:04:21 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 11 Apr 2012 22:04:21 -0400 Message-ID: To: tso@zteusa.com Content-Type: multipart/alternative; boundary=f46d04088d8b71323d04bd71c700 Cc: fmc@ietf.org, Hassnaa Moustafa Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 02:04:50 -0000 --f46d04088d8b71323d04bd71c700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On Wed, Apr 11, 2012 at 9:03 PM, wrote: > Hmmm.... > > I must be missing something .... I think you are missing the word "transporting" or something like that, which is reasonable because I think it was missing from Hassnaa's message. Why would IETF FMC work has anything to do with " (screen size, battery > level for mobile terminals and tablets, supported resolution, processing > capacity and buffering status) "?? > I think the IETF might have work "to do with TRANSPORTING (...)" the various terminal characteristics listed. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > *Hassnaa Moustafa * > Sent by: fmc-bounces@ietf.org > > 04/11/2012 12:09 PM > To > fmc@ietf.org > cc > Subject > [fmc] Fwd: fmc Digest, Vol 1, Issue 15 > > > > > Hi, > > IMO, terminals characteristics is a vey important aspect (screen size, > battery level for mobile terminals and tablets, supported resolution, > processing capacity and buffering status). The network connectivities > (WiFi, 3G, ..) supported by the terminal is important also. > Yes, these need to be transformed into requirements. > > Hassnaa > > Begin forwarded message: > > > *From: *<*Dirk.von-Hugo@telekom.de* > > *Subject: Re: [fmc] List description* > *Date: *April 11, 2012 2:38:15 PM GMT+02:00 > *To: *<*pierrick.seite@orange.com* >, <* > mohamed.boucadair@orange.com* >, <* > d3e3e3@gmail.com* >, <*david.i.allan@ericsson.com* > > > *Cc: **dean.cheng@huawei.com* , *sarikaya@ieee.org= *, > *fmc@ietf.org* > > > Dear all, > As far as I understand here we are all on track - we currently have to > discuss and come hopefully to a conclusion which aspects of interoperatio= n > between fixed and mobile networks to provide a unified service to end use= rs > can be solved by means of IETF i.e. e.g. proposing a BCP of existing > protocols or adaptation and enhancement of approaches. > > If that is what could be reflected within the requirements then I would > add my issues here: > > - beside exchange of customer identity and profile (e.g. subscription > details such as 'silver/gold/platinum' contract and status such as e.g. > 'busy', 'available', 'be right back' etc.) and related operator policies > also the characteristics of currently used terminals is an important aspe= ct > both for service provisioning (e.g. adaptation of information data rate t= o > screen size and resolution) and efficient network resource usage. > > Do you think that would make sense and could be translated into IETF > requirements? > > Furthermore beside 3GPP and BBF also from ITU-T a Recommendation > Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been > published here *http://www.itu.int/rec/T-REC-Q.1762-200709-I*- however it seems that detailed requirem= ents for us cannot be derived > therefrom easily ... > > Best regards > Dirk > -----Urspr=FCngliche Nachricht----- > Von: *fmc-bounces@ietf.org* [ > mailto:fmc-bounces@ietf.org ] Im Auftrag von * > pierrick.seite@orange.com* > Gesendet: Mittwoch, 11. April 2012 12:16 > An: *mohamed.boucadair@orange.com* ; * > d3e3e3@gmail.com* ; *david.i.allan@ericsson.com* > Cc: *dean.cheng@huawei.com* ; *sarikaya@ieee.org*<= sarikaya@ieee.org>; > *fmc@ietf.org* > Betreff: Re: [fmc] List description > > Hi, > > I definitely agree we should elaborate first on requirements from an "FMC= " > standpoint. And I'd add "from and IETF standpoint" also... > > Before talking about solutions, I think we should try to get consensus on > a list of clear requirements with their Motivation/use-case. > > Then, we could talk about solutions and go to a gap analysis, with respec= t > to work done in other WG (or SDOs), to see what protocol extensions are > needed. > > Pierrick > > -----Message d'origine----- > De : *fmc-bounces@ietf.org* [ > mailto:fmc-bounces@ietf.org ] De la part de > *mohamed.boucadair@orange.com* > Envoy=E9 : mercredi 11 avril 2012 08:07 > =C0 : Donald Eastlake; David Allan I > Cc : Dean cheng; *sarikaya@ieee.org* ; *fmc@ietf.org*<= fmc@ietf.org> > Objet : Re: [fmc] List description > > Dear all, > > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? > > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > *http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-* > 01#section-3.3). > > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. > > Cheers, > Med > > -----Message d'origine----- > De : *fmc-bounces@ietf.org* [ > mailto:fmc-bounces@ietf.org ] De la > part de Donald Eastlake > Envoy=E9 : mercredi 11 avril 2012 00:55 > =C0 : David Allan I > Cc : *sarikaya@ieee.org* ; *fmc@ietf.org* > Objet : Re: [fmc] List description > > I think that the nat-reveal draft, while it discusses 8 different > possible solutions, does not actually propose any specific solution > for any specific problem, such as the FMC/NAT problem. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > *d3e3e3@gmail.com* > > On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > <*david.i.allan@ericsson.com* > wrote: > Thanks Donald. > > So it is being addressed elsewhere. It is NOT the focus of > this effort... > > Given that clarification, this discussion is going circular. > We now revert to "what IETF FMC work are we discussing?" > > Dave > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com ] > Sent: Tuesday, April 10, 2012 2:07 PM > To: David Allan I > Cc: *sarikaya@ieee.org* ; *fmc@ietf.org* > Subject: Re: [fmc] List description > > I think this is the draft: > > *https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-* > analysis/ > That is an INTAREA WG draft. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > *d3e3e3@gmail.com* > > > On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > <*david.i.allan@ericsson.com* > wrote: > Hi Bechet: > > You did not provide a useful answer. You simply pointed out > to me things I've said (repeatedly). > > I asked: > 1) Where was the draft you referred to? > 2) What WG is working on it? > 3) Is it the topic of the effort represented by this list? > > Can you please clarify... > > Thanks > Dave > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com > ] > Sent: Tuesday, April 10, 2012 1:29 PM > To: David Allan I > Cc: *fmc@ietf.org* > Subject: Re: [fmc] List description > > Hi Dave, > > In November 2011, 3GPP-BBF Workshop > chaired by > > Dave Allan (BBF), Balazs Bertenyi (3GPP) > > issued Chairmen's Summary slides at: > > *http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104*<= http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104> > 6.zip > > which stated on Slide 4 > > In case of RG with NATs additional mechanisms are needed to > enable this. Jointly encourage IETF work on such mechanisms. > > That's all I have to say. > > I think we should concentrate on IETF work on FMC > discussions on this list. > > Kind regards, > > Behcet > > On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > <*david.i.allan@ericsson.com* > wrote: > Hi Bechet: > > Thanks for your mail. > > Two points. > > Point 1. Can you please clarify that you have expressed > your personal opinion not wearing any hats? > > Does it matter? > > Point 2. On: > > The outstanding headwound is a wifi connected UE behind a > NAT, and I > believe that is already being addressed elsewhere in the IETF. > > Yes, there is a draft called NAT Reveal Analysis draft. > It analyzes the problem and suggests very many solutions (5-6) > and there are even solutions not mentioned in NAT Reveal > Analysis draft. > > A pointer to the draft would be useful. And the WG context > it is being entertained in.... > > So it is a difficult problem and maybe explains why so > many people are subscribed to this list. > > So is solving the NAT problem the purpose of this > endeavour? I did not get that. > > > Cheers > Dave > > _______________________________________________ > fmc mailing list > *fmc@ietf.org* > *https://www.ietf.org/mailman/listinfo/fmc* > _______________________________________________ > fmc mailing list > *fmc@ietf.org* > *https://www.ietf.org/mailman/listinfo/fmc* > _______________________________________________ > fmc mailing list > *fmc@ietf.org* > *https://www.ietf.org/mailman/listinfo/fmc* > > _______________________________________________ > fmc mailing list > *fmc@ietf.org* > *https://www.ietf.org/mailman/listinfo/fmc* > _______________________________________________ > fmc mailing list* > **fmc@ietf.org* > https://www.ietf.org/mailman/listinfo/fmc > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc > > --f46d04088d8b71323d04bd71c700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Wed, Apr 11, 2012 at 9:03 PM, <tso@zteusa.com>= wrote:
Hmmm....

I must be missing something ....

I think you are missing the word "transpor= ting" or something like that, which is reasonable because I think it w= as missing from Hassnaa's message.=A0

Why= would IETF FMC work has anything to do with " =A0(screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status) =A0"??

I think the IETF might have work "= ;to do with TRANSPORTING (...)" the various terminal characteristics l= isted.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Str= eet,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com
=A0

Hassnaa Moustafa <hasnaa.moustafa@gmail.com>
Sent by: fmc-bounces@ietf.org

04/11/2012 12:09 PM

To
fmc@ietf.org
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1,= Issue 15





Hi,

IMO, terminals characteristics is a vey important aspe= ct (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status). The network connecti= vities (WiFi, 3G, ..) supported by the terminal is important also.
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:


From: <Dirk.von= -Hugo@telekom.de>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <pierrick.= seite@orange.com>, <mohamed.boucadair@orange.com>, <d3e3e3@gmail.com&g= t;, <= david.i.allan@ericsson.com>
Cc: dean.cheng@huawei= .com, sarikaya@ieee.org, fmc@ietf.org


Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoc= ols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. = 9;busy', 'available', 'be right back' etc.) and related operator pol= icies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to scree= n size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF requir= ements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been publishe= d here http://www.itu.int/rec/T-REC= -Q.1762-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.com
Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...
Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick
-----Message d'origine-----
De : fmc-bounces@ietf.org= [mailto:fmc-bounces@ietf.org] De la part de
mohamed.boucadair@orange.com
Envoy=E9 : mercredi 11 avril 2012 08:07
=C0 : Donald Eastlake; David Allan I
Cc : Dean cheng; sarikaya@ieee.o= rg; fmc@ietf.org
Objet : Re: [fmc] List description

Dear all,

There is no recommended solution for the FMC case, bec= ause there are
not clear requirements for that case.
I have suggested to Behcet to further elaborate on the requirements
from an "FMC" standpoint. Below an excerpt o= f what I sent to Behcet:

* The current HOST_ID effort in INTAREA WG is restrict= ed to the
analysis of potential channels which may convey the HO= ST_ID information
* A recommendation is likely to be added.but in the co= ntext of address
sharing (RFC6269)
* FMC proponents should elaborate further their requir= ements for the
HOST_ID
(1) Required only during session initialization?
(2) Required for all transport protocols?
(3) Host modification should be avoided or it does not harm?
(4) Which entity will use the HOST_ID information: pro= xy servers, else?
=A0(4a) Packet inspection is required? No?
=A0(4b) Performance impact
(5) Which entity will set the HOST_ID information?

BTW, I discussed this point with some colleagues and i= t seems using
port sets would be more appropriate for the FMC case (= i.e.,
http://tools.i= etf.org/html/draft-ietf-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets are used, a dedicated notification channe= l is needed to
report assigned port sets. FYI, I'm working with D= ean on this point.

Cheers,
Med

-----Message d'origine-----
De : fmc-bounces@ietf.org= [mailto:fmc-bounces@ietf.org] De la
part de Donald Eastlake
Envoy=E9 : mercredi 11 avril 2012 00:55
=C0 : David Allan I
Cc : sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] List description

I think that the nat-reveal draft, while it discusses 8 different
possible solutions, does not actually propose any spec= ific solution
for any specific problem, such as the FMC/NAT problem.=

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell)<= /font>
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<david.i.allan@erics= son.com> wrote:
Thanks Donald.

So it is being addressed elsewhere. It is NOT the focu= s of
this effort...

Given that clarification, this discussion is going cir= cular.
We now revert to "what IETF FMC work are we discu= ssing?"

Dave

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org= ; fmc@ietf.org
Subject: Re: [fmc] List description

I think this is the draft:

https://datatrack= er.ietf.org/doc/draft-ietf-intarea-nat-reveal-
analysis/
That is an INTAREA WG draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell)<= /font>
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com


On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<david.i.allan@erics= son.com> wrote:
Hi Bechet:

You did not provide a useful answer. You simply pointe= d out
to me things I've said (repeatedly).

I asked:
1) Where was the draft you referred to?
2) What WG is working on it?
3) Is it the topic of the effort represented by this l= ist?

Can you please clarify...

Thanks
Dave




-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gm= ail.com]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fmc] List description

Hi Dave,

In November 2011, 3GPP-BBF Workshop
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

issued Chairmen's Summary slides at:

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

which stated on Slide 4

In case of RG with NATs additional mechanisms are need= ed to
enable this. Jointly encourage IETF work on such mecha= nisms.

That's all I have to say.

I think we should concentrate on IETF work on FMC
discussions on this list.

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<david.i.allan@erics= son.com> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expresse= d
your personal opinion not wearing any hats?

Does it matter?

Point 2. On:

The outstanding headwound is a wifi connected UE behin= d a
NAT, and I
believe that is already being addressed elsewhere in t= he IETF.

Yes, there is a draft called NAT Reveal Analysis draft= .
It analyzes the problem and suggests very many solutio= ns (5-6)
and there are even solutions not mentioned in NAT Reve= al
Analysis draft.

A pointer to the draft would be useful. And the WG con= text
it is being entertained in....

So it is a difficult problem and maybe explains why so=
many people are subscribed to this list.

So is solving the NAT problem the purpose of this
endeavour? I did not get that.

<snipped to end>
Cheers
Dave

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

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

--------------------------------------------------=
------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

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


--f46d04088d8b71323d04bd71c700-- From xueli@huawei.com Wed Apr 11 19:57:00 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 65DF021F846F for ; Wed, 11 Apr 2012 19:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 1XlJHQt7JsIX for ; Wed, 11 Apr 2012 19:56:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 649C721F846D for ; Wed, 11 Apr 2012 19:56:59 -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 AFD63238; Wed, 11 Apr 2012 22:56:59 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 19:53:52 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 19:53:23 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.80]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Thu, 12 Apr 2012 10:53:41 +0800 From: Xueli To: "mohamed.boucadair@orange.com" , Donald Eastlake , David Allan I Thread-Topic: [fmc] List description Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcA= Date: Thu, 12 Apr 2012 02:53:40 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Dean cheng , "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 02:57:00 -0000 Hi Med, Thanks a lot for your detailed information.=20 You raised a very good point of the work. Then I would like to add few ques= tions here. Why do you think that the port set solution is more appropriate for FMC cas= e? And do you mind to explain which definition of FMC case you mentioned he= re? Port set solution may be one choice. But the huge configuration works on RG= s could not be avoided, additionally, the RGs are the subscriber side, whic= h even make=20 the configuration work more difficult.=20 BR Li > -----Original Message----- > From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Wednesday, April 11, 2012 2:07 PM > To: Donald Eastlake; David Allan I > Cc: Dean cheng; sarikaya@ieee.org; fmc@ietf.org > Subject: Re: [fmc] List description >=20 > Dear all, >=20 > There is no recommended solution for the FMC case, because there are not > clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements from = an > "FMC" standpoint. Below an excerpt of what I sent to Behcet: >=20 > * The current HOST_ID effort in INTAREA WG is restricted to the analysis = of > potential channels which may convey the HOST_ID information > * A recommendation is likely to be added.but in the context of address sh= aring > (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? >=20 > BTW, I discussed this point with some colleagues and it seems using port = sets > would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01#sect= ion-3.3) > . >=20 > If port sets are used, a dedicated notification channel is needed to repo= rt > assigned port sets. FYI, I'm working with Dean on this point. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > >=A0155 Beaver Street,=A0Milford, MA 01757 USA > >=A0d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > >> =A0155 Beaver Street,=A0Milford, MA 01757 USA > >> =A0d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1 > 104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc From mohamed.boucadair@orange.com Wed Apr 11 23:02:24 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B4621F8496 for ; Wed, 11 Apr 2012 23:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=0.6, 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 LBhlWnO9MIZd for ; Wed, 11 Apr 2012 23:02:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF9D21F8531 for ; Wed, 11 Apr 2012 23:02:22 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1371A324644; Thu, 12 Apr 2012 08:02:21 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CA456238081; Thu, 12 Apr 2012 08:02:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 12 Apr 2012 08:02:19 +0200 From: To: Xueli , Donald Eastlake , David Allan I Date: Thu, 12 Apr 2012 08:02:19 +0200 Thread-Topic: Issue #1: Identification (was RE: [fmc] List description) Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcAABskeAA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.11.150325 Cc: Dean cheng , "sarikaya@ieee.org" , "fmc@ietf.org" Subject: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 06:02:24 -0000 Dear Xue, The scenario is as follows (without elaborating all flow exchanges): o A CPE offers a shared WiFi to hosts which do not belong to the subscriber. o A visiting UE uses that shared connection to access its services o The visiting UE requests access to the service using a given method (e.g., authenticated portal) o The CPE then assigns a private IPv4 address and a set of ports to this UE o Then, the CPE reports the assigned port set to a service node together with other information such as external IPv4@/MAC@, etc. This information will be correlated with the user_id provided during the authentication phase. o The CPE will use that port set for NAPTing packets from that visiting UE o The set of ports (assigned by the CPE) and the external IP address (assigned to the CPE) are then sufficient to uniquely identify a UE. The reporting phase can be avoided if the CPE is pre-configured with a stat= ic list of port sets to be used for visiting UEs.=20 Before discussing whether this is complicated or not, let me first know if = the scenario above makes sense to you. I'm also interested to hear from you about other scenarios which may requir= e "explicit" HOST_ID. Would it be possible to provide answers to the questi= ons I asked below? Thanks.=20 Cheers, Med >-----Message d'origine----- >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 >part de Xueli >Envoy=E9 : jeudi 12 avril 2012 04:54 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Donald Eastlake; David Allan I >Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org >Objet : Re: [fmc] List description > >Hi Med, > >Thanks a lot for your detailed information.=20 >You raised a very good point of the work. Then I would like to=20 >add few questions here. > >Why do you think that the port set solution is more=20 >appropriate for FMC case? And do you mind to explain which=20 >definition of FMC case you mentioned here? >Port set solution may be one choice. But the huge=20 >configuration works on RGs could not be avoided, additionally,=20 >the RGs are the subscriber side, which even make=20 >the configuration work more difficult.=20 > >BR >Li > >> -----Original Message----- >> From: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Wednesday, April 11, 2012 2:07 PM >> To: Donald Eastlake; David Allan I >> Cc: Dean cheng; sarikaya@ieee.org; fmc@ietf.org >> Subject: Re: [fmc] List description >>=20 >> Dear all, >>=20 >> There is no recommended solution for the FMC case, because=20 >there are not >> clear requirements for that case. >> I have suggested to Behcet to further elaborate on the=20 >requirements from an >> "FMC" standpoint. Below an excerpt of what I sent to Behcet: >>=20 >> * The current HOST_ID effort in INTAREA WG is restricted to=20 >the analysis of >> potential channels which may convey the HOST_ID information >> * A recommendation is likely to be added.but in the context=20 >of address sharing >> (RFC6269) >> * FMC proponents should elaborate further their requirements for the >> HOST_ID >> (1) Required only during session initialization? >> (2) Required for all transport protocols? >> (3) Host modification should be avoided or it does not harm? >> (4) Which entity will use the HOST_ID information: proxy=20 >servers, else? >> (4a) Packet inspection is required? No? >> (4b) Performance impact >> (5) Which entity will set the HOST_ID information? >>=20 >> BTW, I discussed this point with some colleagues and it=20 >seems using port sets >> would be more appropriate for the FMC case (i.e., >>=20 >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys >is-01#section-3.3) >> . >>=20 >> If port sets are used, a dedicated notification channel is=20 >needed to report >> assigned port sets. FYI, I'm working with Dean on this point. >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la >> >part de Donald Eastlake >> >Envoy=E9 : mercredi 11 avril 2012 00:55 >> >=C0 : David Allan I >> >Cc : sarikaya@ieee.org; fmc@ietf.org >> >Objet : Re: [fmc] List description >> > >> >I think that the nat-reveal draft, while it discusses 8 different >> >possible solutions, does not actually propose any specific solution >> >for any specific problem, such as the FMC/NAT problem. >> > >> >Thanks, >> >Donald >> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >> >=A0155 Beaver Street,=A0Milford, MA 01757 USA >> >=A0d3e3e3@gmail.com >> > >> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I >> > wrote: >> >> Thanks Donald. >> >> >> >> So it is being addressed elsewhere. It is NOT the focus of >> >this effort... >> >> >> >> Given that clarification, this discussion is going circular. >> >We now revert to "what IETF FMC work are we discussing?" >> >> >> >> Dave >> >> >> >> -----Original Message----- >> >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> >> Sent: Tuesday, April 10, 2012 2:07 PM >> >> To: David Allan I >> >> Cc: sarikaya@ieee.org; fmc@ietf.org >> >> Subject: Re: [fmc] List description >> >> >> >> I think this is the draft: >> >> >> >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- >> >analysis/ >> >> That is an INTAREA WG draft. >> >> >> >> Thanks, >> >> Donald >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >> >> =A0155 Beaver Street,=A0Milford, MA 01757 USA >> >> =A0d3e3e3@gmail.com >> >> >> >> >> >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I >> > wrote: >> >>> Hi Bechet: >> >>> >> >>> You did not provide a useful answer. You simply pointed out >> >to me things I've said (repeatedly). >> >>> >> >>> I asked: >> >>> 1) Where was the draft you referred to? >> >>> 2) What WG is working on it? >> >>> 3) Is it the topic of the effort represented by this list? >> >>> >> >>> Can you please clarify... >> >>> >> >>> Thanks >> >>> Dave >> >>> >> >>> >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> >>> Sent: Tuesday, April 10, 2012 1:29 PM >> >>> To: David Allan I >> >>> Cc: fmc@ietf.org >> >>> Subject: Re: [fmc] List description >> >>> >> >>> Hi Dave, >> >>> >> >>> In November 2011, 3GPP-BBF Workshop >> >>> chaired by >> >>> >> >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) >> >>> >> >>> issued Chairmen's Summary slides at: >> >>> >> >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1 >> 104 >> >>> 6.zip >> >>> >> >>> which stated on Slide 4 >> >>> >> >>> In case of RG with NATs additional mechanisms are needed to >> >enable this. Jointly encourage IETF work on such mechanisms. >> >>> >> >>> That's all I have to say. >> >>> >> >>> I think we should concentrate on IETF work on FMC >> >discussions on this list. >> >>> >> >>> Kind regards, >> >>> >> >>> Behcet >> >>> >> >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I >> > wrote: >> >>>> Hi Bechet: >> >>>> >> >>>>> Thanks for your mail. >> >>>> >> >>>>> Two points. >> >>>> >> >>>>> Point 1. Can you please clarify that you have expressed >> >your personal opinion not wearing any hats? >> >>>> >> >>>> Does it matter? >> >>>> >> >>>> Point 2. On: >> >>>> >> >>>>>>The outstanding headwound is a wifi connected UE behind a >> >NAT, and I >> >>>>>>believe that is already being addressed elsewhere in the IETF. >> >>>> >> >>>>> Yes, there is a draft called NAT Reveal Analysis draft. >> >It analyzes the problem and suggests very many solutions (5-6) >> >and there are even solutions not mentioned in NAT Reveal >> >Analysis draft. >> >>>> >> >>>> A pointer to the draft would be useful. And the WG context >> >it is being entertained in.... >> >>>> >> >>>>> So it is a difficult problem and maybe explains why so >> >many people are subscribed to this list. >> >>>> >> >>>> So is solving the NAT problem the purpose of this >> >endeavour? I did not get that. >> >>>> >> >>>> >> >>>> Cheers >> >>>> Dave >> >>>> >> >>>> _______________________________________________ >> >>>> fmc mailing list >> >>>> fmc@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/fmc >> >>> _______________________________________________ >> >>> fmc mailing list >> >>> fmc@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/fmc >> >_______________________________________________ >> >fmc mailing list >> >fmc@ietf.org >> >https://www.ietf.org/mailman/listinfo/fmc >> > >> _______________________________________________ >> fmc mailing list >> fmc@ietf.org >> https://www.ietf.org/mailman/listinfo/fmc >_______________________________________________ >fmc mailing list >fmc@ietf.org >https://www.ietf.org/mailman/listinfo/fmc >= From hasnaa.moustafa@gmail.com Thu Apr 12 00:33: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 7E3B221F858A for ; Thu, 12 Apr 2012 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_QP_LONG_LINE=1.396, 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 blnia0KElH6p for ; Thu, 12 Apr 2012 00:33:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AECA21F8495 for ; Thu, 12 Apr 2012 00:33:36 -0700 (PDT) Received: by werb10 with SMTP id b10so1277314wer.31 for ; Thu, 12 Apr 2012 00:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=MmTrjsKdYbVp1ByJIEdFuMNMSg/8n3u7JNRLS+d41mE=; b=o/ZH4k5o5T9kxUN4YyNJUso4istH7LPcf0TWE9pRhOoG14qLcQDbL1Hivk04hcsDrt vf+Bvhv8lnMoOQtY7JYzSOraD2Lx9jac0K7xTlqemj/8HoWgM3PJ20jXTEtrwyjbfIgH aLGY6VtMkAfoiQ1WvI8TjrmJVsnSh81gFMXdZepjwXy3CpHXpuypJqGbQuMVX2hR/mnn is6cTjKwCi6WJlks17ab8NEyUCW/4D10/xfBUfKFT3k7WNyEuzydMlVmt3qymP72/aL5 QZKZSCs6Ja0wjksTPDQdrEAwiFaEKNcOgUd9Z8+/WRN9Wv27bx+5NfJCw//hbbvQR9Va wcUQ== Received: by 10.216.137.232 with SMTP id y82mr805534wei.82.1334216016194; Thu, 12 Apr 2012 00:33:36 -0700 (PDT) Received: from [10.96.199.20] ([90.84.144.148]) by mx.google.com with ESMTPS id l5sm50476512wia.11.2012.04.12.00.33.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 00:33:35 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-05529A09-BF12-44C0-8BFD-33F8E8086FA7 Message-Id: X-Mailer: iPhone Mail (9A405) From: Hassnaa Moustafa Date: Thu, 12 Apr 2012 09:35:01 +0200 To: Donald Eastlake Cc: "tso@zteusa.com" , "fmc@ietf.org" Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 07:33:39 -0000 --Apple-Mail-05529A09-BF12-44C0-8BFD-33F8E8086FA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes this is what I meant ; (how to transport these information in a dynamic And real time manner). Sure some protocols=20 Extensions would be required. And here it is the IETF work. Hassnaa S On 12 avr. 2012, at 04:04, Donald Eastlake wrote: > Hi, >=20 > On Wed, Apr 11, 2012 at 9:03 PM, wrote: > Hmmm....=20 >=20 > I must be missing something .... >=20 > I think you are missing the word "transporting" or something like that, wh= ich is reasonable because I think it was missing from Hassnaa's message.=20 >=20 > Why would IETF FMC work has anything to do with " (screen size, battery l= evel for mobile terminals and tablets, supported resolution, processing capa= city and buffering status) "??=20 >=20 > I think the IETF might have work "to do with TRANSPORTING (...)" the vario= us terminal characteristics listed. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > =20 > Hassnaa Moustafa =20 > Sent by: fmc-bounces@ietf.org > 04/11/2012 12:09 PM >=20 > To > fmc@ietf.org > cc > Subject > [fmc] Fwd: fmc Digest, Vol 1, Issue 15 >=20 >=20 >=20 >=20 >=20 > Hi,=20 >=20 > IMO, terminals characteristics is a vey important aspect (screen size, bat= tery level for mobile terminals and tablets, supported resolution, processin= g capacity and buffering status). The network connectivities (WiFi, 3G, ..) s= upported by the terminal is important also.=20 > Yes, these need to be transformed into requirements.=20 >=20 > Hassnaa=20 >=20 > Begin forwarded message:=20 >=20 >=20 > From: =20 > Subject: Re: [fmc] List description=20 > Date: April 11, 2012 2:38:15 PM GMT+02:00=20 > To: , , , =20 > Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org=20 >=20 >=20 > Dear all, > As far as I understand here we are all on track - we currently have to dis= cuss and come hopefully to a conclusion which aspects of interoperation betw= een fixed and mobile networks to provide a unified service to end users can b= e solved by means of IETF i.e. e.g. proposing a BCP of existing protocols or= adaptation and enhancement of approaches. >=20 > If that is what could be reflected within the requirements then I would ad= d my issues here: >=20 > - beside exchange of customer identity and profile (e.g. subscription deta= ils such as 'silver/gold/platinum' contract and status such as e.g. 'busy', '= available', 'be right back' etc.) and related operator policies also the cha= racteristics of currently used terminals is an important aspect both for ser= vice provisioning (e.g. adaptation of information data rate to screen size a= nd resolution) and efficient network resource usage. >=20 > Do you think that would make sense and could be translated into IETF requi= rements? >=20 > Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.= 2802 "Fixed-mobile convergence general requirements" has been published here= http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detail= ed requirements for us cannot be derived therefrom easily ... >=20 > Best regards > Dirk > -----Urspr=C3=BCngliche Nachricht----- > Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pie= rrick.seite@orange.com > Gesendet: Mittwoch, 11. April 2012 12:16 > An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson= .com > Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org > Betreff: Re: [fmc] List description >=20 > Hi, >=20 > I definitely agree we should elaborate first on requirements from an "FMC"= standpoint. And I'd add "from and IETF standpoint" also... >=20 > Before talking about solutions, I think we should try to get consensus on a= list of clear requirements with their Motivation/use-case. >=20 > Then, we could talk about solutions and go to a gap analysis, with respect= to work done in other WG (or SDOs), to see what protocol extensions are nee= ded. >=20 > Pierrick >=20 > -----Message d'origine-----=20 > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com=20 > Envoy=C3=A9 : mercredi 11 avril 2012 08:07=20 > =C3=80 : Donald Eastlake; David Allan I=20 > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org=20 > Objet : Re: [fmc] List description=20 >=20 > Dear all,=20 >=20 > There is no recommended solution for the FMC case, because there are=20 > not clear requirements for that case.=20 > I have suggested to Behcet to further elaborate on the requirements=20 > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:=20 >=20 > * The current HOST_ID effort in INTAREA WG is restricted to the=20 > analysis of potential channels which may convey the HOST_ID information=20= > * A recommendation is likely to be added.but in the context of address=20 > sharing (RFC6269)=20 > * FMC proponents should elaborate further their requirements for the=20 > HOST_ID=20 > (1) Required only during session initialization?=20 > (2) Required for all transport protocols?=20 > (3) Host modification should be avoided or it does not harm?=20 > (4) Which entity will use the HOST_ID information: proxy servers, else?=20= > (4a) Packet inspection is required? No?=20 > (4b) Performance impact=20 > (5) Which entity will set the HOST_ID information?=20 >=20 > BTW, I discussed this point with some colleagues and it seems using=20 > port sets would be more appropriate for the FMC case (i.e.,=20 > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-=20 > 01#section-3.3).=20 >=20 > If port sets are used, a dedicated notification channel is needed to=20 > report assigned port sets. FYI, I'm working with Dean on this point.=20 >=20 > Cheers,=20 > Med=20 >=20 > -----Message d'origine-----=20 > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 > part de Donald Eastlake=20 > Envoy=C3=A9 : mercredi 11 avril 2012 00:55=20 > =C3=80 : David Allan I=20 > Cc : sarikaya@ieee.org; fmc@ietf.org=20 > Objet : Re: [fmc] List description=20 >=20 > I think that the nat-reveal draft, while it discusses 8 different=20 > possible solutions, does not actually propose any specific solution=20 > for any specific problem, such as the FMC/NAT problem.=20 >=20 > Thanks,=20 > Donald=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 > 155 Beaver Street, Milford, MA 01757 USA=20 > d3e3e3@gmail.com=20 >=20 > On Tue, Apr 10, 2012 at 5:17 PM, David Allan I=20 > wrote:=20 > Thanks Donald.=20 >=20 > So it is being addressed elsewhere. It is NOT the focus of=20 > this effort...=20 >=20 > Given that clarification, this discussion is going circular.=20 > We now revert to "what IETF FMC work are we discussing?"=20 >=20 > Dave=20 >=20 > -----Original Message-----=20 > From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 > Sent: Tuesday, April 10, 2012 2:07 PM=20 > To: David Allan I=20 > Cc: sarikaya@ieee.org; fmc@ietf.org=20 > Subject: Re: [fmc] List description=20 >=20 > I think this is the draft:=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-=20 > analysis/=20 > That is an INTAREA WG draft.=20 >=20 > Thanks,=20 > Donald=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 > 155 Beaver Street, Milford, MA 01757 USA=20 > d3e3e3@gmail.com=20 >=20 >=20 > On Tue, Apr 10, 2012 at 4:32 PM, David Allan I=20 > wrote:=20 > Hi Bechet:=20 >=20 > You did not provide a useful answer. You simply pointed out=20 > to me things I've said (repeatedly).=20 >=20 > I asked:=20 > 1) Where was the draft you referred to?=20 > 2) What WG is working on it?=20 > 3) Is it the topic of the effort represented by this list?=20 >=20 > Can you please clarify...=20 >=20 > Thanks=20 > Dave=20 >=20 >=20 >=20 >=20 > -----Original Message-----=20 > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 > Sent: Tuesday, April 10, 2012 1:29 PM=20 > To: David Allan I=20 > Cc: fmc@ietf.org=20 > Subject: Re: [fmc] List description=20 >=20 > Hi Dave,=20 >=20 > In November 2011, 3GPP-BBF Workshop=20 > chaired by=20 >=20 > Dave Allan (BBF), Balazs Bertenyi (3GPP)=20 >=20 > issued Chairmen's Summary slides at:=20 >=20 > http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104=20 > 6.zip=20 >=20 > which stated on Slide 4=20 >=20 > In case of RG with NATs additional mechanisms are needed to=20 > enable this. Jointly encourage IETF work on such mechanisms.=20 >=20 > That's all I have to say.=20 >=20 > I think we should concentrate on IETF work on FMC=20 > discussions on this list.=20 >=20 > Kind regards,=20 >=20 > Behcet=20 >=20 > On Tue, Apr 10, 2012 at 1:32 PM, David Allan I=20 > wrote:=20 > Hi Bechet:=20 >=20 > Thanks for your mail.=20 >=20 > Two points.=20 >=20 > Point 1. Can you please clarify that you have expressed=20 > your personal opinion not wearing any hats?=20 >=20 > Does it matter?=20 >=20 > Point 2. On:=20 >=20 > The outstanding headwound is a wifi connected UE behind a=20 > NAT, and I=20 > believe that is already being addressed elsewhere in the IETF.=20 >=20 > Yes, there is a draft called NAT Reveal Analysis draft.=20 > It analyzes the problem and suggests very many solutions (5-6)=20 > and there are even solutions not mentioned in NAT Reveal=20 > Analysis draft.=20 >=20 > A pointer to the draft would be useful. And the WG context=20 > it is being entertained in....=20 >=20 > So it is a difficult problem and maybe explains why so=20 > many people are subscribed to this list.=20 >=20 > So is solving the NAT problem the purpose of this=20 > endeavour? I did not get that.=20 >=20 > =20 > Cheers=20 > Dave=20 >=20 > _______________________________________________=20 > fmc mailing list=20 > fmc@ietf.org=20 > https://www.ietf.org/mailman/listinfo/fmc=20 > _______________________________________________=20 > fmc mailing list=20 > fmc@ietf.org=20 > https://www.ietf.org/mailman/listinfo/fmc=20 > _______________________________________________=20 > fmc mailing list=20 > fmc@ietf.org=20 > https://www.ietf.org/mailman/listinfo/fmc=20 >=20 > _______________________________________________=20 > fmc mailing list=20 > fmc@ietf.org=20 > https://www.ietf.org/mailman/listinfo/fmc=20 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc=20 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is= solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and are= not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed. I= f you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . >=20 > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc >=20 >=20 --Apple-Mail-05529A09-BF12-44C0-8BFD-33F8E8086FA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Yes this is what I meant ;=
(how to transport these information in a dynamic
And re= al time manner). Sure some protocols 
Extensions would be req= uired. And here it is the
IETF work.

Hass= naa

S


On 12 avr. 2012, at 04:04, Donald E= astlake <d3e3e3@gmail.com> wro= te:

Hi,

On Wed, Apr 11, 2012 at 9:03 PM, <= ;tso@zteusa.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> Hmmm....

I must be missing something ....

I think you are missing the word "transporting" o= r something like that, which is reasonable because I think it was missing fr= om Hassnaa's message. 

Why w= ould IETF FMC work has anything to do with "  (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status)  "??

I think the IETF might have work "to do= with TRANSPORTING (...)" the various terminal characteristics listed.
=
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155= Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com
 

Hassnaa Moustafa <hasnaa.moustafa@gmail.com&g= t;
Sent by: fmc-bounces@ietf.org

04/11/2012 12:09 PM

To
fmc@ietf.org
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1, I= ssue 15





Hi,

IMO, terminals characteristics is a vey important aspec= t (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status). The network connectiv= ities (WiFi, 3G, ..) supported by the terminal is important also.
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:


From: <Dirk.von-H= ugo@telekom.de>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00=
To: <pierrick.se= ite@orange.com>, <mohamed.boucadair@orange.com<= /a>>, <d3e3e3@gmail.com>, <<= font size=3D"3" color=3D"blue">david.i.allan@ericsson.com<= font size=3D"3">>
Cc: dean.cheng@huawei.c= om, sarikaya@ieee.org, fmc@ietf.org


Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoco= ls or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detail= s such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to screen= size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF require= ments?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.28= 02 "Fixed-mobile convergence general requirements" has been published here http://www.itu.int/rec/T-REC-Q.1= 762-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=C3=BCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com<= /a>; d3e3e3@gmail.com; david.i.allan@ericsson.com
Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick
-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de
mohamed.boucadair@orange.com
Envoy=C3=A9 : mercredi 11 avril 2012 08:07
=C3=80 : Donald Eastlake; David Allan I
Cc : Dean cheng; sarikaya@ieee.org= ; fmc@ietf.org
Objet : Re: [fmc] List description

Dear all,

There is no recommended solution for the FMC case, beca= use there are
not clear requirements for that case.
I have suggested to Behcet to further elaborate on the requirements
from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:

* The current HOST_ID effort in INTAREA WG is restricte= d to the
analysis of potential channels which may convey the HOS= T_ID information
* A recommendation is likely to be added.but in the con= text of address
sharing (RFC6269)
* FMC proponents should elaborate further their require= ments for the
HOST_ID
(1) Required only during session initialization?=
(2) Required for all transport protocols?
(3) Host modification should be avoided or it does not harm?
(4) Which entity will use the HOST_ID information: prox= y servers, else?
 (4a) Packet inspection is required? No?
 (4b) Performance impact
(5) Which entity will set the HOST_ID information?

BTW, I discussed this point with some colleagues and it= seems using
port sets would be more appropriate for the FMC case (i= .e.,
http://tools.iet= f.org/html/draft-ietf-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets are used, a dedicated notification channel= is needed to
report assigned port sets. FYI, I'm working with Dean on this point.

Cheers,
Med

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la
part de Donald Eastlake
Envoy=C3=A9 : mercredi 11 avril 2012 00:55
=C3=80 : David Allan I
Cc : sarikaya@ieee.org<= /a>; fmc@ietf.org
Objet : Re: [fmc] List description

I think that the nat-reveal draft, while it discusses 8 different
possible solutions, does not actually propose any speci= fic solution
for any specific problem, such as the FMC/NAT problem.<= /font>

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)=
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<david.i.allan@ericsso= n.com> wrote:
Thanks Donald.

So it is being addressed elsewhere. It is NOT the focus= of
this effort...

Given that clarification, this discussion is going circ= ular.
We now revert to "what IETF FMC work are we discussing?= "

Dave

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com= ]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org= ; fmc@ietf.org
Subject: Re: [fmc] List description

I think this is the draft:

https://datatracker= .ietf.org/doc/draft-ietf-intarea-nat-reveal-
analysis/
That is an INTAREA WG draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)=
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com


On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<david.i.allan@ericsso= n.com> wrote:
Hi Bechet:

You did not provide a useful answer. You simply pointed= out
to me things I've said (repeatedly).

I asked:
1) Where was the draft you referred to?
2) What WG is working on it?
3) Is it the topic of the effort represented by this li= st?

Can you please clarify...

Thanks
Dave




-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmai= l.com]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fmc] List description

Hi Dave,

In November 2011, 3GPP-BBF Workshop
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

issued Chairmen's Summary slides at:

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

which stated on Slide 4

In case of RG with NATs additional mechanisms are neede= d to
enable this. Jointly encourage IETF work on such mechan= isms.

That's all I have to say.

I think we should concentrate on IETF work on FMC
discussions on this list.

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<david.i.allan@ericsso= n.com> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expressed=
your personal opinion not wearing any hats?

Does it matter?

Point 2. On:

The outstanding headwound is a wifi connected UE behind= a
NAT, and I
believe that is already being addressed elsewhere in th= e IETF.

Yes, there is a draft called NAT Reveal Analysis draft.=
It analyzes the problem and suggests very many solution= s (5-6)
and there are even solutions not mentioned in NAT Revea= l
Analysis draft.

A pointer to the draft would be useful. And the WG cont= ext
it is being entertained in....

So it is a difficult problem and maybe explains why so<= /font>
many people are subscribed to this list.

So is solving the NAT problem the purpose of this
endeavour? I did not get that.

<snipped to end>
Cheers
Dave

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

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

---------------------------------------------------=
-----
ZTE Information Security Notice: The information&nb=
sp;contained in this mail is solely property&n=
bsp;of the sender's organization. This mail co=
mmunication is confidential. Recipients named above=
 are obligated to maintain secrecy and ar=
e not permitted to disclose the contents =
of this communication to others.
This email and any files transmitted with =
;it are confidential and intended solely for&n=
bsp;the use of the individual or entity t=
o whom they are addressed. If you have&nb=
sp;received this email in error please notify&=
nbsp;the originator of the message. Any views&=
nbsp;expressed in this message are those of&nb=
sp;the individual sender.
This message has been scanned for viruses =
;and Spam by ZTE Anti-Spam system.

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


= --Apple-Mail-05529A09-BF12-44C0-8BFD-33F8E8086FA7-- From tso@zteusa.com Thu Apr 12 09:00:43 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 2906521F86A8 for ; Thu, 12 Apr 2012 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 qqYeZOv9c-94 for ; Thu, 12 Apr 2012 09:00:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDFB21F86B8 for ; Thu, 12 Apr 2012 09:00:36 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Fri, 13 Apr 2012 00:00:03 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 17299.1996852113; Thu, 12 Apr 2012 23:45:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3CG0Hot047781; Fri, 13 Apr 2012 00:00:17 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: Hassnaa Moustafa MIME-Version: 1.0 X-KeepSent: D01B8749:65719228-882579DE:00572156; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 12 Apr 2012 09:00:11 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-13 00:00:22, Serialize complete at 2012-04-13 00:00:22 Content-Type: multipart/alternative; boundary="=_alternative 0057EAC6882579DE_=" X-MAIL: mse02.zte.com.cn q3CG0Hot047781 Cc: Donald Eastlake , "fmc@ietf.org" Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 16:00:44 -0000 This is a multipart message in MIME format. --=_alternative 0057EAC6882579DE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, I still confuse.=20 Even to discuss the transport these information, why it is so specific for= =20 FMC scenario? Would the transport this info in a dynamic and real-time=20 manner always applies anyway for any architecture?=20 FMC support should NOT and would NOT change how these info are=20 transported, it is totally transparent.=20 Hassnaa Moustafa =20 Sent by: fmc-bounces@ietf.org 04/12/2012 12:35 AM To Donald Eastlake cc "tso@zteusa.com" , "fmc@ietf.org" Subject Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Yes this is what I meant ; (how to transport these information in a dynamic And real time manner). Sure some protocols=20 Extensions would be required. And here it is the IETF work. Hassnaa S On 12 avr. 2012, at 04:04, Donald Eastlake wrote: Hi, On Wed, Apr 11, 2012 at 9:03 PM, wrote: Hmmm....=20 I must be missing something ....=20 I think you are missing the word "transporting" or something like that,=20 which is reasonable because I think it was missing from Hassnaa's message.= =20 Why would IETF FMC work has anything to do with " (screen size, battery=20 level for mobile terminals and tablets, supported resolution, processing=20 capacity and buffering status) "??=20 I think the IETF might have work "to do with TRANSPORTING (...)" the=20 various terminal characteristics listed. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com =20 Hassnaa Moustafa =20 Sent by: fmc-bounces@ietf.org=20 04/11/2012 12:09 PM=20 To fmc@ietf.org=20 cc Subject [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Hi,=20 IMO, terminals characteristics is a vey important aspect (screen size,=20 battery level for mobile terminals and tablets, supported resolution,=20 processing capacity and buffering status). The network connectivities=20 (WiFi, 3G, ..) supported by the terminal is important also.=20 Yes, these need to be transformed into requirements.=20 Hassnaa=20 Begin forwarded message:=20 From: =20 Subject: Re: [fmc] List description=20 Date: April 11, 2012 2:38:15 PM GMT+02:00=20 To: , , < d3e3e3@gmail.com>, =20 Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org=20 Dear all, As far as I understand here we are all on track - we currently have to=20 discuss and come hopefully to a conclusion which aspects of interoperation= =20 between fixed and mobile networks to provide a unified service to end=20 users can be solved by means of IETF i.e. e.g. proposing a BCP of existing= =20 protocols or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would=20 add my issues here: - beside exchange of customer identity and profile (e.g. subscription=20 details such as 'silver/gold/platinum' contract and status such as e.g.=20 'busy', 'available', 'be right back' etc.) and related operator policies=20 also the characteristics of currently used terminals is an important=20 aspect both for service provisioning (e.g. adaptation of information data= =20 rate to screen size and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF=20 requirements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation=20 Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been=20 published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it=20 seems that detailed requirements for us cannot be derived therefrom easily= =20 ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 pierrick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3e3@gmail.com;=20 david.i.allan@ericsson.com Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC"= =20 standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on= =20 a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect= =20 to work done in other WG (or SDOs), to see what protocol extensions are=20 needed. Pierrick -----Message d'origine-----=20 De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de=20 mohamed.boucadair@orange.com=20 Envoy=E9 : mercredi 11 avril 2012 08:07=20 =C0 : Donald Eastlake; David Allan I=20 Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org=20 Objet : Re: [fmc] List description=20 Dear all,=20 There is no recommended solution for the FMC case, because there are=20 not clear requirements for that case.=20 I have suggested to Behcet to further elaborate on the requirements=20 from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:=20 * The current HOST_ID effort in INTAREA WG is restricted to the=20 analysis of potential channels which may convey the HOST_ID information=20 * A recommendation is likely to be added.but in the context of address=20 sharing (RFC6269)=20 * FMC proponents should elaborate further their requirements for the=20 HOST_ID=20 (1) Required only during session initialization?=20 (2) Required for all transport protocols?=20 (3) Host modification should be avoided or it does not harm?=20 (4) Which entity will use the HOST_ID information: proxy servers, else?=20 (4a) Packet inspection is required? No?=20 (4b) Performance impact=20 (5) Which entity will set the HOST_ID information?=20 BTW, I discussed this point with some colleagues and it seems using=20 port sets would be more appropriate for the FMC case (i.e.,=20 http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-=20 01#section-3.3).=20 If port sets are used, a dedicated notification channel is needed to=20 report assigned port sets. FYI, I'm working with Dean on this point.=20 Cheers,=20 Med=20 -----Message d'origine-----=20 De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 part de Donald Eastlake=20 Envoy=E9 : mercredi 11 avril 2012 00:55=20 =C0 : David Allan I=20 Cc : sarikaya@ieee.org; fmc@ietf.org=20 Objet : Re: [fmc] List description=20 I think that the nat-reveal draft, while it discusses 8 different=20 possible solutions, does not actually propose any specific solution=20 for any specific problem, such as the FMC/NAT problem.=20 Thanks,=20 Donald=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 155 Beaver Street, Milford, MA 01757 USA=20 d3e3e3@gmail.com=20 On Tue, Apr 10, 2012 at 5:17 PM, David Allan I=20 wrote:=20 Thanks Donald.=20 So it is being addressed elsewhere. It is NOT the focus of=20 this effort...=20 Given that clarification, this discussion is going circular.=20 We now revert to "what IETF FMC work are we discussing?"=20 Dave=20 -----Original Message-----=20 From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, April 10, 2012 2:07 PM=20 To: David Allan I=20 Cc: sarikaya@ieee.org; fmc@ietf.org=20 Subject: Re: [fmc] List description=20 I think this is the draft:=20 https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-=20 analysis/=20 That is an INTAREA WG draft.=20 Thanks,=20 Donald=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 155 Beaver Street, Milford, MA 01757 USA=20 d3e3e3@gmail.com=20 On Tue, Apr 10, 2012 at 4:32 PM, David Allan I=20 wrote:=20 Hi Bechet:=20 You did not provide a useful answer. You simply pointed out=20 to me things I've said (repeatedly).=20 I asked:=20 1) Where was the draft you referred to?=20 2) What WG is working on it?=20 3) Is it the topic of the effort represented by this list?=20 Can you please clarify...=20 Thanks=20 Dave=20 -----Original Message-----=20 From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Tuesday, April 10, 2012 1:29 PM=20 To: David Allan I=20 Cc: fmc@ietf.org=20 Subject: Re: [fmc] List description=20 Hi Dave,=20 In November 2011, 3GPP-BBF Workshop=20 chaired by=20 Dave Allan (BBF), Balazs Bertenyi (3GPP)=20 issued Chairmen's Summary slides at:=20 http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104=20 6.zip=20 which stated on Slide 4=20 In case of RG with NATs additional mechanisms are needed to=20 enable this. Jointly encourage IETF work on such mechanisms.=20 That's all I have to say.=20 I think we should concentrate on IETF work on FMC=20 discussions on this list.=20 Kind regards,=20 Behcet=20 On Tue, Apr 10, 2012 at 1:32 PM, David Allan I=20 wrote:=20 Hi Bechet:=20 Thanks for your mail.=20 Two points.=20 Point 1. Can you please clarify that you have expressed=20 your personal opinion not wearing any hats?=20 Does it matter?=20 Point 2. On:=20 The outstanding headwound is a wifi connected UE behind a=20 NAT, and I=20 believe that is already being addressed elsewhere in the IETF.=20 Yes, there is a draft called NAT Reveal Analysis draft.=20 It analyzes the problem and suggests very many solutions (5-6)=20 and there are even solutions not mentioned in NAT Reveal=20 Analysis draft.=20 A pointer to the draft would be useful. And the WG context=20 it is being entertained in....=20 So it is a difficult problem and maybe explains why so=20 many people are subscribed to this list.=20 So is solving the NAT problem the purpose of this=20 endeavour? I did not get that.=20 =20 Cheers=20 Dave=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0057EAC6882579DE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sorry,  I still confuse.

Even to discuss the transport these information, why it is so specific for FMC scenario?  Would the transp= ort this info in a dynamic and real-time manner always applies anyway for any architecture?

FMC support should NOT and would NOT change how these info are transported, it is totally transparent.  




Hassnaa Moustafa <= hasnaa.moustafa@gmail.com>
Sent by: fmc-bounces@ietf.org

04/12/2012 12:35 AM

To
Donald Eastlake <d3e3e3@gmail.com= >
cc
"tso@zteusa.com" <tso@z= teusa.com>, "fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] Fwd: fmc Digest, Vol 1, Is= sue 15





Yes this is what I meant ;
(how to transport these information in a dynamic
And real time manner). Sure some protocols
Extensions would be required. And here it is the
IETF work.

Hassnaa

S


On 12 avr. 2012, at 04:04, Donald Eastlake <d3e3e3@gmail.com= > wrote:
Hi,
On Wed, Apr 11, 2012 at 9:03 PM, <tso@zteusa.com> wrote:
Hmmm....

I must be missing something ....

I think you are missing the word "transporting"= ; or something like that, which is reasonable because I think it was missing from Hassnaa's message.

Why would IETF FMC work has anything to do with "  (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status)  "= ;??

I think the IETF might have work "to do with TRANSP= ORTING (...)" the various terminal characteristics listed.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com
 

Hassnaa Moustafa <= hasnaa.moustafa@gmail.com<= /u>>
Sent by: fmc-bounces@ietf.org

04/11/2012 12:09 PM


To
fmc@ietf.org
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1, Issue 15







Hi,

IMO, terminals characteristics is a vey important aspect (screen size, battery level for mobile terminals and tablets, supported resolution, proce= ssing capacity and buffering status). The network connectivities (WiFi, 3G, ..) supported by the terminal is important also.
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:


From: <Dirk.von-Hugo@telekom.de>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <pierrick.seite@orange.com<= font size=3D3>>, <mohamed.boucadair@orange.com>, <d3e3e3@gmail.com>, <david.i.allan@ericsson.com>
Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org


Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoc= ols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to scree= n size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF requir= ements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been publishe= d here http://www.itu.int/rec/T-REC-Q.176= 2-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.com
Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de
mohamed.boucadair@orange.com
Envoy=E9 : mercredi 11 avril 2012 08:07
=C0 : Donald Eastlake; David Allan I
Cc : Dean cheng; = sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] List description

Dear all,

There is no recommended solution for the FMC case, because there are
not clear requirements for that case.
I have suggested to Behcet to further elaborate on the requirements
from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:

* The current HOST_ID effort in INTAREA WG is restricted to the
analysis of potential channels which may convey the HOST_ID information
* A recommendation is likely to be added.but in the context of address
sharing (RFC6269)
* FMC proponents should elaborate further their requirements for the
HOST_ID
(1) Required only during session initialization?
(2) Required for all transport protocols?
(3) Host modification should be avoided or it does not harm?
(4) Which entity will use the HOST_ID information: proxy servers, else?
(4a) Packet inspection is required? No?
(4b) Performance impact
(5) Which entity will set the HOST_ID information?

BTW, I discussed this point with some colleagues and it seems using
port sets would be more appropriate for the FMC case (i.e.,
http://tools.= ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets are used, a dedicated notification channel is needed to
report assigned port sets. FYI, I'm working with Dean on this point.

Cheers,
Med

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la
part de Donald Eastlake
Envoy=E9 : mercredi 11 avril 2012 00:55
=C0 : David Allan I
Cc : sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] List description

I think that the nat-reveal draft, while it discusses 8 different
possible solutions, does not actually propose any specific solution
for any specific problem, such as the FMC/NAT problem.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Thanks Donald.

So it is being addressed elsewhere. It is NOT the focus of
this effort...

Given that clarification, this discussion is going circular.
We now revert to "what IETF FMC work are we discussing?"

Dave

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com<= font size=3D3>]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org; fmc@ietf.org
Subject: Re: [fmc] List description

I think this is the draft:

https://datatrac= ker.ietf.org/doc/draft-ietf-intarea-nat-reveal-
analysis/
That is an INTAREA WG draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com


On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Hi Bechet:

You did not provide a useful answer. You simply pointed out
to me things I've said (repeatedly).

I asked:
1) Where was the draft you referred to?
2) What WG is working on it?
3) Is it the topic of the effort represented by this list?

Can you please clarify...

Thanks
Dave




-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com= ]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fmc] List description

Hi Dave,

In November 2011, 3GPP-BBF Workshop
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

issued Chairmen's Summary slides at:

http://ww= w.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104
6.zip

which stated on Slide 4

In case of RG with NATs additional mechanisms are needed to
enable this. Jointly encourage IETF work on such mechanisms.

That's all I have to say.

I think we should concentrate on IETF work on FMC
discussions on this list.

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expressed
your personal opinion not wearing any hats?

Does it matter?

Point 2. On:

The outstanding headwound is a wifi connected UE behind a
NAT, and I
believe that is already being addressed elsewhere in the IETF.

Yes, there is a draft called NAT Reveal Analysis draft.
It analyzes the problem and suggests very many solutions (5-6)
and there are even solutions not mentioned in NAT Reveal
Analysis draft.

A pointer to the draft would be useful. And the WG context
it is being entertained in....

So it is a difficult problem and maybe explains why so
many people are subscribed to this list.

So is solving the NAT problem the purpose of this
endeavour? I did not get that.

<snipped to end>
Cheers
Dave

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

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fm= c
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fm= c
_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinf= o/fmc
----------------------------------------------------= ----
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=


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

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 0057EAC6882579DE_=-- From Dirk.von-Hugo@telekom.de Thu Apr 12 09:35: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 32D7621F8539 for ; Thu, 12 Apr 2012 09:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 Qc1PP9UeK3VR for ; Thu, 12 Apr 2012 09:35:11 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0256221F84DD for ; Thu, 12 Apr 2012 09:35:09 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 12 Apr 2012 18:35:08 +0200 Received: from HE113656.emea1.cds.t-internal.com (10.134.99.16) by HE113472.emea1.cds.t-internal.com (10.134.93.130) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 12 Apr 2012 18:35:07 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.36]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 12 Apr 2012 18:35:07 +0200 From: To: , Date: Thu, 12 Apr 2012 18:35:06 +0200 Thread-Topic: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Thread-Index: Ac0YxXAPqNn9sWO5TQCDIfRtdUiMSgAAr/dA Message-ID: <05C81A773E48DD49B181B04BA21A342A27974128E7@HE113484.emea1.cds.t-internal.com> References: 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_05C81A773E48DD49B181B04BA21A342A27974128E7HE113484emea1_" MIME-Version: 1.0 Cc: d3e3e3@gmail.com, fmc@ietf.org Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 16:35:13 -0000 --_000_05C81A773E48DD49B181B04BA21A342A27974128E7HE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, the transport of such information may be already provided within homogeneou= s networks e.g. by technology (or system/operator) specific means and there= fore not in scope of IETF. Further more these parameters typically do not c= hange if you are always using the same service and network provider and tec= hnology. But IMO in FMC scenario with various technologies (systems/operators) parti= cipating it may be vitally important to provide this information independen= t of the currently used technology (and terminal interface). I think that f= or an FMC scenario being transparent to transport of these characteristic p= arameters we need a common control protocol (and generally IP layer is the = first common layer applying to both networks). Best regards Dirk ________________________________ Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von tso@= zteusa.com Gesendet: Donnerstag, 12. April 2012 18:00 An: Hassnaa Moustafa Cc: Donald Eastlake; fmc@ietf.org Betreff: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Sorry, I still confuse. Even to discuss the transport these information, why it is so specific for = FMC scenario? Would the transport this info in a dynamic and real-time man= ner always applies anyway for any architecture? FMC support should NOT and would NOT change how these info are transported,= it is totally transparent. Hassnaa Moustafa Sent by: fmc-bounces@ietf.org 04/12/2012 12:35 AM To Donald Eastlake cc "tso@zteusa.com" , "fmc@ietf.org" Subject Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Yes this is what I meant ; (how to transport these information in a dynamic And real time manner). Sure some protocols Extensions would be required. And here it is the IETF work. Hassnaa S On 12 avr. 2012, at 04:04, Donald Eastlake > wrote: Hi, On Wed, Apr 11, 2012 at 9:03 PM, > wr= ote: Hmmm.... I must be missing something .... I think you are missing the word "transporting" or something like that, whi= ch is reasonable because I think it was missing from Hassnaa's message. Why would IETF FMC work has anything to do with " (screen size, battery le= vel for mobile terminals and tablets, supported resolution, processing capa= city and buffering status) "?? I think the IETF might have work "to do with TRANSPORTING (...)" the variou= s terminal characteristics listed. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com Hassnaa Moustafa > Sent by: fmc-bounces@ietf.org 04/11/2012 12:09 PM To fmc@ietf.org cc Subject [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Hi, IMO, terminals characteristics is a vey important aspect (screen size, batt= ery level for mobile terminals and tablets, supported resolution, processin= g capacity and buffering status). The network connectivities (WiFi, 3G, ..)= supported by the terminal is important also. Yes, these need to be transformed into requirements. Hassnaa Begin forwarded message: From: > Subject: Re: [fmc] List description Date: April 11, 2012 2:38:15 PM GMT+02:00 To: >, >, >, > Cc: dean.cheng@huawei.com, sarikaya@ieee.org<= mailto:sarikaya@ieee.org>, fmc@ietf.org Dear all, As far as I understand here we are all on track - we currently have to disc= uss and come hopefully to a conclusion which aspects of interoperation betw= een fixed and mobile networks to provide a unified service to end users can= be solved by means of IETF i.e. e.g. proposing a BCP of existing protocols= or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would add= my issues here: - beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', = 'available', 'be right back' etc.) and related operator policies also the c= haracteristics of currently used terminals is an important aspect both for = service provisioning (e.g. adaptation of information data rate to screen si= ze and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF requir= ements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been published here= http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detai= led requirements for us cannot be derived therefrom easily ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@= ietf.org] Im Auftrag von pierrick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3= e3@gmail.com; david.i.allan@ericsson.com Cc: dean.cheng@huawei.com; sarikaya@ieee.org<= mailto:sarikaya@ieee.org>; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC" = standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on a= list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect = to work done in other WG (or SDOs), to see what protocol extensions are nee= ded. Pierrick -----Message d'origine----- De : fmc-bounces@ietf.org [mailto:fmc-bounces@= ietf.org] De la part de mohamed.boucadair@orange.com Envoy=E9 : mercredi 11 avril 2012 08:07 =C0 : Donald Eastlake; David Allan I Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org<= mailto:fmc@ietf.org> Objet : Re: [fmc] List description Dear all, There is no recommended solution for the FMC case, because there are not clear requirements for that case. I have suggested to Behcet to further elaborate on the requirements from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: * The current HOST_ID effort in INTAREA WG is restricted to the analysis of potential channels which may convey the HOST_ID information * A recommendation is likely to be added.but in the context of address sharing (RFC6269) * FMC proponents should elaborate further their requirements for the HOST_ID (1) Required only during session initialization? (2) Required for all transport protocols? (3) Host modification should be avoided or it does not harm? (4) Which entity will use the HOST_ID information: proxy servers, else? (4a) Packet inspection is required? No? (4b) Performance impact (5) Which entity will set the HOST_ID information? BTW, I discussed this point with some colleagues and it seems using port sets would be more appropriate for the FMC case (i.e., http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- 01#section-3.3). If port sets are used, a dedicated notification channel is needed to report assigned port sets. FYI, I'm working with Dean on this point. Cheers, Med -----Message d'origine----- De : fmc-bounces@ietf.org [mailto:fmc-bounces@= ietf.org] De la part de Donald Eastlake Envoy=E9 : mercredi 11 avril 2012 00:55 =C0 : David Allan I Cc : sarikaya@ieee.org; fmc@ietf.org Objet : Re: [fmc] List description I think that the nat-reveal draft, while it discusses 8 different possible solutions, does not actually propose any specific solution for any specific problem, such as the FMC/NAT problem. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > wrote: Thanks Donald. So it is being addressed elsewhere. It is NOT the focus of this effort... Given that clarification, this discussion is going circular. We now revert to "what IETF FMC work are we discussing?" Dave -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com] Sent: Tuesday, April 10, 2012 2:07 PM To: David Allan I Cc: sarikaya@ieee.org; fmc@ietf.org Subject: Re: [fmc] List description I think this is the draft: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- analysis/ That is an INTAREA WG draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > wrote: Hi Bechet: You did not provide a useful answer. You simply pointed out to me things I've said (repeatedly). I asked: 1) Where was the draft you referred to? 2) What WG is working on it? 3) Is it the topic of the effort represented by this list? Can you please clarify... Thanks Dave -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent: Tuesday, April 10, 2012 1:29 PM To: David Allan I Cc: fmc@ietf.org Subject: Re: [fmc] List description Hi Dave, In November 2011, 3GPP-BBF Workshop chaired by Dave Allan (BBF), Balazs Bertenyi (3GPP) issued Chairmen's Summary slides at: http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 6.zip which stated on Slide 4 In case of RG with NATs additional mechanisms are needed to enable this. Jointly encourage IETF work on such mechanisms. That's all I have to say. I think we should concentrate on IETF work on FMC discussions on this list. Kind regards, Behcet On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > wrote: Hi Bechet: Thanks for your mail. Two points. Point 1. Can you please clarify that you have expressed your personal opinion not wearing any hats? Does it matter? Point 2. On: The outstanding headwound is a wifi connected UE behind a NAT, and I believe that is already being addressed elsewhere in the IETF. Yes, there is a draft called NAT Reveal Analysis draft. It analyzes the problem and suggests very many solutions (5-6) and there are even solutions not mentioned in NAT Reveal Analysis draft. A pointer to the draft would be useful. And the WG context it is being entertained in.... So it is a difficult problem and maybe explains why so many people are subscribed to this list. So is solving the NAT problem the purpose of this endeavour? I did not get that. Cheers Dave _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_05C81A773E48DD49B181B04BA21A342A27974128E7HE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
the transport of such information may be already prov= ided=20 within homogeneous networks e.g. by technology (or system/operator) specifi= c=20 means and therefore not in scope of IETF. Further more these parameter= s=20 typically do not change if you are always using the same service and networ= k=20 provider and technology.
But IMO in FMC scenario with various technologi= es=20 (systems/operators) participating it may be vitally important to provi= de=20 this information independent of the currently used technology (and terminal= =20 interface). I think that for an FMC scenario being trans= parent to=20 transport of these characteristic parameters we need a common control proto= col=20 (and generally IP layer is the first common layer applying to both=20 networks).
 
Best regards=20
Dirk
<= /DIV>
Von: fmc-bounces@ietf.org=20 [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 tso@zteusa.com
Gesendet: Donnerstag, 12. April 2012=20 18:00
An: Hassnaa Moustafa
Cc: Donald Eastlake;=20 fmc@ietf.org
Betreff: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue=20 15

Sorry,  I still confuse.=20

Even to discuss the transpo= rt these=20 information, why it is so specific for FMC scenario?  Would the transp= ort=20 this info in a dynamic and real-time manner always applies anyway for any=20 architecture?

FMC support s= hould NOT=20 and would NOT change how these info are transported, it is totally transpar= ent.=20  




Hassnaa Moustafa= =20 <hasnaa.moustafa@gmail.com>
Sent by: fmc-bounces@ietf.org=20

04/12/2012 12:35 AM

To
Donald Eastlake=20 <d3e3e3@gmail.com>=20
cc
"tso@zteusa.com"=20 <tso@zteusa.com>, "fmc@ietf.org" <fmc@ietf.org>=20
Subject
Re: [fmc] Fwd: fmc Digest, V= ol 1,=20 Issue 15





Yes=20 this is what I meant ;
(how to transport these=20 information in a dynamic
And real time manner). S= ure=20 some protocols
Extensions would be required. And = here it=20 is the
IETF work.

Hassnaa

S


On 12 avr. 2012= , at=20 04:04, Donald Eastlake <d3e3e3@gmail.com>= =20 wrote:

Hi,

On Wed= , Apr 11,=20 2012 at 9:03 PM, <tso@zteusa.com> wrote: =
Hmmm....

I must be missing something ....

I think you are missing the word "transporting" or something like = that,=20 which is reasonable because I think it was missing from Hassnaa's message.= =20

Why would IETF FMC work has= anything=20 to do with "  (screen size, battery level for mo= bile=20 terminals and tablets, supported resolution, processing capacity and buffer= ing=20 status)  "??=20

I think the IETF might have work "to do with= =20 TRANSPORTING (...)" the various terminal characteristics listed.=20

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E.=20 Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, M= A=20 01757 USA
d3e3e3@gmail.com
 =20

Hassnaa Moustafa= =20 <hasnaa.moustafa@gmail.com<= FONT=20 size=3D1 face=3Dsans-serif>>
Sent by: fmc-bounces@ietf.org=20

04/11/2012 12:09 PM=20


To
fmc@ietf.org=
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1= , Issue=20 15







Hi,

IMO, terminals characteristics is a vey im= portant=20 aspect (screen size, battery level for mobile terminals and tablets, suppor= ted=20 resolution, processing capacity and buffering status). The network=20 connectivities (WiFi, 3G, ..) supported by the terminal is important also.= =20
Yes, these need to be transformed into requirements.

Hassnaa=20

Begin forwarded message:


From: <Dirk.von-Hugo@telekom.de>=20
Subject: Re: [fmc] List description
Date: April 11, 2= 012=20 2:38:15 PM GMT+02:00
To: <pierrick.seite@orange.com>,=20 <= mohamed.boucadair@orange.com>, <d3e3e3@gmail.com>= ,=20 <david.i.allan@ericsson.com>=20
Cc: dean.cheng@huawei.com,=20 sarikaya@ieee.org, fmc@ietf.org


Dear all= ,
As=20 far as I understand here we are all on track - we currently have to discuss= and=20 come hopefully to a conclusion which aspects of interoperation between fixe= d and=20 mobile networks to provide a unified service to end users can be solved by = means=20 of IETF i.e. e.g. proposing a BCP of existing protocols or adaptation and=20 enhancement of approaches.

If that is what could be reflected within= the=20 requirements then I would add my issues here:

- beside exchange of=20 customer identity and profile (e.g. subscription details such as=20 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available'= , 'be=20 right back' etc.) and related operator policies also the characteristics of= =20 currently used terminals is an important aspect both for service provisioni= ng=20 (e.g. adaptation of information data rate to screen size and resolution) an= d=20 efficient network resource usage.

Do you think that would make sense= and=20 could be translated into IETF requirements?

Furthermore beside 3GPP = and=20 BBF also from ITU-T a Recommendation Q.1762/Y.2802 "Fixed-mobile convergenc= e=20 general requirements" has been published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it seems that detailed requirements for us cannot be de= rived=20 therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche=20 Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im A= uftrag=20 von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.com
Cc:= =20 dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc= ] List=20 description

Hi,

I definitely agree we should elaborate first = on=20 requirements from an "FMC" standpoint. And I'd add "from and IETF standpoin= t"=20 also...

Before talking about solutions, I think we should try to get= =20 consensus on a list of clear requirements with their=20 Motivation/use-case.

Then, we could talk about solutions and go to a= gap=20 analysis, with respect to work done in other WG (or SDOs), to see what prot= ocol=20 extensions are needed.

Pierrick

-----Message d'origine----- <= BR>De=20 : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De l= a part de=20
mohamed.boucadair@orange.com
= Envoy=E9 :=20 mercredi 11 avril 2012 08:07
=C0 : Donald Eastlake; David Allan I
C= c :=20 Dean cheng; sarikaya@ieee.org; <= /FONT>fmc@ietf.org
Objet : Re: [fmc= ] List=20 description

Dear all,

There is no recommended solution for = the=20 FMC case, because there are
not clear requirements for that case.
I= have=20 suggested to Behcet to further elaborate on the requirements
from an "F= MC"=20 standpoint. Below an excerpt of what I sent to Behcet:

* The curren= t=20 HOST_ID effort in INTAREA WG is restricted to the
analysis of potential= =20 channels which may convey the HOST_ID information
* A recommendation is= =20 likely to be added.but in the context of address
sharing (RFC6269)
= * FMC=20 proponents should elaborate further their requirements for the
HOST_ID= =20
(1) Required only during session initialization?
(2) Required for a= ll=20 transport protocols?
(3) Host modification should be avoided or it does= not=20 harm?
(4) Which entity will use the HOST_ID information: proxy servers,= =20 else?
(4a) Packet inspection is required? No?
(4b) Performance impa= ct=20
(5) Which entity will set the HOST_ID information?

BTW, I discu= ssed=20 this point with some colleagues and it seems using
port sets would be m= ore=20 appropriate for the FMC case (i.e.,
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys= is-
01#section-3.3).

If port sets are used, a dedicated=20 notification channel is needed to
report assigned port sets. FYI, I'm=20 working with Dean on this point.

Cheers,
Med

-----Messa= ge=20 d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De l= a=20
part de Donald Eastlake
Envoy=E9 : mercredi 11 avril 2012 00:55 =C0 :=20 David Allan I
Cc : sarikaya@ieee.org= ; fmc@ietf.org
Objet : Re: [fmc= ] List=20 description

I think that the nat-reveal draft, while it discusses 8= =20 different
possible solutions, does not actually propose any specific=20 solution
for any specific problem, such as the FMC/NAT problem.=20

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E.=20 Eastlake 3rd   +1-508-333-2270 (cel= l)
155=20 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com
On=20 Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<david.i.allan@ericsson.com> wr= ote:=20
Thanks Donald.

So it is being addressed elsewhere. It is NOT th= e=20 focus of
this effort...

Given that clarification, this discussi= on is=20 going circular.
We now revert to "what IETF FMC work are we discussing?= "=20

Dave

-----Original Message-----
From: Donald Eastlake=20 [mailto:d3e3e3@gmail.com]
Sent= :=20 Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org; fmc@ietf.org
Subject: Re: [fm= c] List=20 description

I think this is the draft:

https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-=
analysis/
That is an INTAREA WG draft.

Thanks,=20
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd  =20 +1-508-333-2270 (cell)
155 Be= aver=20 Street, Milford, MA 01757 USA
d3e3e3@gmail.com

On=20 Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<david.i.allan@ericsson.com> wr= ote:=20
Hi Bechet:

You did not provide a useful answer. You simply poin= ted=20 out
to me things I've said (repeatedly).

I asked:
1) Where = was=20 the draft you referred to?
2) What WG is working on it?
3) Is it th= e=20 topic of the effort represented by this list?

Can you please clarif= y...=20

Thanks
Dave




-----Original Message-----
= From:=20 Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Sent:=20 Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fm= c] List=20 description

Hi Dave,

In November 2011, 3GPP-BBF Workshop=20
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

iss= ued=20 Chairmen's Summary slides at:

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

which stated on Slide 4

In case of RG w= ith=20 NATs additional mechanisms are needed to
enable this. Jointly encourage= IETF=20 work on such mechanisms.

That's all I have to say.

I think = we=20 should concentrate on IETF work on FMC
discussions on this list.=20

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 P= M,=20 David Allan I
<david.i.allan@ericsson.com> wr= ote:=20
Hi Bechet:

Thanks for your mail.

Two points.

Po= int=20 1. Can you please clarify that you have expressed
your personal opinion= not=20 wearing any hats?

Does it matter?

Point 2. On:

The= =20 outstanding headwound is a wifi connected UE behind a
NAT, and I
be= lieve=20 that is already being addressed elsewhere in the IETF.

Yes, there i= s a=20 draft called NAT Reveal Analysis draft.
It analyzes the problem and sug= gests=20 very many solutions (5-6)
and there are even solutions not mentioned in= NAT=20 Reveal
Analysis draft.

A pointer to the draft would be useful. = And=20 the WG context
it is being entertained in....

So it is a diffic= ult=20 problem and maybe explains why so
many people are subscribed to this li= st.=20

So is solving the NAT problem the purpose of this
endeavour? I = did=20 not get that.

<snipped to end>
Cheers
Dave=20

_______________________________________________
fmc mailing lis= t=20
fmc@ietf.org<= FONT=20 size=3D3>
https://www.ietf.org/mailman/listinfo/fmc=20
_______________________________________________
fmc mailing list=20
fmc@ietf.org<= FONT=20 size=3D3>
https://www.ietf.org/mailman/listinfo/fmc=20
_______________________________________________
fmc mailing list=20
fmc@ietf.org<= FONT=20 size=3D3>
https://www.ietf.org/mailman/listinfo/fmc=20

_______________________________________________
fmc mailing lis= t=20
fmc@ietf.org<= FONT=20 size=3D3>
https://www.ietf.org/mailman/listinfo/fmc=20
_______________________________________________
fmc mailing=20 list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc=20
_______________________________________________
fmc mailing= =20 list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc


--------------------------------------------------------
ZTE=20 Information Security Notice: The information contained in this mail is sole= ly=20 property of the sender's organization. This mail communication is confident= ial.=20 Recipients named above are obligated to maintain secrecy and are not permit= ted=20 to disclose the contents of this communication to others.
This email and= any=20 files transmitted with it are confidential and intended solely for the use = of=20 the individual or entity to whom they are addressed. If you have received t= his=20 email in error please notify the originator of the message. Any views expre= ssed=20 in this message are those of the individual sender.
This message has bee= n=20 scanned for viruses and Spam by ZTE Anti-Spam system.


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

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


-------------------------------------=
-------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_05C81A773E48DD49B181B04BA21A342A27974128E7HE113484emea1_-- From tso@zteusa.com Thu Apr 12 10:16:08 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 0FD1621F8693 for ; Thu, 12 Apr 2012 10:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 5bn34jOHLHsL for ; Thu, 12 Apr 2012 10:16:05 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B48D721F8684 for ; Thu, 12 Apr 2012 10:16:04 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Fri, 13 Apr 2012 01:15:11 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 17299.2510976350; Fri, 13 Apr 2012 01:00:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3CHFuhb073511; Fri, 13 Apr 2012 01:15:56 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <05C81A773E48DD49B181B04BA21A342A27974128E7@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A27974128E7@HE113484.emea1.cds.t-internal.com> To: MIME-Version: 1.0 X-KeepSent: 362FA493:08F05B36-882579DE:005CFEE8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 12 Apr 2012 10:15:50 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-13 01:16:01, Serialize complete at 2012-04-13 01:16:01 Content-Type: multipart/alternative; boundary="=_alternative 005ED7C6882579DE_=" X-MAIL: mse02.zte.com.cn q3CHFuhb073511 Cc: d3e3e3@gmail.com, hasnaa.moustafa@gmail.com, fmc@ietf.org Subject: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 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, 12 Apr 2012 17:16:08 -0000 This is a multipart message in MIME format. --=_alternative 005ED7C6882579DE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dirk,=20 Thank you for your kind explanation.=20 I believe that the common layer (i.e. above the IP) to transport this info= =20 has already been done today.=20 Let's put FMC scenario aside for now, today for terminal connecting to the= =20 fixed access network, it could be done via either Ethernet port or USB=20 port. The fixed network could be DSL, Cable, Ethernet, EPON etc. etc. etc.= =20 =20 Now when you consider the most wireless handset today, it supports the=20 cellular interface (i.e. CDMA, GSM, HSPA, LTE etc.), WiFi interface and=20 USB port. And, the cellular network infrastructure itself, could be built= =20 based on Ethernet, Microwave, EPON etc. etc.=20 Without the FMC, all those terminal display info on the handset have=20 already transported over those wireless interface (i.e. cellular and wifi)= =20 and wired interface (i.e. Ethernet and USB) as described above.=20 The purpose of FMC is just trying to amalgamate the fixed and mobile=20 infrastructure together which could be based on same or different=20 transport technology in the access and the core network. In addition, the= =20 FMC is also trying to consolidate the support for QoS & Policy control as= =20 well as charging and accounting that are traditional different between the= =20 two networks.=20 Hence, FMC has nothing to do with the terminal display info which is=20 already supported today over its existing interface.=20 Thanks. Tricci=20 =20 Sent by: fmc-bounces@ietf.org 04/12/2012 09:35 AM To , cc d3e3e3@gmail.com, fmc@ietf.org Subject Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Hi, the transport of such information may be already provided within=20 homogeneous networks e.g. by technology (or system/operator) specific=20 means and therefore not in scope of IETF. Further more these parameters=20 typically do not change if you are always using the same service and=20 network provider and technology. But IMO in FMC scenario with various technologies (systems/operators)=20 participating it may be vitally important to provide this information=20 independent of the currently used technology (and terminal interface). I=20 think that for an FMC scenario being transparent to transport of these=20 characteristic parameters we need a common control protocol (and generally= =20 IP layer is the first common layer applying to both networks). =20 Best regards=20 Dirk=20 Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 tso@zteusa.com Gesendet: Donnerstag, 12. April 2012 18:00 An: Hassnaa Moustafa Cc: Donald Eastlake; fmc@ietf.org Betreff: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Sorry, I still confuse.=20 Even to discuss the transport these information, why it is so specific for= =20 FMC scenario? Would the transport this info in a dynamic and real-time=20 manner always applies anyway for any architecture?=20 FMC support should NOT and would NOT change how these info are=20 transported, it is totally transparent. =20 Hassnaa Moustafa =20 Sent by: fmc-bounces@ietf.org=20 04/12/2012 12:35 AM=20 To Donald Eastlake =20 cc "tso@zteusa.com" , "fmc@ietf.org" =20 Subject Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Yes this is what I meant ;=20 (how to transport these information in a dynamic=20 And real time manner). Sure some protocols=20 Extensions would be required. And here it is the=20 IETF work.=20 Hassnaa S=20 On 12 avr. 2012, at 04:04, Donald Eastlake wrote: Hi, On Wed, Apr 11, 2012 at 9:03 PM, wrote:=20 Hmmm....=20 I must be missing something ....=20 I think you are missing the word "transporting" or something like that,=20 which is reasonable because I think it was missing from Hassnaa's message.= =20 Why would IETF FMC work has anything to do with " (screen size, battery=20 level for mobile terminals and tablets, supported resolution, processing=20 capacity and buffering status) "??=20 I think the IETF might have work "to do with TRANSPORTING (...)" the=20 various terminal characteristics listed.=20 Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com=20 =20 Hassnaa Moustafa =20 Sent by: fmc-bounces@ietf.org=20 04/11/2012 12:09 PM=20 To fmc@ietf.org=20 cc Subject [fmc] Fwd: fmc Digest, Vol 1, Issue 15 Hi,=20 IMO, terminals characteristics is a vey important aspect (screen size,=20 battery level for mobile terminals and tablets, supported resolution,=20 processing capacity and buffering status). The network connectivities=20 (WiFi, 3G, ..) supported by the terminal is important also.=20 Yes, these need to be transformed into requirements.=20 Hassnaa=20 Begin forwarded message:=20 From: =20 Subject: Re: [fmc] List description=20 Date: April 11, 2012 2:38:15 PM GMT+02:00=20 To: , , < d3e3e3@gmail.com>, =20 Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org=20 Dear all, As far as I understand here we are all on track - we currently have to=20 discuss and come hopefully to a conclusion which aspects of interoperation= =20 between fixed and mobile networks to provide a unified service to end=20 users can be solved by means of IETF i.e. e.g. proposing a BCP of existing= =20 protocols or adaptation and enhancement of approaches. If that is what could be reflected within the requirements then I would=20 add my issues here: - beside exchange of customer identity and profile (e.g. subscription=20 details such as 'silver/gold/platinum' contract and status such as e.g.=20 'busy', 'available', 'be right back' etc.) and related operator policies=20 also the characteristics of currently used terminals is an important=20 aspect both for service provisioning (e.g. adaptation of information data= =20 rate to screen size and resolution) and efficient network resource usage. Do you think that would make sense and could be translated into IETF=20 requirements? Furthermore beside 3GPP and BBF also from ITU-T a Recommendation=20 Q.1762/Y.2802 "Fixed-mobile convergence general requirements" has been=20 published here http://www.itu.int/rec/T-REC-Q.1762-200709-I - however it=20 seems that detailed requirements for us cannot be derived therefrom easily= =20 ... Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von=20 pierrick.seite@orange.com Gesendet: Mittwoch, 11. April 2012 12:16 An: mohamed.boucadair@orange.com; d3e3e3@gmail.com;=20 david.i.allan@ericsson.com Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org Betreff: Re: [fmc] List description Hi, I definitely agree we should elaborate first on requirements from an "FMC"= =20 standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus on= =20 a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with respect= =20 to work done in other WG (or SDOs), to see what protocol extensions are=20 needed. Pierrick -----Message d'origine-----=20 De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de=20 mohamed.boucadair@orange.com=20 Envoy=E9 : mercredi 11 avril 2012 08:07=20 =C0 : Donald Eastlake; David Allan I=20 Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org=20 Objet : Re: [fmc] List description=20 Dear all,=20 There is no recommended solution for the FMC case, because there are=20 not clear requirements for that case.=20 I have suggested to Behcet to further elaborate on the requirements=20 from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:=20 * The current HOST_ID effort in INTAREA WG is restricted to the=20 analysis of potential channels which may convey the HOST_ID information=20 * A recommendation is likely to be added.but in the context of address=20 sharing (RFC6269)=20 * FMC proponents should elaborate further their requirements for the=20 HOST_ID=20 (1) Required only during session initialization?=20 (2) Required for all transport protocols?=20 (3) Host modification should be avoided or it does not harm?=20 (4) Which entity will use the HOST_ID information: proxy servers, else?=20 (4a) Packet inspection is required? No?=20 (4b) Performance impact=20 (5) Which entity will set the HOST_ID information?=20 BTW, I discussed this point with some colleagues and it seems using=20 port sets would be more appropriate for the FMC case (i.e.,=20 http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-=20 01#section-3.3).=20 If port sets are used, a dedicated notification channel is needed to=20 report assigned port sets. FYI, I'm working with Dean on this point.=20 Cheers,=20 Med=20 -----Message d'origine-----=20 De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la=20 part de Donald Eastlake=20 Envoy=E9 : mercredi 11 avril 2012 00:55=20 =C0 : David Allan I=20 Cc : sarikaya@ieee.org; fmc@ietf.org=20 Objet : Re: [fmc] List description=20 I think that the nat-reveal draft, while it discusses 8 different=20 possible solutions, does not actually propose any specific solution=20 for any specific problem, such as the FMC/NAT problem.=20 Thanks,=20 Donald=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 155 Beaver Street, Milford, MA 01757 USA=20 d3e3e3@gmail.com=20 On Tue, Apr 10, 2012 at 5:17 PM, David Allan I=20 wrote:=20 Thanks Donald.=20 So it is being addressed elsewhere. It is NOT the focus of=20 this effort...=20 Given that clarification, this discussion is going circular.=20 We now revert to "what IETF FMC work are we discussing?"=20 Dave=20 -----Original Message-----=20 From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Tuesday, April 10, 2012 2:07 PM=20 To: David Allan I=20 Cc: sarikaya@ieee.org; fmc@ietf.org=20 Subject: Re: [fmc] List description=20 I think this is the draft:=20 https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-=20 analysis/=20 That is an INTAREA WG draft.=20 Thanks,=20 Donald=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 Donald E. Eastlake 3rd +1-508-333-2270 (cell)=20 155 Beaver Street, Milford, MA 01757 USA=20 d3e3e3@gmail.com=20 On Tue, Apr 10, 2012 at 4:32 PM, David Allan I=20 wrote:=20 Hi Bechet:=20 You did not provide a useful answer. You simply pointed out=20 to me things I've said (repeatedly).=20 I asked:=20 1) Where was the draft you referred to?=20 2) What WG is working on it?=20 3) Is it the topic of the effort represented by this list?=20 Can you please clarify...=20 Thanks=20 Dave=20 -----Original Message-----=20 From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 Sent: Tuesday, April 10, 2012 1:29 PM=20 To: David Allan I=20 Cc: fmc@ietf.org=20 Subject: Re: [fmc] List description=20 Hi Dave,=20 In November 2011, 3GPP-BBF Workshop=20 chaired by=20 Dave Allan (BBF), Balazs Bertenyi (3GPP)=20 issued Chairmen's Summary slides at:=20 http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104=20 6.zip=20 which stated on Slide 4=20 In case of RG with NATs additional mechanisms are needed to=20 enable this. Jointly encourage IETF work on such mechanisms.=20 That's all I have to say.=20 I think we should concentrate on IETF work on FMC=20 discussions on this list.=20 Kind regards,=20 Behcet=20 On Tue, Apr 10, 2012 at 1:32 PM, David Allan I=20 wrote:=20 Hi Bechet:=20 Thanks for your mail.=20 Two points.=20 Point 1. Can you please clarify that you have expressed=20 your personal opinion not wearing any hats?=20 Does it matter?=20 Point 2. On:=20 The outstanding headwound is a wifi connected UE behind a=20 NAT, and I=20 believe that is already being addressed elsewhere in the IETF.=20 Yes, there is a draft called NAT Reveal Analysis draft.=20 It analyzes the problem and suggests very many solutions (5-6)=20 and there are even solutions not mentioned in NAT Reveal=20 Analysis draft.=20 A pointer to the draft would be useful. And the WG context=20 it is being entertained in....=20 So it is a difficult problem and maybe explains why so=20 many people are subscribed to this list.=20 So is solving the NAT problem the purpose of this=20 endeavour? I did not get that.=20 =20 Cheers=20 Dave=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________=20 fmc mailing list=20 fmc@ietf.org=20 https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc=20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is= =20 solely property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy and= =20 are not permitted to disclose the contents of this communication to=20 others. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the originator of=20 the message. Any views expressed in this message are those of the=20 individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam=20 system. _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005ED7C6882579DE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Dirk,

Thank you for your kind explanation.  

I believe that the common layer (i.e= . above the IP) to transport this info has already been done today.  

Let's put FMC scenario aside for now= , today for terminal connecting to the fixed access network, it could be done via either Ethernet port or USB port. The fixed network could be DSL, Cable, Ethernet, EPON etc. etc. etc.  

Now when you consider the most wirel= ess handset today, it supports the cellular interface (i.e. CDMA, GSM, HSPA, LTE etc.), WiFi interface and USB port. And, the cellular network infrastru= cture itself, could be built based on Ethernet, Microwave, EPON etc. etc.

Without the FMC, all those terminal display info on the handset have already transported over those wireless interface (i.e. cellular and wifi) and wired interface (i.e. Ethernet and USB) as described above.  

The purpose of FMC is just trying to amalgamate the fixed and mobile infrastructure together which could be based on same or different transport technology in the access and the core network.  In addition, the FMC is also trying to consolidate the suppo= rt for QoS & Policy control as well as charging and accounting that are traditional different between the two networks.  

Hence, FMC has nothing to do with th= e terminal display info which is already supported today over its existing interface.  

Thanks.
Tricci




<Dirk.von-Hugo@tel= ekom.de>
Sent by: fmc-bounces@ietf.org

04/12/2012 09:35 AM

To
<tso@zteusa.com>, <hasnaa.m= oustafa@gmail.com>
cc
d3e3e3@gmail.com, fmc@ietf.org
Subject
Re: [fmc] Fwd: fmc Digest, Vol 1, Is= sue 15





Hi,
the transport of such inform= ation may be already provided within homogeneous networks e.g. by technology (or system/operator) specific means and therefore not in scope of IETF. Further more these parameters typically do not change if you are always using the same service and network provider and technology.
But IMO in FMC scenario with= various technologies (systems/operators) participating it may be vitally important to provide this information independent of the currently used technology (and terminal interface). I think that for an FMC scenario being transparen= t to transport of these characteristic parameters we need a common control protocol (and generally IP layer is the first common layer applying to both networks).
 
Best regards
Dirk
Von: fmc-bounces@ietf.org [mai= lto:fmc-bounces@ietf.org] Im Auftrag von tso@zteusa.com
Gesendet: Donnerstag, 12. April 2012 18:00
An: Hassnaa Moustafa
Cc: Donald Eastlake; fmc@ietf.org
Betreff: Re: [fmc] Fwd: fmc Digest, Vol 1, Issue 15
Sorry,  I still confuse.

Even to discuss the transport these information, why it is so specific for FMC scenario?  Would the transport this info in a dynamic and real-time manner always applies anyway for any architecture?

FMC support should NOT and would NOT change how these info are transported, it is totally transparent.  



Hassnaa Moustafa <= hasnaa.moustafa@gmail.com>
Sent by: fmc-bounces@ietf.org

04/12/2012 12:35 AM


To
Donald Eastlake <d3e3= e3@gmail.com>
cc
"tso@zteusa.com" <tso@z= teusa.com>, "fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] Fwd: fmc Digest, Vol 1, Is= sue 15







Yes this is what I meant ;
(how to transport these information in a dynamic
And real time manner). Sure some protocols
Extensions would be required. And here it is the
IETF work.

Hassnaa

S


On 12 avr. 2012, at 04:04, Donald Eastlake <d3e3e3@gmail.com= > wrote:

Hi,

On Wed, Apr 11, 2012 at 9:03 PM, <tso@zteusa.com> wrote:
Hmmm....

I must be missing something ....

I think you are missing the word "transporting" or something like that, which is reasonable because I think it was missing from Hassnaa'= s message.

Why would IETF FMC work has anything to do with "  (screen size, battery level for mobile terminals and tablets, supported resolution, processing capacity and buffering status)  "??

I think the IETF might have work "to do with TRANSPORTING (...)" the various terminal characteristics listed.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA=
d3e3e3@gmail.com
 

Hassnaa Moustafa <= hasnaa.moustafa@gmail.com<= /u>>
Sent by: fmc-bounces@ietf.org

04/11/2012 12:09 PM


To
fmc@ietf.org
cc
Subject
[fmc] Fwd: fmc Digest, Vol 1, Issue 15






Hi,

IMO, terminals characteristics is a vey important aspect (screen size, battery level for mobile terminals and tablets, supported resolution, proce= ssing capacity and buffering status). The network connectivities (WiFi, 3G, ..) supported by the terminal is important also.
Yes, these need to be transformed into requirements.

Hassnaa

Begin forwarded message:


From: <Dirk.von-Hugo@telekom.de>
Subject: Re: [fmc] List description
Date: April 11, 2012 2:38:15 PM GMT+02:00
To: <pierrick.seite@orange.com<= font size=3D3>>, <mohamed.boucadair@orange.com>, <d3e3e3@gmail.com>, <david.i.allan@ericsson.com>
Cc: dean.cheng@huawei.com, sarikaya@ieee.org, fmc@ietf.org


Dear all,
As far as I understand here we are all on track - we currently have to discuss and come hopefully to a conclusion which aspects of interoperation between fixed and mobile networks to provide a unified service to end users can be solved by means of IETF i.e. e.g. proposing a BCP of existing protoc= ols or adaptation and enhancement of approaches.

If that is what could be reflected within the requirements then I would add my issues here:

- beside exchange of customer identity and profile (e.g. subscription detai= ls such as 'silver/gold/platinum' contract and status such as e.g. 'busy', 'available', 'be right back' etc.) and related operator policies also the characteristics of currently used terminals is an important aspect both for service provisioning (e.g. adaptation of information data rate to scree= n size and resolution) and efficient network resource usage.

Do you think that would make sense and could be translated into IETF requir= ements?

Furthermore beside 3GPP and BBF also from ITU-T a Recommendation Q.1762/Y.2= 802 "Fixed-mobile convergence general requirements" has been publishe= d here http://www.itu.int/rec/T-REC-Q.176= 2-200709-I - however it seems that detailed requirements for us cannot be derived therefrom easily ...

Best regards
Dirk
-----Urspr=FCngliche Nachricht-----
Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von pierrick.seite@orange.com
Gesendet: Mittwoch, 11. April 2012 12:16
An: mohamed.boucadair@orange.com; d3e3e3@gmail.com; david.i.allan@ericsson.com
Cc: dean.cheng@huawei.com; sarikaya@ieee.org; fmc@ietf.org
Betreff: Re: [fmc] List description

Hi,

I definitely agree we should elaborate first on requirements from an "= FMC" standpoint. And I'd add "from and IETF standpoint" also...

Before talking about solutions, I think we should try to get consensus on a list of clear requirements with their Motivation/use-case.

Then, we could talk about solutions and go to a gap analysis, with respect to work done in other WG (or SDOs), to see what protocol extensions are needed.

Pierrick

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de
mohamed.boucadair@orange.com
Envoy=E9 : mercredi 11 avril 2012 08:07
=C0 : Donald Eastlake; David Allan I
Cc : Dean cheng; = sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] List description

Dear all,

There is no recommended solution for the FMC case, because there are
not clear requirements for that case.
I have suggested to Behcet to further elaborate on the requirements
from an "FMC" standpoint. Below an excerpt of what I sent to Behcet:

* The current HOST_ID effort in INTAREA WG is restricted to the
analysis of potential channels which may convey the HOST_ID information
* A recommendation is likely to be added.but in the context of address
sharing (RFC6269)
* FMC proponents should elaborate further their requirements for the
HOST_ID
(1) Required only during session initialization?
(2) Required for all transport protocols?
(3) Host modification should be avoided or it does not harm?
(4) Which entity will use the HOST_ID information: proxy servers, else?
(4a) Packet inspection is required? No?
(4b) Performance impact
(5) Which entity will set the HOST_ID information?

BTW, I discussed this point with some colleagues and it seems using
port sets would be more appropriate for the FMC case (i.e.,
http://tools.= ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-
01#section-3.3).

If port sets are used, a dedicated notification channel is needed to
report assigned port sets. FYI, I'm working with Dean on this point.

Cheers,
Med

-----Message d'origine-----
De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la
part de Donald Eastlake
Envoy=E9 : mercredi 11 avril 2012 00:55
=C0 : David Allan I
Cc : sarikaya@ieee.org; fmc@ietf.org
Objet : Re: [fmc] List description

I think that the nat-reveal draft, while it discusses 8 different
possible solutions, does not actually propose any specific solution
for any specific problem, such as the FMC/NAT problem.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com

On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Thanks Donald.

So it is being addressed elsewhere. It is NOT the focus of
this effort...

Given that clarification, this discussion is going circular.
We now revert to "what IETF FMC work are we discussing?"

Dave

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com<= font size=3D3>]
Sent: Tuesday, April 10, 2012 2:07 PM
To: David Allan I
Cc: sarikaya@ieee.org; fmc@ietf.org
Subject: Re: [fmc] List description

I think this is the draft:

https://datatrac= ker.ietf.org/doc/draft-ietf-intarea-nat-reveal-
analysis/
That is an INTAREA WG draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com


On Tue, Apr 10, 2012 at 4:32 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Hi Bechet:

You did not provide a useful answer. You simply pointed out
to me things I've said (repeatedly).

I asked:
1) Where was the draft you referred to?
2) What WG is working on it?
3) Is it the topic of the effort represented by this list?

Can you please clarify...

Thanks
Dave




-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com= ]
Sent: Tuesday, April 10, 2012 1:29 PM
To: David Allan I
Cc: fmc@ietf.org
Subject: Re: [fmc] List description

Hi Dave,

In November 2011, 3GPP-BBF Workshop
chaired by

Dave Allan (BBF), Balazs Bertenyi (3GPP)

issued Chairmen's Summary slides at: =

http://ww= w.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104
6.zip

which stated on Slide 4

In case of RG with NATs additional mechanisms are needed to
enable this. Jointly encourage IETF work on such mechanisms.

That's all I have to say.

I think we should concentrate on IETF work on FMC
discussions on this list.

Kind regards,

Behcet

On Tue, Apr 10, 2012 at 1:32 PM, David Allan I
<david.i.allan@ericsson.com> wrote:
Hi Bechet:

Thanks for your mail.

Two points.

Point 1. Can you please clarify that you have expressed
your personal opinion not wearing any hats?

Does it matter?

Point 2. On:

The outstanding headwound is a wifi connected UE behind a
NAT, and I
believe that is already being addressed elsewhere in the IETF.

Yes, there is a draft called NAT Reveal Analysis draft.
It analyzes the problem and suggests very many solutions (5-6)
and there are even solutions not mentioned in NAT Reveal
Analysis draft.

A pointer to the draft would be useful. And the WG context
it is being entertained in....

So it is a difficult problem and maybe explains why so
many people are subscribed to this list.

So is solving the NAT problem the purpose of this
endeavour? I did not get that.

<snipped to end>
Cheers
Dave

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

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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=


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

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


----------------------------------------------------= ----
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=
____________________________________________= ___
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--=_alternative 005ED7C6882579DE_=-- From xueli@huawei.com Fri Apr 13 01:03:34 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 7952A21F8675 for ; Fri, 13 Apr 2012 01:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 IdHzbl0CdMGn for ; Fri, 13 Apr 2012 01:03:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F065F21F8636 for ; Fri, 13 Apr 2012 01:03:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW54533; Fri, 13 Apr 2012 04:03:33 -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, 13 Apr 2012 01:01:10 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 01:01:16 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.80]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 13 Apr 2012 16:01:10 +0800 From: Xueli To: "mohamed.boucadair@orange.com" Thread-Topic: Issue #1: Identification (was RE: [fmc] List description) Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcAABskeAAAzVFdA Date: Fri, 13 Apr 2012 08:01:09 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:03:34 -0000 Dear Med,=20 Thanks so much for your detailed explanation.=20 I am very glad to share some opinions as follows. Let's see what are the scenarios prior to the discussion about the detailed= port set solution. There are several other general scenarios, such as the mobile subscriber is= attached to home WiFi or to the 3GPP femtocell (H(e)NB) , where the mobile subscriber = establishes=20 traffic transporting via the fixed broadband network. In these scenarios, WiFi is converged into RG (residential gateway), additi= onally even femtocell maybe=20 converged later. Here the UEs must be behind RGs for services, where RG wit= h NAT. Let's back to the solutions. In case of RG with NAT, it is not easy work to achieve the port set solutio= n. The RG is the user device, which doesn't belong to the operators. Even more= , it=20 seems not possible at all to do pre-configured on RGs. In addition, mentioned in the ps draft, the issue #2, which is the similar = requirement essentially, also needs solutions.=20 Here, the port set would not work, either. During the FMC work, we should concentrate on possible protocol solutions i= n IETF later. What about your idea?:) Cheers Li From tso@zteusa.com Fri Apr 13 01:44:45 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7D21F87A9 for ; Fri, 13 Apr 2012 01:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=0.055, 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 IO9nqKoj23m4 for ; Fri, 13 Apr 2012 01:44: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 5830321F87A8 for ; Fri, 13 Apr 2012 01:44:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Fri, 13 Apr 2012 16:06:25 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 98730.3614848577; Fri, 13 Apr 2012 16:44:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3D8iIMB041445; Fri, 13 Apr 2012 16:44:18 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> To: Xueli MIME-Version: 1.0 X-KeepSent: F96FAD83:700E69E6-882579DF:002FCECF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 13 Apr 2012 01:44:06 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-13 16:44:20, Serialize complete at 2012-04-13 16:44:20 Content-Type: multipart/alternative; boundary="=_alternative 002FFE82882579DF_=" X-MAIL: mse01.zte.com.cn q3D8iIMB041445 Cc: "mohamed.boucadair@orange.com" , "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:44:45 -0000 This is a multipart message in MIME format. --=_alternative 002FFE82882579DF_= Content-Type: text/plain; charset="US-ASCII" Dear Li, Please allow me to ask a simple question... If the RG is not managed and controlled by the operator, why should the operator be responsible to solve the problem for the user's device behind the RG? Could you please explain? Thanks Tricci Xueli Sent by: fmc-bounces@ietf.org 04/13/2012 01:01 AM To "mohamed.boucadair@orange.com" cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Dear Med, Thanks so much for your detailed explanation. I am very glad to share some opinions as follows. Let's see what are the scenarios prior to the discussion about the detailed port set solution. There are several other general scenarios, such as the mobile subscriber is attached to home WiFi or to the 3GPP femtocell (H(e)NB) , where the mobile subscriber establishes traffic transporting via the fixed broadband network. In these scenarios, WiFi is converged into RG (residential gateway), additionally even femtocell maybe converged later. Here the UEs must be behind RGs for services, where RG with NAT. Let's back to the solutions. In case of RG with NAT, it is not easy work to achieve the port set solution. The RG is the user device, which doesn't belong to the operators. Even more, it seems not possible at all to do pre-configured on RGs. In addition, mentioned in the ps draft, the issue #2, which is the similar requirement essentially, also needs solutions. Here, the port set would not work, either. During the FMC work, we should concentrate on possible protocol solutions in IETF later. What about your idea?:) Cheers Li _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002FFE82882579DF_= Content-Type: text/html; charset="US-ASCII" Dear Li,

Please allow me to ask a simple question...

If the RG is not managed and controlled by the operator, why should the operator be responsible to solve the problem for the user's device behind the RG?

Could you please explain?  Thanks
Tricci



Xueli <xueli@huawei.com>
Sent by: fmc-bounces@ietf.org

04/13/2012 01:01 AM

To
"mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
cc
"fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] Issue #1: Identification (was RE:  List description)





Dear Med,

Thanks so much for your detailed explanation.
I am very glad to share some opinions as follows.

Let's see what are the scenarios prior to the discussion about the detailed port set solution.

There are several other general scenarios, such as the mobile subscriber is attached to
home WiFi or to the 3GPP femtocell  (H(e)NB) , where the mobile subscriber establishes
traffic transporting via the fixed broadband network.
In these scenarios, WiFi is converged into RG (residential gateway), additionally even femtocell maybe
converged later. Here the UEs must be behind RGs for services, where RG with NAT.

Let's back to the solutions.
In case of RG with NAT, it is not easy work to achieve the port set solution.
The RG is the user device, which doesn't belong to the operators. Even more, it
seems not possible at all to do pre-configured on RGs.

In addition, mentioned in the ps draft, the issue #2, which is the similar requirement essentially, also needs solutions.
Here, the port set would not work, either.

During the FMC work, we should concentrate on possible protocol solutions in IETF later. What about your idea?:)

Cheers
Li

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002FFE82882579DF_=-- From xueli@huawei.com Fri Apr 13 01:48: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 E336921F86F1 for ; Fri, 13 Apr 2012 01:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 4uddl4GoNVdV for ; Fri, 13 Apr 2012 01:48:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3857B21F871E for ; Fri, 13 Apr 2012 01:48:28 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW56953; Fri, 13 Apr 2012 04:48:28 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 01:44:41 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 01:44:10 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.80]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 13 Apr 2012 16:44:44 +0800 From: Xueli To: "mohamed.boucadair@orange.com" Thread-Topic: Issue #1: Identification (was RE: [fmc] List description) Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcAABskeAAAzVFdAAAU9cbA= Date: Fri, 13 Apr 2012 08:44:43 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C40F79E@szxeml528-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "fmc@ietf.org" Subject: [fmc] FW: Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:48:29 -0000 Dear Med,=20 I am afraid the last email cannot arrive in time. Try again.:) Cheers Li > -----Original Message----- > From: Xueli > Sent: Friday, April 13, 2012 4:01 PM > To: 'mohamed.boucadair@orange.com' > Cc: fmc@ietf.org > Subject: RE: Issue #1: Identification (was RE: [fmc] List description) >=20 > Dear Med, >=20 > Thanks so much for your detailed explanation. > I am very glad to share some opinions as follows. >=20 > Let's see what are the scenarios prior to the discussion about the detail= ed port > set solution. >=20 > There are several other general scenarios, such as the mobile subscriber = is > attached to > home WiFi or to the 3GPP femtocell (H(e)NB) , where the mobile subscribe= r > establishes > traffic transporting via the fixed broadband network. > In these scenarios, WiFi is converged into RG (residential gateway), addi= tionally > even femtocell maybe > converged later. Here the UEs must be behind RGs for services, where RG w= ith > NAT. >=20 > Let's back to the solutions. > In case of RG with NAT, it is not easy work to achieve the port set solut= ion. > The RG is the user device, which doesn't belong to the operators. Even mo= re, it > seems not possible at all to do pre-configured on RGs. >=20 > In addition, mentioned in the ps draft, the issue #2, which is the simila= r > requirement essentially, also needs solutions. > Here, the port set would not work, either. >=20 > During the FMC work, we should concentrate on possible protocol solutions= in > IETF later. What about your idea?:) >=20 > Cheers > Li From xueli@huawei.com Fri Apr 13 01:59: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 8B3CE21F876C for ; Fri, 13 Apr 2012 01:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 g5o0cMPodtpK for ; Fri, 13 Apr 2012 01:59:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8421F876E for ; Fri, 13 Apr 2012 01:59:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE58518; Fri, 13 Apr 2012 04:59:24 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 01:56:26 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 01:56:23 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.80]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 13 Apr 2012 16:56:16 +0800 From: Xueli To: "tso@zteusa.com" Thread-Topic: [fmc] Issue #1: Identification (was RE: List description) Thread-Index: AQHNGVGt/AioaQsYrEKbZdFzyu4zM5aYcW5A Date: Fri, 13 Apr 2012 08:56:16 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B42C40F7B3@szxeml528-mbs.china.huawei.com> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.57] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B42C40F7B3szxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mohamed.boucadair@orange.com" , "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:59:26 -0000 --_000_01FE63842C181246BBE4CF183BD159B42C40F7B3szxeml528mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tricci, The short answer is traffic control or we say, policy control. The operator should control the traffic from their subscribers, that is the= main point. I think the section 4.1 of the ps draft(http://tools.ietf.org/id/draft-xue-= intarea-fmc-ps-02.txt) would be helpful. :) BR Li From: tso@zteusa.com [mailto:tso@zteusa.com] Sent: Friday, April 13, 2012 4:44 PM To: Xueli Cc: fmc@ietf.org; mohamed.boucadair@orange.com Subject: Re: [fmc] Issue #1: Identification (was RE: List description) Dear Li, Please allow me to ask a simple question... If the RG is not managed and controlled by the operator, why should the ope= rator be responsible to solve the problem for the user's device behind the = RG? Could you please explain? Thanks Tricci Xueli Sent by: fmc-bounces@ietf.org 04/13/2012 01:01 AM To "mohamed.boucadair@orange.com" cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Dear Med, Thanks so much for your detailed explanation. I am very glad to share some opinions as follows. Let's see what are the scenarios prior to the discussion about the detailed= port set solution. There are several other general scenarios, such as the mobile subscriber is= attached to home WiFi or to the 3GPP femtocell (H(e)NB) , where the mobile subscriber = establishes traffic transporting via the fixed broadband network. In these scenarios, WiFi is converged into RG (residential gateway), additi= onally even femtocell maybe converged later. Here the UEs must be behind RGs for services, where RG wit= h NAT. Let's back to the solutions. In case of RG with NAT, it is not easy work to achieve the port set solutio= n. The RG is the user device, which doesn't belong to the operators. Even more= , it seems not possible at all to do pre-configured on RGs. In addition, mentioned in the ps draft, the issue #2, which is the similar = requirement essentially, also needs solutions. Here, the port set would not work, either. During the FMC work, we should concentrate on possible protocol solutions i= n IETF later. What about your idea?:) Cheers Li _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_01FE63842C181246BBE4CF183BD159B42C40F7B3szxeml528mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tricci,=

 = ;

The short = answer is traffic control or we say, policy control.

The operat= or should control the traffic from their subscribers, that is the main poin= t.

I think th= e section 4.1 of the ps draft(http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-0= 2.txt) would be helpful. J

 = ;

BR

Li

 = ;

 = ;

From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Friday, April 13, 2012 4:44 PM
To: Xueli
Cc: fmc@ietf.org; mohamed.boucadair@orange.com
Subject: Re: [fmc] Issue #1: Identification (was RE: List descriptio= n)

 

Dear Li,

Please allow me to ask a simple question...

If the RG is not managed and controlled by the operator, wh= y should the operator be responsible to solve the problem for the user's de= vice behind the RG?

Could you please explain?  Thanks
Tricci


Xueli <xueli@huawei.c= om>
Sent by: fmc-bounces@ietf.org

04/13/2012 01:01 AM

To

"mohamed.boucadair@ora= nge.com" <mohamed.boucadair@orange.com>

cc

"fmc@ietf.org" &l= t;fmc@ietf.org>

Subject

Re: [fmc] Issue #1: Identif= ication (was RE:  List description)

 

=


Dear Med,

Thanks so much for your detailed explanation.
I am very glad to share some opinions as follows.

Let's see what are the scenarios prior to the discussion about the deta= iled port set solution.

There are several other general scenarios, such as the mobile subscribe= r is attached to
home WiFi or to the 3GPP femtocell  (H(e)NB) , where the mobile su= bscriber establishes
traffic transporting via the fixed broadband network.
In these scenarios, WiFi is converged into RG (residential gateway), ad= ditionally even femtocell maybe
converged later. Here the UEs must be behind RGs for services, where RG= with NAT.

Let's back to the solutions.
In case of RG with NAT, it is not easy work to achieve the port set sol= ution.
The RG is the user device, which doesn't belong to the operators. Even = more, it
seems not possible at all to do pre-configured on RGs.

In addition, mentioned in the ps draft, the issue #2, which is the simi= lar requirement essentially, also needs solutions.
Here, the port set would not work, either.

During the FMC work, we should concentrate on possible protocol solutio= ns in IETF later. What about your idea?:)

Cheers
Li

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


 
-------------------------------------------------=
-------
ZTE Information Security Notice:&n=
bsp;The information contained in this mail is=
 solely property of the sender's organization=
. This mail communication is confidential. Re=
cipients named above are obligated to maintai=
n secrecy and are not permitted to discl=
ose the contents of this communication to&nbs=
p;others.
This email and any files =
;transmitted with it are confidential and int=
ended solely for the use of the individu=
al or entity to whom they are addressed.=
 If you have received this email in =
;error please notify the originator of the&nb=
sp;message. Any views expressed in this messa=
ge are those of the individual sender.
This message has been scanned=
 for viruses and Spam by ZTE Anti-Spam&n=
bsp;system.
--_000_01FE63842C181246BBE4CF183BD159B42C40F7B3szxeml528mbschi_-- From tso@zteusa.com Fri Apr 13 10:11:21 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 7F8ED21F86A1 for ; Fri, 13 Apr 2012 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.050, 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 zSARCjv9PT+f for ; Fri, 13 Apr 2012 10:11:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B44EB21F8604 for ; Fri, 13 Apr 2012 10:11:19 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 286201166107848; Sat, 14 Apr 2012 00:33:08 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.3614848577; Sat, 14 Apr 2012 01:11:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3DHB9OH042659; Sat, 14 Apr 2012 01:11:09 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C40F7B3@szxeml528-mbs.china.huawei.com> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <01FE63842C181246BBE4CF183BD159B42C40F7B3@szxeml528-mbs.china.huawei.com> To: Xueli MIME-Version: 1.0 X-KeepSent: C02C40C6:EE67735C-882579DF:005D121D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Fri, 13 Apr 2012 10:10:57 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-14 01:11:12, Serialize complete at 2012-04-14 01:11:12 Content-Type: multipart/alternative; boundary="=_alternative 005E65E1882579DF_=" X-MAIL: mse01.zte.com.cn q3DHB9OH042659 Cc: "mohamed.boucadair@orange.com" , "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:11:21 -0000 This is a multipart message in MIME format. --=_alternative 005E65E1882579DF_= Content-Type: text/plain; charset="US-ASCII" Dear Li, Thank you for your kind and prompt response, and your reference to your draft. Yes. I have read the draft, and I am sorry to say that I don't quite agree most of the arguments. Unfortunately, with your answer, I am still confused. Because, on one hand, you said that, "The RG is the user device, which doesn't belong to the operators.", and then, on the other hand, you said that, "The operator should control the traffic from their subscribers, that is the main point. ". It almost sounds like to me, "well, I am the subscriber of the operator, I can do whatever I want to break the system and the operator just has to fix it." ? Is it the spirit of your consideration, by raising the issue to the operator who is not accountable on the issue that the user creates? IMHO, I can see that the operator should provide the FMC solution on the E2E system that they manage and have the control. Hence, I have trouble to understand your logic. Cheers. Tricci Xueli 04/13/2012 01:56 AM To "tso@zteusa.com" cc "fmc@ietf.org" , "mohamed.boucadair@orange.com" Subject RE: [fmc] Issue #1: Identification (was RE: List description) Hi Tricci, The short answer is traffic control or we say, policy control. The operator should control the traffic from their subscribers, that is the main point. I think the section 4.1 of the ps draft( http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt) would be helpful. J BR Li From: tso@zteusa.com [mailto:tso@zteusa.com] Sent: Friday, April 13, 2012 4:44 PM To: Xueli Cc: fmc@ietf.org; mohamed.boucadair@orange.com Subject: Re: [fmc] Issue #1: Identification (was RE: List description) Dear Li, Please allow me to ask a simple question... If the RG is not managed and controlled by the operator, why should the operator be responsible to solve the problem for the user's device behind the RG? Could you please explain? Thanks Tricci Xueli Sent by: fmc-bounces@ietf.org 04/13/2012 01:01 AM To "mohamed.boucadair@orange.com" cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Dear Med, Thanks so much for your detailed explanation. I am very glad to share some opinions as follows. Let's see what are the scenarios prior to the discussion about the detailed port set solution. There are several other general scenarios, such as the mobile subscriber is attached to home WiFi or to the 3GPP femtocell (H(e)NB) , where the mobile subscriber establishes traffic transporting via the fixed broadband network. In these scenarios, WiFi is converged into RG (residential gateway), additionally even femtocell maybe converged later. Here the UEs must be behind RGs for services, where RG with NAT. Let's back to the solutions. In case of RG with NAT, it is not easy work to achieve the port set solution. The RG is the user device, which doesn't belong to the operators. Even more, it seems not possible at all to do pre-configured on RGs. In addition, mentioned in the ps draft, the issue #2, which is the similar requirement essentially, also needs solutions. Here, the port set would not work, either. During the FMC work, we should concentrate on possible protocol solutions in IETF later. What about your idea?:) Cheers Li _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005E65E1882579DF_= Content-Type: text/html; charset="US-ASCII" Dear Li,

Thank you for your kind and prompt response, and your reference to your draft.  Yes. I have read the draft, and I am sorry to say that I don't quite agree most of the arguments.  

Unfortunately, with your answer, I am still confused.  Because, on one hand, you said that, "The RG is the user device, which doesn't belong to the operators.", and then, on the other hand, you said that, "The operator should control the traffic from their subscribers, that is the main point.  ".

It almost sounds like to me, "well, I am the subscriber of the operator, I can do whatever I want to break the system and the operator just has to fix it." ?

Is it the spirit of your consideration, by raising the issue to the operator who is not accountable on the issue that the user creates?

IMHO, I can see that the operator should provide the FMC solution on the E2E system that they manage and have the control.  Hence, I have trouble to understand your logic.

Cheers.
Tricci




Xueli <xueli@huawei.com>

04/13/2012 01:56 AM

To
"tso@zteusa.com" <tso@zteusa.com>
cc
"fmc@ietf.org" <fmc@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Subject
RE: [fmc] Issue #1: Identification (was RE:  List description)





Hi Tricci,
 
The short answer is traffic control or we say, policy control.
The operator should control the traffic from their subscribers, that is the main point.
I think the section 4.1 of the ps draft(http://tools.ietf.org/id/draft-xue-intarea-fmc-ps-02.txt) would be helpful. J
 
BR
Li
 
 
From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Friday, April 13, 2012 4:44 PM
To: Xueli
Cc: fmc@ietf.org; mohamed.boucadair@orange.com
Subject: Re: [fmc] Issue #1: Identification (was RE: List description)
 
Dear Li,

Please allow me to ask a simple question...

If the RG is not managed and controlled by the operator, why should the operator be responsible to solve the problem for the user's device behind the RG?

Could you please explain?  Thanks
Tricci

Xueli <xueli@huawei.com>
Sent by: fmc-bounces@ietf.org

04/13/2012 01:01 AM


To
"mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
cc
"fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] Issue #1: Identification (was RE:  List description)

 







Dear Med,

Thanks so much for your detailed explanation.
I am very glad to share some opinions as follows.

Let's see what are the scenarios prior to the discussion about the detailed port set solution.

There are several other general scenarios, such as the mobile subscriber is attached to
home WiFi or to the 3GPP femtocell  (H(e)NB) , where the mobile subscriber establishes
traffic transporting via the fixed broadband network.
In these scenarios, WiFi is converged into RG (residential gateway), additionally even femtocell maybe
converged later. Here the UEs must be behind RGs for services, where RG with NAT.

Let's back to the solutions.
In case of RG with NAT, it is not easy work to achieve the port set solution.
The RG is the user device, which doesn't belong to the operators. Even more, it
seems not possible at all to do pre-configured on RGs.

In addition, mentioned in the ps draft, the issue #2, which is the similar requirement essentially, also needs solutions.
Here, the port set would not work, either.

During the FMC work, we should concentrate on possible protocol solutions in IETF later. What about your idea?:)

Cheers
Li

_______________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 005E65E1882579DF_=-- From mohamed.boucadair@orange.com Sun Apr 15 23:33: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 9C39A21F864A for ; Sun, 15 Apr 2012 23:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.084, 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 1TtRggUWFq-T for ; Sun, 15 Apr 2012 23:33:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B612D21F865B for ; Sun, 15 Apr 2012 23:33:38 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1434826426B; Mon, 16 Apr 2012 08:33:37 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EEF724C015; Mon, 16 Apr 2012 08:33:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 16 Apr 2012 08:33:37 +0200 From: To: Xueli Date: Mon, 16 Apr 2012 08:33:35 +0200 Thread-Topic: Issue #1: Identification (was RE: [fmc] List description) Thread-Index: Ac0XbQI9Y5wK5cFtQkK9Pn2AVTyFiQAOjxtAACsvXcAABskeAAAzVFdAAJbPDbA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E28919BEB@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 06:33:39 -0000 Dear Xue, Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : Xueli [mailto:xueli@huawei.com]=20 >Envoy=E9 : vendredi 13 avril 2012 10:01 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : fmc@ietf.org >Objet : RE: Issue #1: Identification (was RE: [fmc] List description) > >Dear Med,=20 > >Thanks so much for your detailed explanation.=20 >I am very glad to share some opinions as follows. > >Let's see what are the scenarios prior to the discussion about=20 >the detailed port set solution. > >There are several other general scenarios, such as the mobile=20 >subscriber is attached to >home WiFi or to the 3GPP femtocell (H(e)NB) , where the=20 >mobile subscriber establishes=20 >traffic transporting via the fixed broadband network. >In these scenarios, WiFi is converged into RG (residential=20 >gateway), additionally even femtocell maybe=20 >converged later. Here the UEs must be behind RGs for services,=20 >where RG with NAT. Med: Agreed...but this is the same scenario I described. I was wondering if= you have identified other scenarios which may raise the identification iss= ue. > >Let's back to the solutions. >In case of RG with NAT, it is not easy work to achieve the=20 >port set solution. >The RG is the user device, which doesn't belong to the=20 >operators. Even more, it=20 >seems not possible at all to do pre-configured on RGs. Med: I won't agree nor object this analysis at this stage. Let's first agre= e on the requirements; a tentative list is provided below. We need provide = answers to these questions: (1) The HOST_ID MUST be set by a trusted device: Yes/No? (1a) The RG MUST set the HOST_ID: Yes/No? (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No? (1c) The UE can set the HOST_ID: Yes/No? (1d) An Upstream service device MUST check the content of the HOST_ID: Yes/= No? (1e) If the answer to (1d) is Yes, which device? Xxxxx (1f) Which information is used by this upstream device to identify the UE b= ehind the NAT? (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/No= ? (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID: = Yes/No? (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: Ye= s/No? (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No? > >In addition, mentioned in the ps draft, the issue #2, which is=20 >the similar requirement essentially, also needs solutions.=20 >Here, the port set would not work, either. Med: I disagree with you conclusion but let's first discuss the requirement= s. > >During the FMC work, we should concentrate on possible=20 >protocol solutions in IETF later. What about your idea?:) Med: IMHO before declaring a work is needed within IETF, we need to: * Identify the issues with a list of functional requirements * Assess whether existing tools can not be packaged to meet those requireme= nts > >Cheers >Li > >= From pierrick.seite@orange.com Tue Apr 17 05:59: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 48D5121F85B6 for ; Tue, 17 Apr 2012 05:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_53=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 IvsR-w4JcPNn for ; Tue, 17 Apr 2012 05:59:11 -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 9454421F85C0 for ; Tue, 17 Apr 2012 05:59:10 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2F6BEE302D8; Tue, 17 Apr 2012 15:11:03 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 209DEE302C4; Tue, 17 Apr 2012 15:11: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); Tue, 17 Apr 2012 14:59:09 +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_01CD1C99.E0837F7D" Date: Tue, 17 Apr 2012 14:59:08 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462024D6F7D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [fmc] List description Thread-Index: Ac0YSZ69UozdU6dPQTSxmDp/H2nVGwET3Xzg References: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f From: To: , X-OriginalArrivalTime: 17 Apr 2012 12:59:09.0679 (UTC) FILETIME=[E129A7F0:01CD1C99] Cc: david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, sarikaya@ieee.org, d3e3e3@gmail.com, mohamed.boucadair@orange.com Subject: Re: [fmc] List description X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 12:59:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C99.E0837F7D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 De : tso@zteusa.com [mailto:tso@zteusa.com]=20 Envoy=E9 : jeudi 12 avril 2012 03:14 =C0 : Jong-Hyouk Lee Cc : d3e3e3@gmail.com; david.i.allan@ericsson.com; = dean.cheng@huawei.com; fmc@ietf.org; BOUCADAIR Mohamed OLNC-NAD-TIP; = SEITE Pierrick RD-RESA-REN; sarikaya@ieee.org Objet : Re: [fmc] List description =20 Dear Pierrick,=20 You have raised the excellent point that we all need to figure out what = are the requirements from "FMC" standpoint. =20 But I am wondering, since 3GPP and BBF have been working on this FMC = work for so long, wouldn't they have done the gap analysis already? = I.e. if they need work to be done in IETF, should they have asked us to = work on them already? Why should we start from scratch to do our own analysis? =20 This is exactly what I meant: let's see what 3GPP/BBF have done before = rushing on solutions J What do you think?=20 Pierrick=20 Thanks.=20 Tricci=20 Jong-Hyouk Lee =20 Sent by: fmc-bounces@ietf.org=20 04/11/2012 04:42 AM=20 To pierrick.seite@orange.com=20 cc david.i.allan@ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, = sarikaya@ieee.org, d3e3e3@gmail.com, mohamed.boucadair@orange.com=20 Subject Re: [fmc] List description =20 =09 Fully agree with his words. On Wed, Apr 11, 2012 at 12:15 PM, wrote:=20 Hi, I definitely agree we should elaborate first on requirements from an = "FMC" standpoint. And I'd add "from and IETF standpoint" also... Before talking about solutions, I think we should try to get consensus = on a list of clear requirements with their Motivation/use-case. Then, we could talk about solutions and go to a gap analysis, with = respect to work done in other WG (or SDOs), to see what protocol = extensions are needed. Pierrick=20 > -----Message d'origine----- > De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com > Envoy=E9 : mercredi 11 avril 2012 08:07 > =C0 : Donald Eastlake; David Allan I > Cc : Dean cheng; sarikaya@ieee.org; fmc@ietf.org=20 > Objet : Re: [fmc] List description >=20 > Dear all, > > There is no recommended solution for the FMC case, because there are > not clear requirements for that case. > I have suggested to Behcet to further elaborate on the requirements > from an "FMC" standpoint. Below an excerpt of what I sent to Behcet: > > * The current HOST_ID effort in INTAREA WG is restricted to the > analysis of potential channels which may convey the HOST_ID = information > * A recommendation is likely to be added.but in the context of address > sharing (RFC6269) > * FMC proponents should elaborate further their requirements for the > HOST_ID > (1) Required only during session initialization? > (2) Required for all transport protocols? > (3) Host modification should be avoided or it does not harm? > (4) Which entity will use the HOST_ID information: proxy servers, = else? > (4a) Packet inspection is required? No? > (4b) Performance impact > (5) Which entity will set the HOST_ID information? > > BTW, I discussed this point with some colleagues and it seems using > port sets would be more appropriate for the FMC case (i.e., > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis- > 01#section-3.3). > > If port sets are used, a dedicated notification channel is needed to > report assigned port sets. FYI, I'm working with Dean on this point. > > Cheers, > Med > > >-----Message d'origine----- > >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la > >part de Donald Eastlake > >Envoy=E9 : mercredi 11 avril 2012 00:55 > >=C0 : David Allan I > >Cc : sarikaya@ieee.org; fmc@ietf.org > >Objet : Re: [fmc] List description > > > >I think that the nat-reveal draft, while it discusses 8 different > >possible solutions, does not actually propose any specific solution > >for any specific problem, such as the FMC/NAT problem. > > > >Thanks, > >Donald > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > Donald E. Eastlake 3rd +1-508-333-2270 = (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I > > wrote: > >> Thanks Donald. > >> > >> So it is being addressed elsewhere. It is NOT the focus of > >this effort... > >> > >> Given that clarification, this discussion is going circular. > >We now revert to "what IETF FMC work are we discussing?" > >> > >> Dave > >> > >> -----Original Message----- > >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] > >> Sent: Tuesday, April 10, 2012 2:07 PM > >> To: David Allan I > >> Cc: sarikaya@ieee.org; fmc@ietf.org > >> Subject: Re: [fmc] List description > >> > >> I think this is the draft: > >> > >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal- > >analysis/ > >> That is an INTAREA WG draft. > >> > >> Thanks, > >> Donald > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> Donald E. Eastlake 3rd +1-508-333-2270 = (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> On Tue, Apr 10, 2012 at 4:32 PM, David Allan I > > wrote: > >>> Hi Bechet: > >>> > >>> You did not provide a useful answer. You simply pointed out > >to me things I've said (repeatedly). > >>> > >>> I asked: > >>> 1) Where was the draft you referred to? > >>> 2) What WG is working on it? > >>> 3) Is it the topic of the effort represented by this list? > >>> > >>> Can you please clarify... > >>> > >>> Thanks > >>> Dave > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >>> Sent: Tuesday, April 10, 2012 1:29 PM > >>> To: David Allan I > >>> Cc: fmc@ietf.org > >>> Subject: Re: [fmc] List description > >>> > >>> Hi Dave, > >>> > >>> In November 2011, 3GPP-BBF Workshop > >>> chaired by > >>> > >>> Dave Allan (BBF), Balazs Bertenyi (3GPP) > >>> > >>> issued Chairmen's Summary slides at: > >>> > = >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-1104 > >>> 6.zip > >>> > >>> which stated on Slide 4 > >>> > >>> In case of RG with NATs additional mechanisms are needed to > >enable this. Jointly encourage IETF work on such mechanisms. > >>> > >>> That's all I have to say. > >>> > >>> I think we should concentrate on IETF work on FMC > >discussions on this list. > >>> > >>> Kind regards, > >>> > >>> Behcet > >>> > >>> On Tue, Apr 10, 2012 at 1:32 PM, David Allan I > > wrote: > >>>> Hi Bechet: > >>>> > >>>>> Thanks for your mail. > >>>> > >>>>> Two points. > >>>> > >>>>> Point 1. Can you please clarify that you have expressed > >your personal opinion not wearing any hats? > >>>> > >>>> Does it matter? > >>>> > >>>> Point 2. On: > >>>> > >>>>>>The outstanding headwound is a wifi connected UE behind a > >NAT, and I > >>>>>>believe that is already being addressed elsewhere in the IETF. > >>>> > >>>>> Yes, there is a draft called NAT Reveal Analysis draft. > >It analyzes the problem and suggests very many solutions (5-6) > >and there are even solutions not mentioned in NAT Reveal > >Analysis draft. > >>>> > >>>> A pointer to the draft would be useful. And the WG context > >it is being entertained in.... > >>>> > >>>>> So it is a difficult problem and maybe explains why so > >many people are subscribed to this list. > >>>> > >>>> So is solving the NAT problem the purpose of this > >endeavour? I did not get that. > >>>> > >>>> > >>>> Cheers > >>>> Dave > >>>> > >>>> _______________________________________________ > >>>> fmc mailing list > >>>> fmc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fmc > >>> _______________________________________________ > >>> fmc mailing list > >>> fmc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fmc > >_______________________________________________ > >fmc mailing list > >fmc@ietf.org > >https://www.ietf.org/mailman/listinfo/fmc > > > _______________________________________________ > fmc mailing list > fmc@ietf.org > https://www.ietf.org/mailman/listinfo/fmc _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc=20 --=20 RSM Department, TELECOM Bretagne, France=20 Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random=20 #email: jonghyouk (at) gmail (dot) com=20 #webpage: http://sites.google.com/site/hurryon/=20 _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc = =20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01CD1C99.E0837F7D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

De : = tso@zteusa.com [mailto:tso@zteusa.com]
Envoy=E9 : jeudi = 12 avril 2012 03:14
=C0 : Jong-Hyouk = Lee
Cc : d3e3e3@gmail.com; david.i.allan@ericsson.com; = dean.cheng@huawei.com; fmc@ietf.org; BOUCADAIR Mohamed OLNC-NAD-TIP; = SEITE Pierrick RD-RESA-REN; sarikaya@ieee.org
Objet : Re: = [fmc] List description

 

Dear Pierrick, =

You have = raised the excellent point that we all need to figure out what are the = requirements from "FMC" standpoint.   =

But I am = wondering, since 3GPP and BBF have been working on this FMC work for so = long, wouldn't they have done the gap analysis already? =  I.e. if they need work to be = done in IETF, should they have asked us to work on them = already?

Why should we start from = scratch to do our own analysis?    

This is exactly what I meant: let’s see what 3GPP/BBF have done = before rushing on solutions J

What do you think? =

Pierrick


Thanks.
Tricci =



Jong-Hyouk = Lee <jonghyouk@gmail.com> =
Sent by: = fmc-bounces@ietf.org

04/11/2012 = 04:42 AM

To=

pierrick.seite= @orange.com

cc=

david.i.allan@= ericsson.com, fmc@ietf.org, dean.cheng@huawei.com, sarikaya@ieee.org, = d3e3e3@gmail.com, mohamed.boucadair@orange.com =

Subject=

Re: [fmc] = List description

 




Fully agree with his = words.

On Wed, Apr 11, 2012 at 12:15 PM, <pierrick.seite@orange.com&g= t; wrote:
Hi,

I definitely agree we should elaborate first on = requirements from an "FMC" standpoint. And I'd add "from = and IETF standpoint" also...

Before talking about solutions, = I think we should try to get consensus on a list of clear requirements = with their Motivation/use-case.

Then, we could talk about = solutions and go to a gap analysis, with respect to work done in other = WG (or SDOs), to see what protocol extensions are = needed.

Pierrick

> -----Message d'origine-----
> = De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De la = part de
> mohamed.boucadair@orange.com=
> Envoy=E9 : mercredi 11 avril 2012 08:07
> = =C0 : Donald Eastlake; David Allan I
> Cc : Dean cheng; = sarikaya@ieee.org; fmc@ietf.org
> Objet : Re: = [fmc] List description
>
> Dear all,
>
> There = is no recommended solution for the FMC case, because there are
> = not clear requirements for that case.
> I have suggested to Behcet = to further elaborate on the requirements
> from an "FMC" = standpoint. Below an excerpt of what I sent to Behcet:
>
> * = The current HOST_ID effort in INTAREA WG is restricted to the
> = analysis of potential channels which may convey the HOST_ID = information
> * A recommendation is likely to be added.but in the = context of address
> sharing (RFC6269)
> * FMC proponents = should elaborate further their requirements for the
> = HOST_ID
> (1) Required only during session initialization?
> = (2) Required for all transport protocols?
> (3) Host modification = should be avoided or it does not harm?
> (4) Which entity will use = the HOST_ID information: proxy servers, else?
>   (4a) Packet = inspection is required? No?
>   (4b) Performance = impact
> (5) Which entity will set the HOST_ID = information?
>
> BTW, I discussed this point with some = colleagues and it seems using
> port sets would be more = appropriate for the FMC case (i.e.,
> http://tools.ietf.org/html/draft-ietf-intarea-nat-revea= l-analysis-
> 01#section-3.3).
>
> If port sets = are used, a dedicated notification channel is needed to
> report = assigned port sets. FYI, I'm working with Dean on this = point.
>
> Cheers,
> Med
>
> = >-----Message d'origine-----
> >De : fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] De = la
> >part de Donald Eastlake
> >Envoy=E9 : mercredi = 11 avril 2012 00:55
> >=C0 : David Allan I
> >Cc : sarikaya@ieee.org; fmc@ietf.org
> >Objet : Re: = [fmc] List description
> >
> >I think that the = nat-reveal draft, while it discusses 8 different
> >possible = solutions, does not actually propose any specific solution
> = >for any specific problem, such as the FMC/NAT problem.
> = >
> >Thanks,
> >Donald
> = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
> > Donald E. Eastlake 3rd   = +1-508-333-2270 (cell)
> = > 155 Beaver Street, Milford, MA 01757 USA
> = > d3e3e3@gmail.com
> = >
> >On Tue, Apr 10, 2012 at 5:17 PM, David Allan I
> = ><david.i.allan@ericsson.com= > wrote:
> >> Thanks Donald.
> >>
> = >> So it is being addressed elsewhere. It is NOT the focus = of
> >this effort...
> >>
> >> Given = that clarification, this discussion is going circular.
> >We = now revert to "what IETF FMC work are we discussing?"
> = >>
> >> Dave
> >>
> >> = -----Original Message-----
> >> From: Donald Eastlake = [mailto:d3e3e3@gmail.com]
> >> = Sent: Tuesday, April 10, 2012 2:07 PM
> >> To: David Allan = I
> >> Cc: sarikaya@ieee.org; fmc@ietf.org
> >> Subject: = Re: [fmc] List description
> >>
> >> I think = this is the draft:
> >>
> >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat= -reveal-
> >analysis/
> >> That is an INTAREA = WG draft.
> >>
> >> Thanks,
> >> = Donald
> >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> >>  Donald E. Eastlake 3rd   = +1-508-333-2270 (cell)
> = >>  155 Beaver Street, Milford, MA 01757 USA
> = >>  d3e3e3@gmail.com
> = >>
> >>
> >> On Tue, Apr 10, 2012 at 4:32 = PM, David Allan I
> ><david.i.allan@ericsson.com= > wrote:
> >>> Hi Bechet:
> >>>
> = >>> You did not provide a useful answer. You simply pointed = out
> >to me things I've said (repeatedly).
> = >>>
> >>> I asked:
> >>> 1) Where = was the draft you referred to?
> >>> 2) What WG is = working on it?
> >>> 3) Is it the topic of the effort = represented by this list?
> >>>
> >>> Can = you please clarify...
> >>>
> >>> = Thanks
> >>> Dave
> >>>
> = >>>
> >>>
> >>>
> = >>> -----Original Message-----
> >>> From: = Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
>= ; >>> Sent: Tuesday, April 10, 2012 1:29 PM
> = >>> To: David Allan I
> >>> Cc: fmc@ietf.org
> >>> = Subject: Re: [fmc] List description
> >>>
> = >>> Hi Dave,
> >>>
> >>> In = November 2011, 3GPP-BBF Workshop
> >>> chaired by
> = >>>
> >>> Dave Allan (BBF), Balazs Bertenyi = (3GPP)
> >>>
> >>> issued Chairmen's = Summary slides at:
> >>>
> >http://www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SF= O/Docs/3BF-1104
> >>> 6.zip
> = >>>
> >>> which stated on Slide 4
> = >>>
> >>> In case of RG with NATs additional = mechanisms are needed to
> >enable this. Jointly encourage IETF = work on such mechanisms.
> >>>
> >>> = That's all I have to say.
> >>>
> >>> I = think we should concentrate on IETF work on FMC
> >discussions = on this list.
> >>>
> >>> Kind = regards,
> >>>
> >>> Behcet
> = >>>
> >>> On Tue, Apr 10, 2012 at 1:32 PM, David = Allan I
> ><david.i.allan@ericsson.com= > wrote:
> >>>> Hi Bechet:
> = >>>>
> >>>>> Thanks for your = mail.
> >>>>
> >>>>> Two = points.
> >>>>
> >>>>> Point 1. = Can you please clarify that you have expressed
> >your personal = opinion not wearing any hats?
> >>>>
> = >>>> Does it matter?
> >>>>
> = >>>> Point 2. On:
> >>>>
> = >>>>>>The outstanding headwound is a wifi connected UE = behind a
> >NAT, and I
> >>>>>>believe = that is already being addressed elsewhere in the IETF.
> = >>>>
> >>>>> Yes, there is a draft = called NAT Reveal Analysis draft.
> >It analyzes the problem = and suggests very many solutions (5-6)
> >and there are even = solutions not mentioned in NAT Reveal
> >Analysis = draft.
> >>>>
> >>>> A pointer to = the draft would be useful. And the WG context
> >it is being = entertained in....
> >>>>
> >>>>> = So it is a difficult problem and maybe explains why so
> >many = people are subscribed to this list.
> >>>>
> = >>>> So is solving the NAT problem the purpose of = this
> >endeavour? I did not get that.
> = >>>>
> >>>> <snipped to end>
> = >>>> Cheers
> >>>> Dave
> = >>>>
> >>>> = _______________________________________________
> >>>> = fmc mailing list
> >>>> fmc@ietf.org
> >>>> = https://www.ietf.org/mailman/listinfo/fmc
> = >>> _______________________________________________
> = >>> fmc mailing list
> >>> fmc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/fmc
> = >_______________________________________________
> >fmc = mailing list
> >fmc@ietf.org
> >https://www.ietf.org/mailman/listinfo/fmc
> = >
> _______________________________________________
> fmc = mailing list
> fmc@ietf.org
> https://www.ietf.org/mailman/listinfo/fmc
______= _________________________________________
fmc mailing list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc =



--
RSM Department, TELECOM Bretagne, France =
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random =

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/ =
______________________________________________= _
fmc mailing = list
fmc@ietf.org
https://www.ietf.org/mailman/listinfo/fmc

 
----=
----------------------------------------------------
ZTE Information Security Notice: The informatio= n contained in this mail is solely pro= perty of the sender's organization. This ma= il communication is confidential. Recipients nam= ed above are obligated to maintain secrecy&= nbsp;and are not permitted to disclose the&= nbsp;contents of this communication to others.
This email and any files tra=
nsmitted with it are confidential and inten=
ded solely for the use of the individu=
al or entity to whom they are addresse=
d. If you have received this email in&=
nbsp;error please notify the originator of =
the message. Any views expressed in this&nb=
sp;message are those of the individual send=
er.
This message has been scanne=
d for viruses and Spam by ZTE Anti-Spa=
m system.
------_=_NextPart_001_01CD1C99.E0837F7D-- From sarikaya2012@gmail.com Tue Apr 17 08:43: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 5EF5321F8562 for ; Tue, 17 Apr 2012 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.066, 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 O5tnOxOVwS9I for ; Tue, 17 Apr 2012 08:43:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6021F854B for ; Tue, 17 Apr 2012 08:43:14 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3582368ggm.31 for ; Tue, 17 Apr 2012 08:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jQU4wGVDGQIHjpCjaI6yeexmTbju6oA3LWVThgi2+mQ=; b=EsxEjsC6ke3vnSFYjWfwOd6/V7ZIQIsmcuQrcecb5GA+lXqpAAnC7xdVH0ZcOlfME5 e7iHIzL/VEB52m4UBgmRceqDS85mCnC3EEAV1Wk2/Q9QzJwzTu9uSlHmmKnS8E/eCLSe Bl4m9YsNBBMkF/piCUbx/WAfUyAMBgYa6Ro4+1lB/u6yMJclAWjVW+lez1qrdIyX6G1e xaTkyVe9g9Tl5uJ+l5eWV0ekbBbJrwTCAkuZWzpjGoXplq6QW7vkDQ02E9Ka+j258WdD 5QQAyqAyay8JQl11uY/8KJgWmEG/hlX/fTP1f3uaHUW7Fc4JUwkI1iBQ5Fa4VvwHlTvG BNGw== MIME-Version: 1.0 Received: by 10.50.189.129 with SMTP id gi1mr10042372igc.16.1334677394060; Tue, 17 Apr 2012 08:43:14 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 17 Apr 2012 08:43:13 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462024D6F7D@ftrdmel0.rd.francetelecom.fr> References: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <843DA8228A1BA74CA31FB4E111A5C462024D6F7D@ftrdmel0.rd.francetelecom.fr> Date: Tue, 17 Apr 2012 10:43:13 -0500 Message-ID: From: Behcet Sarikaya To: pierrick.seite@orange.com Content-Type: multipart/alternative; boundary=14dae9340a83f675eb04bde1cb22 Cc: fmc@ietf.org Subject: Re: [fmc] List description 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, 17 Apr 2012 15:43:15 -0000 --14dae9340a83f675eb04bde1cb22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pierrick, On Tue, Apr 17, 2012 at 7:59 AM, wrote: > Hi,**** > > ** ** > > ** ** > > *De :* tso@zteusa.com [mailto:tso@zteusa.com] > *Envoy=E9 :* jeudi 12 avril 2012 03:14 > *=C0 :* Jong-Hyouk Lee > *Cc :* d3e3e3@gmail.com; david.i.allan@ericsson.com; dean.cheng@huawei.co= m; > fmc@ietf.org; BOUCADAIR Mohamed OLNC-NAD-TIP; SEITE Pierrick RD-RESA-REN; > sarikaya@ieee.org > > *Objet :* Re: [fmc] List description**** > > ** ** > > Dear Pierrick, > > You have raised the excellent point that we all need to figure out what > are the requirements from "FMC" standpoint. > > But I am wondering, since 3GPP and BBF have been working on this FMC work > for so long, wouldn't they have done the gap analysis already? I.e. if > they need work to be done in IETF, should they have asked us to work on > them already? > > Why should we start from scratch to do our own analysis? **** > > This is exactly what I meant: let=92s see what 3GPP/BBF have done before > rushing on solutions J > Let me clarify. This group is an IETF group and hence any future work this group may come up with (I hope I am using the right words) belong to IETF. IETF work is different than the SDO work. SDOs do their work, IETF does its work. Who is rushing on solutions? There are some discussions going on Issue #1 mentioned on IETF draft draft-xue-intarea-fmc-ps-02.txt and possible solutions mentioned on another IETF draft draft-ietf-intarea-nat-reveal-analysis-01.txt. I don't think anybody said Pierrick should not see what 3GPP/BBF have done before on this or on other issues. Regards, Behcet snipped the rest. --14dae9340a83f675eb04bde1cb22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pierrick,

On Tue, Apr 17, 2012 at 7:59= AM, <pi= errick.seite@orange.com> wrote:

Hi,

=A0

=A0<= /p>

De=A0: tso@zteusa.com [mailto:tso@zteusa.c= om]
Envoy=E9=A0: jeudi 12 avril 2012 03:14
=C0=A0: Jong-Hyouk = Lee
Cc=A0: = d3e3e3@gmail.com; david.i.allan@ericsson.com; dean.cheng@huawei.com; fmc@ietf.org; BOUCADAIR Mohamed OLNC-NAD-= TIP; SEITE Pierrick RD-RESA-REN; sarikaya@ieee.org


Objet=A0: Re: [fmc] List description=

=A0

Dear Pierrick,


You have raised the excellent point that we all need to= figure out what are the requirements from "FMC" standpoint. =A0<= /span>

Bu= t I am wondering, since 3GPP and BBF have been working on this FMC work for= so long, wouldn't they have done the gap analysis already? =A0<= span style=3D"font-family:"Arial","sans-serif"" lang=3D= "EN-US">I.e. if they need work to be done in IETF, should they have asked u= s to work on them already?

Why should we start from scratch to do our own analysis= ? =A0 =A0

This is exactly what I meant: let=92s see what = 3GPP/BBF have done before rushing on solutions J


Let me clarify. This group is an IE= TF group and hence any future work this group may come up with (I hope I am= using the right words) belong to IETF. IETF work is different than the SDO= work. SDOs do their work, IETF does its work.

Who is rushing on solutions? There are some discussions going on Issue = #1 mentioned on IETF draft
draft-xue-intarea-fmc-ps-02.txt

and possible solutions mentioned on another IETF dra= ft draft-ietf-intarea-nat-reveal-analysis-01.txt.

I don't think anybody said Pierrick should not see what 3GPP/BBF have done before on this or = on other issues.

Regards,

Behcet

snipped the rest.

--14dae9340a83f675eb04bde1cb22-- From sarikaya2012@gmail.com Tue Apr 17 09:14: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 4DFF711E80B3 for ; Tue, 17 Apr 2012 09:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 GYFrVa2rYkfc for ; Tue, 17 Apr 2012 09:14:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE65F11E8088 for ; Tue, 17 Apr 2012 09:14:24 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3614436ggm.31 for ; Tue, 17 Apr 2012 09:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o805wNOP7UWcN3o+6V1FH3TvGxfRqbiI37ZxlGcoF2w=; b=CPFXLPinW0RPLQrDeUtF/Rsw8oMOVdbywgnWZHOqNTgwQ4ETiStntADn5MMGK9SjhY xv2xavIgSqT+dLfYbODOcitsdEYdDGxUA7b9y6wjOcgshMA7609RU+Ph60fW7hlce2S1 n2HOsInns07EJo+O9DEtzImRyU90GJBmadbfUqlkMHD33qIOII9SGGUt1goXucHhPFUq UYMIdaT/uksdnpWzK4UO8Vspjw+VcetfNEJ2l1e9M2s3yrr6nGB1SEMCz5GP9wsAiViv yP0sY2pyU4bvQzWVI59VBaPjOfBOibSeFaukJVCUmHNj2HjAqTTrSDv8/1YjLC7HdzRB YBZg== MIME-Version: 1.0 Received: by 10.50.85.232 with SMTP id k8mr10185609igz.16.1334679264001; Tue, 17 Apr 2012 09:14:24 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 17 Apr 2012 09:14:23 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28919BEB@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E28919BEB@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 17 Apr 2012 11:14:23 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) 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, 17 Apr 2012 16:14:25 -0000 Hi Med, On Mon, Apr 16, 2012 at 1:33 AM, wrote: > Med: I won't agree nor object this analysis at this stage. Let's first agree on the requirements; a tentative list is provided below. We need provide answers to these questions: > > (1) The HOST_ID MUST be set by a trusted device: Yes/No? > (1a) The RG MUST set the HOST_ID: Yes/No? > (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No? > (1c) The UE can set the HOST_ID: Yes/No? > (1d) An Upstream service device MUST check the content of the HOST_ID: Yes/No? > (1e) If the answer to (1d) is Yes, which device? Xxxxx > (1f) Which information is used by this upstream device to identify the UE behind the NAT? > (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? > (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/No? > (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID: Yes/No? > (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: Yes/No? > (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? > (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? > (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No? > Yes, agreeing on the requirements (for each issue set) is a good idea. Question for clarification: are the above referring to only Sections 3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where HOST_ID is specifically used? I guess you mean for the requirements, we can remove the ones that are answered no? By consensus? How? Behcet From tso@zteusa.com Tue Apr 17 09:56:20 2012 Return-Path: X-Original-To: fmc@ietfa.amsl.com Delivered-To: fmc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED611E8080; Tue, 17 Apr 2012 09:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.046, 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 wACbcr5pN0Is; Tue, 17 Apr 2012 09:56:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6575711E8074; Tue, 17 Apr 2012 09:56:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201689387102; Wed, 18 Apr 2012 00:17:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 53138.2891405403; Wed, 18 Apr 2012 00:56:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3HGu21Y014909; Wed, 18 Apr 2012 00:56:02 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f To: sarikaya@ieee.org MIME-Version: 1.0 X-KeepSent: 7A6FFFD7:12C676A5-882579E3:005BB606; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 17 Apr 2012 09:55:40 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-18 00:56:06, Serialize complete at 2012-04-18 00:56:06 Content-Type: multipart/alternative; boundary="=_alternative 005D04F3882579E3_=" X-MAIL: mse02.zte.com.cn q3HGu21Y014909 Cc: mohamed.boucadair@orange.com, fmc-bounces@ietf.org, "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:56:20 -0000 This is a multipart message in MIME format. --=_alternative 005D04F3882579E3_= Content-Type: text/plain; charset="US-ASCII" Dear Behcet, I must be missing something? I sincerely don't understand where are all these requirements come from the SDO which are developing the FMC solution today? Could you please identify for which SDO's FMC related specifications or LS to IETF have requested these requirements to be addressed by IETF? As far as my understanding, the fundamental concept of Host ID has not been even considered by other SDO (e.g. 3GPP or BBF etc.) which is developing the FMC standards. Hence, I sincerely don't understand why would this Host ID concept be brought up? Regards, Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/17/2012 09:14 AM Please respond to sarikaya@ieee.org To mohamed.boucadair@orange.com cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Hi Med, On Mon, Apr 16, 2012 at 1:33 AM, wrote: > Med: I won't agree nor object this analysis at this stage. Let's first agree on the requirements; a tentative list is provided below. We need provide answers to these questions: > > (1) The HOST_ID MUST be set by a trusted device: Yes/No? > (1a) The RG MUST set the HOST_ID: Yes/No? > (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No? > (1c) The UE can set the HOST_ID: Yes/No? > (1d) An Upstream service device MUST check the content of the HOST_ID: Yes/No? > (1e) If the answer to (1d) is Yes, which device? Xxxxx > (1f) Which information is used by this upstream device to identify the UE behind the NAT? > (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? > (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/No? > (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID: Yes/No? > (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: Yes/No? > (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? > (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? > (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No? > Yes, agreeing on the requirements (for each issue set) is a good idea. Question for clarification: are the above referring to only Sections 3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where HOST_ID is specifically used? I guess you mean for the requirements, we can remove the ones that are answered no? By consensus? How? Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 005D04F3882579E3_= Content-Type: text/html; charset="US-ASCII" Dear Behcet,

I must be missing something?

I sincerely don't understand where are all these requirements come from the SDO which are developing the FMC solution today?  Could you please identify for which SDO's FMC related specifications or LS to IETF have requested these requirements to be addressed by IETF?  

As far as my understanding, the fundamental concept of Host ID has not been even considered by other SDO (e.g. 3GPP or BBF etc.) which is developing the FMC standards.  Hence, I sincerely don't understand why would this Host ID concept be brought up?  

Regards,
Tricci  




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

04/17/2012 09:14 AM
Please respond to
sarikaya@ieee.org
To
mohamed.boucadair@orange.com
cc
"fmc@ietf.org" <fmc@ietf.org>
Subject
Re: [fmc] Issue #1: Identification (was RE: List description)





Hi Med,

On Mon, Apr 16, 2012 at 1:33 AM,  <mohamed.boucadair@orange.com> wrote:

> Med: I won't agree nor object this analysis at this stage. Let's first agree on the requirements; a tentative list is provided below. We need provide answers to these questions:
>
> (1) The HOST_ID MUST be set by a trusted device: Yes/No?
> (1a) The RG MUST set the HOST_ID: Yes/No?
> (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No?
> (1c) The UE can set the HOST_ID: Yes/No?
> (1d) An Upstream service device MUST check the content of the HOST_ID: Yes/No?
> (1e) If the answer to (1d) is Yes, which device? Xxxxx
> (1f) Which information is used by this upstream device to identify the UE behind the NAT?
> (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No?
> (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/No?
> (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID: Yes/No?
> (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: Yes/No?
> (4) The HOST_ID solution MUST be specific to IPv4: Yes/No?
> (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No?
> (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No?
>

Yes, agreeing on the requirements (for each issue set) is a good idea.

Question for clarification: are the above referring to only Sections
3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where
HOST_ID is specifically used?

I guess you mean for the requirements, we can remove the ones that are
answered no? By consensus? How?

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 005D04F3882579E3_=-- From mohamed.boucadair@orange.com Tue Apr 17 10:06: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 E8C5B21F84C5 for ; Tue, 17 Apr 2012 10:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.079, 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 UE-fDLSOpRiv for ; Tue, 17 Apr 2012 10:06:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7024421F84C4 for ; Tue, 17 Apr 2012 10:06:22 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2F18D18C0BB; Tue, 17 Apr 2012 19:06:21 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1578D238056; Tue, 17 Apr 2012 19:06:21 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 17 Apr 2012 19:06:20 +0200 From: To: "tso@zteusa.com" , "sarikaya@ieee.org" Date: Tue, 17 Apr 2012 19:05:34 +0200 Thread-Topic: [fmc] Issue #1: Identification (was RE: List description) Thread-Index: Ac0cuwCg6yq+plnITn2mZZIqcbPDTwAAU0U4 Message-ID: <94C682931C08B048B7A8645303FDC9F36E28518EF2@PUEXCB1B.nanterre.francetelecom.fr> References: <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f , In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.17.124217 Cc: "fmc@ietf.org" Subject: [fmc] RE : Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:06:27 -0000 Dear Tricci, Please refer to slide 12 of www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_S= FO/Docs/3BF-11046.zip. Cheers, Med ________________________________________ De : tso@zteusa.com [tso@zteusa.com] Date d'envoi : mardi 17 avril 2012 18:55 =C0 : sarikaya@ieee.org Cc : fmc@ietf.org; fmc-bounces@ietf.org; BOUCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [fmc] Issue #1: Identification (was RE: List description) Dear Behcet, I must be missing something? I sincerely don't understand where are all these requirements come from the= SDO which are developing the FMC solution today? Could you please identif= y for which SDO's FMC related specifications or LS to IETF have requested t= hese requirements to be addressed by IETF? As far as my understanding, the fundamental concept of Host ID has not been= even considered by other SDO (e.g. 3GPP or BBF etc.) which is developing t= he FMC standards. Hence, I sincerely don't understand why would this Host = ID concept be brought up? Regards, Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/17/2012 09:14 AM Please respond to sarikaya@ieee.org To mohamed.boucadair@orange.com cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Hi Med, On Mon, Apr 16, 2012 at 1:33 AM, wrote: > Med: I won't agree nor object this analysis at this stage. Let's first ag= ree on the requirements; a tentative list is provided below. We need provid= e answers to these questions: > > (1) The HOST_ID MUST be set by a trusted device: Yes/No? > (1a) The RG MUST set the HOST_ID: Yes/No? > (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No? > (1c) The UE can set the HOST_ID: Yes/No? > (1d) An Upstream service device MUST check the content of the HOST_ID: Ye= s/No? > (1e) If the answer to (1d) is Yes, which device? Xxxxx > (1f) Which information is used by this upstream device to identify the UE= behind the NAT? > (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? > (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/= No? > (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID= : Yes/No? > (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: = Yes/No? > (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? > (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? > (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No? > Yes, agreeing on the requirements (for each issue set) is a good idea. Question for clarification: are the above referring to only Sections 3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where HOST_ID is specifically used? I guess you mean for the requirements, we can remove the ones that are answered no? By consensus? How? Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From tso@zteusa.com Tue Apr 17 11:09: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 9A27D21F848C for ; Tue, 17 Apr 2012 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 wlCSiNFlG4wQ for ; Tue, 17 Apr 2012 11:09:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D774121F8469 for ; Tue, 17 Apr 2012 11:09:40 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 621291166107848; Wed, 18 Apr 2012 02:08:46 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.2368126149; Wed, 18 Apr 2012 02:09:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q3HI9VXT070257; Wed, 18 Apr 2012 02:09:31 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28518EF2@PUEXCB1B.nanterre.francetelecom.fr> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f , To: MIME-Version: 1.0 X-KeepSent: B30016DE:ADD986A8-882579E3:005F8887; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 17 Apr 2012 11:09:05 -0700 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-18 02:09:34, Serialize complete at 2012-04-18 02:09:34 Content-Type: multipart/related; boundary="=_related 0063BDFB882579E3_=" X-MAIL: mse01.zte.com.cn q3HI9VXT070257 Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: [fmc] RE : Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:09:46 -0000 This is a multipart message in MIME format. --=_related 0063BDFB882579E3_= Content-Type: multipart/alternative; boundary="=_alternative 0063BDFB882579E3_=" --=_alternative 0063BDFB882579E3_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBNZWQsIA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVmZXJlbmNlLiAgSG93ZXZlciwgd2hl biBJIGxvb2sgYXQgc2xpZGUtMTIsIEkgZG9uJ3QgDQpzZWUgYW55IHJlcXVpcmVtZW50IHN1Z2dl c3RpbmcgdGhlIG5lZWQgZm9yIGRlZmluaW5nIGFuZCBvYnRhaW5pbmcgdGhlIA0KSG9zdCBJRCBm b3IgYSBnaXZlbiBVRT8gIEJ1bGxldCAjMiBiZWxvdyBpcyB0byBpZGVudGlmeSB0aGUgVUUgd2hp Y2ggaXMgDQpiYXNlZCBvbiAzR1BQIGNvbmNlcHQgYW5kIGhhdmUgdGhlaXIgb3duIHNwZWNpZmlj IGlkZW50aWZpY2F0aW9uIGRlZmluZWQgDQpieSAzR1BQLiANCg0KVGhhbmtzLg0KVHJpY2NpIA0K Pj4+Pj4NClByb3ZpZGUgYSBkZWZpbml0aW9uIG9mIOKAnDNHUFAgVUXigJ0gdG8gQkJGIA0K4oCi dG8gYmUgdXNlZCBpbiB0aGUgY29udGV4dCBvZiBCQkYtM0dQUCBpbnRlcndvcmtpbmcgYW5kIGNv bnZlcmdlbmNlDQpFbmNvdXJhZ2UgSUVURiB3b3JrIG9uIG1lY2hhbmlzbXMgdG8gZW5hYmxlIGlk ZW50aWZ5aW5nIGluZGl2aWR1YWwgVUVzIA0KYmVoaW5kIE5BVC9SR3MNCg0KRXh0ZW5kIFNXYSBh bmQgU1RhIHRvIHN1cHBvcnQgZXhpc3RpbmcgQkJGIGFjY291bnRpbmcNCkNvbnRpbnVlIHN0dWR5 aW5nIHRoZSBhcHBsaWNhdGlvbiBvZiBUREYgaW4gYm90aCBCQjIgYW5kIEJCMyANCmNvbmZpZ3Vy YXRpb25zDQrigKJQcm92aWRlIGZ1cnRoZXIgaW5mb3JtYXRpb24gb24gdGhlIFRERi1iYXNlZCBk ZXBsb3ltZW50IHNjZW5hcmlvIHRvIEJCRg0KU2VuZCBMaWFpc29uIFN0YXRlbWVudCB0byBvdXRs aW5lIHRoZSBTYU1PRyBhcmNoaXRlY3R1cmUgdG8gQkJGIG9uY2UgaXQgaXMgDQpzdWZmaWNpZW50 bHkgc3RhYmxlIGFuZCBhc2sgZm9yIGNvbW1lbnRzL2ZlZWRiYWNrDQpTZWVrIHJldmlldyBmcm9t IEJCRiBiZWZvcmUgZmluYWwgYXBwcm92YWwgb2YgM0dQUCBzdGFnZS0yIGFuZCBzdGFnZS0zDQo+ Pj4+Pg0KDQpXaGF0IGRvIHlvdSB0aGluaz8gICBUaGFua3MNClRyaWNjaSANCg0KDQoNCg0KPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IA0KMDQvMTcvMjAxMiAxMDowNSBBTQ0KDQpUbw0K InRzb0B6dGV1c2EuY29tIiA8dHNvQHp0ZXVzYS5jb20+LCAic2FyaWtheWFAaWVlZS5vcmciIDxz YXJpa2F5YUBpZWVlLm9yZz4NCmNjDQoiZm1jQGlldGYub3JnIiA8Zm1jQGlldGYub3JnPg0KU3Vi amVjdA0KUkUgOiBbZm1jXSBJc3N1ZSAjMTogSWRlbnRpZmljYXRpb24gKHdhcyBSRTogTGlzdCBk ZXNjcmlwdGlvbikNCg0KDQoNCg0KDQoNCkRlYXIgVHJpY2NpLA0KDQpQbGVhc2UgcmVmZXIgdG8g c2xpZGUgMTIgb2YgDQp3d3cuM2dwcC5vcmcvZnRwL3dvcmtzaG9wLzIwMTEtMTEtMDlfM0dQUF9C QkZfU0ZPL0RvY3MvM0JGLTExMDQ2LnppcC4NCg0KQ2hlZXJzLA0KTWVkDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IHRzb0B6dGV1c2EuY29tIFt0c29AenRl dXNhLmNvbV0NCkRhdGUgZCdlbnZvaSA6IG1hcmRpIDE3IGF2cmlsIDIwMTIgMTg6NTUNCsOAIDog c2FyaWtheWFAaWVlZS5vcmcNCkNjIDogZm1jQGlldGYub3JnOyBmbWMtYm91bmNlc0BpZXRmLm9y ZzsgQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9OQUQvVElQDQpPYmpldCA6IFJlOiBbZm1jXSBJc3N1 ZSAjMTogSWRlbnRpZmljYXRpb24gKHdhcyBSRTogTGlzdCBkZXNjcmlwdGlvbikNCg0KRGVhciBC ZWhjZXQsDQoNCkkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KSSBzaW5jZXJlbHkgZG9u J3QgdW5kZXJzdGFuZCB3aGVyZSBhcmUgYWxsIHRoZXNlIHJlcXVpcmVtZW50cyBjb21lIGZyb20g DQp0aGUgU0RPIHdoaWNoIGFyZSBkZXZlbG9waW5nIHRoZSBGTUMgc29sdXRpb24gdG9kYXk/ICBD b3VsZCB5b3UgcGxlYXNlIA0KaWRlbnRpZnkgZm9yIHdoaWNoIFNETydzIEZNQyByZWxhdGVkIHNw ZWNpZmljYXRpb25zIG9yIExTIHRvIElFVEYgaGF2ZSANCnJlcXVlc3RlZCB0aGVzZSByZXF1aXJl bWVudHMgdG8gYmUgYWRkcmVzc2VkIGJ5IElFVEY/DQoNCkFzIGZhciBhcyBteSB1bmRlcnN0YW5k aW5nLCB0aGUgZnVuZGFtZW50YWwgY29uY2VwdCBvZiBIb3N0IElEIGhhcyBub3QgDQpiZWVuIGV2 ZW4gY29uc2lkZXJlZCBieSBvdGhlciBTRE8gKGUuZy4gM0dQUCBvciBCQkYgZXRjLikgd2hpY2gg aXMgDQpkZXZlbG9waW5nIHRoZSBGTUMgc3RhbmRhcmRzLiAgSGVuY2UsIEkgc2luY2VyZWx5IGRv bid0IHVuZGVyc3RhbmQgd2h5IA0Kd291bGQgdGhpcyBIb3N0IElEIGNvbmNlcHQgYmUgYnJvdWdo dCB1cD8NCg0KUmVnYXJkcywNClRyaWNjaQ0KDQoNCg0KDQpCZWhjZXQgU2FyaWtheWEgPHNhcmlr YXlhMjAxMkBnbWFpbC5jb20+DQpTZW50IGJ5OiBmbWMtYm91bmNlc0BpZXRmLm9yZw0KDQowNC8x Ny8yMDEyIDA5OjE0IEFNDQpQbGVhc2UgcmVzcG9uZCB0bw0Kc2FyaWtheWFAaWVlZS5vcmcNCg0K DQoNCg0KVG8NCiAgICAgICAgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KY2MNCiAgICAg ICAgImZtY0BpZXRmLm9yZyIgPGZtY0BpZXRmLm9yZz4NClN1YmplY3QNCiAgICAgICAgUmU6IFtm bWNdIElzc3VlICMxOiBJZGVudGlmaWNhdGlvbiAod2FzIFJFOiBMaXN0IGRlc2NyaXB0aW9uKQ0K DQoNCg0KDQoNCg0KDQpIaSBNZWQsDQoNCk9uIE1vbiwgQXByIDE2LCAyMDEyIGF0IDE6MzMgQU0s ICA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj4gTWVkOiBJIHdvbid0 IGFncmVlIG5vciBvYmplY3QgdGhpcyBhbmFseXNpcyBhdCB0aGlzIHN0YWdlLiBMZXQncyBmaXJz dCANCmFncmVlIG9uIHRoZSByZXF1aXJlbWVudHM7IGEgdGVudGF0aXZlIGxpc3QgaXMgcHJvdmlk ZWQgYmVsb3cuIFdlIG5lZWQgDQpwcm92aWRlIGFuc3dlcnMgdG8gdGhlc2UgcXVlc3Rpb25zOg0K Pg0KPiAoMSkgVGhlIEhPU1RfSUQgTVVTVCBiZSBzZXQgYnkgYSB0cnVzdGVkIGRldmljZTogWWVz L05vPw0KPiAoMWEpIFRoZSBSRyBNVVNUIHNldCB0aGUgSE9TVF9JRDogWWVzL05vPw0KPiAoMWIp IFRoZSBSRyBNVVNUIHN0cmlwIGFueSBleGlzdGluZyBIT1NUX0lEIHJlY2VpdmVkIGZyb20gdGhl IFVFOiANClllcy9Obz8NCj4gKDFjKSBUaGUgVUUgY2FuIHNldCB0aGUgSE9TVF9JRDogWWVzL05v Pw0KPiAoMWQpIEFuIFVwc3RyZWFtIHNlcnZpY2UgZGV2aWNlIE1VU1QgY2hlY2sgdGhlIGNvbnRl bnQgb2YgdGhlIEhPU1RfSUQ6IA0KWWVzL05vPw0KPiAoMWUpIElmIHRoZSBhbnN3ZXIgdG8gKDFk KSBpcyBZZXMsIHdoaWNoIGRldmljZT8gWHh4eHgNCj4gKDFmKSBXaGljaCBpbmZvcm1hdGlvbiBp cyB1c2VkIGJ5IHRoaXMgdXBzdHJlYW0gZGV2aWNlIHRvIGlkZW50aWZ5IHRoZSANClVFIGJlaGlu ZCB0aGUgTkFUPw0KPiAoMikgVGhlIFZpc2l0aW5nIFVFIE1VU1QgYmUgdXBkYXRlZCB0byBzdXBw b3J0IHRoZSBIT1NUX0lEOiBZZXMvTm8/DQo+ICgzKSBBbGwgcGFja2V0cyBpc3N1ZWQgZnJvbSB0 aGUgdmlzaXRpbmcgVUUgTVVTVCBjb252ZXkgdGhlIEhPU1RfSUQ6IA0KWWVzL05vPw0KPiAoM2Ep IE9ubHkgVENQIHRyYWZmaWMgaXNzdWVkIGZyb20gdGhlIHZpc2l0aW5nIFVFIE1VU1QgY29udmV5 IHRoZSANCkhPU1RfSUQ6IFllcy9Obz8NCj4gKDNiKSBPbmx5IFVEUCB0cmFmZmljIGlzc3VlZCBm cm9tIHRoZSB2aXNpb24gVUUgTVVTVCBjb252ZXkgdGhlIEhPU1RfSUQ6IA0KWWVzL05vPw0KPiAo NCkgVGhlIEhPU1RfSUQgc29sdXRpb24gTVVTVCBiZSBzcGVjaWZpYyB0byBJUHY0OiBZZXMvTm8/ DQo+ICg0YSkgVGhlIEhPU1RfSUQgc29sdXRpb24gTVVTVCBiZSB2YWxpZCB0byBJUHY2OiBZZXMv Tm8/DQo+ICg0YikgVGhlIHNhbWUgSE9TVF9JRCBzb2x1dGlvbiBNVVNUIGJlIHVzZWQgZm9yIElQ djYgYW5kIElQdjQ6IFllcy9Obz8NCj4NCg0KWWVzLCBhZ3JlZWluZyBvbiB0aGUgcmVxdWlyZW1l bnRzIChmb3IgZWFjaCBpc3N1ZSBzZXQpIGlzIGEgZ29vZCBpZGVhLg0KDQpRdWVzdGlvbiBmb3Ig Y2xhcmlmaWNhdGlvbjogYXJlIHRoZSBhYm92ZSByZWZlcnJpbmcgdG8gb25seSBTZWN0aW9ucw0K My4yLCAzLjQgYW5kIDMuNSBpbiBkcmFmdC1pZXRmLWludGFyZWEtbmF0LXJldmVhbC1hbmFseXNp cyB3aGVyZQ0KSE9TVF9JRCBpcyBzcGVjaWZpY2FsbHkgdXNlZD8NCg0KSSBndWVzcyB5b3UgbWVh biBmb3IgdGhlIHJlcXVpcmVtZW50cywgd2UgY2FuIHJlbW92ZSB0aGUgb25lcyB0aGF0IGFyZQ0K YW5zd2VyZWQgbm8/IEJ5IGNvbnNlbnN1cz8gSG93Pw0KDQpCZWhjZXQNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmbWMgbWFpbGluZyBsaXN0DQpmbWNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm1jDQoNCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUg YWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5k ZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBi eSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg aXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFp bCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBh cmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0K VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBt ZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2Yg dGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0063BDFB882579E3_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgTWVkLCA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBmb3IgeW91ciByZWZl cmVuY2UuICZuYnNwO0hvd2V2ZXIsDQp3aGVuIEkgbG9vayBhdCBzbGlkZS0xMiwgSSBkb24ndCBz ZWUgYW55IHJlcXVpcmVtZW50IHN1Z2dlc3RpbmcgdGhlIG5lZWQNCmZvciBkZWZpbmluZyBhbmQg b2J0YWluaW5nIHRoZSBIb3N0IElEIGZvciBhIGdpdmVuIFVFPyAmbmJzcDtCdWxsZXQgIzINCmJl bG93IGlzIHRvIGlkZW50aWZ5IHRoZSBVRSB3aGljaCBpcyBiYXNlZCBvbiAzR1BQIGNvbmNlcHQg YW5kIGhhdmUgdGhlaXINCm93biBzcGVjaWZpYyBpZGVudGlmaWNhdGlvbiBkZWZpbmVkIGJ5IDNH UFAuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+VGhhbmtzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VHJp Y2NpIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8L2ZvbnQ+DQo8YnI+PGltZyBzcmM9Y2lkOl8yXzBCQkYzN0U0MEJFNDY3ODQw MDYzQkIwMjg4MjU3OUUzIGFsdD0qPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj5Qcm92aWRl DQphIGRlZmluaXRpb24gb2Yg4oCcM0dQUCBVReKAnSB0byBCQkYgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBjb2xvcj0jYzIwMDAwIGZhY2U9IkFyaWFsIj7igKI8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNhbGlicmkiPnRvDQpiZSB1c2VkIGluIHRoZSBjb250ZXh0IG9mIEJCRi0zR1BQIGlu dGVyd29ya2luZyBhbmQgY29udmVyZ2VuY2U8L2ZvbnQ+DQo8YnI+PGltZyBzcmM9Y2lkOl8yXzBC QkY0M0VDMEJCRjNGRUMwMDYzQkIwMjg4MjU3OUUzIGFsdD0qPjxmb250IHNpemU9MyBmYWNlPSJD YWxpYnJpIj5FbmNvdXJhZ2UNCklFVEYgd29yayBvbiBtZWNoYW5pc21zIHRvIGVuYWJsZSBpZGVu dGlmeWluZyBpbmRpdmlkdWFsIFVFcyBiZWhpbmQgTkFUL1JHcw08L2ZvbnQ+DQo8YnI+PGltZyBz cmM9Y2lkOl8yXzBCQkY0QUQ4MEJCRjQ2QTQwMDYzQkIwMjg4MjU3OUUzIGFsdD0qPjxmb250IHNp emU9MyBmYWNlPSJDYWxpYnJpIj5FeHRlbmQNClNXYSBhbmQgU1RhIHRvIHN1cHBvcnQgZXhpc3Rp bmcgQkJGIGFjY291bnRpbmc8L2ZvbnQ+DQo8YnI+PGltZyBzcmM9Y2lkOl8yXzBCQkY0RjQ4MEJC RjRDREMwMDYzQkIwMjg4MjU3OUUzIGFsdD0qPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj5D b250aW51ZQ0Kc3R1ZHlpbmcgdGhlIGFwcGxpY2F0aW9uIG9mIFRERiBpbiBib3RoIEJCMiBhbmQg QkIzIGNvbmZpZ3VyYXRpb25zPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jYzIwMDAw IGZhY2U9IkFyaWFsIj7igKI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPlByb3Zp ZGUNCmZ1cnRoZXIgaW5mb3JtYXRpb24gb24gdGhlIFRERi1iYXNlZCBkZXBsb3ltZW50IHNjZW5h cmlvIHRvIEJCRjwvZm9udD4NCjxicj48aW1nIHNyYz1jaWQ6XzJfMEJCRjU5NjgwQkJGNTUzNDAw NjNCQjAyODgyNTc5RTMgd2lkdGg9MzggaGVpZ2h0PTUyIGFsdD0qPjxmb250IHNpemU9MyBmYWNl PSJDYWxpYnJpIj5TZW5kDQpMaWFpc29uIFN0YXRlbWVudCB0byBvdXRsaW5lIHRoZSBTYU1PRyBh cmNoaXRlY3R1cmUgdG8gQkJGIG9uY2UgaXQgaXMgc3VmZmljaWVudGx5DQpzdGFibGUgYW5kIGFz ayBmb3IgY29tbWVudHMvZmVlZGJhY2s8L2ZvbnQ+DQo8YnI+PGltZyBzcmM9Y2lkOl8yXzBCQkY1 RTMwMEJCRjVCRjAwMDYzQkIwMjg4MjU3OUUzIGFsdD0qPjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj5TZWVrDQpyZXZpZXcgZnJvbSBCQkYgYmVmb3JlIGZpbmFsIGFwcHJvdmFsIG9mIDNHUFAg c3RhZ2UtMiBhbmQgc3RhZ2UtMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPldoYXQgZG8geW91IHRoaW5rPyAmbmJzcDsgVGhhbmtzPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UcmljY2kgPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZsdDttb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4wNC8xNy8yMDEyIDEwOjA1IEFNPC9mb250Pg0KPHRkIHdpZHRo PTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7dHNvQHp0ZXVzYS5jb20m cXVvdDsgJmx0O3Rzb0B6dGV1c2EuY29tJmd0OywNCiZxdW90O3NhcmlrYXlhQGllZWUub3JnJnF1 b3Q7ICZsdDtzYXJpa2F5YUBpZWVlLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtmbWNA aWV0Zi5vcmcmcXVvdDsgJmx0O2ZtY0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJFIDogW2ZtY10gSXNzdWUgIzE6IElkZW50aWZpY2F0aW9uDQood2FzIFJFOiBMaXN0IGRlc2Ny aXB0aW9uKTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+RGVhciBUcmljY2ksPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVyIHRvIHNsaWRlIDEy IG9mIDwvZm9udD48L3R0PjxhIGhyZWY9Ind3dy4zZ3BwLm9yZy9mdHAvd29ya3Nob3AvMjAxMS0x MS0wOV8zR1BQX0JCRl9TRk8vRG9jcy8zQkYtMTEwNDYuemlwIj48dHQ+PGZvbnQgc2l6ZT0yPnd3 dy4zZ3BwLm9yZy9mdHAvd29ya3Nob3AvMjAxMS0xMS0wOV8zR1BQX0JCRl9TRk8vRG9jcy8zQkYt MTEwNDYuemlwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Ljxicj4NCjxicj4NCkNo ZWVycyw8YnI+DQpNZWQ8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KRGUgOiB0c29AenRldXNhLmNvbSBbdHNvQHp0ZXVzYS5jb21dPGJyPg0KRGF0ZSBk J2Vudm9pIDogbWFyZGkgMTcgYXZyaWwgMjAxMiAxODo1NTxicj4NCsOAIDogc2FyaWtheWFAaWVl ZS5vcmc8YnI+DQpDYyA6IGZtY0BpZXRmLm9yZzsgZm1jLWJvdW5jZXNAaWV0Zi5vcmc7IEJPVUNB REFJUiBNb2hhbWVkIE9MTkMvTkFEL1RJUDxicj4NCk9iamV0IDogUmU6IFtmbWNdIElzc3VlICMx OiBJZGVudGlmaWNhdGlvbiAod2FzIFJFOiBMaXN0IGRlc2NyaXB0aW9uKTxicj4NCjxicj4NCkRl YXIgQmVoY2V0LDxicj4NCjxicj4NCkkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZz88YnI+DQo8 YnI+DQpJIHNpbmNlcmVseSBkb24ndCB1bmRlcnN0YW5kIHdoZXJlIGFyZSBhbGwgdGhlc2UgcmVx dWlyZW1lbnRzIGNvbWUgZnJvbQ0KdGhlIFNETyB3aGljaCBhcmUgZGV2ZWxvcGluZyB0aGUgRk1D IHNvbHV0aW9uIHRvZGF5PyAmbmJzcDtDb3VsZCB5b3UgcGxlYXNlDQppZGVudGlmeSBmb3Igd2hp Y2ggU0RPJ3MgRk1DIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbnMgb3IgTFMgdG8gSUVURiBoYXZlDQpy ZXF1ZXN0ZWQgdGhlc2UgcmVxdWlyZW1lbnRzIHRvIGJlIGFkZHJlc3NlZCBieSBJRVRGPzxicj4N Cjxicj4NCkFzIGZhciBhcyBteSB1bmRlcnN0YW5kaW5nLCB0aGUgZnVuZGFtZW50YWwgY29uY2Vw dCBvZiBIb3N0IElEIGhhcyBub3QNCmJlZW4gZXZlbiBjb25zaWRlcmVkIGJ5IG90aGVyIFNETyAo ZS5nLiAzR1BQIG9yIEJCRiBldGMuKSB3aGljaCBpcyBkZXZlbG9waW5nDQp0aGUgRk1DIHN0YW5k YXJkcy4gJm5ic3A7SGVuY2UsIEkgc2luY2VyZWx5IGRvbid0IHVuZGVyc3RhbmQgd2h5IHdvdWxk DQp0aGlzIEhvc3QgSUQgY29uY2VwdCBiZSBicm91Z2h0IHVwPzxicj4NCjxicj4NClJlZ2FyZHMs PGJyPg0KVHJpY2NpPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQmVoY2V0IFNhcmlrYXlh ICZsdDtzYXJpa2F5YTIwMTJAZ21haWwuY29tJmd0Ozxicj4NClNlbnQgYnk6IGZtYy1ib3VuY2Vz QGlldGYub3JnPGJyPg0KPGJyPg0KMDQvMTcvMjAxMiAwOToxNCBBTTxicj4NClBsZWFzZSByZXNw b25kIHRvPGJyPg0Kc2FyaWtheWFAaWVlZS5vcmc8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpUbzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPGJyPg0KY2M8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 Zm1jQGlldGYub3JnJnF1b3Q7ICZsdDtmbWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZTogW2ZtY10gSXNzdWUgIzE6IElkZW50aWZp Y2F0aW9uICh3YXMgUkU6DQpMaXN0IGRlc2NyaXB0aW9uKTxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCkhpIE1lZCw8YnI+DQo8YnI+DQpPbiBNb24sIEFwciAx NiwgMjAxMiBhdCAxOjMzIEFNLCAmbmJzcDsmbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSZndDsNCndyb3RlOjxicj4NCjxicj4NCiZndDsgTWVkOiBJIHdvbid0IGFncmVlIG5vciBvYmpl Y3QgdGhpcyBhbmFseXNpcyBhdCB0aGlzIHN0YWdlLiBMZXQncyBmaXJzdA0KYWdyZWUgb24gdGhl IHJlcXVpcmVtZW50czsgYSB0ZW50YXRpdmUgbGlzdCBpcyBwcm92aWRlZCBiZWxvdy4gV2UgbmVl ZA0KcHJvdmlkZSBhbnN3ZXJzIHRvIHRoZXNlIHF1ZXN0aW9uczo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAoMSkgVGhlIEhPU1RfSUQgTVVTVCBiZSBzZXQgYnkgYSB0cnVzdGVkIGRldmljZTogWWVzL05v Pzxicj4NCiZndDsgKDFhKSBUaGUgUkcgTVVTVCBzZXQgdGhlIEhPU1RfSUQ6IFllcy9Obz88YnI+ DQomZ3Q7ICgxYikgVGhlIFJHIE1VU1Qgc3RyaXAgYW55IGV4aXN0aW5nIEhPU1RfSUQgcmVjZWl2 ZWQgZnJvbSB0aGUgVUU6DQpZZXMvTm8/PGJyPg0KJmd0OyAoMWMpIFRoZSBVRSBjYW4gc2V0IHRo ZSBIT1NUX0lEOiBZZXMvTm8/PGJyPg0KJmd0OyAoMWQpIEFuIFVwc3RyZWFtIHNlcnZpY2UgZGV2 aWNlIE1VU1QgY2hlY2sgdGhlIGNvbnRlbnQgb2YgdGhlIEhPU1RfSUQ6DQpZZXMvTm8/PGJyPg0K Jmd0OyAoMWUpIElmIHRoZSBhbnN3ZXIgdG8gKDFkKSBpcyBZZXMsIHdoaWNoIGRldmljZT8gWHh4 eHg8YnI+DQomZ3Q7ICgxZikgV2hpY2ggaW5mb3JtYXRpb24gaXMgdXNlZCBieSB0aGlzIHVwc3Ry ZWFtIGRldmljZSB0byBpZGVudGlmeQ0KdGhlIFVFIGJlaGluZCB0aGUgTkFUPzxicj4NCiZndDsg KDIpIFRoZSBWaXNpdGluZyBVRSBNVVNUIGJlIHVwZGF0ZWQgdG8gc3VwcG9ydCB0aGUgSE9TVF9J RDogWWVzL05vPzxicj4NCiZndDsgKDMpIEFsbCBwYWNrZXRzIGlzc3VlZCBmcm9tIHRoZSB2aXNp dGluZyBVRSBNVVNUIGNvbnZleSB0aGUgSE9TVF9JRDoNClllcy9Obz88YnI+DQomZ3Q7ICgzYSkg T25seSBUQ1AgdHJhZmZpYyBpc3N1ZWQgZnJvbSB0aGUgdmlzaXRpbmcgVUUgTVVTVCBjb252ZXkg dGhlDQpIT1NUX0lEOiBZZXMvTm8/PGJyPg0KJmd0OyAoM2IpIE9ubHkgVURQIHRyYWZmaWMgaXNz dWVkIGZyb20gdGhlIHZpc2lvbiBVRSBNVVNUIGNvbnZleSB0aGUgSE9TVF9JRDoNClllcy9Obz88 YnI+DQomZ3Q7ICg0KSBUaGUgSE9TVF9JRCBzb2x1dGlvbiBNVVNUIGJlIHNwZWNpZmljIHRvIElQ djQ6IFllcy9Obz88YnI+DQomZ3Q7ICg0YSkgVGhlIEhPU1RfSUQgc29sdXRpb24gTVVTVCBiZSB2 YWxpZCB0byBJUHY2OiBZZXMvTm8/PGJyPg0KJmd0OyAoNGIpIFRoZSBzYW1lIEhPU1RfSUQgc29s dXRpb24gTVVTVCBiZSB1c2VkIGZvciBJUHY2IGFuZCBJUHY0OiBZZXMvTm8/PGJyPg0KJmd0Ozxi cj4NCjxicj4NClllcywgYWdyZWVpbmcgb24gdGhlIHJlcXVpcmVtZW50cyAoZm9yIGVhY2ggaXNz dWUgc2V0KSBpcyBhIGdvb2QgaWRlYS48YnI+DQo8YnI+DQpRdWVzdGlvbiBmb3IgY2xhcmlmaWNh dGlvbjogYXJlIHRoZSBhYm92ZSByZWZlcnJpbmcgdG8gb25seSBTZWN0aW9uczxicj4NCjMuMiwg My40IGFuZCAzLjUgaW4gZHJhZnQtaWV0Zi1pbnRhcmVhLW5hdC1yZXZlYWwtYW5hbHlzaXMgd2hl cmU8YnI+DQpIT1NUX0lEIGlzIHNwZWNpZmljYWxseSB1c2VkPzxicj4NCjxicj4NCkkgZ3Vlc3Mg eW91IG1lYW4gZm9yIHRoZSByZXF1aXJlbWVudHMsIHdlIGNhbiByZW1vdmUgdGhlIG9uZXMgdGhh dCBhcmU8YnI+DQphbnN3ZXJlZCBubz8gQnkgY29uc2Vuc3VzPyBIb3c/PGJyPg0KPGJyPg0KQmVo Y2V0PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpmbWMgbWFpbGluZyBsaXN0PGJyPg0KZm1jQGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+ PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZtYz48dHQ+PGZv bnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm1jPC9mb250 PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5k ZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRo aXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5k ZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0063BDFB882579E3_=-- --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF37E40BE467840063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF43EC0BBF3FEC0063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF4AD80BBF46A40063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF4F480BBF4CDC0063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF59680BBF55340063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_= Content-Type: image/jpeg Content-ID: <_2_0BBF5E300BBF5BF00063BB02882579E3> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --=_related 0063BDFB882579E3_=-- From mohamed.boucadair@orange.com Tue Apr 17 22:40:21 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 4AD8E21F85AC for ; Tue, 17 Apr 2012 22:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 LsPh05Iu+s9D for ; Tue, 17 Apr 2012 22:40:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D926F21F85D7 for ; Tue, 17 Apr 2012 22:40:15 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0CA6C3B439D; Wed, 18 Apr 2012 07:40:14 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DF95B35C055; Wed, 18 Apr 2012 07:40:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 18 Apr 2012 07:40:13 +0200 From: To: "tso@zteusa.com" Date: Wed, 18 Apr 2012 07:40:12 +0200 Thread-Topic: RE : [fmc] Issue #1: Identification (was RE: List description) Thread-Index: Ac0cxUQ4edf/EaGuRaaq/az7b4GkJAAXtExg Message-ID: <94C682931C08B048B7A8645303FDC9F36E2891A2CB@PUEXCB1B.nanterre.francetelecom.fr> References: <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.f , In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/related; boundary="_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.18.35417 Cc: "sarikaya@ieee.org" , "fmc@ietf.org" Subject: Re: [fmc] RE : Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:40:21 -0000 --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_" --_000_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tricci, Please see inline. Cheers, Med ________________________________ De : tso@zteusa.com [mailto:tso@zteusa.com] Envoy=E9 : mardi 17 avril 2012 20:09 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : fmc@ietf.org; sarikaya@ieee.org Objet : RE : [fmc] Issue #1: Identification (was RE: List description) Dear Med, Thank you for your reference. However, when I look at slide-12, I don't se= e any requirement suggesting the need for defining and obtaining the Host I= D for a given UE? [Med] The text talks about means to identify an UE connected behind a NAT. = The text does not talk about the type of the HOST_ID, who sets the HOST_ID,= etc. This is what we are discussing here in this thread. We are trying to = understand the use cases and check what HOST_ID (as discussed in http://too= ls.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01) is suitable for= the FMC use case. Bullet #2 below is to identify the UE which is based on 3GPP concept and h= ave their own specific identification defined by 3GPP. [Med] Unless you will maintain a tunnel/session per UE, how can you identif= y an UE at the IP level (i.e., when you receive an IP packet with a source = IP address shared between the owner of the RG and visiting UEs, how you wil= l unambiguously distinguish the traffic of visiting UEs?). Thanks. Tricci >>>>> [cid:987272805@18042012-0B30]Provide a definition of "3GPP UE" to BBF *to be used in the context of BBF-3GPP interworking and convergence [cid:987272805@18042012-0B37]Encourage IETF work on mechanisms to enable id= entifying individual UEs behind NAT/RGs [cid:987272805@18042012-0B3E]Extend SWa and STa to support existing BBF acc= ounting [cid:987272805@18042012-0B45]Continue studying the application of TDF in bo= th BB2 and BB3 configurations *Provide further information on the TDF-based deployment scenario to BBF [cid:987272805@18042012-0B4C]Send Liaison Statement to outline the SaMOG ar= chitecture to BBF once it is sufficiently stable and ask for comments/feedb= ack [cid:987272805@18042012-0B53]Seek review from BBF before final approval of = 3GPP stage-2 and stage-3 >>>>> What do you think? Thanks Tricci 04/17/2012 10:05 AM To "tso@zteusa.com" , "sarikaya@ieee.org" cc "fmc@ietf.org" Subject RE : [fmc] Issue #1: Identification (was RE: List description) Dear Tricci, Please refer to slide 12 of www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_S= FO/Docs/3BF-11046.zip. Cheers, Med ________________________________________ De : tso@zteusa.com [tso@zteusa.com] Date d'envoi : mardi 17 avril 2012 18:55 =C0 : sarikaya@ieee.org Cc : fmc@ietf.org; fmc-bounces@ietf.org; BOUCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [fmc] Issue #1: Identification (was RE: List description) Dear Behcet, I must be missing something? I sincerely don't understand where are all these requirements come from the= SDO which are developing the FMC solution today? Could you please identif= y for which SDO's FMC related specifications or LS to IETF have requested t= hese requirements to be addressed by IETF? As far as my understanding, the fundamental concept of Host ID has not been= even considered by other SDO (e.g. 3GPP or BBF etc.) which is developing t= he FMC standards. Hence, I sincerely don't understand why would this Host = ID concept be brought up? Regards, Tricci Behcet Sarikaya Sent by: fmc-bounces@ietf.org 04/17/2012 09:14 AM Please respond to sarikaya@ieee.org To mohamed.boucadair@orange.com cc "fmc@ietf.org" Subject Re: [fmc] Issue #1: Identification (was RE: List description) Hi Med, On Mon, Apr 16, 2012 at 1:33 AM, wrote: > Med: I won't agree nor object this analysis at this stage. Let's first ag= ree on the requirements; a tentative list is provided below. We need provid= e answers to these questions: > > (1) The HOST_ID MUST be set by a trusted device: Yes/No? > (1a) The RG MUST set the HOST_ID: Yes/No? > (1b) The RG MUST strip any existing HOST_ID received from the UE: Yes/No? > (1c) The UE can set the HOST_ID: Yes/No? > (1d) An Upstream service device MUST check the content of the HOST_ID: Ye= s/No? > (1e) If the answer to (1d) is Yes, which device? Xxxxx > (1f) Which information is used by this upstream device to identify the UE= behind the NAT? > (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? > (3) All packets issued from the visiting UE MUST convey the HOST_ID: Yes/= No? > (3a) Only TCP traffic issued from the visiting UE MUST convey the HOST_ID= : Yes/No? > (3b) Only UDP traffic issued from the vision UE MUST convey the HOST_ID: = Yes/No? > (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? > (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? > (4b) The same HOST_ID solution MUST be used for IPv6 and IPv4: Yes/No? > Yes, agreeing on the requirements (for each issue set) is a good idea. Question for clarification: are the above referring to only Sections 3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where HOST_ID is specifically used? I guess you mean for the requirements, we can remove the ones that are answered no? By consensus? How? Behcet _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Tricci,
 
Please see inline.
Cheers,
Med

De : tso@zteusa.com=20 [mailto:tso@zteusa.com]
Envoy=E9 : mardi 17 avril 2012=20 20:09
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 fmc@ietf.org; sarikaya@ieee.org
Objet : RE : [fmc] Issue #= 1:=20 Identification (was RE: List description)

Dear Med,

Thank you for your reference.  However, when I loo= k at=20 slide-12, I don't see any requirement suggesting the need for defining an= d=20 obtaining the Host ID for a given UE?  
[Med] The text talks a= bout means=20 to identify an UE connected behind a NAT. The text does not talk about th= e=20 type of the HOST_ID, who sets the HOST_ID, etc. This is what we are discu= ssing=20 here in this thread. We are trying to understand the use cases and check = what=20 HOST_ID (as discussed in http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-01)=20 is suitable for the FMC use case.
 
 Bullet #2 below is to identify th= e UE=20 which is based on 3GPP concept and have their own specific identification= =20 defined by 3GPP.  
= [Med] Unless you will = maintain a=20 tunnel/session per UE, how can you identify an UE at the I= P=20 level (i.e., when you receive an IP packet with a source IP address share= d=20 between the owner of the RG and visiting UEs, how you will unambiguo= usly=20 distinguish the traffic of visiting UEs?).

Thanks.
Tri= cci=20
>>>>> <= BR>Provide a=20 definition of =933GPP UE=94 to BBF
=95to be used in the co= ntext of=20 BBF-3GPP interworking and convergence
3D*=20Encoura= ge IETF=20 work on mechanisms to enable identifying individual UEs behind NAT/RGs=20
3D*Extend SWa and STa to support existing BBF accounting=20
3D*Continue studying the application of TDF in both BB2 and B= B3=20 configurations
=95= Provide further information on the TDF-based depl= oyment=20 scenario to BBF
3D*Send Liaison Stateme= nt to outline=20 the SaMOG architecture to BBF once it is sufficiently stable and ask for= =20 comments/feedback
3D*=20Seek re= view from=20 BBF before final approval of 3GPP stage-2 and stage-3
>>>>>

What do you think?   Thanks
Tricci



<mohamed.boucadair@orange.com>

04/17/2012 10:05 AM

To=
"tso@zteusa.com"=20 <tso@zteusa.com>, "sarikaya@ieee.org"=20 <sarikaya@ieee.org>=20
cc=
"fmc@ietf.org"=20 <fmc@ietf.org>=20
Subject
RE : [fmc] Issue #1:=20 Identification (was RE: List=20 description)





<= TT>Dear Tricci,

Please refer to slide 12 of www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046= .zip.

Cheers,
Med
_____________________________________= ___
De=20 : tso@zteusa.com [tso@zteusa.com]
Date d'envoi : mardi 17 avril 2012=20 18:55
=C0 : sarikaya@ieee.org
Cc : fmc@ietf.org; fmc-bounces@ietf.o= rg;=20 BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [fmc] Issue #1: Identificat= ion=20 (was RE: List description)

Dear Behcet,

I must be missing=20 something?

I sincerely don't understand where are all these=20 requirements come from the SDO which are developing the FMC solution toda= y?=20  Could you please identify for which SDO's FMC related specification= s or=20 LS to IETF have requested these requirements to be addressed by=20 IETF?

As far as my understanding, the fundamental concept of Host = ID=20 has not been even considered by other SDO (e.g. 3GPP or BBF etc.) which i= s=20 developing the FMC standards.  Hence, I sincerely don't understand w= hy=20 would this Host ID concept be brought=20 up?

Regards,
Tricci




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

04/17/2012 09:14 AM
Please respond=20 to
sarikaya@ieee.org




To
     =20  mohamed.boucadair@orange.com
cc
     =20  "fmc@ietf.org" <fmc@ietf.org>
Subject
    &nb= sp;=20  Re: [fmc] Issue #1: Identification (was RE: List=20 description)







Hi Med,

On Mon, Apr 16= ,=20 2012 at 1:33 AM,  <mohamed.boucadair@orange.com> wrote:
>=20 Med: I won't agree nor object this analysis at this stage. Let's first ag= ree=20 on the requirements; a tentative list is provided below. We need provide= =20 answers to these questions:
>
> (1) The HOST_ID MUST be set b= y a=20 trusted device: Yes/No?
> (1a) The RG MUST set the HOST_ID:=20 Yes/No?
> (1b) The RG MUST strip any existing HOST_ID received from= the=20 UE: Yes/No?
> (1c) The UE can set the HOST_ID: Yes/No?
> (1d)= An=20 Upstream service device MUST check the content of the HOST_ID: Yes/No?>=20 (1e) If the answer to (1d) is Yes, which device? Xxxxx
> (1f) Which= =20 information is used by this upstream device to identify the UE behind the= =20 NAT?
> (2) The Visiting UE MUST be updated to support the HOST_ID:= =20 Yes/No?
> (3) All packets issued from the visiting UE MUST convey t= he=20 HOST_ID: Yes/No?
> (3a) Only TCP traffic issued from the visiting U= E=20 MUST convey the HOST_ID: Yes/No?
> (3b) Only UDP traffic issued fro= m the=20 vision UE MUST convey the HOST_ID: Yes/No?
> (4) The HOST_ID soluti= on=20 MUST be specific to IPv4: Yes/No?
> (4a) The HOST_ID solution MUST = be=20 valid to IPv6: Yes/No?
> (4b) The same HOST_ID solution MUST be use= d for=20 IPv6 and IPv4: Yes/No?
>

Yes, agreeing on the requirements (= for=20 each issue set) is a good idea.

Question for clarification: are th= e=20 above referring to only Sections
3.2, 3.4 and 3.5 in=20 draft-ietf-intarea-nat-reveal-analysis where
HOST_ID is specifically=20 used?

I guess you mean for the requirements, we can remove the one= s=20 that are
answered no? By consensus?=20 How?

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





----------------------------------------= ----------------
ZTE=20 Information Security Notice: The information contained in this mail is so= lely=20 property of the sender's organization. This mail communication is=20 confidential. Recipients named above are obligated to maintain secrecy an= d are=20 not permitted to disclose the contents of this communication to=20 others.
This email and any files transmitted with it are confidential = and=20 intended solely for the use of the individual or entity to whom they are= =20 addressed. If you have received this email in error please notify the=20 originator of the message. Any views expressed in this message are those = of=20 the individual sender.
This message has been scanned for viruses and S= pam=20 by ZTE Anti-Spam system.





--------=
------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail =
;communication is confidential. Recipients named a=
bove are obligated to maintain secrecy and&nb=
sp;are not permitted to disclose the contents=
 of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.
--_000_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_-- --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00001.jpg" Content-Description: ATT00001.jpg Content-Disposition: inline; filename="ATT00001.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B30> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00002.jpg" Content-Description: ATT00002.jpg Content-Disposition: inline; filename="ATT00002.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B37> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00003.jpg" Content-Description: ATT00003.jpg Content-Disposition: inline; filename="ATT00003.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B3E> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00004.jpg" Content-Description: ATT00004.jpg Content-Disposition: inline; filename="ATT00004.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B45> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00005.jpg" Content-Description: ATT00005.jpg Content-Disposition: inline; filename="ATT00005.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B4C> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_ Content-Type: image/jpeg; name="ATT00006.jpg" Content-Description: ATT00006.jpg Content-Disposition: inline; filename="ATT00006.jpg"; size=15906; creation-date="Wed, 18 Apr 2012 05:40:12 GMT"; modification-date="Wed, 18 Apr 2012 05:40:12 GMT" Content-ID: <987272805@18042012-0B53> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/4QUURXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUA AAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodp AAQAAAABAAAApAAAANAACvyAAAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTMyBXaW5kb3dz ADIwMDg6MDg6MjcgMTc6NDY6MzAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAIaADAAQAAAAB AAAAGAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEA AgAAAgEABAAAAAEAAAEuAgIABAAAAAEAAAPeAAAAAAAAAEgAAAABAAAASAAAAAH/2P/gABBKRklG AAECAABIAEgAAP/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBEL CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsN Dg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwM/8AAEQgAGAAhAwEiAAIRAQMRAf/dAAQAA//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYH CAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXi ZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIE BAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKy gwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dX Z3eHl6e3x//aAAwDAQACEQMRAD8A9VWB1HqGdY8so6jh9PYP3z6tn9vVlTP+n/XU/rE6x+2i3Lbg YUTbcdbHn/R1V/yfznuWb0/ov1ZzLHU42fdfkbd2yxw1H7wqfWzez+omSJJofnwt/lsGOMPeyGRH 9XF70If35T/VJ24X1pbX69fUmZdZEtdVoSP5DHepS/8Az1X6f9cMrG6nX03rTW7byG05bBtEu0r9 Rn0fe72bv8GqOJff9V/rJThl5PTs9/pPrJ9rLDGy1k/1q/8ArT1T/wAYlLK7GbdH+s7Ye8Oay13/ AII5N4qFi9DRB1bwxQyZDgyRxzjkxnLgz44Rwzof3P3f3X0lJedf87Os+Lkk/jDm/ccneL//0PSr elYF+QcnIpbfaQA02gPDQPza2O9rFhfXDp1eLg19XwKxVl4Ftb2emIkF7a3M2t/e3r59STJVR7/t bnK+/wC7j+bhr1cV+37Fev8AwPbfoD60/VzqPWMzCuxBW2tj22Wue4hzYj83b7vatHq/1T6T1jJb k5Ys9RsaMeWtMfvN93h+avm5JL0eq++trj974cHBf83L2/b+f2uL18b9N/sPpP8A3Gb+P96S+ZEk 7Twa367+v/zn/9n/7RfgUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAAccAgAAAgAAADhCSU0EJQAA AAAAEOjxXPMvwRihontnrcVk1bo4QklNA+0AAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQmAAAA AAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAACeOEJJTQQZAAAAAAAEAAAAHjhCSU0D8wAA AAAACQAAAAAAAAAAAQA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UA AAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAA AAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIA ADhCSU0EMAAAAAAAAQEAOEJJTQQtAAAAAAAGAAEAAAClOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJA AAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAvYAAAAIAAAAEAAAAAEAAAAAAABudWxsAAAA AwAAAAhiYXNlTmFtZVRFWFQAAAAFAFUAcwBlAHIAAAAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJj dDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAYAAAA AFJnaHRsb25nAAAAIQAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAA B3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xp Y2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAElt ZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAGAAAAABSZ2h0bG9uZwAAACEAAAADdXJsVEVYVAAAAAEA AAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAAAQAA AAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpBbGln bmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAAAA9F U2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNlQkdD b2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9uZwAA AAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAADhCSU0EKAAA AAAADAAAAAE/8AAAAAAAADhCSU0EFAAAAAAABAAAAKU4QklNBAwAAAAAA/oAAAABAAAAIQAAABgA AABkAAAJYAAAA94AGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBIgACEQEDEQH/3QAEAAP/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVVgdR6hnWPLKOo 4fT2D98+rZ/b1ZUz/p/11P6xOsftoty24GFE23HWx5/0dVf8n857lm9P6L9Wcyx1ONn3X5G3dssc NR+8Kn1s3s/qJkiSaH58Lf5bBjjD3shkR/Vxe9CH9+U/1SduF9aW1+vX1JmXWRLXVaEj+Qx3qUv/ AM9V+n/XDKxup19N601u28htOWwbRLtK/UZ9H3u9m7/BqjiX3/Vf6yU4ZeT07Pf6T6yfaywxstZP 9av/AK09U/8AGJSyuxm3R/rO2HvDmstd/wCCOTeKhYvQ0QdW8MUMmQ4Mkcc45MZy4M+OEcM6H9z9 3919JSXnX/OzrPi5JP4w5v3HJ3i//9D0q3pWBfkHJyKW32kANNoDw0D82tjvaxYX1w6dXi4NfV8C sVZeBbW9npiJBe2tzNrf3t6+fUkyVUe/7W5yvv8Au4/m4a9XFft+xXr/AMD236A+tP1c6j1jMwrs QVtrY9tlrnuIc2I/N2+72rR6v9U+k9YyW5OWLPUbGjHlrTH7zfd4fmr5uSS9Hqvvra4/e+HBwX/N y9v2/n9ri9fG/Tf7D6T/ANxm/j/ekvmRJO08Gt+u/r/85//ZOEJJTQQhAAAAAABVAAAAAQEAAAAP AEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8A cwBoAG8AcAAgAEMAUwAzAAAAAQA4QklND6AAAAAABiptb3B0AAAAAwAAAAEAAAAAAAAABwAAAAEA AAAAAAEAAP//////////AAAASwAAAAH/////AAAAAAAAAAAAAAAAAAAAAQAAAAD/////AAAAAAT/ ////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAAAAAAAAAAAAAAAAABqAAAABAAAAABAAAA AAAOVGFyZ2V0U2V0dGluZ3MAAAAKAAAAAE10dENPYmpjAAAAAQAAAAAACk5hdGl2ZVF1YWQAAAAD AAAAAEJsICBsb25nAAAA/wAAAABHcm4gbG9uZwAAAP8AAAAAUmQgIGxvbmcAAAD/AAAAAE9wdG1i b29sAQAAAABRbHR5bG9uZwAAAEsAAAALYWRkTWV0YWRhdGFib29sAQAAAApibHVyQW1vdW50ZG91 YgAAAAAAAAAAAAAAD2VtYmVkSUNDUHJvZmlsZWJvb2wAAAAACmZpbGVGb3JtYXRlbnVtAAAACkZp bGVGb3JtYXQAAAAASlBFRwAAAAxub01hdHRlQ29sb3Jib29sAAAAAAtwcm9ncmVzc2l2ZWJvb2wA AAAADHpvbmVkUXVhbGl0eU9iamMAAAABAAAAAAAJWm9uZWRJbmZvAAAABAAAAAljaGFubmVsSURs b25n/////wAAAA1lbXBoYXNpemVUZXh0Ym9vbAAAAAAQZW1waGFzaXplVmVjdG9yc2Jvb2wAAAAA BWZsb29ybG9uZwAAAAA4QklND6EAAAAABoxtc2V0AAAAEAAAAAEAAAAAAARudWxsAAAABAAAABZI VE1MQmFja2dyb3VuZFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAABgAAABNCYWNrZ3JvdW5k Q29sb3JCbHVlbG9uZwAAAP8AAAAUQmFja2dyb3VuZENvbG9yR3JlZW5sb25nAAAA/wAAABJCYWNr Z3JvdW5kQ29sb3JSZWRsb25nAAAA/wAAABRCYWNrZ3JvdW5kQ29sb3JTdGF0ZWxvbmcAAAABAAAA E0JhY2tncm91bmRJbWFnZVBhdGhURVhUAAAAAQAAAAAAFFVzZUltYWdlQXNCYWNrZ3JvdW5kYm9v bAEAAAAMSFRNTFNldHRpbmdzT2JqYwAAAAEAAAAAAARudWxsAAAAFwAAABVBbHdheXNBZGRBbHRB dHRyaWJ1dGVib29sAQAAAA1BdHRyaWJ1dGVDYXNlbG9uZwAAAAMAAAAMQ2xvc2VBbGxUYWdzYm9v bAAAAAAIRW5jb2Rpbmdsb25nAAAAAAAAABhFc2NhcGVEb3VibGVCeXRlVVJMQ2hhcnNib29sAQAA ABJGaWxlU2F2aW5nU2V0dGluZ3NPYmpjAAAAAQAAAAAABG51bGwAAAALAAAADkNvcHlCYWNrZ3Jv dW5kYm9vbAEAAAAZRHVwbGljYXRlRmlsZU5hbWVCZWhhdmlvcmxvbmcAAAABAAAAFkh0bWxGaWxl TmFtZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAACbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9u ZwAAABhsb25nAAAAGAAAABJJbWFnZVN1YmZvbGRlck5hbWVURVhUAAAABwBpAG0AYQBnAGUAcwAA AAAACkluY2x1ZGVYTVBib29sAAAAABFOYW1lQ29tcGF0aWJpbGl0eU9iamMAAAABAAAAAAAEbnVs bAAAAAMAAAANTmFtZUNvbXBhdE1hY2Jvb2wBAAAADk5hbWVDb21wYXRVTklYYm9vbAEAAAARTmFt ZUNvbXBhdFdpbmRvd3Nib29sAQAAABNPdXRwdXRNdWx0aXBsZUZpbGVzYm9vbAAAAAAYU2F2aW5n RmlsZU5hbWVDb21wb25lbnRzVmxMcwAAAAlsb25nAAAAAWxvbmcAAAAUbG9uZwAAAAJsb25nAAAA E2xvbmcAAAAGbG9uZwAAABhsb25nAAAAGGxvbmcAAAAYbG9uZwAAABYAAAAXU2xpY2VGaWxlTmFt ZUNvbXBvbmVudHNWbExzAAAABmxvbmcAAAAAbG9uZwAAABNsb25nAAAAHGxvbmcAAAAYbG9uZwAA ABhsb25nAAAAGAAAABFVc2VJbWFnZVN1YmZvbGRlcmJvb2wBAAAAEVVzZUxvbmdFeHRlbnNpb25z Ym9vbAAAAAAQR29MaXZlQ29tcGF0aWJsZWJvb2wAAAAAEEltYWdlTWFwTG9jYXRpb25sb25nAAAA AgAAAAxJbWFnZU1hcFR5cGVsb25nAAAAAAAAAA9JbmNsdWRlQ29tbWVudHNib29sAQAAABJJbmNs dWRlWmVyb01hcmdpbnNib29sAQAAAAZJbmRlbnRsb25n/////wAAAAtMaW5lRW5kaW5nc2xvbmcA AAADAAAAC091dHB1dFhIVE1MYm9vbAAAAAASUXVvdGVBbGxBdHRyaWJ1dGVzYm9vbAEAAAARU3Bh Y2Vyc0VtcHR5Q2VsbHNsb25nAAAAAAAAABFTcGFjZXJzSG9yaXpvbnRhbGxvbmcAAAAEAAAAD1Nw YWNlcnNWZXJ0aWNhbGxvbmcAAAAEAAAADFN0eWxlc0Zvcm1hdGxvbmcAAAAAAAAADVREV2lkdGhI ZWlnaHRsb25nAAAAAQAAAAdUYWdDYXNlbG9uZwAAAAMAAAAGVXNlQ1NTYm9vbAAAAAAUVXNlTG9u Z0hUTUxFeHRlbnNpb25ib29sAQAAABZNZXRhZGF0YU91dHB1dFNldHRpbmdzT2JqYwAAAAEAAAAA AARudWxsAAAABgAAAAtBZGRDdXN0b21JUmJvb2wBAAAAB0FkZEVYSUZib29sAAAAAAZBZGRYTVBi b29sAAAAABNBZGRYTVBTb3VyY2VGaWxlVVJJYm9vbAAAAAAPV3JpdGVNaW5pbWFsWE1QYm9vbAAA AAAWV3JpdGVYTVBUb1NpZGVjYXJGaWxlc2Jvb2wAAAAAB1ZlcnNpb25sb25nAAAAADhCSU0PogAA AAAACG1zNHcAAAACOEJJTQ+jAAAAAAEcbWFuaUlSRlIAAAEQOEJJTUFuRHMAAADwAAAAEAAAAAEA AAAAAABudWxsAAAAAwAAAABBRlN0bG9uZwAAAAAAAAAARnJJblZsTHMAAAABT2JqYwAAAAEAAAAA AABudWxsAAAAAwAAAABGcklEbG9uZwBAyxIAAAAARnJEbGxvbmcAAAPoAAAAAEZyR0Fkb3ViQGPA AAAAAAAAAAAARlN0c1ZsTHMAAAABT2JqYwAAAAEAAAAAAABudWxsAAAABAAAAABGc0lEbG9uZwAA AAAAAAAAQUZybWxvbmcAAAAAAAAAAEZzRnJWbExzAAAAAWxvbmcAQMsSAAAAAExDbnRsb25nAAAA AQAAOEJJTVJvbGwAAAAIAAAAAAAAAAA4QklND6QAAAAAABxtZnJpAAAAAgAAABAAAAABAAAAAAAA AAEAAAAAOEJJTQQGAAAAAAAHAAQAAAABAQD/4Q/MaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/PiA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJBZG9iZSBYTVAgQ29y ZSA0LjEtYzAzNiA0Ni4yNzY3MjAsIE1vbiBGZWIgMTkgMjAwNyAyMjo0MDowOCAgICAgICAgIj4g PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50 YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8iIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4 bWxuczpzdFJlZj0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVm IyIgeG1sbnM6dGlmZj0iaHR0cDovL25zLmFkb2JlLmNvbS90aWZmLzEuMC8iIHhtbG5zOmV4aWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8iIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeGFwOkNy ZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1MzIFdpbmRvd3MiIHhhcDpDcmVhdGVEYXRlPSIy MDA4LTA4LTI3VDE3OjQ2OjMwKzAyOjAwIiB4YXA6TW9kaWZ5RGF0ZT0iMjAwOC0wOC0yN1QxNzo0 NjozMCswMjowMCIgeGFwOk1ldGFkYXRhRGF0ZT0iMjAwOC0wOC0yN1QxNzo0NjozMCswMjowMCIg eGFwTU06RG9jdW1lbnRJRD0idXVpZDo0NDhCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg eGFwTU06SW5zdGFuY2VJRD0idXVpZDo0NThCODYzRjRGNzRERDExQjA5RkQ0NTE1OEQyQ0Q5NiIg dGlmZjpPcmllbnRhdGlvbj0iMSIgdGlmZjpYUmVzb2x1dGlvbj0iNzIwMDAwLzEwMDAwIiB0aWZm OllSZXNvbHV0aW9uPSI3MjAwMDAvMTAwMDAiIHRpZmY6UmVzb2x1dGlvblVuaXQ9IjIiIHRpZmY6 TmF0aXZlRGlnZXN0PSIyNTYsMjU3LDI1OCwyNTksMjYyLDI3NCwyNzcsMjg0LDUzMCw1MzEsMjgy LDI4MywyOTYsMzAxLDMxOCwzMTksNTI5LDUzMiwzMDYsMjcwLDI3MSwyNzIsMzA1LDMxNSwzMzQz MjszOUMxMzM4RTQ2NDk4RTM0MDdBOTUyRDQxQzRDQTI2OSIgZXhpZjpQaXhlbFhEaW1lbnNpb249 IjMzIiBleGlmOlBpeGVsWURpbWVuc2lvbj0iMjQiIGV4aWY6Q29sb3JTcGFjZT0iMSIgZXhpZjpO YXRpdmVEaWdlc3Q9IjM2ODY0LDQwOTYwLDQwOTYxLDM3MTIxLDM3MTIyLDQwOTYyLDQwOTYzLDM3 NTEwLDQwOTY0LDM2ODY3LDM2ODY4LDMzNDM0LDMzNDM3LDM0ODUwLDM0ODUyLDM0ODU1LDM0ODU2 LDM3Mzc3LDM3Mzc4LDM3Mzc5LDM3MzgwLDM3MzgxLDM3MzgyLDM3MzgzLDM3Mzg0LDM3Mzg1LDM3 Mzg2LDM3Mzk2LDQxNDgzLDQxNDg0LDQxNDg2LDQxNDg3LDQxNDg4LDQxNDkyLDQxNDkzLDQxNDk1 LDQxNzI4LDQxNzI5LDQxNzMwLDQxOTg1LDQxOTg2LDQxOTg3LDQxOTg4LDQxOTg5LDQxOTkwLDQx OTkxLDQxOTkyLDQxOTkzLDQxOTk0LDQxOTk1LDQxOTk2LDQyMDE2LDAsMiw0LDUsNiw3LDgsOSwx MCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwyMCwyMiwyMywyNCwyNSwyNiwyNywyOCwzMDtBNjY4 QkY4OEM3OTEzQThDQzg4NTlBNEVGNjUxMTRGNyIgcGhvdG9zaG9wOkNvbG9yTW9kZT0iMyIgcGhv dG9zaG9wOklDQ1Byb2ZpbGU9InNSR0IgSUVDNjE5NjYtMi4xIiBwaG90b3Nob3A6SGlzdG9yeT0i Ij4gPHhhcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InV1aWQ6MTNBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciIHN0UmVmOmRvY3VtZW50SUQ9InV1aWQ6MTJBOTVCMTU0RTcz REQxMUE4ODRBQjY1ODY2M0UyNDciLz4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94 OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1u dHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAABAAD2 1gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoA AAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1 ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAA DHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChj KSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAA AAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAA AAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAW SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNw YWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmll d2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmll dwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFz AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAA AAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCL AJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8B JQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHy AfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwAD CwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRj BHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYG FgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgL CB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQK agqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0N DSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQ JhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxOD E6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EX ZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuK G7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUg QSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4 JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsq zysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCk MNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3 JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3g PiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJF VUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0C TUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShV dVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4a XmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1n k2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6 cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7 wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZy hteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiS EZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3S nkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldo t+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE 08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4czi U+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////uAA5B ZG9iZQBkAAAAAAH/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcHDQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIABgAIQMBEQACEQEDEQH/3QAEAAX/ xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgMEBQYH CAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMWYvAk coLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1hZWl tcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp+So6 SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB0eEj QhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SUpLTE 1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/APVJNBXFWBeYfMOuzztDZ+YtH0GJdh6p Fzcf7MkpEh/yV5/6+Uy4jyIi9BpNFCIuWHNqPnjx/wCb/HL8elL49F/NKO3+u2/mSHVYGHJJLUAE jxRGEkL/AEOuQ4cg3vicyOr7PJ4J4fBl/S/30vTkggNA/ODU7DzNbeXvN8cQS9ZUstWiHpqWc0j9 RPs0dvg5Lx9Nvt/D8Syhm3otnafYGLwfH0xNR/vMUvVw/wBV65l7x7//0O5fmJLcTCOzuNVj0PRe PK5vDR55mJNI4o/Bf2nb4fi+y37NOX38Id/2NGrlCB1Gf+GP+Tx/05yY15f8lflnqtw9pYa9d3uo cC5huJFqy92ETxJzT/U/4LK44YnkS7TVdqdo6cCWTHGEP6I/38JfV/WSHSL6+/Lf8yLTSmlY+XNc mNtPbsSUhuGICSpXp9qM/wCVE/xfEmCMzGVFv7SENfpPHA/fY/4v58P6X+yj/WilP/ORFlDBcRCP 4ZvrjmIjYhZI45Wp8pGY5XmFScjsLKZaWV8uCP8ApoznD/cRV/8Ala/nH+aX7jl3iF0n8n4n/9H0 pdeVtBvNRbUL+zjvbogLGblRKsaqPsxowKpv8RNOWQMATZcuOuyxgIRkYR/oeni/rMF/ODy7b6bo dv5p0SAWuraHdW80H1dAvJXlWNk4qOjB6MP2srywrcO37I10snFgynjx5YS+v+fAccVL80/y68xe a9Z0W60tYI7aGaOe7lmkKOhFAfhCnl8IHQ4MmIykCF7O7Ux4dPPHPi4pfT/NZF5v/Kfyl5r1GLUN UFwJ46VEMxRGoAPiUhh0AFV45ZLFGRsuBpu1s+HGccSOC+Lkm3+B/Kn/AFbYv+G/rkuAOL+by97/ AP/Z --_009_94C682931C08B048B7A8645303FDC9F36E2891A2CBPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Tue Apr 17 22:43:05 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 C2EBF21F85FD for ; Tue, 17 Apr 2012 22:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.097, 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 6ww6CFaA7GTK for ; Tue, 17 Apr 2012 22:43:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFCC21F85C4 for ; Tue, 17 Apr 2012 22:43:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E279D18C468; Wed, 18 Apr 2012 07:43:01 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C9E5235C055; Wed, 18 Apr 2012 07:43:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 18 Apr 2012 07:43:01 +0200 From: To: "sarikaya@ieee.org" Date: Wed, 18 Apr 2012 07:43:00 +0200 Thread-Topic: [fmc] Issue #1: Identification (was RE: List description) Thread-Index: Ac0ctSjb6M4GsMLsQDySzoRxGTBK7wAcJSzA Message-ID: <94C682931C08B048B7A8645303FDC9F36E2891A2CE@PUEXCB1B.nanterre.francetelecom.fr> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E28919BEB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.18.35417 Cc: "fmc@ietf.org" Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:43:05 -0000 Hi Behcet, The questions below will help us to (hopefully) select the solution to reco= mmend from the list of solutions already identified in http://tools.ietf.or= g/html/draft-ietf-intarea-nat-reveal-analysis-01.=20 Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : mardi 17 avril 2012 18:14 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : fmc@ietf.org >Objet : Re: [fmc] Issue #1: Identification (was RE: List description) > >Hi Med, > >On Mon, Apr 16, 2012 at 1:33 AM, wrote: > >> Med: I won't agree nor object this analysis at this stage.=20 >Let's first agree on the requirements; a tentative list is=20 >provided below. We need provide answers to these questions: >> >> (1) The HOST_ID MUST be set by a trusted device: Yes/No? >> (1a) The RG MUST set the HOST_ID: Yes/No? >> (1b) The RG MUST strip any existing HOST_ID received from=20 >the UE: Yes/No? >> (1c) The UE can set the HOST_ID: Yes/No? >> (1d) An Upstream service device MUST check the content of=20 >the HOST_ID: Yes/No? >> (1e) If the answer to (1d) is Yes, which device? Xxxxx >> (1f) Which information is used by this upstream device to=20 >identify the UE behind the NAT? >> (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? >> (3) All packets issued from the visiting UE MUST convey the=20 >HOST_ID: Yes/No? >> (3a) Only TCP traffic issued from the visiting UE MUST=20 >convey the HOST_ID: Yes/No? >> (3b) Only UDP traffic issued from the vision UE MUST convey=20 >the HOST_ID: Yes/No? >> (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? >> (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? >> (4b) The same HOST_ID solution MUST be used for IPv6 and=20 >IPv4: Yes/No? >> > >Yes, agreeing on the requirements (for each issue set) is a good idea. > >Question for clarification: are the above referring to only Sections >3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where >HOST_ID is specifically used? > >I guess you mean for the requirements, we can remove the ones that are >answered no? By consensus? How? > >Behcet >= From Dirk.von-Hugo@telekom.de Thu Apr 19 09:01:58 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 8277E21F856A for ; Thu, 19 Apr 2012 09:01:56 -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 WdLKf3PHor8X for ; Thu, 19 Apr 2012 09:01:53 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3753D21F854F for ; Thu, 19 Apr 2012 09:01:53 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 19 Apr 2012 18:01:50 +0200 Received: from HE113675.emea1.cds.t-internal.com (10.134.99.28) by HE113472.emea1.cds.t-internal.com (10.134.93.130) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 19 Apr 2012 18:01:44 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.36]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Apr 2012 18:01:44 +0200 From: To: , Date: Thu, 19 Apr 2012 18:01:43 +0200 Thread-Topic: [fmc] Issue #1: Identification (was RE: List description) Thread-Index: Ac0ctSjb6M4GsMLsQDySzoRxGTBK7wAcJSzAAEduLzA= Message-ID: <05C81A773E48DD49B181B04BA21A342A279763F853@HE113484.emea1.cds.t-internal.com> References: <843DA8228A1BA74CA31FB4E111A5C4620248ED67@ftrdmel0.rd.francetelecom.fr> <60C093A41B5E45409A19D42CF7786DFD522EBF949C@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC7133D@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC714DC@EUSAACMS0703.eamcs.ericsson.se> <60C093A41B5E45409A19D42CF7786DFD522EC71561@EUSAACMS0703.eamcs.ericsson.se> <94C682931C08B048B7A8645303FDC9F36E2888CAEE@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F46A@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E2888CEE5@PUEXCB1B.nanterre.francetelecom.fr> <01FE63842C181246BBE4CF183BD159B42C40F758@szxeml528-mbs.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E28919BEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2891A2CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2891A2CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: fmc@ietf.org Subject: Re: [fmc] Issue #1: Identification (was RE: List description) X-BeenThere: fmc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Fixed Mobile Convergence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:01:58 -0000 Hi all, And furthermore there is the draft http://www.ietf.org/id/draft-gundavelli-= v6ops-community-wifi-svcs-03.txt addressing requirements for supporting upc= oming new Wi-Fi community services (using both operators' and residentia= ls' RGs) and mobility tools standardized in IETF that can be used for enabl= ing these architectures including macro networks. Some people including aut= hors of that draft have discussed the currently discussed requirements and = the idea of merging them with above mentioned draft. Beside that other FMC requirements or nice-to-have features such as termina= l parameters may be seen as end-to-end problems where solutions already exi= st at application level (e.g. SIP, SVC, HTTP) - without other network entit= ies in between to participate. Those issues (and whether they are out of scope here) may also be mentioned= in the to-be-written merged draft. Comments welcome! Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: fmc-bounces@ietf.org [mailto:fmc-bounces@ietf.org] Im Auftrag von moha= med.boucadair@orange.com Gesendet: Mittwoch, 18. April 2012 07:43 An: sarikaya@ieee.org Cc: fmc@ietf.org Betreff: Re: [fmc] Issue #1: Identification (was RE: List description) Hi Behcet, The questions below will help us to (hopefully) select the solution to reco= mmend from the list of solutions already identified in http://tools.ietf.or= g/html/draft-ietf-intarea-nat-reveal-analysis-01. Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >Envoy=E9 : mardi 17 avril 2012 18:14 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : fmc@ietf.org >Objet : Re: [fmc] Issue #1: Identification (was RE: List description) > >Hi Med, > >On Mon, Apr 16, 2012 at 1:33 AM, wrote: > >> Med: I won't agree nor object this analysis at this stage. >Let's first agree on the requirements; a tentative list is >provided below. We need provide answers to these questions: >> >> (1) The HOST_ID MUST be set by a trusted device: Yes/No? >> (1a) The RG MUST set the HOST_ID: Yes/No? >> (1b) The RG MUST strip any existing HOST_ID received from >the UE: Yes/No? >> (1c) The UE can set the HOST_ID: Yes/No? >> (1d) An Upstream service device MUST check the content of >the HOST_ID: Yes/No? >> (1e) If the answer to (1d) is Yes, which device? Xxxxx >> (1f) Which information is used by this upstream device to >identify the UE behind the NAT? >> (2) The Visiting UE MUST be updated to support the HOST_ID: Yes/No? >> (3) All packets issued from the visiting UE MUST convey the >HOST_ID: Yes/No? >> (3a) Only TCP traffic issued from the visiting UE MUST >convey the HOST_ID: Yes/No? >> (3b) Only UDP traffic issued from the vision UE MUST convey >the HOST_ID: Yes/No? >> (4) The HOST_ID solution MUST be specific to IPv4: Yes/No? >> (4a) The HOST_ID solution MUST be valid to IPv6: Yes/No? >> (4b) The same HOST_ID solution MUST be used for IPv6 and >IPv4: Yes/No? >> > >Yes, agreeing on the requirements (for each issue set) is a good idea. > >Question for clarification: are the above referring to only Sections >3.2, 3.4 and 3.5 in draft-ietf-intarea-nat-reveal-analysis where >HOST_ID is specifically used? > >I guess you mean for the requirements, we can remove the ones that are >answered no? By consensus? How? > >Behcet > _______________________________________________ fmc mailing list fmc@ietf.org https://www.ietf.org/mailman/listinfo/fmc