From praspati@cisco.com Fri Mar 2 04:23:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257E121F8B89 for ; Fri, 2 Mar 2012 04:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=3.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5c86oLHTKDU for ; Fri, 2 Mar 2012 04:23:25 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id D21EB21F8B88 for ; Fri, 2 Mar 2012 04:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=praspati@cisco.com; l=4391; q=dns/txt; s=iport; t=1330691005; x=1331900605; h=date:subject:from:to:cc:message-id:mime-version; bh=QrLl8OvTAfvZtJdTbS9zutMtIaHfMpFArNASHeyvH/U=; b=WTU4WGoeMpn0CYjYemI/twSKsFmTwZ930GBdQKZnmAmbRIeq+8xDhl66 7J1Hv/LTglxd3sfvXGavDFzlmXCBxwaJVjLsq/N/KT3C77udhEmXm5NHq EWEznj/Sgdx5FXLm0XPGp/yU7vCbiJFdQDz+bwDKQwpUYt7wavI83gXpj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHm7UE9Io8UY/2dsb2JhbABDglKwdIF2gX8BBBIBKjwSAQyBGgEECwMOEgeHZAugewGXFYxCgyIEiE2McJJ7 X-IronPort-AV: E=Sophos;i="4.73,517,1325462400"; d="scan'208,217";a="6995368" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 02 Mar 2012 12:23:23 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q22CNNbW007780 for ; Fri, 2 Mar 2012 12:23:23 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 17:53:22 +0530 Received: from 10.21.112.250 ([10.21.112.250]) by XMB-BGL-41B.cisco.com ([72.163.129.217]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Mar 2012 12:23:22 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 02 Mar 2012 17:53:19 +0530 From: Prashanth Patil To: Message-ID: Thread-Topic: I-D Action: draft-rpcw-pcp-pmipv6-serv-discovery-00.txt Thread-Index: Acz4b0BB/D87VUu+yUqjL93E+swtug== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413555600_160234" X-OriginalArrivalTime: 02 Mar 2012 12:23:22.0979 (UTC) FILETIME=[42A0BB30:01CCF86F] Cc: "Ravikumar Chandrasekaran \(sravikum\)" , "Tirumaleswar Reddy \(tireddy\)" Subject: [pcp] I-D Action: draft-rpcw-pcp-pmipv6-serv-discovery-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:23:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413555600_160234 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6 Author(s) : Tirumaleswar Reddy Prashanth Patil Ravikumar Chandrasekaran Dan Wing Filename : draft-rpcw-pcp-pmipv6-serv-discovery-00.txt Pages : 13 Date : 2012-02-29 This document proposes a solution to PCP Server Discovery problems in Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic and traffic off-loaded to local access network require traversing a gateway implementing NAT and/or Firewall. This draft proposes enhancements to DHCPv4 Relay Agent by introducing a new sub-option under DHCPv4 Relay Option and to PMIPv6 signaling through additional options to Proxy Binding Update/Acknowledgement messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discovery-00. txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discovery-00.t xt --B_3413555600_160234 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable I-D Action: draft-rpcw-pcp-pmipv6-serv-discovery-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directo= ries.

 Title           : P= CP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6
 Author(s)       : Tirumaleswar Reddy             &nb= sp;            &= nbsp;Prashanth Patil
            &nb= sp;            &= nbsp;Ravikumar Chandrasekaran
            &nb= sp;            &= nbsp;Dan Wing
 Filename        : draft-rpcw-pcp-p= mipv6-serv-discovery-00.txt
 Pages           : 1= 3
 Date           &nbs= p;: 2012-02-29

   This document proposes a solution to PCP Server Discovery= problems in
   Proxy Mobile IPv6 (PMIPv6) networks when both home networ= k traffic
   and traffic off-loaded to local access network require tr= aversing a
   gateway implementing NAT and/or Firewall.  This draf= t proposes
   enhancements to DHCPv4 Relay Agent by introducing a new s= ub-option
   under DHCPv4 Relay Option and to PMIPv6 signaling through= additional
   options to Proxy Binding Update/Acknowledgement messages.=


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-ser= v-discovery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-= discovery-00.txt

 --B_3413555600_160234-- From phdgang@gmail.com Mon Mar 5 01:36:19 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0D421F86F8 for ; Mon, 5 Mar 2012 01:36:19 -0800 (PST) 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 OuIdh1sf+PId for ; Mon, 5 Mar 2012 01:36:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD17221F8639 for ; Mon, 5 Mar 2012 01:36:18 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so2284333wgb.13 for ; Mon, 05 Mar 2012 01:36:18 -0800 (PST) Received-SPF: pass (google.com: domain of phdgang@gmail.com designates 10.216.85.81 as permitted sender) client-ip=10.216.85.81; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phdgang@gmail.com designates 10.216.85.81 as permitted sender) smtp.mail=phdgang@gmail.com; dkim=pass header.i=phdgang@gmail.com Received: from mr.google.com ([10.216.85.81]) by 10.216.85.81 with SMTP id t59mr5858232wee.28.1330940178049 (num_hops = 1); Mon, 05 Mar 2012 01:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gAEXi0nFqpryo9rzZkdtcBXuzLoo6B+vULOCl0viwHk=; b=oghFkObVcP3UG3uIakdmaSwpjZSYK3HOOOuTAECx5uhGevMYgwoDiKvg4qafvBgdin awczePiHocJRJufNCnlepBBlVdomhq9MJss3e1ij33tQ6u3Mc/FGkY6PCb7Wz2J4nEgj RfA+RdSrR7xKSCIU/KKFx0+wYTrcEqwPUN1XlveKBj/jw42qQ7RFuXaCTfufRWmBC4tr PKYM/j/FN+XGHXBsn0i6ZSBlpC0N6owT0QBxY8TOBhfwMEY8g0iTFBZ37DIhfKZM3VQD /VgXwnPVqrbZuATHA0F89NVxZN4BTAnGuryUVi2cpCXdRUNyUvfUnbtWqcW988rY75AZ vcOw== MIME-Version: 1.0 Received: by 10.216.85.81 with SMTP id t59mr4699996wee.28.1330940177953; Mon, 05 Mar 2012 01:36:17 -0800 (PST) Received: by 10.180.7.105 with HTTP; Mon, 5 Mar 2012 01:36:17 -0800 (PST) In-Reply-To: <20120305092927.24393.27105.idtracker@ietfa.amsl.com> References: <20120305092927.24393.27105.idtracker@ietfa.amsl.com> Date: Mon, 5 Mar 2012 17:36:17 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [pcp] Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:36:19 -0000 Hello All, We have submitted a draft trying to share some deployment considerations in mobile network environment. Your comments are appreciated A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cases Study- PCP Deployment in Mobile Network Author(s) : Gang Chen Zhen Cao Filename : draft-chen-pcp-mobile-deployment-00.txt Pages : 10 Date : 2012-03-05 This memo provided two cases study, when PCP is deployed in mobile network. Some motivation of deployment PCP in mobile network was described and justification for each deployment case was stated. Corresponding to each mode, the document discussed some features to address operational issues. That might potentially cause some extension on PCP protocol level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-pcp-mobile-deployment-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-chen-pcp-mobile-deployment-00.txt Many thanks Gang From fred@cisco.com Wed Mar 7 22:29:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C3921F869C for ; Wed, 7 Mar 2012 22:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.886 X-Spam-Level: X-Spam-Status: No, score=-108.886 tagged_above=-999 required=5 tests=[AWL=1.713, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 pIrmclvH6o+F for ; Wed, 7 Mar 2012 22:29:15 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3721F8697 for ; Wed, 7 Mar 2012 22:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=71; q=dns/txt; s=iport; t=1331188155; x=1332397755; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=ADGBeJ8UndhN1WUVk9gbB56pRaPEwU2zT6oZgc+E9a4=; b=dVMpGn0QA3m6b/RFDVeqXE0lVN7NXL/km3Y1aWWG6lzEi/8qsJZaQSaH buFkzxiSNr+C8IiysTuJHaUHgGMxmQ46U4r7Vw6FXJSsAF7VjWRmLdva6 HE7s2U04fn0p9HqmW6+0Q0JkXTYrsTAEhPZYZZGappUI0ZwsMdL0WrVAf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAFlRWE+rRDoG/2dsb2JhbABDtSuBB4IjASc/gXOHZZsBAZ8UjUyCP2MEiFCMcYVkijOCcg X-IronPort-AV: E=Sophos;i="4.73,550,1325462400"; d="scan'208";a="34969155" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Mar 2012 06:29:15 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-56.cisco.com [10.70.231.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q286TBaF021953; Thu, 8 Mar 2012 06:29:14 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 15:29:15 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 15:29:15 +0900 From: Fred Baker Date: Thu, 8 Mar 2012 12:29:18 +0900 Message-Id: <831F9510-774B-4A94-8CD9-94D9709CC278@cisco.com> To: pcp-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: [pcp] draft-baker-pcp-nptv6-search-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:29:16 -0000 Dan or I would appreciate an opportunity to discuss this with the WG. From mohamed.boucadair@orange.com Fri Mar 9 05:13:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C13821F8674 for ; Fri, 9 Mar 2012 05:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 e5wRnvOF3inQ for ; Fri, 9 Mar 2012 05:12:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1517421F8668 for ; Fri, 9 Mar 2012 05:12:55 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D9D2A18C469; Fri, 9 Mar 2012 14:12:54 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C155E35C135; Fri, 9 Mar 2012 14:12:54 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 9 Mar 2012 14:12:54 +0100 From: To: Dan Wing Date: Fri, 9 Mar 2012 14:12:52 +0100 Thread-Topic: [pcp] [I-D.ietf-pcp-upnp-igd-interworking] Issue #1: Get a Mapping Thread-Index: AcyunXsGylfp70Z1SX+rR6zeaXvK7gBGheOgE48uDHA= Message-ID: <94C682931C08B048B7A8645303FDC9F36748BC50FD@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F35A8D050CE2@PUEXCB1B.nanterre.francetelecom.fr> <0d7d01ccb124$397b6970$ac723c50$@com> In-Reply-To: <0d7d01ccb124$397b6970$ac723c50$@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: 2011.1.19.234517 Cc: "pcp@ietf.org" Subject: Re: [pcp] [I-D.ietf-pcp-upnp-igd-interworking] Issue #1: Get a Mapping X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:13:04 -0000 Hi Dan, Please see inline. Cheers, Med=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com]=20 > Envoy=E9 : vendredi 2 d=E9cembre 2011 19:57 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org > Objet : RE: [pcp] [I-D.ietf-pcp-upnp-igd-interworking] Issue=20 > #1: Get a Mapping >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 > Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, November 29, 2011 5:48 AM > > To: pcp@ietf.org > > Subject: [pcp] [I-D.ietf-pcp-upnp-igd-interworking] Issue #1: Get a > > Mapping > >=20 > > Dear all, > >=20 > > Context: To list active mappings, an UPnP Control Point=20 > may issue > > GetGenericPortMappingEntry(), GetSpecificPortMappingEntry() or > > GetListOfPortMappings(). > >=20 > > Issue: In the current version of the I-D, these methods are not > > relayed to the PCP Server but are handled according to the > > content > > of the local mapping table: > >=20 > > Drawback: The answer to Get* may not be accurate=20 > since the IWF > > has only a local knowledge of the global mapping table > .............................................^^^^^^ > "home gateway's local", I think=20 > you meant? Med: No, by "global" I meant the full table as maintained by the PCP-contro= lled device.=20 >=20 >=20 > > Some applications issue first Get* to check=20 > whether a port is > > in use or not before sending Add*. e.g., Microtorrent > > (uTorrent) v2.2 calls GetSpecificPortMapping until=20 > it finds an > > external available port, and then calls AddPortMapping(). >=20 > To mimic that functionality, the UPnP IGD->PCP interworking function > can do a MAP request with the PREFER_FAILURE option. Does that not > work? Med: Yes, this is indeed an option. Should I understand that your answer fo= r my question below is: * Ok to relay Get* to MAP? >=20 > > Question for the WG: Do we allow relaying Get* to a PCP > > request (MAP or GET)? > >=20 > > + No GET method is currently defined in the base PCP > >=20 > > + GET is an extension defined in=20 > I-D.boucadair-pcp-failure. >=20 > I don't see how GET solves the problem, especially considering > there is a race condition between when GET is issued and when > an actual subsequent mapping might be performed. In that time, > which I admit is quite small, an implicit dynamic mapping (e.g., > TCP SYN) or explicit dynamic mapping could occur, effectively > "stealing" the port that was available, just moments ago. Med: Agreed. (the comment applies also for the MAP with very short lifetime= ; but I don't think LT of 1s will be used) Unless there is an objection, I will update the text to reflect that GetSpe= cificPortMappingEntry is relayed to a MAP request with short lifetime (e.g.= , 1mn) and PREFERE_FAILURE Option. =20 From internet-drafts@ietf.org Mon Mar 12 08:14:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3821F87E0; Mon, 12 Mar 2012 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 4fD6hEGBwX03; Mon, 12 Mar 2012 08:14:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98821F87D4; Mon, 12 Mar 2012 08:14:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312151401.29965.3871.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 08:14:01 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:14:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group o= f the IETF. Title : Universal Plug and Play (UPnP) Internet Gateway Device (= IGD)-Port Control Protocol (PCP) Interworking Function Author(s) : Mohamed Boucadair Francis Dupont Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-upnp-igd-interworking-01.txt Pages : 24 Date : 2012-03-12 This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP is used in the LAN side and PCP in the external side of the CP router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-upnp-igd-interworking-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-upnp-igd-interworking-01.= txt From mohamed.boucadair@orange.com Mon Mar 12 08:22:40 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC93A21F8849 for ; Mon, 12 Mar 2012 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 YBwbfiXirQFG for ; Mon, 12 Mar 2012 08:22: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 0524F21F8848 for ; Mon, 12 Mar 2012 08:22:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CD78D3242C2 for ; Mon, 12 Mar 2012 16:22:38 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9C1BC35C0CC for ; Mon, 12 Mar 2012 16:22:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 12 Mar 2012 16:22:38 +0100 From: To: "pcp@ietf.org" Date: Mon, 12 Mar 2012 16:22:36 +0100 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-01.txt Thread-Index: Ac0AYsLw6fgo2fSLTfehYb1FU6/EkQAAChrQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E281DB0F3@PUEXCB1B.nanterre.francetelecom.fr> References: <20120312151401.29965.3871.idtracker@ietfa.amsl.com> In-Reply-To: <20120312151401.29965.3871.idtracker@ietfa.amsl.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.12.71225 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:22:40 -0000 Dear all, Changes in this new version are as follows:=20 * Record the feedback received for the 3 issues raised in the mailing list: (1) http://www.ietf.org/mail-archive/web/pcp/current/msg01805.html (2) http://www.ietf.org/mail-archive/web/pcp/current/msg01806.html=20 (3) http://www.ietf.org/mail-archive/web/pcp/current/msg01807.html * Add text to specify the behaviour when receiving GetSpecificPortMappingEn= try * Remove discussion about state synchronisation and avalanche restart since= these issues are not specific to the IWF and would apply to other scenario= s (e.g., web-based PCP Client in the CPE) * For short lifetime errors, the IWF may resent the same request before not= ifying the UPnP CP A diff is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp= -upnp-igd-interworking-01. Comments are welcome. Cheers, Med > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 > part de internet-drafts@ietf.org > Envoy=E9 : lundi 12 mars 2012 16:14 > =C0 : i-d-announce@ietf.org > Cc : pcp@ietf.org > Objet : [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > Port Control Protocol Working Group of the IETF. >=20 > Title : Universal Plug and Play (UPnP)=20 > Internet Gateway Device (IGD)-Port Control Protocol (PCP)=20 > Interworking Function > Author(s) : Mohamed Boucadair > Francis Dupont > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-upnp-igd-interworking-01.txt > Pages : 24 > Date : 2012-03-12 >=20 > This document specifies the behavior of the UPnP IGD (Internet > Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP > Interworking Function (IGD-PCP IWF) is required to be=20 > embedded in CP > routers to allow for transparent NAT control in environments where > UPnP is used in the LAN side and PCP in the external side of the CP > router. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcp-upnp-igd-in > terworking-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-upnp-igd-int > erworking-01.txt >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > = From dwing@cisco.com Mon Mar 12 15:17:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4A21E8151 for ; Mon, 12 Mar 2012 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.992 X-Spam-Level: X-Spam-Status: No, score=-108.992 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 BsOlg3++Kg4L for ; Mon, 12 Mar 2012 15:17:49 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6321E8150 for ; Mon, 12 Mar 2012 15:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1469; q=dns/txt; s=iport; t=1331590666; x=1332800266; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=0758OYc1TGX32ZZeFfHxvoMmr8zWKjrYs9Jbauv4WNM=; b=gpgDCN3csuk7oIKQymaQuN3ak5L3MZm3ZskGHk0k85brPGaNJ0ZxJXWF y8tmpNWY6EmnAuvtrwpdAUP+mOsEcMzvb4zCd/aRFw/UcI/dg11mjrFds FWhh2/k/+uysZ76WOyy+bjZ5QS37+9PO6/YBKePZORqjN7m2z4XGUduRd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMp0Xk+rRDoJ/2dsb2JhbABDpWyPaYEHggkBAQEECAoBFxBLAQMCCQ4BAgQBASgHGQgbCgkIAQEEARILF4dnnRMBnwOJRGOGWgSIVIUPkxSEeIMDgTU X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="35808784" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 12 Mar 2012 22:17:46 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CMHj6t009175; Mon, 12 Mar 2012 22:17:46 GMT From: "Dan Wing" To: "'Xiaohong Deng'" , References: In-Reply-To: Date: Mon, 12 Mar 2012 15:17:45 -0700 Message-ID: <055e01cd009d$f3adc6d0$db095470$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczvpnE3FTe0LfT/Q+SZYMbDwmmr8QQ93flQ Content-Language: en-us Subject: Re: [pcp] Do it differently when PCP response would have exceeded the maximum PCP message size? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:17:53 -0000 I didn't see any followups on this suggestion to create a new error code (e.g., RESPONSE_TOO_BIG), so I will leave the text as-is. -d > -----Original Message----- > From: Xiaohong Deng [mailto:dxhbupt@gmail.com] > Sent: Monday, February 20, 2012 12:06 AM > To: pcp@ietf.org; dwing@cisco.com > Subject: Do it differently when PCP response would have exceeded the > maximum PCP message size? > > In the -23, it suggests in page 17 that: > > > > > > If a PCP response would have exceeded the maximum PCP message size, > > the PCP server SHOULD respond with MALFORMED_REQUEST. > > > > > While MALFORMED_REQUEST means the request could not be successfully > parsed, yet the scenario that text here is trying to describe > (explained by Dan): > > > > > 1. a request arrives, and has two fancy new PCP Options, one says "tell > me > > the human-assigned name for this mapping", and the other says "tell > > me the manufacturer and version of the PCP server" > > 2. the human-assigned name is 1000 bytes, and the manufacturer name is > > 50 bytes. > > 3. the response is built but its length exceeds the 1024 maximum > > size allowed. > > > > > How about do something differently than MALFORMED_REQUEST? For example, > define a new error code for the sake of accuracy or simply truncate the > > response at 1024 bytes to fit? > > > > > > > > Cheers, > > Xiaohong From internet-drafts@ietf.org Mon Mar 12 16:13:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80421E81DD; Mon, 12 Mar 2012 16:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ByeoPIS8pZSD; Mon, 12 Mar 2012 16:13:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944B121E81D9; Mon, 12 Mar 2012 16:13:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312231303.7910.49920.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:13:03 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-24.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:13:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group o= f the IETF. Title : Port Control Protocol (PCP) Author(s) : Dan Wing Stuart Cheshire Mohamed Boucadair Reinaldo Penno Paul Selkirk Filename : draft-ietf-pcp-base-24.txt Pages : 97 Date : 2012-03-12 The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-24.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base-24.txt From dwing@cisco.com Tue Mar 13 17:03:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BC221E8071 for ; Tue, 13 Mar 2012 17:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.078 X-Spam-Level: X-Spam-Status: No, score=-109.078 tagged_above=-999 required=5 tests=[AWL=1.521, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QPx31q99Am78 for ; Tue, 13 Mar 2012 17:03:10 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BF0CB21E8013 for ; Tue, 13 Mar 2012 17:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5124; q=dns/txt; s=iport; t=1331683390; x=1332892990; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=QJCxBbqcbQjBSM+yJKOWPtRkfX8OogPymVv7OGBskrE=; b=S6dpiuG20ypxY1e2A6d++Vd4VuOkQlCB1+bAbNnFPCoce493dTY+lZlh 3Jog/QQthAnC7nyFiiY+UBmaLn4z14IM6fJTnX8eCY0ZTA214+3XQdfhx KDGpE7+KEdHhBl8ZU0roTZpge1avTRTNUPmAym5MYieks5eYN0239rxxu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACTfX0+rRDoG/2dsb2JhbABDpguPZIEHghAICgEXEDQYBRhQIxwBBB4Xh2cMmxSBJwGedIotD4Y6BIhVhRKYDIMFgTUB X-IronPort-AV: E=Sophos;i="4.73,580,1325462400"; d="scan'208";a="35895459" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2012 00:03:10 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2E03Ap5009317 for ; Wed, 14 Mar 2012 00:03:10 GMT From: "Dan Wing" To: Date: Tue, 13 Mar 2012 17:03:10 -0700 Message-ID: <0a5801cd0175$d7e7da70$87b78f50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Bddeh2O0nidefSoKLton7Tr/2oA== Content-Language: en-us Subject: [pcp] draft-ietf-pcp-base-24 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 00:03:11 -0000 Hi, everyone. Yesterday I submitted draft-ietf-pcp-base-24, which I believe resolves the DISCUSS and COMMENTS from IESG members, https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ballot, as well as reviews from TSV, SEC, and APP directorate, and comments on the PCP mailing list. The changes are summarized in http://tools.ietf.org/html/draft-ietf-pcp-base-24#appendix-B.1 (and copied below), and side-by-side differences from -23 are available at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-24.txt Please review the changes. I know the list of changes is long, but few of the changes are normative changes to the protocol itself. One additional change, which did not make it to -24, will be clarification of port 5350 versus port 5351 usage when the server sends unsolicited ANNOUNCE message. These are always sent to port 5351. (Version -23 and -24 has conflicting text about the port when the server sends unsolicited unicast versus multicast ANNOUNCE message). Thanks to Ralph Droms for catching that during his IESG review. This change will be published in -25, if we publish one, or will be incorporated when the RFC Editor does their editing. -d ----- o Explained common questions regarding PCP's design, such as lack of transction identifiers and its request/response semantics and operation (Protocol Design Note (Section 6)). o added MUST for all-zeros IPv6 and IPv4 address formats. o included field definitions for Opcode-specific information and PCP options under both Figure 2 and Figure 3. o adopted retransmission mechanism from DHCPv6. o 1024 message size limit described in PCP message restriction. o Explained PCP server list, with example of host with IPv4 and IPv6 addresses having two PCP servers (one IPv4 PCP server for IPv4 mappings and one IPv6 PCP server for IPv6 mappings). o mention PCP client needs to expect unsolicited PCP responses from previous incarnations of itself (on the same host) or of this host (using same IP address as another PCP client). o eliminated overuse of 'packet format' when it was 'opcode format'. o for IANA registries, added code points assignable via Standards Action (previously was just Specification Required). o Version negotiation, added explanation that retrying after 30 minutes makes the protocol self-healing if the PCP server is upgraded. o Version negotiation now accomodates non-contiguous version numbers. o Tweaked definition of VERSION field (that "1" is for this version, but other values could of course appear in the future). o when receiving unsolicited ANNOUNCE, PCP client now waits random 0-5 seconds. o Removed 'interworking function' from list of terminology because we no longer use the term in this document. o tightened definitions of 'PCP client' and 'PCP server'. o For 'Requested Lifetime' definitions, removed text requiring its value be 0 for not-yet-defined opcodes. o Removed some unnecessary text suggesting logging (is an implementation detail). o Added active-mode FTP as example protocol that can break with mappings to different IP addresses. o Clarified that if PCP request contains a Suggested External Address, the PCP server should try to create a mapping to that address even if other mappings already exist to a different external address. o Changed "internal address and port" to "internal address, protocol, and port" in several places. o Clarified which 96 bits are copied into error response. Clarified that only error responses are copied verbatim from request. o a single PCP server can control multiple NATs or multiple firewalls (Section 4). o Clarified that sending unsolicited multicast ANNOUNCE is not always available on all networks. o Clarified option length error example is when option length exceeds UDP length o Explained that an on-path attacker that can spoof packets can re- direct traffic to a host of their choosing. o Instead of saying IPv4-mapped addresses won't appear on the wire, say they aren't used for mappings. o THIRD_PARTY is useful for management device (e.g., in a network operations center). o Clarified PCP responses have fields updated as indicated with 'set by the server' from field definitions. o Disallow using MAP to the PCP ports themselves and encourage implementations have policy control for other ports. o Instead of 'idempotent', now says 'identical requests generate identical response'. o Described which Options are included when sending Mapping Update (unsolicited responses), Section 14.2. o Dropped [RFC2136] and [RFC3007] to informative references. o Updated from 'should' to 'SHOULD' in Section 16.1. o Described 'hairpin' in terminology section. From bingxuere@gmail.com Mon Mar 19 07:37:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16BF21F8862 for ; Mon, 19 Mar 2012 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 I9wDBy7lF0ie for ; Mon, 19 Mar 2012 07:37:46 -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 1C06D21F885F for ; Mon, 19 Mar 2012 07:37:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so11337258iaz.31 for ; Mon, 19 Mar 2012 07:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=GFsXv5V3xJSayTUwtJmDq39KsqjCwvjR4PPzvWNF+Mo=; b=UCVlHIaDSaOYxKIgjFQxX7hiAAwMsZvZkLrcfjozJzn+M+X1Ue2zlVXX0wbBT7Kcbs kxWfKgjehonq4KYIWcdbhsndAtA4Uf+bwnTNhPeoUFA/D6stKKz6JbAqNR4GGU+3Fge0 VfpET/HVraYybehnWnWDnTQh9JoyPa39unBr1wAGU9BIjVXbXVbpZFLaTSP51+K9nvKm rHsed+Hfi4WoTPYkh6UZLCh56zlCRkkGWNyiGUtHuj6/2h7W1a2UNT4mykfp4Ii1u9em lz1SVGdlGWjlfB6hb4gMST8EXuZMc6kBqggS9TgmzVif3I4wP/qzPNLHZvikrF4ENpvM Xtlg== Received: by 10.50.194.233 with SMTP id hz9mr6207702igc.11.1332167865697; Mon, 19 Mar 2012 07:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.226.2 with HTTP; Mon, 19 Mar 2012 07:37:03 -0700 (PDT) From: Qiong Date: Mon, 19 Mar 2012 22:37:03 +0800 Message-ID: To: pcp@ietf.org Content-Type: multipart/alternative; boundary=14dae9340c7d6a83b304bb9980bc Subject: [pcp] FW: New Version Notification for draft-tsou-pcp-natcoord-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:37:47 -0000 --14dae9340c7d6a83b304bb9980bc Content-Type: text/plain; charset=UTF-8 Dear all, We have submitted a new version of pcp-natcoord which extends PCP with the ability to reserve port set instead of individual mapping. Your comments are appreciated. Thanks in advance! A new version of I-D, draft-tsou-pcp-natcoord-05.txt has been successfully submitted by Cathy Zhou and posted to the IETF repository. Filename: draft-tsou-pcp-natcoord Revision: 05 Title: Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 11 Abstract: This document defines an extension to the base PCP. New OpCode and Options are defined to enhance PCP with the ability to reserve port sets for internal hosts. A URL for this Internet-Draft is: http://tools.ietf.org/id/draft-tsou-pcp-natcoord-05.txt Best wishes Qiong --14dae9340c7d6a83b304bb9980bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have submitted a new version of pcp-natcoord which exte= nds PCP with the ability to reserve port set instead of individual mapping.= Your comments are appreciated. Thanks in advance!

A new version of = I-D, draft-tsou-pcp-natcoord-05.txt has been successfully submitted by Cath= y Zhou and posted to the IETF repository.

Filename:=C2=A0=C2=A0=C2=A0 =C2=A0draft-tsou-pcp-natcoord
Revision:= =C2=A0=C2=A0=C2=A0 =C2=A005
Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0Using PCP To Coordinate Between the CGN and Home Gateway Via Port All= ocation
Creation date:=C2=A0=C2=A0=C2=A0 =C2=A02012-03-13
WG ID:=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0Individual Submission
Number of pages: 11

Abstract:
=C2=A0=C2=A0 This document defines = an extension to the base PCP.=C2=A0 New OpCode and
=C2=A0=C2=A0 Options = are defined to enhance PCP with the ability to reserve port
=C2=A0=C2=A0= sets for internal hosts.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

A URL for this Internet-Draft is:
http://tools.ietf.org/id/draft-tsou-pcp-n= atcoord-05.txt


Best wishes

Qiong


--14dae9340c7d6a83b304bb9980bc-- From bingxuere@gmail.com Mon Mar 19 07:39:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0321F86F6 for ; Mon, 19 Mar 2012 07:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 TUKjWTM1596u for ; Mon, 19 Mar 2012 07:39:01 -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 8E62B21F86E3 for ; Mon, 19 Mar 2012 07:39:01 -0700 (PDT) Received: by iazz13 with SMTP id z13so11338931iaz.31 for ; Mon, 19 Mar 2012 07:39:01 -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 :content-type; bh=huZJLdodFhzu+Up8iPmnS7AkQhkLIh+AXLPhB+m3u8M=; b=TBUiAzaKDyaEhgcyS0g8oDb6Tv1Nh4aoJClbun5koWJov7QhxvhfjLcyX9VsHOkZ1Y efLzaMUVNNsJzEd53aUe2urwjjS9E2jMW3+NvZPXzlowU9BkczLhu72tRr5mP6LXwiMz a60VEXAX/DRPDqcyZ0QNoRmXn6hitAEGFYLNBrqJwR6naikfA99XfcFlKEk3/bLheAJg Kj0IV/K7h96HNHCG+kx+YDpAea5Lg9RZPfJfoe5jaUsJIEgNOsjpJhda8UFM8lmiCVMD dIo+sIhhftbpHfzVO9McGvGcUTfeoPvltBBKQ7lwpwd9YWiCq9+IWaTQrgMsg/ZZDBVZ LaaQ== Received: by 10.50.181.164 with SMTP id dx4mr2678415igc.1.1332167941274; Mon, 19 Mar 2012 07:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.226.2 with HTTP; Mon, 19 Mar 2012 07:38:20 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Mon, 19 Mar 2012 22:38:20 +0800 Message-ID: To: pcp@ietf.org Content-Type: multipart/alternative; boundary=14dae934097bebba8c04bb99843d Subject: [pcp] Fwd: New Version Notification for draft-tsou-pcp-natcoord-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:39:02 -0000 --14dae934097bebba8c04bb99843d Content-Type: text/plain; charset=UTF-8 Dear all, We have submitted a new version of pcp-natcoord which extends PCP with the ability to reserve port set instead of individual mapping. Your comments are appreciated. Thanks in advance! A new version of I-D, draft-tsou-pcp-natcoord-05.txt has been successfully submitted by Cathy Zhou and posted to the IETF repository. Filename: draft-tsou-pcp-natcoord Revision: 05 Title: Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 11 Abstract: This document defines an extension to the base PCP. New OpCode and Options are defined to enhance PCP with the ability to reserve port sets for internal hosts. A URL for this Internet-Draft is: http://tools.ietf.org/id/draft-tsou-pcp-natcoord-05.txt Best wishes Qiong --14dae934097bebba8c04bb99843d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

We have submitted a new version= of pcp-natcoord which extends PCP with the ability to reserve port set ins= tead of individual mapping. Your comments are appreciated. Thanks in advanc= e!

A new version of I-D, draft-tsou-pcp-natcoord-05.txt has been successfu= lly submitted by Cathy Zhou and posted to the IETF repository.

Filename:=C2=A0=C2=A0=C2=A0 =C2=A0draft-tsou-pcp-natcoord
Revision:= =C2=A0=C2=A0=C2=A0 =C2=A005
Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0Using PCP To Coordinate Between the CGN and Home Gateway Via Port All= ocation
Creation date:=C2=A0=C2=A0=C2=A0 =C2=A02012-03-13
WG ID:=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0Individual Submission
Number of pages: 11

Abstract:
=C2=A0=C2=A0 This document defines = an extension to the base PCP.=C2=A0 New OpCode and
=C2=A0=C2=A0 Options = are defined to enhance PCP with the ability to reserve port
=C2=A0=C2=A0= sets for internal hosts.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

A URL for this Internet-Draft is:
http://tools.ietf.org/i= d/draft-tsou-pcp-natcoord-05.txt


Best wishes

Qiong



--14dae934097bebba8c04bb99843d-- From mohamed.boucadair@orange.com Mon Mar 19 08:18:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9258221F87ED for ; Mon, 19 Mar 2012 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 Dm7oSLI5PikC for ; Mon, 19 Mar 2012 08:18:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8A21F87EF for ; Mon, 19 Mar 2012 08:18:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 867D726417C; Mon, 19 Mar 2012 16:18:42 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6A06A35C061; Mon, 19 Mar 2012 16:18:42 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 19 Mar 2012 16:18:42 +0100 From: To: Qiong , "pcp@ietf.org" Date: Mon, 19 Mar 2012 16:18:41 +0100 Thread-Topic: [pcp] FW: New Version Notification for draft-tsou-pcp-natcoord-05.txt Thread-Index: Ac0F3dyqFTGWt8y8QjCf6dFgLsL/vwAAGfjg Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557F64@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E28557F64PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.130327 Subject: Re: [pcp] FW: New Version Notification for draft-tsou-pcp-natcoord-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:18:44 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E28557F64PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The main changes since the last version are as follows: * Define a new OpCode to request a range of ports: The rationale behind thi= s choice is to avoid overloading MAP and to ease separating the port-range = function from the handling of individual mappings. * Two Options are defined to convey port ranges: these two options allow to= convey contiguous, non-contiguous and pseudo-random port sets. * Specify the relationship between the new OpCode and existing Options. The proposed mechanism can be used to retrieve a restricted IPv4 address an= d a port range. A deployment scenario is described in: http://tools.ietf.or= g/html/draft-cui-softwire-b4-translated-ds-lite-05. Cheers, Med ________________________________ De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Qiong Envoy=E9 : lundi 19 mars 2012 15:37 =C0 : pcp@ietf.org Objet : [pcp] FW: New Version Notification for draft-tsou-pcp-natcoord-05.t= xt Dear all, We have submitted a new version of pcp-natcoord which extends PCP with the = ability to reserve port set instead of individual mapping. Your comments ar= e appreciated. Thanks in advance! A new version of I-D, draft-tsou-pcp-natcoord-05.txt has been successfully = submitted by Cathy Zhou and posted to the IETF repository. Filename: draft-tsou-pcp-natcoord Revision: 05 Title: Using PCP To Coordinate Between the CGN and Home Gateway Via= Port Allocation Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 11 Abstract: This document defines an extension to the base PCP. New OpCode and Options are defined to enhance PCP with the ability to reserve port sets for internal hosts. A URL for this Internet-Draft is: http://tools.ietf.org/id/draft-tsou-pcp-natcoord-05.txt Best wishes Qiong --_000_94C682931C08B048B7A8645303FDC9F36E28557F64PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
The main changes since the last version are a= s=20 follows:
 
* Define a new OpCode to request a range of p= orts: The=20 rationale behind this choice is to avoid overloading MAP and to ease=20 separating the port-range function from the handling of individua= l=20 mappings.
 
* Two Options are defined to convey port rang= es: these=20 two options allow to convey contiguous, non-contiguous and pseudo-random po= rt=20 sets.
 
* Specify the relationship between the new Op= Code and=20 existing Options.
 
The proposed mechanism can be used to retriev= e a=20 restricted IPv4 address and a port range. A deployment scenario i= s=20 described in: http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05= .
 
 
Cheers,
Med

De : pcp-bounces@ietf.org=20 [mailto:pcp-bounces@ietf.org] De la part de=20 Qiong
Envoy=E9 : lundi 19 mars 2012 15:37
=C0 := =20 pcp@ietf.org
Objet : [pcp] FW: New Version Notification fo= r=20 draft-tsou-pcp-natcoord-05.txt

Dear all,

We have submitted a new version of pcp-natcoo= rd=20 which extends PCP with the ability to reserve port set instead of individ= ual=20 mapping. Your comments are appreciated. Thanks in advance!

A new=20 version of I-D, draft-tsou-pcp-natcoord-05.txt has been successfully subm= itted=20 by Cathy Zhou and posted to the IETF=20 repository.

Filename:   =20  draft-tsou-pcp-natcoord
Revision:   =20  05
Title:         Using PCP T= o=20 Coordinate Between the CGN and Home Gateway Via Port Allocation
Creati= on=20 date:     2012-03-13
WG ID:   =20      Individual Submission
Number of pages:=20 11

Abstract:
   This document defines an extension to= the=20 base PCP.  New OpCode and
   Options are defined to enh= ance=20 PCP with the ability to reserve port
   sets for internal=20 hosts.           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  =20

A URL for this Internet-Draft is:
http://t= ools.ietf.org/id/draft-tsou-pcp-natcoord-05.txt


Best=20 wishes

Qiong


--_000_94C682931C08B048B7A8645303FDC9F36E28557F64PUEXCB1Bnante_-- From alper.yegin@yegin.org Wed Mar 21 09:03:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6953E21F85CF for ; Wed, 21 Mar 2012 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, 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 RdzdFw89qlGG for ; Wed, 21 Mar 2012 09:03:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 877FE21F863E for ; Wed, 21 Mar 2012 09:03:02 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Me8tq-1RwXqJ2eic-00PWV1; Wed, 21 Mar 2012 12:03:00 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_53334A57-C017-431D-9EFB-EB3ED6DD33D4" From: Alper Yegin In-Reply-To: <1BC7B293-E1A3-4DCD-8C8C-85FC7E601C91@yegin.org> Date: Wed, 21 Mar 2012 18:02:43 +0200 Message-Id: <4922478C-8773-4C01-9C8B-5B9B310C43F8@yegin.org> References: <0511D579-D181-4B56-9F6D-E52C3B38CF7C@lilacglade.org> <1BC7B293-E1A3-4DCD-8C8C-85FC7E601C91@yegin.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:P+feRsirExEoxms9Zsp2TNzSkRl+f9PwtWxkwUGejux Eu1g1tcPaYiPVg07bhlSvZR0mWfbgcE8JweK25pBIxVAOayWCi C+6Dodbibt0DNKSpW88J1+wDr+2N0t6MvUS/m6xcX1ZQN/Ah5M 1WZlTQy28rAgn9MIiaJvtFN7zXlyzR3RvyR2Y3q4iQ2afSnFQg Ft9H4aZLBQLqaLHbDZ6kivDqeuEpfWp+ktmJtTOU4jiVNKj/YD 194fEow6EroqAtvBHG7ACalj35Gmlkku8+SeiGOU5H2SmEa2L8 CcEbpQgXkgwH0MfqSg+4FXJ3Wo+kjM320o8gYBfNEZr0VfeDjl eyMjpdlDyL02vsgNpV7FZlHifMMA/xiktqQj943bv8kQcIYrgM Cb/cIqxJBabpg== Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:03:03 -0000 --Apple-Mail=_53334A57-C017-431D-9EFB-EB3ED6DD33D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Margaret, Sam, Any thoughts on this (see below)? Your approach still looks like unnecessarily bundling up a key = management protocol with the PCP. Why do you want to do it this way? = It's much better to keep them separate and independent. Alper =20 On Nov 30, 2011, at 7:25 PM, Alper Yegin wrote: > Hi Margaret, >=20 > First, we run PANA between the end-points. That yields a PANA session = -- with a session-id and a PANA SA. >=20 > Now that security association can be used with the PCP + your = Authentication Tag Option. >=20 > That's it. >=20 > This split is a very common approach. Former is the so-called key = management protocol (e.g., IKEv2, PANA, 802.1X), and the latter is where = that key is used (e.g., IPsec, Zigbee, 802.11i). > =20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> Hi Alper, >>=20 >> Without a more fleshed-out proposal, it is hard to understand exactly = what you are suggesting. Could you explain how the PANA authentication = would be bound to a particular PCP request/response in this case, = without modifications to the PCP client and server, similar to those = described in our draft?=20 >>=20 >> Margaret >>=20 >>=20 >> On Nov 30, 2011, at 5:07 AM, Alper Yegin wrote: >>=20 >>>=20 >>> I had given this comment at the meeting. Let me recap and solicit = discussion on this: >>>=20 >>> Like the authors declare, this work is "largely based on PANA (RFC = 5191)".=20 >>>=20 >>> In fact what it really does is, it decomposes RFC 5191 into pieces, = imports them over and reassembles some sort of PANA within the PCP = protocol.=20 >>>=20 >>> Instead of resurrecting PANA within PCP, I'd recommend we consider = using PANA as-is alongside PCP.=20 >>>=20 >>> Running PANA between the end-points to dynamically generate a = security association that can be used by PCP is the alternative I'd = recommend.=20 >>>=20 >>> This is a better approach as it relies on re-use of protocols rather = than creating new ones and has less impact on the PCP protocol. >>>=20 >>> Comments welcome. >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >=20 --Apple-Mail=_53334A57-C017-431D-9EFB-EB3ED6DD33D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Margaret,

First, we run PANA between the = end-points. That yields a PANA session -- with a session-id and a PANA = SA.

Now that security association can be used = with the PCP + your Authentication Tag = Option.

That's = it.

This split is a very common approach. = Former is the so-called key management protocol (e.g., IKEv2, PANA, = 802.1X), and the latter is where that key is used (e.g., IPsec, Zigbee, = 802.11i).
 
Alper







Hi = Alper,

Without a more fleshed-out proposal, it is = hard to understand exactly what you are suggesting.  Could you = explain how the PANA authentication would be bound to a particular PCP = request/response in this case, without modifications to the PCP client = and server, similar to those described in our = draft? 

Margaret

On Nov 30, 2011, at 5:07 AM, Alper Yegin wrote:


I had given = this comment at the meeting. Let me recap and solicit discussion on = this:

Like the authors declare, this work is = "largely based on PANA (RFC 5191)". 

In = fact what it really does is, it decomposes RFC 5191 into pieces, imports = them over and reassembles some sort of PANA within the PCP = protocol. 

Instead of resurrecting PANA = within PCP, I'd recommend we consider using PANA as-is alongside = PCP. 

Running PANA between the end-points = to dynamically generate a security association that can be used by PCP = is the alternative I'd recommend. 

This is = a better approach as it relies on re-use of protocols rather than = creating new ones and has less impact on the PCP = protocol.

Comments = welcome.

Alper





_______= ________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pcp

=

= --Apple-Mail=_53334A57-C017-431D-9EFB-EB3ED6DD33D4-- From mohamed.boucadair@orange.com Wed Mar 21 10:10:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01921E804D for ; Wed, 21 Mar 2012 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 YhDu1qsWV-Od for ; Wed, 21 Mar 2012 10:10:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3FB21E8025 for ; Wed, 21 Mar 2012 10:10:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id CC6052DC140; Wed, 21 Mar 2012 18:10:40 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B136027C053; Wed, 21 Mar 2012 18:10:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 21 Mar 2012 18:10:40 +0100 From: To: Alper Yegin , Margaret Wasserman Date: Wed, 21 Mar 2012 18:10:39 +0100 Thread-Topic: [pcp] wasserman-pcp-authentication Thread-Index: Ac0HfByxZ5ySYu2URROxofJa3nANbAACO1xw Message-ID: <94C682931C08B048B7A8645303FDC9F36E2867C340@PUEXCB1B.nanterre.francetelecom.fr> References: <0511D579-D181-4B56-9F6D-E52C3B38CF7C@lilacglade.org> <1BC7B293-E1A3-4DCD-8C8C-85FC7E601C91@yegin.org> <4922478C-8773-4C01-9C8B-5B9B310C43F8@yegin.org> In-Reply-To: <4922478C-8773-4C01-9C8B-5B9B310C43F8@yegin.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E2867C340PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.161516 Cc: "pcp@ietf.org" Subject: Re: [pcp] wasserman-pcp-authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:10:43 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E2867C340PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Alper, all, IMHO, before answering to the question of how to do it, we need first justi= fy why this is needed for PCP. For two cases I'm interested in, I really don't see a justification to have= an authentication channel for PCP: NAT64 and DS-Lite. Cheers, Med ________________________________ De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Alper= Yegin Envoy=E9 : mercredi 21 mars 2012 17:03 =C0 : Margaret Wasserman Cc : pcp@ietf.org Objet : Re: [pcp] wasserman-pcp-authentication Margaret, Sam, Any thoughts on this (see below)? Your approach still looks like unnecessarily bundling up a key management p= rotocol with the PCP. Why do you want to do it this way? It's much better t= o keep them separate and independent. Alper On Nov 30, 2011, at 7:25 PM, Alper Yegin wrote: Hi Margaret, First, we run PANA between the end-points. That yields a PANA session -- wi= th a session-id and a PANA SA. Now that security association can be used with the PCP + your Authenticatio= n Tag Option. That's it. This split is a very common approach. Former is the so-called key managemen= t protocol (e.g., IKEv2, PANA, 802.1X), and the latter is where that key is= used (e.g., IPsec, Zigbee, 802.11i). Alper Hi Alper, Without a more fleshed-out proposal, it is hard to understand exactly what = you are suggesting. Could you explain how the PANA authentication would be= bound to a particular PCP request/response in this case, without modificat= ions to the PCP client and server, similar to those described in our draft? Margaret On Nov 30, 2011, at 5:07 AM, Alper Yegin wrote: I had given this comment at the meeting. Let me recap and solicit discussio= n on this: Like the authors declare, this work is "largely based on PANA (RFC 5191)". In fact what it really does is, it decomposes RFC 5191 into pieces, imports= them over and reassembles some sort of PANA within the PCP protocol. Instead of resurrecting PANA within PCP, I'd recommend we consider using PA= NA as-is alongside PCP. Running PANA between the end-points to dynamically generate a security asso= ciation that can be used by PCP is the alternative I'd recommend. This is a better approach as it relies on re-use of protocols rather than c= reating new ones and has less impact on the PCP protocol. Comments welcome. Alper _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp --_000_94C682931C08B048B7A8645303FDC9F36E2867C340PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Alper, all,
 
IMHO, before answering to the question of how= to do=20 it, we need first justify why this is needed for PCP.
 
For two cases I'm interested in, I really don= 't see a=20 justification to have an authentication channel for PCP: NAT64 and=20 DS-Lite.
 
Cheers,
Med

De : pcp-bounces@ietf.org=20 [mailto:pcp-bounces@ietf.org] De la part de Alper=20 Yegin
Envoy=E9 : mercredi 21 mars 2012 17:03
=C0&nbs= p;:=20 Margaret Wasserman
Cc : pcp@ietf.org
Objet : Re:=20 [pcp] wasserman-pcp-authentication

Margaret, Sam,

Any thoughts on this (see below)?

Your approach still looks like unnecessarily bundling up a key manag= ement=20 protocol with the PCP. Why do you want to do it this way? It's much bette= r to=20 keep them separate and independent.

Alper
 

On Nov 30, 2011, at 7:25 PM, Alper Yegin wrote:
Hi=20 Margaret,

First, we run PANA between the end-points. That yields a PANA sess= ion=20 -- with a session-id and a PANA SA.

Now that security association can be used with the PCP + your=20 Authentication Tag Option.

That's it.

This split is a very common approach. Former is the so-called key= =20 management protocol (e.g., IKEv2, PANA, 802.1X), and the latter is wher= e=20 that key is used (e.g., IPsec, Zigbee, 802.11i).
 
Alper







Hi Alper,

Without a more fleshed-out proposal, it is hard to understand ex= actly=20 what you are suggesting.  Could you explain how the PANA=20 authentication would be bound to a particular PCP request/response in= this=20 case, without modifications to the PCP client and server, similar to = those=20 described in our draft? 

Margaret


On Nov 30, 2011, at 5:07 AM, Alper Yegin wrote:

I had given this comment at the meeting. Let me recap and soli= cit=20 discussion on this:

Like the authors declare, this work is "largely based on PANA = (RFC=20 5191)". 

In fact what it really does is, it decomposes RFC 5191 into pi= eces,=20 imports them over and reassembles some sort of PANA within the PCP= =20 protocol. 

Instead of resurrecting PANA within PCP, I'd recommend we cons= ider=20 using PANA as-is alongside PCP. 

Running PANA between the end-points to dynamically generate a= =20 security association that can be used by PCP is the alternative I'd= =20 recommend. 

This is a better approach as it relies on re-use of protocols= =20 rather than creating new ones and has less impact on the PCP=20 protocol.

Comments welcome.

Alper





______________________________________________= _
pcp=20 mailing list
pcp@ietf.orghttps://www.ietf= .org/mailman/listinfo/pcp



--_000_94C682931C08B048B7A8645303FDC9F36E2867C340PUEXCB1Bnante_-- From hartmans@painless-security.com Sun Mar 25 13:53:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA4621E802C for ; Sun, 25 Mar 2012 13:53:05 -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.370, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 7BIA4bi+8FDZ for ; Sun, 25 Mar 2012 13:53:05 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 26DD921E801A for ; Sun, 25 Mar 2012 13:53:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46bc.meeting.ietf.org [130.129.70.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2FF9720244 for ; Sun, 25 Mar 2012 16:52:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2E564766; Sun, 25 Mar 2012 16:52:55 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Sun, 25 Mar 2012 16:52:55 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:53:06 -0000 Hi. It's taken me a while to investigate the alternative of using Pana for PCP authentication that was suggested back in November. My apologies for the delay; I needed to swap the PANA spec back in. In general, I have found that including key management in-band with a protocol yields simpler implementation and deployment experience than out-of-band key management. Compare your experience with something in-band like a TLS web server with something out-of-band like IPsec to get a feel for the general issue. Most people find that web servers are easier to deploy and configure than IPsec solutions. I'm not alone in the security area in holding this opinion. Several security area experts argued that KARP (the effort to add authentication and key management to routing protocols) would be simpler if it used an in-band approach. There, the KARP working group is having to do out-of-band key management because of domain-specific constraints. Describing the abstract interface between the key management part and the routing protocol part is proving difficult to get consensus on. I suspect that would be simpler (but not simple) in PCP. So, while I believe that out-of-band key management can work for PCP, I think the implementation and standardization effort will be simpler if the working group adopts an in-band approach such as an EAP-based solution rather than an out-of-band approach such as a PANA solution. I'd like to explore some of the differences. I'll start by examining issues apparent at the protocol level. PCP does not need all of the PANA messages. We do not need a separate notification protocol for liveness of sessions. We can use PCP facilities for that. We do not need a re-authentication protocol. We do not need support for IP address reconfiguration on successful authentication. so, an EAP-based solution can directly avoid some of the parts of a PANA solution; this may result in reduced code size and complexity. PANA would need to change in order to support use for applications other than network access. In PANA today, there is not a clear mechanism for indicating what application a PAC is authenticating to. A PAA needs to know this for a number of reasons. For example in EAP channel binding (draft-ietf-emu-chbind), a AAA client such as a PAA is expected to include an eap-lower-layer AAA attribute so than an EAP server can validate channel bindings from the client against channel bindings from a server. In PANA today, the PAA has no way to tell whether the client is authenticating to PANA because it wants network access or because it wants to access PCP. I think PCP is close enough to network access to fall under RFC 3748's current applicability statement, but I think that PCP counts as a different EAP lower layer than PANA for network access. Similarly, some clients may be authorized to access a network but not a PCP server or a PCP server but not a network. PANA needs to gain a mechanism to distinguish this. PANA implementations would need to gain support for that. Handling this in an EAP-based solution is quite easy. PANA assumes an architecture where a DHCP option provides the address of the PAA to the PAC (RFC 5192). We have two choices. We can use this model. That means that the PAA MAY not be the same device as the PCP server. In this model we'd need to standardize a protocol for carrying the security association from the PAA to any PCP server served by that PAA. Alternatively we could choose to require that the PAA be co-resident with the PCP server. That is yet another variation from how PANA normally works that increases implementation cost and complexity. In an in-band solution it's natural to bind the authentication to a given PCP server. There are several aspects of RFC 5191 that assume PANA is being used to achieve IP connectivity. The most obvious is one I've already pointed out: the IP address reconfiguration bit. These aspects of the specification are likely to influence implementation choices; the implementations of PANA are likely to be optimized for this use case. This means they are likely to be more expensive to retool to fit PCP's use case. (This may be less of an issue if PANA is not generally available on a given platform and you start from scratch rather than including a existing version.) An EAP-based solution would be customized to PCP. However, I think the most significant issues are not obvious from the specification. PANA is likely similar effort to an EAP-based if PANA and the PCP server are part of the same monolithic code base that can share variables and data and can be refactored together. However, if that's not true, it gets more complex to implement. For example if your platform has separate processes and PANA and PCP run in different processes, then you'll have to define a communication mechanism between PANA and PCP. If your platform uses PANA for more than just PCP (which presumably is a benefit of using PANA--it can be applied to more than one application), you will need to manage SAs for PCP distinct from SAs for other uses. If your PANA and PCP code come from different sources, then you need to specify the interfaces used to communicate between PANA and PCP in whatever manner your platform uses for this sort of internal interface development. For some platforms that's a fairly big deal. If you are hoping to take advantage of PANA as a platform service exposed to multiple applications, then you'll have to version these interfaces and support backward compatibility or a forward evolution path. We believe that adds significant complexity. We believe that an EAP-based solution provides vendors a much better opportunity to trade off code sharing vs interface cost and be more likely to be near the lower cost/complexity side of the tradeoffs. For example, an embedded device could share the same EAP library both for network access and PCP. Such a device is likely to have a monolithic code base and is likely to be able to avoid most needs to specify platform-specific interfaces other than the API of the EAP library. Alternatively a server for a non-resource-constrained PCP system can pick the most convenient open-source EAP passthrough library. They are more concerned with avoiding implementation cost than code size. If PANA had been used, then the fact that all PAA traffic on the box uses the same port would significantly complicate the server implementation. Finally, I don't think PANA implementations are widely available on most PCP targets today. There are some networking technologies that are looking at/have adopted PANA, so availability of PANA implementations on platforms is likely to rise. However, EAP is available on all these platforms today. In conclusion, we believe an EAP-based solution is a better fit for PCP's requirements than a PANA based solution. However, if the WG chooses to use PANA, we'd be happy to edit our draft to reflect that consensus. Sam Hartman Principal Consultant Painless Security, LLC From hartmans@painless-security.com Mon Mar 26 02:23:40 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3D621F8517; Mon, 26 Mar 2012 02:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 5p8lXGcVlJpZ; Mon, 26 Mar 2012 02:23:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 93CAE21F8581; Mon, 26 Mar 2012 02:23:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 580F520244; Mon, 26 Mar 2012 05:22:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 344864766; Mon, 26 Mar 2012 05:23:34 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Mon, 26 Mar 2012 05:23:34 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [pcp] draft-ietf-pcp-base: security considerations and transaction ID X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:23:40 -0000 Hi. I contributed significantly to the security considerations section that is in the current PCP base document. Last night I was talking to eno of the authors about the PCP discuss positions and particularly the discussion of a transaction ID. He pointed out that PCP is not a request/response protocol. In particular, clients are expected to act on unsolicited PCP responses including new or updated mappings even if there is not a recent request for them. The security analysis we performed assumed that PCP is a request/response protocol. The current text is inaccurate. The obvious thing is that there is a greater attack window than is implied by the current text. It's going to take me a day or two to think through the implications of this. It may be that this does not impact the results of the analysis and just impacts security considerations text. I doubt I will have fully thought this through by the meeting today. I'm happy to attend that meeting if requested, although it was not currently in my plan. I will not be able to make the meeting tomorrow as I'll be co-chairing a session, but the other authors of draft-wasserman-pcp-authentication will be there. From alper.yegin@yegin.org Mon Mar 26 02:33:38 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1519E21F854D for ; Mon, 26 Mar 2012 02:33:38 -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 pYg24bAHxrm9 for ; Mon, 26 Mar 2012 02:33:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CC0A821F856A for ; Mon, 26 Mar 2012 02:33:36 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MNZkg-1SARLg3CCQ-006m3k; Mon, 26 Mar 2012 05:33:32 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 26 Mar 2012 12:33:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:SuwsVBODHxGSVzp3KLtvBvPCwwGPD4s8uBZDC8p5zB1 QXJO1xJTQBRC3XDO5eJrXi5p3EksaCbnfsVzJ9h47dc7FtVpri bDn4FLvQ6AHvj5V9KOY91LUkTxWamNHwFelh1e0toJoa1iSOyw lNCqxIPGVxMAv7nOxG3IzB6XLJ7tMdomxTLFDhV2ejgp/Doulc ++CBs2XnWH0An/Sdaex3XmbxoshQyHCKI7zwAv+hPxu4zQimws ylT20RW+Emb5mcum8J/Necf+9+1ivdbrKYywtgPT6sBBuQsi8o oLrorchr2tqmOd0TIOanopY0h7hZRtzj+LkfvumonCyabpHR3A H44RenRR2G6nRMi9Z/+xluIVr6y9Osu2kKY+8Q3Kg Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:33:38 -0000 Hi Sam, Thanks for the detailed analysis and response. This is a good = discussion. Please see below. >=20 > Hi. > It's taken me a while to investigate the alternative of using Pana = for > PCP authentication that was suggested back in November. My apologies = for > the delay; I needed to swap the PANA spec back in. >=20 > In general, I have found that including key management in-band with a > protocol yields simpler implementation and deployment experience than > out-of-band key management. Compare your experience with something > in-band like a TLS web server with something out-of-band like IPsec to > get a feel for the general issue. Most people find that web servers = are > easier to deploy and configure than IPsec solutions. I'm under the impression that this has more to do with the nature of = IPsec vs TLS, as opposed to the key management used for each. Would = IPsec have been easier to use than TLS if IKE were integrated into it? Key management and subject protocols are two distinct things. They have = different state machines, and messaging. Bundling the two up would only = increase cost, and complexity. Basically, what you are suggesting boils = down to embedding EAP transport into any protocol that needs "crypto = keys", and obviously this is a lot of standardization work, and coding = work eventually. It's much better to utilize modularity for such = distinct protocols than to monolithically integrate them one at a time. = Modularity also yields flexibility, as there are many different ways of = getting keys in place.=20 > I'm not alone in the security area in holding this opinion. Several > security area experts argued that KARP (the effort to add = authentication > and key management to routing protocols) would be simpler if it used = an > in-band approach. EAP has a very peculiar state machine. Trying to wedge it in an another = protocol is a challenge. DHC WG tried that, and after so many years of = effort it failed. DHC and EAP has incompatible state machines.=20 > There, the KARP working group is having to do > out-of-band key management because of domain-specific > constraints. Describing the abstract interface between the key > management part and the routing protocol part is proving difficult to > get consensus on. Isn't that an implementation issue: How one gets keys from one piece (a = config file, or dynamic state produced by a protocol) to another?=20 > I suspect that would be simpler (but not simple) in > PCP. So, while I believe that out-of-band key management can work for > PCP, I think the implementation and standardization effort will be > simpler if the working group adopts an in-band approach such as an > EAP-based solution rather than an out-of-band approach such as a PANA > solution. >=20 This is not "EAP vs PANA", btw. As you know, PANA is an "UDP-based EAP = lower layer". Your proposal is "PCP-based EAP lower-layer".=20 > I'd like to explore some of the differences. I'll start by examining > issues apparent at the protocol level. >=20 >=20 > PCP does not need all of the PANA messages. We do not need a > separate notification protocol for liveness of sessions. We can use = PCP > facilities for that. We do not need a re-authentication protocol. You'd need to trigger re-auth.=20 > We do > not need support for IP address reconfiguration on successful > authentication. That's right. That part is extra. > so, an EAP-based solution can directly avoid some of the parts of a = PANA > solution; this may result in reduced code size and complexity. >=20 I disagree. If we go with "EAP over any protocol that needs crypto = keys", we'll end up O(N) standardization work and O(N) implementation. >=20 > PANA would need to change in order to support use for applications = other > than network access. > In PANA today, there is not a clear mechanism for indicating what > application a PAC is authenticating to. A PAA needs to know this for a > number of reasons. For example in EAP channel binding > (draft-ietf-emu-chbind), a AAA client such as a PAA is expected to > include an eap-lower-layer AAA attribute so than an EAP server can > validate channel bindings from the client against channel bindings = from > a server. In PANA today, the PAA has no way to tell whether the client > is authenticating to PANA because it wants network access or because = it > wants to access PCP. Default of PANA is for "network access". By simple addition of a AVP, we can indicate "this PANA session is for = PCP". This is trivial. > I think PCP is close enough to network access to > fall under RFC 3748's current applicability statement, but I think = that > PCP counts as a different EAP lower layer than PANA for network = access. > Similarly, some clients may be authorized to access a network but not = a > PCP server or a PCP server but not a network. PANA needs to gain a > mechanism to distinguish this. PANA implementations would need to gain > support for that. > Handling this in an EAP-based solution is quite easy. >=20 It'd be more accurate to call that "EAP over PCP"-based solution if we = are contrasting it with PANA (which is EAP over UDP). >=20 > PANA assumes an architecture where a DHCP option provides the address = of > the PAA to the PAC (RFC 5192). This is one way. It's not mandatory to use. If there's another way to = discover PAA, that can be used too. However PCP server is discovered can = be used here, and we can declare PCP server and PAA are co-located. I = think you also make the equivalent assumption in your EAP/PCP design. > We have two choices. We can use this > model. That means that the PAA MAY not be the same device as the PCP > server. In this model we'd need to standardize a protocol for carrying > the security association from the PAA to any PCP server served by that > PAA. Alternatively we could choose to require that the PAA be > co-resident with the PCP server. That is yet another variation from = how > PANA normally works that increases implementation cost and > complexity. In an in-band solution it's natural to bind the > authentication to a given PCP server. >=20 I think EAP authenticator in your design is collocated with PCP server. = Right? If so, PAA is also collocated with the PCP server. Otherwise we both have the same issue of dealing with the split.=20 > There are several aspects of RFC 5191 that assume PANA is being used = to > achieve IP connectivity. The most obvious is one I've already pointed > out: the IP address reconfiguration bit. These aspects of the > specification are likely to influence implementation choices; the > implementations of PANA are likely to be optimized for this use > case. This means they are likely to be more expensive to retool to fit > PCP's use case. You just don't use IP reconfig, that's it. We do not use every bells and = whistles of each protocol in each deployment. > (This may be less of an issue if PANA is not generally > available on a given platform and you start from scratch rather than > including a existing version.) An EAP-based solution would be = customized > to PCP. >=20 >=20 > However, I think the most significant issues are not obvious from the > specification. PANA is likely similar effort to an EAP-based Except that (*), - PANA is already a RFC standard, - It's adopted in the industry (Zigbee Alliance), - There are two open source implementations,=20 - And multiple commercial ones already passed interop events > if PANA and > the PCP server are part of the same monolithic code base that can = share > variables and data and can be refactored together. However, if that's > not true, it gets more complex to implement. For example if your > platform has separate processes and PANA and PCP run in different > processes, then you'll have to define a communication mechanism = between > PANA and PCP. If your platform uses PANA for more than just PCP (which > presumably is a benefit of using PANA--it can be applied to more than > one application), you will need to manage SAs for PCP distinct from = SAs > for other uses. The AVP I mentioned above splits the space into multiple applications, = and SAs are managed separately. > If your PANA and PCP code come from different sources, > then you need to specify the interfaces used to communicate between = PANA > and PCP in whatever manner your platform uses for this sort of = internal > interface development. Sure. This is usual a system development issue. > For some platforms that's a fairly big deal. If > you are hoping to take advantage of PANA as a platform service exposed > to multiple applications, then you'll have to version these interfaces > and support backward compatibility or a forward evolution path. We > believe that adds significant complexity.=20 >=20 It's just addition of one AVP. I wonder where the complexity comes = from?=20 > We believe that an EAP-based solution provides vendors a much better = opportunity > to trade off code sharing vs interface cost and be more likely to be > near the lower cost/complexity side of the tradeoffs. For example, an > embedded device could share the same EAP library both for network = access > and PCP. Sam, PANA is also using EAP.=20 > Such a device is likely to have a monolithic code base and is > likely to be able to avoid most needs to specify platform-specific > interfaces other than the API of the EAP library. Alternatively a = server > for a non-resource-constrained PCP system can pick the most convenient > open-source EAP passthrough library. They are more concerned with > avoiding implementation cost than code size. If PANA had been used, = then > the fact that all PAA traffic on the box uses the same port would > significantly complicate the server implementation. >=20 I don't understand that.=20 Your approach yields O(N) implementation cost and code size as you are = advocating turning every protocol that needs crypto keys to embed EAP = (i.e., becoming an EAP lower layer in RFC 3748 terms). This cannot be = efficient. > Finally, I don't think PANA implementations are widely available on > most PCP targets today. But it's well-ahead of EAP over PCP implementation :-) Please see above = (*) > There are some networking technologies that are > looking at/have adopted PANA, so availability of PANA implementations = on > platforms is likely to rise. However, EAP is available on all these > platforms today. >=20 EAP is there. But what we are really talking about is the "EAP lower = layer", whether it'd be PANA or your EAP-over-PCP design. Having EAP and PCP on one platform does not give you EAP-over-PCP for = free. >=20 > In conclusion, we believe an EAP-based solution is a better fit for = PCP's > requirements than a PANA based solution. However, if the WG chooses to > use PANA, we'd be happy to edit our draft to reflect that consensus. >=20 I think at the minimum we should split key management from PCP security, = as two I-Ds. Then we can continue discussing whether one keys the later using PANA, = your EAP-over-PCP, or some other mechanisms. Bundling up is extremely constraining, and overly-complicating (marriage = of state machines), and costly. Reagrds, Alper >=20 > Sam Hartman > Principal Consultant > Painless Security, LLC > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Mon Mar 26 06:58:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4EA21F8607 for ; Mon, 26 Mar 2012 06:58:22 -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 Dgxjp2R+qVVk for ; Mon, 26 Mar 2012 06:58:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 884DC21F8603 for ; Mon, 26 Mar 2012 06:58:19 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MIL1r-1SGIVE0ncN-003uUC; Mon, 26 Mar 2012 09:58:18 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> Date: Mon, 26 Mar 2012 16:58:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6D61DC46-D517-4BE1-81A9-A1E4FCC09DD4@yegin.org> References: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:5C2oxu+/BBlz9fatR45TRX0vo1rjxVrNK0pNrtn3Ork 7b2oZhUDVhmpmchfDrEriVKGTCS9Tt+hUZMofe7NQiieBhF0WO 1MRTnA/gurYO+AsWKQvy9KM5aCr98ACIwE+axjE2prZIRddKJK R5FkGsNCXvYJmbUQYnhsGlFJ7lQDWUDtlysHmooqKFHBLEgrr4 T3jtRkJmzUWGoT8z3wPHl/1rUCbZSnrdfIaxdqoETmed7bHPPi d8nUEjPY7Pkf9lbs9JZPWlRL7lkyFz9SXz95hwpNbnmbfvzyjU EWCwmEzVH9PNvWSiIIaeCEVUFHQFQpc478ruXZoTHaLoo2mChN bVLypYjR1FUGVtHAsO5ZPCltca6NeQFvolpeVc5BJ Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:58:34 -0000 >> In general, I have found that including key management in-band with a >> protocol yields simpler implementation and deployment experience than >> out-of-band key management. Interestingly, even with the TLS, people did need separate key = management protocol, and that led to RFC 5705. From hartmans@painless-security.com Mon Mar 26 07:00:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13321F8608 for ; Mon, 26 Mar 2012 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 NlJrMcIfOphb for ; Mon, 26 Mar 2012 07:00:42 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0321F8607 for ; Mon, 26 Mar 2012 07:00:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EFCAC2021E; Mon, 26 Mar 2012 09:59:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C4DC54766; Mon, 26 Mar 2012 10:00:39 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> Date: Mon, 26 Mar 2012 10:00:39 -0400 In-Reply-To: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> (Alper Yegin's message of "Mon, 26 Mar 2012 12:33:24 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:00:44 -0000 Hi, Alper. I agree this is an excellent discussion. First, you're absolutely right that the question is whether EAP should be directly integrated into PCP or whether PANA should be used to carry the EAP traffic. If I implied PANA does not use EAP, that was unintentional. These solutions are similar in many ways. I think that we value different tradeoffs and make different complexity assumptions. I think that integrating a security mechanism like EAP into a protocol is not much more expensive than integrating something like PANA into a protocol. You believe that the complexity of matching state machines and doing this standardization work is fairly expensive. I believe that working through the details of how to adapt PANA to a use besides network access is complex. I am more concerned about the implementation costs within a platform--the issues that you described as system development. Now, I think it's time for the WG members to evaluate these approaches, ask any questions they have and make a decision about these tradeoffs for themselves. From alper.yegin@yegin.org Mon Mar 26 08:51:33 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673FA21F8624 for ; Mon, 26 Mar 2012 08:51:33 -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 GO8ccCUZJh2t for ; Mon, 26 Mar 2012 08:51:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA521F8613 for ; Mon, 26 Mar 2012 08:51:32 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lw2K5-1SK8I50qoH-018FC3; Mon, 26 Mar 2012 11:51:31 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 26 Mar 2012 18:51:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:WL7zNMSYEPO84plf6QVztjrlILKVwaHAgkltzgsYtRL i4KNvHHNNtMX4GK7ZI/oVQZNKZ96PmdArazQSSYZ+mgbBx7Yl8 nbKNEnD79rZmE4jl31N5ax7ehskWq5J9C/n/zmDApcqIchRJXv H3H7+4VF4eENohxwhyq3UpaylLqcR15OC12RjZfTVCikbfp3Kl SfNZFRo/B9TdxeCHG6z9jNZol7F1l1FHUd6NLPCRV9wjyuji+9 /NUncdMEzX/BV5g7hTL1o31qfiEpTqtKlbar3P0gqDcxV5untt bAB0PUCSc6E0whd49XpouEhINNdgMprI+ehGaRmi7YWJHBHMIP OjykLLy6TjmSJEmFktb2YEnNPPybv6/7GkSExRSD/ Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:51:33 -0000 Hi Sam, On Mar 26, 2012, at 5:00 PM, Sam Hartman wrote: > Hi, Alper. > I agree this is an excellent discussion. >=20 > First, you're absolutely right that the question is whether EAP should > be directly integrated into PCP or whether PANA should be used to = carry > the EAP traffic. If I implied PANA does not use EAP, that was > unintentional. These solutions are similar in many ways. >=20 > I think that we value different tradeoffs and make different = complexity > assumptions. >=20 > I think that integrating a security mechanism like EAP into a protocol > is not much more expensive than integrating something like PANA into a > protocol. There's a confusion here too. There's no "integrating PANA into a = protocol" being discussed here either.=20 It's about "using" PANA (+ defining one new AVP), as opposed to defining = a whole new EAP lower-layer based on PCP (your proposal). > You believe that the complexity of matching state machines and doing > this standardization work is fairly expensive. >=20 > I believe that working through the details of how to adapt PANA to a = use > besides network access is complex. >=20 I have yet to understand how that's the case. Can you elaborate? > I am more concerned about the implementation costs within a > platform--the issues that you described as system development. >=20 > Now, I think it's time for the WG members to evaluate these = approaches, > ask any questions they have and make a decision about these tradeoffs > for themselves. From yoshihiro.ohba@toshiba.co.jp Mon Mar 26 11:35:10 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3632521E80F7 for ; Mon, 26 Mar 2012 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, 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 k4DFhcSvJtZE for ; Mon, 26 Mar 2012 11:35:09 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF7121E80CC for ; Mon, 26 Mar 2012 11:35:08 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q2QIZ7ZO026078 for ; Tue, 27 Mar 2012 03:35:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q2QIZ7n3002608 for pcp@ietf.org; Tue, 27 Mar 2012 03:35:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id DAA02607; Tue, 27 Mar 2012 03:35:07 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q2QIZ7cW001504 for ; Tue, 27 Mar 2012 03:35:07 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q2QIZ7X0029034; Tue, 27 Mar 2012 03:35:07 +0900 (JST) Received: from [133.199.16.233] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M1I00HSX8YF7500@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 27 Mar 2012 03:35:07 +0900 (JST) Date: Tue, 27 Mar 2012 03:34:53 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <4F70B6CD.2020109@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:35:10 -0000 Sam, Besides what was already responded by Alper, I have one comment. I am not sure what platform you have in mind, but we implemented PANA on multiple microprocessor platforms (See for example http://www.iab.org/wp-content/IAB-uploads/2011/03/Ohba.pdf) in addition to x86 platforms with Windows and Linux OSes, with exporting keys to other protocols. There has been no major complexity/cost issue found for such PANA implementations. I would suggest trying out existing open-source PANA implementations such as cpana and openpana if you have not tried one yet. Regards, Yoshihiro Ohba (2012/03/26 23:00), Sam Hartman wrote: > Hi, Alper. > I agree this is an excellent discussion. > > First, you're absolutely right that the question is whether EAP should > be directly integrated into PCP or whether PANA should be used to carry > the EAP traffic. If I implied PANA does not use EAP, that was > unintentional. These solutions are similar in many ways. > > I think that we value different tradeoffs and make different complexity > assumptions. > > I think that integrating a security mechanism like EAP into a protocol > is not much more expensive than integrating something like PANA into a > protocol. > You believe that the complexity of matching state machines and doing > this standardization work is fairly expensive. > > I believe that working through the details of how to adapt PANA to a use > besides network access is complex. > > I am more concerned about the implementation costs within a > platform--the issues that you described as system development. > > Now, I think it's time for the WG members to evaluate these approaches, > ask any questions they have and make a decision about these tradeoffs > for themselves. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hartmans@mit.edu Mon Mar 26 21:12:09 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108FA21F84B2; Mon, 26 Mar 2012 21:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 prfYtrU0x+Q1; Mon, 26 Mar 2012 21:12:03 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BF31021E8019; Mon, 26 Mar 2012 21:12:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (mf92836d0.tmodns.net [208.54.40.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C9FD520464; Tue, 27 Mar 2012 00:11:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B1064766; Tue, 27 Mar 2012 00:09:43 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) Date: Tue, 27 Mar 2012 00:09:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 04:12:09 -0000 [IESg members with discusses on PCP and transaction identifiers, please read; I propose another argument why you probably want one.] As I mentioned Monday, I had not thought through the implications of a client receiving multiple responses. In addition, when writing the security considerations text, we were focusing on the goal described in section 17. It is the security goal of the PCP protocol to limit any new denial of service opportunities, and to avoid introducing new attacks that can result in unauthorized changes to mapping state. That's fine as far as it goals. However, PCP also gives nodes information on their external addresses. So, to some extent it replaces STUN, or at least you can imagine a legitimate node choosing to trust the external address reported by PCP and not use STUN. If a node should not trust the external address received from a PCP server, then we should not provide that address. Now, trust is relative. There's always the possibility that there's an extra layer of NAT beyond your PCP server it doesn't know about. I suspect some applications will run STUN anyway. However, as I read the spec today, this is not a requirement. So, there's an additional security goal: application security MUST NOT be reduced by trusting PCP rather than STUN. That is, we need to analyze the attacks that have value on a mapped address. Most applications will take their external address and give it to people. They might use SDP or some directory service. They might send it over some messaging service. But they expect someone out there to try and connect to this address. I see 3 important attacks: 1) By modifying a client's view of its external address the attacker can deny service to a client by causing it register a bogus address at which it will not receive traffic. 2) By modifying many clients' belief about their external address, an attacker can create DDOS by generating a lot of traffic to a site that is not expecting it. 3) By modifying a client's idea of an external address, an attacker can redirect traffic destined for the client to the attacker. This can be used as part of a man-in-the-middle attack. In my mind, two aspects of PCP make these attacks easier to mount than similar attacks against STUN. 1) If a client follows the design note in section 6 and receives multiple responses from a PCP server, then the window of opportunity is significantly increased over the STUN binding transaction. That transaction is a simple request/response transaction; clients do not expect to receive multiple responses. If an attacker cannot get there first then an attacker loses the window for the attack. 2) PCP is significantly more vulnerable to off-path attackers than STUN. STUN includes a 96-bit transaction identifier that an attacker MUST guess in order to respond to a request. PCP does not include anything like this. An attacker needs to guess the internal address and internal port. State of art is to include some sort of transaction identifier to defend against off-path attackers: we do it in L2TP, STUN, and a number of UDP protocols like this. We really really wish we'd done it in DNS. In fact our work with DNS and randomized ports and avoiding fake responses strongly suggests that mounting attacks against protocols without long transaction identifiers is easy especially if you have a long time window. PCP does have one thing that is an advantage over STUN. It's not much help against the off-path attack in a number of important deployments (switched LAN, enterprise guest network, firewall deployments without NAT), but it does help with the increased time window for on-path attackers. There's a lot less on-path. If your PCP server is in your CPE, the path from you to it is shorter than the path from you to a STUN server. I have two recommendations. First, PCP should add a transaction ID between 96-bits and 128-bits. (No reason to be weaker than STUN). I could be persuaded that 64-bits is sufficient, but shorter than 64-bits seems like a really bad idea.) Section 8.3 should be updated to require clients drop responses if the transaction ID does not match the transaction ID in the request. Section 8.3 can still say that clients SHOULD process multiple responses from the same request. Secondly, we should document in section 17 that there's a tradeoff in processing multiple responses. Something like: Section 8.3 recommends that clients process multiple responses to a single request. Doing so permits a server to reflect mapping changes to clients more quickly. However, it increases the window of opportunity for an attacker to send fake responses including incorrect mapping information. If clients use external addresses in this mapping information then an attacker may mount a denial-of-service attack against the client or third parties. Additionally, an attacker may be able to redirect traffic destined for the client through the attacker. A security mechanism meeting the advanced threat model (section 17.2) is a mitigation for this class of attack. I also note that we don't actually have security considerations text about the PCP server's confidence in the external address it gives you especially in the situation where there are multiple PCP servers. I'm happy to let that slide as it's complicated and this is late in the process. From mrw@lilacglade.org Mon Mar 26 21:19:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5621E8019; Mon, 26 Mar 2012 21:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 9Afsq7rfWrzU; Mon, 26 Mar 2012 21:19:43 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC7021F84DF; Mon, 26 Mar 2012 21:19:43 -0700 (PDT) Received: from [10.59.91.124] (access-49.80.rev.fr.colt.net [213.41.80.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 4DE7020464; Tue, 27 Mar 2012 00:18:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Tue, 27 Mar 2012 06:19:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 04:19:44 -0000 I think it would be possible to address the security issues raised in = this message AND to maintain the operational model described in section = 6 of the PCP specification, by using a randomly-generated nonce value = (instead of a transaction ID), and associating that nonce with each = client-server-address-protocol-port five-tuple. So, effectively, each = PCP mapping would have a nonce associated with it (on both the client = and server sides) that would be used for further communication regarding = that mapping. Margaret On Mar 27, 2012, at 6:09 AM, Sam Hartman wrote: > [IESg members with discusses on PCP and transaction identifiers, = please > read; I propose another argument why you probably want one.] >=20 > As I mentioned Monday, I had not thought through the implications of = a > client receiving multiple responses. > In addition, when writing the security considerations text, we were > focusing on the goal described in section 17. > It is the > security goal of the PCP protocol to limit any new denial of service > opportunities, and to avoid introducing new attacks that can > result > in unauthorized changes to mapping state. =20 >=20 >=20 > That's fine as far as it goals. > However, PCP also gives nodes information on their external addresses. > So, to some extent it replaces STUN, or at least you can imagine a > legitimate node choosing to trust the external address reported by PCP > and not use STUN. > If a node should not trust the external address received from a PCP > server, then we should not provide that address. >=20 > Now, trust is relative. There's always the possibility that there's an > extra layer of NAT beyond your PCP server it doesn't know about. I > suspect some applications will run STUN anyway. However, as I read the > spec today, this is not a requirement. >=20 > So, there's an additional security goal: application security MUST NOT > be reduced by trusting PCP rather than STUN. That is, we need to = analyze > the attacks that have value on a mapped address. >=20 > Most applications will take their external address and give it to > people. They might use SDP or some directory service. They might send = it > over some messaging service. But they expect someone out there to try > and connect to this address. >=20 > I see 3 important attacks: >=20 > 1) By modifying a client's view of its external address the attacker > can deny service to a client by causing it register a bogus address = at > which it will not receive traffic. >=20 > 2) By modifying many clients' belief about their external address, an > attacker can create DDOS by generating a lot of traffic to a site = that > is not expecting it. >=20 > 3) By modifying a client's idea of an external address, an attacker = can > redirect traffic destined for the client to the attacker. This can be > used as part of a man-in-the-middle attack. >=20 > In my mind, two aspects of PCP make these attacks easier to mount than > similar attacks against STUN. >=20 > 1) If a client follows the design note in section 6 and receives > multiple responses from a PCP server, then the window of opportunity = is > significantly increased over the STUN binding transaction. That > transaction is a simple request/response transaction; clients do not > expect to receive multiple responses. If an attacker cannot get there > first then an attacker loses the window for the attack. >=20 > 2) PCP is significantly more vulnerable to off-path attackers than > STUN. STUN includes a 96-bit transaction identifier that an attacker > MUST guess in order to respond to a request. PCP does not include > anything like this. An attacker needs to guess the internal address = and > internal port. State of art is to include some sort of transaction > identifier to defend against off-path attackers: we do it in L2TP, = STUN, > and a number of UDP protocols like this. We really really wish we'd = done > it in DNS. In fact our work with DNS and randomized ports and avoiding > fake responses strongly suggests that mounting attacks against = protocols > without long transaction identifiers is easy especially if you have a > long time window. >=20 > PCP does have one thing that is an advantage over STUN. It's not much > help against the off-path attack in a number of important deployments > (switched LAN, enterprise guest network, firewall deployments without > NAT), but it does help with the increased time window for on-path > attackers. There's a lot less on-path. If your PCP server is in your > CPE, the path from you to it is shorter than the path from you to a = STUN > server. >=20 > I have two recommendations. >=20 > First, PCP should add a transaction ID between 96-bits and 128-bits. = (No > reason to be weaker than STUN). I could be persuaded that 64-bits is > sufficient, but shorter than 64-bits seems like a really bad idea.) > Section 8.3 should be updated to require clients drop responses if the > transaction ID does not match the transaction ID in the request. > Section 8.3 can still say that clients SHOULD process multiple = responses > from the same request. >=20 > Secondly, we should document in section 17 that there's a tradeoff in > processing multiple responses. >=20 > Something like: >=20 > Section 8.3 recommends that clients process multiple responses to a > single request. Doing so permits a server to reflect mapping changes = to > clients more quickly. However, it increases the window of opportunity > for an attacker to send fake responses including incorrect mapping > information. If clients use external addresses in this mapping > information then an attacker may mount a denial-of-service attack > against the client or third parties. Additionally, an attacker may be > able to redirect traffic destined for the client through the attacker. > A security mechanism meeting the advanced threat model (section 17.2) > is a mitigation for this class of attack. >=20 > I also note that we don't actually have security considerations text > about the PCP server's confidence in the external address it gives you > especially in the situation where there are multiple PCP servers. I'm > happy to let that slide as it's complicated and this is late in the > process. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Mon Mar 26 23:26:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECB621E801F; Mon, 26 Mar 2012 23:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.959 X-Spam-Level: X-Spam-Status: No, score=-9.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2cNduztSONm; Mon, 26 Mar 2012 23:26:12 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECC421E8019; Mon, 26 Mar 2012 23:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=6770; q=dns/txt; s=iport; t=1332829572; x=1334039172; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=K/cKxpMmA2M0B4aOnSkepuyf77ZGH974/bu7WP66PgE=; b=JB2m/IomZyhxqm42vmI+ZRO3XqmwHFeH8CVQf+JYB6QeqmwSiy/1wzjt qpT9f3XvlS6Be9Mj0QhWwU0sA7S0vfFQhh+u6ihoPLUEygWX+u1ph1+ol 0eJA264fbynFThW3Gi619VSPGm3tB7lzy1tky/yxnpw9mZYXRzHpqqV4E U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukGAB9dcU+rRDoI/2dsb2JhbABEgw61OIEHggsBBAEBAQ8BJwIBMQsTCG0wBgENBSKHZwyaKZ8IBIpjhiwEiFiNCYVviFaBaIMHgTQBAQMU X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="34692006" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 27 Mar 2012 06:26:11 +0000 Received: from [10.21.122.158] (sjc-vpn6-670.cisco.com [10.21.122.158]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2R6Q93o016351; Tue, 27 Mar 2012 06:26:10 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 26 Mar 2012 23:26:07 -0700 From: Reinaldo Penno To: Sam Hartman , Message-ID: Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 06:26:13 -0000 Hi, Can you comment how an hacker could mount such attacks in Wireless networks or Wireline broadband with the minimum set of filters preventing spoofing, etc? If I understand your proposal, and we include a transaction ID/nonce (TID for short) we need more discussion: 1 - Since the protocol does not differentiate between retransmissions, renewals and first requests, we need to define when TID will remain the same or change. 2 - Client and Server will now have to remember the TID not only during the transaction but for the lifetime of the mapping since the server might need to send unsolicited responses affecting that mapping at any time and client needs to validate it. 3 - Which TID should be used by multicast ANNOUNCE messages? Although risk is low in link-local we need to certainly define the semantics. 4 - Probably need some guidelines on uniqueness in the case of failure, high-availability, etc Thanks, Reinaldo On 3/26/12 9:09 PM, "Sam Hartman" wrote: >[IESg members with discusses on PCP and transaction identifiers, please >read; I propose another argument why you probably want one.] > >As I mentioned Monday, I had not thought through the implications of a >client receiving multiple responses. >In addition, when writing the security considerations text, we were >focusing on the goal described in section 17. >It is the > security goal of the PCP protocol to limit any new denial of service > opportunities, and to avoid introducing new attacks that can > result > in unauthorized changes to mapping state. > > >That's fine as far as it goals. >However, PCP also gives nodes information on their external addresses. >So, to some extent it replaces STUN, or at least you can imagine a >legitimate node choosing to trust the external address reported by PCP >and not use STUN. >If a node should not trust the external address received from a PCP >server, then we should not provide that address. > >Now, trust is relative. There's always the possibility that there's an >extra layer of NAT beyond your PCP server it doesn't know about. I >suspect some applications will run STUN anyway. However, as I read the >spec today, this is not a requirement. > >So, there's an additional security goal: application security MUST NOT >be reduced by trusting PCP rather than STUN. That is, we need to analyze >the attacks that have value on a mapped address. > >Most applications will take their external address and give it to >people. They might use SDP or some directory service. They might send it >over some messaging service. But they expect someone out there to try >and connect to this address. > >I see 3 important attacks: > >1) By modifying a client's view of its external address the attacker >can deny service to a client by causing it register a bogus address at >which it will not receive traffic. > >2) By modifying many clients' belief about their external address, an >attacker can create DDOS by generating a lot of traffic to a site that >is not expecting it. > >3) By modifying a client's idea of an external address, an attacker can >redirect traffic destined for the client to the attacker. This can be >used as part of a man-in-the-middle attack. > >In my mind, two aspects of PCP make these attacks easier to mount than >similar attacks against STUN. > >1) If a client follows the design note in section 6 and receives >multiple responses from a PCP server, then the window of opportunity is >significantly increased over the STUN binding transaction. That >transaction is a simple request/response transaction; clients do not >expect to receive multiple responses. If an attacker cannot get there >first then an attacker loses the window for the attack. > >2) PCP is significantly more vulnerable to off-path attackers than >STUN. STUN includes a 96-bit transaction identifier that an attacker >MUST guess in order to respond to a request. PCP does not include >anything like this. An attacker needs to guess the internal address and >internal port. State of art is to include some sort of transaction >identifier to defend against off-path attackers: we do it in L2TP, STUN, >and a number of UDP protocols like this. We really really wish we'd done >it in DNS. In fact our work with DNS and randomized ports and avoiding >fake responses strongly suggests that mounting attacks against protocols >without long transaction identifiers is easy especially if you have a >long time window. > >PCP does have one thing that is an advantage over STUN. It's not much >help against the off-path attack in a number of important deployments >(switched LAN, enterprise guest network, firewall deployments without >NAT), but it does help with the increased time window for on-path >attackers. There's a lot less on-path. If your PCP server is in your >CPE, the path from you to it is shorter than the path from you to a STUN >server. > >I have two recommendations. > >First, PCP should add a transaction ID between 96-bits and 128-bits. (No >reason to be weaker than STUN). I could be persuaded that 64-bits is >sufficient, but shorter than 64-bits seems like a really bad idea.) >Section 8.3 should be updated to require clients drop responses if the >transaction ID does not match the transaction ID in the request. >Section 8.3 can still say that clients SHOULD process multiple responses >from the same request. > >Secondly, we should document in section 17 that there's a tradeoff in >processing multiple responses. > >Something like: > >Section 8.3 recommends that clients process multiple responses to a >single request. Doing so permits a server to reflect mapping changes to >clients more quickly. However, it increases the window of opportunity >for an attacker to send fake responses including incorrect mapping >information. If clients use external addresses in this mapping >information then an attacker may mount a denial-of-service attack >against the client or third parties. Additionally, an attacker may be >able to redirect traffic destined for the client through the attacker. >A security mechanism meeting the advanced threat model (section 17.2) >is a mitigation for this class of attack. > >I also note that we don't actually have security considerations text >about the PCP server's confidence in the external address it gives you >especially in the situation where there are multiple PCP servers. I'm >happy to let that slide as it's complicated and this is late in the >process. >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Tue Mar 27 00:55:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFD21F8750; Tue, 27 Mar 2012 00:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.053, 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 Xq01a9xtShof; Tue, 27 Mar 2012 00:55:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6721F8757; Tue, 27 Mar 2012 00:55:02 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9254822C131; Tue, 27 Mar 2012 09:55:01 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 693134C017; Tue, 27 Mar 2012 09:55:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 27 Mar 2012 09:55:00 +0200 From: To: Margaret Wasserman , Sam Hartman Date: Tue, 27 Mar 2012 09:54:59 +0200 Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note Thread-Index: Ac0L0Nks9detfMSDS7K87ZvW2f6CdAAHX60Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E28732E17@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "pcp@ietf.org" , "iesg@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:55:04 -0000 Dear Margaret, Do you have in mind something similar to: http://tools.ietf.org/html/draft-= boucadair-pcp-extensions-02#section-6=20 PCP CLIENT_ID (Code TBA, Figure 5) is a token randomly [RFC4086] generated by the PCP Client. Only one CLIENT_ID Option MUST be present in a PCP message. The PCP Client and PCP Server MUST store the value included in this Option in a PCP MAP request. o The CLIENT_ID MUST be generated by the PCP Client and not the PCP Server; o Upon change of the IP address of the PCP Client (or a third party on behalf of which a mapping has been created), the CLIENT_ID is used to update related mappings (e.g., PCP MAP delete request and PCP MAP create request); o The same CLIENT_ID MUST be used for all requested mappings, unless a new CLIENT_ID is generated by the PCP Client (e.g., reboot, OS crash, etc.); o The CLIENT_ID is stored by the PCP Server for all mappings (persistent storage); Thanks. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Margaret Wasserman >Envoy=E9 : mardi 27 mars 2012 06:20 >=C0 : Sam Hartman >Cc : pcp@ietf.org; iesg@ietf.org >Objet : Re: [pcp] draft-ietf-pcp-base: security impacts of=20 >section 6 design note > > >I think it would be possible to address the security issues=20 >raised in this message AND to maintain the operational model=20 >described in section 6 of the PCP specification, by using a=20 >randomly-generated nonce value (instead of a transaction ID),=20 >and associating that nonce with each=20 >client-server-address-protocol-port five-tuple. So,=20 >effectively, each PCP mapping would have a nonce associated=20 >with it (on both the client and server sides) that would be=20 >used for further communication regarding that mapping. > >Margaret > >On Mar 27, 2012, at 6:09 AM, Sam Hartman wrote: > >> [IESg members with discusses on PCP and transaction=20 >identifiers, please >> read; I propose another argument why you probably want one.] >>=20 >> As I mentioned Monday, I had not thought through the =20 >implications of a >> client receiving multiple responses. >> In addition, when writing the security considerations text, we were >> focusing on the goal described in section 17. >> It is the >> security goal of the PCP protocol to limit any new denial=20 >of service >> opportunities, and to avoid introducing new attacks that can >> result >> in unauthorized changes to mapping state. =20 >>=20 >>=20 >> That's fine as far as it goals. >> However, PCP also gives nodes information on their external=20 >addresses. >> So, to some extent it replaces STUN, or at least you can imagine a >> legitimate node choosing to trust the external address=20 >reported by PCP >> and not use STUN. >> If a node should not trust the external address received from a PCP >> server, then we should not provide that address. >>=20 >> Now, trust is relative. There's always the possibility that=20 >there's an >> extra layer of NAT beyond your PCP server it doesn't know about. I >> suspect some applications will run STUN anyway. However, as=20 >I read the >> spec today, this is not a requirement. >>=20 >> So, there's an additional security goal: application=20 >security MUST NOT >> be reduced by trusting PCP rather than STUN. That is, we=20 >need to analyze >> the attacks that have value on a mapped address. >>=20 >> Most applications will take their external address and give it to >> people. They might use SDP or some directory service. They=20 >might send it >> over some messaging service. But they expect someone out there to try >> and connect to this address. >>=20 >> I see 3 important attacks: >>=20 >> 1) By modifying a client's view of its external address the attacker >> can deny service to a client by causing it register a bogus=20 >address at >> which it will not receive traffic. >>=20 >> 2) By modifying many clients' belief about their external address, an >> attacker can create DDOS by generating a lot of traffic to=20 >a site that >> is not expecting it. >>=20 >> 3) By modifying a client's idea of an external address, an=20 >attacker can >> redirect traffic destined for the client to the attacker. This can be >> used as part of a man-in-the-middle attack. >>=20 >> In my mind, two aspects of PCP make these attacks easier to=20 >mount than >> similar attacks against STUN. >>=20 >> 1) If a client follows the design note in section 6 and receives >> multiple responses from a PCP server, then the window of=20 >opportunity is >> significantly increased over the STUN binding transaction. That >> transaction is a simple request/response transaction; clients do not >> expect to receive multiple responses. If an attacker cannot get there >> first then an attacker loses the window for the attack. >>=20 >> 2) PCP is significantly more vulnerable to off-path attackers than >> STUN. STUN includes a 96-bit transaction identifier that an attacker >> MUST guess in order to respond to a request. PCP does not include >> anything like this. An attacker needs to guess the internal=20 >address and >> internal port. State of art is to include some sort of transaction >> identifier to defend against off-path attackers: we do it in=20 >L2TP, STUN, >> and a number of UDP protocols like this. We really really=20 >wish we'd done >> it in DNS. In fact our work with DNS and randomized ports=20 >and avoiding >> fake responses strongly suggests that mounting attacks=20 >against protocols >> without long transaction identifiers is easy especially if you have a >> long time window. >>=20 >> PCP does have one thing that is an advantage over STUN. It's not much >> help against the off-path attack in a number of important deployments >> (switched LAN, enterprise guest network, firewall deployments without >> NAT), but it does help with the increased time window for on-path >> attackers. There's a lot less on-path. If your PCP server is in your >> CPE, the path from you to it is shorter than the path from=20 >you to a STUN >> server. >>=20 >> I have two recommendations. >>=20 >> First, PCP should add a transaction ID between 96-bits and=20 >128-bits. (No >> reason to be weaker than STUN). I could be persuaded that 64-bits is >> sufficient, but shorter than 64-bits seems like a really bad idea.) >> Section 8.3 should be updated to require clients drop=20 >responses if the >> transaction ID does not match the transaction ID in the request. >> Section 8.3 can still say that clients SHOULD process=20 >multiple responses >> from the same request. >>=20 >> Secondly, we should document in section 17 that there's a tradeoff in >> processing multiple responses. >>=20 >> Something like: >>=20 >> Section 8.3 recommends that clients process multiple responses to a >> single request. Doing so permits a server to reflect mapping=20 >changes to >> clients more quickly. However, it increases the window of opportunity >> for an attacker to send fake responses including incorrect mapping >> information. If clients use external addresses in this mapping >> information then an attacker may mount a denial-of-service attack >> against the client or third parties. Additionally, an attacker may be >> able to redirect traffic destined for the client through the=20 >attacker. >> A security mechanism meeting the advanced threat model (section 17.2) >> is a mitigation for this class of attack. >>=20 >> I also note that we don't actually have security considerations text >> about the PCP server's confidence in the external address it=20 >gives you >> especially in the situation where there are multiple PCP=20 >servers. I'm >> happy to let that slide as it's complicated and this is late in the >> process. >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From hartmans@painless-security.com Tue Mar 27 01:36:08 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE98521F8901; Tue, 27 Mar 2012 01:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 k8ZniAXKf-iS; Tue, 27 Mar 2012 01:36:07 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1521F88F9; Tue, 27 Mar 2012 01:36:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0AB4020464; Tue, 27 Mar 2012 04:35:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 19A0A4766; Tue, 27 Mar 2012 04:36:03 -0400 (EDT) From: Sam Hartman To: Reinaldo Penno References: Date: Tue, 27 Mar 2012 04:36:03 -0400 In-Reply-To: (Reinaldo Penno's message of "Mon, 26 Mar 2012 23:26:07 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:36:08 -0000 >>>>> "Reinaldo" == Reinaldo Penno writes: Reinaldo> Hi, Can you comment how an hacker could mount such attacks Reinaldo> in Wireless networks or Wireline broadband with the Reinaldo> minimum set of filters preventing spoofing, etc? Well, if you explain the set of filters you're specifically talking about, I can better answer that. On most wireless deployments I'm familiar with, very little prevents one wireless client from spoofing IP addresses of another. Also, PCP has to work in a lot of deployments. For example while it might be easy to mandate ingress filtering behavior when a PCP server is collocated with a gateway NAT, it seems more difficult when they are separate boxes. If you can describe what filters are present in your environment I'll try to better answer the question. However, we need a fairly broad solution for the spec because of the broad deployment options for PCP. In terms of specific questions you ask. If we choose a nonce rather than a transaction ID, we avoid questions about retransmits vs new requests. I'd recommend servers either use 0 or a value of their choice for announce messages. Yes, clients and servers would need to remember the nonce. However only in cases where they already have state and it would be trivial to attach this to existing state. Clients would generate nonces randomly; we have easy citations for advice on randomness that we can include. I don't think there are any high-availability concerns for client-generated nonces. Thanks for your questions, --Sam From hartmans@painless-security.com Tue Mar 27 01:45:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AC521E8093 for ; Tue, 27 Mar 2012 01:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 LSFhW8U4pd+0 for ; Tue, 27 Mar 2012 01:45:14 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 113F321E8087 for ; Tue, 27 Mar 2012 01:44:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EEE1120464; Tue, 27 Mar 2012 04:44:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 03AB54766; Tue, 27 Mar 2012 04:44:52 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <70379F37-7BC9-4E2C-9705-DCF55E6CD027@yegin.org> <4F70B6CD.2020109@toshiba.co.jp> Date: Tue, 27 Mar 2012 04:44:51 -0400 In-Reply-To: <4F70B6CD.2020109@toshiba.co.jp> (Yoshihiro Ohba's message of "Tue, 27 Mar 2012 03:34:53 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] wasserman-pcp-authentication: pana alternative X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:45:27 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Sam, Besides what was already responded by Alper, I have Yoshihiro> one comment. Yoshihiro> I am not sure what platform you have in mind, but we Yoshihiro> implemented PANA on multiple microprocessor platforms Yoshihiro> (See for example Yoshihiro> http://www.iab.org/wp-content/IAB-uploads/2011/03/Ohba.pdf) Yoshihiro> in addition to x86 platforms with Windows and Linux OSes, Yoshihiro> with exporting keys to other protocols. Hi. I think of a platform as something like the official Windows Mobile release or the official Android release or something like that. There's a lot of effort in taking an implementation that runs on a platform and integrating it into that platform as the distributor/author of that platform in a way that you can support it going forward and that it's available as a platform service. In terms of things that are easily observed externally look at the effort a Linux distribution like Fedeora, Debian or Ubuntu spends integrating software into their platforms. --Sam From mohamed.boucadair@orange.com Tue Mar 27 01:59:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7EC21F892D; Tue, 27 Mar 2012 01:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.052, 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 Si48h7uaPWeU; Tue, 27 Mar 2012 01:59:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2DC21F88FC; Tue, 27 Mar 2012 01:59:12 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 792EC18C388; Tue, 27 Mar 2012 10:59:11 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 49834238048; Tue, 27 Mar 2012 10:59:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 27 Mar 2012 10:59:11 +0200 From: To: Sam Hartman , Reinaldo Penno Date: Tue, 27 Mar 2012 10:59:10 +0200 Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note Thread-Index: Ac0L9KqSl8xAIsheRBy3K9/iyndauQAAucLA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28732EA6@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.27.73315 Cc: "pcp@ietf.org" , "iesg@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:59:13 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Sam Hartman >Envoy=E9 : mardi 27 mars 2012 10:36 >=C0 : Reinaldo Penno >Cc : pcp@ietf.org; iesg@ietf.org >Objet : Re: [pcp] draft-ietf-pcp-base: security impacts of=20 >section 6 design note > >>>>>> "Reinaldo" =3D=3D Reinaldo Penno writes: > > Reinaldo> Hi, Can you comment how an hacker could mount=20 >such attacks > Reinaldo> in Wireless networks or Wireline broadband with the > Reinaldo> minimum set of filters preventing spoofing, etc? > > >Well, if you explain the set of filters you're specifically talking >about, I can better answer that. > >On most wireless deployments I'm familiar with, very little=20 >prevents one >wireless client from spoofing IP addresses of another. > Med: Some experimental data can be found here about ip spoofing in wireless= networks (Section 4.2.1): http://research.microsoft.com/en-us/people/mzh/netpiculet.pdf: they were ab= le to perform the IP spoofing test in 60 cellular networks, among which only 4 allow IP spoofing.= From repenno@cisco.com Tue Mar 27 02:02:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302721E8093; Tue, 27 Mar 2012 02:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzcDKGEe-DK9; Tue, 27 Mar 2012 02:02:51 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8221E8095; Tue, 27 Mar 2012 02:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=3252; q=dns/txt; s=iport; t=1332838971; x=1334048571; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/J8DbXuATm68rBjr8LZ93POMt/mrCSQENC4BDD77KWQ=; b=M9QgJDS6oCGuVwtUs6+i7K83NcdkE2Wdsga6DvR9Cx+oO96M6r01ZgLF BE3pycy+cmj2Af8bigsV/xeMWYICCKmVnJvvN9ZMu8wElhVG8vJaH7VBx SlN3CB5zlj83e0aoNKLnipPJIB6gMmERqGvZYlQBZ3a1NnwHQkYjDUons A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugGAPmAcU+rRDoH/2dsb2JhbABFgw61OoEHghASAScCATwTCIEdBg4FGweHZ5pCnw6RDwSIWI0JhW+IVoFogweBNhc X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="37822977" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Mar 2012 09:02:51 +0000 Received: from [10.21.114.2] (sjc-vpn2-514.cisco.com [10.21.114.2]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2R92STx003021; Tue, 27 Mar 2012 09:02:38 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 02:02:27 -0700 From: Reinaldo Penno To: Sam Hartman Message-ID: Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:02:53 -0000 On 3/27/12 1:36 AM, "Sam Hartman" wrote: >>>>>> "Reinaldo" == Reinaldo Penno writes: > > Reinaldo> Hi, Can you comment how an hacker could mount such attacks > Reinaldo> in Wireless networks or Wireline broadband with the > Reinaldo> minimum set of filters preventing spoofing, etc? > > >Well, if you explain the set of filters you're specifically talking >about, I can better answer that. [Reinaldo] Traditional filters used both in Wireless and Wireline such as: - Anti-spoofing: A CPE/UE/etc can not generate packets with a source address different then the one allocated to it - Reverse path forwarding checks. - Packets coming through Internet facing interfaces can not have the PCP Server address > >On most wireless deployments I'm familiar with, very little prevents one >wireless client from spoofing IP addresses of another. [Reinaldo] A wireless client can certainly spoof, whether it will make it through the Gateway is another story. Same for broadband. You can spoof a packet, but in general it will not go through RPF checks. > >Also, PCP has to work in a lot of deployments. For example while it >might be easy to mandate ingress filtering behavior when a PCP server is >collocated with a gateway NAT, it seems more difficult when they are >separate boxes. [Reinaldo] The attack vector I see is when the PCP Server is outside the administrative domain of the ISP/Content provider or direct-P2P communication is possible. > >If you can describe what filters are present in your environment I'll >try to better answer the question. > >However, we need a fairly broad solution for the spec because of the >broad deployment options for PCP. [Reinaldo] Agree, but I'm thinking nonce should be optional for those deployments that fall into the advance thread model. > >In terms of specific questions you ask. > >If we choose a nonce rather than a transaction ID, we avoid questions >about retransmits vs new requests. > >I'd recommend servers either use 0 or a value of their choice for > announce messages. > >Yes, clients and servers would need to remember the nonce. However only >in cases where they already have state and it would be trivial to attach >this to existing state. This is not clear to me: It is not clear to me clients always need to remember their mappings if they are happy with the lifetime and are certain they will not need an extension. The client still needs to listen to unsolicited responses, but those have everything needed for the client to know what happen to a mapping it installed before (without having to remember it). But such a nonce precludes stateless (or lightweight) client because now unsolicited messages need to be validated on a per transaction (mapping) basis for the lifetime of the mapping - if I understand your proposal It is also not clear to me how a PCP Proxy would work > >Clients would generate nonces randomly; we have easy citations for >advice on randomness that we can include. I don't think there are any >high-availability concerns for client-generated nonces. > >Thanks for your questions, > >--Sam > From hartmans@painless-security.com Tue Mar 27 02:13:23 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3071121F88FB; Tue, 27 Mar 2012 02:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 AcrLvdqdSVen; Tue, 27 Mar 2012 02:13:22 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 83D6521F88FC; Tue, 27 Mar 2012 02:13:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 629AC20464; Tue, 27 Mar 2012 05:12:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B73494766; Tue, 27 Mar 2012 05:13:16 -0400 (EDT) From: Sam Hartman To: Reinaldo Penno References: Date: Tue, 27 Mar 2012 05:13:16 -0400 In-Reply-To: (Reinaldo Penno's message of "Tue, 27 Mar 2012 02:02:27 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:13:23 -0000 >>>>> "Reinaldo" == Reinaldo Penno writes: Ah, and here we see a terminology clash. I think 802.11 as wireless. I agree that you can prevent one customer from spoofing another. >> However, we need a fairly broad solution for the spec because of >> the broad deployment options for PCP. Reinaldo> [Reinaldo] Agree, but I'm thinking nonce should be Reinaldo> optional for those deployments that fall into the advance Reinaldo> thread model. I agree that if you're using a security mechanism then you don't need a nonce. I'll note though that most security mechanisms will have a session ID that fills the same role. It may be much shorter though. --Sam From repenno@cisco.com Tue Mar 27 02:36:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C508221F8930; Tue, 27 Mar 2012 02:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1o6cz3u7NTA; Tue, 27 Mar 2012 02:36:01 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33EB821F8938; Tue, 27 Mar 2012 02:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1233; q=dns/txt; s=iport; t=1332840961; x=1334050561; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ReyrbhGm135yVN9j3WFyVu4CsMmLjmDkCcJx8NWSIjA=; b=JjOG2GDhHwPktC8adMyOh/sH6b4IzaYB6hb+qFZybFmtYdfL6T2gOrGW Qnz9CPAoYMSEeJPqN/5repk7VUbXOkcV9Q0WMggDbAIjH5zzBCdFIRdgR 2grnRABIvyHtmbj6P+2PciDyz5sYco8fHmo5NQ+UULh9BtLHJlRA9eLiO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugGACiJcU+rRDoJ/2dsb2JhbABFgw61OoEHghASAScCATwTCIEdBg4FGweHZ5pKnxCRDwSIWI0JhW+IVoFogwc X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="37826078" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 27 Mar 2012 09:36:01 +0000 Received: from [10.21.114.2] (sjc-vpn2-514.cisco.com [10.21.114.2]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R9ZrQG003165; Tue, 27 Mar 2012 09:35:55 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 02:35:51 -0700 From: Reinaldo Penno To: Sam Hartman Message-ID: Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:36:01 -0000 I just noticed my sentenced could have two interpretations. What I meant was: - Nonce should not required for those deployment where PCP Server and clients and under one administrative domain. In others words, the current spec is enough. - Nonce could be required in those deployments that fall in the advanced thread model. In this case nonce could be an optional PCP extension. Thanks, Reinaldo On 3/27/12 2:13 AM, "Sam Hartman" wrote: >>>>>> "Reinaldo" == Reinaldo Penno writes: > > >Ah, and here we see a terminology clash. >I think 802.11 as wireless. >I agree that you can prevent one customer from spoofing another. > >> However, we need a fairly broad solution for the spec because of > >> the broad deployment options for PCP. > > > Reinaldo> [Reinaldo] Agree, but I'm thinking nonce should be > Reinaldo> optional for those deployments that fall into the advance > Reinaldo> thread model. > >I agree that if you're using a security mechanism then you don't need a >nonce. I'll note though that most security mechanisms will have a >session ID that fills the same role. >It may be much shorter though. > >--Sam From mrw@lilacglade.org Tue Mar 27 03:26:12 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94BC21E814C; Tue, 27 Mar 2012 03:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qXLQYOXRgZXd; Tue, 27 Mar 2012 03:26:12 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04E21E8147; Tue, 27 Mar 2012 03:26:11 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id CFB11204BA; Tue, 27 Mar 2012 06:25:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28732E17@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 27 Mar 2012 12:26:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8994992D-13E9-448B-9783-A5DC438DF5AA@lilacglade.org> References: <94C682931C08B048B7A8645303FDC9F36E28732E17@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" , "iesg@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:26:12 -0000 Hi Mohamed, On Mar 27, 2012, at 9:54 AM, = wrote: > Dear Margaret, >=20 > Do you have in mind something similar to: = http://tools.ietf.org/html/draft-boucadair-pcp-extensions-02#section-6=20= >=20 > PCP CLIENT_ID (Code TBA, Figure 5) is a token randomly [RFC4086] > generated by the PCP Client. Only one CLIENT_ID Option MUST be > present in a PCP message. The PCP Client and PCP Server MUST store > the value included in this Option in a PCP MAP request. I am not talking about this specifically, because the PCP CLIENT_ID = value is one-per-client. I was suggesting a one-per-mapping nonce that = would be generated by the client the first time a new mapping is = requested, and would be used for all messages related to that specific = mapping. As I said, it would be done on a per 5-tuple. If a client received a message = form the server using a nonce that did not correspond with an existing = mapping maintained by the client, it would be ignored.=20 If we decide we need this in the protocol, I probably wouldn't put it in = an option, personally... but, once we determine whether or not it is = needed, we can talk about how best to include it. Margaret From mrw@lilacglade.org Tue Mar 27 03:41:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27AF21E8167; Tue, 27 Mar 2012 03:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 K2DeN7xq5d38; Tue, 27 Mar 2012 03:41:47 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5467D21E814E; Tue, 27 Mar 2012 03:41:47 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id B5B8020464; Tue, 27 Mar 2012 06:41:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Tue, 27 Mar 2012 12:41:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CAA0123-F2E8-4232-BC5E-62E95891A0FA@lilacglade.org> References: To: Reinaldo Penno X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:41:48 -0000 Hi Reinaldo, On Mar 27, 2012, at 11:35 AM, Reinaldo Penno wrote: > I just noticed my sentenced could have two interpretations. What I = meant > was: >=20 > - Nonce should not required for those deployment where PCP Server and > clients and under one administrative domain. In others words, the = current > spec is enough. How would a client or server detect that it was running in a deployment = that prevented IP Address spoofing? > - Nonce could be required in those deployments that fall in the = advanced > threat model. In this case nonce could be an optional PCP extension. I think you may be misunderstanding... The goal of the _simple threat model_ is to be no less secure than = existing deployments that use implicit mappings and STUN. Sam has = explained why he believes that some type of nonce/transaction ID is = needed to make PCP (in the simple threat model) as secure as implicit = mappings and STUN. So, the whole point is that a nonce is needed when = the PCP authentication mechanism is not used. The advanced threat model is intended to actually be cryptographically = secure, and one could potentially argue that a nonce is not needed when = the PCP authentication mechanism is used. Margaret From repenno@cisco.com Tue Mar 27 04:49:58 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086E121F898C; Tue, 27 Mar 2012 04:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3pn6OVtF2fM; Tue, 27 Mar 2012 04:49:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7034D21F8979; Tue, 27 Mar 2012 04:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=2221; q=dns/txt; s=iport; t=1332848997; x=1334058597; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=bA/KkWaGGf+7pCSupA4VzvqGidD/4a0ImT0hZfgusA4=; b=YAPYS4HLfPDnAO8elcDqZnW10R8CgkvmUo54wvs3A3f43QBNxjAG08ZY 71u8FBy6oRlDaM1TSPAoa1CLJ4hlnO27C0BxdGtQbpN7YifP6pXj4nFKU aVeEeFoKIcpn9UjbLf6uLtMvBq1SsOUBqsgVtFjuPIKsGehmb47PXfzI0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQHAAGpcU+rRDoI/2dsb2JhbABFgw61MoEHggkBAQEDARIBJwIBPAUOCA4KgQUGDgUih2MEmmifDpEPBIhYjQmFb4hWgWiDBw X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="37837696" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 27 Mar 2012 11:49:57 +0000 Received: from [10.21.96.72] (sjc-vpn1-72.cisco.com [10.21.96.72]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RBnujD018166; Tue, 27 Mar 2012 11:49:56 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 04:49:54 -0700 From: Reinaldo Penno To: Margaret Wasserman Message-ID: Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note In-Reply-To: <1CAA0123-F2E8-4232-BC5E-62E95891A0FA@lilacglade.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:49:58 -0000 On 3/27/12 3:41 AM, "Margaret Wasserman" wrote: > >Hi Reinaldo, > >On Mar 27, 2012, at 11:35 AM, Reinaldo Penno wrote: > >> I just noticed my sentenced could have two interpretations. What I meant >> was: >> >> - Nonce should not required for those deployment where PCP Server and >> clients and under one administrative domain. In others words, the >>current >> spec is enough. > >How would a client or server detect that it was running in a deployment >that prevented IP Address spoofing? Configuration or provisioning. You have different behaviors for trusted networks vs. untrusted networks. I guess no different than many actions a user takes when is in, say, a hotspot vs. his(er) home. > >> - Nonce could be required in those deployments that fall in the advanced >> threat model. In this case nonce could be an optional PCP extension. > >I think you may be misunderstanding... > >The goal of the _simple threat model_ is to be no less secure than >existing deployments that use implicit mappings and STUN. Sam has >explained why he believes that some type of nonce/transaction ID is >needed to make PCP (in the simple threat model) as secure as implicit >mappings and STUN. I understand the goal to be as secure as STUN, but not why. I mean, what is the reasoning and use-case behind it? > So, the whole point is that a nonce is needed when the PCP >authentication mechanism is not used. > >The advanced threat model is intended to actually be cryptographically >secure, and one could potentially argue that a nonce is not needed when >the PCP authentication mechanism is used. This is what I do not follow. If somebody is really concerned with security they should use your cryptographically secure proposal (I will call Secure-PCP). And if they are not, they can run the base spec as is. But we are saying there are a group of people that are (kind of) worried, but not to the point to click the 'Secure PCP' button. And therefore for those users we need a nonce. I would think putting the nonce as a PCP extension would be appropriate. Thanks, Reinaldo Thanks, Reinaldo > >Margaret > From hartmans@painless-security.com Tue Mar 27 04:54:00 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29521E81AD; Tue, 27 Mar 2012 04:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DfFcL1kg7ehT; Tue, 27 Mar 2012 04:53:59 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC22421E819D; Tue, 27 Mar 2012 04:53:58 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 952B32021E; Tue, 27 Mar 2012 07:53:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EE2B04766; Tue, 27 Mar 2012 07:53:55 -0400 (EDT) From: Sam Hartman To: Reinaldo Penno References: Date: Tue, 27 Mar 2012 07:53:55 -0400 In-Reply-To: (Reinaldo Penno's message of "Tue, 27 Mar 2012 02:35:51 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:54:00 -0000 >>>>> "Reinaldo" == Reinaldo Penno writes: Reinaldo> I just noticed my sentenced could have two Reinaldo> interpretations. What I meant was: Reinaldo> - Nonce should not required for those deployment where PCP Reinaldo> Server and clients and under one administrative domain. In Reinaldo> others words, the current spec is enough. I'm concerned about attacks where one device in the administrative domain attacks another. Section 17.1 talks about cases such as a guest network and a corporate network both behind the same firewall but have different security properties. So, I'm worried about attackers within the same domain. I think the nonce is more important for the simple threat model than the advanced threat model. From alper.yegin@yegin.org Tue Mar 27 05:03:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB5F21E81BB for ; Tue, 27 Mar 2012 05:03:52 -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=[AWL=0.000, 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 pfpHUjoiR5z8 for ; Tue, 27 Mar 2012 05:03:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C653A21E81BA for ; Tue, 27 Mar 2012 05:03:51 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Ld0PI-1Scj7k3v3Q-00iav1; Tue, 27 Mar 2012 08:03:50 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 15:03:47 +0300 Message-Id: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:3/e2RBSCZ5qPFizBWHYICVRow80PjhRPfptYd9d0w1F bpf+a7Q0uQuqxSZwsrQ0zQtBkIf0XyGGFQlze6dGzH9GY1HQib TQF0nCt+TybcewLOQpdGC/4uZtlhmMjomnqCZ+FFDw2vXAkqSv W94/pzlCnAarsl+dnCJlxSsG5bsuyqev6zCnibvTONuCXz9LDU vo4CVeWOiBQYNMciqAAjekOr+ZTOK0V/3/5dSCfhF5PEWE7x6Q Tsc+975SzOCiW2+7bBm518B6VgzIWvwPXHi3u0l8kTyg4/B/co aEDIw5OdXNhWA6nNSRtItsQmkslmBCQQej3mohfp1YQkmImzWZ zx1OnasoRLhqliJujR8SpLn6TCh2xkjX8y+aFK522 Subject: [pcp] Embedded or separate KMP for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:03:52 -0000 I recommend separating the key management protocol (KMP) from PCP. Bundling the two up is a recipe for unnecessary complexity and cost. (I = already elaborated on that, I can further expand if necessary). I don't see the benefit.=20 So, I recommend draft-wasserman-pcp-authentication-02 is split into two = drafts: Draft I: Integrity Protection for PCP (defining Authentication Tag = Option, etc.) Draft II: EAP transport over PCP (defining EAP Payload Option) I support Draft I. Draft II requires more discussion. Defining PCP-based EAP lower layer is = one approach, using PANA is another, there are other ways to get crypto = keys in place, etc. Alper From mrw@lilacglade.org Tue Mar 27 05:24:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92621E8130 for ; Tue, 27 Mar 2012 05:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8LQ1Lxr318HJ for ; Tue, 27 Mar 2012 05:24:02 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4910621F88F0 for ; Tue, 27 Mar 2012 05:24:00 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 643ED2021E; Tue, 27 Mar 2012 08:23:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> Date: Tue, 27 Mar 2012 14:23:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67295D3D-5DC4-4E12-9DB4-6C994E91A8FE@lilacglade.org> References: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Embedded or separate KMP for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:24:04 -0000 Hi Alper, On Mar 27, 2012, at 2:03 PM, Alper Yegin wrote: > I recommend separating the key management protocol (KMP) from PCP. > Bundling the two up is a recipe for unnecessary complexity and cost. = (I already elaborated on that, I can further expand if necessary). > I don't see the benefit.=20 You and Sam seem to disagree about the relative merits of separate vs. = in-line key management protocols -- you seem to favor a separate = approach (like IKE/IPsec), while Sam favors an inline approach (like = TLS). Hopefully some other people will join this discussion, so that we = can reach some agreement about which is better for PCP.=20 > So, I recommend draft-wasserman-pcp-authentication-02 is split into = two drafts: >=20 > Draft I: Integrity Protection for PCP (defining Authentication Tag = Option, etc.) > Draft II: EAP transport over PCP (defining EAP Payload Option) Given that the draft is 11 pages long, and that anything that referenced = one of the documents would need to reference both of them, splitting the = draft is not appealing to me. If there is WG consensus to split the = document, we will, but we do not need to have two separate drafts to = discuss the options we have been discussing... What benefit do you = think this division will have for PCP implementers? Margaret From repenno@cisco.com Tue Mar 27 05:26:21 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8419921F890E; Tue, 27 Mar 2012 05:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.308 X-Spam-Level: X-Spam-Status: No, score=-10.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZflKgUDOwYGC; Tue, 27 Mar 2012 05:26:20 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7730D21F8903; Tue, 27 Mar 2012 05:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1682; q=dns/txt; s=iport; t=1332851180; x=1334060780; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=ZqJLEkUdFL8NoL/38S1FFPqLfpMkQ1XFoN/y7JYZNWE=; b=HDvQ53o9YLT/EwFXCseWa30rljPayq/dMOGuzWUY7alqG+fNqVtVtY7f p1Z1UGxL47Lx8BV5n6wA66Iw3xbutaQgU+WUIr1Sdyp6xYYy7AQjyusnc /556FHA9h3TFpEAqgyyvnhYMgPIXFUUXE1MyM132pa9iMVWRIzCMW2GOj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIHAH2xcU+rRDoH/2dsb2JhbABEgw61M4EHghASAScCATwTCIEdBg4FIodnmmOfEpEPBIhYjQmFb4hWgWiDBw X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="34724956" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Mar 2012 12:26:19 +0000 Received: from [10.21.96.72] (sjc-vpn1-72.cisco.com [10.21.96.72]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2RCQGq2032580; Tue, 27 Mar 2012 12:26:19 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 27 Mar 2012 05:26:14 -0700 From: Reinaldo Penno To: Sam Hartman Message-ID: Thread-Topic: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, iesg@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:26:21 -0000 On 3/27/12 4:53 AM, "Sam Hartman" wrote: >>>>>> "Reinaldo" == Reinaldo Penno writes: > > Reinaldo> I just noticed my sentenced could have two > Reinaldo> interpretations. What I meant was: > > Reinaldo> - Nonce should not required for those deployment where PCP > Reinaldo> Server and clients and under one administrative domain. In > Reinaldo> others words, the current spec is enough. > > >I'm concerned about attacks where one device in the administrative >domain attacks another. > >Section 17.1 talks about cases such as a guest network and a corporate >network both behind the same firewall but have different security >properties. [reinaldo] I skimmed that section (-24) but did not find this case. But in my experience although guest networks sit behind the same firewall as corporate users they are : - In a separate security 'zone' - Hosts in the guest 'zone' can not access hosts in the corporate 'zone' - Probably those two 'zones' would be server by different PCP Servers (or contexts). Therefore a guest could not inject a spoofed PCP response. If it could inject a spoofed packet (in general) then the enterprise has bigger problems to deal with. >So, I'm worried about attackers within the same domain. I think the >nonce is more important for the simple threat model than the advanced >threat model. Given there are deployments with differing trusts and security levels I would prefer nonce to be an extension. Also, I'm still trying to understand the impacts of nonce on stateless PCP clients and PCP Proxy. Thanks, Reinaldo From fred@cisco.com Tue Mar 27 06:53:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0621E81CE for ; Tue, 27 Mar 2012 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DAjOUcbxavvT for ; Tue, 27 Mar 2012 06:53:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 972D121E81D1 for ; Tue, 27 Mar 2012 06:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3697; q=dns/txt; s=iport; t=1332856395; x=1334065995; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=qav1xOlTX3Rcf008obBT+s4V4wsWzoiIx1jKQAFJOVo=; b=dhUm7n3pGQqot0Z8Gxx+Yg1XFSXyvUjEfVy5wqqQXJT052FWMdtnpYMT 1TZCMEmD6DQHL1LVCycNDyc0RpZEuhmXkTASJG2wg8rjLbet8cDqwnyMp AqygdG4gNSEgOf7uzI4g2cvUKa+CF9fuvG37Xp7lH4JARE56WF6XiSSGA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4JAGrFcU+Q/khM/2dsb2JhbABFtyoEA4EQgQeCIgEnMQ4tfRQ1h2gLmn+fE4pjhiwElWGBEYReiFaBaIJpgVM X-IronPort-AV: E=Sophos;i="4.73,657,1325462400"; d="scan'208";a="69454056" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 13:53:11 +0000 Received: from dhcp-5155.meeting.ietf.org (ams3-vpn-dhcp4280.cisco.com [10.61.80.183]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RDqcoh003675; Tue, 27 Mar 2012 13:53:11 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Tue, 27 Mar 2012 15:53:11 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Tue, 27 Mar 2012 15:53:11 +0200 From: Fred Baker Date: Tue, 27 Mar 2012 15:50:36 +0200 Message-Id: To: Iljitsch van Beijnum Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org Subject: [pcp] You asked about multicast scope X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:53:18 -0000 Please, if you would, open = http://tools.ietf.org/html/rfc4291#section-2.7.=20 scop [sic] is a 4-bit multicast scope value used to limit the = scope of the multicast group. The values are as follows: 0 reserved 1 Interface-Local scope 2 Link-Local scope 3 reserved 4 Admin-Local scope 5 Site-Local scope 6 (unassigned) 7 (unassigned) 8 Organization-Local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E Global scope F reserved In the specification of which I spoke, we wrote: 4. IANA Considerations This note requests of the IANA the assignment of a set of multicast addresses as described in Section 2.7 of the IP Version 6 Addressing Architecture [RFC4291] from the registry [v6mult]. This set of addresses is referred to as "ALL-NPTv6-TRANSLATORS". One address should be assigned for each of the following scopes: Link-Local, Admin-Local, Site-Local, and Organization-Local. 5. Operational Considerations This document defines a set of multicast addresses in several scopes. Operationally, the choice of which scope is appropriate is made by the administration. A reasonable default value in system configurations might be Organization-Local (e.g., all NPTv6 Translators operated by the organization). However, a large organization might well choose Site-Local or Admin-Local, and consider that "site" or "administrative" domain to include the set of NPTv6 Translators advertising a default route into a specific part of its network. You asked about scope, and then jumped on me about zero configuration = and default scope. I quoted myself incorrectly. I said "administrative = scope", by which I meant "admin-local", and in the draft I state = "organization-local". I actually think that for most users, either would = work, and one could argue for site-local. The definition in RFC 4291 is Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration. Site-Local scope is intended to span a single site. Organization-Local scope is intended to span multiple sites belonging to a single organization. I would expect in most residential/SOHO configurations, they are = equivalent - they go to the CPE Router and stop without going to the = ISP. The argument *against* organization-local would be that it is by = default "all sites in an organization", which is probably not the best = possible choice in a large organization. That said, I would expect a = large organization to be willing to configure scopes. You noted at the mike that I was irritated. You were correct. You = demonstrated knowledge of multicast addressing in asking about the = scope, and I answered you very directly with what the specification says = about what scope I might suggest. Since you are an expert on multicast = addressing, I expected you to understand the answer you were given. You = didn't, and you chose to use the opportunity to dump on me. So, a direct = answer in the language of and pointing to the specification you were = referring to isn't deemed by you to be an adequate answer. I have little = choice but to refer you to the spec. I would be happy to have a = conversation with you on the topic when your objective doesn't include = dumping on me. From alper.yegin@yegin.org Tue Mar 27 07:24:23 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC921F88EB for ; Tue, 27 Mar 2012 07:24:23 -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 MXqUNlTa-Op7 for ; Tue, 27 Mar 2012 07:24:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 504A621F889B for ; Tue, 27 Mar 2012 07:24:22 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mg3mH-1RrJ2g2Mnl-00O9mn; Tue, 27 Mar 2012 10:24:20 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <67295D3D-5DC4-4E12-9DB4-6C994E91A8FE@lilacglade.org> Date: Tue, 27 Mar 2012 17:24:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6B8C8EA7-A160-4CA9-A9E5-A7A9A54D7A5A@yegin.org> References: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> <67295D3D-5DC4-4E12-9DB4-6C994E91A8FE@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:YAPCJ2NF5YYtrd/lyTKxYBsjMThvVU1g/6tA7QiJ6H7 54FwDjKIj/DTY2wr2oJdwTJD2h9BVmjEnh9ZoLFKO+RSJC6zkN VGC6SYDqfM57tpWlFnl2qMxrUft/aWz5WyON0xltP8dAOviXsM HNG82kCU0bPzMML70WTUUOnfYxR9w/C8nlgfKcB7btoK9pe3i0 bdKCJibGzSD/QVbhcBw5vFdi/g2wvgYj+PjcxRqhmTJb4N5oay CpUpxAPpg/JH41MyTZH5ov4huRxGmRO0RfuNWYepdURkda+WCW yZkshWXTU+EUhLeWnKKEWsrF9eA9V9IOwpCD5UO6eM6Z7+orD5 6kac3/5c1CLfz5Qa+ov1G1UNhOV5+8/fwPSfjmj7b Cc: pcp@ietf.org Subject: Re: [pcp] Embedded or separate KMP for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:24:23 -0000 Hi Margaret, >=20 > Hi Alper, >=20 > On Mar 27, 2012, at 2:03 PM, Alper Yegin wrote: >> I recommend separating the key management protocol (KMP) from PCP. >> Bundling the two up is a recipe for unnecessary complexity and cost. = (I already elaborated on that, I can further expand if necessary). >> I don't see the benefit.=20 >=20 > You and Sam seem to disagree about the relative merits of separate vs. = in-line key management protocols -- you seem to favor a separate = approach (like IKE/IPsec), while Sam favors an inline approach (like = TLS). =20 TLS is not the right analogy, on two very important fronts: - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven = by the fact that some other protocols need to use TLS as a "separate = KMP".=20 - TLS is basically "transport layer security", something that sits below = the protocol we'd be trying to secure. We are not doing that. =20 > Hopefully some other people will join this discussion, so that we can = reach some agreement about which is better for PCP.=20 >=20 I agree. >> So, I recommend draft-wasserman-pcp-authentication-02 is split into = two drafts: >>=20 >> Draft I: Integrity Protection for PCP (defining Authentication Tag = Option, etc.) >> Draft II: EAP transport over PCP (defining EAP Payload Option) >=20 > Given that the draft is 11 pages long, and that anything that = referenced one of the documents would need to reference both of them, = splitting the draft is not appealing to me. Is this the guideline for hacking two protocols into one? If # pages < = 15, keep putting more stuff in. > If there is WG consensus to split the document, we will, but we do = not need to have two separate drafts to discuss the options we have been = discussing... What benefit do you think this division will have for PCP = implementers? >=20 Using shared secrets to provide integrity protection for a protocol is = one thing, (e.g., IPsec, SRTP) =20 Defining a procedure to put those keys in place is another thing. (e.g., = IKE, TLS with key exporter) And they are distinct problems, which can use distinct and independent = solutions. There's no benefit in having hard-binding between the two. Sorry, = reducing the number of references is not an important thing, really. There are other ways to put the keys in place, such as using other IETF = protocols (PANA), utilizing network access authentication, CGA, dynamic = provisioning schemes, etc. There's no benefit in shutting these down. Is = there? Alper From alper.yegin@yegin.org Tue Mar 27 07:39:19 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9770F21E81B1 for ; Tue, 27 Mar 2012 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.374 X-Spam-Level: X-Spam-Status: No, score=-101.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 SIVp5xjK4hT6 for ; Tue, 27 Mar 2012 07:39:18 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 634A021E81A4 for ; Tue, 27 Mar 2012 07:39:17 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MSN8d-1Roamr2qNP-00T6Ad; Tue, 27 Mar 2012 10:39:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=GB2312 From: Alper Yegin In-Reply-To: Date: Tue, 27 Mar 2012 17:39:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <51DEB05C-AEA9-4B14-849E-EFA1B6764B6A@yegin.org> References: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> To: dacheng zhang X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:EYnRKVax7JsExsKMu5J/L34tuIW7fPPemPKbJBgdZt3 J0fj1dUfFA1Cp2m+E5XWsxPbhye/ZLZNhQ2jN756UTtKZIJz2L ajMofCO5oSVZMp0BAyOXrWdwMxf83J9Wb9N8Smgo0xTCvtVG+M MpudgveT6TqBUyaZsoTsU1QmtBeZRioX7lk68gEX1ATSATBt4A Wxq87W7Ayeem/BeRG/m6DfIrKcH9EXzA5lj7KSBLS1WlYHLFoX 4JGBOQFgrO/vhhZnryGvow0yOjsJgzrGxzeWTubfss2PtERcqF K8OuXhEicZmyXGtjIPHeHTuyqA7Eodt0k1NcR0Q0Nb/gyUi0aI mSeMqfrDea4sDTbXwgxbFjbbbwTJIjwO+6XuY8qse Cc: pcp@ietf.org Subject: Re: [pcp] Embedded or separate KMP for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:39:19 -0000 > We would be very happy to follow any decision of the WG. However, we = need to be very carefully if we intend to select an existing kmp for = pcp. My proposal is to=20 - treat KMP as a separate issue,=20 - not bundle it up with the PCP integrity protection.=20 - have a separate discussion on KMP, - decide whether we allow multiple KMPs with the PCP integrity solution, = or one (in which case, decide the "one"). > For instance, PANA does not support for MTU issue, if we intend to use = it in pcp=A3=ACMaybe we need to discuss whether it needs to be = extended.=20 >=20 PANA transports whatever EAP method sends (whether it's fragmented or = not). And whatever is provided by PANA gets fragmented at the IP layer, if and = when needed. So, what's really left as an issue? Btw, now that you are proposing to define a "new EAP lower-layer (based = on PCP)", can you please confirm if it satisfies the requirements stated = in RFC 3748?=20 Alper >=20 > Dacheng >=20 >=20 > =D4=DA 2012-3-27=A3=AC=CF=C2=CE=E72:03=A3=AC Alper Yegin =D0=B4=B5=C0=A3= =BA >=20 >>=20 >> I recommend separating the key management protocol (KMP) from PCP. >> Bundling the two up is a recipe for unnecessary complexity and cost. = (I already elaborated on that, I can further expand if necessary). >> I don't see the benefit.=20 >>=20 >> So, I recommend draft-wasserman-pcp-authentication-02 is split into = two drafts: >>=20 >>=20 >> Draft I: Integrity Protection for PCP (defining Authentication Tag = Option, etc.) >> Draft II: EAP transport over PCP (defining EAP Payload Option) >>=20 >> I support Draft I. >>=20 >> Draft II requires more discussion. Defining PCP-based EAP lower layer = is one approach, using PANA is another, there are other ways to get = crypto keys in place, etc. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >=20 From yoshihiro.ohba@toshiba.co.jp Tue Mar 27 07:53:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158AE21E80C3 for ; Tue, 27 Mar 2012 07:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, 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 K1Z6vBch+Hou for ; Tue, 27 Mar 2012 07:53:56 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id EE7DB21E81A8 for ; Tue, 27 Mar 2012 07:53:55 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q2RErsEn015155 for ; Tue, 27 Mar 2012 23:53:54 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q2RErsMU004383 for pcp@ietf.org; Tue, 27 Mar 2012 23:53:54 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA04382; Tue, 27 Mar 2012 23:53:54 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q2RErsFd014964 for ; Tue, 27 Mar 2012 23:53:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q2RErs6A004948; Tue, 27 Mar 2012 23:53:54 +0900 (JST) Received: from [133.199.17.158] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M1J00MFITDPAW50@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 27 Mar 2012 23:53:54 +0900 (JST) Date: Tue, 27 Mar 2012 23:53:36 +0900 From: Yoshihiro Ohba In-reply-to: <67295D3D-5DC4-4E12-9DB4-6C994E91A8FE@lilacglade.org> To: pcp@ietf.org Message-id: <4F71D470.7070702@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <961B941D-F565-4305-B8E8-FC31BB0C7B2B@yegin.org> <67295D3D-5DC4-4E12-9DB4-6C994E91A8FE@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 Subject: Re: [pcp] Embedded or separate KMP for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:53:57 -0000 I have an architectural concern on defining application-specific EAP transport (or what you call "in-line key management") because it would advocate each application that requires keys to carry EAP by using some portion of PANA specification in its own way, which can easily lead to specification errors. Even carrying the entire PANA PDU as it is in application payload would require careful considerations due to running a state machine of one protocol within another protocol. I really don't want to repeat a similar time-consuming discussions that happened with EAP over DHCP proposal. I believe the right way is to separate EAP transport from application as much as possible, which makes application protocol designers to focus on their own job (i.e., application protocol design). And as I already mentioned, I don't see any major implementation cost/complexity issue on separating EAP transport and application. Regards, Yoshihiro Ohba (2012/03/27 21:23), Margaret Wasserman wrote: > > Hi Alper, > > On Mar 27, 2012, at 2:03 PM, Alper Yegin wrote: >> I recommend separating the key management protocol (KMP) from PCP. >> Bundling the two up is a recipe for unnecessary complexity and cost. (I already elaborated on that, I can further expand if necessary). >> I don't see the benefit. > > You and Sam seem to disagree about the relative merits of separate vs. in-line key management protocols -- you seem to favor a separate approach (like IKE/IPsec), while Sam favors an inline approach (like TLS). Hopefully some other people will join this discussion, so that we can reach some agreement about which is better for PCP. > >> So, I recommend draft-wasserman-pcp-authentication-02 is split into two drafts: >> >> Draft I: Integrity Protection for PCP (defining Authentication Tag Option, etc.) >> Draft II: EAP transport over PCP (defining EAP Payload Option) > > Given that the draft is 11 pages long, and that anything that referenced one of the documents would need to reference both of them, splitting the draft is not appealing to me. If there is WG consensus to split the document, we will, but we do not need to have two separate drafts to discuss the options we have been discussing... What benefit do you think this division will have for PCP implementers? > > Margaret > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From phdgang@gmail.com Tue Mar 27 09:04:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8674321E80AB for ; Tue, 27 Mar 2012 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 2kSnhWfBW4E1 for ; Tue, 27 Mar 2012 09:04:15 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DF0AF21E8040 for ; Tue, 27 Mar 2012 09:04:13 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so34639wib.13 for ; Tue, 27 Mar 2012 09:04:13 -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=PyzH3KcjkWHTN4mVyInKLF8rfaYUWTJoHzlps2TIMfI=; b=S/RUNDdsSXG0Tocrl7T4Nag4RZVDqEivdp0rbNLKEb/45ASJ52FfL1NyQCc1XxyhHs wM1fLg0w/WGozGeOp/WK82fe9wMlbMGmwjgzX/is2w0TIUdOFkMiO+atndWZpM3PcBjC i2ob58Xf3ot4eoeG3jaGtX7b+iOwXmS9/dMGRBfKDeNomtzG8Vux0p9Rj/2Pgm/yspX/ RaBJ9auqYVHur74NC2D1AFABnU2C9owP+0kzz0tPKjQxFIjaU23UhnERxmi3icu9DPB+ Qtfp+pFSJfD/lD5oh/o5BaDwIh8bMbd67s4xW0pXUm0Zibz+u1D/1fo4uSBTqcriN1MO a1Tg== MIME-Version: 1.0 Received: by 10.216.139.12 with SMTP id b12mr4816627wej.4.1332864252933; Tue, 27 Mar 2012 09:04:12 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 27 Mar 2012 09:04:10 -0700 (PDT) Date: Wed, 28 Mar 2012 00:04:10 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" Content-Type: multipart/mixed; boundary=0016e6d6257454797a04bc3ba4e7 Subject: [pcp] Is it the right place to document something for PCP in mobile network X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:04:15 -0000 --0016e6d6257454797a04bc3ba4e7 Content-Type: text/plain; charset=ISO-8859-1 Hello all, Thanks for your attention on today meeting for http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-00 Chairman encourages me to launch this thread due to limited times on the meeting. As I already stated in slides (see attached), PCP in mobile network is attempted to be a work item in 3GPP. But it failed because 3GPP thought NAT and Firewalls are going beyond their scope. Considering very particular environments of mobile network and goals of PCP technology, it's of necessity to document something either to encourage PCP deployment in mobile network or raise specific concerns from mobile network part. If there are no such considerations, I guess operators may struggle with transplanting PCP into mobile context. Very typical case is when doing PCP discovery, DHCP may not possible because lacking of supporting in 3GPP network. That motivates us to raise the question here. Otherwise, it likely would become grey zone. BRs Gang --0016e6d6257454797a04bc3ba4e7 Content-Type: application/pdf; name="slides-83-pcp-11.pdf" Content-Disposition: attachment; filename="slides-83-pcp-11.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 JVBERi0xLjQNJeLjz9MNCjgzIDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDE0NTY1My9PIDg1L0Ug NTkwMy9OIDgvVCAxNDM5NDYvSCBbIDU1NiAzNDZdPj4NZW5kb2JqDSAgICAgICAgICAgICAgICAg DQp4cmVmDQo4MyAxMw0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwOTAyIDAwMDAwIG4NCjAw MDAwMDA5ODIgMDAwMDAgbg0KMDAwMDAwMTExOCAwMDAwMCBuDQowMDAwMDAxMjM5IDAwMDAwIG4N CjAwMDAwMDE3NjQgMDAwMDAgbg0KMDAwMDAwMTc5OCAwMDAwMCBuDQowMDAwMDAyMDE5IDAwMDAw IG4NCjAwMDAwMDIwOTUgMDAwMDAgbg0KMDAwMDAwMjYyNSAwMDAwMCBuDQowMDAwMDAzMDA3IDAw MDAwIG4NCjAwMDAwMDMyMzQgMDAwMDAgbg0KMDAwMDAwMDU1NiAwMDAwMCBuDQp0cmFpbGVyDQo8 PC9TaXplIDk2L1ByZXYgMTQzOTM1L1Jvb3QgODQgMCBSL0luZm8gODIgMCBSL0lEWzw2MTVBQ0Ez NERGNTAwMzEwRUIwNjJENkFBQTQ2N0E2Nz48MjM3REI0QTM0QzE0NzQ0M0E2QjVFNDI5OURBMEVD NEU+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQogICAgICAgICAgICANCjk1IDAgb2JqPDwvTGVu Z3RoIDI1OS9GaWx0ZXIvRmxhdGVEZWNvZGUvSSAyOTEvTCAyNzUvUyAxODk+PnN0cmVhbQ0KeNpi YGBgZmBgqmFgAZK6DAIMCCDAwMrABhTnKOBMOSDIw8jCqO+yt90wui1fhoHB0iv5+VKwMmYBRU8e h1YVQyaRRc4im1k4JhzhaDyaqjaj0FQ0stjPlsWz9NnhRLUWjsY7KRFJjV+uhKaetfgiqHp9Nk8g kwoDg1IDAwcDQwMIuUaATWQvB4KKjgaoO0C88o4OBsEGdEcAgSkD497NQJoLiJXBIkoMvMwGooev MTDENqywY4xh45p0QIRhgX5Qx2dTfmFHBwaRlq/z5iw53KjBEKDhIMLFkMJ6QcWBiyGAqUEE5nU/ BiZFdiDNBMTWQBzEwKT/FEgzghBAgAEAq8JBNQ0KZW5kc3RyZWFtDWVuZG9iag04NCAwIG9iajw8 L01ldGFkYXRhIDgxIDAgUi9QYWdlcyA4MCAwIFIvVHlwZS9DYXRhbG9nL1BhZ2VMYWJlbHMgNzgg MCBSPj4NZW5kb2JqDTg1IDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDgw IDAgUi9Db250ZW50cyA5MSAwIFIvUm90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUuMjIgODQyXS9S ZXNvdXJjZXMgODYgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag04NiAwIG9iajw8L0NvbG9yU3BhY2U8 PC9DczYgODggMCBSPj4vRm9udDw8L1RUMiA4NyAwIFIvVFQ0IDkyIDAgUj4+L1Byb2NTZXRbL1BE Ri9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgOTAgMCBSPj4+Pg1lbmRvYmoNODcgMCBvYmo8PC9TdWJ0 eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDg5IDAgUi9MYXN0Q2hhciAxNTAvV2lkdGhzWzI3 OCAwIDAgMCAwIDg4OSAwIDAgMzMzIDMzMyAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2 IDU1NiAwIDU1NiA1NTYgNTU2IDAgMCAyNzggMCAwIDAgMCA1NTYgMCA2NjcgNjY3IDcyMiA3MjIg NjY3IDYxMSA3NzggNzIyIDI3OCAwIDY2NyA1NTYgODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3 IDYxMSA3MjIgMCA5NDQgMCA2NjcgNjExIDAgMCAwIDAgNTU2IDAgNTU2IDU1NiA1MDAgNTU2IDU1 NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAw IDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAwIDAgMCA1ODQgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAyMjIgMCAwIDM1MCA1NTZdL0Jhc2VGb250L0FyaWFsTVQvRmly c3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNODgg MCBvYmpbL0lDQ0Jhc2VkIDk0IDAgUl0NZW5kb2JqDTg5IDAgb2JqPDwvU3RlbVYgODgvRm9udE5h bWUvQXJpYWxNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzIvRGVz Y2VudCAtMjExL0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEwMDZdL0FzY2VudCA5MDUvRm9udEZh bWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9y L0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNOTAgMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxz ZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTkxIDAgb2JqPDwvTGVu Z3RoIDQ2MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlkkk2PmzAQhu/+FXMEae34C7Cv y36olVKttD616sElTkKbQASs0v33HZvQJlsQGsAzr595x6t6LKEZQaR7bDqyen4VsBuJrJg2UArG hYBCc6gkhyGQLbl3ZOWcxHy3JRw0Z1wCnQMHKSVTJQgtmC14Ae6IOTtCcZljgmvmVyw+k29Z7ccw wuv0tnmnOZWVYTZ7yQUTWf0CD+F06N+PoZsg/+4+EwUUV6zV4B5QdJGKm5xJ1naw7n+0hwBfwnTu h1+Qu5+YJgyWmUhmS4a1srDY00w216soxZPIZvDbiTb70NFTc6LHJEg3f0Eo52z6PUVl9EAvHgjF bNwmBQ5KGFaC0oppe7Eg7nPp+dOjewKjUr8lM6lfnfmhHe9g7QeQXMjU77XLUgPFB7WNiIORgjNR XXdR/TPEpF6efbeDGlu5g5srwlsmS1mgHDq5zGOp1jPmdUm9b3OqkLVDaKYyn6yefx3mEBIyRW9N VcRBaYVxkef247i+IhjUvv8Al+gMM+IG7oqu/J8O6ohgs32OnmTt/JFI9YX0MP+7MOIhK28Ql+lc n81s3e/9MWzgvn9r/Ma3w4X0afBdE8CFQ2j6Y8R9dOSPAAMAZjq/gAoNCmVuZHN0cmVhbQ1lbmRv YmoNOTIgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDkzIDAgUi9MYXN0 Q2hhciAxMTYvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMCAy NzggNTU2IDU1NiA1NTYgNTU2IDAgMCAwIDAgNTU2IDAgMCAwIDAgMCAwIDAgMCA3MjIgMCA3MjIg MCA2NjcgNjExIDc3OCAwIDI3OCAwIDAgMCA4MzMgNzIyIDAgNjY3IDAgNzIyIDY2NyA2MTEgMCAw IDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCAwIDAgNTU2IDAgMCAwIDI3OCAwIDAgMCAwIDYx MSAwIDAgMCAzODkgNTU2IDMzM10vQmFzZUZvbnQvQXJpYWwtQm9sZE1UL0ZpcnN0Q2hhciAzMi9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTkzIDAgb2JqPDwvU3Rl bVYgMTM4L0ZvbnROYW1lL0FyaWFsLUJvbGRNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdo dCA3MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02MjggLTM3NiAyMDAwIDEwMTBd L0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9U eXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNOTQgMCBvYmo8PC9MZW5n dGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0cmVh bQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10 Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsA jdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0A QBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX 1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuU DQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHB wUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2+ +M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1M rsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au 8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqAC JuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyD j8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3Q CqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14H D8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuU iHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCG cI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZ NE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g 5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2Ew GG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXG krBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3 mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovL Fs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvb etpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSd xmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r +sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5q r61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzq EB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHsh N8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy /cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/ TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21M u73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/m MfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdW Lf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPq QXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOp Zkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xx bGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXv urEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt 2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuv nByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+Co UqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUT tYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C 28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC6 0TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynf r+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO60 70DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+ 3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1 LjIyIDg0Ml0vUGFyZW50IDgwIDAgUi9Db250ZW50cyAzIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hb MCAwIDU5NS4yMiA4NDJdL1Jlc291cmNlcyAyIDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9i ajw8L0NvbG9yU3BhY2U8PC9DczYgODggMCBSPj4vRm9udDw8L1RUMiA4NyAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDkwIDAgUj4+Pj4NZW5kb2JqDTMgMCBvYmo8PC9M ZW5ndGggNTA3L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZxTTY/TMBS851e8Y4IU106c j15ZULVIiEpY4rDi4E3cYjaxK9ttWf4H/F6eXWjLrrRIKIpf8uLMjGfsxY1vYfDA0uUHky1WHxls fVZ1hPfQMkIZg4ZT6CoKTmWb7LXIFkJUOF9sMgq8JsseylOhwBglvIVqyUm/pA2IGedsM0oopR2I Ad/EMctvTXB23A9BW+ML8RXbVU9oBeWpIFDPSIsslJOq+w1EWlY3EeQu//GhaBnPDzhWhOcq1WXu Um3OfY21Pn89pn988Vm8i4Qc2ThSVYxHTsbpFRXqTVRleuyj6rv8Z1HWPSV9vi5o7uxBj2qEwZrB qaBgVLvJPs7KBJjtqDxIM+Itp0evPWgDJ2KyrLsGSrS2wyrenMjaC9kyWTTbez0pMCocrXsAZQ7a WRPRo1/lBaZmVzDVBaa50swIy0XBcjk9oGJ5b/cB/E4NeqMH1D2jUg/BwvpmDUENX4yd7Pbxj1F/ J1PTjnT8STKUsvocL8ZTlNHyKl8VDO2ycnrmeo12M/7c9RdWcFtQzNZsrJthJ13Qw36SLgWgnPGw cXYGCU+ce8n15rIlZfQjwH+a+x6ldbkN+iBDpD5C5E6pR08/rZIK8eqfO2tVxFEZ5eSkvytQ33bK aYUr9Hj+ttKN2mwT5s5JPD/YT9BvRfZLgAEA21X4JAoNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9i ajw8L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCA4MCAwIFIvQ29udGVudHMgNiAwIFIv Um90YXRlIDkwL01lZGlhQm94WzAgMCA1OTUuMjIgODQyXS9SZXNvdXJjZXMgNSAwIFIvVHlwZS9Q YWdlPj4NZW5kb2JqDTUgMCBvYmo8PC9Db2xvclNwYWNlPDwvQ3M2IDg4IDAgUj4+L0ZvbnQ8PC9U VDIgODcgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSA5MCAwIFI+Pj4+ DWVuZG9iag02IDAgb2JqPDwvTGVuZ3RoIDU1MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K SIl8kt1u0zAUx+/zFOfSQYvrfDRpL8eAAWJTpUXiYuXCdU5Xo8SOYqdlD8L7cpzSBZCYcuHYsn// D3tx40pQDtLpc8pEi9uHFJ5clFW8WEGZcpGmsCwEVJmAAaN99LaOFnWd0f56Hwkocr5eQXIeBKSp 4EUJuVjzcimWUHe05ykSXIgwUzSrTxG7s14fpdfWuLj+TovZiosMkvNAmFXKS9IQBc+q35iASAMi mX7zAHpkP+OkTHNesOs45SmDzc0GHvzYPMMnjx0cZAP9YHvrsAFtIL/dbGA3eoi/1Z+JuS7zEhKK Wa0zqN9FF/RFJZvs7qVuseGc71DJ0SHcX9cgTQMf9IAn2bYO5IBgrA8aIVH95owqX1DU42TYKdsj bNlHe8IjDlew+XJ37+Ikq1Z8xXSc8YyZo22PCLIdUFISf0DSnBxfuMXc5X40ampyGwflZA6VZ+kc Kvsn1Et1OatjQdIHBDUOAxo/lbiTpOl6VHqv1XRVgD/6Vivt2+dX61vOmc/1dcQMBkMQ2KHBvfY0 sfSgmlHRkvQeh+e/iqtmSDlBFAHGrp+MbJlDnGja+MESJCy/nn92Jco/87OvsWAY+i9C80jvRELf SvJFDtEoOw7yCaHBo1bo4KT9AVp7+l8Fj+wSZ0BHZ8OZAOp2E5mqPWtVTMVkp2StDpVvWWd39Mrm a55SE6jTRrZXIJujNIoYDo2zg7sC9IqfM7+vo18CDAAuGAaQCg0KZW5kc3RyZWFtDWVuZG9iag03 IDAgb2JqPDwvQ3JvcEJveFswIDAgNTk1LjIyIDg0Ml0vUGFyZW50IDgwIDAgUi9Db250ZW50cyA5 IDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NS4yMiA4NDJdL1Jlc291cmNlcyA4IDAgUi9U eXBlL1BhZ2U+Pg1lbmRvYmoNOCAwIG9iajw8L1hPYmplY3Q8PC9JbTEgMTAgMCBSL0ltMiAxMSAw IFIvSW0zIDEyIDAgUi9JbTQgMTQgMCBSL0ltNSAxNSAwIFIvSW02IDE2IDAgUi9JbTcgMTcgMCBS L0ltOCAxOCAwIFI+Pi9Db2xvclNwYWNlPDwvQ3M2IDg4IDAgUi9DczggNTMgMCBSPj4vRm9udDw8 L1RUMiA4NyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0vRXh0 R1N0YXRlPDwvR1MxIDkwIDAgUj4+Pj4NZW5kb2JqDTkgMCBvYmo8PC9MZW5ndGggODE1Mi9GaWx0 ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImUl9uS2zYShu/5FLikUhEHhwZJXPoQu+Ite+0aVfnC 9oWioWdkayRHkj3Ra2zV7vPu3wBFirOpNXpciQRCDTS6//4avHp2qNXqoEz8d1hti6uX10bdHgrb VNSq2lTaGOVJq8Zqte+Kz8XTRXG1WFj8fvG50IpcFVo1Tx9aGaMrqpVzVBmnvVrc4ze3ha605tEK o8VDUV6vuu1yv97NFl/wxJKa4z9YN7ZyWFpTZZvemi2JLefxa8P2H8p/z+ZNQ5Uvn8zw3JSbh+Xp MN9t1ZNv3zbr1fK43m0PCuN/fuv2y+Nu/6+DetMdH3b7r7NPi1fY1IToePqADzpUjpQhPWw9H/eO 30La+j+zuW9wyvL32dxUbbk9HJfbo3rdHQ7L2059LF9fv/lVvXv3q3rRsRsfZ2q5vVFv7Vu1jM7N 5lSFMrqoojOmMrY28KWy2li1eJ72s+Op67T1x/Lp+rjY7ffd9jib26ZBALq/7tZ/rI8HdbxbH9Qf 3d3yB2/gyvVur26+79fbW7W6233tFCKx3t0cPs7ipvNx11ablndNe5nhwH5yYFMu+MChvNsduouj 1OVypuFICvlyj432u5vv/Rxvnw5ZV8bjTHrcaQytSzsd7pebjbpZHpdq91l97bpvy836R8dHDdh/ eVRL1TvvK82yGUN24fz80vt9t0GofyRvuujp5qRWuz5tEEenjrvkIkJiyCQXz35delhGn9Rmt72d s2M3avHsLa+17Vbx+I/07JznarjU8/xSSr2K6/IfrGJbng98SMm15cPu++ZGbbqjOnQ/IOSN2u5u OuR6lzw57perrxwrjtugJc9xMaHxfyelGJbywmcIB4H9tjzwt/3u++0dPrv7dJRHVUIaAbeTKplq xrhRMzWMyusZl8oRUY7l+OL91Zsni74E/0d6flhmWmsey8QADeu8nrmqKV/yUyrfx/UWv/Sr2GGV erKKjc6YcZEnb99ypFtTHro9wnuI6/y2KP4sjFqrwoMJgZT1ugrA4H3hoRDwyTdt5YJRGzxwlZuM USA2WrSeH7xXYGpPWR3/MWX/xOFd1WLpimXC+0Dh+IN02qo12sP11X1x9fu9Uc93xbv/Z+FtVXvt bZtvUVcUNJ5kW9S6csC5y/eqRgOAQhCtbIsWzQbnyPeqgX745D7fwlc1Tm5NvkWoPE5u8qPbQhI4 uaF8C5Q65zzbIKAv4+CuybegqsXBncu3aKuGU55r4LStUGXeZmvEaeiQM56tEYfbBWrLm2yNOEOV xsFNtkacaarAGc9Oh7OmanByna0RZ6FDnFxna8TZUBGnPN8r5yrLWs8WiXNNvLTZfK/QBwLnPN+A hHhzACLjzeQLEUCU4c0BiIw3nS8SAFGGNwcgyvDm6kaINwcgyvDmAEQZ3hyAKMObAxBFeHPgISdD 5ys36Ig3nS8SABF4o5CfDgBRxjcCEWV8IxBRxjesL+Qb4coi4xuBiDK+EYgo4xuBiCQoQAIPZXQj 8FBGN3K1jG4EHMroRuChjG4EHsroRuChjG4EHjLddP7JwUMZ3ah2QroReCijG4GHMroReCijG4GH IroRcCijG7W1kG4QiOzyRsChEG7AIeBDIVsjkBPDjdrsbHjgUAa3+MYmghu/wcng5oFDwI2abI1A siK4oSiEcEPhMdwoZGccVxcZ3PDyx3CDGLMtgEMZ3DxwCO2ipvItWiHcPHAou7p54FCz1PMl4oMQ bh44BNwo5AsXOJTBzQOHgBsAlG/hfwI3tDpYGLR7WNRWWeRj0gLdz02QEJaJbQUm9bQJZpigQ7FQ nMAxXNknSskxaad9MMMEWZloJcfETzthjkmYqiXDBI1q0gtzTJqJXjIsgond0DUCE4rt0DmBSTvp hz+3cGhWk4aYY1JPr/sZJri9T+77OSY07Yk5Js20KWaYoGNNumKOiZ/e+XNMQuyLTuAYbvGT1phj 0kwv/hkm6FyXzTHHgqTcc0DlpD1mmACVQu45oHLSIDNMgEoh9xxQKeSeQ/8Scs8BlULuOaBSyD0H VAq554BKGfccSDl5C8gwwaV+8hqQY0LMPQqCtACVQvARWCkEH4GVQvBhByn4CHd7IfgIrBSCj8BK IfgIrCRJSRJIKcQegZRC7BGu+DLsEUApxB6BlELsEUgpxB6BlELsEUjJ2NOC44OUQuwRLvpC7BFI KcQegZRC7BFIKcQe3tOE2MO7hxR7eOGUYg9aEV73CKCUUg+gJH4rzJcLpMXUozY/Kx6gFFKP39+E 1EMxSqnnAUpQj5p8uUDAMuqhSKTUQyky9Sjk5x73HCH18BLJ1IMy800ASiH1PEAJJaPIBCatlHoe oBRe9jxAqVn5ArX4IKWeByhBPQoCGQOUQup5gBLUA5cEJv7vqPeuuHp2qNWza8XwwR8+26al+BnQ VK6fvcGir5RRX5RVD8po9Vp9+KTVTWHUWhVctw4berx7oHbvC48bT8P7IamIwqa4Tm7pygf8tWoO HTr+3rCHKJbG4LtR1rqI8qEt2eTi0wXMsSibpg+YuZa/UJNuV2pxX+CbBqAXK/x68VB8KF+s991s XpcPS/7/ZjP7tHhVzPFWFSBn/OZ5MWcb3P9gU75++X62+FL8tkgBWR0QAE3OOHhZWcde6Yo0QqMO q23BHPUU2aj51BTwXtBizG+gBp8oHIq0bfGeeCrA6Iqox6+ajtIsH4fHbI2gtDyN0Br1A9PEi/M4 xGmUfh33ojQiO+y8KhhYbcI2Dsr32+ErMkPn0aqI6w2z09EpnrCux9nHo/H0q+LzLwi/Re44SC5Y Fh80zXI6B8skF9sQNYJvJjWj4I16NEx7EzdRBoPBRApXiyP2Q57UcTU+Byo7PXA+TYNxPLQurXb+ vTE87VmfPPQxuvyA2viAA8hN1fI8ul78uat8HLVN2gwqbfsrQZruhzakzXAVj/kP0dVBFrw3bzaK 5FFYTimMeCnFHLRW28ZzGFGMJoYxLppUY0wSXVoM2rzYqPbjRshPo/poXuQujCKI3T0+TLq9HJ0e b7lJLnry7CE6AxcjNGXArrOH7fmSkRys3CSNPmUx9FlMaeIS6dPYDnmLabzIYmzd4wO8hFWWhiEX SVT3MI9hrwIWBReFudxteIAPl0qORcCvnn6sTwS1iT/u6zOw3nmk0yk5b4Np2+sRlz6gY5znLIzz P6L6LwwuYlz7NBxjuPq5KAyHmD09R5zRMYS8Sac8i7kvDTgwxLwPWhvSz8cRx7xOq6UHaFEX0zgI ctC0F9PDMFY1MhDzed6MH9g4rg1PpzpDxF0fRdNGD1z/a1/VIzBx001BMU0apvrhZhEDbttxFgHv 6crDFPCWLuZTyKajGMA+3KZua+6ALgkcVyZc5hLJBrbwERP3e12lkj4HsK8fRMzb4cGj4SlGMIzT HDE7iJSHLgXMmXMA+wcUkqZZZ2BPY1IjYIq2scX1EaQxpI+Gp8t5P5kO/a9dnYbDanqSEEfnFJyK i5jboKajU0xAGCdNWnmMf5/4diLJJJtHw9PlvPWTed1M4M8JWhV3xSNlofvYMUqX30/FEFHqJ8+C pXCRnUHPQ/Ki3C+KwU1SfcbbUFtuUmnu3Db+y361I1eS40Bfp9AJFMVfkTyPYsd6csZQRN1+QSQA Alxt91hj9YzRSrAeQPyTbj4tN+Ywr77fXOeq13P3Fkpc0jXSe0SPnzhrjPMC8nD3i9SZtObuNgcf Pp+un3aAJ+bCrp0RKqn90OfccL9gWvSIpLGHJCF9NJQ6ssZsKMKHf3BjBN6ciADXecXK7ryHDvic Bl+rhK66ZtEgWgaOS3hl/hb64tHD42j1hh0HiPNk2iJ6DltsnTYfF56ZJ0F1BiKEB4sv2nmALkJy gwif0yAicPOIlSgiBH3sLES43GiYVYjiAR9WOPLOQoTPaRBxKFxINO+GVEJTqnZJph2EH3PYDw6I 9Vb9eYDPrjSi381VGuCz7et5gKi0mZ3+AJ/TIcS5oRdpphcOcwPXyPR8QhgdRJjacOcBrvOuytyf z2EHli9UiUWXxkLbwQ1oK1DfIkSRT38eIMqcfZfYRYiFMtyxRzgtLnMRPqcz8G+ClTXzrzODlLkU EO7HI7OJhQDh//TnAeJ87SWiN/d8j+jZtuXUI5y26nQH+JyuoDewbrZ3JMjDLAT0GHPTU4+eN2Vu aj9CrMnmzwMUVrMnfkB7uuivI3xOV3QCttvK+ostJNcWEeIGzco7oj0X9NSj5zQG+zdzRNr0NoDX W2SS4x0uOAgVqbKKiuON9vilz8eevkDPYQuV273tayAb+HVA2u8wu/9EOS7+oDeO8Ak24PH1gRgk sSolJ1Y7CDV+sGBdg20yjf2ENprcTQ4n1imzKFLEy8ZYakocHRJcvIwyBoV8TjPzwhqoDZ/LkKXn 30T01rKmm+jnd+ZrFtFeUHz0ACqsPGM81v4effyUDXPfrHy9t75YkD2XSGBhSj1YAR1eIITkG99t yMgcPDKH7PmB9+sOkoSUyH+BsuprKmmG1HFcRVxbnmbnd7g4s6r0vv4HhargyDc/FLA4ZdveQgAc fPYPiOA12HIQiwthKEmMG3pOcyhhGf+NLw/6UPiTJtN1oz389dQjN/yh7IDPaUwbOAf7uuvFRISy uv15gM7HZtlw8DkN6mpvt0URMUhjZyFCrCDmG4jjAbH7085CQM9pDlHIeJMQ7cAN6NoVjyfUQYCO COIHB8Qka/48QJxPvKeqNKuDz7ZfrXvreR7s19N+cEip+ooSTfPcJMh12AAIyG1xOfVIOKjpiug5 LCmFKtXHl0pTnoy3PLQchIqxf3BA95LQ8wBxfrv4RYhOSf48QLwLg/102g8OwccB4kiFjfjeWF8d oyLC3Yz4PiJHQ+XUo2eTXxp1yZFfQCG//jxAnHvb92Hbe6I0o3vfCBenP0IwleHPAwQLydt+QGBZ d7bTgKB7urhGuAeM6r6j7uCJTsBute34oSxGj4SDDav8gByDk1OPnsMSbFNebVdh+E7eZNfE7N3I eUbNIq8uBzEUZDPq6HXwOazZ4zX7CxAnKU5FhK7x5QoRojBT3R5E+JwG9fkx8U1vQuNyvMIlPKbs NhKW88kaq2MWuLByJtIl26kncIUrbjfQHqNYRX89wUR07pIaWXYNd0kFn09wva5E5MLNR2eeUqux qOjmpyydCVeESpLAc4uEmahLcHoq8mldugQdnndQrCIU68ohThLWS5biVHKNUgPXdL5ggYhAI0Pw 6o6LTmGIxKquj9yvNt9J/8zppn9bof+EZ+X16iz5ZrZIRO59vv/9n7e/6FcXpbV0+jyXltfP69Vp 1io9I45bCr0Rm5JtslsqGemrfJZXPQjEkvzkdep4rauqTK6z9ebMid16tyB68Dp1vBCCtigpzStS OOjfXhMRF3aFFFIzrotmYRjXWimloHDDze/5f0ziJ7nK0lGl7tr3KhL/RV0s3+kQwbYiP9n3iDd9 /T63nQOxbjslt+vN+U/SS0Hm219JSVfDZYtEgKvOC/pitPqT16FCksui1YtB64VX19bqBNAqP3kd Kn6bWrw/9JZf+hJbWUhdDXCtpI/ZvGC1kQjwk4Qnz8uUukum1b/uC7ypnA4ROCv4ibtHuOnvU0uq +u3aNv+ztqV09OzbNs3Qol0LTARk5q6+Z6MCpFVku2eXUtef/WgFUborPyr4fVZJYehXGhG+TVZs fB8Bu2bl73cnQp+7cDtalZIzwoVF4AZCO1o13FE8+kViFr/lOiR+3pdTJmiyjvlZVllwpyCoFCMI gg42umQTatBz61dcio13E9RU38kmKJJi+wlt3K6GnFIUAbYaLbiPJgtBBIUXEcZZun8S0OyUvkmc GFrpyWNKlwzEa3G6HwSDN+e6GVJJ2WgeE7XpiosMbnGWiV8UyGDTn5jgsi9SVGoRPATa3fYTLyj4 Is9DsL/gi+0syNW9IOpUXFMITuLp7wQXc/0d3xMnW1FIEPWL7nQRgNG/LMn/KxhM67AqE+FbcwpM RdCK/4HUzaKdzOlQ6amgZnltqcB5cjP5c4LCFOt16gCbJUbJnyR76C7cqR29c678RLDj4TXglZCk 3pJMPsbr1WRz/j4FZfiQ6vKY4v+iEhOCPlVwQzC7CrhWdt4m6i1Jgy5BAUe6TMAtnN2Kuir7cp2C apmc8Hb0IKia2iWQwfEOblIYtlne7QpEmYXlyiWHuwKvsCk5W35dEPQWHLV+X1x4NdIaGbQZwY0x QtoAVx5cSysdn0d6ZAqneV9roVDR3m0NYdqu+c8Q/jOE/wzhP0P4zxD+d4bwL6lw/qhcrKD3C7ds ggU7o6Xum48nvl9zsI7CZepg3qefb0vAiWw873RcE+wJsDFqE19XDrcIdNo7OHBaRfkNaxAsWIf7 /F6pcsrlcavH/ePO7iqDa0Eu+sndlLO7+eBUOrgS6RydnEgJFLfvMPjweYnnDuK8DhfIAN3v1X6A OE8+snIddVauu4MxNLRZgiGBX4PVhepqGuk1mVPlxtDJbVASA/hp29PO68cI6FBeoFyNF3UNV5OC 21lHRapnUq7qN6p5ZzHjJhpWncwRpfNjLX0Hn5/Od+d8g3pIOwzeP18sKIYXqrIpOrqJ2sMwByIH OBndTbsjG17oBmzSWXNDl4MhzYH97CBHdZy9NKyXWoScov15RyOrdSmYDe8Rrs572q4+OO4b5WFe ozbbcGEYnG+E8OHjMVxMDWpMTaDquyEcd3dTs6WwHm5OHGfxqyGIKQFmUIM5Q5v02Cbd2oRj3l2b 1Hh+VQdp6dSgnRonO+tVaQfupqVUbfJWn3+rzFYC1AwVF7LsQ+rgmP5bKemQm1D/L+2JUXlTt6I9 4QTqh8Bv9jPF84LzKqOwchZIkOV8eNiUwaRkUTa8kDBEhSOHr2/wLj1HWzjY6vG5+ALjNxMZgygQ gagnEdS028bBe0NrGwvEieaGaJvkdHn0vLnP1ZTALEFX5bmEmyw/vzcTv7gYF+QUXVboY0OEpUHQ G845qAol6IBIkbB0Pc8eytNra0dnmHWi/9XdzcpHc2QFlqQTQsoM7sbp2UXKYCta4658pcZ5FRDD 17GPrVSqLZpuaJMoEqS5m9HBjNMSSBQJ6twkysHG6DZ3ZzaBkiiC3ZEogXvw2zlIlIMzKEcdmHKQ KLsKSJTATaLEFSVRDvbb/N4kysIGTiNwkyB37uAmURbIAMPvS/z9uu73mzNY5yZR5qxdtwcSRYKp PbWcbfxGsVAB7u1AgjL3diDY3CSS073A7XMmUQ4dyosqz2mTKLuaFZxeXSvyTptEmd+o5l1/OWYR z1kNsqLr/FhL38FNoqRXfoC7kT49p5IXjnEqwbrnCJbkOJVgbV+CtRinEmScivCdNqdycAL2wKlE oPvbQQ7y/lxaS88xFB3sI3wOTmXnUj9pt9qGthzMMZ73DuVhQdicyqLCJEjQ5lTu2MFwruoP2MPN zFjfpErQt62ikj+uuUkVQW2bvKFrmxzbRqEEPbu2qfH8qg5idTjtYBdmHbvC7qa1NAOpMs+sNO8U oFZXcUHKZ0xDEdvfz1nxkUUNNvV1CmzJAToWNeSqwqIAHYuiVDbHohQKixofc3NVw7awN/wv49XS KmluQ/ffr6jlvYuu9vuxTM/0IoGECdQuZFU0E4aphMyFBv/76GVbcoYQmubW+WRb8rEsHbdgRkvD n3ZRURvmdAxv1t51LCKaGO4mtLYmYqWpBGuKmRP1DbdsaitXvWFpDZ+uBLZsXXHgK5JejWyCRhKV bII2k5Vs6vdgZRN/WCxOKCzv4XIK2x40FNm0h4tsmt5FNs3YVr70NdzpM1z5hlsfWye1dRd+H5Z1 dVS+UlJ/eVzu5h2G+Yn/uFuOjRLRQ5H3Lt8eLxjz8+XuzoV+ezyvt29/+fL++OX6+rg+//BRbs+P GxjhisUKP0LMMMzdk6vg7eP5zyv1jPUj+TTfH/ABaMUPJAB7heoFUu8eaV8ZhB1UlORZXR4Q7QFV BX5AuYl2qDc4v1H2ZdChGXCgXprxEQUo8mL4divL9fPKnjIGP+DLC6FG5V4WAgohUpfWhwMO2lhX 5hMpFqizAlvVZWQr9gBhQdzQeeNiLdLwxOWmNyYNdovZYCH7htRNznG29Eg3oYuiAIj3AL/KViLd afjjKLqE164HonRca3xghY/DAo2W1woYKn+gt1D3pF9gFXbuKIUgpMJ1GD5g5sOH5tkucLpLWJvx lBJzRb+L+MooCunMOhO5iRnMYyzIAmRdCTUjjw1LPvPIqYIPGU69kDgdPK8lmejr9BXSOiWEpagz LCgQdELA3eZDoNU0Gsb1rxxnxu05mO3wrgEJHnbGYVasLZTU65JAp9PnSZTt88xMf5/HKefVxdyb Os/suRrIh+y5uwiEO0OZvs1lni4+2PBSyOmzN/UBrxzeQLwHDmptNBeWFcG6sPxgQ3tui6c526/3 H9DYimK1YTOa8DvdhKRZr+xOXpeWyOf/kR8oZyjaRTz6W8SnO/NOOl7uyXowTaKjJAhkRlqQefdh fcie9a1A5J3V07IvWD2fg2/KHX6IhCNVRocdI7lCkSKREILr0qVXYZx11GG7QVg6Q8c8NaI9w4ZD WHY8hdgWZNpbUvbF2wHjpt2XViKWN0536KehCuvMI+/zdU2WZzlZNObINC7eKIMsHJpGthd6N0rC EmuFaHN10cgfQlb5XTghoUegYsU07JNIZEaYPeBYdti7i9su+S/HAigzz8Fxeu9j8Wmdw7gU8c2b c5j2Rm1lmv/rGEJSx7ASVB6LFg6dwD0rOxxM3enOx/S8/kHRY1mTzb+oFuAbTdg64LgUua2blA5Z ndTO8OMGsORaJ7kPXu7fzpRuE2c1FmsOYe3uu0rDnpWZg/l+1oYD8lGIEilir0HBfYPiPHkXfu8G FqYKPpRm7NJBsmdhMzNpllmvks6ci9y//6HKYEkWCF2uYPb0PsK6V4h5AwdNQOxJzVqEVnfnokmV yaBxOvsVEwmm4ksOOe3kHz6UQmPoDls4Zn3adgP53lDq8oIHHKdDimFW5xUDfMhp+7BwEEdemTWa DM3VLBqnM+Yg8KExi8yBiDg6AwsHTXCbxwOiPaIOW8dg4TgdcgwwedW+F20iccPjNDCQSzH5nMXS QKYoa7uBY6ZZhDbN8tzAsf1Pu4Fsx2fSWt/AcexnshyoS8ZFMipxl0nMHpBJDNpuINtLWgsecBz+ MALSJE2RjMmpWD3gXGLt0SC+CbUos4Gc6ZRpQqGFfFPK5vyA0oG2wwOOczvMccbCnFybaQSsiAjE t+4BOca4xlvE+69JmQ1ke2LFScXIwrG8L7uBaE/0pFjrGzjO7XCtgCdB0TuEDzFsHxayJqlF2Q1E +15N/+aWmZVNI163tc2shavO7OkGjnMjsw7iM0dS/EU+/L4BBnEEeWf4AVeJ2HYDx+mOIwikVeGg 0qrEdCuT7NJAXgOFDqzhxK7g7laJHpQWjdMdZ7Bc4xUBjMZuPpewUJUBicBCztES9g4sHKdDjqGi GsIx/FxdebhjoDdhlIudeHiQl9Na0ovLJF3YUx0r/Obr9Gh7kjfG9PSAuhnTHo0qo9BSjkdzIcYP PTKjqFXA4xzeCXVR2I7PI7HIhWQrXEPpQWn3SbrSO9qIl+rR6Yk4xQZMD0W1RZkOkL3BujWtDwgd z2bWMtXjzZKQGu/RMy89qXMSX8AtK9IZC+8Nd5bMxlfcJLr8Df9NheVYoaQ6FZbjMKO0RgXHnIAf miStgtzaOk9wnk9MwXE65IyS3tBoc6/dG/pqfgqq3sAfDqh6Ay94wHE6VHdbxQAf6g7BIN5FKMps oNplk8pg4DjdTQUQN5PEwj4G9XtMBTY5PCDf6qaOQKNxOmLfjR9EherCi65G5RfQlMoKrso2Jxxw q8xp1kgUaqFm7kVeKTi292k3kO2xqOUNHOd2ppLPXPnaUvLm8hsolbEpu4GiUsNa8IDjdDgVVkyK ZXyL9cWqRWO/NWSXFqq3xrQbyPakWLaQb4kL68MB+eFY97EdcJzbmQrLsb7ofSosKtigd0WmKrhu 4pxwQGbZJ2U3cGyZXLgaWSgyOSi7gfIWaWp9A8e5oalDut4i4KRCsJCFRlchWMhCJagQLCQJdlcM GcSznSLYQiUi5nQDx7GbWQn7vgmiIdVNsJA3KH2TboKFRgWx3cBxOuQYduNeJHtuhzUqvRjPbYJv vU2G60FGDTOuB9mE43S43r1Bx+DUAs7MnkPFu4WcpX0Hb9A4HbHvMuOPS+d15R3m7u4+L5WnM2SF xe2iSqjYGqpnlZHL6hQkr1SbbbONVuncVesXrsLopigxFUioLSkVl9rpcwdZ1BDH30TNqO2RtJrK ztOIF9XwtmUGzE9NtcMydWBccklkCD93kxaGpDGLYSjJEThZLajkIsmpt9Lm+bBwY17CYknFTerq y+NyN6Sn3T7xH3fLsaH6C6HDmbl8e7xgzM/XJ2jKDoh7PK+3P399f/xyRaDX13wDQwKvjx8vHAIU wJC/vf3hp5/e8z293d7//vgTzi4xdvByD67WOVjGfnz77fs7bOnt228fNPzr4/r8w0e5PT9g9Ub/ WQSmnvH0cqskm1/rQ66kL6msBtgDVN8oBAh40kMQdjaNISGXa6ZAWRlG84figY7K70aYXBJSLysL eF7iVrDENGceMRPx/0be4fAghTuwEhzkHv10nKDwvUBomMBALrh4XZ//+Eq3H/91/ZUmB7cme2zG ji8FLFLyLdcKuehyyDIx74lY87yvIPg/QYEGKQgzAyQ5LAXnkys6d3l6LGoiLB98w0ypKlrsDrV3 pAafI+DVz8l1TwbKUwxA5yeodzHPyUgxrIT0NujpHvbaZHLjyZyh6BRzExu5v8UKd6Jzanr46jg1 4D0F1Z4Syof30qHWvMWZTv8RYAAzhe48Cg0KZW5kc3RyZWFtDWVuZG9iag0xMCAwIG9iajw8L1N1 YnR5cGUvSW1hZ2UvTGVuZ3RoIDIxL0ltYWdlTWFzayB0cnVlL0JpdHNQZXJDb21wb25lbnQgMS9X aWR0aCAxNi9IZWlnaHQgMTAvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NClVVq7tVVe7uVVW7u1VV7u5V Vbu7Cg0KZW5kc3RyZWFtDWVuZG9iag0xMSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDE2 ODMvRmlsdGVyL0RDVERlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA4OCAwIFIv V2lkdGggNzAvSGVpZ2h0IDY2L1R5cGUvWE9iamVjdD4+c3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAA AAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1 MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4j ICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIAEIARgMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAA AAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUH BggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMm RJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKC kkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZm doaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APTG05oDZyGkgEOPpxJP0T9Lsl6ObtI+ 0NnYAD6f53d30vwVleT/AF1/xj/WXpf1kyumdOfVXTjlrWg1h7iS0Okl3xSU+n/Z8oF5Zc1u8tIi sdgA6fdrKl6WXM+uI37o2fmfufS/FeJD/Gp9d5j1q/8Atln9ysU/4zvro8wbmf8AbLP7kqKrfZBV me2chpjdu/R8z9H87Tb+Kb0c2I+0NnZBPp/nz9L6X4Lyir/GJ9bnfSub/wBtM/uVyv69/Wd/N7f+ 22f+RRoqfTDVmEGMhoJDQD6fBH0j9Lv+CRqy5JF7QC4ED0+G92/S7+K5T6n/AFn6p1LqbsPNe2xv pOeCGhpDmlo/NjxXZoKaxpzdIyGiHEn9Hy3s36X4pKykkpYcLwD/ABgCfr31Af8ACM/6hq9/HC8E +vDS/wDxg5rB3tYP+g1GO480HYoq6+mfsuC137Q36HXbtn4xx5K01nTv2ZW1lbhn7j6jyTt269ph X68BzsBjBiwQ8zk66z+b8laZiuOI3G9BoLXbvV7ny4Vjg23+bXVgOXe6GnZoirpwwKzW6w5s/pGl o2AeRn+Ctvd0/wCw0ilrhlz+mceCPLX+CtnHsdiMxvSaNhLvUAG4z2JiU78a12OyjY0Csk7gBJnx MSj7Y7ne1HL21sJf8Xdu/wCsr2+FNs/5zF6gvJP8Wdk/XHJr/dpuH3PYvW1WO7YGykkkkFLDheG/ WZrX/wCM+9riA05FYJPH0Gr3IcLwP68bD/jAzfUEs9Zkjy2NSU901vRqP0l+VSwN7F7T+AKm/rX1 Vx4D8tjyRP6Nrn8+bWwuGbV0w/4IT8T/AHopp6eANrAPmf704Sn3WGEHuG/WD6oFgccxo8jXZP3b VC76y/U9jNwyw8/usreT/wBSFxvodOLBLRPxP96FdiYBZ7WgHxR4591cGPs6n+LC+u76+Z1lRmp9 V7mE6e02MI0XsS8V/wAUYA+umSBwMe0D/PYvakxepJJJJSw4Xz//AIwmu/589RAO0mxsHjljV7ke v9CAJPUcUBoBP6evQO+ifpd1xH1l+pX1R671a7qbuuVY115a21gtpcN4EACXSCQOElPAV4WA7pwe c4Nzd8QXDZt/qxP4q0cDpQ6Ux7epNPUC8hwLh6Yb5DmVvj/Fd9VCQB9ZKjJLQN9OpHI+n2Ts/wAW P1Ua5rx9ZKHCC4AvpILW8n6fATuLwA0paIkfpE63/Y89fh9PZ06p9XUQ7MJ/SAvaWRrw2AR27oeX RgM6ZTZRnb81zj6zC4bABxAifxXSO/xYfVQkuP1kpAjeffSAGnv9PhL/AMa/6qCZ+slQ2kA++nQu 4H0+6YQdNTvf9i4Vrpbn/wCJ2T9bryefstk/59a9sXBfVD6sfVT6r51mbV1qnJyLGnHAfbUAJIcW wHfS9q64df6EYjqOKd07Yvr128x7uyKm+kqH7f6FE/tLEjbvn16/o/vfS4SSU0+x+hwEjz+ZyP8A X4r5wSSQ/R47fQ5KQ4/M4K+cEklP0f2/M4/1+SR7/Q5C+cEklP0f3/N+l/r80h2+h3Xzgkip+j+3 5nHy/wByS+cEklP/2QoNCmVuZHN0cmVhbQ1lbmRvYmoNMTIgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCAxOS9JbWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29tcG9uZW50IDEvV2lkdGggMTYvSGVp Z2h0IDkvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCu7uVVW7u1VV7u5VVbu7VVXu7goNCmVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmo8PC9MZW5ndGggNzgzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiQAAA//8AAAA////ycfJjY6RVFNaU1JYhIOKxMPE4+PfdHN3ODc5MC44MzM7KyosJCIrIiAm LCszbG104+Pj8/LzfYKIR0hYNDREKSYzIR4rHx0pIR4lGhge1tXYRENLLi9DLCs7JiQyR0RHPDxL T1RqNDdMHyAlOzpGPkViOj1VTEtVHRskaV5lqqmsWFhlfn2CtLO08fLvVUlJZ2JfZ2Zr6ubnycTG uri5GhQYLCYp9/n7OzElwrq7lZOT2OHm9Pb6paOo1dXWxcfK7fL57vH1hoWJws3YUU9ZkXyBnjM1 RzAqd1gpsocv9Mcp88Y39a0jvoMfmGcjckwiJBodbikp3cPGjSQibksjzXwc89VJ8uJX8ttP9MxI 85kc9ZcduHYeTTIfVh4dpzc2sHFwsHyAyj5BSRkY7Zkj87o38uRi8tpVil4hqikptkZGmSUouz9B uTc1uyglNxQaPSoo86cl9Lgm86Qdoh0iyEZFq0pNxSQe2FFLs3Ig6pUa24kachoW2EtFo2Zoxzs2 nRwexSgj1zYqGhcg7KMq8qwe9LMeGRYc2ischkVGUxwh1C4k5GddVUEkbysduTIk509C2js21Cgc riAe2kM6y2ZfqVVSf01GmFU4z0Av5VZJ5kMs6TEb5kg4NRsm4y4a6i8a61RF5zkm5zAVkG9quSMe 5i8WmZuk3L3Dzyket7/KTlBcjx4g4TAYzMvM2uPr4+nu0tzmpzQvt6uq3dbW7Ovr5evxunlY0c7R 8O7x4ubuzdnk6Tcp1Wln6u7z1Nzpy9fh8e7uucDF0HVw2YmC+Pb13+fx1uHpwJyg0lhQ3Nzc7vDt oKqz6NLFzpAsP0BEQS4e26Zy5cW28sMf9Lwe+d14+eSN99Rsnqi023sX0Kyct10a3qAbtmcXs1Qr 64kWd3mGbkYc7Iwar3ZZ5noWl1UazGAV1GsXqo+IkTsajV1UrUoT4W8WpmYxoYV6m2dRqldHmYB8 llFGmEgmpGBAwsG/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgwAND1tKAoNCmVuZHN0cmVhbQ1l bmRvYmoNMTQgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxNDI1L0ZpbHRlci9GbGF0ZURl Y29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA1MyAwIFIvV2lkdGggNDQvSGVpZ2h0 IDU0L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIidSUf1wTZRzHXwfCANmdDAbP3TY4kBGc6DAYMI0J LAp0I5VUlKHNQEsEZg4VwhQBBRR/DPEHhQuGBCSxY+lAGTLEgPyRVoJKZhSRv8p+aP7bc2A4UOtv P9vr9eyee99733u+zx2CvOixsbWdZGdvy/pf0MHRabLzZDYbxbApLpz/Il3dnLjuHgAADAcEhvHs XZ+L8gVcrqcXCXAAcAJgkPbmPw/1mcr19fWCXlyIEUwwIfvZMMdv6kv+vp6eJAAE82VgoZD9zKID uP7+UBswiYJizGmagBiRez8DDfTz9fd1dw5EEBYFcAG8q+kjZp7t06zA3RMmgPk5A+AiODjwGLOQ /dRiBKJeXl6eXrZI0ExvEUUhLweHIN4ExsMw9CmxI0qSHiRqj4hnikOJMLG3oy1iRxAURoQLJrKT wUjsJZxZ4aEEz2F26CsMKxRiGDtiPOqKjaCoi1QqmiMCVCQikYTAemFQp6jxbNSoFqeioqVS6AuQ SmWvws4xXucJBceAx/GYI7ITopjwNXsXpnFMnF8fX0JsGDHiBXFz582TyxXy+DfmLwhn2IUoOyHE mn1zUQKPaeziJfGKxKVLly5LUsQrk5XLV8AFRt9SrbRm31alpBJE+BLlqtWJ78C8m8iwMGsWEqlp a2Ot2fSMTPU68F6yMnm9IilxWWKSQpOlhEmeT6SqN2xMt2ZjN6Vl5ySExb2fuyYrXqORa+LXZyk3 L9+8IOyDLWnqjE3W7Na8bfk5BarUQiGYNX+7ZkdRlnL5YooqTlWXpKRkZ+602hK2u9KyM1PyS3dv SqB4hcJZe/bswXjF6/bu05btz9xSvoEMHkPFJLmrfGNedmlOyYHdBw8dPlyRUFGh+vCjyiOVuuzS LRs+JsnQx6hM4E6CXRn5+wu0JSW6ypIqra5Sp6s+oq85WqDdr86Iw3FnQdDjCgReAMdrYz8pK4Ps gao6fU1dpa76qK6yuiZHrZpWiOOkX/1oz3x8UBzgnIadsXmflupqSur01XU10Av/In/t1qhjOI5T PqMbs96HeSM0RksOpX+2rTynoKlJX9VUo2+qKstTrTTQzUYPQFEeziMP9HR3dJTNSMn7fFF6uqp8 X362OlN1aOXxEyaJjDZyKQoHU5jNJiFJZtc0triqy3Rb8nJaDQbxbIPhJD/kFDwrNbWZIUtRqCPj hSykG9saNpa1F5S2nzbB6+FnNNIOSycXp6hCyo6ZAwwKfNoa8su0eq329BmrfsISLJ2okCosLLRj jiHoyQV4Jz8lpb26vf30qTEpo6WNXQTuxqN4M5hjHxIE2gBQbzl7QKvX677ofqKVynp6O908XBBB cXEgM+EI4DAdBFgsXx48d+7sCWu0JcLc6YSeR1y90QsjU0yBfAAu0m1tzR3dyJP7kjXTRrMb6YZM SD1wj6HbLkRL/yUl0R0ttMXYxfaWTUC/ujQXNJotPc0ymVQqkcAnXtZC08berstfL/lm/Avt29wr isMgIMYSQfe0dHS0dDS30BEWmo7xi9vcJ79kvYxI6/b+q9fmhQuumy0WSy/dQ/cyg+Vi+IJLScs0 A99ZszeuXe1PlH+/GA8+FmM2wwuMZovxesCKm0rFtf7+Va1WaMgPqxXyK1c0RYNr4i7/WH8dpt7F 6aebQzv6NPKkpFWtprH2dPN/HlbG9/UVFWUNDg7c2DszODjul1vDw0NZO4qKiuKTb9/hjzXoQiRr 682Bodzk3KHh4Vt3a0UiUeC9Xwd+Gx4azB0aun3/DotvGvOeN7CO//7H/T/vVlTc+2s2i2WwYbGO 1z548PDh3/dr74SGGjhPGu/KiTSIHz3qYj2yOcl34JhMZ0I45/knxayuBhZLbIjkjFthicnE4Tg4 mIKCxgzd3bIQBzhpMnUjL2b+EWAAEYrs1QoNCmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmo8PC9T dWJ0eXBlL0ltYWdlL0xlbmd0aCAxMjkwL0ZpbHRlci9EQ1REZWNvZGUvQml0c1BlckNvbXBvbmVu dCA4L0NvbG9yU3BhY2UgODggMCBSL1dpZHRoIDU0L0hlaWdodCA0Ny9UeXBlL1hPYmplY3Q+PnN0 cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMY FxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAODhAUDg8OFBQQEREQ FB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/wAARCAAvADYDASIA AhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAAB AAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLB YjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1 xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFh cSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD 03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1 VJJV8/IONivuEAgtaCeAXuDJ+UoEgAk9NUE0CezYULrqqGGy1wa0dz+QeK5TrHV7cYCzFybPVr1k uLmuPgWE7fwV23q1dt+JddDBdiV3sYdQHWyXfkCHLzGYkRvRi9+NHwdSrq/Trbxjtui530WPa5k+ Td7RJV1ef/WHNqtBe06j6JHK7bpV1mR0vDvuM220VPsPEucwE/irGbDwCJHXoUYc3uGQI+XqG0kk koWdi57WCXGAs/Pupy8azG9M2stG06kAfytwB47KfV3EVViYa54Dj5eaxsbqTnZn2cuLQDYCNx/N dsHHwVDmOYyDKccKAiBZPW18vbhjEsl+skCvByL/AKv5VZG+wZFIMuZJY8t8N0GPjtWl1J2L1rAp oxMZ9N+MNrXE7BTEDZwd4IA+XhwruTnV1fznvb58/ehYduJYz7RiH2WakHRHk+YlimZZAeEfpRGx 6XTXOGEokYZA8W8Jb/R50dKy8extmfS3KxmGX01v2FwHiSD92nxXe9Pz8XPw68vGP6J40BEFpGha 4diDouW6rmPpIJZLHEAnwkpfVxu/qWV0/e5tFrRk7BoCQRW/75atXmJ+5h93HWQjYA6G2Llrhl9u foB3sainrRlVGo3TFQMB/Y6xPwlJT9Nnp+nA2Rt29o8ElUrJ3Hy9v0v4N24djv8A83+KramWsLHi WnkFcj1zoeR07IrzemVX5QsdYbq2w/YSQ5uxrWh0au8V2KSU8MJ6ka/vdWLJHjjwk+I8C+cZZ67e 3aMDKH/WbP8AyKudAc6rAbXYCyysuZY12hDmktcCD5hd2udyeifV7Iyrbqs441jnu+0MovZBs3He XNsD9rp5iFLysYYeIEkidfg158sd4ys+LznV+s24ocBte0fmuEhX/qtmN6j1Yvx27NmK42WsEgEv rhhkEa8+OilmfVf6pWH9b6w8eO7Iob/3wLpeiY3TcTplGP0uxtuHWHCqxrxYDLnFx3iQfdKfkjy/ CeCHDKW5j6fyZcQzgjjnxCOwPq/NubXbNu47v3tJSU0lFwj8KZrf/9kKDQplbmRzdHJlYW0NZW5k b2JqDTE2IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggOTk1L0ZpbHRlci9EQ1REZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgODggMCBSL1dpZHRoIDM2L0hlaWdodCAyOS9U eXBlL1hPYmplY3Q+PnN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsK CxEVDwwMDxUYExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0O DRAODhAUDg8OFBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7 Ozv/wAARCAAdACQDASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQAB BQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWET InGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N1 4/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcH BgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJE k1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH /9oADAMBAAIRAxEAPwDu8ero/wBVujt2sFVTGtDiBL7LCO57kqmPrVc/pFvVG1MArvFQYZ+iY5M8 on1s6VldU6XXXiQb6XtsDHGA4RtOvzlY7bOj04X/ADTttPr2tL7MwMdsbkkgtb4q1hhjMASDKXF6 h2gNy1c08vEREiMeE8J7zOzqY/1xpzc3ExcSuDe4NtNn5pPZsFHw/rRj29Vt6XlNFdgsdXS8fRcQ fomeCVzHTOk/83Ln9X6uRGPu+y0MlzrbCIaR4D4qyOjjrHWcbrfTnxh3WNuyWOBa6p7ILm687iOy UIYpQuUeD0nXccYOg+xdnM4ZSMc/djxR8LgRqftd7/mj0L9t/tX7M31du704/R7+N+ziUlr7vfP8 n+KSr0zW1svMrxaQ957AMYNXOdGjWjuSs/B6l6NBo6g/08rHBNpeZlpOj2u7jWEs77YcbHN8syNv uGP7hv2di/b8tFnkWx7nZEwezeY9vJU8Iw4dSGvkM+LQNpvU7BXmNyHOpde2y7D3zqwM+iP3XCJ2 rKGb1SpuM+31q22Pr22OLoIJbGhd+fPyV1gf6b9z7o9u/wBRrfH+t4c+SEA31q977924elLWRPl7 lMDAXsWIiZrcPU/nfL+KSo7uofa42VfYfT+nvd6m6f3dkR/aSVSvzbVn8H//2QoNCmVuZHN0cmVh bQ1lbmRvYmoNMTcgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxMDIzL0ZpbHRlci9EQ1RE ZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgODggMCBSL1dpZHRoIDQ2L0hlaWdo dCAzMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgM CQkMEQsKCxEVDwwMDxUYExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7 AQ0LCw0ODRAODhAUDg8OFBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7 Ozs7Ozs7Ozv/wAARCAAfAC4DASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcI CQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCES MQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl 8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQE AwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKD ByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dn d4eXp7fH/9oADAMBAAIRAxEAPwD00be8cDsO4T+zwH3D+5VMrIbS6XGGhgJJ4Ahcxn/Wa255rxnb KuAR9Jyz8nN1llAH5TWjc5fksmYXEadSdnsPUo3bdzd3hpKdxY1pJHGvA/uXCMu6pY5pZVa4yCAA RKLl/WDrNL5vrNLD+Y9hDSPCXI+/k6A/XRsf6LJkIwyQkeovV7FmXivcGSGuOgBjU+Cm4tlp0jfH A/dK5fGyOi59mynJIucJFQdBHDvbuH5pGi3jYfsgdP8AhOf7KWPmzKUo62ISlR30YMvKiE4RqVyk ImJjR17Ob9ZnOfRZj1/zj6mx5juFz+HZTV0DMHTixv1igioXw0xIn0i+G7tsx5rqeqY1F1zHnIZU 8NaC18jTxGiysrpvS3aZWbit/rkA/wDSCr+3zOPm8mSOH3ISNg2Gxiz8ueU9ieQwv1Hh3vse4eE6 39Xeo5+Vjs6HX1G68gOy8vOIpY1/8l0gR4/gvR29V6d0zoWPgdVyWdVza6W13MZ+kNjwIP8AvKym 9F+r/P7Qxo/4wQtDDwOls0xsyhx/kEH8jVclmzkaYDfiQ144+UjKzlnOvDg/HV5v6v8AQrWdQb1H JaaK6iXVVfnEmY+Qldt6jf2dv7er/BCGNj/6ev8AH+5WDXT9jFQsBbv3F+u0acTCrYeXzjJPJKOv tyjEePQM/Mc7HJkx5OKzCcD5CJt//9kKDQplbmRzdHJlYW0NZW5kb2JqDTE4IDAgb2JqPDwvU3Vi dHlwZS9JbWFnZS9MZW5ndGggMTA4Ny9GaWx0ZXIvRENURGVjb2RlL0JpdHNQZXJDb21wb25lbnQg OC9Db2xvclNwYWNlIDg4IDAgUi9XaWR0aCA2My9IZWlnaHQgMjgvVHlwZS9YT2JqZWN0Pj5zdHJl YW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcS FBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQd FBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgAHAA/AwEiAAIR AQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV 5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1 4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9H6p 1F2G2qqlosy8p4qx2HQT3c7yaNSonp2a6uXdQtF/7zWsDAf6m3j5rM+sN32TrvScy3TGa59b3Hhp cIk/et+2306zYGOtjhrBJPw4U0omMMZj+mCb8bqlgNmQPRB0wdSGLHUiw37iAaxALZ9pPmVbWBn9 arzOnXOxDZS+m9lL3O9pDidRoVUv6p1wO/Z9eLvzXaMyZirZ++74KvlycGQxlEg76DTXo2cXLnJA SjKO5HqNaR3lq9UoXWelU+3aX7Gl21olxgTAC5n6uZFx6TmM6jk23W1Z1tO9hO9xbt9rPAT2V1tt 9VebUPVra3HdYxtrpc0wdQQSoxnHuY4V/OEDyJs6/Z3VlwGBmOK+Dr0Pk2aurvuzqcNtJrdfjfaR 6mjm+4N2Ob81o+7b23R8pXNdIe+zq/TX2OLnu6WC5xMkkvbqSunU36Ux+7Ij7GtjkZCV92vnYGL1 DGdjZTN9T+3cHxB7FUsTpGdhsFNPUbDQ3RjLGMe5o8A4rVSUkfc4DXyX1rhv69Unhvx8N3IH1bwx iWYwss/TXNyLLCRuNjSHeERorwxHji3/AKIVlJRz+c8fz9b38GQcXBGvks8Pa+rk09FxMSqymu9z Lbch+ZvMSLHxMDw0UxhVEXOuyXPdk1GpznQNHDloV6z0N7fU2759k88pv1SfzJ08PkoR7Huxqvcs cPn0+rJP3qlx3/WtoYPTcKnLotquc9+LjDFa0xBbIdu076LVVfG+yT+ijfrM/S81YUx3Pezfm148 OvD3183/2QoNCmVuZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUuMjIg ODQyXS9QYXJlbnQgODAgMCBSL0NvbnRlbnRzIDIxIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAw IDU5NS4yMiA4NDJdL1Jlc291cmNlcyAyMCAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTIwIDAgb2Jq PDwvWE9iamVjdDw8L0ltOSAyMyAwIFI+Pi9Db2xvclNwYWNlPDwvQ3M2IDg4IDAgUi9DczkgNTQg MCBSPj4vRm9udDw8L1RUMiA4NyAwIFIvVFQ1IDU1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMSA5MCAwIFI+Pj4+DWVuZG9iag0yMSAwIG9iajw8 L0xlbmd0aCAxODMyL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRX247jxhF911f0ywKS Afb0vZtAsEB8gWEDQRKvgDws/MChOLNydJkVNVn4xX+RfG9O9YUiKcmbeDHgSM2qOnW6uqq69PBN 71jbMxn/+vawePj+nWTP/UJ5bgJzkgspmTWCeSXYqVs8LT4uBFPWcFHXtXeskjrwgO+1YRDUgWsP gWFSWy6ssEqxdr94+GFfs2+Pi78vAL/QMnDhmFQ1t7WMqjXTUnGvkhPBvTWkqAAORae4s5KFmsON spKrUNhItmULI8A36XkQFlyqpBbx/sEOIP09nh/B8ReI4fwTk4L9hb3/WbDN2J787MsLIzWvtWS7 xTtQz8507fgX+LqYJ1dpfdtTsFx9gafBPHuK69uevC6B/mOuLvbZV3px2xm0vuS0RvbZWXpx2xmA 3diZsEjW8P85vGBkh+nFbYdGcPUlu7vYZ2fpxW1nlwL5Y86mBbYvL6bOBLdAkUCREcVKP4WZc7mD NXuBMkMjCCOF6brIC+Jutt7PXRLbjzgczdF/kIAKIXE25orlMpSQPOS2J7gTulbDZ2qBZO6juU3m aFCGMFJnQiCmGgPLvK6mJnPlHvH8DIGA3eAYlebOS6YdUR9R+Bg1dNLQMmqgW2KLyoxPfYZTeJZ1 NQO+UiemGg1dOqaomnEiCkzNjEvtCRQKBlZKxsZ+RWUKM1DJ62qGe6VOVIzApplWJjqS2POUiBGS bgdSkEmBIjo+d2IyRSlEyrqaws6VE40IrL3hDtyk5CHMiTgKJGkoIqIoGFchmeEMTPK6mgFfqfex Lkv+0IOLRISUQYZ4y+B5DQI+7gklNdyZkEepS1KqIIMkHR/YBGFI8byuppBz5Zg4qAKBuxrTgQRf KgI3I+HgkzR8PGSMFOhdVzymMEPi5HU1w71Sj1RyYofAVf279UQ70J+tp4wzcMnre/U0qCcunjIK /KIjeXUywUepS9JbJzNBGNImr6sp5Fw5JbChzNIYpkQcvmKdjEmQhkWugbmvYyvT5orHDGYgktfV DPdKPeYv3U3pTrq+PT7X+8sax5Tujjsz3EXj9uQ1kt+cl0byO0POSOPOZDLSuDNKjDTu3P8jjTsX 7SgWN2M1v2fHckcjwzzYCr0ryJFCeTEowKA0iKSQXxQFDZdujFBeDAoOFTxGKC9uDQNRYTyafL1e PKzXSHi2pqs5UMO1rMKno7bItKkp/yT6ldPCsvUeWs+Uc4JWLVbrT4s/CSEtnvbt+peFQz6iPVa4 z2qv2frbKDZ4ahJb7F9opDcP+LGSpS0eSVoJAL9rQAJjkhC+qDRZxWUf1tVRBUefNULWsKRRKXQk D3M0R2ls0XF4/Jglxr5BaC9CqVQUSuWudlBM4dwGPxb78QYnxvV4gxWyzQWYQse6EJUEBZM0NWkI JsE+XLYWzWJALImkjoG9HENhMLKWZkwt3IK19yzsxCJ7K/G7ydBNfVygfLHAL16nqK8hMCFF5v1A AttwbytjqX4Gq/xSC6TxsI+RAHhcFsHjNYyU3duf1z8uAjElz9wYXRfHqhPChPRYWBqgmKe3nisI DTLS1kkoIFS0xgFanw1slicj8lLl4hH4KwVkFPlE68fw6lP5RNc2WRLaBLHN7qNLhNSq7Ja+k5JI XKNRW+TF6DEpKCCLNnL6bo1fFs/ow7h7qPBr0KBpUdISM6NMF63Tg2y/ePzqM+N1+fmC7i1peDAo NUc3lqHrGv/yJOE5sqAIIy66za0e4ykjoIlWYy89JueGaih5sJFrUrOZLY0Ld9j48D9RCZrGn1tU XKGCfqlKvzTxdq7SBzJfxFlQIb7luGOJOirRKn6V1C+XfzsdH3fdnr07N+du3x3O/SqVDnqLikO0 IDoyxAnPoPuqjJdQ6th6OaU+4b1f/pltus22BdqGsWZ7WlV2ydoPzeHQ7dih6zY9Ox/ZinJCUCEo oWLzjXC4TQC3fOxY0/fb5wMwoNw17Qf2z657aXbbf3WMCK6/SvsJg/vkfd/1ffO8ctwsuxWCvOTs hzPbN7+ytnntu+QXxiNvESeSX7bHw3PXn7fHA2sOG5jsdtvDM3tqtrvXU9cXz8lYzXe+ee2ILe2Y 62Wz2eJ71x9fT22HmLzsOgLuy84xl1mjh51f7eTr5nzuTuANm9f9SyS17Qnd8HrZbV5bBOfT9vzh 92M52t2ma7Gdjh2fRsF8OnUfX7tD+2s+9njJVukDSxvHKnk59SlXyici++9Vhd6Aclz+tILzkHb/ U979CnP0kn1z2Uhh7DGU2jDcH+qSnHqMK7lcrvENx9md9ttDs2PfHbrT8yQ4F0znan+Jqxxmgwuc Wf51JZYv3akhS8C9nI5P23N/A09SNCgUBuNuoJ8SaloBMp/Xf1aVq1F9S+nesO2hPzeHM6MczkmU MrNjn46vu0121DEr3vzmxRt2igGLPnGMlg5TBD1KDzdsY1mSapW60X8FGACMtauZCg0KZW5kc3Ry ZWFtDWVuZG9iag0yMiAwIG9iajw8L0xlbmd0aCA0MDIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJ7JChixtBGMU/cSIiYkXFiBM3ENGDiA1U3MKZjGvgRAMVXagIw4ly6lgqylIThoqyqkSF UFEYGXOwJwobczDn9kRhKw4mImJExIiIERGv0/+hsg++Jx4f78GPiACY6I8NQkDwWXqeDfnfON7P GkePrcCzwLHD0eGJcGiAgL2CU4BDMDgYHC2WC4QOXmdpyIYeiFUeZxyuxKF2xLHL8YvDr7BfVKfx uWUvvLvn+FSIV0az0sXFzyV+c2xzjAX2lfoQVwp8LPA+Pz+z2EkEK6/0dLyubotyVtVJjtcTzKSe S3WtmqXQscSv4Wu4Cm+nmiQus66ftf1sNOim43pFN5ircqYWt4UiZZZiNZejQWt7I3/CRNr4Hjff hT/h6prsHSGieICIvvG474qB1aRBAiy3dxzfFpI0ZzYbtiI1xbtKXq3WX3L80JPLZv01H73skCRZ 2so3miV+ctFMqRZk8GBY4jhzgoiR5+Q4WX7qkiRg57C1vR7wbLF1ST/gscWmwSZyjlwD/dc/0h8B BgBbhv2gCg0KZW5kc3RyZWFtDWVuZG9iag0yMyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3Ro IDg0NTIvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDU0 IDAgUi9XaWR0aCA0NjMvSGVpZ2h0IDI1My9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSInsVwtj27YR JrsoPq2RKzeqncXi7KZtsmzZI02addmjmffe0r33///KSBA43AEHEIRAybJ0CWmKODyID999d3V9 tKMd7WhHO9rRjna0ox3taEc72tGOVtaqqurv6u/R9tuq/jpCeTfsCOeds6oPtrtextGKWEUut0mh jPJ6WPcPPvjOvdn9k/uzmbpv+zmTXpX3ILTdKQN9Ddh8/t3ZDi3v2yq87w7OxP0tOJ+d7cMHi1PZ S8F5b7arK+vLKvtnh+yEraLJzs5Hy+WZ7LSP7DQFp5wKbS3YbhtNO9/HD1efyF4tnLvjZm6wjdrd ZOdd1s6o3VHtZHZ+8bHcsI/aGbe7mdlyWy7P5IZDZedOybWxLZfncsPBaue2E9OidnYeC7a7swk+ NTXY7jGaYTtY7STs3L/Au1o9khsOlZ0Mwq0H3k0PUEQ7v3eY2sls69zc8AAtFo/lhhbOLZAwaJt8 U8Ay4NxBWjTRhArOQ9ROYjvQzqkO0JGdu7BND9CDxZnccNROY/uU3y6Xl3LDkZ1oxQPgdAfk4epU bsjSzrW+7oh2Giu+9f4BGYfw+PNg2NnoK82aEb5RG7XWNLs97JSwGDdJyPv84vtyB9TOq1F8K8PN WwXnBKFRQmPcFAHvBO0cw7f9Zec2Ex5prjLsjMPZ8+3qILRzqoovzQpp58X5R3KPPO0sZhk7MmRD wXZfipEsuz60unO37Cxkn64eyw3XB1Z3blM7p7Ogdl7n1J3lrgk+Nb/u3B9bLJ7IDYfGzjts0Ead zw5NO4O2/2EYAD6LsnPyfHeCj8pm59aTpPwD9PniTBwQBrTzqlB9WUA7U2HKD7ajtrYEmbMP0BfL p9JwQ+ycvBZNXH6Ft0TfHBu5uSXInDvCs9WpMNiwdq5bfu5cOyttaZ+6Ne0E+pAFDD0RBdjeDnc9 /0GEg6idU4lo4kIdiDS0MsLbymyB4pmJZs3wTB0E6ucXP5QbWu1M0sfmXrPrurOiDxX+CbpNawyL IjlU+iAQ0M5apUJJtJtGRFM/gAXbWwEntSI58ZjI+6PlpTRAp50vkvSxafk55JNxJX6qnwrdJjiL VKxjIi+c//hDueV6/pMU6t0u7bRQSnAqHvdkvnV3aO+Q4gmRVmjvILf+dP5iNrt/cr/lSnff9vOY YrLiP28PO8dYYlwecHu2OpMbruc/m4B0yZa4CU6hUuH99sCZGnGHfaAvIWOOL5cP5Ybr+YuAVs6m yWWztJNDVwnvuOsujBEqCG4KO2EIzfrLhZAKdRZkZzNRLstt8NMkM1Tdbd3pGfAfATST+JmdKl93 2hnkZ4BT2687W+DGyOwuDFw8Nxkpt7diZ4NstIy8VeysTGGS5LsTc3gHGt4MXECH24h9Hg62nXY2 Wisbxs3bo517ACe3HsncmCmcA/7qi+VK7qm1s9GMnKzADFjqB1ayToqu4abBbSpt7sgbzKaOhun/ bHUuD9prZ89LxdH17GoLmjlWO0dYDHaBLtlZR4L5Y28wGwT7k5e+dm6Rm+My2xLBVtyMqUzi4gZo gu3//OITedBXbt151fJzW9wcF2wLwLlldiYtILVjnyP1/bl2kkFfOXXn7dTOMenNbdLOhAVk9X+5 fCgP+ipYd27lSv2Oqt6vzDbdshB+fv5IbnDZuWVLXH5VKNhmWGn6euNhqCwxk6ed270SV1ko2PqW sIWlxdUbD8wdWuPNoeW9/upCbtgPdk4XbBPAGnIYyyru2yFoahAXzX55wvgvl1/JU+6Hdk4YbBPQ HMZTyJeDI7uAGTj7JwDeEcTxv1w8lSogODB22s0BfDMYa9P46b0C1gziD9obNJzA0QzM769bvSmj nY2+ptXONH5GncA57kUSHfFI+KBIHraUNOticOJL/5W/7u53IXY2mcVq4oapSFulETTuA+ReyMDd cfPSnVXq6AEj0a7meEL9ZnEpj7aZdjb6yuRmunZ2/0vA6bKzkInZKoSbiRdnZ1qqXS+Wn0pjddr5 8yxaaTOsnJqdheAETD2K4znQKEdbBLJOP2Od3+XqXG58Nf86xJ21vgb5uRXtLMPOeiNqBqmTNSbX zhHcjLi0cM4UswzLZpZnCZTLZeVIdnZZUGqpMuAk6Fy6BbpuklBhX6DYgqlC5VlOL34hT6ngbDlm uNVoviE/E7Vz2rpzjAXhdNkQtjA8RTJhHMWOhukUptw9mk6NYx4Xy7fyZyg4CSMp2zalXoKN2YSN 6048/4MUC+cuZbIoICiyNxZCELI2fHywfOucB229dlpOWp6maeeGV8q3V6pQSQy1UdRpJim1Ave0 j+A9Cj/HGEeRBFwkKgD485kfz89/KefovXY2/eVo5xYs9fOruhw7gxgEKov4j6zATNkpshC1k7yn oRmzc2eCXjtnV5vwMDuv3Yl2Bo1GPo+FQgtuKlg8nNwlcm7s5UVNEUJmv1r9Wp5Ca+dmlMwXWflz PVOJbapvsCWue+OrEBUQSXrlOZIAKkwSSs0SYninnczVPOi6c93ycxyvrvSF/JxMO2tbdyb6hixL 6CLR1GZWVvRYT1+suUDHg3/YfrP4xlulGgS1czTBmlEFasASl1/1gCb6hqxMVuqMp0KuyE5GHfaW P48HVOrR/341f5fLLcZNd4xEPU39gBHRdlg7hYiXYzQ1sf8kP6a2QNYhklqaIWExyvG3868HmSVz d4CSaYxN3rt0S0Ddi3gBrzo1GgqwyIcH+vyJNUSCRqjpzeK1uNb6Zv4Oa84ID31tZdoZyndLaadr CrJALZpCYj/iyV6+9tk+niB6eAojA7nHPaOLWyx/R6YldtOxc5BJymGcwBZlpxNr++cAbhnsDBEQ 2J/QCIRmUm+/m5AxBaMtXail++Xvn8jJdAtny6NmpurOUO2pudkM83gi7XQz283g9LUzFCZD7BS1 V8xrheTImR4gSELuyVLoANFvVGZL6WRJ2ODVGJfSJn+GZ25mi8FW9A1YTATlAkPrnBhtwX1yPAdV UXJRIxB8XTyNy+nFoxA7O+1UPFp33GtoDXql+ap1ssmvLzfVTjfampuknQrlHmp2B7VV+rm9g22F GpgnewZ/NGjvQJ71e6Bj1sRHt5qR+9nVc7ugdl04YzeCWqcwu37uEPxDr51qfNDr795Xf1TaedJe 7a0j4clJ+6O7t5t90qh7/3yiiKqeu3uD7ze5JxYfHmTeg9DmGeDBD4VX7aYCIG103UIhNp7jWJm2 8wOYqpWsDGh0cHqr24PlW75oM6DRzmZt+Gk42fG0cXLXBq9CPA1ufdyi7Az2wm2KhV0XTrGosS7e ppKXiIcr1CwBI2iCQdMC6/TVfx6fP/YOkvrBMluewDZN48klFdgSFtxTwVKDbag/AD32ETwjxCVj eT10TVnXLq4UL0TQCCR4eAK+Aj57dJmGne8wZzWX5aLOT6/0he1SjpuYy+bWnTTv0c8JqRCNjwAm 2g7wM6FuIGEbQaOs5vkoUDcNoO1vUx/iF0jBtP1p9efaxF42CWa2Pt8aktIqpiI7w/5TsbOqYlGU u7JfLAUl3IxY0IGcDYOHQysnC7VNzhj2ZCFHEcLasBPMkv3FvLXaydfQstPRRfqMGkm4yXipc17L z0m0s6pSsaw91HmKkzxK1ExY1YgQ0bNzOnrovKaQGTeLLWqn+QEOrH9ZrNwP7N1u5n+V2MXU1LBT Ih/pNBU7q4BIhtz5zvvxcYSFiGpyTJJcAbKKSayGzvzS/hhvEQwWOAHJWqPke0fC+cDe62/z9yxv 5c9MO9civxg3J9LOfHZSnowBk2qd1GK21uagiA7PkpCFdY0hFiMqicN4QAx+6EjrFn9FVGyhY+d7 j12NzmpdHkqWQ8mR7OwsWztzjeamNctYMEbanJSHTXAHwndAoaaJFInWBlIawqlOqz+vF2+kFUPL zm8V95guqnrTyV3Xs6sAN6X35etOOY2VHNPHjBnNNW16Yt6ZRJYESdOPRFEkl4mxBE6WI5kEyZDM mg3YRKbbVGjhLBVMKvRt4zFMLDjLFZsZ7OxsB+x0khf7BNbH6UeSXgTWhmGSjrH0ByXToIhoOrP0 4z5ZXXqLVbeb+d893jWtTjZ5Wjhd3ZlsiXDGtdTPOMDGP5bBSv2gZjjYjjVCVBMQqLsBkszI5xEz MxyoTYU8dnYvGk8WR/Ez1Tlt60dZKjslbvF2P4Qib8g7aVywrUQE9ahMcEkQQPBIzPUKz97l0cUp mxJ53MLZ5awuP1te9hfTSTm3Fa/G1d5NtTPZwnB6OxM3Qg8iT2STRThJ6OReNiKy5AfjLNdVop3u mpl22kRZPbTa6Wtlg/88yrnUC9Kw4Y8Bqg7saI5F2OnszDCexKmHhpQaoQFs0MRO5jUeCBySgk/T JyQncSOn8e3yAZvO5ExdoYJcapCbs0472/yW5bzI4TbvXTcDnG3omGFeD2wo2ojKM+bnn/OoM1DE LGXqGstGIoQ4HFFMy1ILiMlW6XFwGGwSJ3scLLVV4+Pzf9APMUpbd9pp+UgI1dnMqKr6QzjGqlKR pw0fMyij0f20psDcPLMdJqT1RMT4Oyw1jYwyISSPYLcZ3Dby17wmNU9ttZNku3T1trOdt7/fdHCu XZ3s+al4aH6zGrSxWmt1V+Bg4/pkamcZOOOE5K1OBlPbqIZIAw1/pETk4ZOkqozUHGSCmOU0hmWE 26zln6unNT8Umt//arWzMVyi9JyRl25bn/l6nPQ4iN031s6qtVTXUMNQeOXcBenCTcbUBQieyCCK e43+FGNK2bpGqG1kpXiSzErDq7TTV/Ya/j1/vzY8IhxcI6euvDbvN+eprVcDfjurO4diLdsb1C1M ZWosIXjgxQBJAWQktMQDYH8ptwzQ/ODQ3/Yr/rP4r/M9mtX/69gpMFCyeDGJrQkjjWZnFKZkP8o0 qdXVJiSFhs+qIQZW08jpRIXPhFcWrNHR8M0MXtMRLI31hLg6opu4grpnp9a8GI/c3DZ+NYm16Rjt jOPk+UbwArIfrJVsGUqWzS8J71iKZAGh1QahmpPY/J/9au2x4yiiU1Is90p+TOKNLeG9sSODEEH7 IRLmU8Qn5zuK5CXghMeaNw4hBAIBYsLDhAA/mpnurqpTPd0zPXfu3Z21Urt3Ht09M911+lSdAqD4 S5inTSzHBArQOZif9viP9ey8VOKU0hGy4KTtnJ1NtKrB07nTwTEZ4PACvCuYkECkT/E2YAZjsFVY JDpLg4NXQQe/zcZboaL/+8bJNyHO6AzpLV93XsIa8QXl4AZrUdWuZkyOm9X8rEOoOtCOjtW4KLeZ EWQw5+xno6EVIRKPkVAmWgqQabyFLZIBHFssN7/TnuCsNVgIO4WLhlwqWjcJWVNJW8/I2eycwqly GG70cXZqqkJvW1RgUzh9J8Zj85RtkjcLgw22JuQqlLqXvn14G2YNScLnTstF4N3GaFTg3R3tw3Gz f3UIxXhbObTUISwhQkCsXwjcBl5VZuktc8IlaMBT9lUwlGBUSmOIANgUpyjwmj3Ea+ngTLgI7ExZ J11C1pTFe2Jn04O0XAo5UYcpnHDL1FEnEyshUZ4Cgg2x9kH2vukiO05NOijzOsgTvuXlW9ck4Ee6 h+tYd/qf59hkXuTcuQEtvJmqLxfnzh3AyT5i1Aw54VaUhxBSzyBJmUHyZmDTEDGQU84QN302ZbgT rOBTr7ZXdcawKMmdSTbMG6bVrXLnYGAdQh7PxXWnOlKcA9fgE/Y90M5xjmSqGJRQ8FjNg9gAwGSf sjsh5a3kTo3/99srwE7A0wfbFyI/Xwgc9b+UR13/5mhWTZnj9p3NkWmrhGiOjcCZYoZ9QAIb5sDL BDo3cT8CTKqfDDjwQptxzYkMmhrmYfPQ9eO3Se4dzPjhwXc9L5Wdm80my7Q55WSRnOmrd4JT9bB8 sgzOkpgluoUs+TTWZahEpjEJpDyOnG1OcLa3PF6Cqb6G0yiiGS8eHnzvaBM4cxT1qXLT5lHllbSP 1Zi5vu47Ni9X4tPsRtkiO5M+YSuG0gSwlFGKY/JIGkqdE77m8UzQTN6mW8xFaB8d3uZ22Xv+6q2D d5QzQdkCO22yzFyPUXbYt9lsts6du5BCQzhFMrJ4NWAZliknhlRSEDT4DscVoSy8EicMOqy7vNG+ 62A6StOHB98Xznh9KrnT/+4Ix1j/Kj9R647p4DG+1sKZwBSu84SdCLaDCsXUJyImmQdJ7jSF5ggq Q3YW0cw1q27S+gk3zhsn35JeDgcu5M67G86d4Sf607N2s7lkmvhn2JlXtjViuQpHNmhh3DLYjdSd zEJFL82ncaerABWNAhkLMRhLhoO+3E6g3EDTyrODKTEZYRuGEV3uVP7difyL502sL/114NaR5E2T O3N1J4xfWHc2lJadW8FpuanbGnoHSJmSRKWt9CRp1gBCJVRz2JXvJSGg7OF5kJO1+Lk9PHgHUt0m SFtOctKEjVkyFnk4oYar4AT4lsAZYeOE5CRWaaBFVoiqJUVzOLgMUYXoSQA05MUMTnYs0e2TL/Nm k53pApx3JR/2XAq/npebyMlNqDePfB69E3NowrlNiYd3Lh0N2rbInbPg9GE5xObM0Tuqu/an3hF9 e3f2LU335/zPt1AYFJuoiT6LLRRaJvA0uma+NfpsnHoP4A/aH0qO7+bsV+evPZyXL1/uALvca9ru eDkcL4X2TX/0LT0/++uuXXp1zCbTfonHX07a5VipVimpU0bh/NEXdl5WieYAsi/gXKXtA87TUXss Pz4+ftxdPfZnPPqeU2gK5yk7xZO5GQ49TTuT8afDpjCRH//kp+Ytp/z3s5//ghd4Gt7f9+pqgwvi mkd89JgfkYeGXsxYNX6NSZ2xUtm27hQtIzIiKQ30jpLkVylTi2KVskNKb8XHVMs6etD+UgWaqjZy vzq4h5WYKWOgMEsqtJyj7DsG/WNPT1qTViqjY4um2l5QU1moyDpboNR5vgzFNsYg8R1Orfu70b6u MOIqnhzcA/1NgB6xNqdpNODxIfBRTy/Bc0dwWtwQzdE6sQ6YpAQtPpRWlQa4pE8LGPv2927+Gkdo TfUkstNw0OnRlFtFL9HoqIXU7K3JB9bs0Hwzc9JfO76EuEq8F6UEmMSi0I67JBlBgyapHzNvtC8B 5ELg5CAC+/LJwV1dDmCCYTeFoxR5M7AVo+/+rAQ740aypcEP+FeAaMyM3wl+Y+8yGNLYSPyGf/P7 939DMF3eEj2c9+TdZHgZbiUtJp4peSzXtCM8lwTbJOYoD9X3xFt+FL1CR6a5JkSr4qLc8BzG/vJ+ +3XemAplbz53isOVm9YXQzzzPivguSxx9tbUR9v8sGRu8Zb9yIwFjy1SMmNWTKzZuEDDps4+OPkt 008n2x8+9OxUNCFWJBRNfDNwl2wXSv223Grz5sjYgdSLGLJEyHgzcXwZ4F1AX7WHSOnMUQYpLsEW 8YwxSHEAhHQ3FwNwwoLlzOytoYXKViOtThMCrsXT3pydVWtqzfvJloNChWtN2bCJLxK3DB2WDNmh NUuDrdXsgwbIPsFbEKn2bXO+wZn9dye/VzSxvy9UONZIJ0QhzbbgmBxYhp07Ej9iOwi23pJJUl6G zvTxbDSSlkF6nFbRH7RfkXhCnBf7E7ITvhBJGlfu3AQ7AcL9lCaLg603M81YgUIFQLL+s+Flxurk MH10+FXmH5aeLIXsYM6yIhdSWaTBdBDE1G+7tMXBNprGDd22uM33aPXpeFz2SihVncMi1AfbP5jn k6hrXBDubKR1Bt3CoNSn8zPrbtgJFdlgydW47NbmbqQw/rXjPyqaoO26YHsgy9GYA+o1TYW5ODuT jltydymcImTjOc2b54Vo3bfNiC53Wr5Gt3bB9gAjDqt3xj7jfMtDk4lrbT6aOwm2IPCAFMN6c3c2 tVG2/eLH7eu6AqGni+x0giexaBdsw2cVAYtu7N03OxcoWwkzpEJWti649Ty5Wbb8rOhPxzcdpFGV RB2cmqWJSy6Jsc6xzCUUrom3Sp15O+PcGZYQr1D65PLWmYK6/ccYPhXlcXE+2JqKJ7qcqzK5HSBg cpE50XaYjUC0JNjyGqD8cismpFh5evT24QONMKS+Fzghg5BWpfE+K18JozPJO6FzFmLzIJoxltcE yl4ZWqGC1gj67bbFmEqO/f0kwIl6Fh2h+3mIDz+UNOn1Dm3rYOtgWbIex8cVaNpKs6XVn6++ieJV eRWULenwxBdS1JCFOjQmTcjg3bJz+2Ab15CF7ALAKGbxtApAKhX6ENhpcieldA3PoqOG7MTOtKTJ bYhqWySFUAmgb2zALbluhaZoqhwIPg7KVgOwpE3OnYKmQA3wuAFqZRvBfqeWY6fUUukmdxcPzX52 L55ciYrOMXRhsR07HcsfLlNY1GDJRmSZS2minbZtudkk58rh8aNO+Ck7dOCdC2BYfBC90bayHI6k /vAXhhMUQ/C9FjfiGKxiZmOzNTsbtsrhw+/qseymi2Exnlx7cEPDJy+yv/7Ew+kgagpFEwZCXHXq oFpjpm+B5yJ2ylfzaF5MAyUkFAsOftpJIRnh2wlLyKz3hWfzQu0Z5M3eDJyyg9UFzwOor9w6Bi3k F+qtZ6eKv4H7M62qemkOnpkv7MlydWc2a15A40X43ClJURQe0VMOtqxcMbTqDjCwkG72ejsfdhoR cMEtbs3+8HHbOhCmjCfC6TIcldISUysxSeeieS7sFP23Zps7u78evy9aRKRt//dUCxUVvKk3SMED UM6KnV7TZoRtQe3a3Ol0TfvA4bxMlYCq2v7fwymKYVhMMItR7UMKrcZkrnJKAGpSnDL3+WYnmvo5 sk/vv+pSZvmbUKhwONK6lH3BuTMJllVcWwIhWENL4GSRsPZ4O8uOvRSSeOokIQZlC/hY1LiuGVSN VTDtJl1Gcg7hzMbaNNiyxHs+6BkX8bWTExfDqyWchzO4nhEwuClZ/dtkUAaoDBl3In4KsTbfyCgH qJtG/dBkvHNBjRfTeKgaf+iW2kH0ty7YUtM3ueABP8aBN/pe3953xHYYD0cXRmqLH2THZI7TeJbH TkkhyZ3Pl5Fe2MDaSaG/Y8Up8pbkTm+mYm2Gm3ssTkrsNFNw7jkKtWIfnbxLjJqEypg7/+EUSMpH 0lTJ5pPivirLAomr4XRrk0GLZ/Ni28aXJCq1Y+c/ef9CaTnE06KZo92+yFiArTL+Lvb9fmxiXqXu 2P7swQ0jacXtTz07GUcyZ+OVvXFv0opwloerVbrvnG2L2cXlJSTq4ZS0aVlqvHJ+aBbrzpHhYuwo WjmeFYYL+NfxMbHO0UqMPJyfKTfTHKle2V9mnLSGrXK4ucs5YxW2DSHl6lHbPuOs6bCw7OD8dxVO e5apI9Yk58rhvTll59pt1gxvtu11ka2ISs/OKQedH5LbWFbZrh7PqmwgQ166+ehziqw09WPInRM2 GmfXBnY22F6c3FmYJ9lr/g/cVPd/kmPnAKFRuM5PJGUtx86VoklwtB2EzZSOoffuH77kckzyuXNg LkVzAs81mc2d1nPrtESvDdCLegcajtv2Uy5SDKZZdma4ORptV8XPfO68GDYQ4qrkTID50tU3X3Gk HbLc/2Rz5xx8VoZmKXeu2gZsHGxEYvTiLVEcRIZqn1XlzglbE5oXVNmyFQsrTKfEpAzXHHbJw5nJ nfNsvew8MxSWGmdHRpMG6dLszGtXr7xGPJ4A0Sw759nKKpVssF25xcRIhOw00VUavfa51bbXE2Ub EO3g/O/2rlsZkt6ywXYdsGbZRniQKTOwAVPiU1gUPTu88T++VXa6fO6cAdK64qy3lSvbSMN8HJUM SZArNaoqnoiR5k6Xz50zQFodmutTtoOg6UC7ipqJYTSiyI51RgPxCPr81k1coxyT3OloFjfXz851 0JOSMkOTJKnmYV+CviEYTOLs7nC9y526RMAgyZ1K2yq7MLnzLC1XZBD0UKSi1BuxkQzPSMaR1iW8 rJcBToNBmjtn83N1ZuEs1nF7NOUi0f/ZL5sep2EgDHtuPlBtKUuL9oDElR+JxJEDC/xj2ia2x/Y4 HbtJ6lTvs9s2cTKJnTfzFXmkdf/D1NwExxjK5kxcAFcnMT0Px9MvkkRKcmeHwbOWDrwztBlcjKh+ ZVlx3PZTJopdkbx/RgKKUsm5c8vIuXM9YXlJGoobYtr5yof5nH/qIdnxjjIR7/D67SAKdZbz95wP 8/FIcj6qIvJTcBvEPS/3OKLc63zTyYYvubPknT/uenrdIQTbFdWM2opxCsTj63Vj/LZiJBQGU+le drvv4plnOd8rn1fniLlzAUFd9nM7aY+Yu1noG0Mfks9f9DptBnxy7wwZagk9eT9JoWTxNU+sgk0+ cqVSGFTqeZbzj+7MrbBI7hRrZNYX+vbD1zLWJUwq+5ZWpewaX3cf3sQzn9w7mR/dJ6fl70RSlTq3 HO7o/qLCtKBqaxfxZb8/igeeO3faJMW16cjdkKubNIdRAA3eGgqfbKo2vAh1wh5eP72IB57bO63z Il24FU6KhLMUeSl5N7SZJGHfuhchm6lvMdWp8SZbzp3GGGmU77inrnRPSrfJbw6XI/Z2jD1IVAjl 0/H1UXbQq9kQdE/Hgzi+Ye80lJWxRIJ3qnIneWdzArnYGolh41NYtJz2scspJtdzdHv3zk2uhTNv 7izdZV4TzSVVcpLKOSkJphT0Zd4XFLQh2rIiVuZqlM81vA3uEhNr4Xze70/igSbv3Jac1w2x9WRD FIRjHkhe4uFyLL7yyOu7lcJMh6PZXONKqrREkeNHOdj+ff/5r2RTpG85ORelhg3DdTTjNxu8nDJ8 UvLx64gdP+5YybwIN7B1pv0yu5wcVsUQi7jOVbl3Zp2HjvomY7mrbBuNnMQek3VtR2gkLc+BeKoP RSEn2BB3hWoAAAAAAAAAAAAAsG2MMflePDi7yXm/2mTYnX1iJNxkaRPV8tsw0b3GvXhwdpPLSoTB SROzzMQofgFWMVEtv5GHyGno9nryuzSY3H7Q8Vu2iolq+Y3M4Gotb0C9nC0OrXlq92pTb6JafiNz yNngatUm9cHWZdtJkznkbLhLz3IaaXDCxJBmPXdPbKXIqVl+EjS6ltNIg9N30fjNVuTULD+5iy5s NOFWEM1K9dSYyc3JxSbs9Jq7NExMq819JjfXEpuQZvmtuH6O76naO7ceo+8I/Sn1JvUTW8dkseUD AAAAAAAAAAAAAADAZjBnkh/3GfYLZuvNEOgxw0f8ISrKVlIZPBQj/SjkhHd2iVpOH3zHb8jZIwU5 jc+Z7Mfwf8jZI1rvdCNXmdlh0BWVcvp/yNknqsrWCMEWenZJ3GAOwTTqO31D6vZRCgEAAAAAbIf/ AwBzmV7OCg0KZW5kc3RyZWFtDWVuZG9iag0yNCAwIG9iajw8L0xlbmd0aCAyMjg5Mi9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoMSAxODczNjg+PnN0cmVhbQ0KSInsV0tsnFcVvtdO7Hm/7Rnb42Qc 23ngOPGD2Hm4qUPsPJy4adOkaRJaGtI0kUgaU4XQRKKyWIBEhSjdgpAqQRACoYoNmwqEukJihVjw COoGJGCFqi5YIMw5me/k/+bmn8iVWCDBjD7d+9977nmf89/feedc2q26Tjdx6tndU6c+/NzvZeU9 wXOXb99qdO/o/LtzvuJcx89eWbl6Y+mdt//iXOdvZD979fqdV7Zc++A9519817nNH167cunl9//6 gyXX8Qd5djPXZKHDn7sg9H+S55FrN269nv3KvXvObUg4f/6j6zcvX0q9f+/Xzr/xXXn+x41Lr688 f7zzppx/S+gbr166cWWs66c/dx2//bbI/2jltSsrG++f+pXzL/xT9n/ivFv1b7mNMl+Vv3MFjKsu 4w7JCd/lOr3+ZK0zkXMPfxfOLx52866x9md3f+2+G3GKDc43d9f+//uf/rkfug63Itiw9q+1D+S5 yyVcSnIqJxlWchXX62qu39XdJl1puy8U65C1Sf6/lKSry79j7W/urJt2e90vhN+8m3VPuCk3Jzn6 R3fOLUudbn6At2Xnrmh43d10Dfn3i0TVQZF37t3tO0+cfn5xYWBo6Py4JrTm9YM8twS3TLffc196 uLD6EJOCkiApKD7oEE3kBLOCNPbSWEuALvmg/lbdoCAryGMtj/UCzigmBNNYs/N6JiXoEGzA+kZB t6ALo67XwLcLNB0AryUgx85sAI3xUtopQRmyN8H2Hpzrgt556JgD9PyAoAIZffBNAjZ2w44EeBVI nie/qcwZwRx0SEkcaoJTgtOCIcF2wWcFu8hvBUIfdFG5aaEbgSwD09cCv9h+jZ5DPIiz8H0GOu0U zAnmBU8I9mC+S7Bf8IJgCvMRzD+FZ7Vlr2AGz8pnh+ATgq1YOyx4UnBE8LTgouApwRnBWcFnwG8e 509jX2mP4ewi6HXtINYPCWYhfxLr+8FnN+wYEByHPmOgV3tH8bwP+s5Azj7YN4b1MSAD6FoddKpD FfJNtxOI9VHBs9DhDGw/gvVF+Pkg7NT1k6B/CnuzsGMBZ7ZC54PguQw/zYBGY6lN4LLgR4JhwW3B FkG/oIR4ql8agkFBEbFVHpoPFcE2QRrQtTL81SvQXO4RvIRR4zYBf2yDn+vg3cDaMOb7gGX4Zxdw HaOdG6R5Hef5eQQ+V90S60DqP4yX4HeN6RL8fgZ2Kc7C5+tBDTFziNXKOp5v05z3me7j7IcI6f/b MAJoXmpODwANQg6YREz0nOWSxk77xvew9ibi8B3w/RbGN0CvNfF936z7Ozij9au5rH1N+43Wrda9 1a72sHHfrI1dWJsC3TE8j+P8LKD71j+03uw9oXW/DXxmfdTndD7to/raBVrtFdpLZ6CH8v2kb/ao OZyZBh/VT/vBJt/Mxwbs3A4fzIJG157E3HAEPEbJHq3/A7DrOHw0DT5HfWuv3g/ZizhzCOes589g /yD0N11myJbd9DyP8+PQd45iMQOf7gCfPdDL+r/yWcDeAein/tT+dgU+nMQ4B33G4Celewb2noAu ByBzK+K4BXLGSPYy6LZC50Pgvxd6LpFfDkHWKdi4DL9MwP/74V97By+CRwMyNZaat73ww2bYoH20 zzfz5TjWK7T3BOwuka2aK1ovRZwdAX0feI9gv45z13yzd+u5dfVYu+tBnxBbMDbA02B+nkPcxmDX Nqyrbt+Ev/bgfJ3OLSOOZzFfgt+trx/1UY1bn1G7hsFDx7SPcmzGR7Vtdw7duwh/TSDWgz6qNauP WR/V+A5gEDzGof/XfTOnhqGz9rgfQ79F2KI1qjlzDvaoP16GjzTel+CDeewfB/2nCbp3DLIXfHSH +6pv9sMJxHk35qqH5sKLvnnHvQFdhmDTVd+8i5URm1HYPwp/az180Ue9czdsVr43BXcx3vSt74WP u74e3AnmnrCeu0c79GD8nW/mch02MqyfaW5/2TfvcLd8864xBT9pTPROqrWa9c13ns7TiEm3oIC9 NOZKr7lr9ye9f30Bcxfo+bg7VhrjGOZ2T9bYD5Df+rGm89dgq94zXhV83jdzTEftE3p31fzUvLkI Os1HzT/N4dMY7Vnr4mlAfbaA81oX2ku0Zqahj/UX7YEH4de78KHd69Q/Wj/v+Gbv07zUPNR6miMf 53HG7hnm3xx8lsYa0yvvIvxfxPkM9uxMKngug6aE88bL+NoZk6v3upNYG8fYwFnLC5WttdaD2Cj/ C77ZR6o4Y3JNT+W9BNll0qEHYxmj5dcQzmXxHPrBYpGmfaPVuBxGnDI4Z2M/ZGo+VSC3Ab458K5D 3wzibjLNHrMhi3kRZ2vQJ09xMT9kiU8O65b/J6FDMbDDdLYzZmvBR/mRIz9lY87z3PRK+SiPTC/z Z8VHOZQi/l3Ex+RZvqYJOR/VtumXhd/tezDpW9/XllP8zWi5zbEznkka7TyPnBcp4pnxrX6xGhkl v9r3XrYNryTN2U7jZWtcx8YnQ3uZGLAfWS5/g1o/zROdnU2S/CTJNzrWM+kfjUcy4BXHw+TZGOoe +tn0CenizqUDZMimpG+NA+cX5yXrx/WQDniENmUhJ0Njhs5y/ONyjf0R9lTOY44t+97khHoV/KMx 4ZiniX+K1rJExz2AfR/6IcwDpk8E/FluSJ8K5IRxDfMsjm/cWhw9+53zNUlrnC+ZYC/OFxnfmo9x NRA+c0zD75FQ1zB/QuTbyAv7SKgz68pn8oHcMO5x9sb1B86ruLgxz0TAN66+Q7u5t4Z2JwO6sHbD tTg5cf6Kq+uwB7fTmWvDaiERwytOb/ZHXB/keCXanIvTM6zBOJvi/Mw6co95XK4+zlfJGDqOweNy J9uGNqyxuHoNa/VxcTTfhvnRzmft6jGsuTgfpGLW4/IjfO+G96Xw/RO+D0Kb43wXvmva+S3cj7u7 hbYlaJ4J6O2ubHd/o7H3eM233lXte4e/e0qYlwPbbY/vinb3jOvvYSz1e2A7nvlbqYS1go/u8knM 7XvE1vJkW8lHdZYnniqr2zfv+w3w0G/QUZqbDZt9VA8NPCudflPuhA518pHZYv7iu7N9W9n3hOnN dwc7YzZX6Bx/a5ickm+9Y6VongnWcoE8/rY1vomYmNn3CX+PmE9zBJabJ9l5H+V2nuTnfPTNEZfv fPfjfLJcsByqIAYDvpm/Q3huwJ4a9gZ89I2h36XfIH3sW5L7iMln33KNhvd8fg/mIZd7Sp7mRfJl 2Pu53o2fvQesfsN+lwlkpekc+1RtLwU0FtuGj+owSXR8J81i355Zl7BXp+BX80t4P2Qds8E691P7 Jqz4KAe5p3HPsXsA512B+HAPZv/kiGfaR3lneoR9N/Q332P5fcZ8rV7SwZz9G76PMoEMRY3mRd+a m5xPoe0JH+VynuhMXq+PensYs3bx7aG1mo9yxvhyzofvuLDWmHf4riuQj22t5FvvZXniZf2Bexn3 EYsx13bJt/Zk/qbld1aaeNn5/bRWxZk++ETHCkZe66exHzT9BKbpBaptxl7Eogo7qpBj6zqWIaPm H60H7rnsK65B83PJt74zzOfd8EXRt+bKdeKjtuwkv+n7Xt+3W7Gveus79muCBZwb9lE9VrBvvOug sbuJ5UHet+ZU3Ud5ZHlpOtg7OUtywu+/HO2xnzgnLM/sTsJ8+Q7F+uWJtuyje4GtZWmeov1CAN0b CGwzve2exPamST6/Z/kux++dEnxv/czqKLzbmVzLf7Pdat1sMh6TpE8J2OSb73DdH/TN/NU6qELO IOLJOWk1U4CeAz66m1m9DVMcenHWxirOW+7q2R3Qx/LP+ory2w6aHtBM+qheLc4V39qX7E5a9613 aL5HWa1XfNSHq6Sfxb4KGvN9D+hNbhW0FfCzOBcJY8TD8p3vb5ZbNbIpB34ZnLWeU4UtfRiHfdR7 ahg5r4v+0R7Vg7jZ/dj4F+m5gDUbzb5emptv7Q5m9zDbK/so18rQI+ujHMsTLIYlH/WfXto3Pmaj 6fpvwsttuY0bi6KDh0hNstlsUhRpRbJlJY4zNZWavM3/f9q4y1iF1Vug8oBiE8C573PBtfoCXc+l 9ReWMc8eNZ2avZEfsBm7wDH2TvXuRnyX+2+VJ3oscl9Lwxi8sWG5O5RWj8i/S/191KKnXRXTWb+8 L4jRp6r/U2k1BTyAFWQgnz5E3Pzm8x1iTo0E5/RD5kTn3UmyeFtaL3ITGU+l9THyg7rBf+oc/XbU GbowD4Bh4o+e6D2XllPMW2D2WBruD4qHcU6cJvkX2QfJp0cgE3+63yzyv8h39g2y0c+0l7KeF0bt gTtiewk65ltsnnWeC1tmyScGrgkPpdWdU2k9il4JTqlpm/LeFvfqB9FTMx4lk/5iXE2lj39qAZin d5i/9ThLJvXpGjKQQ5+/K+s8OZWGB2g8MyRPY9M196I7rvXkGPWKOBxLwwy10/lJroD9Zf9ZelOr 4Oue5fqMDuCWeNn31vextDmplwMH7ROXWefsTaIFM44/+Y78sXMOnXHBG8M1jByZRLPXGfvuXYc4 80zsO/R3z7TOf+YBfEfd5fyTZMCbHCGOzk/XCOIET+ec4w32HUdq3kVxS99CTz2wbe7LnnWoJ9Qk lueQ5f9Ladi+lJZLrkfkzWNZ98hL7JMXrvGLzRvxpT9Dhx5P+uaMHABb9FJmALBMTHelzaPEA5n8 Lnd/q+u1ruWbeX6Z279r/620uf1LaXM937/Vs7dKs5x9LT9ny+/13nM9/1q/P9f1Wve+1O/fK7+v 9Zy7b3X/m2R8CZnwfBHtS2c9V32fY+9zjcGL/Oh880zDe4ZZnPeU31Xkx1735tJymf2NaHfBe6s9 n3mxx5tvjP2sHZPO50qDDhvxnbQ3lfd67HQ+xn/rDs+D/vfk3Vo78WcN0snvolEy7ONdabV7LOv4 jKHPJvbzPrk8SmbyddzMN31lHZy7Y2mzhe9b5i3b7depI48z70GfeDPNEHumzTjazp5s432je8Tt qDv0ol1Zx5NFDbSd+zhzfFPfUWdpRy+mjskmvlmuA8Z9+pbvSTQ93Xr+y5zo8T2E7cbZR/VlKmuc uGakvzLGg3gw19hXtutQ3uNuX9a5YoxZL+7MukN99V7yz9rjXHHtulWj+M8cfBD9vWSwMm/Mz74b OjZuS5ubevUrfXHQ2T7k9Gpc5rJr9abac6tGI2sobfa6yh77h0WMmNvG+gu/a1lj40X8XAOov2Bl FM/sPfiY2cl13W9c/HUJujn0zPq/FT19FtpzWdfzzLns1Y4LOHjo3HXNOXRokLkPma5d+G5f1riy /xMbtjvzPuU5Pseg+WgGQD68xqDryb7FM3sws0PmoOvkUGM+iM45Y1ryexCt7/ve8QObvXKGND6s n23mO/XI+DEPDLqffsse2avto76z79yqT1kDrW9P19zbh33pG/gdQt6m9GOSOWx9en3Vs5ntzLkj c6Q3Q6Te27hHbTyU9/5IvW5h3nHp4eWWnc5jxyzr1q0zzxeev7LG2WfZM9NPPZtuLWJ4a8ZJnFm/ qXP2US5a1+X7HPHMPtuL17IegmfWs9zHx72aZ18fOzysM7PJucMH/c/lfWycv7m3DRrwl7mY+dmz 2bNk5jH3juW9TtbL/3tyxuCDTzJPM2ftP8vfi99RdIkV54Jttb7kbdaKjAW55r19jcOfdbmGmS7f l67x+BNb/S71vMzZVt859/tNBs0hbLX8ZfZ8kM6z7i10j/WXuYr5jhwedY4tU70zl/VbYap39+I/ SSdqA29RaJhxPef57EG8j7rPL9+8kx6qXbu6Rx7N9WwQ3Ul8mb+PYRt358r3WO+xB04uZT3/5oyN TcxKnuXR+yo/vJSWA8veU71zrno/lvWsih1X6cTsyEyds81R/kAfZJ6qTGSAFXDgt9Sf5f2c6hqE r6BldgbDnmGYPVi3ZiF6PH2+Nxv3+pznT3SdQs6urO20zn43ZE/Kud21YdL+rVkGmd/LTwwtsr/V OHiWAS+neo9347k0/C/fX6vf/yoNM2D8pf5f7r+VljMPwXsrnqfS8Pi9rHvelx/rj9ADHUwP75Nk XkOu71Fv9roDb3Q7SOa+8v30Y30uLV/m4D2K5q20WrOs/0jGXmdn+Yjaciwtv5ff3yNGztk5ZJ86 /C9hp2fkc12P4rULOcv6tf7/Jnuxlf9TnE2l4eFRd7+X1gfpD5vKm5nrJBpW6gVfMDjEPWrOWH2I /KO+qS9g6Swa5Dzr7CDexsde8tGBWODni/gu+fdSWk9yr6HXLbqBffoz8ojLVNa5cZK+9Abb55yl vpNPxBC8XMSbXmWcwu9a1rn4qtg8l4Z5sGzcnMo6ptm/8PWr6DwvHIJ+FF/nov2D7Rf5dApee/0n ZuSle7uxkpi9ltbD0OnXiNMs/9gn20r/V5VHv3X+Ljr8WzKWs9/q2XNZY5UesdB+q3R/l591yb3D OBtqvBba/8qf38VvDjnQUjPQ9VpavaQ/Efun0moQeN5VHU+x9yr+1MRrafMf85xpmI+cD/iTnkq9 hQfzFLlDn4UW/5OHB+l6EK+LfESNGHROnqPPUb8sMIIO4OtLXcTMcqlxh5DFt+eZOWQs+7xN6H1+ 69h3xICenXOhZ1bPYPvgudF9y8k3KTpN+vYb028C6zaJzjPbLN5+400dGr+xcnkfPfl/0He+c9OW zHHPfalTTx/mW3w8i9bvRPh77gbTs+SiPzzI8VFnvW/qJ/hlbzm/Lw1jn+pidqCn/SpdsM1vQM/A 5InfimD/Ie6fyjrXnZtgBlm7svYfuEam5/Gn0mrNKH7EG59TE6mPjq37kN8OzpVlvUpX7yPDb4ld 5w54tl7Gm98Y1t+5lG+TscPfbxDbsf/gbNSZ68oQd2wX9/zu8XvVfnQ9cu3Yxp5pbZ/9SL6AC2z3 u4t5BF7M7I7Vsu7LOofdr6jtvNeW/9Rk/OJ3YNYgaPDBvXSg/4yl1b5bfmAmcLx2kkOOzzo/VBp6 O/kMzVDv/FLa7LMvrZcustzL7F9ylznesyO9YB801BT3Gu+nvaNkZe7Y9lmyHIeh+hsZ+IUaCO2j 4nhSzGyT60vGLu26q8vYPla5/o/Ps06QQ9Q749j9GFsPonF9JHfBzSS+9iPfJ/Fznrk2gQPm5Vly 8A3zqOcC+DJ/HSX/qazxuKn+g69rLXEiFoP4UNv/VVpOgxtqzSQZYBS7XY9yJhkUL/S8l01D1Zm5 ehYtcccW+xVadNyL5k53PTOexAs7t9p3zPfij47ocycduXcube72bGdfGz/E5l575NdDaTmS/dC4 cWx+KQ1n8AVDxOCofdYoedy7Ly0vdkFnbIIDavMg2mPYCC34RO+Heo7t4GMq65rj3u/eeldaTrk+ eU51zoJt8ugsnnvFEdn4HRxstE8d3Fa6tA1fgfX7ssYBe4fgv42F/47i4TeH8eYcc7ygMw/8bZyw fyce94qnc32q9ybFEBpquXFxXxpe7uIufJ3z1Dz8ah3vxDPl30s+teAoPe5Kq9Xky1tp71Rkeeah X13ke36XvavomAP8xrCPe7Oie5cx5v7jmJEL5JrnyIv+e8Z1/7fMfF+5T8L/JHvw276s/eN3n/1j zHuu2Zb39llP13qfeb7Gr/YZ5/jF71f/v5Vvm7ifPcG10TRD0A/By/Ite9ehH8ra/qHD171kG3vE NXXadX6ZH92z/Fbw28BzD3plv6Dn+a1ivy3nd3Hf347hIF6eZ+wDv5eMD+Pc7zC/c7zHt3FL3jsW 0HuGom8ba73ZqKenZ4Scn3z31NnPPpFxHuJ3E3SZA3mnhz3fdTwS1/7t+e1WjtzySeaa9zMXe/7f dfY8B7lu+Nx4ZAazXxxz7mVO2Ac9P/vX+ZP5kPNg7/3j+p21x/5NLPhur+b2eGV97a1ebe3Zkrgy D+thXPRkf1STe37/yL7kRTxu6XAr55lLenmbMevh+Z/8w5776kdx6fW8Xj/M/Bvi3P41Fno5catf mXfmimvzP8XbOWm8/NN3+mrXWZ41MndcA2/1PPO6hentDbpbMfdc3/PprZhaZ/e9Q/DJPuz9fEPm nR4uuce7CTt7eO3NG7Y75yPb6rk6aXrY6fXGXu9JHRz/Xh1zHLmbmBvifNvhC90Y+yf9X2aPc0fe 8v9TaT3tVH+ZuXf6Rr7fN5l3xo7xTK+Cx9OP9bnj13zzJC5Z+GkKvtAdynregve+vI+BscA86zqx 1+rZM4dvbP+s/7Po5/IeJ4mDxMxGMs+SkfEYFUdjwPLyv3PbOcXeLPmZd+a/jXsZ35xNrPu1/MTi ovP/qk5//lh/1/PH8vPt+n/Gy3RXbuOIwijAGpJDDsnZ7iZAVmzZyiIkD5D3f69cQnXAj2eKN/7R ILu79r05ny/+/wx/PCfclzx/jvVt+px6XPN7STve8ux3wC37f6QM94SV3N8T57eEuWDdkob0WOjw nXmLNZ8UDy/J457391hj7JI6S+Zb8tTZFGv8PeW6wU4D9JvyvE8etNclv2PCPuV+Au4VuKIp+r/l uWx3zvMLbP6cZ+c8U8zJB3Peveb/PfdH0JkBp/x/yv0ZOi7fr7D5Oe05wWYvwLvk/Rl856R1As+3 PJuBe00Zz7HmnvS/A46xdrc7yU55+ljjV3pPscZFb/iS+RhbO8nO6gGfTU/iCucl7Xu1O/nlanea D/rY2uZsvJTjoiEdhDeBzy3WnB1Bl7m2fL+9r3++rx/ws3wn3ytO1M+WmvI91jo7wk76Kk+F57XM //U94f/X/Pca0hkP9gSfJSTfGGvdVO3jzKS6OMW2jpOe+hlnhjN4sOb3wOFcIlpjPL5HyNPfsk7X eRBWOvo7q5o/OdNV8yJn7qGgIZsM+N+bPXrgDDv/1J92EdxkOJRnNF4+V0jmvqDPftobHOkN+J4A 53eiV9nM/z32fS6vfMc8aG0/mu99Rqx86L732XgwWJ/VqvmE8B/FRIVbwVTySXf1uqqu+KJOim9/ Z4m+xwTjkXlE37ttyZszumiNRsfnburF+lPFOOHJg/LSL4PBV/7wfKPNqvcDaVHfKT6OB+Ya31D9 Dm/h+Mzsdq5qJnNgb9ZWPJB+ZXvWHb4R/l8tqWLBayB17GP77tW5x2gb2/hmLWLeDqDHfsC99OtA py+W61blsteDyleeVzPgqzo8xtYne/lR1c2jwdIGXg/Ic682k5bXTcpwMhz5kD2K8Mv3UsCw/55i 62v2NPbGj2y0F9NH8OEc5L2Dvqjs7T2EZ25LxbDiw23mdYF8J/inqpud0WD9dBj62mOe/qhmNJ9D q1pT9WmdtQU9j9OP1hDb2WBZzQ6sw3le+pmvcedctCs8z8/KX6ypFV3pIxoNdGkL3DYe56XGYIV7 Mnv18Wgn1ocWtIaCV2f0FWuNyUDZW/DxPkf9K15OZ5H/AD2kY1ss2bI3GzfxaFPGhst0jK18rfEX rRG4jFvyc10Z453BUsYGtCs9DwZ/NBqVL5SXTu9gvFyuJrbx4rHhfnT65Okx4HvXtze4Sl9fTsNr GeHc/pUv3E7y8aGQwf2t9YTzRRbN/qL3Fj/j4ga+mj2Fz9ovWgv8ayE/eTXAm+FL5eXSp9k7mUek IdqqMaPBiufB6NB+HfhIHvZ39dq9uXsyfOrKOnOPbZ/u4nGu2asFXUGfcBWNqt95n6x6YMXDYfdg 5IvJ+Omc8ydxxsRp8/8Uj/IeDd9nRtb1P+GvW+4Xuhejsbd8RvKZijrszbL6vxb3lb0ZS5oNKafg D/hfZPnjff14X9+MVyW7bMS4HKPWo4oXpy18t8VgfPi2WeqMcn7K/ynWt9WcekyxtUuf/ptsDcCf 8E+9etAY8s5zeQD+GGscnlIe4ZyMpmYyxexo/Cb8j9gvNG7AV93pYjsz0g4H8Ccd8pFNRKOP2k6M N9lrxv5o+B5POmdf4FuK9lZ/6VNn+XHO+zPsxlowGP8zfEKdxZNvRdmS7yy+X2gD8qLs4tXhTPqP sfXTEfDSRX1oNHzFksec9i1oUVfa2HU9FUv+YT1lzDue9HSd3c6yLXPA7eyLcaY985C6LP+qZdTX 6Q/2z/eA9OcbaM8OjIkuHuNDurImVPEme3Wg3RnvUzzGmmwrXyl+RP9iNBlfx3i0HWsu7cTaNsea f8v3HFt7aP6azYfymWRg3VON11kb2zpA+0sWzgzMhd7weM441V1re/qPcaKexX54Mnod8GXfI3DZ W6p5R7QYq5x52ROqWqMv6wNzuQUt7Zm3kkVwigmfxc/gLVqNnfXxKL/Xv9H4eq62sdWNtqZPCdMA Rue0Leun09QcKZka/MtW1eJcNBhNykA+1NNjsqqDvNe7zWuK9O+MN+kqHzSTehyp59Av7OlH8JO9 GDN8d3KeEKxygvkhuWbQYY3gP2sd5aTOk9GVrk3uD7Cf8mqJ6avpPRkt9yfnK86qHfzAWVyxr7ck c1JxNMQ27jnD9zin7uxTOj8Yf8YvZW+MjuKecegzHH1IGUecy95NyqK8WvafYhuvvD/knWzUAodv GNmgAX/xo14dePR23v2FfbWOxpN3jMU2tv7bW01sbSU7fPQ+rOg6PGeKaq5gvHmsVTMIY3wAj9F4 cLb4BD7+ZmRPYB88GT2fX6mbzw4+RzJG2TPcJtWcRTguvq28//ksx3/KNOOMcjhP1R/ZjjMCaZI3 YQbjQ5l8vtmrNYoP2rIv4D8683g8FWdTwYP10+cU6jfZOXVmPHg/Y83kbOAwnId8JmXcV/KfQHfx 42tsY3c5ewMv9lXGlvoC+/cZ56zf6ksnnGldY62trI+HPDvEtu/dY+2N6p1t8fW7T8aXvX3Zz7HN F/ZM1b8r7M45lLw63H8Cf80Iv6SdPsHeT7H2CdIRjnzZ475NmQ/Yj5Cli60tRFP2VA9i3ztgLx1o M/mafWYC/wn493icBxhjonFP/dvY6jnEtucq5pbzr1HPgYqLW2znAuEdjA910ezFWGQd8n7EmakF Xf2r33gvZx3RfCEY1pTl/II95zTWQs5QbeKwX3qtVA9bYJ/jZwzRVor3DrDM47ZYPj/Qj8KRXGfY +RBbH3HWPBh9xXsPXN3rDdjE1seSpQcN4VY9ZTLYJrZ+paykV9mFujMPr0aH+SzZOa8xB1Vv/Y2r vGecid6yPuGu0okyUI6D0WOsykesxV7zROOMM6/tXmNYt8jLbe413u3u55rZl7tveSZfyOcT1hKv X2I7f13T1udcA/byFWdO5Wp1r73PwpxvfPUpwxz1TKOecQLOHi2nW8H/EtscaQyOfV66XXGvsxlw fJd2aWf61t8YwuX8dDEak9Ftwa8DHfFSnl9inW1od5+BO6Prd+5D502YJ6PBOCBNxZBms9bOP8Kv fFvR9xyjvFX/8BhxmhUN1Yc9+5JmW9hnj/axgNuTqaJFn1e9rC/4eG66f9nH93RwXj7fOS+t2Wgc jU4bj7JUvux2cNt4lJE6jobvy/XU7Kqc55tINaWqC3yXiqdmR50PtnxG64HjOeu5V+Uo/yUr6Y7Y 6703GQ/CjrGNHeU036j859vQbSaZhnjUR/OR7LKnq9vM3418z46gd4qtL3r8y8f0HeFORr+Sb4it /L3x9t4j+Sgv/SR9p9j6dC9u3R8L7SvoTTjvzd60b29fj6mqtngc/pXaWsUAeyVtopyUDNfYyuvx 1sSjTRmLnG+nqO1X1WfS26vN3ttEfwB/h6/6H2uX25b37j8/Ix7fFFUeVv2tiruP7plXFd5Q4ElW zgaaTb3W3EwXn4PlV9lNdfoW23fJPc99Xp/B7xyPuT/HWh8Yl4pJ6TDhrIvavpdcz+YX1pgL7p5y /3fIt/D5V64f7+vf7+uP9/X9ff0e68y9wL2B37L+BhovSX+B/zX/T2mnV8Ob81xy32Otr6e09dc8 vyXu15T5nvxGyPU9aSluLgn3BH/Msa2t95T1lnd6pww4u0FO6nNJ3GfgLvsG9+J7jm0PFDxrtGJS 70yfwRWTVf5UccHc9jw6fUCTPdjrsmDG2NYg0tibNzhvai7hfOJvH82GVY3kDHnEP/Nwr398RE/n TWzrXAPaDXD4HqxmyA7wLtMxah0oD212NLpt1HY4mJ0Hoy3/O1+fv9h/PpqT+3iUh2fH4n5v1qYf jwWM6+Hx5LG8lyvtzreKYc2v+le9WXL9P7HWuqVuqs5e8mypDX+mfEttvOe3y+9Sbz8n/C3hr7HW 0cnuVGM+x1oDrwn7lOcvwH/N+2vSGWKtaddYay5zwecT4VRzhr9rOFucDEezKv3BuXgo+KsOzoAR P83aJ/BTz9Tbi/5TLR4N77/xs6ed02Y9/Piadn/J85dY+9c98Y75/RJrf5Sf1R/kH/ZiwQn2c+KL /gX8XiHPnLTUEyWDeA15r3h5Bo1zrPEhHfhVL5TOb7kX7zto3nG37DUPjbCbZoE32IA2FE19qfsZ sE9JVzLOiTPEGseSR3njfVs2m2OdQ5STv5ptlB/nWPNFd+In2Thbf047uC01ZzR5dgO+cvoV8gtG tn7BGfUXfd1dkofHqeagu9HRV/K6L+6x9Yvwx1hnIeVoZasn8OWspZomWz39j/MyWY7cOMJw5EEE 0Ni7m+TMaB1LlhU6+GIf/f7PJSJUf+DD31kgx4cKAIXc98SdfK+9U/msOvYcx3qkd/aCNfaZVPUr 2zkp/7XAq3+pd7I2svezJzZx7PPsUb5bsm96j2KPc3pZj6rNX63x8f5KGNVJyu224izg79l8WJu7 aBOf+zQPUhafP9x/Ge/syNZrgX1KYGiHTNbeYDnn9MaH+Nw9P2Ifzooef65zB/q0gcszAiajdzab +Xw1xNE2ri/11iypXHLYmi+zuKatx4Rn9k3cMeHlfvHZJtOrNdpuqzGOdhEP6T/EUW/6mTM43x1e +vis5LMUcSezE3OLstZyS0/pN8GvA3iwbmZ0CU99fH6kP2gnzm+s1fRxVnOHCp8+6nIQjjZz+6pP OZ0uoeW7VlZDzk4Hfn6fxTTzz21wMdislgjv69v57e38WnzwG/7NwL0CV/eakcbYYySrV1kf8TjI /JvZ3WPcd9rphBfPeuKbi/Fk/GVyuq98VshskOWg13LqRj+PxtPlz3KCMjNPhwSHvJ8q+noPzHzH 3kA+WS9zmh4/bqcMx+3E3ZP5rD1yi2nNn5oTeTSrT7HvRLfYc0/z62JnwLv4jeV9BQ3RnAusdlp9 S2btNqvBXWPPzWu5k44z+K2gNwKXcBPe9U86iKbm+MXgpI98IXqsT7N9j7jvAS8ZGONZjWMuyN6y i8fzZHieM+yllM3v6PesL1JW7SuD3U/xaBvahDnisSzfUT/GNfNhBVwLeMXiYHzoO+YN7ayjf6TD Gkk7bd+N2ZQ6T7jPdNf/JR7tlR3Wg4znmMAo3iaD0d1ox+1BfR1mNjjtteRxZl/R6O2OsXuPx7kp 06XHu/vuTLfG6Li+pNEZrveXMaHlcvX2LpozcHuDc7785z6o6Trh7pLAD8a3i0edMj2YmzO++cxO 7Z94dUabuhJuAm89VYe6hL7gOZfx/5DgqF94LhFf/WTCu+TJ+tYYR51FI7s/k4/+8dpA3z7FPrt5 XnBmctt0caz1frIZVPies5zpmKPEeQWdbAdgP5POnCnZgzJ9/O69uZXn6QS3x53vsQ6/vMOb/aLm G9qhicdestn+E2ynOKTPuVtkc7jHVhYD7KfaC7gjuo5eL+nL7Wjumw2X+bbpeItjDHqfrc3cXiPF P8Ojn6hXE/u84f6XDRrIpfy7xqNMHfj3ybdq3xqPPmjB03PxBl6cCVXbM7+0gPE8lk4ej9RliqPu wr2Uu9Zo8a4tOnbGt42jrURb/5piW6efyd7Zd4u7BvdP9v4lkVk2fQLcE2Aa3H9X3p+NTgPb1HAz uq6/4rHBXWvHcV1vh1XvbA1e7zVfud89Fzro1BkMD+V5svsn0OwS/KvZQnZuk/cRtF5BfwZd9XH3 U+Ybt3/GvwEP4o72n/BreS52T75DImMWU/4c41F+1QPXw/m73+kLfbNOCfYl9p7EuYl75FT09vmH +yTnsbM9ZQIPwrA+TrHPVKr/Pie7DHq/xrGfUYYJ777nUHbq43uI09W37KK+kdmCfL3XUV/F0Aw6 xNWMrXxwPqStd/pyiePsQD6CmfFUr3HcATDkoRoj2hvuLfb483lST83j6s998l/H5fjH2/mlPH+H /JpPtu/n2ONpBcw/If9anv+KvU9wB3op+K+xzwMvsefdl9jn543G17fzPWy3/ftccL8WuBk86OOX cl7h7yX2GFO8a8+RTRkTlP9a7KEYU23JdgDOvDfAeNywTnG29T1hjeMckM3YrE+KN8ncG6xoSKa2 2IpxqZlNO4n6i2b1vtCXz7tixzvwOtCiXLLLK+RhnHOOpE1b2Ik9m7M252jWFvm5x3/VIeUe6VIG zp7Ep58chjY/2324Q7CuKtZYw3xX4d2I+8HeGY9t5R/zlH2B8zHhv49jrpydLo554kd6TMk9vyfQ 0m6g2HGfMI/+jOMsQF701xXv/wHcv8FDMaSZ13OR+wt3HO5cgmGvIb7HP2uNZpNfoL98+keR1WOO skxxnHU8Vle8a/5hvqi/Mu6vsee3+qrLVssF6cVv0iUtPZ9Bz/fM7AyAvYBOtmMNCT/5grKxTrFG uR7Oi/fE6xL4vnJP2T7yj3Ve96/mQ5fJbdBG3W41u2eynP3z+us+pN35nsWU01E8ka/mIZcvk5f/ XGe3Cettpov3CeY7/88nfH1XUf/LeqdydzAYycoc6o2fx5TyX3Q19233P8bf/X+FDGuB/18cZ717 PM7U7Dde/yXH79Blw/059r6wgr/qCvcg79GSc7Z79Q75YgEP4XWAFRx5csdhfZMemjtawNDWYxz9 TFo+v/B0Ce/Wnr5bEt57p/T0Xil9Ga9jAlOL961P/Rd+pK7c8zhbchbweYJ8eL/iuQB2MlqMKZ9P fMaf7f4Kvtms4/YWH+1Qwl0Nj/vn9v0p9h1lBB5l5mx3N98tJpu+FTe0ves+gq/HAvcpxs2Zvwaj pW/6j72Lcvi7Ypf+Fa0ugWN+0y/yCWOZfKbK94Q77Rry3Yz/g+F4Di9GvzdY0RQf1XzRJ73B+Ga1 QjlD+akj/TTZP/azFTINxn+KxxpAPTK/6ruLR3tT3kuCr3vq1BuN0b4p53RylF/qWZSndhR/NTjv Py4L85K2ZN1wPSTbmNAjD9UIl5e4LjdnnEvs8c7YYX3lnuV6E14xxLrEHNX5BFzNsLThdv8COvQ3 c8Jjsea/mv7Uz+G5a3hvrPHx2BMsZwWPwZo9SY8yjh94Zy3U0/dV5+t1zenq/gY/k+cKPuwtlOcS j3Hu35lNvXb0lfcMf7GnZHwv5ykf89Ptc7F/Gax074wu9WLs0BfsaRm8xwrvr+bj3r6vxS63ir85 z9F+7Oeq8S57ZsczXb/l9Amez2PcKz3+vJ/LVllPGY2u91/3s9cpznreU7fzYjpc4jhTkqbqyGr8 ruVuBq73U/LQTur0JZ/XMf/22pLFTuYf7p6albKZRvJxFq/J6rGYzSNO22cS9w3pcf7sE74+7znv LGYy3mezlHyf6cteRvjabsma4jA+M793euPLPMjo+y7CejnGUTfurDV4z43eYInv+0cGx/n2I/a4 GJ7z9FmFeMwT4rvt3N6dvas+q9aJ/sXoctbvcHqjpaP62YLW9q46I52W8r3GcXdzOSSz7pTji+kx x1FO0qC84sE4dN6qH3yyrzFmeDcm9K9xrJudPSlvb//o4zGO9uQszn7l36J1NTtSz97umgJ/seMx QfmdtnRSn6GviCsZJ6Ohu8HgvXb1BsM8pxzsJbQlfcNcp23v5V0xx3jQYc3P7OEyeo5ntrnbN+NN dzfzwxLH+BmNhud4litdHPWj7+hXtydjj/njcUFZJrunzJ3964zOaHeDwbmO7OMur8smH232fDGd 6AvJ4HryH2VhHJP/ltPKOe2z5MF4Zdyy7g2x11+9y05619PtyhqzfTf4J7nacjwu3zu1nPB71QnJ SF95DEjvZ9DpcHcxv3m/4/lsMjnMaj5Xzg2wTVfgfgBsD/x77H2P/qJvRf8OmD6OOT7Fo0yMwS6O OeU6eQ5ld36f5XD23SR4WV54/3vvZL33TI5MR9cvk+tM5kwer5Gq5dTTn15vvE5+xCeZX/sKzAX0 O+OZ6VXTPZsVsvnvzGdn/nZbZffZzJ3pUfMXzxiPetRihnQye7t9Wetno7nlZmv0sphzm/qc0sfR X9OJ3DX67z1r+X925/hn8fwebBZb6gvq5bIxZzLd8XAHynhoFqM91T+yeVs9SjuE17Sr8WwKXGM6 LbHX6+28xt4Hxb8B7aV8K36F6/H2Gnv/ZK/w+JXutdpKv7F3eb858+nZyeixJsrfGS73SfnO68PZ cbibfctOP79Dx2s7Y0GxQrs67FC593z3mrckOtBnY0LTZdNsSNlc9iYeZbjat/eG1ujUbFbTMfPT Gb1MT+G0H8Ab/89//Ql93dfsmvXyTE+P6y8Jry6Os6RyyGVgvGUxSnj5XnM//XoBDHMy2z9E5wZa Hfg57c7uGjxpS4dnbSUsY001zGuJ+0m8PY5qPYy6MBY9tzMf+/+trk34Xivv33Io47fkzrfy4Zzi tWDAt84Uj7PlHI9xu9WbTyZTTRfXY459T9N/9c2NxndxjMnMP2ezl2YRjwvBaUdTLeHMNIFG1uOE r7lxxHsfxxhU3LPPM6Y1J3FucX4N+JIu51bm3Ah40SQMZe8T2tRBNmJ81OpjY/RIk3VgAnyWv+53 znnKQdrM5xvOh8S/GDz7chNH/7DGuY3II6t3TeS6KE6oh+u1PTVD6GwxcgfP5zjGpvtG9mGus3Yq n2lX4bOv3uJxlmE/Ew/dZTlGmxJvtPvMh4M9a3PJVoN+eDs/leemx0uxWQPdN7gVdlgKzFzum9h7 0QZ7jX3+7Mod+85nyLudLwXnXv7f4i/WyyVHkqQIw3JBZWRG5Ptd1dXV09WjGQQIJK6ExIIjcAGu wYo1C1YsOBsVavsVX/xpHlk1YmEKD3d7ub19HAOn0Isxf4Ltsx6m2GRszcvwhhLeuYxz8xn+Y0zr 3XPEmWKKsaT3ToPv1vSTLrsyzKyXMtSLRfDZm23nFV46W4UtVTd9bqFNdNdd3Om1jOt6VnNpC+Yt 8045sgYf2e2K/SW+rG2KVcXXyvaZB4pH0TKfsxmMfhZf5i3laDZpjE8DvLnxVozIJ17DOX9yPU94 8d/1n6Lz+uk1lXMo+2xNbkbr+x7XtCtrGWuRf1kv3decOxQv3BO+10b+s5/7vMG4YC1ZgZZ1Zmky qQf7xha8fW5tjQ/ro99nabTsF14D+W2Nnvfz+5OHYtnnR7dRV25txv4iO3uO+Xwr8HmS4PWLMZzN WEeTKbmz5N61GPB6yZh1m3teqE9q3/PAY9VtwXoqnH3w1J3Ioza3MV7ndsZYPNnewnizXqg2ZjWA sTFV2+jDWgzqO6v4Z1Nu/c5z6Uzdp2AOvk3lLLPNPb5T4HKmzj4is2bjNsFxedzjrMQ3VpvQZdAm 5+6LrtzqXsvPHmbl9n6c8fiW8LMOOKsyxAb7IvXgG0P9aFvGucM6rV7A+6zLOOe8ltbqLWejLfZV w2ZBL3u0oNmWca3j3KKavDWf0h7iLRu73pLB8y14Z7WUNhU9/U8fq2Y1Jpd1LouVbMZgnC1NDm0y Bx350g6yk/dFynC/eo9cmhyvxbVZjvpk/bwxPryf9yjqpzhp7Kt1NuNlOrLeZr6Zqj9tsue1MJuf JWtmtE3saf+hwierF+InvJnxbMptXfH9bK925neSPN+jTtKFNvhjGfK5f8P+WL6/KxVzin29wVgz 3DeS73Ocx8JL0B3MfpsyxF2/fsK657HH2vsKY0W1hHXjEXq9QKcu9KBvJeNQhjrNevwE+ibOZuAn +7A2Kn93wNNXtlJ/YX3g3LIJWTvo2gFnCZvy7kvgMx/Zp3s+D7Dhugy1gXM350vxnOGcdeBzGWLo BN7SfwGZhzKOIcYX65dsJnmrMsQYe6jot8Dnu49vjDVs5fXW34MrnMl2ksF9f+d1xrczHNZa6sk4 lzzODur1nckh3xW+4udvKfViyuN7wt9FxBFf11Vnmn/0vlIuOS/p/Z49gctcGG/6lf6U3xhna6z7 /cbuvzHbL40f6dlDfZ7JevHU/z2o9Xfaw+cw/6/Zj/xrPsjosv1szp2i+4iMDDynPyrDbaXaxDVt n707iHvv7tl59k7qysfskOWTekcNx894x0zPKV5TuPTRxnDayv484dUZn43tZXmRxVPmc9f3nu3d tlP1k7pN1QfSN+DZ2trrXVfqd3Jal+N1wO/jb6cM123hb6RTyfPFZ4nMltlbwXlRT78bdZ8n+24P n2M9T/3do33nkeWW5zTlu+6c7Wq1udZXWAOy+PdZi+c1Hckvi50s9mt83M6qOVnutMD3WCCf1tZT udsaX9cni9UMPNY+ysN7SpZX2fo9daZmhyx/slo7ld81H77HZjU81+mX9PXOaBkPiuupu/u61k9q cZPF6nvvn+HVfJz1PL05vI9mNvX51XlltYq119+LzmvKZlkfrMUu59KuQlvLO68F1D+r4dndM1mO m/V94s2T88yHi5LX3mwvA+Ix/rwvu24L+2fc1WzBM++pU/NYbWauxYv3X+pButpscC/WqJPHRBZj Ge/Mft6T5rYnu/X9tH9PLsFvFefK5x8MTske4Su+glfsvxoecWs87sm7h1ODxQfxa3Je3gFfKuv3 Qo3m5zf4bOffYv/1HXzlm292x5fg+xq8nyZ4CP9LrL/F/6eAV+wJ/7PJ+Rr0fcw9xl5/dg68fu8a 3+eAJ/y/xP9zyHyJs8fYf4Kd+vNj4AqHun6OvXPgXEL2Jfg+g+c18C/BU3pL1x9iLfgUOE+2f429 c/A6B+4VvhVP6fYIXtLxFPsX01t7nyD7BfuPQXuF/HP8+/cEXYn3gnP6ijpI3rWMddKdLoajvZPp ofud7evrK2hX8e3/OadofulrYR9/W5yty1Bne3p/j7K3roLPEjSqo94rNtjvcQ4haxH6daG/etAm 8FwH6dx/d/g/xnod9zkG/i5As9oWfM+Bc4j/U5yvYbeebh/nq+DVxpnOO/CVPxdB1/OZBY5oDqHL Ke52Cr7yn/TTv+7ZQsYhzvbgfQnca+A/BX/FhuKgDbpLnB/g+yPw9tCxibNdrE+w+aEMedHFv+JF MSL+etP6/CO/sWfvy9CvNwHs15x/OB/rnMB5XLh8Z7U455xBWT7bLENn3WMLmnmpz1rkpXzpIF+x Jp5dAlvTpTZT634b0KwM32fnqVmS/BVLilfK071YD1g76KN7d3A9RcuZWzbr40X5qrO1yaZvxbun UW7vgv6l3MbVutzqQ16bMtZffZwxtDbZjEXOpNJJtfxasce63NqPtvI3RDZzn8ttfCrv3C+KlVkZ YkN8Vb8vuM+yDDVQebEEbZPw1zljU3HM3GqCt/b2yT3lk2f4iv1LeC4zy4Oa/RiHXbn1Aelkm63x WpfbGF3F/Vwff6dKf/bdLB7477k3M35+X4K/FR3PbcN63SY08ttUfVIP8Tj1dWabRcI7u9c9YB/O akHWQ9wmtf+a/ZZ38Dze/x/wS+yzT/YY++sPyvnDO+/2Hl1r+ZzF0nv5ZvFZw2MdXZX7+rznHvr2 uag55MGgz+llrBvszYCzx7++LfCaynpWhvpEUI0Wr3XQNWWsV8a3/16AL1gA91dG++uAh3Kr38xk 1O7iZw9G67z9XDweytDTyFM+bybk3dPNQX3xALz5BB11PZTcNr2dGS882yR8nUdmH/LpYI/svDHd XBb7/SpwfTbmTM15xWcLna/LMCMoz07lto+Ibmv/krUq4zxljmpGOmLf3zGUpXlmga+AdiGO+5tz Evk1RpPFzhQwH+cV2ZnP+q/ep3rb6X0nO+iNqP1VApsyfhMKtkG3K8P7RDM0cZbGa218VKN3OF+A Vu+ENXjKfzvo0YGnv2N5P8nRvXs4leEt8wPga/Lfw5f4KvYfQ59j8NlCjnRkH1KP5dzYfy/lNv7u /U/1yjbuxPmfc5nHE98ZPr+SvoeD6T43nMboOcMqRjkLN+B3LeO8mZXb/KzND7U8ntveLME7lXF+ 1t49Dqw7M9DJ18QTf9c3W+v/AppZcp7FxAp6ZHypo9c25y3w2bBmD+eRxbzfueYvjw1+ZxN0U7La Cm72X4sf2m6DM5+7W+NJO+zLrZ7eN3ZlyFG3l791Mz3vxZbjNHbW4CuZLru1f+6TB3OWfNym5Ok0 sjffYszXzE9ZzfDalsnbl3HN87zxmGa++Ry0MNpa/vgco/rTr71uu1yt+3o/K7e15z29RPG7Cbk9 r5+w1wFHfVf6fi7DnLWDjVpbcxZp8RVNg7u2JqPfP8Z/T6fe+lCGWDiWod8vYZMleKnnLwGy4zL4 nAO/5/0Y/C5lmD8V859gP8ngHMM4lV6yg/ThrEVdZHP5Srwl/5z4/hG6tOAvPTaQTX0kbwZczvmS f4Qvl1h34CGZXuM0J3ldl8/5FliXsc+Y87qb5hDZRDOedNX751qG2Uy85BvPgT3stIOtOXOKv6DB mnl0sjsIR3Pz2vjrfrSP6h1tSH/yrbTDPfdhn3UZYkM+O2DNuNpDfhd4wnFfy/a9zD4OL/A740Yx dYaNd2UcY/L/qozjdQMa3fsKWwhvW8Y9UnR8ByxAcyxjn0t33Um6P5RxfpxMH9UI3pVvU9lL+i6B z7xlTq0gx3PrandjD5pjTzXM66dqL23LXD6UIX8Ux43xYBzQhr2tfhM8xGdfhnfhoYxrVlfG+cgc Zj1V/OnM36rKEe5t7V8xyb5N0B29p9GPsiu/vu92WoOnz6/sbx7nnLmz+VD1ZRewLON6oB61tn3p tcQZZxTpL/tRnwbgc+rWdO3K+P7qY89v8FvYRLm5Bv4s1pfE96wtzA3dTees4V25jYUe/3fle6/s 4/IYdtzEeluGerqPtWJ6FWvts/8ssd7ibqwhrEmike60OXs3707fbfGvnHf7iN+sjP3twPqzh14e I/7PeKBPOLMqTpgburtAustWXkdZD7Zx53MZ5nTt9bQXyOGsMA+fr8s4rzkLPQavU/joqQxvPMUt 80M6806Kk17uJ+jW1+9+Tv4KW/S6/ukNfozzQ3x/X4Y+MAs9NBuqFjzHvmKw1/Nb8Nc8ecDZIfT6 FHI5B7+U2/mGca06yz6j3q1e0+O8lu9vhv4+P5chblVDNF+oxp3LuA6wLp0Dp9f3H2/wzzf41xv8 +w3++wb/Cfj7G/ztDf7yBn9+g7/G/TK4GhxDzing5X98V2tsFNcVvndm7jx2ZnZeOw/veB/2gL1+ rHfxYxcDkZckTnEjtTShFSEZJU3oS5BiG6okLRJICSQloYkq0dRCTZGaxNBKhQCu1yAFt3LagGiD WosqyBFUVUmaymp+9O+Wnrs7NiZpO9K395x53HvOdx73brQeffbUCptQ9NyN3v8X2g8396MUQAeI AAGQaNy/dSu6RwCx6F0KFsAD0gAD3vs3jG5DRtyKeYRIpnPj/wMpmm8l3E8hFr0r/g8s2bUEEt2X om9XYmlNLfLVjnRqr7wCwgrfuWhcehZbwQ2KZLpuPJLViI9stE58ib8ozjuieNB47wQcBHwbsB3w EOALgK8C9gEeBnwL8CRgHPAVwCOA0Wj8MuDpSKd4HDBGv9+YxAbWUS+canQcRzkYtWhUsIrug1GN 9DjoXuP+mftym3EV3zpwGKVO9d7/wNZT+1MPVTE//E34Ce6tYo5KHJVIXRp+DCSqMssqQ1WWqgxV Waqi5aeIqpiqiKo4uBd3NS608sKofOtjtAf9AdjMnIfSuwtKce0UOsZjnp3BCooVFhfCDWhoaE2x zPN2wnGFtraB/lJ5jwsXaYbroldOZ0oeaRrMZgaTdE4Z5txUn/NzFXeCmeBnmBn+InOR5/NsQDaw /YQTzsFSGK+tKGIG4esIPwrfcVWsnNklY7kQwqpj4411UYjDctlx7AQvtJdKA/1tcn1dAgZcJMnB THawiXilTLpM1zYABZSBDAqmrvA3eIY/h+kDMnVFuiEx0gwuIbZQC9FQLQSfWqkzfb108iwvSTwA i4IgSrwgIgYpgN3oLZjNRd+o9L9BTghTeIpUhXfwO+SScEmWRuQRa8TdYh1kDnIviK9jsR/3k/XC enkYD5MRQUAbFezB/oOhn3nQEwn0vzjUA4vjU0Vts8Zo4OwHi2DOUG1NEYdhWG6lPPf1Uk+FFfZV 4pYV1wxdd9Ip10mlTnStauvsbFvVNdnT2V7s6egoUP9TUEdfR6eRg+6aDpxeZ9hhjYYJ8BRDMYkg C5gDCWN1WjSLyqjCKIVwbq42B1ZsGJqv21GmNvTZwQA1BCwJ6lJ5JCbFRqSYRIgpKRp3+seiyPOi +AxH4Jeur8L6o8BYDh2p5D4ycJe+ytrB7GUOMT9hXiMT+i+ZN423jOnEr40/GjcMzWtrNRX2XIOi Sksm0PyMX/CH/C/6j/q7/H3+y/5P/ZP+BV+55WO/uRXSe8prs4MsquL4aTuQqlivxDRfC/SgGLBB Ibw8X9MXFucNc3CQxnhscGFo8TLVqFcoLIMrdYKB0WAFuwLPC9TBPiEYKJXKpVKo64ohEMILacNz ZSWVYddLCsPzIXEtQz9gWmqMFzlCBNF2PFPx5OaAj8e7VKnZMtLAhAa5Q5kooR9U2p7Fzya+nzpS /HnqbPGq86eBvyY+7o71cD35bGGntTO9m9mbFvqbqtirSFkPe14Pm8tcAFZ6IGYScONBwpCpfs9D fPN5SKA1sM3ETyN+9XmsoS7IK31K54uQ7ZBN84uUgBr4XAAKFsH/BSqHi0sU3On5crIFA43hv9Lj OKPNTWZS5HjCaZJpWsmEpemCznFQzEkj4Wm6o/daqYQKJcQSgeWBFtMRLCNuC6LIsQTyRLOa4ppN ROgSDLjFoaeAnwR0RVRemW3BQLnPBq1d6Bt4RBSku2VRuGck5vvG4DoXAgWhaiF7dvOPbdu2zPNJ 1IZ+WMm+iicx0ynucHYkx/E4edF5MXk0+YvkNL7m/MNRglVVLE5lMtl0xq/iZMXYRTcIHkHyZAP2 kwAHF3AzytLDC/ALXGNyJptp8SDXptlXMscyTEarUqqlIrQSYHQuBKb1uQbL4Vid5dnZ54lem424 7v00k7fpboV+RvNNKJWGLa8paTaDbxxvybqhabIuSOQBdhMXs8ZTnp+1NV4SWV7gRDHpJZpEFT+s 3R3n7+hR3ehnlfXvW/hERxWfZWacmY538W+Y38qXOqRJPMm8oZ5wJnNkVB01Dqiv4h+ppMSUcsPM g8wTDOlEJtRSckpRTC/dvlEC7z3IPbZemQQOi1pFpTVJa/E9n/h8FbrHSe06NLBOWovTWbtob7ZZ uxDW5hbCvy2ENdrTGqm3GJUfXDT9bhPwWXoacpSGpVLG1jTdUGQr49kpCxpAKm4QnhDMi4bH25vS LU464ahuNpFOdbT3rNEhOQhhOIYjmX5VpR1JB37GID8cVKkoFtJ0Lauxn2hYo7FeOj4TiLVeiSvK y+g6vK8nigkmUQg/CMF42IVmoZFcXtoCl60sRyEcs5swGCUYq3tlFWK07XjrRo/TYiIvSNbae+Jx 3AknF7luB41TADvUzcrodPbd4M/Mhwx3VJxQJ4wjTUdSx8U3U5PZX6Wk56WDsUPqIeO5pudSB7qP CuKe3O5u5knx8e49zF7uu7HvJb7TurdNXN08JK5vvd95kAnFrzHCNXG+m3k9X5XO5n8vvS9dzf9d upkXbSnfwml++9sQSz+KqYZJxW85lj+Vn81fyd/Ik7zS+Z50XfqnxEo27606D3t/GjhRTitmJ1Wg RrEyXTCL5maTNWmXqS11mcEQfsLBergN0x2EfRWP1UMd3g52O8+7y7y13dFY2pd6jlsqNdm6ZXie om5tdu20oce1pGsnIQV0XTcs3bUVJa8nEprqxURPsZJJw/AkwVbhG0OxxZj3+bidkGVb5E3aYyjn 41FtvF350mRumpvOzZHf5a7ia/K8daXjQ/yR/JcO5Rn36Y7D6gvGS+7h3GvqRO4EdzxxU5a3M9tj T1g7c/vUfcaYJXSp69x1uS3MNnFLbKsldJosbSLKK8oV5YbC0sqRNsrRbp+G/zW0hAjqBBphq9Ja qrSGKv5m/5h/yp+FGkK0hgoaPQawWv3MA5zWGt2k1mjZZlQ3d5aN+5mCqcuO69B3IEubDVVzdNPQ /8N4tcW2kZXhOXPOmZs9F4/n5rETXxI7Tqb2OMm2oeDWs82uRLZoE1QBQsVKBKwWhESTAqVLJbqA lsK+NBK7KuWBVqBVaXloSNM2tCobiXKR2IdIZAuFoPQh3VIQUh/2ZYWi8p+xm5aKByTLc2Y0ls// n+/2Zy3P9zK5Yo+aBgEmPEIUmw5PrW84bi7p9WT3Z3JeoVoZGksqBFIPoQihapg0WPd4UOhj3CUu C3nqWtTYr31dP6H/rvfP6i39HrmvfqDJn1aPqt9TT/X+TF1Wf6+JVa2qBzn8JwH1oh5+GWWuqqqW 57QcqK26ZOgGh2KLy/fmenqxpGsQT5cAF1i+Ds1yIJuQqLhT/5r+gYFVTTdI3p62N2y8YaNJ+ySs HtrElsK/QTYEmHGt5pbbbN0EyIXNreYJrb61skJBfuvaFruidjdQ9YnCtruMjY2xLnXvBgb6xNGP 12SeiLiMiYAG9AovEBwQAfN5ZA89V5EToCjCafpj+BZE8bUDHHCZxN51EVjRzzW4n0fBmPad7InG aed05XzlWuXX2h+1W+lb2bvae+n3spqTRQXtkD/nYrNWqEEHLhcKCa6qMINnk24GohjjF7lk2rTM 7F3nckiLDKi7YS9066Y1QJC6SBWAjR1pUxStUrRAV+kDimkILXm/aWw1DQjOHVrGYW6ryXDEbmM/ mmuP/Veg6zKQwWigA64+5k8sJDFK2vAukSh4vPBhz02mXSPn4VTaslxKGpaRJNRPWEQg5CQB37I0 UxR9wwJdTjv2fkK+aeqE7DVBg1mWZl7fwx2Pcifsc85t/e86KZtlZ8QccT5rvsL/kN72JC3F4GG8 Kb8lX5Z/I78r35UFOSncAD75nIsyLMdHelI1gET8RhatQia0wHwiNY+nMT+L5/ECxjhsH47nh7XM mgdkWms1V8Cqu4b8iC4MC2yY6XsUt8dcQXg+V+zrFTVKKA+zgGXYruUaLmSeLD9Uq4xQHu/g01a9 VB5y09jOQmUiVHYMKgu5+Wjwu+gNytf4jxSe6d9feL7/YOGT/ceKp+ip/nP0XP9Vor5RXarerOIU 4N5b0vVyHo7Su1StBWVWYiYeEfKILgU7HE1m4pCads44vINZjYl8abq0UcLzJVTqVAiJ3ejW+E6r eXMl1oytJtfuDk3blXWP247PNC4Zkkbf0514Vs+knYSKwEJHIPfymAcfFVSpN1fMCAaPBR6yvnlh cCg3IsslFsMEOgJywVOys1DeKWBc4+009MQDdnwB2OFyY7/AHEM5iiOVDisNkUWclKC4SAYzbqRn 03w6bK8BdteaXciC0T7a7FNDiDflQuIm7pTLQHle6EKvc4F/FmLFusiNoiDKj9aPSf+u4VZfq3+y PFmZHHg5vE3FsNKq8MsiEtkWUvWa9H3htHBe+KVwW7gPFbGn+TCsi3WpVg+l2sHSl0qvl35UulC6 VvpD6a+lf5ZkGEIykV47WHy9eKF4rfiX4j+KQpE9S0tSrSiJ9VAo1SQjk6sM4gwTtirng86p/Cg2 2C1EVtC5vFiv1arVaihx0xza6H4eApysgorU7HVkc0VQRHXRMnzGeGPKQqsWOmstWKvWA4tY25x/ v9k2QBPnDjMzDlO7U2z0ibWRfTFLFo2tNoTStiixV0SDbrUluGUKyTjR1ULxf8x8nWMY27V9I4qx fh4LAA+kZFAi1IVYIepgHiEMAyTgqUILARYBGIIkTri7t4+IXSbGxTjD7/iMQDsejeHMjnCD3Ch3 PqpPkSnv82TGO1KYLd6i7wb36N1AqaGS1+Ib3osoIpF3EEkDnGMYgiLEelEYbgxHw1PDZ4fp8DDn KGycdBC+8mpxvsgXe34FwtEPE28tFlm6OCA0llHysl8o+li9jlQuzQ0h9bKOJzGPw7k42ayvQ19X gFjgxW0Wa8CMY3rFSgrJpqMjY10/dp6w4W7AH42tGWLPQJeDgjBsWvm6bKQ0IBY0ywchxTA+UUUS JV5JFRNJ2VRKPk4lTJcmFTUhgPhS2dC1fRKWJS0BzRfzsi6KIUmzlBonyiOAep97LSp8S7oq/Va6 JW1KdFjeJx+QPyd/RT5n3CN3HSmTRHGvlILYEHlRTLmYdclFeKkBaFNuQI9SEFY06JAKcuqjDR81 fOSDPwAlrhgWgg9A7nDHYg7/K44p0Bojbg2I62GGpF2VR7TtCOrjtsyglKan7ZRqEopt0+3psdO5 fY7r2ULW1RN8wu7NZYp+AWrKAotfAk11uBL35etcD+qDjaLI4hQ0r5xVFpQVZVW5ozxQRIU8q0AZ FPFgmSasUnDOBWRG5rx/1l/wV/xV/47/wAdbSsCZR7JDUg1nFiQ1bK8Ddd5Zi8eUJphEe64FVYx1 jXEXTKBPkOHJOWU3obYiGwzd9gs2hSOS4JQk6SXgACZf7ID8jEjjxyKbQDJQz8vcVajnE1HPAlkh q+QOIbPkVTJPzhLSIBGZIjOEEDuOjw6bSLhkHA4IrCjbuGEnGsaswRudja93dr0O8QY2/fR2O9wt dzbpvhiLpXORkLceE5Hti+WY49xRbgI5UaZgDBugMfoBY0af1b+t/0D/ib6oJ8hHb8BGJqDBRe4Z lFlK0L0aqDe+0twxmHFoC0C16AV7l0HRenQv74VeyyOT3rR3yDvunfTOeBe9t72HnuxdQ/vgJJOX Zl3kLqN9UVU38+aCiUMTmXqQD8KgFZDJYDo4FBwPTgZngovB28HDQA7YDxusBYloaGpoZggPsZ9b YRmBgZYXyrg8Hu2Z2jOzB++5Dq9S7kMwtYxP7GVvJebHkTFeGG+M43HAbqyWm20G4M32ytZme259 rr3ZZgsQzI5igj7GeGBxodPYXQy/7q5tcj/ZZdDD/+NR306RKpinSVFWEFXFpEwIX+LhVKiYwN01 ER6veUy+yvMpSRQlSdQSHyNYAGztT4iK/EJ3LcuKMtFZfwrj+DwlOM+j3CuQSH8aaQW7YT/nTNm3 B++XhQGwp8XUf9ivu9g4rioO4PfO98zOzJ3dnd3Z3fHuzsbejRPbcdokdgMrdk3UECohR60oViuH EiJoKSVOGtqURkqF+hAhJCwe+iEkwlMQTwQ19CMfJQ+B8GGpFUraqLSkAicEgqmEIlGkmnLurFPb QJF44O1v5SdvdjfZveeee+45LDzDVSYPjKDUUk6M1vtULm+kmmw+XxitdWqTNbV2mm6efhr5qnTp 0I5yQVs6Wbost1Vu6tGSVtI3yuspS3XTpYaUy+vJDXTe1fmsflxXltvRG/Ji2j+/eOODbn2hk9u6 IEvo6k70g0B/eIjpOFFgLFO3NYUKZZbuHn09Pec4dp6aVF02ondTKBQ1cpxcrttL9m2u52ZuTzNe oR5EYQeoYmaoN3msu+nx8OGi8oj2iPWY87D/eKBf4X/KzHu/y/4lvxAZDyoPanusPc5FOSp6v87+ Nv9W5BQmbIqXTWGUzYxKFTNH9dLvsleZspHtZDN0qFxZMCcNnhjcoEAsUgRkkemkq6Y7l0a55bpo rhjrDtSKVBajUt9UQWTzBeEX2+XGmlJxYCCqlONSJY7lGsz3L9MaDrJ+2udD3fyT674x9Nq6q+u0 hwa/NDxTmunTaMIoPxcm1WgiS9/To++Zp7ZLSQfSKn1jzjR6pHAjvfYqFg8HElkcfc0PLN61+Kx1 3FIsuYfnzi222+eCt5aKZG/35PbJVjr6l1ZhxR727j7atrXF5eWZ1FT1WgVbbqGZdcJKXz4jqBvQ heOHQtg5M6Y90x/R9N4uxtW+mmn269pWxylXSqWMezPPv0p5vo7t7mZ+GlwMrgQqK9tiwqNbTKU1 r6P8pdGM1hxR61ViZapO3ivuZfcdV3WNWsTy6WVQ6y9vrM3WlFqvprbn6N6fXroOqKXuzUzjK1Y0 /mHHO137JidynYxOP9QSW5Gta8U7QrnevGXmdfXTQdaWM6SuamFurJecd8k7Q5FrKlDiPESZuYmd 6k68y/8WKzY34xIvxFrH6WR2FLaXdtw6Vbi7NHXrpZFLo9dGro26J4xTyTnjV8kF4zfJvHE9scJb og1a1cj48lDbMhRdO3miOdtUmv2DJ3vb/8KGW4ZYFGaHZAhcJ6jwyQo/Sjd9Vj4RDjBqK2bYE2yW HWdGmtdsdB+NGhdkOizQ7ssOku7+9tz02U57Ye4stZdLEwdNl/9htKJ2MSouBVBGb+34zZxY25J/ ylFgB6qqqXR+864nTNss2FamEHqepppU4dQw5wtLc0q2bX1GBDSENbgnHNuyFXpd8yyR1VWlyYPA cUxb0ai4uhTRII3od6g32tWtfSt3NPfD3E9yr+Qu597JmaOZj2U+lbkn8+XMIdeoCHmJRcXgDCWM QVErU43UfzxZ5mWzcIpblESMuz8S3ujcYntxTqbIwpudubYcVNI5a1W3s6WXDXQUKEXajuO4iq5Q 6yNqlivo0A0ODviO5yp+LpffbojAWpvWbvpcOtNfYxvYkW60odapT9Y/Wz8/cnFkfsSsVIf8oZbV nAjTbW3R18zTo1DmNf3bcnqqbSrIFfryLgupGkd1wYXoiElxWWiTYq84LI4KTQyfpNebvPDc8YQn o9PzC2+m1bl9Q3a6FxapRLeDC+2lHnd8eXJc0WDQDvZvWVrqqhc/4mbl2TYMR5eNv6E7hqKHXhDc fJIKsdeRJ1vbTdmvqoVMJhe20yfu8uWOUcbSuT5A/d8/up/YwvbQw6fYs/wY+wF/nr3Ez7Of86vs j/x61jdpMBrzv8geEI+yg8KMBU/EhL9dbAu2xffyO/2d4s7Avq3AfSFrIfP8gH6fiFks6GjIj/Io 17OKwhUviH1hMMMOI9V4WXZfzKT4Uli53q2MKXxrfEVRlt5mFutFvrd4mPrHk7xD77G6zkc538h5 nXO6BTvUQJn3mTPmrPk987j5NrXro9Pv7d83vfje9H45h6V9RnoR5rI0ldFIFiyepeHMCv6utHnv FNHbx/vpXNwcuKJo08rxa8JYw6lEDlEElZJSUil8A4phquruNM7m9tvleGWatMjM+2+zRymIw9T4 f+5Mwk3ZKG+mIvNM4yXvxeS8/4vkDfV1//Xhq/4fyu5UcoQf8Z9pHPNPK8bT/tPi++yY/7z/YuOX 6nnf+mRyL5/yvsCOJLrpW3XlNnOHOWXebx409Srj85ROMtJ+I1FkpD3P54zqyYnk+jAfloWl22gk 93sHPcXTGrxhtcKNrW5rZ+u+1kxLf7XFgxZvtUYmrb3WYUu1GjSEDCtGM0mqfhI1Bw1bbaYXr5Um vyzqclwx0oPYm3G3ysmXIsxHp2kgoRheoOf2bZ2WMZ4OFs+lQV6cbrfTMFOpoh9GkV4VW3PFwCLT emxsfOVGfFwpysxeT2OZskYXrik7Eot6NU5NxxpOtWg9tXE82SY3wtA/T3VJVw1TUXVhTcnd0XXK 8CrbzH7Pvk71qUzzDRtvtQyjWKRPKxbHNrfoW4yNFYuhYcjZsdXaTH87LOK4yvsasZ3dXK82y6od 92X9Wlx04j4/iOMHAjr8zbwnymrYLHhl4avZbFbL5PKOGtADGuqWfpz/wS7yxr/jg0vosXIPY+oe xrQnyRxjOjH+zJh5gDHrGv03rf8u02XMnWHMu2M1f9eSSz3BN/8/sj9bLffd1fJfWRZSmS68xljx Xcai04yVXu4pf5uxyjxjMf3ue4qx6tVl9UMAUP8rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADAP9kne5aGoSgMv9FgFT8nBaeMSovioFBwaWtpq9KKFbFdJNS0vW2T lBAHQX+Ei5Oji4u7i//BTVB/giKCm6BvPlYF3ZST8CTPPefcmxNyIwiCIAiCIAiCIAiCIAiC8D/B BK6gITrmSeSDGOcocp2+EvsQPRd7AilssRL6CCOzOI59gGuexT7I+EXsOv0m9iH6HV2jA9t4jT2B PW0t8GE9iGvnsQfx57nGvJFz+0eearV9o16slAu1kpHvWQ3fcx3VYHLBWEqnl3OZ8sbmerKq7Oqh 8/VgxzMPLNv0uobb/GK5lJG1VEc5Lb51BmVsYBPrSKIKBZvXQzjs3kKL1oMJ75u632Tm0OB3MFjh oo8jrq/4rDZ8xuooosJ5BdRQ4jjPDizW+6xyOVfRo5kLvC8hzXMZO8yaOGClHfbbZc5F84frpWhZ ZhU6xGFPf6dT7t7dE83mc4JjAFNYDHa+Zmq3YUQLo3h5n5nen1x9w2i03S+fop/k+rFzCnw84AP3 HI6xNiz4FGAAHMFCywoNCmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmo8PC9TdGVtViAwL0ZvbnRO YW1lL0NBTktMSitTaW1TdW4vRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiAyNCAwIFIvRm9u dFdlaWdodCA0MDAvRmxhZ3MgNC9EZXNjZW50IC0xNDAvRm9udEJCb3hbMCAtMTQxIDk5NiA4NTVd L0FzY2VudCA4NTkvRm9udEZhbWlseShTaW1TdW4pL0NhcEhlaWdodCAwL1R5cGUvRm9udERlc2Ny aXB0b3IvSXRhbGljQW5nbGUgMC9MYW5nL3poLUNOPj4NZW5kb2JqDTI2IDAgb2JqPDwvU3VidHlw ZS9DSURGb250VHlwZTIvRm9udERlc2NyaXB0b3IgMjUgMCBSL0Jhc2VGb250L0NBTktMSitTaW1T dW4vV1szWzUwMF0xMSAxMiA1MDAgMTdbNTAwXTE5IDI4IDUwMCAzNiAzOCA1MDAgNDJbNTAwXTQ0 WzUwMF00Nls1MDBdNjhbNTAwXTcyWzUwMF03Nls1MDBdNzkgODMgNTAwIDg1IDg5IDUwMCA5Mls1 MDBdXS9DSURTeXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdp c3RyeShBZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag0yNyAwIG9iajw8L0xlbmd0 aCAzMTMvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJVJI9b4MwEIZ3fsWNrTr4I0ASCTE0 7ZChH2rS7MYcKVIxliFD/n3tO5qqA6DnzCs/+EXs9k97188g3sNoDzhD17s24DRegkVo8Nw7UBra 3s4L0d0OxoOI4cN1mnHYu26EqsrER1yc5nCFu+OxeJD3IN5Ci6F35zjJ9ecpTg4X779xQDeDhLqG FrtM7F6MfzUDgqDg3/B49QiaWC17jy1O3lgMxp0RKinlqo4PpbAGdO3/9UxJjjWd/TIhu70utawT KcX0TKQNUb5mskxbJmR6JMpzolIxbZgKJs6VnCuY1kRkWWmt4n5RdrEqfh3ZOUk2FJKc1Rt2ZXPF wxV/gGYRXbLd4tMRFRwodyxS8HDLPnox4D3TyaVWb03YSwixJKqeqkgl9A5vf4cffTrvdGU/AgwA ElCipQoNCmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUuMjIgODQy XS9QYXJlbnQgODAgMCBSL0NvbnRlbnRzIDMwIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5 NS4yMiA4NDJdL1Jlc291cmNlcyAyOSAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTI5IDAgb2JqPDwv WE9iamVjdDw8L0ltNDg3IDYyIDAgUi9JbTQ4OCA2MyAwIFIvSW00ODkgNjQgMCBSL0ltMjYwIDY1 IDAgUi9JbTIwNyA2NiAwIFIvSW00OTAgMzEgMCBSL0ltNDkxIDMyIDAgUi9JbTI3OSA1NiAwIFIv SW0yODAgNTcgMCBSL0ltMjgyIDMzIDAgUi9JbTI4MyAzNCAwIFIvSW0xMCA1OCAwIFIvSW0xMSA1 OSAwIFIvSW0xMiA2MCAwIFI+Pi9Db2xvclNwYWNlPDwvQ3M2IDg4IDAgUi9DczEwIDYxIDAgUi9D czExIDY5IDAgUi9DczE0IDY3IDAgUj4+L0ZvbnQ8PC9UVDIgODcgMCBSL1RUNCA5MiAwIFIvVFQ3 IDY4IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXS9FeHRHU3Rh dGU8PC9HUzEgOTAgMCBSPj4+Pg1lbmRvYmoNMzAgMCBvYmo8PC9MZW5ndGggNjkzNy9GaWx0ZXIv RmxhdGVEZWNvZGU+PnN0cmVhbQ0KSInsV0uPHLcRvs+v6KMUYFski88cvTaMGIjhYNcnwwdjLMk2 ZiUkMuC/n3qwimRP33IKsBYMqb5pVrFeXxXfPX7J2/XL5vnPl+uny7tvn/z28csllD3WLfvdeb+l 6LYS3Paf95cPl6+eL++enwN+//zh4jbI2wP+77ZW9rr5GHeXXNqeX/C3j5cHtzvn4vZ8vfC/YHv+ 6/Lm8Zcv7/3ftx8ef9geb7+///Tnl+32+frLn+9/3T5/2n785u3zH5dv0Azd7vEJddOfp8fvL377 Du3+sbm9lrT9tXm3/XP76We3/Yo//b5dgo97iRuEtBfw2wsCsLe8RYeOIHC7PIlW9NntJYUW7/6m KASf94B6at191yMANHTPbyHk3YUttLaHgiLgd9HE6yUkt4c8fs9u9+OwSF03fsxyhLIHjHU/Gkve WzPVKuLXYtp+l4vZ6fXi18uHv13+jZnIYc/QGobioYS9YSZQh9tCbHtCuOBdAU8Wl6Bu15fLu3+8 YGy//nz51/96fJRWcGnHmNW2xyYxdZSbUIGTdUPXKhXdHQC+cBgJwItgemH3iWVWeZTVxI28x7RG 7yuVTA2Q8O/moUC/EVd5aH4vRcsFwxdq2isrCOD2VO8B8GoihIiaueRCvwMrvQPUyk1zguUQK/fE AzoQLaih7dm3RlaxmrGZfNOYeomp23NyjXwquWbAvxPgf710A1YTHa3dJZLBYyS93CbvQC0Sdz8D oaFWifqioQcxptjITgmJYgiA/5jsqf6XE/3oXFkBrJr5Rocboj3hmKIcg1nB0DzIXxghrIcmAcVb M9d45RqMFXEN0cxPb756evtQ3zy+/fn5O9IXVd/HS8Q0Y9YeAD3B4nj+Wk4HoNNvnr59+p44iGgH fzJZOYkZE8OF/wtf+JapDlPmOsQggAShUAKlbAQA30t7PcFOe1aH3X9QGSSPeBR5FqrTWh82NG+N mgN70h9MBMsjM6mUPl6NfsWG6nmjem2IoJ2WNpJzI5kMYlNhXqnwu3okIocc48ggdieRIZZ5BlQZ 6+5yQ7nx/WJml/GARxIudCAha6AFJGv6EHBm1FiYu3xgkYJ25cqh4odIhIAWKASlsEVAiXs/gX4N gcoqWdthp/qc2KHYCnO2L43v1xyWT/DcuKisMyvGr4TASKrAZZa6g5Ei4JM4VLgxxKHoE2uEQB6j 58FzyLCDt0OMr5ffLOxIqNA07AXLDnLeY06sIyFNQcY4FzIa+Ja5mtG0OxxThGRIfEtArzJelrzE NsII5WQxxDu6yhYrDmKSgyN7WO8+s+ytDq9MZxQDDGPzU1VRELscqfnoRC9ttEhhQQCaAiVGNgFO ruQpLBnzHQLnPfAVc68L2DMxJiH0ObJ5ziy2HDkCSX7VCGDwTCbJhUn0zDbT134fP9+kCqtF6MZj qIQDkO1+IsMR8HKie4ylXus50AcXAuUgd6d0ci2F0QlhjE6g45iEJOsIfk1Jx2Z01XOvtpa412rN XESB+yxLUtFaAGmtWimktGNUllNtHLTEUrAI5wjceDVUTkmtSWRadHoNoCiFTXM5UVVFPNioNzFC sfGFApUARI6YdYKyWRpDAbuSC88J/eD4dLV3Gy02wXFeUWETDXgH7yJ7GZvQjc+1H0CTS8ik9xjJ RCISRJX7tuFAkhb6rhhIvSWEYu4lQ8VSRrtWBpukUQoFbNZGXgUQKGXJcuS9WgDyEgEousFAZaD3 HwJpqZzMDUrd0RSImQlEr4ERiJ0ScLhRZBp4lmuSbNfMohIzUnsqjAARHcba9WIkHiSROr4yswpR tmzAbQBJ3ULm5iNRHafpnjm73Q0qqchHcueVsoeZvlGmvY2sRNrJUM5ECwlbi2kiW3KkGrKGOsps SaCRroNEohYgkYgEvmcfo9IDPwA3vmCaWCROdbQYdk4Yx52Zm/p9BqIoiEYZIRwAv1RG5aZbgCoq dNGswn0zkJZqmzvAlo7XPeZ1j3ndY173mNc95nWPed1jXveY/8c9hnKPqY7E0aCrC3ZBbLWn7mnZ Grg6I6Y3y6JDQx/lYhZU9qAyqT8D9I5UrefA8NPVBeBVJIbGt+AjWyTKgSlQ06VwZHp0sdgISxTq UyCAAlgdkWtwAcbUS5S/U4CUTqIrk5isXrrCZPViQPdSLzU6wgAPs19DBpS8tZxIPUSyRxCQQIHC ssaAO+QUCHYCBkCin0XPUe+iDN62KmTeWYEclksaUIwNE2bSW230+vMrXRKgXUNbIcnZr/KgUy6m QfIG1DKfCMavIg9Stx64A8SN37hCPesovU16CdsWMgC1UtnKLLPSweodmL9Ip7IuOo5bMSxrDcnJ T3vPKRAOGvxBg7NGy8IdzR+AApNXi0xuTyc0UKpSZW8Jb3W+0wDy4cRRLuNhNfYontDq84sOzzkx BozxmuoZMDKTqZNO5KCUt0iJY4T7TrLyobagBagpAbblTvRQqswlumEboJmJHOesYezyIJcorXsC ANOTic5PYtQFsuuLRh4qB1guZOucAqBOafM7W6INSCsbjBWBttIzeZRjyweAJsd0Qir6DNBIckmf yKMnYj0HtN56SblpCwyRgQAHYKyFPjCQ4ABU3TWZs2xJZKmsH98BYXpLsMHRNAaMXRZmMpCXKVed MOdLL1tbZ7qkbVvE5B2QrJGLWLgD5iMUyQlo0np+3ZFmcm/SeieAOx45ACO0YhZHu84YA2ybYF/O ADuySD1yU/Y0lN4yVOM5EI9H7gAJBvLYvIc5IjlKfJ8vLGO3acL7qHYTj5bIDTrCQIUephtRiVCW 5meF2rgdbB6I1bfG/Y4LpqyRCkwGvBho09Mn8531OSUGqav7DYD3HXrwLNO/G7kdrR6DhK8SCjK+ Pas8+IiNsgE3Xn4psfgYVVICpupqNEtBwwrVBasoVasCMYFVrkN2sXkcPzQI8UfgpnqxpawDYpGm G+6y2Uix5sUA6JBWYs26UKsONhLspbEYvYtRnHcyvBJWMRfKWNL4OA7uLlMRcxn0kOEBujICnSEH 0IuRGmOppG4D09bsCFG/szgQNbKc7YOeeTCdciCkVfamgCsjWC4bhwkBHWGNyg/lYDLxE5bpCCyl kua1DdkqR1bAYnVINszT6EUtTsOoiNfFgMb1iV7ENlfTcHsAIS1ugb111K3hd6zLpZv0YbAEG6Cz u3EYtMQr16gbPSIF4W0iVuZgBHSGVmEOb3O5SiM7zTfuGbXORdRjNSmFdZQf6C/pi9D1WSUAWK6o ElA2r9E2NcGgEiyo5PlExfiQ7GpiGWrZiFmK9DFVw5WphpJljT0B2ciIahQBiQMB8oGEQdkKAddP VOEjLXsCmD2s7imomflA0qtGxtt2DcX9vmt75ItIYH1KlZ6Z/JJfPEq9ENgBOVJc2/i6XjyCFFmW 21NWr5chD2+isFtsCgRxLyQFWCGYe0UIMfTZOgG6KjmuJaNgVTpt8LN0VzfTS+1Fp+AUTZW9LS2d XO+AYLsBT4ATQJ+oVTME9sTgpaWN/YJTrCaqvHDsUtgtnveNaHII54ByGfoZGfB+AbKNkSTD9gSI /AIw0ZVJlPfDdSgcDwoDlKr6pZJRlQEeZr+GDMylfavqkrKWTEp6AoACZRlTgYN6BgQ7Af9lv0p6 4zpy8L1/RR9lA5Kr6tV6nDgzRgLESCABPkzmMg3NYrg98AIH+ffzkSyy6r1uyW2fpUuLrMelWFw+ DgaRfiY9R72Th93EUIV+3e1tYRlOGkORYaIxhom5BjBgLGXDUNiXbsIKAivd1uUeDFYbo5ZZwvBB pxdbPqwGThhyjf9whnrWUXqZ9BQeNWYMtVJvwoZmpdm2os6Yv0hnaZ07vIl1H2Z6LGIdCJ0wwkaD 32hwVmj8XNWCa4yyTLda0Qxqh4QGSlUqPWB3q6tNzBh5I7GlyynK3qxtR8PM08MYoxmMT/UcY7xM Zrx4Suv6uqYSxwj9N1n6dEzcbLNoK58Akzhq2QCCMbwBqSDNZpnpNMFiLt0zjIXbk5HOT2TkjD6Y vmjNQ+mwrByK1i87YzEw2IvfGWIxRlp3gwHvPCX0GXqkY8sbxgrzaEafY2gkXYeUW3rURKznGZpv PaWcPb8sggSolw0j2hc0tQmjLxuGLpey29qix1RZf3zCGEXTDY6iMYbupqs6kJYVJeukcx572kYz IpSWbRGTJ4xkhVzEwgljFqFITowmpTd6tzG0uTcpvTMMtxXZMEZoxSxGu84YYxia4LucY5jIiuqR m15PQ+nthWo8z4hbkRNGVlg64zDXd0jf5wvTqDZ98D6q3dRHeSuNUxgo0cPkES8xxVJEGuFYOlc2 N41VoXnfH4/GmAx4MdBGVrMHi86nbpCqunuwyNaTN9PfltSN1W2Q+q7XN44j70QM2KM11izweaxm C7fqam2WgoYMVYBVtFWrAjGBLNchu7J5stHy5tcB/tFAmSF+skjTDVg2rzDTZGDRIa2NNSugVh1s BE6ritnoSYzijMngErKYE2WANNlWq9KUxPPmCYEmq2jvkIPRk5EKY5VJ3YZbtPLBoNbvLA7UGpnO 9kF/+cV0ikBIa9qbAs6MYG/ZOEzO9iAwMtPBaOpPtNRZYOkpaV7bkK0ismZYrDaPvczT6KgWp2FU 5NbFGI3z0+m+p9k0rj0YIa2utdiuo9ca94515bTspGBEv2Ho7G4cBk3xyjnqRo1IQnibiJV7MBg6 Q6t0Dm9zuUohO31v4Ixa5yTqsZqULutRfrKGurHhHY2x2FtRJvDWm615URGMVoKESp4lKuJDtKuJ 6aWWPXWWInVM2XDgVkOPZYU9MbI1I8pRMCQOxJAPJAzarcBwXaJKP9K0JwZ3D8t7CmrmfiDPq0bG brsOxSneNRx5FGqxOqVMz9z8kl/dKPVE4AuISHFtz+56udGSItPiPb3qYTfocZso3S02ZQS5XkjK YIWLXa9IQwx9tk4MhUqOc8lasCqdEPxMPY3Np7H5NDafxubT2Hwam09j81vG5g93SB3kkwv7a/lx +5BwBymk0lza3x3xzb9314izc35/d9hdvXp1+/rZ3VvwrzG5XKj7ux93fJ74/PerX169+f0ZffLX u92Ll5/y/vBpj0ZWXGr0i7+C39IyHoheg3qYW+isxEZu3LQUWtzfvnwNKz/Drbfgubz/Y48GhmDz LCrydiv6mucWF+bH+90Pz3FcblKw1kHf45PINZcQ60AzLDPpcf4F5yj3ul/wxNQoQNr/f0q7DUOY +hJTNbFs7zFS8NxqA5OU1tzLRzs42MCQhtLtckvzYitIgxrTQailN/LVxd7t/vlcijda5h45lUuw 3KbiL1a7X7hGsnSHSC6ApLbdyT8ZC6U+tFm8KEwgbSSPFMtWyQydhCQfifSS5hSeAwOZki3vzVy4 cUnMCYyB+8HqrEqV19Gd4lSafOlEY5UeySXteRNDUsLznJScwOPlmhekVPJLod/Cv4LXFp24NQle WzEiv1JAtUTTVpYSEiV2A6rDb12QvQ9oq41DRKhBqrQzpmYjIga2Njr4zu4mLi2QraXfJPuW/cpm V3A8NREI1q0Z6bxNY7DN0jD6KVq1orEQdgkl2dyZMue4s1RAy+TMqnIu85oqxSnA5FIByYnm+JzI xq0sFU4cAIlF3En8taf5gVbmpCqhPWVjCP5gjI0eaRgmBsZ+OmiLaJwZ1Ba6TcU4AdNOUh2MZaQi WciS25k/X25GYRwYvyYprCWJw0uY6qxx6XbyMEcrpzN1SFk+9SEBoy5Y1xJgEjjUX/gqiiLZN7mq k6qnizCWynx6GHAOfTSNm+MJolRlj90EzyJX/Yhujz++UCzuuO2sGI0BnU/2flSmvW16BrW9yyCW vhreVGu9ix4YI3En1LvLwxBO4dtW6hAaqkMHwETTQ67bOWd1pUw2aMo7Q/bybkdlpCyXp+GBmyac o+rCUikJOgVTiTTpIUSQAiYppGrGx51RKOX3IlpwiiHb9XbqsOtW9bT72AXXHh9orn/A0CwEWltr aX8dCJXg30bjHc+eSmtAcgmtrBYXK1w/7l78dEQ9/vi/3W8QD5HRdPaCEq9p14KrmEfU88LCY0BP j7s3z/fvIUU1ANWlMBzNnnoUOuKevu++ZE/TzaVYus0A62z0N/Z6wTxdHN4QNrHYkVAlr6lvQBms JiirACZOvQ6lqdssz0IF8lBVTN5zCIBjUwsMRFAR6oGza+dIEzdldFpoIDiKNE3E42s7Qu/91G6N UUCe+cq3jshd2Gl7aqkRSelJHyovuZTVJA2/6dKJMoTf5xojfyn2VGSI/s9kGT6bPB7Drgz/MpAP XxkVDBQmOI6mKsYlxlSOBCsdSal8D9lZAFi4M6eGspoA4MB/f7/66f0zDNV89fn+4/v7z8/+cfcz AT2EApmW0TpylTbGXQy57Cl8bxAtxYITDieRIiJVRBYScYVk/jWtNvy80EWZDHfxZbP0SATH8H/o tpFglh7QNNLjO+Sz07caSDYKgrWlCx0TEaMGvDBiqNwzaKZJf6QCWDEit7Au8W6j4Z3UsKqh1Q8J EzNFE0uOBpOAdN2/wlLzM4JJADnjAQkhC8wibc53fzJbj+qNm2k44+3zdxtxHv1cHGjXIXcfPSB2 YpwdHnanlMruILOiXHYpHZ4lNi8b6K2opxFZv0s9o5uhHoq4KW/1F+7cph+lfJl+ZEqZ3aexd6oe bSB/l/toTW3SDj0tnKpfZJh8h3oGXkM/4Zcz7jvpfPihLSoTGHM0Ar6ea10QOdQ4Oo5mQ6eHesQ7 glsYkXf1pV6g3gQ7rgQaoPh0xnjdrGYdpjxq+1IDQ7DHP9C1Oz1elzY1MorngvaSL4yOycmgpEFe jR7a203oIfum2JtclmUPI6dEY4zcQf1ZxDI9F4XGuQs6iYkS0CMLjbPHKfIjCyR9ph3GhrHGjw10 JgCCO7ougY12GD6eTz/weTTpQjiewPQUjoJB8XDbU8XHRy2R4wo0H3KUsMpKPG88Ra8efmJ5uNDP td7j44bE0cbb0XB07WdjsP1gQHHe1X9rRNeaj4+aYkdpfs+OwsjsKdLfzeLr4w8sn2dXgdIudHWt +vi4LfYVAGl55PVxnB59fXwQvuv915qPj5sSVysvdA+8P05beNTTqvq/2dWV6uPjtrTXM7yIDYPM i7PUzVbt5sEK7qJYWNaVIYzR7Tu78MKYqYphYyHcf3H1VfTyntKxKj0sNNpX7Q5AbxdfoovaHTQR N3dQtt5hyZffQWX1DprK6ztoWtlD5MsvobJ2C334zS2UbS8RLr+FyuotgENdXN/C4/OF/ug30/w6 M2EMcZOozKVTCK4IG8naJobqWGNu5TJKDK7nt9yGxC+ZPoK6Y2uCogcIL36Dsm0FmOQn2I2Ig43T 5gXTVIKCX/cnCixWYCO0KLL3I68kWV07Cyu32hVWolJ5dMK5JrcVLBKwzc2w0rN6+JC685F6+ted D7RriCA73+k2IRtdXrHCXcsPLa+IVcbC5Deba6DN9epvb168/svds7u3tK+Oda70DKulRv5t+J4T rTBc8gXq4SkqGwclUppO2+nty9d8BShK8L7uf9l/RfKWnH9xd4fptr8jNSibayqdfWj+JqA9V0rc cYdrugTfgf6J+O+P3dWvL3/dv3z33/v3nz99y5UAPpHhKfIm4SvB38Lhk2ny6Pltj/pwN9B7xoyn 8xt3vfm7RPP39v7jl/uPl7vrI7+8L+n/1FdNb+M2EL3vr+BRAtZZkRL1cTR2gSAF2hrb3HZ7UGQ6 ZitLXklOmh+y/b19MxRlWXaLvTYIkHAozjzOvPngbbi8f952bv43tFLzsC9zeY02Kia0ktB+CdbH o6hqG6JwBuzj3x9/+mHUmh+zgKWym6j/a/8KNryLmU0DdqaXTk4n2Dk7mVA7J1+R4jyh5ykpVIhx 5Kq7EyRJwYKaBYrXKvNrzeu48GuaSC4+wDvzUgME3sZ0ROkYfjvrpLXLaWfzcn+Gsn63h6jgIwkn 1cGrSHJe05F4tu9OxAw853ehP0HsjkajxWy/ptgAQE44UeFcc3ECnaYsqFlAb0YInDck1Clea7/U i+1UXShggTfhTyjQM9dnhbR2rhgtzj+4AEk3lfifzuR3UjrYTofiNR2Rs313QjJsyp3pgM6ka0hO 37hLjrlVb+Mopn6pMvCgWGZU4qmpc5dRm4/hCtEONuKz+XYy/fDhs+mPbdMbn1vfcJzeELrAj1gh LAmXdeSLzooiz4SS8F0WaVSd6vDuw8MhgfBTi37wI3mZk59lDm2ODRH3dhVNrHUCiXlm5LXm3LsS zI4grEk6KT0fQRsaWTkKkOCZnlu5EkxHMIxQQ5QR9ZL/Dep+bGvJdVujh93YDR1N5FSNXG+TTBbf J6h0RXcSFJA0hz5+QmHbPJD0omteklGC6ymSAgxWetH/peeidFVys6HaTmVdWPw2u7Y7mC0ZwISm ckxiEVl1RNb+cKQckcWrHfbiF2JzFqxDiQ7xKJ7Mvnyx7al7L5jOK68Jd0AkkrO+qdXgsUNoymYr hr1pBFC8lt12xDOi0XGqHZpxCCAE5WDbRgytoJv04SqjJgUgacCl3yGIqCGyh4oxXWNu7mjaKhvD QC6JCQ+gcdKx+u+bsKCBNfiIvwUuuQklPoRArMedSfLgbZEhtpJytZIqn8xEowU3FZCFv8NVipdJ HjyGYFGwN+Kp7G0lurY2FBJc7di1L3ZrRHk81rYqB7Yj0cJlmjmHfAnghZ6iESJFgr2oymP5ZGs7 WNOLdieGzj4/m842z4KmjzEu4GIKFYiLilAofFxkxtHoXG3qBYWlKrvuzR/vuFptGRxAcYMlJZpU JclcVbK45Qa3jAPoAI1F1Z7qrTB/mGqAEWH+qsyR4+nizrZ67uFkaWtqMxgYr8vBbMWx7QZ3EW9Z nZklz352RH+yzRbw34tX4pf3JNlqO7bjsoA8vittDf1lVcHpzVDW9Run4ZJEPF/ncxKx6XjKsHF+ +h6uiCHIDwyHwYkIPnjjFcIGKx2vlvxBRSdLc/7cvt3k34L9qwIiTA+NFDBEvzGvouoM3caWNYft 0IIeBj59sZXh3C/F1u52tjrVQ7hSmMjSYCj7P/s7n0Oz2J6fEreinILLkphsm8E8u7u5SvHbw8+i PI0ExoeFJ/AyL4K5kwCubYzo2/rEa0e38fiScXPnZAvn/Arfd+K1fBsTqz0SFxYR8ZnzJvpTtRdl L+J71Jb79XrBtouUcSz7GtybBmlWifWl1nVX7e0Anp868zWE23e2MVTfnPI4vlMqEuOg+o8AAwAZ 1HSvCg0KZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDI0 OC9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1hZ2VNYXNrIHRydWUvQml0c1BlckNvbXBvbmVudCAx L1dpZHRoIDY2L0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDY2Pj4vSGVpZ2h0IDEyMS9UeXBl L1hPYmplY3Q+PnN0cmVhbQ0KzXy+XBUL+IuH19V/N+QzR4XIKBx5H8cQ8hrj1yGwfFZBTH/vWQzR 943r9/Xu6/7/r+veQbjh/ZDj/IMFwvH8HwwX+FWQUEB3kGrviEEP//+F6yGqOIPIaNB5BTH3mnIU fULj3N8PSB+THIceF8ZwE/HX7/9eELDf7pQ6/oL/YQeGmpQEI4pRmNOU/MN5RiM4/ZnmrBAo+CBS Bjxxj4fu/DynyIH96hnr3j4f/rwuDOBeRwSrENuEH05x9MECjoh4/kVEYIj/48ML2Pkh4XDa7DDX YNgvIO5FrwmPgz/2Q0tOW8Yg8h4LwtkCA9AhwqBYKwrCjgAgAgoNCmVuZHN0cmVhbQ1lbmRvYmoN MzIgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxMTcwMy9GaWx0ZXIvRmxhdGVEZWNvZGUv Qml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgODggMCBSL01hc2sgMzEgMCBSL1dpZHRoIDY2 L0hlaWdodCAxMjEvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ5NVbbFP3HcDxlz2sD6Bt5OLYPlf7 +O7Yud9JSGIKTcgVJ4WEpCtrVNSOwabxQGnZtKZMW8dKQe1EBYNRxjRKGy5paEgIJCEXHMcO8d2O fRzb8fExwTgkS9iF//7mtExICMGkag/76yPrHFuyf1+fv3327/8/XWCRhf7XUzxh+eNxiDt+EGMh QE8tdp/yH37b9LM2Y0fj1PaGqVcaTNsauQSOtaXOujXxpLFNb2jXT2xrmtraNL0l8TjZ0jTa3jTa UjPWWjvc1jDUtnl428tjrVsMLVvGW5tHXtk8tL2xvyNh5EfN5vYWW23TuL4NdHWDmRmIm4S9vwg9 VwKHS3hKxeSrejj/zR9WT22r+fYqIC7h2UMeJUTnWSiRYB9/SsW1jqpvt+IOuxJ0Q3B+ZmWJ84wh XAIEYgysmD3+W/rdH7veqLPri/yNRfNNFbHGyvl6XbRxPd1UyNQX36lZe7e67E5Nebi+Yraxgm4s DzboojW6WM36+dr1TJ2O3qxj9LpIY2W48cVwQxVTV8XWbrpdsylS9xJdX+FpXGfTl9r1pXRDJbtp w91SXS8iO6/JG3l9B1exPB+EnqsCrntRBgJs6MH0hPf4EfPeNyL7Xg+8VuurLwptyr9dXcxuKJmr KGbWFUWKcyCmJGe2LMtdmWV5Mcu8Mcu8IRMeeHTZdGUO5NZlw1NXZZZvXU6wJCdckM/mFkChvHx/ Qa5vXa63PMtTluFeq6HXZoXW5vvz8vqF4pNJwg9liuG33wLxKExYiUc5z5gAF4iFEtiQ79Qnprd2 xw/sDXU0e2tLLXmyKSViliFmCjGKMatIFCTkXrHUKaXMKtKgwUcz0RtZwjGtYFLDt2iEjnQMsqSj pnShUYlOyQg7JfKQlB+n/KiYxsQzBEkrJG612K7ELArEqsAdasqmFJsp9a280hMi6U95vHjfZRBj /+sK66H36P172J0d7vWlFrXULRN7KdJPifwyCS2TeWTyGbEqwFd7UIUTlzgIkQfHAgif5fNivJR4 akoslTfP47NpaJiPhfmESyCyoiITITKTIgtOeBEykorPJ+NMsjAgQK0kMiEWGKi0WxK+WySAr46s ThmVqXtyC3esWg2ME5znSFiOJARtN/bs8O9+jWmpN8gIK4nOYBiNEF4B5uRj02nCyVTB2Bq+E9fa CbWLkPtRCSMgF1LwvyVhK6nYPR4OJ/cJxQ5MasNVDlJjEmkMlGZUohqjZAaSMmGknY+7eLhDQFgJ sUkquSkljRLcKsV9pDAmUwYplUWu+TQ59SOVavJAJ+e5K+asQ2+2WLZWeXSFHo0Mfs9+hPDxCTf8 3DTChUk8lNwlVU/iiluo3C6UenlUKFnEriGZJHKWL7Yi1CAh6RbLz8nUnymyu1SFV4s3XC+oGM1e a0jPM8q1BplySC4fkCu6KapXoRhSqEclShMpsZGJa+pck8TKVX0vrBoQy07IlSN7fs55NOSdcAx6 WsU/2ATveG/bRm979UxZhoXg+zA0ICT8QsqHSDyozInLbIRkWiSZIORuicYmkLh5EgePiuasG0DF PRmZxzLSL25vNbzfGbnUtTh4HfhDgA6CAAtMXmdhtVlZcB4VX66qBOdPzRx+71zDpt788j6BMppZ SRPaq6u/7yUwRyrPK1Ve4SF/JKgbP9nFgeNNBrxcwtNDvq5wj/S1VvrbN/pK0u04j0ZRv1BEC2Uz iMKJKRy44mEFdUskg6c+sSaoLLi0KrVLJL/WUG/9zbvAZQZL0X9FaAhE4mDuG5aAMb9qgNBekGsn 9u4Etx3gHg3iDOgbmarYcuE7iDlNHcgvcxKYjZ/moxRXU9HTKHVjx5scmMB5VMGCv0NPqLjPJNgG +1vKZ9t0vmK5nUjyogjc5G5E7kBVdlRlxeVWnIL72YVTLh7hECqMEu3ljDzD7l3g5iBYZr8WWoie vPCoYmkuAALzYxuau8UZX+UXhz7+HVgKPJifAQssYBeANwYOHBvEskdQpY0kLEK+h5AN8Yi/CKnr r3ZwHlUMfTXI4SoghmEeq1gKJ5j6+pvLQtt0dJEUVngwxINQTgQmpFsxSGnHKQdOegS4H5FO8qjP UojQvl8AnyO+wizfj0Kuzj9wFcZ3Dhl+lZCoCEWH9G0XVVkDhaXBX+4DI/1du3Yv2KwgHAFsHJi9 yzvf6XqBbyHJaQx3otIx+M586ZXmds7hv34KHT/2Jzj/mY9OnDl2Gs5vmDIx36z/VNxlEsZ6+vXF TGsFXSiGFW4MdaPUwwuhhSEOVOlGxR4U9wqIIKmG/z/wVgv6rywszsGK+D1m7mIvrOjKrjvHz+sm i4+Ls6CVaACEvb2trWcl8s/TkB5FZlepjqvgACYMjNPj0txbJGUhKDtPOpmq7EqVf1n9Mif0z8Uj Z0/Dig87f89VHD135skV80zCwMVr9SWRlgo6j3TgDysQqQNJtyOZDkTrFiq9QjEtxAO4xJJEGCTZ w/oWEArACg6s+ESYN5xS5CPL/RrdeaUKPIhwFZf0tdfSNVMilY3IHJQWHMwo7n7/Aw5YZEBkblxT YCYkFpHcmkRZeNoLyYrz5Q0gGoNghX95Ef4cPu48xJhnaLOrf2KUDgY4j+2oCJPQ+8X1mqLbWyv8 uaSTSPbgROLuhmY4kRwXkuETqgICKigg/JjUuAYfkudcaGgCAR8Uvh+BbB8c7eEXgMK2AC99MCnl kOi7sCJhfvZaXbVdob2NqO/wtDNUyREi03P2i+gSC7FBC5h1XM8tMIokNkpt+Z7Yxsv88gfKzwuq uQroz5cuwQoQWT7Zefho58FfHzo4dGOY81jFXDih51yiYouOzhE5/813mQY3dV1x/GO/ZKaAwbWk tz/ti7XYjjEQiIsxa1iHTCYkzUYDTNu0JKSTZYDONC1Jxgm7gcFsScNujGy84N3GeDe25EXrk2RJ lrVgGy8YmwC3R9w0TEwnb36fpfObc+//nMv+7pkFleKk9JBUkLqQvS6RVOCNnSmZR/RpP1s8nIqh 6L3mrC1ls1Slv6U6s5Z8u5Cc/jEEoNFo4eo1dTJD+zxF8xxljXKhbfc+AFuggSAS+q7J1TA4HHKt ZRbbK4lbXE1bgaIjGLA4uP9I8Q8Fv24BX+TUAaBhU+bAq8tcqVJI2qcWSielc1B6O62DeeGmeS/F OufyIUVGE2P8XmYQvvk2cOgg6mkHi7iIP4Aq6237vj65Ye2xdzaHxu4B41ZHze59/1mxuWrL9sHc U9N1Dd67rvHpGICCIbDo3/PPUpmpj1f0kKyN07ST2hKR9oxmPhoIYSKRSLfgtrnco8FYyOHr9Tgw z4dtOG8/0LBp6cCr2Y4UmY0RP7OgdXbYKBilg+WdDOuSKN0SrYXQlRHqqsyV2AKBwl1f/JDfC6GH EdjlUCSILQAUiSAhhEIR9Hhw5JEPW6C2FrB4fPxsw6JVJQlSJyvvoxi4Gk2MulisPq2GRvsxkadf UX1N2B+6c7s1OBS2uZyYGRYDJ3IAbGE38HZWAhYCJXdS2p8sWLmDZSHVLVK5TcQHacMgn143iytV p7h3ffykqhQsrHkH4nMHLIAH0RgaB1A0EreIQpj/ZPEjgiEbAYvo3/fWcsbbs1gXr4e/s1M0dKSJ UZZIVHnKFOT1YPyjwwBYXPz+Qt7h3E+/2PN/LdDQINB/9Ets0ZfMgoVAswI5sxe9PG1VK3pJ2p3E jSrS4MrXJNAVWlOewVC2YytYRGqKkN9ppubDY+e6ZvFVbUbcIgrpEURRLwp1PfI03msqNm9/65xU 3SJNHZSnBwmVnSAhEh0018erminVTUJ3QmZATgcGW1wuueHutteVVUXHh/MLrmGet3Dm/ANbdGso F0diCzepeyqihXvhZOJrW1/iPDfPCGp5m2heByXx6nROheZWAtlIqzqNSywLVtcnZ4GFmViALS5r TBcVmktSmVmmrFcaetTpLolpiJp/N9EQnaca4pQCI25nXrBRIhcrxRaVtOEorUFdnRio8LurVwCw 6G3tMpcXNzTexvzCIjYA2L7aDRaDm7O7VQS2iO+BpPZ/FnK4FP0kHfjN7BjFjyTrXRzTQxAeWgob 71j6761M8o0E7qJYeUm74HrmhqI1b55Z9crZzevPbFl/6rWV5zYuvZK9uNBgKhXLWhJUbrEpQKba 5kq7EkVeNe810HYyycPxNk7RTCmqWP1hUoXa2zFQYa/XA1z74fLf/rjj4LHDmBmXAkWh3cHefZ83 boxbWJUSsIA48j7XC0jaidlcaA5lTxD3SihBrXNodLdItjBRbMla9fiLr1CBGd1uRE4XCkfRBGxW ITTlRyN2FLYiZzMqvY4O54bf/7BcNb+C0lt1C5sIrjkJVlnWCasgJ7dxqhZSVU0bDxFK1NqKgQo7 HXbA7/BATH19ICcSi2JmiNR9tA3oe3eTZ9Uim45xsoSP5nyUwkPpXHSyk4FnkcLFcv0UN5Kkvseb eucxDrWxlKTzVbLOrW+g2iIUdcSX1fs+NNaPRgNoNPJweuDRk9CTKcguN3rYjx6H0ONwfHkeDgDe f+dUZ60rZ7RWRutnoDsSn1RmIdhWWlkqUp5gdUOlpRhhMARgC+vt9l+xqP9wG9D39kZs4WYJD8l4 JQoI1aft0DppPC/4fom6YzbdrTSaaa5y9XJUno9ifei+C6EQQmEE+dPWgUaCYIEmY8L2z9BEBI1F 4n2ZiqLJgYkHsOkOAvdjETQ4FNixq16aYid0bhHt4xUWgm+jNeUizXFGe7ekBIMtKmDKldeChcXW XVNXi5nZi53vA71vbRBWLrRrGRcjccOBEfEuidpFaB2kJv7Wg+xluRYRX0VwLZlLD5u0nce+vB/r eoDCIeSdQOHpsB0JtrjF+fzJnFzntk/AQtj6sWf7J8N7ctDZq6jFUvLmzn5zFQAWU2Daemfis3+V JUhdItbHSbsJto1RlYtUxynN3RvFGCjv9IXzwHho6NKpc56A9/TZM5iZFn/dCvT8Yb17xQKbhnbT Eo+E9ojlHuhFvB1agVZ5GZmb4xtJrkltvKYznsh+GU2GBsbsMTQS53rJw9oa20d7b6Yuu5SoNPP6 BiajS57ZLltSRaYViYxXmHRzxkZsMdnWA4BFXKTdclOW5hCz8PtWMXeH1laItcdIdbSwCAPlHT15 EgCLC8fPgMW16wWYX9zup1XUfvCe9Y21wvIMm4oCCx8Jz1U5TAQPmSxQOg+r9LK8l5daWYVd92KF 0lS4ci2qang0FhqNBgGwqHz5tbIEY2uivoPS30pJaSM0PaSxgzM1yVKbpOm1VFo1/VKpad3p5a+D wvRIaHpyMH7MHN2WFesdBAc3sVvMdHFaeMnmEqpogRkDFTZ23gFOHTpefP5KzsFv+gN+zPMWNX95 t3vLK+7s+djCT3F+QuUjk7EF9AJCVWAZj1Qh0Br/i9mVGcvBAsAWjv15hfSirjmpE7JMH6FuUDBB nclDqdqT2A5O7dIvtOuWtEtfqtBkHUvNHq+sf2bRUF2fvtgpYXy01CpirZy+WpJ8RKwI5xdgoEK3 3w9EheBUZNg/GMDMTNphyI1o9Z/fsb6+xrUs/WcL3As4UU6J2kHwToJyEOIAy/lekATFpjo2w/Kn Tw/t2uUW7ECgsKRswbrmufqoSB8TSR0K0kmKBJHYLha7eN6t1DTT8gKR9LQsufqDnSgCE8qHvH3I 1zew93NzEikQLGS7VUR388k1hC5XpAhdyceMD0cP5OYCI/7If1kv0+CmriuOf+6HziSQ2Freu29/ 2iXLu43N4hhSHAyhkBZMPBAnYAeYpplJZtJps7RNCQRwMPs+DJjFYGO7trwvxQYM3uRFkiVLsmTJ kmzJYLM0k2navh77Gaamph86vfP7qNHop3PPuecPFhbb4NizM78WYaBx17a+nDWOlUk2JTF7oxgX prAgXTcZ007pmxlNLcfX8kwbwm2krnURV6dZWhi77LkFIFS0et/Z2S7Ttbwiu8XTbQTZQfNtNFuH yHIcVWj0nZu3BA8VCQGf8DgiWjTu3FGs0vQrYqANYQAORJODTEwLbjgi5UM3ykKzCiLlVdV1ZVXT /vDLLYJAdcGWnnfXOlenWZXUMMLcJDvEaC2JmcWkbuLrA11f/rH3xNGOwm8Ce74a/cNXnj17B/cX 3j58pOb8WdP1ayKC79EM3S6hsm3qVLHzswMjv/3Ou/d4+PSlv1XVCj19QiA0x+PIQGvdpc8+Nm3J 6Uh7o/un2ChOOQnSjrP9lLaW0BbhytELxcBzi8amlvPHThefOf+nb/csvIE8DAKm/FxzztvON9Nt SsqJMFs01oPxrYq4soRlgt0Ds13w+QSPWwj6hEhQpD51ZVPqKqBMk1CuS6iMS6pKSjEtSa5OT6pa mlBjjK0yGkvidcUJ2otx6isx2psaY6UivsGQMSH8AAiTQcHvFwpPucl4KL0T0cMY30/pawj9IaT0 XSgWAYXBQSvQVNPQ2thUWlm2cC0eBIHa7Tn9m7JHVqbbOXIEw4KMyssbWzBVpTpZ6LY9tyiNS62I T6tMSDclZfzPFmVcCliUGdLrjUum9h299hO4wxzUYni2FjWktpCYqwUAv/AFi8iDSZF5FqEg0LQ1 x7Ih25uR4mKQH5P6ouVuCWVD6laZ8lZMerkxrSR1RXHKsv+XRalhmWjRpom/J5vNXy+xeDQdgR/Z 0XG/4vrNYCQELLyZByGIBZtyN1vXr/GtmLMII8objY+Qajsf20bqmhVxzca0elVst0LXp4oxKw1m Tt9D6e7LFG2LySFFrJUz9FHKHsR04agb4T0kdBbvILkeju5Q0ne1bK9WNawyjioTHSiuN0pv1y3v VSXdJniLQgUKboJY8EaBgohocau5pej44UvPznyLANCQu2lg/VueFclOFvkwaYSixknGLWdGWIMZ V/Xxxg5K10WpvSzjZlgbQQ3CI8Xw/bSim2B6Ka6boDox1CnDeuVoABFDDG3D6QFEdSLsDpK0y16/ Ex3VvVjaswi3EPp2Kd/KaqtwohaTmFncKY/yEGjBWixo0X7ntsh/WtTlbjJveMuVkWznkAdFu6IW h1nOEQUJQuEkVW7O0BtF+xQxHowcwpEZLAx6X9bqh9u2Tu/8MLjj/UDBB8EP88cL8iM78sMfbA/n 5YXfzx/fURDYuT20e3tk947pnfnf5+96mv/Rg/xfh3Z/7PvkU+9Hu6Z+VTC+PqsPl7hJ9LLufhgO uVwjQHvzrYbquo77d0VefPXgDZoImLZt7nsn252ZZuHxYfS6l5B5EYKsBH3nIng34r0YoLQgtUWX ZKKVpcb4f549MxNFJwPCk8gcoUkhAHNgSvBOCX3jgmNKCP8VEC2E8IM5/IEZJkKC1yUUHoSi2EkS tk1LNIJamAjNfowLl5QBoCASCIS+23fQ63IfP3ks9OzMswgHgOr3tph/sda1Ms2iRA4UDUES/h+4 sRCO3Ijz4tyYnBuT8TaZZlCZXM3qrySkTBw7JoTGhJBPCPhnFltIRi+xAMoKdt3du99x+aow6pu2 DQEzFo3N/zh15qqMHiJp2PwtUSTUwoR0hRg/ef0m8ILF4QOHXmoBc3syaMrLgVq43lhiVZB2UgIR Y5hCdpqyUzBAOM+MBROWcIFFHGxWnbShPTXjx8IjgntECI//d4tzWRvPb9j07xaiyHhTI1iEf/N5 I6sbImbWfquEEGtxECkmb5SLBKcmgatXS8ZGfMCdzrstf2kVmf9ehIDavC2DG9d6MtKH+Nl8QSIH RdhoxkZzMGqgHH45F5Yw4VdQCFfZSXUzYprik5tXZ13JyDyXuerkqqwTq9aczsw+n7Hu4vJ1V9PX VyzfVLr8lxczNy5gEbL47rcVf/Hp1ynxJxjWrE8cwskRirNJ6D5SB7UoIlRTZZUiokVR0RFbn2UG 59CVZ2f+2x0CGvPetf18rW9pmpOhZjuCcFCUleasNG+neOiOUYwLyqkJudyPY8MY1i2RduB4h0LR plTf0uiAdrXhtspwjzd2s0YzY+hSJd5XJXTzsWYuxkzqbpOaOqXxcvKS9m8+B4uZbPjEYT27rz5r BYw4pwwfgX9MSvaRmmqkPkSpp8urRMJPpoGSkhugcPNaKVhU15hE5luMA615uY512eNL0kdJJoBm NkzoCFCAcWqjeMh60N2jGKS/mX7xc1xQqfbQPOQCWHcdMhqAvOaSUm4J4ZHg8NYM06wFQ87XpP5X ZZFXidBrjJXQNBkT96bEDlZfePrULvw4IgT6R3/3SUs0YZci+LYhKWMmtNW49iitfVxRLQIKVoe9 q6vn3IkzYPHl778YeXbm36gJoH1rrjs7eyIlzU8wExjlx2A6zVrQSiutdJBKDz4zqazq2F6k7JWw kGQ9Mq1PqnlIxk/ihkmkiRDqCZIP0uwYy4zylAXJbITcT1GPWNUPtBY+YCX0teq4b+MTLDcu//37 8QdjbkC409msXw75CCKYXU6bCTXU4gire/LnGpELJcVgMWQfBkqvlYi8oDA7o8JA+3vbhtdljaem jJFsBGODMgY2NOgIUIBV3EHoXEjtINQWZWI/MpplugEq4Z5cX7uIro/mm6K55mimSULVy5AJxyoI WTkpaeDZBoqtx6lGGdkSxTTKVHWK5NKUn7lPnoNREJoMzFlYRgffzBuU0aO0wiZne8VacPp/UV5n wU3cdwDHH/vSmXYIWOja+9BKWh22sCE2tFCOkDTpUK4kZCiEgstVcyQwTJtkCjxwTAhNiEnohKTh CvjAgDFgfCEs4UPyIck6LMuyJNtIWmObw0Awzb8/zzoMAwnT7nzGD3rw7Hd29r+/33B5hczlaTtw 6BAk1FZclUEU+MmKGwV/dS2Y2Ts/B8byfiWRVrMpLefLyAjDP59sjRB5bgXn0+g6JvKBX/PdTG4V kzWw/SNUVpwu+e5WSdFgSdHtoqLh4iKp9DS4VXpq9FQ5OnMVna1FZdfQ+euo0oWaulD4pgwq0G0J tXhQUXWbZVGPSohhVABjGjC+krHs07CPmhrAiJSOhLt8kc5PPjsE939g197j587IFc+EIGkQODZv blg0vee1rCCp7oPn+yvNTQwGIW2QFVq1OW5ixnXS0m6Z2i28nKDzWrVTiums0W9OyK4KtksG2wXR VmYec9GYZeeyiq3GExahRODLdcJlo/jDwyR4PJJAj5LoXgLdG6+Qtu1pZGYnlHyvlgnivBMXrlDW fTj/qKUZyBXgemPj+VMlL6pIw6k+1Lj1vaaF02NQQWviaiKmpOO03k1q6yjSIc6qMs09Y7CVZuec NdouK82XVdYS3XR07GwDYbXrs/+XigqT6dmKZrtv06bz5im1mNijZuLwLAjWifOXKdPHlP4HT6vs cOGhY8WnoeKT3fuuX666UHflJyvg8uz4G3C/Mb1/XmaEp7u0VJjSNxPcJR6vmvdb1OBB6XtjBsOx v6+rUKl72SnxyaY4MfX/qig2G4qMXDGFX6OZEMH1KankBE1ykiauAlqY0DppnYPgL+CGz/RW1N0p kytkT1c8+14MS94PPgStr09PzrH1CGwYY+C75ubE6kyxdM5M5OsaNxqP7tlQjk8OwqH6C+XARKF7 Mp9grWFc7CTEACn6KQOI4EJKKXTRBj+pjyj5mIKPqY0RTPTQ+haGj5ozJcEqvUQM/1KJMD2ihIQi I6bWRDRkiDE4cKEMMxSKNpSIylI3k7KPfv6CBJl35z9aX8tLz7bF9TqoaFeyLlasybJ8nTsNBXpk 91Fv55Htl6YZ/CZTQEX2kWK7kmxVkSEMwmUM6FFTAxnUoNp4S2m+Pcl0d5JpOMOcVJmh1EMZ615S tmIMjMoJDR1T4SGFwodPhu0yosFDnL6e4M9qdV9YclAyIXuSMBRPgRdXeHbvhApptq3XIHRp2aBG D9/fWtHyVfY0FB+Q2fdvAwdp4gJtrNTqnIKtghZqxMxaRn+d0jtIHbDTvGNs6WBdGWx7hsGfIYYU VjjlWtSWetxcSRuvZU4t1xkuc3wdL9QR1A0c93AcJIQ1ZIAz2kmhRCMcyZyGpD6ZfJ9ygqyy6ip4 PiT46UHgnv9yf56Ytpq7YIVU6zsIs4MVS/JmoWBCFvvuLGhe96F3+Q7Pih0Ny7dU52+xF2x3rt3q WrO1Zc3m5vzN9esLrm0osG8oaMlf71m93vvn9R2rNgLvqoLW1QWNazfWrVtf//7m+vc32fPf7VyT H/r9IqfaAN/9OMfDnuXkjadU9L/zZsng9m7dkmodDiAndCa65YrnQ0JHPgfN86clZ5hTFlNEzURU +hBmdlHmizm/Q/6+cf0PxoRGUM9/UP+4gQf96KGEpNsoPYykYfQw9Xg09Wg0hYbTaDCNhn6UHhg3 OPb7nVEYe2DLiKH9h+qxbBhgejihSUvaWeNJFXt85lwZJID9hZ9CRfHXJ88c/fYFFZHjXwHn/JzU rMx+izGsoSMqXUQjejGxyjYL+frGDUlj+lKoN41Sg+i+BMYr7knodgrdTT2peDQqge8fj/Mszm9b nO9amo9GJAAVYyHJ5OCBL0smWgIaNsKOrb11jO6Umil65XXZk4qDhYVyxcF/fV56/pzsmYp42Wlw bW62NGdK3GoI4RRURDViUGOoy4SKxLinK6QkJFRvWIZG4fCPoaEYGoiigRi6HUN3EmNGbqL7adD8 1qrWJaufVLT9ZetYyIOUY/m7UDGyt7AGzw1quTDNummumtKd0HDn/7hE1teXAI1ez8ni4uYah+9G i73ZKXv+HZeqKkD17Kxbr+Z0WXk/LEdarktrhHfcbp2BfHFZtPQbUL16Vc2iJdffXlr3pyVQ4diy wrl8QevbC/xLFwSWLPC8udDz5mLf0sWNy5Y73lnZsGzl8xWVy1bWrloDFa433vJOfdWvngpzZoAk Wnn+Ckad1LJV76yQyRXA7fXCswC7P94T7AzJnqm466wDlTMtw3/IDWZyXo7y40wnrg9qdfbMPOTv kd3YtQ0c1RsqWGOzJbuG1RUR6hJKbddxjSzjpgHXxOhctN6L6x2s2c5ZG2irm8hqw2xtWLaLyHbS 2VcJyzkl5876Tbt1ehMhhpnsKGbtxpkOjGjXGSq01ElM51i9VpZOJ2VyhbOy5ucq7qTioy0NoGKG eGfhDF8m2yaQ7SQNyxGMZ7W2XBTsHvdA8u3dVcJn3lCZYJqKYlk+ytRlymnDBQ8mwF+Yq5tJYwsO XxOLi2JdFB2AV0zJ9ij47slCQC14tUKYtXqVXIIwdWXQ/gmaCMG1k2QnQ3swbbvBUK7GTuKce+Nm 2ZOKfx4+PJIcgopAT7i4tET2dIIMeZou5lnvLHrFa+HbBBoqYDny4dxYhT80Bs6WB1J05weVYrZb Y4lpp3RPNPoVQpg0B7QG4MMM7bgIa10bbg6qrT6C9hN4VI33Kcj+DLpPQUdVDJx+MS0fVZApBZOc SAxRQj+rcyomRGmqQ63pMBjLlNgxUnBteW/8HRySIOGLo0dBINBR9O2J8ktlp4vOpH68nq5A30uo 7UblrJm9c+clcnO9LOclmE7WWP9f3ssEqKn8juOI4H0rQhJI3kvyAgEEdGynFFwPUKt1Xaftbrd2 1bGundVV8GhrnXqMR61dHcULdSOoQVhxBVd0UBdRFhBPFAEFD8J9JYKu205rD9Nv3m//zwiJBs30 M9958/Ly8t7vk/e/3hBl6aT3rEVF1qv5Nosn5v+sW5UbHpbL43mNvMnpryuEO9qwci6EUsqHlKht uc2H4jliIjMpeCwsKSbF96mW2z7W4aDcdsL9AL7JN6BBpqqPGH1CptjqJ6vbkSBZoMjkI0YEFn/e tA4WeXkXOljYZj0oIE1VedPea5g8oyw43BQSXuLrjzKKffiKMZP/nWSAxX8LvrFeKvj7x3OKRo4o CtHfDgu/odHdCFDf1egruSApd3nbuyHeEO9zQpXS1bQMV7XxwWd79r/+4zHr/fyqEndbG+spjRYL 0vTIbDh0IPvsqaTkxGvXrlA6Tt/PLMcnv4ucDoyo+GHULZW6ltM0ypUWmbpWqc0PFLJD9dnhoTl6 falaXaHRYlSs4rT4G6v9VHXDVQ3DOUq9L1cj40wyrkrOVaj4cs7VVGqCigLU1yOjd/krN0ZEWE0P JYvW9m9hYaqrP3osPTPzeNKBvc4swKOdBsSoCb0YHHZTCKpUqKqH+bUND7DIuVJ/xTVeidVOiVpT JQTW64JreB3eZxuVAl5s631UTWj5vjzaf4MfXyfj0U6q5bxtea90NVd1IV+ptMZA/ToVd+y385F/ NTZQYIFs2Z5w+fLlXTsTkpP2l5aWUDo+C0ubLQ2Wk5OmJQ71u6gLwjRaIVfipa8lgH/Aqyu1mipd 0ENBf81XUewXcNNHUS7janh9gzrE1lsVAmLyF7CMxMoWS9xKlWDfzF5qckpd55wLDtur4tfI5fum /uT5lSIKFBrN7ZSj6RnIxdwLyIXzuRTHFk3N/0hNPzFxcoqgy1KrCzTCdX/+qp/yqkpdIA+4OExe qOCuh0ZcDRpRhAbAB17mAi8rhXwZhy1ySSkUqoRvOCGPFy6ohXxlYEGAg+TJtZ2zjxeSxo77a1SU tbDAanpAQWGSxWFjWvKBw2W3SvbvS0xldG5RUKA8PXJkW1j4Dk59NDTsmEafrtRkBYZlcEFpMnWW LjyZ0xzmtCmckMoJaSohValN8Vdjx7bPCUZeOKQWDmqEZI1wkAt0GIO/pnPWaHWfTYhpzjhOIQUC Crnn8xFYPDa3wyKP0dnie5FWMQ312XHxxp9/sC163M7IsfujJ+2PjN3zg/G7fjR+34SYnZFRSGL0 O7sio/aPHb836h3D+BjDhNjPYycaJk82TJ1i+OnUpHenHXz/F0nvf3Dwlx8e+vBXxpm/PvLRrNRZ s9Nmzzn2m3lffbLg9KLFXy9bfnLBwjPxS279ZfOz3FzrvUqKw9pQP+Xc2WyKw9NeuDALa0OjLU1m a0O7tbrNWttubXpsS3OT1dxKeY5tm8XaAvcWq6XV+girbgvlFRa201hgYa2pluKwpEt5hci502eR jIwvixmvFpGwWK3ISxaPLFKeSxYUO4vXXpkUXnx0riBZZGWeQE6czOySBSlQXi7ApkD75r99h0DB lQtKUNtw5cwnlsdI5tFjUsyPW1NSjRTXLczWf1Je+sp27SekQImLXxovZmn8MmR53LJP4+MWLln0 6dLFHSK1cGTl2j8t+cOyVevXIM4UKEeNxoTtn2H5UdNcjcdBccWiyfoM6Wxhd22byPIVf1y0ZKnr FitWr0T9y1f+Pu53S+wtOovQPZ62tLY3NN4ozCeLdVvW19bXUFyxIBFnD8KWR+3GtC/ewOKTuIWu WHxraUPIwnTv7t07JVduFtZa6lrMzRQXLZxBCshHs+Z4eHhSunl4dmfx9uhuO9adxUuMtxg60tMT W6/+vbAN0PEUhxapKUe+M1tgUW269/ipxY0WxGwRDxTF8PJ8EQ9Y9fD26tWzm7eXR3dPD6/u+Ij9 Hn164yt8xBYfvXv36jtwAKXzLaCA7N6569DBpLVrVxuNh1avXXWO8TbFW0SwM0fEwzndunXz9PSE XY8ePXr16uXl5UXHfXx8evfurVQqR48erdFoxjIc3g4W2SIPRCoqKi4x3lLBXqSrFl+IYMfbG83L Q6vVXmU4u2mySFlZ2aZNm3JycrIYbrEgka7y8OHDWSIDBgyAIERGM5z9pEEEIrBIY7yxAtFBRKfT jXRCREREWFhYaGjoiBEjgoODVSrVQ5H58+dPnToV9eMZYevHcHbH+yK3b98+f/78mTNnbjLcJRIf H98li6FDh5LFoEGDUD/aG56I1AL/zxYkEi/SVQt0EOkpwMK+Hzm710mRlJSUxMTE7du3lzHe3gL8 TIQK6CnisI/bl4oeTfXbH/+Y4exGhxhFRUV1dXXnGe616N+/v1Rk3759OxSJoQnHMV7Zqw0ePJis 1zFecaPjIngcaFQ3btz4kuEWiwUigiAEBQWhzYSEhGA/MDCQ9keNGoVWRN9SowoRiYyMnDJlysKF C9MZr1YANMfBory8HBZnGW6xIBHUabajubkZN9qxY8eMGTNQ7bhx46KjoydOnDh37tytW7dmZmbW iUgWr71FKyNfJCEhQTriLgviDSyAwWBw5eJSzdXV1Zs3b97NcK8CwDT6tcj06dNdsUCrMzDQZ197 fZrucSZZXGS4VwFgXCULqfM6HK8wQGEoIAuspqTBxxWLayJoVG63WCxCFjRGYUag4QjrPXy0LXS9 vLDFkIWPOIivcI6HuCZE/YsYDq/fLLLDjuLiYiPDLQrbRGBBJdHoiklNGmPxt0tTM+nQDrY0dwNn 9UsKBHw3bNiAkQoWpxlvr0ArIlj4+/tTqVKdsbGxmGFrGThyT+Tw4cNxcXHDhg0jTYVCQUauWFRV VZFFUlJSNcNdFtSKUBV1hGyGZCGdL1nQD2miRDeBeE+GMxFqS5cZbrQoEaG2ARGaiO8wsHhz+Ct4 JYlg+uswm7/ioWSKoP49e/ZgoHOjRb3IwIEDpRrQNaZNmzZmzJj7jI0bN2KSwvC4YsWKmTNn0tPB ghYW9JN+/fp5sDWYw2dBFIhghyxuMVyvtkWEau7w1VIR6sX4Y/v06YN9skDjR+PpYKHX68mCKpfc BYbDAjCTSn8LViCNdnRJQbIA9muGJhH0bmlBiN5K76HOLKhyGqCkdeM5hkMFgFc8KJw6dYosyhld ssCrBOqPiYlJt4NOoN6HyYLeGgg8F+qz0kcai6RhFlvqFEqlMoPh7EGQxZYtW2CBprh3796uWqxl r3UymYwssK6QRApFYJEgAhc8EapQKhvDF3RoBCZ8fX1pZFuzZk0Nw9ndPxfBCbjLgQMH8H6Rk5NT xHDdAgwUoRrIQi6XYzVbyMAF6U/DLebNm4cFOc7H08FAaq8zZMgQtVqN2SST8WoFkMqABV4o0K1M JlMWw3UFLCZ9RNB5aUgBkgXeHTD50j9jfpnc3FxIobVjfYUR5i5DsnDl7rQ8oPfT/3Ff9qoJQ1EA tu3SFyg46tQXECcnH0KcXM3uqqiU4AN0qA/gUMTBDoFCO8RNWsjSpUOXgtChL9GPeziHiz81CdhA v6EkbdHzJeeen/l8jsVms7lX0isIFr8MSHZrFuxB/X7/TZHJbddiqCmaMoA7Bx84mUwYnNhS4zh+ ULJazGYzUoWUIElsTCLhMZKcMYt6vT4ajV4UKT508yiKOJ7fHoSBPj8PFSh4dvCBWND6bx2vSkqL oZZTEJ12uy19gePpN1/RwdEsmN9Imy2L5XJJ/CybpPqWxS8ivoX/HHJbwJOj0+nI7CSdwl7QuYNC dMhitVplstglq4Iv4q+6SZJwHESn2+2iI3l16bA2IUZb8xK/kXVD/p+LKyVrYFkVBG6DIEgcWFQq lfV6TbGiFzOcW/wkm2Sd6fgWZw5yz9ritfI3FoGDh2YWHAcCtpWHwKx8DQaD8XgchiEpTfNlGrlx cEGey1+54DZUTmcBjw6mOOIXi9IOsp/KMeHIxMpRi3ynNSvyFszCsoL84bFL5EARbrVakSIKKb/i 1ApmUa1WGSouHH5F4sk3m83FYvGhoHDSeHJg1VVOKMFL18Ol0WhMp9NPRRSKjnc/osDrZl8ouYm6 Vquxbb0rolB0mMeRpC2Xy+w4vV7vS0Gh6NCyISOrZRcKRUeUE7MoOpB/y48AAwD0uRUNCg0KZW5k c3RyZWFtDWVuZG9iag0zMyAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDEzOS9GaWx0ZXIv Q0NJVFRGYXhEZWNvZGUvSW1hZ2VNYXNrIHRydWUvQml0c1BlckNvbXBvbmVudCAxL1dpZHRoIDI5 L0RlY29kZVBhcm1zPDwvSyAtMS9Db2x1bW5zIDI5Pj4vSGVpZ2h0IDEyOS9UeXBlL1hPYmplY3Q+ PnN0cmVhbQ0KynOYloPyEzRBgfiH/8KaCVoOnXdEd/6elff/9/7ddcPseva1ahhw9BwtP5J+g9fv //99137XFX1BcscPh8f//y4Jj/+uoMw8N/4XC//+I//+R/J8L769cXmhguP/IcdfnA0f/I38PsN8 Pv94YP/fvw1y3HF/MNar1x/IY7hevC/Whwtf/61HABABCg0KZW5kc3RyZWFtDWVuZG9iag0zNCAw IG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDM2NzEvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQ ZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDg4IDAgUi9NYXNrIDMzIDAgUi9XaWR0aCAyOS9IZWln aHQgMTI5L1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIicyXeVRTVxrAb1CsenBDZQRRqyIEQUhIAPXg KcValzNYO6PH0c6AGkWs05mKoKAijIigrbsCKp6hLlXrNrigIowcXEBJQiAbyBJARKrWpVZlKcl8 7315jyghefGv+c7v5CQv9/1yc9+99/tuQsL/UejX7jHFQsuL+XlVmgrAVqcFMzhZLdBYW9+ds2Y5 BWvDj0DXmCjwAz6bFfrtP6OKZVJwIodOHJfKpIDVrprt7f2evoCcuJ0jw/84KXhFxIrtx49sTElh tUDSjh2nLmbrGhs5al9UVgMGIjYQf6CZ8M+QYUl2o/aTIRvJiEiH0RviN/xw9iyrzWECbQqtFiko KDDVtmb8BBiIiAH9na8XyMgU+zGXiMsG+9FfDnED4aOHj9pO5kpc+DnXroUtCL98KaeAic6xCosD TLRdETOvYj0RxMXFsdr1PT/uTtvxp0jAovYd0tPTpVKpIXqXngjhhwghMPTy0lKks7f8UIC7Nj8v H7T6Vd/jR1orVSvKkQ/W7goLAzpmR+DH+A3xiKmTNXe9/bP584CdK6PC3ATfJW7eu2N3c3OzWqPR 6eoQU635ldMlcrMvAqA9SZwbiNd64jiTOPYb5JS8a2fV/SpEo9FwtGHU83yABofAx30DcZq1EuFv RLCduK4hw0+fP6MxCY7O+6u3AvR0ggftZyC+BuJNv8eZLJr80R/AVl5eri1TIladT9ZStJJxtIQP Qr33HP3UyPbBIcyY+74hgm9jYk6dOlXGhFUt3TdA9JiMb1yRAML3tQOD4RfdSO8BvfrL5fLysnLE gvPZ7UKA/uOi//A/qf/1OQtq9VE7ABgQHZkwjQy+dfN2CRMctNAr/9y8XFMtNjBqedQqruZNWLjw K02ZErGgffN5OADaG8RDrlAoy5WIaZv2g+cA3CJ62/Wx2tsXugZATw9gEBmkVaqR95qZaEUTySBY tk2NTYhZ7aucAgAH9mPnkTpVJdK1JbsM1/BcrGtzbwLYPiAwUKeqQCxoM3ijQKtTVyLmtdcKAWwv EAjK5KWIBa3Ubjxoa5RaxKz29S05gO3te/QtkZZ095RZba6dO2gf1NQhFrUCaO9J+itKS61qk3nD Qdvc1IyY1VLtvb6gIKLveSNuFhep1RoWs9r1ZJiUie6cEG3/SASgfSvxG+Xta6qtqjP+xxfh3wCo DbFz0tXoEAvaxxo5gHNsMRl4JfeKUq26WXIPnEhu7BYTrXhTYgIXLf0HhTTUXWLnsQvnzQftrqx/ X8i5AqDWQLygQRUZe1+t0ZarEMvalk37APyPSuJxjrj8ebgnaNNCv9ogCnlKxqLTQHwOzl8MWsSy 00TrxdYhPxN+Vg/3N8SzjdrMsWAQnfcOVtdW19TqEKvahM6H4v1u7dGJnoy/ePwIaBEuTlarn7KU lrByAf06AV7z5kackUQhHJ0Y4DRqgyR06vE0DPiUmniZ1N51K2YT0lhZY5MWzZQzSNL+922tf1tf fvU6CDdnZty5d/f2vbsgZLHVDAHa1JEi4MDc8B/7eaW4ChdOnw3aY+fPycoUCIRtHfaaU8jzAKCf r6mhoOZVE3EPEQR6DHIFoUqlUjDB3Qk84PlgbUA/LG8sGH4mnmrCnzx95pq4dV0rOkvO6J0AndnF xkUXJKGSOwy4wxQsdNOIizPpzWq5mBktNbVa+kwy1b69IaUXC+wb/hLYwWQy7lqDQxAFEf9OfG9f uqpftw8BJ0AvFmoavySC4qLi+modYl1L3SV4zhMsceY31D9A8CvQPo2JB+gOi9fExnLUvrmjAKAz cbzhMYkb39NCGLU8aoiGOblIS6SIZS2bK0PI0MOHD5vd/3+XrAOgTW9izyVBJJhk9hnEKfPQIbN3 NeafBqiKnQy1VQu93bZn94PaOsS0zcvrhQC0mUmcbNXG81ynz5olh8MRzTttbhQBH6b9lSewI73M Ho5afsgGoM2nxJHjI0voTNniBDIi58JZnaYSMf5u3i3AEEjVlmNcRtk6b+GuX3gC/ylBIKyvrkXg 2zavuQDu8F/Om8elcjZqP5pEQXc4hgwpKrknLysrkpcgUlEopgk9EZw4cZL74m3Z+yNA94daSpOF AcsnTYt0GL0/YvVB8QxaS41SZm93lVKFWHViGPOOfQDcriDjXpDxsLc8IW6w5eKZBX7u8NGjZUoV YlUYvzoWQG3HrKUGYx4Xv5uFvR8SL9AiHJ0ATkXQ6j+JoLdcL2YnhzdCuHg1OPhoZgZidWDRKZPJ 2EkOBjg9USl+aiTsuvAGPsLFlqzziS6+N/Kvc3lkFWQ0kJSUVKFUI1UN9cbKgdVGJAOoTU9L4zLB cBidh7mCsFHX0FDXANrzBfmXbxcC2/btzTiShbQHL4J5cuDAAS6LF5+IA7HPuVO4KnBqcuD0lc4+ oN3qOAE40t93q6MP0jaEOlfapNXyvLe5TWyn5hK11nY6eDIFqtCkGBPaqjWQAPq5e7JJ3KTM86TB ktI2bRbPTd8noGXFZirbwpOyw1JBVBmVAheBZ19HG49m6WnctaIpU5ruFLDa1t3H8fr+I1nvaXOv 5nDX/jU8/NGTZwjVW2Y8U1NTHz18hOASLi0t5aaFxr7Z2dkaRTliMuAiiUTCnsIM7rDheHLU6j1n A9lMYHtWGxkZ+aC2Hnm2czsUqEuXLkcsOFkzK2QDtcHBwewJF7TVqgqglsGq2dDDH206dSWCWoFA oFNVIh0rk2zSghOYxXPsqvUP8K8sVyOghT0hNiFBLpMhlrUd0xYBxXaeoNWUKRHUOg1yKpGWIPrx 8Mj8lixZzCReK5nX0C8IaOT5aDRqbYUWQa09sVcxgRMsIiKCY53ArH1x1LrYjVtSopMS41O2oJYQ +wWRy9albDm2ci1esUVrnE7BpK+I9Foz0C16wFi88i/eiD19x23v75FHXD5YCzmxjedHJ18/9grz 3t92rYA5M/rRo+HdBV8m+dqg1QfOB+i7fA32Yjz0YSI2wg9td53RVYtzpjttx9yvAXhkNd9lPs46 Y1b76tJ/u9N2Z+74YjnQQCbc1aqra+sQUy04aS09wZYtA+HT3TskLnwQWhgQw/QlQBEZA992tzD1 bjMA2MEWSSSsFpKvBe3z1FTg1cET6XvTkK5t2vYdA2AH++nMudcydcfgkA4iMN2aLGgRswPFaq/t z6zraZw5lrVoRudLbdWqb1YpFAolHfhtTlxyIc8jO/sCcIwMZee5VS0GON/TQoATtRdDlxQPELPr wlZtPhlx+url69LiNOHnGbPDji5Y8QsZC1o6p8N6cWfXIEftq5wCAPoT7RMENtCC6i1V6GIn+aB6 s+Xw2+2ZtmmZI08r8f6NeNAL2QdLkVYibIpINNEKP0DL4GNwmwNVKLxP6Tmy+L5WVVuD0EvDK/wv C5DuhvR/tJd9bFNVGIffizgTzRSZrPJhGVDrBrOrrIuy0TkIMYN9RYkfCVHHGIsuIJEBw8lHnMHE QTTbhAxiYjCRP/jIENDo0KKMOtqwda27Q0tGZCz8s5BF1JVs0Pq79+29u2t3S5F68qRpzrl9eu45 7znnPRurN1zo7NRqLz2aGzK/JDraWbvIZkOXvEoZPngMCWoMLU8Ta/FDRWtpmjxvtTmnKG/pmV/O oWbWDKMoinyGvWrMKMh73v+7n9HrKmtzn1ss9ojhsTUsC0161kUmN6UVPzJbPiYmNzY3e7zeoYaP 49Hy7B8hAxEh1f+7DX3L7Gp3Bkyl2uzRLky5n5JYG6CsXHrYrZSY05TzBCVjEIba2nBNYO3Q2neB HK6ZbiH9OzKVv776lvVlxNsKSo0dA+o0fSakdXu9/gsd0DKsRa4o3dekSEs/RtOD8oQWxq0dpYXf fHuy2+u76Oth0Apt+Bq4eE1ga6Oy0O5CC9KNcx0OB0a4V+xl+Blo4QTYwUKa3ro6XExs7U5KnT3n SU+3J0LLRe5teEtcRqnYw+PUjtDCGZS0pKj4ct9lUSnah29NXQIQGxU0BYtCzahja8E1IauSpp44 ddyvFk1kjnxxAow+ttRVsGr9ls2NDXv0bpR//egE3FU5SqVMY75xbsv+/ZfEi9Exz9oDtkKQS8l6 2n9aTwPYvhTm9NfuCd6Hm1S2j56ipIe++vq41+djIn4lx5tlOU3Tu6gGa5sAVOVkOP9bT8BUFpK2 RFs1PZ6VXwCh2Csy47V3iN7gliYgbSb0IL/O6LoGeTRyWmjm4dajEP4q9jCnnefi1IY2fiJBWdXr 3h7TIrGRzXkPGMrXVp51n4dQpcZeCGJrbx44ApAOQctwsjSyAGvfOkzWWkp5w5q/LznzzZKV71Wt 31tVs69k1R21bFa1XDPc4QOhZDufYn9Ka9Z6jcz9NG+QTMOUcUOq0dV+tGnbjh0fRNezdqD1eyWe bcqnTfN9Yi2cWq3adEowgeub6q6m2DXn2gREawMnfwZ+SptGpG3qf2s7gFberJ65W21ow24JshWT QW3aLcwC0GpTl3A6HcnEWnUVLJebBgeve0pW9AlPQ4tsM8KJCQ3OL5M+FUI6Uxas2wvQVCtM7+zq cjud0KLzN8cuI9zJ9LBwvFY+jLJfiNau2Q7Q9LmQdrbTdVWwKLcSlUzpylC1S5vqa3orPVOmGUDW 3i6uBGhC9zyLViphk63cd8zScaZ67JWRa1N+sl6YGbHV3C6tAmNJkbafk3Ju1DXz+Qiil4+slSZu G6WoeU5Y+2I1iIqZDClFNJUyek5pDOW3aM9/rebDeiZcv/lTMP7FbX+8U4/MivcEoOfUapmx+q3N QKNdcEWwQKsSw6maI5w7NXHLp8zg+00OwczE49T9L432JzJCy/xnYbR2V9EruLYxidPafmg/0+vx MYnSDggWj8cz0HeFSZS2RV6ACde2VlQcPnSQuUdnhJa5d6dqVrWJcv4f5V8BBgDu44hKCg0KZW5k c3RyZWFtDWVuZG9iag0zNSAwIG9iajw8L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCA4 MCAwIFIvQ29udGVudHMgMzcgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0v UmVzb3VyY2VzIDM2IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMzYgMCBvYmo8PC9YT2JqZWN0PDwv SW01MDYgMzkgMCBSL0ltNTA3IDQxIDAgUi9JbTUwOCA0MyAwIFIvSW01MDkgNDQgMCBSL0ltNDg3 IDYyIDAgUi9JbTQ4OCA2MyAwIFIvSW00ODkgNjQgMCBSL0ltMjYwIDY1IDAgUi9JbTIwNyA2NiAw IFIvSW01MTAgNDYgMCBSL0ltNTExIDQ3IDAgUi9JbTI3OSA1NiAwIFIvSW0yODAgNTcgMCBSL0lt MTAgNTggMCBSL0ltMTEgNTkgMCBSL0ltMTIgNjAgMCBSL0ltNzUgNDggMCBSL0ltNzYgNDkgMCBS Pj4vQ29sb3JTcGFjZTw8L0NzNiA4OCAwIFIvQ3MxMCA2MSAwIFIvQ3MxMSA2OSAwIFIvQ3MxNCA2 NyAwIFIvQ3MxNSA3NiAwIFIvQ3MxNiA3NyAwIFIvQ3MxNyA3NSAwIFIvQ3MxOCA3NCAwIFI+Pi9G b250PDwvVFQyIDg3IDAgUi9UVDQgOTIgMCBSL1RUNyA2OCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0vRXh0R1N0YXRlPDwvR1MxIDkwIDAgUj4+Pj4NZW5kb2Jq DTM3IDAgb2JqPDwvTGVuZ3RoIDc5MzYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ7FdL bxtHEr7zV/SRXITjfk5379FKEGyABA4kIAcnB5ocyUxIjkKOYviH7P7efFX9mBmKe9vTQjZsqord Xa+vviq9u7u0YnsRiv9etqfFu+/vlXi6LLRvbBCtaqRSwlkpvJbi3C0eF+8fFu8eHjTOPzwupDCt WOOfFErKxlqhrMMd6cTDEd8+LdaykVJq8bBd8E+49mWxvNtcOv1P8eHug7g77LvTIA79djN0O9Gf xI/f/7J6+B23VWxiEOv0AVNeNt6KEBrtsgF60Za3+emPy3+v1vBFNnH5YbXWjVnCyC+f90N32F+G d+8Pm+1qbRu1/INk8W132T+dVr89/EAG2waurtMHDEYYRKTaVospnDAP5+PyP6t1sBGP/rLCibAs 5uCA93Dh+bzvz/th31045jN5EJfdny/dZbiIS3fasQcqNIoSLsXDt/X9bTaaTe1PT+Lx3B/F5iT6 5+68GXp6bnkRw/nlQik89bvuG1gOhmysFP5vnhrBFii2NrYoGhLkQmBDow2fbFAF1qbxy2/oQy1F N2zz9cZK6wR9OqPp9npeBK0nGQl44v2KHkLW/0gJMTYsn+GUXZ77odsOnJBLd/6rO3NcKRFto7Q3 KRHVtS25CvSIHocP/WaHYDmdJZHP537bXS5IzU4QhNbKooCaMIQnvBtfSzA8bg777b5/wY1hgIeX m7izLeIIr3A3gqCdA88R8CjrcO1DDwtfxXenx/687VYWYR9XegnEX25jzsKMfw05VY2ZGeIMbFGF plnY9i+HnfjUicPmU3dAjr7sh89it3987M4pu7FpnbPT7OqrJqKW/Lm/JxQRnocVhbV5uohfl/tB HPdPnweysD8+H7ojDsNKBghnKTK+Wj3J+Kue+fRVbHY7gnN/6gDlYd+ffl2lzqhorXDTjKzyWFsf CzO4RU6HW1ZIXcQXzsaw+aMTxz6FbxIoJuEbem957sTj/tStn84bfOyQyNNw7g/orJ6AoVRj8Gd6 71VQot9uX56/AondOoWy64Yu9/txf9oM+7+6HJw2KIPy01acFCP96NKzz/0ZgFk7lAJ1vvQvABPV 4lOPyoIyU1yqUQDO66ahsnJbLv982ZyG/fCVO+Rzf9itX57FsD92SDwi/A7cTiPh7h6P0N/7u58W SvwAsv9dAAfooC8gevGj+PibFDt8tRcLbVog1sC6NEocITvqGxPaRnslDov79CjmDOjU6WhffdLk 0QbIAcebxvj0DMvUCFEJjeKCZHSwjQNB6lY2qq3iFvNKNyhp/T5oEMh4O4v5cRxPCqs1eAzfp9u2 xYeprxcRx5P1+j27Vi/PHN8uHv+x+BN9rVEsF/FHrHHbEtyQjqZVUDl0PcgFYxKg3h4X7/51tMGL b/vFz3wXdlqDc6BpeBYlY2J2X2uFQHE/5vuoyv/i+rgJaKwA8E57UGiuq6a6anhOhT4s0OeNeyUb qbkEkK1tWmRGhsZEVqQnXymKjQPljma8UoHgFgAlfEaF5GafIlnESKUpmaCmOS6VPUDkr2Qjy/Pa tk2wwCpWlewAPXgtFwOHUksTUUCmCWpaWxPqFCcaT2rsJhKEjY7LCVUpoRI9LmmMNL4NLcijcUwi CfKWUEh3VY6HFUYyM7A/SBVFAAfURKE90MXNdfVGTqF1NpIprx1l0Bj8MDVZLBxvWMAC56cygrTt 1KdrJ2ExLYW+LIVgWJ5pJs00bQl8LSJPE02VvVDFOtQ/Lt9j2oTlHVMZHrPlsacFzUIgAauIMWrk SZ1Y+/77+5/S3Gbiq3IhM95vUQb8y0xDMwoBWMUwRA5cyoFDTyYYZIXyBdrzKxyz4gclAHj1qEu1 dHAXNNi6AvbRSi4dzlJ/IJ/GX1lxtZbMwwn8La2/qCU6opROWQONbjx1psEmAKIxBhVH4omYMKGM TmFtubRt61gjiT7horaaH3DKQE79iXv5grNce1v7Aw2lIjmBNTKYRMvgE4oBlAbZcIPBk8KcqvEY 12QiEDGjlZy0LGMPhew5KeR6InJDDeZZ0/IFKnWEDFiCI6+ysF18romxHt2YEkN1gyI0Dgkm0QBq BvuSjZ5lGABbmRQlqJ8kX1sOQ5QUGQy5Q9AH2hRFkkuTRs4z5cYUhUkKXU9QpaHIeURUlD+DCniU kKLWFCUSruEh0klphFSy0sIby+ejCTmNLb/og6YOo99UitOUd0MkwEkJRnNhFL4xgIDF+s/yCOgt UyOFDYVyM3S2te89f52zAouUFTpliiLwEQK8Z5ckgYu2VICOQtDJxZBmMCra+pxpSTG5RvnIiVUM DZvTXHKAPqkypMnPhguqJhhiUypzInfGtKTUMfZK0Y7OJYUJVwo9hQlkmQ7k+I1KNbuhyPMQilyk UdFWIB6ugZxZZhzIjq/TupU2JBw3WDwTgSBhwKVsU2/JmFqH2xkxpBpTDNRbNOUw+jnDhELIyhEK 6buQG4vGN8oLjef71PvGUCdiIJA513IGaicWxjPj6EB+veLeJQQgLski5gKB2GoqG5wixG0ZQc4o NhCAXeIvE5JsqY8zgig8U+NxgTUG3cGN6DkfgYbkPGGJKpIKYG9VzaFNbGCj4SeCSY3mZIJWCCwW m2j+1HhWUx9RQzjmGq0Nx0RdZrjRE//RMpwVh1EhCzegXxTLUpU+YhJ3FSWY9YmEY1bENCYqK0Oh tEtWHJNDy/wH9o6R8+g45lyntLCiGqo0Nn5Xm8COFEku3eHZJYoxH0BKFSuCS4UJIclReVE9jmXd hoKQAUVbY5JJkTezzHgzRXqiBG0TC8syklGZGKqCxHYmZbIZoTI7XQmgiO7qtAwzYyqlaHRHNdey nQekEp9OFUrPcqBmkmSg8YwqCn8l22SyDJUZlutO8rbovC06b4vO26Lztui8LTpvi87bovN/uehQ aRGXlYYzn1Yb5NUGm+F1P90oOAgr4UM6zDxqFa0TJcVJjpVGMWxuKMy0KPa/KGKpowozBZfCKscD qpA1yROs6KlbNOwCBxl9HT32tiK4oogtK7y5UlhT+lKG2wqeMUVMXkxE6wt58YNJcZgq1NwpYMvN FMCWmQVWFamcJoY6haqijCHubciFLAJ32i1FHjKp+7PMO+JU9NyGWdwuJorynmfUzRQ2zFyqiuI0 zz1sdbO5R/I4KZNcXuBmIsX4AitCHeiK2IAU2lwpLG8EVXRxJvpMSFkRC+sWC7HscKOi9F9plmu5 ZR8/p51Bs5WQfq8oWFds9jBVhNoN5kq2mhXRXSnGE87eVhQjLaZ7dWOmKJscKMPeVuTJPV4x7kqh R36m+F09URXjCXMlU/CTGzVf5URVjCf0zK0ie3914ZUijL+n1Q0KFOoSjHya/sT77Sx3VRHGxTDc UuiKHPxmc1NWlQGlnSkUd7myhRho2mhWlHLM64kRkqhKzhW6+hRpdjA3+SuFK8xyQ1JMZJIJh3iy /OzympAfUZU5qqIsDtkRVdk+K8ZVhTeJ6AsPV/lv9qtlRZLriO7rK2opDfTovh9bSWawwQKhAW20 cmEsxJSNLRgzf+8Tz3szO73VqntTHSfzPiIy4sQJa4qdkpeAttgkMVBce+RLO3u2j3QC+mFBo49+ CTRP9tKuAbsmqcRrwBzT1MLeDpTGwGrwCtgegfYgYO3BQH+ffEkS4sz5BNApm0nffTN1CFwbznk4 YRWYXmpY11pAnQfHpGaE56IUstDzc6X4Go4cMAJHF23XwPSuXy7ttYAIaANYU+5NwgG7BST0pW3R 9AWvgBT3Q0PxNxxYb5AfV0A+1P8GePhSPAHF+19o18DqkHFcAxINEN8m9DDl0Hg7I9fl0wAqVBOT Q9r6KqNo4mR9Uy6b6WwtgnQWz18mTzvl0/nYi3lW3g56J7Gxv2QA5k6aZmdz9g+sNnHp7v2iiRbR SNJgCzs7MUahl2jkfDjzHCVMYlQ/cXIOPoXO3BZJyNzfTcGp3Aa3N9d4WdJaKRIjGQPFZaEeEo3s j6eeg4QZTh4Swz75RL7CNMrFidR2Y9umuX44AF5wzrq0wYyaRZOrHtNDgumxw6GvohQ4hINfxo0w f8TkgK6mN6oVJt5gQZgsnQHQLAdAS2IBOhQASPLhpu8RJZVMwFeelwAorQPo8m2TB7bJHjGfgODf otKmyCt/IzYG1tcKhYHkztEcCSB67GjWHStJkpRFNo7VgAVj1EMAX0mUuTen5zrQmxMyiiPhZYc7 ZnGr5C2jCMjxBESPVeQrqcpcXo28e7VdusjgEVxDFKm9YNW5AJt3wHilcGg6MpLsMNnMud/JD2Kc IVn24Oqqe5ZoKPBC7TvgoTjmJWo9SS12LRUBUtDORexA4hDlq26DYTBpJs8Y8BXCQIBmDACEgbZQ QgHQdc++Udx+SKMmkzxwsIusyH5IGDurLECZFiRF1AugOmt1KUitF6YxspO/QMNKHFYuAJh2hiUJ XCUqq1YtdkZyLj2E70I5R9ekT7cx/ExrH7y62eRKTklckl95sh39hqSCAQT3uolTw53KbBd/IY6T 10FWhHkAVhiQ14WBPg3obKtKg10lcFoqqQg3DuMIA7qVBn1gYXStBN1z6fU9VhdZuqZGkU5dou6y R2wT0Jl73msgu+bO4uMV4BMiB24BSdpWNT4g0cK2adUqE4lfC5xFXwszyPRGx/LgAhhOe1PGlp5P gPFU5MS/Aohc3ZRbbCaR82NtmJytHYjHSyVLMgOi5ak55oC0dKJnk5UOdG/6lW2tTth5XAM2OKE6 3CYr7GanK5n5uG2A7ddFm+1AGYcrOTBcvXUdFFxjioBs+Wgv/ViOalqBYY0OQJbJIOUTQB1gM+s8 mF2+lgHTtJid4LpkAWXul3xti9r6lTOZKB2nDJVsmuurGh0YXg35ZBfRS9oVFrDeqOUasEOaSKzh bzhgIqyR9rgETN36klxPgAW8MEOG6m84sN7IJ5ungrXC42VvOLDeSIdrmW2u+oJXwLjQr8fx8WlD wh47B4azUxtXQPLMSe+v7egMGMoBiFzl4OzohzLBFf8cx+85SUsSEYUjkPxOk+Qnc1M/ASaQwoUV mcgCEw7xpP1PVfpYm0RnDgdiPVwkOtsrELxBdJaX3acys63Rd5mJXFASecjoZ2WGIfDSzp7tI52A fljQTKi9Apone2nXgF2ziaq9AMwxTa1mzVwGUgJsUwdsj8DNHMDag4FumgJAEuLM+QTQKZtJ330z p5K3b6jqzoBVYHqpYV1rAXUeHBuqKX/lBI6Lnp8rxYMTuANG4JlmmUtgetcvl/ZaUNMBqNTY9ibh gN2ikvq9sC2avuAVkOJ+aCj+hgPrDfLjCsiH+t8AD1+KJ6B4/wvtGlgdMo5rYFwIPRkMeIIV4tNJ AYVq08aQtr7KKJo4Wd+Uy2Y6WwepEp/9hDztlE/nY89szHMDPQx6J7Gxv8rjTk0pz+bsH1ht4tLd +0UTLWIifLIayk6MUeglGjkfzjxHSSZTG4aeQmf7cATRx9zfTcGJHCNub67xsqS1UiQGyywC3WSh HhKN7I+nnoNEc6rMGUEHySEdahrn4sgq007cOHY7AF6UXdmUJAdmk2N2RjA9djz0VZgCx1AEIG5U cPJBEWJ5ojeqDU94gxVhsk4CIDcGUj8B5lWjGW7LJTsluoKv1I0IUF4H0OXjJo9skz1iPgGaDgAq bRpsngIQGwPrc4XCQPLYzMFAdG8HloyVJUnqIlsia8CCUeohgK80ytzb1XMd6P0LKcWRKD4PVWlG 0WpXUuoYCQWiL4l8JZWZy6uRd6+2SxeptWCtYwE239BwWjgSHVzCWTTZzLnf6drEMEOS6sHVVPek UM/xQu074J6/Gl6T1F7XyhAgBe1UxAYkBlGu6iUYBZNl8rCAn+A1AZogAOA1baEEAqDrnn2jtP2Q Rk0leZxgF1mR/RAtpjlPgDIrSImoFkB1lupCCdoymLbITv4CDSdx2MALgGlmGBfDVaKuakljZyTn zkP4LpRydA36dBvDzrR2kYR0pkcuSFySX3myHf2GpHoBBPe6iVPDncpsF38hjpPXQalvHoAVBqRx YUBLA0BnW1UZ7CqBy9GALCtCPwDdKoE+sDC4qmfdc+nzPVZvnfet87513rfO+9Z53zrvW+f9wzvv tx+RqOBXRORFfsI99S6sCGqJod4/PvHOP24viEcI8f7xcfvqw4effvj642/AX6hQ0es+fn/j55Wf //LVXz/8/MvX9MqfPt6++e73dn/8fgeZ9FAn/eKv47fPhgSj74gkHCHTs14mXQOVkBChn777Aaf8 Bdf6DRhi+N/7LVW0TU4IitXzZL8wuQ5ix//8/fbtOzxO1luz9IEamWTGeN8ApDKZ0oeE+jPqvb9n ehjMvmTm5OYX4e9tOShrsDl1uVAU0cmU58I1ga3mTx7Sb4Rqhp5UirPfF75JPzQX+DK1/UwDNuc+ 3f72zrlAc/7JRaD5SH2T6GZKCUS5sUoo4gZ6DnM2N7+YomJm4OfF96LFRash87OsSoQYgqy0+vOD hdCQQujbSchh4qAvpoPo6s2TmqmxOcMcnBOHsWugiHduZM8zICkxiYkkJeBYGy0jo2rMnX47/4ra o1zkiDaVewcAXI8rExMn363nnirl9UQW3qk1IXn/z27kmkgOKUq2d37iBRv/HXdgh1GZSAE6Kasf Lc4W9xO3dnM+oQrxL6AF0VmnIxfAR/aJnShUY4BR4WRLvXqH2xLmedMsUI6lDBlCXU3zrZFWoRtQ YyGzNO4BQ80uPJY0abrwK+QKb9clmyMT9BfOwGVLO6YNQjGCFo1AunG6siSBfgC6H8nCiO9D7fcz CwBqv5qErp2l4um4rSIerHyz1FeJct84tuqq1nervm7B6vGi+Ci/jwz0vBmnCGORe6W40vvMwks1 aZ/izkhMGk3NKrKsKAuRuzS+pGnOk5ahSeHLElgu66gCyh5ejj+9oM0NH1Dl0AK6DGC0p35A0p0k RT7zB858PyGNQfRkOlWPMwJ9sCqdbfM+Ct0OJk3yfSzyfoh0Fi4Y84LNObcH5bNLCp6VWhCl9DSg 0ka0waDwVTweEIuoHSh1tXBaT+SqPR0IuS9kw7bFq2JXqAs8lHWd51zbVS3ygc+0p3pBXXm87oPa +r/RM7FhjHPOen8hpVDx76Tujl7A/8d7xb8xhoLVj+ftmz8/wV3f/+v2I5Zj2KGPXqcE7QW1hRGm UWaA81KdFHJ7+rz9/O7+T6yCgmh9zpZY+7ZILAVGvNP7dBUkYcUwQSoAn0DOhNN85o98afrWOSSU ywuqr/MiujRcJQ9GxaUxVORQZtYNUp92a17PizrWY6vu6zHcEo4LQN1MyJpkF0gjuNeDJHKFHiAp +IK0JqVYtW9Qq8V/9ti9xoWgXGbs7DXNPBR18hrNu5FkqhWVOUOtdial+eY1HqfO3+clYcjo/qlA iNgZyd4oGggbmprsUPA53GuaFiHp2GvUDmSYCDl4zSHA+v9xXmW9cRxH+J2/Yh7JAFzNTJ/zKEhx IgU2FHIBIbCNQCGWMQMur2Uc+N/nq6o+qoe7yxEFw9yunrq+rhNPjbnKAqvMn1DbOwFO3D5dRMsx dQKsA+DPp5/uzs7RVk6fN093m+ezX9efadJ75IkG1YsmMko2Jxsnxk4A+BVw5VlQTfDEYZgFDYZZ DLH0gXiu1SLFDwxZjh/ynOb2EiCBagd+T0k3IqwECCTVAHkDv+/zY9VJ1soEm1c8wEsdDjXGhDwz 0JQyuTx7Uwo0BE81L3PczkXcShpnOQhMGvItb31oNxlOGqVj9xcsRJ8BJ43IHi9IMzLE0RZDE5DL FtE+CAO8yxbRdlcJXvpUYrmdy+AxgNMEK9sYi6lcmiJ1mINGBYgho9D6HPPlySoQL5kgW+ylyEdD tG8Rj07go5YvnfWF+Imn2SLf+qXyw6oVP/EUMZfP68EbzOcM0PIhaLIv5TvqG2+Qj6YSG/tpmXgp ntZIUHvuj57G8Z4i8/WIy3zW5BmchqZEqOj3POyhxNC0keSH+Lr8yhgS/F7gEUJVELNeilqGcKGC wpjxl7ExEer7Gpr9Sa8NpCB4RqjvF6Rl5ZXOSZ09VkJ9Y15RM3jf8QqVMUrecxcqhKrA0eaZwfPU 2ZahlBkNVWjIR5uf8lGkE+++6hgcT5CehmcZKLjA5zITHE+HuNa3j3xPGhN7oKo18NZbbA1xOFYE k+TtUVVkORWo8bChuDUNt59Zig96bSkq/kJLW9Hb47rYVBQ757Wtjam4DfYIprhP4r8X01by9qgq MTRwFhVDoaSxNPIuWNjb60fm99pUjI5LTW1Eb4/rYludXR0JVNy6o++PD8a3vX8rentcF5uKah4O vz9uJ3vMVHzg4ptMbUVvj+vKPUVmjYAhyImxLyrmwRwurK7NDCHUsi/kiELEKoY4q5ivpB4YbQlo V8616g/cnYsLKOOLfai8rg3EmQ+JXHwwfqEPldGW8LEvfchBVZ5hT+d6LUKLD/nZZz4kcn2HcaEP lTH5gHm09zMnBjAY+kd/PdH3dJg6f0escGm8ng/kdd4ejCYkGbMBPFF5WBz7FNziD/XtZc1HJnDY lOfrMpJP84G7LgVKhprAPZVBG7GnmUEad6Tned0oz8W0zjiJkCTVIbDPEWvM3iFzriAPmUhX4fMy BY4yj8ClSc9QY5p1UYWm5IAll153wMruIYzbSrBqvslLLca5c/lDS600Z+xQwc2W2pGW2tMfvr77 6f36bP0fWmXrqhdSuMUQLf+d8D1Fnel5bDLI7ojXwfLqPU0qam29/PAT+wApDubH7sduPxsykasl LH+3XqPDdWuSgeQ5pwTqDHD04MH6OlTjz8l6FDpYT79st/7fyemXD1+6D7c3m7vn73El5DA3bBOU BUs1hZ05en2Z4K6mjhycAeP03NZ+yrYiOrKxl5un3zdPu7m1ZX40Q+ShGS85ciZlAgrEyGlBhNEy wQ2ZAIyJ4E0mhHH2RbQzGURIWioL2uIUtFAiDFpt84Wy9PbktxN6OGZCmJpsPBH6yARicvoLZkok BMboNFMYU+3IYtMXt9zUh2B4ReotJ/M2E8zkuYQOwcsRWwUcGJBEsDYfr04GlFokYr33BEDhlmOW Tp8LAc3eGbpnbjsAc1ek5yM+F+3lPhmbuVvbr06+/gl14BGhM6Iaugn/OJdN4J+9mCMHMtggp0fX XW1P3n3aOkwMH+9RCP7OqIw8gCpUmFBRcej3xWmELUJdgzJQAamgWCraFRQ+alCEUEBh7uo0S9eg kPJ6LaYWTBrLD2BCZaRgAuV0MHswGXqFiZ9IbYWEzxURrLZWQYIurhFBdQ86jLBDKkDopPHgc/GI Wau/JFmjwYrLtViZeRubDwfIyEBAK2jh1eDwkvUKCSZUKDjPKhRWUqJigcbWppSKLD5pLPhcsGDW ioWVbKpgpMqRwUj1KaPRGL4kNqAc9BhfjQ23atKFz8Un6HU6NlCRGjyc5FbNpibVYhvQmVAgcXKs 6dAgIrorIk7D2Zi9oH5wf8LvfXi0IdJmisoT6iY6OHgw1GBYXWAp2lWi8ElD4ZtEsbp6JtEaClat oNBALAgLzhJSeShL2pAYVqbNEiZUIKwck6O+RQHjgm9SSEeEbVNEzgUFZlUp0EDASuul2FhQaExe Eg/2cH608SArgQKjl5aRwTC0UFYwvDSMggfqWJMi46z0ugaPcVYCdX6IaA0Jq673YmnhbgxfUDJI uTuQIk18OM+lrEIihOKVm5oqCTNnkAQa4nUijarHylGDIoTiF3NXr80MFdFe7pOxmbu1fUmgQDsO 0b4WKI7n+hYV06CiIBlplNSQuKbx+CilpFbhoYEkEVQxbHrHKIOqgqTBw7R4mO8aOkj1oqHDDbPE EULFw65U5Rhc1EWFfFS1tCnDTcY0pVCVUBGnMWB19X5okqU1dkFYAPL+ULL0oYWhjzMY+qhgMHrG KKlUYehXYxM4el6Ro4ZjbMeGfjW+TIWKidFDSDZVYaIsXxIaUE6/96aKz5jI0mvL0mtW/cjg9tyl pshZg3nfm9k+OfA6mTbJix8OrpDDZHM3oPVvezLS0/lCuGWCnM2Uz2nbGZz+wKxiORshBF7big5N GBTHMBneBYrI/EHWObOSNsERuyWTAvOQ4TF/k+1KXwyJcM0dl591SkyJAPBXLJcKOx6SzrYQjBCc yQQkT/sF8qERwekyZWeEw8K+6JRMIgSjtOovGjvJX+pwbIgtpotlpi96nP6C/JX4GUv8UPBQ5Bhr uY/YgHidR47n0MEvCJP4+dJdbB7/u9k9v7vY7B7u73ab7pfT9V8/XXz855f3F+t//HI2jy84hn/4 G0O0/HdCyHLAIfIRHc64FSIeDoKOAaO33dOGXmjfNUcHri/JIeUGLQr44Swq0lTdOH3/8NBdbp5+ 3zztyLDzEQ8AYSuk3vqjeNmb7CUEwMufOU26HXHtum/4r3u4vz1DFTi94f9f/dGd/br+DAXniKfJ FUlDgSsJ2txd3z9dbbabu2fIIO7x9O6ZmZEZEwzH/5ifuQyDPKy6v202D93u+dszkO5uSMj22/PN /V1HPrxQ20/FAcsS8OG/Nr99u73u7q+7H/8sjlNzOzfU8Yq51V7RPK6697vdzb/vyOGbqz/SU/5f gAEAZfEsDgoNCmVuZHN0cmVhbQ1lbmRvYmoNMzggMCBvYmo8PC9MZW5ndGggMzI5L0ZpbHRlci9G bGF0ZURlY29kZT4+c3RyZWFtDQpIiezC11rTAACA0b4lLkRUpkyVoTIcDAWKgIONooICbqbiAJwg 75DdpGmapk1Jd3/zFt54vhMIBIBD+OMvclBkv8hvf4FfBX4W+OHP8z3Ptzx7OXZz7OT4muVLls8Z PmXYzvDRn+ZDmq00myk2UqynWPNY9Xjv8c7j7RFvjnid5FWSl0lWXJZdllxeuDxPsJhgIcGzOE/j PHF47PDIYc5hNsZMjGmbKZtJmwmb8SgPozyIcj/KPYsxi1GLEYu7EYYjBCMMmQyaDJjcMbkdpj9M X5hegx6DWwY3Da7rdOt06XTqdIS4FuJqiCsh2jXaNFo1WjQuq1xSuajSrNKk0qjQoFCvUKdwQaFW pkamWqZKplKmQuK8xDmJsxLlEmckykROi5SKnBI5KXLCL3Bc4JhAicANg6DJXIx5h4U4gf/+qb8C DABP1T2pCg0KZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3Ro IDM4Ny9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgNzQg MCBSL1dpZHRoIDQ1Ni9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIks0VVTQlEYheEZ RAEBQaS7W0pSSkC6u7tTQATbv+53gOfmzJ599s27UCjExQkafXlydYTBYLBYHA53DfB4AoFAJN4A EolEJt8Cyh2gUml0OoPBZLLYbA6Hy+Xx+AKBUCQWS6RSmUwuVyhVarVGo73X6fUGg9FoejBbLFab 3e54dLrcHo/3yef3B56DoXAkEo3F44lkKp3OZLK5fKFQLJXLlWqtXm80mq12p9Pt9vqD4XA0Go8n 0+lsNp8vFsvV6gWsN5vt9hXs3sB+f3gHH+ATAV/kfDjskdvdDv7bbjeb9RperlbL5WIxn82m08lk PBoNh4N+r9vtdNqtZrNRr9eqlUq5VCwU8rlsNvOVTiUTiXgsGomEQ8HvgN/ve/J6PW6X0+lw2G1W i8X8YzIZfw16ve5Pq9Go1SqlQiGXyaRSiUQsEgkFfD6Px+Vw2GwWi8lg0Ok0GhXpSKFAUTIZ4pKg MZEIuQl4pDwMgMXCFJjjJueB0OjzZKizfwEGAGPyZFwKDQplbmRzdHJlYW0NZW5kb2JqDTQwIDAg b2JqPDwvTGVuZ3RoIDM5OS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSInswsVWAlEAANBx 4XFhd3d3dzcWior+FQIG2N01MzCUKIhKGCAoiIHd3a34/Ao33nMhCNLr9dU74Hf19ncVqPsi6j6J W5/EzY9KcOO9cv2t4vdrhfa1HFx7IWieCeongvqxbPWxbOWhFFTd41V3eOUdfvm2RHFTLL8uXroq WrwsBBcuCubPC2RnOOkpTnKSLz7OEx/lzR3lzh7mzhzkiPazp/eyhLtZgp3Mqe2MSV06fyt9YjON t5HKXU/haFPYa8ksTRKmTmKqExmrCehKAqKKh5Vx4LgidkweMyqPHlmKGl6MGlqIHJyPGJCF90vD +qWhfZLQXnFIz1xIz2xw90xQlyiwUxTQMe3fLvRtE/i0Tnm3THo18z2b+R5g04R7I8+dznOjc13p XBcayHFuYDuB9WzHepZjHcuhDrMHazG7WswWpDKtqQwrkMKwpDDMKag5GTUjoyZkxBisQYxqEAMS DJFgQxJsSkYtKKgNlelM47jSuH7twvABWRy8HI+okjEN9O+P/AgwAGub3nsKDQplbmRzdHJlYW0N ZW5kb2JqDTQxIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggNDAwL0ZpbHRlci9GbGF0ZURl Y29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA3NSAwIFIvV2lkdGggNDU2L0hlaWdo dCAxL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiSzRZVMCURQG4BlQCUnJpbubBSQklpBauhEkpARB wW7/uXcXnm93zrlzZt6XQMAQiUeYY+Bkj0QiYygUKpV6iqPR6AwGk8lisdnsM4DD4fJ4fL5AIIQg kUgslkgkUqlMJpcrlEqVSq3WaLU6nV5vMBhNJrPZYrHabHa7w+F0utxuGPZ4vD7fuT8QCIZCF+FI JBqNIUg8nkgkU6nLdCaTzebyeRQtFIqlUrlcqVSr1Vqt3mg2W+12p9O96vX714PhcDQa30yms/l8 sVjcLler1d16s9ncP2x3uMen572X/Xu3fQXj9RtYXC7fwZ/5bDqZjMej0XAw+Oj3PrudTrvdajUb 9VoNnKxWvsqlUrFYQNF8PpfLZjPp9HcqmUzE4wgSi0WjkZ/wbygYDPj9fz6v1wPDbrfL5XQ67Hab zWq1mM0mk9FoMOh1Oq1Wo1GrVEqlQiGXy6RSEJdELBJBkFAo4PN5PC6XwwGpgnDZLCaTwaDTaTQ8 d1AAhYKXQSYdysF6wgsjEgkH/wIMAOKTX0MKDQplbmRzdHJlYW0NZW5kb2JqDTQyIDAgb2JqPDwv TGVuZ3RoIDQzMC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIliYGD4//8/w/obLOtvcK2/ wb3+Bs/6G3zrbvCvuyGw7obQuusi666Lrrsutu66+LrrEuuuSwLR2utSa69Lr70us/aa7Nprcmuv ya+5prDmmuKaa0prriqvuaqy+qrq6qtqq6+qr76qsfqq5qorWquuaK+6orPqiu7Ky3orL+uvvGyw 4rLhistGKy4ZLb9kvPySyfJLpssvmi27aL7sosWyi5ZLL1gtvWC95LzNkvO2i8/ZLT5nv/icw6Jz jgvPOi0867zgjMuCM64LzrjNP+0+77THvFOec095zTnpPeekz5yTvrNP+M064T/reMDM44EzjgXN OBY8/WjItCOhU4+ETT0SPvVw+JTDEZMPRU46FDXpYPTEAzETDsT2H4jr3x/fty+hd19Cz97Enr1J 3XuSu4Bod0rn7tSOXWntQLQzvW1nRuuOzJbtWc1AtC27CYi25jRuzWnYmtuwJbd+S17d5vxaINpU UANEGwuqNxYCUdWGosoNxRXri8uBaF0JEJWtKy1dGzn5UNjUw4YrLimuuSq99prwuuuC666zrb/B MAroCAACDACtbNxACg0KZW5kc3RyZWFtDWVuZG9iag00MyAwIG9iajw8L1N1YnR5cGUvSW1hZ2Uv TGVuZ3RoIDQxMS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3Bh Y2UgNzYgMCBSL1dpZHRoIDQ1Ni9IZWlnaHQgMS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIlckWVX AmEQhc9BwXVdVJBQQEJSkA4JqSWWlu7ulhQRO/63r/HJ5+OcO/fOmYvDbW3j8XjCDgTtwjC8hyDE /YNDEol8RKHSaDQ6/fiEwWSyWKdsDofL453xBQKhUCgSS86lUtmFXKFQqtQajVar0+kNl0ajyWQ2 W66sNpvd7nA6UdTl9ni8GObz+f2BYDAUCocj19FYLB5PJJKpVDqdyWRzuXy+UCgWS+VypVKt1ur1 RqPZbLVa7Xan0+32+v3BYDgcjcbj8Q1gMp3OZvP5YrFYLm8Bq2/uvlmv7wGbzebhl8d//I2BYAN0 6/XP0s/6Cvgsl8ByMZ/NptPJBOSAuPFoNBwM+v1er9vptNvgpFaz0ajXa7VqpVIul0rFYiGfz+Wy 2Uw6nUolk4mneCwWfY5EwqFQMBgI+H0+DPN6PW4XijqdDofdZrNaLRaz2WQ0Xhr0ep1Wq9GoVUqF Qi6XyaQvErFYBL4r4PPPeFwuh33KYjGZjNdjOh1UQaW8kUmkw4N9IoIg7zD8AUEQAVSH/8QBvgQY AJLohbsKDQplbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGgg MjQ3L0ZpbHRlci9DQ0lUVEZheERlY29kZS9JbWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29tcG9uZW50 IDEvV2lkdGggNjUvRGVjb2RlUGFybXM8PC9LIC0xL0NvbHVtbnMgNjU+Pi9IZWlnaHQgMTIxL1R5 cGUvWE9iamVjdD4+c3RyZWFtDQrNfL5HBUL/i4fWvX835DMeFI/kG44+8cXkNYeuQ0D48gpD/3f9 fv/17uv+/6/r3kNg4f2Q4/xH/wj9hkcf8Ksg3IDvINPfEIImP/+P/hYh5DPpyCk+6C805CD6hce5 vh2lI95Y5Djwh+M4Cfjrrf/r0MPwu+//C/4QeHak4yPkcUozenEZhsw+T417M81YIFHwQKQMeOPv H+GYf/koHHbqRmFvHw/r14XBnAvI4JViG3BA5h9MEcceQ7uOiIOgdhaFwwi/+PDC9iuUPC4Nrthr sGwXkHci14THwZ/5qBoOvJcDA+SMF4WyBAegQ4VAsFasFHABABAKDQplbmRzdHJlYW0NZW5kb2Jq DTQ1IDAgb2JqPDwvTGVuZ3RoIDMzMi9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSInswlVX wlAAAOD54PEBu7tbMbC7sTFQ+ZkbA5EQBDsQbHc3ttGI2IWEzLt/4YPf+RAE4ThOxnIyJrbGxFZp +GcFtsHRFSoq5UekZGSZH14C4SUitAjfhhZuvyU3cFByHZznf81dwZ+zl58z8MXHNHz+PnUGv01a 38TWV7HldcLyMnH6Mm5+HjM/j548jRw/DR89DsGHD4MHgYGDQP/+fd+ev3fX37N7170D+7q2fZ2w ydth8rYbPW1Gj2jLIzK4Ww3uFr2rWe9q0ruEm06hztmoczRqHQ1aR73WXqex12rYGjVbpWYrN5gK FVOuostUdCm8TpfASlux0laktBXCCqpAQeUrqDwYp3JxMgcns3EyS05myMl0PkjHQBoGUjCQjIFE DAj4hAAlElAiDiUQlIhHiSQMpGIgU05Wq9muHR/y72/7FWAAcVzZpgoNCmVuZHN0cmVhbQ1lbmRv YmoNNDYgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAzODIvRmlsdGVyL0ZsYXRlRGVjb2Rl L0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDc3IDAgUi9XaWR0aCA0NTYvSGVpZ2h0IDEv VHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJTNFXU8JAFAXgGVBASEACofcQeghdCL33mlCDQQFLwK7/ f1ziA35vOzt3d+45ItGZ+OLsEpCcSKWyK4FcroAgGFYqlSrVtUCNIBqNVqtFUZ1OrzcYjSaT2Wyx WG02u93hcLpcGOZ247jH6/X5/P5AIBAMhkIEESbJSCQajcZi8XgikUylbtKZDEVlc7l8vlAolkrl SrVaq9UbjWaz1Wp3Ot1ur9fv9weD4Wg8ntA0w0xn88ViuVqtWHZ9y3Gbu5P77W63f3gEnp55/nA4 Ho8vr29/3sHhcOB5/uN0/7nf77bbr9PQhuO49ZplwVvLxXw2ZRiankzGo+FgAL7s9767nU673Wo2 G416vVarVirlUrFYyOdzuWyWojLp9E8qmUzE47EYWCkSIclwmCBCwSBYN+D3+bxejwfH3Rjmcjmd DrvdZrNaLRazyWQ0Ggx6nQ5FQYAaDYKo1UKmKhUIGIYhSKGQy4XcZTKpUIQENPKvILFY9N+vAAMA D8pWKwoNCmVuZHN0cmVhbQ1lbmRvYmoNNDcgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAx MTc3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgODgg MCBSL01hc2sgNDQgMCBSL1dpZHRoIDY1L0hlaWdodCAxMjEvVHlwZS9YT2JqZWN0Pj5zdHJlYW0N CkiJ5NVtUBT3AcfxN33RvojTKNzt7e3z7e49PwAigigKnJMU5NGDKAhpbJlxklqNU18kqbZTiZk2 tSE6sWNGm4RYOzWmiKIGRRAU0OO4A+/5cY+7g3sQEISCTev2j5vRqW1T7UymL7rzGYa5ubn7fbm9 P/v3/z9e/FwS+F+vePIKz8wA4JcH00mA50bmOlrDh39q3dNgaaoe2V418nKVdVv18CsmYb/AsXXp QUuDydxoGtpWM7K15vaWpZ/DdTUDjTUD3zcN1JUN1pf3NWy+vu2lwfot5rotN+tr+1/e3Le9uqtp Sf8Pam2Ndc7ymqHiipumBr6tAxAmJe/PAc+0X/AfE3qaSsH4kW1ljrqKbygBEPY/fcUTCbzr5tcn 9DSVfIMJU8nFqA8A4+OL84KnrOCTsSXTcZAwduJX3IEfeV+tcJnWhKvXTNYUTVcXT1YaU9UbOdM6 riZvqmzd3dL1U2WFE5VFY9VFXHVhtMqYKjNOl22cLN8YrzBym42h6sK4yZioLp6oKolXlCTLN90p 25So+B5XWeSv3uA0FbhMBVxVcXLTC3cLjBPZGzpRxVl9jpDATycXZ1LPlAAuISHU+qH1zd0zB9+I NdUGywvsOYoRNWpToDYGtdC4QyaLkMooqfTIGZuGMuuJgUzsRhYyaJAO62G7HnHrcMCuw6w6xKJF LWpsREH6KSZMMGGM5nA6QFKcivVpaZcat6tQh4pwaxmnmh5lWRujHc0peB2CZq5cEhIET7kfXHNd FwBH877gnle/fPP10XUrR3SMhRQPS9NsKDRKIHaaDtAqTsSOpbN2lBwmUQsFWak0O7Hci3w3BD8f lSyPwWkxWBSRpIckIp9E7EERJ4G7CMqHURGETEmoKYhIQOgYInWSkIVMN8tENlbikEkcqNSSBt/C FZ9kZB3Iy+UtQ4Kn3w8uR8vbALd/b3Jnk29jgV0r9ynoIEOFGVlYwXIKhV+hDNCaMKyNwFoPwbpJ mZ/AIyichKFpSDQjFk2LoUkITkqwCRifgMmoVOaVyhyYzEbJ7AQZRKmEmJhMJ+LpSESKOSh0iJaa GckoC/tk0gAKgyf0LxNdXJW347ll/0UCv5AAbuzdEd79w3hdpVlBOigsgOMcSgaluAfGb0uQYbF0 cAXsIXQewuAllWGMjUupWRHx5zR8UYzfgwgwO4TQblzuJDRuSu+kM60yvZnRDzIKM8VYccoFE16I cEtJB0lb5ewtOWVhCYecCFFIBEWmFeooo/k0XfyBRjN8sFnwrAl9r9XZt5b4jXl+vQL8hcMoGYJJ H3hTCenFWT+j9Mq1w4QKcCHyIMTE0mXJFVQ8jRqDaQfK9JJsB608o9B+plrZpslr1+VfzX/hWm6R WZdjURrMCnWfUtmtVHUwTKdK1afSDrBqK8U6qaVPM4AinhVpSaWmm1Z8pFT37/2J4NHCqYlp4OsS vkwCnQ0vBhtLA+sz7CQcwjFw94YRJoSyfkzhIRROkr0tY620aohUOqWsD2LdEJPK3tCN0RczMo9n 6M5trze/25w43zbXe40Px/hglOeifCTpySu1qXPPYvSlkmL+bGvg8NtnqjZ1ri68IlWnMos50nB1 2fNjBl2QxN1i6DKE/o5kbvx4lwBsG44Ehf0C92Qc+HcJV+qLw40vhtbqXATEYVgYkXGIIoCqPLjK TageJjC3UHxUpgjR+qg69/xz4jaZsqeq0vHLA7zXxs+n/pbgAD4xw49/xbK6BOgmDe1Kw9AbO/k7 bv4ex8/E+Sv9I0Vb2r+F2iTayOr13cvTPCTuhCVXxdhJjLmx4zUB2C94IuGfK/j7caCrrnCswRjK V7rItCCGghvbhyrdmMaFaRyE0kEw4B4G32IvwbgRlYU1XMrIMe/exd/q5ReSX4nNpj5uFxI8p9qA +fHI4Au1HXTGF6vzY0d/zc9HHkwG+Nkkn5zlg9P8weO9+Mp+TD2WneukSDsC90HkHxDm2itNgkcJ fV/0CsD4JP8XwT8kzE8AXbXrY9uM3Bo5SPDjqB9lPCjYr3PggNoFlhPggGL9UmIYYj4TkbG3fsaH 3DOL8YX7KcDb/FshwbKvxfyLlkcJfaaGc5qs7ryC6M/f4vu72nbtnnU6+IkEn5zhbcGFnfvavgPb ELmdom7jxCB4ZVh+ubZRcPiPnwInjn8Cxp/64KNTx0++c/QIGG8esQoeJ9yNA12m/Hh9EZdHgwQf jvkw5uFHYAAVbkztw2g/RvhgNCglwVGz9J+06/Ls3DhImLkXHz/XCRLaVlacgXM6qPwTdJZ13wFg MRXprK8/zSo/l6AXVZltBUYhQcDHJ3jL7ZvyVS6pcpRi7CQzLFa3iZUXSl8SxP46d+T0SZDwfvNv HiUcO3PqXyRMxoGeyrWJuiIuh3ITDxNQuRvVudBMN2rwIeogQnMI4RXBEYI1syuvm+r4WAQkCEDC h0jOddGaEFUY1hvPqjXR9w/yDxIg4bypvEenH5FpnGRmrzz3UEZ+x7vvCfi5OJ8Yv6nP9eAaG8na ZUo7ZGhPV50trOJT0wBICC/Mga/A0eaWuC3A2bw2j7traICLRgSPExLgpeLXytbc2VoUXkV5yHQ/ QfoxlQfL8KDZXjQjhGgiUiYqJcFJG8blfcrs9qoaPhICJu4nAOd7xy7CuXxeQwTS9aaJWmTfthzd AxKAnopSl8pwB9VOQYYAs/YImek//afUfBJIRu38mPvaqlynXGeRsU5G64QyLyxXf55bKiQAvz9/ HiTwiYWPmw8faz7U2tr6TsuhvhvXBY8TxieApYQtRi5b5iHFjxOwLC+mB+cSOGDBMRvBGJ+EtmZt +Dvf5RrcVJnG8Y/7xZkFe6FJzv3knpNLb5SCgkgpF7k7OCi6rju6C+vMjqzoqDvA7KwuuywoNwvI XQQKpZS0tCm9t5TeS9OkbXKSnCRN0qRJaGvpRYrgu084o5Z1x8zv+3l+ed73ef7vUWP2TwoPH8RR 7Nu2vK2VczSW3xI9eUs+X4TXffXhzPdhoPSlNY0KU1eKqu1Zdb16kWPXXkBUQEMhJAxcV2p71UbY EbyS65clFK5lr0SxMRFQOPTF0fKLJb+uAL/ml5cCQ68sd2fJYag+UVC7CD1PGJ0kJAq1h2R9BO1J Jl3JbCuVfkFhEg58btFmenZ+kFC450eBIKppcuzdd3LjumNvbW4qPBlHE0D9rr3frNxcu3VbpOD0 TGPz9wgGeBR1tsc+3AMKg7v/YVFk2JQZA6wKolcXzlVIuLO6BWgoLGIXPIDD7RkPxcO83xsY7Pfy DrdL5GmFZcDQK/lOE+ukZaAgEEoXwfGk3gmBgVbyNA1zr1tO98qVIdIUYXMa5zCiwg+1FlCwnTqY GM4PowkSA3ZQVEBRGD4w8aLocWTskX+2QgOTfmcO7WaNAqOBLzoJspVSV8g0p9SZyOcVCYyPAmVN 9YUXLp86UtB2t+PjT3f/UgGNRQFRYcBAg4JA0gL+pAuiAqXmabafJZvweTatypPGjKuy4YLUJ5HV XMYpk6ly+9ugEK0vQwFX04pXIfaDwtAHnwV2QoyHixZCMR8KWx95W75tLTdve/O8XNsuz4ooc0KY xonhDkIGA4QnmTZCcwvTn1CYkIsXERWuVtwEGitroyP3YhOjxSXXRf6vQh9H8gyWUCCUHvypLjgZ 0qlkHGq2PSXZKpF51DqeM0CKq1RqyjjTFUPmBcP8kpxloCC8+l7sz38XFUbefT/w1jt3162/tWRx efb8C0lYC210ExneJGVwHuPHcDub3K9Oc5JSF0W3EaoqgjvOGFB/nwiUd9FcAnjsTnNhkVPgzVXl X39zQWTWUI0AooJdR7gZXOyCB9c/aQQHd8FFJfJYgKIHUlMErbJTktJNyHx6vUulu52Et5CanvQl vQtfajLkmYkFZmyhRfXiDd3ia1xuoUp3Ra4wK9RNalOfNsctyxghFtxLNcVSNCOMWqCkXdQzvAFz EBI3LYcu1JCmL0kdsvaIQHlfXysCQKG/wxqJDoNCc8sdkZ8V4kMAKEQ259s1mKiQCHg496OCEv6i QZwcnisJ/mbumMHoZqg+DPOScsix93NetFGGm0lMoVR9hVt4Y+nGsjVvXF275ezqtec2bzi9ZdX5 TcuK8heXmjIsUkV7ksYjzQjiWY5kuTVV4tOyPhPZjT3jxNO8DAtdqKWNR3AN6uoSgfL6fV7g+sWr 772z/T8H9h06dkTkqYARg7MaatmUULCpZaAAw8f3iy7AUJ2ap5ycyziTpP0yQtDqeZ3+Nk6Xpkp7 81Y//vTfqMSM7rQglxtBkIFdMwnBKYzGnGjYhlxtyHIDHSkY/uNfqzQLqgmjTb+oFWPa0tK8KtrP 4i6pxMco23FNHZl+GFOjjg4RKK+HdwIB3gtDqfDq5X0H90fjMZHZFgN/eBnwrn7OoadcNOYnGT+h 8hJ6N2lwUXoXrXLTzCDBxFIVY2na/hSK16ZbcLJYo+h5+3XUUIZifCKCTvnR/UE0HkTjUTQRfjgz 9OiHMJr0oIeD6HEYPR5OROLRIOD75/66vPVVFGejuACl8aViHqnML1fA29MiUZ+g9SMWi4gQCQOi gu1O168p/H4TICp4aMyLUz6ZyiPjnjSCc5HiXmAjJDco09rV6WaSqXlpBaoqRvEBNOVGKIzQMIKB 2dmNxkIJBchd03Fh2yfofjTRjgcxND00+V14fCoCTMWjKDIS3L6zSZ7pxPRx1uSRkH5W1UnqqiS6 4xR3r6JCRFSohj1W1QAKFRUVvQ57fWODyGyF/jc3AsKqRU6OclMyD5wTCeuWad0Yx+O6xKsNNgXN 9OFMu4RtX7rsSAbXc+xfU3Hrd2g4jHyTaHhm2IkER0LhUvH0/oLBHbtcf/oIFLzbPhrdvR+du4ba eyve2DForgVA4QFodtyd/OSzyiR5X5rKLaH9jLyT0lRJNMcJ3b2b5SJQ25nLl4CJ8MiV0+dbW+94 g74z586KzFbo+90GwLNyoUNHekiZV0Z6pUovdCHRCE4gNT5K4YFHokbfgjPX9ekn8l9A0+Gh+844 Gktwo+JhQ73j/T23spZfSVWbWaOFzWymcq3KpbV4dpkkvYjKMeduEhWmO/sAUEhYdPXeUmTb4cZJ afjEXZKrlnLHcG2stEwEavvy5EkAFC4fPxsI+EHh+o0SkVl7IVGF7fV1wopch4YABT/EOUwJy8uL GwRC76XVPpr1sXJBqbbRqmp1Rumqdai2+dH98HgsBIBCzQtbKpPSO1KN3YTxdmYmpNNOTNeHp7cq slrlOQ1Edh35vCVj/ZkVr0H9M2PhmelI4nTx9t6VG/rZdB5j4AJaGQ4epAWYJlZiFoHyWnruAqcP Hy+/VAQK+w8dGAwGRP5Hwb51rSd/gagQIJgApvHjBlEBugDzU6Ap67wUr1wVmJ9fk7sCFABRgf/i VCn5nPXZrEnFUj+mbVZRTVoypM/wEppuRus2LnLql3TJn6/W5R3Lyp+oafpZobmuKWexldS4ZJSf lNsYY53McFSqGi4uEYHyPIEAEBNCD6KjQCASFHlqqEIeGI3ZXlvjXp7zk4LYBThILpmWx1gXRvCY 1EVKgzQTkmY00rm97358eOdOj+AEgqUVlQvXtyUbYxJjXCLnVbhVnurCJYJE6mZZ2ONtpLJEIj+j MNT9ZQeKwhryI98A8g8M7fmbOQ33yDkBo2GS21lDPaYvkKjCRcUiE6OxgwUFwFggCvUPBUN9A/bQ j79ZXfgv62UeFOV5x/H/OtM/OvVoYI933/t9995luUHwIOhUIjrWJLVJZ9rGRIw6TTOTzKTTJumR eoOoUROvOBFFFATKLZeAiMKyu8DeN7vsjYLoOE41efuDF5VE7V995vPXDuw8n/09z+/5feOA6a11 jtVZVhk2d5AoN4RBVK3HU/oITSelbGHYFpbqYrBeVNK9hGlVLi9LXfFUAeDquv1vbO8TqbsWiXpY spUQ9WL4AMm2onitBK1TagZ/83a4/BAXCnAzCV6hffvWCrlyRJriEpJw+6DjjVEpXRLtESEbuVwT mds/T21DY2tNw3Qw/nIFeIDCw79d71qbZ5ERThTx4LSNUpkzCytwdeyLA0Of/9Nw/MuBst3B8n2h XX/z7doztr/s+uEjzWdONV26yMMF7s6id3P1vVNfVwR2H3N9csD7l4PxE+f+09DCDZu4UGSemcRo d+u5Tz5sevutgbxX9T9DEgIphCkXho8QqhZMdUgiGz9bATxVaO/oOnP0RMXJM998c/pf+3a9YMC4 HQZGNhd7V+fbGdyLIGFK7md1XYi8XpHN6a3Qw7lAgPN5OJuDs9i5Ecsso5bvzXbO6uTc3u883kc+ 90Of84HPdt9vmfGPTvvHpsatd4P2xxN2btzBeV2c0805YX4OPQ6GY9zDRy43/O/U3i8v/hTT/5xy Ywyv0IyryrB5halElGdszNLRfLW7vaOzu6O6viZxe5LnmQIczlho9M313sJcJ4P6EJEnSRwg1RZ5 hiH3l1xNCzdg4katnPv/pjDj9/MK0/8o7SYzxhV5TpxxoeQIoWnGNOWoLHC2IrBAYXBQ31zX2N/d 19raWn74oOnJeqYQCQPmTcX+ghw3hQYRYSBZ7BEQVlTRLZL1pOTX6vKqcldV5KyoTM2uTsutz8hv yipoy13dkbsGqFFm1Koz6tOyGrJympZlN+ZnNSzPaM7LatalNuh0FRmqb9MUF1JUV5S6emn6VW1B DZNTrV1Ro81v0y3rVabfFFHjMhhjiOerANydTsAOBwZu1V260tPZFU5EgBfkhXAYsGxcF1g1rxBH CX+yxIsr7GxqL67ulKZ16vLa5Kk9tFIvVRsh6jKaYUJ9SyTtXYrbpKkWRmsiZMMoNSRB9ahkGEdG cdyDsw6cGZCRN1S0QSV3ynXjskwHmmZI0tjVKw3yrOsYa5bKYfNuMSQU7PkqwP55niq0tbceOnb4 3JO1QCEEjG58zbcq20WjAUSYIIgoTnnElJfWGiVyE6sbINRDhMJBsn6asmLEGEaOUewIKdVjlIFg 9BgxiKCDIsQgRkdRzEaRbkZqlZCjKNGPCvpEr/QnJ+mXCoeXSMyYpk/IdtOqBgnWggiMtMQlTorg Yh+GPl+Flyn09V/n+ZGCcdNr7oJsO9wFNNmdtDROM44kSARSFy73MFpDEhmQpnjFhA/BjaCg1QSK 1t75/e+mt78f3roltO3d8Psl0W0lia0l8Xffi7/zTuwPW+JbSqJbt0V2vpfYuXV6e8mDkh33Sz64 XfKnyM4PAx997P9gx9Qft0U3FpkgKcDtw9HnqwDciUfcbi/Q19lztbH12rVrA7du8PzgaZu7zqY3 ij2FeWZW4kRf8WMiP4pC8IFG4cZYCKF+BJDZkmkzqmgiZdW69O9PneRiE9xkiLuXmCcyyYWgd01x /inOe5czRTnHFMArcPHb8wRDs8QinN/NlZVCOSB32HEcJkmoQhOm3I8w8aoaAPbPEwpFDu4t9bs9 paWlx746GnmyninEQ4DxzfXu1XlmGepAkyEPws8CpxSSjgdl/BJmQsxMiFhfkswqUjbSmgsZObGj R7nIBBcJcKHg7LgKMeclCkDNth039ux3nK/kxgPTVhswq9De+d3XJytFpIFR2XAS5nmoQhOqLkPY yUtXgB8pHD5Q/lKFyTAAVXC/uswixe24ACKDk0DtJGEnKGh3vlkFKi5gppLkoSXMIKntyy14VHaE 83i5ePR/K5wuev3Mps0LFXiLaEc7KMT//Gk7rb4pxG3Y7DDPV6EUlU5eruUJT00ClZVVE94AT//g ja5r3TwLnrYIMPb6el9Bvo2dyws46iAwK0lZSQa6ChQiKGbiAurOYjy+CLXjik6U6kjP7lxbdKGg 8HThmq/WFB1fs+5EYfGZgg3frtxQmb+xKm9j3crN1St//QKFiDlwq7fis4+/yEk/TtFGTaaHVtkk uJdgTLgaqnAIk0/V1PPwCocOHbGazPO4bBeerAVjXgSw/mp9YHmeiyLmbgHmIAgLyVhI1k6wcCPG ESYsJmYIOiYWOxFELxAOSCQDUmmvTNGjVAN9Cu11ufYmq9PTOiOlNdC6IXnmLXmGkUkx4urruLJV pjufvaxv96egMJvy7jksp/a2Fa2Chmb4ySKXSOIlKROubEQV5YRiuraBJ35vGqiqugybv3KxGp42 UGhsbuJZoBAFHBuKo8vyx3EqhM4OjXALYP/QOa0EC6kNrvM4QjmSBS6xKMgwYZnCR7Iw5MMQ6xCR AMQut5DwCDCfQAJvilsocZK0GUGDi0WJxVjkF5QFU3boMvfkpI41nr1/38498nKhkfG/ftSVjMWo FLsQhS80YqpGiepLUjVT18gD+7c47ENDw6ePn+QVPv/7Z94na8FBigGe4uJYTl4Qo2IIEUSgF80p kDILKXPgMp9kti85ZCkWRapBQEMg9YlUAaHyDp4+KdFOosoEpojhbJikJ2hqnCW8UsKMiqyY+C4t f0iq4A8smKZFkbYvPcN8+fzjB9HbEx6A6x/s1Ky0sbljIhwilRFTQBWO0Op7/27mOVtVAQo2uxOo vljl8jh54MMfNNXEHcC5oSiamzOB0wmEDosomLfhFsD+rbjagandqMKBKeBImGWZRpF6lMi4Kda0 LCHbktmOZKYzmfov5XUe2+R9BnD8z/0zaRNHEl/v/b72a/v1kTgXJAwoZ7u2YkAopWIUBBkFxLVS IW3aNJjEobJusNBSoAxKaCEhnAFyx4kNIXac2I7txHF84eAj5OAugf72mDejDFR1sz6KFClSnq9f ve/7/OqyyGtS7LJCfg6XVhFZoIZjakimVko0ZNC1Uv6qsqCicF7g8yPP7/2B9PwdTuQOu+auvCHN dUmpMKXsEK8Cqxu5VA0epJI2Z+e+Awdg/gunKvft2L3/8Bdfnz8N84teSbixqDj0Vo6PlMXgC/mF /DZ854TCx/IORb6dmNZCGroMBe2ktp+f4lDkVtA5Y8dOih7W1o80NA42NcbNjbHWxnhL/WhD/XBT zYD9Sshxeait+m7ble8fx8HTB1H0JI7uR9H9GBpNQUJq2642Zlb3BENUorylYKw4f40y7sGVTzra ASQE/H2gpa3tJxKSw+DmwuIwJNDyiIwIS+gIrbaTiiaKtAgz63RzTmtMZ/Pyy3WGKq3pqtRYqSpG J6rQicqnV2r+l4RR6+VXE9rN7k2bLuhzGzGhU8qHZAwcFa248iql+5RSf+90iI6fOQ0g4W8797Rc reuN9l9suvZ6AnzaFxSB6LxsPwsrBNUnpV0YbWYx+xvT0aFvUZ0dmc2opRY5LJHt2zo0068Ls+9v +uv/lZBsrorXfhOrPHzzz1tblpfUFBdWZkmbMbLfmBvidSE5AY8LuArpBYMVkNctOlh2ABJ27tkz OjAIooMJ0Svzw8f+TjEYmJsdUNJ9CspPqdsJ7ooSr5s7Hd1wouT9tCE/GvaE//DRLTY3kqWLEAU3 CKNZnVfLm65oTBcF0zl92mVtjpnLaVQZK4zakwb+koq/qhWqdboKveaMlqug8Gaa6SG4mISKT5DH J8sjUnl/liQiVcD2ZSGUF3HNfrUR9feKIOFExbeiFwl/eu2DRlKOt4tBfLYpxMPRg4GXl50T6rOF s7NnIHffuLEIeugK7lrvg+fnzySDk/j+LGWUNfpxoZcQvKTgoTQggPMJSVofrfGQ6nCmMizTBjDB Sas7GGVQn53ijamJxMjPJQhTI4qPZmb0TPxlGPZtOWnB+XOYpkwwoWhQlLgdF70+9svzixxvFSVn mSJqFSR0SVgbKzTkGL6aWoi8IdFDdAs9dfce+sSj03mlZIwUuiSkQ0r2YFAtYkBIRg1mUEOTmCGZ 9o5Ef2+ybiRDH5fqIdNJaZsmShwYAwtwVE6HpXhPZqYbzwprWTjtBuR4K6GsUqg+N+SjeFT0Yv7h SAL8ZEJqlumWhu9TsD65Gt6wjYLhSF4higyOexYG5r3bLtLaGoXKypuqab5ByG5k1C2U2kKqgJlW WtKHCLZTrrRlsF0Zmp5MoyfL2CEztOL6GlrbnF1wSaW5yimblHwTQV3HcSfH9bAczO+Xk2aSr5Tz h7ILUSomEocU5xfBHV1TVwteqbDPnwIGioSkUQ/3cq9M3U3oLaxQWTQT+aIi+MvwN1XAtXy7c8X2 G8u31JduMW/8xLp2q23N1o41m9tLN7eu29i8fqN5/cYbazd0lK5zrl7XvWoDcK3a6Fi9sW3thqaP 1rV+vLn1403m0pW9a0p7fr3IKtP0YgK83COc0qrUnpLS/yqaKYL/eOdOqtFiAa8nvFLRPr8QxKfp EwZdQMYEpOoeTG+j9Jfz30CemCgdO/AoLfQMDYwbfDSAHqdQahQlR1BqBD1OPB1LPBlLfPcUrmwS Df1HcnDc81/vjsFKA6eGMNp7oBXL80lzYEUJcbyZ1ZZL2a9nzBHB/GBv2T8goeKr8tNHjx85fvTH Eqzz80FiZvaAQeuX0wGpKiAXXJhQZ5qJ3DFROmE4lXYriRJD6GEKjCfcT6HRBLqXeDnhydgPnItL OxeX2paUogcpAAnpinh8aN8XlZMM3XiBV84GWLaJUZ2SMWfmvS16kfBZWdmLhM++/OfZC+dFLyc0 z8kDqdm5EaOmB6cgISgXfHJNUzYkREX/lZCKw/z165ehMXhPhdFwGA0G0WAYjYbR3WjavRh6cBs9 TLYvXeUoWf0iofN3W9MVjxKW5Ssh4cHusgZ8qp+Y6lNwfpqtp1Qn5dyF35SIYrEoaHM5yysq2hss 7usdXn+vud0qeuWmrp+VA+68md9nVHrgpKPg+hRauKnNxmnIHRl3Py149ljDopKW95c0/bYEEixb VliXL3C8v8CzZIG3ZIHzvYXO9xa7lyx2Llnatmy55YMPX0+oWfZh46o1kGB7Z6mr4E2PrOA2OQV2 SC9JXMOocgVb98EKkZgA7C4XXAWQHE7t/HSXr7dH9HJCzQwDGHl3qi+bc3GUB2d6cbVPoTJnFyFP aNzzhOs7tlWz2nZDXgOrOkPIKimZWcW1sYydBtxNRmWj1S5cDZu/hdWbOaOdyOnETJ1Yno3Is9J5 tYThvISz5/yqy1h8kxD8TF4QM/oms/04040R1QqqHFNZVq8VJZNxkZhgrWnYf7DsxxKqpwng7sJp 7my2kye7SBpOOl6MaTRNRb7+cY9S6HHSvXvHdakuShcFsRw3pevT5XfivBPj4SesyrAHduDw1jB4 ZVobxdooOiBhQ5nK/izeK+NdCt7PGl0SLkro+jJozwR5gOC6SLKLpnoZ2okpLsmwcpyzb9gsepHw 94MHH8SHIaHFYvaG/BVnK0U/PFS/S4HLRca7i+a5DMpOnoYEOOm4cS6d4OlBbeZnLc3phGR/8C9/ tMsNYUVu/yStJ5P3k3qvQgPcmKYLF2Ab78T1PpnRJxfcBO0h8FgmOZBBxzLpoJSBZ11YoQxmkolM Jj6JGKb4AVZlzZzQxWBBmuqWyc9JsBMkb9vyexHMdjs1+PnRo+DLY4fP/Jv3MgGKIrvDOB4Y71uB mWGme2Z6YACBWLol67UqLhFZtZLsVmKilnGNK6vgkcRYWSUeZcxiKSuIuAgqCCsoiIqoiwcCggcq IsohMBwzyKG42Vy1SdVOvum/r3dkGByFyldfdTVNz/T3m37v//4vKQUICYmxaSfTyZ0Q8kIWGoMW PfTyq/P2K3VR4BXcHcdXTA/6b0L8S4QbBea04//8eFmRt/6Br1+JRlfirn6s0VdynpIf85YtkrhR 0lVzQq3SIaPBaxmves573Xl3+nZX19rYGDLyk5uftQEh5+I5GAgtLc1kCeFfz41wxozAsqmB9/UT qgRPo+Bl4jyqRytuunEXp0xOfW/qwckTj/n53pv+bpGaK5bLH2JbquCr3TUmjTf6ZLJBoa1TWHqM KpW2UqWt4NSPeK6TUStsjU1us0ZfOkaWwmnipgSUx8SYTU1k5De1t9c1NpnamjMzT/11946Ewwdt EaBTQR/A2R7+Fe9Mva9SN3Aak0zZ7qZuUGrzPYQcH32On0+uXo9pW6ZWo/rVcto6OW9wVTWOVxnH c+QmF67ejatz42plXLWcq1Dx5ZyjrtR4FrmroxXKnf7+5roaCaG142+EcCI9TUK4ffsm2Rrh2f54 OEnjc83L957gWSlXGca6Ph/v3i7jyhTy27wSnUypWvNQxdUKHvW8DttSk1LA/rRpnKoZo92Fx5g3 uvKNbnyDjDfIeABamnalQ37ECbd03lkq7TYVl/7blfB/TEYyEODIfVHFxcXR+6PqDU8SEw6VlZWS X2mTjFiw2s+8HxI7xvWazrNExVfIlNiBtrjzT3h1pVZTq/OsEfRFo8bfdpHfGycvd+Pqeb1R7W2Z nnIBrlMI6A/Rr6JxrVQJFZxgPUd+mCxKna3vqr0uefkeVPFxwT/5/mYRGflNbR3kE2kZ8LUrV9ua MaBMVy9fIb+C0PwU/ndK2um5QcmC7qxaXaAR7ij4W67KWyp1gcz92lhZoZwr8fa/4+NfhJfOexRz HsVKId+NwxG+oRQKVcJ1TsjjhatqHHX5So8C987Ok2ltfV7lGccLCTPfMxcWmOuekJFKQjiWlJp4 +NjD+6U3rucdiotNYbJFgL89fnyvr98XnPqEj2+6Rp+m1Jz18M3gPFPd1Gd1fkcUfCKnSeaEFE5I VQkpSm2yQo0TyzknJPHCUbVwRCMkWqw7wnnYOl6hsXU0J2zV6j6fPYdM+UnIf+VyPgyEF20dcTEH gJDH1KnHsCC0ijY25YSFJ/3so73T3tsfMPPQtPcPBQQemDwresqsyInvxM2esz9gauy0GdEBUw/N nHVw6oz4WXPiZwd+GTg3PigoPnhe/PzghA9CDi8IOfLhzxM+/OjoL36ZtPhXx3+9JGXJ0tSly9J/ syLrk9XZa9Z+vWHjmdWhF8LX3f/L7sI/b/vuyhVzVSU5wkYIT25qrL90MYdse9tLEIZgNposbm4z GzvMhufmhg5z84uXbmslf4/j83ZzC8BbzO2t5mdopNvJ3SBYbmMmBHO9QbJtpBt5hfCl7ItwY4Mh I+PkXSZ7FJLazWa4E4IFk+V/iUC2QnjtN1P+V67YyS8hnM08TT59JtNBBMpPtndP2z/+DiP/azNb i4aEI3d+0/4CzjyRLrntRSucnJJEdgShDY2d6Ff+Zfnibyg/OSx8fbjo9eEb4I1hluOn4WGh69Z8 un6ttaVRDW+O+NO6P2z4bPtW2F5+8omkpKh9n2dfyDqafqT+qQEvgtw9QrP5O9gWweqLLRQbN/1x zbr1jiNs2rIZ4Tdu/n3Y79ZZI9hS0DO+bWntMJpKCvMlhG2R2xua6sndIxCFvVdATkr96i0QPgkL dQQBQn5COHok4fGj0pv3Cs9fP7cl4rNLTK9FsCfKv1SUk5NTP6b+fX8w5NTHqe8A5z7O/Z369XXq 34/OBwwehOv4E0f86Txo4JARw8m2D0pJPg7H7I8GQkTElqSko8dTk3sFgbRMlFO36tOnD1gGDBgw cODA/v3708Vx48YNGjRIqVROmjRJo9HMZOryKUDIEfWEqaKi4gZTDxFamJ7aUWtrq9FoLCsru3Pn DlbSzMzMxMTEGTNmID9Ahg4dumrVKq1We4vJ3oNOi3rIlJubm8bUQwSJ4o0QvhIFBGdnZxwdQUgU hfC7du3at28fEM4y9SR8u6i3+GBNTc0SUcOHD7fMFycnDKcvmLr8iFEUKAghlann+Uk6ne7H9uXv 7+/j4zNhwgQvLy+VSlUjauXKlcHBwQiPOYKjq6tr9wjVoh48eHD58uWsrKwLFy7cY+o5Qnh4+Bsh jBkzhhBGjhyJ8H379sW7wEk80/8NgSjCRb0pAkqT9PsDgWpUEVOXzzojKjk5OTY29vz58xhL0tTu CQL0U1GU4UeiuqyrUk6awhTe+vrHTPYedJQJjCgRjY2Nl5l6C2HYsGFSwiFDhtA5KieFxHKA61gg rLlGjRpFyNuYunnQKVF4ERhL2dnZJSUlJ5l6iLBalCAInp6eGCre3t449/DwoHNUy4kTJ2L84L80 lrxFBQQEzJs3LzQ0VKrt3eeHaCEGQnl5+bFjx4BwkamHCESB2G1WwnKAR6C2zJ8/f9GiRUg7bdq0 uXPnLl++fM+ePVgaGkVJCK99RCtTvqirV69GRUVJF3uOQHoLBMhe/bGHYDAYdu/ejQYjhqm38q9d uxZD+mtRCxYscAQBg02qomtEdf8IWtAxnYGAooTw15h6JT8hoHMjBGm2UsHvJJQjzH1CoCtrmLr8 fmpUCOE2E4ZTbyHsFSUhUJ1E2ZcKkXWxsrTi4hVqKmhpIwR732/dbuEV7NixA5M6JSXl7t272Uy9 gqBQKOgHl0IGBgZi9amqqmpgqhKFYhIWFjZ27FhilMvlhBMhNk4kWwTMAnSStbW1EkJCQoKBqSf5 6YlqtVoaJFh5MU6kdVZqQuh+QngsauHChdKn0HKDqEuECDaXgYDJVVdXh6VZ6lF7mF9CoOUMGTD4 cZ7DFGG/laUP0gADMl4c1riDTLb3A4E6wGImg5V6glAqikY1KGipfcSErqzLT2FQJYjCGme9Xh9g 6vJTmaIQHjdER0ejsvUKQpOoESNGSDEwo0NCQqZPn17NhJG/c+dOVMJNmzYtXryY5gXaVCBIo8hJ 7K9OM3X5rAJROJEQ7jM5EpX2ZRS407/Wi6Kyg5908ODBOCcEzFmsC50Q9Ho9IVBsCVxg6jIAlkvp N0GDce7cOZOVHMwvIUDWI7xZFCqSVDxRYWg7aQ+BYlNFlRrCS0xd5oewWUN+hJcQypkcREBmhJ8z Zw5amk51huoe9gW0CyDhjVB1pZ8af1LxlBYFHGkiKJXKDCZ7r4AQIiMjER4jEGUNs95xhAhWWNzc 3CSERUyFooAQJQogeBcUTwpJIEREcnFxoTq2devWeiZ7T/9SFG7AUw4fPkzlOjc3t/stkq1GiJIC ILxMJkOPWsiEr6KfC1++YsUKNNh0P16N9QZn9Oj/cV/+LAlFYRg3aGgOAked6gOIk5MfQpxcdXdV UiLEb+AsBiESNARBCY5B4BiBUyAF9SX6cR7Oy/FqdSxM6jfI7XrzPs8573n/7FNHKHwXns/1w5kH C0wHSggUCKsOMfpJywcOTisJRGtrFpgF6BC0IK+L8KLxeIwpeifyyYPHLMS8XQ2AZszhcIh+wmA+ n597YvQLZb+wpOrCLDDUNBoNG2nVjy1bOP645K1E9Y4f7HQ6/X6fSZP/nUwml554C4PBgAghEohh iw2CnOlSJ9Qs5PP5VqtlXSXxE5awtwBFGg9ol1cKuHXwg1jgIFMUut0un/eemHUILSh1lMtlncdQ m7zgzizogYQFueBJdXqhhU9cJCyE6xBjIUFo4cZRrVZpkLQXew5J/cgCd9aysJJ19auEhXem0ylH 4M7BuaZUkbrpVFOLkEvZF+INO7sOFT5Mcd+KxZEnXtJaPAccu3Zl6sBCJpMxC4wM4fqTvqz4JnZh xyFrunPo+QULardqtZpZ4Aig1kYwVFmy4maz2Wy324Qxe0SnceLggtjWV1zw56lnQxbg2kF7RrjK QmoJvChIKNCVSmXi+dLCD89mDFp/s2DBQNiw4JIN5NtSqXTlkf7IV2xUv1nIZrP0DBxAXFg+0ZoX i8XRaGSTI/o3J+YbWGnTkZRyJZNCodDr9Z480r9tvSuQfnaZ/j/lW+VcLvfokf5ty/wCBWo6nWZg qdfrs9nsxbNtaWugRtSC6s/pF2Zh20L+J+8CDAD6cq5YCg0KZW5kc3RyZWFtDWVuZG9iag00OCAw IG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDEzOS9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1h Z2VNYXNrIHRydWUvQml0c1BlckNvbXBvbmVudCAxL1dpZHRoIDI5L0RlY29kZVBhcm1zPDwvSyAt MS9Db2x1bW5zIDI5Pj4vSGVpZ2h0IDEyOS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KyndOXLyEzRBc fkCB+L/8hxc5mE3Ce608lnvrrff/9/71tcPx6vYVrw3YdOtP5O/ev3//++678er6mwz5N/fH//8n BMf+tdTPw3TwnX//jx//8j2T8f9euDJxx//IcdepwF/H/kr7fYb4fd/2Hw/+/Jjj1xeYfVeF648g vfC9evC9DrWv/8KOACACCg0KZW5kc3RyZWFtDWVuZG9iag00OSAwIG9iajw8L1N1YnR5cGUvSW1h Z2UvTGVuZ3RoIDM1NjMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xv clNwYWNlIDg4IDAgUi9NYXNrIDQ4IDAgUi9XaWR0aCAyOS9IZWlnaHQgMTI5L1R5cGUvWE9iamVj dD4+c3RyZWFtDQpIicyXCVRTVxqA/2CFabVuuIEiKAgkiIEErJ0yFXHaao8Lbh21Km1BxAV3x10q 7o64QgUPBeS4d2ZacOmIlooLLiQhISQxIIu4Hx2XWhVUkvnf+8nzSULy8MycM//5Difvcd/37rvb f29Cwv9RmBbt4PhfOO2b472kSfuyN27bmrJ3T0HhRaSpkvdmrUc4IV0iNp3WWuTngtN6pQr5r2in xU7D36vXb+C0iNag1+p1Dx88tG4Bm+3wWF+GmCF4tZNnBnjEO/dopF28elVBwRlOSwjWys0QwiL7 O3TFV8RAq49c3Jxbt2uk3bAlqdASx0+cUBsMRCPt70fyEVbLEYr++yC9BoF6CBjXtseXg0d80S9s 8uhxKzZszMzMvH3zds2izdHu/qidPD6qwBJ8bf2SHcibWjmv8iH1EHQLfO+CRA++GdBl5cqVnHbZ O16oVRWriDe0X8xEbGltvAI/JC8vT6FQmCHIBMF4BwAMGi3B15r8hiKOtK/JYwO7gC79vP1sasls /fgvKzb9kLn/bzPmTvSRnr94Cblx5w7BL8Z1n/W4tQ508rVrVyWSNr/wXE3NNYKvFeIsm7+RtJXQ 8yH44ZDOAY8p73mFdfBArbHMqNOVEkJsnBO5Lur7Avzf7LLQ30A6yjto1NixOp1OaYlmaVkPCaVm 6GNmOp2RP4HAZOi6bPlynbqEw6Hz3iKGOujNSpi+NvWJNA2Ke+kaYYYArtrvt3UtwdA0IMTJVk9u gsDnHQbwtQ+mL2C1WHP5GuieeWC/Wq0WYmaFUqrksf5DDdcqiNfasGgGptoh7d26p+5K1Wu0hF2t zDLIQ/MLz2rKywh+GdPAqQiW+QTa9PLyFqa1jHCRn1KlIhqVea4yIlim2EniBC2KLNGU81FVDULa r6GLRq0hmtLWg/yP4IqLw60btwib2ifHTyOk9W3RvkpnJOx81CKRu2Nt3lmEygcGB1VoDYQd7Qkn X9RW6oyEbe2JMwiVDw4OViqUhB2t0kniUPv0nAqh8u+2eA/LN9XLr1dItrb2G4GvbQkupVqtQ+16 UTfUYqYgbGoTeON2OrjtysrSakuJJrQhE6G9whJNOTFMTqEIO3hkbVq0QmGxWk2UV1dTmUdR8QiW qYbAkf0HVlVUEXa0dd7DEapwIridP3caF8CzRZfRSeQtXsfOXGbNWQSdDv+wr6L0CmFH+yznV4TW wBcgGx4ZmbhzG2q3ZWXmHv8ZQS1VFZkRM0VXrBGurU1MpgeTwS0Ruo/uJkbtd8O+PCAedB+8qapX QXK1ohK1hB0nBTpZbQBbZ2YTchf8s1r4PgMxeyeEXTMlx1N3o5bDoTaB6xSXD3np5o2MfGpMLGoJ gU4K05zNyJu2IPYTAklLCBfa0mKiFJs7DDKPWFC7JxfvFJz9hWiulsykfTlzU92kZYXZBw8eOrQp cU2RVpt+YN/VK2XEpcuX30J+VOSDpLnL81v1PQbeKugV867nBOg08i8TUMjRLCduFRAaD5ZkFMJe hgbBH9CGKbK5uwVTQCTCGwZ9LDCXRgicverbvJMnhW8VGOegaQhl9gYVm3NNf4phe5DJvJ1c2vX0 9EGhkCz5plZuEAUUL9/C176ct5XdMPTVgyQGOqpUquuV1YRDreV7Q5I3b9FWVhCkRSdSKx7B7tJl hw4dbo6WacCHoiC1tuTOzTsE999rJ/YhVObTwZ8pFQrCvvNZoRrBR5awi799rVtn9yKFgrCv5XJl BHRS8ML6c5isB85CEkQCL7N/Ap2xsM2m47R/5r1aoHY0dHGoHcK+ulna7SIPjUZjs0f4WqFta9E+ EAX986cfVcXFV0pKCWvtQOggcCTwngpx7+5ZeP5slbGcoP8+nbUBoTIenbvVVFQRArQN6TUR3EPD PkpLT+cOdFEzp/G0IQsXLxa+LNR/Ho80PAgdnV3enzp/rtKgUxh0qFXIh1GauAOBly5eFK598usF xLJehWSD19q2klmu4h2uwZpWMstBIGR3S2+D3kA4dFLg9GfXKzo3hXJpl+Mq+KRn7Wlq094oav61 d3zsVFyfScuem+hQJrUcqWTsZZ/UMZNRS9hvAXRyWhrhqDUNiH3ZMeKlW4TZpb+5VdirDh8z7wqL Pv6PXLlMdib/lMO2tdYyZnR2jKg5ll0/Ms60NLn6zGHU4qorXPvKdQDyV2h39OjR6vIKYkNyCjr5 2ufqMqS2Q7jGuW9meprDw47luNfv0yFDkrZtzdy/f0vyd6hdEhu/fM7CXXOWLRsTtXDGbIJaOzU1 1eGawPVyG3A5JvLJg15a8NSCF2rLoedN8L4LfjfAl6CSaWlpwrUGdoqxI4qhhtkohlhvxpqrZQeq mIWSmoy3zaP7AW+hfQrSfy9JrJ22xjQoDjGzO/8E8DDOX483ETb5MiV37WpG2w5287356D6nrdvO ZK4w6LQz6/tG2r3ZWQK0QSyyMZMmopZgassaJkLX2bNnc8clGjZFRZcda1uHMbTsl5uTo1NrCe4r 8BQWExPDaXGEm1wHxsRMJZpyYpjmJiH1n8c8LlAQGRkZnHaVyD0uLo47M14/suf3n04RdpycmbQZ vCBtisgzPDy8Smckdg+d9GPOEQ6HZoxwaB/OnhA5CWovO0lkcllVqZFA7cIeUhQKXMaxbZFLTmLU crtB1J53Ekv8JZyETkNfRUc7XBMo6iPjEKwbboYVlrSKWo1TgAu4cBJqmdgpUwTuE0zi4cgzCNbo tOeKlQRJROBSesWAHElKadDGxgrUWtYx+fSxE+bFzli7YuWWVWtI4gWt8TLl23VvpW2Yazeg92Xo UQw+KmapYe7cEknx8jb4PQCft9ZyKxhv7Wq8jr1FI7B/+9hC+hZak/8wBB+p9RhCRwba3jekePzN /LevtRZHnR1//dgZCI4E1fkLTWmfLt1uR2vTXD9iKnIOehcVqyr1ZYRVbRsa4ZtvvkbJqTGx0e7+ 9rXmz6KRW70i+Fqr9qccIV6ckIASE0jqIQjniB3tw3XrkRcHcozFWsK6TN1XK4iyEv1TpY5qruCF HS2xIH4eFivRlCDW2uMp6dXvBAnRkhmF1RcKEL4W2TkhNk/UG9nsIT84Of6eZaYI0VJYa+etTkTt 0RlLUYue50zzypurfeUahuwHN3VJSXb8kisGI2l/Y2ZuqGX368ule4Famm71IF+8YjlqL7SR69p9 UACeDbNYMgZ/PFv3/fOk9GZqG77uSAvfe9Cb3dg37DpKQVKpUPO0zIakuVoG0Qdm31Fmn0h2Iy3/ uI9UY9Bz1E1a9igqPmrceMKm7bGhfN702Qqlkq/NdQ3dlrS1PP9caWkpXvr4i/l1Iy3RlJPT6nV6 TisVtQv2lqzemTxl7ly8dAZnDS8uFJy/Wn6VsK/9sH8YT+uPc/M+iKdB5yxwwzsAzrkn/0N7ucZE cUVx/IwaqzYmtCyCaTTEmG53FXYXGA2WYFttbaiPpMbnBxMj+AxaMCI2bhBfTdBoRFOsDYnVVD+Q aDSViI/42KwfwN1FXRZMWMDXB+srre/g7vq/c3aGEXaHUvHm94HMvfNjc+ece849c7zu9MO9u3Ea QFuvjpjap7UXQQ0lE5FH7IM4cu8Wbg2bpkTErlqVD+dYRSmTRn0Obcg0Bf+x1+ZZvfDKP1KSOEOs s3AlWTjxawDtPwVFoqn7KBsBdoss8z4epfRsvbejqjbzoJTq9fkaPF6GtXCC8E87lVxIC5H9P3a5 mvYVZVxxu27eCGjwAjgF0cugpa9aIOd8ecnlCuhGl1nRIq64rlVXV+OwDfgDjLF2IyXZ5YmwtQXb Gf1KaN98Ng3gC5Y5nQgzrUc11uLDbaGkbRUVbtfF5kAzo1/8+vApgLxbUVwEbfN1f9DfwhhqhTmZ hpY41xtr3Tnz9mX/YKQ97wYQvhHHHUI04yiNzR1sarzW2N7WwQQCTXozl2Zop1tlr8fDdNM+P34W QLtfSn0+bnZYmOVnZPsqb/qJUyebkHgq2ivRok/p31JCvHgIr68E0E6ihIb6+pcbf0XmIvjz6VP5 k9HLFi/xqKNLG211Mr+nEXG1JZUAa1JMKU03/NB2Lt2mvCXfImsWDTly9JD2i8udmw44t3ddu+Jr I8W7BGRbW7ymzd/CIH+VypJ1j2wTksdAeKy2Fk7W7lm0vFftqwM1AH0LtAycArHJota0kmVTRUWf tFc83vZgOz9nJz/HVoDHEp8AWb9T6uFB5muUCoI05hGZDbRw6rX6KT72H0W1mWqLKyt0dbw9tS/q 3ABan8+nn/LNyPtLGgug7dYw9ySedkdi+tm6Wm0KTtBatgtareb2SRtZvUNAjqr9VdpUUEqDVjn9 ZN3rtljE1mpZUFRaiuL44OHjlsnfQRshu06ITTCLeqG06+IPFW5sDLRz5y+Atk1Kg7bbZt6W0jtX /ALJy9I9TNSp3DpjakNzCoEo3A77wQ2litD+7taNZy0DpxYnoWmLAdZM7amdWQAwdW7gF/cTst8V OkT/lrMklJfPdMugUL4TYOVKaaR2dY1OzSgA6gY69D+y0/TNvz/vNWhaIusqBWQro0StIYlqF64F PWLGgrSFlonXCL3+rQaELTNdufMLS9Yx0U+2YR/QCTNwjHes3vykoIiJKdSb9VrtuRYJKmn1A6w3 GxoZY6fB0GkR+fa/y6suS2bmfzv12gtkPmnKgpZ5H6dem0uJf/x5yOv1Mf2lHT5gGApn6/UA01/a dJvt6lXPnWAH01/a7VvLkXofQsu8v1Mza9p+EX6g8VaAAQDfDJCHCg0KZW5kc3RyZWFtDWVuZG9i ag01MCAwIG9iajw8L0Nyb3BCb3hbMCAwIDU5NS4yMiA4NDJdL1BhcmVudCA4MCAwIFIvQ29udGVu dHMgNTIgMCBSL1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1LjIyIDg0Ml0vUmVzb3VyY2VzIDUx IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNNTEgMCBvYmo8PC9Db2xvclNwYWNlPDwvQ3M2IDg4IDAg Uj4+L0ZvbnQ8PC9UVDIgODcgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dT MSA5MCAwIFI+Pj4+DWVuZG9iag01MiAwIG9iajw8L0xlbmd0aCAyNDIvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJVM29boMwFIbh3VfxjWbAOQebvynqn6J26BJLHaoMEZiItgGEaemN9H7r QBWp8nBs6fVzNnc+Q+XBy/FVJza7PePkRZIrUyBjRcxIDSFPCKMTjbi1YmNtEnrbCILRqiwQr4PA TMpk0KxVklIKew7NSZAiogK2EvFy1bCzkM/ue8J+coOP7FvoNC/WOoJVFCoJi8ioJF+t6+9qJfni vMqfKDalUal8jELB0qOdcMTX8aOt0XbD54SmH/Gy2yI62KewKmZldAl7/0emV1L/I3N5E11aWffD 5OrF9ejcjLkf38PTnbcL+WDFrwADAKoMTpUKDQplbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2JqWy9J bmRleGVkIDg4IDAgUiAyNTUgMTMgMCBSXQ1lbmRvYmoNNTQgMCBvYmpbL0luZGV4ZWQgODggMCBS IDI1NSAyMiAwIFJdDWVuZG9iag01NSAwIG9iajw8L1N1YnR5cGUvVHlwZTAvRGVzY2VuZGFudEZv bnRzWzI2IDAgUl0vQmFzZUZvbnQvQ0FOS0xKK1NpbVN1bi9Ub1VuaWNvZGUgMjcgMCBSL0VuY29k aW5nL0lkZW50aXR5LUgvVHlwZS9Gb250Pj4NZW5kb2JqDTU2IDAgb2JqPDwvU3VidHlwZS9JbWFn ZS9MZW5ndGggNTE2My9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9y U3BhY2UgODggMCBSL1dpZHRoIDgzL0hlaWdodCAzMy9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSIns V2lUk9kZ7o/2nLa/pu3pOXN0HB3LdKQKCm4sOurIRMStiLgLiAqKylIERYQBQREGB0RJFdlEthgw gSyQhbAFkhACSsCQBQjZv+x78mUh/TAOp3WW9kd75sf0Pe+P+96T5773ue/2xelecP4s1bXwM1XP /+U74gRFFj1Cr0gzAglmQ67d1CFQUIk8NFvBBF3Wn/p2/xNZcFstBoJanKQS+qpFq9WyQ3p1xdQc IqsrJrI5+CrmeBu7XqYX/dTX/G+Ky6XRyYtl05sUguVaRYBSUaJQzOm1HrFUn4g+uqn+j3ua/U4g dp5Ff3ESsSOrK5GjfPWfHMuZVXaxROgRIXZcrNSYoR0WT0EaF9tAB7R+JQCITKHb5TKabZ3Ds6+n FSAI0iYlgMa0CF6sxwWTFdSabXoL6FXdWwXfwpdEq7Owp+UKlYkv03NEmu/VNyKNVg+l67/U+IIb 1CsfSqe3AzOrDJptanWJXC5Wqz0Wk0cgmknCHNzRsjK8xT8WtSuTEpVBOhrTBsvrSZMb/m3oF+Ad 7DNPGUk19NjGsYYensftet7DPfOEPq8wetzunOaxIsSYx+PGj8yfqqAOjYtdDuedFlYzmevF2yz2 BuJ0GZFb1Sd43CeoJPMWlcJHM+chsktuKAxhahWtpH0io4mVWs9Me/a+pj5jpjSMVvfw+GLtEsoB ioH5WEAQrhbtNur3AkCHWuUyGOwGg9FssqnU2ubxBydR24OerdiH8I/HhWZS/lrGSCnqT77cGcmU DP8IbZ3GFF3cW46d0ip0seX9V6oZbtDB4wMHSvryW8frOiYjCij8WWVbHy+sgNwxwIeeAkKNcmQR 2QTahAxaWy0ggTaLoQsfoicetb/C0Ge7R4Rw1ERwTs/1qpEFl8v7vAV1o1/c6WsgTY/xlSwuMMoF xgWq1zNqFk/JfGtOzKkwQ3PBOYTYuz1L19OrquWCvVpJrFYWolZnQLE2GJwGg8lospjNVqvRMTZD K6Vm7EcE7Gr8NOrlhouEHTkDx56wsvN6L3xNzTbZ9D9EfFqg2pPd3TsucVvsh3MJd5vG+mhz8PbX e/J79t8fPF3SF1HQA385cegeJfQmobJ1XK4wQCi7zZ5SRs2tHHa7F3ktOF1uq/1OzQi8meV2ODxO FyDVRuaQzxYNuEBw0Y3LmVw+FH+f6rTa3su3fzbsRuv2VEx0drfXNKqfAnORGmmaRhJkNCQoZG8M epfZDFG2WS12lx2EHC+izDaeaLKace8YKng/0icev/FvlIj6iTuPaF+VDeYu/MBwbMFytqdgNDoj dUS4/iyaNi4m0oV/x0xBIT5TSIHdJEJp3EThIfsFiD5BE4mr+TZ73U4nV6B0v00ASASzqi1xqDr0 1LtIaUwRl3Ffweleaiq1KSKt62HDaGbpQG7FELQjluiO3yDCMggNnW8gc1aoScgnPamjh17FFzaw oB2bmSWZhmkkKSphmB4IUSpfqtVms9kOsXaADqfDwQcMncx57KhIqX07xewesUJQPZp3Fht4qnNt Kjm8eaq4eDAVx3nxvcSLHtM/iUIeTMbtOo/+/FxHxi1C0r2BnKcj1yuGAs6gguNQifk9Fwv70x/Q k0upMVlEPHGypIp++hYpr5KmBIxL5yA6Jv0PNHH5Cq85OCRcs7+1mzrnNan0OZ99TcNj4uedb/yP IhmMmUu3e5PyydHZ5JjbvXKxdn9md37NaB9jLvxGN25wFoLogEoZL0wjOqOa32BQwQBgRK+3Wyw2 mw10OcFpsTqv/fW+4t69d3sKEGNCpdHLXajgPqJnxmED43CBXzMSy+jXyqg5Dif4Hd4LV7JJAYda bpQNbTuO3H3ixYUrnZGpuNDY9tURTbsTOk9lk4+n43fFoD6JaNl5DgU7j8Lg2Tfv9QadbFsFa+qn CZcOKoHTtkY2QynoNduxnNURLSy27N2zoNmf7m2cEaonuUDQOfSV2+SwCx3MsbmbcHpYOv5RHTPk EoYtAHCDM9G5pCGWxAFKpZxQQLBNzg9Ri3102gwVoDCbHTYr6HY6KGzRrnziykvoNSmYz5I7Vyah Qm51caRQObvdoMducRA5yDRyeAw2IH8gLo9yeUbDe4+2Rm1c4/+44iGUkJ5QWFP8ZZwTBJ9WM1dt qF4Pa+zCc4YZIuqIBGLhs7UuMZ0A1aoXiMVyPvarIpL5D6qYOaVDt8uHdx5HbI1E3Klk5HwzjESx 71ePbIxqBYB3veV8BuFQQqcTGnBuV1Jh70fR7a24xQx/3jH1WQxqXSy6nzEPmdfu9acX9ioUequJ IZpaC7GW8Xy1shVaTb5apbNYoNA5tUZrch0dIuubivVLx/ml4wOzuv+SgX3WL4DiaLc5PA6PQil/ NnYvDrc5mRB+nXiCNk95jziHI/vDsrKuLi5os/1p3eMLV3HwStrawNrfrIL7bKk9cgwJO4IMO9K2 Mwq53K/643VPu7p53pqtqWH5bawmE7lfHkb4727c+GWjz+f162BNO462bTrYWlDcl3WbsvskEspM 6MfQ+NsT+/JyLtSrFxvCtaL+wNNosWRxZlEGZpfDmg+kdlnMdmhgR8V3lJQPgza7QVU7N/aBZMoH mP2dVvZrnSZbr3dZLFArWxjgyP2u4f58tXP9NXxgZvfmm8TgPHJQUV9iLcNktkHfG1ar3WFzqwHV i1cP4zCbD7cGVDFL3yNeV8NctuwbIolXXTO6YnkFHD5c+YQeH4/+4INyHG5aIjNIpRqZTDvFkW4J aQjf1/ygYhj6DwEBEy7it4U26PVmyJfJap+ckn3oW1XbMG61g1YbqNOZ18Oasgp7vV5kUt3GQy21 bWxozRgVfxRU7xtcx+cpIfNSEv4Xvy+PjEZCjKQS3erVcOrQYvlo5aWzI78Usz9UCH6rlf5Kp8n6 lriHMD6/Lh3nm4LbdIOwJZu09RYpNJ8UWjxw7h9sV3lUk9kVjx5pp1OdHk+r02qttgqV6riPIoqC KFi3Ac6MOop1RqvFmQE84qgjKiAyKjiyCRoiq2GTJQQM0ERIIBCWLARCWBIICdnXL/lC9oU+CETE 3j++c95733vvvnt/93fvfdmlgiacDjsIB7PRatCa6byWH/GhQflrk8mx8x7+4D5p6dLU4ONlvvte ea1DMpkis8Ua/UP9X1dla1yF2bQYjcZdO/NeFTEAr07xgtMRElIVElLpnEU+jTa+YgOSSOK5hiIx tHZPQU4B3TVks6WfBRQ2NgEoTkZdb/T2yd/hk1+LHeRwFBs3ojw/y/H1KzQZzT1M8fJlmfwxFfhN zo8e6UIIWR4yrodGDDx+RwvZbFaHzmA+l0n2jKzdeZuwO46wNx7vl4A/kNR0ILnF/yGxqU88jXYL QJrBYFEolEXUX/bnrbzZcAno7H4OSMHHjr0OP4ft6uIfCEAHHihxQfHkl1UrV2QGHy05fLQ0+J8l R4BZ9hQsW5aR8qTNtVHAV63fhExP73AfFZfYsiWgUCaZieiSsr7Vm5A9DLFriMqheW5ADg9LfrrV tOovWVyuAlM5sMcn/88rnsXeIXZ28Ff8KbMeN1SQz/Ba93wm/QnvcDoQAqaHeGCRSvArrSYJ0oBY mMQxxv8WATjtzZ54gl88PjCRcPAhMTCZdDClxSex6UpelwGwnxXkeiMMG0w6O2mo5lDh6p8aL891 t1Sq3b4VVYzuAcG18/PcuHvNMGxms2UdFF41hlWJ6a/GsCur2ZiaARyOvcOn8OatZpdWYGblP17Q e4Suc0BWDTxafOpfWHc1EhWJ3733FXCiCx4XL9Zt2fIy/GyV/340Z3gK4SMj8kPBxTdvEBz2KVMn 3COdOFYa4F8QHl7jOgGSZg5TEPweDxF7kZK/SKtJhNRmp93ZyBR+m9a260aDz128/338waSmQykt QU9awNu/zSA/qupRQHqH1QZyPQxPmHV26kjTEbRXIvH63IcPDcrXe2UTCBwdZPBe/6K0pK+xkfNF WPn5f9dGROEuRddfjMFfjiFcuo4vK6P5h71OQ85AN/1F9/qdeZJZ/6oU8KbtqJuxbuZ0nDuLDQup dNkBAO9gIDrkRHlFBYvUMhMLfL6qvJIFgnomNMahOmz/tu25kZEzNZsewnG7EXzGQj4DoRj7vRZK UamNer3ZbrNNmEyhCYR10bV+9wngyUfTyEcy2vYlErAUntNhA8xmMJj1eqNWC1tgR/dI8xH0+tpB tPvVTocjIYHo7Y2CtXpcw9AfV2XRaEKRUNNE4rW0jjc3jxFJ/ObWUWLraHMbLzGlxXN/QStlzLXz zAXsqQvYSeCA6XqVROR9uizjv40zuVKpgLdvfXk/nugEweS09/VKPl2eWVba6755bpkK9IT1UzVJ V5dgxaosJIo2Mz/RM9qznEdD8OkItchbqchTqydg2Ahu7+HKD99/u/se/nAKKTSDfAbZcQrZGfS4 +VEl02gy26x2g9k2YbGBJsYCOykcfFjZZoa4zX1jD0PkvQ15IeLNAEsUGl7t9Xnu2JjatURjip6j mYWYgeJqVhGmH1XK3Pd1xa4vSkXTTZPDZj8SWu5ztAxdwSqrYBmNpvLXrMWfpFKpM20gn6desyYr 7KuKvCJGDZZdUtyzeElqaytv8gOBdcbs7M6Ex+SHqZQTJ6v+vhnV0yt2r6r6C3nU3WPcIMHwU6GQ C0EG4ESQRZRqXe+orGtYQukXcflK5oi8Y0jSzhYO8WQTgP1MFvngsJhKVYjlVstkHT3/RuNpo9Xo PrapeSQ9l2o0mxl0YUYubUSgdi/V4YeS82hpxb055f25Ff1Zxb1FGLZEqpv1mJPcyY9LIcfca3qU 2g4CmcYQovJoIIm41oHNCaTRrFxq9osubO1gV7egsIiuhef1JlOikOueZlIepnY8yugsLO/TaCbe MwuVPo55wJU0CEbZcjkMaWAIgiEtbDabQJVlAixmsoByCBRFwPhmkwnACHZOSvv6hJnpQ1ejRnNe GnX24u40FDVxbp8C9llsU2kR0ho4IrUSmgCunIGZyWKeagKsMrluiKfiCTVTDdc7oALqd2ggg0Kp 18Gu+sSq001MzskX0z/ajQagkHkqe0xFxP9tkZxADZvN5pjWZJ7YDAZJxPeSW/Fyi0NlsGjUOo1K B75aSAeIS683gECe0E8ZwGCf1Don5RyuNOmubMO6scW/YXgsZCxcwEyOe81FaUzqeSerVPqfi+kx mW0JeV0xz9rPPya+7eS7jMMeVf6YSYlOJd95QbnwM+lSciuHP387ENAr5deyb2e1331O+e4JKbWE ATQB85294qScjthsSkw6+XomhTk407nUEIaT86l40siDl91X0si41lGhFK5sGLyWRo5Ka2ufShPv 2ceqUo0FBfJ3bZfW1clVsNxgUxvtGqNVa7JpLU6NzQnZHGqFSolvkFyNEHuuki5C8BYg6B4L6QsX 0BEI6jdhCrN8ns6cUWXwtXo0ftjtqedVrH3X6mG9sQbP2R9R28EUzrrFEZXWfuYuwT4LCZeMCjTH rjUgMf0AIWCo1ho6e0V62BCH7D4f3zzuYmynE1nN8v0BJ1Pq9VpDQOSb03GELtq4VKl/XtXvfRlz +ymZNSiTyOELj1t9I+oA+OfpKUejuUt+LQ3yF5WXitmDCrFModap1DqlQiMXCKQ0qjTnmez0cdnq ZVIPhOx3H40s+Yi59LeMJR/TEIixx0kf4qwYN7j3uzr+NF+5pADT73+1QQPpv09uPRtPBLHqXrqR 1n7y9ryHOwtr2L7/qZMo3lMV0kwcjMKhsAPumQbiyO4I8BvM4cq3na8qwPa73Ioj8TZdxjTMkt79 7A7fS7UqFTz5gUCU9oG1awYRCMXGNfLje2XhoZJvvpaFHpD7bZFt85Su/YPce6V8h5ckYLP40FZB sA93mxfjk4+5MddBgTHvKEAL5+KaIn9pmwutiJSW6NQ28bg6JJZQRnjXx4E6x+9K7as3g3NPAJD+ 8kbjo9mi1C01TdyAaBx//F1cJOXSvop9Cygju4wZdK3+f3r+AhxQ//41zT/nV7n74wdQgfbj28+Y hr3lU47/xwaAKfLpzBlXRUUeMDA8VxR6Zanx0lzzhbHSS125l8Yqz6y0nrkYvgx3eZ4b8qIo/GGA 3WU5sRt+3h9u3MY06uunb2GNeypmgHqjwO7M02cfr996FVC/e/6W68+fffBt2rPuMKhd/e3z9yfP P6zdd8uxZOvFGy9QYuHdV6/y7TPWXYaLfP78HZgkluy44Vq+4/ULaDIAtl6iWw+0zAfWzv9qFpyO 7zsILDdBIf/tZ1rvoaz+o//+gIq1t++/Ai2dt/Xaf9zg9/v3j6dMveloe1lK8I6axEM7/ScR9s9S fV6UxL1qK3rWmPcwJeCqp8Ot1OS327f/wWXKv3/bj98PmXC4f9vVBXtvBnUdsGjf37Ls7J8/f4Al cN+6i9FTj83ef2vKpsveXfuBUgt3XAMV079+9669mD//1IcPX4FNkxUHb4dOOjJ1x/UVh+90rr9Y NfvEy1ef3rz9kj37RMniM8sO3p67+0bezGOLdl4HBsiHj9/CJx+ZDPPa+esvrep2bzhyF8Lde+6R dcu+U9ee4/E41OHAxHb71rPZcx4W5j/ISryXnXI3P+tBbtrjmsoX69Z9e/HyL0EjgE2s91+P3Hx5 8PqLa4/fXn7w5tLdl99hmeLh8w8Hrz8Hyt56+uHSgzc3H7wG1knAAv/K/Tf3nr+H93Rev/18/MaL wzde3H36Hp5rgE3law/fHrrx4syd18AuEkQQ2Dw7fv3FS1hN/fzVx5PXX3z5+gPCffDs/ekbL378 QM+SuMDvXz+/Prz/+cKFDydOvj194uPF898eP4LHMtaKExuAK/z3998/bOIg9r9/RJuH1Q407eim /SPWvf9QVGLXRplThwT494/SGBlsACDAACZSY6IKDQplbmRzdHJlYW0NZW5kb2JqDTU3IDAgb2Jq PDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTgyNy9GaWx0ZXIvRENURGVjb2RlL0JpdHNQZXJDb21w b25lbnQgOC9Db2xvclNwYWNlIDg4IDAgUi9XaWR0aCAxMDEvSGVpZ2h0IDUxL1R5cGUvWE9iamVj dD4+c3RyZWFtDQr/2P/gABBKRklGAAEBAAABAAEAAP/bAEMACQYHCAcGCQgHCAoKCQsNFg8NDAwN GxQVEBYgHSIiIB0fHyQoNCwkJjEnHx8tPS0xNTc6OjojKz9EPzhDNDk6N//bAEMBCgoKDQwNGg8P GjclHyU3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3N//A ABEIADMAZQMBIgACEQEDEQH/xAAbAAACAgMBAAAAAAAAAAAAAAAABwEFAgQGA//EADQQAAEDAwIE BAUDAwUAAAAAAAECAwQABREGIQcSMUEUUWGBExVxkaEiQoIWI7IzorHB0f/EABoBAQADAQEBAAAA AAAAAAAAAAABAwUEAgb/xAApEQACAQMDAgQHAAAAAAAAAAABAgADBBESITETUQUiQWEUJIGhscHh /9oADAMBAAIRAxEAPwB4UUVFIk0UUUiFFFFIhRRRSJrz50W3RlSZ0hthlJAK3FYGT0ohzos5oOw5 DTzZ6LbWFA+4rW1Ba0Xi0vw14CljKFH9qhuDSeDNwsUxT0J1yK+g4WAdiR1Ch0PvXTRoLVU74M56 1ZqTDIyI7ZL7MVhb8hxLbSBlSldAKXN94gTVyS1aUIjspP8AqOJClr9ugH3rT/q2RqRjwMlDbKmw FZbJIcIG5wfuB/5VHcYK2XFLC0rGMnbFYHiFzVpVTRG2PvPqfA7W2rJ1anmzwPSNXS16XdrQ1Ke5 Q7ulYHTmBwcf8+9FVnD2KpOnUKUMfEcUsfTOP+qK0aLFqalucTHvERLh1TgE/ma3F+9S7Pp6N8vl OxpD8pKQ40rCuUJUTv8AalradR61nW64t2+XcJYSlK35AXzKYbHNkJJ6E+m+E7d66PjvL5ptohD9 jTjyh9SEj/E1noLFr4W6guR2W78bkP0QEJ/3E1t0QqWysVBJP7maxJqEZnH6Y1nfrRc0OsypU4O5 QYrzq3A6pWycA5Oc46bnp3rzv141ZEuyvnFwuUacML5PjlASD05UpPKB9K9OGcPxeuLUjGUtOF4/ wSSPzitjitKErXNwwf0sBtkeyQT+VGuvydfSFHEr30ZzL+7cR7unRlpSw6G7lKDoflBIzyoVy5SO gUrz7YOOoxRWOw6n1RDeuMG7/GdbUR8J24LDyiPIds9skVfS9LWybw/sK5N3hW24Mxy4kynQlLiX Fc/KRnI6jBAPfauSvOjdQ2BpUuZAUGEbmSwsLSkeeRuB6kCqqXSwQmAcnke89Nq5O4jE4bXLV8dx bN/hTnLWG1K8TMHKtkpGf3HmUDjHfG3bNL2NrTUq7g06m6z3gp5KhHDpwvKshGBvg9NqtdM62ujV nvNsnSXJLCrc8phbqipbS8BOOY7kHm6HoQMVX8MYYl65taCMpZUp4/xSSPzipWmENR3USC2dIBmG o7rq+LdM3ubcoktQDqGw8W0hJ6coScAbEe29d1ZmpesdCu3Bwhd0YK2FrxjxATggnH7uU4z3xXL8 YpRk62daByI0dpr6EgrP+Ypm8JonhdCwCRhT5ceP8lnH4Aqi6PyysBgntJCamKHiLGDClxJzEhTR QlLiUqyeoJxt5jc/eutlWZySvCnUJQdiRkn2robnosv3hmXDkIbjfFDjzKwdsHJCfr5Hp+KtZ1kA Sp+GOZ4DKWVH+2VZ77g49M18he2d1caNJAI2z7fzeaXhF09kjI30mxYY4j2xlpKeVCUgJHkO1Fel mXcFxlfNIzMd0LwhDK+YFOBvn1OdvLFFa6p01CZ42lLMWJY+sXXEbRd41DqUzYz0JDCWENNh1xQV tknYJPcmrN7SlwRwub0/GciiUpQLyytQQcu85weXPkOldxKaC1hWN8YqUIzGUg12fEvpVe0q6YyT 3i34aaHn2C/uz7i7EWPDKbbDK1KIJKcndI7A/eqLUPDm/XK93GaJFvSJEhxaQp1eQCTjP6PLFOKO 3yOggelQ8zl1Rx13r0LuoKhf1MjpLjEXOueG6J/hpdmdZamIYbadacyEuhKQkKCgNjgAb7HA6d+V OktdPRE211x4whgBpdwBaAHTbPT0xTzLLakBSwebHY1CwFJ5UtgD6b1KXtRVC847yDSUnMU7HDOV G01LSzLjO3WUW21lRUltloKCiAcEkkpTvgdPvZ8M9ET7BfXp1xdiODwym2wytSiCVJyd0jsPzTCQ xsrbtWUdvkdBx6VDXdRlKk8yRTUEGKPVfD6+3bUdyntyIAS++pSAt1YISNk5/R5AUxbLb7lbTaYb T7Py6NBQ042BupYTjIOPP19qt5DILpOOtbDOzSR5DFeKlwzqFPAkqgByJnRUFQBxQTgetc0sk0VC SSNxiikSFgEb0JAANFFIkAAEVkUg7kUUVMTDAwKySkeVFFIk47ViAARiiikQUATvWSdhtRRURJwO uKgDeiikSaKKKRP/2QoNCmVuZHN0cmVhbQ1lbmRvYmoNNTggMCBvYmo8PC9TdWJ0eXBlL0ltYWdl L0xlbmd0aCA1MjcyL0ZpbHRlci9EQ1REZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3Bh Y2UgODggMCBSL1dpZHRoIDE4NC9IZWlnaHQgMTY1L1R5cGUvWE9iamVjdD4+c3RyZWFtDQr/2P/u AA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcb HB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsBDQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUa FxcXFxolICMeHh4jICgoJSUoKDIyMDIyOzs7Ozs7Ozs7O//AABEIAKUAuAMBIgACEQEDEQH/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUkkklKSSSSUpR c5rGlzyGtaJLjoAApLi/rznX5XUenfVmh5rbnvDspzdCa930Z+RTox4jSJSoW9RgdTx+oh1mJL8d p2tviGvI52eI81afYytu6xwa3xJhQoppxMdlNTQymloa0DQANC5n6v5Fn1j6nk9WyCTg4dhpwKPz dzfpWnxPglV2egVdUOpeqGolOsLpHUL+tZ+Vktea+n4dpoorH+Ee36dj/LwCz/rP9d6OlZhwKQ71 qdj73bdNhcJDS6JMIjHInhG6DIAWXrONSh33Gql1rGG7aJ2MjcR/JVD6v9cxevdP+1UBwElj2vEG R5a8qjRkW9K+s7OkhxfhdQqffjsJn0ns+m1v8k+CHCbIO4TxCge7sdP6lh9RpN2JYHtadr28Oa4c tc06ghVsjrdGFmsxM9px23mMfIP80937m7813kVz+W93R/r9i/ZtKOsVkZNQ4L2zD/it/wCsvTKe qdFysawSdhfU7u17Bua4I8IBHaS0SJB7xdRJcx/i96xf1ToDRkkvuxXGlzzyQPo/gunTZR4SQei6 JsAqSSSQSpJJJJSkkkklKSSSSUpJJJJSkkkklKXEfXrEtwesdL+szGl9OG8V5Ma7WzId+JXbqF1N V9TqbmCyt4hzHCQR5hOhLhNrZRsMQ6vKxt1bt1dzJa4dw4crlPqBu6cM/oGSNmViXGxrf3q38OHi uh6X0lnS2uoxrHHEJJrofr6ZPZjudvkpZnScXKvqyyDVl0fzWRXo8Du0+LT4FIEAGPQqI1B7OT9X 6LOiZuX0q9pFGTc7Iwbo9rg/V1ZI4c1cp9YmYeH9c8zI6riOyKLqA7FDmF7HO2gdh4iPJembQQA6 HEeXdZnVGF3UMKGt9rbT6p+mzRurW/neCfjyVImtxSJQsV2ef/xX1PZ0vNuNTqabcguqa4dgIMHv HC2KcG3J667ruaPQoxKnU4bH6Haf5y1/hPZH+rRcOmmtzBU6q65hradzRFjjofmtR7GWNLXtDmnk HUJs5XOR7pjEUB2eWwsK7rf1oHXrGFnT8Fhpwdwg2u13WgHXbrotX6z9Ur6X0TJyHGbHsNVDBy6x 42tAWqAAIGgHAVO3pWLfmszckG62r+Ya/Vlfm1v73mhxWRewVw6Gurk/UTolvR+hMZkDbkZLjda3 92fot+5dGkkhI2ST1TEUAOykkkkEqSSSSUpJJJJSkkkklKSSSSUpJJJJSkkkklKSSSSU1ep51XT8 G3Mud6dVIBe+JgSATovN+o/X/Fvz8W5rbbq8etwcTDHb3aO26dwF3P1ybu+q/Uh/wDj92q4b6hdN 6Fn9NyHdQbS2+smsvt2n2uh27a8eUSrGEREJSkLosWQy4hEGrZ/V768dNwKcmlzrceuy59tDI9Ta HwSHOPgQV6TiZFeVjVZNR3V3MD2O8Q4SCvKfr3idBxHNx+mtqF2Q9lwdSGw1gaayz29nGHL1PplH 2fp2LREelSxkfBoCWeMajIAji7qxk2Yk3TZSSSVdlUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKU kkkkpSSSSSlJJJJKa3UWUWYGQzIYLKTW71GETIjUQuB+rv1P+q+V0gZ+c+5haXC8Oeaw0jQtcABE Fdh9as+vA6Jfe/drtaAwS4kuHCj0ivEyuk0Oym0ubdWLLaxDmF1nvcSY11KkhKUYGiRZ6LJAE69H lMr6n/VWp+LdhWWZHrF7aW7y8Oc0F4Ihuu0jhd303JGXgY+R/pa2uMjaZjUFvbVZvWba8XA+2YBp L6XteyXNaxwB2lpcAY08EXoOZTb9px6xsNLm2Gvs31hvIBGhG7dwlOUpRBOtJiACadZJJJRrlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSnA+s9zN1NBs2O2WODedxeBS1o8/eV dHS8S7E+xeiKsQM9M1sJaS0dpbELB6ljYfW+uOiz34l9WM22txDq9jX3Wx2ncAFsXssM1Yd9u4CD a5x2M89ojcVJWgA3W9yWV3RsOvAswKKGMoLT6dcewuAlunZ06yq2D1Cm/LxMnWu99baMiogiNzfU YR2PukSFLGw76qPRvzMjKdHusL4d5lkQI8uVUZ0/Gd0tzKrH2ZPTbC6q2x5JFlR3yeOW8hKu5VfU PUJKhj9WoyMarJq99NzQ9rmnsRKt1X1Wj2Ok+HdMMSOiQQUiSSSCVJJJJKUkkkkpSSSSSlJJJJKU kksL6zfWDK6IMexmMb8ewuF9rZlkRHl96dGJkREblBIAsu2+xlY3PMBVX9RYDDGlw8TosfD6vi9U r9ai4Wn85p0c0+beysKX2a+bdj9wnZvjqTe9Z+RT/tKvuxyoJJe3FXHJ0B1Gk8tcPu/vUczqDasV 19cEtI3btIb+cT8AqIkqn1dzb62dLY6BkDflFvIpBjb/AG3afCUPbFhIkS4/ReoZWfnsu+z2MBfk WWNG1sstdursO4tnQwP9i6e29zKyfsl5a0cN2En4e/UrOqxTl9Ty3tLajj11047WauAJdYS/jQzC sspyx+gfb6GT+bGrXNH+jJ/JyE40T2UNu7Yxsj1mbxi3s1g7wxrh5wXKk1t46pmXGh9bgGvqeCwg yza4vG8CPYrNePk1NL78mGtGryI44VPJGUepYridjbmWMbj2cuc2Hse+NY5gIECyoHTZj9Xc52b0 +2p9BxrcS59ZpIiGOcXMLB+7HHwQ+qfWDpvS9L7N93ahkF0/wVvqWI+m52VST6gpAu28uqBO8ad2 7twXG531ZOPkm22b67DuY4TscDqDu7qTGcespnQdAtkJaVu9X9U/rXZ1YXjIYK2seG0gGTtI7ldS CCJHC4boHS722sc1u1g4AEBdwwEMAPICr5DGUiYih2ZYggUd2SSSSYlSSSSSlJJJJKUkkkkpSp9U xXZOM6toBkQQVae9rGOe7RrQSfgFj4/1ixOpVB/T7A5p+kD9MfFvZOjGR1j06rZEDd5C76r5tWab cAnHtB+k07Qt4UdYDAHXsLvzjH+xX9eTz4906sicqoni82EgE9nP9Hq/+mZ/m/7E/o9W/wBMz7lf SHPCPH4BHCHKy8bqzqd7sgV0Vnfe5vsIraJdr8lHpleU1v2q9lbDkv8AU2WTvbSxv6FpjxHu8pV/ PrGVfR0gfzdg+0ZzjoBQw6N/tuEfAFQ6gRZkW5D2gVXluK1zR7m0gepY/wCf0fJMMzI0vjGhaPpe HaL7uqB1TsnL1sY0vEVj+baADoQ1X7sezKp2v9F9buHe8OB8QZ0IXO3YFzss5/T7rA0GAWtI0HiI 4W23LyKsR+VZU51jGl1jGsID48O25KcKog2mMjs0unUdYpucet+j9mrfGG7U1j90vDfz/CVa6p0z JvfX1CsV15WFL8cgO3Af4QHXXe0RCLiZ783DryTjPFdokY726t1/PHipfa8jEl/oWWYzRwBL6/hr 7h+RN1u13gk9bMc+l++lgcDDtphzHNkOGv8AJVLA9XHZZ0/qGwBodfivA2tNE6tgzGwnjwIT17sq m3EDNjMVwycRx2kljjuYWxPtaQWoWXj9R6k17mgevin1aWnQTEbPg9pI/wByUR3od0FbpH1owLOq np+MC6trXF1pENkEaNnVdK/MoYAS6SdYAlct0np3RmlvUMQTfeJO8+5v7zQOxB0K1e3Ef6/BOyQg ZXHQIEyBru6X7Qo/lfcl+0KP5X3LNSKZ7YTxl0vt9Hg77v8AaiV5FNmjXa+B5WRCdL2grjLtpLIH UHY1bn2vDamauLzAA+KP0nrWF1al92I7cxjzXPYkcwmHHIC607rhMHTq6CSSSYuYWsbZU9jhua5p Dh4gheX9Y6LldHznZPSnPrY0yGiSW+X8oL1IkASVldRrw8iW7dx7kaaqbBlnA+nUHcLMkYyGrynR vrf9pYac2o+swCX1gQ7tx2Wmev4f7tn+ardOBiUT6VLGz9Ihok/HRF9Kv9xvyA/uViUoE3w19WEC Q6uf+38L92yf6qsY3V8N4fc4OZVS0ue4gQA0SfyKz6TP3R9wVHqjmX5VHR6mhwdF+W1uktaf0dXw e4S7+SEyRj2/FMQe7LBtd6duTkNDb80+vkA/mVAfoaPk3UoGVjZvUGmtj21kS1zz2LjNhDR56fJa mWKsfFHtFlznAA8b3u/gSsXrfS+oDKx78a0sqoaA97TDt0ySR33EoY64uxXy+V0+l4DOm4npeo5z WkufY7kk+H9yubnki23SP5qv93+U7zWJ/wA5cTHuZX1B0OGjHAe1p8XAd1ptyqbgLG2Nc12ocCEp wmTchutEgNAWyCTZ6rPbbw4dnAePn5p9x1ezt9Jp5BHYqt6tY4e37wierW8hzLGNtGhkiHjwKaY1 0SCGvdUcS+vqOKHFjJZkYoiHNtIl7d30SCJhXMext9Tb8U7raHOrIgtJDTrW4HUFM002tcx8BrwW PaeRKoDKZQX2teG5bIruJ+jYWcb/AOs2DKaYk7BcC0er9PazJ/VyRj9RJfS76JryW/TbPb1In4gr JxfrP1Dp1xxOpMNzWHbJ9tg7eGq6K9o6pjXCTWXQ+wDmp7dWXMjmCJkcpsdmL1fGbdm0MdnYbvSy QRxYyPc3+S76Q8lPjyADhmOL81k4ncaIz17D/ds1/khN+3sL92z/ADVo+nX+4PuH9yXp1/uN+4IX DsftW1Lu5/7ewv3LP81V8360YeNjPv8ATscWcNgCSfNa5qr/AHG/cEz6KHt2PqY5p0ILRH5EQcd6 xP2qqXd84zepdX+sFv6Q7MYHSsSGD7h7iuo+qFVuJtx6ySwulx81eu+r2G54dQBSB+YB7I8vBbXS On41DQWn3jtwVHzGWUhwgcMB0ZccQNbsuq2donmEk6SrMjyv1x65m9HycSxjPUw7Q5tzTpqCIIPj Hip9N6rg9TpFuK8OP59Z0c34ha/WsBudhupe0PaQZBXm2X0XP6Zl+vgONbmnQTEffyPirWGWOURE +iQ/S6FhyRkDY9Q7PewkuXb13rQaA51Mga6DlI9f6v8AvVfcE7gH70ftW2exepn8FP1T4AH96NdP kuS/5wdW8a/80JH6w9WGs1/5qXAP3o/aqz2L1N2VVj1G29zWVt1L3xp94XK9V+vjWOdV0xgs/wCH sGk/yGrn89/WOq5TvtbzsY727tGAeTQt76sYH1fbYRuFvUKyRFsCCP8ARt4KmjjxQFn9ZIdI7LZS menDbZHQKetdLx8rILqc2xgc+0Dkk/nNhXcb6tYdFLKg+x2wROg/CFrQUlGcstr0SIhzf2DifvP+ 8f3KTehYjdQ54PkR/ctBJN45d08I7NV3TaXN2l79PMf3KtX0KsXOdda66uQ5tRAH+cQNYWmnQ4pd 1EPMZX1qyuldXtx30Nsx2ENYNu1wYQDDDHC2undZ6Z1BhOHtZY6PUYGhr9BAnTWAhdbb0f7KXdVL W1AHaSYfP8juuIsxYcMnpzn+mfdVu0sA+IUojilEEjgO3F0K25g18wfSElyGH1zrbaGixzHOb3c0 T80b/nB1bxr/AM0JhgP34/auBP7pepSXK/8AOHq3jX/mhI/WLq3jX/mhDgH78ftVZ7H7HqXvZWxz 7HBjGiS46ABcl1n67uFn2bo/vfMOvg/+Bj+JWb1fJ6z1axtVtm3GHLQIBPcwOUfpnRQ0gUsLnHl8 a/LwRJxYxcjxyOwGyhGcjpoH0bpXUW5tDT+fAnx4SVboGA/Gql86+KSp3rdfRsOvyqOf0qjLafaA 5X0kFPKv+qcu9qYfVMhdWkkp5X/mmnH1TE68LqUklPLH6qe6R2XMfWD6sX4d5ycVx3E7iO4Pi0r1 BVc3Bqy2bXjVSYsssZuP1tbOAkKL510n63ZWK4Y/VGmxg09WPe0ef7y6VvW+kuAcMlkESOf7lT6t 9VA524Vh0cH/AHLK/Yd7dBXoFPLPilrwmJ61sxDHMbGw9F+2ulf9yWfj/cl+2ulf9yWfj/cud/Yu R/o0v2LkfuFD3MP9ZPBPuHo/2z0r/uSz8f7lkdb+uWHhA04P6xkEfS4Y2fHTVU/2LkfuFD/5uOdb 6jqQ5/idUY5cINkSPgg45nqA4Tm9T6vkfacyxxBOjncR4Mb2XU9D6WLhXTB2MG1s86K3076uW2OG 8QP9fJdVgdLpxGiANyizcxLJQrhiNgvx4xHXcuK76qA6hR/5pLqklCyPLf8ANNL/AJqBdSkkp5tv 1UrHK1cLpOPigQ0SFfSSUsABoEk6SSlJL5VSSU/VSS+VUklP1UkvlVJJT9VJL5VSSU/VLtse6I80 A/Y/5K+XUklP1D+pfyUv1L+Svl5JJT9Q/qX8lIfY5/NlfLySSn6oZ6ceyI8lJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp/9kKDQplbmRzdHJlYW0NZW5kb2JqDTU5IDAgb2JqPDwvU3Vi dHlwZS9JbWFnZS9MZW5ndGggNDk4L0ZpbHRlci9GbGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50 IDgvQ29sb3JTcGFjZSA2MSAwIFIvV2lkdGggNzUvSGVpZ2h0IDQ0L1R5cGUvWE9iamVjdD4+c3Ry ZWFtDQpIiazVB3LCMBQE0JmQ0DuhdzDYFAdTTTem9/sfJ9/61BCKkXSAN9qdHenjA4/BYPjE8wXH aDSa4JjNZovFarXZbHa7w+F0Ol0ut9vj8Xh9399+vz8QCAZDoVA4Eo3GYrH4c8iKkAMhkLzehCZp EEjhcFKT4vHUQbqAvhAy6YTS6UeQBSE7Qi6EfAgFEIoglEmns1m9JSWuSkqSkjIpgLIcm2wAcTk2 2Tguz/NssuVzvCCwycbzQqHIJpsgFEtlNlChVBbFF0ryXpUUxpLiWBKXI1DpR6xI9CVBth+xKkk1 FiWJ1YpUq9cpBwAladka9XqzSTkAkq1RA6gls8nWbLXljr7XjUDZiwEcsrVludN9bwA8DqCKUAug TrdHOYAz1Ou/XZKIJUE2hPoDygGQkroA9QcDygGcrjQYDikHcIRAUl4YwAvZAFJGurLdDuCQbaiM VPUJdJNNwmzydTZlrKoTygGcocn0wQD+ed1OJXUuSyLQbEY5AChpjNB8TjkAkm06BWi+eH/cl9kA WizZZFuAtHwl24MBEEi70nK1+gM9ed16d7Jp0vr59/ZwAGdovdb3uh1KUq5LIhBQdAMgEJE2G8oB nK602WwpB3CGtls22UDa7SgHcLzSDo6+1+1eNk3avzGAf7Jp0v5XgAEAUZi5wQoNCmVuZHN0cmVh bQ1lbmRvYmoNNjAgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAxMTYwL0ZpbHRlci9GbGF0 ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA2OSAwIFIvV2lkdGggMTc0L0hl aWdodCA1OS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSInsl9mWoyAQho+KGuNK1JhlYvL+TzkCBRRb YndPxsw58190R0T4LGsjiv7rX1CcEJJm+dYY67QjXIXG3e2TT4UvU0FL9jCQF+wqrTalCikhUjG/ FrCLPhG3VLBgXEWffqAz1JqWsOudvmy2ZnPVIFrmCqm+TLdmc5WYtMi00pE/SRYtNjXZbQ3nyKLF lx+YFZontO3WcI6snIBpPyfK8qqrS/bDyrfY1B+TwSqeqPYs/5u1DJu63JoSFANPUdp9AjJ1tzUl SLUCpIjsHqyTt5JtGbV2pgHN/jYDp2XXcd1Vm3cLhab1xH3bJUnGfFg4N9m41c1xTg1X10q5y6a4 Maatg9P0F9gH5/wFdZg2GPkVmrRlUVtHm6FJ2d/Es1R7aVlwJZ2uCLgGF5twChl+C1HWSri9DKkC z9qMNTLOB0TAoQycgpOS79LSAxM1Bw+W+mE8Pl9mGpgmw3H3NqzCfS8t0/CUd+RzxiXhauNyRygN Msiv2BNS/3ZyV7l08Hbg8X5aQxu1ElecZRKTVqQAPJi8h/ZweGJdTQtBlYgQq4ktdsTBnW72Ltph Fe3y9eMYoj92YLnrWtVhBe3g10nT6kH57DlIq6LMUJu6tNx1tSuwUBy1xFYDlToCLRVbnIz94Ldg o3rbixi5ho3rE8D+iswssOCqLjixuhpBe8FDnPZK6Q2/xo0DUuqlhVXYl6ZYypPP/NK0vbSsTcut WzVLeduLSJzVepPYeVIDkjbkvH7ak6I1Z9/HWRtA+q2QSrQOrd0n0rDffo92UJ5gz++pn1ZXBZfW wv3TtPCFzh5akdhs2hwlKQ+tibuCVvqtfESEHvbbm4rUmxi4R17a++zQQhQ1v5gYGEkejwfPBM3j 0S13i9amHS0ZtFT8N2nhd+BFeUpAMXa5i/HJphWwGIg8lj8PaWmGneq79ID2VvLSws7X+0vam71e NEN6tGkL52O7tLI0f4nW1DNaXyWjXlrRh/HSu1scoAzQ8iL8A1qzOjh353W0Jc+z/EzQqCjz0ab5 T2jvRzwxhHscnHGTVpiW4VXkKS2pMa1XiDYoMdPJCQdWpifPW5i0haLNXtAW62kdE8mdPfn2KKK/ n6Or/xlMSxTt/gUteQ+thKTR/Su09Sva+D20sOAIfnCSGTdMy1pBkXcVbf2UlloyaaceCFQHpk4z Li1QQoU5mS/hpeUn3px1Wq2kjWrIZ4q2Rat4g0fRRjMgDucJvi80VB6/hTe7jOYdLy2wNHhrGVAR nmH67QtaOxkNZ2Miyglq2nHU7hKklWcxjKuylUGbfIl2+cIqau7UmujRXR4iBiO1WbS5tFxRqRUZ fOnQGvnWcturh3Y+SZIJVaoQ7RSdfcP+yiusByJeGbXMK0k7cdv0eFPrFOmItTWXFbTq1PVCXbSa FpddlESHIG0vWDy4Tg+2DlcFXph2cGj703kee3zfQ9sPF+kp59NgafkeE/8xyf3zzMBqujruusz0 h0x1lEd7QSXWuPClJxgAf71C3KgNf6i86oTiFg9mSSpeICvDz/7Xh+i3AAMAYn70hAoNCmVuZHN0 cmVhbQ1lbmRvYmoNNjEgMCBvYmpbL0luZGV4ZWQgODggMCBSIDI1NSA3MyAwIFJdDWVuZG9iag02 MiAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIwMDkvRmlsdGVyL0RDVERlY29kZS9CaXRz UGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSA4OCAwIFIvV2lkdGggNTMvSGVpZ2h0IDEwMC9UeXBl L1hPYmplY3Q+PnN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEV DwwMDxUYExMVExMYFxIUFBQUEhcXGxweHBsXJCQnJyQkNTMzMzU7Ozs7Ozs7Ozs7AQ0LCw0ODRAO DhAUDg8OFBQQEREQFB0UFBUUFB0lGhcXFxcaJSAjHh4eIyAoKCUlKCgyMjAyMjs7Ozs7Ozs7Ozv/ wAARCABkADUDASIAAhEBAxEB/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEB AQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGB MgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NG J5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1 AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1Sj F2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oA DAMBAAIRAxEAPwDpP+cOb1fOuqxbji4dTi2s1xvfH55c4GJ5AHZSsqZ/huoXuPne8fkcuY6TjuzM yrAFjqWZNpbY9nO1rN0fgt636jYTSYy7SfMNSpBIG7K7G6e3HdkOy3Pa38wXvdYe2jGuJKp1u6fc /Yyy9piZsfbWNP5TiNUrPqfjMBIyHn4tasDqODbi5T6qbGPYzbq9pnUT+a4KSOHJLSItiyc1hxi5 SobPSMZjEB1WdewnsL3/AMHqT8jqeM0243U7nFvDbHeoPus3LjwMsCZq/wA13/klPHy8qu5jXbC2 07Tt3A8E93FGXL5YgmUdAthzeCZEYzsnwe1H14yndCfeKmftCu5uM46+n72vc23bP8giJ5SXKVf8 k5P/AIex/wDqchJRNhvfVo/5cwvK5/8A56K7vIdqVwf1c/5bw/8Ajnf+eyu5vOuqdDdhzGmnkGGH zXGdSO/Pyh4EafABdle87CJ08FyF14HU8jQe5xC0OV3+jkc9L0geLSbS9wJA05nsgvYG30ayfU5/ suV03E6EzBhU7T+no87P++uU/MfzU/Jr8nI/eMY/rNir/knJ/wDD2P8A9TkJJqj/AJJyf/D2P/1O R5pLGelbv1dP+WsT/jnf+e13Frw90E69iuG+r2vWsUDk3O/89rt7qLWmdspcVFizC2lkSA4H5Lh8 iz9ftdPL3flXaZD3jcC0/NcHkAuue6YlxMfNWsGYDcuNzg1ATusG5wHfVBe8HIogz75/6LkC97g+ IIB/FKp05FA5O/8A765WMmS8UvJZyeOs2OXiHRq/5Jyf/D2P/wBTkJJqv+SMn/w7j/8AU5CSzXoW 59Xv+WsT/jz/AOe16E9rtYMz4GF550AgdZxSToLzJ/62vQLLcfvYP84D+KrczIiqVw2172XbTGvx H9y5a7pzrCS+hpJ7gA/kgrp7snEY1xN7WgA/ngdvis5nVMFsTmNJ8C9h/KVV+8TEgAC1s3LRnu4V vTmkAei10CIkj8qy8rCZRdTYKX1O9WNTLYLXLtndf6QBtudRb/Wc0n8qxfrH1Lo2VjUVYbQy/wBd p9rgZAa+dJKv4s8pCj1a+PlIwyxkJ7HanDq/5Iydf+1uP/1OQkmq/wCR8n/w9j/9TkJKR0UmJZZT eL627zVYTt5GrI1WyX23sBcWNLtY5/is3pEetbPAMwDEw1WLOoYzXFlpqofyK33sDoPBhzmkT20S UyyOmuzG+gb2V7/ziBHj3cq2V9TftL6S/MqZ6BEbA0Tt8ff+KuAss9OKv0bi0OtbaHiC4AwGT4+K GcjAOTksDC5lFbnMaHmXHcGt185TQO6SdtKaeV9T6LLmOOaP0RPZrgdw8Q4eKHf9XK8bKrzmX7/T kemAANRBJO48KxZl4TenDJ9PdY+xzPpHa1rQPv1KXUn4ldldFDCHOY0lxcTJLdztPiihp1H/ACNk /wDh7H/6nISTVf8AImTr/wBrcf8A6nISRU2enmBk/A/i1XMbp2LXkdUuuwRnZmRaPsjXSWgGZe6D wBCDg0ux8jKovYTbU8sfXMElvtI+avjKyCZ+yWQI2tLtw9ug+m0pKTjpb+n0l9zGiuytszpID6N3 4rLbltObln0Kw4VO9L9HAJ3NjSdfvWll9R6jlCsOx7CQ5jn2OdMhjgdsaCPgqTXdU+05T3NeBdW5 rHg6gucHQNTGgQS0bMto6UNmOwuNrzZ7JMQ0DaOyn1G9j8hjGVMaz0xtc1uujPdLvip2ftb9migM eLfUc9zdwG4EADcZ8lLOuuuvabDtobWGkE92t2wGz4pIc6o/5Dyf/DuP/wBTkeaSNXRaPq/fkFp9 F+fS1r/EtZeXfduCSKntvrL/AM2vtX636n7Q2jd9kn1dv5vqfm/Dcubu+wz+rftCP+E9Dj8q8gSS U+qv+0/mfaP7Xp/wQnfa9J9b5bP4ry9JJT6i30JH2j7bHfZ6P/flcxP+Z/qN+2/tGJ93qbdn9r0P cvIkklP0z/kL9if4H9j+n5els/vn5z5pL5mSSU//2QoNCmVuZHN0cmVhbQ1lbmRvYmoNNjMgMCBv Ymo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCAyNzU5L0ZpbHRlci9EQ1REZWNvZGUvQml0c1BlckNv bXBvbmVudCA4L0NvbG9yU3BhY2UgODggMCBSL1dpZHRoIDEzNy9IZWlnaHQgNjEvVHlwZS9YT2Jq ZWN0Pj5zdHJlYW0NCv/Y/+AAEEpGSUYAAQEAAAEAAQAA/9sAQwAJBgcIBwYJCAcICgoJCw0WDw0M DA0bFBUQFiAdIiIgHR8fJCg0LCQmMScfHy09LTE1Nzo6OiMrP0Q/OEM0OTo3/9sAQwEKCgoNDA0a Dw8aNyUfJTc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3 /8AAEQgAPQCJAwEiAAIRAQMRAf/EABsAAAICAwEAAAAAAAAAAAAAAAUGAwQAAQcC/8QAPxAAAQMD AgQDBAgEAwkAAAAAAQIDBAAFEQYSEyExQSJRYRRCcZEHMlKBobHB0RUjM1M0YsJjZHODkpOi4fD/ xAAaAQADAQEBAQAAAAAAAAAAAAACAwQABQEG/8QALBEAAgICAAQFAwQDAAAAAAAAAQIAAwQREiEx QQUTFCJhUXGhFTKRwTOB0f/aAAwDAQACEQMRAD8A7hWUEvN89ldMaKkKeA8SldEfuaGN6gnpVla2 1jy24/GqExrGXiEjszqa24TG6hF7uC2VoisK2uLBUpf2Ujy9eYoC9eJjxyZSk+jfhqqt9a3VvOOq cWU4yo5p9eIQdtJL/EAy8KCW/aoofID2H8/W3eLNHrLcVSFORn1ZdbG4KPvJ/epENNGxAcNO0x95 GO+3OfjnnSehZ3pdDiwdm0gHGR616qi8EHtPHY4rKw57nQOKgK2lac+Wa9Zrn2Wf7bf/AEircW6y YiSI7mUnlsWcgfDyoGwjr2mMTxNd+5eUaptzjQvC8vLh6ITzUfuqgdQHPhhqKfVeD8sUuB7mpSlF S1c1KV1JrftA86auIoHPnEP4hYx9p1G2JeI0hYbO5pw9Er5Z+FEKQVPBScKwR60Ug6hXHjcF1sur T9VZV1Hr60qzEPVI+jxEHlZ/MaqygLGpmCD7QypCvdCTkGqkjUchajwUoaT2z4jShi2k61KGzqAN 73GmspTa1DLQocRTbg8inb+VXjqVrgeFhZf+x2+dY4to7TLn0N31DwrKARdRhTwRKYDaD76VE4+P IUeyPMfOlPW1Z0wj6r67RtDOYrkOrdcU/wAnSrKwfPA/9Ub09Z03RCpElagwlW0IScFRHXJ8qq65 itxJzchrw8ceNPbI7/l8qsaNv8SPHVClr4aisqQs9Dnt6dK69vE+OHqE+dxwlWYarz0+v4l597Tc R1UZUJlSkEpUrgg4I9TXi4Wa3vQFzLW8hrCd2N3gI8sdvlU83TNvuTzkmNKWhxwlSi2sKSSe/PNA brpy526M4tp3jxxzUlBIPxI71LX5RI0xB+Zff54DcVYZe2o4tnOn0n/dAf8AwpPsUB66upSnKY6c cRz9B606W9sO2aM2vOFxkpP3pFe40VqHDMeElKNgIT8fWkLcawwHUyqzGFzIzdAOn1gqRbbE1KjR ltNpdJ5JSMb/AC3ef30N1TbWYAbkw2ktNrO1aUjCQe3L/wC6UsTJkuPdFuSCr2lpzd4vMHIp8vIR ddMuPNZXlriox3UBVTVGhq23sGQpeuWlqcOiOn1i5YIYuc0NupJYTzcwfkPvpoGn7SXyRGRkJ5o9 3n3xQ/QUfbbXZJzueXjn5J6fnUumrh/Ebtd3QoltJbSj4eOl5JZncqeSx2EESqsMOb7P43InrNar fJW7PcSIx/pNKJPPvyq0zAsN0ZPsbLAI95lGxQ/AGlfXElf8cU0pWUobTtHlkc6h0fLcRf4zaFYS 7uSseY2k/mBTvSs1HmljvW5N69FyvThBw718y1Pt0qHcUwU5dU5zaI95Pmfh+lHUWW22yJ7RdlB5 fffzTnyAo85GZckNPqQC61naruMjH60D1XblXBTKfb48dCRnY8rGT51MLzaVVjod5YcVaA9iDZ7b 7SGKvTlzd9nbhtsuH6pDYQT8CKqToLmn5rMpDji4ZWASD4k/5T55qm1p5TTiXEXqAlSTkKC+YNMG o5sBVikIXJYcXw/AErBJXjl0pugtgFZJB6iI2z0s1wAZeYI1AC71x2iyUKW4tgN7sZUV5Hfyqx/B b9/dP/cqPQTTL8uQ642lS2wNhPPb16U85osi7yH4EH8wMLG9VULbGPxqKv0gQ1P21uSgZ4CjuwOx x+1BdN6aiXi0uvKfWmSFlIAIwnyyKf3m0PNLadSFIWMKSe4rn12tVx05KVKtrrvsx6LSM7fRXb76 2LaXq8kNwnt/ybPx1qv9SycSkaI+nzKa7Pf7c/w2WpXI8lM7ik/LlXQrYt9iytruykhxLeXSrHT1 9aR29b3ZCQkpjL9VIOfzobdL9cboNkh7+XnPDQMCqbMXIv0LNDXfvIqc7ExOJqeIk9j0nUH3wLW4 /GOE8ArbIHTw5FImkNQuR55ZnOqW1JVkqUc7Vnv8OnpUL94vsS0NR30luO4jYhxTZCinyz06fhS5 06UWNhAI6vogwc3xRjbW9ewV6g/M6LrWxImxF3COAH2UFS8e+gc/3rNAzfabU5EcOVMKwBj3T0/E GlRWp7mq3KgrdQW1IKCsp8RSe2c/pRPQDEtu7OKU26hnhHfuQQCe360myhq8ZksPTpKKctLs5LKV PMaaM90W3YNNLQwccNvhtnvuIwDQL6NTlVyP/C/11B9Ik5S5jMJJIS2jcr1zjH5VP9GnW5f8r/XQ eUVwWc9W0fzGG8P4ola9FBH4Mt6u009c5CZcEpL2AlaFHGR2NR6T0tIt8322ftC0AhtCTnBPfI9M /OqmqrxNteoVKiOlILacoPMHlQ6VrK7SGi2FNNZ5bm0EH8SaOunKekKrDhMC7JwKsprHU8YP+vvG u56lZg31iGpaeDj+crrtUeg/Kq+tLI7dWWZcEcVxtONoP1k9eXzpGjwptxU46w048RzWpKSat2+/ 3S1DgtOnYk/0nBkD9ab6I1lWpb3DrEfqgtVlyVPA3TXabhaausqQloxHGUk83HUlIHz61d1NpuNZ oTDqJalvKOChePF6jl2rT2tbs6jaOA36oQQfxNe7RZrhqCWmVc3HeB3WoYKvQdvvoyb1YWXMAo7D vEquK6mnGQsx7ntDf0fQlMW96SsY46htyOwz+9NefSo2WkMNJaaSEoQMJSOwr3muJfb5thf6z6jF oGPStY7TVYQCMEAj1rVZSpRB8ix2uQsrdhNKUe+OdeotmtsRYcjw2kLHRQHOr1ZTPNs1riOvvE+n qB4uEb+wkMyIxNjqYkthbahzBpSm6FSVlUOWUpzyQ4jOPvz+lOdZR05NtP7DF5GFRk/5F3ORSY79 nugQ6lJcYcSoZHJWDkfdTMrXrnB2t29CXcfWLmR8sfrTJebHEvCAJCdroGEup6j9x6Uvt6FaL21U 9ZA/2Q/eumMrFvUG4cx9/wCpwzgZ2K5XFPtP2/uLMeLOvs11aBxHVZUomren727p6RISqNxA5gLQ VbSCM454Pma6FbLbGtjHBiN7Unmonqo+prU20wJy98qK2tf2ikZ+dA3iFbkoy+yMTwe6sLaj6s/E 5xPkSNR3niNMFK3MJCAc4Ap3i6UtbTTYejhxxKQFEnko96JwrfEgpIiR22s9SlIBPxq1U1+aWAWr 2qJbieGKhay/TMfieGGGYzSWmG0toT0SkdKhl22FM/xUZp3H2hVmsqMMwOwec6RrQrwkcpRj2a2R nA4xCZQsdwKvjA6AAVqsrMzNzY7mStEGlGpusrVZmhhz/9kKDQplbmRzdHJlYW0NZW5kb2JqDTY0 IDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTcxNi9GaWx0ZXIvRENURGVjb2RlL0JpdHNQ ZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDg4IDAgUi9XaWR0aCA5Ni9IZWlnaHQgMzkvVHlwZS9Y T2JqZWN0Pj5zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8M DA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1Ozs7Ozs7Ozs7OwENCwsNDg0QDg4Q FA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCglJSgoMjIwMjI7Ozs7Ozs7Ozs7/8AA EQgAJwBgAwEiAAIRAQMRAf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEB AQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIG FJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieU pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEA AhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdk RVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwD AQACEQMRAD8A9Te9rGOe87WtBLiewC52vqXVuvZNlfSrPsOBS4tflloe+w+DWvHtRvrnlvxuivDN Dc4MPwgu/grH1WpZV0DCDPz6w9x8XO1KmjHhxe5VmUuGN6gVuWGUuPL7dkCMeKVaE3sLYO+r+QWy 3qWS27/SEzr/AFeFR6dk/WnH66em5Tm52I1oc7ILRWWtPB05PkunSTRlNEECVjqNvEFccQsEExo3 6Tv4EKSWNm/WSnEyrMd9Jd6Zgu3eU8QrVfUrLaBkVVNfSQXb/UgQOZlmihEokkA7Ng4cgAkY0JbF vpLjMj/GVhU3ekzEdaN0b2vgETE6tXU359dXp+1zvVEtgE/kBQGWBBIN8O9Anddl5bNi4fcjwcdm NkdG0qx6hhjMGCbR9pI3CuDMc8xCanqFVtgrILHHgGefmFn22dP/AOc1Vbsacw1S3J3HQQdNqfil DIJGNnhB20ojuCwZLhw7DiI36g9qdD9oY32t+JJ9Vjd5EaQP96sV2NsEt4BjUEa/Nc/jOJ+uOS08 Np0+YauiQibvzIWY5mQkT0lKP2Fx/rX023qPRbq6Buvqi2to7lvLfmJWT9ROu024Y6TkODMnHJFL XQC5hP0RP5zfBdcud6t9TumdQyTlY9jsPMaZLqCGjdzucAOfNWMeSBxnFkur4oyH6JWZMUxkGXHX FXDKJ04h/F3cgZBqcMZzW2n6LngkD5Ahcr1PrvWcHrGL0o5DHPyHV7nisaNe7b3+CtYeF9Y8c+iO qevUCW+rZWbCCOZf5KTfqvh3dRq6pn51mVlVub6Z3MawFp0aAB4nhKBxwJ4iJijXp69N1ZBkmBwg wNi/V067FpY12Pf9cOp4eSA+r0TuYe/83p4zqqmb9UeqvvdThZXo9JySHX1WO/SjbrEbYJ8PxWs7 oVNP1iu6rjZcZGUxwe14a5jNvpzqIIPELQGD1GwS3LrcD3DSR/1SpDFYPGP0iRXYurLnDCUThIr2 4RkJCxxRG4Hcd3ifrlhYHT+k9OxMGs1NGQ51m8y9zto9zz4n7vBd0/KuDacbGj1XMbqeB7ZkrK6x 9ULesNqblZW30XbmmtsEnzmVrZPS3WGuym01XMaG7hwYEdkzLjyAH2huYWAeEmI3APQrMmeGTHiE 5GU4+6ZE66yNjzad/wBqr6hjNyLW2PLmn2iIEqhbY7/xwaq59oxpjzhy1f2Q2uyvKuyXusY4F7nn Q66AKD+mYDuuDrv2k+pXVscyQaw2OTp4HxT+QhLF94OQV7pkYji494xGpPk1OZ/We1wm+AxJ0rYl qYZH/PTLH/BD/qWLpFmY/S8YdZv6pXcX22NDLKpENkNjzGgWmpIgi77kseKBiJA9Zzl9CVKhkYTb shz6sh1dhLPVa10Q0eQ8R4r5kSTmR+nDhVPosY3Ic3Hc573FjgIku3t3eEkodmHhl1zzeN9gDbW7 mgSNu3+qdBqvmdJJT9I4+JS9wdZc2tzSCxoc3dMM0dqdw9rY8itar0/Tb6e3ZA27Y2x2iF8sJJKf qpJfKqSSn6lya67KSyx2xpLTu0GocCOfNVq8XFFNzG3TW9m2wy3Qbdsz20XzGkkp+ocfHoryLrK7 C+x5/StLgYMkjTtoYVlfKqSSn//ZCg0KZW5kc3RyZWFtDWVuZG9iag02NSAwIG9iajw8L1N1YnR5 cGUvSW1hZ2UvTGVuZ3RoIDE0NDQvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQg OC9Db2xvclNwYWNlIDY3IDAgUi9XaWR0aCAxMDUvSGVpZ2h0IDcxL1R5cGUvWE9iamVjdD4+c3Ry ZWFtDQpIibxXi3/TVBQ+wFiTmza96TK20LRdm0YIk23QYde1unXD4UAUpYoy5lSmFt8IvhCrovio ijoQ/XO9Sdrs3rya1pXT3/dbe1/nfPe795w7gGi2j2A/HIARONjBARjttO+djUCM45EQT4hJLOGU haSYiI8hmYvB+B54OAQTk0g5nMJpVVUDgPFhBXETZOygNg6yqGbIWtGQzcFU3z72QR4pgRwCoSYL Wl/MJoupqDw8kIqTEb3EdNw/FxZ6vqeXx0AcmAuNbKheR8ZlTMb5ffrhkz5qkL8YkXvnb+OIxHLM 0zz9+HHcBxdjZhZg7oRBvqOTvn44yYyn5GqdP/XESTkVmU95oWLPW6zW0mrqSR8/RTsmF6P5p2JK dD4nlqipywZpU9xu6t2772Zk7UIkPrXlCjNxpWS2Y45dzonLqxHMLqz25JIuVdlJp8vdPrpV2I3L YvT02pln1pnojqU9Z4v6njlL7xmxc6vUWP1ZLx9To/PPPT96AanohRfPU1MryxdZDqUla08zaqax wO7Z4ozB8u12yHSsqy+9fIkTre/iK69eZnajlKHiJNQ3rmySLXiNJbPhoymyu7YY/wUFO9/x62+8 ycS6bFzt9tmnpjpLdV8+tf1WOe2nodVdDD1L+G024mqj0+c5nvPbo+8ErZUk/fle9yOzepper2l0 NGK8TF979736+8Hr1GGfEOGONM5Ray5kuhpRm3bmg5wUms+PQLR7bywvdlSqMRo5jBZq4WvAVNSc bDQXK9Wju+fOo1G1HDZ/AkLjYJA26N+NDz9y2drHIfMhNnAdRfX6pMaiGDw+D6E8jOtzK0tzSww+ ofob1yPkQVujURwad/bGzfMuLT7tnlOjtGL+Xil58qAX6mcg9Iil+PkXTCKCddnO17tVoXKl0YuT DhrqqYf45TTt6FonN9L1p1K9Fb4G0kD5KjyWzZlFduvW5U5fk2neaF4NXicbB001KQXFki4vuK8L XMt1+w22plZud/OgalxZZdZBaQ1UPBZ45ppLHjeORhZq19lSZNfVMqm2X2NqLQGroBENWr58aq56 RrLcN9+uTzsadTgf/26NPiwbTfuFso13x+hJVdXMe6To3tx2bMXlhdQiUr1bN+7ckV1jv//h7vy0 azT8uJtDE0XzHmmmz2KB5dO4Pet2c7ZbN5Wfxjz8f/5l7abL1bZzPwUrX2h2rhPbqhNjpuQmY97J HjVr89ffbroY2X1qLmnnOs32i3nF9l+b+d3lpVJd7Z370rdOs7M6GiX5jlaak+ta96wYyq73WeX2 xfB7ZuJqc8NXI4ycvGNrZEGSkfW/xCY1aaMZIY+l03/8uXbX9fmLMBlrS84Yja5HWV4w4zCaHZHm yPsqUm5O7Eze5+6zwDpP55yuRh0osmztaY34qh7tzSUQWJYVpk1z1yMs88Ut8xz1OGdhUBVefuCu R5o3Hp3PJfDgXBI5Xt/ytGu+b4ZUsd0uuGOKAlyQ23HJr8+l0S6wKO/stA6H118aWNR3eFnEAf0e jRgoQpuXhXg2/O2Hs4lWjucRUT94HOR7xfogGUdtjudlJCTELFW7smJCQDLPczJKJB/04uyvkRdb KpaS8THE8zs8Z4FHhXhSwmq0+SpcGvyu9IUpyA5+X/oABsg9Cj7m/3wXws7KnmGCpM7CI9CoZSXp 1ND5YLsaTOIh88FOfRuyRo6fv+VhcsJolCrxeGh8MDAWk4bER8rvdz1bWkPho7tfR8QeZvecj1T3 8UNMDq87/WIrd9Dfj+Vqz/hgFOjFtHEQ94RPFqZC/QAcgrz+v/kU82SdKMYpg98rnNyJ5MO2I/BQ yA7ARRLqZG6/dgFauA8uWzqZMagdghgviCRrhPMQW3x+PJoq4fYPcDmkk9cWpjhgSUzohXscTAyw W2H2LxyAEbjkfEbI7z48/CfAAElTqz4KDQplbmRzdHJlYW0NZW5kb2JqDTY2IDAgb2JqPDwvU3Vi dHlwZS9JbWFnZS9MZW5ndGggMTgwL0ZpbHRlci9GbGF0ZURlY29kZS9JbWFnZU1hc2sgdHJ1ZS9C aXRzUGVyQ29tcG9uZW50IDEvV2lkdGggMTA1L0hlaWdodCA3MS9UeXBlL1hPYmplY3Q+PnN0cmVh bQ0KSInskyESwjAQRRc6TGUlEs8lws2I5hSVTC5Bj4DgAJXICgSCybJps+nuMlQjWJU3f36++R+A 7hTOHvg2iHhlWGO6NtN2pIeUWKwzDSO5TDHB6pgJD0QNA96JdoVewjYZiw2RPpkBO0O1oKeiQQSk CE1OUJRxFCgB/V/7RW2JnIC40ALbl0Zp31vXm36a7s7fpF5X0mb2ABe2+c8d6Y3p/WWxl7u9lRXD PoTp8RZgACXsB4kKDQplbmRzdHJlYW0NZW5kb2JqDTY3IDAgb2JqWy9JbmRleGVkIDg4IDAgUiAx NTIgNzIgMCBSXQ1lbmRvYmoNNjggMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlw dG9yIDcxIDAgUi9MYXN0Q2hhciA4My9XaWR0aHNbNTkyIDU5MiAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA1NDddL0Jhc2VGb250L0FyaWFsTmFycm93LUJvbGQvRmlyc3RDaGFyIDY2L0Vu Y29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNNjkgMCBvYmpbL0luZGV4 ZWQgODggMCBSIDI1NSA3MCAwIFJdDWVuZG9iag03MCAwIG9iajw8L0xlbmd0aCAxMjUvRmlsdGVy L0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJYmBg+P///4mj36KCnypL3jFUv9dS9/rjx79rVnzycnyU kfj88aPfu7Z/mTfrQ1nBy2tXfkzsefv94P6HbIyPxQRfujh+aGr4eeH8l4Xz3xUX/n5w/9Ok/m8b 15849u1NSuLf9++fqipO7HnHMApGwWAFAAEGAJ/1QSgKDQplbmRzdHJlYW0NZW5kb2JqDTcxIDAg b2JqPDwvU3RlbVYgMTEyL0ZvbnROYW1lL0FyaWFsTmFycm93LUJvbGQvRm9udFN0cmV0Y2gvQ29u ZGVuc2VkL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJveFstMTM3 IC0zMDcgMTAwMCAxMTA5XS9Bc2NlbnQgOTM1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCA3 MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2Jq DTcyIDAgb2JqPDwvTGVuZ3RoIDMzNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIkUjxG0 BiEQhX9cXFwNF8M0DMM0DMM0DMM0DMPRMAxHwzDc17vn3HMGZr575/u+3+93XfdNyEPZQ+kZqVRM W26ccEH6qEKWIetUVSqmNJ1BFxA+cusJZef4FZJpo2JRqdraTe0Whs5VnAXGqdTCRaq0ioeTCOXX dcWGDkYec+/dxgi1VVzr+3Dv3JEwljoCgDGGkDd2bHPt7zvuc3kYzFjO+dwf4GLK4NrhUNaec3rv KaVCylprHthw3c+z1so5CyFeLqSxKefQ0LfhQniOXqp8jLkg4ilUcTroYy5Tm8kQC+CcFrqUsiFG 6IdexiylMMYeQkyuD3lTKeGoQB0T5hLapJRqhfshXGnnvfUhtqHTP844J306PaTS2tgYoz9ZPjjn lFJMaQ/dp8yty637ENbewvkyMFV435ef97U1Be77ocq8XP6u+0+AAQB1F/TCCg0KZW5kc3RyZWFt DWVuZG9iag03MyAwIG9iajw8L0xlbmd0aCAyNTUvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJYmBg+P///4St2f1bs/q3ZPVtyezbnNm7OaN3U3rPpvTuTWndG1O7gGhDSueG5I71SR3rE9vX JbSBUHzr2riWtbHNa2KaVkc3ro5qWBXZsCqifmV43Yqw2hWhrWvj61dG1CwPqVkeXLsipHpZUNXS wMqlAVVLAyqX+lcs8atY4lu+GIh8yhb7lC72LlvsXbrIq3SRZ+lir5KFHsULPUoWeRYvdC9a6Fa4 wLVogVvBfJeC+c4F853y5znmzXPInWufM9cuZ65tzhybnDm22XNssudYZ8+xypptlTnbMnO2RcYs 84xZZukgZJo+0yRtpjHDKBgFqAAgwACxrnFLCg0KZW5kc3RyZWFtDWVuZG9iag03NCAwIG9ialsv SW5kZXhlZCA4OCAwIFIgMjU1IDM4IDAgUl0NZW5kb2JqDTc1IDAgb2JqWy9JbmRleGVkIDg4IDAg UiAyNTUgNDAgMCBSXQ1lbmRvYmoNNzYgMCBvYmpbL0luZGV4ZWQgODggMCBSIDI1NSA0MiAwIFJd DWVuZG9iag03NyAwIG9ialsvSW5kZXhlZCA4OCAwIFIgMjU1IDQ1IDAgUl0NZW5kb2JqDTc4IDAg b2JqPDwvTnVtc1swIDc5IDAgUl0+Pg1lbmRvYmoNNzkgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNODAg MCBvYmo8PC9Db3VudCA4L1R5cGUvUGFnZXMvS2lkc1s4NSAwIFIgMSAwIFIgNCAwIFIgNyAwIFIg MTkgMCBSIDI4IDAgUiAzNSAwIFIgNTAgMCBSXT4+DWVuZG9iag04MSAwIG9iajw8L1N1YnR5cGUv WE1ML0xlbmd0aCAzNTcyL1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLv u78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJh ZG9iZTpuczptZXRhLyIgeDp4bXB0az0iMy4xLTcwMSI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBkZj0iaHR0cDovL25z LmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxwZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0 aWxsZXIgNy4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6 eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpDcmVhdGVE YXRlPjIwMTItMDMtMjdUMTU6Mzg6NTkrMDg6MDA8L3hhcDpDcmVhdGVEYXRlPgogICAgICAgICA8 eGFwOkNyZWF0b3JUb29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMjwveGFwOkNyZWF0b3JUb29s PgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+MjAxMi0wMy0yN1QxNTozODo1OSswODowMDwveGFw Ok1vZGlmeURhdGU+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2Rj L2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6 Zm9ybWF0PgogICAgICAgICA8ZGM6dGl0bGU+CiAgICAgICAgICAgIDxyZGY6QWx0PgogICAgICAg ICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPk1pY3Jvc29mdCBQb3dlclBvaW50 IC0gZHJhZnQtY2hlbi1wY3AtbW9iaWxlLWRlcGxveW1lbnQtMDAucHB0PC9yZGY6bGk+CiAgICAg ICAgICAgIDwvcmRmOkFsdD4KICAgICAgICAgPC9kYzp0aXRsZT4KICAgICAgICAgPGRjOmNyZWF0 b3I+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpPkNoZW5HYW5n PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgog ICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9 IiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9t bS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjMyZDg3NDA5LTliMmItNGQxMi04 NjhmLTM4MWQ3NGI3ZDA4NjwveGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3Rh bmNlSUQ+dXVpZDplOGQyZmRkYy1hNGQ1LTRjODEtOTI5MC01ZTAxYzhkZDgwOGI8L3hhcE1NOklu c3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBt ZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg Cjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNODIgMCBvYmo8PC9DcmVhdGlv bkRhdGUoRDoyMDEyMDMyNzE1Mzg1OSswOCcwMCcpL0F1dGhvcihDaGVuR2FuZykvQ3JlYXRvcihQ U2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDcuMCBc KFdpbmRvd3NcKSkvTW9kRGF0ZShEOjIwMTIwMzI3MTUzODU5KzA4JzAwJykvVGl0bGUoTWljcm9z b2Z0IFBvd2VyUG9pbnQgLSBkcmFmdC1jaGVuLXBjcC1tb2JpbGUtZGVwbG95bWVudC0wMC5wcHQp Pj4NZW5kb2JqDXhyZWYNCjAgODMNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwNTkwMyAwMDAw MCBuDQowMDAwMDA2MDM2IDAwMDAwIG4NCjAwMDAwMDYxNDUgMDAwMDAgbg0KMDAwMDAwNjcyMCAw MDAwMCBuDQowMDAwMDA2ODUzIDAwMDAwIG4NCjAwMDAwMDY5NjIgMDAwMDAgbg0KMDAwMDAwNzU4 MCAwMDAwMCBuDQowMDAwMDA3NzEzIDAwMDAwIG4NCjAwMDAwMDc5NTQgMDAwMDAgbg0KMDAwMDAx NjE3NSAwMDAwMCBuDQowMDAwMDE2MzI1IDAwMDAwIG4NCjAwMDAwMTgxNTkgMDAwMDAgbg0KMDAw MDAxODMwNiAwMDAwMCBuDQowMDAwMDE5MTU4IDAwMDAwIG4NCjAwMDAwMjA3MzYgMDAwMDAgbg0K MDAwMDAyMjE3NyAwMDAwMCBuDQowMDAwMDIzMzIyIDAwMDAwIG4NCjAwMDAwMjQ0OTYgMDAwMDAg bg0KMDAwMDAyNTczNCAwMDAwMCBuDQowMDAwMDI1ODcwIDAwMDAwIG4NCjAwMDAwMjYwMzkgMDAw MDAgbg0KMDAwMDAyNzk0MSAwMDAwMCBuDQowMDAwMDI4NDEyIDAwMDAwIG4NCjAwMDAwMzcwMTkg MDAwMDAgbg0KMDAwMDA1OTk5NyAwMDAwMCBuDQowMDAwMDYwMjMyIDAwMDAwIG4NCjAwMDAwNjA1 MTggMDAwMDAgbg0KMDAwMDA2MDkwMCAwMDAwMCBuDQowMDAwMDYxMDM2IDAwMDAwIG4NCjAwMDAw NjE0MTYgMDAwMDAgbg0KMDAwMDA2ODQyMyAwMDAwMCBuDQowMDAwMDY4ODU2IDAwMDAwIG4NCjAw MDAwODA3MjYgMDAwMDAgbg0KMDAwMDA4MTA1MCAwMDAwMCBuDQowMDAwMDg0ODg3IDAwMDAwIG4N CjAwMDAwODUwMjMgMDAwMDAgbg0KMDAwMDA4NTUwMSAwMDAwMCBuDQowMDAwMDkzNTA3IDAwMDAw IG4NCjAwMDAwOTM5MDUgMDAwMDAgbg0KMDAwMDA5NDQ0NCAwMDAwMCBuDQowMDAwMDk0OTEyIDAw MDAwIG4NCjAwMDAwOTU0NjQgMDAwMDAgbg0KMDAwMDA5NTk2MyAwMDAwMCBuDQowMDAwMDk2NTI2 IDAwMDAwIG4NCjAwMDAwOTY5NTggMDAwMDAgbg0KMDAwMDA5NzM1OSAwMDAwMCBuDQowMDAwMDk3 ODkzIDAwMDAwIG4NCjAwMDAxMDk4MzUgMDAwMDAgbg0KMDAwMDExMDE1OSAwMDAwMCBuDQowMDAw MTEzODg4IDAwMDAwIG4NCjAwMDAxMTQwMjQgMDAwMDAgbg0KMDAwMDExNDEzNCAwMDAwMCBuDQow MDAwMTE0NDQ1IDAwMDAwIG4NCjAwMDAxMTQ0ODkgMDAwMDAgbg0KMDAwMDExNDUzMyAwMDAwMCBu DQowMDAwMTE0NjYxIDAwMDAwIG4NCjAwMDAxMTk5NzcgMDAwMDAgbg0KMDAwMDEyMTk1NiAwMDAw MCBuDQowMDAwMTI3MzgxIDAwMDAwIG4NCjAwMDAxMjgwMzEgMDAwMDAgbg0KMDAwMDEyOTM0NSAw MDAwMCBuDQowMDAwMTI5Mzg5IDAwMDAwIG4NCjAwMDAxMzE1NTAgMDAwMDAgbg0KMDAwMDEzNDQ2 MSAwMDAwMCBuDQowMDAwMTM2MzI4IDAwMDAwIG4NCjAwMDAxMzc5MjYgMDAwMDAgbg0KMDAwMDEz ODI1NiAwMDAwMCBuDQowMDAwMTM4MzAwIDAwMDAwIG4NCjAwMDAxMzg0OTUgMDAwMDAgbg0KMDAw MDEzODUzOSAwMDAwMCBuDQowMDAwMTM4NzMzIDAwMDAwIG4NCjAwMDAxMzg5NjcgMDAwMDAgbg0K MDAwMDEzOTM3MyAwMDAwMCBuDQowMDAwMTM5Njk3IDAwMDAwIG4NCjAwMDAxMzk3NDEgMDAwMDAg bg0KMDAwMDEzOTc4NSAwMDAwMCBuDQowMDAwMTM5ODI5IDAwMDAwIG4NCjAwMDAxMzk4NzMgMDAw MDAgbg0KMDAwMDEzOTkwOCAwMDAwMCBuDQowMDAwMTM5OTMyIDAwMDAwIG4NCjAwMDAxNDAwMzAg MDAwMDAgbg0KMDAwMDE0MzY3OSAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDgzPj4NCnN0YXJ0 eHJlZg0KMTE2DQolJUVPRg0K --0016e6d6257454797a04bc3ba4e7-- From mohamed.boucadair@orange.com Wed Mar 28 00:27:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349F221F8608 for ; Wed, 28 Mar 2012 00:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.051, 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 ZZiOhSzYbYDA for ; Wed, 28 Mar 2012 00:27:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ED4EF21F852E for ; Wed, 28 Mar 2012 00:27:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B2A1A2DC390; Wed, 28 Mar 2012 09:27:53 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 98F25238048; Wed, 28 Mar 2012 09:27:53 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 28 Mar 2012 09:27:53 +0200 From: To: GangChen , "pcp@ietf.org" Date: Wed, 28 Mar 2012 09:27:51 +0200 Thread-Topic: [pcp] Is it the right place to document something for PCP in mobile network Thread-Index: Ac0MM0TLBcelj5DmREiejveaWPFymgAfm6Yg Message-ID: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.28.51226 Subject: Re: [pcp] Is it the right place to document something for PCP in mobile network X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:27:57 -0000 Hi Gang, all, I do personally think it is valuable to have this document as Informational= .=20 As mentioned by Gang, we have tried in the past to initiate a study item wi= thin 3GPP but this was not successful because there is (surprisingly) no fu= nction to be controlled by PCP (!!!) Since we are aware there are plenty functions (e.g., NAT) which may benefit= from the help of PCP to achieve goals such as better application experienc= e, better battery utilization, etc, a document dealing with some of mobile = considerations is needed. Having a document covering PCP-related considerations in mobile networks wo= uld provide a pointer for operators to be included in their UE profile requ= irements. Of course, the document need restrict the scope to major issues (= e.g., PCP Server Discovery). Cheers, Med =20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de GangChen >Envoy=E9 : mardi 27 mars 2012 18:04 >=C0 : pcp@ietf.org >Objet : [pcp] Is it the right place to document something for=20 >PCP in mobile network > >Hello all, > >Thanks for your attention on today meeting for >http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-00 > >Chairman encourages me to launch this thread due to limited times on >the meeting. >As I already stated in slides (see attached), PCP in mobile network is >attempted to be a work item in 3GPP. But it failed because 3GPP >thought NAT and Firewalls are going beyond their scope. > >Considering very particular environments of mobile network and goals >of PCP technology, it's of necessity to document something either to >encourage PCP deployment in mobile network or raise specific concerns >from mobile network part. > >If there are no such considerations, I guess operators may struggle >with transplanting PCP into mobile context. >Very typical case is when doing PCP discovery, DHCP may not possible >because lacking of supporting in 3GPP network. > >That motivates us to raise the question here. Otherwise, it likely >would become grey zone. > >BRs > >Gang >= From fred@cisco.com Wed Mar 28 01:35:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C111721F88EE for ; Wed, 28 Mar 2012 01:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Twwhd7YfI-r4 for ; Wed, 28 Mar 2012 01:35:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEFA21F88D8 for ; Wed, 28 Mar 2012 01:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2478; q=dns/txt; s=iport; t=1332923733; x=1334133333; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2fXGv9IWJ7FL3m4ZsVJfNlLCeLWb4fs8UFaGfKGhzkg=; b=FMdgsGmQR2K3hwYT2ARqjEJzhM8Fo+ko/K0QHw84Kky2Ivoshkq0urDv Raiz54fnzgYWvWmeiTUr+edNelaXjpTkfqAVEG/9EEfZG+Eq5t3tMS+R8 61aKbTLhsFQ9HSVgjFzJ+YNWUW68LTaVAwY3z7u5SWPyjqY9rWu9XLrB6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM7Mck+Q/khM/2dsb2JhbABFuG2BB4IJAQEBAwESASc/BQsLRlcGNYdjBZsznxKQL2MElWGFb4hWgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="69516370" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2012 08:35:29 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-55-92-161.cisco.com [10.55.92.161]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S8ZSCc031944; Wed, 28 Mar 2012 08:35:29 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Wed, 28 Mar 2012 10:35:29 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Wed, 28 Mar 2012 10:35:29 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 28 Mar 2012 10:35:17 +0200 Message-Id: References: To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org Subject: Re: [pcp] You asked about multicast scope X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:35:34 -0000 On Mar 27, 2012, at 4:04 PM, Iljitsch van Beijnum wrote: > The issue is that if there are layers of indirection, a low scope = value such as this may prevent the packets from being flooded all the = way to the most distant NATs: think ISP-run CGN or NAT64. Or even the = edge of a large organization. >=20 > So I think the scope needs to be bigger than this. On the other hand, = we don't want these packets to travel _too_ far. which brings us back to link-local, admin-local, site-local, and = organization-local. What I chose yesterday without referring to the = draft was admin-local, and back when I was thinking about what the draft = should say I picked organization-local. Let me give you my mental picture of those terms, in view of Cisco. = Cisco has, I'm told, 206 buildings world-wide for engineering, plus = sales offices in any city of a million people or more. Those tend to be = organized into campuses, which in San Jose is buildings A-P, plus = buildings 1..30, plus a few others, but in most cases is on the order of = 1..10 buildings or as many floors in a single building. In Germany, we = have 11 campuses and a total of (this morning) 1145 people; the Munich = office is two floors containing ten people. I think of "Cisco" as an = "Organization", the various campuses as "sites", and the various = buildings as "admin-local". I don't know if Cisco IT has the same = viewpoint, but that's my mental picture. If I were to deploy this in Cisco, I would expect a multicast to = ALL-NPT-TRANSLATORS needs to go as far as the nearest DMZ at least, and = maybe the nearest two DMZs. We have ~30 DMZs world-wide. That brings me = somewhere in the neighborhood of site-local to organization-local. Now, I suspect that the thought going through your mind is something = along the lines of "yes, but Cisco..." OK, so let's decapitate the problem. If the subject of discussion is a = Fortune 5000 company, I would expect it has an IT department, has some = concept of multicast zones and how it wants to use them, and little fear = of configuring things. The conversation about "zero configuration" and = "default scope" is about everyone else - and in such institutions I = suspect that admin-local, site-local, and organization-local are the = same or very similar. Which means we can pick anything except link-local = (too narrow) and global (too wide) as a default and we won't be far = wrong. site-local?= From phdgang@gmail.com Wed Mar 28 02:10:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A5821F8996 for ; Wed, 28 Mar 2012 02:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 7fqnXLwSV3lX for ; Wed, 28 Mar 2012 02:10:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C939521F8997 for ; Wed, 28 Mar 2012 02:10:00 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so510923wgb.13 for ; Wed, 28 Mar 2012 02:10:00 -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=oaY98RqwgQR20insc7FIS72RP/QlZ1xgcCaP3CSEGkw=; b=SHtSOpk/ZdDy/HMw887fyxvp6IL83WDbCar7zDZ0b0xDtUqhVLexdJbU4axCXXAzTG vsxpdTfD8VCT9qurav0Ln4XKw5RSgsfS5ElbrNAHUUkgDNgQ6dNiRJ35wHjbAAfhwBkg zIl5yEFOKY5DLLFNdILfhSk2zHQRBBJ8LAzH0osrsFAvPkeVJ0Hu881Mgr+KbpKuhVER 0H/X5+2wj03MIrqe88NiirHBiG5Ucg3IA9DAmOabK/pzrQq2FZMO4VaWFjnZmN6yEBXR 35ZyRL4dNYCVDrZOwe7nUtR44/C8y3bdths/9AS5Zwo0/OfzXgMRaQA1HiW1qpyv4IIn 2o8g== MIME-Version: 1.0 Received: by 10.180.107.101 with SMTP id hb5mr6099715wib.3.1332925799986; Wed, 28 Mar 2012 02:09:59 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Wed, 28 Mar 2012 02:09:59 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 28 Mar 2012 17:09:59 +0800 Message-ID: From: GangChen To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pcp@ietf.org" Subject: Re: [pcp] Is it the right place to document something for PCP in mobile network X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:10:02 -0000 > Of course, the document need restrict the scope to major > issues (e.g., PCP Server Discovery). Fully agree Gang 2012/3/28, mohamed.boucadair@orange.com : > Hi Gang, all, > > I do personally think it is valuable to have this document as Information= al. > > As mentioned by Gang, we have tried in the past to initiate a study item > within 3GPP but this was not successful because there is (surprisingly) n= o > function to be controlled by PCP (!!!) > > Since we are aware there are plenty functions (e.g., NAT) which may benef= it > from the help of PCP to achieve goals such as better application experien= ce, > better battery utilization, etc, a document dealing with some of mobile > considerations is needed. > > Having a document covering PCP-related considerations in mobile networks > would provide a pointer for operators to be included in their UE profile > requirements. Of course, the document need restrict the scope to major > issues (e.g., PCP Server Discovery). > > Cheers, > Med > >>-----Message d'origine----- >>De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >>part de GangChen >>Envoy=E9 : mardi 27 mars 2012 18:04 >>=C0 : pcp@ietf.org >>Objet : [pcp] Is it the right place to document something for >>PCP in mobile network >> >>Hello all, >> >>Thanks for your attention on today meeting for >>http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-00 >> >>Chairman encourages me to launch this thread due to limited times on >>the meeting. >>As I already stated in slides (see attached), PCP in mobile network is >>attempted to be a work item in 3GPP. But it failed because 3GPP >>thought NAT and Firewalls are going beyond their scope. >> >>Considering very particular environments of mobile network and goals >>of PCP technology, it's of necessity to document something either to >>encourage PCP deployment in mobile network or raise specific concerns >>from mobile network part. >> >>If there are no such considerations, I guess operators may struggle >>with transplanting PCP into mobile context. >>Very typical case is when doing PCP discovery, DHCP may not possible >>because lacking of supporting in 3GPP network. >> >>That motivates us to raise the question here. Otherwise, it likely >>would become grey zone. >> >>BRs >> >>Gang >> From fred@cisco.com Wed Mar 28 05:01:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED65221F885F for ; Wed, 28 Mar 2012 05:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.833 X-Spam-Level: X-Spam-Status: No, score=-109.833 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8, 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 sGvdwwzVygYy for ; Wed, 28 Mar 2012 05:01:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF2D21E811B for ; Wed, 28 Mar 2012 05:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=692; q=dns/txt; s=iport; t=1332936074; x=1334145674; h=in-reply-to:subject:cc:mime-version:date:message-id:to: from:references:content-transfer-encoding; bh=n6VwfGAIVeiwCAmwrGlKMn/HhA/dNvfF9D1cjEG44sY=; b=CCV8Gc0Wj1my3AMeZpLHFjedBzW/ab887gaZaxmfBiiIHHtDrEslDORi xoxJ1bIxMBnTo7Y+OgWD06PML1d0vM+ZW8Qhg3JxnpG8kNgJt+KSa0rET JyeD+0uAzHOLGHBI6uFJTBucsB0+fz2JKWA2SB9unV9RCKzv2EKpAJcdR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACT9ck+Q/khR/2dsb2JhbABFt3J7gQeCAAoBAQQSASc/EAsDAUJXBjWHaJtYnxyQL2MElWGFb4hWgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208,217";a="133594761" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2012 12:01:10 +0000 Received: from dhcp-40d8.meeting.ietf.org (dhcp-10-55-90-141.cisco.com [10.55.90.141]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SC0Prb011697; Wed, 28 Mar 2012 12:01:10 GMT Received: from [127.0.0.1] by dhcp-40d8.meeting.ietf.org (PGP Universal service); Wed, 28 Mar 2012 14:01:10 +0200 X-PGP-Universal: processed; by dhcp-40d8.meeting.ietf.org on Wed, 28 Mar 2012 14:01:10 +0200 X-Apple-Mail-Remote-Attachments: YES In-Reply-To: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> X-Apple-Mail-Signature: SKIP_SIGNATURE X-Uniform-Type-Identifier: com.apple.mail-draft Mime-Version: 1.0 (Apple Message framework v1084) X-Apple-Base-Url: x-msg://80/ Date: Wed, 28 Mar 2012 12:08:47 +0200 Message-Id: <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> To: Iljitsch van Beijnum X-Apple-Auto-Saved: 1 From: Fred Baker References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> X-Apple-Mail-Plain-Text-Draft: yes X-Apple-Windows-Friendly: 1 X-Mailer: Apple Mail (2.1084) Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] You asked about multicast scope X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:01:15 -0000
On Mar 28, 2012, at 10:43 AM, Iljitsch van Beijnum wrote:
I haven't read the spec yet, but isn't PCP supposed to work in the service provider run NAT64/CGN case, too? In that case, the multicasts need to escape out of the site or even organization to reach the service provider at least in the SOHO case. So this would be a scope just shy of global, maybe a new "service provider" scope?

I personally rarely use "zero configuration" and "service provider" in the same sentence... From mbakshi@juniper.net Wed Mar 28 14:25:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70D421F860E for ; Wed, 28 Mar 2012 14:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=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 gWLmaE+VdN79 for ; Wed, 28 Mar 2012 14:25:32 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53921F860B for ; Wed, 28 Mar 2012 14:25:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT3OByup3lreRopUGYUnIlY+x6IjtIQsz@postini.com; Wed, 28 Mar 2012 14:25:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 28 Mar 2012 14:23:24 -0700 From: Mayuresh Bakshi To: "pcp@ietf.org" Date: Wed, 28 Mar 2012 14:23:17 -0700 Thread-Topic: race condition between prefer-failure and map update Thread-Index: Ac0NKQGq/MLev/q9T3eZv3RH1VnF1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] race condition between prefer-failure and map update X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:25:33 -0000 I am trying to interpret below in section 13.2: There can exist a race condition between the MAP Opcode using the PREFER_FAILURE option and Mapping Update (Section 14.2). Because of this, the PCP client MUST validate that the External IP Address and Port in a success response matches the associated suggested values from the request. If they don't match, it is because the Mapping Update was sent before the MAP request was processed. If the PCP server has no use for this new mapping, it SHOULD delete the mapping. What is PCP server supposed to do when PREFER_FAILURE option packet is rece= ived after MAP update AND PREFER_FAILURE suggested external IP and port doe= sn;t match that of earlier map update. -> Return 'CANNOT_PROVIDE_EXTERNAL' OR -> Treat it as refresh (lifetime) for the internal IP and port and = send response with already assigned external IP and port (different than th= ose in PREFER-FAILURE option packet) Last statement looks little ambiguous, 'If the PCP server has no use for th= is new mapping, it SHOULD delete the mapping', is PCP server expected to de= lete mapping created thru update OR is it client who should send delete for= this mapping and resend PREFER_FAILURE option packet? -Mayuresh From dthaler@microsoft.com Thu Mar 29 01:00:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138021F898B for ; Thu, 29 Mar 2012 01:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.882 X-Spam-Level: X-Spam-Status: No, score=-103.882 tagged_above=-999 required=5 tests=[AWL=-0.283, 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 kCJwo72P3rQ3 for ; Thu, 29 Mar 2012 01:00:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48721F86BD for ; Thu, 29 Mar 2012 01:00:32 -0700 (PDT) Received: from mail187-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 08:00:32 +0000 Received: from mail187-va3 (localhost [127.0.0.1]) by mail187-va3-R.bigfish.com (Postfix) with ESMTP id 4C92E1A01DE for ; Thu, 29 Mar 2012 08:00:32 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail187-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail187-va3 (localhost.localdomain [127.0.0.1]) by mail187-va3 (MessageSwitch) id 1333008030804129_890; Thu, 29 Mar 2012 08:00:30 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.237]) by mail187-va3.bigfish.com (Postfix) with ESMTP id BDE444E0082 for ; Thu, 29 Mar 2012 08:00:30 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 08:00:29 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 08:00:28 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 01:00:28 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 01:00:28 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqA== Date: Thu, 29 Mar 2012 08:00:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:00:34 -0000 We got consensus among those at the meetings on the following, and want to confirm WG consensus on the list, in case there are new objections raised or folks who were not present in the room at the time. 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2 agai= nst) This would resolve Stephen Farrell's discuss, allowing the base spec to be published quickly. The alternative would likely take a lot more time to address, especially given that we already moved DS-lite discussion out of the base spec, and the DS-lite scenario was a key motivation for THIRD_PARTY. 2) Add a client-specified per-mapping nonce (no strong objections) Belief is this is needed to resolve the transaction ID discuss's. WG will not add a transaction id, but will add a per-mapping nonce instead. 3) Without having resolved the question of inline vs PANA first, adopt draft-wasserman-pcp-authentication as a working group document (12 in favor= , 3 against) This would be the basis of the pcp security document. Belief is that much of the current document is independent of the=20 unresolved question on the table, and the WG draft should be agnostic on that question. 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus among those who've read it) Barring new objections that were not raised at the meeting, we plan to go forward with the above consensus items. -Dave From dthaler@microsoft.com Thu Mar 29 01:11:06 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC521F88BD; Thu, 29 Mar 2012 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=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 tUU9rW2I0pMT; Thu, 29 Mar 2012 01:11:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CB21F88AD; Thu, 29 Mar 2012 01:11:01 -0700 (PDT) Received: from mail88-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 08:10:59 +0000 Received: from mail88-ch1 (localhost [127.0.0.1]) by mail88-ch1-R.bigfish.com (Postfix) with ESMTP id AF313260113; Thu, 29 Mar 2012 08:10:59 +0000 (UTC) X-SpamScore: -5 X-BigFish: VS-5(zzc85fh1419Mzz1202hzz8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail88-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail88-ch1 (localhost.localdomain [127.0.0.1]) by mail88-ch1 (MessageSwitch) id 1333008657388408_24714; Thu, 29 Mar 2012 08:10:57 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail88-ch1.bigfish.com (Postfix) with ESMTP id 57D193A0077; Thu, 29 Mar 2012 08:10:57 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 08:10:56 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 08:10:46 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 01:10:46 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 01:10:46 -0700 From: Dave Thaler To: "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: Report on PCP WG discussion on 6204bis Thread-Index: Ac0M/2Xm6NNFsPRxQDy0hhkfu8nxPgAg8M5A Date: Thu, 29 Mar 2012 08:10:46 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E72BD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" , Ralph Droms Subject: [pcp] FW: Report on PCP WG discussion on 6204bis X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:11:06 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PCP WG discussed W-6 and W-7 and what advice it might give to the v6ops= WG on what it might say about the PCP protocol. It was made clear the text w= as a v6ops item, and that the PCP WG is providing review/advice. Fred Baker ask= ed for a report to be posted to the v6ops list, which is this email. Also cc'ing Ralph who was substituting as acting co-chair of the PCP meetin= g in Alain's absence. Raw notes straight from notetaker (on Etherpad) regarding W-6: Q1. Is requirement for PCP client okay? v4-only or dual-stack? Q2. Should PCP server be required in CPE? Just for configuring local state? Francis: No reason to put a SHOULD to the PCP client, and not another protocol that can do the same thing. Dave: current defaults from v6ops: Q1=3Dyes, dual stack; Q2=3Dno Stuart: Apple base station has local (CPE-based) apps Dave: another example is web-based CPE configuration Margaret: we can't make requirements for ALL CPE equipment. "SHOULD" doesn't help me; a PCP client is useless without anything to configure Tom Taylor: server function on the CPE needs PCP, not the CPE per se Simon: any CPE router has the ability to run a local server, so the text as written is sufficient Pete Resnick: we got into this mess because CPEs were too stupid to realize that they might have private addresses on both sides. Not clear on why it's SHOULD not MUST. Assuming proxy on the CPE. Also servers will probably be running on the CPE, so need PCP anyway. Dave: no strong consensus in either direction My recollection regarding the last is that we polled the room, and there wa= s a "weak leaning" towards the current W-6 approach, but no strong consensus. And raw notes from notetaker on the W-7 discussion: PCP DS-Lite mode being discussed in v6ops working group for 6204bis. WG suggestion is that v6ops should remove PCP DS-Lite mode from their requi= rements. As chair, my reading of the PCP WG discussion on W-7 was that the PCP WG did not have consensus on what W-7 should say, should it be kept, and there= fore it is best to remove it pending PCP WG work on ds-lite interaction with pcp= , which is being done in a separate document that still needs significant eff= ort. If another update is done in the future once that work is complete, the WG might very well be able to get consensus at that time. -Dave Thaler --_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The PCP WG discussed W-6 and W-7 and what advice = it might give to the v6ops WG

on what it might say about the PCP protocol. = ;  It was made clear the text was a

v6ops item, and that the PCP WG is providing revi= ew/advice.  Fred Baker asked

for a report to be posted to the v6ops list, whic= h is this email.

 

Also cc’ing Ralph who was substituting as a= cting co-chair of the PCP meeting in

Alain’s absence.

 

Raw notes straight from notetaker (on Etherpad) r= egarding W-6:

Q1. Is requirement for= PCP client okay? v4-only or dual-stack?

Q2. Should PCP server = be required in CPE? Just for configuring local state?

Francis: No reason to = put a SHOULD to the PCP client, and not another

protocol that can do t= he same thing.

Dave: current defaults= from v6ops: Q1=3Dyes, dual stack; Q2=3Dno

Stuart: Apple base sta= tion has local (CPE-based) apps

Dave: another example = is web-based CPE configuration

Margaret: we can't mak= e requirements for ALL CPE equipment. "SHOULD"

doesn't help me; a PCP= client is useless without anything to configure

Tom Taylor: server fun= ction on the CPE needs PCP, not the CPE per se

Simon: any CPE router = has the ability to run a local server, so the text

as written is sufficie= nt

Pete Resnick: we got i= nto this mess because CPEs were too stupid to

realize that they migh= t have private addresses on both sides. Not

clear on why it's SHOU= LD not MUST. Assuming proxy on the CPE. Also

servers will probably = be running on the CPE, so need PCP anyway.

Dave: no strong consen= sus in either direction

 

My recollection regarding the last is that we pol= led the room, and there was

a “weak leaning” towards the current = W-6 approach, but no strong consensus.

 

And raw notes from notetaker on the W-7 discussio= n:

PCP DS-Lite mode being di= scussed in v6ops working group for 6204bis.

WG suggestion is that v6o= ps should remove PCP DS-Lite mode from their requirements.

 

As chair, my reading of the PCP WG discussion on = W-7 was that the PCP WG

did not have consensus on what W-7 should say, sh= ould it be kept, and therefore

it is best to remove it pending PCP WG work on ds= -lite interaction with pcp,

which is being done in a separate document that s= till needs significant effort.

If another update is done in the future once that= work is complete, the WG

might very well be able to get consensus at that = time.

 

-Dave Thaler

--_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_-- From mohamed.boucadair@orange.com Thu Mar 29 01:15:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EDE21F87CB for ; Thu, 29 Mar 2012 01:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.051, 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 pOiKhQFtM6R7 for ; Thu, 29 Mar 2012 01:15:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E60F221F89B4 for ; Thu, 29 Mar 2012 01:15:02 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3334A22C518; Thu, 29 Mar 2012 10:15:02 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 184FB238061; Thu, 29 Mar 2012 10:15:02 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 29 Mar 2012 10:15:01 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Thu, 29 Mar 2012 10:15:00 +0200 Thread-Topic: Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzA Message-ID: <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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.29.75416 Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:15:04 -0000 Dear Dave, all, I was one of the 2 who objected to remove the THIRD_PARTY Option from the b= ase spec. I maintain my objection because I see THIRD_PARTY as an important= feature: allow to instruct mappings for non pcp compliant hosts/applicatio= ns. =20 Adding a normative ref to draft-wasserman for the THIRD_PARTY is too strong= IMHO. The major scenarios which driven so far the development of PCP do no= t require authenticated PCP communications: why doing this for explicit map= ping while this is not required for implicit mappings! I do not want to slow down the progress of PCP base spec but cutting the im= portant features from the base spec won't help too.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : jeudi 29 mars 2012 10:00 >=C0 : pcp@ietf.org >Objet : [pcp] Confirming consensus from WG meetings > >We got consensus among those at the meetings on the following, >and want to confirm WG consensus on the list, in case there are new >objections raised or folks who were not present in the room at=20 >the time. > >1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in=20 >favor, 2 against) > This would resolve Stephen Farrell's discuss, allowing=20 >the base spec > to be published quickly. The alternative would likely=20 >take a lot more > time to address, especially given that we already moved DS-lite > discussion out of the base spec, and the DS-lite=20 >scenario was a key > motivation for THIRD_PARTY. > >2) Add a client-specified per-mapping nonce (no strong objections) > Belief is this is needed to resolve the transaction ID=20 >discuss's. > WG will not add a transaction id, but will add a per-mapping > nonce instead. > >3) Without having resolved the question of inline vs PANA first, adopt >draft-wasserman-pcp-authentication as a working group document=20 >(12 in favor, 3 against) > This would be the basis of the pcp security document. Belief is > that much of the current document is independent of the=20 > unresolved question on the table, and the WG draft should > be agnostic on that question. > >4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus > among those who've read it) > >Barring new objections that were not raised at the meeting, we plan to >go forward with the above consensus items. > >-Dave > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From christian.jacquenet@orange.com Thu Mar 29 01:29:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EFD21F892D for ; Thu, 29 Mar 2012 01:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24, 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 I6itiWI2JQbn for ; Thu, 29 Mar 2012 01:29:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBD821F892A for ; Thu, 29 Mar 2012 01:29:25 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9BB3A18C139; Thu, 29 Mar 2012 10:29:24 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7373B4C06F; Thu, 29 Mar 2012 10:29:24 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 29 Mar 2012 10:29:20 +0200 From: To: BOUCADAIR Mohamed OLNC/NAD/TIP , Dave Thaler , "pcp@ietf.org" Date: Thu, 29 Mar 2012 10:29:19 +0200 Thread-Topic: Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYA= Message-ID: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:29:26 -0000 Dave, all, I'd like to second Med's comment.=20 I'm too opposed to motion #1 below, especially in light of the need for the= THIRD_PARTY option for DS-Lite deployments that will start in a couple of = months from now as far as some service providers are concerned. The securit= y concerns that have been raised so far do not apply to DS-Lite scenarios, = as reminded by Med below. I think the -24 is in a sufficiently good shape to be published as is, wher= eas DS-Lite scenarios remain one of the most straightforward use cases for = PCP applicability, and was actually a key driver for the initial base spec = effort back in 2010. Simply ignoring what becomes a fact in the very short term because of secur= ity considerations that do not apply to such use case is not a good enough = reason for me to defer the standardization of the THIRD PARTY at who-knows-= when. Cheers, Christian. -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de moham= ed.boucadair@orange.com Envoy=E9 : jeudi 29 mars 2012 10:15 =C0 : Dave Thaler; pcp@ietf.org Objet : Re: [pcp] Confirming consensus from WG meetings Dear Dave, all, I was one of the 2 who objected to remove the THIRD_PARTY Option from the b= ase spec. I maintain my objection because I see THIRD_PARTY as an important= feature: allow to instruct mappings for non pcp compliant hosts/applicatio= ns.=20=20=20 Adding a normative ref to draft-wasserman for the THIRD_PARTY is too strong= IMHO. The major scenarios which driven so far the development of PCP do no= t require authenticated PCP communications: why doing this for explicit map= ping while this is not required for implicit mappings! I do not want to slow down the progress of PCP base spec but cutting the im= portant features from the base spec won't help too.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20 >Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org Objet := =20 >[pcp] Confirming consensus from WG meetings > >We got consensus among those at the meetings on the following, and want=20 >to confirm WG consensus on the list, in case there are new objections=20 >raised or folks who were not present in the room at the time. > >1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2=20 >against) > This would resolve Stephen Farrell's discuss, allowing the base spec > to be published quickly. The alternative would likely=20 >take a lot more > time to address, especially given that we already moved DS-lite > discussion out of the base spec, and the DS-lite scenario was a key > motivation for THIRD_PARTY. > >2) Add a client-specified per-mapping nonce (no strong objections) > Belief is this is needed to resolve the transaction ID discuss's. > WG will not add a transaction id, but will add a per-mapping > nonce instead. > >3) Without having resolved the question of inline vs PANA first, adopt=20 >draft-wasserman-pcp-authentication as a working group document >(12 in favor, 3 against) > This would be the basis of the pcp security document. Belief is > that much of the current document is independent of the=20 > unresolved question on the table, and the WG draft should > be agnostic on that question. > >4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus > among those who've read it) > >Barring new objections that were not raised at the meeting, we plan to=20 >go forward with the above consensus items. > >-Dave > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From wim.henderickx@alcatel-lucent.com Thu Mar 29 01:31:10 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9621F892D for ; Thu, 29 Mar 2012 01:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.872 X-Spam-Level: X-Spam-Status: No, score=-8.872 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 KyJDkMnrPjf1 for ; Thu, 29 Mar 2012 01:31:08 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B5DE321F892A for ; Thu, 29 Mar 2012 01:31:07 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2T8RfJI002651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 10:31:05 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Mar 2012 10:30:47 +0200 From: "Henderickx, Wim (Wim)" To: "'christian.jacquenet@orange.com'" , "'mohamed.boucadair@orange.com'" , "'dthaler@microsoft.com'" , "'pcp@ietf.org'" Date: Thu, 29 Mar 2012 10:30:46 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAAIR7kQ== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:31:10 -0000 +1 Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: christian.jacquenet@orange.com [mailto:christian.jacquenet@orange.com= ] Sent: Thursday, March 29, 2012 10:29 AM=0A= To: BOUCADAIR Mohamed OLNC/NAD/TIP ; Dave Tha= ler ; pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings Dave, all, I'd like to second Med's comment.=20 I'm too opposed to motion #1 below, especially in light of the need for the= THIRD_PARTY option for DS-Lite deployments that will start in a couple of = months from now as far as some service providers are concerned. The securit= y concerns that have been raised so far do not apply to DS-Lite scenarios, = as reminded by Med below. I think the -24 is in a sufficiently good shape to be published as is, wher= eas DS-Lite scenarios remain one of the most straightforward use cases for = PCP applicability, and was actually a key driver for the initial base spec = effort back in 2010. Simply ignoring what becomes a fact in the very short term because of secur= ity considerations that do not apply to such use case is not a good enough = reason for me to defer the standardization of the THIRD PARTY at who-knows-= when. Cheers, Christian. -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de moham= ed.boucadair@orange.com Envoy=E9 : jeudi 29 mars 2012 10:15 =C0 : Dave Thaler; pcp@ietf.org Objet : Re: [pcp] Confirming consensus from WG meetings Dear Dave, all, I was one of the 2 who objected to remove the THIRD_PARTY Option from the b= ase spec. I maintain my objection because I see THIRD_PARTY as an important= feature: allow to instruct mappings for non pcp compliant hosts/applicatio= ns. =20 Adding a normative ref to draft-wasserman for the THIRD_PARTY is too strong= IMHO. The major scenarios which driven so far the development of PCP do no= t require authenticated PCP communications: why doing this for explicit map= ping while this is not required for implicit mappings! I do not want to slow down the progress of PCP base spec but cutting the im= portant features from the base spec won't help too.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20 >Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org Objet := =20 >[pcp] Confirming consensus from WG meetings > >We got consensus among those at the meetings on the following, and want=20 >to confirm WG consensus on the list, in case there are new objections=20 >raised or folks who were not present in the room at the time. > >1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2=20 >against) > This would resolve Stephen Farrell's discuss, allowing the base spec > to be published quickly. The alternative would likely=20 >take a lot more > time to address, especially given that we already moved DS-lite > discussion out of the base spec, and the DS-lite scenario was a key > motivation for THIRD_PARTY. > >2) Add a client-specified per-mapping nonce (no strong objections) > Belief is this is needed to resolve the transaction ID discuss's. > WG will not add a transaction id, but will add a per-mapping > nonce instead. > >3) Without having resolved the question of inline vs PANA first, adopt=20 >draft-wasserman-pcp-authentication as a working group document >(12 in favor, 3 against) > This would be the basis of the pcp security document. Belief is > that much of the current document is independent of the=20 > unresolved question on the table, and the WG draft should > be agnostic on that question. > >4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus > among those who've read it) > >Barring new objections that were not raised at the meeting, we plan to=20 >go forward with the above consensus items. > >-Dave > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From Tina.Tsou.Zouting@huawei.com Thu Mar 29 01:43:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6327821F8757 for ; Thu, 29 Mar 2012 01:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 Llo0lkLPukTp for ; Thu, 29 Mar 2012 01:43:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3172221F8938 for ; Thu, 29 Mar 2012 01:43:43 -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 AEU16751; Thu, 29 Mar 2012 04:43:42 -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; Thu, 29 Mar 2012 01:41:50 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 01:41:11 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 16:41:52 +0800 From: Tina TSOU To: "Henderickx, Wim (Wim)" Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAAIR7kQAAYz8A Date: Thu, 29 Mar 2012 08:41:52 +0000 Message-ID: <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr>, <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:43:44 -0000 +1 Sent from my iPad On Mar 29, 2012, at 10:31 AM, "Henderickx, Wim (Wim)" wrote: > +1 >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: christian.jacquenet@orange.com [mailto:christian.jacquenet@orange.c= om] > Sent: Thursday, March 29, 2012 10:29 AM > To: BOUCADAIR Mohamed OLNC/NAD/TIP ; Dave T= haler ; pcp@ietf.org > Subject: Re: [pcp] Confirming consensus from WG meetings >=20 > Dave, all, >=20 > I'd like to second Med's comment.=20 >=20 > I'm too opposed to motion #1 below, especially in light of the need for t= he THIRD_PARTY option for DS-Lite deployments that will start in a couple o= f months from now as far as some service providers are concerned. The secur= ity concerns that have been raised so far do not apply to DS-Lite scenarios= , as reminded by Med below. >=20 > I think the -24 is in a sufficiently good shape to be published as is, wh= ereas DS-Lite scenarios remain one of the most straightforward use cases fo= r PCP applicability, and was actually a key driver for the initial base spe= c effort back in 2010. >=20 > Simply ignoring what becomes a fact in the very short term because of sec= urity considerations that do not apply to such use case is not a good enoug= h reason for me to defer the standardization of the THIRD PARTY at who-know= s-when. >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de moh= amed.boucadair@orange.com > Envoy=E9 : jeudi 29 mars 2012 10:15 > =C0 : Dave Thaler; pcp@ietf.org > Objet : Re: [pcp] Confirming consensus from WG meetings >=20 > Dear Dave, all, >=20 > I was one of the 2 who objected to remove the THIRD_PARTY Option from the= base spec. I maintain my objection because I see THIRD_PARTY as an importa= nt feature: allow to instruct mappings for non pcp compliant hosts/applicat= ions. =20 >=20 > Adding a normative ref to draft-wasserman for the THIRD_PARTY is too stro= ng IMHO. The major scenarios which driven so far the development of PCP do = not require authenticated PCP communications: why doing this for explicit m= apping while this is not required for implicit mappings! >=20 > I do not want to slow down the progress of PCP base spec but cutting the = important features from the base spec won't help too.=20 >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20 >> Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org Objet= :=20 >> [pcp] Confirming consensus from WG meetings >>=20 >> We got consensus among those at the meetings on the following, and want= =20 >> to confirm WG consensus on the list, in case there are new objections=20 >> raised or folks who were not present in the room at the time. >>=20 >> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2=20 >> against) >> This would resolve Stephen Farrell's discuss, allowing the base spec >> to be published quickly. The alternative would likely=20 >> take a lot more >> time to address, especially given that we already moved DS-lite >> discussion out of the base spec, and the DS-lite scenario was a key >> motivation for THIRD_PARTY. >>=20 >> 2) Add a client-specified per-mapping nonce (no strong objections) >> Belief is this is needed to resolve the transaction ID discuss's. >> WG will not add a transaction id, but will add a per-mapping >> nonce instead. >>=20 >> 3) Without having resolved the question of inline vs PANA first, adopt=20 >> draft-wasserman-pcp-authentication as a working group document >> (12 in favor, 3 against) >> This would be the basis of the pcp security document. Belief is >> that much of the current document is independent of the=20 >> unresolved question on the table, and the WG draft should >> be agnostic on that question. >>=20 >> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus >> among those who've read it) >>=20 >> Barring new objections that were not raised at the meeting, we plan to=20 >> go forward with the above consensus items. >>=20 >> -Dave >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Thu Mar 29 01:54:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B122B21F89F2 for ; Thu, 29 Mar 2012 01:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ftFAiaBtVqdL for ; Thu, 29 Mar 2012 01:54:31 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id ABC7621F89D5 for ; Thu, 29 Mar 2012 01:54:31 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 9C03E20580; Thu, 29 Mar 2012 04:53:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> Date: Thu, 29 Mar 2012 10:54:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:54:32 -0000 Hi Christian, On Mar 29, 2012, at 10:29 AM, wrote: > Dave, all, >=20 > I'd like to second Med's comment.=20 >=20 > I'm too opposed to motion #1 below, especially in light of the need = for the THIRD_PARTY option for DS-Lite deployments that will start in a = couple of months from now as far as some service providers are = concerned. The security concerns that have been raised so far do not = apply to DS-Lite scenarios, as reminded by Med below. I think you are missing a key point of information here which is that = Stephen Farrell, one of the security ADs, currently has a blocking = "DISCUSS" (an IESG issue) outstanding against our document that requires = that we provide a stronger security solution that must be implemented = when the THIRD_PARTY option is implemented. Also, to be clear, the proposed change is not to eliminate THIRD_PARTY = from PCP. The proposal is to move THIRD_PARTY (which is already = optional in the Base Spec) into a separate document, so that we can = address the blocking issues raised by Stephen Farrell, WITHOUT HOLDING = UP THE BASE SPEC. We don't have the alternative of leaving the base = spec as-is and getting it published now. Realistically, we only have = two choices: 1) Keep THIRD_PARTY in the Base Spec, state that security is mandatory = to implement in PCP clients and servers that implement the optional = THIRD_PARTY option, and add a normative reference to a security = mechanism in the Base Spec. This option will DELAY RFC PUBLICATION OF = THE BASE SPEC until the security mechanism is also approved for = publication as an RFC. OR 2) Move "THIRD_PARTY" to a new document and deal with the security = issues there by normatively referencing a security mechanism and stating = that it is mandatory to implement (but not mandatory to deploy) whenever = the THIRD_PARTY option is implemented. This option will allow us to = PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not delay the THIRD_PARTY = option any longer than it will be delayed, anyway. Given those two choices, which one do you prefer? > I think the -24 is in a sufficiently good shape to be published as is, = whereas DS-Lite scenarios remain one of the most straightforward use = cases for PCP applicability, and was actually a key driver for the = initial base spec effort back in 2010. Everything about how to use PCP in DS-Lite is _also_ being moved to a = separate document. That document will include any special information = about deploying PCP in the DS-Lite scenario and could (if we have WG = consensus) say that it is safe to implement THIRD_PARTY without a = security mechanism in DS-Lite equipment (B4s and AFTRs). =20 Also, I think it is a bit limited to think of PCP as something that only = serves the DS-Lite use case. NAT-PMP and UPNP-IGD are in widespread use = today in non-DS-Lite situations, and we expect that PCP will be widely = deployed and used in those use cases, as well. I believe that this is = why THIRD_PARTY is optional instead of mandatory in the Base Spec. Margaret= From mrw@lilacglade.org Thu Mar 29 01:58:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015A21F8896 for ; Thu, 29 Mar 2012 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.812 X-Spam-Level: X-Spam-Status: No, score=-101.812 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_LWSHORTT=1.24, 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 rG5zpE4s8mNc for ; Thu, 29 Mar 2012 01:58:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8A621F8892 for ; Thu, 29 Mar 2012 01:58:15 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id A573920244; Thu, 29 Mar 2012 04:57:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Margaret Wasserman In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Thu, 29 Mar 2012 10:58:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:58:16 -0000 Hi Wim, As I said in my response to Christian, we do not have the option of = publishing the Base Specification now with the THIRD_PARTY option in it = and no mandatory-to-implement security mechanism. We either need to add = a normative reference to a security mechanism to the Base Spec (and wait = for the security mechanism to be approved before we publish the Base = Spec), or break the THIRD_PARTY option out in to a separate document = (that will normatively reference a security mechanism), so that we can = get the rest of the Base Spec published now. Could you please read my response to Christian (my previous message to = PCP), and let me know which of the two choices listed in that message = you would actually prefer? Thanks, Margaret On Mar 29, 2012, at 10:30 AM, Henderickx, Wim (Wim) wrote: > +1 >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: christian.jacquenet@orange.com = [mailto:christian.jacquenet@orange.com] > Sent: Thursday, March 29, 2012 10:29 AM > To: BOUCADAIR Mohamed OLNC/NAD/TIP ; = Dave Thaler ; pcp@ietf.org > Subject: Re: [pcp] Confirming consensus from WG meetings >=20 > Dave, all, >=20 > I'd like to second Med's comment.=20 >=20 > I'm too opposed to motion #1 below, especially in light of the need = for the THIRD_PARTY option for DS-Lite deployments that will start in a = couple of months from now as far as some service providers are = concerned. The security concerns that have been raised so far do not = apply to DS-Lite scenarios, as reminded by Med below. >=20 > I think the -24 is in a sufficiently good shape to be published as is, = whereas DS-Lite scenarios remain one of the most straightforward use = cases for PCP applicability, and was actually a key driver for the = initial base spec effort back in 2010. >=20 > Simply ignoring what becomes a fact in the very short term because of = security considerations that do not apply to such use case is not a good = enough reason for me to defer the standardization of the THIRD PARTY at = who-knows-when. >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = mohamed.boucadair@orange.com > Envoy=E9 : jeudi 29 mars 2012 10:15 > =C0 : Dave Thaler; pcp@ietf.org > Objet : Re: [pcp] Confirming consensus from WG meetings >=20 > Dear Dave, all, >=20 > I was one of the 2 who objected to remove the THIRD_PARTY Option from = the base spec. I maintain my objection because I see THIRD_PARTY as an = important feature: allow to instruct mappings for non pcp compliant = hosts/applications. =20 >=20 > Adding a normative ref to draft-wasserman for the THIRD_PARTY is too = strong IMHO. The major scenarios which driven so far the development of = PCP do not require authenticated PCP communications: why doing this for = explicit mapping while this is not required for implicit mappings! >=20 > I do not want to slow down the progress of PCP base spec but cutting = the important features from the base spec won't help too.=20 >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20= >> Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org = Objet :=20 >> [pcp] Confirming consensus from WG meetings >>=20 >> We got consensus among those at the meetings on the following, and = want=20 >> to confirm WG consensus on the list, in case there are new objections=20= >> raised or folks who were not present in the room at the time. >>=20 >> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, = 2=20 >> against) >> This would resolve Stephen Farrell's discuss, allowing the base = spec >> to be published quickly. The alternative would likely=20 >> take a lot more >> time to address, especially given that we already moved DS-lite >> discussion out of the base spec, and the DS-lite scenario was a = key >> motivation for THIRD_PARTY. >>=20 >> 2) Add a client-specified per-mapping nonce (no strong objections) >> Belief is this is needed to resolve the transaction ID = discuss's. >> WG will not add a transaction id, but will add a per-mapping >> nonce instead. >>=20 >> 3) Without having resolved the question of inline vs PANA first, = adopt=20 >> draft-wasserman-pcp-authentication as a working group document >> (12 in favor, 3 against) >> This would be the basis of the pcp security document. Belief is >> that much of the current document is independent of the=20 >> unresolved question on the table, and the WG draft should >> be agnostic on that question. >>=20 >> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus >> among those who've read it) >>=20 >> Barring new objections that were not raised at the meeting, we plan = to=20 >> go forward with the above consensus items. >>=20 >> -Dave >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Mar 29 01:58:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9F21F88A1 for ; Thu, 29 Mar 2012 01:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 t5oJW8DbIX3D for ; Thu, 29 Mar 2012 01:58:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 60E1A21F8892 for ; Thu, 29 Mar 2012 01:58:31 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-10f2.meeting.ietf.org [130.129.16.242]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BA46A40054 for ; Thu, 29 Mar 2012 04:58:30 -0400 (EDT) Message-ID: <4F742434.90403@viagenie.ca> Date: Thu, 29 Mar 2012 10:58:28 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: pcp@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> In-Reply-To: <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:58:33 -0000 On 03/29/12 10:54, Margaret Wasserman wrote: > 2) Move "THIRD_PARTY" to a new document and deal with the security > issues there by normatively referencing a security mechanism and > stating that it is mandatory to implement (but not mandatory to > deploy) whenever the THIRD_PARTY option is implemented. This option > will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not > delay the THIRD_PARTY option any longer than it will be delayed, > anyway. If your only use for THIRD_PARTY is in a DS-Lite setting, you don't need an additional security mechanism. You can just enforce a simple ACL ensuring that the address is a DS-Lite address. IMHO this use case is important enough to make this option unworkable. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mrw@lilacglade.org Thu Mar 29 02:02:41 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B2321F88CB for ; Thu, 29 Mar 2012 02:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mfpsC9pEsiWB for ; Thu, 29 Mar 2012 02:02:40 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24821F8851 for ; Thu, 29 Mar 2012 02:02:33 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 9284920580; Thu, 29 Mar 2012 05:01:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> Date: Thu, 29 Mar 2012 11:02:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr>, <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:02:41 -0000 Hi Tina, On Mar 29, 2012, at 10:41 AM, Tina TSOU wrote: > +1 As I indicated to Wim, you are agreeing to a choice that is not = available to us. We _can not_ publish the current PCP Base Spec as is. = We need to make changes to address Stephen Farrell's discuss. So, just = publish the Base Spec as-is is not a choice we can make. Given that fact, which of the options in my previous message would you = like to see us pursue: (1) Delay the Base Spec while we wait for a = security mechanism to be approved, or (2) break out THIRD_PARTY so that = the rest of the PCP Base Spec can be published now? =20 Margaret From mrw@lilacglade.org Thu Mar 29 02:04:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A137321F891E for ; Thu, 29 Mar 2012 02:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 JCfI08pYPX6f for ; Thu, 29 Mar 2012 02:04:32 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 39E7021F88AC for ; Thu, 29 Mar 2012 02:04:32 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 4D35220244; Thu, 29 Mar 2012 05:03:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F742434.90403@viagenie.ca> Date: Thu, 29 Mar 2012 11:04:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <4F742434.90403@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:04:32 -0000 Hi Simon, On Mar 29, 2012, at 10:58 AM, Simon Perreault wrote: > On 03/29/12 10:54, Margaret Wasserman wrote: >> 2) Move "THIRD_PARTY" to a new document and deal with the security >> issues there by normatively referencing a security mechanism and >> stating that it is mandatory to implement (but not mandatory to >> deploy) whenever the THIRD_PARTY option is implemented. This option >> will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not >> delay the THIRD_PARTY option any longer than it will be delayed, >> anyway. >=20 > If your only use for THIRD_PARTY is in a DS-Lite setting, you don't = need an additional security mechanism. You can just enforce a simple ACL = ensuring that the address is a DS-Lite address. IMHO this use case is = important enough to make this option unworkable. Everything about DS-Lite deployment that was in the Base Spec is being = moved to a separate document. That document could state that it is okay = to use THIRD_PARTY in the DS-Lite case, as long as support for an ACL is = provided on the PCP Server/AFTR. Margaret From bingxuere@gmail.com Thu Mar 29 02:05:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680DA21F89FF for ; Thu, 29 Mar 2012 02:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 16WUn2GRnRNc for ; Thu, 29 Mar 2012 02:05:44 -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 4BCAD21F89A2 for ; Thu, 29 Mar 2012 02:05:44 -0700 (PDT) Received: by iazz13 with SMTP id z13so3223182iaz.31 for ; Thu, 29 Mar 2012 02:05:43 -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=GEejMlKumgDit5en+4NQosqAwOlG6XdGIDk5zvhMlss=; b=fAA1meVDqle+N5GriJhFEO2IboR8viepXRSvc/yd1jCHQckP3ceCo4k5n4/pjhmalF y9ngivp4b8z3361DwmRTAgxHI3O/RDnZ0wbZl9Wik8CBX/wwxGN9dxqfYGc5cRok/Qp6 oXASg39v5KCB86w1NkyqxVAYcW7cEyFbRXDRPfUblW2jV98hrUfltDBWSa/bRIy/hdU2 SWcwQaJS1YmDvaMvJZ1f8WJHhnUX5mMgQcyoiD40wMU23x/SCCkgvPJEzMDBdh0lSzHS kJfq0mDxDiXlrqfadnt6a+Zr0TmPLr5TXm4FDYvFT0OghhgFxfmQ9WNZXcOZnh2N0kBG RT+Q== Received: by 10.42.203.67 with SMTP id fh3mr19441398icb.44.1333011943831; Thu, 29 Mar 2012 02:05:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Thu, 29 Mar 2012 02:05:03 -0700 (PDT) In-Reply-To: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> From: Qiong Date: Thu, 29 Mar 2012 17:05:03 +0800 Message-ID: To: christian.jacquenet@orange.com Content-Type: multipart/alternative; boundary=20cf303ddc4464b7f904bc5e0772 Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:05:45 -0000 --20cf303ddc4464b7f904bc5e0772 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support. We need to move forward asap. Best wishes Qiong On Thu, Mar 29, 2012 at 4:29 PM, wrote: > Dave, all, > > I'd like to second Med's comment. > > I'm too opposed to motion #1 below, especially in light of the need for > the THIRD_PARTY option for DS-Lite deployments that will start in a coupl= e > of months from now as far as some service providers are concerned. The > security concerns that have been raised so far do not apply to DS-Lite > scenarios, as reminded by Med below. > > I think the -24 is in a sufficiently good shape to be published as is, > whereas DS-Lite scenarios remain one of the most straightforward use case= s > for PCP applicability, and was actually a key driver for the initial base > spec effort back in 2010. > > Simply ignoring what becomes a fact in the very short term because of > security considerations that do not apply to such use case is not a good > enough reason for me to defer the standardization of the THIRD PARTY at > who-knows-when. > > Cheers, > > Christian. > > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=C3=A9 : jeudi 29 mars 2012 10:15 > =C3=80 : Dave Thaler; pcp@ietf.org > Objet : Re: [pcp] Confirming consensus from WG meetings > > Dear Dave, all, > > I was one of the 2 who objected to remove the THIRD_PARTY Option from the > base spec. I maintain my objection because I see THIRD_PARTY as an > important feature: allow to instruct mappings for non pcp compliant > hosts/applications. > > Adding a normative ref to draft-wasserman for the THIRD_PARTY is too > strong IMHO. The major scenarios which driven so far the development of P= CP > do not require authenticated PCP communications: why doing this for > explicit mapping while this is not required for implicit mappings! > > I do not want to slow down the progress of PCP base spec but cutting the > important features from the base spec won't help too. > > Cheers, > Med > > >-----Message d'origine----- > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >Dave Thaler Envoy=C3=A9 : jeudi 29 mars 2012 10:00 =C3=80 : pcp@ietf.org= Objet : > >[pcp] Confirming consensus from WG meetings > > > >We got consensus among those at the meetings on the following, and want > >to confirm WG consensus on the list, in case there are new objections > >raised or folks who were not present in the room at the time. > > > >1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2 > >against) > > This would resolve Stephen Farrell's discuss, allowing the base > spec > > to be published quickly. The alternative would likely > >take a lot more > > time to address, especially given that we already moved DS-lite > > discussion out of the base spec, and the DS-lite scenario was a k= ey > > motivation for THIRD_PARTY. > > > >2) Add a client-specified per-mapping nonce (no strong objections) > > Belief is this is needed to resolve the transaction ID discuss's. > > WG will not add a transaction id, but will add a per-mapping > > nonce instead. > > > >3) Without having resolved the question of inline vs PANA first, adopt > >draft-wasserman-pcp-authentication as a working group document > >(12 in favor, 3 against) > > This would be the basis of the pcp security document. Belief is > > that much of the current document is independent of the > > unresolved question on the table, and the WG draft should > > be agnostic on that question. > > > >4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus > > among those who've read it) > > > >Barring new objections that were not raised at the meeting, we plan to > >go forward with the above consensus items. > > > >-Dave > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --20cf303ddc4464b7f904bc5e0772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support.

We need to move forward asap.

Best wishes
Qion= g

On Thu, Mar 29, 2012 at 4:29 PM, <christia= n.jacquenet@orange.com> wrote:
Dave, all,

I'd like to second Med's comment.

I'm too opposed to motion #1 below, especially in light of the need for= the THIRD_PARTY option for DS-Lite deployments that will start in a couple= of months from now as far as some service providers are concerned. The sec= urity concerns that have been raised so far do not apply to DS-Lite scenari= os, as reminded by Med below.

I think the -24 is in a sufficiently good shape to be published as is, wher= eas DS-Lite scenarios remain one of the most straightforward use cases for = PCP applicability, and was actually a key driver for the initial base spec = effort back in 2010.

Simply ignoring what becomes a fact in the very short term because of secur= ity considerations that do not apply to such use case is not a good enough = reason for me to defer the standardization of the THIRD PARTY at who-knows-= when.

Cheers,

Christian.

-----Message d'origine-----
De : pcp-bounces@ietf.org [mail= to:pcp-bounces@ietf.org] De la = part de mohamed.boucadair@o= range.com
Envoy=C3=A9 : jeudi 29 mars 2012 10:15
=C3=80 : Dave Thaler; pcp@ietf.org
Objet : Re: [pcp] Confirming consensus from WG meetings

Dear Dave, all,

I was one of the 2 who objected to remove the THIRD_PARTY Option from the b= ase spec. I maintain my objection because I see THIRD_PARTY as an important= feature: allow to instruct mappings for non pcp compliant hosts/applicatio= ns.

Adding a normative ref to draft-wasserman for the THIRD_PARTY is too strong= IMHO. The major scenarios which driven so far the development of PCP do no= t require authenticated PCP communications: why doing this for explicit map= ping while this is not required for implicit mappings!

I do not want to slow down the progress of PCP base spec but cutting the im= portant features from the base spec won't help too.

Cheers,
Med

>-----Message d'origine-----
>De : pcp-bounces@ietf.org [= mailto:pcp-bounces@ietf.org] De= la part de
>Dave Thaler Envoy=C3=A9 : jeudi 29 mars 2012 10:00 =C3=80 : pcp@ietf.org Objet :
>[pcp] Confirming consensus from WG meetings
>
>We got consensus among those at the meetings on the following, and want=
>to confirm WG consensus on the list, in case there are new objections >raised or folks who were not present in the room at the time.
>
>1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2<= br> >against)
> =C2=A0 =C2=A0 =C2=A0 This would resolve Stephen Farrell's discuss,= allowing the base spec
> =C2=A0 =C2=A0 =C2=A0 to be published quickly. =C2=A0 The alternative w= ould likely
>take a lot more
> =C2=A0 =C2=A0 =C2=A0 time to address, especially given that we already= moved DS-lite
> =C2=A0 =C2=A0 =C2=A0 discussion out of the base spec, and the DS-lite = scenario was a key
> =C2=A0 =C2=A0 =C2=A0 motivation for THIRD_PARTY.
>
>2) Add a client-specified per-mapping nonce (no strong objections)
> =C2=A0 =C2=A0 =C2=A0 Belief is this is needed to resolve the transacti= on ID discuss's.
> =C2=A0 =C2=A0 =C2=A0 WG will not add a transaction id, but will add a = per-mapping
> =C2=A0 =C2=A0 =C2=A0 nonce instead.
>
>3) Without having resolved the question of inline vs PANA first, adopt<= br> >draft-wasserman-pcp-authentication as a working group document
>(12 in favor, 3 against)
> =C2=A0 =C2=A0 =C2=A0 This would be the basis of the pcp security docum= ent. =C2=A0Belief is
> =C2=A0 =C2=A0 =C2=A0 that much of the current document is independent = of the
> =C2=A0 =C2=A0 =C2=A0 unresolved question on the table, and the WG draf= t should
> =C2=A0 =C2=A0 =C2=A0 be agnostic on that question.
>
>4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus
> =C2=A0 =C2=A0 =C2=A0 among those who've read it)
>
>Barring new objections that were not raised at the meeting, we plan to<= br> >go forward with the above consensus items.
>
>-Dave
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp
>
_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp

_______________________________________________________________= __________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

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

--20cf303ddc4464b7f904bc5e0772-- From alper.yegin@yegin.org Thu Mar 29 02:05:54 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918FC21F8A03 for ; Thu, 29 Mar 2012 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 wZH39Tmxg-d7 for ; Thu, 29 Mar 2012 02:05:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE2E21F88CA for ; Thu, 29 Mar 2012 02:05:53 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LkwUH-1SlgZV1pBN-00b8EM; Thu, 29 Mar 2012 05:05:51 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 29 Mar 2012 12:05:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1B1F59-6383-4FF2-BC8D-B1B2769B3E7C@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:FLNtzr4GE4ZwMy+RKOWYPXVURZf10GuDkVH+bkX5wJu rDj7BfZ5OofLXqK2F8u658RX6pGFobINsUB/xXPqXBVlMfuAcp +2b6Xp1mQbr36WrMRB75rXG0QGESxmDxN+nZIivIpB5CNcOUBY ZbmumyDLfloPODE/9ahjmO/JoYBvkb7KCmROpX1vaMcskGNGQq Ip+XlWrJhacEUv59hAa9PkpjAfObjpaR4JMdF0WU+jvgZFWeUl JC16TrlifHSoBoZwOD8sRDg+Rr+1QWeEQOlX95ycJn2qei7nnK bnpUjdONSAp8SE2UKpXVOXmLtwjs0meuttlAnKWeanRhnUc/2x qi5c9YuydBoCb0lApDZ8VkTDfZQaKkLvZG2abSx5z Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings (issue 3) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:05:54 -0000 Dave, >=20 > 3) Without having resolved the question of inline vs PANA first, adopt Please note that, the primary issue is "inline vs. separate KMP (key = management protocol) for PCP" I use PANA as a way to illustrate separate KMP.=20 There are certainly other ways of performing separate KMP as well. Does it make sense to define a PCP-based (i.e., inline) KMP for PCP? This is the question we need to answer.=20 > draft-wasserman-pcp-authentication as a working group document (12 in = favor, 3 against) > This would be the basis of the pcp security document. Belief is > that much of the current document is independent of the=20 > unresolved question on the table, and the WG draft should > be agnostic on that question. If so, the WG draft shall not have any details about the use of EAP = (e.g., section 5.4, 5.5., 5.7, etc.). That's the way to separate KMP from the I-D, and just leave PCP = integrity protection in. And if this is done, I do support such an I-D as well. Let's be very clear on these details, otherwise it's ambiguous what the = decision and actions are. Thanks. Alper From mrw@lilacglade.org Thu Mar 29 02:09:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB2A21F897E for ; Thu, 29 Mar 2012 02:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 P8YdycaK+lXh for ; Thu, 29 Mar 2012 02:09:24 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6121F8977 for ; Thu, 29 Mar 2012 02:09:23 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 235C020580; Thu, 29 Mar 2012 05:08:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F742434.90403@viagenie.ca> Date: Thu, 29 Mar 2012 11:09:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07E97662-3570-4ADF-8B7C-5802E5272D0F@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <4F742434.90403@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:09:24 -0000 One further technical question on this... On Mar 29, 2012, at 10:58 AM, Simon Perreault wrote: > On 03/29/12 10:54, Margaret Wasserman wrote: >> 2) Move "THIRD_PARTY" to a new document and deal with the security >> issues there by normatively referencing a security mechanism and >> stating that it is mandatory to implement (but not mandatory to >> deploy) whenever the THIRD_PARTY option is implemented. This option >> will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not >> delay the THIRD_PARTY option any longer than it will be delayed, >> anyway. >=20 > If your only use for THIRD_PARTY is in a DS-Lite setting, you don't = need an additional security mechanism. You can just enforce a simple ACL = ensuring that the address is a DS-Lite address. IMHO this use case is = important enough to make this option unworkable. Given that the B4 and the AFTR will not necessarily be located in a = single administrative domain (the B4 can be customer-owned equipment, or = even a host), why do you assume it is safe to use the THIRD-PARTY option = without security in the DS-Lite case? In other words, what would stop = an injection attack where an attacker takes over my printer and sends = messages from that printer that spoof THIRD_PARTY messages from the IPV6 = address of the B4 running on another host in my house, to open incoming = holes to additional nodes in my network that may be entirely unaware of = DS-Lite? Margaret From simon.perreault@viagenie.ca Thu Mar 29 02:09:25 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0421F8990 for ; Thu, 29 Mar 2012 02:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 m8hf5uN6YE2F for ; Thu, 29 Mar 2012 02:09:24 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 71D6C21F8977 for ; Thu, 29 Mar 2012 02:09:24 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-10f2.meeting.ietf.org [130.129.16.242]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9E78140054 for ; Thu, 29 Mar 2012 05:09:23 -0400 (EDT) Message-ID: <4F7426C2.4070207@viagenie.ca> Date: Thu, 29 Mar 2012 11:09:22 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: pcp@ietf.org References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr>, <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:09:25 -0000 On 03/29/12 11:02, Margaret Wasserman wrote: > As I indicated to Wim, you are agreeing to a choice that is not > available to us. We _can not_ publish the current PCP Base Spec as > is. We need to make changes to address Stephen Farrell's discuss. "Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide range of options available. It's not binary. We can tweak things a bit, try to convince the AD with new arguments, etc. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mrw@lilacglade.org Thu Mar 29 02:11:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AC921F8977 for ; Thu, 29 Mar 2012 02:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 BrDFL6W9wBOF for ; Thu, 29 Mar 2012 02:11:04 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7B821F86D1 for ; Thu, 29 Mar 2012 02:11:04 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id B39AB20244; Thu, 29 Mar 2012 05:10:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <5B1B1F59-6383-4FF2-BC8D-B1B2769B3E7C@yegin.org> Date: Thu, 29 Mar 2012 11:11:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5B1B1F59-6383-4FF2-BC8D-B1B2769B3E7C@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings (issue 3) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:11:05 -0000 On Mar 29, 2012, at 11:05 AM, Alper Yegin wrote: > , the WG draft shall not have any details about the use of EAP (e.g., = section 5.4, 5.5., 5.7, etc.). > That's the way to separate KMP from the I-D, and just leave PCP = integrity protection in. > And if this is done, I do support such an I-D as well. My understanding is that the draft would indicate that we have not = decided between the two proposals that have presented to the WG: use of = PCP over EAP (as described in our original non-WG document) or use of = EAP over PANA (as described in your e-mail). Margaret From simon.perreault@viagenie.ca Thu Mar 29 02:12:25 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F9221F8503 for ; Thu, 29 Mar 2012 02:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 E7G+5pz2nZlx for ; Thu, 29 Mar 2012 02:12:24 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1D97C21F8504 for ; Thu, 29 Mar 2012 02:12:23 -0700 (PDT) Received: from eeepc.viagenie.ca (dhcp-10f2.meeting.ietf.org [130.129.16.242]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A741440054; Thu, 29 Mar 2012 05:12:22 -0400 (EDT) Message-ID: <4F742775.9000904@viagenie.ca> Date: Thu, 29 Mar 2012 11:12:21 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: Margaret Wasserman References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <4F742434.90403@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:12:25 -0000 On 03/29/12 11:04, Margaret Wasserman wrote: >> If your only use for THIRD_PARTY is in a DS-Lite setting, you don't >> need an additional security mechanism. You can just enforce a >> simple ACL ensuring that the address is a DS-Lite address. IMHO >> this use case is important enough to make this option unworkable. > > Everything about DS-Lite deployment that was in the Base Spec is > being moved to a separate document. That document could state that > it is okay to use THIRD_PARTY in the DS-Lite case, as long as support > for an ACL is provided on the PCP Server/AFTR. Ok so "ACL" would be an acceptable "security mechanism". I thought it was implied that the PANA stuff needed to be implemented if you wanted to use THIRD_PARTY. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange.com Thu Mar 29 02:12:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A440421F857A for ; Thu, 29 Mar 2012 02:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GcY0jpnExaFi for ; Thu, 29 Mar 2012 02:12:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 222A021F856C for ; Thu, 29 Mar 2012 02:12:29 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 549263B44F4; Thu, 29 Mar 2012 11:12:29 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3810135C048; Thu, 29 Mar 2012 11:12:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 29 Mar 2012 11:12:29 +0200 From: To: Margaret Wasserman , Simon Perreault Date: Thu, 29 Mar 2012 11:12:28 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NivcXWHgfYNfNSQiuJ0ZGJQPMrgAAMwtw Message-ID: <94C682931C08B048B7A8645303FDC9F36E2873370B@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <4F742434.90403@viagenie.ca> 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.3.29.75416 Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:12:32 -0000 Re-, As I already said, THIRD_PARTY is NOT only for DS-lite: it is also for host= s belonging to the same subscriber but which do not support PCP (eg., webca= m, server). Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Margaret Wasserman >Envoy=E9 : jeudi 29 mars 2012 11:04 >=C0 : Simon Perreault >Cc : pcp@ietf.org >Objet : Re: [pcp] Confirming consensus from WG meetings > > >Hi Simon, > >On Mar 29, 2012, at 10:58 AM, Simon Perreault wrote: >> On 03/29/12 10:54, Margaret Wasserman wrote: >>> 2) Move "THIRD_PARTY" to a new document and deal with the security >>> issues there by normatively referencing a security mechanism and >>> stating that it is mandatory to implement (but not mandatory to >>> deploy) whenever the THIRD_PARTY option is implemented. This option >>> will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not >>> delay the THIRD_PARTY option any longer than it will be delayed, >>> anyway. >>=20 >> If your only use for THIRD_PARTY is in a DS-Lite setting,=20 >you don't need an additional security mechanism. You can just=20 >enforce a simple ACL ensuring that the address is a DS-Lite=20 >address. IMHO this use case is important enough to make this=20 >option unworkable. > > >Everything about DS-Lite deployment that was in the Base Spec=20 >is being moved to a separate document. That document could=20 >state that it is okay to use THIRD_PARTY in the DS-Lite case,=20 >as long as support for an ACL is provided on the PCP Server/AFTR. > >Margaret > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From gilles.bertrand@orange.com Thu Mar 29 02:13:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D121F87D5 for ; Thu, 29 Mar 2012 02:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 QDuZ3aNJpqJd for ; Thu, 29 Mar 2012 02:13:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6923321F87CB for ; Thu, 29 Mar 2012 02:13:15 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4ED514110ED for ; Thu, 29 Mar 2012 11:13:14 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 463B04110D5 for ; Thu, 29 Mar 2012 11:13:14 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 11:13:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 11:13:05 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF034268B9@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <51D96D3F30495C4BAF8D190702F9B93302854F45@ftrdmel1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAALOKkAAAGnrwAAAScvAAANcuIA== References: <51D96D3F30495C4BAF8D190702F9B93302854F45@ftrdmel1> From: To: X-OriginalArrivalTime: 29 Mar 2012 09:13:14.0216 (UTC) FILETIME=[2BA0E680:01CD0D8C] Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:13:16 -0000 +1 Gilles -----Message d'origine----- De : JACQUENET Christian OLNC/NAD/TIP Envoy=E9 : jeudi 29 mars 2012 10:29 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Dave Thaler; pcp@ietf.org Objet : = RE: Confirming consensus from WG meetings Dave, all, I'd like to second Med's comment.=20 I'm too opposed to motion #1 below, especially in light of the need for = the THIRD_PARTY option for DS-Lite deployments that will start in a = couple of months from now as far as some service providers are = concerned. The security concerns that have been raised so far do not = apply to DS-Lite scenarios, as reminded by Med below. I think the -24 is in a sufficiently good shape to be published as is, = whereas DS-Lite scenarios remain one of the most straightforward use = cases for PCP applicability, and was actually a key driver for the = initial base spec effort back in 2010. Simply ignoring what becomes a fact in the very short term because of = security considerations that do not apply to such use case is not a good = enough reason for me to defer the standardization of the THIRD PARTY at = who-knows-when. Cheers, Christian. -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = mohamed.boucadair@orange.com Envoy=E9 : jeudi 29 mars 2012 10:15 =C0 : = Dave Thaler; pcp@ietf.org Objet : Re: [pcp] Confirming consensus from WG = meetings Dear Dave, all, I was one of the 2 who objected to remove the THIRD_PARTY Option from = the base spec. I maintain my objection because I see THIRD_PARTY as an = important feature: allow to instruct mappings for non pcp compliant = hosts/applications. =20 Adding a normative ref to draft-wasserman for the THIRD_PARTY is too = strong IMHO. The major scenarios which driven so far the development of = PCP do not require authenticated PCP communications: why doing this for = explicit mapping while this is not required for implicit mappings! I do not want to slow down the progress of PCP base spec but cutting the = important features from the base spec won't help too.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20 >Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org = Objet : >[pcp] Confirming consensus from WG meetings > >We got consensus among those at the meetings on the following, and want = >to confirm WG consensus on the list, in case there are new objections=20 >raised or folks who were not present in the room at the time. > >1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2 >against) > This would resolve Stephen Farrell's discuss, allowing the base spec > to be published quickly. The alternative would likely=20 >take a lot more > time to address, especially given that we already moved DS-lite > discussion out of the base spec, and the DS-lite scenario was a key > motivation for THIRD_PARTY. > >2) Add a client-specified per-mapping nonce (no strong objections) > Belief is this is needed to resolve the transaction ID discuss's. > WG will not add a transaction id, but will add a per-mapping > nonce instead. > >3) Without having resolved the question of inline vs PANA first, adopt=20 >draft-wasserman-pcp-authentication as a working group document >(12 in favor, 3 against) > This would be the basis of the pcp security document. Belief is > that much of the current document is independent of the=20 > unresolved question on the table, and the WG draft should > be agnostic on that question. > >4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus > among those who've read it) > >Barring new objections that were not raised at the meeting, we plan to=20 >go forward with the above consensus items. > >-Dave > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Thu Mar 29 02:14:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6811521F8A15 for ; Thu, 29 Mar 2012 02:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3JcTS+6LlKeh for ; Thu, 29 Mar 2012 02:14:11 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E6D7B21F87CB for ; Thu, 29 Mar 2012 02:14:10 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 289F220580; Thu, 29 Mar 2012 05:13:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F7426C2.4070207@viagenie.ca> Date: Thu, 29 Mar 2012 11:14:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4FC9AE1A-C74C-4E94-9726-D3392FED69A1@lilacglade.org> References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr>, <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> <4F7426C2.4070207@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:14:11 -0000 Hi Simon, On Mar 29, 2012, at 11:09 AM, Simon Perreault wrote: > On 03/29/12 11:02, Margaret Wasserman wrote: >> As I indicated to Wim, you are agreeing to a choice that is not >> available to us. We _can not_ publish the current PCP Base Spec as >> is. We need to make changes to address Stephen Farrell's discuss. >=20 > "Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide = range of options available. It's not binary. We can tweak things a bit, = try to convince the AD with new arguments, etc. There have been several off-line discussions with Stephen Farrell, = attempting to understand what we need to do to resolve this issue, and = this is the best plan that we were able to come up with... If you have a better alternative that you think Stephen will be willing = to accept, please propose it! =20 Saying "publish the document as-is", though, doesn't make any sense. Margaret From mrw@lilacglade.org Thu Mar 29 02:26:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2608121F8A24 for ; Thu, 29 Mar 2012 02:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8FWnfELrVYQr for ; Thu, 29 Mar 2012 02:26:24 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 361AE21F8A07 for ; Thu, 29 Mar 2012 02:26:24 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 6B5A92014A; Thu, 29 Mar 2012 05:25:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F742775.9000904@viagenie.ca> Date: Thu, 29 Mar 2012 11:26:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C084DA4-6659-452A-AC84-8A1F6BD8C6DC@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <4F742434.90403@viagenie.ca> <4F742775.9000904@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:26:26 -0000 On Mar 29, 2012, at 11:12 AM, Simon Perreault wrote: >> Everything about DS-Lite deployment that was in the Base Spec is >> being moved to a separate document. That document could state that >> it is okay to use THIRD_PARTY in the DS-Lite case, as long as support >> for an ACL is provided on the PCP Server/AFTR. >=20 > Ok so "ACL" would be an acceptable "security mechanism". I thought it = was implied that the PANA stuff needed to be implemented if you wanted = to use THIRD_PARTY. ACL might be an acceptable security mechanism, if we can constrain the = environment so that an ACL _is_ sufficiently secure. I do, personally, = think that an ACL is sufficient for DS-Lite deployments where the B4 and = AFTR are running in a single administrative domain (i.e. they are both = in the ISPs network). I expect that the security considerations in the DS-Lite document will = be similar to what we tried to say in the Base Spec with the simple and = advanced security models: =20 If you know that your PCP client implementation will only be used in = situations that have certain constraints (i.e. your B4 implementation is = running on ISP equipment), it is okay not to implement any crypto = security. However, we will probably want to mandate implementation of = an ACL in this case, so that one B4 can't make THIRD_PARTY requests that = affect another... This is just common sense, and I think we all assumed = the PCP Server on the AFTR would check the address range in THIRD_PARTY = requests, we just didn't say so in the document, perhaps because we = thought it was obvious. However if your PCP client implementation may run in other environments = (i.e. on a desktop PC), it is mandatory to implement (but not mandatory = to use) a cryptographic security mechanism. I think this would include = cases where a B4 runs in a separate administrative domain from its = AFTER, such as hosts that serve as their own B4s. It also follows that if a PCP Server wants to serve PCP Clients that run = in separate administrative domains, it will need to implement a = cryptographic security mechanism that can be used to authenticate those = B4s. An ACL would probably be fine for a typical AFTR, though, one that = only talks to B4s in the same ISP domain. Does that make sense? Margaret From dxhbupt@gmail.com Thu Mar 29 02:28:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3321F8966 for ; Thu, 29 Mar 2012 02:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 l4KTWD0Sq03s for ; Thu, 29 Mar 2012 02:28:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B24D821F895C for ; Thu, 29 Mar 2012 02:28:56 -0700 (PDT) Received: by eaaq11 with SMTP id q11so979529eaa.31 for ; Thu, 29 Mar 2012 02:28: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=0W+VboDypGceLclW+lQYkuD505FwlRkAXA6Tkm0j4Hk=; b=Ij9RqpY5us8Kp84zosSK+HrZxnISh2GKD/YcycnuYFEJ1s6D37+pxyXEaz4B3rYmAz MvV7NrQqoj1m565syPWVlYPcm/GfcgQvojrFej4a7WP9i13/+GfqeJsgn7cQAEK4CCL5 baHt64ku/QMzgLvRsMhdTH5BGGHnXnY2jn7RiZ9eJvUmWYh1qS3BBzrxKD11WhNxcrgq 74EQ5yBiDQBI2UC6UM3IyZbKh4NE/jGnYV3MVDIVB4jtqAXIdxk5FVm5ry03UjFv1dHc UK+nEjBEhLasT6mfLexU2l4Um3vITFutxzEaeDJsOBqoDlR2sskQnzAoQdgGiTgr9ZbB DWLQ== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr3795440wib.15.1333013335351; Thu, 29 Mar 2012 02:28:55 -0700 (PDT) Received: by 10.180.99.134 with HTTP; Thu, 29 Mar 2012 02:28:55 -0700 (PDT) Received: by 10.180.99.134 with HTTP; Thu, 29 Mar 2012 02:28:55 -0700 (PDT) In-Reply-To: <4F7426C2.4070207@viagenie.ca> References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> <4F7426C2.4070207@viagenie.ca> Date: Thu, 29 Mar 2012 17:28:55 +0800 Message-ID: From: Xiaohong Deng To: Simon Perreault Content-Type: multipart/alternative; boundary=f46d0444803555a27004bc5e5a7b Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:28:57 -0000 --f46d0444803555a27004bc5e5a7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for keep THIRD PARTY. Since both voice of keeping it and killing it existent and hear the majority of keeping =EF=BC=8Cdon't see a justice of k= illing it. =E5=9C=A8 2012-3-29 =E4=B8=8A=E5=8D=8810:09=EF=BC=8C"Simon Perreault" =E5=86=99=E9=81=93=EF=BC=9A > On 03/29/12 11:02, Margaret Wasserman wrote: > >> As I indicated to Wim, you are agreeing to a choice that is not >> available to us. We _can not_ publish the current PCP Base Spec as >> is. We need to make changes to address Stephen Farrell's discuss. >> > > "Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide range o= f > options available. It's not binary. We can tweak things a bit, try to > convince the AD with new arguments, etc. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.**ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > ______________________________**_________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/**listinfo/pcp > --f46d0444803555a27004bc5e5a7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1 for keep THIRD PARTY. Since both voice of keeping it and killing it e= xistent and hear the majority of keeping =EF=BC=8Cdon't see a justice o= f killing it.

=E5=9C=A8 2012-3-29 =E4=B8=8A=E5=8D=8810:09=EF= =BC=8C"Simon Perreault" <simon.perreault@viagenie.ca>=E5=86=99=E9=81=93=EF=BC=9A
On 03/29/12 11:02, Margaret Wasserman wrote:
As I indicated to Wim, you are agreeing to a choice that is not
available to us. =C2=A0We _can not_ publish the current PCP Base Spec as is. =C2=A0We need to make changes to address Stephen Farrell's discuss.=

"Discuss" means "discuss", not "kill THIRD_PARTY&q= uot;. There's a wide range of options available. It's not binary. W= e can tweak things a bit, try to convince the AD with new arguments, etc.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=
_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp
--f46d0444803555a27004bc5e5a7b-- From yoshihiro.ohba@toshiba.co.jp Thu Mar 29 02:29:33 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666F621F8993 for ; Thu, 29 Mar 2012 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, 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 LDahDG7Jm2mu for ; Thu, 29 Mar 2012 02:29:32 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5D521F8970 for ; Thu, 29 Mar 2012 02:29:31 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q2T9TVNc021843 for ; Thu, 29 Mar 2012 18:29:31 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q2T9TVaZ029935 for pcp@ietf.org; Thu, 29 Mar 2012 18:29:31 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA29934; Thu, 29 Mar 2012 18:29:31 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q2T9TUV7019532 for ; Thu, 29 Mar 2012 18:29:30 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q2T9TTlo006323; Thu, 29 Mar 2012 18:29:29 +0900 (JST) Received: from [133.199.18.206] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M1N00BAR3P3AV20@mail.po.toshiba.co.jp> for pcp@ietf.org; Thu, 29 Mar 2012 18:29:29 +0900 (JST) Date: Thu, 29 Mar 2012 18:29:10 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <4F742B66.4040104@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5B1B1F59-6383-4FF2-BC8D-B1B2769B3E7C@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 Subject: Re: [pcp] Confirming consensus from WG meetings (issue 3) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:29:33 -0000 (2012/03/29 18:11), Margaret Wasserman wrote: > > On Mar 29, 2012, at 11:05 AM, Alper Yegin wrote: >> , the WG draft shall not have any details about the use of EAP (e.g., section 5.4, 5.5., 5.7, etc.). >> That's the way to separate KMP from the I-D, and just leave PCP integrity protection in. >> And if this is done, I do support such an I-D as well. > > My understanding is that the draft would indicate that we have not decided between the two proposals that have presented to the WG: use of PCP over EAP (as described in our original non-WG document) or use of EAP over PANA (as described in your e-mail). > I agree that such statement is required indeed. *In addition*, any details on inband scheme that is the main part of conflict should not be included in a WG draft. Yoshihiro Ohba > Margaret > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From mrw@lilacglade.org Thu Mar 29 02:31:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3321F89CC for ; Thu, 29 Mar 2012 02:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Hm5nMvUHM8S5 for ; Thu, 29 Mar 2012 02:31:01 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22121F89BD for ; Thu, 29 Mar 2012 02:31:01 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 60A8620580; Thu, 29 Mar 2012 05:30:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Thu, 29 Mar 2012 11:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> To: Qiong X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:31:01 -0000 Hi Qiong, On Mar 29, 2012, at 11:05 AM, Qiong wrote: > +1 support. >=20 > We need to move forward asap. These two lines are mutually incompatible. The proposal to move THIRD_PARTY out of the Base Spec is a proposed way = forward to get the Base Spec published ASAP. Mohammed's proposal will involve _delaying_ the Base Spec until we can = resolve the blocking issues raised by Stephen Farrell. This would = probably involve blocking publication of the Base Spec until we have a = cryptographic security mechanism that is ready for RFC publication. Could you read my mail on this thread, and let us know which of the = available paths you would actually prefer? Thanks, Margaret From mrw@lilacglade.org Thu Mar 29 02:32:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34121F8734 for ; Thu, 29 Mar 2012 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 5mIfn+V-sX+b for ; Thu, 29 Mar 2012 02:32:16 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8960821F86DC for ; Thu, 29 Mar 2012 02:32:15 -0700 (PDT) Received: from dhcp-11b2.meeting.ietf.org (dhcp-11b2.meeting.ietf.org [130.129.17.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id D0B1820580; Thu, 29 Mar 2012 05:31:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-371531796 From: Margaret Wasserman In-Reply-To: Date: Thu, 29 Mar 2012 11:32:13 +0200 Message-Id: References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> <4F7426C2.4070207@viagenie.ca> To: Xiaohong Deng X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:32:17 -0000 --Apple-Mail-13-371531796 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 29, 2012, at 11:28 AM, Xiaohong Deng wrote: > +1 for keep THIRD PARTY. Since both voice of keeping it and killing it = existent and hear the majority of keeping =EF=BC=8Cdon't see a justice = of killing it. >=20 >=20 There is no proposal on the table to kill THIRD_PARTY. Margaret --Apple-Mail-13-371531796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

+1 for keep THIRD PARTY. Since = both voice of keeping it and killing it existent and hear the majority = of keeping =EF=BC=8Cdon't see a justice of killing = it.


There is no proposal on the table to = kill = THIRD_PARTY.

Margaret

= --Apple-Mail-13-371531796-- From alper.yegin@yegin.org Thu Mar 29 02:32:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6C321F8753 for ; Thu, 29 Mar 2012 02:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.296 X-Spam-Level: X-Spam-Status: No, score=-101.296 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, MANGLED_DIET=2.3, 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 qtxeK7VHrvdl for ; Thu, 29 Mar 2012 02:32:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 34EEB21F8734 for ; Thu, 29 Mar 2012 02:32:52 -0700 (PDT) Received: from [10.1.1.2] (odakk1.odakk.com [78.111.98.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmbFL-1SnLsz1vhz-00ZXHo; Thu, 29 Mar 2012 05:32:51 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Thu, 29 Mar 2012 12:32:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3F0EF867-E2F2-4731-B462-85758B9B0F2C@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <5B1B1F59-6383-4FF2-BC8D-B1B2769B3E7C@yegin.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:3Q2mmJGSOpSnB47YMpY1+3IAW1G7AIKk0i6pBRKhZWP lm5B9EfZ/OV59EQh8YIydXRwggdNv2TMjLDLTy7V710GzJ9JSq 0IlE0qEuL1GWt+7wntxEJaGHFOvRY/aLVsNC8gYNX0hJ1GkVZL m51Vw7hw5JXkCyr4agZXgcCkBKPBGBbHMPt/qateukyHAJjlr6 aIqbmlO9lkLrJQ1HXaIULwm2rhxMzY4FNf+6A+WUyECnlAMOgq hJyC5+v0ESgsw9jvscIQ2cQkaHL2FgXsPRzpYkWqPLOzXV+xMY 3tbdwRAD9pFhgdDIkdLnpPBmN5MEBkw+K07s4q5SCiHRauqtwV /MhHTItflEeGv5HvGNV9aB4CjqxiDuIsYNyS/XEgx Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings (issue 3) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:32:52 -0000 On Mar 29, 2012, at 12:11 PM, Margaret Wasserman wrote: >=20 > On Mar 29, 2012, at 11:05 AM, Alper Yegin wrote: >> , the WG draft shall not have any details about the use of EAP (e.g., = section 5.4, 5.5., 5.7, etc.). >> That's the way to separate KMP from the I-D, and just leave PCP = integrity protection in. >> And if this is done, I do support such an I-D as well. >=20 > My understanding is that the draft would indicate that we have not = decided between the two proposals that have presented to the WG: use of = PCP over EAP (as described in our original non-WG document) or use of = EAP over PANA (as described in your e-mail). >=20 There's no agreement on whether KMP shall be bundled up with PCP = integrity protection. There's no value in having discussions and = multiple solutions in the WG I-D. Let's split draft-wassermann-pcp-auth into two: 1. PCP integrity protection. 2. EAP-over-PCP based KMP for PCP It makes sense to make the 1st one a WG I-D. We can keep discussing 2 along with other alternatives. Regards, Alper > Margaret >=20 From dthaler@microsoft.com Thu Mar 29 02:45:28 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D721F88BC for ; Thu, 29 Mar 2012 02:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.879 X-Spam-Level: X-Spam-Status: No, score=-103.879 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 CacmZhpeAf+4 for ; Thu, 29 Mar 2012 02:45:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 89FF321F88B7 for ; Thu, 29 Mar 2012 02:45:27 -0700 (PDT) Received: from mail181-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 09:45:26 +0000 Received: from mail181-ch1 (localhost [127.0.0.1]) by mail181-ch1-R.bigfish.com (Postfix) with ESMTP id CDED11401C3; Thu, 29 Mar 2012 09:45:26 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zz9371I542M1432N4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail181-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail181-ch1 (localhost.localdomain [127.0.0.1]) by mail181-ch1 (MessageSwitch) id 1333014325825943_18136; Thu, 29 Mar 2012 09:45:25 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail181-ch1.bigfish.com (Postfix) with ESMTP id C3B66120052; Thu, 29 Mar 2012 09:45:25 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 09:45:25 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 09:45:16 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 02:45:15 -0700 From: Dave Thaler To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAAB/vHA= Date: Thu, 29 Mar 2012 09:45:14 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E7A49@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:45:28 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, March 29, 2012 10:15 AM > To: Dave Thaler; pcp@ietf.org > Subject: RE: Confirming consensus from WG meetings >=20 > Dear Dave, all, >=20 > I was one of the 2 who objected to remove the THIRD_PARTY Option from the > base spec. I maintain my objection because I see THIRD_PARTY as an > important feature: allow to instruct mappings for non pcp compliant > hosts/applications. >=20 > Adding a normative ref to draft-wasserman for the THIRD_PARTY is too stro= ng > IMHO. The major scenarios which driven so far the development of PCP do > not require authenticated PCP communications: why doing this for explicit > mapping while this is not required for implicit mappings! >=20 > I do not want to slow down the progress of PCP base spec but cutting the > important features from the base spec won't help too. >=20 > Cheers, > Med Thanks, though as you note this is not a new objection since you were at th= e meeting. That said, I'll remind folks that THIRD_PARTY is already optional, not mand= atory to implement, and hence in the consensus being confirmed, there will NOT b= e a normative ref to draft-wasserman. (If there were, it would hold up publica= tion which would defeat the purpose of moving it to a separate document.) -Dave From christian.jacquenet@orange.com Thu Mar 29 03:00:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8FB21F897A for ; Thu, 29 Mar 2012 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.451, 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 ObWSX+3-Ac+I for ; Thu, 29 Mar 2012 03:00:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A949921F8977 for ; Thu, 29 Mar 2012 03:00:43 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1DFE918C0B4; Thu, 29 Mar 2012 12:00:43 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 01A64238048; Thu, 29 Mar 2012 12:00:43 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 29 Mar 2012 12:00:40 +0200 From: To: Margaret Wasserman Date: Thu, 29 Mar 2012 12:00:38 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NiY/7XD/b/TcoRVmbh92vVX8tyAAB6drA Message-ID: <6509_1333015243_4F7432CB_6509_16387_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84C27@PUEXCB1C.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> In-Reply-To: <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.29.90323 Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:00:45 -0000 Hello Margaret, Thanks for your feedback - please see inline.=20 [snip] I think you are missing a key point of information here which is that Steph= en Farrell, one of the security ADs, currently has a blocking "DISCUSS" (an= IESG issue) outstanding against our document that requires that we provide= a stronger security solution that must be implemented when the THIRD_PARTY= option is implemented. CJ: I'm perfectly aware of that DISCUSS. Also, to be clear, the proposed change is not to eliminate THIRD_PARTY from= PCP. CJ: I also fully understand that.=20=20 The proposal is to move THIRD_PARTY (which is already optional in the Base = Spec) into a separate document, so that we can address the blocking issues = raised by Stephen Farrell, WITHOUT HOLDING UP THE BASE SPEC. We don't have= the alternative of leaving the base spec as-is and getting it published no= w. CJ: I'm not convinced this situation is that black and white. In the meanti= me, the clock's ticking and removing the THIRD PARTY from the base spec, je= opardizes the progress of several deployments this year because the referen= ce to the THIRD_PARTY standard (if any) will be missing.=20=20 Realistically, we only have two choices: 1) Keep THIRD_PARTY in the Base Spec, state that security is mandatory to i= mplement in PCP clients and servers that implement the optional THIRD_PARTY= option, and add a normative reference to a security mechanism in the Base = Spec. This option will DELAY RFC PUBLICATION OF THE BASE SPEC until the s= ecurity mechanism is also approved for publication as an RFC. OR 2) Move "THIRD_PARTY" to a new document and deal with the security issues t= here by normatively referencing a security mechanism and stating that it is= mandatory to implement (but not mandatory to deploy) whenever the THIRD_PA= RTY option is implemented. This option will allow us to PUBLISH THE BASE S= PEC AS AN RFC ASAP, and will not delay the THIRD_PARTY option any longer th= an it will be delayed, anyway. CJ: there is a high risk that the second option is a showstopper to short-t= erm deployments as far as vendors are concerned. The base spec was initiall= y due for May 2011. We're one year later, with several service providers wh= o not only need the base spec but also the THIRD_Party option as currently = documented in the -24 to ignite operational deployments. And I really think= that the IETF (let alone the AD who originated the DISCUSS) should take in= to account such operational concerns. Given those two choices, which one do you prefer? CJ: see above. > I think the -24 is in a sufficiently good shape to be published as is, wh= ereas DS-Lite scenarios remain one of the most straightforward use cases fo= r PCP applicability, and was actually a key driver for the initial base spe= c effort back in 2010. Everything about how to use PCP in DS-Lite is _also_ being moved to a separ= ate document. That document will include any special information about dep= loying PCP in the DS-Lite scenario and could (if we have WG consensus) say = that it is safe to implement THIRD_PARTY without a security mechanism in DS= -Lite equipment (B4s and AFTRs). CJ: fine, but that's not what I'm worried about.=20=20 Also, I think it is a bit limited to think of PCP as something that only se= rves the DS-Lite use case. CJ: let me assure you that I don't see myself as a limited mind.=20=20 NAT-PMP and UPNP-IGD are in widespread use today in non-DS-Lite situations,= and we expect that PCP will be widely deployed and used in those use cases= , as well. CJ: agreed and fair enough.=20=20 I believe that this is why THIRD_PARTY is optional instead of mandatory in = the Base Spec. CJ: right. And again, I don't think I demanded that the THIRD_PARTY should = become a mandatory feature. Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From dthaler@microsoft.com Thu Mar 29 03:28:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB521F8931 for ; Thu, 29 Mar 2012 03:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.876 X-Spam-Level: X-Spam-Status: No, score=-103.876 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 7ykfXmHVQq+K for ; Thu, 29 Mar 2012 03:28:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3421F8927 for ; Thu, 29 Mar 2012 03:28:51 -0700 (PDT) Received: from mail11-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 10:28:49 +0000 Received: from mail11-am1 (localhost [127.0.0.1]) by mail11-am1-R.bigfish.com (Postfix) with ESMTP id DB421420386; Thu, 29 Mar 2012 10:28:49 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail11-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail11-am1 (localhost.localdomain [127.0.0.1]) by mail11-am1 (MessageSwitch) id 1333016928658455_19418; Thu, 29 Mar 2012 10:28:48 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.238]) by mail11-am1.bigfish.com (Postfix) with ESMTP id 924A91000C2; Thu, 29 Mar 2012 10:28:48 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 10:28:47 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 10:28:28 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 03:28:28 -0700 From: Dave Thaler To: Margaret Wasserman , Tina TSOU Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAAIR7kQAAYz8AAA9jtYAAC/VEYA== Date: Thu, 29 Mar 2012 10:28:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E7B23@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr>, <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4800B1C0-F385-4134-801A-18231FC64190@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:28:53 -0000 Thanks Margaret. All these +1's are not useful, since they are +1'ing an option we don't hav= e (publish immediately as is). The options are: (1) Delay the Base Spec while we wait for security text that we have consen= sus on and that Stephen Farrell will be happy with, and that does not reference DS-lite. (This could take a very long time, as certainly this is not a to= pic that=20 is easy to get consensus on.) Note subtle wording different from Margaret's wording... this does not necessarily assume a security mechanism, but rather consensus on text stating under what instances it is "safe", where those instances require=20 no normative references to things not in the spec (for example, it must require no normative references to use of PCP with DS-lite). From discuss= ions with Stephen Farrell, this is not likely to be quick. (2) break out THIRD_PARTY so that the rest of the PCP Base Spec can be=20 published now? So those who didn't already make their point at the meeting should repeat their point in the context below. If you believe we shouldn't take it out, then it's ok to respond saying you= 'd support: "Delay the Base Spec while we wait for new consensus on safe non-DSlite cases" for example, but it better start with "Delay the Base Spec ..." -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Margaret Wasserman > Sent: Thursday, March 29, 2012 11:03 AM > To: Tina TSOU > Cc: pcp@ietf.org > Subject: Re: [pcp] Confirming consensus from WG meetings >=20 >=20 > Hi Tina, >=20 > On Mar 29, 2012, at 10:41 AM, Tina TSOU wrote: > > +1 >=20 > As I indicated to Wim, you are agreeing to a choice that is not available= to us. > We _can not_ publish the current PCP Base Spec as is. We need to make > changes to address Stephen Farrell's discuss. So, just publish the Base = Spec > as-is is not a choice we can make. >=20 > Given that fact, which of the options in my previous message would you li= ke > to see us pursue: (1) Delay the Base Spec while we wait for a security > mechanism to be approved, or (2) break out THIRD_PARTY so that the rest o= f > the PCP Base Spec can be published now? >=20 > Margaret >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Thu Mar 29 03:33:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA021F88DF for ; Thu, 29 Mar 2012 03:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.874 X-Spam-Level: X-Spam-Status: No, score=-103.874 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 CzjN3lPXgJI7 for ; Thu, 29 Mar 2012 03:33:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9721F8943 for ; Thu, 29 Mar 2012 03:33:32 -0700 (PDT) Received: from mail147-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 10:33:32 +0000 Received: from mail147-va3 (localhost [127.0.0.1]) by mail147-va3-R.bigfish.com (Postfix) with ESMTP id E9C281808B2; Thu, 29 Mar 2012 10:33:31 +0000 (UTC) X-SpamScore: -9 X-BigFish: VS-9(zz15bfK1432Nzz1202hzz8275bhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail147-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail147-va3 (localhost.localdomain [127.0.0.1]) by mail147-va3 (MessageSwitch) id 1333017210628483_2736; Thu, 29 Mar 2012 10:33:30 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.250]) by mail147-va3.bigfish.com (Postfix) with ESMTP id 892F21600AF; Thu, 29 Mar 2012 10:33:30 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 10:33:29 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 10:33:20 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 03:33:19 -0700 From: Dave Thaler To: "christian.jacquenet@orange.com" , Margaret Wasserman Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAEAOcgAACT20AAA24oRA= Date: Thu, 29 Mar 2012 10:33:19 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <6509_1333015243_4F7432CB_6509_16387_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84C27@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <6509_1333015243_4F7432CB_6509_16387_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84C27@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:33:34 -0000 christian.jacquenet@orange.com writes: > Hello Margaret, >=20 > Thanks for your feedback - please see inline. >=20 > [snip] >=20 > I think you are missing a key point of information here which is that Ste= phen > Farrell, one of the security ADs, currently has a blocking "DISCUSS" (an = IESG > issue) outstanding against our document that requires that we provide a > stronger security solution that must be implemented when the THIRD_PARTY > option is implemented. >=20 > CJ: I'm perfectly aware of that DISCUSS. >=20 > Also, to be clear, the proposed change is not to eliminate THIRD_PARTY fr= om > PCP. >=20 > CJ: I also fully understand that. >=20 > The proposal is to move THIRD_PARTY (which is already optional in the Bas= e > Spec) into a separate document, so that we can address the blocking issue= s > raised by Stephen Farrell, WITHOUT HOLDING UP THE BASE SPEC. We don't > have the alternative of leaving the base spec as-is and getting it publis= hed > now. >=20 > CJ: I'm not convinced this situation is that black and white. In the mean= time, > the clock's ticking and removing the THIRD PARTY from the base spec, > jeopardizes the progress of several deployments this year because the > reference to the THIRD_PARTY standard (if any) will be missing. > > Realistically, we only have two choices: >=20 > 1) Keep THIRD_PARTY in the Base Spec, state that security is mandatory to > implement in PCP clients and servers that implement the optional > THIRD_PARTY option, and add a normative reference to a security > mechanism in the Base Spec. This option will DELAY RFC PUBLICATION OF > THE BASE SPEC until the security mechanism is also approved for publicati= on > as an RFC. >=20 > OR >=20 > 2) Move "THIRD_PARTY" to a new document and deal with the security issues > there by normatively referencing a security mechanism and stating that it= is > mandatory to implement (but not mandatory to deploy) whenever the > THIRD_PARTY option is implemented. This option will allow us to PUBLISH > THE BASE SPEC AS AN RFC ASAP, and will not delay the THIRD_PARTY option > any longer than it will be delayed, anyway. >=20 > CJ: there is a high risk that the second option is a showstopper to short= -term > deployments as far as vendors are concerned. The base spec was initially = due > for May 2011. We're one year later, with several service providers who no= t > only need the base spec but also the THIRD_Party option as currently > documented in the -24 to ignite operational deployments. And I really thi= nk > that the IETF (let alone the AD who originated the DISCUSS) should take i= nto > account such operational concerns. Can you elaborate on the scenario that requires THIRD_PARTY without DS-lite? (If DS-lite, you're blocked on the DS-lite spec anyway so that's a non-issue here.) And further on what you believe the security solution is in said deployment= s? > Given those two choices, which one do you prefer? >=20 > CJ: see above. I looked above and couldn't find a preference for one of the two, only for an option that's not open to us. It does sound like your primary goal is to get THIRD_PARTY published asap, regardless of what document it's in. I didn't hear you providing reasons why it needs to be in the same spec, only a reason to not delay that option. Separating it out means the two can progress as soon as possible independently without one blocked on the other. =20 > > I think the -24 is in a sufficiently good shape to be published as is, = whereas > DS-Lite scenarios remain one of the most straightforward use cases for PC= P > applicability, and was actually a key driver for the initial base spec ef= fort back > in 2010. >=20 > Everything about how to use PCP in DS-Lite is _also_ being moved to a > separate document. That document will include any special information > about deploying PCP in the DS-Lite scenario and could (if we have WG > consensus) say that it is safe to implement THIRD_PARTY without a securit= y > mechanism in DS-Lite equipment (B4s and AFTRs). >=20 > CJ: fine, but that's not what I'm worried about. >=20 > Also, I think it is a bit limited to think of PCP as something that only = serves the > DS-Lite use case. >=20 > CJ: let me assure you that I don't see myself as a limited mind. >=20 > NAT-PMP and UPNP-IGD are in widespread use today in non-DS-Lite > situations, and we expect that PCP will be widely deployed and used in th= ose > use cases, as well. >=20 > CJ: agreed and fair enough. >=20 > I believe that this is why THIRD_PARTY is optional instead of mandatory i= n > the Base Spec. >=20 > CJ: right. And again, I don't think I demanded that the THIRD_PARTY shoul= d > become a mandatory feature. -Dave From fred@cisco.com Thu Mar 29 04:13:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9B21F8918; Thu, 29 Mar 2012 04:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 muV7EBu9VOPs; Thu, 29 Mar 2012 04:13:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C22F121F8915; Thu, 29 Mar 2012 04:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2650; q=dns/txt; s=iport; t=1333019626; x=1334229226; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=eiEEpiBhFrq15oDM8tu/rU6PEsE+27cz0e/Y2w1quRg=; b=SatdF+mJwiYjnLDgBcWxQKkIUSKUIYrDl0BJqQsHGyJUUuUoOH7fNiWe jOldwv0IttHKzjHlk3PdKTO7iI658cnOFlw8WMb57YXODqx5pWJ89LydX QjHBJ7xpOovKdXtre6U3Gd2iHrKdPAV0593qBwFVs/R1v6gAyUtS0GSQp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOdCdE+Q/khN/2dsb2JhbABEuQ+BB4IJAQEBAwESASc/BQsLEgYuSQ4GNYdjBZtpnx+QPGMElWGFb4hWgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="133709869" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2012 11:13:43 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-55-81-200.cisco.com [10.55.81.200]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBDgcm031225; Thu, 29 Mar 2012 11:13:42 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Thu, 29 Mar 2012 13:13:43 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Thu, 29 Mar 2012 13:13:43 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> Date: Thu, 29 Mar 2012 13:13:28 +0200 Message-Id: <947EA806-8E8B-47FF-9662-83210441C19E@cisco.com> References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, 6man 6man Subject: Re: [pcp] You asked about multicast scope X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:13:47 -0000 On Mar 29, 2012, at 12:02 PM, Iljitsch van Beijnum wrote: > On 28 Mar 2012, at 12:08 , Fred Baker wrote: >=20 >>> I haven't read the spec yet, but isn't PCP supposed to work in the = service provider run NAT64/CGN case, too? In that case, the multicasts = need to escape out of the site or even organization to reach the service = provider at least in the SOHO case. So this would be a scope just shy of = global, maybe a new "service provider" scope? >=20 >> I personally rarely use "zero configuration" and "service provider" = in the same sentence... >=20 > Am I understanding you correctly when I take that to mean that the = admin (value 4) scope is appropriate because then the people running the = multicast routing can determine exactly how far these packets travel? >=20 > That makes sense, but there is one potential issue, that I think some = people who are well-steeped in IPv6 multicast should look at: in this = situation, the scope value 4 may need wider distribution than side-wide, = which is scope 5. I can't find any documentation on whether that's ok or = not between sessions right now, but I'm reluctant to assume that a lower = scope value can have wider distribution than a higher one without having = a spec that explicitly says so or hearing from some implementers. I imagine. Note that the document actually says "organization scope". The non-boilerplate part of the document contains 44 sentences; three of = them, in sections 4 and 5, mention the specifics of the scope. Is it = fair to assume that you have no issue with the remaining sentences? 4. IANA Considerations This note requests of the IANA the assignment of a set of multicast addresses as described in Section 2.7 of the IP Version 6 Addressing Architecture [RFC4291] from the registry [v6mult]. This set of addresses is referred to as "ALL-NPTv6-TRANSLATORS". One address should be assigned for each of the following scopes: Link-Local, Admin-Local, Site-Local, and Organization-Local. 5. Operational Considerations This document defines a set of multicast addresses in several scopes. Operationally, the choice of which scope is appropriate is made by the administration. A reasonable default value in system configurations might be Organization-Local (e.g., all NPTv6 Translators operated by the organization). However, a large organization might well choose Site-Local or Admin-Local, and consider that "site" or "administrative" domain to include the set of NPTv6 Translators advertising a default route into a specific part of its network. From wim.henderickx@alcatel-lucent.com Thu Mar 29 04:21:51 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F521F896D for ; Thu, 29 Mar 2012 04:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.881 X-Spam-Level: X-Spam-Status: No, score=-8.881 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 nPpwYVEn4NTa for ; Thu, 29 Mar 2012 04:21:50 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB721F896A for ; Thu, 29 Mar 2012 04:21:50 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2TBLjU8019989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 13:21:47 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Mar 2012 13:21:46 +0200 From: "Henderickx, Wim (Wim)" To: Margaret Wasserman Date: Thu, 29 Mar 2012 13:21:48 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NihdgWdOv6E70S2upEbUNgR8g6QAE8uZg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E1DF09E1@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D67E1DE4CF7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:21:51 -0000 Margeret, My proposal is to keep THIRD PARTY in the base spec and mandate simple secu= rity using ACLs as a mandatory solution. The full security should come in a= nother document. Wim -----Original Message----- From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 Sent: donderdag 29 maart 2012 10:58 To: Henderickx, Wim (Wim) Cc: 'christian.jacquenet@orange.com'; 'mohamed.boucadair@orange.com'; 'dtha= ler@microsoft.com'; 'pcp@ietf.org' Subject: Re: [pcp] Confirming consensus from WG meetings Hi Wim, As I said in my response to Christian, we do not have the option of publish= ing the Base Specification now with the THIRD_PARTY option in it and no man= datory-to-implement security mechanism. We either need to add a normative = reference to a security mechanism to the Base Spec (and wait for the securi= ty mechanism to be approved before we publish the Base Spec), or break the = THIRD_PARTY option out in to a separate document (that will normatively ref= erence a security mechanism), so that we can get the rest of the Base Spec = published now. Could you please read my response to Christian (my previous message to PCP)= , and let me know which of the two choices listed in that message you would= actually prefer? Thanks, Margaret On Mar 29, 2012, at 10:30 AM, Henderickx, Wim (Wim) wrote: > +1 >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: christian.jacquenet@orange.com [mailto:christian.jacquenet@orange.c= om] > Sent: Thursday, March 29, 2012 10:29 AM > To: BOUCADAIR Mohamed OLNC/NAD/TIP ; Dave T= haler ; pcp@ietf.org > Subject: Re: [pcp] Confirming consensus from WG meetings >=20 > Dave, all, >=20 > I'd like to second Med's comment.=20 >=20 > I'm too opposed to motion #1 below, especially in light of the need for t= he THIRD_PARTY option for DS-Lite deployments that will start in a couple o= f months from now as far as some service providers are concerned. The secur= ity concerns that have been raised so far do not apply to DS-Lite scenarios= , as reminded by Med below. >=20 > I think the -24 is in a sufficiently good shape to be published as is, wh= ereas DS-Lite scenarios remain one of the most straightforward use cases fo= r PCP applicability, and was actually a key driver for the initial base spe= c effort back in 2010. >=20 > Simply ignoring what becomes a fact in the very short term because of sec= urity considerations that do not apply to such use case is not a good enoug= h reason for me to defer the standardization of the THIRD PARTY at who-know= s-when. >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de moh= amed.boucadair@orange.com > Envoy=E9 : jeudi 29 mars 2012 10:15 > =C0 : Dave Thaler; pcp@ietf.org > Objet : Re: [pcp] Confirming consensus from WG meetings >=20 > Dear Dave, all, >=20 > I was one of the 2 who objected to remove the THIRD_PARTY Option from the= base spec. I maintain my objection because I see THIRD_PARTY as an importa= nt feature: allow to instruct mappings for non pcp compliant hosts/applicat= ions. =20 >=20 > Adding a normative ref to draft-wasserman for the THIRD_PARTY is too stro= ng IMHO. The major scenarios which driven so far the development of PCP do = not require authenticated PCP communications: why doing this for explicit m= apping while this is not required for implicit mappings! >=20 > I do not want to slow down the progress of PCP base spec but cutting the = important features from the base spec won't help too.=20 >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de=20 >> Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp@ietf.org Objet= :=20 >> [pcp] Confirming consensus from WG meetings >>=20 >> We got consensus among those at the meetings on the following, and want= =20 >> to confirm WG consensus on the list, in case there are new objections=20 >> raised or folks who were not present in the room at the time. >>=20 >> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2=20 >> against) >> This would resolve Stephen Farrell's discuss, allowing the base spec >> to be published quickly. The alternative would likely=20 >> take a lot more >> time to address, especially given that we already moved DS-lite >> discussion out of the base spec, and the DS-lite scenario was a key >> motivation for THIRD_PARTY. >>=20 >> 2) Add a client-specified per-mapping nonce (no strong objections) >> Belief is this is needed to resolve the transaction ID discuss's. >> WG will not add a transaction id, but will add a per-mapping >> nonce instead. >>=20 >> 3) Without having resolved the question of inline vs PANA first, adopt=20 >> draft-wasserman-pcp-authentication as a working group document >> (12 in favor, 3 against) >> This would be the basis of the pcp security document. Belief is >> that much of the current document is independent of the=20 >> unresolved question on the table, and the WG draft should >> be agnostic on that question. >>=20 >> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus >> among those who've read it) >>=20 >> Barring new objections that were not raised at the meeting, we plan to=20 >> go forward with the above consensus items. >>=20 >> -Dave >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Thu Mar 29 04:31:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8055821F886E for ; Thu, 29 Mar 2012 04:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.341 X-Spam-Level: X-Spam-Status: No, score=-10.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y-FVDRKqRvg for ; Thu, 29 Mar 2012 04:31:56 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A185B21F88B9 for ; Thu, 29 Mar 2012 04:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=716; q=dns/txt; s=iport; t=1333020716; x=1334230316; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tJULXRzvSiQrEXHtAWHtSwpCP4+NCgrhzC/12VWmwWE=; b=g3HDpfrMDqFCj2z1l6G7DkSFm82XzaAsOUXEzXpZPB7t6CYUNzGT3JXq 70PoaOxa52/mOgZRlZ+XaEVJh3WfOu7z8cGOle9UY0CDE1VIr1YedNb4e wFN410sW7LjxVey6xQqPkXvQ9DyKv2eQjaurVAZf6udC+zVK0rm0i1ju4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUGABpHdE+rRDoH/2dsb2JhbABEgw62AYEHghASAScCATwTCA6BDwYBDQUih2eba58hkR8EiFiNCYVviFaBaIMH X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="35074253" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Mar 2012 11:31:56 +0000 Received: from [10.21.89.103] (sjc-vpn5-359.cisco.com [10.21.89.103]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBVell005539; Thu, 29 Mar 2012 11:31:46 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 29 Mar 2012 04:31:40 -0700 From: Reinaldo Penno To: Dave Thaler , "christian.jacquenet@orange.com" , Margaret Wasserman Message-ID: Thread-Topic: [pcp] Confirming consensus from WG meetings In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:31:57 -0000 The subscriber web portal case since CPEs and hosts will take quite some time to be PCP ready. Subscriber accesses an ISP provided mapping/port forwarding portal. This portal (in full control of ISP) talks PCP to CGN to install mappings. PCP Client 9web portal) and CGN are within ISP's administrative domain. I mentioned this case explicitly in the last IETF meeting and asked if security was needed. WG (chair) answer at the time was no. Thanks, Reinaldo On 3/29/12 3:33 AM, "Dave Thaler" wrote: >Can you elaborate on the scenario that requires THIRD_PARTY without >DS-lite? (If DS-lite, you're blocked on the DS-lite spec anyway so >that's >a non-issue here.) From mohamed.boucadair@orange.com Thu Mar 29 04:46:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B721F89D0 for ; Thu, 29 Mar 2012 04:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.049, 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 uaxu9Z7hShfP for ; Thu, 29 Mar 2012 04:46:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7D921F8973 for ; Thu, 29 Mar 2012 04:46:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4F6683B4493; Thu, 29 Mar 2012 13:46:30 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 34B744C073; Thu, 29 Mar 2012 13:46:30 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 29 Mar 2012 13:46:30 +0200 From: To: Dave Thaler , JACQUENET Christian OLNC/NAD/TIP , Margaret Wasserman Date: Thu, 29 Mar 2012 13:46:28 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAEAOcgAACT20AAA24oRAAGMbqcA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E287337B3@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <6509_1333015243_4F7432CB_6509_16387_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84C27@PUEXCB1C.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:46:32 -0000 =20 >-----Message d'origine----- >De : Dave Thaler [mailto:dthaler@microsoft.com]=20 >Envoy=E9 : jeudi 29 mars 2012 12:33 >=C0 : JACQUENET Christian OLNC/NAD/TIP; Margaret Wasserman >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Objet : RE: [pcp] Confirming consensus from WG meetings >>=20 >> CJ: there is a high risk that the second option is a=20 >showstopper to short-term >> deployments as far as vendors are concerned. The base spec=20 >was initially due >> for May 2011. We're one year later, with several service=20 >providers who not >> only need the base spec but also the THIRD_Party option as currently >> documented in the -24 to ignite operational deployments. And=20 >I really think >> that the IETF (let alone the AD who originated the DISCUSS)=20 >should take into >> account such operational concerns. > >Can you elaborate on the scenario that requires THIRD_PARTY without >DS-lite? (If DS-lite, you're blocked on the DS-lite spec=20 >anyway so that's >a non-issue here.) > Med: Please refer to: http://www.ietf.org/mail-archive/web/pcp/current/msg0= 1981.html= From dwing@cisco.com Thu Mar 29 05:06:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6021F8A3E for ; Thu, 29 Mar 2012 05:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.166 X-Spam-Level: X-Spam-Status: No, score=-109.166 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8, 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 XZSR2RViyOqj for ; Thu, 29 Mar 2012 05:06:55 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 569DC21F8A2D for ; Thu, 29 Mar 2012 05:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2230; q=dns/txt; s=iport; t=1333022815; x=1334232415; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=w3zLBGDJ83+L4W3i0CUewpDocim42aoXNvGP1c2Tn90=; b=SZOnoyN8Xjy09XuJyGiuT0pi9g0G0I8hyEZQ0Vj4nE8DyAFq4/+5Tqm3 im+0SvwQ2AWkp0Vd6xlOMBYiTf6NGEjutyx/UH2iY03kdpTy4Eg2Nglqo 6tMa+ItjaeLqgTN80OxNDkK3TIle0H0bz1M7KcuBv3ww28Q8R5xnOrLgD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOdPdE+rRDoH/2dsb2JhbABEqTKPXYEHggkBAQEDAQEBAQUKARQDEDQQBwEDAgkOAQIEAQEoBxkOFQoJCAEBBAESCxeHYwQMm2GfIYpthjIEjWuJB400gWiCaYFSAhc X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="38193562" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 29 Mar 2012 12:06:54 +0000 Received: from dwingWS (sjc-vpn4-197.cisco.com [10.21.80.197]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TC6qW1002869; Thu, 29 Mar 2012 12:06:53 GMT From: "Dan Wing" To: "'Mayuresh Bakshi'" , References: In-Reply-To: Date: Thu, 29 Mar 2012 14:06:52 +0200 Message-ID: <027b01cd0da4$6e2a5c80$4a7f1580$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0NKQGq/MLev/q9T3eZv3RH1VnF1wAerszw Content-Language: en-us Subject: Re: [pcp] race condition between prefer-failure and map update X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:06:56 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Mayuresh Bakshi > Sent: Wednesday, March 28, 2012 11:23 PM > To: pcp@ietf.org > Subject: [pcp] race condition between prefer-failure and map update > > > I am trying to interpret below in section 13.2: > > > There can exist a race condition between the MAP Opcode using the > PREFER_FAILURE option and Mapping Update (Section > 14.2). > Because of > this, the PCP client MUST validate that the External IP Address and > Port in a success response matches the associated suggested values > from the request. If they don't match, it is because the Mapping > Update was sent before the MAP request was processed. If the PCP > server has no use for this new mapping, it SHOULD delete the > mapping. > > > What is PCP server supposed to do when PREFER_FAILURE option packet is > received after MAP update AND PREFER_FAILURE suggested external IP and > port doesn;t match that of earlier map update. > > -> Return 'CANNOT_PROVIDE_EXTERNAL' OR Right. > -> Treat it as refresh (lifetime) for the internal IP and port > and send response with already assigned external IP and port (different > than those in PREFER-FAILURE option packet) That would violate the semantics of PREFER_FAILURE. > Last statement looks little ambiguous, 'If the PCP server has no use > for this new mapping, it SHOULD delete the mapping', is PCP server > expected to delete mapping created thru update OR is it client who > should send delete for this mapping and resend PREFER_FAILURE option > packet? That is fixed in -25 (which is not yet published), which says that the PCP client does that deletion if the PCP client doesn't have use for the created mapping. (Most of the time, the PCP client will have a use for the mapping, which is why PREFER_FAILURE is nearly always unnecessary and just causes an additional PCP round trip.) -d > > -Mayuresh > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Thu Mar 29 05:36:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23521F8ADE for ; Thu, 29 Mar 2012 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.872 X-Spam-Level: X-Spam-Status: No, score=-103.872 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 Rd8-Iw0zh0Yl for ; Thu, 29 Mar 2012 05:36:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id A975321F8AD2 for ; Thu, 29 Mar 2012 05:36:52 -0700 (PDT) Received: from mail76-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 12:36:51 +0000 Received: from mail76-ch1 (localhost [127.0.0.1]) by mail76-ch1-R.bigfish.com (Postfix) with ESMTP id BE6B23A0598; Thu, 29 Mar 2012 12:36:51 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zzbb2dI9371I542M1432N98dK4015Izz1202hzz1033IL8275bh8275dhz2fh668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail76-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1 (MessageSwitch) id 1333024609857414_4508; Thu, 29 Mar 2012 12:36:49 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail76-ch1.bigfish.com (Postfix) with ESMTP id CB84A2009D; Thu, 29 Mar 2012 12:36:49 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 12:36:49 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 12:36:02 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 05:36:02 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 05:36:02 -0700 From: Dave Thaler To: Reinaldo Penno , "christian.jacquenet@orange.com" , Margaret Wasserman Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0NgYjs0ngUQJVfTgm6A2RN04bPqAAAObzAAABuwYAAEAOcgAACT20AAA24oRD//6uqAIAAY2PQ Date: Thu, 29 Mar 2012 12:36:02 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E7FD0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:36:53 -0000 Thanks Reinaldo. > -----Original Message----- > From: Reinaldo Penno [mailto:repenno@cisco.com] > Sent: Thursday, March 29, 2012 1:32 PM > To: Dave Thaler; christian.jacquenet@orange.com; Margaret Wasserman > Cc: pcp@ietf.org > Subject: Re: [pcp] Confirming consensus from WG meetings >=20 > The subscriber web portal case since CPEs and hosts will take quite some = time > to be PCP ready. >=20 > Subscriber accesses an ISP provided mapping/port forwarding portal. This > portal (in full control of ISP) talks PCP to CGN to install mappings. PCP= Client > 9web portal) and CGN are within ISP's administrative domain. I mentioned > this case explicitly in the last IETF meeting and asked if security was n= eeded. > WG (chair) answer at the time was no. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > On 3/29/12 3:33 AM, "Dave Thaler" wrote: >=20 > >Can you elaborate on the scenario that requires THIRD_PARTY without > >DS-lite? (If DS-lite, you're blocked on the DS-lite spec anyway so > >that's > >a non-issue here.) >=20 >=20 From diego@tid.es Thu Mar 29 05:52:41 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372B321F88C7 for ; Thu, 29 Mar 2012 05:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 JFwKijm05wyo for ; Thu, 29 Mar 2012 05:52:40 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0721F85CF for ; Thu, 29 Mar 2012 05:52:37 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1N00GY8D3NBE@tid.hi.inet> for pcp@ietf.org; Thu, 29 Mar 2012 14:52:35 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 79.92.03017.31B547F4; Thu, 29 Mar 2012 14:52:35 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M1N00GY3D3NBE@tid.hi.inet> for pcp@ietf.org; Thu, 29 Mar 2012 14:52:35 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 29 Mar 2012 14:52:35 +0200 Date: Thu, 29 Mar 2012 14:52:33 +0200 From: DIEGO LOPEZ GARCIA In-reply-to: To: "mohamed.boucadair@orange.com" , GangChen Message-id: <3F416ADE-B495-406D-A1A9-DCEF63361029@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [pcp] Is it the right place to document something for PCP in mobile network Thread-index: Ac0Nqs+usaG85Z/LR92kSIMOiLLTuA== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f0c6d000000bc9-5a-4f745b130be9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXCFe/ApSscXeJvsPSDvsXkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbBTu+Azd8XptoWsDYzXOLsYOTkkBEwkJvR/ZIOwxSQu3FsP ZHNxCAlsZJT48ektM4TznVFi1+HXUJlGRonj+y6zgrSwCKhKTN/7ignEZhNQl2g5+o0FxBYW iJK4/fwcO4jNKRAs8WPiWrC4iECixKFpt8DizAKKElPfHwObwytgKfF4wz0WCFtQ4sdkCJtZ QEei9/s3ZghbXKK59SZUXFviybsLYL2MQGd/P7WGCWJ+tMTaaU+hdulJNH07wgZRIypxp309 I8SbAhJL9pxnhrBFJV4+/scK8dhrRomVxw+zT2AUn4XkjllI7piF5I5ZSO5YwMiyilGsOKko Mz2jJDcxMyfdwFAvI1MvMy+1ZBMjJJIydjAu36lyiFGAg1GJh3eCc7G/EGtiWXFl7iFGSQ4m JVFehqgSfyG+pPyUyozE4oz4otKc1OJDjBIczEoivMcjgHK8KYmVValF+TApGQ4OJQleW5A2 waLU9NSKtMwcYLqASTNxcIK08wC1G4LU8BYXJOYWZ6ZD5E8xSkqJ82qDJARAEhmleXC9rxjF gY4U5pUHyfIAExtc1yuggUxAA5l5wQaWJCKkpBoYVy7/5s3OUjN9b6ru7tXd9xauV0x+17Y5 1epJ2+ySaf/nzU6bxrFxi86+g0ybAns7pnRaV5nN4+SQdP0/bfPkdr8TYkyPLbsbHWsd2eeo vluVdG7h0b0OXydv12R83ff3sxvj3zT+tRe09jDuvTbzxYvz83Z8WsuisvXQX/4Thyof3PY8 e5H/uaMSS3FGoqEWc1FxIgA+lp6hKQMAAA== References: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> Cc: "pcp@ietf.org" Subject: Re: [pcp] Is it the right place to document something for PCP in mobile network X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:52:41 -0000 2012/3/28, mohamed.boucadair@orange.com : > Hi Gang, all, > > I do personally think it is valuable to have this document as Information= al. > > As mentioned by Gang, we have tried in the past to initiate a study item > within 3GPP but this was not successful because there is (surprisingly) n= o > function to be controlled by PCP (!!!) > > Since we are aware there are plenty functions (e.g., NAT) which may benef= it > from the help of PCP to achieve goals such as better application experien= ce, > better battery utilization, etc, a document dealing with some of mobile > considerations is needed. > > Having a document covering PCP-related considerations in mobile networks > would provide a pointer for operators to be included in their UE profile > requirements. Of course, the document need restrict the scope to major > issues (e.g., PCP Server Discovery). +1 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From mrw@lilacglade.org Thu Mar 29 06:34:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1421F8B7F for ; Thu, 29 Mar 2012 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 CTiyg5j6NRhF for ; Thu, 29 Mar 2012 06:34:16 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4464821E8028 for ; Thu, 29 Mar 2012 06:34:16 -0700 (PDT) Received: from dhcp-43e9.meeting.ietf.org (dhcp-43e9.meeting.ietf.org [130.129.67.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 1152820244; Thu, 29 Mar 2012 09:33:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E287337B3@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 29 Mar 2012 15:34:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4E721E@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E2873365F@PUEXCB1B.nanterre.francetelecom.fr> <31993_1333009764_4F741D64_31993_19_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84B09@PUEXCB1C.nanterre.francetelecom.fr> <9D6F7B96-D797-4A50-84F8-D7BFA9CDAF97@lilacglade.org> <6509_1333015243_4F7432CB_6509_16387_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C84C27@PUEXCB1C.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B4E7B51@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E287337B3@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:34:17 -0000 On Mar 29, 2012, at 1:46 PM, = wrote: >> Can you elaborate on the scenario that requires THIRD_PARTY without >> DS-lite? (If DS-lite, you're blocked on the DS-lite spec=20 >> anyway so that's >> a non-issue here.) My understanding is that 3rd party will be used for all sorts of proxies = (UPNP-to-PCP proxies and PCP-to-PCP proxies), not just for the PCP = proxies in an ISP-controlled B4 device. Margaret From ovautrin@juniper.net Thu Mar 29 06:57:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AD521F85FD for ; Thu, 29 Mar 2012 06:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 SXI7TO17RubR for ; Thu, 29 Mar 2012 06:57:23 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7242D21F85CC for ; Thu, 29 Mar 2012 06:57:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RqQcRO1erJ09BhvDv26BXnR7UN7uB/@postini.com; Thu, 29 Mar 2012 06:57:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 29 Mar 2012 06:57:06 -0700 From: Olivier Vautrin To: "pcp@ietf.org" Date: Thu, 29 Mar 2012 06:57:10 -0700 Thread-Topic: [pcp] Confirming consensus from WG meetings Thread-Index: Ac0Ns9OF/OpIYa1RQLO3SX4Zs8T5GA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Confirming consensus from WG meetings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:57:25 -0000 This would be my proposal as well. The THIRD_PARTY option will be in use in all our first deployments of PCP, I don't see how we could have a working solution today without it. ACL/Filters should be a good enough protection. /Olivier On 3/29/12 3:45 PM, "Olivier Vautrin" wrote: >Margeret, > >My proposal is to keep THIRD PARTY in the base spec and mandate simple >security using ACLs as a mandatory solution. The full security should come >in another document. > >Wim > >-----Original Message----- >From: Margaret Wasserman [mailto:mrw at lilacglade.org] >Sent: donderdag 29 maart 2012 10:58 >To: Henderickx, Wim (Wim) >Cc: 'christian.jacquenet at orange.com'; 'mohamed.boucadair at >orange.com'; 'dthaler at microsoft.com'; 'pcp at ietf.org' >Subject: Re: [pcp] Confirming consensus from WG meetings > > >Hi Wim, > >As I said in my response to Christian, we do not have the option of >publishing the Base Specification now with the THIRD_PARTY option in it >and no mandatory-to-implement security mechanism. We either need to add a >normative reference to a security mechanism to the Base Spec (and wait for >the security mechanism to be approved before we publish the Base Spec), or >break the THIRD_PARTY option out in to a separate document (that will >normatively reference a security mechanism), so that we can get the rest >of the Base Spec published now. > >Could you please read my response to Christian (my previous message to >PCP), and let me know which of the two choices listed in that message you >would actually prefer? > >Thanks, >Margaret > > >On Mar 29, 2012, at 10:30 AM, Henderickx, Wim (Wim) wrote: > >> +1 >>=20 >> Cheers, >> Wim >> _________________ >> sent from blackberry >>=20 >> ----- Original Message ----- >> From: christian.jacquenet at orange.com [mailto:christian.jacquenet at >>orange.com] >> Sent: Thursday, March 29, 2012 10:29 AM >> To: BOUCADAIR Mohamed OLNC/NAD/TIP ; >>Dave Thaler ; pcp at ietf.org >> Subject: Re: [pcp] Confirming consensus from WG meetings >>=20 >> Dave, all, >>=20 >> I'd like to second Med's comment. >>=20 >> I'm too opposed to motion #1 below, especially in light of the need for >>the THIRD_PARTY option for DS-Lite deployments that will start in a >>couple of months from now as far as some service providers are concerned. >>The security concerns that have been raised so far do not apply to >>DS-Lite scenarios, as reminded by Med below. >>=20 >> I think the -24 is in a sufficiently good shape to be published as is, >>whereas DS-Lite scenarios remain one of the most straightforward use >>cases for PCP applicability, and was actually a key driver for the >>initial base spec effort back in 2010. >>=20 >> Simply ignoring what becomes a fact in the very short term because of >>security considerations that do not apply to such use case is not a good >>enough reason for me to defer the standardization of the THIRD PARTY at >>who-knows-when. >>=20 >> Cheers, >>=20 >> Christian. >>=20 >> -----Message d'origine----- >> De : pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] De la part >>de mohamed.boucadair at orange.com >> Envoy=E9 : jeudi 29 mars 2012 10:15 >> =C0 : Dave Thaler; pcp at ietf.org >> Objet : Re: [pcp] Confirming consensus from WG meetings >>=20 >> Dear Dave, all, >>=20 >> I was one of the 2 who objected to remove the THIRD_PARTY Option from >>the base spec. I maintain my objection because I see THIRD_PARTY as an >>important feature: allow to instruct mappings for non pcp compliant >>hosts/applications. >>=20 >> Adding a normative ref to draft-wasserman for the THIRD_PARTY is too >>strong IMHO. The major scenarios which driven so far the development of >>PCP do not require authenticated PCP communications: why doing this for >>explicit mapping while this is not required for implicit mappings! >>=20 >> I do not want to slow down the progress of PCP base spec but cutting the >>important features from the base spec won't help too. >>=20 >> Cheers, >> Med=20 >>=20 >>> -----Message d'origine----- >>> De : pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] De la >>>part de=20 >>> Dave Thaler Envoy=E9 : jeudi 29 mars 2012 10:00 =C0 : pcp at ietf.org O= bjet >>>:=20 >>> [pcp] Confirming consensus from WG meetings >>>=20 >>> We got consensus among those at the meetings on the following, and want >>> to confirm WG consensus on the list, in case there are new objections >>> raised or folks who were not present in the room at the time. >>>=20 >>> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2 >>> against) >>> This would resolve Stephen Farrell's discuss, allowing the base spec >>> to be published quickly. The alternative would likely >>> take a lot more >>> time to address, especially given that we already moved DS-lite >>> discussion out of the base spec, and the DS-lite scenario was a key >>> motivation for THIRD_PARTY. >>>=20 >>> 2) Add a client-specified per-mapping nonce (no strong objections) >>> Belief is this is needed to resolve the transaction ID discuss's. >>> WG will not add a transaction id, but will add a per-mapping >>> nonce instead. >>>=20 >>> 3) Without having resolved the question of inline vs PANA first, adopt >>> draft-wasserman-pcp-authentication as a working group document >>> (12 in favor, 3 against) >>> This would be the basis of the pcp security document. Belief is >>> that much of the current document is independent of the >>> unresolved question on the table, and the WG draft should >>> be agnostic on that question. >>>=20 >>> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus >>> among those who've read it) >>>=20 >>> Barring new objections that were not raised at the meeting, we plan to >>> go forward with the above consensus items. >>>=20 >>> -Dave >>>=20 From fred@cisco.com Thu Mar 29 14:31:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846CE21E8082; Thu, 29 Mar 2012 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ONWmINEC-KkN; Thu, 29 Mar 2012 14:31:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0221E801F; Thu, 29 Mar 2012 14:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1069; q=dns/txt; s=iport; t=1333056674; x=1334266274; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=y92Sah817gY/LhuwhElPkN5uduQx8daL4nB9DW1riII=; b=gpBrOTbJ6dJltPNM1sasHzIg74PItp2bHq6IpD8PlILzjjjvqG8ueh3O vUOuLGMU7/WMIx/sUUT4uaTHRyFLeNtISxyFdwAuXlOI+VyVKxzdqX8P8 DQT810DNNY6peaw7Km4RzFEwyY/zy7biaLt9kh0g/3OMkMm3bVcUosPG+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIHTdE+Q/khL/2dsb2JhbABCuSWBB4IJAQEBAwESASc/BQsLEgYuSQ4GNYdjBZ9Tlz+QKmMElWGFcIhWgWiCaQ X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="69692796" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 21:31:08 +0000 Received: from dhcp-478d.meeting.ietf.org (ams3-vpn-dhcp4703.cisco.com [10.61.82.94]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TLQWuE023974; Thu, 29 Mar 2012 21:31:08 GMT Received: from [127.0.0.1] by dhcp-478d.meeting.ietf.org (PGP Universal service); Thu, 29 Mar 2012 23:31:08 +0200 X-PGP-Universal: processed; by dhcp-478d.meeting.ietf.org on Thu, 29 Mar 2012 23:31:08 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> Date: Thu, 29 Mar 2012 23:31:07 +0200 Message-Id: References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> <4F74447E.6020506@venaas.com> <4F74526D.6070003@innovationslab.net> <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , pcp@ietf.org, 6man 6man Subject: Re: [pcp] You asked about multicast scope X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:31:15 -0000 On Mar 29, 2012, at 2:52 PM, Iljitsch van Beijnum wrote: > On 29 Mar 2012, at 14:15 , Brian Haberman wrote: >=20 >> It is not an assumption, it is stately quite clearly in the Scoped = Addressing Architecture (RFC 4007). =46rom Section 5 : >=20 >> A zone of a given scope (less than global) falls completely = within >> zones of larger scope. That is, a smaller scope zone cannot >> include more topology than would any larger scope zone with which >> it shares any links or interfaces. >=20 > Brian, Stig, thanks for the help. >=20 > Fred: I think what would be best is to define a "service provider" = scope that is smaller than global, and larger than organization. These = would be defined to be forwarded to ISPs by default, although = organizations that don't want that can always filter them at the desired = boundary. >=20 > That way, the clients can always use a fixed scope =3D fixed multicast = group, avoiding the need for discovery or configuration here. I don't think this is a service provider discussion.= From bingxuere@gmail.com Fri Mar 30 00:59:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2A021F87A8 for ; Fri, 30 Mar 2012 00:59:31 -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 t-V0V6szHJxt for ; Fri, 30 Mar 2012 00:59:31 -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 E47DE21F87AB for ; Fri, 30 Mar 2012 00:59:30 -0700 (PDT) Received: by iazz13 with SMTP id z13so754841iaz.31 for ; Fri, 30 Mar 2012 00:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RxuQhF8VXIdlWkM2Ias7nbWuXp2WbRccubl2mREL5zk=; b=qVOXEztfia9fQWpTIhMQ84B3/e/siMZ/LYd5DtSR7mWy8npSuVUVGwz0mX/yKuVGv6 UrK7jVTQNEVFQleuKorf5yLK+cV/zCqKkpMyAYbI0fdvSPxNoFf3ql35KoSEkIkmnfbl qOl5ypNd89b6H2oU+6juFYLygLIXrT2B6Y5Ej85ijXXAcgajAFsEcZR5R3yUIUfaJn12 DIT32T/ssQcL6UCbzrGH7yxgdDh3FNfMmX334CCjZvzEQa/bZZ6JODkUpUb/6ln3ENtn 979/LJcUBJPNDxxqGP7saf+8KtRA9nZTDRSPY5/0e6PrpzCfgX2HjkSbVy+/iCDcCAR5 7NAQ== Received: by 10.50.186.231 with SMTP id fn7mr718300igc.15.1333094370493; Fri, 30 Mar 2012 00:59:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Fri, 30 Mar 2012 00:58:50 -0700 (PDT) From: Qiong Date: Fri, 30 Mar 2012 15:58:50 +0800 Message-ID: To: pcp@ietf.org Content-Type: multipart/alternative; boundary=14dae934089167c4e804bc7138bc Subject: [pcp] Ask for your comments on PCP port-set extension X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:59:31 -0000 --14dae934089167c4e804bc7138bc Content-Type: text/plain; charset=UTF-8 Dear all, Thanks for your attention on PCP meeting for http://www.ietf.org/id/draft-tsou-pcp-natcoord-05.txt As Chairman encourages us to launch this thread due to limited times on the meeting. As discussed in the meeting, the general application secnario for this requirement is described in http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt, in which NAT is offloaded into distributed CPEs. In this way, CGN does not need to maintain per-session binding table, but rather per-subscriber binding table (including IPv6 address, IPv4 address and port-set). And the CPE will need to acquire an public external address plus port set. The requirement to extend PCP is specifically useful in case an operator is not willing to use DHCPv4 server (or do not have an existing DHCPv4 server) in the IPv6 transition world. Since PCP protocol is quite flexible for port management and can be located in AFTR naturelly, we choose to extend PCP protocol and define a new OpCode for port-set management. The rationale behind this choice is to avoid overloading MAP and to ease separating the port-range function from the handling of individual mappings. And we also define two port-set options to convey contiguous and non-contiguous port-set. So we would like very much to have your comments on this port-set extension proposal. Thanks in advance! Best wishes Qiong --14dae934089167c4e804bc7138bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

Thanks for your attention on PCP meeting for
http://www.ietf.org= /id/draft-tsou-pcp-natcoord-05.txt

As Chairman encourages us to = launch this thread due to limited times on the meeting.
As discussed in the meeting, the general application secnar= io for this requirement is described in
http://www.ietf.org/id/= draft-cui-softwire-b4-translated-ds-lite-05.txt, in which NAT is offloa= ded into distributed CPEs. In this way, CGN does not need to maintain per-s= ession binding table, but rather per-subscriber binding table (including IP= v6 address, IPv4 address and port-set). And the CPE will need to acquire an= public external address plus port set.

The requirement to extend PCP is specifically useful in case an operato= r is not willing to use DHCPv4 server (or do not have an existing DHCPv4 se= rver) in the IPv6 transition world. Since PCP protocol is quite flexible fo= r port management and can be located in AFTR naturelly, we choose to extend= PCP protocol and define a new OpCode for port-set management. The rational= e behind this choice is to avoid overloading MAP and to ease separating the= port-range function from the handling of individual mappings. And we also = define two port-set options to convey contiguous and non-contiguous port-se= t.

So we would like very much to have your comments on this port-set exten= sion proposal. Thanks in advance!

Best wishes
Qiong

=C2=A0=
--14dae934089167c4e804bc7138bc-- From dwing@cisco.com Fri Mar 30 01:30:30 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFD421F87EF for ; Fri, 30 Mar 2012 01:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.485 X-Spam-Level: X-Spam-Status: No, score=-109.485 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 A6X6MgBxkQjf for ; Fri, 30 Mar 2012 01:30:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 758DB21F86B7 for ; Fri, 30 Mar 2012 01:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3472; q=dns/txt; s=iport; t=1333096229; x=1334305829; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=mQOQXqJDpU/LZ6jLUAUwkgqy02JhbXYuqdFUQz1MI0U=; b=FaUgsJiF3yvVGMa7EZ6Ay5yr5d+wrKbcwjZMRXxQpPzriCIc6+0p1Wc7 ycnBVsT5Msl8XiQvcQDu9kTAXyHkJKJXdhUUrltVpd0XFqPAtAi/+GEGN 1enCAvPQRhZuGbWFcwpMD9MZy+bEIKvy0AGmQ9IFZyes98RfPdYZPuk/R 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADNudU+rRDoG/2dsb2JhbABChVOjO49bgQeCCQEBAQQICgEQB0IKDwEDAgkPAgQBAQMCIwMCAhkjCgkIAQEEARIJAheHZwyfWo0IiiuBL4lLhH6BGASNa5Y8gWiCaYFS X-IronPort-AV: E=Sophos;i="4.75,342,1330905600"; d="scan'208";a="35763680" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Mar 2012 08:30:29 +0000 Received: from dwingWS (sjc-vpn4-479.cisco.com [10.21.81.223]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2U8US92018369; Fri, 30 Mar 2012 08:30:28 GMT From: "Dan Wing" To: "'Qiong'" , References: In-Reply-To: Date: Fri, 30 Mar 2012 10:30:27 +0200 Message-ID: <066601cd0e4f$5d02c400$17084c00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0OSxfnQh7/jAmKQZWoo+SdVYujLQAAYIMw Content-Language: en-us Subject: Re: [pcp] Ask for your comments on PCP port-set extension X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:30:30 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Qiong > Sent: Friday, March 30, 2012 9:59 AM > To: pcp@ietf.org > Subject: [pcp] Ask for your comments on PCP port-set extension > > Dear all, > > Thanks for your attention on PCP meeting for > http://www.ietf.org/id/draft-tsou-pcp-natcoord-05.txt > > As Chairman encourages us to launch this thread due to limited times on > the meeting. > As discussed in the meeting, the general application secnario for this > requirement is described in > http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt, > in which NAT is offloaded into distributed CPEs. In this way, CGN does > not need to maintain per-session binding table, but rather per- > subscriber binding table (including IPv6 address, IPv4 address and > port-set). And the CPE will need to acquire an public external address > plus port set. > > The requirement to extend PCP is specifically useful in case an > operator is not willing to use DHCPv4 server (or do not have an > existing DHCPv4 server) in the IPv6 transition world. Since PCP > protocol is quite flexible for port management and can be located in > AFTR naturelly, we choose to extend PCP protocol and define a new > OpCode for port-set management. The rationale behind this choice is to > avoid overloading MAP and to ease separating the port-range function > from the handling of individual mappings. And we also define two port- > set options to convey contiguous and non-contiguous port-set. > > So we would like very much to have your comments on this port-set > extension proposal. Thanks in advance! The Cryptographically Random Port Range Option will lead to interoperability problems, and is not worth pursuing. There is only a slight gain to such pseudo-random port assignment (reference RFC6056), because an attacker can cause the victim to open 100's of ports to a server owned by the attacker, thus the attacker learns allocated port numbers and the port assignment algorithm (which could be leveraged against other subscribers using that same algorithm at the same ISP). Thus, the pseudo-random assignment of port numbers does not achieve the goals outlined in RFC6056. The document needs to describe what happens in corner cases. FOR EXAMPLE, if a PCP sends a mapping request for a subset or superset of their allowed mappings. For example, let's say a customer gets ports 500-600 (100 ports). The PCP client might issue a normal draft-ietf-pcp-base MAP request -- is that supposed to be handled normally? Afterwards, the PCP client might request 300 ports, which I suppose results in an error (?) or an assignment of 100 ports, or an assignment of 99 ports?? Then, what happens if the PCP client tries to renew that first port is requested? I am not interested in the answer to that specific example -- rather, I am interested in new text in the document that describes what is supposed to occur when the PCP client asks for too many ports using MAP_PORT_SET, asks for fewer ports than permitted by the CGN, and what happens if the PCP client sends a MAP request or sends a combination of MAP_PORT_SET and MAP. With that additional information, I can evaluate the proposal better. Right now, I don't know how well it will work when a non-MAP_PORT_SET-capable PCP endpoint or NAT is introduced to a user's home. -d From dthaler@microsoft.com Fri Mar 30 07:43:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A121F8675 for ; Fri, 30 Mar 2012 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.37 X-Spam-Level: X-Spam-Status: No, score=-105.37 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sStE05nSmVPP for ; Fri, 30 Mar 2012 07:43:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0B21F8673 for ; Fri, 30 Mar 2012 07:43:48 -0700 (PDT) Received: from mail90-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 30 Mar 2012 14:43:47 +0000 Received: from mail90-va3 (localhost [127.0.0.1]) by mail90-va3-R.bigfish.com (Postfix) with ESMTP id A5F7026048F; Fri, 30 Mar 2012 14:43:46 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail90-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail90-va3 (localhost.localdomain [127.0.0.1]) by mail90-va3 (MessageSwitch) id 1333118624978810_27005; Fri, 30 Mar 2012 14:43:44 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.244]) by mail90-va3.bigfish.com (Postfix) with ESMTP id E430332005A; Fri, 30 Mar 2012 14:43:44 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 30 Mar 2012 14:43:43 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 30 Mar 2012 14:43:28 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 30 Mar 2012 07:43:28 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Fri, 30 Mar 2012 07:43:28 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0Og19CMBLvWGdiQCCH4fAtFC8UDg== Date: Fri, 30 Mar 2012 14:43:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Stephen Farrell Subject: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:43:52 -0000 Based on the feedback received during the meeting and on this thread from various people reporting they were blocked on THIRD_PARTY for deploying PCP for the web portal case, I met with Stephen Farrell today to report on the WG feedback and have a new proposal for the WG's review, which Stephen would be okay with if worded properly. The proposal is to split how we think about THIRD_PARTY into two separate options with different Option Codes (though the rest of=20 the option format may be identical), one in the base spec and one moved out of it. Specifically: * One is for use cases where the PCP client and PCP server are owned and operated by the same entity and are placed on an entirely trusted network. That is explicitly not a home network nor a typical enterprise network. A PCP server intended for a home network MUST NOT support this option. This option can appear in the pcp-base spec with the above restrictions and is intended to=20 unblock the deployments of the people who objected to the=20 "separate it out" proposal. As noted below, we rename this option to something else (SAME_PARTY?) and use the term THIRD_PARTY for the next one. * The second option would be separated out of the pcp-base spec, would mandate that it be protected via whatever advanced security mechanism we decide on, and be usable for more general cases where the PCP client and PCP server could even be owned by different entities and hence the term "THIRD_PARTY" is more appropriate to retain for this option. With appropriate wordsmithing, is this approach something we can quickly get consensus on? -Dave From dthaler@microsoft.com Fri Mar 30 07:53:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9D21F86C2 for ; Fri, 30 Mar 2012 07:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.379 X-Spam-Level: X-Spam-Status: No, score=-105.379 tagged_above=-999 required=5 tests=[AWL=1.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AidcQhK5eaAh for ; Fri, 30 Mar 2012 07:53:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2921F86BE for ; Fri, 30 Mar 2012 07:53:34 -0700 (PDT) Received: from mail15-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 30 Mar 2012 14:53:33 +0000 Received: from mail15-tx2 (localhost [127.0.0.1]) by mail15-tx2-R.bigfish.com (Postfix) with ESMTP id 7077F2030C for ; Fri, 30 Mar 2012 14:53:33 +0000 (UTC) X-SpamScore: -1 X-BigFish: VS-1(zz4015Izz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail15-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail15-tx2 (localhost.localdomain [127.0.0.1]) by mail15-tx2 (MessageSwitch) id 133311921235977_9819; Fri, 30 Mar 2012 14:53:32 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.247]) by mail15-tx2.bigfish.com (Postfix) with ESMTP id ECCCBA0097 for ; Fri, 30 Mar 2012 14:53:31 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 30 Mar 2012 14:53:30 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 30 Mar 2012 14:53:29 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Fri, 30 Mar 2012 07:53:29 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0OhAKWvzzm+Kj6Tpme/SDjwr4pWQ== Date: Fri, 30 Mar 2012 14:53:28 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WG last call on draft-ietf-pcp-dhcp-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:53:35 -0000 This email initiates a last call on draft-ietf-pcp-dhcp-02. This call will last for three weeks (due to various people traveling the week after IETF) to conclude Friday April 20. Please send comments to the list, even if it's just to=20 say you found no issues and you support publication. I'd consider the document done once there's at least 5 reviewers who say it's ready for publication, and any issues raised have been addressed. Thanks, -Dave From wim.henderickx@alcatel-lucent.com Fri Mar 30 08:49:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA3B21F86A5 for ; Fri, 30 Mar 2012 08:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.441 X-Spam-Level: X-Spam-Status: No, score=-9.441 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgKaaq78AgSH for ; Fri, 30 Mar 2012 08:49:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id DCFE321F86A2 for ; Fri, 30 Mar 2012 08:49:09 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2UFn7Vw006272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Mar 2012 17:49:08 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 30 Mar 2012 17:49:08 +0200 From: "Henderickx, Wim (Wim)" To: Dave Thaler , "pcp@ietf.org" Date: Fri, 30 Mar 2012 17:49:08 +0200 Thread-Topic: WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0OhAKWvzzm+Kj6Tpme/SDjwr4pWQACJ/Cg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E277406D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:49:11 -0000 support -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave = Thaler Sent: vrijdag 30 maart 2012 16:53 To: pcp@ietf.org Subject: [pcp] WG last call on draft-ietf-pcp-dhcp-02 This email initiates a last call on draft-ietf-pcp-dhcp-02. This call will last for three weeks (due to various people traveling the week after IETF) to conclude Friday April 20. Please send comments to the list, even if it's just to=20 say you found no issues and you support publication. I'd consider the document done once there's at least 5 reviewers who say it's ready for publication, and any issues raised have been addressed. Thanks, -Dave _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Fri Mar 30 09:05:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F9521F8671 for ; Fri, 30 Mar 2012 09:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DflPn9taOram for ; Fri, 30 Mar 2012 09:05:18 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6542821F8670 for ; Fri, 30 Mar 2012 09:05:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [93.158.46.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 340CE2014A; Fri, 30 Mar 2012 12:04:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8ABBA4766; Fri, 30 Mar 2012 12:05:15 -0400 (EDT) From: Sam Hartman To: Dave Thaler References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 30 Mar 2012 12:05:15 -0400 In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> (Dave Thaler's message of "Fri, 30 Mar 2012 14:43:27 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:05:18 -0000 >>>>> "Dave" == Dave Thaler writes: Dave> * One is for use cases where the PCP client and PCP server are Dave> owned and operated by the same entity and are placed on an Dave> entirely trusted network. That is explicitly not a home Dave> network nor a typical enterprise network. A PCP server Dave> intended for a home network MUST NOT support this option. Dave> This option can appear in the pcp-base spec with the above Dave> restrictions and is intended to unblock the deployments of the Dave> people who objected to the "separate it out" proposal. As Dave> noted below, we rename this option to something else Dave> (SAME_PARTY?) and use the term THIRD_PARTY for the next one. I don't support this option in the base spec. Any such trusted network is an environment where it would be reasonably easy to share credentials between the PCP server and a authorized party. So, such an option is an excellent candidate to be used along side a mandatory-to-implement security mechanism. (Mandatory-to-implement security mechanisms are not mandatory-to-use. If you don't think it is worth credentialing and would prefer to turn off security, that's fine.) As a result I believe we would produce a higher-quality spec if we had only one third-party option. This compromise produces a technically inferior result simply to get the third party option specified 6-9 months earlier. I prefer either 1) Moving the third-party option to its own document or 2) delaying the base spec to this compromise option. --Sam From mrw@lilacglade.org Fri Mar 30 10:11:28 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FB21F8644 for ; Fri, 30 Mar 2012 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 WnQ3YI+lJvQf for ; Fri, 30 Mar 2012 10:11:27 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A7DEE21F85B5 for ; Fri, 30 Mar 2012 10:11:27 -0700 (PDT) Received: from [10.216.7.7] (unknown [93.158.40.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 17F4B207D4; Fri, 30 Mar 2012 13:10:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 30 Mar 2012 19:11:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:11:28 -0000 I have read draft-ietf-pcp-dhcp-02. I support specification of a DHCP = option to configure hosts with the name(s) of their PCP Server(s), but I = think there are any issues with this document that need to be addressed = before publication. My detailed comments are included below, but I'll = start with a couple of general comments. This document _way_ oversteps what should be defined in a DHCP option, = proscribing quite a bit of operational behaviour of the PCP server = including: how to handle multiple PCP servers, how to handle = retransmissions, etc. More than half of the information in this = document does not belong here. Also, there is a lengthy discussion in this document of whether to use = IP Addresses or Names, and I don't understand any of that. There are a = number of DHCP options that contain server lists, and those servers can = be represented by either IP addresses or names. For an example of a = good DHCP option definition along those lines, please see the NTP DHCP = Option (RFC 5908). IMO, it would be much better to produce a PCP Server = DHCP Option based on the NTP DHCP Option than to do it as described in = this document. Margaret =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Detailed Comments: (1) The Abstract: The text in the abstract does not match the document = (addresses vs. names). To resolve this issue I would suggest: OLD: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server addresses.=20 NEW:=20 This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. (2) Introduction: This option does not provide anything about = "reachability information", it provisions a list of PCP Servers on a = host. The DHCP server won't know anything about whether those Servers = are reachable at any given time, or from any given place on the network, = so it can't convey that information. =20 To resolve this issue I would suggest: OLD: This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options which can be used to provision PCP Server [I-D.ietf-pcp-base] reachability information; more precisely it defines DHCP options to convey a name (as per Section 3.1 of [RFC1035]) of PCP Server(s). NEW: This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options to provision a list of PCP Server [I-D.ietf-pcp-base] names. (3) Section 3: Configuration of a list of servrtd is quite common, and = it does not require a lengthy rationale, nor is it valuable to invent a = new way to to do it. This section describes an operational model that = is not pertinent to many uses of PCP, and I am concerned that by = describing this model, we could give the impression that the IETF is = condoning, or even encouraging, the type of "organization" described. I = am not sure why we would want to do that. Also, since we are moving the = DS-Lite stuff out of the Base Spec, discussing "the DS-Lite Use Case" = for PCP as we do here would require a reference to the new spec, and I = don't think one should be needed in a DHCP option that is useful for all = use cases. To resolve this issue, I would suggest: Remove section 3. Rework the option to accept a list of names or IP = Addresses, like the NTP Server option (RFC 5908). (4) Section 4: There are a number of problems with this section. (4a) It is possible to return more than one PCP Server name in the list, = and it is possible that there will be more than one PCP controlled = device on a hosts outbound path. So, the first statement in this = section is simplistic... Is the applicability of this option = constrained to cases were there is only one PCP-controlled device = serving as a gateway to a leaf network? If so, you should say that = somewhere in here. If not, I think you need to say something else. (4b) What is "any terminal belonging to the same realm"? "Terminal" and = "realm" aren't words that apply in a typical IP networking case, and it = is unclear what is meant here. =20 (4c) What is a CP Router? Do you mean a customer-premise router? If = so, you need to expand the acronym the first time you use it... Also, = Customer Premise Equipment (CPE) is more commonly used in the IETF, I = think. If this option is used to configure a router, is it assumed that = the router will pass this information on to its internal hosts? Or that = it will serve as a PCP proxy for them? (4d) "Customers" will experience "service troubles" and their = "service(s) won't be delivered appropriately" is a bit obscure.... I also wonder why this section exists in this document at all, since it = seems more like general advice on how to deal with a situation where a = PCP Server isn't co-resident with the device it controls than anything = having to do with the DHCP option... Also, it isn't really necessary to = tell someone that if they misconfigure their hosts, they won't work. =20 To address these four problems, I suggest that you remove section 4. (5) Section 5: This section doesn't make sense to me, as written. You = have described two operational models, but IMO they muddle together the = notion of receiving a list of PCP Servers (i.e. multiple names), and a = list of IP addresses in a DNS response (i.e. multiple IP Addresses = corresponding to the name). =20 IMO, you need to make a decision here... Do you want to treat each IP = Address returned from name resolution as a separate PCP Server? Or do = you want to treat each PCP Server name provisioned by DHCP as a separate = server. It appears that you use the latter (one name, on server) in = section 5.1 and the former (one address, one server) in section 5.2. = This doesn't make any sense to me. I *think* what you want to do is to allow multiple DHCP Server names to = indicate multiple servers that should be used in parallel (to cover the = case where a site is multi-homed), and that you want clients to use each = set of IP addresses as alternate ways to reach each of those servers, = but that is not what this section says. Also, why do you describe a PCP retransmission algorithm here in the = DHCP spec? All you want to do in the DHCP spec is describe how a node gets its = configuration information through DHCP. You don't want to describe how = PCP works. The PCP base spec needs to describe how PCP works included = what its expected configuration looks like, while remaining neutral on = whether that configuration is obtained via manual configuration, DHC or = other means. To address this issue: Construct a DHCP Option that can be used to indicate whether the PCP = Servers in the PCP Server list should be tried in sequence if the prior = servers are unavailable, or whether they should all be used in parallel. = If a more complicated construct is needed, describe what it is, and I = will help you understand how to represent that in a DHCP option. DO NOT descrive how the PCP Client will work in this option. How does a = PCP Client use multiple servers if they are configured statically? Or = if there are multiple default routers in the default router list. All = of this operational mode stuff belongs in the PCP base document, not in = an DHCP option. (6) Section 6: =20 (6a) The DS-Lite example isn't helpful here. (6b) Also, this option only allows you to configure one DNS name, which = doesn't match all of section 5. =20 (6c) This document should not tell you how to configure your DNS server. (6d) When you want to configure a server list, it is typical to include = the server list in one option (as in NTP) not to send multiple options = as seems to be described in this draft. =20 (6e) I don't even know what to say about the "local cache" of resolved = addresses... Include what TTL? What cache?=20 To address this issue I would suggest: Remove the DS-Lite example. Move to an option like the NTP DHCP Option in RFC 5908, perhaps with a = flag to indicate whether the servers should be used as a redundancy = list, or as a list of servers to be used in parallel (see my suggestion = for section 5. Remove the mention of how to configure a DNS server. Substantially rework the client behaviour section. (7) Section 7 has many of the same issues described in section 6. (8) There is no link between using DHCPv4 or DHCPv6 and DNS in terms of = what IP version will be returned in a name lookup, and I don't see why = you would want to imply that there is. =20 From jari.arkko@piuha.net Fri Mar 30 11:41:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE6F21F8682 for ; Fri, 30 Mar 2012 11:41:52 -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 ikN9aKZNXy4Q for ; Fri, 30 Mar 2012 11:41:52 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5021F867D for ; Fri, 30 Mar 2012 11:41:52 -0700 (PDT) Received: from localhost (178-55-207-83.bb.dnainternet.fi [178.55.207.83]) by p130.piuha.net (Postfix) with ESMTPSA id 92DF12CC56; Fri, 30 Mar 2012 21:41:43 +0300 (EEST) Date: Fri, 30 Mar 2012 20:41:17 +0200 Message-ID: From: Jari Arkko To: Dave Thaler , "pcp@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:41:53 -0000 IFdmbQoKSmFyaQoKRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6Cgo+ QmFzZWQgb24gdGhlIGZlZWRiYWNrIHJlY2VpdmVkIGR1cmluZyB0aGUgbWVldGluZyBhbmQgb24g dGhpcyB0aHJlYWQKPmZyb20gdmFyaW91cyBwZW9wbGUgcmVwb3J0aW5nIHRoZXkgd2VyZSBibG9j a2VkIG9uIFRISVJEX1BBUlRZIGZvcgo+ZGVwbG95aW5nIFBDUCBmb3IgdGhlIHdlYiBwb3J0YWwg Y2FzZSwgSSBtZXQgd2l0aCBTdGVwaGVuIEZhcnJlbGwgdG9kYXkKPnRvIHJlcG9ydCBvbiB0aGUg V0cgZmVlZGJhY2sgYW5kIGhhdmUgYSBuZXcgcHJvcG9zYWwgZm9yIHRoZSBXRydzCj5yZXZpZXcs IHdoaWNoIFN0ZXBoZW4gd291bGQgYmUgb2theSB3aXRoIGlmIHdvcmRlZCBwcm9wZXJseS4KPgo+ VGhlIHByb3Bvc2FsIGlzIHRvIHNwbGl0IGhvdyB3ZSB0aGluayBhYm91dCBUSElSRF9QQVJUWSBp bnRvIHR3bwo+c2VwYXJhdGUgb3B0aW9ucyB3aXRoIGRpZmZlcmVudCBPcHRpb24gQ29kZXMgKHRo b3VnaCB0aGUgcmVzdCBvZiAKPnRoZSBvcHRpb24gZm9ybWF0IG1heSBiZSBpZGVudGljYWwpLCBv bmUgaW4gdGhlIGJhc2Ugc3BlYyBhbmQgb25lCj5tb3ZlZCBvdXQgb2YgaXQuICBTcGVjaWZpY2Fs bHk6Cj4KPiogT25lIGlzIGZvciB1c2UgY2FzZXMgd2hlcmUgdGhlIFBDUCBjbGllbnQgYW5kIFBD UCBzZXJ2ZXIgYXJlIG93bmVkCj4gICBhbmQgb3BlcmF0ZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFu ZCBhcmUgcGxhY2VkIG9uIGFuIGVudGlyZWx5Cj4gICB0cnVzdGVkIG5ldHdvcmsuICAgVGhhdCBp cyBleHBsaWNpdGx5IG5vdCBhIGhvbWUgbmV0d29yayBub3IgYSB0eXBpY2FsCj4gICBlbnRlcnBy aXNlIG5ldHdvcmsuICAgQSBQQ1Agc2VydmVyIGludGVuZGVkIGZvciBhIGhvbWUgbmV0d29yawo+ ICAgTVVTVCBOT1Qgc3VwcG9ydCB0aGlzIG9wdGlvbi4gICAgVGhpcyBvcHRpb24gY2FuIGFwcGVh ciBpbiB0aGUKPiAgIHBjcC1iYXNlIHNwZWMgd2l0aCB0aGUgYWJvdmUgcmVzdHJpY3Rpb25zIGFu ZCBpcyBpbnRlbmRlZCB0byAKPiAgIHVuYmxvY2sgdGhlIGRlcGxveW1lbnRzIG9mIHRoZSBwZW9w bGUgd2hvIG9iamVjdGVkIHRvIHRoZSAKPiAgICJzZXBhcmF0ZSBpdCBvdXQiIHByb3Bvc2FsLiAg IEFzIG5vdGVkIGJlbG93LCB3ZSByZW5hbWUgdGhpcyBvcHRpb24KPiAgIHRvIHNvbWV0aGluZyBl bHNlIChTQU1FX1BBUlRZPykgYW5kIHVzZSB0aGUgdGVybSBUSElSRF9QQVJUWQo+ICAgZm9yIHRo ZSBuZXh0IG9uZS4KPgo+KiBUaGUgc2Vjb25kIG9wdGlvbiB3b3VsZCBiZSBzZXBhcmF0ZWQgb3V0 IG9mIHRoZSBwY3AtYmFzZSBzcGVjLAo+ICAgd291bGQgbWFuZGF0ZSB0aGF0IGl0IGJlIHByb3Rl Y3RlZCB2aWEgd2hhdGV2ZXIgYWR2YW5jZWQgc2VjdXJpdHkKPiAgIG1lY2hhbmlzbSB3ZSBkZWNp ZGUgb24sIGFuZCBiZSB1c2FibGUgZm9yIG1vcmUgZ2VuZXJhbCBjYXNlcwo+ICAgd2hlcmUgdGhl IFBDUCBjbGllbnQgYW5kIFBDUCBzZXJ2ZXIgY291bGQgZXZlbiBiZSBvd25lZCBieQo+ICAgZGlm ZmVyZW50IGVudGl0aWVzIGFuZCBoZW5jZSB0aGUgdGVybSAiVEhJUkRfUEFSVFkiIGlzIG1vcmUK PiAgIGFwcHJvcHJpYXRlIHRvIHJldGFpbiBmb3IgdGhpcyBvcHRpb24uCj4KPldpdGggYXBwcm9w cmlhdGUgd29yZHNtaXRoaW5nLCBpcyB0aGlzIGFwcHJvYWNoIHNvbWV0aGluZyB3ZQo+Y2FuIHF1 aWNrbHkgZ2V0IGNvbnNlbnN1cyBvbj8KPgo+LURhdmUKPgo+Cj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+cGNwIG1haWxpbmcgbGlzdAo+cGNwQGlldGYu b3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcAo= From simon.perreault@viagenie.ca Fri Mar 30 14:13:20 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71D721F8672 for ; Fri, 30 Mar 2012 14:13:20 -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 JRcjiShvDYz1 for ; Fri, 30 Mar 2012 14:13:19 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C135021F8674 for ; Fri, 30 Mar 2012 14:13:19 -0700 (PDT) Received: from eeepc.viagenie.ca (ter75-1-81-57-68-77.fbx.proxad.net [81.57.68.77]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0AF2640054 for ; Fri, 30 Mar 2012 17:13:18 -0400 (EDT) Message-ID: <4F7621EC.2050003@viagenie.ca> Date: Fri, 30 Mar 2012 23:13:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:13:20 -0000 On 03/30/12 20:41, Jari Arkko wrote: > Wfm +1 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From bingxuere@gmail.com Fri Mar 30 15:55:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00C21F867E for ; Fri, 30 Mar 2012 15:55:48 -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 lq1alSa2x0kl for ; Fri, 30 Mar 2012 15:55:46 -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 C870C21F867D for ; Fri, 30 Mar 2012 15:55:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so1882355iaz.31 for ; Fri, 30 Mar 2012 15:55:46 -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=dDjrXrbkoNgmYpP506HVE1YXbrUXKfPF7IyM+zhRP8I=; b=z7EDj/3Y9bbapOSdAsxt1a0lqZElmeIOKrkB8YctvVNWqpRDiaMRtSvBUOFuFt12Mb rBwEqho8NR0/xISENBcDdXOdz2VZLIWwrLyKfyXVcYmIgrInG6mxjIZ7AjnnxTyIlPUc vm/rkN8QZlPxjbRKcgxyRrczXFUClwiTo0iU0+00epEnDRR8mAztavfWu3ppvapMo8HR wjaUO+aAlhgXJIp04b9izIbvgCrXIKfXX98pGPX9sVBj14UuxoLjAiRhdY31B88gOHSa EexX9DUsJaMppkhcTgVxgghB/ywLC0YlQN8TpBsEWzpGSczQX4787baqib5aWgV+LnuP L1qA== Received: by 10.50.186.231 with SMTP id fn7mr149950igc.15.1333148146219; Fri, 30 Mar 2012 15:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.115.194 with HTTP; Fri, 30 Mar 2012 15:55:05 -0700 (PDT) In-Reply-To: <066601cd0e4f$5d02c400$17084c00$@com> References: <066601cd0e4f$5d02c400$17084c00$@com> From: Qiong Date: Sat, 31 Mar 2012 06:55:05 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=14dae9340891b03ad304bc7dbdae Cc: pcp@ietf.org Subject: Re: [pcp] Ask for your comments on PCP port-set extension X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:55:48 -0000 --14dae9340891b03ad304bc7dbdae Content-Type: text/plain; charset=UTF-8 Hi Dan, Thanks a lot for your detailed comments on it. Please see inline. On Fri, Mar 30, 2012 at 4:30 PM, Dan Wing wrote: > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Qiong > > Sent: Friday, March 30, 2012 9:59 AM > > To: pcp@ietf.org > > Subject: [pcp] Ask for your comments on PCP port-set extension > > > > Dear all, > > > > Thanks for your attention on PCP meeting for > > http://www.ietf.org/id/draft-tsou-pcp-natcoord-05.txt > > > > As Chairman encourages us to launch this thread due to limited times on > > the meeting. > > As discussed in the meeting, the general application secnario for this > > requirement is described in > > http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-05.txt, > > in which NAT is offloaded into distributed CPEs. In this way, CGN does > > not need to maintain per-session binding table, but rather per- > > subscriber binding table (including IPv6 address, IPv4 address and > > port-set). And the CPE will need to acquire an public external address > > plus port set. > > > > The requirement to extend PCP is specifically useful in case an > > operator is not willing to use DHCPv4 server (or do not have an > > existing DHCPv4 server) in the IPv6 transition world. Since PCP > > protocol is quite flexible for port management and can be located in > > AFTR naturelly, we choose to extend PCP protocol and define a new > > OpCode for port-set management. The rationale behind this choice is to > > avoid overloading MAP and to ease separating the port-range function > > from the handling of individual mappings. And we also define two port- > > set options to convey contiguous and non-contiguous port-set. > > > > So we would like very much to have your comments on this port-set > > extension proposal. Thanks in advance! > > The Cryptographically Random Port Range Option will lead to > interoperability problems, and is not worth pursuing. There is only > a slight gain to such pseudo-random port assignment (reference RFC6056), > because an attacker can cause the victim to open 100's of ports to > a server owned by the attacker, thus the attacker learns allocated > port numbers and the port assignment algorithm (which could be > leveraged against other subscribers using that same algorithm at > the same ISP). Thus, the pseudo-random assignment of port numbers > does not achieve the goals outlined in RFC6056. > [Qiong] We use the pseudo-random algorithm because it has been defined in RFC6431. The cryptographic mechanism ensures that the entire 64k port range can be efficiently distributed to multiple nodes such that when nodes calculate the ports, the results will never overlap with ports that other nodes have calculated (property of permutation), and ports in the reserved range (smaller than 1024) are not used. As the randomization is done cryptographically, an attacker seeing a node using some port X cannot determine which other ports the node may be using (as the attacker does not know the key). How do you think of it? BTW, I'm not sure of what you have mentioned on interoperability problems here. Would you please elabroate a little more ? Thanks a lot! > > The document needs to describe what happens in corner cases. FOR > EXAMPLE, if a PCP sends a mapping request for a subset or superset > of their allowed mappings. For example, let's say a customer gets > ports 500-600 (100 ports). The PCP client might issue a normal > draft-ietf-pcp-base MAP request -- is that supposed to be handled > normally? Afterwards, the PCP client might request 300 ports, > which I suppose results in an error (?) or an assignment of 100 > ports, or an assignment of 99 ports?? Then, what happens if the > PCP client tries to renew that first port is requested? I am not > interested in the answer to that specific example -- rather, I am > interested in new text in the document that describes what is > supposed to occur when the PCP client asks for too many ports > using MAP_PORT_SET, asks for fewer ports than permitted by the > CGN, and what happens if the PCP client sends a MAP request or > sends a combination of MAP_PORT_SET and MAP. > [Qiong] Thanks a lot! This is very helpful. We will add new text for this in the next version. In general procedure, I think the PCP server should be configured with port quota for PCP client, which is the maximum number of ports a PCP client will get in total. And the PCP server will also be configured with the size of port set to allocate each time. Then for the corner case, how about we solve this problem in the following way: 1) If the PCP client asks for too many ports using MAP_PORT_SET, USER_EX_QUOTA error code can be returned to the PCP client. 2) If the PCP client asks for fewer ports than permitted by the CGN, it is still up to the CGN to determine the size of port-set allocated to the PCP client, unless PREFERE_FAILURE option is used in PCP client. 3) For the combination of MAP_PORT_SET and MAP, since MAP_PORT_SET is designed for PCP client to get the overall valid port set, while MAP is designed to get the specific port for an application, I think there is no confliction between them. The server should guarantee that the specific port allocated via MAP should be within the valid port-set allocated to PCP client via MAP_PORT_SET. For example, the port-set returned by MAP_PORT_STE is [1024, 2047], and the port returned by MAP is 2004. So if the client renew MAP_PORT_SET several times, we only need to guarantee the port returned by MAP is within the current valid port-set for the PCP client. Do you think it is fine to solve these corner cases ? Thanks a lot to point out these problems. Best wishes Qiong > > With that additional information, I can evaluate the proposal > better. Right now, I don't know how well it will work when > a non-MAP_PORT_SET-capable PCP endpoint or NAT is introduced to > a user's home. > > -d > > > --14dae9340891b03ad304bc7dbdae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dan,

Thanks a lot for your detailed comments on it. Please see in= line.

On Fri, Mar 30, 2012 at 4:30 PM, Da= n Wing <dwing@cisco= .com> wrote:
>= -----Original Message-----
> From: pcp-bounces@ietf.org= [mailto:pcp-bounces@ietf.org] = On Behalf Of
> Qiong
> Sent: Friday, March 30, 2012 9:59 AM
> To: pcp@ietf.org
> Subject: [pcp] Ask for your comments on PCP port-set extension
>
> Dear all,
>
> Thanks for your attention on PCP meeting for
> http://www.ietf.org/id/draft-tsou-pcp-natcoord-05.txt
>
> As Chairman encourages us to launch this thread due to limited times o= n
> the meeting.
> As discussed in the meeting, the general application secnario for this=
> requirement is described in
> http://www.ietf.org/id/draft-cui-softwire-b4= -translated-ds-lite-05.txt,
> in which NAT is offloaded into distributed CPEs. In this way, CGN does=
> not need to maintain per-session binding table, but rather per-
> subscriber binding table (including IPv6 address, IPv4 address and
> port-set). And the CPE will need to acquire an public external address=
> plus port set.
>
> The requirement to extend PCP is specifically useful in case an
> operator is not willing to use DHCPv4 server (or do not have an
> existing DHCPv4 server) in the IPv6 transition world. Since PCP
> protocol is quite flexible for port management and can be located in > AFTR naturelly, we choose to extend PCP protocol and define a new
> OpCode for port-set management. The rationale behind this choice is to=
> avoid overloading MAP and to ease separating the port-range function > from the handling of individual mappings. And we also define two port-=
> set options to convey contiguous and non-contiguous port-set.
>
> So we would like very much to have your comments on this port-set
> extension proposal. Thanks in advance!

The Cryptographically Random Port Range Option will lead to
interoperability problems, and is not worth pursuing. =C2=A0There is only a slight gain to such pseudo-random port assignment (reference RFC6056), because an attacker can cause the victim to open 100's of ports to
a server owned by the attacker, thus the attacker learns allocated
port numbers and the port assignment algorithm (which could be
leveraged against other subscribers using that same algorithm at
the same ISP). =C2=A0Thus, the pseudo-random assignment of port numbers
does not achieve the goals outlined in RFC6056.
=C2=A0=
[Qiong] We use the pseudo-random algorithm because it has been d= efined in RFC6431.
The cryptographic mechanism ensures that the entire = 64k port range can be efficiently distributed to multiple nodes such that w= hen nodes calculate the ports, the results will never overlap with ports th= at other nodes have calculated (property of permutation), and ports in the = reserved range (smaller than 1024) are not used.=C2=A0 As the randomization= is done cryptographically, an attacker seeing a node using some port X can= not determine which other ports the node may be using (as the attacker does= not know the key). How do you think of it?
BTW, I'm not sure of what you have mentioned on interoperability proble= ms here. Would you please elabroate a little more ? Thanks a lot!
=

The document needs to describe what happens in corner cases. =C2=A0FOR
EXAMPLE, if a PCP sends a mapping request for a subset or superset
of their allowed mappings. =C2=A0For example, let's say a customer gets=
ports 500-600 (100 ports). =C2=A0The PCP client =C2=A0might issue a normal<= br> draft-ietf-pcp-base MAP request -- is that supposed to be handled
normally? =C2=A0Afterwards, the PCP client might request 300 ports,
which I suppose results in an error (?) or an assignment of 100
ports, or an assignment of 99 ports?? =C2=A0Then, what happens if the
PCP client tries to renew that first port is requested? =C2=A0I am not
interested in the answer to that specific example -- rather, I am
interested in new text in the document that describes what is
supposed to occur when the PCP client asks for too many ports
using MAP_PORT_SET, asks for fewer ports than permitted by the
CGN, and what happens if the PCP client sends a MAP request or
sends a combination of MAP_PORT_SET and MAP.
=C2=A0
[Qiong] Thanks a lot! This is very helpful. We will add new text fo= r this in the next version.
In general procedure, I think the PCP serve= r should be configured with port quota for PCP client, which is the maximum= number of ports a PCP client will get in total. And the PCP server will al= so be configured with the size of port set to allocate each time. Then for = the corner case, how about we solve this problem in the following way:
1) If the PCP client asks for too many ports using MAP_PORT_SET, USER_EX_QUOTA error code can be returned to the PCP clien= t.
2) If the PCP client asks for fewer ports than permitted by the CGN, it is = still up to the CGN to determine the size of port-set allocated to the PCP = client, unless PREFERE_FAILURE option is used in PCP client.
3) For the = combination of MAP_PORT_SET and MAP, since MAP_PORT_SET is designed for PCP= client to get the overall valid port set, while MAP is designed to get the= specific port for an application, I think there is no confliction between = them. The server should guarantee that the specific port allocated via MAP should be within the valid port-set allocated to PCP client via MAP_PORT_SET.=C2= =A0 For example, the port-set returned b= y MAP_PORT_STE is [1024, 2047], and the port returned by MAP is 2004. So if the client renew MAP_PORT_SET several times, we only need to guaran= tee the port returned by MAP is within the current valid port-set for the P= CP client.

Do you think it is fine to solve these corner cases ? Thanks a lot to p= oint out these problems.

Best wishes
Qiong

With that additional information, I can evaluate the proposal
better. =C2=A0Right now, I don't know how well it will work when
a non-MAP_PORT_SET-capable PCP endpoint or NAT is introduced to
a user's home.

-d



--14dae9340891b03ad304bc7dbdae-- From chenycmx@gmail.com Sat Mar 31 23:11:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2583221F86A0 for ; Sat, 31 Mar 2012 23:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.797 X-Spam-Level: * X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, 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 APWkIJqlXUSK for ; Sat, 31 Mar 2012 23:11: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 13E4B21F8664 for ; Sat, 31 Mar 2012 23:11:22 -0700 (PDT) Received: by iazz13 with SMTP id z13so3303301iaz.31 for ; Sat, 31 Mar 2012 23:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=0RdTxePf+7pcySqWAOJToi88Kmk15xHkpEq6qF0EnY8=; b=VjE+A5Ei6Il/a94d9SO0HrgivNkhLcVp04RZbK3PBFa+hJJb89MTjBMRyBTW41hS5q jUqkSMyTgwTdnDWtn71x6ZwicP6RFhCl8XAS7cvguN9RH/VwUY7pFg1fGaR47z1+tNb0 Z84SnznR2pXPXr1nOezLVIqAU3s9VVCHOqImBT7o4vv1PnxLg4S2aSMJshyXpqzTB0qh wVNj8GZkoxzND0CI6/RfJ0j9EFYw7MhbdfX6TZh1NjRNqp7S5pFm+Q6UXElZXji1yMMU 4K2nYXNxepSG145SenIfZOOw91xoEnVYUxyF8yPXLWjLaqo9TwO3JysF+IT4n5Ud47fq dtOw== Received: by 10.50.242.5 with SMTP id wm5mr2532949igc.40.1333260681582; Sat, 31 Mar 2012 23:11:21 -0700 (PDT) Received: from flashfox-PC ([166.111.68.233]) by mx.google.com with ESMTPS id mk10sm5655520igc.4.2012.03.31.23.11.16 (version=SSLv3 cipher=OTHER); Sat, 31 Mar 2012 23:11:20 -0700 (PDT) Date: Sun, 1 Apr 2012 14:11:16 +0800 From: "Yuchi Chen" To: "Margaret Wasserman" References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>, <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> X-Priority: 3 X-GUID: 4882C6F9-3315-41A8-866F-59657553FC7F X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <2012040114111191638324@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart022545016217_=----" Cc: "pcp@ietf.org" Subject: Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 06:11:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart022545016217_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBXYXNzZXJtYW4sDQoNCkkndmUgcmVhZCBkcmFmdC1pZXRmLXBjcC1kaGNwLTAyLiBJIGRv IGFncmVlIHdpdGggeW91ciBjb21tZW50IHRoYXQgdGhpcyBkcmFmdCBzcGVuZHMgc28gbWFueSB3 b3JkcyANCm9uIHdoYXQgc2hvdWxkIG5vdCBiZSBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IHdoaWNo IGp1c3Qgc3BlY2lmaWVzIGFuIG9wdGlvbiBvZiBESENQLCBsaWtlIHRoZSBiZWhhdmlvcg0Kb2Yg UENQIHNlcnZlcnMuIFN1Y2ggY2xhcmlmaWNhdGlvbiBjYW4gYmUgbWFkZSBpbiBhIGRyYWZ0IHRp dGxlZCB3aXRoIHRleHQgbGlrZSAnQ29uc2lkZXJhdGlvbnMgb2YgREhDUCANCm9wdGlvbnMgZm9y IHRoZSBQQ1AnLiBBY3R1YWxseSwgSSBkbyBhZ3JlZSB3aXRoIG1vc3QgcGFydCBvZiB3aGF0IHlv dSBzYWlkLiBIb3dldmVyLCBJJ20gbm90IHNvIHN1cmUNCmlmIHRoZSBzdGF0ZW1lbnRzIGluIHRo ZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIG9mIHRoZSBkcmFmdCBzaG91bGQgYmUgbW9kaWZp ZWQgYXMgeW91IG1lbnRpb25lZC4gDQpTaW5jZSBnZXR0aW5nIHRoZSBhZGRyZXNzZXMsIG5vdCBq dXN0IHRoZSBuYW1lcyBvZiBQQ1Agc2VydmVycyBpcyB0aGUgbWFpbiBvYmplY3RpdmUgb2YgUENQ IGNsaWVudHMsDQphbmQgc2luY2UgcHJvdmlkaW5nIHRoZSBtZXRob2QgZm9yIFBDUCBjbGllbnRz IHRvIGdldCBQQ1Agc2VydmVycycgbmFtZXMgdmlhIERIQ1AgaXMgdGhlIHB1cnBvc2UgDQpvZiB0 aGUgZHJhZnQsIEkgZG9uJ3QgdGhpbmsgaXQncyBhcHByb3ByaWF0ZSB0byBzYXkgdGhhdCAnVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgREhDUCAoSVB2NCBhbmQgSVB2NikgDQpvcHRpb25zIHRvIGNv bmZpZ3VyZSBob3N0cyB3aXRoIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSBTZXJ2ZXIgbmFt ZXMuJyBpbiB0aGUgYWJzdHJhY3QsIG9yIHRoYXQgDQonVGhpcyBkb2N1bWVudCBkZWZpbmVzIERI Q1B2NCBbUkZDMjEzMV0gYW5kIERIQ1B2NiBbUkZDMzMxNV0gb3B0aW9ucyB0byBwcm92aXNpb24g YSBsaXN0IG9mIFBDUCANClNlcnZlciBbSS1ELmlldGYtcGNwLWJhc2VdIG5hbWVzLicgaW4gdGhl IGludHJvZHVjdGlvbi4gSU1PLCB0aGUgY3VycmVudCBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9u IG9mDQp0aGUgZHJhZnQgaXMgb2ssIGFuZCBpdCBtaWdodCBiZSBiZXR0ZXIgaWYgbW9yZSBkZXRh aWxzIGFib3V0IHRoZSBhY3F1aXJlbWVudCBvZiBhZGRyZXNzZXMgb2YgUENQIHNlcnZlcnMNCmlz IHByb3ZpZGVkIGluIHRoZSBzZWN0aW9uIDUgb3IgZWxzZXdoZXJlLg0KDQpCZXN0IFJlZ2FyZHMh DQoNCg0KDQpZdWNoaSBDaGVuDQoNCkZyb206IE1hcmdhcmV0IFdhc3Nlcm1hbg0KRGF0ZTogMjAx Mi0wMy0zMSAwMToxMQ0KVG86IERhdmUgVGhhbGVyDQpDQzogcGNwQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3BjcF0gV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtcGNwLWRoY3AtMDINCg0KSSBo YXZlIHJlYWQgZHJhZnQtaWV0Zi1wY3AtZGhjcC0wMi4gIEkgc3VwcG9ydCBzcGVjaWZpY2F0aW9u IG9mIGEgREhDUCBvcHRpb24gdG8gY29uZmlndXJlIGhvc3RzIHdpdGggdGhlIG5hbWUocykgb2Yg dGhlaXIgUENQIFNlcnZlcihzKSwgYnV0IEkgdGhpbmsgdGhlcmUgYXJlIGFueSBpc3N1ZXMgd2l0 aCB0aGlzIGRvY3VtZW50IHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYmVmb3JlIHB1YmxpY2F0 aW9uLiAgTXkgZGV0YWlsZWQgY29tbWVudHMgYXJlIGluY2x1ZGVkIGJlbG93LCBidXQgSSdsbCBz dGFydCB3aXRoIGEgY291cGxlIG9mIGdlbmVyYWwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQg X3dheV8gb3ZlcnN0ZXBzIHdoYXQgc2hvdWxkIGJlIGRlZmluZWQgaW4gYSBESENQIG9wdGlvbiwg cHJvc2NyaWJpbmcgcXVpdGUgYSBiaXQgb2Ygb3BlcmF0aW9uYWwgYmVoYXZpb3VyIG9mIHRoZSBQ Q1Agc2VydmVyIGluY2x1ZGluZzogIGhvdyB0byBoYW5kbGUgbXVsdGlwbGUgIFBDUCBzZXJ2ZXJz LCBob3cgdG8gaGFuZGxlIHJldHJhbnNtaXNzaW9ucywgZXRjLiAgTW9yZSB0aGFuIGhhbGYgb2Yg dGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYmVsb25nIGhlcmUuDQoN CkFsc28sIHRoZXJlIGlzIGEgbGVuZ3RoeSBkaXNjdXNzaW9uIGluIHRoaXMgZG9jdW1lbnQgb2Yg d2hldGhlciB0byB1c2UgSVAgQWRkcmVzc2VzIG9yIE5hbWVzLCBhbmQgSSBkb24ndCB1bmRlcnN0 YW5kIGFueSBvZiB0aGF0LiAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIERIQ1Agb3B0aW9ucyB0aGF0 IGNvbnRhaW4gc2VydmVyIGxpc3RzLCBhbmQgdGhvc2Ugc2VydmVycyBjYW4gYmUgcmVwcmVzZW50 ZWQgYnkgZWl0aGVyIElQIGFkZHJlc3NlcyBvciBuYW1lcy4gIEZvciBhbiBleGFtcGxlIG9mIGEg Z29vZCBESENQIG9wdGlvbiBkZWZpbml0aW9uIGFsb25nIHRob3NlIGxpbmVzLCBwbGVhc2Ugc2Vl IHRoZSBOVFAgREhDUCBPcHRpb24gKFJGQyA1OTA4KS4gIElNTywgaXQgd291bGQgYmUgbXVjaCBi ZXR0ZXIgdG8gcHJvZHVjZSBhIFBDUCBTZXJ2ZXIgREhDUCBPcHRpb24gYmFzZWQgb24gdGhlIE5U UCBESENQIE9wdGlvbiB0aGFuIHRvIGRvIGl0IGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 Lg0KDQpNYXJnYXJldA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpEZXRh aWxlZCBDb21tZW50czoNCg0KKDEpIFRoZSBBYnN0cmFjdDogIFRoZSB0ZXh0IGluIHRoZSBhYnN0 cmFjdCBkb2VzIG5vdCBtYXRjaCB0aGUgZG9jdW1lbnQgKGFkZHJlc3NlcyB2cy4gbmFtZXMpLg0K DQpUbyByZXNvbHZlIHRoaXMgaXNzdWUgSSB3b3VsZCBzdWdnZXN0Og0KDQpPTEQ6DQoNClRoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzIERIQ1AgKElQdjQgYW5kIElQdjYpIG9wdGlvbnMgdG8gY29uZmln dXJlDQpob3N0cyB3aXRoIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSBTZXJ2ZXIgYWRkcmVz c2VzLiANCg0KTkVXOiANCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgREhDUCAoSVB2NCBhbmQg SVB2Nikgb3B0aW9ucyB0byBjb25maWd1cmUNCmhvc3RzIHdpdGggUG9ydCBDb250cm9sIFByb3Rv Y29sIChQQ1ApIFNlcnZlciBuYW1lcy4NCg0KKDIpIEludHJvZHVjdGlvbjogIFRoaXMgb3B0aW9u IGRvZXMgbm90IHByb3ZpZGUgYW55dGhpbmcgYWJvdXQgInJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv biIsIGl0IHByb3Zpc2lvbnMgYSBsaXN0IG9mIFBDUCBTZXJ2ZXJzIG9uIGEgaG9zdC4gIFRoZSBE SENQIHNlcnZlciB3b24ndCBrbm93IGFueXRoaW5nIGFib3V0IHdoZXRoZXIgdGhvc2UgU2VydmVy cyBhcmUgcmVhY2hhYmxlIGF0IGFueSBnaXZlbiB0aW1lLCBvciBmcm9tIGFueSBnaXZlbiBwbGFj ZSBvbiB0aGUgbmV0d29yaywgc28gaXQgY2FuJ3QgY29udmV5IHRoYXQgaW5mb3JtYXRpb24uICAN Cg0KVG8gcmVzb2x2ZSB0aGlzIGlzc3VlIEkgd291bGQgc3VnZ2VzdDoNCg0KT0xEOg0KDQpUaGlz IGRvY3VtZW50IGRlZmluZXMgREhDUHY0IFtSRkMyMTMxXSBhbmQgREhDUHY2IFtSRkMzMzE1XSBv cHRpb25zDQp3aGljaCBjYW4gYmUgdXNlZCB0byBwcm92aXNpb24gUENQIFNlcnZlciBbSS1ELmll dGYtcGNwLWJhc2VdDQpyZWFjaGFiaWxpdHkgaW5mb3JtYXRpb247IG1vcmUgcHJlY2lzZWx5IGl0 IGRlZmluZXMgREhDUCBvcHRpb25zIHRvDQpjb252ZXkgYSBuYW1lIChhcyBwZXIgU2VjdGlvbiAz LjEgb2YgW1JGQzEwMzVdKSBvZiBQQ1AgU2VydmVyKHMpLg0KDQpORVc6DQoNClRoaXMgZG9jdW1l bnQgZGVmaW5lcyBESENQdjQgW1JGQzIxMzFdIGFuZCBESENQdjYgW1JGQzMzMTVdIG9wdGlvbnMN CnRvIHByb3Zpc2lvbiBhIGxpc3Qgb2YgUENQIFNlcnZlciBbSS1ELmlldGYtcGNwLWJhc2VdIG5h bWVzLg0KDQooMykgU2VjdGlvbiAzOiBDb25maWd1cmF0aW9uIG9mIGEgbGlzdCBvZiBzZXJ2cnRk IGlzIHF1aXRlIGNvbW1vbiwgYW5kIGl0IGRvZXMgbm90IHJlcXVpcmUgYSBsZW5ndGh5IHJhdGlv bmFsZSwgbm9yIGlzIGl0IHZhbHVhYmxlIHRvIGludmVudCBhIG5ldyB3YXkgdG8gdG8gZG8gaXQu ICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIG1vZGVsIHRoYXQgaXMgbm90 IHBlcnRpbmVudCB0byBtYW55IHVzZXMgb2YgUENQLCBhbmQgSSBhbSBjb25jZXJuZWQgdGhhdCBi eSBkZXNjcmliaW5nIHRoaXMgbW9kZWwsIHdlIGNvdWxkIGdpdmUgdGhlIGltcHJlc3Npb24gdGhh dCB0aGUgSUVURiBpcyBjb25kb25pbmcsIG9yIGV2ZW4gZW5jb3VyYWdpbmcsIHRoZSB0eXBlIG9m ICJvcmdhbml6YXRpb24iIGRlc2NyaWJlZC4gIEkgYW0gbm90IHN1cmUgd2h5IHdlIHdvdWxkIHdh bnQgdG8gZG8gdGhhdC4gIEFsc28sIHNpbmNlIHdlIGFyZSBtb3ZpbmcgdGhlIERTLUxpdGUgc3R1 ZmYgb3V0IG9mIHRoZSBCYXNlIFNwZWMsIGRpc2N1c3NpbmcgInRoZSBEUy1MaXRlIFVzZSBDYXNl IiBmb3IgUENQIGFzIHdlIGRvIGhlcmUgd291bGQgcmVxdWlyZSBhIHJlZmVyZW5jZSB0byB0aGUg bmV3IHNwZWMsIGFuZCBJIGRvbid0IHRoaW5rIG9uZSBzaG91bGQgYmUgbmVlZGVkIGluIGEgREhD UCBvcHRpb24gdGhhdCBpcyB1c2VmdWwgZm9yIGFsbCB1c2UgY2FzZXMuDQoNClRvIHJlc29sdmUg dGhpcyBpc3N1ZSwgSSB3b3VsZCBzdWdnZXN0Og0KDQpSZW1vdmUgc2VjdGlvbiAzLiAgUmV3b3Jr IHRoZSBvcHRpb24gdG8gYWNjZXB0IGEgbGlzdCBvZiBuYW1lcyBvciBJUCBBZGRyZXNzZXMsIGxp a2UgdGhlIE5UUCBTZXJ2ZXIgb3B0aW9uIChSRkMgNTkwOCkuDQoNCig0KSBTZWN0aW9uIDQ6ICBU aGVyZSBhcmUgYSBudW1iZXIgb2YgcHJvYmxlbXMgd2l0aCB0aGlzIHNlY3Rpb24uDQoNCig0YSkg SXQgaXMgcG9zc2libGUgdG8gcmV0dXJuIG1vcmUgdGhhbiBvbmUgUENQIFNlcnZlciBuYW1lIGlu IHRoZSBsaXN0LCBhbmQgaXQgaXMgcG9zc2libGUgdGhhdCB0aGVyZSB3aWxsIGJlIG1vcmUgdGhh biBvbmUgUENQIGNvbnRyb2xsZWQgZGV2aWNlIG9uIGEgaG9zdHMgb3V0Ym91bmQgcGF0aC4gIFNv LCB0aGUgZmlyc3Qgc3RhdGVtZW50IGluIHRoaXMgc2VjdGlvbiBpcyBzaW1wbGlzdGljLi4uICBJ cyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIG9wdGlvbiBjb25zdHJhaW5lZCB0byBjYXNlcyB3 ZXJlIHRoZXJlIGlzIG9ubHkgb25lIFBDUC1jb250cm9sbGVkIGRldmljZSBzZXJ2aW5nIGFzIGEg Z2F0ZXdheSB0byBhIGxlYWYgbmV0d29yaz8gIElmIHNvLCB5b3Ugc2hvdWxkIHNheSB0aGF0IHNv bWV3aGVyZSBpbiBoZXJlLiAgSWYgbm90LCBJIHRoaW5rIHlvdSBuZWVkIHRvIHNheSBzb21ldGhp bmcgZWxzZS4NCg0KKDRiKSBXaGF0IGlzICJhbnkgdGVybWluYWwgYmVsb25naW5nIHRvIHRoZSBz YW1lIHJlYWxtIj8gICJUZXJtaW5hbCIgYW5kICJyZWFsbSIgYXJlbid0IHdvcmRzIHRoYXQgYXBw bHkgaW4gYSB0eXBpY2FsIElQIG5ldHdvcmtpbmcgY2FzZSwgYW5kIGl0IGlzIHVuY2xlYXIgd2hh dCBpcyBtZWFudCBoZXJlLiAgDQoNCig0YykgV2hhdCBpcyBhIENQIFJvdXRlcj8gIERvIHlvdSBt ZWFuIGEgY3VzdG9tZXItcHJlbWlzZSByb3V0ZXI/ICBJZiBzbywgeW91IG5lZWQgdG8gZXhwYW5k IHRoZSBhY3JvbnltIHRoZSBmaXJzdCB0aW1lIHlvdSB1c2UgaXQuLi4gIEFsc28sIEN1c3RvbWVy IFByZW1pc2UgRXF1aXBtZW50IChDUEUpIGlzIG1vcmUgY29tbW9ubHkgdXNlZCBpbiB0aGUgSUVU RiwgSSB0aGluay4gIElmIHRoaXMgb3B0aW9uIGlzIHVzZWQgdG8gY29uZmlndXJlIGEgcm91dGVy LCBpcyBpdCBhc3N1bWVkIHRoYXQgdGhlIHJvdXRlciB3aWxsIHBhc3MgdGhpcyBpbmZvcm1hdGlv biBvbiB0byBpdHMgaW50ZXJuYWwgaG9zdHM/ICBPciB0aGF0IGl0IHdpbGwgc2VydmUgYXMgYSBQ Q1AgcHJveHkgZm9yIHRoZW0/DQoNCig0ZCkgIkN1c3RvbWVycyIgd2lsbCBleHBlcmllbmNlICJz ZXJ2aWNlIHRyb3VibGVzIiBhbmQgdGhlaXIgInNlcnZpY2Uocykgd29uJ3QgYmUgZGVsaXZlcmVk IGFwcHJvcHJpYXRlbHkiIGlzIGEgYml0IG9ic2N1cmUuLi4uDQoNCkkgYWxzbyB3b25kZXIgd2h5 IHRoaXMgc2VjdGlvbiBleGlzdHMgaW4gdGhpcyBkb2N1bWVudCBhdCBhbGwsIHNpbmNlIGl0IHNl ZW1zIG1vcmUgbGlrZSBnZW5lcmFsIGFkdmljZSBvbiBob3cgdG8gZGVhbCB3aXRoIGEgc2l0dWF0 aW9uIHdoZXJlIGEgUENQIFNlcnZlciBpc24ndCBjby1yZXNpZGVudCB3aXRoIHRoZSBkZXZpY2Ug aXQgY29udHJvbHMgdGhhbiBhbnl0aGluZyBoYXZpbmcgdG8gZG8gd2l0aCB0aGUgREhDUCBvcHRp b24uLi4gIEFsc28sIGl0IGlzbid0IHJlYWxseSBuZWNlc3NhcnkgdG8gdGVsbCBzb21lb25lIHRo YXQgaWYgdGhleSBtaXNjb25maWd1cmUgdGhlaXIgaG9zdHMsIHRoZXkgd29uJ3Qgd29yay4gIA0K DQpUbyBhZGRyZXNzIHRoZXNlIGZvdXIgcHJvYmxlbXMsIEkgc3VnZ2VzdCB0aGF0IHlvdSByZW1v dmUgc2VjdGlvbiA0Lg0KDQooNSkgU2VjdGlvbiA1OiAgVGhpcyBzZWN0aW9uIGRvZXNuJ3QgbWFr ZSBzZW5zZSB0byBtZSwgYXMgd3JpdHRlbi4gIFlvdSBoYXZlIGRlc2NyaWJlZCB0d28gb3BlcmF0 aW9uYWwgbW9kZWxzLCBidXQgSU1PIHRoZXkgbXVkZGxlIHRvZ2V0aGVyIHRoZSBub3Rpb24gb2Yg cmVjZWl2aW5nIGEgbGlzdCBvZiBQQ1AgU2VydmVycyAoaS5lLiBtdWx0aXBsZSBuYW1lcyksIGFu ZCBhIGxpc3Qgb2YgSVAgYWRkcmVzc2VzIGluIGEgRE5TIHJlc3BvbnNlIChpLmUuIG11bHRpcGxl IElQIEFkZHJlc3NlcyBjb3JyZXNwb25kaW5nIHRvIHRoZSBuYW1lKS4gIA0KDQpJTU8sIHlvdSBu ZWVkIHRvIG1ha2UgYSBkZWNpc2lvbiBoZXJlLi4uICAgIERvIHlvdSB3YW50IHRvIHRyZWF0IGVh Y2ggSVAgQWRkcmVzcyByZXR1cm5lZCBmcm9tIG5hbWUgcmVzb2x1dGlvbiBhcyBhIHNlcGFyYXRl IFBDUCBTZXJ2ZXI/ICBPciBkbyB5b3Ugd2FudCB0byB0cmVhdCBlYWNoIFBDUCBTZXJ2ZXIgbmFt ZSBwcm92aXNpb25lZCBieSBESENQIGFzIGEgc2VwYXJhdGUgc2VydmVyLiAgSXQgYXBwZWFycyB0 aGF0IHlvdSB1c2UgdGhlIGxhdHRlciAob25lIG5hbWUsIG9uIHNlcnZlcikgaW4gc2VjdGlvbiA1 LjEgYW5kIHRoZSBmb3JtZXIgKG9uZSBhZGRyZXNzLCBvbmUgc2VydmVyKSBpbiBzZWN0aW9uIDUu Mi4gIFRoaXMgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byBtZS4NCg0KSSAqdGhpbmsqIHdoYXQg eW91IHdhbnQgdG8gZG8gaXMgdG8gYWxsb3cgbXVsdGlwbGUgREhDUCBTZXJ2ZXIgbmFtZXMgdG8g aW5kaWNhdGUgbXVsdGlwbGUgc2VydmVycyB0aGF0IHNob3VsZCBiZSB1c2VkIGluIHBhcmFsbGVs ICh0byBjb3ZlciB0aGUgY2FzZSB3aGVyZSBhIHNpdGUgaXMgbXVsdGktaG9tZWQpLCBhbmQgdGhh dCB5b3Ugd2FudCBjbGllbnRzIHRvIHVzZSBlYWNoIHNldCBvZiBJUCBhZGRyZXNzZXMgYXMgYWx0 ZXJuYXRlIHdheXMgdG8gcmVhY2ggZWFjaCBvZiB0aG9zZSBzZXJ2ZXJzLCBidXQgdGhhdCBpcyBu b3Qgd2hhdCB0aGlzIHNlY3Rpb24gc2F5cy4NCg0KQWxzbywgd2h5IGRvIHlvdSBkZXNjcmliZSBh IFBDUCByZXRyYW5zbWlzc2lvbiBhbGdvcml0aG0gaGVyZSBpbiB0aGUgREhDUCBzcGVjPw0KDQpB bGwgeW91IHdhbnQgdG8gZG8gaW4gdGhlIERIQ1Agc3BlYyBpcyBkZXNjcmliZSBob3cgYSBub2Rl IGdldHMgaXRzIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gdGhyb3VnaCBESENQLiAgWW91IGRv bid0IHdhbnQgdG8gZGVzY3JpYmUgaG93IFBDUCB3b3Jrcy4gIFRoZSBQQ1AgYmFzZSBzcGVjIG5l ZWRzIHRvIGRlc2NyaWJlIGhvdyBQQ1Agd29ya3MgaW5jbHVkZWQgd2hhdCBpdHMgZXhwZWN0ZWQg Y29uZmlndXJhdGlvbiBsb29rcyBsaWtlLCB3aGlsZSByZW1haW5pbmcgbmV1dHJhbCBvbiB3aGV0 aGVyIHRoYXQgY29uZmlndXJhdGlvbiBpcyBvYnRhaW5lZCB2aWEgbWFudWFsIGNvbmZpZ3VyYXRp b24sIERIQyBvciBvdGhlciBtZWFucy4NCg0KVG8gYWRkcmVzcyB0aGlzIGlzc3VlOg0KDQpDb25z dHJ1Y3QgYSBESENQIE9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIHRvIGluZGljYXRlIHdoZXRoZXIg dGhlIFBDUCBTZXJ2ZXJzIGluIHRoZSBQQ1AgU2VydmVyIGxpc3Qgc2hvdWxkIGJlIHRyaWVkIGlu IHNlcXVlbmNlIGlmIHRoZSBwcmlvciBzZXJ2ZXJzIGFyZSB1bmF2YWlsYWJsZSwgb3Igd2hldGhl ciB0aGV5IHNob3VsZCBhbGwgYmUgdXNlZCBpbiBwYXJhbGxlbC4gIElmIGEgbW9yZSBjb21wbGlj YXRlZCBjb25zdHJ1Y3QgaXMgbmVlZGVkLCBkZXNjcmliZSB3aGF0IGl0IGlzLCBhbmQgSSB3aWxs IGhlbHAgeW91IHVuZGVyc3RhbmQgaG93IHRvIHJlcHJlc2VudCB0aGF0IGluIGEgREhDUCBvcHRp b24uDQoNCkRPIE5PVCBkZXNjcml2ZSBob3cgdGhlIFBDUCBDbGllbnQgd2lsbCB3b3JrIGluIHRo aXMgb3B0aW9uLiAgSG93IGRvZXMgYSBQQ1AgQ2xpZW50IHVzZSBtdWx0aXBsZSBzZXJ2ZXJzIGlm IHRoZXkgYXJlIGNvbmZpZ3VyZWQgc3RhdGljYWxseT8gIE9yIGlmIHRoZXJlIGFyZSBtdWx0aXBs ZSBkZWZhdWx0IHJvdXRlcnMgaW4gdGhlIGRlZmF1bHQgcm91dGVyIGxpc3QuICBBbGwgb2YgdGhp cyBvcGVyYXRpb25hbCBtb2RlIHN0dWZmIGJlbG9uZ3MgaW4gdGhlIFBDUCBiYXNlIGRvY3VtZW50 LCBub3QgaW4gYW4gREhDUCBvcHRpb24uDQoNCig2KSBTZWN0aW9uIDY6ICANCg0KKDZhKSBUaGUg RFMtTGl0ZSBleGFtcGxlIGlzbid0IGhlbHBmdWwgaGVyZS4NCg0KKDZiKSBBbHNvLCB0aGlzIG9w dGlvbiBvbmx5IGFsbG93cyB5b3UgdG8gY29uZmlndXJlIG9uZSBETlMgbmFtZSwgd2hpY2ggZG9l c24ndCBtYXRjaCBhbGwgb2Ygc2VjdGlvbiA1LiAgDQoNCig2YykgVGhpcyBkb2N1bWVudCBzaG91 bGQgbm90IHRlbGwgeW91IGhvdyB0byBjb25maWd1cmUgeW91ciBETlMgc2VydmVyLg0KDQooNmQp IFdoZW4geW91IHdhbnQgdG8gY29uZmlndXJlIGEgc2VydmVyIGxpc3QsIGl0IGlzIHR5cGljYWwg dG8gaW5jbHVkZSB0aGUgc2VydmVyIGxpc3QgaW4gb25lIG9wdGlvbiAoYXMgaW4gTlRQKSBub3Qg dG8gc2VuZCBtdWx0aXBsZSBvcHRpb25zIGFzIHNlZW1zIHRvIGJlIGRlc2NyaWJlZCBpbiB0aGlz IGRyYWZ0LiAgDQoNCig2ZSkgIEkgZG9uJ3QgZXZlbiBrbm93IHdoYXQgdG8gc2F5IGFib3V0IHRo ZSAibG9jYWwgY2FjaGUiIG9mIHJlc29sdmVkIGFkZHJlc3Nlcy4uLiAgSW5jbHVkZSB3aGF0IFRU TD8gIFdoYXQgY2FjaGU/IA0KDQpUbyBhZGRyZXNzIHRoaXMgaXNzdWUgSSB3b3VsZCBzdWdnZXN0 Og0KDQpSZW1vdmUgdGhlIERTLUxpdGUgZXhhbXBsZS4NCg0KTW92ZSB0byBhbiBvcHRpb24gbGlr ZSB0aGUgTlRQIERIQ1AgT3B0aW9uIGluIFJGQyA1OTA4LCBwZXJoYXBzIHdpdGggYSBmbGFnIHRv IGluZGljYXRlIHdoZXRoZXIgdGhlIHNlcnZlcnMgc2hvdWxkIGJlIHVzZWQgYXMgYSByZWR1bmRh bmN5IGxpc3QsIG9yIGFzIGEgbGlzdCBvZiBzZXJ2ZXJzIHRvIGJlIHVzZWQgaW4gcGFyYWxsZWwg KHNlZSBteSBzdWdnZXN0aW9uIGZvciBzZWN0aW9uIDUuDQoNClJlbW92ZSB0aGUgbWVudGlvbiBv ZiBob3cgdG8gY29uZmlndXJlIGEgRE5TIHNlcnZlci4NCg0KU3Vic3RhbnRpYWxseSByZXdvcmsg dGhlIGNsaWVudCBiZWhhdmlvdXIgc2VjdGlvbi4NCg0KKDcpIFNlY3Rpb24gNyBoYXMgbWFueSBv ZiB0aGUgc2FtZSBpc3N1ZXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNi4NCg0KKDgpIFRoZXJlIGlz IG5vIGxpbmsgYmV0d2VlbiB1c2luZyBESENQdjQgb3IgREhDUHY2IGFuZCBETlMgaW4gdGVybXMg b2Ygd2hhdCBJUCB2ZXJzaW9uIHdpbGwgYmUgcmV0dXJuZWQgaW4gYSBuYW1lIGxvb2t1cCwgYW5k IEkgZG9uJ3Qgc2VlIHdoeSB5b3Ugd291bGQgd2FudCB0byBpbXBseSB0aGF0IHRoZXJlIGlzLiAg DQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpwY3AgbWFpbGluZyBsaXN0DQpwY3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGNw ------=_001_NextPart022545016217_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Wasserman,
 
I've read draft-ietf-pcp-dhcp-02. I do agree with your comment that t= his=20 draft spends so many words
on what should not be described in the draft which just specifie= s an=20 option of DHCP, like the behavior
of PCP servers. Such clarification can be made in a draft titled=20 with text like 'Considerations of DHCP
options for the PCP'. Actually, I do agree with most part of what you= said.=20 However, I'm not so sure
if the statements in the abstract and introduction of = the=20 draft should be modified as you mentioned. 
Since getting the addresses, not just the names of PCP servers is the= main=20 objective of PCP clients,
and since providing the method for PCP clients to get PCP servers' na= mes=20 via DHCP is the purpose
of the draft, I don't think it's appropriate to say that=20 'This document specifies DHCP (IPv4 and IPv6= ) 
options to configure=20 hosts with Port Control Protocol (PCP) Serve= r names.' in=20 the abstract, or that
'This document defines DHCPv4 [RFC2131] and&= nbsp;DHCPv6 [RFC3315] options=20 to provision a list of PCP 
Server [I-D.ietf-pcp-base] names.' in the introduction. IMO= , the=20 current abstract and introduction of
the draft is ok, and it might be better if more details about th= e=20 acquirement of addresses of PCP servers
is provided in the section 5 or elsewhere.
 
Best Regards!
Yuchi Chen
 
Date: 2012-03-31 01:11
CC: pcp@ietf.org
Subject: Re: [pcp] WG last call on=20 draft-ietf-pcp-dhcp-02
 
I have read draft-ietf-pcp-dhcp-02.  I = support specification of a DHCP option to&nb= sp;configure hosts with the name(s) of their=  PCP Server(s), but I think there are&n= bsp;any issues with this document that need&= nbsp;to be addressed before publication.  My=  detailed comments are included below, but&n= bsp;I'll start with a couple of general = ;comments.
 
This document _way_ oversteps what should&nb= sp;be defined in a DHCP option, proscribing&= nbsp;quite a bit of operational behaviour of=  the PCP server including:  how to = ;handle multiple  PCP servers, how to h= andle retransmissions, etc.  More than half&= nbsp;of the information in this document doe= s not belong here.
 
Also, there is a lengthy discussion in&= nbsp;this document of whether to use IP = ;Addresses or Names, and I don't understand&= nbsp;any of that.  There are a number&n= bsp;of DHCP options that contain server list= s, and those servers can be represented = ;by either IP addresses or names.  For&= nbsp;an example of a good DHCP option d= efinition along those lines, please see the&= nbsp;NTP DHCP Option (RFC 5908).  IMO, = it would be much better to produce a&nb= sp;PCP Server DHCP Option based on the = NTP DHCP Option than to do it as d= escribed in this document.
 
Margaret
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Detailed Comments:
 
(1) The Abstract:  The text in the=  abstract does not match the document (= addresses vs. names).
 
To resolve this issue I would suggest:<= /DIV>
 
OLD:
 
This document specifies DHCP (IPv4 and = IPv6) options to configure
hosts with Port Control Protocol (PCP) = Server addresses. 
 
NEW: 
 
This document specifies DHCP (IPv4 and = IPv6) options to configure
hosts with Port Control Protocol (PCP) = Server names.
 
(2) Introduction:  This option does not=  provide anything about "reachability information= ", it provisions a list of PCP Servers&= nbsp;on a host.  The DHCP server won't&= nbsp;know anything about whether those Servers&nb= sp;are reachable at any given time, or = from any given place on the network, so=  it can't convey that information.  
 
To resolve this issue I would suggest:<= /DIV>
 
OLD:
 
This document defines DHCPv4 [RFC2131] and&n= bsp;DHCPv6 [RFC3315] options
which can be used to provision PCP = ;Server [I-D.ietf-pcp-base]
reachability information; more precisely it = defines DHCP options to
convey a name (as per Section 3.1 = of [RFC1035]) of PCP Server(s).
 
NEW:
 
This document defines DHCPv4 [RFC2131] and&n= bsp;DHCPv6 [RFC3315] options
to provision a list of PCP Server = [I-D.ietf-pcp-base] names.
 
(3) Section 3: Configuration of a list&= nbsp;of servrtd is quite common, and it = ;does not require a lengthy rationale, nor&n= bsp;is it valuable to invent a new way&= nbsp;to to do it.  This section describ= es an operational model that is not per= tinent to many uses of PCP, and I = am concerned that by describing this model,&= nbsp;we could give the impression that the&n= bsp;IETF is condoning, or even encouraging, = the type of "organization" described.  I&nbs= p;am not sure why we would want to = ;do that.  Also, since we are moving&nb= sp;the DS-Lite stuff out of the Base Sp= ec, discussing "the DS-Lite Use Case" for&nb= sp;PCP as we do here would require a&nb= sp;reference to the new spec, and I don= 't think one should be needed in a = ;DHCP option that is useful for all use=  cases.
 
To resolve this issue, I would suggest:=
 
Remove section 3.  Rework the option&nb= sp;to accept a list of names or IP = ;Addresses, like the NTP Server option (RFC&= nbsp;5908).
 
(4) Section 4:  There are a number=  of problems with this section.
 
(4a) It is possible to return more = ;than one PCP Server name in the list,&= nbsp;and it is possible that there will = ;be more than one PCP controlled device = ;on a hosts outbound path.  So, the&nbs= p;first statement in this section is simplis= tic...  Is the applicability of this op= tion constrained to cases were there is = ;only one PCP-controlled device serving as a=  gateway to a leaf network?  If so= , you should say that somewhere in here= .  If not, I think you need to&nbs= p;say something else.
 
(4b) What is "any terminal belonging to=  the same realm"?  "Terminal" and "real= m" aren't words that apply in a typical=  IP networking case, and it is unclear&= nbsp;what is meant here.  
 
(4c) What is a CP Router?  Do = ;you mean a customer-premise router?  If&nbs= p;so, you need to expand the acronym th= e first time you use it...  Also, = Customer Premise Equipment (CPE) is more com= monly used in the IETF, I think.  = If this option is used to configure a&n= bsp;router, is it assumed that the router&nb= sp;will pass this information on to its = ;internal hosts?  Or that it will serve=  as a PCP proxy for them?
 
(4d) "Customers" will experience "service tr= oubles" and their "service(s) won't be deliv= ered appropriately" is a bit obscure....
 
I also wonder why this section exists&n= bsp;in this document at all, since it s= eems more like general advice on how to=  deal with a situation where a PCP = ;Server isn't co-resident with the device it=  controls than anything having to do wi= th the DHCP option...  Also, it isn't&n= bsp;really necessary to tell someone that if=  they misconfigure their hosts, they won't&n= bsp;work.  
 
To address these four problems, I sugge= st that you remove section 4.
 
(5) Section 5:  This section doesn't&nb= sp;make sense to me, as written.  You&n= bsp;have described two operational models, but&nb= sp;IMO they muddle together the notion of&nb= sp;receiving a list of PCP Servers (i.e.&nbs= p;multiple names), and a list of IP add= resses in a DNS response (i.e. multiple = ;IP Addresses corresponding to the name). &n= bsp;
 
IMO, you need to make a decision h= ere...    Do you want to treat&nbs= p;each IP Address returned from name resolut= ion as a separate PCP Server?  Or = do you want to treat each PCP Server&nb= sp;name provisioned by DHCP as a separate&nb= sp;server.  It appears that you use the=  latter (one name, on server) in sectio= n 5.1 and the former (one address, one&= nbsp;server) in section 5.2.  This doesn't&n= bsp;make any sense to me.
 
I *think* what you want to do is&n= bsp;to allow multiple DHCP Server names to&n= bsp;indicate multiple servers that should be = ;used in parallel (to cover the case wh= ere a site is multi-homed), and that yo= u want clients to use each set of = IP addresses as alternate ways to reach = ;each of those servers, but that is not=  what this section says.
 
Also, why do you describe a PCP re= transmission algorithm here in the DHCP spec= ?
 
All you want to do in the DHCP&nbs= p;spec is describe how a node gets its&= nbsp;configuration information through DHCP.  You=  don't want to describe how PCP works.&= nbsp; The PCP base spec needs to descri= be how PCP works included what its expe= cted configuration looks like, while remaining&nb= sp;neutral on whether that configuration is = obtained via manual configuration, DHC or ot= her means.
 
To address this issue:
 
Construct a DHCP Option that can be&nbs= p;used to indicate whether the PCP Servers&n= bsp;in the PCP Server list should be tr= ied in sequence if the prior servers ar= e unavailable, or whether they should all&nb= sp;be used in parallel.  If a more = ;complicated construct is needed, describe what&n= bsp;it is, and I will help you understa= nd how to represent that in a DHCP = ;option.
 
DO NOT descrive how the PCP Client = ;will work in this option.  How does&nb= sp;a PCP Client use multiple servers if = ;they are configured statically?  Or if = ;there are multiple default routers in the&n= bsp;default router list.  All of this o= perational mode stuff belongs in the PCP&nbs= p;base document, not in an DHCP option.
 
(6) Section 6:  
 
(6a) The DS-Lite example isn't helpful = here.
 
(6b) Also, this option only allows you&= nbsp;to configure one DNS name, which doesn'= t match all of section 5.  
 
(6c) This document should not tell you&= nbsp;how to configure your DNS server.
 
(6d) When you want to configure a = server list, it is typical to include t= he server list in one option (as in&nbs= p;NTP) not to send multiple options as = seems to be described in this draft. &n= bsp;
 
(6e)  I don't even know what to&nb= sp;say about the "local cache" of resolved&n= bsp;addresses...  Include what TTL?  What&nb= sp;cache? 
 
To address this issue I would suggest:<= /DIV>
 
Remove the DS-Lite example.
 
Move to an option like the NTP DHC= P Option in RFC 5908, perhaps with a&nb= sp;flag to indicate whether the servers shou= ld be used as a redundancy list, or&nbs= p;as a list of servers to be used = in parallel (see my suggestion for section&n= bsp;5.
 
Remove the mention of how to configure&= nbsp;a DNS server.
 
Substantially rework the client behaviour se= ction.
 
(7) Section 7 has many of the same=  issues described in section 6.
 
(8) There is no link between using = ;DHCPv4 or DHCPv6 and DNS in terms of&n= bsp;what IP version will be returned in = ;a name lookup, and I don't see why&nbs= p;you would want to imply that there is= .  
 
 
 
 
 
 
 
_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp
------=_001_NextPart022545016217_=------